Reading is Required for Software Engineers
When I got my first job in software engineering, my team was anything but agile. I was shown my desk, allocated a computer, and given a book to read, Working Effectively with Legacy Code. I devoured it, as well as a few others that happened to be at my desk as well. Everyone I worked with had read these as well. I only took a few computer science courses before I began my career, so, I really hadn’t noticed the existence of books about software as a concept, just how to program in particular languages. This abstract kind of text really spoke to my history in philosophy, I took other recommendations and loans and read quite a few such books. I noticed a shift, people were talking more about articles, and less about books, then it seems no one talked about reading much anymore. This might be more a function of my surroundings changing, rather than the community at large, but I think it’s worth taking a step back.
good code transcends language
The best books understand that most of what makes for good coding is not specific to any language. Each language has conventions and idioms that are preferred by the community that surrounds the language, but it is still bound by best practices. Some of these practices will be implemented in vastly different ways, depending on the peculiarities of each language. This means you will need to put some effort into what the lessons mean for you coding, but it will save you the effort of reading a stack of books for each language you need to use.
there’s nothing new under the sun
While you might argue that computers are new and AI is newer, books on software in the abstract hold up surprisingly well. Anything that gives you nuts and bolts how-to advice, probably won’t hold up, but Enterprise Integration Patterns gives you a set of solutions to common problems to keep in your toolbox, regardless of what implementations come around to help you complete the real work. Of course, the pattern landscape is evolving, but generally the ideas are not being made obsolete, just variants and new ideas being added.
design is everywhere
Software and system design is a favorite topic of mine. Patterns are the different ways to build, which can be components of a design, or even the theme of a design, but the design is where you take the goals of the software, the stresses on the system, the organization of the company and lay out how it will come together. A really good design seems obvious after the fact, you can see people interacting with it efficiently and effectively. The book that really hit home for me on this topic is The Design of Everyday Things, be careful though, it will lead to endless frustration about poorly designed everyday things! For me, the central point of the book is, if it needs instructions, it probably needs to be designed better. A door that you walk into because you thought it was a push, should have been designed differently, putting the word “PUSH” on it is not the best fix, when you approach a good door, you just know what the right thing is. The same goes for APIs, if you are constantly having to refer to the documentation to map what you want to do to the name of the function, it could probably use some work.
thanks for reading
The more software engineers that read, the more shared language and knowledge we have, which makes communication a joy. So grab a book and get to it!