def programming

Scrum is like the rules of soccer. Following them does not make you a good player.

These days, the problem isn't how to innovate; it's how to get society to adopt the good ideas that already exist.

If you say "I told you so", you are the one who has failed. Because you knew, but did not manage to stop the train wreck

What one programmer can do in one month, two programmers can do in two months.

Programmers have to fight against the two most destructive forces in the universe: entropy and stupidity.

Promoting a good developer to management is often a twofold bad move: you'll lose a good developer and get a poor manager.

Software being "Done" is like lawn being "Mowed".

90% of the functionality delivered now is better than 100% delivered never.

Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.

Almost every attempt at making something better will be regarded by someone else as a personal attack.

An evolving system increases its complexity unless work is done to reduce it.

UNIX is simple. It just takes a genius to understand its simplicity.

Go is the language JavaScript programmers retire to when they get old. Like the Florida of programming languages.

I know testers who make good devs. I know devs who make good testers. I know Scrum Masters who make good coffee.

on scrum

We crave for new sensations but soon become indifferent to them. Wonders of yesterday are today common occurrences.

Hardware eventually fails. Software eventually works.

That which optimizes one part of the system necessarily undermines the system as a whole.

Every great developer you know got there by solving problems they were unqualified to solve until they actually did it.

Teams are immutable. Every time someone leaves, or joins, you have a new team, not a changed team.

on teams

Start out with finding the right problem to solve. This is a combination of “what customers are asking for”, “what customers don’t even know they want yet” and “what can be solved with something simple to understand and manage”

Like designers, if you give a programmer a problem with parameters, they’ll apply every bit of genius they have to solve it in the best possible way. If you tell them how to do it, you’ll suffer the wrath of an angry God.

There's nothing more permanent than a temporary hack.

It can be better to copy a little code than to pull in a big library for one function. Dependency hygiene trumps code reuse.

A programmer does not primarily write code; rather, he primarily writes to another programmer about his problem solution. The understanding of this fact is the final step in his maturation as technician.

Telling a programmer there's already a library to do X is like telling a songwriter there's already a song about love.

Built with using

Source code available @ githubpull requests are more than welcome ;-)