I have had two very different careers thus far in my life.
My first, artist management, had a strong need for soft skills — communication, problem-solving, stress management, conflict resolution, the list goes on. Software engineering is quite the opposite, with obvious importance placed on the hard skill of writing code.
A matter of mere months into my software engineering career, it became apparent that, while up until then my focus had been solely on writing code (and to some extent, with good reason), this was only one facet of being an effective software engineer. It takes a myriad of skills to be an additive team member on a business’ engineering team. To name just a few…
Communication
An inability to communicate about code is perilous. Other team members, both technical (other engineers) and non-technical (product managers, business development) will look to you to articulate, in plain english, the capabilities and limitations of your code, how your code fits into the larger ecosystem, what your code means for user experience, etc.
Reviewing Code
Knowing what your code does is easy. You did write it, after all. Reading someone else’s code is a whole other ballgame. It takes an understanding of best practices and higher-level concepts to be able to follow what is happening and catch potential bugs.
Decision Making
There is usually more than one way to complete a task at hand. Making decisions in software engineering requires time management, prioritization skills, a comprehension of the ecosystem at a high level, consideration of business goals and requirements, and more.
The Benefits of Reading
The list of resources that exist on any given engineering topic is never ending and spans a variety of media — online courses, YouTube videos, blogs, documentation, etc. And of course there is the knowledge gleaned from working on a team of engineers.
I have spent varying amounts of time with each of these, and have found that there is simply no substitute for good old fashioned books.
Being a Sponge
You learn more than you realize by simply absorbing and consuming content. I find this to be most profound in two ways:
- Completing The Circle — I cannot tell you how many times I will read something, and a week later hear it come up in conversation at work. Every time, I have this realization that had I not read what I did, I would have gotten much less out of the conversation than I was able to. And worse, I wouldn’t even have known what it was that I was missing out on. This happens constantly, even when reading something more abstract which I can’t quite directly connect to what I’m working on. Inevitably I have this moment of “Oh, that’s what they were talking about” or “Oh, that’s when you would use this”.
- Pushing Your Limits — In all honesty, I don’t always feel like I grasp what I read the first time around. It depends on the book, but if I’m diving into something new and complex, it can feel as if the chapters are going over my head. Unfailingly though, if I stick with it, I find that I push that feeling of “not knowing” out just a little bit further. Something that two weeks ago felt like total gibberish will suddenly click and that space of “not knowing” is filled with something new. In engineering you will never know everything, and if you aren’t learning something that feels confusing at first, then quite simply you aren’t challenging yourself. The intention should be to constantly be moving the goal post, and one fantastic way to do that is read, read, read. Whether or not it feels like it makes sense at first, keep reading.
Get Comfortable Talking About Code
Discussing code often comes less naturally than writing it. You may know in your head what you need to do, or why you did something — but are you able to articulate it to someone who can’t see the inner-workings of your mind? Reading books about code provides a framework for discussing your work. It allows you to see how others converse, and gain a familiarity with this type of conversation. This exposure leads to these conversations feeling more fluid and natural over time.
Concepts Over Syntax
Engineering books tend to focus more on the concepts rather than specific syntax, which is imperative to your growth. Languages, frameworks, and technologies change, and memorized syntax won’t be of much help when it eventually gets deprecated. Nor will it be useful when eventually your team decides to implement something new.
Besides, anyone can Google search the right syntax and find a good-enough answer on StackOverflow. What you can’t find with a simple search is how the fundamental principles of an architecture, framework, or other technology apply to your application in nuanced ways. This comes only from your own solid understanding of your technology on a conceptual level.
Understanding the “Why”
To the previous point of concepts vs. syntax, it is vital that you always understand the “why” behind the code you are writing (and the code you are reading, for that matter). This understanding is what will allow you to improve your program, anticipate potential issues, debug errors, and adapt to changing requirements. In understanding why something was done, or why something is a best practice, you can use your knowledge to build optimal solutions rather than “one-size-fits-all” patches.
Reading Code Samples and Analyses
As mentioned earlier, the ability to read the code of others and provide meaningful feedback is essential to being an additive member of an engineering team. This can be very daunting at first, and it might feel hard to even know where to begin.
Most engineering books, especially those that are language or framework specific, include code samples and accompanying analyses. These samples provide a remarkable opportunity to 1. gain practice reading others’ code in a safe space (i.e., there is no actual risk of you missing a bug that gets merged into production) and 2. learn how code is analyzed. You are able to get a sense of what kinds of things to look for, where to start, and helpful questions to be asking yourself and your team.
Learning the Language
Every technology has its own industry-standard language that is used to talk about it. You can pick this up from your conversations with co-workers, but reading provides the chance to familiarize yourself with this language in a safe space (i.e., without making a blunder in front of your entire team). Consistency in verbiage is crucial to strong communication, and learning this standard is the foundation.
I cannot stress enough how important I feel reading has been to my own growth as an engineer. Truly, I think it is less important what you are reading (in terms of topic, at least — just make sure it’s quality) and more important that you are reading something engineering related. It’s a great goal to always be reading at least one engineering book. Pick one up, and commit to reading a few pages every day. Even if you have to reread passages or entire pages, that’s fine. Just stick with it, and see how your thoughts, conversation, and approach changes.
I am including a list of books below that I have read and found to be invaluable. Any one of these would be a great place to start.
Recommended Reading List
Note: I highly recommend the entire “Clean” series by Uncle Bob, and have liked all O’Reilly books I have read. Even if you are well versed in an area, you will be surprised by what you learn by sitting down and reading the O’Reilly book on it.
Clean Architecture: A Craftsman’s Guide to Software Structure and Design by Robert Martin (aka Uncle Bob
The Pragmatic Programmer by David Hurst Thomas and Andrew Hunt
Learning React: Modern Patterns for Developing React Apps by Alex Banks, Eve Porcello
- Programming TypeScript: Making Your JavaScript Applications Scale by Boris Cherny
- Domain-Driven Design Distilled by Vaughn Vernon
Cracking the Tech Career by Gayle Laakmann McDowell
Practical Object Oriented Design in Ruby by Sandi Metz
AUTHOR:
Bryn Bennett – SheCanCode Blog Squad.
