Today I stumbled over this article which makes a few excellent points about how fast (in terms of lines per person per hour) a developer usually is. I like that idea a lot, even though I would never try and use it to actually assess the speed of a developer. The underlying metric takes into account lines added and lines deleted as well, so measuring on lines added only would be meaningless.

Here are a few tools which can make your life easier on linux:

• bat is a drop-in replacement for cat, it displays line numbers, syntax highlighting and more.
• exa is a replacement for ls. Powerful features include a tree view and git information.
• oh my zsh is a great ZSH configuration with many very useful features.
• SpaceVim is a modern vim distribution. It comes with many great defaults.

On the difference between a maker’s and a manager’s schedule.

When you’re operating on the maker’s schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in. Plus you have to remember to go to the meeting. That’s no problem for someone on the manager’s schedule. There’s always something coming on the next hour; the only question is what. But when someone on the maker’s schedule has a meeting, they have to think about it.

This is why I usually recommend having meetings with developers next to the lunch break, shortly after work start or before the end of the work day. YMMV though, as different people prefer different times.

Many people I know have observed the following effect: people are going through the motions of Agile, they do everything “by the book”, yet they are struggeling. Or, they are doing the same work as before without any change other than renaming their meetings to use agile vocabulary, and call themselves agile. Or, my personal favorite, working in a chaotic and unpredictable way and justifying it with the word “agile”

I recently discovered that there is a word for it, and it has been around since 2016: Dark Scrum, or, more generally, “Dark Agile”!

Software Architecture is overrated, clear and simple design is underrated. This article resonates with me because I have worked with multiple teams before, with different emphasis on architecture, and I - from my anecdotal experience at least - do not think that investing more in upfront architecture is really making the software better in the long run. If you are factoring in the time to refactor as you go, and are working with skilled engineers, minimizing the upfront architecture work and focussing on clear and simple design is the key.

Awesome visualization of the most popular programming languages on StackOverflow since 2008. Call me a nerd, but I really like this kind of video.