4 ms·

The author was on a mismanaged project and his takeaway is to blame his fellow devs rather than hold management accountable. In fact, he does not even seem to r

The author was on a mismanaged project and his takeaway is to blame his fellow devs rather than hold management accountable. In fact, he does not even seem to recognize the existence of a managerial issue. This whole article reeks of imposter syndrome. Of course, it must be the case that all the devs who are more productive and impactful than the author are actually secretly very bad, and that the author's inability to understand technologies like Rx, validation and testing frameworks is actually a hidden strength because it makes him some perfectly interchangeable lowest common denominator developer. I hate/hated working with Rx, but it is fundamentally not challenging or complex. This story is common because the types of people who are capable of single-handedly building large parts of a software product in a short time are naturally the ones who are "hyper-productive" and leveraging a tonne of different technologies and paradigms. The unexceptional "slow and steady" devs are usually not capable of having that kind of impact. When devs like the author do manage to single-handedly deliver entire codebases (e.g. over long periods of time), they are typically just as bug-ridden and unmaintainable as what the "rock star" devs produce. Ultimately, the onus is on businesses to avoid crutching themselves entirely on a single developer's output. But there are a heap of shitty businesses that have no method for delivering software other than to let singular, highly motivated and passionate developers "go HAM" on the codebase with no oversight. These businesses deserve to fail, and the unmaintainability of the code base after the departure of their key players represents the correction of a market anomaly. >Then suddenly, the frontend lead quit for greener pastures What does this even mean? Key personnel do not "suddenly" quit.

moffkalast 3y ago
The main management issue with this project sounds like the lack of prototyping while requirements are unknown. Until they are rock solid every piece of code written should be considered expendable. I bet the guy suddenly quit once it became obvious that they'd have to maintain a poorly fit monstrosity and management wouldn't support a full rewrite that was badly required now that they knew what they actually needed. And because they probably got a better paid offer from some other place where they could build something from scratch again. Or maybe I'm just projecting, lmao.
pjerem 3y ago
> Of course, it must be the case that all the devs who are more productive and impactful than the author are actually secretly very bad That's exactly what is not implied. The point is not the tech. Any tech can be good. The thing is that while you can be a brillant programmer who makes super smart design choices using the better techs, it's not enough. If you create a smart and powerful architecture but you fail to document it and then convince, train and onboard the rest of the team, you may be a brillant programmer but you are also a bad team member. Those people are not wrong, they can be very productive or useful, but you have to identify them and make them work alone, because that's where they strive. And that's where I agree with you when you say it's a management issue. Those people are frequently really good at abstract thinking, which is a great power for a programmer but can be an issue when you have to communicate clearly a train of thought with other people. In my experience, this can be a root of conflicts between people that otherwise have a good relationship, because it ultimately leads to programmer A thinking that programmer B is over engineering everything and programmer B thinking that programmer A is too stupid. > When devs like the author do manage to single-handedly deliver entire codebases (e.g. over long periods of time), they are typically just as bug-ridden and unmaintainable as what the "rock star" devs produce. That's why devs like the author are never asked to single-handedly deliver entire codebases but to bring their skillset to a team that is tasked to maintain long term code base. And maintening long term codebases for a team may imply doing things the boring and simpliest way.
- CipherThrowaway 3y ago
  I'm yet to see evidence that the types of people who whinge about these types of "brilliant programmers" are themselves much better at documentation, training and onboarding a team. The fact that devs like this are even in a position to whine and complain about their projects becoming unmaintainable after the star team mate leaves is a clear demonstration that they themselves have not made any substantial contribution to the maintainability or transferability of the codebase. Further, it shows they lacked the ability to professionally advocate for these things within the business. I'm very skeptical about these situational anecdotes where someone with low impact complains about someone with high impact. "I was on a team where the guy who wrote everything left and then everything sucked" is not a compelling vantage point.

moffkalast 3y ago

The main management issue with this project sounds like the lack of prototyping while requirements are unknown. Until they are rock solid every piece of code written should be considered expendable. I bet the guy suddenly quit once it became obvious that they'd have to maintain a poorly fit monstrosity and management wouldn't support a full rewrite that was badly required now that they knew what they actually needed. And because they probably got a better paid offer from some other place where they could build something from scratch again. Or maybe I'm just projecting, lmao.

pjerem 3y ago

> Of course, it must be the case that all the devs who are more productive and impactful than the author are actually secretly very bad That's exactly what is not implied. The point is not the tech. Any tech can be good. The thing is that while you can be a brillant programmer who makes super smart design choices using the better techs, it's not enough. If you create a smart and powerful architecture but you fail to document it and then convince, train and onboard the rest of the team, you may be a brillant programmer but you are also a bad team member. Those people are not wrong, they can be very productive or useful, but you have to identify them and make them work alone, because that's where they strive. And that's where I agree with you when you say it's a management issue. Those people are frequently really good at abstract thinking, which is a great power for a programmer but can be an issue when you have to communicate clearly a train of thought with other people. In my experience, this can be a root of conflicts between people that otherwise have a good relationship, because it ultimately leads to programmer A thinking that programmer B is over engineering everything and programmer B thinking that programmer A is too stupid. > When devs like the author do manage to single-handedly deliver entire codebases (e.g. over long periods of time), they are typically just as bug-ridden and unmaintainable as what the "rock star" devs produce. That's why devs like the author are never asked to single-handedly deliver entire codebases but to bring their skillset to a team that is tasked to maintain long term code base. And maintening long term codebases for a team may imply doing things the boring and simpliest way.

CipherThrowaway 3y ago
I'm yet to see evidence that the types of people who whinge about these types of "brilliant programmers" are themselves much better at documentation, training and onboarding a team. The fact that devs like this are even in a position to whine and complain about their projects becoming unmaintainable after the star team mate leaves is a clear demonstration that they themselves have not made any substantial contribution to the maintainability or transferability of the codebase. Further, it shows they lacked the ability to professionally advocate for these things within the business. I'm very skeptical about these situational anecdotes where someone with low impact complains about someone with high impact. "I was on a team where the guy who wrote everything left and then everything sucked" is not a compelling vantage point.