For all intents and purposes, the craft of creating software is really new. It’s only been around for about 60 years or so. Compare this to something like architecture, which has been around since the early 1st century AD.
The reason that this is important is because we, as a nation of software makers, haven’t really had a lot of time to figure all of this shit out. Further, even though things are changing all the time, the actual craft of creating software is basically the same as it was in the beginning.
If you haven’t been programming for at least 20 years or more, then it might be tough for you to understand how little the actual nuts and bolts of programming have evolved in the last 60 years. Every program can still be boiled down to the basics of structured programming that Dijsktra was preaching since the early 1970’s: Sequence, Selection, and Iteration.
So even though what we do is basically the same as what we’ve done since the beginning, our knowledge about how we should go about doing it has changed considerably.
Yes, we still rely heavily on Sequence, Selection, and Iteration but now we know more about where we should put those Sequences, Selections, and Iterations.
In a traditional computer science curriculum, the focus isn’t on programming. The focus is on mathematical analysis of algorithms and data structures. You’re taught as much (or as little) programming as necessary to get your coursework done. In the end though, universities don’t produce Codesmiths. Universities produce Chump Coders or one of its many variants.
This is because the advanced skills of creating software comes from wrestling with real code while solving real world problems. You have to have been in the trenches trying to answer complex questions that don’t have answers already. It’s these shared experiences from the battlefield that move the industry forward.
Once you’ve had enough of paying the price for bad code (either your own or someone else’s), that’s when you start down the path of the Initiate.
The key to growing in this occupation is to realize that neither the languages that you love or the frameworks that you’re familiar with are the keys to your success. Because the field is so new and because the core fundamentals of programming today are almost exactly what they were from the beginning (Sequence, Selection, and Iteration), your ability to advance is not hinged on language particulars or framework features.
The key is to rapidly apply the things we have learned from our collective battles in the trenches where the software is built. You must accept and apply the disciplines that have emerged and have been passed down from the Gurus of our craft.
Basically, you need to challenge yourself to differentiate between what you can do and what you should do. Once a thing has been placed in the bucket of things that you shouldn’t do, then you must be disciplined enough to not do that thing. And vice versa, of course.
One of the most important things that you can learn from me or from anyone else regarding professional software creation, is that you must build your systems for easy maintainability.
We’ve learned that software has to constantly and speedily evolve with the ever changing needs of its users. Rarely does version-one of a software system meet all of the needs. Therefore, you must focus on building into your system the ability to quickly and continuously change it without a total system meltdown or months and months of delays and budget woes due to complications with the code.
This blog is dedicated to me doing my part to help share the various things we’ve learned that help us build maintainable systems.
Keeping our software easy to change and easy to manage is how we do it. This is the path of the Codesmith. It is the first canon and is the one that binds all of the advice that you will find on this blog. You must fight with all that’s within you to keep your software soft.
Any action that makes your software hard to change later is an action that you should be disciplined enough to avoid.