[ctroein89]

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

> 6. I have a Plan B in case my solution to my current problem doesn’t work.

> 9. I can clearly articulate unknowns and risks associated with my current problem.

These rules imply one of 3 things about the author:

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

* The manager gives zero weight or value to discovery

* The manager expects the whole project to have been fully specified before starting

Yikes, that's toxic! I think it's important that engineers have the mindset of understanding the problem, but that means that figuring out the problem is part of the work! Which then means that engineers should definitely have periods where they don't understand the problem, where they don't have a Plan B yet, and don't know what the unknowns are, because they can't know what the solution will be until they've started the work.

[MajimasEyepatch]

This is a strange interpretation. It does not matter whether you are working on the simplest web page or a brand new problem that no one has solved before: it is absolutely necessary that you clearly articulate the problem you are trying to solve. Even if you’re a scientist working in a purely exploratory, theoretical setting, you still have to be able to articulate your problem. You may refine that as you go, but if you sit down to work on something and realize you can’t articulate the problem, the first step is to stop and focus on defining the problem better.

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.

[ctroein89]

It’s reasonable to have tickets that are “is this API interesting to us?” or “how do clients use this new system?” It’s not a “problem”, and there aren’t definite goals. The task is open-ended, and it’s ultimately up to the developer’s judgement to decide that they are done.

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.

[dekleinewolf]

I think you're using a different definition of 'problem'. Maybe a better word is 'goal'. The point is: you have to know why you are doing something.

[Matumio]

Quoting a researcher: "If you knew what you were doing, it would not be research." (Daniel Lemire, while talking about research grant proposals.)

> 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."

[nooorofe]

Term "toxic" is toxic by itself.

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.

[NikolaNovak]

I'm not reading those 3 nearly as Cynically.

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.

[datagram]

I don't think the rules imply any of that.

"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.

[ChrisMarshallNY]

> figuring out the problem is part of the work

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.

[pardon_me]

Exactly. The hardest part about software is deciding how to implement the tools we have, and not knowing the answer until we start developing and uncover the true problems we must solve. A list of small tasks to complete is solvable by AI.

[quickthrower2]

The problem to be solved can be "I have been given a single sentence specification and I have no idea what the boss wants".

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".

[systemvoltage]

> Yikes, that's toxic!

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.

[outworlder]

And that's precisely why 'spikes' or 'POCs' exist. It's way more common to not have all the answers if you are working on anything remotely interesting. There should be some time to explore solutions. In even more interesting cases, solving the unknowns is the entire project.

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

[MajimasEyepatch]

Where does the article imply that seniors don’t do research? How exactly do you expect that anyone can know these things without doing research? The point of the article is that juniors jump into the work without doing the research to figure these things out, while seniors take the time to figure these things out. Sure, maybe they can do that quickly based on experience, but I don’t think the article implies that seniors don’t do research.

[strken]

Having a plan B for things is a bit silly sometimes. If you need to parse some data, your plan A is to write a parser, and your plan B is...to write a parser in a slightly different way? Pair program as you write the parser? That's not really plan B, it's just redoing plan A if you mess up.

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