tfnico's blog

TL;DR I (or AI) made a thing: mlr-desktop is a GUI for the awesome tool Miller (mlr) Miller is like awk, sed, cut, join, and sort for name-indexed data such as CSV, TSV, and tabular JSON And it was completely done by an AI agent (vibe coding). Read on for more details, or download the latest release and try it out (available for Mac, Windows and Linux). Background One thing we do at snabble is importing large amounts of retail product data from our customers. Think product names and prices.  Ideally, we receive data in the form of JSON, but often we get data from legacy systems that only support CSV export (or worse: some other proprietary text format). Here's a trivial example of some well-formed CSV: SKU,Product Name,Price,Barcode FRO-010,Organic Free-Range Eggs (Dozen),5.99,5012345678901 PNC-025,Fresh Baked Sourdough Loaf,4.25,5023456789012 DRY-050,Basmati Rice (5kg),12.50,5034567890123 PRO-005,Roma Tomatoes (Per Lb),2.99,5045678901234 CNS-012,Black Beans (Canned),0.89,5056789...

Thirteen blog posts later, this one notes my departure from eyeo after 4 years and 3 months. I joined eyeo around the headcount of 80 employees, and now I think there's just over 250 people there. My role coming in was as operations manager, doing a mix of infrastructure engineering and technical project management. I later on took on organizational development to help the company deal with its growing pains . We introduced cross-functional teams, departments (kind of like guilds), new leadership structures, goal-setting frameworks, onboarding processes and career frameworks.  And all of this in a rapidly growing distributed company. I'm proud and happy that for a long time I knew every employee by name and got to meet every single new-hire through training them on company structure and processes.  At some point, we had enough experienced leaders and organizational developers that I could zoom back in on working in one team, consulting them on  Git and continuous integ...

At work, we maintain patches for some pretty large open source repositories that regularly release new versions, forcing us to update our patches to match. So far, we've been using basic Git operations to transplant our modifications from one major version of the upstream to the next. Every time we make such a transplant, we simply squash together the modifications we made in the previous version, and land it as one big commit into the next version. Those who are used to very stringent keeping of Git history may wrinkle their nose at this, but it is a pragmatic choice. Maintaining modifications on top of the rapidly changing upstream is a lot of work, and so far we haven't had the opportunity to figure out a more clever way to do it. Nor have we really suffered any consequences of not having an easy to read history of our modifications - it's a relatively small amount of patches, after all. With a recent boost in team size, we may have that opportunity. Also the need for be...

Over the last year, I've been increasingly doing a lot of blogging the intranet at work. As a consequence of this, I think I've felt less urge for blogging out here. The same way an open source developer builds a public profile by having their product shared in the open, I think it makes sense for people who don't work on code to do the same in the form of blogging, vlogging, tweeting or writing posts on Twitter/Facebook. Unfortunately, the content I write on the intranet is very specific to that culture. So it wouldn't be right to copy it in here. What I can do is to iterate some of the topics just quickly in this post, and then think about what topics are worth writing more about here. Your feedback is appreciated! Write a comment below or tweet me if you want to direct my writing in a particular direction. What do I do anyway For context, the last years my role has evolved quite a bit. I have a tricky profile to pin down into a role: I've drifted from s...

This is a post going into the usefulness of live voice-chat tools in distributed teams. If you've ever seen the Leeeeeroooooyy Jeeeenkiiins video of World of Warcraft fame, you've heard this kind of tool in action. It's how the participants in the video are speaking with each other - this is not a feature built into the World of Warcraft game - it's a separate team-oriented VoIP software, and it's all about letting gamers communicate orally while gaming.  Since these tools are for gamers, they have to be fast (low latency) light (as not to steal CPU-cycles from heavy games graphics)  moderate in bandwidth usage (as not to affect the game server connection) There are several options around: TeamSpeak , Ventrilo , more recently the massively grown Discord , and finally Mumble , which is the open-source alternative of the gang. A few years ago, when I joined eyeo (a distributed company), several of the operations team were avid gamers, and had a TeamSp...

Last year, I came across an awesome free resource for learning mediation and as part of that, empathic listening. As I blogged about at the time , Gregorio Billikopf 's audio seminar "Listening First Aid: An Empathic Approach" provided me some very useful knowledge, not only for conflict mediation, but for every day life: Listening is obviously a huge part of how we operate socially, and becoming better at it is something that not many think about, although it is sorely needed for many. "Engaging Conversation" by Michael Coghlan licensed CC BY-SA 2.0 Naturally, I was keen on letting others in on Gregorio's resources, but the website where the audio seminar is hosted only offers a single zip file download containing the mp3 files, and a slow download at that. In this day and age where everything can be but a click away for attention, I figured it would be worthwhile making this content more accessible. I sent Gregorio an email to ask if he was in...

Recently, I signed up for doing an internal talk about roadmaps, and what they are generally all about. I figured this post would be a good start to get myself into crystallizing the message up front. Keeping in mind, roadmaps are but one component in an extremely complex domain involving many sciences, so this is one of those scratching-the-surface-posts. Who's saying what out there Before we start inventing our own wheels, it's nice to review what is the state of roadmaps out there. Perhaps there is some "industry best practice" ;) So I'll begin by collecting information from the first, best sources I know about. I happen to follow a couple of product management authorities on Twitter: Melissa Perri and John Cutler . Then recently, our internal head of product recently pointed out Roman Pichler . Finally, there's the venerable Marty Cagan who I reckoned has written a thing or two about roadmaps, and that was indeed the case. Note that each of ...

This is another follow-up post on my first year at eyeo . In a company where the norm was to shun any hype, and avoiding cargo-culting by all means, it was not easy to use the language I had come to learn in the industry. Mentioning "Agile" would derail any discussion into shoot-downs, anecdotes and personal opinions and experiences. Few of the agile values, principles or practices were taken at face value. The more experienced colleagues had bad experiences with "agile transformations", and the large majority of younger colleagues had not recognized the pains of silofication , nor experienced the joy of successful organizational change. As is the norm these days, "DevOps" has already been reduced to infrastructure engineering. Scrum was a fad, XP forgotten, Kanban was a board on the wall. Sprints were pointless, we'd rather ship when there's a big enough reason to ship. Conway's and Little's laws were unknown, as were Lean, theory of c...

I recently   posted   this sketch on Twitter: Thanks to a few mighty retweets, it gathered a lot of views (9000 impressions, whatever that means). While that's fun and all, I still felt a bit sad that such an awfully simple insight can garner much more popularity than a thorough blog post that I put some hours into. So, rather than let Twitter get away with this, I'll steal my own content back into the blog :) The thread went like this: Pondering how to battle individualism in companies. For some, it is counter-intuitive that teams can be more responsive, faster and even more accountable than single individuals. Having "teams" in place is no guarantee that team work is happening. Be wary of too large teams, "I/me/mine", personal contact details instead of team point of contact. Good team is sailing crew, not galley slaves. Beware heroes, go-to persons, calling in favors and other shadow handling of work. Real teams make the work explici...

Back at uni, we had a semester about IT project management , and one of the highlights was this two-day off-site where we went to a camp and did team-building kind of exercises to explore social dynamics and stuff. One exercise was called "Saboteur". In short, the mission was for the teams to recreate a complicated building block construction set in a different room. The constraint was that each team could only dispatch one person at a certain interval to study the original construction. The goal was to get to the identical structure first. Additionally, each team was "infiltrated" with an unknown amount of saboteurs, tasked with slowing down their teams without revealing their purpose. To counter for this, our team decided to use double-checking observation roundtrips to weed out the saboteur(s). The team members that were found to have provided wrong observations were excluded from making any more observation roundtrips. I remember this girl in particular th...

I recently found myself mediating a personal conflict within a team. In this post, I'll share what I quickly had to pick up and learn in order to do so. Disclaimer: I am not a trained professional in conflict handling. If you find yourself in a similar situation, get professional help from a trained mediator and do not try to do anything without the backing of the supervisor(s) of everyone involved! Spotting the conflict I try to keep some tap on the conversations that are happening around the company, and in particular I try sensing conflicts. In this case, I spotted what at first looked like a regular somewhat heated exchange in a distributed team, and then as the discussion continued, the participants started to pull for executives to come in and break the argument in their favor. The topic under discussion was definitely a team-internal thing, so my alarm bell started chiming. This didn't feel like a regular technical discussion. It had an air of threat and desperation...

I'm just about ship GitMinutes episode 46, which is going to be the final episode. I'll just paste the outro script here, as it sums up the sentimental thoughts pretty well: I’m happy to have finally finished [publishing the last episodes from Git-Merge 2017], just in time before Git-Merge 2018 takes place in March. I won’t be going there myself, so I’m counting on someone else to pick up the mic there. It’s sad to be shipping this one as it is probably the last GitMinutes episode ever. To go a bit down memory lane, 6 years ago, my daughter was born, and as I used a little of that paternity leave to set up my podcasting infrastructure and produce the first few episodes. Initially it was just going to be 10 episodes and call the experiment finished. Instead, I got to 46 episodes, the last dozen or so lazily tailing the last few Git-Merge conferences. To every one of my guests, thank you so much again for coming on to share your passion in this little niche of computer s...

Note: This topic of this post was heavily inspired by The Phoenix Project and the succeeding tome of reference, The DevOps Handbook . There are many metrics out there that can guide you to improve your business, but in the upside-down world of Internet business, many of these can be plain wrong, or at least they do not serve well as guides for what you should be doing. If you measure success by measuring profit, for instance, you'll run out of good will with your users or partners very quickly. Then there are a load of more noble but fuzzy numbers that you can measure by surveying employees or users. Think employee-happiness, etc. While these are definitely useful, they are easy to get wrong, and it's easy to over-do it, causing survey fatigue. They're also hard to trace from cause to effect. It's hard to say which particular company decision lead to some satisfaction rating going down. Take the SWOT analysis  as a particular one of these surveys. It will give yo...

In my previous post , I suggested several topics to blog about, based on my experiences of 2017. How Silos Grow was the topic most asked for: This was my initial shock after joining the company. Only a few years after taking off as a startup, the hedges began growing, seemingly almost by themselves, and against the will of the founders. I've worked in silos, and in companies without them, but I haven't been there to witness them coming into existence before. It is a fascinating phenomenon, yet oh, so common. And a killer of great companies. This posts digs into why and how silos happen. It's a bit of a long one, so here's the TL;DR: It is about human nature. Departments are a good thing (for some things). People in different departments are inherently different. The project method is still problematic (and reinforces the silos). Cross-departmental teams should be the first-class organizational unit instead. Although the idea to write this came from my fir...