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.
Latest comments (29)
Excellent points!! I am trying to learn to see the big picture
Being just an efficient coder means a machine, but with knowledge outside of it can make a coder really live.
Great Piece. I enjoyed reading it.
Nicely articulated👍
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.
Wow, how am I just now reading this!? Great article :)
Thanks :) and it’s only from last week!
Thanks for sharing !!!