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.