Let's explore 3 ways you can approach writing code that will increase your skill as a developer and move you closer towards senior level.

As a junior developer much of your work centers around thinking of ways to make a function work or a unit test to pass. You start off by working on a small part of the codebase. This is important but at some point you'll need to make the mental shift away from just making things work.

Unfortunately, most developers stay stuck in the middle of the career ladder because they fail to develop big picture thinking.

Go from writing code to architecting solutions and patterns.

There's nothing wrong with focusing on the details of a function or feature. Things have to work obviously. The hidden cost of solely "making things work" are:

code that cannot be re-used

lack of cohesive patterns

overly-complex logic

refactors that cost time and money when new business requirements pop up

Developers who make things work will almost always have a job. Those who create the solutions that can be leveraged will be the ones that get promoted.

So what is "big picture thinking"? It's more than a buzzword. Here are 3 mental shifts you need to make in order to increase your influence and technical depth.

Step 1: Leverage design patterns

Most of the problems for architecting applications have been solved. You just don't know about them.

There are micro and macro design patterns. Micro patterns can be leveraged for smaller pieces of your app like using inversion of control or a particular pattern from SOLID (look it up) to make your functions work better and be more extensible.

Macro patterns usually dictate the overall application architecture. For example in a React app, it's common practice to separate the presentational logic from business logic using the presenter/container pattern or custom hooks.

Look up the common patterns for the framework you are using and decide which makes the most sense for you and your team. If they aren't using any obvious patterns, this is a great opportunity to suggest one.

Step 2: Make work easier for your team through standardization

If there is no single way to do something then everyone will create their own method of handling common scenarios.

This is bad and confusing.

One developer uses the presenter/container pattern, another leverages custom hooks. One (over)uses lodash and the rest of you never touch it. Carl comments all his functions. Lizzy does not.

A new developer is hired and confused how they're supposed to create a feature with so many options. Maybe they add their own flavor in the mix.

Once your team agrees and standardizes on a pattern it can free up the team to tackle the "real" problems and makes it much simpler to onboard new people. Once a decision has been made, it needs to be enforced via tools like linters and code reviews.

Standardization can be applied to other areas of the dev lifecycle as well: code reviews, branching strategies and deployments.

Step 3: Care about performance

Code goes from your computer into Github, gets reviewed, passes QA and is deployed!

Done right?

No. No, no, no!

Customers care about performance and you should too. If there are no tools to monitor performance then consider this an opportunity to explore some options: Datadog, New Relic, Rollbar, etc. A simple Lighthouse can surface glaring issues.

Get familiar with the tools your team is using and check them out before you start your day. Look for anomalies after deployments and how your features scale in production. Catching issues before customers (or your CTO) does will catapult you up the ranks of the dev team.

Conclusion

The theme throughout these 3 mental shifts is expanding your focus beyond your own code and to begin thinking of ways make your team work better and with more ease. Use patterns for writing code, architecting apps and monitor what happens after deployment.

Ask yourself these 3 questions on a weekly basis and you'll discover more areas to make a positive impact:

What is 1 thing we should be doing that we are not?
What is one metric the business cares about right now that we can work on?
What is 1 thing we should we stop doing?

Hope that's helpful!

If you are NOT solely interviewing with companies who have a fetish for white-board interviews check out all the free resources I have here: https://brianjenney.me and then get my freakin' course (that's not really a course) https://notanothercourse.carrd.co/

3 Ways to Develop this Senior Software Developer Trait: Big Picture Thinking

Let's explore 3 ways you can approach writing code that will increase your skill as a deve

What will you write today?