Don't force the reader of your code to scroll past the minutiae.
function makeBreakfast() {
const ingredients = fetchIngredients();
const friedBacon = fryBacon(ingredients.bacon);
const cookedScrambledEggs = whiskEggsAndFryThem(ingredients.eggs);
const preparedMeal = plateAndSeasonMeal(friedBacon, cookedScrambledEggs);
return preparedMeal;
}
function fetchIngredients() {
return {
bacon: 'got some bacon',
eggs: 'got some eggs',
};
}
function fryBacon(bacon) {
// return some fried bacon
}
function whiskEggsAndFryThem(eggs) {
// return some cooked scrambled eggs
}
function plateAndSeasonMeal(friedBacon, cookedScrambledEggs) {
// Transfer fried bacon onto the plate
// Transfer cookedScrambledEggs onto the plate
// Season what's on the plate
// return the meal
}
Good tooling will provide a delightful developer experience that motivates further work. Bad tooling will promote demotivation, leading to the death of the project.
It should be easy to clone a project and get it up-and-running.
A developer should be able to change a piece of the project and have the tooling respond almost instantaneously with the results of their change.
Fight tooth-and-nail for every microsecond you can save on build execution time. If a dependency introduces tooling head-aches and longer waiting periods, alarm bells should be ringing.
Code is a blueprint. No user ever cared about the blueprint. They cared about what was created from the blueprint
Delightful code does not lead to a delighted customer. What the customer experiences with the running software is all that really matters.
However, if a developer is not delighted when they work on the blueprint, it will be a challenge for them to delight their customer.
const preparedMeal = plateAndSeasonMeal(friedBacon, cookedScrambledEggs);
This line might be confusing as you don't declare
cookedScrambledEggs
before