You’ve been working on this piece of code for some time now. A couple of days, maybe even weeks. It all works, although a bit hairy. Then you wake up one day, with an epiphany. This code can be reduced to about half it’s size! So you start refactoring the pages of code that now seem inefficient. Without any hesitation, you’re deleting days of blood, sweat and tears.
It has been somewhat of a mystery to me as to why we don’t care about the enormous amount of work we’ve put into this. Sure, the result will be a lot better. It will be more transparent, easier to maintain and in many cases even a bit faster. Also, in most cases, the old code is on some version control system, such as svn or git. But still, we don’t care about our past code? We even enjoy tearing out so much work?
This goes a bit further as well, for those who haven’t seen the myth of the genius programmer, Google talks about getting requests from developers, asking to clear their svn repositories. They have loads of space for us to use, it doesn’t cost us any money whatsoever, but still we want to clear our past code? We actually want to erase the code from the face of the planet, while it doesn’t even stand in our way.
I think this has to do with us, programmers, wanting to be excellent at our first try. So if that first try didn’t work out perfectly, we just erase it from history, right? It’s the Men in Black flasher Men in Black flash penat our finger tips!
When you think about it, this is exactly how it goes with many other professions. Painters for example, they tend to throw away entire paintings or paint over an existing one, to erase their ‘failed’ work from history.
In This Developer’s Life, episode 'Scars’, they talk about how nice it would be if your resume stated how many failed projects you’ve been working on. Now is refactoring code not the same as failing projects, but it’s a bit of the same nature. Have you ever seen a developer stating his failed projects on his resume?
I think that gaining skill is a process done through a lot of trial-and-error. You try something out, it doesn’t work out exactly the way you had in mind, so you try something else. It actually is this process of refactoring massive amounts of code that gets you to be a better programmer. Still we don’t want people to see what we have been screwing up in the past.
When not reflecting the improvement in the products we create, we let out an important bit of information for our future employer: the ability to see room for improvement. It’s one of the most useful and at the same time hardest skills a developer can have. Seeing a piece of code, or maybe a database diagram for that matter and noticing points of improvement upon the existing design. It’s this ability of looking at a project from a more distant viewpoint, what makes a developer unique.
If you really were to write this perfect piece of code the first go, you would be lucky. No improvements would be needed and it would work out the first time. But how many times does this actually happen in practice? Most of the time, you’ll create a prototype and improve it, until it gets the form your client is looking for. The better you can do this, the more of a useful asset you’ll be for any client or employer.
There’s a whole array of development methods created for this type of software engineering, which works exactly like this. Creating a prototype and improving upon that. It has struck me that the hardest part of developing software is not building the product right, but building the right product. It would be great if we could all leave our pride behind and start publishing our mistakes for other developers to see.