Choosing a path in software development can be difficult. There are a wide variety of paths available, depending on your preference and education. My own path seems to be more common, from what I’ve seen scrolling through the internet lately. I was self-taught. No CS degree here. But what this meant was that I had to decided what subjects were important to focus on. I was interested in lots of different things, but I also needed to focus on things that would get me hired. This meant learning web development. These jobs were easier to come by and they were easier to get into.
What I was really interested in was what the big boys had going on. When I started learning, there were people in the industry who were pushing the envelope. These were the people I was interested in and the reason I wanted to get into technology. I liked building things, but I wanted to build big things. But you don’t build big things without a CS degree and at least some software experience. I was coming from the mortgage industry! I had serious Excel skills, sure, but that definitely wouldn’t cut it.
There were occasions - not very often, but important when they did arise - when we’d be starting something new. Maybe we needed a new service or a new group of services. Maybe it was decided that we needed to rebuild something or start something new from scratch. When my team members or managers discussed these things, I would either be left out or have nothing to contribute. This makes sense. I didn’t know the answers here! Learning web development the way I did doesn’t teach you what the right way to structure a project is. It doesn’t teach you how to properly organize services and architect a project.
And so we’ve reached the crux of the issue. It’s not only that I didn’t know the answers in these situations, it’s also the value that may have been transferred from that knowledge into the rest of my work. I’ve since learned more about software architecture and would be able to contribute in those sorts of discussions. I’ve also realized that having a good understanding of software design and architecture is useful in many situations outside of these “new project” discussions!
The Missing Piece
Simple software architecture patterns such as service decomposition and encapsulation can promote good patterns in many areas of development, not just when designing complex systems. For example, a new front end developer is given a new feature to implement. It involves calling an api, creating some web components, and introducing some new logic. If I was put in this situation near the start of my career, I wouldn’t have had any understanding of good design patterns. I would have very likely arranged this code either all in the same place or just wherever seemed right. Quite often, this will not result in code that’s easy to maintain, easy to refactor, and easy to contribute to. If instead I had a basic understanding of software design patterns, I may have attempted to separate my code into clearly encapsulated areas. I might have thought it out ahead of time and considered what areas of this feature might be more volatile - more likely to be changed in the future. While good Test-Driven Development practices might help you encapsulate your code, choosing what code to encapsulate and how you should do so can contribute even more to the quality of your project.
Service decomposition and encapsulation are only a small part of good software architecture. But I think they do the best job of pointing out the value that can be brought to a self-taught developer’s education, especially near the beginning to middle stages of their career. Spending some time looking into software architecture while also learning how to build that software would create a more well-rounded developer who could bring more value to their work and their team.
These days, I’m spending quite a bit of time thinking about software architecture. I’m analyzing different patterns and practices and deciding what seems to be good practice throughout the industry and I believe I’ll be sharing some of these discoveries here. I’d like to put together a series of posts which dive into software architecture for self-taught developers and how to present some of the more complex ideas from this subject in a way that’s easily digestible and related to the daily work of a software developer in the early stages of their career.