I've spent the past couple of years spending more time doing in-depth architecture and technical writing than typing in an IDE. Earlier this summer I returned to full-time development for a new project. To my surprise, even while rusty with the syntax, I'm a far strong coder now than I was. I wanted to use this opportunity to point out some of the things that have changed in my thought process and approach.
Big picture
The first thing I noticed was a change in my perspective. My focus is no longer on the ticket in front of me to the exclusion of everything else. I know what my task is, I'm paying attention to how it's part of a larger system and why Iām building it. I am cognizant of the fact that changes I make impact other tickets and systems.
Early on in my career I wanted to make sure my code worked. That it was efficient. Now I'm focused on making sure that working code is the right code for the project as a whole. And that we're clear on the larger goal it's working towards.
Consideration for usability first
Part of those larger goals is recognizing that successful completion of a task is bigger than writing an efficient forloop. And that we shouldn't count on being able to refactor later, that we should spend the time to do things right upfront. That means responsive design, accessibility, and internationalization are baked in from the start.
It also extends to considering the API experience, prioritizing consistency for users and future developers. Considering readability and organization of the codebase. Selecting the least opinionated choices so that you're not locked in should you need to change behavior or undergo an extensive refactor.
All of these "heads up" considerations have made me a much stronger coder. It's yet another reminder that our skills extend well beyond syntax.
Prioritization
Doing things right the first time is a weighted statement. If we assign that mentality to everything we'll never ship. Most projects fall behind schedule and a large part of that is because prioritization gets muddled.
Considering the big picture and being aware of the most important functionality means I know when I come across a potential tradeoff. This feature is going to take longer and likely result in some complex code. Do we really need exactly what we described? Or is the project better off with a slightly different feature or implementation?
In previous stages of my career I likely wouldn't have thought to question the ticket in front of me. But now I recognize that that often isn't what's best for the team or the project. That doesn't mean you constantly try to de-scope your work. Only when it has more benefits than drawbacks.
Awareness of integration concerns
Even if the code I write is perfect and meets every requirement I know that the place it's most likely to fall down is integration. When building large systems there are multiple points of exchange between other applications, databases, etc.
Having architected systems I now make a point to know each integration point within the code I'm writing. Making sure I understand the complexities, challenges, and potential edge cases. It's part picking your head up and looking around, and part making sure the left hand is talking to the right!
How is this getting deployed? Is this data format going to being compatible across systems? Am I passing all the information necessary?
Security Focus
Another point that I'm more focused on than before is security needs. Often there is an overarching plan but the specifics aren't attached to every ticket. When I write code I need to be aware of what pieces of the security plan apply to my features.
That applies to my code and the integration points I mentioned earlier. Too often the biggest vulnerabilities are found when data moves between systems. Making sure I am considering these complexities and asking the right questions can make a big difference down the line.
Communication
This is the biggest change. Early on in my dev career I assumed that the best way to prove my abilities was to get my task and complete it. Yet over time I've learned that the biggest source of failure is often due to people and teams. A lack of communication and coordination can cause serious problems.
Now, I'm far more likely to speak up when I see something that clashes within the project. I'm more likely to ping a coworker to confirm a design consideration than wait and let it play itself out. I know now that these potential faults have an outsized impact on the final product.
Conclusion
You don't have to spend time architecting systems or planning large efforts in order to internalize these concepts. As you gain more experience, work on a larger variety of projects, you start to see the patterns of failure and success. You learn what to prioritize and what is likely a secondary concern. But this was my path, so I wanted to share it.
Top comments (29)
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.
Spot on. This is perfect advice for those looking to grow into Senior and Lead roles.
Help me,how can i learn in-depth architecture, so my coding and mindset work like it should in development
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!
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
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
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!
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.
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. :)
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.
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
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!