Slashdot Mirror
How To Get Out of Developer's Block?
Midnight Thunder writes "I have spent the past six months working on a software project, and while I can come up with ideas, I just can't seem to sit down in front of the computer to code. I sit there and I just can't concentrate. I don't know whether this is akin to writer's block, but it feels like it. Have any other Slashdotters run into this and if so how did you get out of it? It is bothering me since the project has ground to a halt and I really want to get started again. I am the sole developer on the project, if that makes a difference."
You are a far better person than I. Ever since I took my hobby of programmer to work, I haven't been able to do it as a hobby. I get home and the last thing I was to do is look at code. I blame Scrum Logs, and crappy deadlines. I blame Scrum because it's a daily reminder of how little you did the day before and how much more crap you have to do over the next 2 weeks. In one ear you have your manager asking you what you did and what you're doing every freaking day, and in the other you have yourself pointing out that you desperately need a vacation. If I had no time-lines and could go back to pre-Scrum days, I think I'd be in a far better mood. ;)
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
This isn't really a troll. It may well be an excellent idea to just say fuck it and start coding without caring whether you are doing it wrong or whatever. Just throw some code together that roughly does the first or next few things it needs to do, compile it (if necessary), and debug it just barely enough for it to produce more or less desirable results. Then forget about it until the next day.
Next day, either refactor what you did the day before, or just keep moving crazily forward. Eventually you will refactor it into something reasonable, and you will have achieved forward movement.
Don't worry, nobody's watching. Like the man said:
Plan to throw one away. You will anyway.
Get yourself an enormous piece of paper (butcher paper, or something from an art store), and make a big drawing, in pencil, of the entire project and how everything will fit together. Do it at an appropriate detail level to fill a good portion of the paper.
This has multiple benefits... it gets all your ideas written down, it gets the project organized (and helps identify potential problems before they're in code), it makes for nicely visible pieces of a larger puzzle, and, perhaps most importantly, it gets you away from the computer where you have coder's block.
The one best piece of code I've ever written, which had all sorts of interprocess communication and synchronization problems to overcome, etc., I started with a big drawing, which lent itself very nicely to a fully pseudocoded skeleton of the program (fully doxygened and line-by-line commented before any code went in), followed by the actual code, which practically wrote itself at that point. Not only did this keep the process going, but it also helped me eliminate and compensate for a whole bunch of technical and design issues, before I had even written the code that I would have had to fix. After addressing a few rogue syntax errors, the program ran correctly the first time.
Unfortunately, while effective, this process left me completely spent. Having written what was, by my standards, a perfect piece of code, I saw little further for me to accomplish in my career, and I was especially devastated when I saw that it was fairly likely that my contribution would not make it into the final product. A mere shell of a programmer remained, and I have steadily lost interest in programming since. I'm enrolling in graduate school for music in the fall.
-- I prefer the term "karma escort."
As a director of a software development organization, I won't be popular for saying this. But... it is your boss' fault. Not yours.
You simply aren't motivated. I want to slap the person somewhere in another post who said... "motivation comes from within". It *rarely* comes from within.
When one of my managers or peers comes to me and complains about "unfocused" or "unmotivated" employees, I tell them to get off their collective ass and motivate their team or their employee. Psychologically, as an employee, you should feel driven by your surroundings to achieve a goal. That feeling should be driven by your team, your boss, your organization.
Being "self-motivated" is the single, biggest path to burnout in existence. Don't even begin to blame yourself.
Here is what I would recommend. Go to your manager. Tell your manager that you simply aren't feeling very motivated about the work you are doing. Have an open and honest conversation about it. You might be surprised. Your boss might actually bring some out some of the motivational mojo that you need. If your boss doesn't come through for you, then think about going to another organization.
But don't quit programming. You probably love it and you probably are pretty decent at it. You just need to be motivated, that's all.
Sole developer is hard.
So don't be a sole developer. Stop worrying about code, and focus on packaging your idea to 'sell' to others. Find a partner, a team, an investor, or just a friend who will be pleased to see you succeed in making your vision a reality.
The first thing I do on most projects is find the one stakeholder who I would be most pleased to make happy. I then share all of my ideas, sketches, prototypes, etc. to this person. Usually they are just a non-techie user who gets anxious to see the final result... which in turn makes me excited to finish so I can finally show it to them.
I guess what I am saying, is make the project bigger than you... don't be a sole developer, be a hero, be a teammate, be a friend, make someone proud... then the project isn't a chore!
Sometimes the best solution is to stop wasting time looking for an easy solution.
I never really did Scrum, but on several XP teams we had daily standups in the morning. However, I *never* invited the manager. In fact, I explicitly told the manager he wasn't welcome. A standup is about communicating small important issues to the rest of the team so that they don't have to discover it themselves. For instance, "I've changed the interface to this class, so if you're going to use it, please come and talk to me." It should never, ever be about tracking progress!!!!!! In XP there is an iteration plan, in Scrum there's a backlog. Either way that document tracks progress. A manager should never, ever ask "How far are you in your task", or "Do you think you'll finish in time" or "What have you done". He can look at the plan to see what is crossed off the list (and if you're really on the ball you've got people independently verifying that the acceptance tests are acceptable). It's up to *you* to warn people if you think your task won't fit in the time remaining. Everything else can be determined by looking at the plan/backlog.
Agile should be *easy* on you from this perspective. It's one of the reasons it's called agile. If you're not finding it this way you're doing it wrong (IMHO -- of course flame wars have been started on less). Ideally you should never talk to your manager. All information up and down the chain should be transparent. This leaves your manager free to act solely as a shit shield. Unfortunately most managers are too micro-managing to do agile properly.