By Janice J. Heiss,
December 2008
Since 1999, JSC writers have interviewed Java developers from diverse backgrounds and solicited their advice for students. In this article, 11 top Java developers share the fruits of long experience.
Joshua Bloch When we ask Java developers about their favorite Java book, they repeatedly refer to Effective Java by Joshua Bloch. So his advice seems like a good place to start.
Chief Java architect at Google, Joshua Bloch is well known as the author of Effective Java , now in its second edition, and coauthor with Neal Gafter of Java Puzzlers .In a former life as a senior staff engineer at Sun Microsystems and an architect in the core Java platform group, Josh Bloch designed and implemented the award-winning Java Collections Framework and contributed to many other parts of the platform, including the java.math
package.
Bloch holds a Ph.D. in computer science from Carnegie-Mellon University, where during the defense of his dissertation, which was open to the public, he arranged for his mother to ask a long technical question that he answered flawlessly after saying, "Awww, Mom!" He responded to another planted question with a rap song, backed by a recorded rhythm track played on a boom box concealed under the desk.
Bloch is fond of saying, "Computer science is an immature discipline, and I aim to keep it that way."
"Write lots of code. Have fun with it!"
Write lots of code. Have fun with it! Collaborate with people who are more experienced than you and learn from them. Join an open-source project. Code reviews are a great way to learn. Don't be embarrassed when people find problems in your code; fix them and have fun watching your code and your skills improve. Oh, yeah, and go buy a copy of Effective Java .
Effective Java is written for experienced Java developers. Do you have any advice for how a computer science major in college might benefit from the book? Or an experienced developer moving from another language to Java?
Many programmers find it useful to keep a copy at their desk so they can look at the code examples and such while they work. Also I've seen people use item references in comments explaining their design decisions. Needless to say, I'm honored that they've done so. As for programmers moving from another language, I think they'd do well to read a quick introduction to Java before tackling my book. Peter Sestoft's Java Precisely would be an excellent choice.
What are some things you wish you'd learned in engineering school?
I wish I'd learned to play guitar better than I do, which isn't very well. I wish I'd learned a foreign language. And art history. Also, it would have been nice to learn something about business and finance. That said, Columbia did very well by me. But I would encourage undergraduates to take the opportunity to acquire breadth while they still have time for it. They'll have plenty of time for depth later.
Read the full interview with Josh Bloch.
Tor Norbye is a principal engineer at Sun Microsystems, where he has worked on development tools since 1996, most recently on the Ruby and JavaScript editors in the NetBeans IDE. He is also a cohost of the weekly Java Posse podcast and specification lead for Java Specification Request (JSR) 273. He has a master's degree in computer science from Stanford University, where his classmates included Google cofounder Larry Page.
Three things.
1. Learn to use your tools. And I don't mean just enough to get by. I mean really learn how to use your tools. Become an expert user. After you've learned all the items in menus and context menus, and after you've learned the most important key bindings, then Google "tips and tricks" for your IDE.
"Learn to use your tools. And I don't mean just enough to get by. I mean really learn how to use your tools."
Learn how to use built-in code templates. Learn how to use the quick fixes. For example, in NetBeans, you don't have to write the left-hand side in assignments when you're calling a method. Just write this:
"foo".indexOf("o");
Move the caret inside indexOf
, the method name, and type Alt-Enter. Assuming you're calling a method that has a return value, and you're not already reading the return value, NetBeans will generate the left-hand side of the assignment -- including the type declaration -- for you:
int indexOf = "foo".indexOf("o");
At this point, you're in code-template-editing mode, so you can type a new name for the result variable.
Similarly in NetBeans, try typing newo
and hit Tab. Go ahead. Try it.
And that's just the editor. You also need to know how to properly use the debugger, profiler, and version-control integration.
2. Learn how to make trade-offs. When you're a computer science student, you typically have programming assignments where the inputs and outputs are pretty clear, and the scope is limited. You can write a "perfect" program that's well documented, elegant, fully tested, and correct. In the software industry, that's often not the case. There's a never-ending list of requests. You've often taken over somebody else's code, and you're not thrilled with the way it was written.
Then, at least for mature products, there's also a pretty large number of low-priority bugs -- bugs that are real but of limited impact, so they didn't hold up the last release. What is more important: Add a feature that will benefit a lot of users, or fix a bug that affects almost nobody? Rewrite the code to make it more maintainable, something most programmers long to do? Spend time helping users of the current shipping version of the software? There aren't enough resources to do everything, but they're all important. So you end up having to time-slice to address at least some of these, and in addition, make hard choices.
And even if you have perfect time-management skills, or your manager makes priority choices for you, at the end of the day, as an engineer, the software discipline is also filled with trade-off choices. To speed up some code, you can make it faster by adding a cache -- but that drives up memory consumption. Is that trade-off worthwhile? Congratulations, it's your job to answer that one.
3. Finally, learn the platform APIs. There's a huge number of well-written and performant classes in the Java platform, along with some utility classes around them. Make sure you have a good grasp of all the available functionality in the platform before you write your own code. For example, yes, there's no reverse()
method on the java.util.List
interface. But not so fast -- don't write it yourself. There's a Collections
class that contains a lot of utility methods that operate on collections, like List
, and it provides a reverse()
method.
And if you're building on top of a rich-client platform like NetBeans, or using other libraries like the Google Collections API or some of the Apache libraries, there's a wealth of additional APIs you can reuse. For example, when I write my unit tests for NetBeans code, I can rely upon additional testing infrastructure written for NetBeans that make it simple to add performance-related tests or memory leak tests.
Chet Haase is a senior computer scientist on the Flex SDK team at Adobe, focusing on graphics issues and features. In a former life, at the time of the following interview, he worked for Sun Microsystems as a client architect in the desktop Java group. He is coauthor with Romain Guy of the book Filthy Rich Clients: Developing Animated and Graphical Effects for Desktop Java Applications . He is also the author of a humor book, When I am King.
What advice do you have for someone who wants to have a career creating graphics software?
Take the math courses you need. It doesn't need to be higher-level stuff, but I've leaned heavily on linear algebra and some amount of calculus for a lot of what I've done.
What advice would you give to a programmer new to the Java programming language?
Don't use line numbers. Don't put your entire application in one method. Trust the garbage collector to do its job.
Is there anything you wished you'd learned in engineering school?
I actually could name lots of things I learned in engineering school that I wish I hadn't wasted my time on. One big difference is that you work on new and small projects in school and huge and old projects in the real world.
"Don't use line numbers. Don't put your entire application in one method."
For example, the code I work on at Sun is part of the JDK library that has been in constant development for well over 10 years. Frequently, the hard part of any fix or feature is not the functionality of the fix or feature itself, but rather how it integrates with all of the code around it. Does the fix break compatibility? Does it conflict with anything going on around it? Do you understand the context of the code? This is something that's particularly difficult in old code bases in which the original developers have all left long ago. Does your team agree with and understand the changes?
I don't know how to cover such topics in school effectively, especially in the tight time frames of individual classes, but the more students are exposed to team development, versus individual projects, the easier it is for them to become integrated into team development in the real world.
Related to team development, I think code reviews would be a great tool for school. I've probably learned more about coding practices and the code I work on through the reviews we do in the client group than in coding itself. You learn how others do things, you get objective perspectives on how you do things, and everyone comes to a shared understanding of how teams should develop common code.
Ben Galbraith is a frequent speaker, independent consultant, conference producer, and author of several books. He is an experienced CEO, CTO, and software architect, and was hired in October 2008 by Mozilla to lead an initiative to create web development tools that will make life easier for web developers. He wrote his first computer program at age 6, started his first business at age 10, and entered the IT workforce at age 12. For the past few years, he's been professionally coding in the Java language and was the top-rated speaker at the 2006 JavaOne conference.
I believe all software engineers should learn about how to ensure that their users have a quality experience. I covered some aspects of that topic in my 2008 JavaOne conference talk Creating a Compelling User Experience.
I think the roles of a software developer are a bit up in the air at the moment. Not many years ago, we developers were sort of gatekeepers: No software was created unless we wrote the code, and we interpreted designs and direction we were given as we thought made sense.
Now, there are a bunch of efforts by the platform vendors -- Microsoft, Adobe, Sun, and so on -- to empower a less technical audience to create software. Microsoft Expression, Adobe Thermos, and perhaps some future tool from Sun are all about letting a more creative, less technical person create user interfaces that in the past would have required all kinds of code and engineering effort.
This reflects an emerging trend in recent years to reify a new, highly technical designer, often called an interaction designer, as the leading force in software development, rather than engineers. To get a fascinating look at this effort, Google for a transcript of Alan Cooper's keynote at the Interaction08 conference.
So how will software be developed tomorrow? And where do new entrants fit into all of this? Lots of different people can feel passionate about being involved in the creation of beautiful, compelling software. I think such people have got to figure out whether they are at heart an engineer -- if they get their kicks solving hard technical problems -- or if they are something else.
"There will always be opportunities for great engineers, but as I said earlier, I think the number of these opportunities will shrink as other, less technical personnel play larger roles in the software-development process, using more productive, higher-level tools and frameworks than we have used in the past."
There will always be opportunities for great engineers, but as I said earlier, I think the number of these opportunities will shrink as other, less technical personnel play larger roles in the software-development process, using more productive, higher-level tools and frameworks than we have used in the past.
Newcomers should find one or more mentors as soon as you can. Google makes finding information easier than ever, but nothing beats interacting with an expert.
Masood Mortazavi, a software engineering manager at Sun, started his work with the company on the Java EE development team and as an expert in continuous availability issues and telecom collaborations with the Java software group. In recent years, he's managed teams of engineers who contribute to open-source databases such as Apache/Derby, PostgreSQL, and MySQL.
He has a B.S. (U.C. San Diego) and an M.S. (U.C. Davis) in applied and chemical engineering, and a Ph.D. in computational fluid dynamics with a dissertation titled Vortex-Vortex Interactions and PDF Methods (U.C. Davis). In addition, he has a master's degree in journalism (U.C. Berkeley) and an M.B.A. (U.C. Berkeley), and he spent several years pursuing a second Ph.D. in the Graduate Group in Logic and Methodology of Science (math, philosophy, and computer science) at U.C. Berkeley, with a focus on foundations of math, theories of computation, and philosophy. He stopped work on his second Ph.D. soon after joining Sun in 1999.
Start simple. Learn the basics of the language, and even before that, make simple modifications to existing, running programs and see what happens.
Tap into the amazing online documentation resources.
Write the most advanced program you can concoct, choosing something that tickles your imagination, to stretch your own limits, and if you can, to stretch the limits of the Java platform.
Get involved and write programs for some commercial or open-source software that matters and that people actually use.
As you advance, select a great IDE to work with, say NetBeans. (Sometimes this is necessary earlier.)
Keep learning about the systemic use of Java in system programming. There are lots of pleasant surprises there.
Don't forget that billions of dollars of revenue have been generated and millions of people have been employed because someone at Sun Microsystems invented Java, and a group of dedicated engineers kept producing innovations around it. So contribute to the goodness.
Can you name some things you wish you'd learned in engineering school?
"Millions of people have been employed because someone at Sun Microsystems invented Java."
Yes -- more design, more marketing, more business, more economics, more management and organizational theory, and finally, more philosophy and art -- all in that order or some other combination, to create a good mix of ideas.
Unfortunately, while going through four different University of California campuses, Stanford University, and some other schools as an engineering student and researcher, I didn't observe an interest in bringing these other disciplines into the life of an engineering student. Unfortunately, students are kept in the silos of their own academic disciplines. Even in science and technology, they are divided into various minidisciplines with very little cross-pollination.
I myself did have some lucky breaks. For example, my Ph.D. advisor, Dr. Wolfgang Kollmann, was very open to my exploration of various areas. While conducting research in computational fluid dynamics with him, I also took advanced courses in biochemistry, embryology, linguistics, and linguistic neurophysiology, along with courses in art, philosophy, economics, and political science. I also worked on the university paper.
This is a very general problem in American education that probably exists elsewhere as well. We're "mass producing" technologists and scientists with narrow focus and with little care for their development as leaders and creative inventors who can help us to disclose new ways of living, working, and prospering.
European engineering schools have had a tradition of teaching these other disciplines along with engineering. We cannot compete globally unless we train top-notch engineers who have a broad perspective about how their technical work fits into other domains and who understand the institutional place for technology. Otherwise, it's highly unlikely that we will be able to continue to tap technology for the general social good, beyond the production of gadgets.
Raghavan "Rags" Srinivas, was, until recently, a technology evangelist at Sun Microsystems, focusing on new technology directions and trends. With 20 years as a software developer and 7 years in technology evangelism, his general area of interest is distributed systems, specializing in interoperability, mobility, and security. He publishes a standards column and has represented Sun at a number of standards bodies. Rags holds a master's degree in computer science from the Center of Advanced Computer Studies at the University of Louisiana at Lafayette.
Don't be overwhelmed by the language or the platform. If you break it down, the basics of the language are based on object-oriented programming, threading, concurrency, and event-driven programming. It's necessary to become a master of these concepts since the rest of your career will depend on this foundation.
"Don't be overwhelmed by the language or the platform."
After that, one can specialize in one or multiple areas, which might involve designing GUIs, doing web stuff, JDBC programming, EJB/JMS programming, security, and so on. If one's foundation is strong, it's fairly easy to move from one area to another with relative ease.
Cay Horstmann is professor of computer science at San Jose State University in California. He was named a Java Champion in 2005, an award given to individuals working outside of Sun who have received special recognition from Java technology developers across industry, academia, Java User Groups (JUGs), and the larger community. He has a Ph.D. in mathematics from the University of Michigan, is the author of Core Java , and coauthor of Core JavaServer Faces .
First, don't panic. When students first see the API with thousands of classes, they despair. I used to be able to tell them, "That's OK, at least the language itself is very simple." But that was before this:
static <T extends Object & Comparable<? super T>> T
Collections.max(Collection<? extends T> coll)
As a student, you need to stay within a safe subset of the Java language and the API so that you can use it as a tool to learn some good computer science.
"When students first see the API with thousands of classes, they despair."
Next, code. Professional programmers often forget how hard it is for most beginners to actually program. It's so unlike most activities. The computer is unforgiving. When you're wrong, you're told very quickly that you were sloppy or stupid -- not a good thing for a fragile ego. And when you are wrong, you need to stop and think. Random tinkering rarely gets you anywhere.
This is a really hard sell to today's students. Your ego isn't stroked very much, and you'll get a headache trying to fix your mistakes. A career in divorce law sounds so much more attractive. But when you succeed, it sure feels good. The trick is to get students to that point.
Last summer at a faculty summit at Google, bigwig professors from big-name universities expounded on their efforts to reform the computer science curriculum and make it less focused on programming. The organizers from Google said, "That's all fine and good, as long as the students can code when they graduate."
Arun Gupta is a technology evangelist for web services and Web 2.0 apps at Sun. He was the spec lead for APIs in the Java platform, a committer in multiple open-source projects, a participant in standards bodies, and a contributor to Java EE and SE releases. He holds a B.S. in electronics and an M.S. in computer science, both from Delhi University, India.
As a beginner, I used a lot of vi (visual editor). But now I've been using IDEs, like the NetBeans IDE, for the past couple of years, and I must say my productivity has gone up multifold. Specifically, features like boilerplate text, refactoring, and debugging are much easier to work with in IDEs than manually or using pluggable scripts in the vi environment.
For instance, if I'm writing a Java bean, then I need to give the class name, field names, and their types, and the rest of the boilerplate text of getters/setters is generated for me. I can set up a breakpoint when a particular exception is thrown, and the IDE will halt whenever that exception is thrown. I can change a class name or move it to a different package name, and all of its references are updated accordingly. These are simple but powerful examples.
"I really recommend that new users try out different IDEs and pick one of their choice."
And some IDEs have very powerful features such as remote debugging. The IDEs keep me focused on the logic part of my code and take care of code logistics for me. I really recommend that new users try out different IDEs and pick one of their choice. For instance, the NetBeans IDE is available free.
In school, I didn't realize the importance of documenting. I would go through design, develop, and test cycles but would not document the design decisions or add comments in the code. This would make even my own code unreadable to me, sometimes a few weeks after I wrote it. UML designing and adding Javadocs liberally through the code has helped me write readable code.
Secondly, I wish we had more participation from industry in school. It would have been good for someone currently working in the industry to talk to us about industry trends, practices, and standards.
Every time I visit Delhi, I go back to my school, meet the faculty, and mingle with the students. I give a presentation on the latest industry standards in my field, discuss the importance of coding standards, and show code samples. During my last visit, I started working with some students on a new web services-related project and hope to inculcate in them the great coding practices that we follow at Sun.
Rick Cattell is an independent consultant in database systems and in engineering management. He was previously a Distinguished Engineer at Sun Microsystems and has worked most recently on open-source database systems and proprietary innovations in database systems. He served for more than 20 years at Sun Microsystems in management and senior technical roles, and for more than 10 years in research at Xerox PARC and at Carnegie-Mellon University, where he received his Ph.D. in computer science.
Cattell is best known for his contributions to middleware and database systems -- particularly enterprise Java, object-oriented databases, object/relational mappings, and database interfaces. The author of several dozen papers and six books, Cattell is also known for a talk titled "Things I Wish I'd Learned in Engineering School," which he has presented at universities around the United States.
First, I didn't realize how important it was, for me at least, to work on things that people are actually going to use. I didn't realize that it wasn't very satisfying to write research papers or even to build working systems if the results of my labor weren't going to be used in the real world.
"Good technology is only 10% of success."
I also didn't realize that good technology is only 10% of success. If your management doesn't know how to manage a successful engineering project, or your marketing department doesn't know how to access the customers, or doesn't tell you what the customer wants, or if your lawyers don't handle your intellectual property correctly, or if the chief architect doesn't have the ability to create a consistent and simple architecture, then your work can be for naught, and you can spend years building things that never see the light of day.
en he first joined Sun Microsystems in Hong Kong. Now based in Singapore, he works as a Sun Java technology evangelist and frequently helps individual developers and software vendors to architect and prototype both their server and desktop-based Java applications. His more recent work has focused on Swing-based client applications. He also keeps ISVs up-to-date on the latest developments in the Java platform and what's on the horizon.
"Choose an area of your immediate need."
He graduated in 1987 from the Royal Melbourne Institute of Technology in Melbourne, Australia, where his favorite subject was compiler theory.
First and foremost, I would suggest exploiting the web. There's tons of learning material. There are forums to post your queries and download open-source code. Getting books is another good way, but I've had people complain to me that the moment they buy any technology-related book, it's already out-of-date. I suggest trying the local library or subscribing to something like Safari Bookshelf.
For a beginner, the plethora of Java APIs can be quite intimidating. Choose an area of your immediate need, for example, web programming, servlet/JSP/JSF, GUI, Swing, persistence, JDBC/JDO (Java Data Objects)/CMP (container-managed persistence), or what have you. Work on a project that gives you experience in using the API, the development tools, and the runtime environment. Keep the project manageable -- I tend to pick something that is fun and that I can complete in three months max.
Tom Ball is a software engineer at Google, working on Java development tools. He began working with Java in 1994 as part of Sun's JDK, AWT, Swing, Jackpot, and NetBeans teams, and contributed to the JavaFX Script compiler team. He has no formal university education.
Programming is still a craft, so the more you can work with senior developers, the more you'll learn of the important stuff the computer science professors don't teach. If you have time, join an open-source project and help out in any way you can to learn and to build credibility with your peers.
But don't join every project you find interesting. I've seen many enthusiastic newcomers spread themselves too thin, overcommit, and thus not be taken seriously.
Finally, get to know the various Java communities through their forums and blogs, then join in. We're a great group!