What affects your motivation level to write good code?

Question

When you suddenly feel "eehhhhhh....not now...just to get it done somehow", what can be the reason?

Answer 1

fear of screwing up.

Answer 2

Time constraint, push it to refactoring time.

Answer 3

Sleep level

Answer 4

An uninteresting (to you) area of the application. Applies even more so when there is another area you are/were/will be working on that excites you.

Answer 5

Time constraints and experience with the language. However, I don't seem to get much done without time constraints!

Answer 6

I got the damn "stupid" problem that i can't say to myself "screw it, do it lousy". Eventually it appears that ripping out your vains pays out when it comes to repair bugs, do some improvments or reuse code. "Lousy" part of code sooner or later will take revenge on you,

Answer 7

About eight years ago, I had completely "bought into" the project I was working on. I was focused, psyched, felt like an important part of the team, and I enjoyed my work.

I arrived at work one day to find I'd been transferred to another project. I literally had less than a week's warning. Turns out one of the team members had not only blamed me for her own mistakes and stupid decisions, but she had also accused me of some rather unsavory behavior. Fortunately for me, cooler (and saner) heads prevailed, and neither the blame nor the accusations stuck. Even so, it was obvious that one of us had to go, and management felt that I was more easily replaced.

I was crushed, and I've had pretty much zero motivation ever since. I feel like one of those people who go through a nasty divorce, and never marry again. I'd like to commit to a new project, but there's a nagging doubt that I can't shake, that doing so would only be inviting another disaster.

I can still force myself to program, but my motivation is gone. What used to be fun is now a chore, and it's been long enough that I seriously doubt that it will ever be fun again.

Answer 8

When you've inherited a piece of code to which you are unsure of the nuances, entry points and/or "quirks" of said code AND there are no unit tests.

Answer 9

Tight deadlines and a tired brain is a deadly combination for me. That being said, it happens very rarely these days. When I get that feeling, I know it's time to get home instead of doing an half-assed job.

I find that doing maintenance and even customer support work from time to time keeps me honest about my craft. Somehow, facing a irate customer who just lost critical data because of one of your bugs makes one think twice about cutting corners the next time. Code ownership is another big incentive ("there won't be any ugly hacks in MY modules") and so are code reviews.

Answer 10

Good code? Nothing is sexier than a finely chiseled api. I am significantly motivated when I have a fairly detailed requirements document. If it's not available I 'go alpha' and make one, meet with people, converse, persue, whiteboard and hunt down details like the dogs they are. Then its time to execute, break out the monster and start nailing things down. Coffee helps alot. Lots of coffee. Also, sometimes... Late at night... I whiteboard by myself, with the lights on so I can watch!

Answer 11

I'm a biologist/statistician that writes code regularly for research purposes, but I am not a full-time programmer. When I'm writing something that I know is going to be around a while, I take pride in the quality of my code. However, when prototyping something that may or may not be a good idea (the whole point is that I only know in hindsight after I try it on some data), I tend to want to just get it up and running ASAP even if that means cut-and-paste, violate every rule of good style, and have no idea how it works two weeks later. However, in my case this isn't necessarily a bad thing. In my field, the ability to get a prototype up and running pronto is a pretty valuable skill, because it gives me quick feedback on ideas I have in my problem domain.

Answer 12

Getting new tasks every day but not enought time to finish existing ones.

Answer 13

The simplest answer is "pride". Knowing that something was done the right way and truly reflects my skills is something that I take pride in. It is knowing that in a code review I don't have to feel embarrassed or make excuses for why something is done the way that it is.

I think on a bit deeper level, it isn't as much the code the inspires me to stay focused, but more the fact that I know that I am in control of it - kind of driving the code forward instead of letting the code drive me. Sounds strange, but I don't know another way to describe it.

Answer 14

Legacy code and the broken windows theory. I want to make things right, but the legacy code is just sooo bad written that I just want to leave as soon as possible.

Then I go like this:

If I put an extra variable over.... mhhh heeeere.... -> test -> view result, done!! Let's get out of this project!!!

Contributing to the code's bad reputation. Hence broken window theory.

Answer 15

Repetative work kills motivation

For example, writing lots of accessors in java. After having used ruby and lisp, this sort of work seems unnecessary; I know netbeans/eclipse support generating lots of this for you, but not always.

Being able to solve the problem domain, instead of arguing with the tools I use

For example, be it language, build/deploy-system or whatever. If the compile/deploy/test-cycle takes more than a few seconds it gets tedious to improve/refactor the code. Not to mention it kills the general motivation.

Your day is filled with interruptions

Trying to get something done, but people keep interrupting for whatever reason.

Lots of other reasons as well. There are books on the subject as to how to keep programmers productive; programming is creative work, so when a programmer is not happy, the code and product often suffers. No matter how much management (or the programmer himself) denies it.

Answer 16

Attention Deficit Disorder

Answer 17

I feel like I am most motivated when its two things a) a hard problem, b) I see the value in solving the problem or task. I can get increasingly demotivated when I think the task is lacking value.