How to move from junior to senior developer

What skills or behaviours differentiate a senior dev from a junior? It goes without saying that it's not like flicking a switch - it's a gradual change that takes time but I think that there are certain ways of thinking which can help push this forward.

Thinking about "future us"

A major shift is no longer just focusing on the job in hand and building what is immediately in front of us but thinking about ourselves and our team when we come back to this piece of work in weeks, months or years from now. Is it built to last? Will you or other developers understand it? Can you do anything now that will save further work in the future?

Planning for reuse

One way to help our future selves is to think about what we might need going forward. Can this functionality be built in such a way that it can be used again? Can it be a component or a generic function that can save us from writing something similar down the line?

Optimising for speed and scalability

If we're focused on the job in hand it can be very easy to build something that works well with some dummy data and think that's job done. Let's say, for example, we've got a table that displays data from an endpoint. You make some dummy data with 10 records, wire it up and it all looks great. Everyone's happy, on we go. But what happens when your 10 records becomes 10,000 records? Are you just having a huge table, which just keeps growing until your page can no longer function?

It's important to think about this from the outset. How big could this get? Will it reach a point where the user experience becomes worse? Will the page grind to a halt under the weight of rendering?

Consider things like filtering, paging and windowing as strategies for coping with more data.

Empty state and loading

Along similar lines, how does the UI look when there's no data? For example, when a user is new to the system and hasn't yet created their first record, do they get an empty screen or a table with header row only? Not a great look.

If there's potential for a small delay while loading then how does the user know that something is happening and it's not just broken? Is ther a clear difference between data that it is not yet loaded and there being no data?

Think about what you can show the user at the various stages to reassure them. If there is no data you can show a line of text to explain this and offer an action to add a record. If things are still loading you can add "loading..." text or an animated spinner.

Error handling

Sticking with the user experience, if things go wrong do we handle it gracefully so the user knows what's going on?

We should see areas where things can fail, for example, any network request, and work out what to do so that our UI doesn't just look broken. If possible offer the user a suggestion of what they can try.

Ensuring ALL user input is validated

If you have any user input, like a form, you can't ever assume that a user will behave normally. From the developer's point of view, users are a nightmare. You might have a simple text input labelled "First name". What if they enter numbers or symbols? What if they decide to paste in 10,000 characters? What if they enter code to try to hack your app?

Use input types and the pattern attribute to limit the input. Remember that it's not rocket science to bypass front end validation so make sure that your backend also validates what gets passed in.

How will it be tested?

Returning to the central idea of thinking about our future selves and our team, have we considered how we can be confident what we've built works and is robust? If we're lucky enough to have people to test our work how can we make their job easier? Are there clear indicators that something has succeeded or failed?

If we have automated testing in place how can we make this easier? Is there anything we can do to make page elements easier to locate? Can we add anything into the code to help make it clear what is happening when we can't see the screen?

Prioritising accessibility

Web accessibility is not an optional extra. It's an essential part of web development. This is an area that can really expose the difference between a junior and senior. We must ensure that everything we build is accessible.

If you're not too sure about what is required there are tools that can help, like Lighthouse or WAVE. These won't solve all your problems but will help catch some of the most basic issues and will hopefully help educate you on how things should work.

A good manual test that anyone can do it to try using your UI without a mouse, trackpad or pointing device - go keyboard only. Can you still navigate, tabbing between interactive elements?

Responsive design and translations

Does your UI work at different screen sizes? A lot of developers think about things working on laptop and mobile.

One area that is often overlooked is the massive screen. Sometimes elements that are full screen width can look ridiculous on a massive screen. Imagine a full width table with just 2 columns, the first being left aligned, the second right aligned. Those elements can be a very far apart, too far to make an obvious connection. There should be a maximum width.

The other aspect which many developers don't consider is translation of text. You might think you don't offer translation or that nobody outside of your territory uses your site but you'd be surprised. Users can get their browser to translate pages - as a developer it's not in your control. So, if you have content that is a neat fit, for example a label on a card, then it might no longer fit when translated into a language that uses more characters. You need to ensure that all content can flow and handle being expanded.

Managing technical debt

You should have a mindset of leaving things in a better state than you found them, taking the opportunity to make improvements and update things as you go. If you spot things that are a potential problem but too big to fix now then don't ignore them. Log it in a backlog so that it can be planned.

Writing technical documentation

The final point, which again is about being kind to ourselves and others, is to write documentation. Write it for yourself - you won't remember as much as you think you will - and write it for your team and any future team members who join. Things change, people come and go, people go on leave, get sick, etc. Don't let knowledge stay in one person's head and become a single point of failure.

Also, if you've written a document on something then you can quickly refer people to it rather than needing a call to explain things when you're struggling to remember it yourself.

Summary

The transition from junior to senior is mostly about thinking ahead, thinking about how you can help yourself, your collesgues and your users, thinking about what could go wrong and how you mitigate it and, finally, sharing your knowledge with others.

If you practise these things and talk about these things you'll soon be viewed as a senior.