I want to start off this post with a story:
The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pounds of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot -albeit a perfect one – to get an “A”. Well, grading time came and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes – the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.
This story is from the book Art & Fear.
I’ll admit I haven’t actually read this book, but I came across this one day and it really struck me.
The better you get the worse you get
Software development is a difficult profession. It is fairly easy to learn how to program, but learning how to actually build a full software system can take years of study and practice.
One thing I have noticed though is that new software developers tend to be really productive.
I remember back in the day having my floppy disk with several different programs I was working on. It seemed that as I started to understand software development better, I actually started to become less productive.
Why would that be?
I have a few theories on this, but my main theory is that when we don’t really know what we are doing we just try to get the task done.
Remember when you were a kid? Mostly likely you did a lot of drawings. Probably your drawings weren’t really that good and if you judged them by your standards of art today, you might even call them terrible.
How come you don’t draw so much now? (Perhaps you do, but most of us don’t.) A better question though is “why did you draw so much then?”
There are of course many answers to this question, but I think most of us will find that one of the reasons why youngsters draw so much is because they are exploring and learning and not limited by constraints.
At some point as we get older, we have a notion of what good art is and what art should like. We might even learn how to properly draw. We end up having an expectation of what is a good drawing, which tends to create a bigger entry barrier for picking up that crayon.
So what happened?
I know I went through a phase myself in software development, where I wasn’t nearly as productive as I could have been.
I spent a good deal of time on “problem admiration,” and an even greater amount of time on “making the simple complex.”
As software developers we have a tendency to box ourselves in by constraints as we search for the perfect solution to a problem.
Now before I get too far here, I am in no way suggesting to write crap code and ship it. Don’t do that!
What I am suggesting is to try and find a solution that is 90% optimal and, knowing that you can revisit the problem again if you need to actually find a better solution, go with it, rather than spend time up front looking for that 95% optimal or higher solution.
I’ve written before that this is the hardest thing I struggle with and I think it is true for many software developers.
The problem is that when we start out as software developers we don’t know the “right way” to do things so we are less constrained in what we do. We just march forward and go do things.
As we start to learn the “right way” to do things, we are often stifled by that knowledge and the constraints it brings and that causes us to be less productive or to over engineer and design solutions to problems.
So am I suggesting amateurs are better than professionals?
Not by any means, but perhaps they are better in some regards. Perhaps they are better at producing more.
In my mind the key is to be able to take that constraint-less, fearless attitude of a new developer and temper it with the knowledge and wisdom of experience.
I have applied this myself and in the last few years and it has increased my productivity immensely.
Here are some practical ways that I was able to increase my productivity as a developer.
- Leap before you look. I stopped reading up on a subject or technology so much before jumping into it. I started by jumping into it and then refining my knowledge as opposed to trying to learn something and then do it.
- Stop worrying about how. Often when I consider some course of action or a project to work on, then first thing I will consider is how I will accomplish it. This is a killer for motivation and a waste of time. How is not important, what and when are far more important. How gets us caught up in the details. I started having faith in myself that I would figure out how as I needed to.
- Don’t be a afraid to do it dirty first. Many times I want to start of with a clean solution to a problem. This is often a waste of time, because you don’t know enough about a problem to design it properly until you start trying to solve the problem.
- Don’t be afraid to rewrite code. This goes hand and hand with my previous bullet, but I included it here, because it is important on its own. Rewriting something is not bad or as hard as it seems. If you aren’t afraid to completely rewrite some code you wrote, you are more likely to solve a problem with a less than optimal solution, which will advance you on your way, instead of getting stuck.
- Recognize that there is no perfect solution, there are only solutions that are optimized for one or more variables. Some solutions have fewer trade-offs than others, but all solutions have trade-offs, which cannot be avoided, no matter how hard you try.
- Don’t be afraid to fail, but fail because you ran as hard as you could, not because you gave up. It is much better to try 20 times at a big goal and have the 20th time be a success than it is to pick some small goal you know you can accomplish and get it the first time. You can only succeed as big as you are willing to fail. They key thing about failure is that when you get knocked down, you can always get back up.
The moral of this story…
So sometimes, being good is bad, because it hinders and paralyses us. I’ve found that many more things are accomplished by doers than by thinkers.
Don’t let your knowledge of the “craft” of software development be a hindrance to your productivity or you will be destined to watch those with less skill and knowledge than you constantly surpass you while you angrily and bitterly critique them from the sidelines.
Reference: When Being Good is Bad from our NCG partner John Sonmez at the Making the Complex Simple blog.
