There is the assumption in our industry that being a backend engineer is more prestigious than being a frontend engineer and in general the idea that frontend engineering is for “bad” software engineers. Not only is this wrong, it showcases how short sighted some engineers can be.
Both frontend and backend engineering has evolved a lot – Frontend engineering isn’t about centering a div nor is backend engineering about serializing HTML for a browser to render.
I actually think that frontend engineering is harder than backend engineering, the rationale being:
- You have a fragmented surface (Android, iOS, Chrome, Firefox etc.) – so essentially more surface to maintain/support. To give more color, one thing I remember from my time at Google was how some Samsung TV decided that the
eval method in JavaScript wasn’t good and removed it from their browser.
- Your app is most of the time a stateful one – except for very simple ones. Backend engineers tend to flee away and prefer stateless not because it is more efficient but because it is simpler to build/maintain.
- You have less insights and control over your system. If your server OOMed, you can retrieve a core dump and debug things but if your webapp runs out of memory you may not have a lot to work on.
- More unexpected things can happen. For example you may also have some browser extensions that interact poorly with your app – these aren’t necessarily bugs that impact only a few users, they have the potential to take down your whole service. You may have malware that steals user cookies and replay traffic.
As an engineer, you should work with the rest of your colleagues to make your company successful. Looking down on your coworkers is a recipe for disaster – this is especially detrimental as both frontend and backend engineers have to find the right balance between powerful apps and simpler systems (e.g. the two extremes are simple static apps with simple-ish backend services or powerful apps that are more complex to build/maintain).
LinkedIn post
If you work on infrastructure and do a good job, your launches are likely drama free – they do not result in outages, in customer escalations or in visible breakages. People who look only at product metrics (e.g. product revenue) basically do not see the impact (positive or negative) of your work.
This means that you could save the company millions of dollars (in infrastructure cost, in engineering time etc.) but no one would know. Worst, people would know only when your infrastructure is broken. I often joke with coworkers that if they do not hear about me, it’s probably a good thing since there are no ongoing privacy incidents.
With that being said, this is something you can help correct:
- Make sure you have metrics to demonstrate your progress and impact – tie them back to the business (e.g. what % of revenue does your new framework support, how much machine costs you saved etc.)
- Celebrate and talk about your accomplishments – send announcements, give tech talks at all hands about your work etc.
- Raise awareness about risks that you/your team cannot tackle yet (e.g. for prioritization reasons) – this will help people understand that if something breaks, it wasn’t your fault. It also reminds people that these risks exist and need resources (e.g. staffing). Once in a while they’ll also remember that even though all these risks were present, none of them actually happened because of your team.
Last but not least, infrastructure (in broad terms, including privacy/security) is critical for the long term success of every company – one reason Google is immensely successful is because they have one of the best infrastructure in the world. So don’t shy away from rolling out quality infrastructure improvements!
LinkedIn post
Every now and then, you may not be able to agree with another party – about prioritization, what technical solution to adopt or something else. In this case, the last step is to escalate to your leadership.
Escalations often have negative connotations and may sound intimidating (especially if you just started your career) but they don’t have to. Here are few things to be know/be aware of:
What other advice do you have to better prepare for escalations?
LinkedIn post
While job offers often mention a required number of years of experience, this is more a guidance than anything else. For example if you move from Google to Meta, Meta will match your level regardless of how many years of experience you have.
In general, you need some time to get promoted to the next level – e.g. the median L3 engineer needs 2 years to get to L4. But time is not enough, that’s why you have L5 with both 3 and 20 years of experience. You do need time to grow though because you need some experience that can’t be learned in books – e.g. you don’t know how to manage a large team until you have actually done it. How much time you need depends on your skills (and luck).
One important takeaway is also that cruising (and getting time seniority) doesn’t get you promoted nor does it get you a raise – you may have gotten one in the past as the job market was getting more competitive but you can’t assume you’ll get an annual raise if you’re cruising. With time, you have more knowledge and become more efficient but in the software industry, this is not enough to get promoted beyond L4/L5 – being an efficient L4 doesn’t make you L5.
Last but not least, getting promoted at your current company is the easiest way to get a senior position somewhere else since companies care about impact, scope and leadership rather than years of experience. This also why writing your actual impact on your resume rather than your number of years of experience is better.
Keep a growth mindset if growing is something you desire. Do not settle for mediocre systems/processes, learn from others and keep reflecting every now and then on yourself.
LinkedIn post
