Tuesday, February 27, 2007

Becoming a Better Developer

Maybe this has been covered to death but, it still seems to be brought up.

Constantly Study
Study best practices, design patterns, refactoring techniques. Study the libraries and API's used in your development environment. Every other day I see re-implementations of methods provided in the java.util.Collections and java.util.Array classes. When you know whats available, you spend less time reinventing off the shelf code. Study anti-patterns, this helps avoid the most common mistakes.

Master Your IDE
Learn every keyboard shortcut in your development environment. One day, remove your mouse and hide it in your desk. Learn to use your environment without a mouse. Spend about 10 minutes every day learning to do something new with your development environment. When you know it inside and out, you can work more efficiently.
Use your IDE for everything. Need to write a word doc, write the text first with a text file in your IDE, copy paste; email too.
Some people even post lists of shortcuts. Most IDE's have them in the help pages. If not there, a quick google can reveal much.
Extend and Customize Your IDE
About every development environment in existence allows you to write extensions and plugins. You are constantly saying, I wish my IDE could do ... anyway. Write an extension to it. If you find yourself writing boring code, write a plugin to do it for you. "If it's worth doing once, write a program to do it."
This is once of the least followed recommendations. C',mon, this is your tool, customize it to allow you to work better and faster.

Master Your Environment
Much like your IDE, spend some time learning your other tools, your operating system, anything that eats up your time during the day. If you use ANT for builds, try to learn something new about it. Do you know the keyboard shortcut to minimize a window on your operating system? Change active windows? Do you use them? Can you use your email program without a mouse?

Learn New Programming Languages
In the "Pragmatic Programmer", Dave Thomas recommends learning a new programming language every year. Each language is invented with a different goal in mind. Each provides a different way of approaching and thinking about a problem. Next time you are faced with a difficult programming problem, ask yourself how you would solve it using something other than your primary language. Change the way you think.

Learn New Human Languages
This is an extension of the point above. Different cultures have different ways of looking at the world. Learning a language can give a small insight into the culture. Learning about the culture can help you with the language. Gaining new ways of looking at the world can give you new insights into approaching problems and developing solutions.
Being a good developer essentially means being good at solving problems. There are many useful problem solving techniques outside of the realm of programming.

Re-Study Your Basic CompSci
You don't need to do this constantly but, review this stuff every once and a while. Sure you know how to write a linked list, b-tree, finite state machine, etc. When was the last time you did? When was the last time you converted an array to a b-tree and back again? You might be surprised how quickly you can become rusty.

Refactor Some Old Code
Maybe your management won't let you refactor old code or check in the refactoring. Don't worry about it. Make a copy and refactor some code from an old project. By spending time thinking about how to make the code better, you will be more likely to do it right the next time you write new code. This makes a great programming exercise, its even better if you have some unit tests to verify changes as well.
Learn about refactoring. I highly recommend Martin Fowler's book on the subject, "Refactoring".
Write About Your Code
I'm not just talking about documentation. Think about if you were trying to explain the code to a novice programmer. Even though what you write may be considered 'lame' by some, don't worry about it. The process of trying to explain what you've done will help you to understand it better. This is really a progression of the ask the duck technique.
If you work in an environment where you can't publish such information publicly, then write it anyway, call it documentation, and pass it around to your fellow programmers.
One key thing is to develop a thick skin about feedback. You may receive scathing remarks. Don't weat it, and don't respond. Don't let your emotions get ahold of you. Just try to remove the meat of the remark and try to use it constructively.

Fat Angus also has suggestions on becomming a better developer
A humorous take on the subject
Learning Never Stops
Attestation tasks proposal
Becoming a Better Developer

Labels: , ,

Links to this post


At 28 February, 2007 00:03, Anonymous Anonymous said...

I agree with all the points you stated there. But that means developers have no life either if that is the case ^_^.

Remember, we work 9-5 (well, 8-4, whatever, the point is, 8 hours a day, sometime even more in startup environment). After work, your brain hurts a little bit and it needs some rest. Not to mention the time it requires for you to travel from office to home.

As one of my instructor said this to me: "You can't be good at two things. Either you're a lousy CEO or your a lousy father".

At 28 February, 2007 02:36, Anonymous Anonymous said...

Good topic. I don't, however, agree with much of what you say. I had a funny tingling as soon as you mentioned patterns and anti-patterns. They are symptoms of Java rot. Anyway, here are some points I call BS on:

- Learning human languages: ridiculous. Gaining different perspectives happens in all kinds of ways. Why stop at language? Learn new cultures, cuisines or religions! Meanwhile, I'd recommend something much more concrete: Learn to read code. Download a BSD or Linux kernel and learn to read. It's tough at first, but over time you'll be amazed at all the secrets that are contained in code.

- Master/Customize/Learn your IDE. Eek! Run the other way! There's yet to be an IDE that offers hald the raw editing productivity that emacs or vim offer. Do your brain (and wrists) a favor: invest in mastering a real editor and give the IDE the boot.

- Refactor: (another pet peeve: Stop using that word. It's more Java hype that's overblown). Instead - rewrite your code, often. Coding legends don't crank out perfection their first time around. What separates the hacks from the masters is that the masters looked at their first working implementation and said: "I can do better". The hacks are usually just happy that it works and move on to some other crap. Focus on writing the fewest lines of code you can: more code means more bugs. Focus on writing as few comments as you can. Pick variables names and expressions that are self explanatory. Save comments for state, not logic.

Oh - finally - here's my golden rule:

- Focus on staying motivated: in the end your productivity and learning depend solely on whether you enjoy what you're doing. Ignore or fix the crap that drags you down and surround yourself with people and things that motivate you. Oh, and enjoy every sandwich.

At 28 February, 2007 08:04, Blogger willCode4Beer said...

Patterns, Anti-patterns, Refactoring...
This as been going on longer than Java has existed.
Patterns provide a vocabulary to explain something without going into the details everybody already knows. Its about communication. BTW, when the GOF book was written targeting C++ developers.
Anti-patterns are about avoiding the common same mistakes everybody else makes.
Refactoring is good regardless of your development language.
Language, culture... lets face it, the hard part of programming is NOT the code, its solving problems. The code is just the language we use to express to solution to our problems.
BTW, I started with VI/make. It took a whiule to convert to useing an IDE. You say just use emacs, fine. Are you saying you don't customize emacs? You don't have a collections of shortcuts and scripts for emacs? Its the same thing. VIM is most useful when you've customized your .vimrc file. Why wouldn't you do the equivalent in an IDE?

At 28 February, 2007 11:21, Blogger sjf said...

Nice tips.

Anonymous: you don't think emacs is an IDE?

At 28 February, 2007 20:52, Anonymous dc said...

You could say that becoming part of your community is another way. I've learned countless thing from cough(slashdot), dzone, blogs like this one. Becoming part of the developer community is quite hard and because you have to put your self out there and that's scary especially when it's all in writing!

Good post. How did I get a five ?

At 05 March, 2007 09:12, Blogger Chris Roland said...

You could always make your IDE (Visual Studio) more powerful with a Vi plugin, e.g. www.viemu.com.


Post a Comment

Subscribe to Post Comments [Atom]

<< Home

Links to this post on: