Periods when engineer don't understand the problem should be spent on analysis of the problem domain. "Now I am working on defining the problem domain" - is an activity to work "I don't understand the problem" task. During that period probably zero code will be written.

> That author only encounters problems that have been fully solved before

He doesn't, otherwise there would be no talk about "plan B" and risks. When you actively write a project code, you should know that solution is possible. Having plan doesn't mean "problems have been fully solved before". You may have POC which doesn't end in resolution, but it should be clear what is POC for and a failure is possible outcome.

"No one has ever solved this problem before and I'm not sure where to start" seems like an important unknown/risk to let your manager/lead know about. Likewise, the backup plan can just be "we scrap that feature" or "we solve a much simpler problem". The point is to be deliberate about what you're doing and communicate potential setbacks.

Point 1 is a prerequisite to points 6 and 9. But once you’re ready to start actually building a solution, you should absolutely have an understanding of the risks and a Plan B in case your solution fails.

Nowhere in the article does it imply that you can fully understand a problem without putting in the work. The difference between juniors and seniors that the article is highlighting is that juniors will jump into implementation without knowing these things, while seniors will take time to do some research and figure these things out first. Usually, if you’re senior, you should also have the experience to do so quickly, but that’s not always possible.

To define terms, “the problem” is the issue faced by the client or the customer. The task isn’t the problem. A team should tackle tens or hundreds of tasks while still learning to understand the full problem. This is the motivation behind iterative processes like Scrum.

The author’s message is that if you don’t fulfill all 50 requirements _at all times_, you don’t even deserve to be a software developer (not even a junior). I disagree. I think I get the message that these rules are trying to send, but I think they are, as a whole, unreasonable in a professional, business environment. Everyone should be a product engineer, but being product-focused necessitates speculative activities that exist for no other reason than figuring out the boundaries of the problem being solved. And those activities need to be repeated as the problem is being solved, to evaluate if the problem is correctly understood. Someone, whether that’s a junior or a senior, needs to be spending time doing things that aren’t articulateable so that everyone else can articulate exactly why they are working on their current tasks.

As I become more senior, I’m starting to appreciate all of the tasks that don’t go onto the sprint board and aren’t articulateable. They exist because I need to know enough about Product’s or Account Management’s job to communicate with them, and I won’t know what exactly “complete” is until I’ve reached completion on those tasks. That’s part of the job, and I reject any list of rules that leaves no space for those activities.

> 1. I can articulate precisely what problem I am trying to solve.

You can read this in multiple ways, but I'm reading it as: "I'm not participating in the process of figuring out which problems we can solve. I will only ask for clarification of your intent, never try something on my own."

It seems that the author has never encountered the "research" side of R&D.

IME, finding the problem is almost all of the work.

Once I can reproduce an issue, and trace it to its genesis, it's as good as solved.

We have a problem where there isn't ever a mild criticism or offering a different perspective. Just because you don't see the world your way, doesn't mean that others are toxic.

I think this is serious problem and should be reflected upon. Sometimes to push your perspective, it starts with considering other perspectives with good intentions. May be people will listen to you.

The plan B can be "The boss cannot tell me what they want in a succinct way, and/or I am not confident what they want, so I will make various suggestions and get them to choose an option."

The unknown risks - all developers intuitively should know this unless they are very new. Stuff like "this will work, but not effort is going in to how to scale this up later", or "this requires digging up some old code no one has touched for ages, which could explode the time estimated if it is hard to understand that code or refactor it".

Number 1 should not be controversial for vast majority of IT. If you cannot articulate what problem you're trying to solve, you won't know when you're done or how to approach it or what it's value is. Anything from scope creep to underfunding to business mis alignment are classical dangers of not having #1. (note it does not read "I know exactly the specific solution and implementation details". Just says "understand what the heck you're trying to accomplish", which I would expand as "understand and agree")

#2 I view tactically and or operationally. It's good, when choosing a tool or approach or algorithm or vendor etc, to know what some alternatives may be. Presumably, you consciously or subconsciously did that work anyway during solutioning or POC or just brainstorming phase.

#3 is basic project management. Articulating risks is crucial. Ideally the developer can do it but if not, for love of all that is unholy, somebody should :). And you should be able to articulate some key unknowns - e. G. I don't know the performance of this yet to be developed application until we get to performance testing.

Plan Bs make sense for external dependencies, but for internal work they imply your current solution has feasible alternatives, which is often nonsensical.