Take the 2-minute tour ×

Recently, I have been tasked with more high-level planning assignments due to the lead developer of my team leaving. I hate long-term planning. My brain just doesn't naturally seem wired for it, and I am not interested enough in it to spend the time to learn it (it is hard enough to keep up with the programming side of the picture).

Can one still be a good programmer without being a high-level planner, too?

As a senior programmer, is one expected to be good at planning out the entire product and picking a date of completion?

share|improve this question
Ranty or not, is your actual question Can I still be a good programmer without being a high level planer too? or one of the others? –  Oded Sep 28 '12 at 13:44
Edited for clarity ... my question is Can I still be a good programmer without being a high level planer too? –  MattW Sep 28 '12 at 13:47
I think it'd still be a better question if you took out all of the autobiographical stuff and just asked your question. –  Winston Ewert Sep 28 '12 at 13:52
I tried to make it less ranty, feel free to rollback if you don't like it. –  Ryathal Sep 28 '12 at 13:58
This is a really interesting question. I don't think you do need to do lots of technical specifications to be a good senior dev - in Agile development many of the features of a new system or project are emergent. See my answer for more info. –  Robin Winslow Sep 28 '12 at 15:35
show 4 more comments

7 Answers

up vote 14 down vote accepted

Detailed long-term project plans are notorious for usually being wildly inaccurate. The functionality of the system will inevitably change before launch, and people usually spend a long time working out the specifics that go into the specification only to have stake-holders give it a cursory glance at best.

You should read more on Agile planning, you might find it fits in more with your mindset. Many Agile methodologies try to find ways to move away from detailed, long-term planning.

Agile methodologies try to minimise detailed technical specifications and documentation in favour of self-documenting code and isolated, atomic user stories and ultimately working software. In an efficient Agile team, there will be a minimum amount of time spent on planning.

Read the Agile Manifesto and look into Scrum. Use Iterative Development and Dynamic systems development method to guide the project.

The main downside with Agile approaches is that you have to admit openly that you don't know the exact scope of your project, and getting management buy-in to this idea can be extremely difficult, and usually takes a while. See this question and answer and this post for some tips on that.

However it is certainly true that as you get to be a more senior programmer you will probably do less coding, but I think that in an Agile team instead of meaning that you write more technical specifications, it would mean you spend more time managing and tutoring the members of your team and making architectural decisions about code.

share|improve this answer
"Detailed long-term project plans are notorious for usually being wildly inaccurate." DING DING DING +1 –  Ryan Kinal Sep 28 '12 at 18:47
add comment

Yes it is possible. However, if you want to be a good software engineer or software architect that is where your high level planning comes into play. To me, the main difference between a programmer and an engineer has been the ability to see the big picture.

share|improve this answer
I don't mind planning out the work I am doing right now / in the next 2 weeks. Meaning, if what I am about to write involves multiple pieces, I don't mind planning that at a high level and then doing it (in fact - that is exactly what I would do). I don't succeed at trying to come up with a date months in the future - then trying to figure out why we are not going to hit it. That is where my personal frustration starts to peak. –  MattW Sep 28 '12 at 14:05
I try not to let that frustrate me personally. I try to pin that sort of stuff on the project managers ;). –  Blaise Swanwick Sep 28 '12 at 14:50
add comment

Is it possible to be a good programmer and not a high level planner?

For a while, yes. Is it possible to do this for long? No.

With many employers nowadays it is standard operating procedure to give cost of living industry-competitive raises. If you don't improve yourself, don't try to tackle bigger and harder problems, those industry-competitive raises will price you out of the market in five or ten years. Keep this up and your employer will eventually start to look for a reason to get rid of you, and your employability elsewhere will be drastically diminished as well.

share|improve this answer
I am confused. A COL raise should keep pace with the inflation rate, in theory. Are you suggesting that the real dollars paid to software developers is gradually decreasing over time? Or that COL raises are generally more than the actual increase in the cost of living? I'd say a bigger concern is that an inability to demonstrate growth is, itself, generally considered a negative. However, there are other ways to demonstrate growth, such as greater breadth or depth of technical skill. –  Ethel Evans Sep 28 '12 at 23:36
I should have said industry-competitive raises rather than cost of living raises. I edited my answer to say just that. Those industry-competitive raises are pretty sweet for young adults, typically much better than inflation. Cost of living raises are for old fogies. There's a problem when someone gets raises higher than inflation but that person's skills remain that of a fresh out. –  David Hammen Sep 29 '12 at 0:55
Gotcha! Thanks for clarifying, that definitely makes sense. –  Ethel Evans Oct 1 '12 at 20:28
I'd argue, sadly, that over time the programming skill is getting easier to learn, and so the existing, non-growth, skill of an engineer devalues beyond COL. –  NewAlexandria Oct 7 '12 at 17:59
add comment

Sure, you can be a good programmer, from a programmer's point of view. From management's point of view is a whole other question. In my experience, being involved in the planning process is the best way to 1) get more interesting programming assignments and 2) get to do them the way you want.

In other words, once it gets down to short term planning, a lot of options are off the table. If your preferred solution would take six weeks but they only budgeted two, you're stuck with what they decided. If you have concerns about something they already discussed in long term planning, they're not going to want to rehash it.

If you're happy with that state of affairs, more power to you. Most people grow less satisfied with that the more experience they get.

The dirty little secret is no one is very good at long term planning and estimation. Better planners are the ones who are aware of their limitations, so believe it or not, you are ahead of the curve. Get some training on accounting for uncertainty in estimation. Look at techniques like evidence based scheduling or scrum, which rely on historical data to show how accurate your estimates are. You will be happier in the long term if you have a larger say in your work.

share|improve this answer
"The dirty little secret is no one is very good at long term planning and estimation." Ain't that the truth! +1 just for that. Even with a good history, there are lots of numbers that need to be plucked from the clear blue sky because the next project is never an exact copy of any previous project. If it was, we'd be able to reuse all of the code as-is and be done with it ASAP. There's always something new, and past performance is not always a good indicator of how the effort needed for that new stuff. –  David Hammen Sep 28 '12 at 14:54
Ok - so maybe the frustration (and even ego) are more of what I need to manage. If I can not beat myself up too badly and just get better at it with time (instead of saying "I don't like doing this") - I will be better in the long run. I can be hard on myself when I am doing it poorly - but it seems (based on the answers here) I had better learn to do it well if I want to stay employed as a software engineer. I do appreciate everyone's thoughts. I really don't have anybody at my company to learn this from - so hearing this from everyone here is a huge help! –  MattW Sep 28 '12 at 15:07
add comment


Short Answer: Yes it is possible.

However, more you get experience with the type of projects that you are involved, the better planning ideas you will have. Ideally, as a programmer we have some approach how to solve the problem or we look for one. Thus, if we know the approach then we may start think about the planning :)

Another possible route is that a programmer who becomes a good planner is also eventually heads toward Project Management. Thus, if you have interest in management of projects you may put some extra effort toward that direction.

share|improve this answer
add comment

Yes and No are your answers.

On the one hand, you're being nudged towards project management. IMO, all good programmers have some degree of project management capability, but they are different skill sets. The ability to plan for the long term improves your ability to communicate with the actual project management. So "no" you can't be a good programmer without the ability to plan long term.

That having been said, project management is a different skill set that appeals to aspects that are related but different than programming. So here's where the "yes" comes into play. You don't have to be a project manager to be a great programmer.

For your specific situation, try to become more objective about what the company needs as well as what you enjoy doing. There a bit too much ego reflected in your question and that's biasing your ability to look at this situation. If you can find ways to contribute more to your employer while still doing the things you enjoy, then you should consider them and talk the matter over with your boss.

share|improve this answer
add comment

Planning and the Bungie-Boss

Dilbert has many strips about the bungie-boss. Our challenges and expectations about planning may be both the cause and effect of leadership curn. My experience at a Fortune 100 company was that in one year, everyone who started the year as a project lead exited. Perhaps this was due to the planning problem. Not sure if your former lead left for this reason, but when your role requires you make a plan with a commitment, if it does not come to pass, often, a deadline related exit is the result.

Organizational Context of Planning

If you are uncomfortable with planning, perhaps you are uncomfortable with being accountable for commitments made to marketing or other stakeholders before the problems to be solved are documented or understood. This is a good instinct.

Planning is an important tool. Don't neglect it. Don't misunderstand it.

Planning is integrally linked to commitments, accountability, and negotiating power. Agile planning has many merits. You should know its techniques, as well as the techniques of planned methodologies. Your organization may have its own approach and getting advice and working with someone who has survived leadership of many projects many be surprisingly helpful.

A Simple Planning Example - Must not be about software...

If a roofing company came to my house to bid on a replacement, if they bid too low, they may lose money on the job, but if they bid too high, they won't get the job at all. Either way, they are out of business. In your new role, if you bit too low, you will run the project until the accountability kicks in, then you will have problems. If you estimate a project with enough padding to insure success by the deadline, they many just pick someone else to lead. The kicker is that you are not like the roofer. He can see how big the roof is, and has historical data about how long that size roof takes.

Becoming a Better Planner

You may wish to consider some kind of training. In Agile methodologies, and most recent planned methodologies, estimation is a team wide activity. Consequently, you should consider getting training for your team as well.

From experience, I can tell you it can be frustrating to get estimates from team members who will put it off, give you estimates they make in two minutes based on the task name without reference to a requirement or feature description or the existing code, or who insist that several of the tasks you list can be done in some fraction of a day even though past projects have spent weeks on similar issues.

There are various project manager training courses and certifications, but I would watch for one that was independently accredited. It might be worth a second thought before choosing to certify with approaches based on planned methodologies if you expect to work with Agile teams (or the other way around).

SLIM is a method invented by Putnam after working at GE and other companies on DoD projects in the 1970's. SLIM is influential, and his company QSM offers a certification that seems to flow out of a tool that they make. Depending on whether your company has adopted their tool, it might have either no value or high value.

Steve McConnell (author of Code Complete) also wrote a book about software estimation, and his company Construx teaches two classes for PDU credits that are accredited through the Project Management Institute. I have his book, and if I wanted to learn about the topic via classroom training, I would probably pick Construx. They also do Scrum training and administer various scrum assessments accredited through Scrum.org.

Another source that could provide great academic training about software project estimation, would be Barry Boehm's group at USC, based on their extensive work on COCOMO and COSYSMO constructive cost modeling which has been used at NASA and other large contractors to estimate very large projects. I am not sure I am a true believer in COCOMO, but I like the empirical work they have done to correlate the effects of scale and cost drivers on schedule duration.

I also found a chapter from a textbook published by O'Reilly that briefly discusses major software estimation methods including Watts Humphreys PROBE and Kent Beck's planning game. PROBE includes a notion that engineers track metrics on their own productivity, then apply them to their assign part on new projects. Planning Game is very highly collaborative between developers and other stakeholders.

share|improve this answer
add comment

Your Answer


