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.
'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.
This applies to ambitious feature requests as well - if the code's good enough that the contract was signed, the business requirement was met, they can just kick the can down the road until they can fix it.
> 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.
I've seen both kinds. GF projects where the senior devs feel that they have to get something right from the beginning, spending a year just on that piece (a set of widgets, a data ingestion framework, a state machine that covers the entire underlying algorithm). And other GF projects which have frequent updates and are open to development with very few speed bumps.
Of course you can call out the former examples as incompetent or hubris, and they will probably occur less and less, but nevertheless they exist.
I was going to say the same. In my experience I can say without hesitation green field projects is how you advance your career, become visible and get promoted.
What is progress? Are you sure that was greenfield?
I think the OP meant projects that required long investments without immediate returns. For instance, a platform migration that requires many components to be finished before it can even be tested. Or, real greenfield, like a new product venture with a unproven customer thesis. The kind that requires months of work before you can go to market and validade... How do you report progress? Components built, percentage completed? Without something a user can drive or a seller sell, that's not progress... It's just speculation.
> '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.
From a certain perspective, that line of thinking is only "problematic" if customers stop paying. In other words, the product only has to maintain a certain minimum quality threshold and doing any more is a waste of money. I don't necessarily agree with that myself but it is a common attitude.
>>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.
Long stays in most companies are practically non-existent these days, apart from a few folks who are present for long, unfortunately these people are often called lifers, coasters etc.
Simply put, no one person can say they contributed most to the building of a system. Barring very few rare projects.
So you already need the runbook, documentation model to run things, for the reason people themselves work along those lines.
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 replaceable roles and ultimately replace the expert individual contributors.
P.S. The parallels between this cycle of mistrust and the modern dating crisis (in the US) does not elude me.
> 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..
I don't think torginus's point is that the new devs will find the proper fixes for the code, more that such a hack might be good enough in the eyes of both the company's management and the company's users.
As much as it pains me to recognize this (as a fan of clean, elegant code) not every bit of software needs to be clean and elegant to achieve its intended purpose (which is, at least in the corporate software world being discussed here, to make money).
If you meet the needs of your software's users, you can make a lot of money for a lot of years selling a piece of crap held together with chewing gum and elastic bands (and many companies have).
Such "sleep(5)" is actually a milestone in a project, a milestone that marks the beginning of deterioration and the end of architectural changes. I've seen multiple pull requests with "sleep" and similar shortcuts, and worse, I've rewound coding agent context and changes because of such model suggestions. I'm responsible for informing management about the consequences of such shortcuts and why we have to take the correct, often more time-consuming and more expensive, approach to avoid project derailment in the long term. I believe that management picks employees. If they don't trust my judgment, then it's okay for me, but I don't feel obliged to be responsible for the consequences.
I'm certainly not defending such code, just saying that its out there and in some very successful projects.
If the managers where you work understand the dangers of taking on such tech debt and are willing to put in the resources to avoid it, consider yourself lucky, because in my experience that's not at all universal, or even particularly common, though it does certainly exist at some places.
A old Twitter thread: “what’s one thing you wish you didn’t know about cloud providers? Answer: eventual consistency means it just sleeps and retries all the way down.”
IMHO, there's never been a better time to build your own product and learn to sell it. The effort that AI implementation requires is clearly exponential to complexity of the organization.
You can build faster now that you ever have: I am building faster than I have in 25 years of engineering. You have more capable support for all the unfamiliar processes of building a business imaginable.
And almost everyone larger than you is finding it harder to achieve similar productivity gains from implementing AI, if not outright struggling with it. This is a golden moment and won't last long.
I already get multiple cold emails a month selling me some sort of software product or service that I don't need and that wouldn't work for me.
If a bunch of additional people start going and building MVPs, what keeps that from becoming even more of a flood, like what you get if you post a job application on LinkedIn nowdays?
I think sales is likely to get harder, not easier, soon.
And to your earlier post, I think the big question is: can individuals get more done on their own now building new things because of less organizational issues compared to incumbents, or because of less product complexity and scope? Is the organization the problem, or is the complexity of stuff built to try to service a thousand different previous sales deals and customers?
Productivity has always been inversely exponentially correlated with manpower, I don't think this is related to AI, and I don't think AI speeds anything up in this scenario. If nothing else you're now constraining what could be one-man development speed to the speed of a chat-session, which is much, much slower.
If you know what you're doing (and most times even if you don't, yet) it's much faster to work actually solo, without bothering with any AI assistance except at most something like one-line auto-complete on command.
I can't agree with this more, and it's exactly both the position and the impetus of my personal action plan for the next several years to come.
Truly, AI levels the playing field, if you just have the inclination to look at it that way. It brings such potential to the right people. In my hands, a software developer who has been slinging code for food for 40+ years, I am a 'god' with a cheap monthly subscription to Claude Code. I can run several projects and keep track of every one of them and see progress like I've never had that chance to, in my entire lifetime. And yes, I still wield the stick, because I KNOW how to do this stuff. Claude really doesn't. Claude just gives me raw material, individual orchestral parts as it were, that I can put together with a conductor's baton.
My enterprise client? They get barebones slop. Enough to keep things alive but yet never be scalable and extendable. And they deserve that. They slaughtered our entire US based team and went overseas. They retain me to keep the wheels on while offshore wires up worthless, unpredictable AI agents to 'enhance' the product. I'm taking their money until I can break free sometime next year. They get the scraps now, and they will never know until karma brings them their bitter fruit.
My personal project. A really, really fun and fluid development momentum. Truly art and logic combined with Claude doing the grunt work for me. Absolutely a blast and it will have a user base, and the user base will really enjoy the results.
New partnerships. You can now make ANYONE you know, that much more viable, that much more tech savvy. As an individual, with your talents and our new little 'digital helpers', you, yourself can become the David to any Goliath you wish. You can help elevate ideas, small teams, and aspiring entrepreneurs and have a blast doing so.
Shed the notion that this moment has to be dark for you. It doesn't. It just takes seeing that maybe, just maybe, the boneheads that are trying to capitalize in these horrendous actions which include lying about AI, lying about the reasons they are laying off, etc. are bringing about their very demise in real time. Clueless as to what they are doing.
And those of us with the knowledge, ethics, high standards, discipline, and honor, are now armed with the very thing that can bring down those who created it to harm us.
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.
'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.
This applies to ambitious feature requests as well - if the code's good enough that the contract was signed, the business requirement was met, they can just kick the can down the road until they can fix it.