Spot on. This is perfect advice for those looking to grow into Senior and Lead roles.
When working on a team, architecture is critical to various aspects of our daily routine. I've worked on teams that had to navigate through poorly developed projects and have found that we tend to complain to each other about how frustrating it is to accomplish simple tasks. Our morale had diminished over time and everything took 2x to 10x the amount of time to develop compared to projects where I had complete control over the architecture. Even though we were paid well and didn't have to spend any overtime at work, we were burnt out from the frustration of debugging overly engineered code with twice as many layers of abstraction than should be required for a web application. Not only did we have to work with such horrible code, but our managers had no development experience and would refuse to approve time for the team to overhaul projects that were started by toxic ex-employees who had no clue what they were doing when building the initial architecture. Without proper architecture, one year worth of estimated development time can turn into three years full of unneeded stress with sprints that are made up of 75% bug fixes.
My optimum architecture includes ASP.NET Core Web APIs that are called from a single-page web app which uses a micro JS library to handle AJAX calls, a Business Logic Layer (BLL) in C# called from the Web API, and Dapper at the Data Access Layer (DAL) that communicates with SQL and is executed exclusively from the BLL.
Help me,how can i learn in-depth architecture, so my coding and mindset work like it should in development
Some theory books:
Architecture is at many levels, from classes to components to systems, so there is no single silver bullet. And not always can you put best practices in play due to various constraints, you just keep working on it like a muscle and it gets better
There are some interesting books on architecture patterns. But I think paying attention to the big picture of the projects you work on goes a long way!
Great article, I enjoyed reading it!
I feel like balancing upfront planning vs the cost of refactoring later because of overlooked needs is one of the harder things about software. Identifying those things that would be hard to bolt on later seems like an important consideration.
It definitely is, but it's a skill that constantly gets exercised as a developer. You get better at it with time, learn how to gain time by overscoping other areas and learn where you can cut time and budget from others.
IMO, the majority of software is learning to engineer people less than engineering code
This is why all developers should be able to see the big picture and I try and get my staff involved in design discussions etc as soon as possible. It doesn't matter what the code looks like if it doesn't meet the wider goal.
And 💯 on the importance of talking to others, devs, designers and users.
Switching your mindset from "I need to work on this thing NOW" to the bigger picture has been life-changing for me. I feel happier as a developer and that I can bring more to the table.
Are there books or resources you have found helpful in learning more about architecture?
I learned from live projects so didn’t do much reading, but I know there are some very popular books of architecture patterns!
Excellent article, and one I can totally relate to, after 3 years away in executive management, I found I preferred being close to the code :-)
Interestingly enough, while I love to code, I am increasingly finding that I am more impactful to guide the implementations across development, deployment, maintenance, reviewing of libraries and frameworks, what approaches to take as projects evolve plus what to prioritize to meet today's needs with an eye on what will be needed and done tomorrow
Hi, thanks for introducing this important topic.
I always miss real-world examples in architectural discussions such as this.
Do you have any resource you can point to that can show, for example, bad architectures, why they're bad and how they could've been better implemented?
I’m not sure of anything quite like that. My experience with bad architecture is based on real companies and codebases! Lessons learned in live time.
Architecture is key, the main disagreements I have with other devs are when they do not seem to understand the overarching architectural or business plan.
Which unfortunately have been rather often in my career.
On the flip side my persuasion skills have grown quite well due to the challenge. :)
Hello! What books would you recommend for reading on Architecture?
I mostly learned by doing with help from others. But this one is pretty well known: oreilly.com/library/view/software-...
Great! This will be a big help. Thank you so much!
Many things you said really match with many problems I face now. Amazing article. I already shared on my LinkedIn.
Glad it resonated with you!
Thanks for sharing !!!
Wow, how am I just now reading this!? Great article :)
Thanks :) and it’s only from last week!
How does one take all of these points and effectively raise concerns to the team of complexities of a story or a new feature? I'm often pushed back with "Oh this is easy to solve. It's just like X".
I tend to ask questions about edge cases. How do we handle this? Have we accounted for this? if you're correct, their "just" solution won't handle those complexities.
Good point, thank you!
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.