My automatic “red flag” was btree tests. As soon as I saw one of those, I knew I was wasting my time.
I was especially annoyed by recruiters that couldn’t do math. They loved all my experience, but ghosted me, as soon as they realized it came with gray hair. I guess the place is crawling with 35-year-olds with 30 years of experience.
As it turned out, I ended up giving up, and just retiring. I had the means, but wanted to keep working for at least another decade. I really enjoyed adding value. I was especially interested in helping small companies get on their feet, as my particular skillset would have been almost ideal for that, and my “nest egg” gave me a pretty good risk tolerance, along with a willingness to take a lower base.
Turns out that these were the exact companies that didn’t want me, though.
Also turned out that I really loved being retired. I have been doing more work in the last eight years, than in a couple of decades previously. I just don’t get paid for it, and I’m fine with that. In fact, I actively resist pursuing a paycheck, as I don’t want to deal with knuckleheads, anymore.
I just had to have my hand forced. I would not have voluntarily done this.
Basically, any test that involves binary trees (sorry - "btree" is a somewhat different thing).
Realistically, most programmers never see another binary tree, after they leave school.
It's a "youth-pass filter." People right out of college will ace them. Us oldsters are less likely to do as well (unless we cram for them). In forty years of programming, I never encountered a single one, in the wild, and a lot of our image processing algorithms involved a decent amount of data crawling, so they had some relation to binary trees (shows why they teach them), but the way they were handled was much different.
Works best, if you retain, but most companies aren’t willing to do that. They basically force you to leave, in order to make good money.
Being older is just part of the formula. Being good is another part, and having a good relationship with the company and coworkers, is just as important. That comes from longevity in the job, and also, a sense of security.
Companies love to have workers that are constantly afraid they’ll lose their jobs. That doesn’t really encourage a productive, quality-focused mindset.
There’s a lot of negative stuff, said about older employees. Maybe some of it is true, but I suspect that a lot of it, is an inevitable response to years of being treated like shit.
As someone that started with Machine Code, I'm grateful for compiled -even interpreted- languages. I can’t imagine doing the kind of work that I do, nowadays, in Machine Code.
I’m finding it quite interesting, using LLM-assisted development. I still need to keep an eye on things (for example, the LLM tends to suggest crazy complex solutions, like writing an entire control from scratch, when a simple subclass, and five lines of code, will work much better), but it’s actually been a great boon.
I find that I learn a lot, using an LLM, and I love to learn.
The same thing happens if you are the head cook in a restaurant.
If you are a cook wanting to open a restaurant, you will be delegating, the same thing with AI. If you are fine only doing what your hands can possibly do in the time allotted, go ahead and cook in your kitchen.
But I need to make money to be able to trade for the food I eat.
You will make money but the others are the artists.
That’s the whole point.
You become a customer of an AI service, you get what you want but it wasn’t done by you. You get money but not the feeling of accomplishment from cracking a problem.
Like playing a video game following a solution or solving a crossword puzzle with google.
Pretty B/W view.
The feeling of accomplishment is the part that makes a job interesting, if it’s just about money it becomes dull.
And don’t forget, it’s more likely to find someone cheaper who can write the same prompts as you than people with the same kind of experience in cracking problems.
To tackle the second part first, do you think creating finely crafted bespoke code is going to save a mid level ticket taker (not referring to you of course) who can take well defined requirements and create code is going to save anyone’s job - ie “a human LLM”?
Those types of developers on the enterprise dev side - where most developers work - were becoming a commodity a decade ago and wages have been basically stagnant. Now those types of developers are finding it hard to stand out and get noticed.
The trick is to move “up the stack” and closer to the customer whether that be an internal customer or external customer and be able to work at a higher level of scope, impact and ambiguity.
It’s been well over a decade and 6 jobs ago that I had to do a coding interview to prove I was able “to codez real gud”, every job I’ve had since then has been more concerned with whether I was “smart and get things done”. That could mean coding, leading teams, working with “the business”, being on Zoom calls with customers, flying out to the customers site, or telling a PE backed company with low margins that they didn’t need a team of developers, they needed to outsource complete implementations to other companies.
I’ve always seen coding as grunt work. But the only way to go from requirements -> architectural vision -> result and therefore getting money in my pocket.
My vision was based on what I could do myself in the allotted time at first and then what I could do with myself + leading a team. Now it’s back to what I can do by myself + Claude Code and Codex.
As far as the first question, my “fun” during my adult life has come from teaching fitness classes until I was 35 and running with friends in charity races on the weekend, and just hanging out, spending time with my (now grown) stepsons after that and for the past few years just spending time with my wife and traveling, concerts, some “digital nomadding” etc
Anyway, I have been dealing with Zoom for over five years (like most folks). I don’t especially like it, but there’s really no viable alternative. Its video quality is light years ahead of anyone else, and its UI, though still klunky, has become a de facto standard. Everyone knows the UX, and is afraid to use anything else. Classic “the devil you know” conundrum.
I’ve found it really difficult to get non-technical people to use anything else. At one time, I could get folks to use BlueJeans, but that’s gone the way of the Dodo.
It’s a pretty common issue, when adopting FOSS alternatives. The UI is often optimized for FOSS lovers (tech people), not regular mensch. The tech may be great, but the UI is inscrutable. Tech folks just can’t seem to grok how important good UX is.
It’s actually a bit depressing, seeing this type of thing happening. It’s like a slow-motion trainwreck. Inevitable, unstoppable, and we can’t look away.
the thing is a lot of recent legal preceding surrounding X is about weather X fulfilled the legally required due diligence and if not what level of negligence we are speaking about
and the things about negligence which caused harm to humans (instead of e.g. just financial harm) is that
a) you can't opt out of responsibility, it doesn't matter what you put into your TOS or other contracts
b) executives which are found responsible for the negligent action of a company can be hold _personally_ liable
and independent of what X actually did Musk as highest level executive personal did
1) frequently did statements that imply gross negligence (to be clear that isn't necessary how X acted, which is the actual relevant part)
2) claimed that all major engineering decisions etc. are from him and no one else (because he love bragging about how good of an engineer he is)
This means summoning him for questioning is legally speaking a must have independent of weather you expect him to show up or not. And he probably should take it serious, even if that just means he also could send a different higher level executive from X instead.
and count on Trump to disrespect the extradition treaties. Which might be a reasonable expectation, but will have consequences, and Trump might not hold power forever.
reply