5 Intro to Small Hacks

62% of regular Stack Overflow users visit the same question multiple times in a 3-month period.

5

People think that they think, but it’s not true. It’s mostly self-criticism that passes for “thinking”. True thinking is rare, just like true listening. Thinking is listening to yourself. It’s difficult. To think, you need to be at least two people at the same time.

‒ Jordan B. Peterson, “12 Rules for Life” (emphasis added)

5.1 What it’s all about

I found that solutions I look for when programming come in two categories:

  1. These I remember easily, and
  2. These I find hard to remember.

This is a collection of the latter type.

The reason why I created this document was to collect and organize the solutions to problems I had once found how to solve. My goal in each iteration of editing this document is to make these solutions a bit more useful to any person that might need them.

The measure of success of this document in realizing its purpose is the number of times someone successfully applies a solution described in it to reach their goal.

5.2 Organization of content

This document is managed in a cache-like manner.

This means that methods used more often are listed at the top of the chapter. These used less often, or those less important, appear further down.

In spite of that rule, each recipe is easily accessible thanks to the “search” feature available in every distribution format. Those formats include: HTML, PDF, and EPUB.

For the planned printed edition, an index shall be available in the end to facilitate searching.

Areas considered in this book include:

  1. Software engineering using Linux, VIm and other tools.
  2. Unix-like operating system architectures and operation,
  3. Documentation, listening and communication with the user,
  4. Software distribution,
  5. Best practices for the system administrator, and
  6. Fundamental concepts of machine learning.

5.3 Enjoy your hacking

What follows is a passage from one of Richard Stallman’s memoirs.

In June 2000, while visiting Korea, I did a fun hack that clearly illustrates the original and true meaning of the word “hacker”.

I went to lunch with some GNU fans, and was sitting down to eat some tteokbokki (*), when a waitress set down six chopsticks right in front of me. It occurred to me that perhaps these were meant for three people, but it was more amusing to imagine that I was supposed to use all six. I did not know any way to do that, so I realized that if I could come up with a way, it would be a hack. I started thinking. After a few seconds I had an idea.

– Richard Stallman, “On Hacking” 6

  1. The world is full of fascinating problems waiting to be solved.
  2. No problem should ever have to be solved twice.
  3. Boredom and drudgery are evil.
  4. Freedom is good.
  5. Attitude is no substitute for competence.

Being a hacker is lots of fun, but it’s a kind of fun that takes lots of effort. The effort takes motivation. Successful athletes get their motivation from a kind of physical delight in making their bodies perform, in pushing themselves past their own physical limits. Similarly, to be a hacker you have to get a basic thrill from solving problems, sharpening your skills, and exercising your intelligence.

If you aren’t the kind of person that feels this way naturally, you’ll need to become one in order to make it as a hacker. Otherwise you’ll find your hacking energy is sapped by distractions like sex, money, and social approval.

(You also have to develop a kind of faith in your own learning capacity — a belief that even though you may not know all of what you need to solve a problem, if you tackle just a piece of it and learn from that, you’ll learn enough to solve the next piece — and so on, until you’re done.)

– Richard Stallman, “Hacker Howto” 7

5.4 Principles

From the Agile Manifesto 8:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

After the Agile Manifesto:

  1. My highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity – the art of maximizing the amount of work not done – is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

5.5 Features

Each hack description shares the following properties:

  1. Has been successfully used at least once,
  2. Can be understood and applied in less than 3 minutes.
  3. The hacks are reviewed and updated each year together with the changes in software and hardware.