Posts tagged #Engineering

In networking, adding too much buffering to intermediate network devices introduce unnecessary delays. The trade-off is that bursty traffic will have the appearance of getting through faster. But in reality, the speed of the network is still the same. Data just takes longer to get through.

Working with a poorly thought-out, or overengineered technology stack, or an overly bureaucratic organization is also a form of proof-of-work.

Lifecycles of software systems that solve real world problems can be broken down into distinct phases based on where it is with respect to the problem and the eventual solution.

This article presents a taxonomy of these phases that should help you understand how each part of the lifecycle fits together.

• Don't use carousels in your UI.
• Instead, if you must stick content into little cards, let the horionztal layout wrap to additional lines.
• If you end up with too many horizontal lines of content, then you definitely have too many items that can be accessed via a horizontally panning UI. You need a different UI altogether.

Evaluating properties like inclusion and equity of products can't be done through exhaustive enumeration of product outcomes. Instead we will need to increasingly rely on the controls that we place how we construct the products.

Adding more knobs doesn't make your API more powerful.

The only useful strategy is one that reduces risks.

Zero technical debt isn't always the answer.

Configuration-as-code has the same usability issues as everything else as code along with the same benefits.

Luck isn't enough. You need a culture of virtue.

Don't block a code review because of minor issues that are best left to the discretion of the author.

A set of questions help you think through and evaluate proposed projects and research programs.

Markdown documents should be readble without understanding complex mark-up. A growing number of Markdown syntax extensions take the form of HTML or HTML-like tags and boilerplate that hinder readability. Instead we should focus on how some construct should be presented in plain-text for human consumption and then add minimal structure to it for machine consumption.

Takes a look at an alternate form of code highlighting based on core semantics instead of syntactic role.

Large projects accumulate a large number of issue reports over time. This is normal. Typically for a "successful" project the rate of new issues being reported will exceed the rate of issues being fixed. Hence the growth.

But what are they to do about this ever-growing pile of bugs?