3 ms·

I love that you found/acknowledged Type 3. Type 3 is a super easy trap to fall into, especially when you don't understand the problem space. I think the only w

I love that you found/acknowledged Type 3. Type 3 is a super easy trap to fall into, especially when you don't understand the problem space. I think the only way you can avoid that is by almost annoyingly probing to find the root of problem (because it is often some broken or stupid human process). Most of the time, it does not require more software to fix, and the problem is to do with process complexity. If you can simplify that, any software you write will be more minimal. So yes, the problem as always is with people IMO and having to educate/convince them to change their ways (or at least, open their eyes to a different solution). I guess this makes me a Type 2 as described by the article (although it naturally oversimplifies each archetype). What some people might not want to hear is that, yes, I think you unfortunately can only excel at problem solving as an engineer if you also are good at the "product" management part. I have a way more controversial opinion in industry that is a bit spicy... I think if you aren't coding the solution to the problem, you shouldn't be allowed to define the solution or get anywhere near it. In other words, even to my favorite PMs I've worked with - I think your job exists because many engineers are anti-social and don't want to talk to people. For the ones that do collaborate well, a PM is unneeded on the team and would be a detriment. It's not a personal knock - I just believe that to be the truth. The original agile manifesto got it right and we have collectively fucked it up.

dasil003 4y ago
I agree that software engineers need to understand the product and take more responsibility in its definition. I believe this has regressed compared to early professional programming norms as computers and especially smart phones have become staples in everyday life. I also think current ways of working have enabled bad product management. That said, good product management is still worth its weight in gold. Someone who is willing to put in the work in terms of analyzing user behavior, has good UX instincts and respect for engineering can add a lot of value and magnify the impact of the team. It’s rare, but definitely a force magnifier for the team.
gregmac 4y ago
> if you aren't coding the solution to the problem, you shouldn't be allowed to define the solution I think you're on the right track here, but from the wrong direction. You pretty much stated it earlier: > the only way you can avoid that is by almost annoyingly probing to find the root of problem I approach this as: if someone brings a solution, mostly ignore it and start asking "why?" until you're back at a root answer like "so my business can make money". I can't even count the number if times someone has proposed a solution where I've done this and not only ended up with something simpler and faster to build, but a better or more complete solution. This often comes in like "just build a button to export this data to csv", which if you probe is actually "..So I can get it into Excel easier" ... "So I can reformat it to bring to this other system". The result is something like "what if we push the data to their API, that we already have integrated with, once every hour?" Sometimes it's software, sometimes it's not, mostly it ends up being a mix -- but importantly if you don't ask "why" enough, you'll solve the wrong or at best only an intermediate problem.

dasil003 4y ago

I agree that software engineers need to understand the product and take more responsibility in its definition. I believe this has regressed compared to early professional programming norms as computers and especially smart phones have become staples in everyday life. I also think current ways of working have enabled bad product management. That said, good product management is still worth its weight in gold. Someone who is willing to put in the work in terms of analyzing user behavior, has good UX instincts and respect for engineering can add a lot of value and magnify the impact of the team. It’s rare, but definitely a force magnifier for the team.

gregmac 4y ago

> if you aren't coding the solution to the problem, you shouldn't be allowed to define the solution I think you're on the right track here, but from the wrong direction. You pretty much stated it earlier: > the only way you can avoid that is by almost annoyingly probing to find the root of problem I approach this as: if someone brings a solution, mostly ignore it and start asking "why?" until you're back at a root answer like "so my business can make money". I can't even count the number if times someone has proposed a solution where I've done this and not only ended up with something simpler and faster to build, but a better or more complete solution. This often comes in like "just build a button to export this data to csv", which if you probe is actually "..So I can get it into Excel easier" ... "So I can reformat it to bring to this other system". The result is something like "what if we push the data to their API, that we already have integrated with, once every hour?" Sometimes it's software, sometimes it's not, mostly it ends up being a mix -- but importantly if you don't ask "why" enough, you'll solve the wrong or at best only an intermediate problem.