Analysis paralysis: you know too much to just write code

This is a translation of Scott Hanselman’s Analysis Paralysis: Over-thinking article and Knowing Too Much to Just CODE .

I read a post today on ArsTechnica “ I know too much to program quickly. What should I do? "- this is an overview of this issue on StackOverflow:

I began to notice that the more experienced I become, the more time it takes me to complete projects or tasks. I do not lose the qualifications of age, no. The problem is that I see too many ways to break something. And the number of potential errors and just the nuances of which I know is becoming more and more.
')
A simple example: I used to simply write data to a file. Now I am thinking about the permissions, file occupation by another application, multithreading, atomic operations, frameworks, different file systems, the number of files in a directory, predictable names of temporary files, the quality of my PRNG , power outage during any operation, adequate API for my code, normal documentation and so on.

It's just a bomb, right about me. I also recently thought, not from the age of whether such problems appear, but I'm just not so old. The problem creates a great experience, coupled with too deep thinking about the problem. I am more experienced than many, but obviously not so experienced as to not suffer from the paralysis of analysis .

I have a couple of my own projects, on which I work on vacation and in the evenings when everyone is sleeping. The first is the port of the popular iOS application under Windows Phone, the second is a startup with my friend Greg, we are writing an iOS application with a cloud service. Both projects started just fine, but then a huge number of problems collapsed, and the development stalled.

I start to implement features, and then I throw. It feels like I “swap to disk” - I spend more time shuffling ideas rather than realizing them. I'm still quite productive in general , but when I write code, I just start to slow down.

I think too much. “Write settings to file” turns into confusion from paranoia about multithreading or migration of settings from previous versions of the application (which does not exist yet, aha), and then the volume of the task becomes too large. I am not afraid of big projects; this is all my architectural paranoia. For all the years of programming, I learned about so many potential bugs and problems, because of which something might not work, which, after all, does not work all because of me.

YAGNI - "you do not need it"

The correct answer, they say, - You Ain't Gonna Need It - you won't need it. “The best is the enemy of the good.” It's easy to say, but hard to do. Mouviciel with StackOverflow writes:

Looks like you're not experienced enough.
Your next lesson: follow the requirements, nothing more

I understand this perfectly, but for help I often need another brain.

How to think less

I learned about Agile a few years ago. Most of all from this technique I like pair programming. With a good partner it turns out to do the work three times more, and not two.

So, I solved the problems with my startups by finding partners. I'm not the best programmer, but quite tolerable. And when I work with a partner, then both get better. With Greg, I'm working on iOS, with Jen on another project. They obviously write code better than me, although I am also useful. They brought a fresh look into the programmer’s life and the habit of saying YAGNI and just implementing features. The irony is that when my name is in a project, I contribute the same thing.

My wife is funny. The old joke about relationships: your partner tells you something year after year, and one day you rush home from work to share a new idea from a stranger ... the very idea that your partner has been talking to you all these years.

I work remotely, so all my pair programming goes through video chat and screen sharing. I use Skype, Lync, Join.me, whatever. My partner and I go through the features in turn in our organizer, broadcast the screen of one of us to the other, speak and write code, think through and develop the architecture, commit to Git, synchronize and switch places.

So we can hold out until three o'clock, then we get tired. However, the feeling of satisfaction from working together on a problem is wonderful.

And your programmer life is paralyzed over time? How do you handle such problems?