6 ms·

Trouble is I've burnt a lot of man hours fixing shit that was done truly shitly by people who had a reputation for getting shit done... and then they move onwar

by gHosts 5y ago

Trouble is I've burnt a lot of man hours fixing shit that was done truly shitly by people who had a reputation for getting shit done... and then they move onwards and upwards to another role to create more shit that needs cleaning up before it can be really called a product and actually sold.

dragonwriter 5y ago
> I've burnt a lot of man hours fixing shit that was done truly shitly by people who had a reputation for getting shit done... IME, people who have a reputation of getting shit done tend to: (1) Have little ethics around quality of work, and (2) Have their greatest skill in self-promotion which is used to sell their lack of attention quality as a pragamtism. People who have a reputation for getting shit done well, OTOH...
- MattGaiser 5y ago
  I don't see this as an ethics issue, but just a trade off and given how long employees stay in a role, there is no long term. I can do both. "Do you want carefully tested code in 3 days or do you want it tomorrow?" And whenever I have put it to any non-technical product manager or business analyst, 90% of the time the answer is "tomorrow." Product Managers get a reputation for getting shit done too by encouraging this.
  - genericone 5y ago
    Exactly, I think its more like, capture 80% of the value tomorrow, or capture 0% until day 3, where it now becomes >80%, but only immeasurably so in the eyes of the program. There will be future risk to that work that was done in 1 day, and that's where the tradeoff comes into play.
- zsmi 5y ago
  I always thought is was more of a semantics things. For example the article, and all the comments in this thread at this time, don't define the word "done". I am pretty sure we're not all using the same criteria for "done".
0xy 5y ago
One thing I've noticed about "get shit done" people is that they quickly become the poster child to management for "Dirty Deeds Done Dirt Cheap". Managers go directly to these people for sketchy, half-baked ideas done in 3 seconds that can boost whatever metric makes them look good to their bosses. Of course, it's always an unmaintainable spaghetti mess. Over my years in the industry I've come to realize these types of people are really damaging to engineering culture within an organization. They represent a quick buck over quality.
- leetrout 5y ago
  And hero worship when they circle back and clean up their own messes.
  - bluesnowmonkey 5y ago
    Whoa, hold up, if someone made a mess and then cleaned it up, that would be just fine. Great even. Almost nobody does that. Around here there are people making messes but getting shit done, people cleaning things up but looking like they’re getting nothing done, and people who actually do nothing. Somebody who gets something done AND cleans up the mess is automatically top tier as far as I’m concerned.
  - macawfish 5y ago
    Or when they clean up their own messes in a way that results in new messes to be cleaned up later
- grecy 5y ago
  I worked at a very large telco for 4 years, and you just described a few of the people I worked with better than I ever could. I once got a call from a Project Manager on conference with a bunch of VPs, letting me know I was now the sole support person for a new customer-facing product that went live that day. On the call I confirmed with everyone listening there was no documentation for the entire system, no support procedures, nobody could tell me the name of the server or any credentials to even access anything, or what to do if anything went wrong. But there it was, dumped in my lap. That PM always got a green tick for delivering projects on time, and got many promotions and bonuses.
marktolson 5y ago
There are those who forge the path and those who finish the paving. Both types are required as it's exceptionally rare to find people who can consistently do both.
- t0mbstone 5y ago
  I can do both (and have), but it really is a case of time constraints. So I let management decide. Do they want a quick prototype that is going to be unstable and buggy and difficult to maintain long-term, or do they want something solid that is well tested and stable and refactored and well-documented so newcomers can work on it easily as the team grows? There are trade-offs. The quick prototype allows you to get something in front of your stakeholders that resembles the desired end product. This allows them to easily identify things that they missed, and allows them to quickly change direction if need be. This can backfire really easily though, because if your prototype is too good, they will think it's a polished product that can be sold even though it's completely lacking tests and is duct taped together behind the scenes. You have to CONSTANTLY remind them that THIS IS NOT A STABLE PRODUCT and that it still needs tests and refactoring and clean-up. A lot of the time, you will have to create the JIRA stories and advocate for this extra work to be done yourself, or else management simply won't prioritize it. I've been a part of multiple startups with successful exits now, and they were all based on code that was rapidly prototyped and duct taped together behind the scenes. Being able to pivot and adapt is more important than stability, when you are a startup. But once the startup has been bought by a larger company, it's probably time to rewrite and refactor and stabilize things. Now that you have big clients and people depending on the systems, it's time to batten down the hatches and prioritize stability and longevity.
  - w0m 5y ago
    > So I let management decide. Do they want a quick prototype that is going to be unstable and buggy and difficult to maintain long-term, or do they want something solid that is well tested and stable and refactored and well-documented so newcomers can work on it easily as the team grows? In my experience; every time I've shown a quick prototype that 'mostly' worked - that went into production.
Verdex 5y ago
Yeah, a large problem in software engineering is that we have zero metrics for how terrible anything is. So, you have some engineers complaining about code written by another one of your vendors. Are they just unfamiliar with the technique/programming language being used? Or maybe the other vender is just too sophisticated and their engineers can just do better? Or maybe they were a bunch of hacks that threw together code until it worked well enough to pass the acceptance criteria needed to get the final milestone payment released. One way to pass the buck is to just "hire on the ability to get shit done" and justify it with "well, the shit needed to be done and now it is." I can see it working okayish in the short term. However, eventually you want something (or need something a competitor has) and the answer is "cannot be done because the codebase is infested with demon spiders." Meanwhile the "got shit done" people are either gone (if you're lucky) or insist that the only way to do it is to continue the nightmare development philosophy they created on their own that mixes ideas from shintoism and kabbalah into C++ templates. Every week they're "making good progress" but the features are going to show up exactly never.
- zebraflask 5y ago
  You know, I recognize that this is a somewhat serious discussion? But I can think of a few scenarios from experience where saying "the codebase is infested with demon spiders, can't do it" would be a satisfying thing to say in reply to unrealistic development requirements.
- taylodl 5y ago
  > "we have zero metrics for how terrible anything is" There's Cyclomatic Complexity (https://en.wikipedia.org/wiki/Cyclomatic_complexity https://en.wikipedia.org/wiki/Cyclomatic_complexity) but I think that's too low-level for what we really need. Cyclomatic Complexity allows us to evaluate one function implementation versus another, when what we really want is the ability to evaluate different architectures and designs.
  - Verdex 5y ago
    Yes, we do have Cyclomatic Complexity and it seems like that's it. Unfortunately, Cyclomatic Complexity is of dubious value. Even the wiki link you have here contains a section where they question the correlation between CC and the number of defects. Some studies say yes, but it looks like total program length is also correlated and sometimes better. Or in other words, line count might be a better metric than CC, which isn't exactly a ringing endorsement. Additionally, even if CC turns out to be useful, it is rather targeted. Basically, it's a metric to make sure you don't have too many if-statements[1]. Not as effective in our current OO/FP world where lots of decisions can be shunted off to an unknown object or lambda. However, whether or not you want to claim CC is useful for non-if-statement branches, it definitely doesn't say anything about code that's bad because of bad variable names, or code that's bad because of deep inheritance, or code that's bad because the wrong abstraction is used, etc (which is kind of what you're already saying with your statement about architectures and designs). [1] - So, I guess you could probably create a CC setup that is able to count linear independent paths that aren't if-statement related. However, both OO and FP allow you to setup scenarios where the execution path indirection is decided at run time (pass in a different object implementation or a different lambda). So you crash head first into the halting problem pretty quickly. [Not to mention, I've never seen anyone try to do this ... although I haven't actually been checking very carefully, so maybe there are tools that try to do this in a limited fashion?] However, it's also debatable which linearly independent paths are bad and which ones are actually helpful. Like, I bet that TCP library call contains a ton of linear independent paths. But if you fix that by just vomiting your hand rolled communication protocol onto the internet with objectively less linear independent paths, then I can't call that an improvement in program comprehensibility just because the linear independent paths have been reduced.
29athrowaway 5y ago
The reason startups get large amounts of funding is because they are expected to grow exponentially. Tech debt mills cannot grow exponentially. They grow quickly for a couple of years, then stop growing once the accrued tech debt slows down growth. Once the 10xers/rockstar/ninjas that "got shit done" for years are asked to make things work for that missing "5% of the time", they will look for another job and disappear. Tech debt mills should not be treated as startups. They are small or medium businesses that are not prepared for exponential growth, and as such, do not deserve startup-level funding. The obsession over "getting shit done" and "shipping" are traits of tech debt mills. Sustainable growth and a long-term vision beats tech debt mill mentality.
gumby 5y ago
A positive use case that still matches your criteria: Used to work with a really nice guy (everyone loved him). Wrote code really fast. It worked. It was scary code though. When a customer had a crisis we’d send him in. He’d find the 10 holes in the dike and stick his fingers in. As soon as he went to work on something else the water would come rushing back in. But that was ok. He’d stabilize things while somebody wrote a saner patch. What he did was usually a clue about the underlying problem. Actually this wasn’t his only mode. You probably are running some of his decades old code right now. I could use someone like him again.

by gHosts 5y ago

dragonwriter 5y ago

> I've burnt a lot of man hours fixing shit that was done truly shitly by people who had a reputation for getting shit done... IME, people who have a reputation of getting shit done tend to: (1) Have little ethics around quality of work, and (2) Have their greatest skill in self-promotion which is used to sell their lack of attention quality as a pragamtism. People who have a reputation for getting shit done well, OTOH...

MattGaiser 5y ago
I don't see this as an ethics issue, but just a trade off and given how long employees stay in a role, there is no long term. I can do both. "Do you want carefully tested code in 3 days or do you want it tomorrow?" And whenever I have put it to any non-technical product manager or business analyst, 90% of the time the answer is "tomorrow." Product Managers get a reputation for getting shit done too by encouraging this.
- genericone 5y ago
  Exactly, I think its more like, capture 80% of the value tomorrow, or capture 0% until day 3, where it now becomes >80%, but only immeasurably so in the eyes of the program. There will be future risk to that work that was done in 1 day, and that's where the tradeoff comes into play.
zsmi 5y ago
I always thought is was more of a semantics things. For example the article, and all the comments in this thread at this time, don't define the word "done". I am pretty sure we're not all using the same criteria for "done".

0xy 5y ago

One thing I've noticed about "get shit done" people is that they quickly become the poster child to management for "Dirty Deeds Done Dirt Cheap". Managers go directly to these people for sketchy, half-baked ideas done in 3 seconds that can boost whatever metric makes them look good to their bosses. Of course, it's always an unmaintainable spaghetti mess. Over my years in the industry I've come to realize these types of people are really damaging to engineering culture within an organization. They represent a quick buck over quality.

leetrout 5y ago
And hero worship when they circle back and clean up their own messes.
- bluesnowmonkey 5y ago
  Whoa, hold up, if someone made a mess and then cleaned it up, that would be just fine. Great even. Almost nobody does that. Around here there are people making messes but getting shit done, people cleaning things up but looking like they’re getting nothing done, and people who actually do nothing. Somebody who gets something done AND cleans up the mess is automatically top tier as far as I’m concerned.
- macawfish 5y ago
  Or when they clean up their own messes in a way that results in new messes to be cleaned up later
grecy 5y ago
I worked at a very large telco for 4 years, and you just described a few of the people I worked with better than I ever could. I once got a call from a Project Manager on conference with a bunch of VPs, letting me know I was now the sole support person for a new customer-facing product that went live that day. On the call I confirmed with everyone listening there was no documentation for the entire system, no support procedures, nobody could tell me the name of the server or any credentials to even access anything, or what to do if anything went wrong. But there it was, dumped in my lap. That PM always got a green tick for delivering projects on time, and got many promotions and bonuses.

marktolson 5y ago

There are those who forge the path and those who finish the paving. Both types are required as it's exceptionally rare to find people who can consistently do both.

t0mbstone 5y ago
I can do both (and have), but it really is a case of time constraints. So I let management decide. Do they want a quick prototype that is going to be unstable and buggy and difficult to maintain long-term, or do they want something solid that is well tested and stable and refactored and well-documented so newcomers can work on it easily as the team grows? There are trade-offs. The quick prototype allows you to get something in front of your stakeholders that resembles the desired end product. This allows them to easily identify things that they missed, and allows them to quickly change direction if need be. This can backfire really easily though, because if your prototype is too good, they will think it's a polished product that can be sold even though it's completely lacking tests and is duct taped together behind the scenes. You have to CONSTANTLY remind them that THIS IS NOT A STABLE PRODUCT and that it still needs tests and refactoring and clean-up. A lot of the time, you will have to create the JIRA stories and advocate for this extra work to be done yourself, or else management simply won't prioritize it. I've been a part of multiple startups with successful exits now, and they were all based on code that was rapidly prototyped and duct taped together behind the scenes. Being able to pivot and adapt is more important than stability, when you are a startup. But once the startup has been bought by a larger company, it's probably time to rewrite and refactor and stabilize things. Now that you have big clients and people depending on the systems, it's time to batten down the hatches and prioritize stability and longevity.
- w0m 5y ago
  > So I let management decide. Do they want a quick prototype that is going to be unstable and buggy and difficult to maintain long-term, or do they want something solid that is well tested and stable and refactored and well-documented so newcomers can work on it easily as the team grows? In my experience; every time I've shown a quick prototype that 'mostly' worked - that went into production.

Verdex 5y ago

Yeah, a large problem in software engineering is that we have zero metrics for how terrible anything is. So, you have some engineers complaining about code written by another one of your vendors. Are they just unfamiliar with the technique/programming language being used? Or maybe the other vender is just too sophisticated and their engineers can just do better? Or maybe they were a bunch of hacks that threw together code until it worked well enough to pass the acceptance criteria needed to get the final milestone payment released. One way to pass the buck is to just "hire on the ability to get shit done" and justify it with "well, the shit needed to be done and now it is." I can see it working okayish in the short term. However, eventually you want something (or need something a competitor has) and the answer is "cannot be done because the codebase is infested with demon spiders." Meanwhile the "got shit done" people are either gone (if you're lucky) or insist that the only way to do it is to continue the nightmare development philosophy they created on their own that mixes ideas from shintoism and kabbalah into C++ templates. Every week they're "making good progress" but the features are going to show up exactly never.

zebraflask 5y ago
You know, I recognize that this is a somewhat serious discussion? But I can think of a few scenarios from experience where saying "the codebase is infested with demon spiders, can't do it" would be a satisfying thing to say in reply to unrealistic development requirements.
taylodl 5y ago
> "we have zero metrics for how terrible anything is" There's Cyclomatic Complexity (https://en.wikipedia.org/wiki/Cyclomatic_complexity https://en.wikipedia.org/wiki/Cyclomatic_complexity) but I think that's too low-level for what we really need. Cyclomatic Complexity allows us to evaluate one function implementation versus another, when what we really want is the ability to evaluate different architectures and designs.
- Verdex 5y ago
  Yes, we do have Cyclomatic Complexity and it seems like that's it. Unfortunately, Cyclomatic Complexity is of dubious value. Even the wiki link you have here contains a section where they question the correlation between CC and the number of defects. Some studies say yes, but it looks like total program length is also correlated and sometimes better. Or in other words, line count might be a better metric than CC, which isn't exactly a ringing endorsement. Additionally, even if CC turns out to be useful, it is rather targeted. Basically, it's a metric to make sure you don't have too many if-statements[1]. Not as effective in our current OO/FP world where lots of decisions can be shunted off to an unknown object or lambda. However, whether or not you want to claim CC is useful for non-if-statement branches, it definitely doesn't say anything about code that's bad because of bad variable names, or code that's bad because of deep inheritance, or code that's bad because the wrong abstraction is used, etc (which is kind of what you're already saying with your statement about architectures and designs). [1] - So, I guess you could probably create a CC setup that is able to count linear independent paths that aren't if-statement related. However, both OO and FP allow you to setup scenarios where the execution path indirection is decided at run time (pass in a different object implementation or a different lambda). So you crash head first into the halting problem pretty quickly. [Not to mention, I've never seen anyone try to do this ... although I haven't actually been checking very carefully, so maybe there are tools that try to do this in a limited fashion?] However, it's also debatable which linearly independent paths are bad and which ones are actually helpful. Like, I bet that TCP library call contains a ton of linear independent paths. But if you fix that by just vomiting your hand rolled communication protocol onto the internet with objectively less linear independent paths, then I can't call that an improvement in program comprehensibility just because the linear independent paths have been reduced.

29athrowaway 5y ago

The reason startups get large amounts of funding is because they are expected to grow exponentially. Tech debt mills cannot grow exponentially. They grow quickly for a couple of years, then stop growing once the accrued tech debt slows down growth. Once the 10xers/rockstar/ninjas that "got shit done" for years are asked to make things work for that missing "5% of the time", they will look for another job and disappear. Tech debt mills should not be treated as startups. They are small or medium businesses that are not prepared for exponential growth, and as such, do not deserve startup-level funding. The obsession over "getting shit done" and "shipping" are traits of tech debt mills. Sustainable growth and a long-term vision beats tech debt mill mentality.

gumby 5y ago

A positive use case that still matches your criteria: Used to work with a really nice guy (everyone loved him). Wrote code really fast. It worked. It was scary code though. When a customer had a crisis we’d send him in. He’d find the 10 holes in the dike and stick his fingers in. As soon as he went to work on something else the water would come rushing back in. But that was ok. He’d stabilize things while somebody wrote a saner patch. What he did was usually a clue about the underlying problem. Actually this wasn’t his only mode. You probably are running some of his decades old code right now. I could use someone like him again.