profile

Hello, I'm Wojciech 👋

and that's my daily list

Subscribe to read my programming experiences, ideas, mistakes and tips I wish I'd known myself earlier. Learn how to enable high-performing teams, make an impact, grow as a software engineer and level up your career.

But, seriously, what did they do?

We mentioned last time the 80% layoffs at Twitter and the main question still remains: what did all those people actually do? A lot of meta-work. That's the work that you need to do in order to get "real" work done. (Of course, it wasn't literally 80% of the people doing meta-work 100% of the time, but probably more like 100% of people spending 80% of their time on meta-work.) For example, if you're on a team that handles tweet replies and you want to make a change that hides the replies from...
1 day ago • 1 min read

What did 80% of the programmers do at Twitter?

When Elon Musk took over Twitter he reportedly fired 80% of the staff over a few months, including more than half of the programmers. Many people claimed that the platform will inevitably go down in weeks, if not days. It’s just impossible to judge whose role is essential with such huge layoffs. While, of course, there was a lot of quirks in the “transition period”, with time we see that Elon Musk was right. Not in the “did the right thing” sense, but right that the platform can keep...
2 days ago • 1 min read

Mocking in E2E is fine

The term end-to-end tests is misleading, because the same way the horizon changes when you change you point of view, the “ends” also change when you have a different perspective. I once wrote: Let’s take a look at an imaginary ecommerce app. For a developer from a checkout team E2E test would probably mean: user picks some items, proceeds to checkout, fills in all their details, pays, order is created. But for an actual user, the “end-to-end” means: they were able to find a product that they...
2 months ago • 1 min read

Know your boss

When you're starting a new job, new project, or joining a new team - always make sure you know who your boss is. You need a single source of truth for any doubts. If you have more than one boss, don't trust any of them. Even if they mean well, they won't ever have the full picture. Double-check everything. Have a good one, Wojciech PS. I have lovingly crafted this email using only the best artisanal keystrokes. If you find come across any typos, feel free to fix them yourself and enjoy this...
2 months ago • 1 min read

Senior developers don't drop things

There’s a phrase a friend of mine shared a few months ago that has been coming back to me over and over: “Senior developers don’t drop things”. There’s a few ways you can understand that, all of them useful: * If you say you’ll do something - do it, delegate it, or write down the details to do it later. * Recognise what’s important and make sure it’s done. * Own your tasks. Even if you need assistance from other people to get the necessary information, even when you delegated it, even when...
2 months ago • 1 min read

Who's an A-player?

In a recent post I mentioned teams of A-players being able to work faster, more agile, and more independent. Of course, those are desired qualities for the team that you’re working on - who wouldn’t want that for themselves? So, a question arises - what does it mean to be an A-player? Obvious answer: it depends. Everybody has their own set of skills that they’re looking for and you can’t be an A-player to everyone. Useful answer: think of what kind of team you’d like to be on and strive to be...
2 months ago • 1 min read

Onwards to Programmer Anarchy

After reading my last post, you might have thought “I’m working on a team of A-players that are free to do their best work, what do I pick instead of Scrum?”. My first answer would be - do Scrum anyway. That seems contradictory, but I’m a big believer in “slow is fast” (“If you need to go fast, go slow. Because slow is smooth and smooth is fast”). It’s very easy to trip and fall on your face when you start running out of a sudden, while it’s much safer to pick up the speed gradually. So, if...
2 months ago • 1 min read

When is Scrum a good choice

So, we’ve discussed lately what are Scrum’s tradeoffs, now it’s time to weigh them and decide whether it’s a good fit for your team or not. The guideline is misleadingly simple: if you’re faster with Scrum - go for it, if you’re slower - ditch it. But what does it mean “faster”? Well, as Marty Cagan says, we should look beyond Time to Market - the metric when your feature gets deployed in front of your users, but rather focus on Time to Money - metric which means that you delivered something...
2 months ago • 1 min read

Scrum - the slow parts

In the last email we talked about the (possible?) benefits of Scrum for the development team. Today, let’s get clear about the costs. There’s the context switch cost of having meetings in general and Scrum is widely known (hated?) for being meeting rich. While most of them are like any other longer meeting you might have, the worst offender is probably the daily standup with some common anti-patterns. Sometimes it’s done with a team that’s too big and everybody just waits for their turn to...
2 months ago • 1 min read

Scrum - the good parts

Today, let’s dive into the good parts of a Scrum process. I’m taking a limited perspective of the software development team here. There are many reasons organisations choose Scrum that are not listed here. However, those benefits would apply to different parts of the organisation and it’s up to different teams to analyse them. Scrum basically awards a protection for the team, allowing them to stop chasing moving targets. Starting with the idea of a sprint, where the team takes a chunk of work...
2 months ago • 2 min read

Subscribe to read my programming experiences, ideas, mistakes and tips I wish I'd known myself earlier. Learn how to enable high-performing teams, make an impact, grow as a software engineer and level up your career.

Share this page