Photo by Nico Smit on Unsplash

Today, our society tends to move more and more towards specialization. You can buy everything prefabricated, and you are supposed to hyper-specialize in your job.

When it comes to your life, you should really consider if this makes sense for you.

Here are some examples, what we do on our own. Many examples are mundane — but that is just fine, considering that many people cannot boil an egg, without a special appliance.

We are chefs

Every morning, we stand in our kitchen and prepare a meal tailored exactly to our taste. Additionally, we have complete control over all the ingredients - which is great since we both are on a special diet.

It’s cheaper and healthier than to buy a meal every day — and best of all, cooking is a skill, and we are getting better and better.

We are barbers

Jupp. It probably doesn’t look great, but this saves money and is relatively simple to learn.

For the ladies, this is probably a bigger challenge — but it should save you gals even more money.

We are farmers

We have a little garden and are starting to grow our food. I won’t argue that this is cheaper in every case — it isn’t — but It’s great to do it.

We build furniture

Some of our furniture is hand-made by us. You really don’t have to buy every piece of furniture. It’s wonderful to have some pieces custom-made by you.

We repair our devices

If a device is broken, we try to fix it. Occasionally this is beyond us — but often it works.

What has this to do with early retirement?

My point is — you don’t have to buy everything. Use your money and save money to build the skills you want. You don’t have to be perfect.

This is very rewarding.

As a retiree you will probably be very happy to be into knitting and soldering or to have acquired other new skills.

Photo by Shir omani Kant on Unsplash

I love reading. When I was young, my parents heavily subsidized my book purchases. So, I formed a habit of buying a ton of books.

When I became a programmer, this started to become more and more costly. Every few days, the postman delivered my books.

When I started to budget and tried to invest money, I noticed that I spent between 100-200 Euros on books every month.

This means 18,000 Euros over ten years. Quite a big sum.

I managed to get my book related expenses down to 20 Euros per month with these tricks. Spoiler: They are obvious — but only in hindsight.

The library

Most of my non-technical books I get from our local library now. It has quite a wonderful assortment of great books. And: Every time I ask for them to buy a new one, they buy it for me.

I enjoy being there. It gives me a sense of community to share all these books with many people.

Used books and selling books

For books that the library doesn’t have, I buy used book over Amazon Marketplace. And after I read them, I sell them.

This makes even expensive books very affordable.

My employer

For work related books, my employer is happy to order them for me. And I can give these books to my colleagues and have them at hand in our company’s library.

Saving is not about sacrifice

So, you see: I still love books. I read as many as before. I enjoy walks to the library — and all the book-loving people there.

I do not have shelf after shelf full of books at home — but that’s fine with me.

I save a ton of money — and still enjoy reading.

These are the kinds of things, you have to watch out for — where you waste money, without improving your life.

Imagine there were no days, no hours and no seconds. And no time.

How would you feel about problems in the future?

How would you feel about the past?

What would be your story without a past? Would there be a story?

Who would be you without time? Would you even be?

What would be true? What would be false?

Would you even think these questions? Would there be any questions?

Or would you just live in bliss? Now.

God, grant me the serenity to accept the things I cannot change,

The courage to change the things I can,

And wisdom to know the difference.

Reinhold Niebuhr (1892 – 1971)

Life is full of problems. Haven’t you noticed? You can spend your whole energy and creativity on fixing them.

Here are a few examples that you might encounter as a programmer:

• Your team does not test code
• You want to use Git, but everyone else just feels fine with SVN
• No department speaks to another one
• Scrum sucks

I had quite a hard time trying to fix all these things only a few years ago. It was quite impossible for me to “fix” these things in my team.

Do not try to change people

This is my advice: Do not try to change people.

It sounds simple. But it isn’t easy to do it.

Start with yourself

Here are a few examples:

Example 1: Everyone else uses SVN and you want to use GIT

What you can change today is use git-svn. It is not perfect, but you can commit as often as you like, squash commits and only push quality code into SVN.

You don’t have to ask anyone. Just do it. Be patient and wait. Someday, some other colleagues might use GIT. Tell them about git-svn. Before long, you all might use GIT.

Example 2: Your team does not test code

And what about you? Do you really test-drive or test code? No? Then why not start now. You don’t have to ask for permission. If you believe it’s what professionals do, then do it. Today.

If there is a point to testing, then someone might notice. If there is no point to testing, you might notice.

Example 3: The debarments do not speak to each other

Speak to another department. Invite a colleague that you don’t know to lunch. Are you willing to do this? Are you willing to do this weekly?

Are there any colleagues that might be willing to do it? Can they join you? Ask them :)

Is there a question in your daily work, that only another department can answer? So, why don’t you ask them?

This is something that you can do. Today.

Why is this more effective?

You can act immediately on these problems. You do not have to ask for permission to change yourself.

Why waste any energy on stuff that you cannot do? It is absurd to change, if you think about it. It shows a lack of trust into your fellow programmers. Without trust, why should they follow you? You are not testing your code as well. You are not talking to other departments — why should they?

Change yourself

The things that you cannot accept in others, are a mere reflection of you. You cannot accept them because you haven’t come to terms with yourself.

Try to change yourself.

You might not change the “situation” at all — but you will stop to be its victim. You will feel much better and, in the end you might be surprised, that the problem just dissolves over time.

After a few of these experiences, you might even notice, that the biggest problem might have been your perception of the “situation”.

This is for the brave

Do not forget that changing oneself is only for the brave. It hurts to see that all the bad things that we think “others” do, we might actually do ourselves.

So be gentle to yourself :)

When I started to pair-programm I had absolutely no idea what I was doing. I sat next to another programmer and we started. Occasionally it worked, but more often it was a frustrating experience.

Maybe you are new to pair programming and want to give it a try, or you have trouble getting started. Then this blog post is for you.

I show you how we pair at Gutefrage.net. Some of this advice is really obvious — but much of the other stuff we figured out the hard way through pairing over and over again.

“Lightspring/Shutterstock.com”

Preparations for your first pairing session

Probably your workspace is not suited for 2 people working on it for an extended amount of time. So, before you even begin: Be a good host: Adjust your environment for pairing.

Physical preparation of your workspace

Move away the piles of paper, the dishes, and your backpack under the table. Clean your table. Don’t let the navigator feel like he is just a visitor.

Now move 2 chairs in front of the table. If you do not pair all the time, it is also ok to keep a few spare chairs scattered through the office.

Prepare your hardware

Now take a good look at your screen(s). Can you see them from both perspectives? Is the contrast high enough?

Especially with notebook screens, it can happen that the person sitting next to you will have such a bad contrast that it might be hard for your pair to see what you are doing. If this is the case, get a monitor that both of you can watch.

Place a second mouse/keyboard combo on your desk. It’s nice for the navigator to point to code or be able to write a chunk of pseudocode, and it costs nearly nothing.

Prepare your computer

Adjust your font size to 16px or 18px. I know this seems ridiculously big, but it will be much nicer for the navigator to look at it. (And also for you, of course)

Now close all your programs. E-Mail clients, IRC, Instant Messenger are of-limits during pairing in my opinion. You will have time for checking this stuff in between the pairing session.

Prepare an editor/IDE that both of you can use. Get an environment ready that works, check out the project, run the tests.

Talk to your partner

You should know each other’s schedule. I find it frustrating if my pair has to leave in 15 minutes. Better to know in advance.

Grab Essential tools

Now the navigator should grab a notepad and a pencil. Also prepare a timer.

A kitchen timer works fine, alternatively search for “Pomodoro Timer” on Google.

Immediately before every session

Grab a coffee, go to the restroom, and prepare yourself to focus for the next 25 minutes. Close open loops that might distract you during this time.

The first pairing session

At the beginning of each session, the navigator sets the timer to 25 minutes.

Then talk about what you want to do on a high level. Both of you should have a good idea about the scope of the task ahead and what steps are involved.

If the task consists of multiple steps, the navigator should write down a list off these steps.

Write a test first

Pick the best step to start with and write the first test. Try to get the test right, so you both understand what needs to be done.

TDD is especially effective with pairing, it communicates what you want to do, and it will focus both of you on the next step.

Driver

Now the driver’s responsibility is to implement the code. Explain what you are doing along the way. Do not concentrate that much on the big picture, but try to get the task at hand done. Trust your navigator to keep the larger picture in sight.

Whenever there are alternatives ways to do it, and you are not sure — ask your navigator what to do.

Let the navigator guide you through the list of tasks. Ask him how to proceed if you are unsure.

Navigator

Ensure that you work on the tasks on the list.

If you discover additional tasks — it often does make sense to postpone them and focus back on the problem at hand. It’s your responsibility that both of you don’t forget them — so write them down.

Keep engaged with the driver and try to understand what the driver does.

When you notice that the Driver get’s stuck, unstuck him. Even if you don’t know the answer to the problem at hand — ask him a question.

Point out typos or problems if the driver does not see them himself. Is the code understandable? Are the variable names ok? Is the class getting to bloated? Do an on-the-fly code review. Mention problems. But do not micromanage, of course. — Just like in a normal code review.

Pull the driver out of the implementation if you have the feeling that you should change the angle. Discuss it with him.

Talk, talk, talk!

“pio3/shutterstock.com”

You should communicate all the time! In a good pairing session, it really feels like you are working on this in unison. As the driver you can focus on getting the tests passed and as the navigator you can keep the pair going in the right direction, ensuring an excellent quality.

Communicating right is maybe the hardest part for most programmers — just keep doing it. It’s a skill that you can acquire and if the pair is really attuned to each other after many sessions this will feel like second nature to you.

General behavior

Concentrate on the task at hand for 25 minutes. Do not watch your emails, do not take breaks, try to stay engaged. It is expensive for 2 programmers to become distracted.

Work step by step from your list. After you have finished a step, take it off the list and start working on the next step.

Don’t argue too much. This is not an ego game — if both of your solutions are equivalent, just decide and keep going ;)

After the session

The session ends after 25 minutes. Take a break of at least 5 minutes. This is the time to grab a coffee, to visit the restroom, check your mails and take a break.

Good pairing is intensive. You will need the break, especially if you want to work for a few hours in a pair.

After each pairing session, switch roles. We solve this with a WIP commit to the feature branch, then we change workstations.

After the break is over, start another pairing session if needed.

Conclusion

Getting started with pairing is no easy feat. Don’t get discouraged. It is worth to learn it.

In a future blog post, I will describe the many problems that you might encounter during pairing and how to tackle them.

I hope after reading this little primer you get the idea how this could work and be sustainable. Since this are not best practices by any means, feel free to implement pairing your own way.

If you have experience pairing or tried this out: What are your thoughts about this? How do you pair?

I just finished reading Linchpin: Are You Indispensable? by Seth Godin 📚. The book really strikes a chord with me.

Essentially it tells you why its a good idea to not only do your “job”. Why you should care to be an artist and why you should engage much more. It suggests that you have much more to offer than just being a cooperate drone.

It also talks about fear and hesitation. And why you should not listen to this kind of thoughts -
just act on your ideas.

I couldn’t agree more! Every other way of working is a waste of your time.

I enjoyed reading the book.

I made me stop and think about what I can contribute.

Highly recommended.

Castle 11 from Bill Ward’s Brickpile. (CC BY 2.0)

Since quite a while, I try to find a good solution for sharing my dotfiles between my different computers.

I started with chef — Unfortunately, this did not work so well. Especially if you also want to use your dotfiles on a server. Also, it felt a little complicated.

The next approach I took was putting my dotfiles into my Dropbox and symlink them. This worked ok. But Dropbox on a server? No way.

So, I kept looking. A few days ago, I stumbled over
homesick — an astonishing rubygem that manages your dotfiles.

How to set it up

First install homesick:

gem install homesick

Now create a “castle”. A castle is a collection of dotfiles.

homesick generate ~/dotfiles

This creates a git repro with a /home folder inside. Just put your dotfiles / dotfolders in there. Then push the stuff to GitHub.

Now install the castle with homesick.

homesick clone https://github.com/foo/dotfiles.git

Now let homesick do its magic.

homesick symlink dotfiles

All the dotfiles from within this castle will be symlinked.

This is wonderful!

• You feel at home at each of your servers in no time
• You share your dotfiles with the world
• You can learn from others and refine your files
• You can put essential little scripts into a .bin directory.
• The castle concept allows you to try someone else’s dotfiles

A word of caution

Please do not put sensitive information into you dotfiles.
Especially ssh keys, bash histories and passwords in configuration
files do not belong on GitHub.

Try it!

Seriously. It’s magical. This is one of those things that you try out, and you ask yourself how you could possibly live without it.

Interested? Have a look at my dotfiles.

From time to time, I really want to make it hard for me to seek for distractions.

I found myself using the nice Mac OS X tool Freedom all the time. Freedom disables the network connectivity, which means no Twitter, Facebook etc.

But when I revisited the site, I found that the author now charges $10 for it - That’s just a little too expensive in my opinion.

So, I went out, and it took me 5 minutes to come up with freedom.sh.

# !/bin/bash
echo "Enough of this filthy internet" | cowsay -s
sudo route -n delete default &> /dev/null

Cowsay required. (If you prefer not to install cowsay just remove the line!)

________________________________
< Enough of this filthy internet >
--------------------------------
            ^__^
            (**)_______
            (__)       )/
             U  ||----w |
                ||     ||

To reenable your internet, you have to add back the default route or restart your computer.

Little update (18.09.21): I do use Freedom now. It got even more expensive - but it syncs between all my devices and changed from a internet kill-switch to something even more useful. I found it great to disable news sites and other addictive sites during corona.

Last week, my colleagues at Gutefrage.net, and I had our second

Coding Dojo.

I learned an important lesson — even though this wasn’t the first time I practiced the kata.

The kata

The task was to create a class that decomposes natural numbers into its prime factors.

Additionally, the factors should be sorted ascending.

Examples:

1  => \[] # Since 1 is no prime ;)
5  => \[5]
10 => \[2,5]
75 => \[3,5,5]

You get the idea ;)

This sounds simple and like a perfect candidate for an

Introduction to TDD, right?

Unfortunately, this kata is a bit tricky.

Performing the kata

The first tests are straightforward:

module PrimeFactorDecomposer
  def decompose(number)
if number < 4
    number
else
    [2,2]
end
  end
end

describe PrimeFactorDecomposer do
  include PrimeFactorDecomposer

  it "returns no prime factors for 1" do
    decompose(1).should be_empty
  end

  it "decomposes 2 into 2" do
    decompose(2).should be == [2]
  end

  it "decomposes 3 into 3" do
    decompose(3).should be == [3]
  end

  it "decomposes 4 into 2,2" do
    decompose(4).should be == [2,2]
  end
end

Now the trouble begins

Now decomposing 5 would be a nice test? Right? Since 5 is a prime, it would only return 5. But how can we find out if it’s a prime?

So, we could write a function that finds out if 5 is prime. Hm, that seems hard.

What about 6? But then we have to develop an algorithm that works — otherwise, we would just move sidewards and add conditionals.

What’s the problem?

You do not know how to solve the problem. Not everything is as simple as the FizzBuzz Kata.

Adding another test alone does not suffice. It’s a common hurdle for newcomers to TDD.

How to solve this?

Grab a sheet of paper and think about the algorithm. Or do a little spike until you fully understand the problem. Every so often it’s just not true, that a design “magically” emerges.

Learnings

You need sound knowledge about where to go — otherwise you will have problems with TDD along the way. Then you have to lean back and think a little or get feedback from something else than your tests.

TDD is cool, but it cannot solve every problem. Especially not complicated algorithms (this is a straightforward one, of course).

Another personal learning for me was to watch myself better, when I do a kata the first time.

When the design does not emerge from the tests — I should listen to them. Maybe they want to tell me that I have absolutely no idea what I am doing and that I need to think more…

I am quite excited about Avdi Grimm’s new project Ruby Tapas.

Three times a week, Avdi post short videos about different concepts and techniques in Ruby.

The first 3 episodes were short, but I already learned some obscure details of Ruby that I didn’t know about

I think that over many weeks, that should give me a pretty solid knowledge of the parts of Ruby that I do not touch in my daily work.