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

Image for post
Image for post
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, test, and deploy”. …


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

Image for post
Image for post
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 the lead time to deliver business value. …


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

Image for post
Image for post
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 you so, my job here is done. But since you’re likely locked down at home and quite bored, feel free to keep on reading).


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

Image for post
Image for post
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

Image for post
Image for post
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 every month, every day better than every week. Every hour better than every day. As. Soon. As. …


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

Image for post
Image for post
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. …


Image for post
Image for post
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…

“…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 of code that could use a redesign. If something feels “hard to test” then it is poorly designed. …


Image for post
Image for post
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 come up with the best possible design?” …


Image for post
Image for post
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. …


How should we think about UI components when testing them?

If I gave you a really complex function such as

function sum (a, b) {
return a + b
}

You’d know how to test it right away. You’d do something like the following:

test('sums two numbers', () => {
expect(sum(1, 2)).toBe(3)
})

test('JavaScript being JavaScript', () => {
expect(sum(null, undefined)).toBe(NaN)
expect(sum(null, null)).toBe(0)
})

Felt easy. Why was it so simple, though?

You might say that sum() is "easily tested". Numbers in, number out.

Okay, that’s interesting. So this is the mental model you used:

input ➡ Function ➡ output

So: Given a specific input, we only had to expect the appropiate output. This is one of the strengths of Functional Programming, but that’s beyond the scope right now. …

About

Adrià Fontcuberta

Words matter — Frontend development, CSS, UX, design, lean, agile and everything in between. https://afontcu.dev

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