Don’t Mock Me: Everything We “Know” About Unit Testing is Wrong

One Hour is Too Long (Or Is It?)

A while ago, a software engineer I know asked for my opinion on his startup’s CI. Their End-to-End (E2E) suite took about an hour to run, and the team was agonizing over whether to move it from every PR (presubmit) to a nightly job because it felt “too slow.”

An hour? One, single, hour? For an E2E test suite? My answer: Don’t touch it. In a startup, there are a million things with higher ROI than shaving minutes off an hour-long E2E suite, especially if your unit test coverage isn’t optimal yet. And certainly do not switch to running it nightly. Getting coverage that late will grind your development cycle to a halt, discovering bugs which may have been introduced by any PR in the past 24 hours(!!!).

When I posted about this on Twitter the pushback exposed an interesting aspect of software engineering culture: Many engineers felt that an hour-long CI was torture. They were waiting for the green checkmark before moving to the next task. Some even waited for the code to hit production before starting something new.

To me, this pointed at a deeper problem: it wasn’t actually about the time the CI took. It was about trust. The CI was failing late, the tests were flaky, and the developer workflow was strictly synchronous.

Since then, using AI agents to write code and execute tests asynchronously have become a widespread practice in software engineering, so perhaps engineers have gotten used to working asynchronously – but not necessarily in a good way.

Continue reading

My favorite… things

A sporadically updated list of reading and viewing recommendations so I have something to link to:
(These are not affiliate links, but maybe they should be?)

Technical

Coding principles and other programming basics:

Career

Basics for any leader

People Stuff

Productivity

Other Interests

Articles

Books


Something nice for the preview when I share this

Going places: How to manage your career

After my last post on how I got my career back on track I was flooded with (at least 3) requests to share my advice on what I did to “level up” my work so other people could get ahead the same way.

The easy answer here would be “I can’t say”. Each person, each manager, each organization, each situation is unique and who am I anyway to be giving advice on things I’m still figuring out myself. That said, my “obvious” might be someone else’s “mind blown”, so here goes.

Photo by Nathan Jennings on Unsplash
Continue reading

Declutter python code with error handling decorators

Image by Andreas Lischka from Pixabay

I recently reviewed some code which converted gRPC error codes into custom errors using a decorator and the simplicity and genius of it made me facepalm “why didn’t I think of it myself?”.

Really, why didn’t I? When I wrote how to handle errors with grace I mentioned using decorators to validate input parameters and how important it was to keep error handling separate from your main code as much as possible. I just didn’t think to combine the two. Oh well, better late than never.

Continue reading

How to Design a Permissions Framework

I usually start my posts with some personal anecdote explaining the background for what I’m writing and how I came up with the idea. I could probably do the same for this one, but the truth is that I’m writing it because I ❤️ permissions. I don’t exactly know why they hold such magic for me, but it is what it is, I get excited about permissions. User roles, checking who’s allowed to do what and when, and making sure it all works together is just the best kind of fun!

Photo by Hello I’m Nik on Unsplash

You might not share my excitement, and that’s OK, I guess, but permissions are one of the basic building blocks of almost any application. The permissions framework I’ll present here can start simple and evolve as you go, so you can be sure you are gonna need it and it’s definitely worth the small effort of setting it up from the get-go.

Continue reading

Once more, with feeling: A radical approach to code review

I was lucky to be in Dropbox’s headquarters when Kim Scott came to speak about her (then) new book “Radical Candor”. Dropbox was nice enough to hand out free copies (yay! free books!) so I actually ended up reading most of the book on the flight home.

Even though the book was written with managers in mind, I found myself referring back to it pretty often. Its insights proved quite useful in my daily work as a software engineer, especially in processes which require written or in person interaction with our co-workers. A little bit of Radical Candor can totally change how we do and react to code or design reviews, driving better results and higher satisfaction.

Radical Candor: Some Background

Before I share how you should use Radical Candor while creating software, it might be helpful to explain what Radical Candor is. I will try to keep this section as short as possible, since it’s just setting up the background for how to use Radical Candor in the context of software processes. If you’re already familiar with the framework you can just skip to the next section (titled Radical Code Review).

I have good reason for creating my own version of this, as you will see below.

Radical Candor is about giving guidance that’s kind and clear, specific and sincere

(source here).
Continue reading

Better software design with mind maps

Have you ever tried to design a complicated bit of software and ended up with a great big tangled mess? Designing software is hard and formal processes can be frustrating. Is there a better way to approach this task? Mind maps are a fun and intuitive way to brainstorm and organize your ideas on paper or a whiteboard. In this talk I show how to use mind maps to design software well, convert your thought process into an excellent technical spec, and break it down into workable tasks while leaving lots of room for agility and flexibility.

English, from Wix Engineering Tech Talks
Hebrew, from Reversim summit 2019

Silly Baboons, Stubborn Elephants: A Product Engineer’s Guide to Working with Platform Engineers

A while ago I was telling a friend how I was frustrated at work. I had been adding support for a really important product feature, and our platform teams were making it impossibly difficult. It felt like every line of code required a month of negotiations to get approved. Let’s be honest here — I wasn’t telling, I was complaining. “Do they think we’re idiots?!”, I asked.

She was smiling with what I thought was empathy, until I was done and she said: “You are idiots”. Then she proceeded to explain that from her experience as a platform engineering manager, product engineers and platform teams live in a parallel universe. Finding common ground is quite a challenge. I believe at one point she used the words “silly baboons” (which gave this post its title).

No newfangled live action for me, thank you very much
Continue reading

How to hire the right way: An engineer’s perspective on tech recruiting

I’m an engineer, but I also have an MBA and for this post I’ll be wearing that hat. I was seriously considering buying an actual hat with “MBA” printed on it, but some good people talked me out of it, so unfortunately it’s a metaphorical hat instead of a real one.

I often see engineers complain about recruitment processes: They are long, they seem totally irrelevant to the job, everything is stupid. We just don’t get it. Unfortunately, we’re probably right — some employers don’t have any idea what they’re doing, but does it really have to be that way?

One of the very best courses I took during my MBA was a course about recruitment processes and the research behind them. It left a lasting impression on me and affected my perspective on recruitment processes when I was hiring and as a candidate. When I hear these rants, I often try to explain the rational behind a good hiring process, and I think this is insight which can be useful for engineers and recruiters, which is why I’m writing this post.

Continue reading