As a web developer, should you switch to a more niche field?
In my day job in technical recruitment I talk to dozens of tech firms and hundreds of software engineers every week. Some developers think the web domain is crowded with too many developers and that salaries will go down because of it. I was asked by a reader if it makes sense to pivot to other, specialized domains with a growing market. Here are some ideas:
Systems Engineering
Sometimes software engineers perform operations on top of their development tasks, some end up enjoying it and switching to systems engineering entirely. They’re then mostly freed from other tasks such as the expectation to “fix something on the frontend”. Their focus becomes doing things on the command line or with special DevOps tools such as Ansible, Docker, or Terraform.
On every team of ten or so developers, there is maybe one DevOps/system engineer. The person’s job is to keep the infrastructure running for the developers, test engineers, and users.
It is hard to assess systems engineers because of the multitude of tools and skills that are used. Interviews consist of questions about which technology would be used in which scenario and if there is a match between tech used at the employer and by the candidate.
Also, be aware that this job can include on-calls. If it is at night or at weekends this can be both a bug and a feature because you’re paid more after working hours and on Sundays, at least in Europe.
The way to succeed in DevOps is to be an asset for both developers and the business. E.g., realize what things could be used “as a service” as opposed to building stuff in-house. What is better for your firm: Serverless or Kubernetes? Algolia or your own ElasticSearch cluster?
Firms that require a systems engineer aren’t small and usually shouldn’t lowball you in compensation. Systems engineers get respect from developers for being able to keep apps running and scaling them up as needed. That is not the case with other specializations.
ERP/proprietary technologies
Generalist software engineers often look down on technologies such as SAP and people who develop in it. Being forced to work in closed-source software carries some stigma to it.
Developers who are forced to use the technology of one specific firm need to attend training that costs thousands of dollars just to learn the details of the language because there is often no other option. (Luckily, this is most often paid by employers.)
Albeit it is true that most proprietary technology stacks are quite limited in what they can do (some aren’t even Turing complete), they are among the most used programming languages in the world, because so much important software relies on them. Many banking solutions are technologies that are 40+ years old.
If you don’t like the fast-paced nature of the web, proprietary technologies might be an excellent alternative; very few things change there. Since many COBOL developers retire while the need to maintain legacy software stays, it might make sense for some people to pivot to it.
Many developers in ERP are career changers, they come from — for instance — chemistry or physics, STEM fields with few job openings. This is a sign of a solid job market and good job security. Firms using this software often don’t have the hire-and-fire mentality or money issues of smaller firms. The field has many veterans who hold tacit knowledge in their heads. Once you gain it, you can become an “irreplaceable employee”.
For example, if you are already familiar with JavaScript it is easy to pivot to Oracle NetSuite. I hear it can be very financially rewarding.
Test engineering
Software engineering isn’t like other forms of (real world) engineering. It has unpredictable elements and requirements change all the time.
Some software engineers look down on testers because they think they aren’t “producing anything”. Albeit there are manual testers that do rather repetitive tasks, test engineers write software to uncover broken elements and come up with creative ways to show the weaknesses of systems. These engineers don’t produce a product for end-users, but they produce useful information.
As a software engineer, you often can follow some kind of blueprint: Start with the UX/design, then build a frontend, set up a backend, database, use this or that library. As a test engineer, you need a different skillset. Here, mostly heuristics work, there is no clear path to follow. This is like coming up with mathematical proofs; you need a leap of creativity to get it done.
As companies increasingly learn the value of reliable software and happy users, they invest more money in testing and the salaries grow with it. Small companies don’t hire test engineers, unless they have a sense of quality and how heavily their product affects users (e.g could it kill someone/loose money); so mainly middle-sized or big firms hire test engineers more likely.
Cybersecurity
While the mindset in software engineering is about building things, security is about how things can be destroyed, how bad events can be mitigated or how to deal with breaches after they occur.
Cybersecurity is not a standardized field, it ranges from checking boxes in excel sheets to pen testing/hacking as a ‘red team’ to building systems that can survive such red-team attacks.
Advanced practitioners think beyond this. They assume it is a question of when, not if, you will be hacked, and so you should work your way backward from there on how to survive such an event. That is easier said than done because humans think in probabilities. They often only consider harm that is likely. However, the thing to focus on is impact. You should ask yourself “what can wipe me out?” and try to prepare for that instead of only predictable problems with low impact. You can use threat modeling to find out likely points of compromise, and prioritize which ones need to be fixed.
Juniors tend to get tricked into cybersecurity jobs at auditing firms, hoping it will be cool but ending up in boring endeavors like having to survey employees about their password strengths and checkboxes in an Excel file.
Small- or middle-sized firms don’t (yet) care about security. Only bigger companies hire such professionals, and you need to find a firm where they take security seriously and where they don’t just make a pseudo-effort to make the auditors happy. There are often more jobs in consulting companies that specialize in security, but the downside here is that you are often traveling or switching between relatively short-term work.
Security is a relatively small world, so word-of-mouth often travels fast and far, and you often find new opportunities using organic network connections. Remember this during your job hunt.
Unless you work in a security company, selling the value of it isn’t an easy task. You have no shiny app to show or revenue to point to in your salary or promotion negotiation, you have to rely on your management to understand that your work saves your firm from ruin. It is hard to sell something that didn’t happen. Nevertheless, if you are good at breaking things and thinking about defense-in-depth, then you should consider pivoting into security, which can pay well.
Mobile development
Other fields have it easier in this regard and the value is much easier to sell. The world went mobile and is still going. Mobile engineering has its own languages, frameworks, principles, and challenges.
I once had to do some work in Xcode and Objective C, and it didn’t seem to be the nicest development environment. Back in the day of the first iPhone it didn’t matter because apps were so in demand that developers didn’t care how unpleasant it was; cost didn’t matter. Now, the development environment became better with Swift and Android and there are more developers out there.
Native mobile development gets some competition from the ever-improving cross-platform solutions. React Native and Flutter are on the rise. They seem to be contenders worth looking at. We are hearing that these solutions will enable “write once, run everywhere” already since the first Ionic version, a JavaScript-based framework that allows the cross-platform development of apps. Yet, complex apps likely will always be built in native technologies because only Google and Apple can give all needed access to the underlying hardware.
We can be happy that Microsoft stopped their mobile efforts, otherwise, we would have three platforms to develop for and not “just” two. With the world going increasingly mobile, the need for such developers will go up with it. If you worked in Java you can easily switch to Android. If you worked with React you can easily switch to React native. The “switching costs” here are low and the “niche aspect” high enough to justify a bigger compensation. Many firms, small and large, require mobile skills.
Embedded development
Embedded development is a niche where you have to work most often with C/C++, a language that developers tend to either love or hate. It is an ancient one with pointers and memory problems that can make your life very hard, if you don’t know what you’re doing. Students rarely learn to program in it properly in university. Hence, C/C++ developers are rare nowadays.
Embedded jobs are more available in places where you have lots of mechanical engineering, like in Germany. The car industry has a rising demand for embedded technology because of automated vehicles. The same is true for drones in defense and other sectors. Another need is in high-frequency trading but these kinds of firms you find focused in New York City or London and not so much elsewhere. The most recent, big, and rising sector for embedded engineering is the 5G technology. Many of the tools, infrastructure, and network technology around it is written in C/C++ for performance reasons.
Exotic programming languages
Generally, the best engineers don’t care about programming languages all that much and just use whatever is already used by a team. Yet I often hear strong preferences by developers.
Some want to use Rust, others Golang or even Haskell. If you’re into side-effect free code, I see why you’d rather code in Ocaml or Haskell and not JavaScript.
If you invest enough of your time to learn an exotic stack well enough, there is a chance that a firm that actually wants “3-years experience in XYZ” might interview you, but only if you can showcase that you invested 3–4 months of work into doing work in the needed stack. Sometimes salaries might be lower because many want to work with cool, new technology, or salaries might be higher because of the industry. For instance, in finance many use Haskell.
Machine Learning, big data, data science, AI, and other career scams
Machine Learning, big data, data science, and AI are fields that sound sexy but the reality can be very different.
Only big tech firms have enough data to let a handful of PhDs work with it. There are no jobs for backend developers who used NLTK for one weekend. Try putting a job advert online for “Machine Learning” and you’ll be flooded with CVs. Each of my clients who had to fill such a role experienced this. People want to pivot to machine learning and even are okay to take a big pay cut. That is not the case with the other fields mentioned in this article.
Also, the basis for most “data jobs” is shaky. More data doesn’t mean you can generate more insights. Quite the opposite can be the case. More data, algorithms, and software can make you more confused and gets you “fooled by randomness”. I see for instance publishing houses putting out machine learning positions to help journalists generate “insights”. At some point, they will find out that this is pure “fugazi”. Some firms just take old “data analytics” positions and rename them to “machine learning”. Still, the only thing hires will do is calculate means/medians and standard deviations, in Excel VB scripts, if they are unlucky.
Of course, self-driving cars and similar fields need “real” machine learning engineers. But how many jobs are there? Very few. This field is for people who meet three criteria: They can code really well, they have an academic track record, and they live in a region where companies do real machine learning. That is mostly the Bay Area tech giants and their satellite offices. Of course, there is a startup here and there that also does serious stuff, but the market is small. Maybe I am wrong speaking that negatively about machine learning, but at the moment that is my impression of the market.
Summary
Every person “gets sick” of something they do long enough. You have to analyze why you want to switch fields. Is it temporary unhappiness or is something constantly bothering you about what you are doing? If the annoyance stays for many months, it likely is something that won’t change, and you should consider changing careers. Maybe to those mentioned here.
No one can really advise you on the details of a career change. You can reach out to people working in the desired field and ask them about their experiences. Be aware that some people working in any field will find what they do boring. Many people are working for the money and get limited satisfaction out of their jobs. One can say: Almost any job sucks in its own unique way at least sometimes. So, don’t feel bad about feeling bad.
Once you change a domain you rarely want to get back or change fields again albeit I have seen people going from Python to DevOps to frontend and have no problems with convincing employers that they know what they want. Yet these were shifts within web development.
Every career change has switching costs that grow as you age. When you are young, you have more energy and time to focus on studying another field in your free time. In your CV, you need to highlight not only what you did in your job but also in your free time, write down how many weeks, months or years you invested in learning a new skill or how long you exactly worked on a personal project. Writing this properly into a CV is a challenge for most developers and I dedicated a whole chapter to it in “Coderfit: All you need to know for your programming career”. I’d be super happy if you grab a copy and send me any questions you might have.
The career changes suggested in this article can be drastic and all the markets of the niche jobs we discussed here are smaller than the current web development market, but they are growing. I am excited to see what the future brings.
If you liked reading this post, follow me on Twitter for similar content.
I thank Firas Cheaib, Trishannk Karthik Kuppusamy, Ilari Henrik Aegerter, Szilveszter Farkas, Nadia Yudina, Mike Miller for contributing with their expertise and corrections.
Originally published at https://coderfit.com on September 12, 2020.
