Making mistakes: Part 1

Publish your code.

This is by far my biggest mistake, and it took me roughly ten years to realize it. As it turns out, it’s responsible for a wide range of mistakes and problems further down the line. I wish our professors had told us to publish everything, but at the time programming was treated more like a craft than a science. Then of course, publishing your own code is terrifying as it is. Everyone can see it and judge you based on its quality. Your name will be all over it and the internet never forgets. That thought alone is a big obstacle and the less experience you have, the harder it is to overcome.

However, it’s not so much about how everyone else will perceive your work. It doesn’t matter if the first code you publish is made up of copy and paste, code smells and anti-patterns. It doesn’t even matter that maybe there’s already some code out there that does the same thing but better, faster and painted in all fancy colours. What really counts is the effect that publishing has on the way you perceive your own product and the way you treat it. You may be the best programmer in the world, creating magnificent software all day long. But the day you make it available to other people will be the day you think of a bunch of ways to improve it considerably.

That last bit is the important information you should take away from this. Publishing your code makes you think about how others might want to use it. The code that you are very happy with may look flawed and incomplete all of a sudden. Something that had worked for you for several years won’t be quite good enough any more. That’s because private code will never be held to the same standard as public code, no matter how hard you try. Don’t believe me? Just go ahead and compare your front lawn to your basement.

Finally, making that decision to publish my code had the same effect on me. I kept improving my code for a while before releasing it the first time. The first batch of mistakes surfaced during that pre-release period, and in one way or another they are all a by-product of coding in private. Therefore, this mistake is definitely my arch nemesis, and I’ll be in for a hell of a fight in the years to come. Some numbers should help in outlining the consequences that all this had for me personally.

I’ve had a very productive period of coding in private where the code just kept piling up more and more. Of course there is some copy pasta as in any old code base. Occasionally I have implemented something twice when I forgot about the first time I did it. Some features from the BCL are in there too, either because I didn’t know it’s already there or because I wanted to see how I could do it. There has been a lot of experimenting with never finished console applications and all this has resulted in 513.430 lines of code¹⁾, including 247.518 unit tests²⁾ in 11.878 test methods³⁾. All this is packed into 3.509 source files, weighing in at 33.911.811 Bytes on disk.

Sieving all this will require a considerable amount of time. I’ll have to write comments and documentation and skim the usable parts from the rubbish, the incomplete and the obsolete. There are some gems that will eventually make it into a repository on GitHub, but that will take time. I am almost certain that publishing the code while I wrote it would have reduced the required effort dramatically. The code would be in a much better condition, there would be fewer bugs and simpler and easier to use APIs. You could say that publishing the code from the start could have made all the difference in quality. It could have been a real product, but it ended up being hardly more than a proof of concept or a prototype: Useful but highly unstable if used outside it’s very small comfort zone.

Now go ahead and create that account on GitHub or GitLab or whatever makes your boat float. Move your creations into the public domain and let them evolve into product grade artefacts of fine craftsmanship. Let the world help you evolve yourself along the way.

_{1) from Visual Studio Code Metrics
2) unique test results
3) unique test methods}