3 ms·

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 se

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.
  - kqr 5y ago
    For the same reason I talk about security weaknesses, and not security strengths: pointing out a weakness is the first step to fixing them. Even if you have no interest in fixing a weakness, it is absolutely essential that you're aware of it, and can engage in compensating behaviour.
    - ozim 5y ago
      What I see in "software engineer who is bad at business" is that is broad and not useful. We can discuss specific flaws with specific person and think about course of action to fix it. Telling someone "you suck" is not first step to fixing anything. Just like laughing someones system has so many holes as Swiss cheese. You want to be specific like you have an XSS here and here, those are steps to fix it.
  - nickm12 5y ago
    Agreed. I don't think everyone can be great at everything. There are some basic levels of competencies that are required though and, most importantly, people need to be able to respect the strengths of others that don't align with their own. My own examples were driven by working with developers who were actively disdainful for people and ideas that were not on their single axis of focus, which was bad for the team and for the product.
jwalton 5y ago
The first example isn’t a software engineer. The code is a spaghetti mess because the system wasn’t engineered - there are no design documents, because the system wasn’t designed it was just hacked together. There’s no memos describing why certain decisions were made. The second is, ironically, usually the same, but instead of a lack of design there’s a lack of requirements, which is even worse.

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.
- kqr 5y ago
  For the same reason I talk about security weaknesses, and not security strengths: pointing out a weakness is the first step to fixing them. Even if you have no interest in fixing a weakness, it is absolutely essential that you're aware of it, and can engage in compensating behaviour.
  - ozim 5y ago
    What I see in "software engineer who is bad at business" is that is broad and not useful. We can discuss specific flaws with specific person and think about course of action to fix it. Telling someone "you suck" is not first step to fixing anything. Just like laughing someones system has so many holes as Swiss cheese. You want to be specific like you have an XSS here and here, those are steps to fix it.
- nickm12 5y ago
  Agreed. I don't think everyone can be great at everything. There are some basic levels of competencies that are required though and, most importantly, people need to be able to respect the strengths of others that don't align with their own. My own examples were driven by working with developers who were actively disdainful for people and ideas that were not on their single axis of focus, which was bad for the team and for the product.

jwalton 5y ago

The first example isn’t a software engineer. The code is a spaghetti mess because the system wasn’t engineered - there are no design documents, because the system wasn’t designed it was just hacked together. There’s no memos describing why certain decisions were made. The second is, ironically, usually the same, but instead of a lack of design there’s a lack of requirements, which is even worse.