Programming: Things They Don’t Teach You At University — Part Three of Five

Planning

Part three of this series is all about planning. Planning might not be the most exciting topic but it affects everything you do, whether you are working on a solo project or a large team. Here are some tips taken from my first eighteen months of experience.

Plan before you code

When I first started programming I hardly planned things at all. I would just jump right into coding. I would start by reading all the relevant code in the system, trying to fit it all into my head and then changing it so that it did what I needed it to do. This was exhausting, and didn’t actually save time. After eighteen months, my advice is never jump right into coding unless it’s a simple bug fix that you already know the answer to.

Instead, spend time thinking about the problem. Use abstraction, start at the highest level of abstraction (lowest level of detail) and think about the problem without looking at any code.

Think about the problem domain, or the users point of view, then gradually increase the level of detail. Start thinking about the front end and the back end (where applicable) communicating with each other. Then go down a level and think about packages or classes sending messages to each other. Take your mind up and down through the different levels of detail, try and simplify the problem, don’t just try and hold really complicated structures in your head.

You can try getting away from your desk for this part, it can help you concentrate. Also keep a log and write down your thoughts and pseudo-code, it really takes the pressure off your short-term memory, and will reduce the chance of headaches (seriously).

Planning short, medium and long term goals

Similar to the point about abstraction, really an extension of it, is the point that planning happens at different levels. You should have different team objectives for different time frames. Start with a long time frame of a year, or a quarter, set your objectives here first. Then move to smaller chunks and create smaller objectives that will fulfil the long term ones. Doing this speeds up scheduling sessions as it’s quite quick to come up with monthly achievements when you know that they must fulfil the quarterly ones.

Planning your day

Write down three to five achievements that you can cross off during the day. This helps to stay focused and allows you to measure your performance.

Software methodology

Talk about software methodology with your team. We did this on our team, and eventually introduced our own lightweight methodology that is influenced by the Unified Process. We have five development phases that we use on every task/feature that we embark on. Following these phases forces us not to jump into code too early, and plan properly, as the first two phases don’t involve any coding. This has improved our code quality and productivity a lot.

Priorities

Another way to simplify your planning is to make priority lists. We started creating a list of top fifteen priorities for each of our projects. When deciding what has a high or lower priority a good tip is to rate things on impact/benefit versus effort. It’s also good to put a rough time estimate on each of the priorities, it doesn’t have to be perfect (these estimates never are) but it will help to plan the coming weeks and months.

Time estimates

Many people have said that it’s virtually impossible to estimate the time things will take in programming. As a new programmer this is almost certain. A good code base will make estimating things easier but as a new programmer this is out of your control. You may not even know if the code base IS good or bad until you gain more experience.

If you find you are always under-estimating the time needed for tasks, you can try adding some extra “padding” to your estimates, until you reach a point where you are over-estimating as often as you are under-estimating (some times you might even get it right!). It’s more useful to make accurate predictions than to please people by giving them optimistic estimates that turn out to be wrong.

If you found this interesting then check out the previous two parts on Teamwork (link) and Flexibility (link).

Note: part four is now live and can be found here!.

-Mike Gregory