willCode4Beer

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
backlinks:
A humorous take on the subject
Learning Never Stops
Attestation tasks proposal
Becoming a Better Developer

Labels: continuing education, development, practices

posted by willCode4Beer @ 4:45 PM