<story><title>Expectations of professional software engineers</title><url>https://adamj.eu/tech/2022/06/17/mike-actons-expectations-of-professional-software-engineers/</url></story><parent_chain><item><author>ctroein89</author><text>&amp;gt; 1. I can articulate precisely what problem I am trying to solve.&lt;p&gt;&amp;gt; 6. I have a Plan B in case my solution to my current problem doesn’t work.&lt;p&gt;&amp;gt; 9. I can clearly articulate unknowns and risks associated with my current problem.&lt;p&gt;These rules imply one of 3 things about the author:&lt;p&gt;* That author only encounters problems that have been fully solved before&lt;p&gt;* The manager gives zero weight or value to discovery&lt;p&gt;* The manager expects the whole project to have been fully specified before starting&lt;p&gt;Yikes, that&amp;#x27;s toxic! I think it&amp;#x27;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&amp;#x27;t understand the problem, where they don&amp;#x27;t have a Plan B yet, and don&amp;#x27;t know what the unknowns are, because they can&amp;#x27;t know what the solution will be until they&amp;#x27;ve started the work.</text></item></parent_chain><comment><author>MajimasEyepatch</author><text>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.&lt;p&gt;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.&lt;p&gt;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.</text></comment>
<story><title>Expectations of professional software engineers</title><url>https://adamj.eu/tech/2022/06/17/mike-actons-expectations-of-professional-software-engineers/</url></story><parent_chain><item><author>ctroein89</author><text>&amp;gt; 1. I can articulate precisely what problem I am trying to solve.&lt;p&gt;&amp;gt; 6. I have a Plan B in case my solution to my current problem doesn’t work.&lt;p&gt;&amp;gt; 9. I can clearly articulate unknowns and risks associated with my current problem.&lt;p&gt;These rules imply one of 3 things about the author:&lt;p&gt;* That author only encounters problems that have been fully solved before&lt;p&gt;* The manager gives zero weight or value to discovery&lt;p&gt;* The manager expects the whole project to have been fully specified before starting&lt;p&gt;Yikes, that&amp;#x27;s toxic! I think it&amp;#x27;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&amp;#x27;t understand the problem, where they don&amp;#x27;t have a Plan B yet, and don&amp;#x27;t know what the unknowns are, because they can&amp;#x27;t know what the solution will be until they&amp;#x27;ve started the work.</text></item></parent_chain><comment><author>nooorofe</author><text>Term &amp;quot;toxic&amp;quot; is toxic by itself.&lt;p&gt;Periods when engineer don&amp;#x27;t understand the problem should be spent on analysis of the problem domain. &amp;quot;Now I am working on defining the problem domain&amp;quot; - is an activity to work &amp;quot;I don&amp;#x27;t understand the problem&amp;quot; task. During that period probably zero code will be written.&lt;p&gt;&amp;gt; That author only encounters problems that have been fully solved before&lt;p&gt;He doesn&amp;#x27;t, otherwise there would be no talk about &amp;quot;plan B&amp;quot; and risks. When you actively write a project code, you should know that solution is possible. Having plan doesn&amp;#x27;t mean &amp;quot;problems have been fully solved before&amp;quot;.
You may have POC which doesn&amp;#x27;t end in resolution, but it should be clear what is POC for and a failure is possible outcome.</text></comment>