redleggedfrog

That was a really good summary, thank you.

I agree, for many it's wonderful. If you've got family at home I can see that being a real attraction. When my kids were little I'd have liked that as well. I also had wonderful office-mates that are now life-long friends, but I mostly worked non-corporate nearly mom-and-pops so we were a close knit group. I realize I am an outlier. I just wonder if not being in an office is 3% (or whatever %) of the unhappiness problem.

I'd also add that healthcare is serious shit-show as it currently stands and the best strategy is to just stay as healthy as you possibly can to avoid having to go to the doctor, if you can even find one who will see you.

Remote work is an interesting one. Before you had 8-9 hours a day of serious social activity, and if you were lucky, people you enjoyed. Even if you didn't enjoy the people, you were at least social. Remote takes that away, and as the article noted, social contact is a definite plus for well-being.

LOL! The first thing that came to my head was, "I've never had a CEO that shouldn't be in jail. Well, except for the current one. He seems okay. The others committed fraud and deceit at a level that would surely have them on the wrong side of the law, if not in prison.

Kind of stems from every CEO except this latest one has been a. Some sort of mental, and b. some sort of sociopath. We can see this with our big name CEOs of course, but even these small-time CEOs have the same problem. They're lacking something human, but that is also part of what drives them, and keeps them, CEOs, I suspect. It's a job that requires you to not have any qualms about taking a group of people on a ride and then screwing them over for your benefit.

This is not just software development wisdom, it's life wisdom.

The future is already here. Been working a few years at a subsidiary of a large corporation where the entire hierarchy of companies is pushing AI hard, at different levels of complexity, from office work up through software development. Regular company meetings across companies and divisions to discuss methods and progress. Overall not a bad strategy and it's paying dividends.

A experiment was tried on a large and very intractable code-base of C++, Visual Basic, classic .asp, and SQL Server, with three different reporting systems attached to it. The reporting systems were crazy being controlled by giant XML files with complex namespaces and no-nos like the order of the nodes mattering. It had been maintained by offshore developers for maybe 10 years or more. The application was originally created over 25 years ago. They wanted to replace it with modern technology, but they estimated it'd take 7 years(!). So they just threw a team at it and said, "Just use prompts to AI and hand code minimally and see how far you get."

And they did wonderfully (and this is before the latest Claude improvements and agents) and they managed to create a minimal replacement in just two months (two or maybe three developers full time I think was the level of effort). This was touted at a meeting and given the approval for further development. At the meeting I specifically asked, "You only maintain this with prompts?" "Yes," they said, "we just iterate through repeated prompts to refine the code."

It has all mostly been abandoned a few months later. Parts of it are being reused, attempting a kind of "work in from the edges" approach to replacing parts of the system, but mostly it's dead.

We are yet to have a postmortem on this whole thing, but I've talked to the developers, and they essentially made a different intractable problem of repeated prompting breaking existing features when attempting to apply fixes or add features. And breaking in really subtle and hard to discern ways. The AI created unit tests didn't often find these bugs, either. They really tried a lot of angles trying to sort it out - complex .md files, breaking up the monolith to make the AI have less context to track, gross simplification of existing features, and so on. These are smarty-pants developers, too, people who know their stuff, got better than BS's, and they themselves were at first surprised at their success, then not so surprised later at the eventual result.

There was also a cost angle that became intractable. Coding like that was expensive. There was a lot of hand-wringing from managers over how much it was costing in "tokens" and whatever else. I pointed out if it's less cost than 7 years of development you're ahead of the game, which they pointed out it would be a cost spread over 7 years, not in 1 year. I'm not an accountant, but apparently that makes a difference.

I don't necessarily consider it a failed experiment, because we all learned a lot about how to better do our software development with AI. They swung for the fences but just got a double.

Of course this will all get better, but I wonder if it'll ever get there like we envision, with the Star Trek, "Computer, made me a sandwich," method of software development. The takeaway from all this is you still have to "know your code" for things that are non-trivial, and really, you can go a few steps above non-trivial. You can go a long way not looking to close at the LLM output, but there is a point at which it starts to be friction.

As a side note, not really related to the OP, but the UI cooked up by the LLMs was an interesting "card" looking kind of thing, actually pretty nice to look at and use. Then, when searching for a wiki for the Ball x Pit game, I noticed that some of the wikis very closely resembled the UI for the application. Now I see variations of it all over the internet. I wonder if the LLMs "converge" on a particular UI if not given specific instructions?

Dead rich people don't own own anything, their heirs do. Keep that in mind.

Then you're going to need to invent an android with a awesome set of secondary sexual characteristics then, cause otherwise your idea is going nowhere. Mojo Nixon has your number: https://youtu.be/jz8ea8S5UH8?si=TIKuZmpIz3f9U-cX

Just making sure there is less noise when they start (already started) using U.S.-armed U.S. forces here in the U.S. to oppress people they don't like - non-Magazis, people without white skin, non-Christians, non-straight, and the poor. It's a lot quieter to disappear people when no one can report it and there isn't anyone to appeal to anyway.

Who's going to protect you now America? Federal government, police, your Mom? Nope nope nope. You noodle armed programmer geeks need to break out your 2nd Amendment rights and get strapped.

You're assuming that gold is going towards infrastructure. I don't think a lot of it is. I think it's a money grab while the getting's good.

It will never ever ever happen, because the nearly the entire software industry actively works against anything that inhibits pace of development.

Software is mostly created by businesses. Business want to make money above all else. Creating software needs to take the absolute minimum amount of time and money and quality, both in code and the program functioning itself, is an afterthought.

Because software isn't a tangible product, like a car or a bridge or a building, there is a prejudice against having certification for the engineers. It's not "important" like tangible objects that easily (most of the time) have their flaws exposed. Less important means less emphasis on craft, and you shouldn't need a certificate to prove you can add code to a project.

This cat has been out of the bag for so long it's just preposterous to think it will change. The current model of, "just get anything that can move the project forward," be it offshore, AI, hordes, long hours, whatever, will always be the strategy.

If you want quality write it for yourself. Early on in my career I built a carefully curated set of moonlight clients that my employer(s) did not know about. Here I wrote high quality software on my own timelines, emphasizing quality over everything else, because I am a one man team and don't have time for support. Now those clients pay me more each month than my employer. Most months I just get a check in the mail and don't have to do anything. As one said, "It just keeps working and we even forget it's there." (most of the software is integration related).

So it can be done, you just have to have the priority be different than a business that is in it for the money alone.

Let me share an anecdotal but very telling story about this attitude of more work is better work.

I have been a software developer for 30+ years now, and I have avoided working outside the 8-5 hours at every opportunity. I had bosses who very much chaffed at this, who were spending literally their entire lives working, and wish that we drones did the same.

I didn't, I just didn't show up if such a thing was expected, and made sure my work was good enough that they wouldn't think to fire me.

Now, I spent time with my kids, I stayed healthy and happy. My wife adores me for the time we spend together. The loss - nothing. I invested my income wisely, low risk, starting in my 20's, and am now sitting 9 million in assets and cash.

My bosses? One divorced, alienated from their kids, their companies sold and disassembled, and super sadly then contracting cancer because they could never give up their cigarettes with the level of stress they felt. They'll never get to enjoy the money from their sold company, they'll never get their family back.

Another, shunned by all their ex-employees, their own children (and grandchildren), suffering from the need to "get back in the game" when they're way past their prime, and when they were near useless at their job before anyway. But they worked all the time!

And another (years after I worked for them), fresh from a failed startup where they had invested all their money, and convinced their friends and family to invest, and having to lay off their entire staff after a failed pivot where they worked 24/7 for 5 years, going slightly nuts and now living in a commune in Massachusetts.

You get one life folks. I don't care if you're having the time of your life with your 24/7 job/startup you love so much. It's like taking drugs - it's great while you're doing it, but the repercussions come later in life. And they're awful.

That's not at all who the article is talking about. You're piers are not representative, and what you describe is not the issue.

As my buddy from Oracle likes to say, "No one cares what we do as long as the flow of streak, coke, and strippers doesn't stop."

He's a big Zed Shaw fan.

Totally lines up with my experience as well. We also have the opposite problem of reams of code generated years ago from a period of unsupervised offshore work where we're slowly paying down the debt but the LLMs will attempt to use the old code for new work. Most of it is spaghetti UI code and nearly impossible to reuse effectively but the LLMs give it their best and we have prompt around it.

I haven't really noticed that myself. I go "LLM shopping" fairly frequently trying to find which one of the few I'm paying for gives the best result for the current problem. They all seem to have their shortfalls, although I will say Claude is better for Greenfield work.

I'll share a new wrinkle that casts more shade on the coding LLMs.

We have a fair number of offshore resources that are used for dev. They developers are fully integrated into the team, are in all the stand-ups, and substitute for the usual role of junior programmers. They don't get the grunt-work shoveled on them, they get the same work as everyone else, they're just expected to not be as fast.

In 6 months 2 out of 4 of them been sacked, and surprise, not because we could replace their work with LLM output, but because their use of LLMs was so unrestrained and scattershot the pull requests they submitted had become nightmares. One thing mentioned in the article about unit test creation was something we saw as well. Perhaps this is partly due to working an existing code base where the LLM loses some of its advantage, and certainly some of it was cultural in that progress was thought more important than actual manageable code. The two sacked fellows where told, literally, from my own mouth, multiple times, "You cannot just ask Copilot to write you code, paste the entire thing into Visual Studio with no thought of what has changed, with the end goal of just compiling and meeting the single set of acceptance criteria on your story. You're breaking other things and introducing bugs." It went on deaf ears, and now they're gone. They were nice people, I didn't know how to get through to them, but they were convinced the LLMs were the way to go.

I use LLMs to help write code every day, and I wouldn't want to be without it, but I'm fairly surgical about it. Most of the time Copilot gives you a page of say, React code, or EF Core queries, you have to be really careful about anything you didn't explicitly ask for. Honestly, there is a time savings, but there is not a quality increase. The benefit is subverted by the time it takes to figure out how to ask correctly, the time to vet the output, and the time to fix the little tiny insidious bugs it can introduce.

So, don't go vibe coding and lose your job, is something to think about. I have to admit that it has worn me down meeting these interesting people from far-flung locations only to watch them flounder and get let go.

That mentor was very, very wise. I've had the same thing happen to me twice now. It happens outside the realm of career as well. For me it was a baby in the NICU and the rest of my life still needing serious attention as well. Something changes in your brain maybe. It's sad because while often 'stamina' will gain you things, this feels like a loss without a gain.

Not me, but my buddy got out of software development and learned to be, as he describes it, "a bog standard electrician." He had money for trade school, and then apprenticed under an experienced electrician. Dude is in his 40's, so late career change. Makes double the money he did doing remote coding.

Stupid things for stupid people, no mystery.

Just ask yourself if this AI generated software is what you want managing your bank account or the monitor next to your bed in the hospital. The lack of determinism makes LLMs unsuited for many tasks where precise outcomes are necessary.

1 in 5 Americans don't like the police.

I would never heard of these cards except for they got the creator banned and ended up on Hacker news because of that. Seems pretty Streisandy to me.

Cue Streisand effect in 3...2...

Makes me want to use an LLM to apply for a gajillion jobs. See how they like their own medicine.

That's funny those are considered Senior Dev attributes. I would think you'd better be doing that basic kind of stuff from the minute your writing code for production and future maintenance. Otherwise your making a mess someone else is going to have to clean up.

That's an interesting scenario you're proposing.

To answer it personally, which of the two, 7 figure bonus or being fired, it'd be I'd quit. If someone is structuring the development of software based on this premise, then they are going to need a different kind of person than me. But I admit I'm probably an outlier here. I don't really work for the money, and my salary is enough, and I don't like undo pressure.

For arguments sake let's say the 7 figures is $1,000,000. To offer that kind of bonus the project is likely going to be a larger one. And I'm assuming my estimate is determining the deadline, so of course I'm making sure it's something I think I can achieve.

But then there are other significant problems with this structure and the likelihood of meeting the deadline, and, more importantly, generating good code and user experience.

- +5% (in ignoring the -5% as no one cares if you're early unless it creates some sort of QA burden) implies a narrow window. On a 6 month project that is ~6 days. Enough that personnel changes or other uncontrollable factors could lead to a missed deadline. One person getting fed up and leaving would be a huge problem.

- The specification would have to be really clear and agreed upon, since there is much at stake.

- Any changes, scope creep, customer requests, could change the development time, and you'd have to have some sort negotiating buffer built in since there is now so much at stake. Otherwise you're going to get literally everything rejected by the developer as they drive towards the deadline (maybe that's what you want, though).

- Is the result worth having? A focus on a deadline, in my experience, tends to shortchange quality. But maybe the deadline is more important than quality.

- And lastly, if that deadline is missed, or worse, something changes the scope of the project and the bonus is not awarded because that led to the deadline being missed, you're going to have some super pissed developers that will not trust such an arrangement in the future.

I suspect you're talking about situations beyond my pay-grade. I've been a meat and potatoes programmer working in e-commerce and integrations mostly, and we don't see 7 figure bonuses. We certainly have had can't miss deadlines that we mostly didn't miss, but mostly those deadlines were due to external factors (API deprecation mostly), or financial considerations, or lastly, arbitrary deadlines set by management. On the latter, those mostly got missed. But that was to be expected as they were not tied to reality.

And I'd second leetcrews comment below of, "...but it's not a sustainable approach for delivering features". Maybe this scenario works once or twice, but it seems like a terrible way to develop software.

But still, an interesting thought experiment.

You can't make accurate estimates that can be used for deadlines for non-trivial work. You can make educated guesses on how long specific things will take, and it might be a pretty good guess if you've been keeping metrics on your past work, including things like vacation days and other similar disruptions as well, and keeping a team together long enough to have solid institutional knowledge on your code-base. And you can respectfully lay these numbers out to a manager in the form of, "This will probably take 1 to 3 days," or for bigger stuff, "2 to 3 weeks", and so on. And the manager can take the sum of all this and say, "The soonest it can probably be done is 3 months, but most likely it'll be 4, with a small chance of a bit longer", or whatever, you get the idea. And then the mangers can set the deadline as they see fit. Now, for some reason, many managers just look at the first number and are done - that's the due date. And then after that they get deer in the headlights treatment, so the worst case becomes the best case. That's on them. If they don't understand that software estimation isn't an exact science they're in the wrong field.

As for software development being special, I really hope that what I've described above is like other engineering disciplines, and we're not special. I don't want to be special, I want to be an engineer, like those who work with aircraft or bridges and what not. I feel like in those fields the concept of estimation is a little more respected. But I'm probably wrong. :^)

I'll mention I've been a professional software developer since the early 90's, not that experience equals veracity. But I've had good success using the system above, and even though the bad managers to good managers was pretty even during that time, the company experienced outstanding success during my tenure (20 years!). In the end, bad managers never last. Good managers, who take reasonable estimates to their superiors, succeeded, where managers who brought "It'll be done July 1st" got doubted because their superiors know it really doesn't work that way.

I've gone through times when management would treat estimates as deadlines, and were deaf to any sort of reason about why it could be otherwise, like the usual thing of them changing the specification repeatedly.

So when those times have occurred I've (we've more accurately) adopted what I refer to the "deer in the headlights" response to just about anything non-trivial. "Hoo boy, that could be doozy. I think someone on the team needs to take an hour or so and figure out what this is really going to take." Then you'll get asked to "ballpark it" because that's what managers do, and they get a number that makes them rise up in their chair, and yes, that is the number they remember. And then you do your hour of due diligence, and try your best not to actually give any other number than the ballpark at any time, and then you get it done "ahead of time" and look good.

Now, I've had good managers who totally didn't need this strategy, and I loved 'em to death. But for the other numbnuts who can't be bothered to learn their career skills, they get the whites of my eyes.

Also, just made meetings a lot more fun.

I did, partly out of curiosity, partly because I'm in a progressive town literally surrounded for a hundred miles by a sea of red.

They like Trump because he appears anti-establishment and they fear/dislike the establishment. They don't feel the establishment in place is good for them. They truly, truly struggle with finances. Many are in the military and on food stamps. Some are farmers who can't make farming work anymore. They fear immigrants because they might take jobs or bring crime (and drugs). They fear they cannot protect themselves so the want access to guns.

One common thread was the stimulus checks. They really liked the stimulus checks.

Another thing is pining for the good ol' days. Lot of that, too. No issues like pronouns muddying things up.

Generally, not racist, not sexist, but some are, just like any rando person.

Seemed to me just like regular folk who are scared and can't make ends meet like they used to, well, a long time ago. The grocery store prices that are annoying to me are truly a decision point for them.

Then when you take three steps back, and look at it objectively, it's often of their own doing. A lot, I mean a lot, of disparagement of education, even of K-12, so the means to get better employment is more of a struggle. A whole lot of drug and alcohol abuse on top of it. They are the only people I know who smoke. Lot of broken relationships and marriages. Family chaos. The image of solid salt of the earth isn't what my Trumper acquaintances (friends?) are experiencing. They are pretty desperate and really wish there was some way to get back on top of things.

So, in desperation they vote for a person that promises to make it better. And really they don't care about much else. If you want to win elections, do the chicken in every pot line.

This is all anecdotal of course, but I went to the effort, this was seven people, all of whom I'm on good terms with and converse with on a regular basis. And they were respectful of my position - that you need both conservatives (to keep what's good of the old ways) and progressives (to find new ways that are better) in the political arena to make it work. That's not a popular position, though.