Now that I have more time on my hands and no longer have to follow my former employer’s social media policy (which, admittedly, had improved over the years from the original Omertà-like policy), I can write more freely about the things I have learned over the years. Funnily enough, that’s when I saw this post implying the pointlessness of the exercise. Sure, he’s not saying that I shouldn’t speak – the implication is more that nobody should listen…
Well, I suppose that this is mostly aimed at “how to advance your career” advice, not “how to become a better software engineer or architect” advice. Yeah, I’m not going to write about that. Also, with time, the purely technical details will lose relevance – for example, there is very little topical relevance to the code of the automated hematology classification code I worked on during my internship at Technicon Instruments in the late 1980s (rewriting PL/M into C just isn’t a hot problem these days). However, even going that far back, there are constant threads related to people that recur today.
We may think that software engineering is just a technology problem, but it is first and foremost a people problem. Some of the things I saw in Tarrytown nearly 40 years ago still happen across the software industry today. Tools and processes are better, people are better educated, have access to a wealth of information we didn’t have at the time, but we’re still working with the same hardwired constraints of the human mind.
Finally, the fact that we – on the whole – know more about writing software doesn’t mean that we apply that knowledge uniformly. E.g., for all dependency layering within non-trivial programs is a problem we’ve tackled for decades, spawning generations of tools to help us (or, to “solve” the problem, if you listen to their marketing), it still is something that even experienced developers get wrong on a fairly frequent basis.