4 ms·

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,

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.

franktankbank 1y ago
What dev to do then?
- WalterSear 1y ago
  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.
  - ponector 1y ago
    It was never an issue to build something. The challenge is to sell your product to cover dev costs at least.
    - WalterSear 1y ago
      That too, is easier than ever. It's just work, there's no secrets to it.
      - majormajor 1y ago
        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?
      - intended 1y ago
        Nope - this is one of the blind spots people have. Right now GeAI is making it easier for many people to get started on projects they have. It’s improving starts of new projects. GenAI is not creating demand for new projects. Or new novels, new movies, new stories. People are ending up creating, essentially, for themselves.
        deleted 1y ago
        [deleted]
        deleted 1y ago
        [deleted]
  - fgauer 1y ago
rcbdev 1y ago
This markedly does not apply if the stack is esoteric enough and/or the code is bad enough.
- torginus 1y ago
  I don't think aspiring to write awful backends in Elixir is the solution to this problem.
  - moffkalast 1y ago
    Like alcohol, technically it is a solution.
BobbyTables2 1y ago
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..
- georgemcbay 1y ago
  > 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).
  - kmac_ 1y ago
    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.
    - georgemcbay 1y ago
      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.
captainkrtek 1y ago
> '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.
- nradov 1y ago
  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.
  - captainkrtek 1y ago
    For sure, as long as the product keeps selling and it stays up, great, the business is still viable. I think its more analogous to a car with some problems that may be going unchecked; it still drives and gets you from A->B, until it doesn’t.
- kamaal 1y ago
  >>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.
ncphillips 1y ago
> 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.
- nurettin 1y ago
  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.
- TurboHaskal 1y ago
  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.
- HeavyStorm 1y ago
  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.
etruong42 1y ago
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.

franktankbank 1y ago

What dev to do then?

WalterSear 1y ago
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.
- ponector 1y ago
  It was never an issue to build something. The challenge is to sell your product to cover dev costs at least.
  - WalterSear 1y ago
    That too, is easier than ever. It's just work, there's no secrets to it.
    - majormajor 1y ago
      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?
    - intended 1y ago
      Nope - this is one of the blind spots people have. Right now GeAI is making it easier for many people to get started on projects they have. It’s improving starts of new projects. GenAI is not creating demand for new projects. Or new novels, new movies, new stories. People are ending up creating, essentially, for themselves.
      - deleted 1y ago
        [deleted]
      - deleted 1y ago
        [deleted]
- fgauer 1y ago

rcbdev 1y ago

This markedly does not apply if the stack is esoteric enough and/or the code is bad enough.

torginus 1y ago
I don't think aspiring to write awful backends in Elixir is the solution to this problem.
- moffkalast 1y ago
  Like alcohol, technically it is a solution.

BobbyTables2 1y ago

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..

georgemcbay 1y ago
> 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).
- kmac_ 1y ago
  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.
  - georgemcbay 1y ago
    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.

captainkrtek 1y ago

> '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.

nradov 1y ago
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.
- captainkrtek 1y ago
  For sure, as long as the product keeps selling and it stays up, great, the business is still viable. I think its more analogous to a car with some problems that may be going unchecked; it still drives and gets you from A->B, until it doesn’t.
kamaal 1y ago
>>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.

ncphillips 1y ago

> 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.

nurettin 1y ago
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.
TurboHaskal 1y ago
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.
HeavyStorm 1y ago
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.

etruong42 1y ago

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.