Do you want to be making this much money when you're 50? (2012)
yosefk.com
yosefk.com
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.
Like a Moore's Law but for computer programmers.
[1] https://www.bls.gov/opub/mlr/2000/12/art1full.pdf [2] https://en.wikipedia.org/wiki/Software_engineering_demograph...
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.
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.
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.
[1] https://rkoutnik.com/2016/04/21/implementers-solvers-and-fin...
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.
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 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.
I'm 57, and I completely agree.
"- 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.
I read this as the author talking about a career change from programming--not describing the requirements to become a programmer.
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.
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.
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
}
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)
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.
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)
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
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.
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.
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.
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.
As time goes by, the understandable version and the useful version diverge further and further.
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.
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.
Spoken like someone who has never had to debug (for instance) why a serial port is not connecting properly. All abstractions are leaky¹.
1. https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
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
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.
Low level is easy (2008) (yosefk.com)
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.
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.
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.
There are other reasons why I personally might not choose that route, but that longevity is an advantage.
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.
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.
There can be health risks. This is a very sedentary job with a lot of eye strain and stress.
There can be legal risks, like with HIPAA or even other more basic things.
You do generally need a college degree for most places to even consider you.
I don't make money to the point of it being addicting. I do dream of quitting, but there's not a lot of interesting stuff out there.
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.
[0] https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...
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.
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.
*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.
* network network network
* don't aim for the 1% of companies that have devs jumping to join them
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).
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.
But right now there is still a shortage of devs and pay is growing, I dont understand it. It has to stop some time.
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.
It's easy to forget, but remembering this fact results in a wider range of life options.
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.
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. :-)
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.
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.
"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.
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.