There are many virtues a team can show. But I’ve come to realize that it boils down to this:

Photo by Markus Spiske on Unsplash

If I wanted a team to be better, I’d ask them to be predictable.

“What does ‘predictable’ even mean, Adri?” you might ask.

I’m not a dictionary, but I’ll try to answer.

I understand predictability as “the ability to produce a stable flow of value per unit of time by spending a similar amount of resources”.

To do so, a team needs to keep costs stable. You know what I’m talking about. Development costs, infrastructure costs, maintenance costs, opportunity costs…

Keeping them at bay is not free, though. Our software and infrastructure degrades over time (yeah, folks, I’m talking about…

I’ve been told I was going slow in every project I ever participated in.

Photo by Nick Abrams on Unsplash

Every. Single. One.

You end up developing a hard skin on the subject. It is not easy, though. It requires time and strong convictions.

The truth is, “slow” is a big word.

It is also a facade.

You say slow

But this is all I hear:

“We’re fighting against unrealistic expectations ( and you told your boss about them, so now we’re both fucked)”.

“We’re measuring outputs over outcomes “.

“We’re doing too much at once”.

“We’re trying to please everyone at once”.

“We’re overloaded with reworks”.

“We’re waiting for handoffs”.

“We’re switching context too often”.

“We have a poor infrastructure to develop…

Why would anyone give money to me to type weird stuff on a computer?

Photo by Victoria Heath on Unsplash

Why would anyone do it? I mean, let’s face it. We, programmers, are picky. We want to work on what we please. We want to go to expensive conferences. We feel entitled to call the shots.

I guess one of the reasons is that we produce software — eventually.

Yet, we keep forgetting why are we doing this. We forget why do we get paid.

And no, it is not because we type weird stuff.

The goal of software development

(Did I just write a subtitle using the post title? You bet I did).

In short: the primary goal of software development is to reduce…

Sometimes we face hard choices, where there’s no clear path or direction. Actually, we might not even have a clear goal.

Photo by Nick Fewings on Unsplash

NOTE: This post was first published in my newsletter. Subscribe to receive my posts a week earlier, right to your inbox 🚀

You’ve probably been there before. Think about it. Situations where the line dividing “the right call” and “a fucked up mess” seems blurry.

On such occasions, the temptation is to take a step back. To go back to a previously known state. Back to safety.

You might end up suggesting things you would not consider given other circumstances.

I’m here to tell you that when things derail, we need to go back to basics.

(Now that I’ve told…

Someone was pleased with us last week (“us” as in “my team”).

Photo by Kelly Sikkema on Unsplash

NOTE: This post was first published in my newsletter. Subscribe to receive my posts a week earlier, right to your inbox 🚀

Turns out, we deployed a contrived new version of a form they were using. Among other stuff, there was an input to introduce the bank account. A single text field where you could paste the number from somewhere else.

How exciting, a form with an input. You’re such a senior developer.

We didn’t know back then, but before this new version, our users had to type it into several inputs. …

Some random thoughts about software development teams

Photo by Steven Lelham on Unsplash

NOTE: This post was first published in my newsletter. Subscribe to receive my posts a week earlier, right to your inbox 🚀

Teams should be the core entity. The primary unit of work within an engineering team.

Teams should be cross-functional: all needed roles should be there — and when I say all, I mean every role — not only coding. The customer should be there. If not possible, a customer advocate (say, a Product Owner) is a valid, common alternative.

The Software

Software teams should focus on producing running, working, and tested code as soon as possible.

Every week better than…

Recently I’ve been asked how I approach the unit vs. integration vs. e2e debate. I’ve answered it twice below

Photo by Koala on Unsplash

NOTE: This post was first published in my newsletter. Subscribe to receive my posts a week earlier, right to your inbox 🚀

Short answer

I don’t really care about names.

Write tests that provide a higher degree of confidence in your application.

Write a test before writing the “production” code that should make it pass.

Make sure your test suite is fast and cheap to run and maintain.

Longer answer

When I code a new feature, I like to start writing an application-level test using Cypress and Cypress Testing Library. This test is gonna stay in red until the whole feature is developed. …

Photo by Nathan Dumlao on Unsplash

But but but.

In a perfect world, we’d face charges for writing untested code.

Buuut we are not there yet.

We all “know” testing is important.


“…but it is hard”

If your code is hard to test, it’s probably because it’s doing too much (and it’s too coupled).

If it’s doing too much, it’s also hard to understand.

If it’s hard to understand, it’s also hard to maintain.

And one could argue that unmaintainable code is not good code.

If testing hurts, we tend to blame the test. Usually, though, the root cause is the code being tested.

In short: Testing highlights pieces…

Photo by Tine Ivanič on Unsplash

What if everything in software development was about creating feedback loops?

Gimme examples

Okay, okay. Here’s a non-exhaustive list of examples and some questions they might try to answer.

Static analysis (type analysis and linting tools): “Does the code I wrote have valid syntax and grammar?”

Code build/compilation: “Is my code compiling?”

Unit test: “Does that small unit of code do what I think it does?”

Integration test (whatever that means): “Does that last piece of code works as expected when used in its environment?”

Application-level tests: “Does that last feature behave as expected, from a user standpoint?”

Pair programming: “Did we…

I love random stock pictures. Photo by Raj Eiamworakul.

I’ve been focusing on testing for the last few months. Here’s a non-compelling list of tools to learn about it.

disclaimer: Turns out this list has nothing to do with testing, a lot to do with learning paths.

I write about it

I’ve written several articles:

As explained in Learning in public, I feel that writing stuff to your future self is an excellent way of improving. It is simple: Write the post you wish you’d found two months ago.

For example, today’s post is gonna remember my future self that there are several ways of learning. …

Adrià Fontcuberta

Words matter — Frontend development, CSS, UX, design, lean, agile and everything in between.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store