I'd love to see a survey of what developers do as they age, how many leave the industry, why, and to do what. I'm 43 and I'm the oldest person on my team by around 5-15 years. My manager is younger, my coworkers are younger, even my manager's manager is younger.
Earlier in my career, most people I worked with were older than me, which makes sense, but what happened to all those people? Did the industry just expand so much that I can't find them? Or did I just join a company that attracts younger devs?
I know for me, I'd like to still be programming when I'm 50, but I'm already souring on the "working in a medium to large company" aspect. The coding is still fun, and the money is great, but the process of making software in the context of a corporation isn't.
Sample size = 1, I'm closing in on 50 and moved from programming to product management and then project management about 10 years ago. It was a significant compensation hit, and the skill gap took a lot to overcome (I am a much better programmer than project manager), but overall I am happy with the change. I took a look at my trajectory in my 30s and didn't like what I saw:
1. I didn't want to be a JIRA ticket monkey for the rest of my life, and people management seemed way out of reach.
2. The "win the battle, lose the war" pattern of projects started getting demoralizing: You're developer #21190 on the team, make the best technical decisions in your little corner of the product, but after a year it gets canceled or fails because some decision maker way above you on the totem pole blew a deadline/estimate by an order of magnitude. It's tiring to do your best work on projects pre-doomed to fail.
3. Work life balance sucks as a developer. I spent countless nights working through to 2AM to meet my ever-increasing ticket goals.
4. The technology-of-the-month treadmill gets you nowhere. I'm all for learning new things, but the constant emphasis on switching to a new fashionable framework just because it is new and fashionable, and just to put another keyword on your resume, is IMO a waste of learning.
All in all I felt like a well-paid cog under enormous pressure to always be cogging harder.
> All in all I felt like a well-paid cog under enormous pressure to always be cogging harder.
This is why I've found myself gravitating toward smaller companies. Though I've done a stint or two at some bigcos (100k+ folks) I've almost always been happier at smaller companies (<100 people). You can see the results of your work more clearly, there's less process, and when a teammate isn't making the cut, it's clearer (less room to hide).
They aren't as sexy and well known, but if you can find the right smaller company, you can still be compensated pretty well, find technical challenges and grow.
Sure, you may still be a cog (you're an employee, after all) but you're a much bigger cog in a smaller machine. Yes please.
For us not-so-young folks with family and a clear division between work and life, small and medium companies are the best; you can feel the impact your decisions have, and there's always room for improvements and innovation. Startups and large companies are too stressing for different reasons.
Re #3: this has been my experience almost my entire 10 year tenure as a software developer. You start out doing a few stories, hey this is easy. Then they get harder (ooo we're starting to pack those two weeks now! Hope I get a good bonus for this, it's exhausting), then eventually you're tracking down acceptance criteria for your own stories (what happened to the project manager?! I can do this though, I'm senior level, no problem), then you're getting support requests for other devs and more and more work, scope creep, debugging, etc...
And any request to "follow the rules" (what if we had AC before stories started? what if we defined who would do that and gave them time to do it? what if we didn't change or add stories mid-sprint? can we discuss why that overtime happened the last few times so it doesn't happen again? Sure, bring it up in the retro... but we won't be willing to change much, sorry) leads to you being increasingly shunned and disliked.
Does anyone have solutions to this? It seems like most people solve it by moving up the ladder, as ICs generally aren't treated well in most places, and when you can delegate you hopefully can get back to 40h/wk.
> then eventually you're tracking down acceptance criteria for your own stories (what happened to the project manager?!
Lol depending on the product owner I get anywhere from "some nice stories and design mockups" to "there isn't even a document describing the requirments and I have to write my own stories for bookkeeping purposes."
I definitely can relate to Point 4. I think one way of countering this is to focus on a platform versus the base technologies. In particular, I am thinking along the lines of doing development work with the likes of Salesforce, Microsoft Dynamics or SAP. The years of experience are valued more and the rate of change is inherently slower. The obvious downside is that the development work itself may not be as interesting but that can be mitigated somewhat on the projects one takes on within these platforms.
I agree with all your points, although I'm lucky that where I'm working today, #3 is not an issue, but it has been before.
I absolutely agree with #2. I definitely got demoralized over the years when I realized even if I did a good job, the project could fail in so many other ways, often due to decisions much higher up in the chain.
All these issues are harder to live with as you mature. You can live with them a bit more when you're young since you're still naive and may not be aware of them or even care.
I think it's possible to stay a developer without being just a ticket monkey, but it's certainly true that not every organization is prepared to grant developers greater autonomy[1].
There is a case to be made that since the number of programmers are increasing to the point of approximately doubling the number of programmers every five years, every old programmer could still potentially be active in the field, but constantly be more and more obscured by the ever-increasing mass of new programmers, and all the programmers you see around you should have on average less than five years’ experience. In other words, nothing happened to those older people, except that they are now dispersed among an ocean of new programmers.
According to this BLS report [1] in 1989 the US had 739K "computer and data processing" jobs. By 1999 it was 1830K. Wikipedia say there were nearly 21M "software developers" by 2016 [2]. I'm pretty sure our industry hasn't gotten any smaller so, basically, we just got really diluted.
I'm in my mid-50s, and have been programming professionally for over 30 years. I'm not the oldest or most experienced person on my team, though!
I have no intention to stop programming. I don't program because there's money in it, but because that's what I truly like to do -- so the thing that attracts me to certain positions isn't pay, but how interesting the work they're offering is, and whether I'll learn new things from it.
The question I face isn't if I will me doing development in the future, it's if I will be doing it at the place I currently work.
Purely anecdotal, but many of the older Software Engineers I know in the Bay Area "retire" or "FIRE" in their early-to-mid 40s -- i.e. they are financial secure and they choose to either (a) move to a LCOL area and stop working entirely, or (b) they forego W2 income for side projects and part-time work -or- work on passion jobs.
I'm a middle-aged programmer. I read only the beginning of this article and I didn't want to continue.
"- little or no required education": maybe, but only for the rare prodigy. "Software engineers" without an understanding of math and some amount of formal computer science are necessary evils rather than assets. Or are doing low-level, low-thought work.
"- No health or legal risks": a software engineering career will mess your body up bad if you don't intentionally work against that. For those of you who are young and don't believe me (and are programmers, sysadmins, devops, or otherwise spend all day on a computer), come back to me in a decade or so.
> "- little or no required education": maybe, but only for the rare prodigy. "Software engineers" without an understanding of math and some amount of formal computer science are necessary evils rather than assets. Or are doing low-level, low-thought work.
The key here is required education. You will be expected to have certain skills, but how you acquire those skills is up to you. At one past job, there were 6 developers on my team, and only 2 of us had CS degrees. The others had degrees in physics, bioengineering, electrical engineering, and one without a degree. In contrast, every doctor you meet will have a medical degree, and every lawyer will have a law degree. Both of these are expensive and require years of post-graduate education.
> "- No health or legal risks": a software engineering career will mess your body up bad if you don't intentionally work against that. For those of you who are young and don't believe me (and are programmers, sysadmins, devops, or otherwise spend all day on a computer), come back to me in a decade or so.
There's a difference between a job that literally wears your body down (construction, for instance), and a job that can lead to health problems because of a lack of physical activity. There's nothing you can do about the former, while you can address the latter by finding time to exercise a few times a week.
I programmed for a long time (decade or more) before I went to engineering school. The difference in understanding is night and day. Like I said, if the programmer is doing relatively low-level tasks, they won't understand their deficiency.
> There's a difference between a job that literally wears your body down (construction, for instance), and a job that can lead to health problems because of a lack of physical activity.
You don't think of yourself as a person who works with their hands, but you do. I had a bad habit of hitting keys on a keyboard really hard (due to a few early keyboards I had to work on). That can wear your body down, too - especially your fingers.
There are no direct health risks. What hits you in old age is not programming but bad habits - bad posture when sitting, too much sitting and not enough physical activity and excercising, and others. Those are possible to offset or fix. Comparing to manufacturing where you have same or similar bad habits as well as direct health risks of something or somebody accidently hurting you. Programming therefore can be considered to be without health risks.
> "Software engineers" without an understanding of math and some amount of formal computer science are necessary evils rather than assets. Or are doing low-level, low-thought work.
I read this as the author talking about a career change from programming--not describing the requirements to become a programmer.
I have been doing computer work for over a decade. no discernible health effects. That could change, but I would say it is less risky than a manufacturing job. The data clearly shows that some jobs have a higher risk of occupational injury than others.
It can come on quickly. I'm at over 30 years experience now and once, about 11 years ago, my shoulder just started having this shooting pain almost immediately whenever I sat in typing/mousing position. It was kind of terrifying. At times, it was so bad that I legitimately thought that I might have to give up sitting at a computer. I ended up investing in a better chair, focusing on better posture, taking breaks, doing exercises, and also switching my mouse to the left side for about 6 months (the pain was in my right shoulder and was particularly bad in the mouse position, so I thought learning to left-mouse would be a good idea). Ultimately, it worked out, but I had to make some pretty serious changes to make that happen, and now that I'm in the better habits, I wish I'd made the change much earlier.
> without an understanding of math and some amount of formal computer science are necessary evils rather than assets
I mean it's not like you need to be a prodigy to pick up enough math and computer science concepts without a formal education.
I'm a high school graduate and I've made it far enough to be an L6 at a well known tech company. I'm not prodigy, I just I spent large amounts of time coding over the years.
And I certainly don't consider what I do low-level, low-thought work, even though I can't invert a binary tree without looking it up.
If someone who's from a more traditional background grills me on CS topics they'll probably find me quite lacking. But the reality is, prodigy or not, if you're curious enough to teach yourself programming, you're not going to suddenly fall short trying to learn "enough" of the math and formal CS stuff.
Enough to me is not being able to whiteboard implementations and manipulations random data structures, but rather knowing which ones exist and when to use them... then hopping on Google to find the details.
And I mean, someone has to write the search engine processing more data than I can fathom, and maybe their work would be prohibitively difficult if that wasn't all literally on their fingertips, but there's infinitely more people doing complex system design that can afford the few seconds of context switching.
-
I find if anything people from a formal background overestimate the importance of math and CS sometimes.
It's been so long I forgot the details, but I remember as a fresh dev in my first "real" job a co-worker very proud that their refactor of a function in our hot path was working 30% faster than before.
I took one look and saw something like
void blahBlah(blahblah){ //made this faster
loadABunchDataIntoStringsUsingPoorlySizedBuffers()
processABunchOfData() //by making this very fast
}
Use a simple memory mapped file instead of "loadABunchDataIntoStringsUsingPoorlySizedBuffers" broke his benchmark. Now the "blahBlah" function took "no" time.
Stuff like that is everywhere in programming. Times where people choose the most formally correct data structure instead of a simple cache friendly array. Or destroying performance with GC unfriendly, but highly "type sound" code.
At the end of the day, to me nothing can replace time spent coding. And in my experience, people who can make it over the initial hump of difficulty in coding are people who end up spending a lot of time doing it (of course I might be a bit biased there)
> The problem is, you don't know what you don't know until you break that barrier.
How does that follow?
There's two barriers. Knowing enough to look up the details, and knowing enough to vomit it on a whiteboard.
Now the latter is much more impressive, but the improvement in useful output for even the highest tiers of devs is marginal in my experience.
After all, what the average CS grade knows after 4 years isn't theoretical physics or PhD level CS something. It's not unknowns unknowns all the way down that you need years of study to get to the surface of what is unknown.
The same can be said about the "making it far enough to be an L6 at a well known tech company" barrier. Actually, I believe this is a better qualification in terms of capacity, since it's more selective.
One of the things I love about being a developer is the sheer variety of tech adjacent jobs. I've been a developer for about two decades (in my mid 40s). In the last half decade I've worked through some other adjacent careers.
Since 2016, I have:
* been a startup CTO (a pre-seed startup)
* a technical trainer (to help pay for, well, eating, as I was building the startup
* an engineering manager (player-coach, too small a team for me to only do people things)
* developer advocate (writing, speaking, documented, example apps)
* book author (don't do this for the money, but writing deeply on a technical or engineering related topic is a fantastic experience, as it forces you to justify things that you might have been handwavey about in your mind)
All of these involved some programming, but none of them were 40+ hr/week of development. This is one of the other reasons to love software development.
I know a few developers in their 50s and 60s that are programming near full time. Some have moved from company to company, but a lot more have hunkered down at a place where:
* the work is steady, but not glamorous
* they trust the management
That's where I suspect many of the older devs have gone: to quiet, safe jobs where they can do their work and trust their management to do theirs.
For me this is the silver bullet. I'm only in my early 30s, but corporate management is a mixed bag so if there was a company where I actually had faith in the management, they'd have me for life. That said, I'm coming up on a 10-year tenure already (not always programming, but different roles within the same company), so it's not all bad.
The thing that scares me about jumping into programming today is that you realistically can't know all the layers any more. My programming experience was writing a program, and a few libraries that went with it, from scratch, in Turbo Pascal.
I knew how my code worked, and the run time libraries were simple enough that they really never caused any issues. I also spoke with most of the users of the program, personally.
Now you're expected to write "apps" that run in some random mobile platform, with almost no feedback when things break. You're depending on layers upon layers of abstraction to make everything work, it's like building on sand.
On the other hand, as pointed out, it's like that in other occupations as well.
We programmers do have a choice, however. It doesn't have to be, though. We could simplify things and remove some of the cruft.
> you realistically can't know all the layers any more
This has always been true. What you percieved to be the case was an illusion. To paraphrase myself¹: Imagine someone who started with soldering, electronics, radio, and circuits, and is just beginning with computers and programming. They would probably feel the exact way you do; that they used to know “all the layers”, but that it’s somehow becoming too large for them. Knowing “all the layers” was an illusion for them, as it was for you.
> almost no feedback when things break.
This, however, is absolutely crucial. Fast feedback loops, however and at whatever level they are implemented (REPL, fast development iterations, TDD, monitoring) are essential to knowing that what you are doing is actually accomplishing anything and not just doing cargo cult coding.
I've written compilers, and editors
I know several assemblers
I've designed and repaired TTL/CMOS based circuits
I've done NAND to Tetris
I know digital and analog electronics
I know how tubes and transistors work
I've fixed atomic clocks
There wasn't a layer I couldn't troubleshoot or understand. Things were much simpler back then.
Yes, yes, you’re the exception, the modern reneissance man. r/iamverysmart.
But could you do what the fictional engineer in The Mysterious Island did, to start from mining, smelting, drilling, making chemicals to create a whole level of technology from scratch? There’s also creating civilization; i.e. the social and legal constructions which guide and powers us as a group; most of us have a vague notion, but how many of us could create a system of law and government from nothing? There is almost an infinite stack to know. Anyone claiming to know “all the layers” is simply blind to all the layers they themselves take for granted.
Very true, though unlike a towering software stack, the chances that your hardware was going to suddenly start doing something surprising were lower (not nil, obviously, or we wouldn't have started virtualizing hw, but now any one of several package managers could take your app down).
I'd wager the most common type of developer/programmer/software engineer these days is what they call "T Shaped" [1] whereby you have a breadth of knowledge that you're somewhat familiar with, knowledgable of, or have experience with, along with deep knowledge and skill in one or a few areas. One might even say an expertise in a particular niche. I consider myself in this category where the horizontal part of the T is "fat" with more than a decade of experience in my chosen field, and a long vertical portion with deep expertise in two languages and an ecosystem. This is what the traditional generalist has shifted towards recently.
The technology world is shaped like an inverted pyramid, and I suspect that everyone's T is just a small segment of that pyramid. I was fortunate to study computer engineering at a liberal-arts university that tried to build competent engineers by training them with triangular, rather than T-shaped knowledge. The learning curve went something like this:
As the parent pointed out, it's all built on sand - not in the manner they meant, but it's actually built on silicon. At some level, physics and chemistry can teach you about electrons and orbitals and excitation. You can learn about insulators, conductors, and semiconductors. In the lab, you can get some glass plates coated with (clear, conductive) titanium dioxide, an electrolyte, and some Ruthenium or organic dyes, and make a dye-sensitized solar cell, or a tungsten wire and chip of germanium and make a point-contact diode. A little more physics and you can build a bipolar transistor or field-effect transistor.
With that physics as the tip of the pyramid, now branching out with the help of commercial discrete components, you can expand into electrical engineering. On a breadboard, you can make a NOT gate, an AND gate, an SR latch, an SRAM cell. Realize that there's a whole breadth of analog electronics, but we're in a computer engineering course, so consign yourself to a cursory introduction and again climb the pyramid to commercial 7400-series logic ICs, and make a binary adder. Realize that there are lots of 7400-series ICs, with various applications, parameters, and specifications, the pyramid is already staggeringly broad. You know how to move sideways here, but don't right now - climb up and expand further to CPLD and FPGA development boards and some VHDL, rebuild your binary adder in silicon, make a seven-segment decoder, add some load/store instructions, conditional logic, and a few more math primitives; you've got a CPU.
Now that you know how to build a CPU, go buy an Arduino, it contains a small CPU. But don't download the IDE yet, instead, get avrgcc and become familiar with AVR assembly language. Write a main.s, you can blink some LEDs or drive a hobby servo with a PID loop in response to a sensor. There are lots of microcontrollers like PICs, 8051s, and ARMs, and lots of work done in assembly, but we can't linger here - we have to keep climbing the ladder.
Speaking of ARM microcontrollers, grab an ARM dev board. You made a few function calls in your assembly programs, learn about the C ABI. Start learning C on a PC, manipulating text, once you're familiar enough with the syntax to write a "Zork", head back to the dev board and write a Forth, talk to some sensors over SPI, UARTs, and I2C. Write an RTOS, digging through Linux source code to learn about syscalls. OK, your RTOS sucks, and isn't very good at securing real-time constrains when your user code has bugs much less malicious inputs, but it's an OS, here's FreeRTOS. Hook your board to another students' GPIO (optocouplers are handy) and develop a packet network. Install uIP on your boards, and start talking Internet Protocol over sockets. Send an HTML page. Embed some Javascript. Realize that your Cortex-M0 is really resource-constrained, and set up your webpage on a VPS. Install Python on the VPS, and build a web framework. Try to keep track of data in CSV files, redo that as a database, someone already did that and it's called SQLite. And so on up the chain. Down the chain, nothing is a black box, it's all built on sand.
Every level of the pyramid is occupied by someone with T-shaped knowledge. Those just below you are writing the frameworks that you have so much experience in, they're using languages and operating systems that someone with experience closer to the hardware than them developed. Those left and right of you are using different frameworks, with a different path to the electron at the bottom of the pyramid, those above you are your clients who use your products. Further up the pyramid are people who don't know exactly how things get done, they have a lot of things to keep track of, fortunately their vendors (your clients) have software to do that.
The idea that everyone needs to have the base of their T reach the atomic physics at the tip of the pyramid is a little antiquated, even more so the idea that everyone needs to know everything below their framework. That may have been true in the 6502 era, and for a few exceptional people like Carmack or Knuth or Ritchie for some time beyond that. But few can be expected to maintain encyclopedic knowledge of the esoteric alternatives that don't lead up to their T, and no one can keep track of what every user - who may also be a developer - is developing in real time.
It was kind of like that back in the days of "shrink-wrapped" (even if it wasn't really shrink wrapped) software, too, though - I remember trying to debug problems that were specific to a particular environment on remote computer users computers before the internet. At least with apps you can build in some sort of telemetry.
But yeah, things are way more complicated than they used to be, and it takes a lot longer than most people appreciate to go from zero to productive.
I think there's a lot of truth to this, in that it's good to understand all the layers below you. But there's also some truth to the opposite: Did anyone ever really understand all the layers, or even most of them? Even if you knew all the details of how your microchip worked (weren't those details usually proprietary?), you might have wanted your code to work on other chips, or even on future versions of your current chip. At some point, we always have to close our eyes and abstract away parts of the problem behind the contract we believe those parts will follow.
You could specifically limit the processing to a microprocessor that doesn't have advanced features, and is implemented on an FPGA. You'd own all the RTL and could make a modern ASIC if you really wanted.
You can understand all the layers if the design is meant to be simplified; like project Oberon, but based on a system that runs C code (and the UI would need to be a little more modern).
You can understand all the layers, but the system has to be designed to be understood.
You can have a system that is understandable (to someone not at that layer), or you can have a system that is robust (not crash all the time) and functional (more than just a bare-bones feature set). It's the things you have to do to make it robust and functional that make it hard to understand.
As time goes by, the understandable version and the useful version diverge further and further.
I don't think that's necessarily the case, but it's a damn good point; I'd posit that a number of advancements of modern systems could be retroactively applied to a much less sophisticated "base" system and still maintain reliability, because they're born out of increasingly sophisticated programming practices that are widely established at this point (unit testing, fuzzing, even formal methods).
I'm no longer sold on "added functionality" though. I want my computers to be dumber, do less, and be fully owned; I want a 32-bit Z80 (or something like it) that runs at 400MHz on an FPGA, and a graphics subsystem that's primitive and easy to understand and work on. It won't play Crysis - fine. But DOOM, sure! (There is a killer project about a multi-Z80-core CPU implemented on an FPGA, I'll find a link to the project later)
It seems like we made this deal that we get more and more functionality, and it's set us up so that computing could be taken away from us (walled gardens, the modern internet, telemetry, software that requires subscriptions, updates you don't control, etc etc).
But you've brought up an interesting point that I'll need to consider deeply about reliability and its effect on system complexity.
I definitely want to keep making this kind of money, and if anything problems like stress have actually become less of an issue as my pay increases. Jobs that value programmers tend to understand how best to extract value from them (and death marches generally aren't it).
I also agree that the lack of older programmers has more to do with the growing number of new programmers than with attrition of older programmers (though certainly that does happen as well).
The main problem I think programmers face as they approach 50 is the "half-life" of their knowledge and skills. So much of the frameworks, platforms, etc. that we use will become obsolete in 5 years. Very little of what we have learned now will still be relevant in 20-30 years. Other professions have this problem as well, but I think few have it as bad as programmers.
It is possible to stay on top of the latest trends, but that requires some degree of fluid intelligence, and that begins to decline after your mid-twenties (though you can delay that decline somewhat by staying physically active). Crystallized intelligence, on the other hand, lasts well into your 60's. It's therefore in our best interests to make sure we learn knowledge and skills that have a longer half-life.
> if anything problems like stress have actually become less of an issue as my pay increases
That's been my experience too; pay and stress have been somewhat inversely proportional. Some of this is just a natural result of being financially secure enough that being fired isn't something I have to fear, but it's also that companies which pay poorly also treat their employees poorly in other ways too.
A lot of programming languages are also very different. In addition to standard languages like Java, Javascript, and Python, I've also done work with Erlang, Prolog, and XSLT. Those require very different mental models from a typical procedural mindset.
At the same time, learning even very radically different programming languages isn't really that big of a deal. It takes a few months at most to get reasonably productive.
Even still, it's nice to know that some of the investment in technical knowledge has paid off. I'm not just thinking of programming languages either, but platforms, protocols, frameworks, architectures, etc. Here are some examples of technical knowledge that I think is wise to invest in and can be useful for many years:
- Unix (command line and systems programming)
- Relational databases/SQL
- Internet application and network architecture
- the actor model for concurrency
- MVC
- text editors like Emacs and Vi
- discrete mathematics
- distributed version control
- UML (specifically sequence diagrams)
- tools for creating visualizations from text (graphviz, plantUML, etc.)
These are things that I have been able to take from job to job, and have been useful regardless of the programming language, framework, or platform we are using.
Anecdotal, but where I work, I noticed most of the older programmers are working on systems like AS/400. Makes sense though, many such systems are still running and functional in many businesses, and they have a skill that few have nowadays.
From what I've gathered from talking to them, IBM still provides regular updates for these systems, and while change is slower than would be experienced by a web developer, they still are learning and adapting to changes made in these updates, and have to adapt to interfacing with new technologies adopted by other areas of the business.
I tend to leverage the Lindy Effect in determining which skills and technology are worth learning: if it's been around for a long time, it probably will continue to be around for a long time more.
There are other reasons why I personally might not choose that route, but that longevity is an advantage.
I'm 55 and still a programmer. However, in my job I also do other stuff like mess with sensors, cameras, motors. Early on in my career I realized I loved programming but not in a pure SW company.
I did make the conscious decision to never become a manager of any sort, that's really hard and I wouldn't be very good at it.
Moving closer to family so I need to change job. Applied to quite a few programming jobs in the nearby city. After probably 10-15 unsuccessful technical interviews with leetcode I've decided to go back to IT.
Now that I have kids and a house I don't want to spend hundreds of hours to learn this completely separate skill (leetcode) that I rarely if ever will get to use in my job and get no joy from.
I had a similar experience in my last dance with interviews.
Even when I got good enough to solve some easy/medium problems in interviews efficiently and faster than the average, I was still getting rejection letters. Kind of a waste of time when you can make so much solo these days, but interviewing is distracting because its like a full time job, while competing against the most driven people from Asia who trying to stand out against a very large population, while I'm just casually looking for a signing bonus for the year.
Basically the only data I have is that there is just a cap on what people are willing to pay me as an employee. Like they think much harder about approving me, than seems warranted. I start to think hmmm maybe I shitposted something on social media that nobody will tell me about.
But when I go down in asking comp range, the whole experience is completely pleasant and familiar again. That's kind of annoying. Makes me want to pay fees to professional groups under the hope that they can bus me though. Seems similar to stories I've read about random athletic clubs at Stanford all joining the same team at Facebook.
What kind of solo work do you mean? It seems to me like anything without some local client is getting into a global competition for peanuts, but I would be happy to be set straight!
You can launch DAOs that automate anything these days and take a small percentage from the users of it. Just automate any small aspect of what people do and auto-liquidate proceeds for USD* so that you aren't accidentally speculating on anything, your users can pay for the liquidation too.
*Your oracle server/cron job can incorporate a broker's API to get actual USD, your DAO can only get surrogates such as USDC which is redeemable 1:1 for USD at certain brokerages.
It's a boom town. Anybody can make 3x more than what a FAANG would pay annually, and that's being generous.
> Now that I have kids and a house I don't want to spend hundreds of hours to learn this completely separate skill (leetcode) that I rarely if ever will get to use in my job and get no joy from.
Great point and I do worry about the longer-term damage this leetcode-interviewing may do to the industry. Like any echo chamber, it perpetuates itself. So those who believe memorizing leetcode patterns is related to being a good programmer (it's not) will only hire those who are like themselves, making it worse and worse.
By the time the whiteboard leetcode craze started I was fortunately old enough and established enough that I never had to deal with that early in my career. And by now I have the confidence to tell anyone who wants to do that type of interview to go pound sand. But for younger engineers it's a huge problem so I worry.
Best we can collectively do is stop doing that type of interview. Instead interview people based on their experience and based on actual day to day job requirements (which is never to regurgitate algorithms on a whiteboard).
* network network network
* don't aim for the 1% of companies that have devs jumping to join them
If you can get an intro into a company, esp a one on the smaller size, with say 10-25 devs, you can sometimes skip the leetcode madness. Or, if you do a coding interview, it's more of a 'can this person navigate a codebase or comment on a PR'. That is to say, an interview closer to the real job.
The fastlane involves interviewing for jobs when you already have a job, to get ongoing signals of what others think you are worth as well as getting counteroffers to blindside your current employer in matching or beating.
Never interview for jobs when you don't have a job, if you can help it.
In tech this is even easier because some companies allow for standing offers that can last a year (despite other companies bluffing with 24 hour exploding offers), or they have matchmaking that last upwards of a year as well.
So you can literally keep your job or be laid off and the next employer never even knew but you already had the offer from them.
I always thought there would be a huge surplus of programmers soon. The recent wage stagnation (outside SV), lots of h1bs and bootcamp craze seemed to bring on a new wave of people that was going to prove my view.
But right now there is still a shortage of devs and pay is growing, I dont understand it. It has to stop some time.
Based on purely anecdotal experience, I think bootcamps aren't necessarily putting out productive entry-level developers. We briefly hired someone as an entry-level web developer who would talk a bit about how he was teaching some web programming classes in the evenings (at the bootcamp he just graduated from). He did not have the knowledge to be to be teaching classes. We had to let him go. We have hired several entry-levels from state schools who have been very successful with us, by comparison.
Say you have 5 years of experience. Bootcamps can't create people with 5 years of experience. (They can five years from now, but by then, you'll have 10 years of experience.)
TFA is commentary, the real article I was looking for is the first link in TFA.
The original question isn’t about money at all.
In any case, what I want to be doing when I’m 50 is rather irrelevant. When I was 10 I wanted to be a pilot, but that desire went away before I turned 15.
Still choosing shitty places to work when I'm 50? No, hopefully I have exited that phase in my life. Or did the author mean something else when they typed "doing this"?
dadgum is a treasure of insight. I think I’ve read every blog post on the site (and was sad when he stopped posting). I highly recommend you read the article, he’s talking about software development and the types of headaches you’ll find at just about every level of the stack.
By 50 my ideal career would be "retired", with enough savings and passive income (from investments or whatever else) to sustain a good lifestyle for me and my family. Plus, who knows how long this software gold rush will actually last for. It may not remain as lucrative a career as it is now.
While I generally like my job, I sure as hell hope I don't have to spend the next 20 years of my life attending standups and updating Jira tickets.
Plus, who knows how long this software gold rush will actually last for.
I make no claim of knowing, but developing software has paid well at least back to the late 70s, certainly into the 80s when I started. Not the ridiculous amounts some make now, but it has always (always == "within in the working years of those reading") financed an upper-middle class lifestyle in the U. S. I have no reason to think it won't continue to do so within my (albeit, short) remaining working years.
As for the topic at hand, many of the comments strike me as not appreciating what we have. You want to know what I don't want to be doing when I'm 50? Being an auto mechanic, which is what I did a long time ago. At least one person complained that writing software wrecks your body or some crap. Man, go talk to anyone that does any kind of physical labor for a living and see how much sympathy you get. I mean, those complaining aren't wrong, but go talk to a mechanic, nurse, or any similar job that folks will work well into their 50s, see how much sympathy you get. Complaining about Jira tickets sure won't garner much. :-)
> spend the next 20 years of my life attending standups and updating Jira tickets
What's frustrating is that this is self-inflicted damage from agile.
The first not-quite-20 years of my career there were no standups, no jira-centric workstyle (we had bug trackers of course, but day to day work didn't revolve around that the way it does with jira).
Work was so pleasant, solving interesting technical problems and making the product better, just like hacking at home on personal projects. Work doesn't have to be sprinting from status report meeting to status report meeting. It never was that way before agile.
I've largely opted out of day to day programming just to avoid that unpleasant madness. But I miss it and wish I could go back to exciting hands-on programming every day, without the agile headaches.
Not sure I want to be programming forever but I’d like to manage software engineers until I retire. Hopefully in the near future I’ll be able to do it and my boss recently asked if I still wanted to manage people.
Still love programming and will continue to do some python programming around the house and tinkering with my Raspberry PIs but I’ll probably say adios to JavaScript.
I wish I read this article in 2012. I enjoyed programming, but never considered it a career. It was my passion, I didn't have any expectation or desire to make money from it.
> "passion burns out, whereas greed is sustainable
Boy do I hope this isn't true. I'm driven in my career by passion, not a desire for income (I've never been particularly money-motivated -- not saying that's good or bad. It's just how I am.)
If the passion burns out, so does my whole career.
If you love programming for the sake of programming, better to keep it as a hobby or side thing. When it becomes full time job, specially in a legacy code base, all the fun goes away.
I disagree with this, from the perspective of someone who really just loves the constant learning and puzzle-solving aspects of programming. I've been doing it for over 30 years and I feel incredibly lucky to have people throw heaps of money at me to do what I enjoy, plus I still work on side project code a few times a week minimum. I even procrastinate programming tasks I don't want to do with programming tasks I do want to do. It's pretty amazing.
The money is addictive. But so is the “working on cool new shit” aspect of it. I know quite a few engineers that bounce around from place to place to scratch that itch.
I realized about 5 years ago that I definitely don’t want to be doing this when I’m 50, and I don’t want the money to be the reason I keep doing it. Started getting very serious about income investing aside from my 401k/retirement account. My hope is over the next 15 years I will hit a point where “pretirement” will become a very real possibility.
tl;dr/BLUF: 55, recently returned to full time programming, loving it, going to keep at it quite a while.
Longer version....
I was sort of a programmer 30ish years ago (programming was a small but vital part of my job, at best I was OK at it). Moved into management, then, about 20 years ago, cyber security consulting (PIAs, TRAs, governance structures, policies, PKI auditing, some bizdev, some product management, all in the cyber space).
Just over a year ago, I converted back to full time wage slavery, primarily as a programmer, with a few other duties (hey, startup), and this after spending about 6 months mostly programming for the same co as a consultant.
One month it's React and Node and graph DBs (for the compliance product), the other it's shell and C and C++ and SELinux (for the unidirectional gateway), rinse, lather, repeat.
Lots of customer interaction, lots of iterating, no face-to-face or bum-in-seat unless I want to (or it's required for security purposes), lots of learning, lots of interesting problems.
This stuff is great.
Will I be doing this at 60? That will depend on the right balance between three things: My health, status of the profit share, and my ongoing interest. Just having too much fun right now.
Earlier in my career, most people I worked with were older than me, which makes sense, but what happened to all those people? Did the industry just expand so much that I can't find them? Or did I just join a company that attracts younger devs?
I know for me, I'd like to still be programming when I'm 50, but I'm already souring on the "working in a medium to large company" aspect. The coding is still fun, and the money is great, but the process of making software in the context of a corporation isn't.