The conversation

Lessons learnedExperience excerpt · English

In my experience, if you're working on a green-field project, you're working long hours, making …

In my experience, if you're working on a green-field project, you're working long hours, making very little visible progress, you have to write a lot of code, make important decisions. All the while management is breathing down your neck and asking 'why isn't it ready yet'. Once the thing is shipped, then all the important people come out of the woodwork, who were surely there all along, 'supporting' you from behind the scenes, there are photo ops and important people shaking hands. If they feel particularly charitable, then you might get a seat at the table. There's talk of spinning up a team around the product, and people fall over each other to get to lead it. But the thing is, most likely they don't need your expertise any more, not really, once everything works, you don't really have a negotiating position as a dev. They get some cheap juniors to fix the bugs and add the missing feature niggles - hiring 3 juniors might not even be cheaper, the point is management does not have to depend on you , they can play their human resource games. …

Original discussionAI isn't replacing jobs. AI spending is562 source comments · at import
4

What was this responding to?

Parent context · original excerpt

GL

As a recently laid of senior engineer, to the extent that my job was replaced, it was replaced with offshore junior devs who'd already been working with the company for over year with a pretty rough level of productivity by man-hour, though maybe taking 3x the time to get things done is worth it if they're cheap enough. Which is to say I see my layoff as as cost cutting backed by a premise that there is no value in retaining senior level talent, to try and keep operating in the black, not because AI was materially producing a lot of benefits. (Because to the extent it was, I was the one reaping them compared to the offshore folks and less experienced onshore ones.)

Full original

Community replies 0

No community replies yet. Add your perspective.

Replies from the source 4

Direct replies available in this import. Original-language excerpts.

BO

You have an amazing amount of confidence that the new devs are going to fix subtle race conditions… They’ll add a few sleep(5) calls to make them go away though..

Full original
CA

> 'But only I can fix that complex race condition, that popped up half a year after development' - well if it was good enough with the bug for people not to notice it for half a year, it's going to be good enough for another half, until the new devs can fix it. From my time at AWS, and in light of the recent DynamoDB dns race condition bug, this is a line of thinking that is problematic. There is so much complexity in the inner workings of any one of those services. Many of those services are now composed of many teams, each having turned over completely multiples of times. Yes there are runbooks and knowledge passed down from each generation, to some extent. But when you hit some critical outage, edge case, etc., those people running the systems have such a different relationship to the system having simply maintained it vs. built it.

Full original
NC

> In my experience, if you're working on a green-field project, you're working long hours, making very little visible progress, you have to write a lot of code, make important decisions. Funny, this is the complete opposite of my experience. Greenfield projects I've been a part of have had a ton of highly visible progress with _frequent_ updates to stakeholders basically from day 1. Same goes for complex additional features.

Full original
ET

I am finding this to be the new "meta" for the software development lifecycle. Given this new reality, it's getting harder and harder to actually invest in ambitious, green-field projects. In this new meta, individual contributors and leadership don't trust each other, leading to a vicious feedback loop of making it harder and harder to jumpstart ambitious projects. It's hard to commit to a green-field project that is predicated on a level of risk that leaders are hesitant to take on as they would also take on the "counterparty risk" of the expert individual contributors holding them over the barrel to finish the project. The expert individual contributors are likewise hesitant to devote themselves to the task knowing that once leadership considers the "hard bits" to be done, leadership's aversion to risk will try to swap out the expert-individual-contributor roles with much more replace…

Full original
Continue on Hacker News

Respect different perspectives. Share concrete experiences.

Sign in to post, reply, repost, and quote.