3 ms·

You nailed it in the first sentence - businesses don't need developers, they really need problem solvers - but we often don't get a seat at that table to turn a

by dwd 6y ago

You nailed it in the first sentence - businesses don't need developers, they really need problem solvers - but we often don't get a seat at that table to turn around a problem before it lands on our desk as a request to code some poorly understood idea someone had. 1) Identify the problem - it invariably isn't to do with code but a combination of time and cost. 2) Can the problem be solved without a line of code, such as changing the process and removing the issue that way? 3) Is there an off-the-shelf application, software or component that will solve the problem. 4) Maybe you do need to code something. We are also all too quick to just dive straight in at (4) because that's what we identify as, that's what we enjoy and unfortunately what we get paid to do rather than getting paid to think, advise and value-add.

ptero 6y ago
Some ideas that look poorly thought out are in fact pretty good, just different from what we would do ourselves. In my experience it is a key skill to objectively evaluate ideas that are different from my preferences and accept those that are good enough, but not use my preferred way of doing things. This is a quick path to get a seat at the table and getting your opinions heard. My 2c.
- Angostura 6y ago
  A perspective worth considerably more than 2c. Made me think.
- dwd 6y ago
  I agree with your sentiment and yes, a workable solution is always the best solution. Idea was probably the wrong word, it's the highly vested, fully formed solutions that I've had issues with. Also, in saying that, I do believe domain knowledge is far more valuable that programming chops, and not understanding the domain to be able to translate that into an application process is worse that someone with domain knowledge trying to come up with how it should be coded. Some of the best projects I've worked on involved a lot of sitting and drinking coffee with the domain expert.
  - Aeolun 6y ago
    I think the problem is that getting the information from the domain expert and then running and programming with it is doable, but the domain expert cannot ask you for advice on programming and then build an application (at least not in the same timeframe).
- mgkimsal 6y ago
  > Some ideas that look poorly thought out are in fact pretty good The only times I've ever found that to be true is when there's other details available that I'm not aware of. Business constraints "everyone knows" about but aren't documented anywhere, for example. Decisions made in a meeting that aren't communicated out, meaning, essentially, that you only are given a portion of the problem and request. This gets back to the 'seat at the table' concern above. The 'seat at the table' is far more related to interpersonal/political skills than technical ones, but can be chicken/egg in some places.
  - ptero 6y ago
    My opinion is certainly skewed by my personal experience, so take it with a grain of salt. That said, engineers are a highly opinionated bunch and a group of 5 will have 5 different personal preferences. But they are smart and will quickly recognize an objective opinion that is not hard-driven by personal preferences. Folks with good technical judgement who are willing to accept a different approach quickly become a highly respected member of the community. They frequently end up with more tables offering them seats, in a technical expert role, than they care to occupy.
    - dwd 6y ago
      This is one of those places where strong opinions, loosely held should be applied. And I can imagine those people getting more invites simply on the basis of possibly being more agreeable to interact with. Programming is an abstraction (a perspective on what the computer is really doing) that is very much shaped by the tools we choose to use. Meta-religion is probably a fair way to describe it, and can be every bit as divisive in some circles.
Aeolun 6y ago
> we often don't get a seat at that table to turn around a problem before it lands on our desk This. We don’t get to change the problem after the fact either.
gen220 6y ago
Has anyone ever seen a medium-to-large-sized company, in any industry/vertical, that's solved the "[Engineers] often don't get a seat at that table" problem? Anecdotally, because I've brought up this issue a lot, I've heard many responses from bother sides. From some engineers, not in the room: "I would never want to be in the room, because then I'd have to work with those people". From other engineers: "They'd never want us there, we're just resources to be used." From the non-engineers who are in the room: "we didn't know you wanted to be there, of course you're welcome", or "we didn't want to interrupt your work for such a high-level meeting". I find that the reason for exclusion is either incompetence (in which case, get out), or a lack of awareness that certain engineers are exceptional sources of opinion, in those rooms. But I've never seen a culture that's pushed engineers into those strategy meetings; it's always been opt-in rather than opt-out. (It's always opt-out for the product org).
- ozim 6y ago
  In my experience I don't often hear: "They'd never want us there, we're just resources to be used." But: "Damn those stupid meetings again, wasting my time." It is like a lot of developers don't consider meetings part of job. I am currently less and less into actual typing of code and much more into understanding what others are trying to accomplish.
  - gen220 6y ago
    As engineers, we are spoiled in that we are accustomed to (1) navigating high signal:noise ratio environments (2) systematically improving the signal:noise ratio in environments where it’s poor. On (1), many corporate meeting rooms have terrible ratios, and so they intuitively feel unproductive. On (2), it’s much easier to improve the ratio in code than it is in words spoken by people. It requires a lot of patience, but in the long game, engineers do improve that ratio in meetings and strategy discussions, and the company benefits from it. My theory is that most engineers are not interested in playing the long game, because (1) it’s not as fun (2) they don’t plan on being at the company on time scales where the investment will have been worth it. While I personally don’t emulate their behavior, I think the developers you describe could conceivably be acting perfectly rational for their career goals.
raj_khare 6y ago
Yeah, the advice that you should spend more time on understanding the question rather than figuring out various solutions is right

by dwd 6y ago

ptero 6y ago

Some ideas that look poorly thought out are in fact pretty good, just different from what we would do ourselves. In my experience it is a key skill to objectively evaluate ideas that are different from my preferences and accept those that are good enough, but not use my preferred way of doing things. This is a quick path to get a seat at the table and getting your opinions heard. My 2c.

Angostura 6y ago
A perspective worth considerably more than 2c. Made me think.
dwd 6y ago
I agree with your sentiment and yes, a workable solution is always the best solution. Idea was probably the wrong word, it's the highly vested, fully formed solutions that I've had issues with. Also, in saying that, I do believe domain knowledge is far more valuable that programming chops, and not understanding the domain to be able to translate that into an application process is worse that someone with domain knowledge trying to come up with how it should be coded. Some of the best projects I've worked on involved a lot of sitting and drinking coffee with the domain expert.
- Aeolun 6y ago
  I think the problem is that getting the information from the domain expert and then running and programming with it is doable, but the domain expert cannot ask you for advice on programming and then build an application (at least not in the same timeframe).
mgkimsal 6y ago
> Some ideas that look poorly thought out are in fact pretty good The only times I've ever found that to be true is when there's other details available that I'm not aware of. Business constraints "everyone knows" about but aren't documented anywhere, for example. Decisions made in a meeting that aren't communicated out, meaning, essentially, that you only are given a portion of the problem and request. This gets back to the 'seat at the table' concern above. The 'seat at the table' is far more related to interpersonal/political skills than technical ones, but can be chicken/egg in some places.
- ptero 6y ago
  My opinion is certainly skewed by my personal experience, so take it with a grain of salt. That said, engineers are a highly opinionated bunch and a group of 5 will have 5 different personal preferences. But they are smart and will quickly recognize an objective opinion that is not hard-driven by personal preferences. Folks with good technical judgement who are willing to accept a different approach quickly become a highly respected member of the community. They frequently end up with more tables offering them seats, in a technical expert role, than they care to occupy.
  - dwd 6y ago
    This is one of those places where strong opinions, loosely held should be applied. And I can imagine those people getting more invites simply on the basis of possibly being more agreeable to interact with. Programming is an abstraction (a perspective on what the computer is really doing) that is very much shaped by the tools we choose to use. Meta-religion is probably a fair way to describe it, and can be every bit as divisive in some circles.

Aeolun 6y ago

> we often don't get a seat at that table to turn around a problem before it lands on our desk This. We don’t get to change the problem after the fact either.

gen220 6y ago

Has anyone ever seen a medium-to-large-sized company, in any industry/vertical, that's solved the "[Engineers] often don't get a seat at that table" problem? Anecdotally, because I've brought up this issue a lot, I've heard many responses from bother sides. From some engineers, not in the room: "I would never want to be in the room, because then I'd have to work with those people". From other engineers: "They'd never want us there, we're just resources to be used." From the non-engineers who are in the room: "we didn't know you wanted to be there, of course you're welcome", or "we didn't want to interrupt your work for such a high-level meeting". I find that the reason for exclusion is either incompetence (in which case, get out), or a lack of awareness that certain engineers are exceptional sources of opinion, in those rooms. But I've never seen a culture that's pushed engineers into those strategy meetings; it's always been opt-in rather than opt-out. (It's always opt-out for the product org).

ozim 6y ago
In my experience I don't often hear: "They'd never want us there, we're just resources to be used." But: "Damn those stupid meetings again, wasting my time." It is like a lot of developers don't consider meetings part of job. I am currently less and less into actual typing of code and much more into understanding what others are trying to accomplish.
- gen220 6y ago
  As engineers, we are spoiled in that we are accustomed to (1) navigating high signal:noise ratio environments (2) systematically improving the signal:noise ratio in environments where it’s poor. On (1), many corporate meeting rooms have terrible ratios, and so they intuitively feel unproductive. On (2), it’s much easier to improve the ratio in code than it is in words spoken by people. It requires a lot of patience, but in the long game, engineers do improve that ratio in meetings and strategy discussions, and the company benefits from it. My theory is that most engineers are not interested in playing the long game, because (1) it’s not as fun (2) they don’t plan on being at the company on time scales where the investment will have been worth it. While I personally don’t emulate their behavior, I think the developers you describe could conceivably be acting perfectly rational for their career goals.

raj_khare 6y ago

Yeah, the advice that you should spend more time on understanding the question rather than figuring out various solutions is right