Never Take a Hard Shot
Permalink: Never Take a Hard ShotI saw this thread go by on twitter and I thought it was some excellent advice.
Don't solve hard problems. Break hard problems down into easy problems and solve those easy ones instead.

I saw this thread go by on twitter and I thought it was some excellent advice.
Don't solve hard problems. Break hard problems down into easy problems and solve those easy ones instead.
If you map every letter to a sequence of numbers, every book can be expressed as a number.
If you then prefix these numbers with "0." You will have a number between 0 and 1. This means that every book, every story, and all written language (now and in the future) exists as fractions between 0 and 1.
It all already exists, we just have to find the interesting numbers.
The plan is always the first casualty of war.
So, why does it happen? Why are we always wading?
There are many factors that contribute to it. Let’s picture a company growing, hiring more employees to grow faster, new developers come in, old developers leave, the dynamic business changes the requirements quite constantly, the communication between IT and business has gaps, developers are so focused to achieve the sprint commitment, the rush is always putting pressure on everyone working on the project, no one cares to learn about the user-product relationship, no one cares to write tests, developers cannot design as it seems not to deliver short term value, TDD is philosophical, the company doesn’t invest time to train its teams, the most valuable practice is what solves the today’s problem, hero culture rises, we always need more logs to try to realise what is going on, we need to lead the market…
Learning to juggle…
one ball takes a second
two balls takes a minute
three balls takes an hour
four balls takes a week
five balls takes OCD
The light at the end of the tunnel
is the headlight of an oncoming train.
I briefly covered a mapping function in "The Functional Shape of Loops" which can be used for one-to-one mapping, meaning that one item in the input collection produces one value in the output collection:
[1, 2, 3] |> map((n) => n * 2); // [2, 4, 6]
Sometimes it's useful to have a one-to-many mapping, where one input produces multiple output values.
I was writing some code in a template that looked a lot like:
if (collection.HasItems)
{
foreach (var item in collection)
{
<some markup>
}
}
else
{
<some message about no items>
}
and I realized that it would be awfully nice for for, foreach, and while loops to have an else clause.
Learning to program, it's quite common to come across many resources and code samples that include imperative loops of various sorts (particularly for and while).
Frequently when I see examples that include loops, I cringe. They often include many steps that make them harder to understand because there is so much happening every iteration.
Instead, I much prefer to use a functional approach to iteration. Each step can be converted to an individual function and those functions can be applied to the entire collection to produce a result.
There are several advantages to the functional approach over imperative: