How to Know When It's Time to Go
thecodist.com
thecodist.com
I was not obsolete. A big company like Apple, there are always things that need taken care of.
I assumed with iOS, Swift, etc., maybe the guys on the Cocoa team were obsolete? Of course not. That code is still there, still needs maintaining, interoperability with the new languages, frameworks, etc.
I'm more surprised they want to stay on.
And that is in fact why I left Apple: the job had changed, the "career" had changed. The engineers were no longer steering the ship. It had been that way when I started in 1995 though. A "team", let's say the graphics team, would figure out what API to revisit, what new ones to add — perhaps how to refactor the entire underlying workflow. The "tech lead" (who would regularly attend Siggraph since we're talking about the graphics team) would make the call as to what got priority. Marketing would come around after the fact to "create a narrative" around all the changes to the OS. I hate to say it, but many, those were the good ole' days.
(And let's be clear, in the 90's, Apple's customers were more or less like the engineers, we also loved the machine for the same reasons they did — so we did right by them, made changes they would like because we wanted them too. You can't say that as convincingly for the phone, being a mass consumer device.)
Marketing took the reins long ago though — especially as Apple began to succeed with the iPhone (which, someone can correct me if I am wrong, but I think was an engineer driven project initially — I mean most things were up to that point).
I stuck around nonetheless though because there was money to be made and kids still to raise.
When the last daughter flew the coop though, so did I.
But no reason for me to mentor — really it's just let the engineers drive. Sometimes it works (or sued to in another era), sometimes it does not. Either way, it will be a fin place to work. ;-)
What I don't like is all the bullshit around it. Primarily now the barrier is that I don't have to work, so why would I put up with abusive hazing? I mean of course, hiring processes, which have only gotten worse over time (hallmark property of the cycle of hazing).
I'm not doing on-call rotations anymore. Either allow us to engineer the thing to be resilient, or pay off-duty people (a wonderful opportunity for offshore people that management is so desperate to use).
Finally, I don't want to code in Python or JavaScript. As a long time programmer, it is annoying that we keep going backwards and wasting more and more hardware power.
Nobody is producing anything exciting in software anymore. I can't think of a pure software company doing anything I would be excited for, because google and facebook and the like control the internet.
It doesn't even pay that well anymore, and AI is just another huge excuse to drop wages by management.
Apple is a fantastic example: operating systems are stagnant, hardware outside of the architecture switch is stagnant (and how much of that was simply priority access to the state of the art TSMC node tech).
Nobody makes good solutions for anything anymore.
Can you expand on this? I haven’t noticed salaries going down where I’m at (only fewer open positions the last ~1.5 years due to the global economic climate - but I’m sure this is cyclical and will swing back soon enough).
And each year I can afford less and less with my relatively huge salary.
It's not going well but I bet it's gonna take at least a year before anyone notices.
The software jobs slowly go into the direction of not being worth the effort (I don't really believe that we will reach that point but that's the current direction).
> Two uneducated polish factory workers today won’t be able to buy your parents’ house either.
Of course - because from my point of view factory jobs are currently paid terrible. They used to be paid better (worth the effort due to being able to buy more).
What I see locally is that cost of living has gone up but no other jobs (aside maybe real estate?) have improved compensation relatively to programming in that time.
They're not? Some of the newer programming languages seem very interesting, attempting to fix some of the mistakes done in older languages. Of course, most of the really interesting problems are already solved by existing solutions, but perhaps there's room for improved solutions instead of just using the incumbent.
>I like programming. I can still do it. What I don't like is all the bullshit around it.
If you have spare time (you sound like you might be retired), perhaps you should try getting involved in an open-source project that interests you (and isn't in Python or JS of course).
>I can't think of a pure software company doing anything I would be excited for, because google and facebook and the like control the internet.
Personally, I work in robotics and find it quite interesting. I would also find writing software for spacecraft interesting. Neither of those are "pure software", but still I think they're applications that will change the world, hopefully for the better, and don't already have some huge incumbent dominating the market.
Political shifts probably mean that manufacturing will be onshoring and automating. Software in the last 3 decades has basically mirrored like Conway's law management structures without source manufacturing elsewhere.
The next economy will have a lot more near shored manufacturing. And that means hardware, robotics and hardware software boundaries
The real world/physical materials is also a little bit more resistant to AI replacement
What is robotics but a whole wide range of apis to do all kinds of different things with different devices.
But the point is you're going to need a human to verify that the robot is doing what the AI generated code is intended to do.
Part of my motivation to go into writing code in the first place was that I noticed software getting worse and more user-hostile in the 2010s and I wanted to change that. Turns out the people making software worse think the stuff that makes it worse are "best practices" so you're fighting an impossible battle and nobody is going to dare allowing you to advance into a leadership position or often even get a job in the first place unless they think you're a true believer in the BS.
I also have no interest, at this point, in writing code unless I'm paid to do it. It's hard to find motivation to write code when I mentally associate it with all of the corporate BS and the grifting con artists of the tech industry. The one saving grace was that the money was good and it was possible to switch jobs for more money or because you're tired of 1 particular company's BS. Now, even that isn't possible anymore so what's the point?
Yea, this has been the biggest change I've witnessed during my career. When I got into computers and programming, it was all about empowering the user, helping the user solve their problems, and providing the user with the tools that make the computer do what he wants it to do.
Now, the software industry is mostly about empowering the software company (and its "partners"), solving the company's problems, and making the user's computer do what the company wants it to do. From the software company's point of view, the user is seen as either 1. an annoying middle-man who just happens to (for now) possess the computer and/or 2. a cow to be milked for money, attention, engagement or time.
I've had 3 jobs in the ~decade-long range. I was really ready to move on in each case. Partly I was ready for a change and partly the company had changed.
The problem is, I have a family and finding fulfilling work that you have no experience in, in this country, at 50, is close to impossible.
So for now I consider myself lucky and try to rediscover the fun things in programming.
It appears that the only path left for us in many European countries, is to go freelancer, and I vouch for the same problem regarding skills, forget about having Github repos, or open source contributions, if the technology company X is looking for isn't the one we haved used in the last 5 years or so on day job.
In the old days (say until ~7-8 yrs ago) I didn't have to attend very many meetings but of those I had to go to most were useful/necessary. These days I could probably count the useful meetings I attend in a year on one hand but the amount of Scrum-worship-meetings per week requires two hands.
The same amount of actual work I could do in a week in the old days would now take several months because it needs to be planned in detail. And no, not any technical detail, but rather discussions on how to divide it into stories but without doing any proper technical analysis and then straight ahead to story point guesstimates, yay! Then after a brief period of actual coding it's stuck in code review for weeks because no one will look at a PR unless prodded with a stick.
While I do think that code reviews can some times be beneficial, most of the time they are (in my experience unfortunately) pretty useless. Most comments (and I have to admit I'm guilty to this as well) are more bike-shedding than bug-preventing. Complex bugs are rarely found in code-reviews in my experience.
While these are my experiences during the last 7-8 years or so, it's more or less the same on all the half a dozen companies (or so) I've worked for during that period (which is also a very big reason why I've worked on half a dozen companies in that period).
Unfortunately, modern methods are basically just institutionalized guesswork: this is what Agile is all about. It's a methodology designed by programmers for programmers, in order to bamboozle management and inflate the programmers' own sense of self-importance. The correct way to design a business's internal systems, including but not limited to its software, appears to have been forgotten, except a pastiche of it lives on as a strawman called "Waterfall" for Agilistas to take down.
This is actually the hardest part. I can write detailed requirements about the car I need. Create a PowerPoint presentation that shows a schema of the system and subsystems; the engine block, transmission and steering wheel etc. with lines how they are connected.
That's the easy part. Now you need the team of skilled engineers developing the actual car. And you need them to be experienced and good at it.
You need at least one guy who is able to load a complete mental map of everything that's needed to be engineered. Who understands the business requirements and is able to create a vision for the product and technical solution. He needs to understand databases, web services, authentication, authorization, security, performance, web standards back- and front-end solutions. Be smart about what logical components are needed and have an high level idea how they could be implemented technically. Ideally that guy can also open a repository and read what's going on.
Especially with larger corporations there's still so much potential for automation. Yet what we see is a big fragmented mess. Systems and subsystems that are poorly integrated. Exactly the car you'd expect that was designed in PowerPoint by non-engineers.
> That's the easy part. Now you need the team of skilled engineers developing the actual car. And you need them to be experienced and good at it.
In this analogy, the engineers who design the car are the equivalent of the systems analysts. The programmers are the machinists on the shop floor actually building the car.
> You need at least one guy who is able to load a complete mental map of everything that's needed to be engineered. Who understands the business requirements and is able to create a vision for the product and technical solution. He needs to understand databases, web services, authentication, authorization, security, performance, web standards back- and front-end solutions. Be smart about what logical components are needed and have an high level idea how they could be implemented technically. Ideally that guy can also open a repository and read what's going on.
Yes -- that's your systems analyst! More importantly, they need to understand the business and the information needs of the people involved. A high-level, 10,000-foot understanding of technical requirements is important, but the details should be left to the programmers. That's what programmers are good at. It's the big-picture, business-centric, people-oriented view that's missing in today's culture, and prevents us from "building the right thing right".
No, because with software there's no human execution. It's the computers that execute the design. The developers design the blueprints of what the computers need to execute. They are the architects.
For an analogy you can probably best compare this with 3D printed houses.
> A high-level, 10,000-foot understanding of technical requirements is important, but the details should be left to the programmers.
But why leave the details to the programmers? Why doesn't the systems analyst produce a proper CAD-like blueprint that leaves no room for interpretation? His system design should produce the exact same result regardless which contractor implements it. Yet that's never the case.
The reason is because he can't. The systems analyst doesn't have a clue what he's designing. If he would be able to write a proper blueprint we could just hand it off to the computer and have it executed. No need for programmers. But now the systems analyst has become a developer.
I'm not opposed to planning but I'm opposed to the kind of meta-planning game that is wont when scrum is involved. I've been in meetings where the thing we're planning is literally to change one line of code and we say as much but the PO still insistently asks if it shouldn't be multiple stories. The whole thing eventually took man days in meetings even though we insisted it was extremely quick. Turns out the whole thing was sold upstream to management as a big feature so a single 1-point story wouldn't cut it.
As a contractor I can at least remind myself that I'm getting paid for sitting through all those meetings but as someone who likes to actually do things I feel like I slowly die inside.
I get that they're depressing if you let them get to you, but I've always looked at it as I bill the same whether the client wants me in a useless meeting or a useful one. Helps me through.
I don't have any doubt in my ability to learn new languages and frameworks, but running in that hamster wheel just gets boring after a while.
Mind-numbing makework, really.
Containers: see BSD jails, Solaris zones.
WASM: see JVM and Smalltalk VM.
Async / futures / actors: see Erlang, Lua, Oz.
The cool type system of Typescript: see OCaml and Haskell.
Numpy: see APL.
Through the list above, there's usually a 20 to 40-year gap between the first availability and the turning into "new hotness".
About WASM, it is not the first sandboxed bytecode interpreter but the first that runs in a browser and that has usable toolchains to compile not “browsers first” languages into it. I’d argue that that’s where the novelty is.
The VM itself is pretty tight, but abstractions have a nasty habit of being leaky.
Everything Old is New Again: Binary Security of WebAssembly
https://www.usenix.org/conference/usenixsecurity20/presentat...
Just one of the many articles that are slowly surfacing, now that WebAssembly is interesting enough as possible attack vector.
While there is a sandbox, you can attack WASM modules the same way as a traditional process via OS IPC, by misusing the public API in a way that corrupts internal memory state (linear memory accesses aren't bound checked), thus fooling future calls to follow execution paths that they shouldn't. With enough luck, one gets an execution path that e.g. validates an invalid credential as good.
My conception of it is that they were pretty much Java only (with Clojure and Scala also available in the later years before they got deprecated?). Is this conception wrong?
[Python]: https://www.jython.org/jython-old-sites/archive/21/applets/i...
[Scala]: https://cs.trinity.edu/~mlewis/ScalaApplet/scalaWebApplet/We...
[JRuby]: https://www.jruby.org/getting-started — offers to run as an applet in the first few lines.
There was (is?) also asm.js, which IIRC was a subset of JS that removed any dynamicness so it would be a lot faster than vanilla JS. But again, no broadly carried / w3c standard.
I also wrote a "toy" (read: for school) dialect of Scala compiling to Oz and therefore turning every local variable or field into what Scala calls a Future, for free. Performance was abysmal, though! But in terms of language idioms, it was quite nice.
---
Unrelated: about Wasm, none of what it does is new, obviously. What's interesting about it is that
a) browser vendors agree to do it together, and
b) the design grows to accommodate many source languages. This used not to be the case but the eventual arrival of WasmGC significantly redistributed the cards of the game.
Relevant background here: I'm the author of the Scala to JavaScript compiler, and now co-author of the Scala to Wasm compiler.
It's not that those who reapplied the old concept in new circumstances are not innovators; they are! Much like the guy who rearranged the well known thread, needle, and needle eye and invented the sewing machine, completely transforming the whole industry.
But seeing the old idea resurfacing again (and again) in a new form gives you that feeling of a wheel being reinvented, in a newer and usually better form, but still very recognizable.
There were plenty of ways to do "containers" (via vservers, jails, zones etc) but the concept of image never caught on before Docker.
You could sling tarballs of chroots around and at times this did happen but it was a sort of sysadmin thing to do, there was no coherent "devex".
Dunno about email though, the last real innovation in that space that I can remember with lasting impact was gmail. There were a few more tidbits like inbox (RIP), the inbox zero methodology, and Airmail (?) but none of them really took off.
For example, for Haskell [1990] (ok, not so much the type system bits, but…), see FP [1977] (https://en.m.wikipedia.org/wiki/FP_(programming_language))
It's like referring to ideas from 1960s as "old" in 1994. Not ancient, but already not really recent.
[My personal experience from doing related-work searches for research papers is that there was often an at least somewhat relevant reference from the 60s...]
(1)
Garbage collection in every high level language: Java, which was the first mainstream language to do it-- people were seriously using cpp for high level business logic at the time, and were suspicious of GC for its performance.
But Java itself got it from LISP, which had introduced GC without it ever going mainstream decades prior
(2)
No SQL had already been tried as hierarchical databases in the 70s or 80s iirc. Relational model won because it was far more powerful. Then in the early 2010s, due to a sudden influx of fresh grads and boot campers etc, who often hada poor grasp on SQL, schemaless stuff became very popular... And thankfully the trend died back down as people rediscovered the same thing. Today's highly scalable databases like Spanner and Cassandra don't ostentatiously abandon relational calculus, they reimplement a similar model even if it isn't officiallu SQL
(3)
And then there's the entire cycle that's gone back and forth several times of client based vs server based:
First there were early ENIAC type computers that werr big single units. I would consider that similar to thick client.
Then as those developed we had a long era of something more similar to cloud, in that a single computer developed processes to support many partitioned users who submitted punch card batches.
That developed even further into the apex at the time of cloud style computing: terminal systems like ITS, MULTIcS, and finally in the 70s, UNIX.
Then the PC revolution of the 80s turned that totally on its head and we went back to very very thick client, in fact often no servers at all (having a modem was an optional accessory)
We stuck with that through the 90s , the golden age of desktop software.
A lot of attempts were made to go back to thinner clients but the tech wasn't there yet.
Then of course came the webapp revolution started by Gmail's decision to exploit a weird little used API called XMLHttpRequest. The PC rapidly transformed over the next decade from a thick client to a thin vessel for a web browser, as best exemplified by the Chromebook, where everything happens in the cloud -- just like it did in the mainframe and terminal days 50 yeara ago...
The trend could stay that way or turn around -- it's always depended in hardware performance balance changes.
Schemaless has its place for document storage and the like, but it requires a much more careful approach, else it can devolve into insanity.
Edit for another: RPC calls are really old and went out of style maybe 15 or 20 years ago in most codebases. Most of the modern JavaScript metaframeworks are now using RPC calls obscured by the build/bundling process.
It is a reinvention of an old idea though. There was around 15 years where RPC rotted on the vine until Google brought it back for (mostly) the enterprise scale, and another 6 or 7 years before JavaScript frameworks rediscovered it again for fullstack web applications.
The details change, and each one tries to solve the problems of the past (typically by inventing exciting new problems), but conceptually none of these things are _that_ different.
I mean granted, I've worked with e.g. Gatsby for a while which is SSR on the one side but a hydrated SPA with preloading etc on the other making for really fast and low bandwidth websites, but still.
What's funny about this example is that it's arguably not even that much of a time-difference between the two epochs of forgetting and re-learning. It's just that everyone jumped on the microservices bandwagon so much that they couldn't deal with it in a mono-repo context, so they dumped it and convinced the world that many smaller repos was "better". Then they learnt the hard lessons of distributed and complicated version dependencies and coordinating that across many teams and deployments. Their answer to this? Not back to mono-repos, no no no, semantic versioning dude, it's the hip new thing! When that was a bust and no one could get around to being convinced of using it "the right way", they were forced to begrudgingly acknowledge the value of mono-repos. But not before they made a whole little mini-industry of new build or dependency systems to "support" mono-repos as if they're just lots of little repos all under a single version-controlled repo.
These days I get this kind of stuff: "Hey you guys wrote this neat module as part of your project, can you separate it out and we can both share it as a dependency? Because, you know, it's a separate little mini-something inside of their codebase." ...Only to then be told that separating it out would "ruin" their "developer experience" and people would have to, gasp, manage it as a dependency instead of having it in their repo.
/rant. It's really hard not to be shocked and disgusted at this level of industry-level brain rot. I never thought I'd be "that guy" complaining about my lawn, but seriously, our industry is messed up and driven by way too many JS hipsters and their github-resume-based-development.
I hate having to do this, because then I have to get Nexus working with whatever the package manager in question is (Maven, npm, pip, NuGet all have different ways of publishing packages), setup CI for the publishing and god forbid I also need to manage the Nexus credentials for local installs and possibly even might have a Git submodule somewhere in specific cases, which also confuses some tooling like GitKraken sometimes.
It does prove your point, but honestly dependency management is a pain and I wish it wasn’t so; separating a module from your main codebase and publishing it as a package should be no harder than renaming a class file.
I get it, it's a team sport. It's just that the more people you put on your "team" the less agency everyone feels because responsibility gets diffused and it becomes more about about the "team" and less about actually doing the thing.
I still get enjoyment out of some coding - C++ on Linux for enterprise applications - but I do miss the “magic”.
but that's not the same thing as enjoying writing the dreck that many employers want, and keeping up with their endless stack of messy JIRA issues, planning meetings, poor design docs, and management shenanigans....
There are also parallels with embedded device and FPGA work that I personally find thrilling.
Plus we on the VICE (open source Commodore emulator) team are always looking for devs.
I don’t code 6502 nowadays but I’m active on r/c64.
I still enjoy writing code or shall we say solving problems via code. I still get excited about new things. I'm also a manager and I enjoy helping others. What I enjoy less is the politics.
Building things is fun, I don't think this goes away, it was always fun and is still fun.
Thing is I’ve solved so many problems, over the years at different companies, that there aren’t many new ones. Obviously, I can knock out the code quickly to the surprise of many. It’s just experience and I’m not a magician.
Like yourself, I enjoy helping others, younger coders in my case, work through their problems.
I guess that’s why I keep having to switch teams to pull them out of the quagmire they’ve gotten themselves into.
It's tough to tell younger engineers that have cut their teeth swimming in intricacies and edge cases and integration nightmares and constantly surfing on the edge of chaos, and managing it, that they're likely contributing to the problem, not fixing it. But someone needs to.
I can't remember details like I used to, things mark&sweep out of my brain much faster they used to. (Probably not just because I'm older but because as a parent, home owner, and spouse... I just have a lot to manage on top of it.) But.. really... a good system, a well-built system ... should be resilient to that, and people with experience.. that's hopefully what we build.
When I reflect I do cringe a bit at what I was zealous about and things I took way too far. But, I do think the discussion, sometimes debate, around the fancy/new vs tried/true resulted in much better results.
Now that I am old, but not that old, the younger engineers who are passionately discovering new tools and “new” design patterns keep me interested in software development. Being able to share where things come from then we can compare/contrast together. It is rarely a straight copy and it’s fun to see how things get better/worse with reinvention.
So, I think trying to get a mix of ages on a team is really beneficial. Passionate young engineers help prevent the old engineers from getting too jaded.
I got into the industry during the .com boom with no degree, without finishing university, so kind of jumped the queue, age-wise, I guess.
And yes, I often cringe in remembrance of past-self. I cringe at present self, too, though :-)
Projects fail for many reasons. Technical, market, capital, time and so on. But things change. Building an add-on for electric cars would likely fail 20 years ago, again 10 years ago. But now? Or 10 years from now?
Only by -really- understanding what caused a project to fail can you determine if that barrier is no longer in place. Which means you can try again, and potentially find the next barrier or success.
That, and prioritizing "new" features over maintenance because the former were booked as CapEx work, thus amortizable, while maintenance was booked as OpEx, combined with companies wanting to minimize CapEx ratio for accounting purposes.
Notice how little of what is measured and managed has anything to do with building working software to satisfy user needs?
I'm used to verifying code with a compiler/interpreter and a unit test -- not by going through my code line by line and declaring to an interviewer "yes I think it's correct". My way of doing things is to just run the damn thing with the right tests and it will tell me if something is wrong.
Unfortunately job interviews these days are still hellbent on whiteboarding Leetcode problems. I'm past that. Unfortunately they aren't. It's this kind of BS -- not being allowed to use the best tools that exist -- that makes me not want to code for work anymore.
Right now I feel like I'll never want to stop making things, but that if I were rich enough and good enough at creating in a different medium other than code, I completely understand the desire to walk away from the terminal and never look back. Few things have been as frustrating to me as programming. Yet since few things have been so rewarding, I persist.
It's a great article because it's making me think about my own life. I'll keep pondering. Thanks for posting it.
What do you mean, this is the best part of the job, the part I look forward to most each day.
If you never feel that way, I'm very happy for you!
Spending time in the terminal with vim and shell is healing.
I think most devs can delay burnout/leaving the field if they begin viewing programming as a means to an end, e.g. "programming as a way to build their own business," or "using programming knowledge to mentor others," or "using programming knowledge in another domain they're interested in to great effect."
Money. If you are financially independent, you are done with the field. If you are financially dependent, you are burnt out.
Instead I now program in a great language, Elixir, working on projects that I want, and reading books that I’ve been putting off for decades.
AI has mostly been a nice benefit to - Copilot really makes writing code more pleasant. I haven't really seen any downsides to AI in my work.
I'm almost always remote, and mostly like that, too.
This, at least for the time being, seems more a thing that people worry about than a real phenomenon.
Can relate. I've been "retired," since I was 55, and SV was nice enough to let me know that I was too old to play in their pool.
Pissed me off, something fierce, but, in the long run, it's the best thing that ever happened to me.
I could have made millions -for other people- maybe for me, as well, but I have never really been interested in that kind of thing. The work and the technology has always fascinated me.
I've found that what I really enjoy, is making UI tools for nontechnical folks. That's what I do, these days. I make free software for folks that can't afford the kind of stuff I do.
I guess if that's the way absolutely everything functions then perhaps dysfunction is actually just function.
But the other is it's a down part of the cycle and there's just a glut of us all, and a bit of disrespect from employers as well.
It's been a long time since we had one, and many people either didn't work through one before, or have forgotten.
That part will bounce back. In 5 years it'll be a crazy job market again, and having Rust on your resume will be valuable.
(To put it in perspective, I learned and wrote Python in 1996, 1997. And I really liked it. But nobody even knew what it was, and nobody would hire for it. I moved on, and lost my taste for dynamically typed languages, and then all the sudden Python was huge, and if I'd stuck with that, it would have been a big thing for me, I guess. I suspect a similar thing will happen with Rust, etc. At least I hope so, since Rust is my day-job :-) )
But, yes, even if the tech cycle isn't terrible at the moment (e.g. dot-bomb nuclear winter) it's definitely down. I somewhat regret effort and money I put in a couple of years ago to get myself setup to do various stuff post "retirement" because, while I haven't exactly been beating the bushes, opportunities haven't been falling off trees either.
Programming for the sake of "writing code" is probably going to miss the target.
For example "analyst". My take is that is where it all started. Someone looking at numbers and needing computers to help making sense of them.
Why do you have to be so demeaning?
I'd argue almost nobody is "writing code for the sake of writing code". In my case I love solving problems with code. Not by clicking through AWS' terrible website. Not through taking a deep breath and trying to reformulate a ChatGPT prompt for the 17th time.
Look into IaC (infrastructure as code) which all major clouds, and even smaller clouds support. Much more sane way of managing resources.
> trying to reformulate a ChatGPT prompt for the 17th time
Is the company mandating you use AI to solve problems... or? Anecdotally I don't use AI very much at $DAYJOB, nor do any of my co-workers.
No, sane way is automating it 100% with zero UI required. But you do you.
> Is the company mandating you use AI to solve problems... or? Anecdotally I don't use AI very much at $DAYJOB, nor do any of my co-workers.
As mentioned in a reply to your sibling comment, I don't do it because I was sure from the get go that it will only get some algorithms right, and only for the most popular languages, and I was on point. But I had fun watching colleagues banging their heads against the wall many times.
And again as per the reply to the sibling comment, I was commenting on the general "future" state of the area.
Umm... that's what IaC is for, you write resource blocks in a file then use a command to deploy said resources.
Infrastructure as code means text, not a UI. Please Google the things people are suggesting before getting confrontational
Most places with a decent level of engineering maturity are using some form of infrastructure-as-code (Terraform/OpenTofu, Cloudformation, etc). Though more broadly speaking, it's true that software developers are now frequently expected to move beyond just compiling a JAR file and calling it a day. Expectations of knowledge of the underlying infrastructure that's running your code and how to operate it is more common than it was 15 years ago. I consider this a good thing overall though.
> Not through taking a deep breath and trying to reformulate a ChatGPT prompt for the 17th time.
I don't know anyone who's doing this at their programming job. GenAI is really good at 1) acting as an enhanced, customizable StackOverflow replacement for specific one-shot algorithms ("given a pandas dataframe with these columns, write code that groups by X and gets the median of the top 3 values"), and 2) pumping out boilerplate code that wasn't interesting to write anyway, like object mappers and certain unit tests. The tougher problems around software architecture, class design, and the trade-offs are still fully in the realm of humans, for now.
And you are demeaning as well for no reason. I even went out of my way to clarify I like SOLVING PROBLEMS WITH CODE, not "just compile a JAR file" which you conveniently ignored and pushed your narrative. Not cool, dude.
> Expectations of knowledge of the underlying infrastructure that's running your code and how to operate it is more common than it was 15 years ago. I consider this a good thing overall though.
I don't deny it on the premise but again, most vendors want to lock you in so their UX is terrible and specific. I had much more fun making scripts and cookbooks that setup a VPS for my customer's app. Nowadays this has been mostly remedied by Dockerfiles though integrating with k8s and its 5000+ friends is making me want to retire for the next 3 lives.
> I don't know anyone who's doing this at their programming job.
I don't do it either but I've met plenty of "programmers" who do, and swear by it, even though they had to chase 2-3 subtle bugs that took them 12+ hours to find and correct... whereas just writing those 150-200 coding lines would have taken them 4 hours tops, tests included. It's quite funny.
---
My bigger comment here was to criticize the very weird direction the area is trying to go to. It will fail btw. Marketing people are pushy and get their way... INITIALLY. Sooner or later reason prevails.
Seems the majority of work is overly complex (in terms of "system design") CRUD stuff that uses whatever constellation of "Services" are cool this month, and "solving problems" that Ruby on Rails or ExpressJS solved like ten years ago, but now with way more yaml configurations and and other imposed complexity for dubious gain and benefit.
The new hyper focus of LLM chatbot hype isn't helping either.
One thing I figured out early on is that your choices in languages and tech really matter. There are only so many things you can learn and you have to make some educated bets on things getting traction or not. And if you make the right bets, it's easier to keep your skills fresh and relevant.
Some things look fancy and nice and then five years later it's all outdated and obsolete. And some other things go big. Java was one of those things and in 1995, when I was in university, they decided to use it for teaching programming to first year students. So I ended up being a teaching assistant and now have nearly thirty years of experience with the JVM ecosystem.
I recognized the signs of the platform and language (especially) going a bit stale about fifteen years ago. It's becoming the Cobol of my generation (plenty of work but not the kind that gets me excited). I realized I needed to move on if I wanted to stay relevant. Since then I've touched a lot of languages. Right now, I do a lot of Kotlin but I keep an eye out for new things. Kotlin was a bit of a bet ten years ago. I fully committed to mastering it six years ago. And at this point it's starting to feel like a good bet. The language is modern, has a lot of momentum and there's lots of interesting stuff happening with the language, compiler, tools, etc. Particularly multi-platform is opening up a lot of possibilities.
I've dabbled with other things along the way but never really got the feeling that mastering that stuff was worth my time. E.g. Ruby was interesting but it's now mainly used by people in their forties (i.e. my age). Younger generations seem to not be interested in it. Same with things like Scala. Lots of stuff still happening with both of course but it seems that they are both a bit past their peak.
Python on the other hand keeps surprising me by not getting replaced with something else. I kind of like the language and have done some things with it over the years. And I like that they are clearing out technical debt (like the GIL) and keeping the language fresh. I work with some twenty year old interns that know and love it. People will be doing Python long after I die. That's a bet I didn't make but it would have been a good one. And not too late obviously. I know enough python to be able to jump in a project and use it. I've done so on a few projects in recent years. It's a very approachable language; kind of by design.
Java has become a lot better. It was always a boring, but easy to write, easy to debug, easy to build with language, on purpose. That was the selling feature, so that finding developers was easy. It purposely didn't move quickly, or adopt the latest fasions, waiting them out to see what stuck and adopting later.
Ok, so what? Well, Java has started to evolve more quickly with the new development cycles. I still write Java. We easily deal with null safety, we have a good build system, we have a monorepo, we don't (often) have dependency hell. Most of our code runs on ZGC and we don't think too hard about garbage, because ZGC is so damn fast. Our hotpath is different. We think very carefully about GC and memory access etc on the hotpath. And we have one language, covering both types of coding, in the same repo, the same build, the same tooling, the same monitoring, deployments, etc etc.
Java is a real workhorse and is becoming nice to work with too.
https://www.youtube.com/watch?v=nQxsG9Vcndw
There's also a Guy Lombardo and a Louis Prima version but I like this one.
I've been singing this at work for a year or so, trying to give people a gentle hint about my future.
> It's not worth working and being miserable.
Agree 100%. I've quit several jobs after the environment becomes more stressful than fun. Over the years my tolerance for BS has lowered, possibly to the detriment of my bank account. But I've never regretted my decision to leave. The weight off my shoulders is priceless.
> Age and ability are not correlated.
I wonder how subjective this is. Cognitive decline with age is real, but maybe keeping the brain active with programming can help keep it at bay. A study about this would be interesting.
> ... cognitive decline..
I know this is not the age groups you thought about, but on the topic: I think they ARE correlated, but the other way: At 40 I have had time to get to know so ridiculously much more than someone starting out in their early 20s. And I see its effect very real, people in early 20s (generalizing ofc) can spend so long on things on have seen so many times...or spend more time making lots of bugs and finding them than just writing the code with fewer bugs.
Or spend their brain cycles on the "how to code" part of the job, instead of that just being second nature and focusing on the underlying ideas.
Or young people may be be competent coders, but completely baffled reading and really grasping underlying ideas in existing codebases (especially this I know I have progressed at with training over the years..)
I feel experience can be undervalued in our industry in a way it is not in others. It is valued... but not as much as I feel it should be..
Of course this effects drowns a bit in the noise of all of the programmers like the OP talks about that barely get by, in all age groups. But within the set of skilled coders... from what I have seen, I would always prefer working with the older to the younger to get a project done..
(Ofc there may be a point where this turns. I lack personal experience with coders 20 years older than myself.)
If you ever manage to come up with a reliable way of identifying skilled coders, you'll be very, very rich.
At my previous job we had 20 interns and one senior who was like 50 and his attitude boiled down to "why can't we just keep doing things the way I was taught when I was a student".
At my current job there's me, another Junior, and a Senior. The other Junior works very fast, very well, always has valuable input in discussions. With the senior I need to work carefully, because while the guy has knowledge in certain areas, he misidentifies priorities, makes mistakes, doesn't communicate shit, while at the same time demands things to be his way because he is the senior so he has authority. On top of that his English sucks so every meeting in which he's involved takes three times as much time as it could.
My father worked as a consultant designing analog-style ICs until his mid 70s - his customers were therefore presumably happy to pay his consulting rate. I’m going to vote for “early” cognitive decline being overrated…
I like programming computers, but just not 2000 hour a year. I can afford not to do that, so I don't.
I hit a point in my 30s where I could sock away a year's worth of savings in 3-6 months of contracting, so that's pretty much where my full-time phase ended. I came back "out of retirement" when the first kid was born and worked 5 years semi-fulltime to save up enough for houses, college, etc., ramping down to 4 day weeks for the last few years because I really value my free time.
Since then, I've done the odd 3-6 month/year stint (since programming and working on a good team that can ship is still pretty fun.) Recently I've been doing that part time, 2-3 days a week, a few months a year.
I don't know what most people would call my situation. I call it Retired as I want to be at any given moment. I expect I'll keep doing it for the dozen-odd years between now and when I hit "Retirement Age". But maybe not. It's almost more of a hobby at this point.
I guess the point is that it seems like a silly idea to do something all day every day for most of your life, then suddenly drop it completely. If it was fun, do more of it. But on your own terms, and only enough that it's still fun.
The problem with Golang is that it has the same name as a common verb instead of a noun ("go" is used as a verb like 99.99% of the time).
I remember coming across a thread maybe 10-14 years ago where the Golang creators were asked to change the name of the language. They declined. If I recall, one of the arguments was that the name would naturally become associated with Golang. Here we are in 2024, and the confusion still happens.
The TFA blog was great, by the way, even though it was not about about Golang as I had expected.
I discovered Go around 10 years ago, and it was a point in my career where I was fed up with the overgrowing complexity of the mainstream languages and cultures around them. I was seriously considering switching to other fields. Go has changed that direction 180 degrees.
Ha I know lots of retired programmers. I was one for a while, but like most I really wanted to get back to work
It's been a challenge for me to adapt to the new reality of coding as a game of busy-work and lock-in through complexity.
It has become a bit of a theatre for me, unfortunately. I know I could do something in a way that's 100x more efficient but it would negatively impact my job security so no thanks. Also, if I do the right thing, taking all the risk upon myself, nobody will appreciate. I'll stick to inefficient popular tools and methodologies. I'll play the game of Whac-a-mole... Like a bad gardner who pulls the weeds out by the leaves and leaves the roots behind. That's the smart move.
I tried the other approach, doing my very best, outperfoming and it couldn't have worked out worse. The manager class feels nothing but contempt for people who outperform. "Good boy! Here, have a pat on the back... Sucker."
But I'm basically semi-retired to a degree in my field. I'm doing the bare minimal to get by at this point. I ultimately would love to quit some day, and pivot into a different career, not entirely related to coding. I'm not at that point yet financially though, and am spending energy elsewhere
I would love to start a non-coding related business one day though.
I have more Project experience but technically I dont know much more about Cloud, JS frameworks, modern DBs etc than someone 30 years old. Ironically my main advantage seems to be I can focus more and work longer hours than younger people who seem to value WLB much more than we used to.
A former boss of mine retired early once he decided he was done with the politics required to navigate his work. He fully unplugged from corporate life and got comfortable delving into his passions... cycling, woodworking (so much woodworking), etc. He seemed to be having a blast from what I could see. I recently caught up with him, and it turned out after about a year off, he'd just accepted a job at a fintech that his former boss reached out about. I guess for him it was time to go from that specific job but maybe not quite from engineering in general.
I do get how you can burn out, especially on the business side of things. A lot of jobs just aren’t important. The trick is to avoid them if you can and leave them as soon as possible if you can’t. Every non-startup / non-economic boom job comes with some degree of Kafka, and you’re either going to learn to not care about it or go crazy. I’m not sure that is especially unique for programmers though, this seems to be most things. Unless you’re extremely talented at the HR part of organisational politics (which most programmers aren’t) you’re also going to have to build some really stupid stuff during your career because change management is hard. So hard that it’s virtually impossible for talented HR staff to do when the direction is upwards, which it’ll always be for programmers. Again, it’s something you either learn to laugh about or burn out on.
The change in technology, however? Isn’t that part of the fun? If it isn’t, is that because you don’t have the time for it? Because if don’t (and a lot of jobs won’t give you this) then you’re frankly in one of those “leave as soon as possible” positions. Even so, niche work rarely dies. The author mentions mainframe work, but mainframe work is still some of the highest paid work in the world because those grey beards who actually know and want to do it are so retired that a lot of them are frankly dead. I’m not sure how you could ever work on mainframes for 40+ years and then not be able to get paid handsomely by banks.
Anyway to each their own. It’s a nice perspective, and it offers you a few insights into just how much of a cog in the machine you’re going to be in virtually any job. Even one where you’re extremely well liked and rewarded. I think the best thing I learned from my stint in management is how everyone, and I do mean everyone, is replaceable. It’s just a matter of cost. Which can sound depressing, but it’s also very liberating because it teaches you to not get overly attached to jobs or employers.
Of course, the shift in the past few decades from coding-from-scratch to cut-and-paste has also pushed me out of the 'flow' of slinging code that I long enjoyed. So maybe the insistent adoption by management of agile-oriented groupthink and processes should be a clear message to me that resistance is futile, and it's time for me to make way for devs who are happy to play a game whose rules have changed, one that I no longer enjoy as I once did.
Ended up hanging around for a year effectively working part time. Not sure that was the right idea or not (had lots of vacation which I pretty much all took) but year+ passed by and it was pretty obvious at that point I couldn't drag my feet any longer and didn't have the interest or need to do a job search.
"If the struggles outweighs the pleasure you should stop doing it".
Kind of bleak when it comes to romantic relationships
I heavily relate to this line in the article:
> Some time ago, I knew a programmer with the same number of years of experience as me. Yet he seemed unable to comprehend what was required of him, and I had to review everything he wrote because it rarely worked
There's unable and there's not caring. I can imagine not having some specific skill sets and I can imagine just not having the interest in putting in the effort and learning what's needed. The results may look somewhat similar but they're different situations.
I made some of these mistakes. I didn't have anyone to help me avoid them. Now I can help but .... I cannot help. Only after the balls up and even then often not.
If I had a nickel for every leader I've worked for who didn't know when it was time to go... I'd have 3 nickels, which is still a surprising amount
You'll have to be able to tolerate some level of Initech-style management but if you just accept that and play along the work pace is pretty relaxed.
E.g. Facebook, Google, Amazon, and others have used a lot of Java in the last twenty years and many of their teams are transitioning to Kotlin at this point (each of them have talked about this in public). With many millions of lines of code that's a slow transition obviously but Kotlin is apparently the goto choice for a lot of new stuff.
Java is turning into the Cobol of our generation. People will still be doing this for a long time. But not a lot of young people are likely to want to do that. It's not an obvious choice for new projects at this point.
https://learnhub.top/the-most-in-demand-programming-language...
https://newrelic.com/resources/report/2024-state-of-the-java...
https://www.itpro.com/careers/29133/the-top-programming-lang...
Also, you might want to read up on how Amazon, Google, Facebook and other companies are moving to Kotlin internally at scale for server side use. They've been pretty vocal about that. A lot of Java shops are of course a bit glacial in their adoption of new technology. That's why I refer to it as the new Cobol. That has less to do with the language and more to do that this kind of companies simply don't change very easily. You'll find some actual Cobol lurking in a lot of these companies as well probably.
Kotlin was originally developed to be a drop in replacement for Java in any Java project. Android developers embraced it in a hurry because they were stuck with a relatively old and crappy version of Java because of the whole Oracle law suit with Google. Google made that official shortly after Kotlin 1.0 released acknowledging that many Android developers were voting with their feet at that point already. They also just embraced Kotlin multi platform at Google IO a few months ago.
On the server side, people have been using Kotlin for about as long. But things move more slowly there. Spring launched their Kotlin support around Spring Boot 2.0. That's six years ago already. It worked fine before that but that's the moment they started shipping lots of out of the box Kotlin support. Frankly, if you are using Spring and not using Kotlin, you're missing out big time. Lots of companies of course insist on doing things the verbose and hard way with Java.
The Oracle excuse is bonkers, everything on Android depends on JVM, written in Java, and Maven Central libraries, written in Java.
If Oracle actually played a role they would have switched Android to Dart and Flutter.
Kotlin was adopted by some management folks on Android team that are Kotlin heads, and to this day most Android documentation samples use Java 8 as counterexamples to how Kotlin makes things better, completely dishonest.
Looking forward to see JetBrains shown off their ecosystem rewrite in Kotlin Native, showing the rest of the world how Java is so passé.
Anyway, Kotlin came along as that was still in the courts. Google understandably wasn't putting a lot of effort in updating the compiler or the core Java libraries. With Kotlin, developers gained access to a lot of modern language features.
So, not bonkers but well documented history. If you want to try your compose apps on IOS, you can now. It's currently in Alpha release. Zero java libraries running on that platform. All Kotlin multi-platform backed by IOS native.
As for Kotlin getting endorsed by Google. That wasn't management doing anything other than responding to a lot of Android developers enthusiastically adopting Kotlin long before it was even releases properly and getting some good results. App development is super competitive and developers aren't afraid to try out new stuff if it gives them an edge. And Kotlin did exactly that.
Between that and the Oracle dispute, it was a logical move for Google to make it official. In the same way Jetbrains move to push kotlin multiplatform and compose multiplatform originated outside of Google. And is now getting endorsed by Google as well. I guess the compose team and the flutter team are in different parts of the org chart.
While using Android Studio, Gradle, Android SDK, Kotlin compiler, D8, R8, all running on top of Java Virtual Machine, using Java libraries from Maven Central.
So much for breaking free from Oracle.
Despite speed of Java evolution accelerating and Java being the best Java has ever been, I agree with this. Everything is Javascript or Python these days, Java is seen as old, boring, hard, inconvenient as you need to compile it and often it doesn't compile. Javascript/Python happily run until they don't and fail at runtime which feels like it just works (until it randomly doesn't) and you can pick up a teach yourself Javascript/Python in 24hrs style book and feel you are a competent developer very quickly.
A lot of Java positions I see now are maintenance roles, which isn't a great thing. Maintenance roles are never great, often seen as bottom tier developers. Unlike Cobol, there's likely many more people who have programmed Java than Cobol so even if Java dev becomes a niche I suspect they'll still be enough of them around that compensation is not anything significant.
Kotlin is nice, let's see where it is in ten years. Closure, Groovy, JRuby, Scala are also nice but ultimately Java won as the modern Java and all those other JVM languages that once had interest and promise are now niche or completely dead.
And if I’m lucky enough to get laid off (around retirement time), that would be a huge windfall to move me toward retirement.
Programmers planning to work after 50 are fools.
I don’t think most developers have the skills necessary to freelance and/or most enterprises are not setup to work with freelancers.
Most people can't do it, because their expenses grow to match their income. They want bigger and better everything, and they always find new "mandatory" expenses. Especially if they have kids.
I am fortunate my spouse was on board with this plan, which was mine. I’m 38, spouse is 36, for reference. Assuming we have college saved for, I don’t want to work a day past 55 if I can manage it.
It's not that these jobs have never existed, it's that they are in greater quantities.
25 years ago. Adjusted to today that's ~190k USD in salary. Add equity, bonus, ESPP etc. There's ups and downs but I think there are lots of US software jobs that pay this today.
(Mind you, that wasn't a great stretch for me in terms of compensation. But a later job made up for it at least by my standards.)
I'm guessing retiring just means working on your own things with enough runway til you drop dead.
I’m working to bring down the spend rate, but even if I don’t I should be good well before 50. I’m saving/investing about 160k/year, plus or minus. Some of the money saved is pre tax in 401k and some isn’t, so it’s not exactly dollar for dollar equivalent.