Like many, I became a SWE because I loved writing code. Ruby, in particular (whatever one thinks of its other strengths and weaknesses) can be very expressive and beautiful.

However, most code is corporate CRUD stuff. The world sort of runs on CRUD. But it's rarely particularly fun, or beautiful, or fulfilling. It tends to be pretty ugly because there's rarely time to make it beautiful. So I'm not losing much joy there.

Additionally, even with an agentic workflow, my team still thinks deeply about architecture issues. We believe that well structured code is better for bots and humans alike. So I am still exercising my engineering brain; I'm writing blueprints and supervising the bricklayers now instead of laying bricks.

Does that match your teams' experience at all? Sometimes I feel like folks on these threads are working in a parallel universe where the majority of coding tasks and somehow fulfilling and fun and not 99% tweaking reports, trying to implement arcane and contradictory business logic, or fighting with shitty and frustrating externalities. Maybe people found joy in those aspects. I guess there are all types of people in the world. I mean, I'm a sicko who loves writing SQL, something that most coders seem to hate.

    I've been direct with my team about it being a legitimate 
    feeling of grief and the grieving process that comes along 
    with it. It's been helpful for folks to hear that they aren't 
    alone in that feeling.

This is super great. God, I wish all leaders had half this much empathy! Good on you.

▲ ASalazarMX 4 hours ago | parent | next [-]

I am one of those weirdos that found joy in business software. The clear specifications, reasonable timelines, and enough technical freedom, let you focus on clean, secure, resilient architectures.

I find that I struggle more with personal projects, as I tend to take things where I'm not even in the skirts of the learning curve, and consequently redo my work a few times.

▲

adjejmxbdjdn 17 minutes ago | parent | next [-]

I’ve enjoyed it too.

One of the fun things to do would be to use the 8 hrs of work to spend about 4-5 hrs working on deliverables, which was usually sufficient to exceed expectations, using 2-3 of the remaining hours (I’d keep 1-2 hrs for myself), to make significant architectural improvements.

I’d bring in an improvement every 6 months or so and suddenly the app would get significantly better and I’d get credit for it.

▲

swat535 2 hours ago | parent | prev | next [-]

> The clear specifications, reasonable timelines, and enough technical freedom, let you focus on clean, secure, resilient architectures.

I have no idea where you work but 90% of companies are not like that. In fact, it's the opposite: filled with awful management, terrible timelines and legacy code.

Engineering had always been a nuisance to them and getting basic approval for maintenance regarding technical debt has been an uphill battle.

▲

JohnBooty 3 hours ago | parent | prev | next [-]

Wow. That was hardly ever the case in my experience in ~30 years in the industry. I enjoy(ed) what you’re describing too but… how common was this for you?

▲

wincy 3 hours ago | parent [-]

Different person but I’ve been a SWE about ten years now - my favorite work has been improving the CRUD stuff people have left behind. Like the time I took a proprietary document they were using to document their REST apis and wrote a converter to turn those into OpenAI spec compliant yaml files, taking a single tenant application and making it a secure multienant application so instead of 80 different app services we had two, coalescing all their data sources into one normalized DB. There’s a lot of work I’ve done I’m really proud of. I’ve always found myself being the “in the muck” guy fixing up and bettering legacy code, I’ve always felt that was really rewarding and interesting.

▲

lowbloodsugar 3 hours ago | parent [-]

Sure. If you get pleasure in fixing really badly broken shite, there’s tons of opportunity for that, but no money in it. Only money in new features, which is why the codebase is what it is. I have, on rare occasion, been the fixit guy called in temporarily to fix another teams work or get it out the door: that was fun. Short lived , but fun.

	▲	szundi 2 hours ago \| parent [-]
		[dead]

▲

esseph 4 hours ago | parent | prev | next [-]

>I am one of those weirdos that found joy in business software. The clear specifications, reasonable timelines, and enough technical freedom

Where do you work! :)

	▲	swat535 2 hours ago \| parent [-]
		I asked the same question, so that I could apply..

▲

skydhash 2 hours ago | parent | prev [-]

> The clear specifications, reasonable timelines, and enough technical freedom, let you focus on clean, secure, resilient architectures.

The nicest thing was when you nailed down the architecture and then you are mostly twiddling your thumbs while waiting for the PM guys to have the next feature idea. Maintenance and bug fixing is a breeze.

▲ everforward 5 hours ago | parent | prev | next [-]

> not 99% tweaking reports, trying to implement arcane and contradictory business logic, or fighting with shitty and frustrating externalities.

Those are the parts the LLM is bad at. The 1% of stuff that was interesting was worth looking forward to.

I’m unconvinced about architecture mattering much. I used to think that, but these days I’m leaning towards it being the product of a problem we don’t have anymore. Architecture used to be dangerous and time-consuming to redo. If an AI can do that safely for $100 or $1000 in tokens (one day), that ROI is maybe negative

▲

JohnBooty 3 hours ago | parent | next [-]

In a big production codebase with lots of active customers and data, architecture changes still feel pretty difficult even with LLMs accelerating them by an order of magnitude — migrating and backfilling data and all of that. That’s more complex than pointing Claude at a repo and saying “rewrite this in Rust.”

I guess you’re right, though - what is the ROI of keeping the architecture clean? It certainly saves time and money later, but it’s unclear if it’s a net win.

(It’s of course also significant to note that the upfront work of figuring out the right architecture and keeping the code clean has also been correspondingly reduced as well. Both sides of the equation are affected…)

The industry never really figured out a way to reliably answer this question in the pre-LLM days either, so… I suspect it will continue to be hard to determine.

	▲	2 hours ago \| parent [-]
		[deleted]

▲

slopinthebag 4 hours ago | parent | prev [-]

in my experience it takes more than a day to sufficiently migrate bad architecture to a good one. like, many more days than it took to vibe the original implementation. having the prototype is good to understand what you want, but then going back and rebuilding it properly is a longer task. which is fine.

▲ rco8786 16 minutes ago | parent | prev | next [-]

It sounds like you could be on my team, tbh.

▲ bah9 3 hours ago | parent | prev [-]

I think this is not "parallel universe". Selection bias: people who love to code often choose non trivial frontier work. They tend to grirf about agentic workflow the most. Myself included.