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?

  • If your position is Developer, why are you expected to plan? Maybe estimate, but not plan
    – superM
    Sep 28, 2012 at 13:54
  • yes it is possible. In this case though your productivity will strongly depend on how good is your manager / team lead
    – gnat
    Sep 28, 2012 at 14:57
  • 1
    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. Sep 28, 2012 at 15:35
  • 1
    How's that one quote go? "Days of coding can save hours of planning" or something to that effect. Oct 1, 2012 at 14:27

7 Answers 7


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.

  • 4
    "Detailed long-term project plans are notorious for usually being wildly inaccurate." DING DING DING +1
    – Ryan Kinal
    Sep 28, 2012 at 18:47

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.

  • 1
    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, 2012 at 14:05
  • I try not to let that frustrate me personally. I try to pin that sort of stuff on the project managers ;). Sep 28, 2012 at 14:50
  • To add to Blaise's comment. Bad managers insist on meeting the schedule and blame the team for missing "commitments". In that environment, schedules are certainly frustrating. Good managers realize that the initial schedule is a baseline guess and not a commitment. They know that some tasks will take longer and some shorter. What they are most interested in is long term trending. e.g. We are currently running 20% behind on the baseline schedule over 3 months. That likely means we'll run 20% over on the remaining similar tasks. They then use this new schedule for managing the project.
    – Dunk
    Apr 30, 2015 at 20:17

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.

  • 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. Sep 28, 2012 at 23:36
  • 1
    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. Sep 29, 2012 at 0:55
  • Gotcha! Thanks for clarifying, that definitely makes sense. Oct 1, 2012 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. Oct 7, 2012 at 17:59

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.

  • "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. Sep 28, 2012 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, 2012 at 15:07

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

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.


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.


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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.