Thinking is your defence against stupidity
Ben "The Hosk" Hosking
September 7, 2022
7
min read
Developers need to reason from first principles because assumptions or letting other people think for you will often result in doing the wrong thing and wasted time.
I was trying to get the Microsoft Power Platform CLI to work to move a Power Portal from one environment to another. In theory, this copies the portal in a file and then you can import this into another with a few lines of PowerShell.
Except it wasn’t. I got an error saying the file was too big or the wrong file type. It was the end of the day. I was getting hassled for an update on progress. The progress is we are stuck with an error and we don’t know what the error means.
There were other environments where the portal had been imported, I looked at those environments to see the settings . There are two settings.
The limits on the other Dynamics 365 environments were 5 megabytes, I looked at the blocked file extensions. I compared them to the environment I was using, and it had the same file extensions.
I asked another developer how they could import the portals, if the extensions were the same. He explained the tool they used removed the js filetype, imported the portal and then added back in the js filetype.
Error messages rarely tell you what exactly is wrong, they point you in the right direction. The error message was telling me there was an incorrect file type and instead of thinking it through, I used assumptions.
If I had thought what was happening, if I thought checked the file types that were importing, I could have worked this out.
Assumptions are the own goals of software development
They are bugs you create by assuming something works in certain way and you don’t stop to clarify it. You then build software on top of the assumption.
When a hopeful user proves the assumption is wrong, the code needs to change and everything dependant or connected to it might also need to change.
Requirements is common area assumptions kick developers in the butt but assumptions appear in other areas.
examples
Letting other people think for you as a developer is like trusting those people to pack your parachute. Only checking the parachute when you pull the cord whilst you are hurtling towards the ground.
Musk: Well, I do think there’s a good framework for thinking. It is physics. You know, the sort of first principles reasoning. Generally I think there are — what I mean by that is, boil things down to their fundamental truths and reason up from there, as opposed to reasoning by analogy. Through most of our life, we get through life by reasoning by analogy, which essentially means copying what other people do with slight variations
Elon Musk used first principles thinking when creating Tesla. At the time, batteries were expensive and couldn’t hold much charge. Musk used first principles thinking to question why were batteries so expensive when you consider whats used to make a battery.
Musk thought that electric would be cheaper than gas/petrol. A huge power station must be a more efficient way of creating energy than a small combustion engine. Musk created huge giga factories to reduce the cost of batteries.
Another example of first principles thinking is Space X and reducing the cost of space rockets. Musk saw the big expense in space rockets is they are used once, SpaceX made reusable rockets that can land (safely) and be used again.
“I don’t know what’s the matter with people: they don’t learn by understanding; they learn by some other way — by rote or something. Their knowledge is so fragile!” — Richard Feynman
When you don’t think for yourself, you are risking going wrong and not knowing why. Developers should learn to understand, not learn to just solve the problem in front of you.
Falling into a trap of not thinking is a common misstep. Many times I have started off creating a document by copying the format a previous or similar document has used. Whilst copying the document, I come to sections that don’t seem to make sense or pointless.
Often at this point I will think about the purpose of the document, what's the goal of the document and what should it contain?
The times I have assumed someone else has done the thinking and worked out the best approach, I have sleep walked into problems.
An opposite example is removing code. You might look at the code and think its rubbish and not needed. In this example you aren’t doing enough thinking, what is the code doing, why did someone create this code.
“Don’t ever take a fence down until you know the reason it was put up.” ― G. K. Chesterton
Before You Remove or Change Code, Think of Chesterton’s Fence
Don’t remove code until you understand what it does and why it was added.
It’s easy to be hit with a problem or requirements, search the internet and within a few minutes you will have the solution.
Copy-and-Paste Developers Suffer From Fragile Knowledge because if anything changes they won’t have the knowledge of the problem or the solution to fix it.
A solution that you copy, requirements you use without understanding the business or design you implement, is a shortcut.
Best practices you use but don’t understand are a short cut.
This knowledge is fragile and brittle. If the environment changes and you need to modify the current solution or need to create a new solution, you haven’t got the knowledge or experience to do so.
A copied solution from the internet is giving a developer a fish. It solves the problem for one day. Understanding how a solution works gives you knowledge and experience that you can use to create many future solutions, code and software.
You want to learn how to fish not just get one fish. Good developers are curious and they learn to understand. This way, their knowledge, skills and experience grow. They become more effective and more valuable.
Creating software is understanding requirements and thinking of the best designs/code.
I have seen lots of developers skip the learning. These developers get stuck as soon as the bugs and problems appear.
It's worth the effort to think before you act in software development, it will save you time and mistakes.
What are the business goals and purpose (not just requirements because requirements are often wrong or missing)
The other way of thinking is second order thinking. Second order thinking goes below the surface and asks and then what. Decision and actions have second-order and unwanted effects. Software has many interrelated pieces of functionality/code.
Software is a game of thinking and it’s better to avoid problems and do things right first time. Many times I have seen people create great software but the requirements were wrong and the software was wrong.
A developer should be like a carpenter, measure twice and cut once. Developers should think, clarify and question, before they create software.
