6 ms·

In his "Make good art" speech [1] Neil Gaiman mentions a third axis in the good-bad/nice-jerk graph, namely, "delivers the work on time". I'm not sure how good

In his "Make good art" speech [1] Neil Gaiman mentions a third axis in the good-bad/nice-jerk graph, namely, "delivers the work on time". I'm not sure how good it would work for software development, but the comic book world has plenty of successful artists like that - their art is okay at best, but they have plenty of work because they reliably hit their deadlines. Assuming your worker is not entirely terrible, I always thought this made for a reasonable tie breaker. [1] https://jamesclear.com/great-speeches/make-good-art-by-neil-gaiman https://jamesclear.com/great-speeches/make-good-art-by-neil-...

CuriouslyC 4y ago
That works better in comic books than software. As an example, I have a coworker who is pretty good in terms of domain knowledge, and can push out work pretty fast, but he does things like write migrations that insert rows of data one at a time in a loop, or adds three layers of almost do-nothing wrapper functions around business logic that doesn't need to be abstracted. He's made a lot of useful contributions but the stuff he's been heavily involved in is borderline indecipherable so the tech debt tradeoff has been pretty brutal.
- mjr00 4y ago
  This reflects more poorly on your engineering leadership than your coworker imo. Where are the guardrails? Why aren't his migrations going through a pull request where you can review and say "this should be a batch insert?" If PRs are in place but nobody speaks up, why is the culture afraid of pointing these things out?
  - CuriouslyC 4y ago
    Oh, I totally agree, had I been the technical lead for that team I would have flagged a lot of that stuff. As it stands the lead for that team is also on the nice but incompetent spectrum to some degree, and since the code base they're working on is an inherited dumpster fire I get the sense people on that team have mostly given up on code quality.
  - morelisp 4y ago
    I can’t speak for the GP but I am currently in a position where we have the PR, we make the comments, the fix happens (kind of), but then it all repeats the next time. It’s tiring for the (technical) PO and the senior dev doing most of the reviews (me). It does not seem tiring for the employee. He seems like he could enjoy doing this forever, often commenting about how much he’s learning.
  - srcreigh 4y ago
    Yeah this kind of stuff is always best solved with general eng guidelines. I’ve been that guy many times. Having to do my PR 3 separate times over the course of a week because of feedback. IMO each solution worked fine, and the feedback was also fine. The trouble with explicit guidelines is it’ll make clear that your high-clout engineers are always breaking them. The reality is some peoples time matters more. And ideas aren’t always better, it’s about reducing the mental workload of one person at the expense of another person. There was a comment on previous thread about how they beautifully offered the autistic guy his own somewhat independent projects and he excelled. This is unthinkable in many places. It’s common to have the one high clout senior guy who wants to maintain clout but doesn’t have the mental resources to offer autonomy of the underlings. One can dream, though.
- stuckinhell 4y ago
  Manager here, I can tell you sometimes the things engineers care a lot about like algorithms and the fastest/correct ways to do things are not important. Domain knowledge is typically far more valuable. The real world of business has tons of weird legal/finanical/workflows edgecases. I'll always hire a mid engineer with strong business domain knowledge over a very technical engineer with no strong businss domain knowledge. My firm only has one team that's an exception to this rule.
  - CuriouslyC 4y ago
    As a staff engineer at an org that heavily prioritizes domain knowledge and promotes for it and agreeableness heavily, I think that view is only true in the most black and white of cases. We have lots of developers working at 25% productivity because the flaming dumpster fire of tech debt we inherited is slowly turning into a flaming landfill fire as we pile shit on top of shit rather than fix things. I'm not sure why management hasn't made the connection between repeatedly missing deadlines and rampant unchecked tech debt, I've pointed it out many times. At this point I'm just glad I'm not on a team that's severely impacted, but I feel bad for the people who are going to be forced to crunch and will still come out looking like poor employees.
    - stuckinhell 4y ago
      I sympathize as well, but I also know many many developers are extremely poor at judging what/how the code affects a given Firm's KPI's. I've been in literally hundreds of conversations with engineers who want to refactor a given technical system and don't realize the code debt is really due to the fact human businesses run on endless edge cases and weird exceptions. They only account for the majority use cases, but the problem is the firm would get sued without complete coverage. So when they deal with the edge cases, the code looks like shit again, and then what was the point of the company spending money on the refactor ? Application/Code Architecture in real world businesses is extremely tough given moving requirements, endless legal/financial edge cases, and subtly different but similar concepts across different business domains. It's gets even tougher when you have to make difficult decisions about cost centers and profit centers. My firm has a super specialty team (extremely well paid) that goes in and refactors/clean's up codebase's that are identified as becoming less efficient. However even the average senior engineer lacks the experience and understanding to clean up code debt in most business codebases.

CuriouslyC 4y ago

That works better in comic books than software. As an example, I have a coworker who is pretty good in terms of domain knowledge, and can push out work pretty fast, but he does things like write migrations that insert rows of data one at a time in a loop, or adds three layers of almost do-nothing wrapper functions around business logic that doesn't need to be abstracted. He's made a lot of useful contributions but the stuff he's been heavily involved in is borderline indecipherable so the tech debt tradeoff has been pretty brutal.

mjr00 4y ago
This reflects more poorly on your engineering leadership than your coworker imo. Where are the guardrails? Why aren't his migrations going through a pull request where you can review and say "this should be a batch insert?" If PRs are in place but nobody speaks up, why is the culture afraid of pointing these things out?
- CuriouslyC 4y ago
  Oh, I totally agree, had I been the technical lead for that team I would have flagged a lot of that stuff. As it stands the lead for that team is also on the nice but incompetent spectrum to some degree, and since the code base they're working on is an inherited dumpster fire I get the sense people on that team have mostly given up on code quality.
- morelisp 4y ago
  I can’t speak for the GP but I am currently in a position where we have the PR, we make the comments, the fix happens (kind of), but then it all repeats the next time. It’s tiring for the (technical) PO and the senior dev doing most of the reviews (me). It does not seem tiring for the employee. He seems like he could enjoy doing this forever, often commenting about how much he’s learning.
- srcreigh 4y ago
  Yeah this kind of stuff is always best solved with general eng guidelines. I’ve been that guy many times. Having to do my PR 3 separate times over the course of a week because of feedback. IMO each solution worked fine, and the feedback was also fine. The trouble with explicit guidelines is it’ll make clear that your high-clout engineers are always breaking them. The reality is some peoples time matters more. And ideas aren’t always better, it’s about reducing the mental workload of one person at the expense of another person. There was a comment on previous thread about how they beautifully offered the autistic guy his own somewhat independent projects and he excelled. This is unthinkable in many places. It’s common to have the one high clout senior guy who wants to maintain clout but doesn’t have the mental resources to offer autonomy of the underlings. One can dream, though.
stuckinhell 4y ago
Manager here, I can tell you sometimes the things engineers care a lot about like algorithms and the fastest/correct ways to do things are not important. Domain knowledge is typically far more valuable. The real world of business has tons of weird legal/finanical/workflows edgecases. I'll always hire a mid engineer with strong business domain knowledge over a very technical engineer with no strong businss domain knowledge. My firm only has one team that's an exception to this rule.
- CuriouslyC 4y ago
  As a staff engineer at an org that heavily prioritizes domain knowledge and promotes for it and agreeableness heavily, I think that view is only true in the most black and white of cases. We have lots of developers working at 25% productivity because the flaming dumpster fire of tech debt we inherited is slowly turning into a flaming landfill fire as we pile shit on top of shit rather than fix things. I'm not sure why management hasn't made the connection between repeatedly missing deadlines and rampant unchecked tech debt, I've pointed it out many times. At this point I'm just glad I'm not on a team that's severely impacted, but I feel bad for the people who are going to be forced to crunch and will still come out looking like poor employees.
  - stuckinhell 4y ago
    I sympathize as well, but I also know many many developers are extremely poor at judging what/how the code affects a given Firm's KPI's. I've been in literally hundreds of conversations with engineers who want to refactor a given technical system and don't realize the code debt is really due to the fact human businesses run on endless edge cases and weird exceptions. They only account for the majority use cases, but the problem is the firm would get sued without complete coverage. So when they deal with the edge cases, the code looks like shit again, and then what was the point of the company spending money on the refactor ? Application/Code Architecture in real world businesses is extremely tough given moving requirements, endless legal/financial edge cases, and subtly different but similar concepts across different business domains. It's gets even tougher when you have to make difficult decisions about cost centers and profit centers. My firm has a super specialty team (extremely well paid) that goes in and refactors/clean's up codebase's that are identified as becoming less efficient. However even the average senior engineer lacks the experience and understanding to clean up code debt in most business codebases.