The years 2023-2025 in books

Mon, 12 Jan 2026 11:11:11 +0000

Books read between 2023 and 2025.

Again. Close to zero commute if we discard planes. And less of an interest in reading books in general. A trend I’ll reverse in 2026.

As previously I’ll rate the books from one to three stars. Three of three (3/3) stars being what I thoroughly have enjoyed and would recommend to others who are into the topic of the book or enjoy a good read in general. Giving a book one star neither states the book is bad or I do not agree with it, rather it is something I personally did not enjoy too much.

2023

Project Hail Mary - Andy Weir (3/3)

Plain amazing. Made the flight from El Salvador back to Germany fly by like nothing.

When Money Dies - Adam Fergusson (2/3)

The inflationary spiral in Austria after WW2. Often recommended in Bitcoin circles.

Heat 2 - Michael Mann (2/3)

Had to read it as I’m a huge fan of the 1995 movie Heat. Lots of good parts. I’m waiting for the upcoming movie.

Elon Musk - Walter Isaacson (3/3)

Inspiring. And insane how much the contents would have to be expanded to contain what has happened in the years after the publish date.

Fahrenheit 451 - Ray Bradbury (2/3)

Quick read on censorship.

2024

Wild - Cheryl Strayed (2/3)

Back in 2014 I watched the movie. Didn’t realize it was based on a book back then. Good read!

Seveneves - Neal Stephenson (2/3)

The whole story and idea is awesome. Would be a 3/3 but the beginning was quite slow and the end too boring for my taste.

The slow beginning led me to only finish the book on my third attempt. I tried to read it 2 times in the last 10 years.

2025

Only one. But a great one. One of the greatest I have read.

Musashi - Eiji Yoshikawa (3/3)

Life and deeds of swordsman Miyamoto Musashi.

In 2021 I read about half of Taiko. Same author. Published 2 years after Musashi in 1937. Back then some suggested to do it before Musashi to be historically aligned. Taiko takes place before Musashi. I don’t think this is necessary. Musashi was the superior book.

Even if one doesn’t read Musashi it makes sense to look at his rules:

Accept everything just the way it is
Do not seek pleasure for its own sake
Do not depend on partial feelings
Think lightly of yourself and deeply of the world
Be detached from desire throughout your life
Do not regret what you have done
Never be jealous
Never let yourself be saddened by a separation
Resentment and complaint are inappropriate
Do not let yourself be guided by lust or love
In all things, have no preferences
Be indifferent to where you live
Do not pursue the taste of good food
Do not hold onto possessions you no longer need
Do not act following customary beliefs
Do not collect weapons or practice with weapons beyond what is useful
Do not fear death
Do not seek to possess goods or fiefs for old age
Respect Buddha and the gods without counting on their help
You may abandon your own body, but preserve your honor
Never stray from the Way

The year 2022 in books

Sun, 01 Jan 2023 11:11:11 +0000

Books read in 2022. Zero commute by train. When travelling, or moving, by car I find myself listening to podcasts and music rather than audiobooks. I was able to read 12 books. A lot less than in previous years.

Argentarius - Vom Gelde - 3/3

The author explains to his son how money works. Written over 100 years ago. Fully applicable to today.

Liebe deinen Nächsten (or “Flotsam” in English) - Erich Maria Remarque - 3/3

Why the title isn’t “Treibgut” (flotsam in German) is beyond me. Especially when reading it during evasive travels.

Hunger - Knut Hamsun - 2/3

A struggling artist in Norway. Written over 100 years ago.

Kinder von Hoy - Grit Lemke - 2/3

An introduction to youth live in the former DDR.

Too Loud a Solitude - Bohumil Hrabal - 1/3

The rating could be off. I wasn’t too focussed on the book while reading and found myself moving pages without remembering what is in it. Should give this another go in the future.

Gothic Violence - Mike Ma - 2/3

Lots of short essays. Some “meh” some great.

Alles was wir nicht erinnern - Christiane Hoffmann - 2/3 - Audiobook

The author travels along the escape route of her parents from what is now Poland to their home in Germany after the second world war.

The Corrections - Jonathan Franzen - 3/3

Heard it is a book you should read in your thirties. Applied to me.

Speculator (Book 1 High Ground Series) - Doug Casey and John Hunt - 2/3 - Audiobook

Action packed story on gold mining and speculation in Africa.

Drug Lord (Book 2 High Ground Series) - Doug Casey and John Hunt - 2/3 - Audiobook

Novel on drugs and the FDA and everything in between.

The White Pill - Michael Malice - 2/3

A refresher on communist history from Lenin to the end of the USSR.

The Stranger - Albert Camus - 3/3

I knew nothing about the book when reading it. Luckily I did not even read the text on the back. Almost read this in one sitting. It’s great.

On Purity

Fri, 23 Dec 2022 06:30:22 +0000

Three examples.

Is this a pure function?

const add = (num1, num2) => num1 + num2

How about this?

const getCurrentMonthIndex = () => new Date().getMonth()

Or this?

const log = (msg) => console.log(msg)

Well, what is a pure function?

Definition

A function is pure when given the same input, we always get the same output

Example 1

Given 2 and 3 add will always yield 5

> add(2,3)
5

Thus ✅. A pure function

Example 2

Given no input getCurrentMonthIndex will return us 9 as long as we are in October. As soon as we enter November it will return the number 10.

> getCurrentMonthIndex()
9

Same input - not same output.

Thus ❌. Not a pure function

Example 3

Given the String "hello" log will always print "hello" to the console.

> log("hello")
hello

Same input, same output. A pure function?

What if?

> const console = "broken"
> log("hello")
Uncaught TypeError: console.log is not a function
    at log (REPL1:1:30)

By redefining console we changed the behaviour of our log function. Same input. Different output. As was expected.

❌ Not a pure function

So - How did we find out if these functions are pure?

Pretty much by reading the their implementation details.

Their function body.

And, of course, by testing (calling, invoking) them.

Super easy to do that with one-liners. Hard with functions spanning tens, hundreds or thousands of lines in length.

Creating purity

Can we rewrite both getCurrentMonthIndex and log to be pure?

Of course. We only need to declare their hidden inputs.

For the getCurrentMonthIndex it is the new Date() and for log the console.

> const getCurrentMonthIndex = (today) => today.getMonth()
> getCurrentMonthIndex(new Date())
9

> const log = (logger, msg) => logger.log(msg)
> log(console, "hello")
hello

Is this helpful code? Is this good code?

Up for the reader to decide.

Have we made the hidden inputs visible?

No, there is is still the this present in all JavaScript functions. It is hidden but its there.

Are the functions pure?

Depends. Whether we consider them are pure or not - we probably can agree that they are more pure than they were before.

How did we find out if these functions are pure?

We did so by reading their code. Their implementation.

There is no other way of knowing!

Even if we call them with multiple inputs and check the output it is hard to cover the full space of available inputs.

Especially in the JavaScript case above where the input could be any type. We can add the Strings '4' + '2' and Numbers 4 + 2.

Is there an alternative where we don’t have to read the code?

Let’s play with the programming language Haskell.

sayHello :: String -> String
sayHello name = "Hello " ++ name

sayHello takes a String as an argument and returns a String

ghci> sayHello "Reader"
"Hello Reader"

An equivalent to console.log() would be putStrLn

ghci> putStrLn "Hello Reader"
Hello Reader

Let’s use it inside of sayHello

sayHello :: String -> String
sayHello name = putStrLn("Hello " ++ name)

Running this will give us an error.

test.hs:2:17: error:
    • Couldn't match type: IO ()
                     with: [Char]
      Expected: String
        Actual: IO ()
    • In the expression: putStrLn ("Hello " ++ name)
      In an equation for ‘sayHello’:
          sayHello name = putStrLn ("Hello " ++ name)
  |
2 | sayHello name = putStrLn("Hello " ++ name)
  |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^

String is expected and actual is IO (). The compiler does not allow us to do that.

We have to define the side-effect (putStrLn) in the function definition.

sayHello :: String -> IO ()
sayHello name = putStrLn("Hello " ++ name)

ghci> sayHello "Reader"
Hello Reader

So what?

We don’t have to read the implementation to learn whether the function is pure or not. Only the type signature!

A function taking String as input and returning a String as output is pure. It has to be.

Haskell is considered a purely functional programming language. Not because it has pure functions but because expressions in Haskell can be expressed exclusively in terms of a lambda calculus.

Lambda calculus?

Well, maybe something for our next post :)

Trunk based development

Sun, 27 Mar 2022 06:30:22 +0000

At my first real job, back in 2014, we were using the version control system svn for the backend. The mainline branch - think master or main in git terms - was called trunk.

Every developer pushed changes straight to mainline (trunk). There was no code review before adding changes to mainline. Me, having worked with git previously - in fact most projects in the company where using git already - thought this was subpar. Almost awful. Not the way things are done in modern software development.

Later someone was added to the team in charge of moving us to continuous delivery. When discussing branching strategies yours truly, being an avid reader of hackernews and all things development related, was eager to push for Gitflow.

The response I got back was

Yeah, but thats not really continuous delivery

Boy was I shaken. Isn’t this the cool git branching model everyone is using?

Back then I did not get it. Mostly because we did what most folks do. Have our own definition of what continuous is supposed to be.

In our case it was after every sprint. A release every two weeks - If, and only if, nothing goes wrong.

Of course every two weeks is better than every few months. And every week is better than every two weeks. But not what I would consider continuous today.

We ended up having feature branches, some short lived (days), some long lived (months). These changes were moved to mainline after one or more reviews.

The workflow had its issues but was, from my perspective, way better than to contributing straight into mainline.

Years later, when Microservices were all the rage, I watched a talk by Sam Newman

Some of his comments on Gitflow in the talk

Because if there is something worth doing, there is something worth doing really complicatedly

I don’t understand all this because I’m old and quite stupid

Every single picture that shall explain to me how Gitflow works just makes we want to kill myself

Well the last one is an exaggeration. But taking the

I don’t understand all this because I’m old and quite stupid

from a guy of his calibre is quite humbling.

Today I would agree.

Getting to “short lived” “feature branches” is hard. Both due to a definition what “short lived” is exactly and the common question how the whole “feature” - it’s a “feature branch” after all, can be implemented in a few days, or even hours.

If we get quick reviews, meaning colleagues get into the review ASAP instead of once or twice a day, we might get small branches and thus small pull requests (PR)

Branch -> Fix a flaky test -> PR
Branch -> Fix a typo in the docs -> PR
Branch -> Refactor a method name -> PR
Branch -> Create the DB migration for the feature -> PR
Branch -> Add a failing, ignored, acceptance test for the feature -> PR
Branch -> […] -> PR

And if we have feature toggles in place like

if current_user_sees("our_awesome_future_feature"):
  show_new_feature()

and thus only specific users, or groups, will be able to see the new functionality in production. We can split the feature into

Branch -> Add a button without functionality leading to the new feature -> PR
Branch -> Create the scaffolding (UI) for the new feature -> PR
Branch -> Create the REST API for the new feature -> PR
Branch -> Integrate the REST API for the new feature -> PR
Branch -> Use our corporate design for the new feature UI -> PR
Branch -> Adapt feedback from the UX folks -> PR
Branch -> Improve the performance -> PR
Branch -> […] -> PR

See Structuring work for continuous integration for more examples.

Or as Kent Beck calls it

First make the change easy, then make the easy change

If we don’t get quick reviews the developers will bundle these changes into one big change. This automatically leads to longer lived feature branches.

To avoid the hassle of slow reviews we can try adding a second pair of eyes right away by pair programming or even multiple pair of eyes by mob programming.

Instead of having multiple branches we push small changes into main, or master, or trunk. Together as a team.

That is trunk based development.

Trunk can always be released. It could even be released on every push. That’s the strategy.

Users will not care about unfinished features because they will not see them.

Only the developers. Or any other group configured to see them. When the feature is done the flag can be removed and everyone is able to see and use it.

Linting, complexity and all that jazz

Wed, 16 Mar 2022 06:30:22 +0000

Checking out a new, at least to me, python codebase where the README.md stated

flake8 src/ tests/
black src/ tests/

Flake8 is a tool for style guide enforcement. Often called a linter. A static code analysis tool. While black is a python code formatter.

Cool. Let’s run these commands.

flake8 src/ tests/

Executed successfully. No warnings. No errors. Thumbs up. On with

black src/tests

Executed successfully. Has reformatted a single file. Cool.

Before the reformat there was the following line. (Think of it as one line even if this blog setup splits it into two)

def validate_action(self, currentState: TestRunAction, action: TestRunAction):  # noqa: C901

The reformat did apply the maximum line length rule and changed the above to

def validate_action(
  self, currentState: TestRunAction, action: TestRunAction
):  # noqa: C901

Ok cool, LGTM, commit and push.

Seconds later I get back a failed pipeline result.

Why?

src/backend/processor.py:335:5: C901 ‘Processor.validate_action’ is too complex (14)

Let’s check C901.

Ok, that’s what the # noqa C901 comment did. It told flake to ignore the configured complexity rules for the validate_action method.

Awesome now I can either:

Decrease the complexity of validate_action
Google where else to put the # noqa: C901 comment - All while taking into account the method now being split into three lines

Plus I’m left wondering why there was a file checked into mainline which did not follow the code formatting rules.

Turns out the black formatting is not part of the pipelines. But flake8 is. Explains the failure above.

Fine, the pipeline should probably not reformat the code automatically. As a result it would have to create its own reformat commits.

Two additional todos get added to my backlog:

Find out how to fail the build if black has to format - need to google that - because if there is a reformat black will just reformat and exit with code 0 (success).
Create a git hook to run the command on localhost before a commit. Or to tell the editor to automatically apply black during save.

Additionally we notice the README.md states the two commands in the wrong order. black should have been run first to catch the error before creating a commit.

A third TODO appears.

improve documentation

Now without having fixed the actual issue, the complexity of validate_action, we have already gathered three additional todos.

We enter the common dilemma on whether to be a good sport and fix these issues or to just not give a f*ck, undo the formatting, push changes and have the green build again.

(And even if we give a f*ck we might want to undo the formatting - to be back to green and then to fix all the above)

We could quickly improve the readability of validate_action, achieved by extracting the logical parts into methods. Sadly extracting methods does not improve complexity, only readability. Great example for the difference between complexity and being complicated.

Or we could change the rules to increase the max characters per line limit. Or to allow more complexity in methods. Both would have to be discussed with the team.

Quickly removing the types TestRunAction to shorten the line and have the necessary space to fit # noqa: C901 there?

Great, making the code worse to game the linter.

We can take the above as an example why forcing formatting rules on a team doesn’t just magically achieve the same formatting everywhere. And why flake8 does not automatically improve code quality. It can simply be disabled as it was in the case above. As a result we get cryptic ignore statements throughout our code base that probably no one will ever fix.

So what you are saying is these tools don’t help us?

Yes. I believe so.

Although, f*ck, it depends.

If the team really cares we don’t need a linter. Errors would be caught by tests and formatting would be applied by the editor. Everyone would not want to have their code differ from what is already in the code base.

If the team does not care too deeply these tools only add additional friction. Leading to ignore statements throughout the code. Increased build time plus commits such as “satisfy linter”. And of course a team that hates the rules but does not want to bother with having a discussion about changing them.

Especially if there are folks on the team who peruse and try these rules with the same energy a kid would apply to the candy in a candy store. Have them all.

To add insult to injury - Both tools did not help us to avoid having both snake_case (the validation_action) and camelCase (the currentState).

Probably another rule available in the docs of flake8. Haha.

The year 2021 in books

Thu, 13 Jan 2022 11:11:11 +0000

Books read in 2021. Again almost zero commute. I was able to read 31 books.

As in 2020 I’ll rate the books from one to three stars. Three of three (3/3) stars being what I thoroughly have enjoyed and would recommend to others who are into the topic of the book or enjoy a good read in general. Giving a book one star neither states the book is bad or I do not agree with it, rather it is something I personally did not enjoy too much.

Die Nibelungen - Auguste Lechner - 1/3

Common tale in germany.

The New Right: A Journey to the Fringe of American Politics - Michael Malice - 2/3

An intro to the American New Right

Ask Your Developer - Jeff Lawson - 3/3

Written as a handbook for Project Managers or Product Owners. Talk to your developers about problems instead of solutions. Telling them what the goal is instead of telling them what to do.

Der Himmel kennt keine Günstlinge - Erich Maria Remarque 2/3

On racing and cherishing life with a carefree attitude.

Staff Engineer: Leadership Beyond the Management Track - Will Larson 2/3

How to stay an Individual Contributor in a software company instead of moving into management.

How to destroy a tech startup in three easy steps - Lawrence Krubner - 3/3

A funny and gripping read on some, questionably true, experiences of a developer in a tech startup. Went through it in one sitting.

Heat - Bill Buford - 2/3

The authors experiences working as a cook.

White Noise - Don Delillo - 1/3

A critique of modern society.

Jordan B. Peterson - Beyond Order - 2/3

A list of rules to live by.

Vladimir Nabokov - Pnin - 2/3

The first Nabokov book I’ve read. About a russian professor in america during the 1950s.

Franz Kafka - Die Verwandlung - 2/3

Quick read. A classic.

The Anarchist Handbook - Michael Malice - 3/3

A collection of anarchist essays.

Permutation City - Greg Egan - 3/3

What if we live forever? But on Amazon EC2 ;)

Fundamentals of Software Architecture: An Engineering Approach - Mark Richards, Neil Ford - 3/3

How to be an effective Software Architect.

An Elegant Puzzle: Systems of Engineering Management - Will Larson - 2/3

An approach to management in modern software companies.

A Gentle Introduction to Unqualified Reservations - Mencius Moldbug - 2/3

Introduction to the “Political Red Pill”.

Against the Grain: A Deep History of the Earliest States - 3/3

Without grain there would not be modern states. Grain is easiest to tax.

Bronze Age Mindset - Bronze Age Pervert - 3/3

Recommended by George Hotz on the Lex Fridman Podcast. Criticisms of Modern Society.

The Pussy - Delicious Taco - 1/3

A bunch of essays, or blog posts, on relationships with women. A book one gets recommended after reading Bronze Age Mindset.

Sun and Steel - Yukio Mishima - 1/3

The wikipedia article of Yukio Mishima can be read afterwards, not before.

Harassment Architecture - Mike Ma - 1/3

Another books revered in right wing circles.

Threat Modeling: Designing for Security - Adam Shostack - 2/3

Techniques to apply to your software and the surrounding infrastructure to find issues.

An Open Letter to Open-Minded Progressives - Mencius Moldbug - 2/3

By separating voters into two competing but cooperating parties, neither of which can destroy the other, the two-party system creates a government which will survive indefinitely, no matter how much happier its citizens might be without it.

Die Kadetten - Ernst von Salomon - 3/3

Experiences of the author in a German Kadettenanstalt during the days of the First World War.

The Outlaws - Ernst von Salomon - 3/3

Experiences of the author in the German Freikorps in the aftermath of the First World War and the Murder of Walther Rathenau.

Bauern, Bonzen und Bomben - Hans Fallada - 2/3

Story about the German Landvolkbewegung.

Faserland - Christian Kracht - 1/3

A quick read on the affluent part of my parents generation while in their late twenties/early thirties in Germany.

Industrial Society and Its Future - Theodore J. Kaczynski - 3/3

A critique of modern society written around 1995.

21 Lessons: What I’ve Learned from Falling Down the Bitcoin Rabbit Hole - Gigi - 3/3

Quick read and a great gift for “future bitcoiners”. People already in the rabbit hole won’t take too much out of it.

The End of All Evil - Jeremy Locke - 3/3

The state is “not just” inefficient. It is evil.

Demian: Die Geschichte von Emil Sinclairs Jugend - Hermann Hesse - 2/3

“Wer nicht in die Welt passt, der ist immer nahe daran, sich selber zu finden.”

Rough translation:

“He who doesn’t fit (into our world), is always close to finding himself”

Production data in test environments

Sat, 06 Nov 2021 06:30:22 +0000

The thoughtworks Technology Radar has added the technique Production data in test environments. It has the status “Hold”. Short for “Don’t do that”.

I was asked what my thoughts are.

It seems people having issues with the technique probably do use production data in test environments. Having worked on such systems, all the listed drawbacks are true. Some are more of an issue than others.

Protection of private data is important and of legal relevance. Sending incorrect alerts from test systems to real clients can happen on production too. There are measures to avoid this. Previews that show who, or even a number of how many, will get the message. Or sending it to an internal group first before sending it to everyone applicable for the notification.

Taking a step back.

Why do people put production data into test environments?

To fill the databases with more than only a few bytes?
To check if the queries are fast enough on larger datasets?
To check if our database migrations are successful on real data?
To actually display something in the app?
To reproduce bugs?
To make it look real for demoing purposes?

Valid reasons.

Before we discuss using bogus or obfuscated data as an alternative let’s take another step back.

Thinking from first principles - Why is there a test environment at all?

What if we were reproducing bugs in production?

What if we demo the production app instead of an app connected to a test environment?

What if we turn it around and add test data to our production environment?

A fake hotel that only testers can see and book, a fake car that only testers can see and buy, a fake article that only testers can read and share.

A new feature that only testers can see and use?

Using a simple A/B Test where one of the groups, or a third group, is developers, testers, other stakeholders, project managers or anyone else that is not the end user.

I always try to add this concept to products and projects I’m working on.

Examples

The roadtrips in the app below were not visible for everyone. They might just be there for testing. Instead of crossing the alps you can do a roadtrip from and to the office. Or check out how the content looks and feels before the customer sees it.

All in production.

Another example.

I do not drive the car below. Aside from the name the car might not even exist. Still it is mine in the production app. It is test data in production.

Do we now have the solution for the whole production data in test environments?

Guess not. It’s providing options.

Having production data in test environments is an option.

Having test data in production environments is an option.

On dedicated DevOps

Mon, 27 Sep 2021 09:22:13 +0000

Joining a new team I was able to hear the remarks on how we have no dedicated DevOps person who is taking care of the AWS infrastructure and all the Gitlab pipelines.

The conversation reminded me of an old tweet.

“Yeah, we’ve found this great person to do all the DevOps”
That isn’t DevOps
— Sam Newman (@samnewman) April 19, 2016

Okay… DevOps is also not a pipe

What then is DevOps?

Back then I took the tweet and in my head automatically translated it into

Every developer should be able to do operations work

It is the responsibility of the developers to take care of Ops

Meaning a specific train of thought is required to understand the tweet. It does not tell you how to do it. Only how not to do it.

Wikipedia on DevOps tells us

Most often, DevOps is characterized by key principles: shared ownership, workflow automation, and rapid feedback.

Yes, shared ownership. Of what though?

Hopefully development and operations.

There should be no dedicated DevOps person in the team. There should be no dedicated anything in the team. Dedicated anythings are always a bottleneck. Or poised to become a bottleneck in the future. Either by moving to other parts of the organisation, to other organisations, to other fields of interest, enjoying a holiday or anything else that makes them unavailable.

Of course we can have a person that carries DevOps knowledge into the teams. With the goal to enable the team to take care of the DevOps work themselves at one point. Teaching them to work with AWS or Gitlab pipelines if we take the example above.

Thus let’s not have a dedicated DevOps person in the team.

More on the topic is described in the article Cross functional teams

Structuring work for continuous integration

Tue, 07 Sep 2021 09:30:22 +0000

Consider our product has a bunch of included services. Warranty, insurance, additional drivers and more. The services are displayed in a grid. Our users might, or might not, know about them yet.

What do these included services mean exactly? All we get is an icon and a title?

Maybe the feedback made it clear people had further questions when looking at the services - Maybe adding additional context is a legal requirement.

We decide to add more context. One approach is the common “info” ( i ) icon or, in our case, the “Show details” (Details anzeigen) button.

The button on the bottom left leads to the detail view on the right.

All we need to do is to display some text in a view and implement a way to get there.

Not too hard.

The common approach developers take is

Create the button
Have the button open a modal (a sheet in iOS terminology) - Pressing Done (Fertig) closes the sheet - The view on the left is displayed again.
Layout the content of the sheet

This is fine. It gets the job done.

Can we improve upon it?

Yes.

Consider continuous integration. We merge to master as often as possible. Multiple times a day - even multiple times per hour.

Using the approach above we cannot merge to master directly after creating the button. Yes, technically we can, with the result of having a master state that cannot be released right now. Consider someone in the team finds a bug which needs a bugfix release ASAP. Only possible after we remove the added button. The button without functionality.

If a user discovers the button he will press it and nothing would happen. Step 2 (opening the sheet) is not yet implemented.

Even if it was, without Step 3 (layout the sheet) the user would see a blank page.

What if we were to change the order of the steps in our approach?

We start with the content of the sheet. No need to commit to the sheet element yet. Maybe the designers will show up a few minutes later with the decision to have the view use the full screen?

If we layout the content first we are able to merge. Due to SwiftUI we also do not need to have a button to allow us to see our view. That is what previews are for.

The current state is mergeable to master. Even if there is some pending release it would not matter. After all, the view does not have an entry point yet. We did not implement the button. No user will be able to see the view. We can collect feedback from other developers or designers on the contents of the sheet without the necessity to think on how the user gets there.

As a result the approach changes to

Layout the content of the sheet
Create the button
Have the button open the sheet

We have split a single unit of work, which has to be merged as one, into two units of work, mergeable one by one.

Is the change in question too trivial to warrant a change of our “usual” order? The statement “We can do this in an hour” comes to mind. Fair enough.

Consider we had to implement some logic that fetched the content of the sheet from a server. Suddenly we have to deal with http requests, API design, possible errors due to being offline or an unreachable server.

What if, due to the possibility of collecting feedback earlier, we had to change the design of the sheet multiple times?

A feature once considered trivial before is not trivial anymore.

On having a favorite programming language

Sun, 29 Aug 2021 09:30:22 +0000

Sometimes I get asked “What is your favorite programming language?”, “What programming language would you use when starting to learn programming?”, “What do you think of programming language $X?”, “What programming languages do you use?”.

Let me elaborate.

Back in school we got taught Delphi. Don’t remember much about it. The programming was done through some kind of interface builder. In university I got to do Prolog and Java.

Back then one was able to use Java a lot because Android was quite new. Android apps were - and still can be - written in Java.

Later, after reading suggestions on prominent YouTube lectures, I was able to play with Scheme. Python was added when a course on using MongoDB was relying on it. The course made use of the bottle framework. Python was also the first language where I wrote tests. Later Python was used throughout the “Programming Bitcoin” book by Jimmy Song using jupyter notebooks. Due to working with AngularJS and Backbone.js at my first job I was able to pick up some JavaScript. JavaScript stuck with me and it is what I use today if I need to create a quick scripts using Node.js. By getting into Angular, often called Angular2 at my second job I was able to work with TypeScript.

By following the Ethereum ecosystem for a while I got to do some programming with Solidity. The default smart contract programming language back then.

After spending way too much time on hackernews, and seeing again and again how every programmer should know Assembly and C I went through a PDF for Assembly and the beginning of Learn C the Hard Way. Back then the book was free and not yet finished.

After functional programming started to become all the rage I got my feet wet in Clojure by spending some time with the book Clojure for the Brave and True. Later Haskell by working through half of the haskell book.

By following the TDD and Clean Code community I was able to see a lot of Ruby in presentations and code snippets. Ruby was later revisted by working through Programming Languages Part A, Part B and Part C by Dan Grossman on coursera. The course also made you wirte code in ML and Racket.

In 2018 I had the fortune to introduce Kotlin into a, until then, pure Java codebase. Instead of resistance the change was welcomed with open arms by fellow developers. Both the possibility to learn something new, and to be paid for it, plus the ability to write, or to be honest generate, less boilerplate.

Kotlin is what I use to this day in most backend related work.

As Rust became popular, it was supposed to be the new C, I did spend some time with the book The Rust Programming Language.

While getting into iOS development I was able to quickly pick up Swift and SwiftUI.

Once I read the statement you are only able to state you know a certain programming language if you are able to write Fizz buzz in it. A low bar. It will only prove you remember the basic syntax. I would be able to write Fizz buzz in Java, Kotlin, JavaScript, Swift and Python. Mainly because I used all of them recently. For all the others I would have to brush up my knowledge for a few minutes.

How do you learn a programming language then? You don’t need to know generics to write a simple Java command line application. You don’t need to know the difference between class and struct before writing an iOS app in Swift. It will become apparent at one point in your journey. Right when you need it.

Neither do you need to read a book on the programming language. Is reading the book helpful? Sure, you might pick up a few tricks while reading it and remember parts of the codebase you can apply it to. Is it required? No.

In my day to day work I sometimes get the question during pairing “Would this syntax work here?”. Even when you know the answer (Yes/No) the better answer is “Let’s write a test and see”. The moment you have a test we can play around with the implementation details, learn what works and iteratively improve it if necessary.

So what is my favorite programming language?

I don’t have one. Saves me quite some time when discussing what to use for a new project. What I care more about is the tooling around the language. I enjoy working more with Kotlin than with Swift because I consider IntelliJ to be superior to Xcode. But then, Xcode might be a lot easier than setting up your Haskell tooling. (To be fair it has been a while I have looked into Haskell tooling). Do I thus like Kotlin more than Swift because I enjoy working with it more? Fair enough. I guess the answer is a Yes. For now.

What program language would you use when starting out to learn programming?

Depends on what you would want to do. The easiest might be where you have all the required tools, a browser, already installed. Thus JavaScript. Then again you are trying to solve a problem. It doesn’t really matter in the beginning. Use what your friends use, use what the guy on YouTube uses or use what your colleagues use.

In the end it is all if, else, loops and pattern matching for the functionally inclined.

I reject the notion of “Do $X to become a better programmer”. To become a better programmer you program. You program to solve problems. Even if the problem is not having anything better to do on a lazy sunday afternoon.