A sad but realistic starting point for everything we do: Things can go wrong and will go wrong.

Do you know this cool new feature? Unfortunately, users won’t use it.

Do you know this excellent new UI design you just crafted? Unfortunately, users won’t get it.

Do you know this great function you just wrote? Unfortunately, it won’t work as expected.

Read this comfortably at https://afontcu.dev/minefield

We overestimate what we can achieve in a short period.

But, at the same time (no pun intended), we underestimate a long-term improvement process.

It's pure maths

First, think of any process you'd like to improve.

Hi, folks! It’s been a while since my last issue, but here I am again with some random thoughts about… you know, a little bit of everything.

Stay safe!

(btw, you can also read this newsletter on my site: )

Software development is like a chess game.

I like chess. It is a game where principles are paramount and easy to understand. Still, their implications are hard to get for our brain (not kidding).

Now, I tend to lose. I lose because I don’t pay attention. I oversee threats and take dangerous paths, and I realize when it’s too late.

Hi mate! It’s been a while since I sent you an email. Not sure if I can say “Happy New Year” or if it’s already too late into January.

Anyway!

I wanted to share some quick ideas when it comes to the best attribute a software team can show.

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

Hi folks! It’s been a while since my last article. You know, hard times, a pandemic and all that.

But finally, the long wait has come to an end. Here’s a new post!

The status quo is dull.

Following is a list of stuff I noticed we tend to accept blindly.

1. Why do we work in two-week iterations?

Who decided ten working days was the way to go? When did they decide that? What was the context? Is it still valid?

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

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.

In theory, theory and practice are the same. In practice, they are not.

Except when they are.

You read books, posts, watch videos, whatever, and that’s cool. But the true power comes from matching these learnings with personal experiences.

Recently, I experienced a match between theory and reality. And oh, you bet it felt good.

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

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.

Ron is the manager of a small shoe factory. And he’s quite good at it, I must say. An excellent small shoe factory manager.

Over time, Ron came to the conclusion that he could measure the factory productivity. It’s merely the .

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

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.

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

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.

Some random thoughts about software development teams:

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.

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

Short answer

I don’t really care about names.

Write tests that provide a in your application.

I know, I know. Feedback loops rock the stage. But.

Not long ago we agreed that software development is just about feedback loops. Not sure if we actually agreed on that, though, but nevermind.

…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.

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

Gimme examples

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

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

(Sunday rant ahead)

I have just come back from my first Agile Lean Europe 2019 in Porto. As in any other , there’s no program - the attendees create the agenda for the day. That’s part of what makes them so appealing.

(Read this post in my blog here).

A year ago, in my JSCamp 2018 recap, I listed some of the best talks. You might notice that most of them were “technical”. That’s totally expected, right?

This year, however, things were a bit different.

While debreafing the event, my former colleague and I noticed some recurring topics. And those weren’t the topics you’d expect from a JavaScript conference.

Antipatterns to tell if you are solving problems or just developing sotware.

1. You can’t tell why something is under development

…or the reason sounds like I’ve been told to”, “it makes sense” or similar stuff.

You and your team fail to know why something is important? And why working on that feature is important than working on that other thing? Don’t you know the expected outcome (outcome - not output) of the current sprint? .

Let’s say you are sold on the idea of testing. You know it’s essential, and you are struggling to sell it to your team, your managers, and your colleagues.

Why is it so hard?

You and I know that testing increase productivity - in the long run. And people on the other side are not aware of that pleasant feeling when refactoring some code and seeing the “✅ 100% tests” message.

Last year I had the chance to give my “Maintainable & scalable CSS” talk in a couple of events: Barcelona Crafters and Commit 2018. In both conferences, I had a 45-minute slot to fill in with my personal experience managing CSS.

That was cool. Same talk, similar time slot (40 vs 45 min). I was expecting to use the exact same speech and slides. You might call it “ROI optimization”

However, in between both events, I was invited to speak at Modern Web Event by La UOC. There, I had the chance to talk about (drumroll…) maintainable and scalable CSS.

There was only one problem.

When I was 15 (so 14 years ago, OMFG), I started my personal blog called Buscant a Wally (Where’s Wally?). I remember discovering what a blog was thanks to my Spanish teacher, and running home on a Wednesday during lunch time to launch my first blog ever.

It was exciting. In 2005, the internet was way different. There were a lot fewer people (I say that as a good thing). Twitter didn’t exist. Facebook did, but nobody knew about it. Internet content lived in blogs, so . The goal wasn’t about harvesting likes or retweets. We just wanted to discover cool things, and share them.

And that’s a good thing.

Photo by on

t3chfest is one of a kind. It is a tech conference, obviously, but some things make it different from the others.

The newsletter’s title was a Tweet published weeks ago by Amy. I wrote a short response, but the questions have been in my head for some time, so I wanted to discuss the topic further.

So, here’s the list of myths that I believed a long time ago. I wouldn’t say “before becoming a software engineer”, because I’m not sure when that happened. When I as Junior? When I became “Senior” (what does that even mean)?

AlphaZero has become the ultimate King of the gaming Artificial Intelligences. The algorithm, developed by DeepMind (a.k.a. Google), beat everyone at everything.

Last month, a detailed paper was published with detailed information of the matches it played against , the most popular and powerful chess enginer out there… until now.

The current big topic in the frontend community is not… new. However, CSS Tricks spiced everything up with their last post, called The Great Divide.

Ahh, the Internet. You gotta love the Internet.

This week, Slack unveiled its new logo. If you’ve been on the Internet long enough, you can easily guess the reaction to that change.

Feel free to grab some popcorn and . At least to to the mix.

When we think about the future, we tend to focus on things that will likely change. We like progress, shining new things.

You know, everybody expected flying cars from this decade. We are gonna fail on this one, arent’ we?

Anyway. What if we turned things upside down?

What if we thought about the future in terms of

Everyone has an opinion about the topic — So why wouldn’t I?

I’ve been a web developer for 10 years. So, when I read headlines such as:

Horror Vacui, “fear of empty space”, is a term used in visual art to describe a tendency of filling the entire surface of an artwork with details. It avoids blank states. Victorian Age art is a clear example of this style, which is usually related to unstable, troubled minds.

, by Jean Duvet. Apocalypse

disclaimer: this newsletter goes full personal. Hopefully, you’ll understand..!

“Expand my brain, learning juice!” - Homer Simpson, poet (Episode s17e06)

When , I stated that was one of the main reasons for doing so.

Yup, my subject is a meme.

I’ve been working in the web industry for 10 years now. Does it make me a Senior Developer?

Have you ever tried to sell something to someone?

Photo by on

…long live agile?

I wanted my first newsletter to tell you about my first public talk ever. I talked about CSS at . I explained how do we deal with it nowadays.

Well, now I do. Hi! 👋

I was wondering how to start. You might have some questions, so what about starting with an FAQ? Let’s go!

A newsletter? Why starting a newsletter?

Because I’m becoming a huge proponent of mindset. You see, almost everyone learns in private. They just consume content. But I truly believe that, if you want to master something, the best way is trying to explain it to someone else.