antwerkz

Every developer has his own idea of what makes for good development processes.  I'm not so presumptuous to think that my approach is the best but it's served me well so far.  I've talked to numerous beginners who keep stumbling over some very basic concepts and techniques.  While beginners certainly aren't to blame for such missteps, I've seen some not-so-beginners that continue to stumble over these same points.  So I thought I'd take a few minutes and share some of my thoughts as a starting point for discussion at least.  I offer these ideas without any warranty or expectation.  These ideas work for me.  So take what I say with a grain of salt, see if they work for you, then adapt/reject those that don't.

Put Off Using an IDE

When learning a new language, you should try doing as much of the early work as you can using just a text editor.  This will help you learn the environment and the syntax and the environment of a language without having an IDE obscure those details.  For example, I run the ##java channel on freenode.  I spend a lot of time helping out newbies figure out how to make things work in java.  More often than not, these newbies are using Eclipse to do their development.  There are aspect of using an IDE that are very helpful, but many of these beginners don't know what a classpath, a vague notion of packages, have no real idea about to compile their code, and are completely helpless when it comes time to share their work with someone else.

Spending even just a few weeks with nothing but vim and javac, most people should be able to build a comfortable level of experience with the language, the tools, and the environment.  However, many beginners I come across choose not to do this and struggle with the fundamentals of Java for far longer than is really warranted.  Once these concepts start to settle in to a developer's mind, I highly recommend using an IDE.  IDEs are great for exploring the API and speeding up the development process.  They're just not that great at helping someone learn everything else that goes with it.

Keep a Beginner's Mind

I've spent a lot of time over the years helping newbies in IRC and I've noticed a disappointing trend:  A newbie comes in and complains about getting a ClassNotFoundException.  We give him links to documents detailing such concepts as classpaths and packages and imports and the like.  Oftentimes, what we get back vehement declarations that, yes, he does know what classpath is; no, he is not an idiot; yes, he has tried that why do we think he tried asking in IRC.  Despite demonstrated ignorance on the subject, these newbies insist they already know what they need to know on the subject.  It's very difficult to get anything across to these types of users.

So when tackling a problem, keep a beginner's mind.  Knowing is an impediment to learning.  If you're so sure you know what you need to know, you'll almost certainly miss any of the finer details missing from your understanding.  I've seen this happen time and time again.  No matter how skilled you may think you are, never assume total mastery on a subject.  There's a reason that you ask others for help:  other people may know something you do not.  If you assume that you already know what they're trying to tell you, you'll miss whatever aid they may be able to give.

Get It Working First

Have you ever had a conversation where someone asks questions like "What should I name this class?" or "Which is faster?  X or Y?" or "What's the most efficient way to ... ?"  I've seen these conversations last far longer than it would've taken to write a simple, working implementation.  If they'd have just written the code, they'd have been done.  When writing new code, I try to keep this maxim in mind:  working slow code is better than lightning fast nonworking code.  Working code can always be optimized and improved.  It can also be delivered to a customer.  Nonworking code really can't (or at least shouldn't be).  Don't get so caught up in such details early on that you fail to deliver anything at all.  As Donald Knuth said, "Premature optimization is the root of all evil (or at least most of it) in programming."

Use Tools When You Can

I know I just said to put off using an IDE but this isn't really contradictory.  Understanding what you're doing and the libraries you're using is a fundamental part of writing excellent code.  However, doing things well and quickly is a win/win.  Once you understand the fundamentals of what you're doing, putting good tools to work can dramatically increase your productivity.  What those tools can look like can run the gamut from simple bash scripts to IDEs to the most enterprisey workflow suites available.  In many cases, you can get these tools off the "shelf."  In others, you might need to write scripts or smallish programs.  Personally, I think if you do something more than once, it should be scripted the second time.  If you're pretty sure you're going to be doing something again and again, it should be scripted the first time.  It means being a little slower up front but yields tremendous dividends down the stretch.

Reevaluate Periodically

Continuing on the theme of tools, I think it's helpful to periodically reevaluate your options.  I'd used vim for years and was content with that.  I decided at one point to give eclipse a try and was pleased with it.  Shortly thereafter, I tried IDEA to see what the fuss was all about.  I fell in love.  I've used IDEA ever since.  I still keep an eye on the other two big ones, though.  I try to give both Eclipse and Netbeans a spin every so often.  By doing so I've discovered that Eclipse still feels like running in wooden shoes a size too small.  However, I've also found that Netbeans has made some really nice strides.  The refactoring features still are lightyears behind IDEA's but the IDE itself is much, much nicer than the first time I tried.  Consequently, I've ended up using Netbeans from time to time for things it does a bit better than IDEA.  (There aren't many, to be honest, but I do flip back and forth sometimes.)

If you pick one tool and never look back you can really miss out on some advantages that newer versions of other products bring.  For example, I recently made the switch to maven and have been able to take advantage of things I'd previously been missing.  I'm still not 100% please with the state of the world in maven-land but I'm becoming proficient enough to overcome most objections I'd been harboring.  Using other tools (and other programming languages) is a good way to keep limber mentally even if you do end up continuing to use the same tool.