Thinking about software engineering

One point that I disagree with is &quot;Every question asked in an internal Slack is a policy failure. It means the existing information systems failed to deliver an answer, and the user falls back to manually asking the hive mind&#x27;s tacit knowledge.&quot; I find it&#x27;s usually a failure of the doc search mechanism. It&#x27;s much faster to ask humans a vague question than try to form the right search query for the internal doc system, which is usually much much worse than Google.<p>This can be solved by making docs public, but also by having people respond with a link to the docs. So Slack can still be a good interface to Q&amp;A, as long as a single answer is documented.

&gt; You can write more or less tests, you can be more or less sure that something you just wrote is actually correct.<p>At the risk of taking things too literally: that&#x27;s quite an exaggeration. Even the most cautiously written code (short of formal verification) often turns out have serious bugs.<p><i>Linus&#x27;s law</i> (curiously apparently written by ESR) famously states that <i>given enough eyeballs, all bugs are shallow</i>. This implies that the typical initial value of 2 eyeballs is inadequate, but even Linus&#x27;s law doesn&#x27;t seem to go far enough. Sneaky bugs can hide for years in mature codebases.<p>&gt; If you take say SOLID which sounds kind of reasonable, the Single Responsibility Principle in an OCD way can only be met by unary functions. Everything else must be doing more than &quot;one thing&quot;.<p>I don&#x27;t see where this is coming from. Multiplication is an operation over two operands but it&#x27;s clearly &#x27;doing one thing&#x27;, to the extent that this is even meaningful.

Hopefully the article is enjoyable to those that haven&#x27;t read his blog, I stumbled upon it because I&#x27;m a fan on nintil in general, but I think it&#x27;s interesting even if you aren&#x27;t familiar with his other writings.

&gt;Absent tooling to detect dead ode I&#x27;m not sure if this is a pun that is over my head or a typo.<p>Thanks for the article. I think the most difficult issue to solve is the meetings one, especially now that so much work is being done remotely. It&#x27;s easy to have inconclusive meetings in engineering because you can just handwave your way through a project that drags on for too long and any non-technical stakeholders will have no choice but to put up with it. Also, engineering is complex and it&#x27;s easy to over-commit and end up with really tough problems to solve.<p>One thing I&#x27;d like to add is that a &quot;meeting&quot; should minimize the number of active participants. If a &quot;meeting&quot; has more than 4 people it should be considered a presentation. It&#x27;s a waste of to be in a meeting and trying to follow a conversation that you aren&#x27;t involved in. If there is information in that conversation that others need to hear, it should be documented in some way.

&gt; Lack of ownership is the root of all evil<p>This is something I battle at every job. Every meeting should include as a documented outcome: who owns this gap we just identified?

Thing is execution of Software Engineering is highly opinionated. People with diverse cultures have different needs &amp; skills. It is very difficult to write one doc that doesn’t raise questions or meetings. I guess we can minimize them by holistically understanding the use of the doc we’re creating.

Really interested in the &#x27;custom pandas typechecker&#x27;. Are there any more details anywhere, or has anyone else tried writing something similar?

What would be the best programming language matching his criteria(flexible, concise, static types, DSLs)?

No, meetings are usually not for thinking. They are for delivering status to an authority figure while wasting everyone else&#x27;s time for the convenience of said authority figure.

There are many misunderstandings in Software Engineering. The first main misunderstanding is that Software Engineering is about writing code. I would argue that is the main misunderstanding.<p>In reality, software engineering is about solving problems, business problems, process problems, machine problems, etc. using code in software as a tool.<p>The 80&#x2F;20 rule applies here. 80% of time is spent analyzing and developing solutions, 20% of time is spent writing code and developing software.<p>Too many people focus on the code part, when they should be focusing on problem solving part.