4 ms·

You probably should have gotten the raise, and there are some fair and unfair reactions to you here. There isn’t enough information to judge if you’re summarizi

by dahart 4y ago

You probably should have gotten the raise, and there are some fair and unfair reactions to you here. There isn’t enough information to judge if you’re summarizing this fairly, but maybe this is related: one thing I’ve seen happen many times over is that the first person or first few people to work on a project have a massive productivity advantage over people that come later. We could call it “10x” but it’s not measurable, it’s just very large. The reason that first-in people are more productive is they are witness to all of the initial assumptions and initial architecture, they decide and understand how every corner of the thing works, and they understand how to refactor it quickly and change core pieces of the pipeline. By the time other people join later, there’s a whole bunch of dependencies that make it both difficult to understand the whole system and time-consuming to change - a core piece has subsystems that depend on it, and each subsystem has unit tests, etc. etc.. People who don’t have familiarity with the entirety of the system have to make small changes and tread carefully, and this is almost completely independent of the skill of the programmer. The strongest example of this is when I built a codebase with a partner for a cloud service in a year, and then sold the company to a group of engineers that I believe are probably better than I am. It took them much longer, several years, to get to the point where they could swap out and rewrite major features. But it’s absolutely clear to me this wasn’t because I’m more productive than they are, it’s because the system complexity was high, learning what I did and why took a lot of time, my documentation was sub-par, I wasn’t around enough and able to help them understand what I did. BTW did you try to get other programmers involved? Is it possible part of the issue was doing too much solo work and not communicating enough? Not saying this has anything to do with you, but I’ve known and managed some very highly skilled programmers that are difficult to work with despite their apparent code productivity. It just means that skill and code output are only part of the job, and high skill can’t always overcome other issues.

BlargMcLarg 4y ago
The context you're presenting is different from the one presented by GP. Making a few generous assumptions, both GP and the team started from the same point (requirements) and made a similar system, same inputs, same outputs. If that is the case, doing it in a shorter timeframe, while alone compared to a team of devs is insane. I don't necessarily buy GP's story, but it's not the same story as "reading up and extending a system is harder than making a system", where group B would have a different starting point as group A.
- ratww 4y ago
  I can't see why you don't buy it. I have seen this kinda thing happening dozens of times in my career. Both in startups (especially in startups!) but also very frequently even in enterprise. One developer makes a system in N months, a team of people is hired to rewrite it, it takes 2x or 3x the amount of time. A tale as old as time. It is kinda obvious from the get go that it would take more time. With 19 developers there is a much larger organisation and communication overhead. If there's more managers, then means A LOT of bikshedding. In enterprise, there's probably someone responsible for the architecture, there will most certainly involve architecture astronautics "to help developers move faster", which will invariably make them slower.
  - BlargMcLarg 4y ago
    Not fully buying it doesn't have to do with not believing the feasibility of GP's story. Rather, stories tend to be more complex than any given individual tends to represent them, and I'd like to give a full team of 19 developers the benefit of the doubt they didn't run around like headless chickens. Case in point, if you mention managers and communication outside those 19 developers, that already changes things quite a bit. That individuals can truly develop amazing things which most teams could only hope to reach shouldn't be doubted. Plenty of solo projects with absolutely astounding results exist to prove the opposite. Enough that one could argue they fall outside the realm of 'they are geniuses with a rare talent'. Management types like to pretend developers are idiot savants capable of programming, but good developers are far more than that.
    - ratww 4y ago
      I'm completely ok with giving a team of 19 developers the benefit of the doubt, but in this case it doesn't matter if they're good or bad developers. They're 19 people. There's gonna be lots more overhead if it's a project that one person was able to do themselves. Bring in a junior developer in the middle and you're gonna have to train them, slowing down the process. Bring in a new senior and he might not slow you down, but won't be productive for a while. Bring a designer and that overhead becomes even higher. Bring a second designer and it's even worse. Another stakeholder? Same deal. Dailies and Retros are too crowded? Divide the team in two and bring another manager? Same deal. Software is hard. Head count doesn't mean speed. In fact it often means the opposite. EDIT: About solo devs, it's funny that in HN there is a bit of a cult for good developers that manage to make things useable for others, and that includes everything from products to libraries and languages. But as soon as someone tells a story about someone or some team being unable to take over a solo-dev work, their work is immediately treated as if it were complete garbage. One thing that made me a better developer was stopping having this attitude. Maybe the reason I can't understand is that I am the one who's not good enough. EDIT 2: Btw, sorry if my tone sounds as if I'm disagreeing with you. I’m not! I also don't think you were doubting the OP. It's just that I keep seeing this industry making the same bad assumptions about team-size, year in year out.
nyanpasu64 4y ago
Reminds me of Peter Naur's essay, "Programming as Theory Building": https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf
- bluesnowmonkey 4y ago
  Love this article. It contains a very deep and important insight, that the program and programmer are inseparable. Can’t replace one without replacing the other. People often pretend you can. In big companies a new team will “take ownership” of an existing system. But they won’t really understand it until they rewrite it. Wanting to rewrite is not a character flaw, it’s just an inherent part of the process. That said, if one person wrote the first version, then one person can write the second version. Teams don’t have to get bigger.

by dahart 4y ago

BlargMcLarg 4y ago

The context you're presenting is different from the one presented by GP. Making a few generous assumptions, both GP and the team started from the same point (requirements) and made a similar system, same inputs, same outputs. If that is the case, doing it in a shorter timeframe, while alone compared to a team of devs is insane. I don't necessarily buy GP's story, but it's not the same story as "reading up and extending a system is harder than making a system", where group B would have a different starting point as group A.

ratww 4y ago
I can't see why you don't buy it. I have seen this kinda thing happening dozens of times in my career. Both in startups (especially in startups!) but also very frequently even in enterprise. One developer makes a system in N months, a team of people is hired to rewrite it, it takes 2x or 3x the amount of time. A tale as old as time. It is kinda obvious from the get go that it would take more time. With 19 developers there is a much larger organisation and communication overhead. If there's more managers, then means A LOT of bikshedding. In enterprise, there's probably someone responsible for the architecture, there will most certainly involve architecture astronautics "to help developers move faster", which will invariably make them slower.
- BlargMcLarg 4y ago
  Not fully buying it doesn't have to do with not believing the feasibility of GP's story. Rather, stories tend to be more complex than any given individual tends to represent them, and I'd like to give a full team of 19 developers the benefit of the doubt they didn't run around like headless chickens. Case in point, if you mention managers and communication outside those 19 developers, that already changes things quite a bit. That individuals can truly develop amazing things which most teams could only hope to reach shouldn't be doubted. Plenty of solo projects with absolutely astounding results exist to prove the opposite. Enough that one could argue they fall outside the realm of 'they are geniuses with a rare talent'. Management types like to pretend developers are idiot savants capable of programming, but good developers are far more than that.
  - ratww 4y ago
    I'm completely ok with giving a team of 19 developers the benefit of the doubt, but in this case it doesn't matter if they're good or bad developers. They're 19 people. There's gonna be lots more overhead if it's a project that one person was able to do themselves. Bring in a junior developer in the middle and you're gonna have to train them, slowing down the process. Bring in a new senior and he might not slow you down, but won't be productive for a while. Bring a designer and that overhead becomes even higher. Bring a second designer and it's even worse. Another stakeholder? Same deal. Dailies and Retros are too crowded? Divide the team in two and bring another manager? Same deal. Software is hard. Head count doesn't mean speed. In fact it often means the opposite. EDIT: About solo devs, it's funny that in HN there is a bit of a cult for good developers that manage to make things useable for others, and that includes everything from products to libraries and languages. But as soon as someone tells a story about someone or some team being unable to take over a solo-dev work, their work is immediately treated as if it were complete garbage. One thing that made me a better developer was stopping having this attitude. Maybe the reason I can't understand is that I am the one who's not good enough. EDIT 2: Btw, sorry if my tone sounds as if I'm disagreeing with you. I’m not! I also don't think you were doubting the OP. It's just that I keep seeing this industry making the same bad assumptions about team-size, year in year out.

nyanpasu64 4y ago

Reminds me of Peter Naur's essay, "Programming as Theory Building": https://pages.cs.wisc.edu/~remzi/Naur.pdf https://pages.cs.wisc.edu/~remzi/Naur.pdf

bluesnowmonkey 4y ago
Love this article. It contains a very deep and important insight, that the program and programmer are inseparable. Can’t replace one without replacing the other. People often pretend you can. In big companies a new team will “take ownership” of an existing system. But they won’t really understand it until they rewrite it. Wanting to rewrite is not a character flaw, it’s just an inherent part of the process. That said, if one person wrote the first version, then one person can write the second version. Teams don’t have to get bigger.