I tell anyone asking me for career advice the same two things.
The first: the deeper in the world’s dependency tree you are, the less frequently things will churn, and the longer your skills will last. TCP doesn’t change very often. Theoretical skills may be applicable for your entire career. Human skills are more durable than any technical skill. Kernels don’t change very often (but more than TCP). Databases don’t change very often (but more than kernels). There is a spectrum of skill durability, and you will burn out faster if you find that all of your skills become worthless after a very short time. Dependency forces things not to change their interface, which causes the work to shift toward performance and reliability among other things that some people find far more rewarding over time.
The second: the more people who do what you do, the worse you will be treated, the more BS you will have to put up with, the worse your pay will be, the faster you will be fired, the harder it will be to find a job that values you, etc… etc… Supply and demand applies to our labor market, and if you want to be happier, you should exploit this dynamic as heavily as possible. Avoid competition like the plague. But don’t avoid funding. How do you avoid competition without going off into the wilderness where there is no money to be made? Hype drives funding, but it also drives a lot of competition. However, using rule #1 above, the hyped things depend on other things. Many of these dependencies are viewed as “too hard” for one reason or another. That’s the best place to be. Go where other people are afraid, but nevertheless have a lot of money depending on.
All hyped things rely on things that for one reason or another are not commonly understood, and tend not to change quickly. That’s a good place to find work involving durable skills that tend to have lower competition. Go where the dependency is high but the competition is low, and you have a better chance of being happy than people who go where the competition is high or the dependency is low. Bonus points if it’s actually “hard” because then you won’t get bored as quickly.
There are areas of front-end that are high-dependency, durable, slow-changing, and low-competition. That’s where engineers are likely to be happiest. But these two principles apply to every field or zooming out to any business generally. I’m pretty happy working on new distributed systems and database storage engines for the time being. But I’m always looking for the things that are viewed as hard while also receiving significant investment, as these are the things that will ultimately give me more opportunities to live life on my own terms.
This is so true, I’ve gone to my car to fetch my laptop just to upvote and comment. It’s an exceptionally important piece of advice I wish I had understood as early as possible in life, but I didn’t.
CS (pure) and Math degrees are so good because they teach you really basic theories that are mostly timeless. Whenever I’ve gravitated towards more trendy or applied skills, either in coursework or in jobs, there’s always been a really poor and transient ROI.
[…] using rule #1 above, the hyped things depend on other things. Many of these dependencies are viewed as “too hard” for one reason or another. That’s the best place to be.
What are some examples of these dependencies right now, or in the near future?
Thank you very much for this post. Great distillation of essential career advice, especially the part about the durability of human skills. So many developers would derive far more value from a single public speaking or improv class than from learning yet another new programming language.
Oh man, the number of times I’ve echoed this exact same message to others almost verbatim in the first two paragraphs. Thanks for posting this. Thinking about my career in this way a few years ago was probably the most valuable change I made.
Large-scale ML, blockchain, IoT, serverless, k8s, etc… are all areas recently flooded by newly minted experts in the topical skills, but like the Australian poop diver who claims to have never worked a day in his life, there are great opportunities for high-respect jobs in the dirty internals of the systems :) Particularly with this set of hyped tech, there are very few people who seem to specialize in getting bugs to jump out in distributed systems. Everybody is still writing almost all of them in a way that assumes the happy path. But there are techniques for building all of these systems in ways that encourage the race conditions to jump out. The few people who take pride in building correct distributed systems will have their plates full for a while!
Another reason why this kind of bug hunting and prevention is not all that popular may be that the sorta-similar yet way-cooler-seeming field of systems security tends to absorb a lot of the people who may have otherwise been predisposed to this type of work.
Spitballing, I’m going to google “hyped programming field” and see what comes up, then I’ll try to break it into areas for investigation. Ok, my results on the first page seemed to be about AI, python, golang. I mentioned high-scale ML depending on distributed systems skills and correctness skills above, so I’ll think about the others. Python feels harder for me to answer so let’s dig into that.
Python is immensely popular and I think that becoming an expert in alleviating any friction point that people often hit will be lucrative. But what about things that SOUND really boring? When I think about things that suck about Python, the most dreadful thing that comes to my mind is migrating large applications from Python 2 to Python 3. Python 2 stuff is still everywhere, and it’s increasingly hazardous over time because its support has run out. But people don’t want to touch things that are still ticking along. Legacy systems, like geriatric medical care, becomes more important every day.
But despite being extremely important and an excellent place to apply interesting mechanical (yet supervised) translation and correctness analysis during modernization, so many people have been burned by consent issues at work where their managers forced them to work on legacy despite them not wanting to work on them. So much of the overall programming population has been burned by non-consensual legacy engineering that almost everyone wants to stay as far away as possible. The only question is how to find the companies who realize that modernizing their legacy systems is actually something you want to pay a specialist to do instead of forcing the task on junior devs with no negotiating power. Banks are well-known for paying consultants for this kind of work, but to be honest I’m not sure.
Maybe Python 2 modernization isn’t exactly a golden ticket due to the difficulty in finding companies who are willing to hire specialists to perform this task. Maybe it’s too easy. But may it’s not. I’m not sure. In any case, this maybe demonstrates the general search technique, and can be used to illuminate further areas for research. If general Python 2 modernization is “too easy” then you can slap on more filters. Python 2 modernization for automotive codebases. That sounds much more correctness-critical and likely to pay a specialist to accomplish.
Anyway, the general pattern is: what feels repulsive and hard? Maybe that sense of repulsion creates a dynamic where the few people who do the thing are extremely well treated due to their scarcity. If that scarcity of talent aligns with an extremely popular overall field, there’s a good chance that there are folks who require a specialist to address this niche.
Anyway, the general pattern is: what feels repulsive and hard? Maybe that sense of repulsion creates a dynamic where the few people who do the thing are extremely well treated due to their scarcity. If that scarcity of talent aligns with an extremely popular overall field, there’s a good chance that there are folks who require a specialist to address this niche.
Here’s an example of scarcity working out well for an expert. Another company in my industry was converting to a different accounting system. These projects are incredibly complex and can last years. Part of the process required recreating hundreds of templates for the new system. One contractor handled the template conversion; she retired at a young age after the project was complete.
Have you written about this anywhere? I’d be curious to hear more about it. It immediately struck a chord with me, and probably does with most software engineers.
I think everyone who interacts with frontend javascript feels the same way. I’m afraid that in the backend he is going to see a similar kind of rapidly growing complexity too - except instead of npm hell it is k8s hell.
I wish I had a cogent view on the forces that are making software engineering go this horrible way but I have no such insight. The best I can come up with is that Alan Kay quote about how professions that grow faster then their education end up susceptible to fads which, christ preserve me, I cannot even find by searching. I really hope that quote is true because it at least suggests that once the profession stops growing the symptoms might improve.
I think it happens because the only way to make a simple solution is if you have a deep understanding of the problem you are trying to solve. It requires a much greater understanding than what is needed to solve it via sheer force of effort.
In the majority of developers’ work they don’t have enough time to gain deep understanding of the problems they are trying to solve. The moment they have a solution, even a half-baked one, they move onto solving the next problem in an ever growing queue of work.
Developers may also become bored before building up enough context to break through the complexity barrier. It can take a long time and many iterations to simplify some problems. Many developers (or their managers) lack the patience to keep working on “solved” problems after they have something that meets their needs well enough.
As an industry we also have a problem with knowledge transfer. Even if a developer reaches a new level of understanding they may not be able to pass all of this onto the next generation of devs. The new devs go through the process of reinvention and relearning the same concepts, then the cycle continues.
I think it happens because the only way to make a simple solution is if you have a deep understanding of the problem you are trying to solve. It requires a much greater understanding than what is needed to solve it via sheer force of effort.
I agree, The best thing to look for in any professional, doctor, lawyer, coder, etc is their ability to not engage with a problem, instead solving it in a simple and non-intrusive way. The worst behavior from professionals are the folks who are going to do a lot of work no matter what. These guys look busy, and they’re deep in a bunch of technically wonky stuff that nobody understands, so naturally they look like they know what they’re doing and are doing a good job. The guy who shows up in flip-flops and after a five-minute conversation solves your problem? He’s just some smart eleck showman, probably a con man.
It’s a severe problem. It’s eating our industry alive.
I do have a (self-consistent, if not necessarily correct or happy) set of thoughts which explain the dynamic sufficiently for me.
As developer productivity improves, the set of problems profitably solved by software grows faster than productivity does, so there’s demand for more developers the more productive they are.
Software development frequently generates profits far in excess of what is needed to sustain the operation
Organisations which enjoy profits far in excess of their operating needs become dominated by empire-building because there is no counter-pressure.
As an empire-building manager, I need to invent plausible ways to occupy the developers I hire.
A consultancy will recommend technologies suitable to the size of the team I have (that is, something that will require all of my staff to maintain).
A consultancy will generally not recommend something that works with no configuration or setup required, since then they can’t sell you configuration or setup work.
I started coding when I was 14, around 2007 or so. [..] Fast-forward 3 years I got my first few gigs as a web developer. By then I was pretty good at HTML and CSS already, had dabbled enough with PHP to know my way around of most sticky problems I would find myself in and while I didn’t really know much of vanilla JavaScript, it was okay, because everyone used almost exclusively jQuery anyway.
Is there any other industry where a 17-year old who “dabbled enough” can land a job? I can’t shake the feeling that this is the real problem with a significant part of the industry: 18 year olds who write much of the code, guided by a 22-year old “senior developers”, all led by a 24-year old CTO.
I don’t think there’s anything wrong with React or NPM or most other frontend things, but you got to know when to apply it and when not to apply it. Youthful enthusiasm and hubris leads to the “JS framework of the week”-syndrome. Experience is not a substitute for talent, but talent is also not a substitute for experience.
I think that an industry without credentialism is a great thing. There is generally too much credentialism in the world. Not having credentials does not preclude learning and mastery.
I don’t think age is the problem. It is more, lack of experience and lack of education. Aren’t we always hearing about those who only attend a coding bootcamp and already find a job? How good is their code quality?
don’t think age is the problem. It is more, lack of experience and lack of education.
But those are strongly correlated, no?
I do suspect that age in itself does play a part; certainly if I look at myself I am now, at the age of 35, not the same person that I was when I was 17 or 25. I am more patient, more aware of risks, more humble, and less likely to be swept along in a wave of enthusiasm. Generally I think I’m more thoughtful about things (although I’m hardly perfect, and in 20 years when I’m 55 I’ll be able to list aspects where I’ve improved over 35-year old me – at least, I hope I will).
I’ve worked with a few older (30s) people who did a bootcamp and they were generally okay; their code wasn’t always perfect, but that’s okay as long as they keep learning and developing.
I think guidance is key here; there is nothing at all wrong with a 17-year old or bootcamper being employed as a programmer as such, provided they are guided by more experienced programmers. It’s this part that is often missing.
I agree, but you are conflating two things. I started programming when I was 7, so by the time I was 18 I had 11 years of experience. There are a lot of fields where that amount of experience, even if it’s as an amateur, will get you a job. 18-year-old me was painfully immature; however, and anyone who would have offered him a job really needs to re-examine their hiring process.
On the technical side, part of the problem with 18-year-old me was the problem with any autodidact. There were massive gaps in my knowledge where I didn’t realise the knowledge even existed. A few years at a university that focused on theory and hanging out with systems programmers on the side helped a lot there: the main value of a university education is that it gives you a guided tour of your ignorance. It doesn’t fix your ignorance but it does give you the tools to fix the bits that you discover you need to fix and it does show you what you could learn.
I think that’s a big part of the problem with the industry. We have a huge number of people who have absolutely no idea of the scope of their ignorance. The biggest difference between 18-year-old me and me is that I am no longer surprised to find there’s a big bit of computer science that I don’t know anything about. Until a few years ago, I didn’t know that effects systems or flow-sensitive type systems existed. Now that I do and have learned that a bunch of properties that I’d been trying to enforce dynamically can be statically verified.
…the main value of a university education is that it gives you a guided tour of your ignorance.
I’m going to steal the shit out of this quote. You nailed it. I learned to program when I was 10. Much later (after college, actually) when I decided to wanted to do this for a living I actually went back to school because I realized (through conversations with friends) that there were a ton of things I didn’t even know I didn’t know. Fast-forward a couple years and I was a much, much more effective software developer.
I think the crux of the matter is that “coding” and “developing a product” are not the same things (I use “product” in the broadest sense; it can also be something like Vim or Lobsters). Coding requires pure technical chops and talent, whereas developing a product requires much more, and many of those skills can’t easily be taught in a course.
A teenager can find a clever exploit in some application: this requires just talent. But actually writing an application and maintaining it for 20 years takes much more than just an understanding of the technical parts.
Going back to this story, this seems roughly the problem in JS (or at least one of them): there are many very smart and talented people involved, many of whom are undoubtedly smarter than I am, but a sizeable number of them also don’t seem to have the “product developing skills” that are required to build an ecosystem that’s not the pain that it is today.
I know a few designers that started very early, but it’s too not common. I have a friend that has started beekeeping at the age of 16. Most of jobs where you can start early are usually not very knowledge heavy and more based around the ability to do it. Now the question is, is programming knowledge heavy, and should it be?
I see this prototypical rant posted here on a regular basis, and I’m thinking it’s time to hold these to a higher standard.
I don’t know many people who would argue that variations of the modern react stack are easy or ergonomic to configure or who are happy with the amount of churn in that scene, or who think JavaScript is a great language without serious problems.
But often missing from these critiques is context about what is getting built, and analysis about when certain tools and frameworks are useful and when they’re not. It would be foolish to write “I don’t see why we have scala when Perl cgi scripts work just fine”. Are we bringing in a whole compiler tool chain in order to add form validation on a single page? Or are we working on an app with a dynamic user experience built on top of tricky client-side flows? The second case is more interesting to me because then we can engage in why tools are failing us at the task they were actually designed for. Is developer experience the problem? Do we need a better language or runtime? Is the web unsalvageable even as a compile target? How does wasm change any of this?
Because if you don’t then obviously you haven’t learned anything since 2005 and suck [..]
I want to have a personal life and not have to spend my nights reading up on some new flavour of *.js in fear that if I don’t I would soon be made irrelevant. [..]
This, so much this. And I’m not even doing this as my job.
And of course there is truth to it, of course its better to not just slap some vanilla JS on it. But its sooo much tooling, so many new dialects and so many points you can get wrong. In the end I look on my React/Vue/Ember/Angular/Svelte/Elm/..-Hello-World (don’t you dare forget Typescript on top) with ~30k NPM packages. Meanwhile I’m trying to make the framework specific webserver work as reverse-proxy such that I can develop locally with the React/Vue/.. hot reloading while also making REST requests. Oh wait I said REST, that’s outdated, nowadays you wanna do GraphQL, have fun with that in your backend. And lets not forget the newest bootstrap alternative with your favorite flair of fontawesome. And please start using material themes, thats what the new kids do. (And yeah not doing it feels bad, of course I wanna look good and feel good & fresh with my stuff.)
Meanwhile my rust backend has ~300 dependencies, around 12 of them are direct ones. And for some reason it doesn’t feel that clunky. Maybe because I have more control and am not playing whack a mole with layers on layers of post/pre processors for html/html5/scss/css/js/typescript ? It’s just less of an overload of different working systems.
And yeah, this is kinda Mee-Too with additions. So looking at the moderation logs feel free to delete it pushcx if its not adding any value.
Maybe a hot take, but I suspect that your Rust situation doesn’t feel clunky because Cargo is a first-party tool. Everything in the JS world is created by a different company or organization. They all have their own agendas and ideas about how things should work and they are all chasing “mindshare”. Look at WebPack, it actually rewrites NPM packages so that they work correctly. If JavaScript had an actual package management ecosystem, created by a first party (of course there really isn’t one in this case, but Google or Mozilla might fit the bill well enough to work) then changes could be proposed to that system to make browser dependencies work cleanly and everyone would get them automatically. But instead we have software that mangles the competing package formats and no one actually fully understands.
As a ranty aside, I am skeptical of any tool or ecosystem that leaves important features to the “community”. Look at Go, they tried to leave dependency management to the community and all they got were a huge number of half-baked competing solutions. Sure, they learned a lot from the experiment, but in the meantime the company I worked for at the time spent hundreds or even thousands of developer-hours fighting with dependency tooling.
We all love comparing ourselves to other branches of engineering, so what if civil engineers built bridges with no railings and asked the “community” to provide those? Even systems that are intended to be extended, like phones, have limited and clearly-defined extension points. It’s not a perfect analogy but my point is that most branches of engineering design and build full solutions to problems.
Full first-party solutions that allow for interoperation and extension are the sweet spot IMO. Rust (and modern Go, FWIW) mostly has this, JavaScript does not.
Everything in the JS world is created by a different company or organization. They all have their own agendas and ideas about how things should work and they are all chasing “mindshare”.
As somebody who’s spent a fair percentage of their time doing JS development since it was invented, this is definitely the big, (comparatively) recent change that’s causing all the problems. Everybody wants those github stars and blog posts for their linkedin, and those of us with work to do are the ones paying the tab.
He forgot Docker and all of the additional fun around making sure some kind of cloud deployment strategy is part of your build.
It’s interesting to me that in such a complex environment we don’t teach coders the one skill they need most of all: adding incremental complexity as-needed. Nobody talks about choosing what to add and why. Nobody talks about ways to understand you’ve gone too far (except for a few folks like me. Apologies for the shameless plug.)
For some odd reason, discussions on frameworks and complexity always devolve into some version of “Dang kids!” vs. “Talentless luddite!” As many people have pointed out, not only do we not teach or talk about incremental complexity, if you don’t have the appropriate buzzwords in your CV, you don’t get hired. So BigCorps naturally end up with scads of people who did well on scads of tech that somebody decide they had to use/learn but nobody very good at actually making things happen.
There’s plenty to criticize about the tooling of a typical, modern, web front-end. Little of it can be found here. There are more holes and falsehoods in this rant than there are facts.
JavaScript no longer is liked by the community, so the community created a poor man’s version of a typed language which duct-tapes around an already poorly made language.
This is verifiably false. Surveys by Stack Overflow and State of JS indicate a relatively high satisfaction with the language. TypeScript emerged not as a result the language’s fundamental design flaws, but to cope with the increasing demands of project requirements, including the use of greater numbers of external data sources and dependencies, which, in turn, warrant some kind of type contract. Indeed, JavaScript has grown out of its “toy language” infancy that made it so easy for web developers to simultaneously use to embellish sites written in some other language and deride as beneath their pay. The “poorly made language” link points to an article that uses, among other straw man arguments, the IEEE 754 Double Precision number primitive as an example some kind of fringe, obviously wrong design decision.
you better set-up your project with TypeScript, ESlint, Webpack and Babel
As if linting, bundling, and transpiling to support legacy environments is some arbitrary, unnecessary choice made only out of the innate stupidity of the front-end development community.
Don’t have NPM? Better install that, too, because nobody installs libraries without a package manager anymore. Oh and while you’re at it, install also Yarn, because why not make use of two package managers at the same time.
First off, you don’t have to pick yarn. It’s there as an alternative to npm if you want it. And yes, it was never really OK to copy-paste JavaScript into one’s own source without distinguishing what one wrote from what someone else did. Now that we have a de facto standard for dependency management, there’s little excuse not to use it. There are some valid criticisms to be made of npm’s design, but none of them are made here. I might challenge people to try to do better, but part of my day job is debugging a proprietary module system designed by someone who regularly vented his loathing of the JavaScript language, so please don’t, at least not in anger.
I want to have a personal life and not have to spend my nights reading up on some new flavour of *.js in fear that if I don’t I would soon be made irrelevant. I don’t want to learn nor use a million different tools. I don’t want to know a bit about everything and a lot about nothing.
This is the only statement of substance in the whole article, and it too is somewhat misguided. I have little to cite but my own 16 years of experience in the software industry and my observation of my father’s career, which started in the ’60s, both of which are subjective. My first lecture as a CS student in 2000 was an orientation by the head of electrical and computer engineering, who’d just performed the academic equivalent of a hostile takeover of the CS department. He told us all that we were in the wrong major, that the real money was in circuit design, and that software engineering was a dead-end career. I’m going to go out on a limb and say that no one gets a pass on constant learning because they’ve buried themselves somewhere deeper in the stack. When one finds that making good on the claim to be “full stack” is an impediment to learning about something else of greater interest it’s neither necessary nor helpful to take potshots like this on the way out. If they find something else that can:
bind application state to a uniform resource locator,
animate transitions between application states,
dynamically and accessibly lay out and render both LR and RL text in any font,
dynamically render animated vector, 2D raster, and 3D graphics,
and run on pretty much any general purpose consumer computing device without porting to another language,
…then they will have something of substance to write about.
I agree with the general topic of the discussions in this thread, but I must say that as someone who never cared about frontend; these modern frameworks like Vue or React have been a game changer for me.
I used to not be able to put anything decently looking, using jQuery and raw CSS was a PITA, but nowadays with frameworks like Vue and Vuetify I can just make something decently looking, sure, I can’t style it too much so it has an unique look, I’d probably need a designer for that, but what matters is that it’s functional, it feels right and it’s responsive. I even do some frontend at work and it’s not bad.
Counterpoint: I, another front-end developer who’s exhausted by the complicated tech stack at $dayjob, put together a JS-only side project that doesn’t use SCSS or TypeScript or other bells-and-whistles. I found that the power of JS within the client itself is plenty powerful for many things which were previously handled by a backend (caveat: it’s not doing any Real Number-Crunching).
I’m not sure what’s your point. Autogenerated CSS will force the client to waste CPU cycles reading through dozens auto-prefixed settings it doesn’t need and hasn’t needed in a decade. In any case I’m still to see CSS have any real performance impact.
I’ve given in my resignation at my current place of employment and will be seeking an exclusively back-end role for my next adventure, starting April.
I knew that was how this was going to end. Web developers often seem to miss the fact that there’s anything outside their field. There are things going on in CS other than serving and rendering web pages!
Mobile and desktop app development has similarities to front-end web dev, but you get to code with stuff that isn’t Jell-O, can afford to focus on one platform at a time, and have a lot more capabilities. Then there’s embedded development, but the technical constraints there might be a steep learning curve to someone who’s used to JS.
At my previous job I did everything (full-stack) and it progressively led to being primarily frontend (in Elm, at least). There wasn’t a path to what I wanted to work on (both tech and domain), which was one of the reasons I left.
When interviewing for my next job, I told everywhere that I did not want to work in anything frontend related. I’ve been asked I’d be willing to a minority split, but I knew that that promise wouldn’t be held. I’ve also had to prevent myself from thinking at my new place that I could quickly knock out a PR or too.
My father works in a company where most third party libraries are banned from use and those that do get included have to be properly licensed, attributed, audited and continually maintained in collaboration with the company.
I always thought it was a bit peculiar a stance, but it has meant they avoid a lot of the problems the rest of the JS ecosystem seem to have.
It’s interesting because I often try to sell others on using vanilla web components when possible and if you need a larger tool to guide your data and organize things I suggest Elm. Both because they’re slow to change, so if the same code I was writing 3+ years ago is still the same I’m writing today, they’re focused, and they’re small. React, Vie, Ember, Angular, etc are all changing frequently. Some as often as every 6 months. I know entire teams that can’t keep up with a 6 month release frequency! How is an individual supposed?
I’ve seen people struggle with the transition from front-end to embedded. The way of thinking is different, it requires a different skillset, and there is little respect to be had when people come from a web background. I don’t think the transition would be complete until after building skills a couple of years in one company, then switching to another.
I think in general the industry tends to stray into topics of less interest as more layers of abstraction are stacked on top of previous layers and these layers are inevitable in the quest for efficiency. The interesting, theoretical and technical work is hidden away and you’re left with gluing and maintenance. Being able to write a custom container system is cool but knowing how to use docker is what makes you money. Note that this doesn’t apply everywhere - there definitely exist places where the tool or framework itself is written that provide the right balance between new innovation and reuse of old skills. The problem lies in that you only need one good framework for thousands of projects, so most developers are always going to get left shoveling dirt.
I guess the takeaway here is aim to work where there is value in innovation, such as developer product and tool companies, and stay away from working in heavily-layered abstractions for too long.
I tell anyone asking me for career advice the same two things.
The first: the deeper in the world’s dependency tree you are, the less frequently things will churn, and the longer your skills will last. TCP doesn’t change very often. Theoretical skills may be applicable for your entire career. Human skills are more durable than any technical skill. Kernels don’t change very often (but more than TCP). Databases don’t change very often (but more than kernels). There is a spectrum of skill durability, and you will burn out faster if you find that all of your skills become worthless after a very short time. Dependency forces things not to change their interface, which causes the work to shift toward performance and reliability among other things that some people find far more rewarding over time.
The second: the more people who do what you do, the worse you will be treated, the more BS you will have to put up with, the worse your pay will be, the faster you will be fired, the harder it will be to find a job that values you, etc… etc… Supply and demand applies to our labor market, and if you want to be happier, you should exploit this dynamic as heavily as possible. Avoid competition like the plague. But don’t avoid funding. How do you avoid competition without going off into the wilderness where there is no money to be made? Hype drives funding, but it also drives a lot of competition. However, using rule #1 above, the hyped things depend on other things. Many of these dependencies are viewed as “too hard” for one reason or another. That’s the best place to be. Go where other people are afraid, but nevertheless have a lot of money depending on.
All hyped things rely on things that for one reason or another are not commonly understood, and tend not to change quickly. That’s a good place to find work involving durable skills that tend to have lower competition. Go where the dependency is high but the competition is low, and you have a better chance of being happy than people who go where the competition is high or the dependency is low. Bonus points if it’s actually “hard” because then you won’t get bored as quickly.
There are areas of front-end that are high-dependency, durable, slow-changing, and low-competition. That’s where engineers are likely to be happiest. But these two principles apply to every field or zooming out to any business generally. I’m pretty happy working on new distributed systems and database storage engines for the time being. But I’m always looking for the things that are viewed as hard while also receiving significant investment, as these are the things that will ultimately give me more opportunities to live life on my own terms.
There is an old Yorkshire saying: “where’s there’s muck, there’s brass”.
This is so true, I’ve gone to my car to fetch my laptop just to upvote and comment. It’s an exceptionally important piece of advice I wish I had understood as early as possible in life, but I didn’t.
CS (pure) and Math degrees are so good because they teach you really basic theories that are mostly timeless. Whenever I’ve gravitated towards more trendy or applied skills, either in coursework or in jobs, there’s always been a really poor and transient ROI.
What are some examples of these dependencies right now, or in the near future?
Thank you very much for this post. Great distillation of essential career advice, especially the part about the durability of human skills. So many developers would derive far more value from a single public speaking or improv class than from learning yet another new programming language.
Oh man, the number of times I’ve echoed this exact same message to others almost verbatim in the first two paragraphs. Thanks for posting this. Thinking about my career in this way a few years ago was probably the most valuable change I made.
Thank you for the kind words :)
Large-scale ML, blockchain, IoT, serverless, k8s, etc… are all areas recently flooded by newly minted experts in the topical skills, but like the Australian poop diver who claims to have never worked a day in his life, there are great opportunities for high-respect jobs in the dirty internals of the systems :) Particularly with this set of hyped tech, there are very few people who seem to specialize in getting bugs to jump out in distributed systems. Everybody is still writing almost all of them in a way that assumes the happy path. But there are techniques for building all of these systems in ways that encourage the race conditions to jump out. The few people who take pride in building correct distributed systems will have their plates full for a while!
Another reason why this kind of bug hunting and prevention is not all that popular may be that the sorta-similar yet way-cooler-seeming field of systems security tends to absorb a lot of the people who may have otherwise been predisposed to this type of work.
love this comment. like the other commenter, do you have any examples of “hard, but trendy” in frontend or elsewhere?
Spitballing, I’m going to google “hyped programming field” and see what comes up, then I’ll try to break it into areas for investigation. Ok, my results on the first page seemed to be about AI, python, golang. I mentioned high-scale ML depending on distributed systems skills and correctness skills above, so I’ll think about the others. Python feels harder for me to answer so let’s dig into that.
Python is immensely popular and I think that becoming an expert in alleviating any friction point that people often hit will be lucrative. But what about things that SOUND really boring? When I think about things that suck about Python, the most dreadful thing that comes to my mind is migrating large applications from Python 2 to Python 3. Python 2 stuff is still everywhere, and it’s increasingly hazardous over time because its support has run out. But people don’t want to touch things that are still ticking along. Legacy systems, like geriatric medical care, becomes more important every day.
But despite being extremely important and an excellent place to apply interesting mechanical (yet supervised) translation and correctness analysis during modernization, so many people have been burned by consent issues at work where their managers forced them to work on legacy despite them not wanting to work on them. So much of the overall programming population has been burned by non-consensual legacy engineering that almost everyone wants to stay as far away as possible. The only question is how to find the companies who realize that modernizing their legacy systems is actually something you want to pay a specialist to do instead of forcing the task on junior devs with no negotiating power. Banks are well-known for paying consultants for this kind of work, but to be honest I’m not sure.
Maybe Python 2 modernization isn’t exactly a golden ticket due to the difficulty in finding companies who are willing to hire specialists to perform this task. Maybe it’s too easy. But may it’s not. I’m not sure. In any case, this maybe demonstrates the general search technique, and can be used to illuminate further areas for research. If general Python 2 modernization is “too easy” then you can slap on more filters. Python 2 modernization for automotive codebases. That sounds much more correctness-critical and likely to pay a specialist to accomplish.
Anyway, the general pattern is: what feels repulsive and hard? Maybe that sense of repulsion creates a dynamic where the few people who do the thing are extremely well treated due to their scarcity. If that scarcity of talent aligns with an extremely popular overall field, there’s a good chance that there are folks who require a specialist to address this niche.
Here’s an example of scarcity working out well for an expert. Another company in my industry was converting to a different accounting system. These projects are incredibly complex and can last years. Part of the process required recreating hundreds of templates for the new system. One contractor handled the template conversion; she retired at a young age after the project was complete.
Have you written about this anywhere? I’d be curious to hear more about it. It immediately struck a chord with me, and probably does with most software engineers.
I think everyone who interacts with frontend javascript feels the same way. I’m afraid that in the backend he is going to see a similar kind of rapidly growing complexity too - except instead of npm hell it is k8s hell.
I wish I had a cogent view on the forces that are making software engineering go this horrible way but I have no such insight. The best I can come up with is that Alan Kay quote about how professions that grow faster then their education end up susceptible to fads which, christ preserve me, I cannot even find by searching. I really hope that quote is true because it at least suggests that once the profession stops growing the symptoms might improve.
I think it happens because the only way to make a simple solution is if you have a deep understanding of the problem you are trying to solve. It requires a much greater understanding than what is needed to solve it via sheer force of effort.
In the majority of developers’ work they don’t have enough time to gain deep understanding of the problems they are trying to solve. The moment they have a solution, even a half-baked one, they move onto solving the next problem in an ever growing queue of work.
Developers may also become bored before building up enough context to break through the complexity barrier. It can take a long time and many iterations to simplify some problems. Many developers (or their managers) lack the patience to keep working on “solved” problems after they have something that meets their needs well enough.
As an industry we also have a problem with knowledge transfer. Even if a developer reaches a new level of understanding they may not be able to pass all of this onto the next generation of devs. The new devs go through the process of reinvention and relearning the same concepts, then the cycle continues.
I agree, The best thing to look for in any professional, doctor, lawyer, coder, etc is their ability to not engage with a problem, instead solving it in a simple and non-intrusive way. The worst behavior from professionals are the folks who are going to do a lot of work no matter what. These guys look busy, and they’re deep in a bunch of technically wonky stuff that nobody understands, so naturally they look like they know what they’re doing and are doing a good job. The guy who shows up in flip-flops and after a five-minute conversation solves your problem? He’s just some smart eleck showman, probably a con man.
It’s a severe problem. It’s eating our industry alive.
I do have a (self-consistent, if not necessarily correct or happy) set of thoughts which explain the dynamic sufficiently for me.
Thats DevOps, not Backend? More like
composer,pip,gem, all of who are better in one way or another against trashynpmand alike.Is there any other industry where a 17-year old who “dabbled enough” can land a job? I can’t shake the feeling that this is the real problem with a significant part of the industry: 18 year olds who write much of the code, guided by a 22-year old “senior developers”, all led by a 24-year old CTO.
I don’t think there’s anything wrong with React or NPM or most other frontend things, but you got to know when to apply it and when not to apply it. Youthful enthusiasm and hubris leads to the “JS framework of the week”-syndrome. Experience is not a substitute for talent, but talent is also not a substitute for experience.
I think that an industry without credentialism is a great thing. There is generally too much credentialism in the world. Not having credentials does not preclude learning and mastery.
I don’t think that “let’s not rely too much on credentials” and “let’s not have teenagers and early tweens run the company” are incompatible views.
An even bigger problem is that having credentials doesn’t automatically imply mastery either!
I don’t think age is the problem. It is more, lack of experience and lack of education. Aren’t we always hearing about those who only attend a coding bootcamp and already find a job? How good is their code quality?
But those are strongly correlated, no?
I do suspect that age in itself does play a part; certainly if I look at myself I am now, at the age of 35, not the same person that I was when I was 17 or 25. I am more patient, more aware of risks, more humble, and less likely to be swept along in a wave of enthusiasm. Generally I think I’m more thoughtful about things (although I’m hardly perfect, and in 20 years when I’m 55 I’ll be able to list aspects where I’ve improved over 35-year old me – at least, I hope I will).
I’ve worked with a few older (30s) people who did a bootcamp and they were generally okay; their code wasn’t always perfect, but that’s okay as long as they keep learning and developing.
I think guidance is key here; there is nothing at all wrong with a 17-year old or bootcamper being employed as a programmer as such, provided they are guided by more experienced programmers. It’s this part that is often missing.
I agree, but you are conflating two things. I started programming when I was 7, so by the time I was 18 I had 11 years of experience. There are a lot of fields where that amount of experience, even if it’s as an amateur, will get you a job. 18-year-old me was painfully immature; however, and anyone who would have offered him a job really needs to re-examine their hiring process.
On the technical side, part of the problem with 18-year-old me was the problem with any autodidact. There were massive gaps in my knowledge where I didn’t realise the knowledge even existed. A few years at a university that focused on theory and hanging out with systems programmers on the side helped a lot there: the main value of a university education is that it gives you a guided tour of your ignorance. It doesn’t fix your ignorance but it does give you the tools to fix the bits that you discover you need to fix and it does show you what you could learn.
I think that’s a big part of the problem with the industry. We have a huge number of people who have absolutely no idea of the scope of their ignorance. The biggest difference between 18-year-old me and me is that I am no longer surprised to find there’s a big bit of computer science that I don’t know anything about. Until a few years ago, I didn’t know that effects systems or flow-sensitive type systems existed. Now that I do and have learned that a bunch of properties that I’d been trying to enforce dynamically can be statically verified.
I’m going to steal the shit out of this quote. You nailed it. I learned to program when I was 10. Much later (after college, actually) when I decided to wanted to do this for a living I actually went back to school because I realized (through conversations with friends) that there were a ton of things I didn’t even know I didn’t know. Fast-forward a couple years and I was a much, much more effective software developer.
I think the crux of the matter is that “coding” and “developing a product” are not the same things (I use “product” in the broadest sense; it can also be something like Vim or Lobsters). Coding requires pure technical chops and talent, whereas developing a product requires much more, and many of those skills can’t easily be taught in a course.
A teenager can find a clever exploit in some application: this requires just talent. But actually writing an application and maintaining it for 20 years takes much more than just an understanding of the technical parts.
Going back to this story, this seems roughly the problem in JS (or at least one of them): there are many very smart and talented people involved, many of whom are undoubtedly smarter than I am, but a sizeable number of them also don’t seem to have the “product developing skills” that are required to build an ecosystem that’s not the pain that it is today.
I know a few designers that started very early, but it’s too not common. I have a friend that has started beekeeping at the age of 16. Most of jobs where you can start early are usually not very knowledge heavy and more based around the ability to do it. Now the question is, is programming knowledge heavy, and should it be?
Programming probably not, but development yes, I think.
I see this prototypical rant posted here on a regular basis, and I’m thinking it’s time to hold these to a higher standard.
I don’t know many people who would argue that variations of the modern react stack are easy or ergonomic to configure or who are happy with the amount of churn in that scene, or who think JavaScript is a great language without serious problems.
But often missing from these critiques is context about what is getting built, and analysis about when certain tools and frameworks are useful and when they’re not. It would be foolish to write “I don’t see why we have scala when Perl cgi scripts work just fine”. Are we bringing in a whole compiler tool chain in order to add form validation on a single page? Or are we working on an app with a dynamic user experience built on top of tricky client-side flows? The second case is more interesting to me because then we can engage in why tools are failing us at the task they were actually designed for. Is developer experience the problem? Do we need a better language or runtime? Is the web unsalvageable even as a compile target? How does wasm change any of this?
This, so much this. And I’m not even doing this as my job.
And of course there is truth to it, of course its better to not just slap some vanilla JS on it. But its sooo much tooling, so many new dialects and so many points you can get wrong. In the end I look on my React/Vue/Ember/Angular/Svelte/Elm/..-Hello-World (don’t you dare forget Typescript on top) with ~30k NPM packages. Meanwhile I’m trying to make the framework specific webserver work as reverse-proxy such that I can develop locally with the React/Vue/.. hot reloading while also making REST requests. Oh wait I said REST, that’s outdated, nowadays you wanna do GraphQL, have fun with that in your backend. And lets not forget the newest bootstrap alternative with your favorite flair of fontawesome. And please start using material themes, thats what the new kids do. (And yeah not doing it feels bad, of course I wanna look good and feel good & fresh with my stuff.)
Meanwhile my rust backend has ~300 dependencies, around 12 of them are direct ones. And for some reason it doesn’t feel that clunky. Maybe because I have more control and am not playing whack a mole with layers on layers of post/pre processors for html/html5/scss/css/js/typescript ? It’s just less of an overload of different working systems.
And yeah, this is kinda Mee-Too with additions. So looking at the moderation logs feel free to delete it pushcx if its not adding any value.
Maybe a hot take, but I suspect that your Rust situation doesn’t feel clunky because Cargo is a first-party tool. Everything in the JS world is created by a different company or organization. They all have their own agendas and ideas about how things should work and they are all chasing “mindshare”. Look at WebPack, it actually rewrites NPM packages so that they work correctly. If JavaScript had an actual package management ecosystem, created by a first party (of course there really isn’t one in this case, but Google or Mozilla might fit the bill well enough to work) then changes could be proposed to that system to make browser dependencies work cleanly and everyone would get them automatically. But instead we have software that mangles the competing package formats and no one actually fully understands.
As a ranty aside, I am skeptical of any tool or ecosystem that leaves important features to the “community”. Look at Go, they tried to leave dependency management to the community and all they got were a huge number of half-baked competing solutions. Sure, they learned a lot from the experiment, but in the meantime the company I worked for at the time spent hundreds or even thousands of developer-hours fighting with dependency tooling.
We all love comparing ourselves to other branches of engineering, so what if civil engineers built bridges with no railings and asked the “community” to provide those? Even systems that are intended to be extended, like phones, have limited and clearly-defined extension points. It’s not a perfect analogy but my point is that most branches of engineering design and build full solutions to problems.
Full first-party solutions that allow for interoperation and extension are the sweet spot IMO. Rust (and modern Go, FWIW) mostly has this, JavaScript does not.
As somebody who’s spent a fair percentage of their time doing JS development since it was invented, this is definitely the big, (comparatively) recent change that’s causing all the problems. Everybody wants those github stars and blog posts for their linkedin, and those of us with work to do are the ones paying the tab.
He forgot Docker and all of the additional fun around making sure some kind of cloud deployment strategy is part of your build.
It’s interesting to me that in such a complex environment we don’t teach coders the one skill they need most of all: adding incremental complexity as-needed. Nobody talks about choosing what to add and why. Nobody talks about ways to understand you’ve gone too far (except for a few folks like me. Apologies for the shameless plug.)
For some odd reason, discussions on frameworks and complexity always devolve into some version of “Dang kids!” vs. “Talentless luddite!” As many people have pointed out, not only do we not teach or talk about incremental complexity, if you don’t have the appropriate buzzwords in your CV, you don’t get hired. So BigCorps naturally end up with scads of people who did well on scads of tech that somebody decide they had to use/learn but nobody very good at actually making things happen.
There’s plenty to criticize about the tooling of a typical, modern, web front-end. Little of it can be found here. There are more holes and falsehoods in this rant than there are facts.
This is verifiably false. Surveys by Stack Overflow and State of JS indicate a relatively high satisfaction with the language. TypeScript emerged not as a result the language’s fundamental design flaws, but to cope with the increasing demands of project requirements, including the use of greater numbers of external data sources and dependencies, which, in turn, warrant some kind of type contract. Indeed, JavaScript has grown out of its “toy language” infancy that made it so easy for web developers to simultaneously use to embellish sites written in some other language and deride as beneath their pay. The “poorly made language” link points to an article that uses, among other straw man arguments, the IEEE 754 Double Precision number primitive as an example some kind of fringe, obviously wrong design decision.
As if linting, bundling, and transpiling to support legacy environments is some arbitrary, unnecessary choice made only out of the innate stupidity of the front-end development community.
First off, you don’t have to pick yarn. It’s there as an alternative to npm if you want it. And yes, it was never really OK to copy-paste JavaScript into one’s own source without distinguishing what one wrote from what someone else did. Now that we have a de facto standard for dependency management, there’s little excuse not to use it. There are some valid criticisms to be made of npm’s design, but none of them are made here. I might challenge people to try to do better, but part of my day job is debugging a proprietary module system designed by someone who regularly vented his loathing of the JavaScript language, so please don’t, at least not in anger.
This is the only statement of substance in the whole article, and it too is somewhat misguided. I have little to cite but my own 16 years of experience in the software industry and my observation of my father’s career, which started in the ’60s, both of which are subjective. My first lecture as a CS student in 2000 was an orientation by the head of electrical and computer engineering, who’d just performed the academic equivalent of a hostile takeover of the CS department. He told us all that we were in the wrong major, that the real money was in circuit design, and that software engineering was a dead-end career. I’m going to go out on a limb and say that no one gets a pass on constant learning because they’ve buried themselves somewhere deeper in the stack. When one finds that making good on the claim to be “full stack” is an impediment to learning about something else of greater interest it’s neither necessary nor helpful to take potshots like this on the way out. If they find something else that can:
…then they will have something of substance to write about.
I agree with the general topic of the discussions in this thread, but I must say that as someone who never cared about frontend; these modern frameworks like Vue or React have been a game changer for me.
I used to not be able to put anything decently looking, using jQuery and raw CSS was a PITA, but nowadays with frameworks like Vue and Vuetify I can just make something decently looking, sure, I can’t style it too much so it has an unique look, I’d probably need a designer for that, but what matters is that it’s functional, it feels right and it’s responsive. I even do some frontend at work and it’s not bad.
Counterpoint: I, another front-end developer who’s exhausted by the complicated tech stack at
$dayjob, put together a JS-only side project that doesn’t use SCSS or TypeScript or other bells-and-whistles. I found that the power of JS within the client itself is plenty powerful for many things which were previously handled by a backend (caveat: it’s not doing any Real Number-Crunching).Why calculate something once at build time when you can waste user cpu cycles doing it every time somebody looks at the site?
I’m not sure what’s your point. Autogenerated CSS will force the client to waste CPU cycles reading through dozens auto-prefixed settings it doesn’t need and hasn’t needed in a decade. In any case I’m still to see CSS have any real performance impact.
Sounds a lot like How it feels to learn JavaScript in 2016.
Good read! Thanks a lot for sharing.
I knew that was how this was going to end. Web developers often seem to miss the fact that there’s anything outside their field. There are things going on in CS other than serving and rendering web pages!
Mobile and desktop app development has similarities to front-end web dev, but you get to code with stuff that isn’t Jell-O, can afford to focus on one platform at a time, and have a lot more capabilities. Then there’s embedded development, but the technical constraints there might be a steep learning curve to someone who’s used to JS.
At my previous job I did everything (full-stack) and it progressively led to being primarily frontend (in Elm, at least). There wasn’t a path to what I wanted to work on (both tech and domain), which was one of the reasons I left.
When interviewing for my next job, I told everywhere that I did not want to work in anything frontend related. I’ve been asked I’d be willing to a minority split, but I knew that that promise wouldn’t be held. I’ve also had to prevent myself from thinking at my new place that I could quickly knock out a PR or too.
Anyway, just saying, you’re not alone.
My father works in a company where most third party libraries are banned from use and those that do get included have to be properly licensed, attributed, audited and continually maintained in collaboration with the company.
I always thought it was a bit peculiar a stance, but it has meant they avoid a lot of the problems the rest of the JS ecosystem seem to have.
It’s interesting because I often try to sell others on using vanilla web components when possible and if you need a larger tool to guide your data and organize things I suggest Elm. Both because they’re slow to change, so if the same code I was writing 3+ years ago is still the same I’m writing today, they’re focused, and they’re small. React, Vie, Ember, Angular, etc are all changing frequently. Some as often as every 6 months. I know entire teams that can’t keep up with a 6 month release frequency! How is an individual supposed?
I’ve seen people struggle with the transition from front-end to embedded. The way of thinking is different, it requires a different skillset, and there is little respect to be had when people come from a web background. I don’t think the transition would be complete until after building skills a couple of years in one company, then switching to another.
I think in general the industry tends to stray into topics of less interest as more layers of abstraction are stacked on top of previous layers and these layers are inevitable in the quest for efficiency. The interesting, theoretical and technical work is hidden away and you’re left with gluing and maintenance. Being able to write a custom container system is cool but knowing how to use docker is what makes you money. Note that this doesn’t apply everywhere - there definitely exist places where the tool or framework itself is written that provide the right balance between new innovation and reuse of old skills. The problem lies in that you only need one good framework for thousands of projects, so most developers are always going to get left shoveling dirt.
I guess the takeaway here is aim to work where there is value in innovation, such as developer product and tool companies, and stay away from working in heavily-layered abstractions for too long.