After some responses to my post on becoming a better developer. I figured that I should add some time management to it. I know the list looks like a lot of stuff but it shouldn't really consume much time. Most of the tasks should result in creating more free time resulting in a greater payout as time goes by.
So, lets get started.
- Constantly Study
- This one actually requires that you have at least a little passion for what you do. Sitting down with a book for half an hour to an hour a few days a week isn't going to kill you or take away from your family life
- Master Your IDE
- Take 5 minutes at the beginning of the day to learn ONE new thing. You will have recouped the time several times by the end of the day. They payoff occurs every day
- Extend and Customize Your IDE
- Granted, this can take a few hours. But, you really get the payoff in crunch time because you can work faster. You also get a mental payoff, by letting the machine perform the boring tasks.
- Master Your Environment
- Much like mastering your IDE, invest a couple of minutes and reap the benefits almost instantly and continuously.
- Learn a New Programming Language
- A professional programmer should be able to pick up a new language in a day, max two. Sure it takes longer to learn the libraries, best practices, and standards around a new language but, just give it 30 minutes to an hour a day. You don't need to *constantly* be learning a new language. Do it during the slower work periods. You've got a whole year for crying out loud.
- Learn New Human Languages
- Just pick up a Berlitz program and listen to it during your commute instead of Howard Stearn. Your brain will thank you.
- Re-Study Your Basic CompSci
- Refactor Some Old Code
- Write About Your Code
- Just do these during lulls at work; or on your laptop while sitting in meetings. Like learning a new programming language, you don't need to do these everyday. Just take it out of your Slashdot/Digg/Reddit/DZone time. Hell, if you found the time to read this post...
You don't have to give up your life to do things to develop yourself as a programmer. Just use a few minutes here and there. Make good use of down time. These things provide a cumulative effect.
One of the best things you can do is to get out and have a life. Work on the car, chop up some wood in the garage and turn it into something. Take the kids to the zoo. Do things that make you use your brain.
Get a different perspectives on the world.
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 developerbacklinks:A humorous take on the subjectLearning Never StopsAttestation tasks proposalBecoming a Better DeveloperLabels: continuing education, development, practices
Sometime we find ourselves with complex sets of requirements. All too often, this results in lots of convoluted unmaintainable code. Lets start early with the concept of using a rule engine or a state machine.
A good rule engine can be great when dealing with "conflicting" requirements. You can reverse the logic and show WHY something happened.
State machines really excel in event driven environments (like your J2EE app). Especially when complexity can get out of hand quickly.
Why use these. Well besides that its an established method and people might be able to understand your code...maintainability is enhanced. A new line (or modifying a line) in a state table is pretty easy. Modifying a rule (with Prolog) is much easier than diving into a rats nest of deeply nested if/elseif/else statments.
Why don't we do this more?
UpdateI found a great explanation for
a rules engine. The example used is highly approved by this site.
;-)
I just started rereading
Steve McConnell's book
Code Complete
(yes I know, I need to get the second edition). Its one of these things I do, every few months or so, I go and re-read books in my collection of development practices.
Anyway, very early on, he mentions several things about design and about keeping it in scope. You don't go about building a doghouse the same way you do a skyscraper.
A bigger point comes to mind. We developers treat programming languages and design patterns as tools in the toolbox called our brain. No serious developer only knows one language. We pick the best language and platform for the task at hand. We don't just use one design pattern, we pick the one that best fits the problem. So, why don't we treat our methodologies the same way? What about our development processes?
You don't spend a week planning to build a doghouse. You don't find a doghouse architect. You don't design a doghouse down to the last nail. You sketch it out on a napkin and drive to the hardware store. You finish it in an afternoon. A doghouse doesn't need a big process.
In the same mode of thinking, you don't hire contractors to build an office building from a back of the envelope sketch.
So, with XP, RUP, SCRUM, Waterfall, BUFD, etc.... why does everybody say there can only be one process (that should be used on every project)? Why not evaluate the scope of the project, the clarity of the requirements, the schedule, and the customer; then pick the best process for the project.
To my observation this is the downfall of CMMI. CMMI requires that all projects should be built with the same process. Sure there are means to customize the process but, its still the same beast no matter what.
Another good post about giving sanity to development processes:
Software Development ProcessesUpdate: Manuel has written a great
response mentioning how some tools just plain belong in other fields of use.
This keeps popping up. The latest is Java vs Ruby (it seems the last was Java vs Python). Many of the arguments come down to loose typing vs strong typing. My answer is why not both?
Especially, in our brave new world of managed code. I think this is a case where Microsoft got it right with the marketing of the CLR in their .net framework. It really isn't much different than the Java Virtual Machine. Ever since the beginning there have been compilers for languages other than Java that create bytecode for the VM.
Lets take it from another angle, the idea that a developer might have to know one more language isn't really a big deal. On a given day, the average (J2EE) web developer will use Java, JavaScript, SQL, XML, XSL, JSP, Expression Language, and (X)HTML, at a minimum. Most will use a few more. If another language can make life easier, then lets use it.
We have been able to compile Ruby to byte code for a long time. Your Java classes can see the classes and methods generated by the jRuby compiler, the reverse is also true. Our development environments are sophisticated enough to deal with multiple compilers and languages. With eclipse, it's just a matter of a few more plugins and a builder.
So, let's all get along and use the best tool for the job at hand. If Java and C++ can get along with clunky old JNI, then Java and Ruby should be able to work miracles together with the advanced tools of today.
