4 ms·

Sorry next developer, I'm on a tight deadline, used to love this craft, now I just do what the product people tell me to get a nice paycheck.

Arisaka1 3y ago
Yep. Yesterday I ran into a job opening asking for "Java developer who delivers 3x faster than the other developers" in one of the bullet points. It's such a weird point to emphasize that you want speed with no concern to trade-offs, and the maintainability and scalability of the codebase will be the first victims sooner or later.
- rpastuszak 3y ago
  Sounds like they're looking for a person who'll work 3x faster than the rest of the team by taking shortcuts and slowing everyone else down.
- BugsJustFindMe 3y ago
  My personal experience is that the majority of developers I ever encounter at work (as opposed to within my social network) are usually slow because they're bad engineers who don't understand problems quickly, don't have the knowledge or experience to see solutions quickly, and in general don't think deeply quickly. It's not hard to 3x performance without sacrifices when the baseline is mediocre at best. "Fast must be cutting corners and not just actually better at programming" is a weird fallacy to hang your hat on.
  - 3-cheese-sundae 3y ago
    There is always a cost to everything.
    - BugsJustFindMe 3y ago
      > There is always a cost to everything. There's a huge cost to having engineers who are bad at understanding and solving problems. The cost of having people who are good at understanding and solving problems is supposed to be that you pay them more, but that's not how employment incentive structures work in practice because information asymmetry and stigma around talking about salaries.
  - webdood90 3y ago
    > the majority of developers I ever encounter at work are usually slow because they're bad engineers hm, something about this that I just can't put my thumb on
    - screye 3y ago
      "Majority of people who drown cannot swim."
    - xupybd 3y ago
      It's a bit elitist[1]. They're saying we should expect 3x better performance from engineers. We should also expect them to write good code at this pace. The only reason we don't have these things is that most engineers are simply bad engineers. Only people the author perceives as good enough should ever be used as a metric of normal productivity. Presumably the author puts themselves in this group of good engineers. 1. https://en.wikipedia.org/wiki/Elitism
  - another-dave 3y ago
    While this is true, if a job ad is telling me that that's _their_ experience of their average hire, it's probably not somewhere I want to work!
    - BugsJustFindMe 3y ago
      I agree (unless they also pay you three times as much, in which case fair enough).
  - kaba0 3y ago
    Especially in CRUD settings when if people would just bother to learn at least a bit about the framework, they could outsource most of the code to that. It’s not like that filtering you have to implement is some brand new discovery that has never been done before.. these apps are literally fancy excel tables very often.
  - otikik 3y ago
    I used to work with this kind of developer. He was bounds and leaps faster than all the other developers in the team. The code he produced was absolutely and completely unmaintainable. The joke was that this guy could program C in any language. His code kindof-sort-of worked, but only he understood it and when anyone else had to take over his stuff, the first thing they had to do was rewriting the part from scratch. Of course there were no tests, so when the new person broke something in their attempt to try to work with their code they were scolded. The person in question was the CTO of the company, by the way. He was 3x alright, but at the expense of everyone else on the team. I was very glad to see him go.
- mikepurvis 3y ago
  "You'll get to work on a codebase for whom the entire development mindset has been 3x-speed-at-all-costs." Yeah..... pass.
- mostlylurks 3y ago
  There are cases where the tradeoffs don't involve the actual codebase. For instance, there are certainly many developers who are 3x faster than the average developer simply as the result of having enough experience and/or skill to know which tools and/or approaches are optimal for a large subset of the kinds of problems they encounter in their typical work, such as a developer familiar with a particular ecosystem accomplishing some task in 10 minutes by knowing which library and which function to use, and how, whereas another might take hours (or days) to accomplish the same task since they have to figure out what tools are even available to solve an issue and how to use them, or worse (sometimes), rolling their own solution where a library implementing the functionality already exists. The tradeoff here is simply that it will be harder to find such developers, and they'll generally want higher compensation, but their work will not degrade the quality of the codebase, quite the opposite.
- otikik 3y ago
  I like those offers, they self-identify as places to avoid
m00x 3y ago
The craft is not the code, but the product. You can have beautiful code and garbage product, and great code and a garbage product. If your PM is pushing bad products, that's on them. Your job is to deliver good product, not good code.
- majikandy 3y ago
  Can’t it be both?
  - m00x 3y ago
    It absolutely can! I'm not saying that you should disregard your code, just that it's not what you should put at the top of your list. You can build amazing products with amazing code, and they will often raise each other up. A great example is Redis, that codebase taught me how to write C code, and I also use Redis everywhere.
- dlisboa 3y ago
  That’s not a great way to look at it. You can be passionate about the craft and not passionate about the product. You can usually find interesting problems relating to craftsmanship even when doing things you’re not thrilled to do. Let’s be honest: sometimes you’re not “changing the world” like many founders like to think, just building yet another shopping cart. If you lose love for your craft there’s no product that’ll cure it.
  - 000ooo000 3y ago
    Well said. I am certainly not in this game because I love building forms. Mastering my tools of choice grants me satisfaction. It's hard to find a place working on a product that is truly interesting, but fortunately at least, finding a place working with tools I like is easier.
  - m00x 3y ago
    But you're trying to build a damn good shopping cart, which is the product. The code analogy here would be nerding out on how to use a hammer in spectacular ways, but not really do anything interesting with it. You can still really love your tools, but you shouldn't focus on them as much as what you're building with them.
nouveaux 3y ago
Sorry future me, I'm on a tight deadline. If I spent an extra two hours making this better now, you wouldn't have to spend two days fixing these problems. You're probably still on a tight deadline.
- stodor89 3y ago
  "I love deadlines. I love the whooshing noise they make as they go by." -- Douglas Adams

Arisaka1 3y ago

Yep. Yesterday I ran into a job opening asking for "Java developer who delivers 3x faster than the other developers" in one of the bullet points. It's such a weird point to emphasize that you want speed with no concern to trade-offs, and the maintainability and scalability of the codebase will be the first victims sooner or later.

rpastuszak 3y ago
Sounds like they're looking for a person who'll work 3x faster than the rest of the team by taking shortcuts and slowing everyone else down.
BugsJustFindMe 3y ago
My personal experience is that the majority of developers I ever encounter at work (as opposed to within my social network) are usually slow because they're bad engineers who don't understand problems quickly, don't have the knowledge or experience to see solutions quickly, and in general don't think deeply quickly. It's not hard to 3x performance without sacrifices when the baseline is mediocre at best. "Fast must be cutting corners and not just actually better at programming" is a weird fallacy to hang your hat on.
- 3-cheese-sundae 3y ago
  There is always a cost to everything.
  - BugsJustFindMe 3y ago
    > There is always a cost to everything. There's a huge cost to having engineers who are bad at understanding and solving problems. The cost of having people who are good at understanding and solving problems is supposed to be that you pay them more, but that's not how employment incentive structures work in practice because information asymmetry and stigma around talking about salaries.
- webdood90 3y ago
  > the majority of developers I ever encounter at work are usually slow because they're bad engineers hm, something about this that I just can't put my thumb on
  - screye 3y ago
    "Majority of people who drown cannot swim."
  - xupybd 3y ago
    It's a bit elitist[1]. They're saying we should expect 3x better performance from engineers. We should also expect them to write good code at this pace. The only reason we don't have these things is that most engineers are simply bad engineers. Only people the author perceives as good enough should ever be used as a metric of normal productivity. Presumably the author puts themselves in this group of good engineers. 1. https://en.wikipedia.org/wiki/Elitism
- another-dave 3y ago
  While this is true, if a job ad is telling me that that's _their_ experience of their average hire, it's probably not somewhere I want to work!
  - BugsJustFindMe 3y ago
    I agree (unless they also pay you three times as much, in which case fair enough).
- kaba0 3y ago
  Especially in CRUD settings when if people would just bother to learn at least a bit about the framework, they could outsource most of the code to that. It’s not like that filtering you have to implement is some brand new discovery that has never been done before.. these apps are literally fancy excel tables very often.
- otikik 3y ago
  I used to work with this kind of developer. He was bounds and leaps faster than all the other developers in the team. The code he produced was absolutely and completely unmaintainable. The joke was that this guy could program C in any language. His code kindof-sort-of worked, but only he understood it and when anyone else had to take over his stuff, the first thing they had to do was rewriting the part from scratch. Of course there were no tests, so when the new person broke something in their attempt to try to work with their code they were scolded. The person in question was the CTO of the company, by the way. He was 3x alright, but at the expense of everyone else on the team. I was very glad to see him go.
mikepurvis 3y ago
"You'll get to work on a codebase for whom the entire development mindset has been 3x-speed-at-all-costs." Yeah..... pass.
mostlylurks 3y ago
There are cases where the tradeoffs don't involve the actual codebase. For instance, there are certainly many developers who are 3x faster than the average developer simply as the result of having enough experience and/or skill to know which tools and/or approaches are optimal for a large subset of the kinds of problems they encounter in their typical work, such as a developer familiar with a particular ecosystem accomplishing some task in 10 minutes by knowing which library and which function to use, and how, whereas another might take hours (or days) to accomplish the same task since they have to figure out what tools are even available to solve an issue and how to use them, or worse (sometimes), rolling their own solution where a library implementing the functionality already exists. The tradeoff here is simply that it will be harder to find such developers, and they'll generally want higher compensation, but their work will not degrade the quality of the codebase, quite the opposite.
otikik 3y ago
I like those offers, they self-identify as places to avoid

m00x 3y ago

The craft is not the code, but the product. You can have beautiful code and garbage product, and great code and a garbage product. If your PM is pushing bad products, that's on them. Your job is to deliver good product, not good code.

majikandy 3y ago
Can’t it be both?
- m00x 3y ago
  It absolutely can! I'm not saying that you should disregard your code, just that it's not what you should put at the top of your list. You can build amazing products with amazing code, and they will often raise each other up. A great example is Redis, that codebase taught me how to write C code, and I also use Redis everywhere.
dlisboa 3y ago
That’s not a great way to look at it. You can be passionate about the craft and not passionate about the product. You can usually find interesting problems relating to craftsmanship even when doing things you’re not thrilled to do. Let’s be honest: sometimes you’re not “changing the world” like many founders like to think, just building yet another shopping cart. If you lose love for your craft there’s no product that’ll cure it.
- 000ooo000 3y ago
  Well said. I am certainly not in this game because I love building forms. Mastering my tools of choice grants me satisfaction. It's hard to find a place working on a product that is truly interesting, but fortunately at least, finding a place working with tools I like is easier.
- m00x 3y ago
  But you're trying to build a damn good shopping cart, which is the product. The code analogy here would be nerding out on how to use a hammer in spectacular ways, but not really do anything interesting with it. You can still really love your tools, but you shouldn't focus on them as much as what you're building with them.

nouveaux 3y ago

Sorry future me, I'm on a tight deadline. If I spent an extra two hours making this better now, you wouldn't have to spend two days fixing these problems. You're probably still on a tight deadline.

stodor89 3y ago
"I love deadlines. I love the whooshing noise they make as they go by." -- Douglas Adams