Delayed failure - 123dev #76

Sometimes things break later

We often measure things in development environments to understand things like how much traffic our application can accept or how many resources it’ll use. This is a good practice to get estimations, but the only measurements that matter are the ones we do in production.

I’m building a case and have to make custom brackets. I measured the space and then made prototypes out of cardboard and paper. I created 3D models and printed them. Hours later I had a physical bracket I could finally use! A marvel of rapid prototyping.

However, I neglected to measure the bracket when the rest of the case was assembled. All of my screw holes were off and I forgot to give clearance for a critical part of the case. I had to repeat a lot of work I could have avoided by measuring with the production assembled constraints.

Welcome new—and old—subscribers! This space usually gives you more information on how to be a better engineer, but I have been reserving it instead to show support for Ukraine in the ongoing war for their freedom.

The secondary impacts of this war are beginning to show (e.g. grain shortages) and it remains to be seen what this will do to the Russian economy. There have been too many horrible things that have happened in the world recently. I remain hopeful for the people of Ukraine that this attack will end soon.

Are you ever curious what technologies a website uses? Built With can show you some of the front end and marketing tracking websites use.

Technical interviews mostly suck. Many of them still require leet code style questions with riddles to solve and then require you to write code. Most of the time you don’t have the ability or time to search the internet or read documentation which is not how the vast majority of developers work.

I like this approach of having someone explain code that’s already written. It shows they understand it or gives you insight into gaps they may have or their reasoning about what things might do. I especially appreciate this blog for explaining the perfect answers they’re looking for.

I can never remember what this paradox is called so I’m sharing it here that maybe it’ll stick this time. Jevons paradox says that efficiency gains (via technology, policy, or process) will be lost due to increased usage. Jevons measured it with coal but the same can be seen in other systems like highway lanes and internet bandwidth.