Friday, January 31, 2020

Friday Links

Zappos has quietly backed away from holacracy


Use Emacs to get social and track your todo list

How we retired Python 2 and improved developer happiness 

Why the Guardian will no longer accept fossil fuel advertising

Ring Doorbell App Packed with Third-Party Trackers

Terraform at Flexport

New Enterprise IT Controls for Data Studio

Google Receives Geofence Warrants

How to Perform Concurrent HTTP Requests in Ruby and Rails

Introducing Buffer’s Family Support Fund

Confessions of a Recovering Proprietary Programmer, Part XVII

Do more with Data Studio Community Visualizations

Preserving open source software for future generations


#74 Jeff Hunter: Embracing Confusion

S2 Ep.2: How do you balance investment in tech debt vs customer value?

Bicycle - Pessimists Archive Podcast

The Walkman - Pessimists Archive Podcast

#68 - Will MacAskill on the paralysis argument, whether we're at the hinge of history, & his new priorities

Tuesday, January 28, 2020

Saying goodbye to some legacy code

When I joined Devex a bit more than six years ago most of the code base was in one large monolith. This monolith was based on Ruby On Rails and was responsible for delivering

This part was called "neo". I guess because it was a rewrite of a previous Java
version. I am not sure if it was a reference to Matrix or the Greek meaning. 

There were already some initiatives in place rewriting parts of it in different services, but the monolith was always looming in the background.
Any changes to it required increasing amount of work. It was like someone tried to put the definition of technical code into code.

I generally against rewrites, they tend to last for years and you loose a lot of knowledge that is baked into the original. I also have nothing against Monoliths. So I tried refreshing the code base by upgrading the dependencies, getting the few tests to run and making local development easier with Vagrant. I realized fairly early that this was not going to work.

So we went with a gradual rewrite. Whenever we worked on part of the site we migrated it to our new architecture (Also a Monolith or at least a Duolith).

Now six years later we finally switched off the remainders of "neo" and I thought we should celebrate in style.

Legacy code is after all something that successfully supported you for a long time and enabled you to start with something fresh. Devex wouldn't be were we are without "neo".
Cremation - ignore the dog

So we staged a proper funeral, where everybody who wanted said some words. We also collected printouts of the most annoying bits of code, some very dated looking screenshots and some email and chat conversations from the very beginning.

This was my eulogy:
Today we say goodbye to maybe the best known system at Devex.+
Neo - from Greek meaning young or new, which he was neither.
Or from the Matrix character, handsome, powerful and agile, which he was also not.

We all have memories of him that will stay with us for a long time.
We laughed about his quirks.
He had amazing depths, which brought us sometimes close to tears trying to understand him.

His heritage will live forever in our data structures.
Finally we burned the printouts, collected them in an urn (aka hummus glass) and cheered with Cava while chatting about the "good" old days.

I hope you can give your legacy code also the sendoff they deserve.

The End

Update (March 2020)

We got a present from our CEO while he was visiting the Barcelona Devex office this week....

RIP Neo Mug

Friday, January 24, 2020

Friday Links

How we built the good first issues feature

Which of these 2020 Democrats agrees with you most?

KubeInvaders - Gamified Chaos Engineering Tool for Kubernetes

Linkedin: Global Talent Trends

Uber Has Been Quietly Assembling One of the Most Impressive Open Source Deep Learning Stacks in the Market

Critical Windows Vulnerability Discovered by NSA

How to build your company's engineering brand. 

Vancouver, Tall Buildings and Brent Toderian - The Life-Sized City Urbanism Podcast

The People's Pyramid

Webflow Engineering with Bryant Chou 

Friday, January 17, 2020

Friday Links

How Slack is Silently Killing Your Productivity


Enroll in the new Advanced Protection Program in an instant

Portfolio for Jira 3.0 and beyond

“Up and to the right” with Data Studio

Pros and Cons of Using structure.sql in Your Ruby on Rails Application

My polyglot Advent of Code

Engineering management: An Interview with Michael Lopp

Why Cassettes Are The New 45s

Floppy Sleeves

Google to phase out user-agent strings in Chrome

Accelerating netfilter with hardware offload, part 1

Radical Candor: Software Edition

Goodbye, Clean Code

Google’s Hash Code competition is back

More great memos.

Git v2.25.0

Facebook releases improved Displacement Maps for crisis response

5 Work Culture Trends We’re Looking Out For in 2020

Work Is Work

Your first 90 days as CTO or VP Engineering.

I went to see a movie, and instead I saw the future

The End of Indie Web Browsers: You Can (Not) Compete

AWS S3: You’re out of order.

PostgreSQL Connection Pooling: Part 2 – PgBouncer

The last tracker was just removed from

What I learned going from prison to Python

It's 2020, and browsers can do amazing stuff.


Slack Data Platform with Josh Wills

Friday, January 10, 2020

Friday Links (Post holidays podcast edition)

BeOS: The Alternate Universe’s Mac OS X

Outcome Over Output: Also Impact and Effort

DoD Enterprise DevSecOps Initiative(Software Factory)

Why I’m putting Bra Theory on an indefinite hiatus

Twitter is probably not the right medium for explaining the intricacies of analyzing and refactoring crusty old FORTRAN.

The C64 review – a captivatingly precise replica of the joys of 80s gaming

Making faster: Code size and execution optimizations (Part 4)


Alex Talks to Cycling Whistleblower Jonathan Vaughters

Bill Gates — The biggest success story you haven't heard

Living with Star Wars

freeCodeCamp with Quincy Larson

Best of: Master the Art of Staying in

Alex Talks to Dayton Mayor Nan Whaley

Bruce Schneier: How insecure, unregulated tech is endangering the world

Kubernetes Progress with Kelsey Hightower

Amazon Kubernetes with Abby Fuller

RadioLab: 60 Words

Tuesday, January 07, 2020

Book Review: The Phoenix Project and The Unicorn Project

The Phoenix Project

Someone recommended this to me and I got it for free on Kindle, so I thought I give it a go.

I kind of like the concept of a novelized version of a DevOps book.

I also liked the main characters and the general setup. It seemed a bit weird that a lot of best practices are completely unknown in the fictional company, but I guess this might also exist in the real world.

For most of the book I was question myself why I would even read it, it is close enough to what I had to deal with in some of my jobs and I don't really find my life exciting enough to be made into a book.

One of the problems I see is how rapid change is shown in the book. A very large company is turned around in less than a year and this is even managed in spite of the awful internal company politics.

The Unicorn Project

After reading The Phoenix Project I thought I give this one a try to see the other side of the fictional company. 

The Unicorn Project is the developers view of The Phoenix Project, the timelines overlap and some characters are also shared.

That being said, I found the main character of this book super annoying. Apparently she is "really, really good" and keeps repeating this a few times. There is even half a chapter, which just describes how "really, really good" she is. Getting through the book with her as the central character was painful.

As the first book, this one is also a long list of best practices put into a story. In this book it is put to the extreme though. And there is no reality where all of these could be applied in the short time-frame of the book.

If you are interested into a novelization of a developers life I would suggest to just read The Phoenix Project and skip this one.

On Goodreads