But this is very obviously not what AI is doing. In essence, an LLM is taking works and compressing them and storing them in a big database, to later be reproduced with a touch of non-determinism.
It's closer to archival and compression than captioning. But they're selling it. That's a big problem - you can't just take someone else's work, sprinkle some god knows what on it, throw it in a big pot with other shit you stole, and then reproduce it later. Even if your reproduction is super convoluted and not 100% accurate.
"Some people might not enjoy writing their own code. If that’s the case, as harsh as it may seem, I would say that they’re trying to work in a field that isn’t for them."
I've tolerated writing my own code for decades. Sometimes I'm pleased with it. Mostly it's the abstraction standing between me and my idea. I like to build things, the faster the better. As I have the ideas, I like to see them implemented as efficiently and cleanly as possible, to my specifications.
I've embraced working with LLMs. I don't know that it's made me lazier. If anything, it inspires me to start when I feel in a rut. I'll inevitably let the LLM do its thing, and then them being what they are, I will take over and finish the job my way. I seem to be producing more product than I ever have.
I've worked with people and am friends with a few of these types; they think their code and methodologies are sacrosanct. That if the AI moves in there is no place for them. I got into the game for creativity, it's why I'm still here, and I see no reason to select myself for removal from the field. The tools, the syntax, its all just a means to an end.
This is something that I struggle with for AI programming. I actually like writing the code myself. Like how someone might enjoy knitting or model building or painting or some other "tedious" activity. Using AI to generate my code just takes all the fun out of it for me.
This so much. I love coding. I might be the person that still paints stuff by hand long after image generation has made actual paintings superfluous, but it is what it is.
One analogy that works for me is to consider mural painting. Artists who create huge building-size murals are responsible for the design of the painting itself, but usually work with a team of artist to get up on the ladders and help apply the image to the building.
I don’t enjoy writing unit tests but fortunately this is one task LLMs seem to be very good at and isn’t high stakes, they can exhaustively create test cases for all kinds of conditions, and can torture test your code without mercy. This is the only true improvement LLMs have made to my enjoyment.
except they are not good at it. the unit tests you'll have written will be filled with (slow) mocks with tautological assertions, create no reusable test fixtures, etc.
of course — that’s what they’re trained on after all. most treat tests as a burden / afterthought, propagating the same issues from codebase to codebase, never improving. i wouldn’t consider those good either.
Saying that writing unit tests isn’t high stakes is a dubious statement. The very purpose of unit tests is to make sure that programming errors are caught that may very well be high stakes.
It is as much of an issue if it prevents a bug in production code from being detected before it occurs in production. Which is the very purpose of unit tests.
There were seamstresses who enjoyed sewing prior to the industrial revolution, and continued doing so afterwards. We still have people with those skills now, but it's often in very different contexts. But the ability to create a completely new garment industry was possible because of the scale that was then possible. Similarly for most artesanal crafts.
The industry will change drastically, but you can still enjoy your individual pleasures. And there will be value in unique, one-off and very different pieces that only an artesan can create (though there will now be a vast number of "unique" screen printed tees on the market as well)
The only reason I got suckd into this field was because I enjoyed writing code. What I "tolerated" (professionally) was having to work on other people's code. And LLM code is other people's code.
I've accepted this way of working too. There is some code that I enjoy writing. But what I've found is that I actually enjoy just seeing the thing in my head actually work in the real world. For me, the fun part was finding the right abstractions and putting all these building blocks together.
My general way of working now is, I'll write some of the code in the style I like. I won't trust an LLM to come up with the right design, so I still trust my knowledge and experience to come up with a design which is maintainable and scaleable. But I might just stub out the detail. I'm focusing mostly on the higher level stuff.
Once I've designed the software at a high level, I can point the LLM at this using specific files as context. Maybe some of them have the data structures describing the business logic and a few stubbed out implementations. Then Claude usually does an excellent job at just filling in the blanks.
I've still got to sanity check it. And I still find it doing things which looks like it came right from a junior developer. But I can suggest a better way and it usually gets it right the second or third time. I find it a really productive way of programming.
I don't want to be writing datalayer of my application. It's not fun for me. LLMs handle that for me and lets me focus on what makes my job interesting.
The other thing I've kinda accepted is to just use it or get left behind. You WILL get people who use this and become really productive. It's a tool which enables you to do more. So at some point you've got to suck it up. I just see it as a really impressive code generation tool. It won't replace me, but not using it might.
what's the largest (traffic, revenue) product you've built? quantity >>>> quality of code is a great trade-off for hacking things together but doesn't lend itself to maintainable systems, in my experience.
Sure, but the vast majority of the time in greenfield applications situations, it's entirely unclear if what is being built is useful, even when people think otherwise. So the question of "maintainable" or not is frequently not the right consideration.
To be fair, this person wasn’t claiming they’re making a trade off on quality, just that they prefer to build things quickly. If an AI let you keep quality constant and deliver faster, for example.
I don’t think that’s what LLMs offer, mind you (right now anyway), and I often find the trade offs to not be worth it in retrospect, but it’s hard to know which bucket you’re in ahead of time.
I resonate so strongly with this. I’ve been a professional software engineer for almost twenty years now. I’ve worked on everything from my own solo indie hacker startups to now getting paid a half million per year to sling code for a tech company worth tens of billions. I enjoy writing code sometimes, but mostly I just want to build things. I’m having great fun using all these AI tools to build things faster than ever. They’re not perfect, and if you consider yourself to be a software engineer first, then I can understand how they’d be frustrating.
But I’m not a software engineer first, I’m a builder first. For me, using these tools to build things is much better than not using them, and that’s enough.
I don't think the author is saying it's a dichotomy. Like, you're either a disciple of doing things "ye olde way" or allowing the LLM to do it for you.
I find his point to be that there is still a lot of value in understanding what is actually going on.
Our business is one of details and I don't think you can code strictly having an LLM doing everything. It does weird and wrong stuff sometimes. It's still necessary to understand the code.
I like coding on private projects at home; that is fun and creative. The coding I get to do at work inbetween waiting for CI, scouring logs, monitoring APM dashboards and reviewing PRs, in a style and abstraction level I find inappropriate is not interesting at all. A type of change that might take 10 minutes at home might take 2 days at work.
> "as harsh as it may seem, I would say that they’re trying to work in a field that isn’t for them."
I find this statement problematic for a different reason: we live in a world where minimum wages (if they exist) are lower than living wages & mean wages are significantly lower the point at which well-being indices plateau. In that context calling people out for working in a field that "isn't for them" is inutile - if you can get by in the field then leaving it simply isn't logical.
THAT SAID, I do find the above comment incongruent with reality. If you're in a field that's "not for you" for economic reasons that's cool but making out that it is in fact for you, despite "tolerating" writing code, is a little different.
> I got into the game for creativity
Are you confusing creativity with productivity?
If you're productive that's great; economic imperative, etc. I'm not knocking that as a positive basis. But nothing you describe in your comment would fall under the umbrella of what I consider "creativity".
No citizen nor law abiding non citizen is affected. When you commit crimes, you “give up” your own liberty for the security of the public. That’s how all law works - when it is enforced properly, anyways.
You don't actually know whether these people are law-abiding or not, because there has been no due process. The government says they are in this gang, they say they aren't. Without due process we don't actually know if they got picked up for being in a gang, or just for having tattoos (which is what one of them alleges).
The law is blatantly absent if the executive explicitly states it can detain and deport any person it deems a threat without due process and without duty to notify anyone, let alone a court or judge.
It's literally the executive tyranny of a king and absence of balance of power in full action which led to the founding of the United States of America.
Even if you're a criminal, last I checked the law, properly enforced, grants you the right to an attorney to prevent exactly this: unchecked executive power.
I never stopped developing. After getting laid off in April 2023 after 13 years as first a full stack then mobile dev, I just started working on things that interested me. I did apply and interview a few times, but I started to realize that pushing 50 and being as cynical as I now am, I'm pretty much unemployable as an IC.
So I released my application to the App Store this month, and while savings are dwindling, things are starting to finally move into the other direction now.
> but I started to realize that pushing 50 and being as cynical as I now am, I'm pretty much unemployable as an IC.
Well that's me. My theory is that it is not age that makes one unemployable in the software industry, but the unwillingness to put up with shit cooked up by bunch of 25 year old CEOs, CTOs, and the like.
I'm the same age, and I'm pretty sure the industry has substantially changed, not just me.
EDIT: and by changed, I don't mean improved. I was a huge advocate of agile and eXtreme Programming early in my career, and I even worked in shops where it seemed to be really having good results. Now I see everyone using SCRUM and... it's garbage and I want to gouge my eyes out in the meetings.
I see a lot of talking but not a lot of code getting written. And where the code gets written, it's always a pile of ego-boosting needless complexity.
I think the issue with Scrum and agile is that it's become mainstream.
Anything that becomes mainstream is likely to get twisted and turned into whatever the "powers that be" want it to be.
So, while using XP or Scrum or Kanban for that matter properly in a sane environment is going to be great, if you work in an un-sane (sic) one, then the powers that be have turned whatever system you're using into theirs. This is how things like SAFe are born, that try to make "agile safe for the corporation" and of course they're nothing more than corporate BS under an agile name and that gives agile a bad name.
Just like Jira is getting a bad name because it's so configurable that corporations are able to use it to do what they do. You can also use it as nothing than an electronic place to house your "post-it notes on a wall". All up to you, your cow-orkers and company. Nobody can blame Atlassian / Jira for taking the money of these corporations. I know I would if I had had the idea of releasing a ticketing system that doesn't even know that you should use surrogate keys for all your entities instead of making an issue key that can change if you move issues between projects your "primary key" that is referenced everywhere and shit breaks :shrug:
I miss buganizer at Google. It didn't try to hoist a process. It was... "here's a ticket. go do it. or not. whatever" low clutter. right to signal to noise ratio. The bug tracker in Google's ill faited github competitor was similar. Really decent.
The problem with JIRA is it becomes a little fantasy code writing exercise for people who've stopped coding (managers). You get to pretend you're dispatching program for your robots^H^H^H^Hteam to execute. And write out a little maze for your rats to run through.
Also was just talking to a friend about this. The original agile folks, the XP people... were explicitly against using software to track tasks. It was yellow sticky notes on a whiteboard. ON PURPOSE.
Mentally making the move from writing code to management needs to be a shift in mentality from "I'm making software systems that solve problems" to "I'm building teams that solve problems".
Team building is people skills, and it's about finding well springs of motivation, soft skills, getting people talking to each other, making sure people aren't forgetting things.
Unfortunately people coming from an engineering/programming mindset can go the other way: management is about making lists, and getting people's names on those lists. Management is about making processes, and making people conform to those processes.
I'm not saying those aren't useful tools, but they need to be seen as that. Tools. Means to an end, not ends in themselves.
Most software developers want to do good work. They want to write code to make things happen, because that's what they were trained to do. Original agile was about trying to liberate that instinct from the crushing weight of corporate processes so that teams of developers could self-organize to do the things they generally naturally want to do.
I don't recognize that in SCRUM based teams today.
And as for your point, I do think that remote work makes things harder, and I've yet to see a remote team that fires on all cylinders. But for years I worked on hobby projects with people who I never met face to face and it was fine. So I dunno.
> I do think that remote work makes things harder, and I've yet to see a remote team that fires on all cylinders
The way I see it is businesses can have it one of two ways:
They can acknowledge that remote work is fine and allow their teams to work from wherever and figure out timezone differences and async collaboration workflows
Or
They can decide that remote work doesn't work. Then they must stop hiring expensive remote consulting firms and cheap offshore remote teams. They also must stop spreading teams out across multiple regional offices across North America
It is absurd to make people commute to an office building only to have people dialing in to meetings from other office buildings in other countries anyways, and then say remote work doesn't work
A lightweight process works well when you have engineers that are all of the following:
- experienced
- competent
- understand their problem domain
- actually care
In other words, a team of strong engineers (and a great, accessible product owner).
What I’ve found is that lightweight agile fails without a lot of oversight and frequent checkins, for anything else.
So SCRUM is SE training wheels because it forces a cadence, gets engineers to start breaking down work, and estimate; but the cost is that it holds-back great engineers with all of the (stifling) ceremonies.
I’ve gently nudged my risk adverse tech-lead to consider moving to Kanban now that his team is pretty strong now.
> This is how things like SAFe are born, that try to make "agile safe for the corporation" and of course they're nothing more than corporate BS under an agile name
SAFe was truly one of the worst things I encountered with consulting clients. Planning days were an unbelievable exercise in futility. Waterfall masquerading as agile, the absolute worst of both worlds.
> SAFe was truly one of the worst things I encountered with consulting clients.
we've been using SAFe for a few years, I despise every minute of the planning process. Feel like a mix between using a crystal ball and forcing square pegs in round holes... Of course the additional disfunctionality at my company between sales, PO/PM/BO and engineering doesn't help, though it seems that I've avoided the worst SAFe train of the company.
My last job was SAFe. When I started I was given Staff level title and had dreams of maybe moving into lead or management at some level. Once I saw the process I became completely unmotivated to go in that direction.
For them I understood some of the motivation. Hardware & equipment manufacturer, which involves scheduling complicated industrial processes for months/years out. So you need some semi-coherent vision of where things will be, so having a multiquarter waterfall-esque plan was going to be needed.
I agree that some of the outputs of the SAFe process aren't useless, like expressing dependencies between teams and discussing objectives, but the process is way too costly for what it achieves. Maybe if the name was changed to something like SCRUM and Waterfall evil child...
The issue with scrum and agile is that it became a managerial and reporting process to force teams to hit a management imposed deadline instead of what it was intended to be: a tool for engineers to self-manage and self-evaluate their progress to provide a realistic completion date.
At the risk of taking this thread further OT, I am a product manager / consulting CPO but a whole heartedly agree with you. I like the way you phrase it. A tool to evaluate progress and provide realistic completion dates. That is how I always push companies to use agile pointing and estimating. Use it to identify unrealistic roadmap expectations as early as possible, force hard conversations on priorities and staff allocation... before committing on plans to customers or stakeholders. Or when taking a risk on a delivery date, be doing that knowingly from the beginning, with contingency plans and management owning that risk and consequences otherwise.
1. Get the change to work
2. Refine the change to make it cleaner, less complex.
Most devs stop at #1. Trying to eke out every hour of developer productivity via Scrum is antithetical to #2 though.
One other anecdote, me and a buddy were responsible for cleaning up a fairly sophisticated DSS scheduling system. The original dev left and a poseur came in and wrecked the codebase for over a year. Hospitals were cancelling contracts left and right and our cash flow was ... uh, short a lot. Our rule was if we ran across some bad code while working on our tickets: a bug, janky code, disorganized code, shit variable names, whatever, we fix it on the spot. We were able to do this because we had 3 month cycles and nobody breathing down our necks asking, "what did you do yesterday?" "why aren't all your tickets done this sprint?" Well it worked and we ended up with a clean scheduling system that was really nice after a few years and the company exited with a decent sale. I couldn't imagine a culture like this today.
At my last gig someone that my team unanimously rejected as unqualified showed up one day the following year as our new technical lead and boss. It went about how you'd expect.
Much later I told my skip boss about the kind of feeling of disregard that may have fostered as he pushed me for insights. And he remarked that it sounded like I had a chip on my shoulder. All I could come up with was 'guess I was born with it.'
Yeah cynical. And much happier working on my own things that are meaningful and interesting.
But this industry is also, in my eyes and experience, madness at times.
"experience" seems to mean between nothing and everything depending on the previous company, the whims of the "hiring market", who/whatever reviews your resume and other nebulous forces subject to change at any time.
I've worked with people with loads of "experience" that are not particularly good that have managed to string together a career well-enough, and I know folks too with fancy resumes and experience that matches roles identically that can't get interviews for identical positions with referrals.
At any given time, what any party responsible for hiring "values" seems to change on a whim.
It's infuriating.
I don't have a "premium" resume, but when I can exceed all the expectations for a several job listings and I have a few years experience at a "fancy" company, you'd think I could at least get some calls back somewhere, right?
This makes the prospect of investing in any software skills for the purposes of employment a total contradiction.
(and yes, I understand the market is an has been very "bad" for a few years, but this kind of thing has existed since I've been doing this for the better part of a decade)
> the unwillingness to put up with shit cooked up by bunch of 25 year old CEOs, CTOs, and the like
You haven't seen the shit written by 50++ senior and principal 'developers'. Imagine local variables names 20-40 chars long. Then they are passed into function call, like 15-20 of them. While actually these are just 3 structures. I.e. 'gurus' unroll them into individual elements and pass. Long names to make the code what they call 'self-documented'. No comments at all. And all this is in a big project with other devs working on it for years. It's absurdly slow for the project of this size and resources. But with almost no competitors this can last for decades and it actually does.
I switched into software dev full time at 50 and took a new software job at 52. I'll be 55 y/o this year and I highly doubt I will switch jobs again, I like the org and the work.
Prior to that, starting at 45 y/o I was a part time dev and full time firefighter-paramedic (14 years total). Covid scared me to becoming a FT dev.
I have a BS degree in Aerospace Engineering and from 1999 - 2006 I was job jumping quite a bit because I was miserable. All the jobs were boring.
I took a EMT Basic night class because my wife and I were getting into scuba diving and I wanted to be a dive master on boats during the weekend. I enjoyed EMT so much that I signed up for Paramedic class, not knowing what I was going to do with it, just did it. It was relatively cheap at the time and we were kid free at that time as well when I started. School was 15 months long.
As we were about ready to graduate PM school the county fire dept (FD) came in and said they would hire paramedics but you had to cross train to be a fire fighter as well. I was 36 y/o, we just had our 1st kid and I figured if I didn't do it then I'd never would and probably regret it so I got hired as a PM and then FD trained me for FF. This was 2006, hence the username FM2606 for fire-medic Feb 6, 2006 my hire date.
It didn't take long to see a bunch of firefighter's getting hurt, specifically back issues due to working and mainly from lifting stretchers with patients on them. I also have a chronic health issues and I figured if either or both of these issues became a problem and I couldn't work as a FF/PM we'd be screwed, so I decided to do an online master's degree in comp sci. Comp sci being my initial major out of highschool before I dropped out.
Fast foward to 2015, I finished my master's, had 2 kids and started working part time as a dev.
Fast forward again to 2020, I was about to turn 50 y/o, Covid hit and I was taken out of the field due to my health issues. I started applying for full time dev jobs. Landed one and then two years later switched to a bigger org.
No regrets on any of it. Becoming a FF/PM was one of the best career decisions of my life. I loved it (for the most part) but it was time to go.
I didn't have an "in". I think persistence paid off and plus I feel like I interview pretty good.
Not sure you will see this. Congrats on your journey into full time dev! I stumbled upon the podcast below a couple years ago, and I found it fascinating. It defines "Mission Critical" as teams that need to make decisions in a couple minutes that impact life-and-death situations. You might find it interesting given your background.
Mission Critical Team Institute (MCTI) Teamcast
Exploring the questions vexing the most elite teams in the world
Sounds like you just worked your ass off. Nice job!
You also have a different background that would perk up interview potential (at least to me). Diversity (aerospace eng, firefighter, emt, paramedic) can help bring different perspectives and ways of thinking through problems that will ultimately help an organization.
Organizations that mostly hire people with CS degrees from top universities that can fly through leet coding tests and ace system design problems I think end up with not much diversity in thought when it comes to problem solving.
Luckily for me my current manager didn't have a code test. I received a timed coding test for another position within the same org but a different manager and bombed the hell out of it.
Well done. That's a great career, and lots of brave and sensible decisions along the way. I don't have experience of firefighters much, but having worked with military folks a little bit, which I think is similar in terms of communication and team building training, I'm not surprised you interview well. Those intangibles really add up.
I did actually. I created a custom dashboard with basic stats of type of calls ran, how many calls were run by each station, how many were EMS and how many were fire calls.
Then I started doing some more automation stuff. Nothing super interesting and mostly bespoke stats gathering.
Well, if you’re ever still interested in the intersection of the two, give me a buzz - my email is my HN handle at Gmail. I might have something for you.
I'm 56. Please teach me your ways. I took a break from dev work from 2017 to 2023 and want to get back into it. I learned more recent stuff like React and have built a couple of open source projects and a mobile app using React Native, but I can't even get an interview.
I have heard this a few times from different people/places, but why is it the case that at 50+ it is harder to find work? Assuming a regular retirement age, there are still many more years left in the career than a typical tech employment lasts.
> but why is it the case that at 50+ it is harder to find work?
I think this begins to be visible even sooner, 38 if you graduated at 23. The majority of the job market requires very very few 15+ years experienced engineers. 5 to 10 years of experience is a sweet spot - you will be easily hired. Everything below and beyond is a struggle, especially for the latter since very few companies need and are willing to pay for those skills.
And that's how you become unemployable with the irony of being at more or less what would be the peak of your technical capabilities. In years later on, people start to lose the drive.
I'm very good in my niche, but businesses just want 'answer to question'. I can provide 'answer to question while also making sure the answer-generating process is fully reproducible, data limitations are addressed and made visible, uncertainty has been calculated and is included in the answer'.
Not every question needs that!
Most people are willing to pay for Ikea furniture, not hand-crafted artisanal pieces. Ikea is good enough.
I must say that I have never thought about that before but that's the reality of the tech market. Many people I talk to, who are outside the tech, can't comprehend this at all - they all assume the same - the more experience and knowledge you have, the more competitive and therefore highly sought out you become. Not true at all.
I think landing (and keeping) a job in tech is challenging, whether you're a recent graduate or a seasoned professional with decades of experience. While the reasons for rejection may change with age, the key factors for getting hired remain the same: competency and collaboration. Demonstrating strong skills and being easy to work with will always be valuable—focus on these, and opportunities will follow. - a 40's something developer with 20+ years experience
Because most founders who made it in the field, did so at a young age and so they are biased to view old people who didn't "make it" and are still coding as incompetent even though it has nothing to do with reality. Reality is that being good in the tech side does not correlate that mich with being good on the business side. They are almost independent factors aside from some low baseline requirement of competence...
The baseline requirement of technical competence for extreme financial success in tech is so low that most big tech companies don't even hire rank-and-file engineers whom don't meet that requirement half-way.
There was a YC CEO that in a podcast basically asserted that innovation was pretty much done by people less than 30 years of age. I had been gearing to apply to that company until I saw that comment.
the average age for successful founders is 40 years, and i believe that is first time founders. so i do not believe that founder bias against age is the issue.
in austria/germany the problem is that cultural expectation is that people get paid by seniority, and also based on their experience and qualifications, regardless of the actual requirements for the job. it is also assumed that no one wants to do work that is below their qualifications.
that is, a 50 year old isn't even asked what their salary expectations are, it is simply assumed to be higher than what they want to pay, or rather, they can't bring themselves to pay someone like that less than they think is appropriate for their age. combine that with the perception that older people are less flexible and unwilling/unable to learn new stuff, and you end up with the belief that older people are expensive and useless or overqualified.
I wonder how that could be possible? There are proportionally so few of us old-timers around to begin with, given how much smaller the industry was and how rapidly it has grown over the last 20-30 years.
I won't be rehired anywhere near what I was making if I do find something, that's fairly certain. So I've put the onus on myself to generate the income I'm looking for.
reply