You’re not any slower in completing projects. Previously, you thought your novice projects were done when they really were not. You should sell this quality to clients.
“This company might get it done faster and cheaper, but is it really done? Or will you be hunting bugs for years?”
Beyond that, you need to know and accept the old idiom: “Perfect is the enemy of good.”
Sounds like it’s time for you to join the dark side: management.
I’m not suggesting you give up programming and become a manager. But it seems like all the experience you’ve quoted up until now has been technical in nature. In simple operation of writing out a file, you can think of 10 different aspects that a less mature developer would never consider. Not necessarily a bad thing, but…
The dark side is all about present value. It’s about making minimal investment for maximum gain (cost-benefit analysis). In business everything boils down to how much will this cost me, probability of success, probability of failure, probability of spectacular failure and potential gain. Do the math; act accordingly.
This works just as well when you are a developer: create a temporary file, ignoring permissions and name collisions – 5 min. Net gain, the rest of the team can start working on whatever code depends on the presence of that file. Is it a perfect solution? Absolutely not. Will it get you 99%, 95%, maybe 90%? Yeah, it probably will.
Another question to ask: How do you feel about technical debt? Some people think it must be eliminated. I think those people are wrong. Just like in business, technical debt allows you to borrow “cash” or “time” in order to deliver something sooner. What’s better: A perfect solution in 2 years or a complete hack that a customer can use and purchase in 4 months? Every situation is different, but in some situations if you wait 2 years, your customer will already sign up with your competition.
The key is to manage technical debt the same way a well-run business manages financial debt. If you don’t take on enough, you are not getting optimum return on investment. If you take on too much, the interest will kill you.
So my advice: Start evaluating your work based upon whether you’re maximizing your value instead of maximizing your thoroughness. And if you practice this, you will develop the same intuition that you already developed in your technical area.
As a side note, I recently started doing the pomodoro technique and it has helped a lot. Instead of going on a tangent of a tangent, focus in small time intervals and then allocate pomodoros for future work/research. It’s amazing how many times I made a note to research a topic but an hour later when the time came, I thought to myself, “there’s at least 3 other things I could do with my time today which are all more valuable.”
I had the (likely) same problem many years ago, it lasted for a few years and I overcame it. So maybe it would be of some interest to you to know how I achieved that, even if I’m not sure my way will also apply to you.
You should also have a look here : The Seven Stages of Expertise in Software Engineering It shows that productivity is in great part a side effect of skill level. It may be that you are still at some point between stage 3 and stage 4 on the technology you’re currently using (skill proficiency depends on technology, you can be master of some technologies while still learning others).
Now I start with biographic testimony.
A bit of context. I’m 47. I started programming at 12 in the 80’s. While in high school I also worked as a part time professional game programmer. Basically it didn’t got me that much money, just enough to buy hardware, but I enjoyed it and learned much. At 18 I started a formal learning of Computer Science.
As a result when I turned 20, whenever starting any programming task I knew many ways to solve the given problems and was very conscious of the many parameters and pitfalls at hands, and drawbacks and limits of any method.
At some points (say about 26 years old) it became really difficult for me to write any program at all. There was so many possibilities opened that I was not able any more to choose between them. For a few years (make it 6) I even stopped programming and became a technical news-writer.
I never totally stopped trying to program nevertheless. And at some point it came back. The key for me was extreme Programming, more specifically the Simplicity principle: “Write The Simplest Thing That Could Possibly Work”.
Basically I forced myself not to care about code efficiency (that was my main roadblock, avoid inefficient designs), but just go the easiest way. I also forced me to care less about errors, and delay error handling to a later time, after writing tests raising the error (really that’s TDD).
That’s something I learned when I was writing. When I do not know what to write, or I knew what I was writing was bad. Just go on. Actually write the bad stuff. I will eventually correct it later. Or if it’s really that bad erase it and rewrite it, but it’s faster to write things two times that write anything perfect the first time.
Really it is very likely that a code you believe is good at first writing will need as much improvement as a really bad one.
If you follow the Simplicity path you also get an added bonus. You easily accept to remove/change initial design/coding. You get a more flexible mind.
I also got in the habit to put a temporary comment in code, explaining what I was not doing now and intended to do later when the code would be functional in the normal use case.
I also attended an XP Dojo an practiced code katas with other programmers to internalize the XP practices. It helped. It made the above formal methods instinctive. Pair programming also helped. Working with young programmers gives some momentum, but with experience you also see what they do not. For instance in my case I often see them engage in overly complicated designs and I know the design nightmare that may lead to. Gone that way. Did that. Had problems.
The paramount point for me is keeping the flow. Being fast is really succeeding in keeping the flow.
Now I’m back as a professional programmer and I believe I’m both better and faster with a deeper understanding of what I’m doing. Practicing TDD I may still be slightly slower than when I was a young bull (and tested nothing), but I also have no fear refactoring and certainly spend much less time debugging (nearly no time at all, make it less than 10% of time).
Summarily: I overcame my codeblock using agile methods (XP), going for simplicity then refactoring, and practicing to make that instinctive. It worked for me. Not sure it can be generalized to anyone else.
In terms of skill acquisition level, I mostly learned to accept that every time I change technology (learn new language, new framework, etc.) I will go through a stage when I’m slowing down. This is normal and will eventually overcome that. I also can compensate for that with good methodology and general purpose programming skills and It won’t be as much a problem.