I’ve been a professional software developer for over a decade, and have been writing code since I was a kid. Over the years I have read a lot of advice from software developers with far more experience than me, to expand my thinking and perhaps avoid some mistakes that they once made. Some of my colleagues at various companies have been invaluable sources of insight, as well. I’ve had enough experience at this point to learn more than a few lessons of my own, some the hard way. I want to give back, and share what I’ve learned with others.
There are basic common sense things about how to write good code that seem obvious once you know them, but are not so obvious to people who have not yet learned those lessons. Some excellent advice is repeated so often that it seems like a cliché to even mention (encapsulation is good!).
I increasingly appreciate the importance and benefits of my received wisdom very gradually. The more code I write and fix, year after year, the more these basic principles of software craftsmanship resonate with me (no seriously, encapsulation really is quite good!)
Many thoughts about what it means to write good code flutter around inside my head. In order to structure these thoughts into something coherent and meaningful I’ve started a living document on GitHub, titled “Sustainable Coding“.
Note: I strongly hesitated to use “sustainable” in the title because it is a popular buzzword. I generally consider the presence of buzzwords to be a warning that something lame is afoot. But, as I explain in the introductory section, it truly is the best word I can find that fits my needs.
If you’re interested in reading my take on what it means to strive for excellence as a software developer, here’s the link:
https://github.com/ijoshsmith/sustainable-coding
This document is a work-in-progress. There’s a lot more that I want to write about, but I’m not in a rush. The document will grow at its own pace.
Pingback: Dew Drop – February 8, 2016 (#2183) | Morning Dew
I like ‘future you’.
I’ve come across ‘past you’ and found him over using a qualifying name as part of related classes. For example, ‘ActionBase’, ‘ActionDoc’, ‘ActionSet’, to the point where they actually become difficult to read in the solution explorer. Present me, feels that namespacing can partly answer this problem, such as ‘Actions.Base’, ‘Actions.Doc’, ‘Actions.Set’. Do you have a better solution?
That seems like an appropriate usage of namespaces to me.
Pingback: 15-02-2016 - wut more links? - Magnus Udbjørg