I think this article hits on some truths and gets a handful of things wrong. First, they are correct that we are in a dynamic profession that requires constant learning and expanding. No doubt the people who choose to stay in software are likely to be people who are curious, life-long learners where this is a benefit of the profession rather than a drawback. That said, one thing I noticed from teaching computer science while a graduate student is that the poor students think about languages and libraries as key skills, while the better students think about the data structures, algorithms, and design principles. These slightly more meta-level concepts are far more stable and timeless, while the underlying implementations of them are constantly evolving. If you think of each new library as "having to learn a new skill" I can imagine burnout and overload are more likely, but if you figure once you know 3D graphics you can pretty easily pickup any new graphics engine, then it might even seem fun to explore different takes on the same old concepts. It's like hearing a new band in your favorite genre.
As for attributing burnout as the core issue here, I would strongly disagree with this idea. When teaching undergrads I noticed immediately that a good portion of each student cohort was basically there because they were interested in making money in the future rather than exploring the ideas of computer science. They were no doubt going to get frustrated or bored and move into management or some other profession rather than continue to expand as an engineer. This is totally fine, and they are probably richer for having learned what they did, but I don't know why we can't just see this and appreciate it for what it is rather than portraying it as the drama of burnout.
It's hard to blame students when they look at job postings and all that they see advertised is positions for programmers using languages X, Y and Z, or when they see tweets and blog posts by hotshot programmers about frameworks A and B.
The entire industry focuses way too much on 'experience with tool X' as a proxy for 'technical skill Y'. It's a bit like asking a carpenter how many years of experience they have with DeWalt cordless nail guns rather than ask about their house framing skills.
Worse, industry is routinely bashing on CS degrees because they don't turn people into framework X-ready candidates. It's getting a little tiring just how little credit is given to the idea of "maybe these tools can be learned in a reasonable amount of time by people with a degree showing they can pick things up rather quickly".
> It's a bit like asking a carpenter how many years of experience they have with DeWalt cordless nail guns rather than ask about their house framing skills.
This kind of logic only works for tech organizations that already have enough in-house domain expertise to onboard new programmers. The other day somebody asked me how to find a programmer to implement something for them. From a programming standpoint there was very little to do, but it involved many obscure technologies that you couldn't pickup in a day (and no you can't pick different technologies). For a person who's already done something similar it'd be a quick and easy job, shouldn't cost too much. With a generic programmer it'd take much longer, cost much more and you couldn't be sure they'd actually deliver.
>The entire industry focuses way too much on 'experience with tool X' as a proxy for 'technical skill Y'
Strongly emphasizing this. This is HIGHY applicable to the analytics environment. As a business analyst who specialized in mostly ad-hoc development because it was the most value-add area at the companies I worked with.. I had a lot of trouble finding new work because I didnt use Tableau, or Power BI, or Looker, etc. I was some sort of fool for doing everything in SQL, Excel, and Python.
IMO the tools are great, and you need a much lower level understanding of analytical concepts to get value from them. But for some reason people kept getting the impression I would somehow be less effective with them because I dont use them. And I had trouble correcting them with the limited bandwidth that exists to communicate with a single applicant in the hiring process. If I tried to get right to the point, I felt myself appearing arrogant.
The carpentry analogy is very similar to how i described it. "I am currently using a ruler and screwdriver, and these tools provide lasers and power drills"
It's interesting because at least in terms of working professionals, of the most productive professions I've worked with, the ones who focus on "meta-level" concepts are usually the ones who overthink every detail and get very little work done and ultimately they are the ones who burn out.
They tend to bike-shed details, take way too long to try to create sophisticated abstractions that never quite achieve the silver bullet they originally thought it would, and spend too much time dwelling on irrelevant details that ultimately leads no where and results in a kind of paralysis that can be very hard to break out from.
The ones who master a specific language or master a specific library/technology that focuses on doing a few things very well and in very concrete terms are able to deliver the most business value. Furthermore they absolutely have the ability to take their mastery of that and map it to new languages or new libraries. I mean I'm not talking about going from Java to Haskell or Haskell to Idris, but rather people who master C++ can fairly easily pick up Java or Python or TypeScript. People who have mastered Unity can easily pick up Unreal Engine. People who have mastered web development can easily pick up mobile development.
The idea that people who have a solid mastery of a technology and a programming language are somehow just stuck and unable to take those skills and apply them to other areas I think is overstated and just untrue, but those who treat software engineering as highly theoretical and focus on abstractions, design principles and get caught up on these high level details tend to not get much done and when they realize that software is not as clean and elegant as they would like it to be, they get burned out and give up.
I think going over any substantial codebase for products that are widely used and deliver solid business value on Github where most code is not at all reflective of the ideals often espoused on blog posts validates my point of view.
In short, people who treat software as just a tool to accomplish a concrete task are more productive than those who write software for the sake of writing software. They don't write the cleanest code, or the most elegant data structures and algorithms, but they produce the greatest amount of tangible business value.
If your comment does anything for me its to show how terribly few words we have to discuss these things.
> "meta-level" concepts
I'd say having a strong grasp of what you can achieve with just using files and folder, or understanding how SQL solves en entire problem space are meta level concepts. Its just that we take them for granted.
> business value
Is apparently something different than 'value', but still includes every software ever that was valuable to a business?
> high level details
...?
> software engineering
Building constraint solver for a compiler or ensuring a JS animation centers a div?
> highly theoretical and focus on abstractions, design principles
I'd recognize all these things. But out of context 'in the general case' they become meaningless.
---
I understand the picture you are trying to paint, but i don't think it tells anything beyond "I've noticed people make things overly complex". I agree.
However, keep in mind the 'get things done and provides value' software you've seen: is the software 'that survived', might have been set up by a very experienced person ( whose failures we're not seeing ), nobody might recognize it as being not-simple ( e.g. I've seen high value business software partial recreate 'regex'. Worked great, straightforward and easy to read function, just ~50 lines or so, could have been a single function call. ), how the requirements are presented is hugely important.
I think no one was writing about ones who master specific language.
There is a lot of people who learn just a surface without going deep into tool and think they know enough.
For me it seems that someone who would really go deep into learning language would get most of theoretical stuff on the way. Because there is no way to really master C++ or really master Java without learning about data structures and all kinds of "meta-level" concepts.
Maybe the difference is mostly approach to learning more practical/more theoretical.
I understand the concept here but there is also a level of right tool for the job.
Some guys see a screw and reach for their trusty hammer. Some guys know to grab a screwdriver.
I had a project the last two weeks where the code was just going to fail about as often as it was going to succeed. I had to write a resource manager and an Erlang style supervisor and use an embedded key value store.
A better dev may have intuited what took me basically a midstream rewrite to figure out, a worse developer may still be grinding on the problem.
I think my solve is "robust enough" but there was no real way to power through that. You either found the right abstractions or you didn't.
Not to be rude, but did you finish reading the article? The whole point was that high-aptitude learners give up. In fact I don't agree that re-learning the same tasks over and over with the zillionth framework iteration is a rewarding learning experience. It makes perfect sense to change careers instead.
And as music goes, you sound like the record companies that thought everyone should listen to disco for the next 50 years...
As I’ve gotten older it’s harder for me to learn an entirely new area (like say going from web dev to mobile or ML). But it’s actually easier to learn a new variation of something (like the latest JS framework) because it’s usually pretty similar to one of the things I already know. I guess this leads to increasing specialisation, but it also means studies that merely count “new skills” will be misleading if they don’t differentiate in which way the skills are new.
I'm the complete opposite. Hand me a new JS framework that does the same thing I've done a million times but have to learn it's opinionated abstraction set that's somehow better and I just turn off. I simply do not care, at all. You need to simply explain to me the improvement you're proposing or it might as well be trash to me.
Now give me a new theoretical concept where I can expand my knowledge or integrate into my knowledge map and view of the world and I'm excited, there aren't enough hours in the day. Tell me about this all new concept I wasn't familiar with--I'll start thinking of ways I can use it, how I can leverage it, or how it may connect with other ideas and concepts I have.
Now give me a tight deadline which most business environments create and I agree with you, give me the boring stuff I can pump out, get my paycheck and go home to enjoy the rest of my day.
> No doubt the people who choose to stay in software are likely to be people who are curious, life-long learners
The article showed the opposite effect though. Curious, life-long learners stop working in software development because they have to constantly learn new skills and believe they can get more bang for their buck when they can invest in skills that don’t lose their value over time.
I once got excited about ExtJS, the way it created a desktop-like experience in the browser, and I said to myself, "I will learn this, all of it, I will become an expert. Tips and tricks, best practices, the works".
After six months of this, ExtJS 4 came out, which was essentially a totally new framework. Everything I learned was not only not applicable, it had to be actively unlearned.
The lesson here is: become good and proficient at something, but don't focus on becoming a ninja in one particular transient tech. There is value in becoming a Jedi of Unix build-in tools, or more persistent technologies like Git, for example.
Also, this is a bigger problem in the Javascript echosystem, where the hype cycles are more intense than in, say, Python. I checked out my Flask project from seven years ago and it's ready to rock.
I get the thing about constant learning, but learning in this industry used to be cumulative. Now it's a hamster wheel. You are learning how to solve the same problems, in a different, presumably in a "new" way.
People seem to be spending more time coming up with catchy names for their projects than making sure this is all sustainable.
Yes, this is how I feel. I have no problem learning a new skill. I get discouraged when I learn a new skill and just when I start to get really comfortable and productive with it, it's suddenly "legacy" and some new thing is popular.
The only skills that have really stood the test of time for me are C, PHP, unix shell stuff, and SQL.
It's a mix of both. You need to have solid fundamentals and need to keep learning new ways to apply those fundamentals in the real world. There is absolutely effort involved in learning a new language, library, framework, platform no matter how good you otherwise are.
> I noticed from teaching computer science while a graduate student is that the poor (a) students think about languages and libraries as key skills, while the (b) better students think about the data structures, algorithms, and design principles.
The truth is that the programmers in group (b) think about both. Who's designing a lot of the new languages, libraries, and frameworks? Chances are it was someone from group (a). If you're in group (b) then do you want to spend your whole career being forced by your bosses to constantly relearn and follow the latest vogue vision from group (a)? Of course not. So this might not apply to students, but everyone from group (b) will eventually get burned by fads enough times that they start caring about the politics of software. Namely, not wanting to depend on bloat that doesn't actually solve computer science and systems engineering problems. Group (b) might even create alternatives themselves. Go is great example. The guys who built the Fifth Bell System watched their vision behind their techniques decline over the decades and said, enough is enough. So they made Go and it was like a ray of sunshine when it came out.
I actually find the model in the article pretty convincing despite agreeing with you on that it's a profession for people who like to learn knew things and that university/grad school should teach more generic, theoretical knowledge that depreciate slower.
However, these still don't invalidate the main point of the article, that a faster rate depreciation means that your max knowledge level, given your specific rate of learning, will be lower. I.e. your advantage over a less skilled, younger professional will be lower.
And you may say that learning a new 3D library shouldn't be counted as learning a new skill, but it doesn't make the problem go away. If anything, it underlines it: if you have to start working with a new 3D library then you will have to spend time and effort on learning it (to become efficient at using it) while if you were able to keep using it, you could spend that time and effort on learning something that we could count as a new skill.
The article is also hitting on the fact that your skill premium as an engineer has a cap, and so does your willingness to burn the midnight oil on a project. This means that as time goes on, as an engineer you'll face the following
- A younger engineer will have the same value to your employer as you do.
- A younger engineer will work harder than you are willing to.
These two items are inevitable given the current rate of change in the industry. While some engineers will find next level differentiated work to engage in such as leading a core piece of infrastructure which defines the changing field... Many will not. If the rug gets pulled on this core piece of infrastructure.. then it's often the case that the engineers are not particularly more skilled than others on brand new projects.
Well, that's not what the data is showing. Why are you trying to create a narrative that is not trying to explain what we observe? Smarter people leave the field earlier and the author offers a compelling explanation why.
> When teaching undergrads I noticed immediately that a good portion of each student cohort was basically there because they were interested in making money in the future rather than exploring the ideas of computer science.
In my school, those who wanted to make money went straight to management or finance. Computer science was for the passionate ones and probably not the right path to make money for the brightest students.
> the poor students think about languages and libraries as key skills
well so do the recruiters, they’ll be fine
in fact, the better students are the ones wasting their time unless they prefer to be in academia, like you
so what metric are you really gauging for?
the “poor students” are pivoting for money and the name of the university to boost their employment prospects, maybe this shows in their academic performance and ability to understand, I saw the same in undergrad
> they are correct that we are in a dynamic profession that requires constant learning and expanding
Not true. I have met many developers who haven't learned anything new for 15+ years and are still doing just fine developing software. A lot of Java developers come to mind. They have pretty much done the same thing their whole career and have no need or desire to learn anything new.
Once you understand how the industry churns and burns and doesn't really give much credence for capability as you age - it becomes disheartening to try and want to be an IC. Most people see the writing on the wall for being an older IC therefore they move into management or product or other roles.
A fascinating premise, and matches what I saw as an engineering director. The best just get bored and move on.
I think many teams are unaware how much extra value is possible by retaining existing employees vs hiring new ones. Each year I'd try to make sure I was "making them an offer they couldn't refuse" with new interesting challenges, new tech, plenty of personal research time, as much pay increase as I could possibly give, etc. A lot of engineering managers think that it's no big deal to just hire new staff, but even going from average turnover of two years to three years is an massive improvement.
its not just the best ones. If you remove people from the grind for 1-2 days a week, give them a small budget and enough autonomy to do what they want, most people will fix shit that bugged them for a long time.
The main problem is how micromanage-y the current development processes are. Everything has to be a ticket/user story and has to be planned and approved by some people that never even wrote a single line of code. Everything has to have some immediate business impact. I even see scrum teams measuring for team utilization now. target is 90% atm and they wonder why productivity is down.
> If you remove people from the grind for 1-2 days a week
The modern office seems hellbent on killing every last bit of slack in their workers, then wondering why they leave or get burned out.
I realized the other day that a big part of my drive to move towards self-employment is really just a way to carve out time to take adequate care of myself. I have significant doubts that it is possible to continue to advance in tech to staff+ levels, be a good spouse, parent, and friend, and not run myself into the ground with physical/mental issues. And that is sad on multiple levels.
So I respond by easing up on advancing my career, because it gives back to me the least.
It gets worse, too - as long as I've worked as a software developer there's been some sort of time tracking system in place, and it has to be planned up-front, and has to work out to at least 40 hours (after they "negotiate" your estimates down). Which leaves no time for the unplanned stuff that inevitably comes up. This always goes in a cycle like this:
1. Management demands that every bit of work be associated with a ticket
2. devs just open tickets for the unplanned stuff so that it shows up in the ticket tracking system
3. management complains about devs opening "their own" tickets and prohibits self-opened tickets
4. devs do the unplanned (always "super high priority!") stuff without any ticket tracking and fall behind on their "planned" tickets (that nobody really cares about any more, but are still on their board)
1. management demands that every bit of work be associated with a ticket...
I've dreamed about a 20% policy like google had, except it's where you can work on anything, including code debt.
I've tried to stress to managers in the past that developers feel the pain of code debt. It makes us slower! Enable us to spend time sharpening our tools and managing our codebase.
One problem of course is, not all SWE can do this well. I wouldn't necessarily trust a junior hire to recognize and execute a proper refactor.
> give them a small budget and enough autonomy to do what they want, most people will fix shit that bugged them for a long time.
This has been huge for me at my current job. I saw some unused equipment in a lab and started asking questions why. Turns out the thing worked, but not great, so no one used it. What started as just fixing bugs and adding features became my own line item in the budget and requests for the (new and improved) equipment from other departments. It's something I look forward to working on.
That reminds me of the time I was a junior dev, and the team lead told me verbatim: "I know you are too busy to write tickets, but can you take some time off [this urgent thing] to do that? Thanks!"
This was after they encouraged a certain "cool culture" for a couple of months due to the lack of direction. It was pretty funny that I did not only get micromanaged, but was told I did the wrong thing, and then asked to do a third job that was not my responsibility.
We have a lot of bugs everyone complains to me about and I have sufficient downtime to fix them* but I have to go through drawn out planning, UI, UX processes before I can even start. I just don't bother any more.
And yeah, it's definitely not just the best ones. I am mediocre and am so bored and so done with dev.
* the downtime is there because I am waiting for planning, UX, and UI for a different high priority task.
> Everything has to have some immediate business impact.
Or more specifically, explainable business impact.
But it's hard to explain how the code has become horrible and needs a refactor to makes it easier on devs, reducing stress, reducing likelihood of both bugs, and developers leaving.
It may not be a matter of "the best". I have taken a personality test that had an item on it that covered product lifecycle. If 1 is initial conception, 2 is prototype, 3 is initial release, 4 is major enhancement, and 5 is maintenance, my personality is that I prefer 2 or 3. By 4 (major enhancement) I start to get bored, and by 5 (maintenance) I'm definitely bored.
It's not that I'm one of "the best" (though I like to think that I am). I have a personality clash with the later stages of product lifecycle.
Is that the premise? Seems to be saying that constantly changing skills exhausts developers to the point that it becomes more lucrative to work in another profession.
Although, I suppose learning new things just to tread water can be boring too.
This is how I read it too. That a fast learners skill is degraded in a field that is constantly reset (software dev) vs one where you can stack knowledge. And thus the fast learners will eventually leave the software field and transition to one that doesn’t reset constantly so they can stand out more.
Doesn’t have to do with boredom so much as maximizing potential.
To be fair, almost all my managers were amazing, people who truly cared about their staff: at professional level as well as a personal level.
I've only had one absolute psychopath as a manager ... but I should thank him because he was the last straw and gave me enough courage (and anger) to leave AWS and start my journey as a solo entrepreneur.
Oddly enough I joined AWS not too long ago and while the job itself sucks, my manager is exceptionally awesome. In fact I only interviewed with AWS as kind of a half-joke, but he was so likeable that it convinced me to take it seriously. He has a healthy "fuck em" attitude when it comes to pressure from outside the team, so he's constantly protecting us in a multitude of ways (e.g. during on-call rotations or deadlines being imposed on us). He has yet to do a single thing that I would consider micro-management.
I think for some engineers (me) there's not much you can offer. I don't just want any new random tech challenge. It's unlikely your company or most companies have something I could truly be passionate about solving.
Literally every engineering director I've ever seen says exactly what you're saying. E.g., "as much pay increase as I could possibly": for my experience and growth, an employer I worked with offered a -6.6% increase in real salary for my time there. (≈3 years tenure.) Negative. The work was also … not what I'd like to be doing. So between "stay with company" and "find different company", it shouldn't be too hard to predict which option was more appealing.
My experience, unfortunately, is that good managers like you seem to be don't last long. They get replaced by manage-up sleazeballs who'll never, ever protect the people beneath them because it's not game-theoretically optimal.
The thing is, executives measure themselves by how quickly they get promoted into the next role, so no one cares that good management might reduce turnover in the next 2-3 years--in fact, the executive mindset is that it could just as easily increase turnover (what if we invest in their careers, and they leave?)
My philosophy as an engineering manager is to actually pursue this outcome. If I treat them badly they will leave. If I treat them well and train them into better engineers then they will leave. It's like being a college football coach. Having your star athlete be drafted to the NFL is entirely the point.
There is no shortage of swe. What I see and what I have experienced first hand is that companies, especially the more hyped/small ones, pretend to be FAANG and gets very picky when interviewing. They often employ FAANG style interview.
Now, if I really have to spend that much time prepping to interview at your unprofitable company (that most likely will go under) don’t you think that I would try my best to work at faang instead ?
As matter of fact, I was rejected at plenty of these small insignificant companies, but end up having offers as L6 at FAANG.
Be humble and you will find plenty of good engineers out there.
I know tons of good swe that don’t want to interview/ work at mega FAANG, and if I was running a business I would definitely try to attract those talents by being different. Offering a “normal and reasonable” interview process along with better perks, flexibility and wfh.
Instead, they all want to run bizzilion of micro services in k8s
I definitely think "we do not do leetcode interviews" and maybe "we only have three interviews total" would be selling points on a job posting. People who are experienced in the field don't want to go through the same hoops that newbies do just to prove they know how to write basic algorithms.
You wrote: <<People who are experienced in the field don't want to go through the same hoops that newbies do just to prove they know how to write basic algorithms.>>
I am constantly interviewing candidates for roles at my company. It seems like CVs are a complete gamble. Either some are lies, or wildy understated, and everything in between -- at all levels of experience! "[J]ust to prove..." and yet so many can not do the 2022 version of FizzBuzz. I am stunned how many senior (well, so they say!) hands-on technical applicants cannot do basic things like write a very simple linked list class, or explain to me how a hash map works. For get about explaining the finer points of sorting algorithms (honestly, very low value in my line of work).
There is no reasonable alternative to testing of some kind for hands-on techincal roles -- I am flexible about method: (1) white board coding (ugh in 2022), (2) IDE/text editor on shared PC / video chat (meh / eh in 2022), or (3) take home (the best in 2022, even if there are drawbacks for people with families).
Joel Spolsky said it best about hiring: The goal is to avoid bad hires. Average and above are fine.
Personally I do because I enjoy working with very smart people.
The backlash against leetcode is the same as backlash against other types of tests: most people are going to fail and most people don't like failing, so they blame the test.
> "we do not do leetcode interviews" and maybe "we only have three interviews total" would be selling points on a job posting.
It depends on the job. I have had interviews that broke the mold here and were panel discussions or more job-talk experience, and I found the interviews uniquely exhausting because they required their own set of skills to study for that were different from the “leet code” style. At the extreme end were the take home projects, which I simply didn’t have time to do for every company and were extremely unattractive to me for that reason. I actually find doing leetcode style interviews for me required the least amount of prep and was the most straightforward, especially when they were structured to leave me with time to ask and talk to real engineers at the company.
> Now, if I really have to spend that much time prepping to interview at your unprofitable company (that most likely will go under) don’t you think that I would try my best to work at faang instead ?
I feel the same way.
That said, my company and many others make the interview process much easier but still find it difficult to hire. I know this is a common problem, because I get bombarded with good job postings by recruiters and they are usually still there months later when I finally get around to responding.
Companies have only tested my code skills and handed me personality tests when applying for full time jobs. As a freelancer, I get one or two interviews where I talk to the architects, tech leads and managers, and that's it - either I'm in or out after that. They end up treating me as an employee anyway, so don't really know why this distinction is made in the first place, but I suspect HR.
I don't think FAANG style interviews are a good way to do it, but it is more important to be picky about hiring at a small company. If you're in a company where everybody knows everybody, then any new hire will affect the entire team. A good hire will pull the whole team up. A bad hire will negatively affect everyone.
>High-ability workers are faster learners, in all jobs. However, the relative return to ability is higher in careers that change less, because learning gains accumulate.
This is not the only reason for the quick learner -> high dropout thing. By the article's definition, I'd be a "fast learner". Most of the industry expects me to come in already knowing what they want me to know, while most ways to obtain said knowledge are blocked by barriers difficult to bypass for non-corporates. Meanwhile, almost every corporate I get in expects me to do the same things for several months and gives me a few learning opportunities every year. At the same time, university primed me to absorb knowledge like a sponge and never get stuck on a single perspective, while corporates are complaining why graduates don't know Spring after graduating.
So somehow you're expecting me to stay while my knowledge deteriorates unless I keep it up in my own time, all the while giving lowball raises and not satisfying my desire for challenges. Yes, I get it, grunt work has to be done. But you really can't tell me you're in need of software developers when you actively push people to do the very thing you claim you don't want them to do.
"somehow you're expecting me to stay while my knowledge deteriorates unless I keep it up in my own time, all the while giving lowball raises and not satisfying my desire for challenges"
That's not really the expectation... the expectation is that you'll be replaced by someone younger who's already learned all that.
The expectation for more senior people is that they'll go in to management or architecture.. or maybe burn out.. it doesn't really matter to most corporations, as their workers are replaceable.
This is spot on, and personally, the main reason why I decided to move to an engineering manager after 10 years as a developer.
And even as an engineering manager, I do not feel safe. I think only once you reach director level, you are protected from market hype and newest frameworks trends.
This. Slap the golden handcuffs if possible for the most boring work and give employees extra vacation time to recover from that slog and they might not leave. Most people are willing to deal with some BS as long as they feel compensated and the comp keeps up with changes in the marketplace.
Some really good points on the ultra-fast depreciation of SE tech skills. A relative of mine is a mechanical engineer, well past retirement age and still going strong in his 2-man consulting shop because that's what he loves doing. He works with precision manufacturers, automotive suppliers,... all very cutting-edge stuff, helping them develop new product lines, manufacturing processes,... He says the core skills that he's using are still those that he learnt in university several decades ago.
I was actually surprised because I heard so much about crazy new materials like carbon fibers, graphene, technologies like 3D-printing,... but apparently what makes a machine break are still the same things: mechanical stress, heat dissipation, friction,... new materials and processes might change the coefficients, but not the (mostly Newtonian) physics (my interpretation btw, not his words).
One could say the same thing about software engineering - true fundamental advances in algorithms and data structures are sufficiently rare that it wouldn't be a nuisance to keep up with them. But the %-age of how important those basics are relative to the extremely fast-changing landscape of tools and frameworks is much smaller (plus, one could argue that even the fundamentals see a lot of shifting ground in CS, with neural architectures, differentiable programming, not to mention quantum computing).
I think the skill depreciation concept is a bit exaggerated. Especially in the context of the newness of computers relative to the engineering field in general, the latter which has been around, arguably, for thousands of years.
For example, SQL & Unix have been around since the 1970s.
Linux since late 1991.
Javascript: The end of 1995. NodeJS: 2009.
Sure, there's a ton of churn in the JS Ecosystem, but all it takes is a bit of wisdom, skepticism, and patience to avoid the hype-cycle.
Also, once you learn to build certain things with a programming language you learn the paradigms of the system you build.
For example-- Web Servers. Looking at ExpressJS vs Python Flask documentation, there are many analogous pieces, because they follow the same standards for protocols.
Another example-- data engineering / statistical computing: Checking out R vs Python packages, there are a lot of the same concepts, just in a slightly different format/language.
HTTP/1.0: 1996 (RFC 1945)
TCP: 1974 "In May 1974, Vint Cerf and Bob Kahn described an internetworking protocol for sharing resources using packet switching among network nodes."
"TLS is a proposed Internet Engineering Task Force (IETF) standard, first defined in 1999"
Considering all of this... I don't think most major things actually change that much. Sometimes a popular new framework takes the world by storm, but that's pretty rare compared to the output and churn of the ecosystem.
The issue is that every job I’ve had requires learning a bunch of new shit. Rarely am I just transferring over to the same languages or frameworks. Add on that each company decides different design patterns that they want to utilize and has a different interpretation of what REST is and what HTTP status codes are… it’s a pain in the ass to be an expert in any good amount of time. Expert being one that can dive into the true weeds like cryptic memory leaks that require special profiling tools that aren’t documented anywhere - etc. (and able to do this at a moments notice with ease)
Especially if you’re a full stack eng who is constantly swimming over the entire stack and they keep pushing new DBs, new logging tools, etc.
There are commonalities but it is a lot of learning as you go. I used to know Angular pretty well but now I don’t remember it at all. I haven’t even gotten to really ramp on React as much because my company uses it in such a terrible way that it’s clearly not fit for.
From the perspective of whoever is experiencing it, it doesn't really matter how it fits into the historical picture. What you experience is sitting in front of your screen while your family is having dinner, not points on a multi-decade timeline.
In the last 20 years I have seen mostly ultra-fast depreciation of SE _interviewing_ skills.
After the first ten years software development becomes quite intuitive and you internalize all those best practices. You can be trusted to start a new service from an empty git repository. Later it gets incremental, there's a lot of path dependency in languages and frameworks and few things come out of the blue. Those that do are frequently intellectually stimulating to learn.
But interviews have been steadily getting strange and difficult (in a way not related to real life software development), at least in the last 10 years.
Very true. This stuff started at places like Google and Facebook and it makes a sort of sense for them as right or wrong they're very focused on hiring new college grads. With no real work experience to speak of you can do a lot worse than hire the ones that show they can apply their CS coursework to leetcode problems.
But doing the same to workers with 10 years of real world experience doesn't make nearly as much sense. Like hiring medical doctors by quizzing them on organic chemistry problems. Google and Facebook do it because they can and they don't know what else to do, but I don't understand how it became a universal practice.
>I was actually surprised because I heard so much about crazy new materials like carbon fibers, graphene, technologies like 3D-printing,... but apparently what makes a machine break are still the same things: mechanical stress, heat dissipation, friction,... new materials and processes might change the coefficients, but not the (mostly Newtonian) physics (my interpretation btw, not his words).
I don't really see the difference between that an programming. Writing code is still a bunch of "if" statements, the same underlying data structures, same algorithms, etc. There's some new technology being added on the top akin to carbon fiber and the other things you mentioned but it's fundamentally the same.
You really think that a SE in their 70's who learnt how to write if statements and data structures 50 years ago would say that they're still basically doing the same thing now as back then? Maybe if they work on legacy stacks like the famed COBOL devs coming back out of retirement. But the thing is that what he's working on is cutting edge, not maintaining systems that were built decades ago.
An unsolvable problem. The rapid deterioration of skill will not stop, it is accelerating instead. People's desire for stability as they grow older will not change either.
The only attraction in software development is the relatively good pay. The job itself sucks. You'll spent your life sitting in a chair looking at a text editor, and that's the best part of your day as about 50% of it is distractions. You're quite unlikely to work on something truly creative or thrilling, so it's mostly a boring grind.
Then, as the article mentions, it turns out the grind was for nothing and the rug is pulled every few years and you have to start over again. The job is cognitively taxing so you'll turn into an absent person that lives in their heads, it drains your life energy.
If I would be young now, I'd say fuck it and go install solar panels or heat pumps. It's outside, physical but not too physical, thus healthy. You get to meet lots of people and you see the direct result of your work. There's no office politics and you're contributing to a tangible good thing for the world. Skill requirements don't change much.
You might come home somewhat physically tired (but over time it normalizes), with a clear head and not a care in the world. There's no overflow between work and personal life.
You go to different places and different people, every single day. That's 100% less repetitive compared to sitting at home or going to the office to see the same people.
As for the tasks themselves, it was merely an example, but even for this example I disagree. My brother-in-law basically does all of these things, both for private citizens and industry and comes across a wide array of different situations.
I'm not saying it's absolute perfection, no job is. But I stand by my point that it has a series of very meaningful advantages: far healthier, more social, direct impact of your work, no cognitive overload, no politics.
Go ask people installing solar panels and heat pumps if the idea of working a "cognitively taxing" job where they could make more money, work from anywhere and not be dead physically tired at the end of the day sounds appealing... I don't think you'll hear them all say "screw that, I love installing solar panels". The grass is always greener for sure, but none-the-less software engineering and tech offers a very high quality of life with significant earning potential and a ton of flexibility.
> If I would be young now, I'd say fuck it and go install solar panels or heat pumps
Amen. For me the advice I give the young—-go for a trade. HVAC (especially if you live where it’s hot) and plumbing to me are the most future and recession proof jobs there are. Literally by the time other folks are graduating with CS degrees and massive college debt, you have been making 70k a year for 3 years and are about to clip 6 figures for the rest of the time you want to work.
One day a computer will be able to write its own code (and that’s not that far off now), but no robot or computer in this world will be able to come to your house and fix a clogged toilet, or replace a blown capacitor in your heat pump and people will always be willing to pay nearly anything to get those two problems replaced.
Unfortunately, this is also a low cost skill to acquire, so the barrier to entry is low.
As all the mid level white collar jobs keep getting automated away, there's going to be a glut of people in need of income who are more than capable of learning a trade if their ego can handle it.
It's not so much a desire for stability in general rather than the depreciation. I found that piece in the post rather convincing. I don't think most people have a problem with learning new skills in this field. But having to throw away old ones sure feels like a waste and given the model in the post limits how good you can ever get.
Also, sitting and staring at a text editor should not sound that awful for anyone who likes to create via writing code. Because that's how you do it. But that's not what you experience, obviously. It's about what goes on in your head.
I remember the feeling after taking a new job as a fresh graduate. It felt ridiculous that I know get paid for doing the thing I've wanted to do most of the time in the past ~12 years but I was told that you can't do that all day because you have duties. (Now the pay was actually pretty bad, even for local standards, as my first job was in an academic research institute.)
I think the problem of ageism wasn't mentioned at all and it should be.
People who love the field have no problems keeping up to date. Sure some job posts will mention Hadoop or Kafka but whatever, a good dev will have no problem learning these in a few days.
Does he get a chance though if he's 50?
Ironic thing here is that Hadoop is mostly already outdated.
Which is btw one of the depressing thing for a lot of data engineers: we used to play with those cool distributed processing frameworks, and now? We are mostly writing some terraform to deploy cloud resources, most of the distributed part being handled by those cloud providers.
> Which is btw one of the depressing thing for a lot of data engineers: we used to play with those cool distributed processing frameworks, and now? We are mostly writing some terraform to deploy cloud resources, most of the distributed part being handled by those cloud providers.
Sounds to me like switching one provider/tool by another - or are data engineers feeling bummed because the job has become too trivial / less fun?
I'm not disputing the fact that there is ageism, as I'm sure there are thousands of examples of it, but there's so much demand and so many different companies. I've worked with plenty of over-50's. Maybe there's a sweet spot for growing companies where you need the experience, which has been where I've worked. Small companies don't need structure, and maybe want cheap employees. Large companies put all that structure in management and a few super senior folks. (though I saw plenty of over 50s in my large company experiences) Medium growing companies need experience. I dunno, just guessing since certain companies I've worked for seem to have a higher concentration of older folks.
Here, this rando website says that 46% of software engineers are 40+
That's a survey though, I'm curious what biases are going to exist in the data. We might assume that older software developers move around less? May be less likely to respond to surveys? May be less likely to visit stack overflow, especially if they do less hands on coding?
I'm with you, I don't know the answer this is definitely complex.
It could be a combination of things -
a) burnout due to ever changing tech
b) ageism
c) highly paid devs choosing to retire / switch professions early simply because they can financially
40 is definitely not that old anymore for tech I think. Well I'm 38 I'll find out soon.
There should really be a surplus of software developers. Most companies are solving problems they don't have, employing a team of 10x more developers than they need - because of course microservices, Kafka, Kubernetes, you name it - cargo culting the shit out of it.
I feel like the need to continuously learn new things is a feature of the profession, not a bug. It is certainly a difficult challenge, but I've always felt that the most important trait in a software developer is an eagerness to learn new things.
I think the overall premise of the article makes sense, but where I differ from the writer is in how I view the need for constant learning and self-development. The author writes,
> Like a fast, expensive car that quickly loses value as it's driven around town, the skills and human capital of software engineers fall apart without constant, expensive maintenance.
What the author is talking about, however, is not a material object with transient importance to one's life (i.e. a vehicle), it is your mind. Learning new things doesn't just mean you retain your relevance as a software developer, it also helps stave off cognitive decline. It keeps you sharp, relevant, mentally agile. That may not be the case in every job, but the field as a whole certainly has that attribute.
> the opportunity cost of working in a rapidly-changing field is highest for the best learners
It's not that learning is an unattractive aspect (I agree, it's a great feature!). Instead it's that it levels the playing field between those entering the profession and those that have been in it for many years. Yes, you still have "experience" as an advantage, but you can't say you've worked with LATEST_TECH for many more years than someone coming out of college.
Contrast that with other professions, like law, or medicine. Where it's not just "experience" working in your favor. But actual knowledge of the existing laws and medical practices.
That's an excellent point which mirrors my experience as well. My parents are both recently retired civil engineers one which was working for the government/city, the other in a private company. Both very valued in their professional circles, and even outside just because of their reputations.
I've never seen them at home reading a law, bylaw or a "teach yourself how to design a bridge in 30 days". Whenever something changed in their profession (very rarely) be it law or similar they went to seminars about it. Some of the time they (or their "guild") were even consulted so that stuff ended in the law itself. Something really new in the industry (say some software tool or whatever), the company paid for the trip, and the training. The older they were, the more compounding experience and knowledge they had. With each year they were worth more to their respective companies.
Contrast this to my current company (previous were even worse), where my boss proclaimed that all new infrastructure is going to be in Terraform (I had no problem with that, but zero experience), hired a new guy almost straight out of school with 1.5 years of TF experience (and absolutely nothing else from what I've found out later) with much better pay than the rest of the team. Oh, and he said he'll expense us any TF book we want to buy. So here I am, on my 2 week "long" vacation reading a fat book about some technology X which we'll be abandoned in couple of years time.
> Contrast that with other professions, like law, or medicine. Where it's not just "experience" working in your favor. But actual knowledge of the existing laws and medical practices.
In my experience knowledge decreases very fast if you work in a programming job (exception: if you use an insane amount of your free time to avoid this decrease).
> I feel like the need to continuously learn new things is a feature of the profession, not a bug.
The bug is in our brains. After two decades, you are not the fast learner you were, especially after you manage to fill your clothes with keys traded for responsibilities.
Realizing that is a source of mid-life crisis. Trust me, I've been there.
Also: you're learning the same thing you already learned several times before, except slightly different this time. Things are no longer as exciting as when you learned it the first time, and especially if $new_thing isn't a fundamental improvement over $old_thing, or even worse (in your view, whether that view is correct is another matter) it just becomes a slog.
I found that excitement/motivation is pretty important in actually learning new things. I'm close to 40 now and don't find it's harder to pick up new things when I'm motivated. If anything, I find it easier as I have a broader background knowledge and spend my time more effectively – I didn't believe my teachers when they told me that taking notes helps you remember stuff but they were right and I was a stubborn idiot. All of that offsets the undoubtedly decreased ability of my brain compared to when I was 21. It's just that I've done a lot of things before and find it hard to motivate myself for "$new_thing that's fundamentally just like $old_thing building $new_app that's not really any different from $old_app".
Agreed. I hire interns every year, and I am continually astounded at just how incompetent so many people are who are months away from finishing a master's in computer science. On paper, I wouldn't expect a shortage of software developers. But as a practical matter, more than half of everyone I talk to who is about to finish their CS degree is very clearly not going to last long in this field. Not just because they are incompetent, but because software so clearly doesn't interest them. Right now they think the salary will be enough to keep them happy. Think again.
> so many people are who are months away from finishing a master's in computer science
Because by hiring masters degree interns you're not exactly scraping the cream off the top...
Masters degrees in Computer Science -- unless used as an immigration thing -- make no sense.
The make no sense for the research route -- in CS in the USA, you go straight to a (zero tuition + living wage stipend) PhD from undergraduate. No reason to pay for a master's degree.
The make no sense for the SWE route either.
Masters students are mostly in it for either a domestic degree or because they couldn't find a (good enough) job out of undergraduate.
Most departments know this and treat their MS program as a total cash cow.
I've always considered Computer Science to be a distinct field from programming (or "Computer engineering", if you will). I mean, a brilliant particle physicist does not necessarily make a good engineer, an astronomer doesn't necessarily good telescopes, and a cancer researcher doesn't necessarily make for a good GP.
Not that these people automatically lack the ability to do these things well – some do, some don't – it's just that they're different fields with different training, mindsets, interests, etc.
Where are you from, if you don't mind sharing? I believe it depends on the education system. From my point of view in France new grad need 1 to 2 years to be "work ready". They just have to learn how work life is working.
I suspect it's a result of the bucket being wider and larger - many many people have latched onto the idea that "software" is the way to make lots of money, so people are signing up to learn it.
In the past CS (if there even was a CS degree/course offered) would me mainly populated by "the nerds" who were really into it, money be damned.
Arguably this could be why the educational requirements around other well-known lucrative positions became so difficult.
I think it's time to start separating what is a software developer.
Is a software developer someone willing to learn new languages and uses software to solve problems? Or is a software developer someone who knows latest.js and writes front end code or someone who writes C code to makes the LEDs on the machine blink.
There are two opposing hiring methods:
* hire for positional skills
* hire people not positions.
At a smaller scale, maybe you need to to just be a flexible person who can do anything. But how many start ups are going to hire a 35 year old C programmer to do js front end, or type coffee script? Yes that's 35 year old may have learned a lot of lessons along the way, but at their stage in life they're also going to likely cost you more and in all likelihood have more responsibilities outside of work.
Myself, I'm a generalist. I have programmed all levels of the stack. Consequently though, I can't claim deep mastery of many specific areas that a lot of "skill" positions require. On the hire "people" not positions, perhaps I can fulfill those roles but in doing so, as I become more senior I leave a lot of my skills sitting in the toolbelt to do a narrow software task (at a mega corp) and my lifestyle isn't well suited for the grind of startups (many many hours). Sometimes feels a bit of a catch-22
> Is a software developer someone willing to learn new languages and uses software to solve problems? Or is a software developer someone who knows latest.js and writes front end code or someone who writes C code to makes the LEDs on the machine blink.
Yes. A software developer is someone who develops software.
I got the impression that there is much less of this in lower level languages. It seems like there is a fairly stable foundation of C, Cpp that everything else is built on top of. I wonder if embedded programmers have this problem.
> I got the impression that there is much less of this in lower level languages.
Not only the lower level languages, but fundamental skills in general, I think. Undertanding the computer from the hardware level, OS level as well network protocols, filesystems etc tend to continue to provide benefits even if one fashionable technology is replaced by another.
Similarly, fully undertanding algorithms, data structures, design patterns and architectural patterns also generalize, provided you DO understand these concepts with their strengths, weaknesses, and when to use them and not use them.
If you have the skills above (+ some math and general troubleshooting ability), you are able to approach most software/compute problems from first principles. If so, you may find that you are able to take up senior roles even involving technology you have not used before, as long as the tech introduces few new fundamental ideas. (And if there are new fundamental ideas, you need to learn those to keep up, but such ideas arrive much more rarely than new tech).
People who do not learn these things from first principles, but instead are memorizing patterns they learn from other people, have to do a lot of new memorization when new tech becomes fashionable.
Not only does that take a lot of effort, it also makes it unlikely that they will be able to identify antipatterns by themselves, and it may cause them to end up trying to use the new and fashionable tech in ways it is not suitable for.
This is what I’m hoping for. At least, I’ve noticed on the admin side that lower level tools and system calls seem to be more stable and better documented than the abstractions built overtop of them.
I think market pressures make this a difficult fit in the workplace. High turnover (~2yrs) and larger systems encourage shorter term results with a shallower understanding.
This isn’t a criticism (I have so so much to learn still, I’m in no position to judge, nor do I want to be), but more of an observation. Balancing learning churn(frameworks/languages) vs fundamentals(theory, concepts) is a struggle I think I will have for the rest of my life.
>If so, you may find that you are able to take up senior roles even involving technology you have not used before, as long as the tech introduces few new fundamental ideas.
But will you be hired for those roles? Not that many companies will do that I think.
From an outside perspective, as someone who does embedded development as a hobby rather than a profession, the answer is both yes and no. The stability of C and C++ helps, but you still have some churn in libraries and you almost certainly have to deal with vendor specific libraries (which makes moving between vendors difficult). Trying to bypass libraries doesn't really help on that front, since you are simply trading of churn in libraries with churn in microcontrollers.
In my experience it's the opposite problem. Advocating for modern development practices or languages (even unit testing, let alone Rust) for embedded projects is hard work. Most new embedded projects, even today, are written in C or C++.
How does the language matter? I write software (mostly) in C for a living (the simple man's "embedded" as in "Linux on an ARM board", not the "bits on a micro controller" kind) and I made sure we use test-driven development with proper version control and CI.
We have been trying to use Rust for some new projects but cross-compiling is still much more hit-and-miss with Rust (i.e. third-party libraries) than it is with C. I imagine it would be worse for proper embedded projects.
I have the same experience. I cant event get people onto github. We spend thousands a month trying to keep our international teams connected to our local servers and they still have to zip up the project and send it to me over teams.
The turnover problems saying that relative wage advantage declines? Their chart on a log scale shows that the wages are still really high compared to non-CS jobs. A more likely interpretation is that junior programmers are for whatever reason highly paid in their sample. Those error bars are suspiciously tight, so there's a good chance their sample is biased.
The selection problem data? First, they're missing a plot that shows that the same correlation (higher AFQT scoring individuals are slightly more likely to leave the field) doesn't hold for other majors/fields as well. Second, is the AFQT psychometrically valid when compared across different age groups? Third, is their sample valid here at all? It wouldn't take much bias to make these correlations disappear. The super bright principle engineer is probably not going to take the time to sit an AFQT and be part of this.
Then we have weird assertions without citation like "Some workers, endowed with superior ability, learn faster than others, picking up skills at a quicker pace. Those workers will tend to sort into high-skilled, fast-changing professions initially, maximizing their early career earnings. Less impressive workers will sort into low-skilled, slower-changing professions."
A quick glance through the original paper the data is from does not fill me with confidence. The idea that maybe conventions for job postings in different fields might be different and thus mess up their data doesn't seem to have occurred to them to start with. The NLSY data they work from for AFQT scores can't be used naively. People drop out steadily after the initial tracking period.
So: bad academic research, bad interpretation of it by a layman.
I really wish that I had something comprehensive to suggest. There are some things that I think everyone who deals with statistics should read, such as Freedman's 'Statistical Models and Shoe Leather'[^1] and Tukey's 'Exploratory Data Analysis'[^2]. Pearl's 'Causal Inference in Statistics' is the best introduction I know of to issues of causality as we understand them today. For actual inference, the basis is one player game theory (aka, decision theory). I learned it from Kiefer's 'Introduction to Statistical Inference,' which sets out the theory very nicely in the first few chapters. That's a starting point at least. There are some interesting courses[^3] that try to teach statistics via resampling that seem pedagogically very valuable. Resampling does build intuition nicely and using it gets people over their squeamishness around using randomized procedures.
I read an article some time ago with the reasoning that went like this:
"The goal of software development is to automate things. So, in principle, with time there should be less demand for software development skills because most of the hard work has already been done, and we have better, more high level tools. The only reason we see demand for software developers growing is because we let the bad developers in :) Bad developer can easily generate 2 FTEs per year, by introducing subtle bugs in code that someone has to find and fix. "
Ye no. The reason is not Javascript framework churn. I feel the notation that the software field change fast is a MBA take on it since the in fashion key words change name all the time.
I guess the underlying reason is that engineers wont be promoted to (real) chief engineers with agency. Being a boss requires reports for some reason. So experienced people leave sweetshops to escape the grind when they get fed up.
> I guess the underlying reason is that engineers wont be promoted to (real) chief engineers with agency. Being a boss requires reports for some reason.
Sadly, this is absolutely true. Manage or be managed. Capitalism invariably becomes corporate (if unchecked, monopoly) capitalism which invariably becomes managerial capitalism, in which people are assessed by their position in the tree structure rather than anything they do, and 0 reports |= loser.
Unfortunately, if you think you can take on a middle-management role and also do technical work, you're probably wrong. Middle management isn't hard but it's super time-consuming, if you do it right (that is, if you care at all about the people you're managing, although you won't have much ability to protect them as you might hope for, because PMs). You'll barely know what the people under you are doing (most managers'll admit this in private) because so much of your time will be spent on meetings and political bullshit.
To me it is acceptable if the management class is drawn from tech people. MBA people are largely.. not the type of person I am interested in being managed by.
Big tech that I work at generally doesn't have MBA type managers and it is good.
> Programming-related jobs have high rates of skill turnover
True, but there are fundamental patterns that remain the same. And if we are talking about the level-of-abstraction type of change, then having experience in the underlying techs certainly helps.
Many software positions do not account for the opportunity cost of learning job-specific knowledge, or soon-obsolete knowledge, making it hard to justify the investment in the long run. With pressure, the human capital will also erode faster, leading to a situation where more fresh blood is needed.
Consequently a smart software company need a mechanic to maximize learning RoI for its workers, else the best choice for them would be to leave (even a job they appreciate). So called "accidental complexity" is almost always low RoI.
I retired a bit early and I have found it immensely rewarding to take classes in various hard technical subjects. Some of these are directly applicable to jobs I could do, or have done. I think tech employers should be more supportive of life long learning. I get dinged by recruiters constantly because my resume is great but I'd rather do this, TBH. I have worked in FAANG btw. Retired at principal level.
Hey! I'm trying to plan out my career a bit and I was wondering if I could pick your brain a bit. There's an email that can get to me in my profile, if you're willing to give me some advice :)
I think the profession is too new for the research data to really make sense. The sample size of devs with 20y of experience can't be comparable to that of the devs with 2y experiencie. I think the statistics from the paper stop making sense with the higher ages.
I'm 26 years old. I have no idea what my future looks like. Neither do other people my age.
> The highest ability, fastest learners disproportionately leave the field over time. They have a multitude of other ways to profitably leverage their intellect and skills. Software development carries serious opportunity cost.
Curious where some HN users have gone when they left software dev, especially if it is something other than management of some type.
This is super interesting. One of the reasons why I got to develop my strongest CS skill into Smalltalk (a puristic niche technology) is because I've understood that working with it makes easier the maximization of what is timeless and the minimization of what ages faster than fish out of the fridge (libraries).
Just wait till you have to debug GPT42-generated code produced by offshore subcontractors fulfilling GPT43-generated business requirements beamed straight down from Orbital 4B.
By "debug", you mean shooting up all the drones that ended up being created with some instruction that had as a side effect that humanity would go extinct? (Perhaps something like: "Collect all H20 from Earth, and bring it to Orbital 4B")
Be careful this isn’t an an excuse for ageism. Skills like problem solving, debugging,, planning, … these are invariants and always useful. The language or tool that is used will change, but the underlying process remains the same.
Medical and scientific fields have continuous learning via papers, conferences, even courses that update peoples skills. Also, there’s new ideas and methods coming in with new people who then get involved in the skill exchange once hired (latest synthesis ideas vs. Picking up medchem).
And it seems to be panic buying and selling in this field - inhaling anything with a pulse 5-7 weeks ago and now trying to lay off half the staff today or next week. Same problems, same market issues.
And if the damned SWE’s we’re valuable they’d give them proper working conditions. As somebody wrote, lawyers don’t do jira tickets.
> Programming-related jobs have high rates of skill turnover. Over time, the types of skills required by companies hiring software developers change more rapidly than any other profession.
There's a reason I still strongly prefer candidates with a computer science degree to someone with 9 months at a bootcamp for some roles. New tools, frameworks, programming languages, and libraries constantly enter this industry. I believe knowing the fundamentals and having a deep understanding of how computers work allows you to more quickly pick up new things.
I understand there are curious graduates that come out of bootcamp programs who will dive deep and fill in the gaps and there are universities with subpar computer science departments. I still prefer the latter in general cases.
An ass-clown engineering director/manager I had, proudly shared a chart – I guess it was from something related to the post - that at the current rate, everyone in the US will need to be a SWE at Amazon for it to continue to grow. I can't tell if that case is true or not and I don't remember the time frame, but I have a suspicion SWEs will instead have to work smarter with better tools and languages that effort "multipliers". x10 languages, and tools perhaps.
With OpenAi (and other comparable technologies) able to semantically understand "write fast and efficient C code for a prime sieve" and generate fairly impressive C code, I'm no longer sure I agree that we will never have enough software developers (after watching this, made me get just a little nervous as well as excited about the future of our industry):
I'm very curious about how this "AI writing code" thing is going to turn out.
I have not tested AI myself for producing code, but I toy a little (ok, more than a little) with various GPT instances to write prose. Sometimes it's great, sometimes it's poor, but:
1/ It never gets anywhere: there is never any resolution
2/ Sometimes it just loops, takes up a clue from itself and produces the same set of words indefinitely.
What I do is generate, survey, and then edit. It's a great tool to get new ideas. But how could this work for code that's supposed to accomplish something?
Code is famously much harder to read than to write; that's why people always prefer rewriting than refactoring. With code-generating AI, all that's left for humans to do is the reading, understanding, and monitoring parts.
It's a difficult job, and if done by incompetent youngsters, I think pretty dangerous too.
What OpenAI does is regurgitate stuff it's seen on the internet.
These things are basically a glorified hashtable (with compression).
Much like what a google query does when it leads you to a chunk of code in stack overflow.
Luckily, there's much more to what SWE does, and it's high time people stop believing that AI is at the level where it can do the job of a SWE, it's ridiculous.
Or to put it in a way that's perhaps more clear: Go ask OpenAI to rewrite to GUI of FreeCAD to be usable, see what it comes up with.
My first initial reaction was: did the computer write that code, or is it cribbing code from Stack Overflow? While the latter is problematic for developers who do the same, it is not a problem for developers who have to write original code or where the code has to be verifiable. If it is problematic, it would also say a lot about what the industry has evolved into and would probably be why so many people are leaving it (even if AI could not take over, less experienced and less expensive developers could).
Or for that matter, how often in your career has the problem been an example problem that people use to showcase basic examples of their programming language.
Prime sieve is almost definitely in the top 10 of most written and published programs ever.
Interestingly enough at the end of the video he asks the AI to write some code that makes money. And it responds with "maybe try investing or not spending money". This is much more in line with the type of questions I get asked in my career and somehow I doubt I would still be working if I had answered the same way seriously.
This is a super trivial example of a very simple algorithm that doesn't have to interact with any other systems. It's almost certainly copied directly from the training data as well, which is fine for an educational toy example, but generally a violation of copyright.
I've been quite happy with Github Copilot but it is not remotely useful to a non-programmer.
> perennial labor shortages unless the pace of change slows sufficiently
This frames it as a one-way cause and effect ("unless"). I wonder if the "dropout of fast learners" that _causes_ the labor shortage will in turn _cause_ the pace of change to slow!
I think it follows that an industry full of slow learners might have a lower propensity for introducing change (i.e. developing new frameworks) and adopting change (choosing a new framework over one I'm already comfortable with).
I started programming in "high-level languages" like Pascal, Lisp, Smalltalk and Prolog. I then had to do a project in C. It felt clumsy at first. But then I got it, the pointer arithmetic, and I felt empowered by it. I felt "closer to the machine". The machine felt more like friend. I felt "C doesn't lie" because its computational model corresponds so closely to the hardware. Just saying most any language can be fun.
There isn't a shortage of software developers. The pay isn't great--the kids getting $300K packages out of Stanford are an exception; it's a marketing expense. In fact, if you control for the level of intelligence it takes to be any good, SWEs make less (and get far less autonomy--do you think lawyers work on Jira tickets?) than any other professional, and they hit a salary/challenge plateau quick... after which, they increasingly face ageism.
People leave because the job sucks. I don't mean that programming sucks; I quite enjoy it. Computer science is still an engaging field worth studying, and research programming isn't bad at all. Corporate SWE is pretty awful, though; you get paid far too little and treated far too shabbily to justify spending hours dealing with bugs and bad decisions that exist not because you're working on hard problems (after all, I've generated my share of bugs and bad decisions) but because of inadequate processes, mindless cost-cutting, generic incompetence, and an overall lack of care, especially at the top. All of this, to make a barely middle-class salary while people who are already rich and connected make millions off my work? No thanks. 2.25/5, would not do again.
Cry me a river. Software development is some of the easiest, highest paid work in history. The majority of the population is grinding away in tough physical labor or abusive service jobs getting paid pennies while software devs moan about only making low six figures and getting a few boring jira tickets while they sit in their home office reading hacker news for half the day.
On one hand, I agree with you that on the whole we're a bunch of spoiled crybabies. Totally grant you that.
On the other hand, saying that the majority of the population is grinding in tough physical labour is just not true. Most other jobs are generic office jobs that don't need to be done (just like 80%+ of software engineering jobs don't need to be done).
Most of us are just doing things for money. Are most people working hard? Not usually, because it mostly doesn't matter. Spreadsheets idle in inboxes, meetings lead nowhere and achieve nothing, brown-nosers and family members get promoted into jobs they're incompetent at. And the world continues to spin regardless.
I can't get on the "It is a hard-knock life for Software developers" train. We are very-very well compensated, and we are insufferable.
I do understand the issue. Humans are prone to complain about any slight whether real or imagined. Millionaires will complain about not having enough money, A-list celebrities will complain about not having enough visibility, sports stars will complain about every foul play.
Money just does not lead to life satisfaction, only craving. I just have to accept that this is the human condition.
> Software development is some of the easiest, highest paid work in history.
Nope this is an outdated opinion. You can do just as well or better in trades (source: my electrician buddy). If you’re referring to the FAANG salaries (sub 1%) you’re comparing to doctors, lawyers, entrepreneurs in terms of opportunity cost. Your average joe programmer isn’t killing it like you seem to think, and they’d do just as well in trades or middle management.
The cynic in me thinks this is an opinion promoted by employers, just like the BS “labour shortage” headline.
This seems to be a perspective that's exclusively silicon valley (perhaps large parts of the US) based. Not at all true in Europe at the least. Not that it's a bad job by any stretch of the imagination, but even low six figures is really rare in the EU for Software Development.
Easiest is also highly subjective, if your job is making wordpress templates/sites then sure. If you're working on complexer systems then this statement is horseshit. I've done physical and service jobs that were both easier than the software development I do, only difference was that the physical job was also physically exhausting.
There's absolutely zero point venting out frustration on fellow working class members when upper management and up are actively trying to reduce costs by cutting headcount and/or wages relative to profits.
This race to the bottom is how software devs will become the new "teacher shortage", and how wealth will continue to funnel to the upper classes with those on the lower end unable to climb up.
Yeah indeed. Coming from someone who had to work with physical labor before I started programming, software developers don't know how good they have it.
"The pay isn't great", "treated far too shabbily", "dealing with bugs and bad decisions", "inadequate processes" and so on, sucks when development is the only thing you've dealt with, but you have no idea how it is to actually have a blue collar job if you're actually complaining about those things.
I think cs137 and others like them should try to have a part-time job at McDonalds (or whatever that is not in front of a screen), because it will make you love your software engineering job again.
> Software development is some of the easiest, highest paid work in history.
I joked with a girl yesterday when she asked me what I did. I told her: "I'm a dude that's paid way to much to sit in his living room and make websites and apps".
Not everyone will make $300k per year, but you'll probably still make way more than most other professions. Teachers make like $70k in good places, often times much less. Here we are sitting in our pajamas at home changing the background color of a button and making twice as much.
So many things I have to disagree with. Not all software engineering is easy, particularly the highly paid variety. The six figure salary is diluted by spending weekends constantly having to learn new technology off the clock. Companies then expect senior engineers to mentor other engineers and give presentations of their technical challenges, debasing the value of the knowledge gained working off the clock. Manual labor jobs don’t typically require the student loans software engineers have to pay off, further offsetting the salary gains by years. Manual labor workers get to go home and be done at the end of the day and aren’t tacitly expected to be available at all hours. It may not be the worst industry but it definitely is not a fun industry to work in at a lot of companies. It has one of the worst interview cultures on earth probably and the more years I work the more I see the obvious flaws to the point where I want to leave.
Well, I think the parent is comparing software engineering to other white collar professions like lawyer.
In my opinion comparing SWE to blue collar work like construction is apples to oranges. Ofc the blue collar work is harder and more demanding physically.
It’s better to think about whether software engineers are being compensated fairly relative to other professions like lawyers.
I think they are given that wages seem to be governed with supply and demand. On one hand I don’t make as much as my sister, who is a doctor. On the other hand, I make enough/comfortable money and don’t have to deal with the liability/responsibilities/obligations of being a doctor or lawyer, and I can work from bed naked should I choose to do so.
Hmm what makes you think software developers are not abused? Maybe in your world they are not, but it regular to hear about devs working 12-14 hours a day. With bosses and clients harassing them even at off hours.
No one talked about service workers. These peoples are exponentially more fcked than any of us can ever be. There is still a too large gap between employee and CEO / founder compensation in our buisiness, despite six figure salaries and yes, it is worth complaining about and fighting for.
I think sales is a much better gig than software engineering, personally.
Any engineer who has enough EQ and people skills to give some demos on Zoom is going to find that Sales Engineering/Solutions Engineering is an easier job with more earning potential, all with no on-call rotation.
On top of that, the company treats you like you're valuable rather than a cost center (especially relevant to people doing infrastructure and IT engineering). Sales teams go on vacation to team-build, engineers are shoved in a conference room with some lukewarm sandwiches.
Your comment already has a lot of responses but one thing I didn't see mentioned is about the tough physical labor. It is often neglected that working at the computer is really bad for your body. Sitting for hours is unhealthy and creates all kinds of problems: obesity, disc prolapse, bad circulation, so much more. Also your eyes suffer a lot and become worse much faster than in most other jobs.
I agree that being a SWE is certainly not the worst thing in the world but it has also a lot of bad properties that often are overlooked and the most positions do not have moon salaries, that we see on HN regularly.
Also to do whatever lower income job you don't need to study for 5+ years (master). You need to compare with jobs that have similar requirements to your education.
lol yes this is a good point. We should all volunteer in a hospital or police department for a few days to get some perspective...
And another thought: many jobs descriptions list any technical novelty under the sun even though only some small project in some small team somewhere in the company uses it. Why? To look more appealing to job seekers. It's much cooler to describe the job as PHP + Elixir + Kafka + Big data than simply PHP - which is mostly what the job is about.
I'm not denying the field is changing fast, it is. But there's other reasons why 50 year olds are pushed away besides some imagined inability to keep up.
In comparison to the majoritiy of the population it truly is a nice job, though if you ain't working at FAANG your pay can be lower compared to e.g. a mechanical engineer
What they expressed is not contrary to what you express. They said the expected salary conditioned on intelligence for SWE is lower to that of other jobs, and I am inclined to agree. If you include game dev jobs in SWE then it goes even lower.
Oh yeah, every dev in the world makes $100 000 minimum per year, sure. And it's boring and easy with reasonable deadlines and appropriate vacations and time off work.
As a civil engineer: I assure you my studies were QUITE rigorous. The job is very demanding, and I assure you the complexity can be very high, the consequences of mistakes are severe and occur over a massive variety of time scales. I had to work for four years apprenticing under licensed engineers after school and pass no fewer than four examinations, and get 4 licensed engineers to personally vouch for my work before getting licensed myself as a civil engineer. I am personally liable, in perpetuity, for loss of life injury or property which occurs as a result of work that I put my stamp on.
As a licensed P.E (who is, dare I say, fairly talented amongst my peers even) with a total of 8 years experience, do you know what I get paid to deal with that complexity and liability? About $80k in medium cost of living area for 45 hours/week. That's not atypical. Does that "control for the intelligence" required of the job?
80k for 8 years of experience with a PE is a bit low. You should be cracking six figures by now if you’re structural and coming close if you’re actual (roadway) civil. Are you in materials testing? If so, obviously you should try to switch over to an inspection gig to get some of that sweet overtime. I was clearing something like 110k salary at similar experience back when I practiced and quite a bit more with my equity/COLA/bonus, but I was in a high risk niche field. Not sure where you’re at but any market of reasonable size should be able to support you getting a raise, especially if you’re actually as good as you think.
I agree with everything you say. Software engineers (most should not even be called engineers, they’re coders or developers and on the same level as a lab technician to me) are prima donnas whose mathematical and scientific backgrounds are (on average) at least one level of education behind any actual licensed engineer/professional making half as much. And their degree of liability is infinitely lower, as you note. I’ll probably get sued or be involved in a lawsuit for my work another half dozen times before 2032 even though I haven’t stamped anything in 3 years.
Wow unfair, is it because you work for the public sector that the salary is mediocre? It is not a bad wage but indeed sounds like the salary should be 50% higher.
Many lawyers have to religiously time track everything. Because hours attributable to a specific client are billed and billable hours are where the revenue comes from.
SWE's are not the only ones that think that their pay is low compared to their intelligence level, their education level, how tough, inconvenient or important their work is or what they feel they deserve for some other reason.
For instance, I'm sure there are plenty of HR managers in various companies that are secretly furious about all the young young mostly males, mostly white or asian, still in their 20s, join the company and make more than they do.
I'm sure HR managers know that the majority of jobs they are hiring for are different from the job they're in, with different pay scales and demographics.
>SWE's are not the only ones that think that their pay is low compared to their intelligence level, their education level, how tough, inconvenient or important their work is or what they feel they deserve for some other reason.
Sure, but it doesn’t mean some or all of them are not right, especially when the unequal distribution of wealth is well known and documented to evolve for the worst.
Why would the ethnicity or sex matter when these HR managers would still see the same differences regardless of ethnicity or sex?
Either way, I'd think twice about putting HR managers as victims here when they are the main perpetrators of low raise budgets and high hiring budgets.
HR managers are rarely ever intelligent. The work they do doesn’t require it and intelligent people don’t want to do a job where they’ll be surrounded by lower intelligence people.
LOL, a lawyer in my family does. He actually meets with a whole group of lawyers every month or so and they all do a retrospective to figure out how well applying agile/lean/whatever principles to their firms has been working. He actually feels it gives them a real edge.
I've suggested this to my lawyer wife more than once. The problem is that she works for multiple partners with no visibility in to each other's tasks. So each partner thinks they can have 100% of her time whenever they want, and get upset when that turns out not to be true.
The intelligence floor for becoming a nurse is low, so nurses have extremely large variance in their intelligence, knowledge, and training. Knowing someone is a nurse doesn’t mean you can assume they are pros. Some nurses keep up with the latest medical research papers and are overall similarly knowledgeable to doctors, and some know less about biology than I do and will tell you about vaccine conspiracies and how some homeopathic nonsense will help you. I’ve met people at both ends.
In general to me the whole process of getting the degree, the bar and then the actually work and the pay unless you make it seems like rather bad compared to how easy SWE or related work can be.
The school is laughably expensive for something that should in reality be rather cheap. Read books, listen to lecturers? No laboratory work or practical experience and so on, clearly overpriced. And the studying to get approval of cartel? And then end up working for rather poor compensation for quite a long bit in career... As the pay is bi-modal, yes partners rake in money, but they also need to get the clients. But the people doing bulk of the work aren't that well paid.
Except for almost all of them. Aside from a few exceptions (doctors, laywers), everyone else makes significantly less. A structural engineer with a master's degree for exemple will makes less than half (closer to 3 - 4x in my region).
Lawyer pay honestly isn't that great. I know lawyers who went to top schools and routinely work 60-80 hour weeks to make as much as SWE do.
The lawyers who didn't go to top schools became public defenders etc and make about 70k a year and are saddled with a quarter million dollars in law school debt.
Yes, I more or less think they do. Unless they are a headliner or founder of their own firm.
Lets say you are a lawyer at glob corp, and they get sued. Do you really think you can say "Eh, the other guy has a point. I am not going to defend this one."? You either work the case defending glob corp, or you are no longer glob corp's lawyer.
> The pay isn't great--the kids getting $300K packages out of Stanford are an exception; it's a marketing expense.
You don't have to make 300k for the pay to be great. Even if you fall short of that and land at a company that only pays you $120k, you're still making a killing compared to most other professions.
> Corporate SWE is pretty awful
Then get out of Corporate. I work for an SMB, make about as much as I used to in Corporate, but the stress level and workload makes is much easier. Everyone want's one of those SWE jobs for a company that is in the news, but in fact you want the exact opposite. You want a low profile job at a company no one outside your niche has heard of. The pay is about the same, work is 10x less crazy, and if you disagree with a decision, usually you know the person that made it because the company is only about 200 employees.
I think the signal:noise ratio isn’t great in this sector. Although corporate is 100% guaranteed misery, I have yet to come up with a reliable way to find SMBs where IT (because that’s how they call it, a SWE is the same as the help desk in their view) isn’t considered as “the geeks working the cost center in the basement”.
Do you have a method or did you rely on blind luck like the rest of us?
Probably not, but instead they get to bill their working hours in 6 minute increments. And they have to bill a high number of hours a day. Praise yourself lucky if you don't have to do that!
You want to represent a murderer, rapist or a Bernie Madoff? Lawyers deal with an order of magnitude more BS. You may feel bad when you work on a dead end feature. Imagine if your representation let a rapist walk.
Average salary for a software developer in the US is over $100k/year. For a 30 year old, that would put them in the 95% income percentile, or 87% for a 40 year old.
The comparison to other lawyers is weak because becoming a lawyer requires a hell of a lot more education. You can become a software developer without even a having a college degree.
You are also ignoring other professions like nursing. Nurses make far less than software developers and work a hell of a lot harder. Same with teachers.
As far as barely making a middle-class salary while rich people get richer off your work? Welcome to capitalism.
buddy our goal is to make their professions just a shitty and atomizing as ours. it is the way (the faster the better). the professional class are an impediment to progress idc how mean that sounds.
I think this article hits on some truths and gets a handful of things wrong. First, they are correct that we are in a dynamic profession that requires constant learning and expanding. No doubt the people who choose to stay in software are likely to be people who are curious, life-long learners where this is a benefit of the profession rather than a drawback. That said, one thing I noticed from teaching computer science while a graduate student is that the poor students think about languages and libraries as key skills, while the better students think about the data structures, algorithms, and design principles. These slightly more meta-level concepts are far more stable and timeless, while the underlying implementations of them are constantly evolving. If you think of each new library as "having to learn a new skill" I can imagine burnout and overload are more likely, but if you figure once you know 3D graphics you can pretty easily pickup any new graphics engine, then it might even seem fun to explore different takes on the same old concepts. It's like hearing a new band in your favorite genre.
As for attributing burnout as the core issue here, I would strongly disagree with this idea. When teaching undergrads I noticed immediately that a good portion of each student cohort was basically there because they were interested in making money in the future rather than exploring the ideas of computer science. They were no doubt going to get frustrated or bored and move into management or some other profession rather than continue to expand as an engineer. This is totally fine, and they are probably richer for having learned what they did, but I don't know why we can't just see this and appreciate it for what it is rather than portraying it as the drama of burnout.
It's hard to blame students when they look at job postings and all that they see advertised is positions for programmers using languages X, Y and Z, or when they see tweets and blog posts by hotshot programmers about frameworks A and B.
The entire industry focuses way too much on 'experience with tool X' as a proxy for 'technical skill Y'. It's a bit like asking a carpenter how many years of experience they have with DeWalt cordless nail guns rather than ask about their house framing skills.
Worse, industry is routinely bashing on CS degrees because they don't turn people into framework X-ready candidates. It's getting a little tiring just how little credit is given to the idea of "maybe these tools can be learned in a reasonable amount of time by people with a degree showing they can pick things up rather quickly".
32 replies →
> It's a bit like asking a carpenter how many years of experience they have with DeWalt cordless nail guns rather than ask about their house framing skills.
This kind of logic only works for tech organizations that already have enough in-house domain expertise to onboard new programmers. The other day somebody asked me how to find a programmer to implement something for them. From a programming standpoint there was very little to do, but it involved many obscure technologies that you couldn't pickup in a day (and no you can't pick different technologies). For a person who's already done something similar it'd be a quick and easy job, shouldn't cost too much. With a generic programmer it'd take much longer, cost much more and you couldn't be sure they'd actually deliver.
1 reply →
>The entire industry focuses way too much on 'experience with tool X' as a proxy for 'technical skill Y'
Strongly emphasizing this. This is HIGHY applicable to the analytics environment. As a business analyst who specialized in mostly ad-hoc development because it was the most value-add area at the companies I worked with.. I had a lot of trouble finding new work because I didnt use Tableau, or Power BI, or Looker, etc. I was some sort of fool for doing everything in SQL, Excel, and Python.
IMO the tools are great, and you need a much lower level understanding of analytical concepts to get value from them. But for some reason people kept getting the impression I would somehow be less effective with them because I dont use them. And I had trouble correcting them with the limited bandwidth that exists to communicate with a single applicant in the hiring process. If I tried to get right to the point, I felt myself appearing arrogant.
The carpentry analogy is very similar to how i described it. "I am currently using a ruler and screwdriver, and these tools provide lasers and power drills"
Closer to hiring an electrician certified in Australia to work in the US as a carpenter.
Give them six+ months to train up and I’m sure they’ll do fine.
It's interesting because at least in terms of working professionals, of the most productive professions I've worked with, the ones who focus on "meta-level" concepts are usually the ones who overthink every detail and get very little work done and ultimately they are the ones who burn out.
They tend to bike-shed details, take way too long to try to create sophisticated abstractions that never quite achieve the silver bullet they originally thought it would, and spend too much time dwelling on irrelevant details that ultimately leads no where and results in a kind of paralysis that can be very hard to break out from.
The ones who master a specific language or master a specific library/technology that focuses on doing a few things very well and in very concrete terms are able to deliver the most business value. Furthermore they absolutely have the ability to take their mastery of that and map it to new languages or new libraries. I mean I'm not talking about going from Java to Haskell or Haskell to Idris, but rather people who master C++ can fairly easily pick up Java or Python or TypeScript. People who have mastered Unity can easily pick up Unreal Engine. People who have mastered web development can easily pick up mobile development.
The idea that people who have a solid mastery of a technology and a programming language are somehow just stuck and unable to take those skills and apply them to other areas I think is overstated and just untrue, but those who treat software engineering as highly theoretical and focus on abstractions, design principles and get caught up on these high level details tend to not get much done and when they realize that software is not as clean and elegant as they would like it to be, they get burned out and give up.
I think going over any substantial codebase for products that are widely used and deliver solid business value on Github where most code is not at all reflective of the ideals often espoused on blog posts validates my point of view.
In short, people who treat software as just a tool to accomplish a concrete task are more productive than those who write software for the sake of writing software. They don't write the cleanest code, or the most elegant data structures and algorithms, but they produce the greatest amount of tangible business value.
If your comment does anything for me its to show how terribly few words we have to discuss these things.
> "meta-level" concepts
I'd say having a strong grasp of what you can achieve with just using files and folder, or understanding how SQL solves en entire problem space are meta level concepts. Its just that we take them for granted.
> business value
Is apparently something different than 'value', but still includes every software ever that was valuable to a business?
> high level details
...?
> software engineering
Building constraint solver for a compiler or ensuring a JS animation centers a div?
> highly theoretical and focus on abstractions, design principles
I'd recognize all these things. But out of context 'in the general case' they become meaningless.
---
I understand the picture you are trying to paint, but i don't think it tells anything beyond "I've noticed people make things overly complex". I agree.
However, keep in mind the 'get things done and provides value' software you've seen: is the software 'that survived', might have been set up by a very experienced person ( whose failures we're not seeing ), nobody might recognize it as being not-simple ( e.g. I've seen high value business software partial recreate 'regex'. Worked great, straightforward and easy to read function, just ~50 lines or so, could have been a single function call. ), how the requirements are presented is hugely important.
I think no one was writing about ones who master specific language.
There is a lot of people who learn just a surface without going deep into tool and think they know enough.
For me it seems that someone who would really go deep into learning language would get most of theoretical stuff on the way. Because there is no way to really master C++ or really master Java without learning about data structures and all kinds of "meta-level" concepts.
Maybe the difference is mostly approach to learning more practical/more theoretical.
I understand the concept here but there is also a level of right tool for the job.
Some guys see a screw and reach for their trusty hammer. Some guys know to grab a screwdriver.
I had a project the last two weeks where the code was just going to fail about as often as it was going to succeed. I had to write a resource manager and an Erlang style supervisor and use an embedded key value store.
A better dev may have intuited what took me basically a midstream rewrite to figure out, a worse developer may still be grinding on the problem.
I think my solve is "robust enough" but there was no real way to power through that. You either found the right abstractions or you didn't.
Not to be rude, but did you finish reading the article? The whole point was that high-aptitude learners give up. In fact I don't agree that re-learning the same tasks over and over with the zillionth framework iteration is a rewarding learning experience. It makes perfect sense to change careers instead.
And as music goes, you sound like the record companies that thought everyone should listen to disco for the next 50 years...
As I’ve gotten older it’s harder for me to learn an entirely new area (like say going from web dev to mobile or ML). But it’s actually easier to learn a new variation of something (like the latest JS framework) because it’s usually pretty similar to one of the things I already know. I guess this leads to increasing specialisation, but it also means studies that merely count “new skills” will be misleading if they don’t differentiate in which way the skills are new.
I'm the complete opposite. Hand me a new JS framework that does the same thing I've done a million times but have to learn it's opinionated abstraction set that's somehow better and I just turn off. I simply do not care, at all. You need to simply explain to me the improvement you're proposing or it might as well be trash to me.
Now give me a new theoretical concept where I can expand my knowledge or integrate into my knowledge map and view of the world and I'm excited, there aren't enough hours in the day. Tell me about this all new concept I wasn't familiar with--I'll start thinking of ways I can use it, how I can leverage it, or how it may connect with other ideas and concepts I have.
Now give me a tight deadline which most business environments create and I agree with you, give me the boring stuff I can pump out, get my paycheck and go home to enjoy the rest of my day.
> No doubt the people who choose to stay in software are likely to be people who are curious, life-long learners
The article showed the opposite effect though. Curious, life-long learners stop working in software development because they have to constantly learn new skills and believe they can get more bang for their buck when they can invest in skills that don’t lose their value over time.
I once got excited about ExtJS, the way it created a desktop-like experience in the browser, and I said to myself, "I will learn this, all of it, I will become an expert. Tips and tricks, best practices, the works".
After six months of this, ExtJS 4 came out, which was essentially a totally new framework. Everything I learned was not only not applicable, it had to be actively unlearned.
The lesson here is: become good and proficient at something, but don't focus on becoming a ninja in one particular transient tech. There is value in becoming a Jedi of Unix build-in tools, or more persistent technologies like Git, for example.
Also, this is a bigger problem in the Javascript echosystem, where the hype cycles are more intense than in, say, Python. I checked out my Flask project from seven years ago and it's ready to rock.
I get the thing about constant learning, but learning in this industry used to be cumulative. Now it's a hamster wheel. You are learning how to solve the same problems, in a different, presumably in a "new" way.
People seem to be spending more time coming up with catchy names for their projects than making sure this is all sustainable.
Yes, this is how I feel. I have no problem learning a new skill. I get discouraged when I learn a new skill and just when I start to get really comfortable and productive with it, it's suddenly "legacy" and some new thing is popular.
The only skills that have really stood the test of time for me are C, PHP, unix shell stuff, and SQL.
It's a mix of both. You need to have solid fundamentals and need to keep learning new ways to apply those fundamentals in the real world. There is absolutely effort involved in learning a new language, library, framework, platform no matter how good you otherwise are.
> I noticed from teaching computer science while a graduate student is that the poor (a) students think about languages and libraries as key skills, while the (b) better students think about the data structures, algorithms, and design principles.
The truth is that the programmers in group (b) think about both. Who's designing a lot of the new languages, libraries, and frameworks? Chances are it was someone from group (a). If you're in group (b) then do you want to spend your whole career being forced by your bosses to constantly relearn and follow the latest vogue vision from group (a)? Of course not. So this might not apply to students, but everyone from group (b) will eventually get burned by fads enough times that they start caring about the politics of software. Namely, not wanting to depend on bloat that doesn't actually solve computer science and systems engineering problems. Group (b) might even create alternatives themselves. Go is great example. The guys who built the Fifth Bell System watched their vision behind their techniques decline over the decades and said, enough is enough. So they made Go and it was like a ray of sunshine when it came out.
I actually find the model in the article pretty convincing despite agreeing with you on that it's a profession for people who like to learn knew things and that university/grad school should teach more generic, theoretical knowledge that depreciate slower.
However, these still don't invalidate the main point of the article, that a faster rate depreciation means that your max knowledge level, given your specific rate of learning, will be lower. I.e. your advantage over a less skilled, younger professional will be lower.
And you may say that learning a new 3D library shouldn't be counted as learning a new skill, but it doesn't make the problem go away. If anything, it underlines it: if you have to start working with a new 3D library then you will have to spend time and effort on learning it (to become efficient at using it) while if you were able to keep using it, you could spend that time and effort on learning something that we could count as a new skill.
The article is also hitting on the fact that your skill premium as an engineer has a cap, and so does your willingness to burn the midnight oil on a project. This means that as time goes on, as an engineer you'll face the following
- A younger engineer will have the same value to your employer as you do.
- A younger engineer will work harder than you are willing to.
These two items are inevitable given the current rate of change in the industry. While some engineers will find next level differentiated work to engage in such as leading a core piece of infrastructure which defines the changing field... Many will not. If the rug gets pulled on this core piece of infrastructure.. then it's often the case that the engineers are not particularly more skilled than others on brand new projects.
Well, that's not what the data is showing. Why are you trying to create a narrative that is not trying to explain what we observe? Smarter people leave the field earlier and the author offers a compelling explanation why.
> When teaching undergrads I noticed immediately that a good portion of each student cohort was basically there because they were interested in making money in the future rather than exploring the ideas of computer science.
In my school, those who wanted to make money went straight to management or finance. Computer science was for the passionate ones and probably not the right path to make money for the brightest students.
> the poor students think about languages and libraries as key skills
well so do the recruiters, they’ll be fine
in fact, the better students are the ones wasting their time unless they prefer to be in academia, like you
so what metric are you really gauging for?
the “poor students” are pivoting for money and the name of the university to boost their employment prospects, maybe this shows in their academic performance and ability to understand, I saw the same in undergrad
> they are correct that we are in a dynamic profession that requires constant learning and expanding
Not true. I have met many developers who haven't learned anything new for 15+ years and are still doing just fine developing software. A lot of Java developers come to mind. They have pretty much done the same thing their whole career and have no need or desire to learn anything new.
Once you understand how the industry churns and burns and doesn't really give much credence for capability as you age - it becomes disheartening to try and want to be an IC. Most people see the writing on the wall for being an older IC therefore they move into management or product or other roles.
A fascinating premise, and matches what I saw as an engineering director. The best just get bored and move on.
I think many teams are unaware how much extra value is possible by retaining existing employees vs hiring new ones. Each year I'd try to make sure I was "making them an offer they couldn't refuse" with new interesting challenges, new tech, plenty of personal research time, as much pay increase as I could possibly give, etc. A lot of engineering managers think that it's no big deal to just hire new staff, but even going from average turnover of two years to three years is an massive improvement.
its not just the best ones. If you remove people from the grind for 1-2 days a week, give them a small budget and enough autonomy to do what they want, most people will fix shit that bugged them for a long time.
The main problem is how micromanage-y the current development processes are. Everything has to be a ticket/user story and has to be planned and approved by some people that never even wrote a single line of code. Everything has to have some immediate business impact. I even see scrum teams measuring for team utilization now. target is 90% atm and they wonder why productivity is down.
> If you remove people from the grind for 1-2 days a week
The modern office seems hellbent on killing every last bit of slack in their workers, then wondering why they leave or get burned out.
I realized the other day that a big part of my drive to move towards self-employment is really just a way to carve out time to take adequate care of myself. I have significant doubts that it is possible to continue to advance in tech to staff+ levels, be a good spouse, parent, and friend, and not run myself into the ground with physical/mental issues. And that is sad on multiple levels.
So I respond by easing up on advancing my career, because it gives back to me the least.
7 replies →
We can’t even push to a git repo unless it has a linked work item/story/task/bug.
So, in order to say, upgrade packages or refactor difficult to read code, the work item needs to be approved by a non-tech PO.
Guess how much gets done outside of planned/micromanaged? Answer: next to nothing.
55 replies →
> has to be planned and approved
It gets worse, too - as long as I've worked as a software developer there's been some sort of time tracking system in place, and it has to be planned up-front, and has to work out to at least 40 hours (after they "negotiate" your estimates down). Which leaves no time for the unplanned stuff that inevitably comes up. This always goes in a cycle like this:
1. Management demands that every bit of work be associated with a ticket
2. devs just open tickets for the unplanned stuff so that it shows up in the ticket tracking system
3. management complains about devs opening "their own" tickets and prohibits self-opened tickets
4. devs do the unplanned (always "super high priority!") stuff without any ticket tracking and fall behind on their "planned" tickets (that nobody really cares about any more, but are still on their board)
1. management demands that every bit of work be associated with a ticket...
5 replies →
I've dreamed about a 20% policy like google had, except it's where you can work on anything, including code debt.
I've tried to stress to managers in the past that developers feel the pain of code debt. It makes us slower! Enable us to spend time sharpening our tools and managing our codebase.
One problem of course is, not all SWE can do this well. I wouldn't necessarily trust a junior hire to recognize and execute a proper refactor.
18 replies →
> give them a small budget and enough autonomy to do what they want, most people will fix shit that bugged them for a long time.
This has been huge for me at my current job. I saw some unused equipment in a lab and started asking questions why. Turns out the thing worked, but not great, so no one used it. What started as just fixing bugs and adding features became my own line item in the budget and requests for the (new and improved) equipment from other departments. It's something I look forward to working on.
That reminds me of the time I was a junior dev, and the team lead told me verbatim: "I know you are too busy to write tickets, but can you take some time off [this urgent thing] to do that? Thanks!"
This was after they encouraged a certain "cool culture" for a couple of months due to the lack of direction. It was pretty funny that I did not only get micromanaged, but was told I did the wrong thing, and then asked to do a third job that was not my responsibility.
We have a lot of bugs everyone complains to me about and I have sufficient downtime to fix them* but I have to go through drawn out planning, UI, UX processes before I can even start. I just don't bother any more.
And yeah, it's definitely not just the best ones. I am mediocre and am so bored and so done with dev.
* the downtime is there because I am waiting for planning, UX, and UI for a different high priority task.
1 reply →
Shit that bugged them for a long time might have a lot less value to the business than a tedious task that nobody wants.
4 replies →
> Everything has to have some immediate business impact.
Or more specifically, explainable business impact.
But it's hard to explain how the code has become horrible and needs a refactor to makes it easier on devs, reducing stress, reducing likelihood of both bugs, and developers leaving.
I could not agree more. My current gig is the opposite and after a year I'm ready to leave.
> The best just get bored and move on.
It may not be a matter of "the best". I have taken a personality test that had an item on it that covered product lifecycle. If 1 is initial conception, 2 is prototype, 3 is initial release, 4 is major enhancement, and 5 is maintenance, my personality is that I prefer 2 or 3. By 4 (major enhancement) I start to get bored, and by 5 (maintenance) I'm definitely bored.
It's not that I'm one of "the best" (though I like to think that I am). I have a personality clash with the later stages of product lifecycle.
>The best just get bored and move on.
Is that the premise? Seems to be saying that constantly changing skills exhausts developers to the point that it becomes more lucrative to work in another profession.
Although, I suppose learning new things just to tread water can be boring too.
This is how I read it too. That a fast learners skill is degraded in a field that is constantly reset (software dev) vs one where you can stack knowledge. And thus the fast learners will eventually leave the software field and transition to one that doesn’t reset constantly so they can stand out more.
Doesn’t have to do with boredom so much as maximizing potential.
> The best just get bored and move on.
Or a reorg happens and you land a shitty manager.
To be fair, almost all my managers were amazing, people who truly cared about their staff: at professional level as well as a personal level.
I've only had one absolute psychopath as a manager ... but I should thank him because he was the last straw and gave me enough courage (and anger) to leave AWS and start my journey as a solo entrepreneur.
Oddly enough I joined AWS not too long ago and while the job itself sucks, my manager is exceptionally awesome. In fact I only interviewed with AWS as kind of a half-joke, but he was so likeable that it convinced me to take it seriously. He has a healthy "fuck em" attitude when it comes to pressure from outside the team, so he's constantly protecting us in a multitude of ways (e.g. during on-call rotations or deadlines being imposed on us). He has yet to do a single thing that I would consider micro-management.
1 reply →
I think for some engineers (me) there's not much you can offer. I don't just want any new random tech challenge. It's unlikely your company or most companies have something I could truly be passionate about solving.
Literally every engineering director I've ever seen says exactly what you're saying. E.g., "as much pay increase as I could possibly": for my experience and growth, an employer I worked with offered a -6.6% increase in real salary for my time there. (≈3 years tenure.) Negative. The work was also … not what I'd like to be doing. So between "stay with company" and "find different company", it shouldn't be too hard to predict which option was more appealing.
It's not even that they get bored, it's that they're comfortable with their tools and don't feel like doing the mandatory re-tool every 5 years.
You should fill in your profile with a link to your careers page :-)
My experience, unfortunately, is that good managers like you seem to be don't last long. They get replaced by manage-up sleazeballs who'll never, ever protect the people beneath them because it's not game-theoretically optimal.
The thing is, executives measure themselves by how quickly they get promoted into the next role, so no one cares that good management might reduce turnover in the next 2-3 years--in fact, the executive mindset is that it could just as easily increase turnover (what if we invest in their careers, and they leave?)
My philosophy as an engineering manager is to actually pursue this outcome. If I treat them badly they will leave. If I treat them well and train them into better engineers then they will leave. It's like being a college football coach. Having your star athlete be drafted to the NFL is entirely the point.
"what if we invest in their careers, and they leave?" - Does that also apply to decision makers?
There is no shortage of swe. What I see and what I have experienced first hand is that companies, especially the more hyped/small ones, pretend to be FAANG and gets very picky when interviewing. They often employ FAANG style interview.
Now, if I really have to spend that much time prepping to interview at your unprofitable company (that most likely will go under) don’t you think that I would try my best to work at faang instead ?
As matter of fact, I was rejected at plenty of these small insignificant companies, but end up having offers as L6 at FAANG.
Be humble and you will find plenty of good engineers out there.
I know tons of good swe that don’t want to interview/ work at mega FAANG, and if I was running a business I would definitely try to attract those talents by being different. Offering a “normal and reasonable” interview process along with better perks, flexibility and wfh.
Instead, they all want to run bizzilion of micro services in k8s
I definitely think "we do not do leetcode interviews" and maybe "we only have three interviews total" would be selling points on a job posting. People who are experienced in the field don't want to go through the same hoops that newbies do just to prove they know how to write basic algorithms.
You wrote: <<People who are experienced in the field don't want to go through the same hoops that newbies do just to prove they know how to write basic algorithms.>>
I am constantly interviewing candidates for roles at my company. It seems like CVs are a complete gamble. Either some are lies, or wildy understated, and everything in between -- at all levels of experience! "[J]ust to prove..." and yet so many can not do the 2022 version of FizzBuzz. I am stunned how many senior (well, so they say!) hands-on technical applicants cannot do basic things like write a very simple linked list class, or explain to me how a hash map works. For get about explaining the finer points of sorting algorithms (honestly, very low value in my line of work).
There is no reasonable alternative to testing of some kind for hands-on techincal roles -- I am flexible about method: (1) white board coding (ugh in 2022), (2) IDE/text editor on shared PC / video chat (meh / eh in 2022), or (3) take home (the best in 2022, even if there are drawbacks for people with families).
Joel Spolsky said it best about hiring: The goal is to avoid bad hires. Average and above are fine.
20 replies →
Personally I do because I enjoy working with very smart people.
The backlash against leetcode is the same as backlash against other types of tests: most people are going to fail and most people don't like failing, so they blame the test.
16 replies →
> "we do not do leetcode interviews" and maybe "we only have three interviews total" would be selling points on a job posting.
It depends on the job. I have had interviews that broke the mold here and were panel discussions or more job-talk experience, and I found the interviews uniquely exhausting because they required their own set of skills to study for that were different from the “leet code” style. At the extreme end were the take home projects, which I simply didn’t have time to do for every company and were extremely unattractive to me for that reason. I actually find doing leetcode style interviews for me required the least amount of prep and was the most straightforward, especially when they were structured to leave me with time to ask and talk to real engineers at the company.
Three interviews is now an "only"? Man this industry is fucked.
Basic algorithms? FAANG algorithm questions are usually far from basic.
http://they.whiteboarded.me/companies-that-dont-whiteboard.h...
1 reply →
I agree with some of what you said, mainly this:
> Now, if I really have to spend that much time prepping to interview at your unprofitable company (that most likely will go under) don’t you think that I would try my best to work at faang instead ?
I feel the same way.
That said, my company and many others make the interview process much easier but still find it difficult to hire. I know this is a common problem, because I get bombarded with good job postings by recruiters and they are usually still there months later when I finally get around to responding.
Companies have only tested my code skills and handed me personality tests when applying for full time jobs. As a freelancer, I get one or two interviews where I talk to the architects, tech leads and managers, and that's it - either I'm in or out after that. They end up treating me as an employee anyway, so don't really know why this distinction is made in the first place, but I suspect HR.
I don't think FAANG style interviews are a good way to do it, but it is more important to be picky about hiring at a small company. If you're in a company where everybody knows everybody, then any new hire will affect the entire team. A good hire will pull the whole team up. A bad hire will negatively affect everyone.
>High-ability workers are faster learners, in all jobs. However, the relative return to ability is higher in careers that change less, because learning gains accumulate.
This is not the only reason for the quick learner -> high dropout thing. By the article's definition, I'd be a "fast learner". Most of the industry expects me to come in already knowing what they want me to know, while most ways to obtain said knowledge are blocked by barriers difficult to bypass for non-corporates. Meanwhile, almost every corporate I get in expects me to do the same things for several months and gives me a few learning opportunities every year. At the same time, university primed me to absorb knowledge like a sponge and never get stuck on a single perspective, while corporates are complaining why graduates don't know Spring after graduating.
So somehow you're expecting me to stay while my knowledge deteriorates unless I keep it up in my own time, all the while giving lowball raises and not satisfying my desire for challenges. Yes, I get it, grunt work has to be done. But you really can't tell me you're in need of software developers when you actively push people to do the very thing you claim you don't want them to do.
"somehow you're expecting me to stay while my knowledge deteriorates unless I keep it up in my own time, all the while giving lowball raises and not satisfying my desire for challenges"
That's not really the expectation... the expectation is that you'll be replaced by someone younger who's already learned all that.
The expectation for more senior people is that they'll go in to management or architecture.. or maybe burn out.. it doesn't really matter to most corporations, as their workers are replaceable.
This is spot on, and personally, the main reason why I decided to move to an engineering manager after 10 years as a developer.
And even as an engineering manager, I do not feel safe. I think only once you reach director level, you are protected from market hype and newest frameworks trends.
You think directors feel safe? I highly doubt it...
2 replies →
This. Slap the golden handcuffs if possible for the most boring work and give employees extra vacation time to recover from that slog and they might not leave. Most people are willing to deal with some BS as long as they feel compensated and the comp keeps up with changes in the marketplace.
Some really good points on the ultra-fast depreciation of SE tech skills. A relative of mine is a mechanical engineer, well past retirement age and still going strong in his 2-man consulting shop because that's what he loves doing. He works with precision manufacturers, automotive suppliers,... all very cutting-edge stuff, helping them develop new product lines, manufacturing processes,... He says the core skills that he's using are still those that he learnt in university several decades ago.
I was actually surprised because I heard so much about crazy new materials like carbon fibers, graphene, technologies like 3D-printing,... but apparently what makes a machine break are still the same things: mechanical stress, heat dissipation, friction,... new materials and processes might change the coefficients, but not the (mostly Newtonian) physics (my interpretation btw, not his words).
One could say the same thing about software engineering - true fundamental advances in algorithms and data structures are sufficiently rare that it wouldn't be a nuisance to keep up with them. But the %-age of how important those basics are relative to the extremely fast-changing landscape of tools and frameworks is much smaller (plus, one could argue that even the fundamentals see a lot of shifting ground in CS, with neural architectures, differentiable programming, not to mention quantum computing).
I think the skill depreciation concept is a bit exaggerated. Especially in the context of the newness of computers relative to the engineering field in general, the latter which has been around, arguably, for thousands of years.
For example, SQL & Unix have been around since the 1970s.
Linux since late 1991.
Javascript: The end of 1995. NodeJS: 2009.
Sure, there's a ton of churn in the JS Ecosystem, but all it takes is a bit of wisdom, skepticism, and patience to avoid the hype-cycle.
Also, once you learn to build certain things with a programming language you learn the paradigms of the system you build.
For example-- Web Servers. Looking at ExpressJS vs Python Flask documentation, there are many analogous pieces, because they follow the same standards for protocols.
Another example-- data engineering / statistical computing: Checking out R vs Python packages, there are a lot of the same concepts, just in a slightly different format/language.
HTTP/1.0: 1996 (RFC 1945)
TCP: 1974 "In May 1974, Vint Cerf and Bob Kahn described an internetworking protocol for sharing resources using packet switching among network nodes."
"TLS is a proposed Internet Engineering Task Force (IETF) standard, first defined in 1999"
Considering all of this... I don't think most major things actually change that much. Sometimes a popular new framework takes the world by storm, but that's pretty rare compared to the output and churn of the ecosystem.
The issue is that every job I’ve had requires learning a bunch of new shit. Rarely am I just transferring over to the same languages or frameworks. Add on that each company decides different design patterns that they want to utilize and has a different interpretation of what REST is and what HTTP status codes are… it’s a pain in the ass to be an expert in any good amount of time. Expert being one that can dive into the true weeds like cryptic memory leaks that require special profiling tools that aren’t documented anywhere - etc. (and able to do this at a moments notice with ease)
Especially if you’re a full stack eng who is constantly swimming over the entire stack and they keep pushing new DBs, new logging tools, etc.
There are commonalities but it is a lot of learning as you go. I used to know Angular pretty well but now I don’t remember it at all. I haven’t even gotten to really ramp on React as much because my company uses it in such a terrible way that it’s clearly not fit for.
1 reply →
From the perspective of whoever is experiencing it, it doesn't really matter how it fits into the historical picture. What you experience is sitting in front of your screen while your family is having dinner, not points on a multi-decade timeline.
In the last 20 years I have seen mostly ultra-fast depreciation of SE _interviewing_ skills.
After the first ten years software development becomes quite intuitive and you internalize all those best practices. You can be trusted to start a new service from an empty git repository. Later it gets incremental, there's a lot of path dependency in languages and frameworks and few things come out of the blue. Those that do are frequently intellectually stimulating to learn.
But interviews have been steadily getting strange and difficult (in a way not related to real life software development), at least in the last 10 years.
Very true. This stuff started at places like Google and Facebook and it makes a sort of sense for them as right or wrong they're very focused on hiring new college grads. With no real work experience to speak of you can do a lot worse than hire the ones that show they can apply their CS coursework to leetcode problems.
But doing the same to workers with 10 years of real world experience doesn't make nearly as much sense. Like hiring medical doctors by quizzing them on organic chemistry problems. Google and Facebook do it because they can and they don't know what else to do, but I don't understand how it became a universal practice.
1 reply →
>I was actually surprised because I heard so much about crazy new materials like carbon fibers, graphene, technologies like 3D-printing,... but apparently what makes a machine break are still the same things: mechanical stress, heat dissipation, friction,... new materials and processes might change the coefficients, but not the (mostly Newtonian) physics (my interpretation btw, not his words).
I don't really see the difference between that an programming. Writing code is still a bunch of "if" statements, the same underlying data structures, same algorithms, etc. There's some new technology being added on the top akin to carbon fiber and the other things you mentioned but it's fundamentally the same.
You really think that a SE in their 70's who learnt how to write if statements and data structures 50 years ago would say that they're still basically doing the same thing now as back then? Maybe if they work on legacy stacks like the famed COBOL devs coming back out of retirement. But the thing is that what he's working on is cutting edge, not maintaining systems that were built decades ago.
An unsolvable problem. The rapid deterioration of skill will not stop, it is accelerating instead. People's desire for stability as they grow older will not change either.
The only attraction in software development is the relatively good pay. The job itself sucks. You'll spent your life sitting in a chair looking at a text editor, and that's the best part of your day as about 50% of it is distractions. You're quite unlikely to work on something truly creative or thrilling, so it's mostly a boring grind.
Then, as the article mentions, it turns out the grind was for nothing and the rug is pulled every few years and you have to start over again. The job is cognitively taxing so you'll turn into an absent person that lives in their heads, it drains your life energy.
If I would be young now, I'd say fuck it and go install solar panels or heat pumps. It's outside, physical but not too physical, thus healthy. You get to meet lots of people and you see the direct result of your work. There's no office politics and you're contributing to a tangible good thing for the world. Skill requirements don't change much.
You might come home somewhat physically tired (but over time it normalizes), with a clear head and not a care in the world. There's no overflow between work and personal life.
Chose wisely, young ones.
The jobs you mention are even more repetitive. Just like most jobs. I think this is a the grass is greener mind of thing
No, they're not.
You go to different places and different people, every single day. That's 100% less repetitive compared to sitting at home or going to the office to see the same people.
As for the tasks themselves, it was merely an example, but even for this example I disagree. My brother-in-law basically does all of these things, both for private citizens and industry and comes across a wide array of different situations.
I'm not saying it's absolute perfection, no job is. But I stand by my point that it has a series of very meaningful advantages: far healthier, more social, direct impact of your work, no cognitive overload, no politics.
Go ask people installing solar panels and heat pumps if the idea of working a "cognitively taxing" job where they could make more money, work from anywhere and not be dead physically tired at the end of the day sounds appealing... I don't think you'll hear them all say "screw that, I love installing solar panels". The grass is always greener for sure, but none-the-less software engineering and tech offers a very high quality of life with significant earning potential and a ton of flexibility.
> If I would be young now, I'd say fuck it and go install solar panels or heat pumps
Amen. For me the advice I give the young—-go for a trade. HVAC (especially if you live where it’s hot) and plumbing to me are the most future and recession proof jobs there are. Literally by the time other folks are graduating with CS degrees and massive college debt, you have been making 70k a year for 3 years and are about to clip 6 figures for the rest of the time you want to work.
One day a computer will be able to write its own code (and that’s not that far off now), but no robot or computer in this world will be able to come to your house and fix a clogged toilet, or replace a blown capacitor in your heat pump and people will always be willing to pay nearly anything to get those two problems replaced.
Unfortunately, this is also a low cost skill to acquire, so the barrier to entry is low.
As all the mid level white collar jobs keep getting automated away, there's going to be a glut of people in need of income who are more than capable of learning a trade if their ego can handle it.
1 reply →
It's not so much a desire for stability in general rather than the depreciation. I found that piece in the post rather convincing. I don't think most people have a problem with learning new skills in this field. But having to throw away old ones sure feels like a waste and given the model in the post limits how good you can ever get.
Also, sitting and staring at a text editor should not sound that awful for anyone who likes to create via writing code. Because that's how you do it. But that's not what you experience, obviously. It's about what goes on in your head.
I remember the feeling after taking a new job as a fresh graduate. It felt ridiculous that I know get paid for doing the thing I've wanted to do most of the time in the past ~12 years but I was told that you can't do that all day because you have duties. (Now the pay was actually pretty bad, even for local standards, as my first job was in an academic research institute.)
I think the problem of ageism wasn't mentioned at all and it should be. People who love the field have no problems keeping up to date. Sure some job posts will mention Hadoop or Kafka but whatever, a good dev will have no problem learning these in a few days. Does he get a chance though if he's 50?
Ironic thing here is that Hadoop is mostly already outdated.
Which is btw one of the depressing thing for a lot of data engineers: we used to play with those cool distributed processing frameworks, and now? We are mostly writing some terraform to deploy cloud resources, most of the distributed part being handled by those cloud providers.
> Which is btw one of the depressing thing for a lot of data engineers: we used to play with those cool distributed processing frameworks, and now? We are mostly writing some terraform to deploy cloud resources, most of the distributed part being handled by those cloud providers.
Sounds to me like switching one provider/tool by another - or are data engineers feeling bummed because the job has become too trivial / less fun?
1 reply →
The Hadoop ecosystem is still very much ongoing. You must work in small tech/startups if you think that these are being replaced by managed services.
1 reply →
I'm not disputing the fact that there is ageism, as I'm sure there are thousands of examples of it, but there's so much demand and so many different companies. I've worked with plenty of over-50's. Maybe there's a sweet spot for growing companies where you need the experience, which has been where I've worked. Small companies don't need structure, and maybe want cheap employees. Large companies put all that structure in management and a few super senior folks. (though I saw plenty of over 50s in my large company experiences) Medium growing companies need experience. I dunno, just guessing since certain companies I've worked for seem to have a higher concentration of older folks.
Here, this rando website says that 46% of software engineers are 40+
https://www.zippia.com/software-engineer-jobs/demographics/
Now I'm curious, this stack overflow survey paints a grimmer picture:
https://insights.stackoverflow.com/survey/2018
That's a survey though, I'm curious what biases are going to exist in the data. We might assume that older software developers move around less? May be less likely to respond to surveys? May be less likely to visit stack overflow, especially if they do less hands on coding?
I'm with you, I don't know the answer this is definitely complex. It could be a combination of things - a) burnout due to ever changing tech b) ageism c) highly paid devs choosing to retire / switch professions early simply because they can financially
40 is definitely not that old anymore for tech I think. Well I'm 38 I'll find out soon.
There should really be a surplus of software developers. Most companies are solving problems they don't have, employing a team of 10x more developers than they need - because of course microservices, Kafka, Kubernetes, you name it - cargo culting the shit out of it.
https://www.youtube.com/watch?v=y8OnoxKotPQ
That video is story of my life. Microservices to the brim!!!
I feel like the need to continuously learn new things is a feature of the profession, not a bug. It is certainly a difficult challenge, but I've always felt that the most important trait in a software developer is an eagerness to learn new things.
I think the overall premise of the article makes sense, but where I differ from the writer is in how I view the need for constant learning and self-development. The author writes,
> Like a fast, expensive car that quickly loses value as it's driven around town, the skills and human capital of software engineers fall apart without constant, expensive maintenance.
What the author is talking about, however, is not a material object with transient importance to one's life (i.e. a vehicle), it is your mind. Learning new things doesn't just mean you retain your relevance as a software developer, it also helps stave off cognitive decline. It keeps you sharp, relevant, mentally agile. That may not be the case in every job, but the field as a whole certainly has that attribute.
> the opportunity cost of working in a rapidly-changing field is highest for the best learners
It's not that learning is an unattractive aspect (I agree, it's a great feature!). Instead it's that it levels the playing field between those entering the profession and those that have been in it for many years. Yes, you still have "experience" as an advantage, but you can't say you've worked with LATEST_TECH for many more years than someone coming out of college.
Contrast that with other professions, like law, or medicine. Where it's not just "experience" working in your favor. But actual knowledge of the existing laws and medical practices.
That's an excellent point which mirrors my experience as well. My parents are both recently retired civil engineers one which was working for the government/city, the other in a private company. Both very valued in their professional circles, and even outside just because of their reputations.
I've never seen them at home reading a law, bylaw or a "teach yourself how to design a bridge in 30 days". Whenever something changed in their profession (very rarely) be it law or similar they went to seminars about it. Some of the time they (or their "guild") were even consulted so that stuff ended in the law itself. Something really new in the industry (say some software tool or whatever), the company paid for the trip, and the training. The older they were, the more compounding experience and knowledge they had. With each year they were worth more to their respective companies.
Contrast this to my current company (previous were even worse), where my boss proclaimed that all new infrastructure is going to be in Terraform (I had no problem with that, but zero experience), hired a new guy almost straight out of school with 1.5 years of TF experience (and absolutely nothing else from what I've found out later) with much better pay than the rest of the team. Oh, and he said he'll expense us any TF book we want to buy. So here I am, on my 2 week "long" vacation reading a fat book about some technology X which we'll be abandoned in couple of years time.
> Contrast that with other professions, like law, or medicine. Where it's not just "experience" working in your favor. But actual knowledge of the existing laws and medical practices.
In my experience knowledge decreases very fast if you work in a programming job (exception: if you use an insane amount of your free time to avoid this decrease).
> I feel like the need to continuously learn new things is a feature of the profession, not a bug.
The bug is in our brains. After two decades, you are not the fast learner you were, especially after you manage to fill your clothes with keys traded for responsibilities.
Realizing that is a source of mid-life crisis. Trust me, I've been there.
Also: you're learning the same thing you already learned several times before, except slightly different this time. Things are no longer as exciting as when you learned it the first time, and especially if $new_thing isn't a fundamental improvement over $old_thing, or even worse (in your view, whether that view is correct is another matter) it just becomes a slog.
I found that excitement/motivation is pretty important in actually learning new things. I'm close to 40 now and don't find it's harder to pick up new things when I'm motivated. If anything, I find it easier as I have a broader background knowledge and spend my time more effectively – I didn't believe my teachers when they told me that taking notes helps you remember stuff but they were right and I was a stubborn idiot. All of that offsets the undoubtedly decreased ability of my brain compared to when I was 21. It's just that I've done a lot of things before and find it hard to motivate myself for "$new_thing that's fundamentally just like $old_thing building $new_app that's not really any different from $old_app".
Brother is teaching at the University among other things and from the stories he sometimes tells me:
I do not worry about agism or work at all.
Lets just say that when we were studing, most ppl were not the brightest tool in the shed. Now its supposedly many many times worse.
Agreed. I hire interns every year, and I am continually astounded at just how incompetent so many people are who are months away from finishing a master's in computer science. On paper, I wouldn't expect a shortage of software developers. But as a practical matter, more than half of everyone I talk to who is about to finish their CS degree is very clearly not going to last long in this field. Not just because they are incompetent, but because software so clearly doesn't interest them. Right now they think the salary will be enough to keep them happy. Think again.
> so many people are who are months away from finishing a master's in computer science
Because by hiring masters degree interns you're not exactly scraping the cream off the top...
Masters degrees in Computer Science -- unless used as an immigration thing -- make no sense.
The make no sense for the research route -- in CS in the USA, you go straight to a (zero tuition + living wage stipend) PhD from undergraduate. No reason to pay for a master's degree.
The make no sense for the SWE route either.
Masters students are mostly in it for either a domestic degree or because they couldn't find a (good enough) job out of undergraduate.
Most departments know this and treat their MS program as a total cash cow.
I've always considered Computer Science to be a distinct field from programming (or "Computer engineering", if you will). I mean, a brilliant particle physicist does not necessarily make a good engineer, an astronomer doesn't necessarily good telescopes, and a cancer researcher doesn't necessarily make for a good GP.
Not that these people automatically lack the ability to do these things well – some do, some don't – it's just that they're different fields with different training, mindsets, interests, etc.
1 reply →
Where are you from, if you don't mind sharing? I believe it depends on the education system. From my point of view in France new grad need 1 to 2 years to be "work ready". They just have to learn how work life is working.
Do you mean students are less intelligent these days?
I suspect it's a result of the bucket being wider and larger - many many people have latched onto the idea that "software" is the way to make lots of money, so people are signing up to learn it.
In the past CS (if there even was a CS degree/course offered) would me mainly populated by "the nerds" who were really into it, money be damned.
Arguably this could be why the educational requirements around other well-known lucrative positions became so difficult.
I think it's time to start separating what is a software developer.
Is a software developer someone willing to learn new languages and uses software to solve problems? Or is a software developer someone who knows latest.js and writes front end code or someone who writes C code to makes the LEDs on the machine blink.
There are two opposing hiring methods: * hire for positional skills * hire people not positions.
At a smaller scale, maybe you need to to just be a flexible person who can do anything. But how many start ups are going to hire a 35 year old C programmer to do js front end, or type coffee script? Yes that's 35 year old may have learned a lot of lessons along the way, but at their stage in life they're also going to likely cost you more and in all likelihood have more responsibilities outside of work.
Myself, I'm a generalist. I have programmed all levels of the stack. Consequently though, I can't claim deep mastery of many specific areas that a lot of "skill" positions require. On the hire "people" not positions, perhaps I can fulfill those roles but in doing so, as I become more senior I leave a lot of my skills sitting in the toolbelt to do a narrow software task (at a mega corp) and my lifestyle isn't well suited for the grind of startups (many many hours). Sometimes feels a bit of a catch-22
> Is a software developer someone willing to learn new languages and uses software to solve problems? Or is a software developer someone who knows latest.js and writes front end code or someone who writes C code to makes the LEDs on the machine blink.
Yes. A software developer is someone who develops software.
Re: skill churn
I got the impression that there is much less of this in lower level languages. It seems like there is a fairly stable foundation of C, Cpp that everything else is built on top of. I wonder if embedded programmers have this problem.
> I got the impression that there is much less of this in lower level languages.
Not only the lower level languages, but fundamental skills in general, I think. Undertanding the computer from the hardware level, OS level as well network protocols, filesystems etc tend to continue to provide benefits even if one fashionable technology is replaced by another.
Similarly, fully undertanding algorithms, data structures, design patterns and architectural patterns also generalize, provided you DO understand these concepts with their strengths, weaknesses, and when to use them and not use them.
If you have the skills above (+ some math and general troubleshooting ability), you are able to approach most software/compute problems from first principles. If so, you may find that you are able to take up senior roles even involving technology you have not used before, as long as the tech introduces few new fundamental ideas. (And if there are new fundamental ideas, you need to learn those to keep up, but such ideas arrive much more rarely than new tech).
People who do not learn these things from first principles, but instead are memorizing patterns they learn from other people, have to do a lot of new memorization when new tech becomes fashionable.
Not only does that take a lot of effort, it also makes it unlikely that they will be able to identify antipatterns by themselves, and it may cause them to end up trying to use the new and fashionable tech in ways it is not suitable for.
This is what I’m hoping for. At least, I’ve noticed on the admin side that lower level tools and system calls seem to be more stable and better documented than the abstractions built overtop of them.
I think market pressures make this a difficult fit in the workplace. High turnover (~2yrs) and larger systems encourage shorter term results with a shallower understanding.
This isn’t a criticism (I have so so much to learn still, I’m in no position to judge, nor do I want to be), but more of an observation. Balancing learning churn(frameworks/languages) vs fundamentals(theory, concepts) is a struggle I think I will have for the rest of my life.
>If so, you may find that you are able to take up senior roles even involving technology you have not used before, as long as the tech introduces few new fundamental ideas.
But will you be hired for those roles? Not that many companies will do that I think.
1 reply →
From an outside perspective, as someone who does embedded development as a hobby rather than a profession, the answer is both yes and no. The stability of C and C++ helps, but you still have some churn in libraries and you almost certainly have to deal with vendor specific libraries (which makes moving between vendors difficult). Trying to bypass libraries doesn't really help on that front, since you are simply trading of churn in libraries with churn in microcontrollers.
That’s very frustrating. I suppose it would be very expensive to standardize apis at this level where everything is performance critical.
In my experience it's the opposite problem. Advocating for modern development practices or languages (even unit testing, let alone Rust) for embedded projects is hard work. Most new embedded projects, even today, are written in C or C++.
How does the language matter? I write software (mostly) in C for a living (the simple man's "embedded" as in "Linux on an ARM board", not the "bits on a micro controller" kind) and I made sure we use test-driven development with proper version control and CI.
We have been trying to use Rust for some new projects but cross-compiling is still much more hit-and-miss with Rust (i.e. third-party libraries) than it is with C. I imagine it would be worse for proper embedded projects.
1 reply →
I have the same experience. I cant event get people onto github. We spend thousands a month trying to keep our international teams connected to our local servers and they still have to zip up the project and send it to me over teams.
3 replies →
We need a #badstatistics tag or something.
The turnover problems saying that relative wage advantage declines? Their chart on a log scale shows that the wages are still really high compared to non-CS jobs. A more likely interpretation is that junior programmers are for whatever reason highly paid in their sample. Those error bars are suspiciously tight, so there's a good chance their sample is biased.
The selection problem data? First, they're missing a plot that shows that the same correlation (higher AFQT scoring individuals are slightly more likely to leave the field) doesn't hold for other majors/fields as well. Second, is the AFQT psychometrically valid when compared across different age groups? Third, is their sample valid here at all? It wouldn't take much bias to make these correlations disappear. The super bright principle engineer is probably not going to take the time to sit an AFQT and be part of this.
Then we have weird assertions without citation like "Some workers, endowed with superior ability, learn faster than others, picking up skills at a quicker pace. Those workers will tend to sort into high-skilled, fast-changing professions initially, maximizing their early career earnings. Less impressive workers will sort into low-skilled, slower-changing professions."
A quick glance through the original paper the data is from does not fill me with confidence. The idea that maybe conventions for job postings in different fields might be different and thus mess up their data doesn't seem to have occurred to them to start with. The NLSY data they work from for AFQT scores can't be used naively. People drop out steadily after the initial tracking period.
So: bad academic research, bad interpretation of it by a layman.
Are there any books/courses you recommend for learning statistics at a rudimentary level?
I really wish that I had something comprehensive to suggest. There are some things that I think everyone who deals with statistics should read, such as Freedman's 'Statistical Models and Shoe Leather'[^1] and Tukey's 'Exploratory Data Analysis'[^2]. Pearl's 'Causal Inference in Statistics' is the best introduction I know of to issues of causality as we understand them today. For actual inference, the basis is one player game theory (aka, decision theory). I learned it from Kiefer's 'Introduction to Statistical Inference,' which sets out the theory very nicely in the first few chapters. That's a starting point at least. There are some interesting courses[^3] that try to teach statistics via resampling that seem pedagogically very valuable. Resampling does build intuition nicely and using it gets people over their squeamishness around using randomized procedures.
[^1]: http://psychology.okstate.edu/faculty/jgrice/psyc5314/Freedm...
[^2]: Sadly really hard to find. We need a cheap reprint of this.
[^3]: https://resample.statistics.com/intro-text-online/
I read an article some time ago with the reasoning that went like this:
"The goal of software development is to automate things. So, in principle, with time there should be less demand for software development skills because most of the hard work has already been done, and we have better, more high level tools. The only reason we see demand for software developers growing is because we let the bad developers in :) Bad developer can easily generate 2 FTEs per year, by introducing subtle bugs in code that someone has to find and fix. "
Anyone here has the actual source ?
If you believe in the Jevons paradox [1], you can explain it without reaching for "bad developers".
[1] https://en.wikipedia.org/wiki/Jevons_paradox
Most work going on is feature work in my experience. Not bug fixes.
A new feature will take longer to implement on top of a badly designed or misbehaving dependency.
Where do you work and are you hiring?
You're assuming that management actually cares about fixing bugs.
There's a much more obvious resolution to this problem that applies to the economy writ large.
Ye no. The reason is not Javascript framework churn. I feel the notation that the software field change fast is a MBA take on it since the in fashion key words change name all the time.
I guess the underlying reason is that engineers wont be promoted to (real) chief engineers with agency. Being a boss requires reports for some reason. So experienced people leave sweetshops to escape the grind when they get fed up.
> I guess the underlying reason is that engineers wont be promoted to (real) chief engineers with agency. Being a boss requires reports for some reason.
Sadly, this is absolutely true. Manage or be managed. Capitalism invariably becomes corporate (if unchecked, monopoly) capitalism which invariably becomes managerial capitalism, in which people are assessed by their position in the tree structure rather than anything they do, and 0 reports |= loser.
Unfortunately, if you think you can take on a middle-management role and also do technical work, you're probably wrong. Middle management isn't hard but it's super time-consuming, if you do it right (that is, if you care at all about the people you're managing, although you won't have much ability to protect them as you might hope for, because PMs). You'll barely know what the people under you are doing (most managers'll admit this in private) because so much of your time will be spent on meetings and political bullshit.
To me it is acceptable if the management class is drawn from tech people. MBA people are largely.. not the type of person I am interested in being managed by.
Big tech that I work at generally doesn't have MBA type managers and it is good.
> Programming-related jobs have high rates of skill turnover
True, but there are fundamental patterns that remain the same. And if we are talking about the level-of-abstraction type of change, then having experience in the underlying techs certainly helps.
One of the things the article is actually measuring is that nobody hires based on deep knowledge on the profession.
Many software positions do not account for the opportunity cost of learning job-specific knowledge, or soon-obsolete knowledge, making it hard to justify the investment in the long run. With pressure, the human capital will also erode faster, leading to a situation where more fresh blood is needed. Consequently a smart software company need a mechanic to maximize learning RoI for its workers, else the best choice for them would be to leave (even a job they appreciate). So called "accidental complexity" is almost always low RoI.
I retired a bit early and I have found it immensely rewarding to take classes in various hard technical subjects. Some of these are directly applicable to jobs I could do, or have done. I think tech employers should be more supportive of life long learning. I get dinged by recruiters constantly because my resume is great but I'd rather do this, TBH. I have worked in FAANG btw. Retired at principal level.
Hey! I'm trying to plan out my career a bit and I was wondering if I could pick your brain a bit. There's an email that can get to me in my profile, if you're willing to give me some advice :)
I think the profession is too new for the research data to really make sense. The sample size of devs with 20y of experience can't be comparable to that of the devs with 2y experiencie. I think the statistics from the paper stop making sense with the higher ages.
I'm 26 years old. I have no idea what my future looks like. Neither do other people my age.
> The highest ability, fastest learners disproportionately leave the field over time. They have a multitude of other ways to profitably leverage their intellect and skills. Software development carries serious opportunity cost.
Curious where some HN users have gone when they left software dev, especially if it is something other than management of some type.
This is super interesting. One of the reasons why I got to develop my strongest CS skill into Smalltalk (a puristic niche technology) is because I've understood that working with it makes easier the maximization of what is timeless and the minimization of what ages faster than fish out of the fridge (libraries).
Just wait for gpt 42, it will be better than most of us at coding.
As a software developer, you are going to use gpt 42 to develop software. You will probably write a lot less code manually, but it’s not a bad thing.
Perhaps, or maybe gpt models will reach AGI capabilities way before version 42, and able to fill every role in a corporation, from CEO and down.
If we assume one version every 12-24 months, GPT 42 would arrive some time between 2060 and 2100.
4 replies →
Just wait till you have to debug GPT42-generated code produced by offshore subcontractors fulfilling GPT43-generated business requirements beamed straight down from Orbital 4B.
By "debug", you mean shooting up all the drones that ended up being created with some instruction that had as a side effect that humanity would go extinct? (Perhaps something like: "Collect all H20 from Earth, and bring it to Orbital 4B")
Finally someone who actually reviews my code. Or will I be the code reviewer?
You'll review GPT42's code. Then your GPT43 boss will review your review.
1 reply →
Even better, it is really good at PRs!
Be careful this isn’t an an excuse for ageism. Skills like problem solving, debugging,, planning, … these are invariants and always useful. The language or tool that is used will change, but the underlying process remains the same.
Medical and scientific fields have continuous learning via papers, conferences, even courses that update peoples skills. Also, there’s new ideas and methods coming in with new people who then get involved in the skill exchange once hired (latest synthesis ideas vs. Picking up medchem).
And it seems to be panic buying and selling in this field - inhaling anything with a pulse 5-7 weeks ago and now trying to lay off half the staff today or next week. Same problems, same market issues.
And if the damned SWE’s we’re valuable they’d give them proper working conditions. As somebody wrote, lawyers don’t do jira tickets.
> Programming-related jobs have high rates of skill turnover. Over time, the types of skills required by companies hiring software developers change more rapidly than any other profession.
There's a reason I still strongly prefer candidates with a computer science degree to someone with 9 months at a bootcamp for some roles. New tools, frameworks, programming languages, and libraries constantly enter this industry. I believe knowing the fundamentals and having a deep understanding of how computers work allows you to more quickly pick up new things.
I understand there are curious graduates that come out of bootcamp programs who will dive deep and fill in the gaps and there are universities with subpar computer science departments. I still prefer the latter in general cases.
Discussed (a bit) at the time:
We Will Never Have Enough Software Developers - https://news.ycombinator.com/item?id=24910949 - Oct 2020 (10 comments)
I live in France, I have been able to write c++ for ten years now, and it's not like employers want me.
I might not be the best developer, and France might be a bad job market that always requires a degree, but that's my reality.
An ass-clown engineering director/manager I had, proudly shared a chart – I guess it was from something related to the post - that at the current rate, everyone in the US will need to be a SWE at Amazon for it to continue to grow. I can't tell if that case is true or not and I don't remember the time frame, but I have a suspicion SWEs will instead have to work smarter with better tools and languages that effort "multipliers". x10 languages, and tools perhaps.
With OpenAi (and other comparable technologies) able to semantically understand "write fast and efficient C code for a prime sieve" and generate fairly impressive C code, I'm no longer sure I agree that we will never have enough software developers (after watching this, made me get just a little nervous as well as excited about the future of our industry):
https://youtu.be/k_EF42H2ZC0?t=187
I'm very curious about how this "AI writing code" thing is going to turn out.
I have not tested AI myself for producing code, but I toy a little (ok, more than a little) with various GPT instances to write prose. Sometimes it's great, sometimes it's poor, but:
1/ It never gets anywhere: there is never any resolution
2/ Sometimes it just loops, takes up a clue from itself and produces the same set of words indefinitely.
What I do is generate, survey, and then edit. It's a great tool to get new ideas. But how could this work for code that's supposed to accomplish something?
Code is famously much harder to read than to write; that's why people always prefer rewriting than refactoring. With code-generating AI, all that's left for humans to do is the reading, understanding, and monitoring parts.
It's a difficult job, and if done by incompetent youngsters, I think pretty dangerous too.
What OpenAI does is regurgitate stuff it's seen on the internet.
These things are basically a glorified hashtable (with compression).
Much like what a google query does when it leads you to a chunk of code in stack overflow.
Luckily, there's much more to what SWE does, and it's high time people stop believing that AI is at the level where it can do the job of a SWE, it's ridiculous.
Or to put it in a way that's perhaps more clear: Go ask OpenAI to rewrite to GUI of FreeCAD to be usable, see what it comes up with.
My first initial reaction was: did the computer write that code, or is it cribbing code from Stack Overflow? While the latter is problematic for developers who do the same, it is not a problem for developers who have to write original code or where the code has to be verifiable. If it is problematic, it would also say a lot about what the industry has evolved into and would probably be why so many people are leaving it (even if AI could not take over, less experienced and less expensive developers could).
How often in your career has the problem been that well articulated?
Or for that matter, how often in your career has the problem been an example problem that people use to showcase basic examples of their programming language.
Prime sieve is almost definitely in the top 10 of most written and published programs ever.
Interestingly enough at the end of the video he asks the AI to write some code that makes money. And it responds with "maybe try investing or not spending money". This is much more in line with the type of questions I get asked in my career and somehow I doubt I would still be working if I had answered the same way seriously.
This is a super trivial example of a very simple algorithm that doesn't have to interact with any other systems. It's almost certainly copied directly from the training data as well, which is fine for an educational toy example, but generally a violation of copyright.
I've been quite happy with Github Copilot but it is not remotely useful to a non-programmer.
The problem space will just shift and the market will demand much more and much better software.
> perennial labor shortages unless the pace of change slows sufficiently
This frames it as a one-way cause and effect ("unless"). I wonder if the "dropout of fast learners" that _causes_ the labor shortage will in turn _cause_ the pace of change to slow!
I think it follows that an industry full of slow learners might have a lower propensity for introducing change (i.e. developing new frameworks) and adopting change (choosing a new framework over one I'm already comfortable with).
I started programming in "high-level languages" like Pascal, Lisp, Smalltalk and Prolog. I then had to do a project in C. It felt clumsy at first. But then I got it, the pointer arithmetic, and I felt empowered by it. I felt "closer to the machine". The machine felt more like friend. I felt "C doesn't lie" because its computational model corresponds so closely to the hardware. Just saying most any language can be fun.
a more accurate state:
We Will Never Have Enough Teachers
Backend Devs have to teach themselves as the techniques and languages and tools dramatically change over time.
Front end Devs have it twice as hard as we have to teach ourselves while at the same time use design to teach the app end user.
We are in one of the professions where teaching is the core of the profession.
I'm predicting this to change somewhat because of remote work.
The lack of geographic barriers is going to change this curve for a lot of "dark matter" devs in the hinterlands.
We have far too many.
The industry should better evolve to empower everyone to "code" tools for themselves.
Can you name all the tools you use to develop software? Just thinking about it makes me tired.
Why would I work at 50 when I retire at 40?
There isn't a shortage of software developers. The pay isn't great--the kids getting $300K packages out of Stanford are an exception; it's a marketing expense. In fact, if you control for the level of intelligence it takes to be any good, SWEs make less (and get far less autonomy--do you think lawyers work on Jira tickets?) than any other professional, and they hit a salary/challenge plateau quick... after which, they increasingly face ageism.
People leave because the job sucks. I don't mean that programming sucks; I quite enjoy it. Computer science is still an engaging field worth studying, and research programming isn't bad at all. Corporate SWE is pretty awful, though; you get paid far too little and treated far too shabbily to justify spending hours dealing with bugs and bad decisions that exist not because you're working on hard problems (after all, I've generated my share of bugs and bad decisions) but because of inadequate processes, mindless cost-cutting, generic incompetence, and an overall lack of care, especially at the top. All of this, to make a barely middle-class salary while people who are already rich and connected make millions off my work? No thanks. 2.25/5, would not do again.
Cry me a river. Software development is some of the easiest, highest paid work in history. The majority of the population is grinding away in tough physical labor or abusive service jobs getting paid pennies while software devs moan about only making low six figures and getting a few boring jira tickets while they sit in their home office reading hacker news for half the day.
On one hand, I agree with you that on the whole we're a bunch of spoiled crybabies. Totally grant you that.
On the other hand, saying that the majority of the population is grinding in tough physical labour is just not true. Most other jobs are generic office jobs that don't need to be done (just like 80%+ of software engineering jobs don't need to be done).
Most of us are just doing things for money. Are most people working hard? Not usually, because it mostly doesn't matter. Spreadsheets idle in inboxes, meetings lead nowhere and achieve nothing, brown-nosers and family members get promoted into jobs they're incompetent at. And the world continues to spin regardless.
13 replies →
I can't get on the "It is a hard-knock life for Software developers" train. We are very-very well compensated, and we are insufferable.
I do understand the issue. Humans are prone to complain about any slight whether real or imagined. Millionaires will complain about not having enough money, A-list celebrities will complain about not having enough visibility, sports stars will complain about every foul play.
Money just does not lead to life satisfaction, only craving. I just have to accept that this is the human condition.
14 replies →
> Software development is some of the easiest, highest paid work in history.
Nope this is an outdated opinion. You can do just as well or better in trades (source: my electrician buddy). If you’re referring to the FAANG salaries (sub 1%) you’re comparing to doctors, lawyers, entrepreneurs in terms of opportunity cost. Your average joe programmer isn’t killing it like you seem to think, and they’d do just as well in trades or middle management.
The cynic in me thinks this is an opinion promoted by employers, just like the BS “labour shortage” headline.
17 replies →
This seems to be a perspective that's exclusively silicon valley (perhaps large parts of the US) based. Not at all true in Europe at the least. Not that it's a bad job by any stretch of the imagination, but even low six figures is really rare in the EU for Software Development.
Easiest is also highly subjective, if your job is making wordpress templates/sites then sure. If you're working on complexer systems then this statement is horseshit. I've done physical and service jobs that were both easier than the software development I do, only difference was that the physical job was also physically exhausting.
19 replies →
There's absolutely zero point venting out frustration on fellow working class members when upper management and up are actively trying to reduce costs by cutting headcount and/or wages relative to profits.
This race to the bottom is how software devs will become the new "teacher shortage", and how wealth will continue to funnel to the upper classes with those on the lower end unable to climb up.
Yeah indeed. Coming from someone who had to work with physical labor before I started programming, software developers don't know how good they have it.
"The pay isn't great", "treated far too shabbily", "dealing with bugs and bad decisions", "inadequate processes" and so on, sucks when development is the only thing you've dealt with, but you have no idea how it is to actually have a blue collar job if you're actually complaining about those things.
I think cs137 and others like them should try to have a part-time job at McDonalds (or whatever that is not in front of a screen), because it will make you love your software engineering job again.
5 replies →
> Software development is some of the easiest, highest paid work in history.
I joked with a girl yesterday when she asked me what I did. I told her: "I'm a dude that's paid way to much to sit in his living room and make websites and apps".
Not everyone will make $300k per year, but you'll probably still make way more than most other professions. Teachers make like $70k in good places, often times much less. Here we are sitting in our pajamas at home changing the background color of a button and making twice as much.
So many things I have to disagree with. Not all software engineering is easy, particularly the highly paid variety. The six figure salary is diluted by spending weekends constantly having to learn new technology off the clock. Companies then expect senior engineers to mentor other engineers and give presentations of their technical challenges, debasing the value of the knowledge gained working off the clock. Manual labor jobs don’t typically require the student loans software engineers have to pay off, further offsetting the salary gains by years. Manual labor workers get to go home and be done at the end of the day and aren’t tacitly expected to be available at all hours. It may not be the worst industry but it definitely is not a fun industry to work in at a lot of companies. It has one of the worst interview cultures on earth probably and the more years I work the more I see the obvious flaws to the point where I want to leave.
9 replies →
Well, I think the parent is comparing software engineering to other white collar professions like lawyer.
In my opinion comparing SWE to blue collar work like construction is apples to oranges. Ofc the blue collar work is harder and more demanding physically.
It’s better to think about whether software engineers are being compensated fairly relative to other professions like lawyers.
I think they are given that wages seem to be governed with supply and demand. On one hand I don’t make as much as my sister, who is a doctor. On the other hand, I make enough/comfortable money and don’t have to deal with the liability/responsibilities/obligations of being a doctor or lawyer, and I can work from bed naked should I choose to do so.
8 replies →
Hmm what makes you think software developers are not abused? Maybe in your world they are not, but it regular to hear about devs working 12-14 hours a day. With bosses and clients harassing them even at off hours.
6 replies →
No one talked about service workers. These peoples are exponentially more fcked than any of us can ever be. There is still a too large gap between employee and CEO / founder compensation in our buisiness, despite six figure salaries and yes, it is worth complaining about and fighting for.
I think sales is a much better gig than software engineering, personally.
Any engineer who has enough EQ and people skills to give some demos on Zoom is going to find that Sales Engineering/Solutions Engineering is an easier job with more earning potential, all with no on-call rotation.
On top of that, the company treats you like you're valuable rather than a cost center (especially relevant to people doing infrastructure and IT engineering). Sales teams go on vacation to team-build, engineers are shoved in a conference room with some lukewarm sandwiches.
> Software development is some of the easiest, highest paid work in history
In US for sure. But there are many other places where you get a better balance between learning/working/salary in other jobs.
Not to mention the notoriously higher rate of burnout in the industry, even in the US.
The people in this threads making huge overgeneralizations might be indeed overpaid.
Your comment already has a lot of responses but one thing I didn't see mentioned is about the tough physical labor. It is often neglected that working at the computer is really bad for your body. Sitting for hours is unhealthy and creates all kinds of problems: obesity, disc prolapse, bad circulation, so much more. Also your eyes suffer a lot and become worse much faster than in most other jobs.
I agree that being a SWE is certainly not the worst thing in the world but it has also a lot of bad properties that often are overlooked and the most positions do not have moon salaries, that we see on HN regularly.
Also to do whatever lower income job you don't need to study for 5+ years (master). You need to compare with jobs that have similar requirements to your education.
4 replies →
lol yes this is a good point. We should all volunteer in a hospital or police department for a few days to get some perspective... And another thought: many jobs descriptions list any technical novelty under the sun even though only some small project in some small team somewhere in the company uses it. Why? To look more appealing to job seekers. It's much cooler to describe the job as PHP + Elixir + Kafka + Big data than simply PHP - which is mostly what the job is about.
I'm not denying the field is changing fast, it is. But there's other reasons why 50 year olds are pushed away besides some imagined inability to keep up.
In comparison to the majoritiy of the population it truly is a nice job, though if you ain't working at FAANG your pay can be lower compared to e.g. a mechanical engineer
Username checks out. I laughed so hard and I recognize myself in the description. Just an awesome comment.
What they expressed is not contrary to what you express. They said the expected salary conditioned on intelligence for SWE is lower to that of other jobs, and I am inclined to agree. If you include game dev jobs in SWE then it goes even lower.
Agreed. Software devs have had it easy for a long time. I hope that doesn't go away but it is true!
Oh yeah, every dev in the world makes $100 000 minimum per year, sure. And it's boring and easy with reasonable deadlines and appropriate vacations and time off work.
2 replies →
This is... To be charitable: uninformed.
As a civil engineer: I assure you my studies were QUITE rigorous. The job is very demanding, and I assure you the complexity can be very high, the consequences of mistakes are severe and occur over a massive variety of time scales. I had to work for four years apprenticing under licensed engineers after school and pass no fewer than four examinations, and get 4 licensed engineers to personally vouch for my work before getting licensed myself as a civil engineer. I am personally liable, in perpetuity, for loss of life injury or property which occurs as a result of work that I put my stamp on.
As a licensed P.E (who is, dare I say, fairly talented amongst my peers even) with a total of 8 years experience, do you know what I get paid to deal with that complexity and liability? About $80k in medium cost of living area for 45 hours/week. That's not atypical. Does that "control for the intelligence" required of the job?
80k for 8 years of experience with a PE is a bit low. You should be cracking six figures by now if you’re structural and coming close if you’re actual (roadway) civil. Are you in materials testing? If so, obviously you should try to switch over to an inspection gig to get some of that sweet overtime. I was clearing something like 110k salary at similar experience back when I practiced and quite a bit more with my equity/COLA/bonus, but I was in a high risk niche field. Not sure where you’re at but any market of reasonable size should be able to support you getting a raise, especially if you’re actually as good as you think.
I agree with everything you say. Software engineers (most should not even be called engineers, they’re coders or developers and on the same level as a lab technician to me) are prima donnas whose mathematical and scientific backgrounds are (on average) at least one level of education behind any actual licensed engineer/professional making half as much. And their degree of liability is infinitely lower, as you note. I’ll probably get sued or be involved in a lawsuit for my work another half dozen times before 2032 even though I haven’t stamped anything in 3 years.
2 replies →
Wow unfair, is it because you work for the public sector that the salary is mediocre? It is not a bad wage but indeed sounds like the salary should be 50% higher.
1 reply →
Many lawyers have to religiously time track everything. Because hours attributable to a specific client are billed and billable hours are where the revenue comes from.
On the other hand, lawyers knowledge of the law and legal procedures doesn't become stale after a few years.
"Requires 20 years experience in the Affordable Care Act" - Said no law firm ever
2 replies →
This happens for quite a few software engineering jobs too.
It's not the 6 minutes I heard lawyers do, but I definitely have been asked to track intervals of 15 minutes.
1 reply →
No SWE has been audited for pointing their JIRA ticket too high.
1 reply →
SWE's are not the only ones that think that their pay is low compared to their intelligence level, their education level, how tough, inconvenient or important their work is or what they feel they deserve for some other reason.
For instance, I'm sure there are plenty of HR managers in various companies that are secretly furious about all the young young mostly males, mostly white or asian, still in their 20s, join the company and make more than they do.
I'm sure HR managers know that the majority of jobs they are hiring for are different from the job they're in, with different pay scales and demographics.
Infact I'd say it's their profession.
2 replies →
>SWE's are not the only ones that think that their pay is low compared to their intelligence level, their education level, how tough, inconvenient or important their work is or what they feel they deserve for some other reason.
Sure, but it doesn’t mean some or all of them are not right, especially when the unequal distribution of wealth is well known and documented to evolve for the worst.
https://en.wikipedia.org/wiki/Distribution_of_wealth#Global_...
4 replies →
Why would the ethnicity or sex matter when these HR managers would still see the same differences regardless of ethnicity or sex?
Either way, I'd think twice about putting HR managers as victims here when they are the main perpetrators of low raise budgets and high hiring budgets.
10 replies →
You're not wrong.
https://m.youtube.com/watch?v=WkKHupWzB-g
1 reply →
HR managers are rarely ever intelligent. The work they do doesn’t require it and intelligent people don’t want to do a job where they’ll be surrounded by lower intelligence people.
5 replies →
> do you think lawyers work on Jira tickets?
LOL, a lawyer in my family does. He actually meets with a whole group of lawyers every month or so and they all do a retrospective to figure out how well applying agile/lean/whatever principles to their firms has been working. He actually feels it gives them a real edge.
I've suggested this to my lawyer wife more than once. The problem is that she works for multiple partners with no visibility in to each other's tasks. So each partner thinks they can have 100% of her time whenever they want, and get upset when that turns out not to be true.
>> SWEs make less (and get far less autonomy--do you think lawyers work on Jira tickets?) than any other professional
Nurses are professionals too, and they will never see anything close to $300k/year.
The intelligence floor for becoming a nurse is low, so nurses have extremely large variance in their intelligence, knowledge, and training. Knowing someone is a nurse doesn’t mean you can assume they are pros. Some nurses keep up with the latest medical research papers and are overall similarly knowledgeable to doctors, and some know less about biology than I do and will tell you about vaccine conspiracies and how some homeopathic nonsense will help you. I’ve met people at both ends.
Lawyers work on "discovery". Requesting and sifting through piles of documents. The jira ticket doesn't seem so bad.
In general to me the whole process of getting the degree, the bar and then the actually work and the pay unless you make it seems like rather bad compared to how easy SWE or related work can be.
The school is laughably expensive for something that should in reality be rather cheap. Read books, listen to lecturers? No laboratory work or practical experience and so on, clearly overpriced. And the studying to get approval of cartel? And then end up working for rather poor compensation for quite a long bit in career... As the pay is bi-modal, yes partners rake in money, but they also need to get the clients. But the people doing bulk of the work aren't that well paid.
1 reply →
Agreed. I made more from owning and living in a house than I can possibly save from SWE job.
It’s housing that’s the anomaly there though, not SWE salaries.
5 replies →
How do you make money from owning and living in a house?
12 replies →
>SWEs make less than any other professional
Except for almost all of them. Aside from a few exceptions (doctors, laywers), everyone else makes significantly less. A structural engineer with a master's degree for exemple will makes less than half (closer to 3 - 4x in my region).
Lawyer pay honestly isn't that great. I know lawyers who went to top schools and routinely work 60-80 hour weeks to make as much as SWE do.
The lawyers who didn't go to top schools became public defenders etc and make about 70k a year and are saddled with a quarter million dollars in law school debt.
>do you think lawyers work on Jira tickets?
Yes, I more or less think they do. Unless they are a headliner or founder of their own firm.
Lets say you are a lawyer at glob corp, and they get sued. Do you really think you can say "Eh, the other guy has a point. I am not going to defend this one."? You either work the case defending glob corp, or you are no longer glob corp's lawyer.
> The pay isn't great--the kids getting $300K packages out of Stanford are an exception; it's a marketing expense.
You don't have to make 300k for the pay to be great. Even if you fall short of that and land at a company that only pays you $120k, you're still making a killing compared to most other professions.
> Corporate SWE is pretty awful
Then get out of Corporate. I work for an SMB, make about as much as I used to in Corporate, but the stress level and workload makes is much easier. Everyone want's one of those SWE jobs for a company that is in the news, but in fact you want the exact opposite. You want a low profile job at a company no one outside your niche has heard of. The pay is about the same, work is 10x less crazy, and if you disagree with a decision, usually you know the person that made it because the company is only about 200 employees.
> SMB
I think the signal:noise ratio isn’t great in this sector. Although corporate is 100% guaranteed misery, I have yet to come up with a reliable way to find SMBs where IT (because that’s how they call it, a SWE is the same as the help desk in their view) isn’t considered as “the geeks working the cost center in the basement”.
Do you have a method or did you rely on blind luck like the rest of us?
I'm optimistic growing remote work means extending the working life of an SWE (counter to ageism).
Most companies with good pay have a decently high median age for senior SWEs.
I'm not sure why anyone 50+ would want to work at the vast majority of startups...
so, de-aging video call filter?
> do you think lawyers work on Jira tickets?
Probably not, but instead they get to bill their working hours in 6 minute increments. And they have to bill a high number of hours a day. Praise yourself lucky if you don't have to do that!
> do you think lawyers work on Jira tickets?
LOL Jira has nothing on billing in 15 minute increments.
> do you think lawyers work on Jira tickets
You want to represent a murderer, rapist or a Bernie Madoff? Lawyers deal with an order of magnitude more BS. You may feel bad when you work on a dead end feature. Imagine if your representation let a rapist walk.
What's the alternative though? What other "career" change can a SWE make that will make them even close to what they used to make?
What about escaping corporate swe and working for oneself?
Average salary for a software developer in the US is over $100k/year. For a 30 year old, that would put them in the 95% income percentile, or 87% for a 40 year old.
The comparison to other lawyers is weak because becoming a lawyer requires a hell of a lot more education. You can become a software developer without even a having a college degree.
You are also ignoring other professions like nursing. Nurses make far less than software developers and work a hell of a lot harder. Same with teachers.
As far as barely making a middle-class salary while rich people get richer off your work? Welcome to capitalism.
You could work two easy software engineering jobs from home in parallel and double your income though.
Good luck if you spend 40-70 % of your working time in meetings and pair programming sessions, like I do.
If you're not getting paid enough, have you tried leaving your job and finding another one?
buddy our goal is to make their professions just a shitty and atomizing as ours. it is the way (the faster the better). the professional class are an impediment to progress idc how mean that sounds.