I continue to be reminded of the importance of the Plan.
When working in a Project, developing a System, or part thereof, the first and best way to begin is planning. Or if you have jumped in half-way … same thing. The Plan man.
What does this mean? It boils down to, I think, a few important details.
Clarity of Thought
Whatever means you take (notepad, whiteboard, project management software, massive cranial capacity), it’s vital to gain some measure of clarity when working on a Project. No matter how small or large.
This means knowing where you are going. Not just the big picture, but smaller pictures, goals, deadlines etc. It also means you know where you have been. Review the past week. Know what you have gotten done, and what you have not. It’s important not to cheat yourself. It’s not going to help your own development as a developer (ha) if you aren’t honest. Know that you have missed a deadline, and rectify it.
So I guess that’s a second point.
Be Honest and Fix The Wrongs
If you believe you’re the best programmer in the world, then i guess there’s nothing left to learn. But I know guys who believe they are great programmers (and they are in truth) but who also know that they will continue to learn until they pass out of this mortal coil. This is good. Better than good. It’s neccessary. We have to be willing to accept that sometimes we will miss our goal because we have stuffed up, or because of events out of our control.
The next step is to fix it. Plan baby plan.
Review and … Plan
You can definately go overboard (never) with this. Balancing the planning and reviewing with the work itself is a skill. But if you’re still in the project, and you have a couple of hours without any pressure, or it’s the start/end of the week … review. Plan. See where you have gone, and where you want to be this time next week/month/year.
Old & New Functionality
This is where I was getting to with the other blather. I constantly find myself discovering old functionality that, basically, sucks. I created it with very little foresight. Almost no planning, just reacting to the client’s needs. There’s a billion words just in that topic … but anyway. What do you do? It’s the hard way. Either rip it out and create anew, or clean it up. Both a viable depending on the situation. One good aspect of cleaning it up, is that you get to make old code new … better and more sparkly :). But however it’s done … Plan. Sometimes you can just do it, code it straight up, because you have clarity of thought. "The problem is that the totalling is wrong" … "I went in and found a minus instead of a plus" …
So what about brand new functionality. Again, the Plan man. Throwing in functionality is the bane of my life, because i’ve done it so much. And I continue to … but am hopefully getting better at planning a little beforehand. What will this affect (if you have an entity/module/thread diagram, you can hopefully find these things out a lot quicker), and what effects will be had? What’s the best way to get this functionality done … sometimes the fastest is best, sometimes the other.
I’ve babbled on … being the second article, I probably haven’t progressed with much of the above mentioned clarity … but it’s another step towards TOTAL WORLD DOMINATION … i mean … towards a great little library.