22 ms·

> “Product-first” engineers are obsessed with using code to solve a user problem and they see code as just a means to an end. > “Code-first” engineers are obse

by mLuby 5y ago

> “Product-first” engineers are obsessed with using code to solve a user problem and they see code as just a means to an end. > “Code-first” engineers are obsessed with the abstractions, architecture, tools and libraries in the code. Elegant code is the end. Then aren't basically all professional software engineers "product-first" engineers? Consumers or clients are the users to "product" engineers, who in turn are the users to "infrastructure" engineers. If the infrastructure engineers spend their time building elegant abstractions, tools, and libraries that don't solve the product engineers' problems, the product engineers will get their infrastructure needs met elsewhere (i.e. off the shelve, roll their own, or outsource) and the infrastructure engineers won't be necessary. (I'm not arguing against infrastructure engineers per se, just that their primary goal isn't elegant code.)

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.
weeblewobble 5y ago
That part caught me too. I'm not obsessed with either one. People pay me to make computers do what they want them to do.
mmmpop 5y ago
Can we start by not calling people lacking engineering degrees "engineers"? Nothing wrong with being a "developer" but everything wrong with being a CSS jockey who gives them self an extremely inflated title. Exceptions can be made for CS degree holders in my opinion. I don't hold an engineering degree myself, so I am just "programmer". I still make more than most engineers, so why the fuss?
- cassonmars 5y ago
  Because computer science is not an engineering degree, and (at least in the states) professional engineers are required at a minimum to hold a four year degree in an accredited engineering program, work under a certified engineer for a period of time, take an exam, etc. While this is for literal physical engineering, there is not an appropriate parallel for software engineering. There are people who hold doctorates in computer science that cannot build functioning software. And it’s not expected that they can — CS is not an engineering degree. If mathematicians were commonly employed like software engineers, they may find themselves adopting a Mathematic Engineer, but that doesn’t mean it bears any relationship to an engineering degree, let alone any degree.
  - shynrou 5y ago
    In addition to that, the title is more descriptive of what other employees should expect from you. A programmer is a typist, tasks in results out, no creativity or problem solving expected. Developer creates something new so a little more creative. Engineers engineer stuff they plan and make things work. Architect strictly plans. I don't say thats what they do but a lot closer to what people expect.
  - wheelinsupial 5y ago
    > While this is for literal physical engineering, there is not an appropriate parallel for software engineering. What you have described of an engineer applies to software engineers in Canada. There exist accredited software engineering degrees, some of which may be held under a computer science major with a further specialization in software engineering. There used to be a PE in software engineering in the US. So a parallel for software does exist. Given that there is precedence for licensing and there exist programs attempting to focus on educating those who need to build systems, why is there such an aversion to hiring those graduates and following those processes? Do they produce worse software? Is there no need because of agile and move fast and ship things?
atirip 5y ago
I would not say obsessed. Instead I divide engineers to implementors (people who are masters of using frameworks/libraries to implement features, but are not capable of writing one) and developers (people who can write a framework/library if that is the ticket). But yes, there are lots of implementors around and very few developers. We currently try to hire a developer and that is not easy.
lhorie 5y ago
No, I don't think so. You don't need to be strictly in an infra-oriented position to do infra oriented work. The most common example is the proverbial senior developer setting stack standards for their more junior team (despite being in a role that is largely oriented towards shipping actual products). Conversely, one could be a product-first infra person, who ships widely useful tools but whose code may be of questionable quality (e.g. someone might duck tape together some mission critical CI pipeline w/ python and bash and no tests)
nickm12 5y ago
I see where you're going with this, but I think about it a little bit differently. Product-orientation and infrastruture-orientation are two different skill sets and professional software developers should have some development on both axes. I have worked with developers all over the map on these axes and I think the fatal combination is someone who spikes on one axes but ignorance or even active disregard for the other. The failure modes look very different though. The "product-only" engineer quickly whips up something that satisfies their user's need, but over time the code becomes sphagetti that is buggy and painful to modify and the users are unhappy. The "infrastruture-only" engineer makes a puristic system that seems impressive from a technical point of view, but interfaces poorly with the customer's problems. Customers either have to go through contortions to make their problem fit into the architecture of the system or they just move on and find something that is better suited to them.
- kqr 5y ago
  So, in your terminology, a software engineer who is bad at programming is a "product-only", whereas a software engineer who is bad at business is "infrastructure-only"? If so, why invent new terminology when we have the perfectly fine description "software engineer who is bad at business"? Isn't it bound to confuse more than it helps?
  - ozim 5y ago
    Why do we even go into negative descriptions? Why don't we go thinking about people strengths and think how we create a team that is composed of people with different strengths? Manager will have to make sure he makes it clear in the team that: Joe might not be whipping perfect code but he is good at figuring out users vague requests and putting those into action. Jane might be obsessed with her language of choice and does not like vague requirements, she likes something like we are having 20 requests per second make system to handle 50. You don't want to describe people as "bad in something" because that is not productive. For a manager that should be obvious. But even if someone is working in a team, describing colleagues/projects/workplace in negative ways is bad and not productive. While yes there are instances where it is bad and people should call bad things out, but most of what I see are mere annoyances that one can gloss over.

by mLuby 5y ago

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.

weeblewobble 5y ago

That part caught me too. I'm not obsessed with either one. People pay me to make computers do what they want them to do.

mmmpop 5y ago

Can we start by not calling people lacking engineering degrees "engineers"? Nothing wrong with being a "developer" but everything wrong with being a CSS jockey who gives them self an extremely inflated title. Exceptions can be made for CS degree holders in my opinion. I don't hold an engineering degree myself, so I am just "programmer". I still make more than most engineers, so why the fuss?

cassonmars 5y ago
Because computer science is not an engineering degree, and (at least in the states) professional engineers are required at a minimum to hold a four year degree in an accredited engineering program, work under a certified engineer for a period of time, take an exam, etc. While this is for literal physical engineering, there is not an appropriate parallel for software engineering. There are people who hold doctorates in computer science that cannot build functioning software. And it’s not expected that they can — CS is not an engineering degree. If mathematicians were commonly employed like software engineers, they may find themselves adopting a Mathematic Engineer, but that doesn’t mean it bears any relationship to an engineering degree, let alone any degree.
- shynrou 5y ago
  In addition to that, the title is more descriptive of what other employees should expect from you. A programmer is a typist, tasks in results out, no creativity or problem solving expected. Developer creates something new so a little more creative. Engineers engineer stuff they plan and make things work. Architect strictly plans. I don't say thats what they do but a lot closer to what people expect.
- wheelinsupial 5y ago
  > While this is for literal physical engineering, there is not an appropriate parallel for software engineering. What you have described of an engineer applies to software engineers in Canada. There exist accredited software engineering degrees, some of which may be held under a computer science major with a further specialization in software engineering. There used to be a PE in software engineering in the US. So a parallel for software does exist. Given that there is precedence for licensing and there exist programs attempting to focus on educating those who need to build systems, why is there such an aversion to hiring those graduates and following those processes? Do they produce worse software? Is there no need because of agile and move fast and ship things?

atirip 5y ago

I would not say obsessed. Instead I divide engineers to implementors (people who are masters of using frameworks/libraries to implement features, but are not capable of writing one) and developers (people who can write a framework/library if that is the ticket). But yes, there are lots of implementors around and very few developers. We currently try to hire a developer and that is not easy.

lhorie 5y ago

No, I don't think so. You don't need to be strictly in an infra-oriented position to do infra oriented work. The most common example is the proverbial senior developer setting stack standards for their more junior team (despite being in a role that is largely oriented towards shipping actual products). Conversely, one could be a product-first infra person, who ships widely useful tools but whose code may be of questionable quality (e.g. someone might duck tape together some mission critical CI pipeline w/ python and bash and no tests)

nickm12 5y ago

I see where you're going with this, but I think about it a little bit differently. Product-orientation and infrastruture-orientation are two different skill sets and professional software developers should have some development on both axes. I have worked with developers all over the map on these axes and I think the fatal combination is someone who spikes on one axes but ignorance or even active disregard for the other. The failure modes look very different though. The "product-only" engineer quickly whips up something that satisfies their user's need, but over time the code becomes sphagetti that is buggy and painful to modify and the users are unhappy. The "infrastruture-only" engineer makes a puristic system that seems impressive from a technical point of view, but interfaces poorly with the customer's problems. Customers either have to go through contortions to make their problem fit into the architecture of the system or they just move on and find something that is better suited to them.

kqr 5y ago
So, in your terminology, a software engineer who is bad at programming is a "product-only", whereas a software engineer who is bad at business is "infrastructure-only"? If so, why invent new terminology when we have the perfectly fine description "software engineer who is bad at business"? Isn't it bound to confuse more than it helps?
- ozim 5y ago
  Why do we even go into negative descriptions? Why don't we go thinking about people strengths and think how we create a team that is composed of people with different strengths? Manager will have to make sure he makes it clear in the team that: Joe might not be whipping perfect code but he is good at figuring out users vague requests and putting those into action. Jane might be obsessed with her language of choice and does not like vague requirements, she likes something like we are having 20 requests per second make system to handle 50. You don't want to describe people as "bad in something" because that is not productive. For a manager that should be obvious. But even if someone is working in a team, describing colleagues/projects/workplace in negative ways is bad and not productive. While yes there are instances where it is bad and people should call bad things out, but most of what I see are mere annoyances that one can gloss over.