How did I get involved in software architecture & design? Do I think of myself as a software architect? Here are some insights about my career, which have helped me and ultimately led me to YouTube and produce videos about software architecture and design. Here’s a bit about my journey writing in software.
Check out my YouTube channel, where I post all kinds of content accompanying my posts, including this video showing everything in this post.
I’ve always been involved in IT infrastructure and operations. Before working professionally as a software developer, I was interested in how software runs. Setting up my own servers at home and running Linux was a hobby. When I started working professionally as a software developer in the late ’90s, I was responsible for writing e-commerce software and the web servers they ran on, mail servers, DNS, etc.
That foundational knowledge of operations carried throughout my career, where I was more and more involved as the industry evolved from physical servers to on-perm VMs and then to the cloud.
You could say that before the “devops” movement, that was already what I was doing was heavily involved in both writing software systems and managing the infrastructure that ran them. DNS, database replication, web servers, load balancing, the list goes on.
This has been invaluable, especially when working in small teams and startups.
I’ve always written software for line-of-business types of large systems: E-Commerce, Distribution, Manufacturing, Accounting, and Transportation.
While they are all very different, they’re all lines of business with some overlap. I’ve always said the best developers I know working in these systems have good developer skills but even better business knowledge.
Understanding how businesses work and how money flows. How do they make money? What are the core parts of each domain where they generate revenue? How do they incur costs? There are business processes that are the main workflows of any business.
It sounds simple, but it’s understanding the business.
If you’re working in these types of systems, understanding the fundamentals of your domain will serve you well.
That segways well into a big ah-ha! in my career: finding Domain Driven Design. Because I lived in various domains, this book was a game-changer in multiple ways. The first was it was a gateway. DDD led me to CQRS. CQRS led time to Event Sourcing. Event Sourcing segwayed me into Event-Driven Architecture.
DDD also validated some thoughts I had and forced me to think deeply about design. A lot of people, still today, are hung up on the “tactical patterns” of Domain-driven Design. Aggregates, Entities, Value Objects, Repositories, etc. While they have value, they are a means to an end. The real value in DDD for me was thinking about boundaries on many different levels.
A lot of how I think now is rooted in coupling and cohesion. If you boil things down, they generally return to those two and the trade-offs you make for them.
Working with large systems means thinking about cohesion and defining boundaries. Coupling is inevitable, but how you manage it is vital.
Software Architecture and Design
Being involved in greenfield projects working in small companies and startups has forced me to think about software architecture and design. How to decompose large systems. However, I’ve also been thrown into the fire several times to work on a large existing (brownfield) project without any support. Zero. A large system that is running a company, and you’re the one that’s got to deal with it. Fix bugs, add features, and deal with the infrastructure of how it’s running. There is no developer documentation. Nobody to ask. Nothing. It sounds stressful, and it was. But coming out of those situations gave me experience in navigating large codebases and seeing a lot of issues with these types of systems.
When you’re working on a greenfield project, especially for a startup, you don’t have time for bikeshedding. Make the best decision you can, given the information you have, and move forward. Too often, developers can get caught up in over-analyzing and bikeshedding over irrelevant things.
Software architecture, to me, is about making decisions that give you options in the future but with little cost. I talk about this in my post: What is Software Architecture?
Systems need to evolve. Technology changes, businesses change, industry changes, your system needs to change.
Do I think of myself a software architect? No, not really. It’s always been apart of my role. Thinking about decomposing systems, how a system should function, how the business works, and how to model that is always been apart of my role. I understand there are folks with the title of “Software Architect,” and I think that’s a role that can exist in certain situations, but I do think everyone can have a role in architecture and design on a team. Even if that’s understanding the reasons why certain decisions were made.
So, how did I end up creating videos on YouTube about software architecture and design? The primary reason, and why I still do it today, is that I think there is a lack of good content on the topic.
There’s too much emphasis on “how” and not enough on “why”.
I create videos that I would want to watch. They aren’t for everyone, and that’s fine. They aren’t for people that want the “show me the codez!” videos.
I absolutely show code in some videos, and it’s for illustration purposes to explain a concept. Not surprisingly, although I show code in C#, there’s a large number of viewers who do not use C# at all.
I said there’s a lack of good because there’s also a lot of content that is, to me, misleading, bad, clickbait, and incorrect. Does that mean that everything I post is correct? No. Because of that I only post videos/blogs that I’m confident in based on my experience. My lane is software architecture and design. I post content around it based on all my 20+ years of experience.
Hopefully, what I post will resonate, and like the YouTube comment above, hopefully, you’ll get an “aha” moment, just like I have from other folks I mentioned above.
Good luck on your journey!
Developer-level members of my Patreon or YouTube channel get access to a private Discord server to chat with other developers about Software Architecture and Design and access to source code for any working demo application I post on my blog or YouTube. Check out my Patreon or YouTube Membership for more info.
- What is Software Architecture?
- STOP doing dogmatic Domain Driven Design
- How the Swedish Transport Agency learned distributed systems in six months