A few days after finishing last week’s newsletter on energising work and collaboration, I started to look back at moments in my career when I felt energised and satisfied. This is a list of a few of the things that I came up with:

• Seeing the impact of my work and knowing that my work matters. When a feature is released, I can see if it’s working, if people are using it, whether it’s successful or not.

• Being part of the decision-making process and having my feedback recognised.

• When I had the chance to not just be a coder, cranking up lines of code in a dark cave, only seeing tickets.

• Having skin in the game.

• Talking to users, understanding them, their circumstances, their world, and discovering how we could help them.

• Exploring the problems, ideating and solving things together, as a team.

• Being able to solve problems, not just build stuff.

• When I built something, whether it was an API, a user interface, a library, etc. it was built—and designed—with the people using it at the centre.

• An environment where we feel supported, and our humanity is seen.

• We can do good work and have pride in our work.

• We are treated as responsible adults.

• I can adapt, learn new things, face new challenges and grow.

• I am surrounded by people better than me that I can learn from. People are keen to learn from others.

• When the team cared about and built shared understanding frequently. The use of maps (e.g. user story mapping, event storming, etc.), visual tools and pairing/mobbing was widespread.

• Writing code that models the business flow and logic in a descriptive and well-understood way. People that aren’t developers could understand it, the code uses the language of our business.

• Building things that I can be proud of, instead of having the feeling that I have to compromise and write bad code all the time.

• “It is what it is” is not in our vocabulary.

• When I was able to move fast but always under control, with a safety net. Mistakes weren't scary.

This week I’ve been able to stabilise a bit more my routine and “roll with the punches” when I couldn’t. Part of it has been doing lots of movement snacks (every 45 minutes at least), making sure I go for walks in the middle of the day, that I eat healthy and get enough sleep. Specially, getting enough quality sleep has been a challenge sometimes, but it’s getting better, and I feel better because of it.

In terms of learning, I’m still not back to full speed, but I’ll take what is given. Anki flashcards are my go to these days, they help reinforce the things I learnt in the past and just takes a few minutes a day to do.

Recently, I did a Kotlin intensive “sprint”, went through the book Kotlin in Action in a few days and built a little something. The language didn’t blow my mind (like Elixir or F#) and I’ve never been a fan of Java, but I was happily surprised at how “comfortable” it felt to write, and got the impression it was well designed. Definitely felt way better than JavaScript overall—not that it’s a difficult thing to do. I like that it prioritises expressions over statements (fewer statements in languages, please), so for example, you can assign an if to a value, has pattern matching and a functional flavour. One thing I’m not a fan of is the way it deals with nulls—in a similar way JS/TS deals with it, optional chaining, nullish coalescing, letting you know that you’re trying to access null, etc. I get that this is a much better way than what Java does, but still.

I also came back to the book Hands-on Rust, spending an hour here and there. It’s enjoyable because it has you learn Rust by creating a video game—a dungeon crawler—, which is right up my alley.

Finally, I started reading Just Enough Research by Erika Hall. Fantastic book so far. It gives me “continuous discovery” vibes. Basically, the idea is that good research is important. It allows us to ask better questions, reduce uncertainty, and build the right thing. It should be done collaboratively and frequently, not only by a researcher or a designer in isolation. The idea is not foreign to me, but I want to see it from a design perspective rather than a product management perspective (since design has been doing this for the longest time) and Erika Hall is one of the bests.

Interesting links

• Unresolved Forces. I recently discovered this book by Richard Fabian—you can read it online—about design patterns. While I have only skimmed through it, I can tell it’s a gem, and I’d like to have some time to read it. The book describes the emergence of the design pattern movement, what patterns really are, why they failed, system theory and much more. From the book: This book is for developers who have heard of, used, or even read up on design patterns but think something is missing or needs correcting. It is also for those who wish to know why this can still be the case.

• Why the Frontend Kingmaker isn’t Full-Stack: A History. Interesting article about the history of the frontend role, its devaluation, why the full-stack role is a myth and failed and the renewed interest in the frontend.

• Why we should stop describing design as “problem solving”