At what point does someone become a senior developer? Is it after five years of working experience in a tech startup? Is it when you are fully proficient in your programming language of choice? Is it when you've memorized every passage from the Agile Manifesto?
There's no developer bible that explains what it means to be a junior, mid-level, or senior developer, which means that no one really knows what each "level" means. Instead, we define where we are by looking at those who we believe are significantly better or worse developers. But that's not the right way of looking at seniority.
What Really Matters As a Senior Developer
The one factor that tech companies increasingly search for in their developers is their business vision. That's right. How well a developer can envision a business's future matters heavily.
Yikes, you might think, and you wouldn't be the only one. For decades, developers were seen as secluded people, who had little contact with other bipeds, who only had to be good at writing code and little else.
A completely inaccurate depiction, of course, but one that snuck into the minds of many developers nonetheless. Still, let's throw away that prejudice and, for the sake of this article, open our minds and hearts to the idea that developers need to be savvy business people too.
What About Technical Ability?
I don't believe that a developer's seniority should be linked strictly to their technical abilities. While certainly important, it increasingly doesn't determine whether you're a junior, mid-level, or senior developer.
Instead, companies are now looking for developers who are good team members, competent communicators, and potential managers. These are all soft skills that are not so easily learned, contrary to the hard skills that constitute technical abilities. Instead, someone's competency in particular soft skills arises out of their personality traits and cultural alignment with the company they're working for.
How Can You Think in Business?
A developer should always aim to deliver measurable results. But this means more than quickly completing a project with the latest technologies, design patterns, design systems, etc.
These aspects are important, but they only represent a percentage of what it means to deliver measurable results. You also need to think about the business in more general terms. What that means is best explained with an example.
The Checkout
Imagine you've been working on a project for an online checkout. You're tasked to create a payments page that can process a reasonable number of payments and serves as a thorough update of the old payments page.
Your first line of thought might be XSS, CSRF, credential management, Sanitize, and other technical security aspects that guarantee no one can buy a car for $1.99 at your newly programmed checkout. Important points, but they're not crucial at this stage. Instead, you need to ask yourself the following:
- Why do we need this new checkout?
- What didn't work about the old checkout?
- What hypothesis are we trying to validate with the new checkout?
These questions and their answers are important because they help you build a solution to the problem instead of molding the problem to the solution. Here's what I mean with that:
As developers, we all carry a set of technologies that we've learned over time. Because we know these technologies inside out, it's incredibly easy to apply our technologies as solutions to problems that aren't really a good fit. We become preachers of the particular technologies we've learned, which I believe is wrong.
Instead, you should ask which technology is best for the problem you're trying to solve. This quite possibly means it's not one of the technologies you know, but learning new technologies and languages shouldn't be terribly difficult once you've crossed the initial learning curve.
Additionally, it means the company you work for won't be stuck in a tech stack that's outdated, simply because their developers tend to stick with what they know instead of figuring out what the best technology is for any particular problem.
Planning the Next Steps
Once you've adopted this mindset, the next steps become more intuitive. Once you know what's expected of the checkout project, you'll want to develop POCs, case studies, MVPs, and other preparations to ensure that your solution is the best one.
Developing the Solution
Then, you need to consider what results you'll deliver in what timespan and for what budget. When you define things this way, ideas like automated testing, metrics, and tracking will start to make more sense from a technical perspective.
For example, as you're developing our checkout, you'll need to have fields, validations, and masks. For many developers, this Holy Trinity will immediately bring up two technologies: Formik and Yup. React developers use both technologies to solve form problems such as field validation, the control of values, and others.
If you thought about Formik and Yup as a solution, think about how this duet can help deliver value. Answering this question can lead to ideas like this: What if you use a session to store the Formik values for when the user tries to make a payment and receives an error that the form is already pre-filled and validated?
Had you ever thought about using Formik this way? Because it's possible. Formik has enableReinitialize, isInitialValid, initialTouched, and validateOnMount, all of which can be used to create this feature and reduce friction from user errors and payment issues.
There are many more examples you could think of. My point is that thinking this way will help deliver measurable results that are good for your client or the company you work for.
As developers, we are the tip of the spear, and the way we think when we write code can accelerate a company's success or grind it to a halt. Those who put the business first are the ones who end up being senior developers.
