6 ms·

I think it has a lot to do with motivation. Some people are more motivated to solve the business problem. They may accrue more technical debt in exchange for i

by reidjs 5y ago

I think it has a lot to do with motivation. Some people are more motivated to solve the business problem. They may accrue more technical debt in exchange for important features and increasing revenue. Some people are more motivated by clean, well documented, DRY code. They are probably going to fight to refactor parts of the codebase to prevent losing revenue. Most people are probably somewhere in between.

mLuby 5y ago
That's an improvement on the article's classification. I'd say it's "make the change now; clean up later" engineers vs "clean up now so the change is easy later" engineers. Too much of the former and productivity grinds to a halt under all the tech debt. Too much of the latter and there'll be zero new features shipped. A balance (ideally within each engineer) is ideal.
- geoduck14 5y ago
  This pretty much sums up the challenges I've been facing the past week
strken 5y ago
This seems kind of like saying "some people are motivated by sleeping, while others are motivated by eating" - every software engineer in the industry is going to do both. There's one type of software engineer, and it's someone who juggles multiple competing constraints. You meet product needs quickly using a coherent and well-designed platform; you build a platform in response to real customer needs. It's a silly dichotomy, because there's always a point when product-focused engineers need a platform, and when platform-focused engineers look for customer impact.
- fiddlerwoaroof 5y ago
  This is what a product-focused engineer would say :) There’s definitely a difference between the people who are more interested in the results of programming vs. the people who are really interested in the craft of programming as a process. They both end up having to think about product questions, but they tend to find their way into different parts of the company: the product-focused engineers are always working on splashy new features while the craft-focused are generally behind the scenes trying to figure out a way to make the DX of the codebase better (and sometimes even being called “architecture astronauts” as a result).
  - strken 5y ago
    I'm usually the most platform-oriented or infrastructure-oriented engineer on my team. I consistently push for refactoring, test coverage, observability, automation, design sessions, and good documentation. This week I've been adding load shedding and backoff to things, rewriting some old tests that were disabled for being flaky, and rewrote a gigantic fanout query to use a task pool. That you think I sound like a product engineer when I've been wearing the "I wish we had a real SRE" hat all week is illustrative of the original point: they're not categories that engineers conform to.
jedberg 5y ago
And you really need everyone in your group to be the same type or you will have a lot of butting heads. I was once contracting on a project where I was building code to solve urgent business problems. By necessity of the timeline, the code was ok but not perfect. Then they brought on a new manager, who immediately ran all my code through a linter and told me to stop all work until the linter came up clean. I told him that I was hired to make working code that solves an immediate problem, and he told me my services were no longer required. I found out later the project was quickly moved to another team because his team was unable to meet the tight timelines.
- userbinator 5y ago
  That's the difference between process-oriented and result-oriented thinking. I've also heard the two extremes being referred to as "tool-worshipping fools" and "rule-breaking fools".
  - vkou 5y ago
    Organizations tend reward process-oriented thinking regardless of whether it succeeds or not, and results-oriented thinking only if it succeeds.
    - geoduck14 5y ago
      >Organizations tend reward process-oriented thinking regardless of whether it succeeds or not I'm not sure if my experience aligns with this
  - kqr 5y ago
    This seems incorrect. The archetypal process-oriented professional in my book is the money-making poker player. In poker, you cannot control the result of any hand -- not even the result of a week's play. To achieve long-term success, you must have a good process for your playing, and not be influenced by the results. A good process sets you up for the best chance of success, but it cannot guarantee success. If you start to adjust based on results (and not deeper changes to the causal matrix -- these are process-informed changes) you'll do worse. Edwards Deming called this "tampering". The same thing applies, of course, in business. The greatest process will produce bad results if you're unlucky with uncontrollable external factors. A bad process can by chance produce good results if you're lucky with uncontrollable external factors. You cannot judge a process by its results in individual instances alone. Judgment of a process must be made in terms of theory, repeated experiment, and long-term tendencies of the outcomes. And, as in poker, any long-term successful business is process-oriented. They carefully build processes that set them up for greatest chance of repeated success. Any results-oriented business has -- by de-emphasising the process -- no way to influence the outcome. They are "driving on the highway by looking at the centre line in the rear view mirror" as someone put it. Theory and process is the only thing that can tell you anything about future results. I strongly recommend reading Deming's The New Economics.

by reidjs 5y ago

mLuby 5y ago

That's an improvement on the article's classification. I'd say it's "make the change now; clean up later" engineers vs "clean up now so the change is easy later" engineers. Too much of the former and productivity grinds to a halt under all the tech debt. Too much of the latter and there'll be zero new features shipped. A balance (ideally within each engineer) is ideal.

geoduck14 5y ago
This pretty much sums up the challenges I've been facing the past week

strken 5y ago

This seems kind of like saying "some people are motivated by sleeping, while others are motivated by eating" - every software engineer in the industry is going to do both. There's one type of software engineer, and it's someone who juggles multiple competing constraints. You meet product needs quickly using a coherent and well-designed platform; you build a platform in response to real customer needs. It's a silly dichotomy, because there's always a point when product-focused engineers need a platform, and when platform-focused engineers look for customer impact.

fiddlerwoaroof 5y ago
This is what a product-focused engineer would say :) There’s definitely a difference between the people who are more interested in the results of programming vs. the people who are really interested in the craft of programming as a process. They both end up having to think about product questions, but they tend to find their way into different parts of the company: the product-focused engineers are always working on splashy new features while the craft-focused are generally behind the scenes trying to figure out a way to make the DX of the codebase better (and sometimes even being called “architecture astronauts” as a result).
- strken 5y ago
  I'm usually the most platform-oriented or infrastructure-oriented engineer on my team. I consistently push for refactoring, test coverage, observability, automation, design sessions, and good documentation. This week I've been adding load shedding and backoff to things, rewriting some old tests that were disabled for being flaky, and rewrote a gigantic fanout query to use a task pool. That you think I sound like a product engineer when I've been wearing the "I wish we had a real SRE" hat all week is illustrative of the original point: they're not categories that engineers conform to.

jedberg 5y ago

And you really need everyone in your group to be the same type or you will have a lot of butting heads. I was once contracting on a project where I was building code to solve urgent business problems. By necessity of the timeline, the code was ok but not perfect. Then they brought on a new manager, who immediately ran all my code through a linter and told me to stop all work until the linter came up clean. I told him that I was hired to make working code that solves an immediate problem, and he told me my services were no longer required. I found out later the project was quickly moved to another team because his team was unable to meet the tight timelines.

userbinator 5y ago
That's the difference between process-oriented and result-oriented thinking. I've also heard the two extremes being referred to as "tool-worshipping fools" and "rule-breaking fools".
- vkou 5y ago
  Organizations tend reward process-oriented thinking regardless of whether it succeeds or not, and results-oriented thinking only if it succeeds.
  - geoduck14 5y ago
    >Organizations tend reward process-oriented thinking regardless of whether it succeeds or not I'm not sure if my experience aligns with this
- kqr 5y ago
  This seems incorrect. The archetypal process-oriented professional in my book is the money-making poker player. In poker, you cannot control the result of any hand -- not even the result of a week's play. To achieve long-term success, you must have a good process for your playing, and not be influenced by the results. A good process sets you up for the best chance of success, but it cannot guarantee success. If you start to adjust based on results (and not deeper changes to the causal matrix -- these are process-informed changes) you'll do worse. Edwards Deming called this "tampering". The same thing applies, of course, in business. The greatest process will produce bad results if you're unlucky with uncontrollable external factors. A bad process can by chance produce good results if you're lucky with uncontrollable external factors. You cannot judge a process by its results in individual instances alone. Judgment of a process must be made in terms of theory, repeated experiment, and long-term tendencies of the outcomes. And, as in poker, any long-term successful business is process-oriented. They carefully build processes that set them up for greatest chance of repeated success. Any results-oriented business has -- by de-emphasising the process -- no way to influence the outcome. They are "driving on the highway by looking at the centre line in the rear view mirror" as someone put it. Theory and process is the only thing that can tell you anything about future results. I strongly recommend reading Deming's The New Economics.