Building web in 2026

My tech year in review (2025)

Tue, 30 Dec 2025 13:00:00 GMT

As AI tools improve, many programming activities seem to move faster. This year, I merged more pull requests, touched more repositories, resolved more bugs, paid down more tech debt, built more prototypes, and explored more new tools than ever before.

In comparison, some other things felt surprisingly slow. In this post, I want to reflect on them.

Conferences
Blogging
Reading
Domain-Driven Design
What’s next

Conferences

Before I fully switched to JavaScript tech stack in 2023, I regularly attended Drupal conferences and meetups, often as a speaker. I enjoy the creative challenge of presenting to a like-minded crowd and learn a ton while preparing.

I’ve started applying to JS conferences in 2023 with several proposals from software architecture to interviewing tips to web performance. At first, it was all rejections. In 2024, I finally got an approval for a lightning talk at React Alicante. And in 2025, I had the pleasure of speaking at five (!) conferences:

React Paris (my review)
CityJS London (my review)
React Summit
BcnDev
React Alicante (my review)

Interestingly, all conferences selected the same talk, “At the top of the pyramid: Playwright testing at scale”. Indeed, my 2024 was all about testing, and I learned Playwright quite well.

Play

Building a speaker profile, growing my network, developing talk ideas, rehearsing, and physically traveling to conference locations all takes a lot of time and energy.

Blogging

Since I was busy with conferences, I didn’t have enough energy left for blogging. For me, the most intense part of writing is thinking, reflecting, and discovering insights from my own experiences. It takes time and patience.

Proofreading and adding interactivity became much easier, though. I wanted to make “Balancing Coupling in Software Design” (book review) easier to read, so with AI assistance, I migrated my blog to Astro and built interactive quiz components.

To keep this blog alive while on “writing holidays”, I’ve added a quick “This Week I Learned” section.

Reading

AI gives accurate, personalized answers to dozens of my questions daily. That’s great for getting the task at hand done. But these effortless interactions rarely leave me with deep understanding. For that, I still prefer high-quality, curated content written by domain experts.

A couple of examples from healthcare analytics, since that’s what I’ve been exploring lately:

The Book of OHDSI - basics of healthcare analytics (focused on the OMOP Common Data Model)
R for Data Science - a great intro to how scientists think and work in R

Domain-Driven Design

I’ve been practicing DDD to various extents since discovering it in 2022 (“Learning Domain-Driven Design” - the software architecture 🐒 book that makes sense). Instead of sharing how amazing and impactful it is, I want to reflect on some challenges I’ve faced so far.

In 2024, I joined Aetion (now part of Datavant) to work on a complex healthcare business domain. I followed my own advice from “Onboarding yourself as a Senior Software Engineer”, got promoted to Staff Engineer, worked in two teams, and contributed to both code and culture in several meaningful ways. Yet, I’m still figuring out the business domain.

Recently, I spent a few months redesigning a drug analytics module. While my official task was to conduct a technical design, most of the time was spent figuring out what the hell we were trying to build. It took several months of using the product, reading documentation, and talking to experts before I could write a first draft. Not exactly the timeline you’d expect in the age of AI. Of course, I used AI to support my explorations, but the core thinking was on me and my colleagues.

This is the cost of building something unique in the “core” business domain, the one that brings companies their competitive advantage.

While Domain-Driven Design is supposed to simplify this process, in practice it’s not always that easy.

DDD Obstacle 1: The name is overloaded

Most backend developers are aware of the Domain-Driven Design methodology. Some practiced tactical DDD focused on aggregates and value objects. Lucky ones participated in EventStorming sessions a few times, but most of us only read or heard about it.

As a result, when developers talk about applying DDD, it usually leads to misunderstandings. The best solution I’ve found is to avoid talking about DDD in the first place.

DDD Obstacle 2: Domain learning is a side quest

I’ve met developers with years of experience in the same company and yet not knowing much about its core business domain. Some intentionally avoid investing in less transferable niche knowledge; others simply don’t have enough time.

In day-to-day work, we developers often prioritize writing code over learning the product. Building software is already hard and requires a lot of technical learning, from programming languages to distributed systems to frontend frameworks and everything in between.

As a result, developers have neither the time nor cognitive capacity to learn the business domain. In my particular case, I have been in healthcare analytics for almost two years now, and I still have a lot to learn.

DDD Obstacle 3: It’s not interesting

Many of us became developers because we genuinely love building software. The idea to learn something completely different, like medicine, law, or insurance, might not sound that exciting.

On the other hand, not all domain experts are equally excited to explain the basics again and again to the disengaged engineering crowd.

Many facilitation activities exist to help overcome these issues. Needless to say, one has to practice a lot to master EventStorming, Domain Storytelling, or similar techniques.

What’s next

This post was partially inspired by the talk “Slow down to speed up your decision-making” from Gien Verschatse at GSAS Barcelona 2025. In the age of AI, it’s important to remember that some things should be slow. Next year, I’ll continue my DDD journey with the book “Collaborative Software Design”, which Gien co-authored.

Another inspiration of the year is DuckDB. It can process enormous volumes of data super fast on a typical macbook. In combination with my data analytics experiences at work, DuckDB made me curious about data processing beyond traditional relational databases. Slowly, and with a lot of handwritten notes, I’m finally reading the “Designing Data-Intensive Applications” book.

Yet another area I’m curious about is local-first and sync engines, a topic that became even louder after the TanStack DB release.

I’m excited about AI acceleration in coding and looking forward to spending more time on the slow things! 🎄

Previous editions: 2019, 2023

A story of one regexp

Sun, 23 Nov 2025 00:00:00 GMT

I find regexp writing very entertaining. When I need to perform some boring text manipulation - let’s say extracting URLs from raw logs - I’d rather spend 10 minutes tweaking a regexp than the same amount of time doing it manually.

Back in my PHP days, I was lucky to write hundreds of regular expressions for matching URL paths, tweaking HTML, or validating user input. I’ve heard horror stories about dramatic regexp incidents, but I’ve never experienced anything like that myself. Until this year.

Not a database problem

This year, I’ve been working a lot on a large Java monolith known for its severe performance issues.

One of these issues was reported by a user who couldn’t open an entity report screen in one of their projects. Normally, the GET endpoint responsible for the report responds in 1-3 seconds, which is acceptable¹ for that use case. In the user’s case, it was taking 18 minutes, which obviously resulted in a timeout error.

The entity in question had hundreds of dependent entities and nested configurations. The team was pretty sure the slowdown was due to some ORM cruelties resulting in billions of database queries. Indeed, the telemetry trace confirmed 196 SELECT queries, but nothing particularly slow. The response was getting stuck right before the end of the processing, without any meaningful tracing information.

I followed the code for quite some time until I finally found it, the topic for this article!

The problem

The entity reports are generated in markdown using a custom heading ID syntax. These heading IDs are replaced by HTML anchors when rendering the report to HTML². A quick replaceAll with a regexp is invoked to perform the replacement.

If you like regular expressions as much as I do, try to solve this problem using a regexp in JavaScript. Find the last occurring word in square brackets in each line. In the example below, ref_heading_1 and ref_another_heading should be matched.

Interactive content is not supported in RSS

The original code used something like this (click to reveal):

Interactive content is not supported in RSS

It suffers from the problem known as “catastrophic backtracking,” the same issue that brought down Cloudflare six years ago³.

In the regexp above, the [^\n]* part greedily matches the entire line and then backtracks character by character in an attempt to find a \[(\w+)\] match. When executed as is, without any optimizations, this results in exponential time complexity.

18 min vs 7ms

Before fixing the problem, I want to take a quick detour and share how that poor regexp is executed by different languages.

I took ~80k lines of markdown with 14 matching square brackets and ran this regexp on my M2 mac. Try to guess my results:

Interactive content is not supported in RSS

This is not a proper benchmark by any means, but now you know why I didn’t have any problems with regular expressions early in my career.

Apparently, PHP has always been very tolerant to poor regexp design by using a highly optimized PCRE library under the hood. Since 7.3, it uses PCRE2 with JIT, which makes regexp execution blazing fast, as you could see in my mini-benchmark.

On the other hand, Java does not rely on any library by default. It provides its own regexp implementation, which is far less optimized than specialized libraries. I could literally follow all the backtracking steps in the debugger to see how bad it was. As soon as I installed a specialized library⁴, I’ve got acceptable performance, although it was still nowhere near PCRE2 written in C.

If you check the leaderboard of the Java One Billion Row Challenge, you’ll notice that beyond a certain threshold, all solutions are essentially C code disguised as Java. Such optimizations must be as entertaining as regexp, but not for a sane production codebase.

A better regexp

Could we rewrite this regexp to achieve acceptable performance?

I usually start from the part I really want to match and then build the rest of the regexp around it. In this case I need a word starting with ref_ in square brackets:

\[(ref_\w+)\]

This will match all words in square brackets, but we only need the last one. We can specify that none of the next characters until the new line can be a square bracket:

\[(ref_\w+)\][^\[]*\n  ✅

Figured out a better one? Share in comments!

The fix

As I said, I find regexp writing very entertaining. Still, the production code is not the right place for that. The mix of escaped square brackets makes this regexp hard to read and review.

Instead, I wrote a simple loop that iterates over the lines of the input text, looks for the specific pattern [ref_ using String.contains, and only if a match is found, invokes the replaceFirst method.

This solution is much faster than any regexp I tried, and also much easier to maintain. Now, time to look into those 196 SELECT queries 😈

Footnotes

Acceptable for that particular system in that particular phase of its maintenance cycle 🤓 ↩
A more common format would be {#heading-id} but migrating would require much more effort: https://www.markdownguide.org/extended-syntax/#heading-ids ↩
Details of the Cloudflare outage on July 2, 2019 (Appendix: About Regular Expression Backtracking) ↩
RE2/J is a port of C++ library RE2 to pure Java. ↩

React Alicante 2025

Mon, 13 Oct 2025 08:00:00 GMT

On this page, you can find a full list of all React Alicante 2025 talks with my short comments. A longer opinionated summary at the end.

Enjoy and feel free to reuse it if you need a summary for your team or employer.

Sessions - Day 1
Sessions - Day 2
My summary

Sessions - Day 1

16 high quality talks on React Server Components, Compilers, CSS and personal projects.

Building for You by Kadi Kraman

@kadikraman

Kadi, a software developer at Expo, set a theme for this year’s conference: personal side projects built out of curiosity and passion. She touched on common obstacles like procrastination, scope creep, and goal setting when building something outside of work.

Developing Waku and Exploring Client State with React Server Components by Daishi Kato

@dai_shi

The author of Zustand and Jotai talks about Waku, the project he initially built to explore React Server Components but ended up with a fully functional React framework that offers a minimalistic alternative to Next.js. Daishi demystified the RSC API by breaking it down to serializing and deserializing components. As a state management guru, he went deeper and explored how jotai may look like in RSC world. The result is waku-jotai.

Building Interactive Async UI with React 19 and Ariakit by Aurora Scharff

@aurorascharff

Aurora took a real life example of a dropdown component with some data fetching logic and walked us through a series of refactorings to make it more accessible, maintainable, and user friendly. The synergy between React, Ariakit and Tailwind made code much more compact and declarative.

The 2025 State of React Testing by Daniel Afonso

@danieljcafonso

The past, present and future of frontend testing featuring Vitest Browser Mode, MSW, Playwright, and emerging AI tools.

Oxc and Biome as possible replacements for ESLint/Prettier
Vitest Browser Mode
UI-TARS-2 - vision-language model (VLM)
Creating self-healing automated tests with AI and Playwright
Midscene.js

Compilers, User Interfaces & the Rest of Us by Matheus Albuquerque

@ythecombinator (slides)

Typical frontend work can feel distant from computer science theory, but many of the tools we use every day actually involve compilers. The deck is packed with links to libraries, concepts and articles that I’m yet to explore. In the past, I would be overwhelmed by this talk, but with AI I feel I can easily dig couple layers deeper if I need to.

React Beyond the DOM by Erik Rasmussen

@erikras

The talk started as a typical overview of React internals but suddenly turned into a fascinating live demo that blew everyone’s mind 💡

react-pdf and ink as examples of custom React renderers
Github repo used in the talk
Bracket Lens (I spotted it on Erik’s screen)

Legacy Starts Tomorrow: Surviving the Refactoring Loop by Paulina Chojnowska

@AntariaPaulina

A much needed reminder that we should never stop refactoring despite it’s rarely immediately profitable. Advice from Paulina is as obvious as “sleep well and brush your teeth” and yet it has to be said: refactor all the time, plan for it, own the code.

Feature Flags 101: Transforming Your Development with a Simple Switch by Luis Oliveira

@_luisFilipePT

Feature flags allow us to control behavior without deploy. Luis clarifies use cases for environment variables vs feature flags and shares some common patterns like “Kill Switch”.

Building component libraries with designers, not for them by Przemek Krupiński

@pppemo

Przemek is a regular React Alicante attendee who came back this year with a lighting talk on collaborating with designers. He focused on the importance of building shared language, trust and cross-functional transparency.

Local first is the new black by Miquel Company

@solilokiam

Miquel builds a cool personal project, The Pyrenees Challenge event for motorcycle enthusiasts. He shared his local-first journey starting with DIY Zustand+Yjs, continuing with Tinybase and its performance issues, and eventually settling on jazz tools.

https://lofi.so/

Level up your React knowledge with vibe coding by Heather Thacker

@hhthacker

A lightning talk on how AI can be used to learn React.

How I used AI Workflows with Figma & Playwright MCPs to accelerate my development time by Aris Markogiannakis

@arismarko (slides)

MCPs made a lot of noise when they were first introduced, but it’s not always clear how they can be used in our day to day work. Aris shared some examples from his own workflows.

Scaling a React Application from 0 to a Brazilian users by Dan Neciu

@neciudan

Dan shared a brief story of co-founding CareerOS and surviving its early days. Some technical tips include starting component library early and bringing wrappers for all 3rd party libraries.

My CSS is Faster Than Your React! Writing CSS only React Search! by Evyatar Alush

@evyataral

Evyatar blew everyone’s mind by building a fully functioning search with just CSS. In fact it was used in his library emoji-picker-react (code) before he replaced it with vistualization.

FlairUp

Reacting to Surprises: Creating Engaging Hidden Features by Courtney Yatteau

@c_yatteau

Courtney shared a few examples of easter eggs in apps that can make user experience more engaging.

Nearly Familiar: Can Web Developers Relate to Genealogy? by Kevin Maes

@kvmaes

Kevin wrapped up the first day with an insanely well-built personal project for exploring genealogical data, his longtime hobby. While we learned a lot about genealogy and visualization pipelines, the main takeaway for us was to reconnect with our inner creativity. It can be very satisfying and educational to build something for fun.

Sessions - Day 2

Another 16 talks on React 19.2, animations, and of course AI!

The State of React and the Community in 2025 by Mark Erikson

@acemarke (slides)

Mark acknowledged the complicated state of React community caused by the weird and intense Vercel’s push for React Server Components. Several years later, the community is still recovering. Just a few days after this talk, React introduced the React Foundation.

Blog post

The Suspense Continues: ViewTransition and Activity by Chance Strickland

@chancethedev

Just a few days before React Alicante, React 19.2 was released and Chance gave us a live demo of the new features.

The Beachcomber’s Guide to Type-Safe Design Systems by Kathleen McMahon

@resource11

Kathleen covered several important topics, such as the polymorphic component smell (<Button as="a" /> 💩), the semantics of interface vs type in component libraries, and the power of typed design systems. She also led an accessibility workshop at the conference and shared with me that overall awareness of a11y is growing!

Token Studio

Unleashing the Magic of JavaScript Generators by Mattia Manzati

@mattiamanzati (slides)

Generators have been around longer than async/await and yet most of us without Python background don’t quite understand them. “Generators are iterators and iterables that provide pull-based data flow” - Mattia unpacked this for us starting small and ending up with its own UI rendering engine powered by generators.

Surprisingly, there is not much educational content on the topic. The most relevant I found is Algebraic Effects in JavaScript series by Redux Saga author.

The Dark Side of UI – Avoiding Common Frontend Anti-Patterns by Bree Hall

@bytesofbree

Bree walked us through a few poorly written React components and offered better approaches, featuring libraries like TanStack Query and TanStack Vistualization.

Awesome Cursor Rules (or awesome-copilot) to communicate your preferences to AI

Navigating the hype driven world of AI development without going crazy by Kitze

@thekitze

Super fun talk ridiculing the hype around AI as well as our FOMO around it. For Kitze, coding is a form of procrastination. He doesn’t allow himself to write code manually and instead forces himself to always use AI. The “Managers have been vibe coding forever” slide immediately went viral

Zen and the art of code maintenance by Beth Swingler

@bethylogism

Using Zen as analogy, Beth highlighted some common code maintenance problems. Bonus points for mentioning the Tidy First? book! 😻

Fun with emails by Daniel Mocan

@danielsmocan

Daniel gave us a quick intro to React Email, a great library to dramatically simplify email templating.

End-to-end testing: the hard parts by Kate Marshalkina

@kalabro

I gave a shorter version of my “Playwright testing at scale” talk focusing on the hard parts. More on my speaker experience at the end of the post.

Deploying an app with Docker by Forbes Lindesay

@ForbesLindesay

A friendly intro to Docker for frontend developers who want to deploy their apps outside Vercel.

Boosting React Native Performance with React Compiler: A Sneak Peek into the Future by Ilda Neta

@ildaneta

Ilda demonstrated how React Compiler can be used in a React Native project. I didn’t know about "use no memo" directive to opt out of automatic memoization.

Make development easier with your own browser extensions by Łukasz Nowak

@LukaszNowakPL

Łukasz wanted to build a helper extension for himself and his teammates but it turned out to be tricker than expected. He faced several challenges such as embedding React, communicating with the main page, and debugging.

Github repo used in the talk

Audio recording and playback complexity across browsers by Vinu Vijy Nair

@vinu-phoenix

Vinu shared how he attempted to build a new audio feature for ManyChat fully in the browser, what challenges he faced and of course what he learned.

The Missing Middle Ground: Fast & Real Testing for React Native by Łukasz Chludziński

@lukasz_app

Another testing talk, this time in React Native space. Łukasz demoed a new library react-native-harness that allows testing native capabilities while keeping tests fast and developer friendly.

Running WebAssembly in React Native Applications by Shivay Lamba

@HowDevelop

WebAssembly is not super common in React Native due to the differences between web and mobile platforms. Apparently, there are some interesting use cases and solutions in this space.

Polygen

Practical guide to animation in React by Kateryna Porshnieva

@krambertech

This year Kateryna demystified animations for the rest of us. Very visual and practical talk covering everything from basics to spring physics.

My summary

It was my third (!) React Alicante conference in a row and the fourth (!) React conference this year. I’ll be honest, I was not sure I would enjoy it that much, given that I had already heard from many of the speakers earlier this year.

Turns out, I had no reason to worry. After visiting so many conferences, React Alicante is still one of my favorites:

I prefer single-track conferences with a larger audience - it feels more engaging.
I love the packed agenda, with 32 talks plus optional workshops.
The average talk quality is high, with some lightning talks outperforming full talks.
Tickets are cheaper than most other conferences.
The organization is always very smooth. For a regular attendee, everything just works, while behind the scenes the organizers work hard to fix all the random issues.
A very special location creates vacation vibes.
The lovely community spirit and super friendly atmosphere ❤️

Speaker experience

Delivering the same talk at multiple conferences is efficient but boring.

For React Alicante, I decided to rework my material into something new. I love the time constraint that a lightning talk imposes - it requires me to be laser-focused on what’s important. Last year, I gave a deck-free inspirational speech on mentorship. This year, I decided to go technical and even included a short live coding demo. I had a lot of fun, and I hope the attendees enjoyed it as well!

Videos

All sessions were recorded and will be available on YouTube. While waiting, checkout React Conf 2025 recordings (day 1, day 2).

Bullet points from CityJS London 2025

Thu, 01 May 2025 21:00:00 GMT

Nine things from my CityJS London 2025 notes:

The community is excited about MCP. New user experience. No more glue code. LLM is the glue (Kent’s talk, MCP spec, shadcn/ui registry MCP demo)
Testing is a hot topic (Soumaya Erradi, Daniel Afonso, and your humble author each presented in packed rooms). Tools mentioned: Selenium, Cypress, Playwright, Vitest Browser Mode, Biome, Oxc, msw-auto-mock.
Lynx - a new React Native alternative open-sourced by the TikTok team. Yes, CSS is supported (ReactLynx)
AI generates vulnerable code, and even security experts like Liran Tal find it difficult to review it.
Accessibility Insights Chrome extension
New asynchronous model is coming to Svelte (discussion)
HTMX didn’t take off because developers love the component model from React.
Meetups are dead (I don’t agree as I’m attending a few in Barcelona).
Huge thanks to the organizers — I finally have a cup to drink my tea in! 😅

Of course, my notes are incomplete and only capture a fraction of this large 3-track event! Check the official videos when they’re out.

What’s next?

React Summit (June 13th, 2025)
DevBcn (July 8th - 10th, 2025)
React Alicante (October 2nd - 4th, 2025)

See you there 👋

React Paris 2025

Tue, 25 Mar 2025 09:00:00 GMT

On this page, you can find a full list of all React Paris 2025 talks with my short comments. A longer opinionated summary at the end.

Enjoy and feel free to reuse it if you need a summary for your team or employer.

Sessions - Day 1
Sessions - Day 2
My summary

Sessions - Day 1

A day full of diverse React talks including a keynote by Kent C. Dodds.

Abracadabra: The Vanishing Network by Kent C. Dodds

@kentcdodds

React superstar Kent C. Dodds opened the event with his Abracadabra talk. Many of us had seen it already, but it didn’t matter - we all love Kent so much.

One of the questions from the audience concerned the blurry line between frontend and backend in React Server Components. Kent’s take was that it’s not necessarily a bad thing if you’re not married to the traditional frontend/backend team split.

Links:

Building a design system with React in 2025, what’s new? by Jean Burellier

@shepsheplu

Jean and his team at Sanofi have built a design system from scratch, even the date picker! In their highly regulated pharmaceutical field, a bespoke solution was the only viable option and was actually cheaper than using existing libraries.

I Can’t Believe It’s Not JavaScript by Jemima Abu

@jemimaabu

“We went from JS supporting the web to JS running the web” — Jemima shared a brief history of JavaScript and how it became massively overused in the modern web. She shared several examples where plain HTML and CSS could do a much better job than JavaScript, bringing us back to the fast and accessible web.

Links:

Demystifying Accessibility in React Apps by Kateryna Porshnieva

@krambertech

A variation of Kateryna’s talk on accessibility walked us through some common UI elements and how to make them accessible. When the audience asked how to justify accessibility work to project managers, Kateryna confidently suggested to “just do it” - and I fully agree it should be part of the Definition of Done.

Links:

Goodbye, useState by David Khourshid

@davidkpiano

David started by sharing some common examples of useState hell - “Vibe State Management”. Modern React offers many alternatives to useState, and David walked us through some of the most popular ones.

Links:

Type-Safe URL State Management in React with nuqs by François Best

@fortysevenfx

François is the author of nuqs — URL state manager for React. In his talk, he explained some benefits of storing state in the URL as well as some common challenges that nuqs solves.

It’s always great to have open source contributors on stage!

Links:

React Server Components: Elevating Speed, Interactivity, and User Experience by Aurora Scharff

@aurorascharff

Aurora teaches RSC using live coding approach. This time she took a very slow Next.js app and progressively improved its UX using latest React features. As a bonus, she integrated the app with nuqs.

Links:

Github repo used in the talk

What we learned rebuilding the largest Nordic electronic retail website in Next.js? by Tomas Jansson

@tomasjansson

A case study of the largest Nordic electronics retail website rebuilt with idiomatic Next.js and hosted on Vercel. The achieved performance boost speaks for itself, but it wasn’t easy to get there. Tomas shared advice on how to push innovation and get buy-in within larger organizations.

Links:

Bridging Code and Creativity: Level Up Your Game as a Frontend Engineer by Yu Ling Cheng

@YuLingEC

Yu Ling took us on a journey from a typical developer who struggles to communicate with designers and product managers to an influential leader who helps the whole team collaborate and build better products.

I noted down a magic phrase for when I have doubts but am not ready to express them yet: “Let me double check and get back to you.”

Links:

Slides

Sessions - Day 2

The second day was much more focused on AI with a great vibe keynote by Tejas Kumar.

Using AI Effectively in 2025 by Tejas Kumar

@tejaskumar_

A live coding session with Tejas who built a streaming AI chat first without any libraries at all to help us understand the basics, and then with Vercel AI SDK which solves most of the complexity for us. The second part of the talk demoed a simple AI agent capable of rendering React components, playing videos, and interacting with browser APIs such as location. Super cool!

Links:

Let’s build K.I.T.T. with JavaScript by Nico Martin

@nic_o_martin

Imagine a LEGO car that understands human language, knows everything about 90 episodes of Knight Rider, and runs around the stage at React Paris.
That’s what Nico built using Tiny Llama running in the browser, IndexedDB to store data about all the episodes, and a bit of JavaScript magic.

Links:

From Chaos to Clarity: Mathematical Foundations for Maintainable React Applications by Héla Ben Khalfallah

@b_k_hela

Héla started with a list of typical JavaScript codebase issues: spaghetti code, callback hell, lack of testing, and so on. She believes all that is curable with math, and gave us an intro to Graph Theory, Category Theory, Functional Programming and Lambda Calculus.

Links:

Work Smarter, not Harder with Chrome DevTools by Dominika Zając

@domizajac

Dominika shared some less known Chrome DevTools tips and tricks that I tried first thing at work the next day. Very useful! Of course, AI was involved again!

Links:

A Tale of Two Components: Mastering A/B Testing in React by Violina Popova

@PopovaViolina

Violina gave an intro to A/B testing and how to do it in React. She also shared some real-life results from A/B campaigns her team ran at ClipMyHorse.TV, a YouTube for horse lovers!

At the top of the pyramid: Playwright testing at scale by Kate Marshalkina

@kalabro

I also had a pleasure to speak at React Paris! This time I shared a story about end-to-end testing and Playwright. More on my speaker experience at the bottom.

Links:

React Query API Design - Lessons Learned by Dominik Dorfmeister

@tkdodo

Dominik started his journey as a React Query user, then became active in the community answering questions and writing documentation. Today, he is the key maintainer of the de-facto standard library for data fetching in React. In this talk, he shared some lessons he learned working on such a cool project. It was a pleasure to meet and learn from him!

Using Remix, the wrong (?) way by Antoine Chalifour

@antoinechalifour

I really enjoyed Antoine’s honest story about building his product with Remix and having quite a few battles with the opinionated framework. Remix is great, but Antoine’s project didn’t quite fit its router model. Luckily, Antoine found a way to make it work and also learned a lot on his way!

A journey into the fiber by Matias Nahuel Gonzalez Fernandez

@matiNotFound

Matias wrapped up the event with the inspiring demos of custom React Fiber implementations, including Doom in React!

Links:

My summary

React Paris offered a great speaker lineup, but my biggest highlight was the very special and friendly atmosphere between the talks. With generous coffee and lunch breaks, I had plenty of time to meet interesting people, share laughs, and enjoy the beautiful location in the heart of Paris.

At React Paris 2025, I met the most female developers I’ve ever seen at a tech conference. This speaks a lot about both the event and the state of the community!

Speaker experience 📣

Honestly, I didn’t expect much interest in the testing topic. That’s why I put extra effort in making my talk more fun for everyone. It worked out well, and the audience was very positive and responsive - what a gift for a speaker!

This time, I had some minor issues with the microphone during my talk, and while I absolutely hated it, I also love in-person events for exactly this kind of unpredictable and live experience.

Next stop is CityJS London! I already have a few ideas on how to improve my talk 🎉

Organization ❤️

The event went super smoothly, but I know that it’s the result of hard work by the organizers. I’m impressed and I’m definitely keeping an eye on everything the BeJS team is doing!

Full Stack coding interviews - how it was in 2024

Fri, 27 Dec 2024 00:00:00 GMT

In this article, I want to zoom in on coding interviews for Senior Full Stack JavaScript roles at small to medium-sized companies (not FAANG!). Below, I share my experiences interviewing for these roles from both sides of the table.

Categories of tasks

Good news: Most companies can’t afford a super complicated full stack coding task in a typical 1-hour interview. They can’t have too many interview rounds either because both candidates and interviewers are busy.

As a result, most companies come up with something relatively standard, often not too relevant to the actual role, but certainly manageable after some prep work. I identified five categories (or archetypes) of live coding tasks for Full Stack JavaScript roles.

Category 1: Data Structures and Algorithms (DSA)

🎯 Goal: demonstrate confident usage of arrays, loops, hash maps etc.

From my modest experience, LeetCode-like questions are still very popular in interview pipelines, including for Full Stack roles. While I see them as a waste of time, they do have their benefits:

Programming language independent
Easy to measure (solved / not solved, in what time, Big O, etc.)
Large pool of tasks of various levels
Tests-friendly

Prep tips:

Focus on easy (70%) and medium (30%) tasks (LeetCode 75)
Talk out loud as you solve a problem (imagine you’re streaming on Twitch)
Use TypeScript (but perhaps solve a couple in plain JS)
Implement Bubble Sort and Quick Sort from memory (ThePrimeagen’s course)
(Re)read Big O section from the Cracking the Coding Interview book (or alternative)
Solve a couple of easy problems using lightweight TDD approach

Because I don’t sort arrays in place in my normal professional life, this type of task requires the most prep effort from me.

Real problems from my interviewing experience:

Determine if a given number is a prime number.
This is one of the first examples in “Cracking the Coding Interview”, and yet people still ask it in interviews as a “sanity check”
Calculate the N-th number in the Fibonacci sequence.
I was asked to use my own IDE and took the opportunity to drive the solution with tests, which gave me bonus points with the interviewer
Return an array of sums of columns in a matrix
Shift all zeros to the end of an array
Flatten a deeply nested JS object into a new object with properties in the format “propNameLevel1.propNameLevel2.propNameLevel3”.
I got lost in recursive calls and failed that round

Category 2: React (Vue/Angular) exercise

🎯 Goal: demonstrate confident frontend coding

If the role involves React, the pipeline will almost certainly include a React coding exercise.

Prep tips:

Practice building simple components from scratch, with minimal dependencies
Try to keep all code in one file for as long as possible. If it gets too long, you are doing it wrong
Make use of all common hooks. In practice, I’ve only needed useState and useEffect during my interviews, but it’s good to be overprepared
Reread the entire useEffect documentation page (I learn something new every time!)
Build a simple Todo app using built-in fetch for data fetching
Challenge your data fetching implementation for potential race conditions, missing error handling, CORS, slow network support etc.
Cover your app with different types of tests

Nothing feels more awkward in a React interview than when a candidate struggles to write useState without Copilot. A day of prep can make a huge difference.

Real problems from my interviewing experience:

React Like Button (example)
Redux Shopping Cart (example) - yes, Redux is still a thing
React StarRating component
React Stopwatch component

Category 3: REST endpoint

🎯 Goal: demonstrate confident backend coding

Another popular task is to build a REST endpoint and/or read data from it.

Prep tips:

Build a simple CRUD REST API using two different REST libraries (e.g. Express and Hapi)
Implement GET, POST, PATCH, DELETE verbs with fake/in-memory data
Implement basic pagination
Build a simple endpoint in raw Node.js (for example, streaming a big CSV file)

Real problems from my interviewing experience:

Given a JSON contract, build GET and PUT endpoints
Fetch data from an external resource, sort and expose via GET endpoint

Category 4: Take home tasks

🎯 Goal: set the stage for the in-person discussion

Take home tasks allow companies to go beyond basic fetch, GET and useState by letting candidates spend more time on the task. Remember that just solving a take home task is not enough to succeed. You need to prepare for further discussion and live code changes.

Prep tips:

Add tests!
Make sure you are proud of the code you’ve written. A personal touch is a plus too.
If you had to write a lot of code, reassess. Is there a simpler way?
Make sure you understand every single line of it.
Be able to explain every decision you’ve made: libraries, naming, algorithms, testing strategy, etc.
Come up with a couple of additional features for the task and try to implement them without sharing with the interviewer
Add tests!

Real problems from my interviewing experience:

Implement search UI by screenshot
Build markdown editor

Category 5: code katas

🎯 Goal: demonstrate professional coding style (testing, debugging, refactoring, pairing, etc.)

Unlike LeetCode questions where the main goal is to solve the problem, code katas are focused on the process rather than the end result. In fact, many of them are open-ended and can have many “correct” solutions.

Prep tips:

Practice popular katas (Gilded Rose, String Calculator, Mars Rover, Tennis, Bank Account)
Practice them again. The whole point of katas is to repeat them again and again to sharpen your skills and uncover nuances.
Find a community to practice collaborative design and pairing (or organize one)

I haven’t experienced classic code katas in interviews, but I know they are not uncommon. Practicing them can help with other types of tasks too.

Mixing categories

🎯 Goal: demonstrate broad set of skills

In practice, companies only have an hour or two to assess a candidate’s coding skills. As a workaround, they may come up with a Full Stack task that contains a bit of everything: design a contract, implement custom business rules, expose an API endpoint and render it with React. While it sounds like a lot, the interviewers likely expect simple, standard solutions that you can surely implement.

Traits of strong candidates

Now that we’ve covered all common categories of live coding tasks, let me share my observations on what makes a Full Stack developer stand out in a live coding interview.

Bias, bias, bias

A lot of candidates that I liked just played to my biases. They mentioned something I strongly agreed with. They impressed me by writing a reduce function on first try. They named a variable applesauce, etc. Despite our best efforts to address our biases, interviewing will never be fair and objective.

Now, to the actual traits.

Keep code green

Successful candidates tend to test their code often even if there are no actual tests. It can be as simple as refreshing the browser or printing a variable via console.log. As a result, code is always green (runnable), without random typos or unfinished pseudocode.

Show off without writing code

Candidates often trap themselves when they try to show off. I noticed that strong candidates prefer mentioning unessential code improvements (like useMemo) without actually implementing them. Usually interviewers are happy enough to move on and get an impression that the candidate knows how to code what they’ve just suggested. I’ve seen multiple times how this helped candidates pivot or extend code quicker because they kept it simple. It’s tempting to extract code into a separate function, file, or component, but great candidates know to delay it until absolutely necessary.

Know coding symbols names in English

Slow and error-prone coding without an AI assistant can be perceived as confident and professional if accompanied by clear communication of what’s happening. Knowing the names of all the common symbols is essential.

Engage the interviewer

A coding interview is supposed to focus on code, but at least half of its success lies in great communication. Clarifying the task and expectations, deciding on the approach, nailing the details, offering improvements and opinions - all of that affects how the candidate will be judged. Unfortunately, we all are biased, and what works for one interviewer may not work for another. Great candidates listen to signals from the interviewers and calibrate their communication style accordingly.

Confident coding basics

It’s difficult for candidates to communicate well if they are stuck mapping one array to another. Fluent knowledge of the basics of the language or framework frees up mental capacity for meaningful communication. For example, in a React exercise, the following can be considered the building blocks:

A functional component with typed props
useState
useEffect
Common JS Array functions (map, find, filter)
Promises and async / await

If all above sounds trivial, great! Just make sure you can code your way through those basics.

Keep a steady pace

Time constraint is real and it would be unfair to give “Don’t rush” advice. One has to rush to deliver meaningful results in the interview setting. Still, strong candidates somehow manage to keep a steady pace without creating a sense of rush.

Mention tests

The harsh reality is that very few developers write tests regularly. Strong candidates know how to bring up the topic of testing without necessarily applying TDD to the task at hand.

To summarise

Interviewing for Full Stack roles at small to medium-sized companies has its own specifics. For me, the key is to narrow my prep efforts to the right category of tasks and focus on the basics. Of course, coding interviews are just one part of the job hunting process. I found the recent “An Engineering Leader’s Job Search Algorithm” extremely thorough and relevant. I hope this article complements it well for those who are looking at Senior Full Stack roles specifically.

“Balancing Coupling in Software Design” (book review)

Mon, 14 Oct 2024 00:00:00 GMT

“Balancing Coupling in Software Design”, the new book by Vlad Khononov, can be summarised by one logical expression:

BALANCE = (STRENGTH XOR DISTANCE) OR NOT VOLATILITY

If that seems a bit cryptic, don’t worry. Throughout this article, you’ll have a chance to play with each variable from the expression and get a sneak peek of the Balanced Coupling model. Inspired by Vlad’s approach to balancing theory and practice in his book, I’ve added little quizzes to test your software design intuition. If you’ve already read the book, use them to check yourself!

Let’s get started with the first variable, or shall we say, dimension of coupling.

Integration Strength
Distance
Volatility - coupling in the dimension of time
Balancing and re-balancing
Fractal geometry of software design
To summarise

Integration Strength

At the core of the book is the new model for evaluating the strength of coupling. The stronger the coupling, the more knowledge is shared between modules.

Try to order Integration Strength levels from strongest to weakest:

Interactive content is not supported in RSS

To come up with these levels, the author analysed two existing models from 1970s (Structured Design) and 1990s (Connascence) and found that not only are they outdated, but they also have significant blind spots. To help us connect with the history, this part of the book includes code samples in Assembly, PL/I, and Fortran.

Integration Strength inherits the best parts of both mentioned models, modernises them, and addresses some of the gaps.

Let’s see if you can match situations on the right with their corresponding Integration Strength levels on the left:

Interactive content is not supported in RSS

Let’s see how much knowledge is shared between modules in the scenarios above.

Intrusive coupling

Instead of communicating through public interfaces, the downstream module communicates through, and thus depends on, the implementation details of the upstream module

The strongest level of coupling is all about hacking around to get the job done in ways never intended for integration. Patching an external library requires understanding undocumented internals and keeping the patched behaviour in mind when applying updates. It’s worth mentioning that sometimes it’s the only way to go.

Functional coupling

Functionally coupled modules share the knowledge of the functionalities they are implementing.

From a business perspective, checkout form validation is a single piece of work that must be completed before an order is placed.

On the technical side, however, a subset of this validation begins on frontend to provide a better user experience with fast visual feedback. If frontend checks pass, it’s time to run full validation on backend. Every time the form changes, both frontend and backend have to stay in sync regarding their validation rules. They are functionally coupled.

Model coupling

Model coupling takes place when the same model of the business domain is used by multiple modules.

If the previous levels share knowledge about behaviour, model coupling only shares knowledge about internal data structures. Typically, they are easier to reason about and change less frequently. In the example above, we used PostgREST to automatically expose a database table as REST API — handy! However, every time we rename or delete columns in our table, our API clients fail.

Contract coupling

Modules are contract coupled if they communicate through an integration-specific model

As Vlad puts it, a contract is “a model of a model”, a new level of abstraction that reduces amount of shared knowledge to the bare minimum. This makes contract coupling the weakest level of the Integration Strength model.

In our example above, OAuth 2.0 is a standard protocol for authorization. If you’ve ever worked with it, you may argue that it requires a great deal of knowledge and patience to integrate with it properly.

I intentionally chose this example to emphasise that contract coupling almost always involves overhead. Let’s revisit the PostgREST situation. To “upgrade” it to the contract level, we could introduce a database view that would serve as an API contract. This would allow us to evolve the original table structure (internal model) without breaking the API, but we would need to maintain the introduced view.

Now that we can reason about the first variable in the Balanced Coupling equation, let’s move on to the second one:

BALANCE = (STRENGTH XOR DISTANCE) OR NOT VOLATILITY

Distance

Again, let’s start with a quiz. Sort the following encapsulation boundaries from the least to the most distant:

Interactive content is not supported in RSS

In addition to the levels listed above, there are hidden levels that we humans create when working in groups.

The greater the ownership distance, the higher the coordination effort needed to implement changes affecting multiple modules. Consequently, the perceived distance between the modules also increases accordingly.

For example, full stack web developers often reduce the distance between frontend and backend by using monorepos, sharing types, or even pieces of code between the two services. Sometimes this works out great, while other times it turns into a nightmare.

Returning to the Balance equation, it has something to do with STRENGTH XOR DISTANCE. Time to look deeper!

You may have noticed that the expression uses boolean values. This is good enough for grasping the main trends. The book also introduces a hypothetical numeric scale to illustrate the nuances.

Map boolean Strength and Distance values to the corresponding situations on the left:

Interactive content is not supported in RSS

Let’s walk through all the combinations of STRENGTH and DISTANCE to see what we find. Click on the blurred items below to reveal the answers.

	Low distance	High distance
Low strength	Interactive content is not supported in RSS	Interactive content is not supported in RSS
High strength	Interactive content is not supported in RSS	Interactive content is not supported in RSS

Red items above reflect complexity while green ones contribute to modularity of the system. Apparently,

STRENGTH XOR DISTANCE = MODULARITY

Of course, the book goes deeper into the topics of modularity and abstractions, referencing Dijkstra, David Parnas, and John Ousterhout! It does the same with the topic of complexity by looking at phenomena from various angles including the Cynefin framework.

For now, let’s move on to the final variable in the equation:

Volatility - coupling in the dimension of time

Imagine a strongly coupled system. One, in which all components share excessive and extraneous knowledge across their boundaries. Even intrusive coupling is there. […] But if the components will never change, does the potential for cascading changes even matter?

Volatility reflects the frequency with which a software module changes. But how can we predict the frequency of changes without knowing future requirements? Vlad, who also happens to be the author of one of the best books on Domain-Driven Design, suggests deriving volatility from the type of DDD subdomain. The new book also includes a quick recap of DDD subdomain types if you need a refresher.

Now, try to guess expected volatility for each subdomain type:

Subdomain	Competitive Advantage	Complexity	Volatility
Core	High	High	Interactive content is not supported in RSS
Generic	Low	High	Interactive content is not supported in RSS
Supporting	Low	Low	Interactive content is not supported in RSS

It’s worth noting that as the business evolves, new subdomains may emerge, and existing ones may change in type. In addition, volatility can be influenced by team communication patterns, reorgs, and growth.

Balancing and re-balancing

Back to the Balance equation, it’s time to put all the variables together:

BALANCE = (STRENGTH XOR DISTANCE) OR NOT VOLATILITY

We’ve already discovered that the first part of the equation means modularity, the opposite of complexity:

BALANCE = MODULARITY OR NOT VOLATILITY
BALANCE = NOT COMPLEXITY OR NOT VOLATILITY

There is one more way to express it. Give it a try:

Interactive content is not supported in RSS

Volatility makes modularity optional. It’s okay to have a big ball of mud as long as it rarely changes. In other cases, we can tune strength and distance to achieve modularity. Examples of balancing (and rebalancing) are my favourite part of the book!

Since in this article I want to share my understanding of the book, I’ve prepared my own example.

Example: abandoned component library

The team is working on a new frontend for a project and realises that there will, in fact, be two different frontend applications sharing the same backend and visual language. To address this requirement the team identifies the following parts, each in its own repository:

Backend at backend.acme.com
UI component library at styleguide.acme.com
Frontend 1 at shop.acme.com
Frontend 2 at journal.acme.com

In theory, everything looks great. Each part is independently deployable, and the same visual language is promoted by the centralised component library.

However, the component library soon started to lag behind the actual look and feel of the application. In one instance, the design team was late for the demo and delivered a large piece of visuals without identifying atomic components. As a result, the developed UI components were not optimised for reuse.

In another instance, a tiny visual glitch was fixed directly in the application instead of being promoted to the component library.

Slowly, more and more visual work was done directly in applications code. The product team began raising concerns about visual inconsistencies and duplicated work between the two frontend applications. The UI library was practically abandoned. What happened?

High distance

In the initial design, all parts were equally distanced from each other by using different repositories. For example, the distance between Frontend 1 and UI component library was the same as the distance between Frontend 1 and backend.

At the same time, team structure didn’t quite reflect this, with one backend team and one frontend team (owning all frontend).

DISTANCE = High (True)

Functional coupling

In the Integration Strength dimension, every frontend feature required changes in two repositories: the UI component library and the application itself. The idea was to organically grow the UI component library as part of the applications development. That meant constant switching between the two repositories:

Make a change to the UI component library
Release
Make a change to the application
Realise the UI component has to be slightly adjusted
Repeat

STRENGTH = High (True)

Volatility

While the complexity of the frontend applications wasn’t high, they had to evolve at extreme pace: all new features were first implemented as frontend experiments, and only after validating user interest were they properly built on backend.

VOLATILITY = High (True)

As you can see, all three variables are high, indicating that the system is not balanced. In fact, this state of the system is called pain, or, in other words, high maintenance effort. Time for another quiz: try to complete the following equation:

Interactive content is not supported in RSS

Self-regulation

Without realising it, the team “rebalanced” the system by quietly abandoning the UI component library.

Better solution

The self-regulation caused issues with product quality. To mitigate this, the team reduced the distance between the UI component library and the frontend applications by merging all frontend repositories into one monorepo. Coincidentally, this also reduced the distance between the two frontend applications. But that’s a story for another time.

The book contains dozens of detailed examples and case studies that help to fully understand the Balanced Coupling model. In a couple of them, the author admits that rebalancing doesn’t always bring value; local complexity reappears at a higher level as global complexity and vice versa. Luckily, the solution is right in front of us:

Fractal geometry is nature’s way of mitigating complexity.

Fractal geometry of software design

Early in the book, Vlad draws our attention to a rather obvious fact:

A system’s component is almost always a subsystem in its own right. It consists of its own internal components, interacting to achieve its goal. Or, as Tim Berners-Lee put it, any system is a component in another, larger system

Closer to the end, the book beautifully connects this idea with the new coupling model by introducing Fractal Modularity. Regardless of the level of abstraction we operate at, Balanced Coupling serves as a self-similarity principle at all levels.

To summarise

Before discovering the Balanced Coupling model, I had a very vague understanding of the coupling phenomena.

Once, I was asked to duplicate an algorithm for calculating premium subscription in two different microservices. It was the easiest way to get job done - copy paste 3 lines of code. The system in question was in the process of decoupling from the legacy monolith, and we were going to make it worse by duplicating business logic in two separate modules owned by two different teams. Not knowing how to convince the teams to rethink the approach, I simply gave up.

The “Balanced Coupling” book refines our engineering language, enabling more productive conversations not only about coupling, but also about complexity, modularity, maintenance, stability, cost, growth, and innovation. Now it’s our turn to have these conversations, apply the new model in practice, and see how it works.

Thanks for making it this far! I hope you enjoyed the little quizzes. Here’s the last one for today:

Interactive content is not supported in RSS

Resources

React Alicante 2024

Wed, 25 Sep 2024 10:00:00 GMT

On this page, you can find a full list of all React Alicante 2024 talks with my short comments. A longer opinionated summary at the end.

Enjoy and feel free to reuse it if you need a summary for your team or employer.

Sessions - Day 1
Sessions - Day 2
My summary

Sessions - Day 1

17 high quality talks on React Server Components, Astro, SolidJS, a11y, and good old CSS!

Composition is King by Chance Strickland

@chancethedev

Despite the fact that React is shifting to the server, its core principles, composition and UI as a function of state, won’t go anywhere.

Enhancing Forms with React Server Components and React 19 by Aurora Scharff

@aurorascharff (slides)

A hands on demo of server components and actions in Next.js. Aurora popularizes RSC in her talks, workshops, and a blog where she publishes in-depth RSC guides. She also recommended me a case study talk from Tomas Jansson as an example of RSC in production (of course, in Next.js).

Debugging JS and React by Mark Erikson

@acemarke (older version of slides from 2023)

A good refresher on debugging techniques from Redux maintainer. I’ve never used console.table() or console.count() before. console.timeStamp() should be handy in profiling, too.

Building Complex UI with State Machines by Erik Rasmussen

@erikras (code)

Erik, who is most famous for redux-form and final-form, walked us through building a state machine for a search form using XState. In his unique style, he made me, my teammates and probably the whole audience fall in love with XState.

Astro Studio - All Secrets Reveiled by Elian Van Cutsem

@eliancodes (code)

An overview of all the latest Astro features: Astro Studio sunset and Astro DB, server islands and actions, Astro Starlight, community loaders, and I likely forgot something. Astro 5 is in beta, but the only missing bit is stable Vite 6 release.

The A1lyboros (maximizing code accessibility with Copilot) by Alena Nikolaeva & David Jensenius

@alenanik11 (slides)

The only way to ensure accessibility is through thorough manual testing. The speakers, who both work on Copilot at Github, raised the problem of bias in large language models. AI code generators don’t guarantee accessibility, but they still can be helpful for exploring the topic. Get started with this prompt shared by the speakers:

I need to learn about accessibility and need to write code that conforms with the WCAG 2.1 level A and AA
success criteria defined at https://www.w3.org/TR/WCAG21/. I want you to be my accessibility coach, a
subject-matter expert that makes me think and account for all accessibility requirements and usability
enhancements. When you answer questions about accessibility please use reputable sources such as w3.org,
webaim.org, developer.mozilla.org, and https://www.ibm.com/able/. When possible, please provide links and
references for additional learning. When you suggest code please use semantic HTML, ensure it is operable
using the keyboard, follow WCAG 2.1 sufficient techniques, and follow the ARIA Authoring Practices Guide
and related design patterns. Do you understand these instructions?

Enhancing your Static Sites with React Server Components by Akash Hamirwasia

@blenderskool

Every static site eventually needs more dynamic data fetching, and it’s historically been a pain. On a simple example, Akash demonstrates how RSC dramatically simplify the process and render previous tricks like useStaticQuery from Gatsby or getStaticProps from Next.js obsolete. An earlier version of this talk is available in the author’s blog.

Making your own tRPC-like library by Gabriel Grubba

@gabrielgr

With end-to-end type safety provided by tools like tRPC, you can “dot your way into it” without ever leaving your IDE. But how does tRPC work? Gabriel suggests implementing one yourself to understand the magic. The constraints of a lightning talk, unfortunately, didn’t allow me to catch the details.

Diagrams you need to know by Jenny Truong

@jen_ayy_ (slides)

Non-technical lightning talk from a stately team member with tons of links to diagram drawing services. I only managed to capture https://dbdiagram.io/ and https://www.tldraw.com/. Checkout the slides for more!

Using events and modern state management tools to clean up local-first logic by Wojciech Ogrodowczyk

@sharnik (slides)

What makes some products really great? They solve a hard problem for their users, often employing a non-obvious technical approach, like event sourcing for an imaginary TODO app. As another example, Wojciech references a talk from Liner about local-first approach.

Dude where is my password? by Miquel Company

@solilokiam (demo / repo)

Miquel explained how passkeys work by building an app with SimpleWebAuthn and Next.js. While passwordless approach is much more secure, Miquel admitted that after years of memorizing passwords, users don’t feel confident in getting rid of them. Popularization talks like his are a great way to spread the word.

Let’s build everything! The chaos of pet projects by Mikhail Korolev

@mkrl__ (slides)

A mix of art and technology from someone who broke two arms in an bicycle accident just before the conference. Misha is the king of pet projects and shared how he manages his projects from the initial idea to the finish line. Talks like this make in-person conferences special, and it’s impossible to fully capture their vibe in text or video.

How to make cheap e2e tests by Anastasiia Dragich

@nastia_dragich

Playwright won, and we all run hours of end-to-end tests in our CI pipelines. Nastia shared how she makes them much faster by mocking backend APIs. She calls this type of tests “isolated integration tests”. I also learned that Playwright has webServer config to start background processes before running tests.

3D Models on the Web with React Three Fiber by Thomas Derflinger

Web: https://tderflinger.com/

An interactive intro into React Three Fiber for rendering 3D models in the browser. Thomas also has a blog post on the same topic.

A Schema is all you need! by Mattia Manzati

@MattiaManzati (slides)

Yes, TypeScript is great, but it doesn’t help in the good old JavaScript runtime. Solutions like zod improve the situation, but don’t fully solve it. Mattia demos the power of @effect/schema by building an encoder and decoder for a simple Todo item schema. I also learned about property-based testing with fast-check.

Signals: What, How, and Why! by Atila Fassina

@atilafassina

Atila stepped up on short notice to replace a cancelled talk and delivered a high-quality deep dive into signals in SolidJS and beyond. I learned about lazy vs eager signals, performance optimizations in Solid and upcoming SolidHack event.

One App Fits All: Building Responsive Experiences in React by Kateryna Porshnieva

@krambertech

Kateryna reminded us that we may not need JS at all with the power of modern CSS. She built a responsive app interface using Utopia fluid design approach, clamp() CSS function, CSS grid, container queries, ch units, hover, pointer, and prefers-reduced-motion media queries. As an example of UI that does require JS, Kateryna built a fully fluid navigation bar using ResizeObserver.

Sessions - Day 2

Another 17 talks on React 19, TypeScript, React Native, soft skills and more

useWat by David Khourshid

@DavidKPiano

React library (or framework?) is far from being perfect. With humor and kindness, the author of XState walked us through some of the weirdest React parts that we learned to accept as a norm. In all this mess, it’s best to stop worrying about the latest React features and instead focus on building great products for our users.

From Chaos to Clarity: Design Patterns for Scalable Software by Joana Santos

@joanamcsa

Nobody expected a design patterns talk to include YMCA dance and life advice on how to be yourself. Joana definitely knows how to keep the audience engaged.

Type-Safe React with OCaml: A Practical Guide by Dillon Mulroy

@dillon_mulroy

Dillon shared his passion for OCaml and walked us through a simple OCaml code example. OCaml ecosystem is rapidly evolving and becomes more approachable thanks to the tools like create-melange-app created by Dillon.

Full Stack Form Validation with React Server Actions by Evyatar Alush

@evyataral

The author of a very interesting form validation framework Vest gave us a live demo of how to get started with it. Server actions supported!

Continuous Improvements of The Code Review Process by Keren Kenzi

Blog: https://medium.com/@KerenKenzi

An overview of code review practices, also available in Keren’s blog.

Chaos Mode - Finding & Fixing Race Conditions by Forbes Lindesay

@ForbesLindesay (slides)

Forbes provided a great visual explanation of a race condition bug using a search-as-you-type widget as an example. He suggested a method to catch race conditions by introducing random fetch delays, which he calls “Chaos Mode”. Then, he showed the wrong, the right and the fast ways to fix the issue. State machines are mentioned again!

React is turning 19! by Nikhil Sharma

@niksharma1997

An overview of all the latest React 19 features including React Compiler (which is not part of React 19, technically speaking).

From mentee to mentor: the art of asking questions that accelerate careers by Kate Marshalkina

@kalabro (video, slides)

I had the pleasure of giving a lightning talk, which can be summarized as: “Don’t give advice, ask more questions.” More on my speaker experience at the end of the post.

Covid fairytale: Building a React Native App to find a toilet roll during pandemic by Aris Markogiannakis

@arismarko (slides)

A story of building a fun React Native app as React developer including some details on Prisma and Expo.

Speed at Scale: Optimizing The Largest CX Platform Out There by Matheus Albuquerque

@ythecombinator (slides)

While conferences focus on bright new things, at work we often deal with legacy codebases, outdated tools, and slow applications. Matheus shared an in-depth case study on optimizing the performance of a large legacy app (React 15, Webpack 1, Node 10). The content was too extensive for a lightning talk, but fortunately, the slides contain all the references. Highly recommended!

The easy way to Full Stack by Dani Coll

@dani-coll

Dani sets the stage by sharing dozens of full stack job postings in companies of all sizes. Despite common view, companies do hire full stack engineers. It can be an interesting and fulfilling career path but how to get there? By following our interests and picking small tasks at work beyond our common responsibilities.

Sweet, savory, and fresh! Accessible design system Storybook tests by Kathleen McMahon

@resource11

Kathleen made us all smile even though the stats she shared were not so fun: the more aria labels developers add to webpages, the more accessibility issues they introduce. One way to improve accessibility of React components is to use Storybook built-in tools. They can’t replace manual testing, but at least it’s a good start.

Types, TypeScript and the JIT by Daniel Minor

@dminor (slides)

Daniel works on SpiderMonkey, a JavaScript engine that powers Firefox. In his lightning talk, he touched on the theory of types, soundness vs completeness, and how a JavaScript engine executes our code.

The Shape of Frameworks to Come by Daniel Afonso

@danieljcafonso

An intro to SolidStart, a meta-framework for SolidJS. In contrast to some other frameworks, it aims to mitigate the vendor lock-in issue by using a composable architecture, where each piece can be replaced with a different implementation.

How you can Server-Render without Rendering on the Server by Eric Vicenti

@EricVicenti

Eric presented Rise Tools, a framework for building mobile apps that are heavily controlled by the server. With a live coding demo, we all saw in action how a mobile app can be updated in real time. Very cool! If Rise Tools takes off, we will have a new way to quickly build and test our mobile app ideas.

Evolving Game Development with Genetic Algorithms by Kevin Maes

@kvmaes (slides)

Kevin shared how he built a game using genetic algorithms to evolve the complexity of game levels. It was fun to listen to his story full of interesting learnings, little details, and funny episodes. I’m impressed by the amount of work required to build a game from scratch. All code is available on Github. Of couse, powered by XState!

The Illusion of Success: When Delivering on Time is not Everything by Paulina Chojnowska

Slides

A lot of wisdom about software development processes delivered through a set of funny stories. As a community, we all agree on the importance of work-life balance, the dangers of tech debt, the power of prioritization, and the synergies of teamwork. Yet, things often go wrong. Paulina’s talk was a great reminder that our jobs are not only about code. That’s why we probably won’t be replaced by AI anytime soon.

My summary

React Alicante is known for its smooth organization, international speakers, and a long list of diverse talks. This year, the conference hosted 18 full talks, 16 lightning talks, and 12 workshops—a massive volume of content! Many speakers, sponsors and attendees return year after year, which is a sign of a great community. For me, it was the second React Alicante in a row, and this time I returned with a lightning talk!

Speaker experience 📣

I’m extremely greatful to the conference organizers for the opportunity to speak. It was interesting and challenging to prepare a 10 min non-technical session on a topic that I could talk about for hours. Inspired by several other talks (1, 2), I decided to build my presentation around one simple idea: ask more questions. This way I could keep it focused and hopefully useful even for people who were not interested in mentorship.

If you want to learn more about my mentorship experience, please check out my article “Where to find a mentor”.

Technical issues ☠️

This year, I paid more attention to technical issues because I was concerned about them as a speaker. It turned out that a tiny technical issue can ruin a talk. As a speaker, it’s easy to start panicking and lose the vibe. The audience quickly picks up on this and becomes disengaged. Experienced speakers had video recordings of their live coding pieces in case something went wrong.

Videos 🎥

All sessions were recorded and will be available on YouTube. While waiting, please feel free to check out videos and my report from 2023.

Tidy first? (book review)

Sun, 21 Jan 2024 21:00:00 GMT

Tidy First? sets a new standard for software design books. The author, Kent Beck, proves that it’s possible to write about software design in a concise and practical style. Reading it was a pure joy, and I’m looking forward to the next parts.

Below are a few highlights from my reading. For a more comprehensive review and three full chapters from the book, check out this article by Gergely Orosz.

Human-centred

Throughout the book, Kent offers several definitions of software design, with the following being reiterated a few times:

Software design is an exercise in human relationships.

The first book in the series focuses on the programmer’s relationship with themself. We all can afford 30 min for tidying up between the tasks to make our own coding experience more pleasant.

Start with yourself.

Leave the code a little better than you found it.

The book presents 15 types of tidyings and explains how these can be integrated into a programmer’s day-to-day without much hassle.

The next books in the series promise an even stronger emphasis on human relationships as Kent plans to zoom out to team-level and organization-level software design activities.

“All problems are interpersonal relationship problems” from “The Courage to Be Disliked” applies to software too.

A Philosophy of Software Design

It has become a tradition to mention John Ousterhout’s book in every software design article on this blog. Below is an excerpt I found in the annotated reading list at the end of “Tidy First?”:

Ousterhout, John, A Philosophy of Software Design, Palo Alto: Yakmyam Press, 2018

This is the book that got me off my butt writing. John’s points are well taken about making design better, but they are presented dogmatically — always keep your code as clean as you possibly can. The question mark in Tidy first? is a direct response.

In a way, “A Philosophy of Software Design” is more beginner-friendly precisely because of its dogmatic approach.

“Tidy First?” reminds me of a teacher’s textbook. It provides a basic foundation for an imaginary software design class, leaving it up to the “teacher” to expand on the book’s ideas. In practice, senior and staff engineers often play roles of teachers and mentors. For them, “Tidy First?” could serve as an excellent inspiration.

Economics of options

In the final part of the book, Kent Beck draws an interesting analogy between the economics of options and the ever-changing nature of software:

“What behavior can I implement next?” has value all on its own, even before I implement it. This surprised me. I thought I was getting paid for what I had done. I wasn’t. I was mostly getting paid for what I could do next.

As Kent explains, software design has to reconcile the economic imperatives of “earn sooner/spend later” and “create options, not things”. On one hand, we want to sell more now, on the other hand, we want to prepare for future change, i.e. create more options.

As money directly affects how we build software, clarifying the relationship between money and software design is a wise idea.

To summarise

Kent Beck, who is famous for inventing Extreme Programming and (re)inventing Test-Driven-Development, has authored a beautiful little book on the daily practice of software design.

The book didn’t waste a single minute of my time. Even the introductory sections were packed with useful ideas. For instance, the intro to the Theory part explained how the theory might be actually useful in practice.

Last but not least, it has a beautiful cover. Highly recommended!

My tech year in review (2023)

Mon, 25 Dec 2023 17:00:00 GMT

This type of post is more useful for the author than the reader, so feel free to skip to the comments. Whether you are my reader, teammate, mentee or mentor - I’ll be super happy to receive a comment or a thumbs up from you.

Happy holidays, and see you next year!

Below are some highlights from my year in tech:

Mentorship

This year, I’ve delivered 1000+ mentorship minutes on ADPList, plus a couple of paid sessions on codementor and topmate. At the same time, I was lucky to find a great long-term mentor for myself. Highly recommend a longer commitment over a one-off chat!

The most common topics discussed in my sessions were job hunting and breaking into tech. While we expect more layoffs and hiring freezes in 2024, I’m optimistic about long-term opportunities in our field. Mentorship is one of the tools to spark and maintain the positivity and self-confidence necessary for overcoming the challenges of 2024.

Finally, I recommend the Coaching Habit book to everyone who wants to better support and empower others.

Coding

In 2023, I doubled the volume of my code contributions. Solving problems with code is something that brings me pure joy.

This year, I had a chance to work on frontend and backend, from microservices to microfrontends, with classic databases and asynchronous messaging mechanisms. I discovered my natural ability to navigate foreign codebases and pick up new tools quickly. I’m an okay coder, but with much more practice (and Copilot), I made great progress this year.

After reading that last line, you may think that I’m being humble. Yes and no. I somehow have never needed to be very good at programming, but at the same time it’s part of my job that I admire the most.

Writing

It’s been a good year for this blog. Below are all the articles I published in 2023:

On soft skills:

On software design:

On tools:

On events:

If you had a chance to read some of them, which was your favourite?

New job

After joining New Work as a Senior Frontend Engineer (technical interviews are easier for specialists 🤷‍♀️) I immediately transformed myself back to Full Stack and received the highest rating in my recent performance review.

I approached my new job as a giant learning class and took every opportunity to test my skills. The list of tools I touched is enormous. My favourites are Turborepo, MSW, Nest.js, GraphQL Mesh, Datadog and ArgoCD.

My least favourites are all Microsoft products. Luckily, not all my communication happens in Microsoft Teams. I enjoy going to the office from time to time, having a long lunch with teammates, or giving a talk for a local meetup.

I also realised that my style and energy may have disturbed a few colleagues, and I hope they will forgive me. Working in a large company has helped me understand that every developer is different, with different strengths, motivations and life situations.

Tools

In 2019, I had a similar post listing my main tools at work. Surprisingly, they haven’t changed much:

Macbook Pro M1 (14”/16”)
Firefox and Chrome (but I try to avoid Chrome)
BetterTouchTool
VS Code
ChatCPT & Copilot (new)
Docker
iTerm (my approach to the command line)
PhpStorm (still using for some tasks)
Evernote
1Password
Remarkable (new)

What’s next

2023 has been one of my best years in tech. I re-discovered the joy of web development, met many like-minded people and laid a foundation for the next steps.

Speaking in DDD terms, I aim to work more on the “core” subdomains, i.e. complex business problems. Opening a hundred pull requests is easy, making a real organisational impact is harder.

One way to make my work more impactful is to increase scope, e.g. zoom out to the architectural level. For that, I’ll continue exploring software design practices and common system design patterns.

On the other hand, I want to explore less safe ways to do things, e.g. bringing new ideas, experimenting, and questioning the status quo. For that, I wish myself, and all of us, a lot of courage, creativity and self-confidence in 2024.

Let’s have a fantastic new year! 🎄

Advent of Frontend Architecture - supporting materials

Wed, 20 Dec 2023 17:00:00 GMT

Below you will find supporting materials for my lightning talk, “Advent of Frontend Architecture”, at the BarcelonaJS meetup.

Patterns

Patterns.dev - frontend-friendly book on design patterns
Learning JavaScript Design Patterns - supporting materials for the second edition of the book by Addy Osmani
Feature-Sliced Design - opinionated folder structure for bigger frontend projects (alternative to Clean Architecture)

Practices

🥂 Pair tech concept

Two developers are brainstorming an implementation plan on a call. A good alternative to pair programming in fully remote environments.

🍻 Design it twice

Fully spec out first version of your implementation plan. Put it aside and try to spec out an alternative version. Compare the two to come up with the final version.

🎊 Throw away

Without any thorough planning, go ahead and implement the first quick & dirty version. Throw it away. Spec out a proper implementation plan based on your learnings.

🪐 Don’t change jobs

Stay on the same project until your own decisions come back to you in the form of poor, unmaintainable code.

Books

A Philosophy of Software Design - my favourite software engineering book
Learning Domain-Driven Design - good introduction to DDD (my review)
Thinking Architecturally (my review)

Back story

This talk is based on “The road to Software Architecture (frontend edition)” article and is inspired by CSS Christmas Calendar website.

A little promotion: If you need a hand on your journey, I’m offering both free and paid mentorship sessions.

Learning at work: common obstacles and how to overcome them

Fri, 20 Oct 2023 08:30:00 GMT

Every developer I’ve met during my mentorship sessions was striving to learn. Yet, many felt stuck in their careers. When debugging growth obstacles with them, I always start by exploring “learning at work” opportunities.

It’s common to treat learning and working as two separate activities. First, a developer invests time in acquiring missing knowledge. Then they go and happily complete their task at work. Ideally, others only witness the latter part and perceive them as an expert.

Reality is different, though, and I often hear developers complain they can’t learn at work:

“I don’t have time to learn at work”
“I work on a legacy project”
“My company doesn’t use technology I want to learn”
“We don’t have a learning culture”
“I’m the only frontend developer in the team / I have nobody to learn from”
“I don’t have a side project”

These are all common circumstances for many of us. I have experienced all of them myself, and will address each later in this article. But first, let me name a few benefits of learning at work:

Benefit 1: Focus

For over two years, I was learning TypeScript in background while still writing production code in JavaScript. Then, I threw myself in a 100% TypeScript project at work and mastered it within a couple of weeks. My work environment helped me radically focus on what I wanted to learn.

Benefit 2: Real-world problem

Back to my TypeScript example, I had practical problems to solve, and they served as real-world exercises to test my new skills.

Benefit 3: Deadline

Working in short sprints introduced internal deadlines that forced me:
a) to be realistic about what I can achieve
b) to finish at least one task per sprint

Benefit 4: Supporting network

When I got stuck, I could ask more experienced developers for help and fast-track my learning (or learn together if my question puzzled them too).

Benefit 5: Healthy dose of discomfort

Not knowing where to start felt shitty. I was willing to go the extra mile to overcome this discomfort. The term “hardworking” is out of fashion these days, but that’s often required to learn topics deeply.

Benefit 6: Time

I spend 8 hours every day at work, 40 hours per week. With a bit of effort, I can balance productivity vs challenge in my workload and keep learning organically.

Many employed developers can access all those benefits at their jobs. I learned to appreciate and use them to my advantage.

Now, let me go back to the list of common obstacles and share how I think about them now:

⏰ Obstacle 1: I don’t have time to learn at work

For me, developer efficiency is not about working faster. It’s about doing repetitive chores and basic tasks faster so that we can spend more time on difficult ones.

Everyone’s favourite example is unnecessary meetings. But it can also be a buggy dev environment that slows down every code change, broken communication between dependant teams, or gaps in business domain knowledge. If basics are broken, everything becomes more difficult.

Another source of time is personal budget. I don’t mind borrowing a little if I’m passionate about a task at hand. I never regretted late evenings debugging an intriguing issue or polishing documentation for a new feature. I have only warm memories of those occasional spikes of energy and dedication. I wouldn’t necessarily recommend this approach to everyone, but it feels necessary to mention it in this article.

But my primary source of time for learning is hidden in this quote:

Software Engineering is a learning process, working code is a side effect (Alberto Brandolini)

As software engineers, we learn 100% of the time at work. You may be learning 40 hours/week without even realising it. It’s a good idea to regularly reflect on your past experiences and uncover any hidden learnings. In practice, deep work on any engineering task brings me new insights.

💩 Obstacle 2: I work on a legacy project

Due to frequent job changes, developers often depart from a company before their code becomes an unmaintainable ball of mud. Instead, they join a new company where they have to deal with someone’s else ball of mud.

When I think of my past struggles with legacy projects, two issues stand out:

Slow. They all were very slow to run, to build, to test. Such projects tend to have hours-long testing pipelines; otherwise, it’s too risky to implement any changes. As a result, even a minor modification can take days to release. I believe it’s never too late to optimise performance, particularly if you plan to support the project for awhile.

Complex. Legacy projects encapsulate tons of undocumented business logic. Developers often have to start making changes before familiarising themselves with all project features. Sometimes, it’s just too much to fit in one man’s head. Other times, people with knowledge may have already left the company. Either way, I’d spend more time watching how others use the project, reviewing git history, and asking around about the most confusing features. Nobody will be excited to talk about a legacy system. At the very least, I try to keep the conversation tone neutral.

Other common issues with legacy projects are spaghetti code, outdated technology, poor UX, lack of structure, low test coverage, inconsistent documentation. Finding your way through all these issues is a great software engineering lesson. It’s extra effective (and painful) if you were the one creating the mess several years ago.

⚛️ Obstacle 3: My company doesn’t use technology I want to learn

First of all, your tech stack of preference must intersect with the one of your employer. It’s heartbreaking to see JavaScript developers fighting with PHP (and vice versa). If you find yourself constantly battling against the tech stack, I recommend switching jobs.

Now, let’s consider a less extreme example. Imagine that I want to learn Clojure. It’s a respected language with a high developer satisfaction rating. I have a friend who happily transitioned from PHP to Go to Clojure, and I believe I can too! As a Full Stack developer, I’m easily attracted by this kind of thing! However, to be honest, I don’t have a lot of tasks at work that would be a good fit for Clojure.

In such a situation, I would question why I want to learn Clojure when several other opportunities are available at my current company. Depending on the answer, I might decide to explore Clojure in my spare time or choose another language to feed my curiosity.

As a side note, I’ve never experienced disgust towards any particular technology. Clojure is cool, and PHP is cool, too.

👺 Obstacle 4: We don’t have a learning culture

The mindset I describe in this article doesn’t require any specific culture. Thinking in such bold terms can create unnecessary frustration. Instead, I would begin by adjusting my own approach to learning at work, and see if others want to join me. It’s perfectly okay if they choose not to; it shouldn’t change my plans.

🐺 Obstacle 5: I’m the only developer in the team / I have nobody to learn from

Junior developers often find themselves in smaller companies with just a few other developers. In a similar situation, I doubled down on learning from a local web community. It was different from working in a strong dev team, but still very fruitful. Many autonomous full stack developers have grown up in such environments.

🧶 Obstacle 6: I don’t have a side project

I don’t have one, either. I’ve made several attempts but quickly abandoned them. I genuinely admire developers who build side projects, commercial or open source, practical or crazy. I’m not one of them, and that’s fine.

I’m more driven by the idea of contributing back to the web community. Nowadays, I write articles and provide mentorship.

Go discover what works for you; it doesn’t necessarily have to be a side project.

To summarise

If you are willing to find learning opportunities, you will find them in almost any company. Working environments create perfect conditions for learning:

🎯 focus
📊 real-world problems
⌛️ deadlines
🤝 supporting network
🤪 a healthy dose of discomfort
⏰ time

With the right attitude towards common learning obstacles, we can continue growing without side projects, frequent job changes, or expensive training sessions.

I will conclude with one of my favourite quotes:

“Software Engineering is a learning process, working code a side effect.” (Alberto Brandolini)

I hope you enjoy the never ending learning curve and get the maximum out of it!

A little promotion: If you need a hand on your journey, I’m offering both free and paid mentorship sessions.

React Alicante 2023

Sun, 01 Oct 2023 20:00:00 GMT

On this page, you can find a full list of all React Alicante 2023 talks with my short comments. If you want a longer opinionated summary, it’s at the very bottom.

Enjoy and feel free to reuse it if you need a summary for your team or employer.

Sessions - Day 1
Sessions - Day 2
My summary

Sessions - Day 1

16 high quality talks on performance, accessibility, resumability, types, SolidJS, Playwright, Canvas, CDN & Edge, tRPC, React Native, codemods, MSW, React Query, and more. Great atmosphere, friendly people, and a lot of complaints about useEffect! 😄

React—The Good Parts by Tejas Kumar

Twitter: @TejasKumar_

A response to React haters (who were not really in that room 🤷‍♀️) full of cool “implement it yourself” demos from basic counter app to server components.

🌟 SolidJS for React Developers by Erik Rasmussen 🌟

Twitter: @erikras
Slides: https://speakerdeck.com/erikras/solid-for-react-developers

As I’ve been using react-final-form from Erik for a while, I trust his opinion on Solid. He managed to get the audience up to speed with Solid in 30 minutes, comparing Solid and React side by side and highlighting some non-obvious things. Apparently, the syntax is almost the same but the devil is in details.

Playing your tests wright by Debbie O’Brien

Twitter: @debs_obrien

Another reminder that the testing pyramid is in the past. End-to-end tests are the most reliable way to ensure your app really works, and the tooling is there to make it happen. I agree with the general message, but I may not be as attached to Playwright as Debbie.

Type safety from the database to the frontend by Forbes Lindesay

Twitter: @ForbesLindesay

Code-heavy talk on getting your types right in different parts of the stack from databases to untyped external APIs and everything in between. We even looked at some Rust code. As a bonus, I learned that I can write numbers with underscore symbol in JavaScript:

const oneMillion = 1_000_000;

Building Text Containers in Canvas by Aakansha Doshi

Twitter: @aakansha1216
Slides: https://docs.google.com/presentation/d/1INBB7oE0tI3SFGK5t65ThWXc0lO3hQ_utVBntKyUyog/edit#slide=id.g24789271ec1_0_0

A deep dive into canvas from Excalidraw developer. I appreciated the level of detail and how Aakansha broke down the problem into smaller, understandable pieces. Canvas API reminded me of programmatic PDF manipulation from my past PHP experience. I’m glad I don’t have to deal with it anymore 😄

Pushing boundaries to the edge by Facundo Giuliani

Twitter: @facundozurdo

An intro into origin vs CDN vs edge for frontend developers. As I was already familiar with the topic, it was less interesting for me. Edge computing is more challenging in practice than it may sound in the intros. Still, I met quite a few attendees who enjoyed this overview from Facundo. Indeed, if you are on Vercel, it should be rather easy to start with edge.

tRPC - Better than REST/GraphQL? by Devlin Duldulao

Twitter: @DevlinDuldulao

Lightweight intro into tRPC. The talk wasn’t actually diminishing REST or GraphQL as it may look from the title.

Common Pitfalls in React Native Apps and How to fix them by Dan Neciu

Twitter: @neciudan
Slides: https://drive.google.com/file/d/1Tw4ojP3iNFe2UdT_xzYvvIWxtcNQOwkt/view

A couple of gotchas from Dan’s experience with React Native, such as lack of localStorage, how to correctly import fonts and render HTML, etc. It was interesting to compare it with my Flutter experience as a React developer.

Maximizing React Performance with DevTools: Profiler and Components by Jelena Maravic

LinkedIn: Jelena Maravic
Slides: https://www.canva.com/design/DAFnrN1Ls5g/view

This short talk was packed with React performance tips and tricks. In practice, developers often fear profiling tools, and I would love to see more presentations popularizing them.

Codemods - how to support your users with breaking changes delivery by Łukasz Nowak

GitHub: @lukasznowakpl
Slides: https://github.com/LukaszNowakPL/codemods/blob/main/%5BEN%5D%202023-09-29%20-%20React%20Alicante%20-%20Codemods.pdf

A hands-on example of using codemods to help users overcome breaking changes in your library. Apparently, tools like jscodeshift make it, if not easy, then at least doable.

Seek, and you shall find your way to fun! by Kevin Maes

Twitter: @kvmaes

Kevin presented his side project, which he built just for fun (and also to learn some fancy graph algorithms that we wouldn’t usually use in our React apps). You can find the code here on GitHub.

Crafting Accessible Components for Component Libraries by Mathilde Buenerd

GitHub: @mathildebuenerd

Mathilde opened a series of accessibility talks at React Alicante with React-specific tips on accessibility, such as React.forwardRef for overcoming focus issues, or React.AriaAttributes to enable aria-* attributes on library components.

The State of GraphQL Clients in 2023 by Roy Derks

Twitter: @gethackteam

A short and practical overview of GraphQL clients’ space, with special attention to Relay. As I’m relatively new to GraphQL, I found this talk informative.

🌟 Hydration, Islands, Streaming, Resumability… Me, Oh My! by Matheus Albuquerque 🌟

Twitter: @ythecombinator
Slides: https://speakerdeck.com/ythecombinator/react-alicante-2023

A thorough walk-through with tons of historical references and technical details. I bookmarked the slides to review the links later. Given how hot this space is right now, I appreciate the balanced, non-biased tone of this talk.

All you need is a contract… by Daniel Afonso

Twitter: @danieljcafonso

Daniel is clearly a big fan of Mock Service Worker and React Query! I believe they are both defacto standards anyway. MSW received special attention as an amazing dev tool not only for running tests but also for parallelising backend and frontend development.

🌟 Practical guide to building accessible forms in React by Kateryna Porshnieva 🌟

Twitter: @krambertech
Slides: https://krambertech.notion.site/krambertech/Practical-Guide-to-building-accessible-forms-in-React-daba42af8f894223bbc8e184e532ed64

The best talk of the day and probably the best talk I’ve seen in a while. Kateryna is a pro at explaining complex topics in a simple, engaging way. Absolutely recommended.

Sessions - Day 2

Another 16 talks on AI, Solid, Astro, Qwik, ReasonML, state machines and more.

Why I Still Choose React by Chance Strickland

Twitter: @chancethedev

An overview of React past and present with funny 200-line useEffect examples from a seasoned React developer involved in Remix, React Training, Reach UI and other famous projects. SolidJS is mentioned again, but it’s clear that the audience still chooses React.
Chance rightly points out that if signals were a silver bullet, React would adopt them already. React’s main advantage is its mental (rendering) model, and there should be other ways to fix useEffect without sacrificing the beauty of the UI = fn(state) formulae.

Processes, StateCharts and WorkFlows by Mattia Manzati

Twitter: @mattiamanzati
Slides: https://mattiamanzati.github.io/long-running-process/1

A side track into the world of sagas, eventual consistency and state machines. I could make sense of the material thanks to Mattia’s creative analogies and my prior DDD knowledge. It may feel too advanced, but in fact, we all deal with more complex problems at work than the famous counter app.

Resumability in the next generation frontend framework With O(1) loading time by Ruby Jane

Twitter: @rubyjane88

A rather boring intro into resumability and its frontman Qwik. What impressed me, though, is how the React community is open to alternative voices and ideas in the space.

🌟 Server-side rendering React natively with Reason by David Sancho 🌟

Twitter: @davesnx
Slides: https://docs.google.com/presentation/d/150JjwU4HdtdWN_iT5MkvaKrQv3Dnj3OJCey-cRi3V9U/edit#slide=id.g7207e88d15_0_121
Blog post: https://sancho.dev/blog/server-side-rendering-react-in-ocaml

An active contributor to Reason/OCaml ecosystem explains the basics of ReasonML and shares a story of building server-reason-react. I wish there were more talks from active open source contributors who deserved their round of applause!

Bye-bye, weeds! Digital Gardening with Astro & MDX by Kathleen McMahon

Twitter: @resource11
Slides: https://noti.st/resource11/cegRnq/bye-bye-weeds-digital-gardening-with-astro-mdx

A story of upgrading a personal blog from Gatsby 2.3 to Astro. Funny enough, this very blog runs on Gatsby 2.4. I feel Kathleen’s pain, but maybe a dedicated talk at React Alicante is a bit too much for this topic. Anyway, I shortlisted Astro if I ever need to migrate from Gatsby.

Rendering Dilemma: Reacting to State Change by Atila Fassina

Twitter: @AtilaFassina

At this point, speakers started repeating each other with Solid comparisons, counter demos and UI = fn(state) slides. Nevertheless, Atila’s talk was well prepared, and I learned about React Forget compiler efforts (auto-memoisation) and Svelte Runes (signals in Svelte).

A comparison of Microfrontends composition techniques Module Federation (webpack, vite vs turborepo) by Aris Markogiannakis

Twitter: @arismarko
Slides: https://www.canva.com/design/DAFqwlKyZ5o/rn_f4K5wT41jbsR0e3XpYA/view

As it was a lightning talk, it only gave a quick overview of microfrontends concept. Aris compared Next.js multi-zones solution with Webpack Module Federation (which now has Vite support), and the latter won (no surprise).
Apparently, I missed a whole conference dedicated to microfrontends, but luckily videos are available on YouTube!

Accelerating Your Career: Becoming a 10x Junior Engineer by Joana Santos

Twitter: @joanamcsa

An exceptionally well-prepared lighting talk! I’m extra happy that Joana pointed out the importance of mentorship in tech.

Supercharging React Performance with SolidJS Signal by Subham Bhattacharjee

Twitter: @subhaminion

Unfortunately, the talk repeated 99% of what previous speakers had already covered.

Patterns for Making Accessible Components by Chris Cormier

GitHub: @LeviathanTheGreat

An organic continuation of the accessibility topic started on day 1. Chris took a couple of practical examples and walked us through making them accessible. Accessibility speakers coordinated well to avoid repeated content and at the end of the day I had a coherent understanding of the topic. Well done!

How To Build a Chrome Extension Using React by Adina Stoica

Twitter @adinutzyc21

A shorter version of Adina’s talk missed the React part but was still informative if you plan to build a Chrome extension.

You are not becoming rich with a mobile app by Stefano Solinas

Twitter: @obsidianart

Stefano shared the news from indiehackers space. Most side gigs fail, but even when they succeed in the first place, like Stefano’s Imagzle app, it’s a tough ride.

Reviewing code review - duty, fun or… revenge? by Paulina Chojnowska

Twitter: @AntariaPaulina
Slides: https://www.slideshare.net/Paulina218683/reactalicante2023paulinachojnowskapdf

Another perfect lightning talk on the challenges of a good old code review. Paulina nails it down to two questions: Does the code work? Do you like it?
A bonus: slides from Smashing Conference on Conventional Comments.

🌟 Making state management intelligent by David Khourshid 🌟

Twitter: @davidkpiano

An impressive yet easy-to-follow demo by David using xstate, ChatGPT and React. This talk was very much needed after so many counter demos!

Building Machine Learning Models on Edge with React by Shivay Lamba

Twitter: @HowDevelop
Slides: https://docs.google.com/presentation/d/1Eg4mdpc9-kvmk_yXUU0_mCkyzXs_jvHMqj5FR4URhKE/edit#slide=id.g2863585916f_0_1

A comprehensive overview of AI tools in the web ecosystem. Check the slides for tons of links from TensorFlow.js to Langchain to AI.JSX. I will definitely do as it will likely be part of my day-to-day job very soon.

Imperative vs Declarative: Weathering the storm by Kyle Simpson

Twitter: @getifyX

Kyle welcomed us to reconsider what we understand as imperative and declarative programming. He emphasised the importance of optimising code for reading, not for compiling. Unfortunately, he lost me in the second part of his talk as I was clearly overreacted.

My summary

It was my first conference entirely dedicated to React, and I enjoyed it a lot, even if my talk reviews may sound a bit picky. Sorry about that - I’m a demanding attendee!

In fact, I liked it so much that I put together this page to share useful ideas with my friends and colleagues. Here are they:

Sessions diversity and distribution 👩🏼‍💻👨🏾‍💻

All talks can be separated into inspirational speeches aka keynotes (1), overviews/getting-started guides (2), and specialised deep dives (3). To me, we had too many keynote-style sessions (1) and not enough advanced React-specific content (3).

The average quality of talks was very high. Speakers from various locations and with diverse backgrounds were presented.

Beyond React 💐

It was clear to me and everyone whom I met in Alicante that React will be around for a long time. The ecosystem is healthy, and there is no need to switch to another framework. Still, the React Alicante lineup responded enthusiastically to the rise of alternative frameworks. I’m returning to Barcelona knowing much more about Solid than I knew before.

Popular choices 📊

Based on a few conversations I had: Next.js, Typescript, React Query, Cypress, GraphQL (no surprises here)

Unpopular topics 🔻

State management, code structure / architecture, styling & UI libraries, forms - these topics were on hold as solved.

React Server Components were purely covered, even though performance was a hot topic. RSC adoption is low, too (again, only based on my conversations)

Organisation 👏

By the end of day 2 it became a tradition to clap to the organisers at the beginning of every talk. Indeed, the organisation was high class. I’m definitely returning next year!
Maybe with a lightning talk? 😄

Onboarding yourself as a Senior Software Engineer

Sat, 15 Jul 2023 18:30:00 GMT

The success of the onboarding process depends equally on both parties. There is plenty of advice for the hiring side. I used it myself when onboarding developers of various levels as a Tech Lead. Today, I want to share some tips from another side of the table. I recently onboarded myself at a new job using my learning from onboarding other developers. It worked out very well, with feedback like, “It’s the fastest onboarding I’ve ever seen”, “Your onboarding has been spectacular”, and “Don’t be such an asshole”. I’m also trying to get better at the “Two truths, one lie” icebreaker.

I attribute a lot of my success to a great team in charge of my onboarding. On my side, I did a few things well, too. In this article, I share the less obvious ones.

Get access

As dumb as it sounds, giving you access to critical tools and services needs to be done as soon as possible. Onboarding checklists usually cover access to tools like Jira or Toggl, and that’s okay. But what you really need is access to all the technical tools, from git and Jenkins to Figma and analytics. Chasing some accesses can be non-trivial due to special SSH key requirements or a gatekeeper person being on sick leave.

It’s crucial to get access to all possible observability tools. You can learn so much about your project from Datadog if you only have access and a willingness to explore.

Enable Sponge Mode

I had to consciously enable “Sponge Mode” for my first month in a new company. “Sponge Mode” means that you absorb new information without challenging the status quo. It’s important to note down inconsistencies, ideas for improvements, flaws in processes, etc. Later, you will be able to raise them with the team. But first, you need to understand how the current system works by observing it with curiosity. “Interesting” should be your number one reaction to awkward things. Also, start using the language of the org as soon as possible. If people call the staging environment “preview”, call it “preview” too.

Meet people

Go to the office, share a personal story, play “Two truths, one lie”, have a beer, and be yourself throughout the process. Building relationships and gaining trust takes time. It’s a good idea to show others that you are interested in building relationships. And you are, because software development is a team sport.

Ask different people the same question

During the first weeks, you have the privilege to ask stupid questions and get detailed answers. Try to build a multi-dimensional model of your new workspace by asking different people the same question. For example, ask a fellow developer, Product Manager, and UX designer what they think your team is building. You’ll likely receive three different answers, all correct in their own context.

Read source code

Often, code onboarding is delayed in favour of process onboarding. It’s an unfortunate obstacle that you must proactively overcome. Even when my first week was fully booked with meetings and bureaucracy, I dedicated an hour every day to reading source code. Sometimes I had to read code on a train from my mobile. It allowed me to build my own opinion on the codebase and collect my questions for more productive onboarding discussions.

Ultimately, it enabled me to start coding sooner and steadily increase the complexity of my tasks until I felt at home in my new project.

Setup tooling

You probably have your preferred IDE, clipboard manager, grammar checker, terminal, shortcuts, etc. It’s best to configure these little comfy things before you start coding. Be open to changing habits too. Pairing on a task is easier when the whole team uses the same editor.

Be useful

Usually, a newbie gets maximum attention in the first week or two, and then, slowly, everyone becomes busy again. It’s expected that Senior Developers will take responsibility for their onboarding and complete it themselves. My main advice here is to try to be useful. I couldn’t take on larger tasks at first, but I could review and test some completed tasks, update the repo’s documentation, configure Renovate, etc. There are always multiple ways to help your team, and the sooner you start being useful, the sooner you become part of the team.

To summarise

The first three months in a new company are very intense for a new employee. I encourage developers to embrace all that intensity and proactively onboard themselves using my tips above or other tested techniques. For me, they worked very well. Compared to my interviewing experience, the onboarding was a breeze. I’m looking forward to what’s next!

It depends! Exploring my favourite Renovate features for dependency updates

Sun, 18 Jun 2023 14:00:00 GMT

I learned about Renovate a couple of years ago when I was trying to group automated updates in Dependabot. It’s 2023, and Dependabot is still figuring out how to implement grouping. Not blaming them; dependency updates are challenging. Regardless of the approach you take, a fair amount of work is required to set up tools and processes for dependency management. In this post, I have collected a few of my favourite features and tricks when working with Renovate. Have I missed anything? Of course! Renovate is highly configurable (and well-documented), so if you need the full guide, please consult the official docs.

How Renovate works

Before delving into the details, let’s ask ChatGPT for a quick summary of how Renovate works:

Renovate is an open-source tool designed to automate the process of updating dependencies in a project. It works by identifying relevant package files within a codebase (including monorepos), then generating and scheduling pull requests to update those dependencies and their associated lock files. Users have the ability to customise the behaviour of the Renovate bot through configuration files and share configurations using ESLint-like presets.

The easiest way to get started with Renovate is to install it in your repo as a GitHub App:

Renovate will automatically open a “Configure Renovate” PR with meaningful defaults. Once the config file is merged, Renovate will start opening regular pull requests with dependency updates. In theory, that’s it. In practice, you’ll likely want to tweak the configuration and fine-tune it to suit your specific needs and preferences.

Feature 1: config presets

Renovate supports hundreds of configuration options, or at least it feels that way. The resulting configuration file, even for a simple app, can end up being huge and cryptic. Fortunately, Renovate provides config presets that allow you to abstract away the details and share config pieces across multiple projects.

One crucial config preset to be aware of is config:base. It enables core Renovate features such as the Dependency Dashboard and monorepo grouping (more on this later in the article). It’s a good idea to base your configuration on config:base or, in the case of JavaScript projects, on the config:js-app or config:js-lib presets.

Here is an example configuration for my personal blog powered by Gatsby:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json", // up to date schema with all supported properties
  "extends": [
    "config:js-app", // base on the recommended config for JS applications
    "schedule:monthly", // can be schedule:weekly, schedule:weekends, etc
    "npm:unpublishSafe", // the release must be at least 3 days old
    ":approveMajorUpdates", // require explicit update approval on the dashboard before opening PR
    ":maintainLockFilesWeekly" // regenerates lock file to update all indirect deps
  ],
  "transitiveRemediation": true // apply security updates for indirect (transitive) NPM dependencies
}

As it’s a JavaScript project, I used the config:js-app preset. I configured the update schedule, enabled the minimum release days restriction, disabled automatic PRs for major updates, and enabled weekly lock file maintenance. All using the default config presets. Thanks to JSON5 support, I can add comments to my config!

If I have multiple projects similar to this one, I can convert my new configuration into a preset and refer to it in the config of the other projects:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "github>kalabro/kalabro.tech//renovate/js-app" // loads my base config from another repo
  ],
  // Further extending config for this specific project
  "postUpdateOptions": ["yarnDedupeHighest"]
}

It assumes that my shareable config is available at https://github.com/kalabro/kalabro.tech/renovate/js-app.json. As you probably guessed, you can keep customising the final config using other presets or configuration options. For example, you may need to group (or exclude) certain dependencies to reduce update noise.

Feature 2: grouping related updates

My blog has 20 Gatsby-related dependencies (what a mess, but it’s a topic for another blog post 😄). Updating them one by one is distracting and also likely to cause issues. What if we could ask Renovate to group all gatsby-* dependencies in one PR? No problem at all:

{
  "packageRules": [
    {
      "matchPackagePatterns": ["^gatsby"],
      "groupName": "Gatsby packages"
    }
  ]
}

packageRules is a cool and flexible config option for grouping Renovate updates. However, in my case, it’s not even necessary! My default config already has built-in knowledge on how to group Gatsby dependencies, thanks to Renovate’s base preset. It encompasses a wide range of curated package rules, especially for the Javascript ecosystem. Whether it’s Angular, Vue, or anything in between, Renovate has you covered.

A few typical use cases for the packageRules configuration:

Separating dependencies and devDependencies. The latter is easier to automerge.
Modifying the update schedule for specific types or groups of updates.
Restricting updates for certain packages.

A word of caution. Although it may seem counterintuitive, I have found that smaller and more frequent updates tend to be more effective than large grouped PRs.

Feature 3: lock file updates

Renovate performs update checks for your direct dependencies, which are the ones listed in the package.json file. These direct dependencies can themselves have their own dependencies, which are known as indirect or transitive dependencies. Typical web projects often have much more transitive dependencies than direct ones. The easiest way to keep these dependencies up to date is by regularly refreshing the lock file. When you combine this approach with dependency pinning, lock file updates can be safely automerged.

{
  $schema: "https://docs.renovatebot.com/renovate-schema.json",
  extends: [
    "config:js-app", // pins dependencies in package.json file
    ":maintainLockFilesWeekly", // regenerates lock file to update all transitive deps
  ],
}

If you prefer ranges ("^1.2.3") to pinning ("1.2.3"), lock file maintenance will update everything according to the ranges specified in your package.json. If this is what you are looking for, take a look at config:semverAllMonthly preset for inspiration.

Feature 4: Dependabot integration

Wait, what?
Yes, Renovate delegates vulnerability checks to Dependabot. When running on GitHub, Renovate checks Dependabot security alerts and immediately triggers the corresponding updates. To utilise this feature, you need to enable Dependabot alerts in your project settings.

A vulnerability remediation PR may appear as follows:

Of course, this feature is configurable via the vulnerabilityAlerts setting.
You can also override the prBodyTemplate setting to remove the Renovate banner at the top.

Feature 5: Dependency Dashboard

For quite a while, I thought Renovate was a typical CI tool without UI. Luckily, I was mistaken. Renovate comes with a Dependency Dashboard where you can find a summary of all opened and pending updates, as well as any configuration issues. Below is a screenshot of the Dependency Dashboard for this blog (don’t worry about all the security issues, it’s a static website):

Instead of jumping back and forth between different PRs and Renovate app logs, I can view and manage everything from one place. It’s even more helpful when you’re maintaining multiple repositories.

To summarise

If you’re seeking an automated dependency management tool, I can confidently recommend Renovate. It’s well-designed, flexible, and open source. After using it for over a year, I particularly enjoy some of its features, such as shareable configs and the Dependency Dashboard. However, be aware that the initial learning curve can be steep, especially if you can’t use the preconfigured GitHub app.

Are you using Renovate or any other dependency management tool? I’d love to know about your experience in the comments on DEV!

Budgeting my communication capacity

Sat, 03 Jun 2023 20:00:00 GMT

Spring 2023 was fun. After 7 years in one company, I started a new role in a very different type of business, with a very different tech stack. Bold move for me! The entire process from interviewing to signing an offer to opening my first PR in a new team took almost a year. Landing a job in tech is hard. “The system is broken” is a common phrase to hear when engineers of all seniority levels share their hiring experiences. Funny enough, my new job is to build products for recruiters. Let’s see if I can help to “fix the system.” I’ll start by sharing some learnings from my recent job change project. And the first one is all about networking.

I’m an introvert. I enjoy the comfort and solitude of remote work with async communication. When I’m in the flow, I can solve a wide range of technical problems from backend to frontend, from planning to shipping, from enterprise to greenfield. Out of 100%, 80% of my capacity is technical, and the remaining 20% is communication skills. However, those 20% were barely enough to support all of my technical work, especially when I started taking on more management responsibilities. I had ambition, and growing often meant management.

Introverts on the other side of the screen will understand that once you’ve spent all your communication budget, it’s a hard stop. I had been working like this for years, not leaving any of my “extrovert” budget for the outer IT space.

As a result, when it was time to move on, I had very few useful connections and an outdated understanding of the IT recruitment market. I had to go through cold interviews with their live coding sessions, algorithmic problems, personality tests, and other humiliating experiences. Not fun at all.

The most popular advice I received during that period was to keep interviewing. I was told to schedule as many interviews as possible until I became comfortable with them. I was advised to stretch my 20% even further.

Today, I have a better advice for myself: budget your communication capacity to stay in sync with the IT reality. This means reserving 5% of my extravert capacity for external activities and spending that 5% wisely. Booking every morning for yet another interview call is not wise at all.

While 5% may seem like a small number, there are many activities in IT that bring a lot of value with just a bit of communication effort. Let me share some concrete examples that have worked for me:

Meetups and conferences

I found my current employer on meetup.com. I have also built strong connections with people I met at meetups and conferences. For me, the best way to network at a conference is to give a talk. This way, people come to me with specific questions, and I don’t need to worry about how to start a conversation. I can also build good relationships with other speakers by giving feedback and asking follow-up questions. Even if I don’t create any meaningful connections, I go home inspired and motivated. Good enough for me.

Mentorship and coaching

I feel much more comfortable in deeper 1:1 conversations than in group activities with strangers. Mentorship sessions were the main source of energy for me in 2022. I spoke to engineers and leaders from various organisations, and everyone was very helpful and supportive. Today, I have a couple of trusted mentors, and offer engineering mentorships myself on ADPList. If you are new to mentorship read my post “Where to find a mentor” to get started.

Blogging

I created this little blog five years ago when I was playing with Gatsby during Christmas. Even with my occasional writing, it has become a great foundation for my public profile. As a bonus, it makes a positive first impression on recruiters. Writing skills are important in tech, as a lot of communication and knowledge sharing happens asynchronously.

Reading

Surprisingly, reading can be a decent networking tool. Writing a book review, giving a recommendation or participating in a book club - all of these activities can bring interesting people and ideas into my life. My “Learning Domain-Driven Design” book review is the most popular post on this blog to date.

Working from the office

To reserve some communication capacity for the activities mentioned above, I left behind my Tech Lead role and started as an individual contributor. However, as a Senior Engineer, I still have a lot of meetings to plan the work, pair on implementation, and stay up to date with the business in general. I was surprised to find out that all those activities drain me much less when I work from the office. Also, drawing on the whiteboard is a lot of fun!

Things that didn’t work for me

I’m not the first to discover the difficulties with networking for less outgoing engineers, and I know there are many other ways to show up in the global IT community. Some of them didn’t work for me (but they may work for you):

Dale Carnegie tricks
Not my thing, but I agree that learning some “tricks” can help in common situations, like starting a conversation with a stranger or having an argument with a colleague.

Online communities
There are many topic-specific channels in Slack, Reddit, Discord, Twitch, etc.

Open Source contributions
Early in my career, I was lucky to meet great people from the Drupal open-source community. They influenced my career more than anyone else. Participating in open source requires time and effort, and at some point I disengaged in favor of client work.

Freelance gigs
I know some very well-connected freelancers, but I’m not sure if my 5% communication budget will be enough to satisfy any client.

Building side projects
Building something public can be a great starting point for building connections with very interesting, well-connected people. Pretty much every indie developer I met was a very interesting person with multiple talents.

To summarise

As an introvert, I have a limited communication capacity that I refer to as my “extravert budget”. In the past, I used to spend all of it at work, leaving nothing for other activities. My recent job change experience has made it clear to me that I need to budget my communication capacity wisely. Otherwise, I’m at risk of alienating from the global IT community.

Firstly, I gave up some of my management responsibilities and made it a habit to come to the office twice a week. Surprisingly, in-person meetings drain me much less compared to Zoom calls. Additionally, I began working with a mentor to enhance the efficiency of my communication.

By making these changes, I am now able to engage more with the global IT community and naturally expand my professional network. I have found several activities that work well for me, such as meetups, mentorship, and blogging.

I’d love to know what works for you, especially if you consider yourself a less outgoing person. Please, share your experience in comments on DEV.to or contact me directly. Let’s connect! 😄

Thinking Architecturally (book review)

Tue, 28 Feb 2023 10:00:00 GMT

Today I want to share a short ebook by software architect and author Nate Schutta. Thinking Architecturally is available for free on the VMWare website (author’s employer at the time of writing).

Thinking Architecturally is a perfect read for mid-level & senior developers who want to focus on the right things in our noisy industry. Unlike many other architecture books, it stays away from technical jargon and philosophical abstractions. It’s practical and easy to read, even if you know nothing about software architecture. Each chapter ends with exercises (katas) that welcome you to think architecturally.

If you trust my taste, go ahead and download the book. If you want a sneak peek, below you can find a few of my favourite quotes.

Technology Changes

Technology will change and frankly that is what attracts many people to this industry. Learning new things keeps things fresh! But more than a few of us are guilty of practicing resume-driven design, of choosing a technology not for fitness to purpose, but to be able to add it to our CV.

In the first chapter, Nate shows that technology repeats itself, and we can avoid unnecessary mistakes by learning from the past.

Thinking Strategically

Hope is not a strategy. As a senior technologist, you need to keep up with changes in your industry.

The author talks about information hygiene, a T-shaped skillset as a better replacement for “Full-Stack”, Tech Radar and other strategic approaches to stay current in our industry. Most of his recommendations are not new. They are available for us now and for free. The book does a great job promoting good old practices like local meetups and book clubs.

Evaluating and Choosing Technologies

Risks cannot be eliminated completely, but they can be managed. Consider each risk [of a new technology] and how you can mitigate it.

If you have ever wondered how to choose between multiple technologies or tools, chapters 3 & 4 of Thinking Architecturally are the answer. I usually follow my own “How to investigate technical solutions” to evaluate new tools, but I have to admit that Nate’s version is much more thorough.

Funny enough, the book includes an example of an evaluation of Angular and React (at the time when Angular was slightly more popular), and React wins it.

Introducing Technologies

As a senior technologist, your ability to communicate will dictate outcomes. Don’t be afraid to take that internal workshop on presentations.

I noticed that most architects compare their work with marketing and sales. It’s not something we usually learn as software engineers. Throughout the book, Thinking Architecturally emphasises the importance of networking, (over)communication, and learning initiatives such as meetups, book clubs and hackathons.

These “soft” activities are strategic tools for architects to cultivate the right architectural principles across the organisation.

Maintaining Technologies (“ilities”)

I met Nate, the author of Thinking Architecturally, at GSAS Barcelona, where he ran a workshop with the same title. At the workshop, we worked in groups on a random Architectural Kata (another great resource available for free). This is when I learned about “ilities” - software quality attributes that often end with “ility” (Scalability, Usability, Maintainability, etc).

If you’ve been recently preparing for the systems design interview, you may recognise “nonfunctional requirements”.

Below is what Nate says (and I very much agree):

For much of my career, I referred to the ilities as the nonfunctional requirements. And that term is still appropriate! However, a colleague convinced me there was a better phrase. We were walking through the architecturally significant requirements on an application when he made a great point. Most customers hear the “nonfunctional” part of the term and decide immediately that they only want functional requirements, stopping the conversation. But we have to convince them of the importance of something they can’t readily see. Framing the quality goals as something nonfunctional implies they aren’t required for the system to work.

Chapter 6 of the book gives clear guidance on how to identify, rank and measure quality attributes. It helped me to structure my intuitive approach to day-to-day software design. It helped me to think architecturally!

To summarise

Thinking Architecturally is my first recommendation for software engineers looking for ways to stay current and grow in the rapidly changing tech industry. This short ebook has already affected how I mentor senior developers on ADPList and how I approach my own learning.

If you are interested in software architecture topic, you may also like my article The road to Software Architecture (frontend edition).

Fast by default with Next.js

Mon, 20 Feb 2023 14:00:00 GMT

There is a famous quote from Donald Knuth that premature performance optimisation is the root of all evil. As usually happens with quotes, it was often taken out of context and amplified.

It’s 2023, and despite all the efforts, the web remains slow. Developers tend to blame frameworks, programming languages, browsers, and even customers who constantly change requirements. Every new library or tool states that it’s blazing fast, yet we keep building slow sites with it.

If we compare React bundle size throughout the years, it hasn’t significantly grown. What has grown is the amount of our own code written on top of React. It has grown so much that React itself started shifting its parts to the server (Server Components), which sounds insane for a frontend library!

In this article, we will see how the Next.js framework encourages performance-first development by offering or even enforcing several web optimisations out of the box. None of them are specific to Next.js. We can (and should) implement them using any other web development tools.

JavaScript Code Splitting
Preload JavaScript on link visibility
Dynamic import
Third-party scripts
Fonts
Images
Static optimisation
Edge Middleware
React Server Components and streaming SSR
To summarise

JavaScript Code Splitting

From the very beginning, Next.js provided a page-based routing system. To make your app available at example.com/about you had to create pages/about.js file in Next.js. Many developers found this structure intuitive and easy to use.

Under the hood, it allowed Next.js to implement Route-based Splitting, which was further optimised in version 9.2 to benefit from HTTP/2.

Preload JavaScript on link visibility

Once we break our JS into multiple chunks, we must ensure they are loaded at the right time. Link component form Next.js prefetches corresponding page code using Import on Visibility or Import On Interaction patterns.

As you scroll down the notion.so website, you can notice some extra scripts are being loaded. If you then decide to go to another page, all necessary JavaScript will be already in place.

Dynamic import

Heavy code that is only used under certain circumstances can be lazy-loaded using Dynamic Import. This technique requires developers first to identify candidates for lazy loading and then implement a smooth loading experience for the user.

For many years, Next.js has been offering next/dynamic function for this purpose. Under the hood, it’s just a wrapper around React.lazy and Suspense that you can use in any React project.

Third-party scripts

As you may know, <script> tag behaviour is very complex. An external script can completely ruin your Web Vitals regardless of how well you optimise your code. Below is a quote from a brilliant tutorial by the Google team “Optimise your loading sequence”:

Scripts get different priorities based on where they are in the document and whether they are async, defer, or blocking. Blocking scripts requested before the first image ( or an image early in the document) are given higher priority over blocking scripts requested after the first image is fetched. Async/defer/injected scripts, regardless of where they are in the document, have the lowest priority. Thus we can prioritise different scripts by using the appropriate attributes for async and defer.

The main takeaway is that there is no one right way to include scripts on the site. We need to consider the entire loading sequence, versions of frameworks and browsers, the target audience of the site and a handful of other factors.

Back to Next.js, its <Script> component provides a simplified interface for HTML <script> tag:

<Script src="https://example.com/script.js" />

This code can be put anywhere in the app, and Next.js will load it at the most appropriate time (after the page becomes interactive). It’s best for most scripts, such as Google Tag Manager or Google Analytics.

If you need to load the script much earlier (or much later), you can use the strategy property.

Fonts

The easiest way to optimise Largest Contentful Paint (LCP) metric is to place a large text block at the top of your page. For example, Next.js homepage uses <h1> as LCP element:

Commonly, web designs are based on non-standard fonts aka web fonts. Loading them from Google Fonts or similar services takes precious time and creates other issues like Cumulative Layout Shift (CLS).

Next.js team has been working on fonts optimisation since version 10. They started with inlining font CSS and adding <link preconnect> hint for the browsers and by version 13 ended up with built-in self-hosting and optimisation for any font file.

Font optimisation is hard, and I’m incredibly grateful to the Next.js team for handling it for me.

Images

On many websites, the main contributor to performance issues is media. When I work on performance, I always start with images. They are usually easy to fix and bring an immediate, noticeable boost.

Thanks to WebP and AVIF, lazy loading and aspect-ratio, srcset and picture tag, we can deliver the most appropriate images to our users. Next.js offers a smart wrapper around <img> tag that utilises all mentioned techniques (and probably more) to reduce the amount of development work required to render an image in 2023.

Below is a screenshot with the resulting markup generated by Next.js Image component from this example:

As with any opinionated solution, next/image has its limitations, but it’s a great starting point that sets the bar high.

Static optimisation

A few years ago, the industry became obsessed with Static Site Generation (SSG). Good old static HTML was back under a fancy name. This very site was built using an early GatsbyJS version.

Indeed, static sites are more secure, faster, and cheaper. In 2020, Next.js announced Automatic Static Optimisation: a simple API that uses SSG for static parts of the app while serving the rest of the app dynamically.

Most dynamic sites couldn’t benefit from SSG at that time. First of all, it would require a massive rewrite. But the main problem was to trigger rebuilds every time you needed to update your static pages. We at SystemSeed overcame this issue by using Cloudflare CDN cache. You can learn more about this approach in my article “Let Cloudflare CDN speed up your classic website like it’s static”. Guillermo Rauch, Vercel’s CEO, later contacted me about that article:

Messages like this are the greatest reward for the author! 💚

These days Next.js provides a built-in way to regenerate static pages. It’s called Incremental Static Regeneration (ISR).

Edge Middleware

Next.js is funded by Vercel, a hosting platform that’s primary focus is speed. While most Next.js performance features are hosting-neutral, some are harder to self-host. Edge Middleware is a good example. It’s inspired by (and based on) Cloudflare Workers. If you are a Vercel customer, you can immediately benefit from blazing-fast edge computing without leaving your favourite framework codebase. Amazing!

But even if we are not on Vercel, their setup inspires us to build something similar with the tools available to us.

Vercel deploys the middleware code to edge functions, which are invoked before the request reaches the CDN. This allows static pages can be cached, as the middleware is called before the CDN sends back a cached response

The quote above is from the OpenNext project, which aims to port Vercel setup to other serverless platforms.

React Server Components and streaming SSR

From React 18 release notes:

In React 18, you can start using Suspense for data fetching in opinionated frameworks like Relay, Next.js, Hydrogen, or Remix. Ad hoc data fetching with Suspense is technically possible, but still not recommended as a general strategy.

React is getting more complicated. It took several years to release Suspense, and it will take another few years to adopt it. Given the level of complexity, it’s wise to delegate implementation details to experienced frameworks’ maintainers.

Next.js 13, the latest release to date, introduces a new routing system that supports streaming SSR, Server Components, and Suspense for data fetching. By pushing more code to the server, we can reduce the client-side JavaScript and speed up hydration.

If you are new to React Server Components, I recommend to start with Rendering Fundamentals documentation. Welcome to the new Next.js!

I’m sure the old pages routing will keep working for a while, but the new things will all go to the app directory.

To summarise

I welcome you to rethink Knuth’s words about premature performance optimisation and embrace the “Fast by default” mindset when building websites. Not all optimisations are evil. Some of them have become common sense and should be applied by default.

Next.js is an excellent example of the “fast by default” mindset. It popularises web performance best practices by making them easy to use (or even enforcing on ESLint level). I like this approach and apply it to other tools.

Similar to mobile-first or security-first development cultures, it takes time to establish “fast by default” mindset, and I’m grateful to Next.js for helping me with it.

Three tricks to get in focus mode

Sun, 05 Feb 2023 14:00:00 GMT

I find myself very lucky to be a software engineer. I enjoy solving problems with code, and it usually doesn’t require any effort to go into “focus mode”. Quite the opposite - it’s sometimes hard to stop thinking about that tricky bug and close my laptop.

Still, there are situations when distractions and multitasking prevent me from achieving what I want. I have a few tricks in my toolkit to restore focus and attack the problem, even if it’s a tough one.

What is the focus mode

Focus mode is a tool to handle certain types of work. Like a hammer or a needle, it’s helpful in some situations and harmful in others. Focus mode is never the end goal. Before trying to focus, I need to figure out what and why I want to achieve with its help.

To focus means to keep our full attention on one thing for a long enough period of time. I haven’t met any person who doesn’t know how to do it. We all constantly go in and out of focus, naturally guided by our interests and curiosity.

Beyond focus, we can sometimes fall into the flow state, a highly intense and rewarding experience of full immersion in a particular activity. Mihaly Csikszentmihalyi studied the flow state his whole life and wrote a comprehensive book on the subject. What’s crucial for this article is that the flow state usually requires focus as a prerequisite.

_Mental state in terms of challenge level and skill level, according to Csikszentmihalyi’s flow model, Wikipedia_

Below I share three tricks that help me get into focus mode, but it’s important to remember that they are merely techniques for occasional use. If I regularly experience difficulties with focus, I know it’s time to revisit my plans. Are they aligned with my north star? Are they achievable?

This post was inspired by a question from one of my mentorship sessions at ADPList. Mentorship is a great way to explore deeper reasons behind the lack of focus. Read “Where to find a mentor” if you are interested in this route.

Trick 1: “Is it technically possible?”

6 am. My alarm throws me into a dark and cold Monday morning. Even my cat, who is supposed to be a nocturnal animal, is against this idea. Before I even notice it, I start looking for reasons to stay in bed.

In such moments I ask myself: is it technically possible? Can someone like me get up at 6 am? Is it doable for a woman who went to bed at 10 pm and has scheduled some writing work before her regular working hours?

In 99% of situations, the answer is yes. It’s not that cold in the kitchen for me to freeze. And if it’s dark, I can turn on the lights 💡

Trick 2: Microtask

It’s common practice to break work into small achievable chunks of work. Yet, even a well-scoped task can be hard to start. In this situation, I create a microtask - the first ridiculously small step.

For example, if I need to build a new project, a microtask can be “initialise git repository” or “print hello world on the screen”. It helps to write the microtask down even if typing it will take longer than actually doing it!

If it’s impossible to extract a meaningful microtask, I use the “Do X for 30 min” template. Let’s say I want to get better at solving algorithms problems, but I don’t know where to start. I put the microtask “Work on leetcode for 30 min” in the Centered app and stare at the screen for 30 min. Half an hour later, I will understand my current level much better and can create more meaningful microtasks.

Microtask is similar to micromanagement. Only apply it to your own tasks when you are stuck.

Trick 3: Add flavour

If I don’t have control over what I do, I can at least control how I do it. I call it flavour. Example:

What: review and update legacy documentation
How (adds interest flavour): generate images from your documentation using AI tool
How (adds challenge flavour): make resulting documentation shorter, not longer
How (adds value flavour): pair on it with a more junior developer
How (adds fun flavour): work on it from your favourite café

Deciding how I will do my work sparks motivation and increases self-accountability even when I don’t feel deeply connected to the end goal of the task.

And many more

While writing this post, I discovered a good list of things that help me focus. Most of them are common sense rather than tricks:

Early mornings
Sticking to schedule
Working in solitude
Keeping mind clear (journaling, meditation, exercises)
External deadline / commitment
Involving other people
Music for concentration
Embracing a healthy dose of discomfort

To summarise

We often find ourselves fully focused and dedicated when we work on interesting and challenging problems. It feels great, and we want more of that flow state.

Over the years, I learned a few tricks to restore my focus. I’m sure you have your own tricks, too. Please share in the comments on DEV.to. I’d love to learn from you!

The road to Software Architecture (frontend edition)

Tue, 31 Jan 2023 09:00:00 GMT

According to the State of JS report, the “Code Architecture” problem was the main pain point for JavaScript developers in 2022.

In this post, I argue that folders are better than microservices, disagree with Uncle Bob, and cite Martin Fowler’s advice against the Gang Of Four book. This is my road to Software Architecture. Let’s go!

My background

As a Full-Stack Developer, I’ve been involved in the software design process since very early in my career.

Even before I realised it, I started making everyday architectural decisions such as:

where to put my code
what & how to test
which framework to use
how to spread the work between multiple developers, and so on

It turned out these little decisions matter in the long run. Some pieces of PHP code that I wrote eight years ago are still in use in production.

The oldest React app that is currently in use was started by my team at SystemSeed in 2017 from the Create React App template. We’ve managed to stay on un-ejected CRA all these years and recently upgraded the codebase to React 18.

Another long-living project was built with Next.js 2. Today it runs on top of Next.js 13 and serves thousands of users around the globe.

Working on such projects brings a lot of problems that I can classify as “Code Architecture” from the State of JS report. Let me elaborate on what I understand by that.

Software Architecture (as I understand it)

There are many clever definitions of software architecture. In this article, I lean towards the term “software architecture” to avoid any confusion between “software design” and “UI design”.

Philosophically speaking, software architecture work is about finding optimal answers to questions that don’t have one correct answer. I mean those questions with zero answers on StackOverflow (apart from the famous “It depends”).

Architectural problems often appear at the worst possible moment, disturbing our coding flow and making us feel annoyed and uncertain. That’s why software architecture can feel like a pain point, but in fact, it’s an essential part of our jobs, and Copilots can’t do it yet!

Traditionally, software architecture decisions have been part of more senior roles’ responsibilities. Some companies even have a dedicated Software Architect role. That person, though, wouldn’t be able to decide on every little detail. They likely came from the backend background to oversee the systems on a very high level. So in practice, developers who actually implement frontend applications are the main contributors to the resulting code architecture.

That’s suddenly a lot of pressure on us! Let’s see how we can reduce our anxiety around code architecture and become better at it.

Learn your tools

“Clean Architecture”, the famous book by Uncle Bob, states that we should design framework-agnostic architectures:

Good architectures are centered on use cases so that architects can safely describe the structures that support those use cases without committing to frameworks, tools, and environments.

Really? Well, I’m hired as a framework specialist; how can I put it aside?

The answer turned out to be simple. Before you can put the frameworks aside, you need to learn a few of them on a very good level. Once you become fluent in a couple of frameworks, you start to see patterns and trade-offs. At that point, recommendations from Uncle Bob will start to make sense.

For example, these days, I focus on improving my React skills. For me, learning advanced React patterns is a valuable time investment and a good step towards understanding modern frontend in general.

My decision to focus on one established technology means saying no to many other tools and frameworks highlighted in the State of JS report. It’s uncomfortable to feel “left behind,” but I am confident that it will pay off.

As Nathaniel Schutta says in “Thinking Architecturally”:

I thought I’d “missed the wave” of some technology or another. What I didn’t appreciate at the time is that new technologies are a lot like buses — one comes every 15 minutes or so.

Once I understand the tool deeply, I start making more informed architectural decisions.

Embrace folders

Many of us jumped into microservices way too soon. There is a much safer (and cheaper) option — folders!

Folders are logical boundaries of our modules, features, components, etc. Well-organised file structure makes project architecture readable and extendable.

React community has a couple of suggestions to start with (1, 2). The official site says:

If you’re just starting a project, don’t spend more than five minutes on choosing a file structure.

It’s not because file structure is not important. It’s because it should change as your project evolves. Let’s say you had to touch files from ten different folders to ship a new feature. It’s a sign that you need to review your folder structure (and your logical boundaries).

Testable code

Most people write tests because they want to be confident that the app works as expected after code changes. As a nice bonus, testable code results in better code architecture!

For a long time, I was only using end-to-end tests that treated the resulting app as a black box. It allowed me to write mediocre code with spaghetti from dependencies, inconsistencies and workarounds. Everything changed when I started to imagine how I would write other types of tests for my code:

Visual regression test (e.g. component look & feel with dummy content)
Unit test (e.g. how the utility function calculates the fee based on ordered products)
Integration test (e.g. how the Basket component responds to user interactions such as hover and click)
End-to-end test (finally, how the entire shopping flow works in the browser)

Even if I don’t write all these types of tests, thinking about them helps me structure my code better.

What about design patterns?

Design patterns in software are similar to the chords in music. Someone discovered them many years ago, but people keep combining the chords in many different ways to compose new songs.

Just like learning chords by the book may be difficult at the beginning, classic design patterns books may not make any sense for a frontend developer.

A quote from Martin Fowler’s review of the famous Design Patterns book:

Despite my praise, this is not an easy book to read. I don’t recommend it until you’re pretty comfortable with the basic principles of OO design. Even then it takes a fair investment of effort to really appreciate the book. Unlike most books, however, it amply pays that investment.

Luckily, we can learn about modern JavaScript and React design patterns from a free book Patterns.dev. It describes all common patterns in a frontend-friendly language with practical examples and animations.

Observer Pattern animation from patterns.dev (video)

The Community Patterns section lists some framework-specific resources to dig deeper.

Business logic

The pieces of UI logic we write for the frontend may be trivial, but their large volume and constant changes become a challenge as the projects grow. The most coherent approach to business logic that I have found so far is Domain-Driven Design (DDD).

DDD places a strong emphasis on building a shared understanding of the problem domain and focuses team efforts on the most important parts (“Core” subdomain).

Domain-Driven Design is about letting your business domain drive your design decisions.
Vlad Knononov, “Learning Domain-Driven Design”

In other words, development teams should understand and stay focused on the problem the business is trying to solve for its users.

If it sounds too abstract, I recommend the “Learning Domain-Driven Design” book (read my review here). I’m currently exploring ways to apply DDD principles to frontend architecture problems. Stay tuned for more articles on the topic.

To summarise

Some questions about software development don’t have one correct answer apart from “It depends”. We face them every day, and our answers contribute to the architecture of the projects we work on.

Developers who know their tools and cover their code with tests tend to make better architectural decisions. That’s why I suggest starting by mastering essential frontend tooling.

Once we feel comfortable with the tooling, we can zoom out and think in terms of design patterns and business problems. It’s a whole new world! I made several attempts to enter it, and I found the following resources most helpful so far:

Patterns.dev - frontend-friendly book on design patterns
“A Philosophy of Software Design” - my favourite software engineering book
Learning Domain-Driven Design - good introduction to DDD (my review)

That’s how far I went on my road to Software Architecture.
Follow me on Twitter, Mastodon, or LinkedIn to stay updated on my next adventures.

Flutter guide for React developers

Sun, 22 Jan 2023 13:00:00 GMT

Flutter is a popular framework for building cross-platform mobile apps. I had a chance to play with Flutter and found quite a few similarities with React. In this guide, I map common Flutter concepts to their equivalents in web development. If you are a React developer interested in Flutter, it will help you find your fit in the new territory.

This article doesn’t question whether you should use Flutter, React Native, PWA or a native app approach. There are good use cases for each of them. Today we will focus on Flutter for mobile app development. Let’s dive in!

VS Code → VS Code
Chrome Dev Tools → Flutter Dev tools
TypeScript → Dart
ESlint → Dart lint
div → Widget
CSS → Widget
Accessibility → Widget (again!)
@mui → Material Components (MDC)
Render → Build
State → State
npm → pub.dev
Redux + React Query → Riverpod
React Router → Go Router
Backend → Firebase
React Testing Library → flutter_test
React Docs → docs.flutter.dev
What’s next

VS Code → VS Code

Most Flutter developers write code with the same tools as web developers. VS Code with Flutter extension is the most popular option.

Android Studio has first-class Flutter support if you are more comfortable with IntelliJ IDEA. I picked this option and was quite happy with it.

Like any other mobile dev setup, it takes time to prepare everything for cross-platform development. To help developers troubleshoot their local setup, Flutter comes with a handy utility flutter doctor:

💡 Get started with the local development environment:

Carefully follow official installation instructions. Don’t skip steps!
If you are not ready to install Flutter locally, you can also use DartPad, an online Dart & Flutter playground

I personally found the initial installation process more straightforward than for React Native.

Chrome Dev Tools → Flutter Dev tools

It’s hard to imagine web development without the powerful dev tools we have in our browsers.

Surprisingly, Flutter isn’t far behind. I started using Flutter widget inspector from day 1 to debug my widgets styling issues. Just like in Chrome, Flutter Inspector has multiple tabs, from Networking to Performance. It was interesting to explore my app from different angles there.

Last, you can debug Flutter code from your IDE using breakpoints. For some reason, I still prefer console.log() in JavaScript!

💡 Get started with Flutter Dev tools:

DevTools - official documentation

TypeScript → Dart

Flutter uses the Dart programming language. Dart is similar to JavaScript but with types and some nice syntax sugar on top of it. For example, Dart has an async functionality, but Promises are called Futures there.

If we need an array in the JavaScript sense, in Dart, we use a List:

var nav = ['Home', 'Furniture', 'Plants', if (promoActive) 'Outlet'];

The example above is a List of Strings. The last item is only added if promoActive is true. Neat!

💡 Get started with Dart:

Learning Dart as a JavaScript developer - half an hour, and you are ready to go!

My experience with Dart was only positive so far. You don’t need to spend time configuring TypeScript or Webpack. With Dart, everything is built-in and ready to use.

ESlint → Dart lint

Dart & Flutter have built-in code analysing and formatting tools. It makes it easy to learn framework best practices. I was happy with the default linters setup, but it’s possible to customise it too.

💡 Get started with linters:

When you start a new Flutter project, the linters should be preconfigured for you
For customisation check Dart linter rules and Flutter linter rules

div → Widget

Everything in Flutter is a widget. If you compare them to HTML tags, Flutter widgets are usually much more specialised.

For example, “to center a div” in Flutter, you use the specialised Center widget:

Center(
    child: const Text("I’m centered!")
),

It takes time to get familiar with all built-in Flutter widgets. I don’t think I explored even half of them.

💡 Get started with Widgets:

Scan through the Widget catalog to learn what’s available
Regularly watch short “Widget of the Week” videos from the official Flutter team.

I didn’t quite enjoy Flutter’s way of passing children as properties. Personally, I find JSX syntax easier to work with.

CSS → Widget

Everything is a widget, remember? Flutter doesn’t support CSS. Instead, all styling is handled by widgets and their properties.

Let’s say I want to add some padding to my Center widget. In Flutter, I need to wrap my widget with another one, specialised in padding, and pass my original widget via child property:

Padding(
   padding: EdgeInsets.all(16),
   child: Center(child: Text("I’m centered!")),
);

EdgeInsets.all(16) means padding: 16px. Flutter operates in logical pixels and takes care of translating our values into physical pixels for each device and screen type.

Now let’s add a black border with border radius around the previous widget:

DecoratedBox(
      decoration: BoxDecoration(
        border: Border.all(
          color: Colors.black,
          width: 1,
        ),
        borderRadius: BorderRadius.circular(12),
      ),
      child: const Padding(
        padding: EdgeInsets.all(16),
        child: Center(child: Text("I’m centered!")),
      ),
)

In Flutter, all properties are granularly typed, and for each aspect of styling, you need to create a value of the appropriate type. Because of that, the resulting code is much more verbose.

💡 Get started with Widgets:

Scan through the Widget catalog to learn what’s available
Regularly watch short “Widget of the Week” videos from the official Flutter team.
How to choose which Flutter Animation Widget is right for you? - great overview of Flutter animations.

Accessibility → Widget (again!)

Accessibly is a first-class citizen in Flutter. For example, images and icons have the semanticLabel property for screen readers. For more advanced cases, there is a special widget Semantics which has more than 50 properties to describe the meaning of your widgets.

The Flutter team made it easy for developers to debug accessibility by providing the showSemanticsDebugger property. It replaces the original widgets with the corresponding semantic labels that the screen readers would read:

💡 Get started with accessibility:

Accessibility widgets - official documentation

@mui → Material Components (MDC)

@mui is Material Design implementation for React. When using @mui as your component library, you first create a top-level theme, expose it via React Context, and then enjoy consistent styling across all your components.

Below is how you would print a heading with @mui:

<Typography variant="h4">Heading 4</Typography>

Flutter comes with Material Components (MDC) out of the box. Technically you can opt-out and go your own way, but I haven’t explored that route yet.

Similar to React implementation, various aspects of the theme are first configured at the top level of the app and then reused in individual widgets like this:

Text(
    'Heading 4',
    style: Theme.of(context).textTheme.headline4,
)

💡 Get started with Material:

MDC codelabs (small practical lessons) from the official Flutter team
Material Theme Builder supports export in Flutter
Material 3 for Flutter by Eilidh Southren
Flutter Theming Guide by Mike Rydstrom

Be prepared for a steep learning curve: hundreds of widgets and properties, sophisticated Material theme configuration, and of course, mobile device specifics that don’t exist on the web.

Render → Build

Flutter widgets are classes that must implement the build method. It’s similar to the render method in React class components.

Let’s implement the build method for our “centered div” example from the beginning of this guide:

class CenteredText extends StatelessWidget {
  const CenteredText({super.key, required this.text});
  // Props are class members in Flutter.
  final String text;

  // Widget must implement the build method.
  @override
  Widget build(BuildContext context) {
    return Center(child: Text(text));
  }
}

If you had a negative experience with class components in React, put it aside for a moment. Flutter is based on Dart, and its class implementation is much more robust and well-thought than in JavaScript.

💡 Get started with building custom widgets:

How to Create Stateless Widgets from Flutter in Focus video series

State → State

Quote from Flutter documentation:

Flutter widgets are built using a modern framework that takes inspiration from React. The central idea is that you build your UI out of widgets. Widgets describe what their view should look like given their current configuration and state. When a widget’s state changes, the widget rebuilds its description, which the framework diffs against the previous description in order to determine the minimal changes needed in the underlying render tree to transition from one state to the next.

The actual implementation of stateful widgets differs from how we build stateful components in React. Instead of adding one line of code with the useState hook, you need to create two (!) separate objects: one for the stateful widget and another for its state. Wonder why? Check out the links below for details.

Luckily, both VS Code and Android Studio have shortcuts to scaffold Flutter widgets. In practice, I can create Flutter widgets as fast as I create new React components.

💡 Get started with stateful widgets:

How Stateful Widgets Are Used Best from Flutter in Focus video series
Flutter’s setState() might not be what you think it is - Flutter is inspired by React, but under the hood, it works differently.

npm → pub.dev

pub.dev is the official package repository for Dart and Flutter apps. I found it very clean and developer-friendly. Pub.dev promotes high-quality packages via the Flutter Favorite program and Package of the Week YouTube show.

There are two files in the Flutter app directory that are related to pub.dev: pubspec.yaml and pubspec.lock (equivalents of package.json and package.lock).

💡 Get started with pub.dev:

Head to pub.dev and explore the packages

Redux + React Query → Riverpod

Like with React, the Flutter ecosystem has born a dozen competing state managers.

Some seasoned Flutter developers lean towards Riverpod (#5 in the chart above) when building real, complex applications. I trust their choice.

💡 Get started with Riverpod:

Flutter Riverpod 2.0: The Ultimate Guide by Andrea Bizzotto
Time Tracking app with Flutter & Firebase - an example app by Andrea Bizzotto

React Router → Go Router

Mobile app navigation is quite different from the web. The built-in Flutter Navigation API is so complex that the Flutter team decided to build an official third-party package with a simpler API: Go Router.

Similar to React Router, you declare your routes (and their sub-routes) and map them to the screens of your app.

Get started with Go Router:

Flutter Navigation with GoRouter: Go vs Push by Andrea Bizzotto
Deep linking - official Flutter documentation

Backend → Firebase

Mobile/desktop apps are rarely static landing pages. Almost always they require some backend for authentication, data synchronisation, analytics and more. Yet most apps will never become popular, and developers don’t want to spend months building sophisticated backends. That’s why Firebase is so popular in mobile dev, Flutter included. It offers a set of APIs for all common features you may need as a mobile developer, all free until a certain threshold.

Google supports both Flutter and Firebase so you can expect an excellent integration between the two. If you don’t want to store your data with Google, several open source alternatives provide similar developer experience.

💡 Get started with Firebase:

Add Firebase to your Flutter app - official documentation
One-file Firebase chat app - official DartPad example
I tried 5 Firebase alternatives - video by Jeff Delaney

React Testing Library → flutter_test

A robust testing ecosystem is another sign of a serious approach to the framework quality.

Developers can test Flutter apps with the following types of tests:

Unit — verifies the behaviour of a method or class
Widget — verifies the behaviour of Flutter widgets without running the app itself
Golden — verifies visual output of Flutter widgets without running the app itself
UI integration — verifies the full app UI works by running the app on a device (some network services can be mocked)
End-to-end — same as above, but without any mocking

Example of a widget test:

testWidgets('Testing MyWidget', (WidgetTester tester) async {
  await tester.pumpWidget(MyWidget());
  await tester.tap(find.text('Save'));
  await tester.pump();
  expect(find.text('Success'), findsOneWidget);
});

WidgetTester provides an API to manipulate widgets programmatically; for example, tester.tap(find.text('Save')) will simulate tapping on the “Save” button.

It was pretty unexpected for me to find visual regression testing tools (Golden image tests) in the standard testing library. In addition to the standard tools, there are several external packages that help to further advance Flutter testing.

💡 Get started:

Testing Flutter apps - official documentation
Golden Toolkit - UI regression tests on top of Flutter’s Golden test functionality

React Docs → docs.flutter.dev

Official Flutter and Dart documentation are exceptionally good. Apart from detailed written documentation, the Flutter team provides interactive examples, videos, and codelabs.

You may not need any paid external resources at all to become a Flutter dev.

What’s next

I hope this guide will help you navigate the Flutter world as a React developer. If you are at the very beginning, start with “Your first Flutter app” codelab. Feel free to bookmark this guide and return to it as you progress through your journey!

Where to find a mentor

Sun, 15 Jan 2023 11:00:00 GMT

Last year I had several mentorship/coaching experiences, and the results impressed me. In this article, I reflect on what worked for me and suggest how to get started.

The most popular question I received last year was “Where to find a mentor”. I used to respond with this blog post from Gergely Orosz with the list of engineering mentorship resources.

Soon enough, I realised that by asking “Where to find a mentor”, people actually want to know if they need a mentor at all and how to get started.

First of all, if it came to your mind that you need a mentor, then you probably need one. I suggest starting with the following steps:

Choose one question
Answer your question yourself
Scan your existing contact list for potential mentors
Pick any available mentor from any mentorship service
Don’t delay your first mentorship session

Let’s go through the steps in detail.

Choose one question

In a nutshell, mentorship is about asking and answering questions.

Preparing your questions in advance is good practice. However, I suggest going further and reducing the list of questions to just one.

Your first session will be about getting to know each other and understanding the context. Having more than one problem can feel overwhelming for both parties.

Of course, once you’ve established a good relationship with your mentor, you can “break the rules” if they are limiting. I personally stick to one question rule and finish the session earlier if I’m clear on the next steps.

Answer your question yourself

After choosing a question, I try to answer it myself. This self-coaching practice helps me validate my question.

Let me give you an example. Imagine a person going to a pharmacy and saying, “I don’t feel well, give me some pills”. The pharmacist can’t feel your body for you, so they will ask lots of questions until they can help. If the person does a bit of introspection to identify what exactly hurts, they will come up with a much clearer request.

Same with mentorship. The only person who knows all the context of your problem is you. Explore this context on your own so it’s fresh when the mentor asks questions like “What have you already tried?” or “What piece of information do you miss to make a decision?”

Don’t worry if you can’t answer your question yet. It’s important that you try.

The opposite can happen, too. You can find an obvious solution to your problem. In this case, you may want a mentor’s help to verify your solution and go through the next steps together.

Scan your existing contact list for potential mentors

The most expensive (and rewarding) part of mentorship is building a trusting relationship. You may already have a few great mentors in your immediate network.

You don’t have to call it “mentorship” with them. This word can be interpreted as a serious commitment. Casual “I need your advice” works well for me.

Pick any available mentor from any mentorship service

Scan the services from Gergely Orosz’s list for mentors who are 3-5 years ahead of you career-wise. Book a session with someone who caught your attention and who has available time slots in the near future.

One can argue that we should carefully review the mentor’s experience, reviews, ratings, social media, etc. In reality, people either match or don’t match, and you can’t predict it before meeting for your first session.

I wouldn’t worry too much about wasting time with the “wrong” mentor. I’ve asked the same question to several different mentors and always learned something new.

Don’t delay your first mentorship session

Requesting your first mentorship session takes courage! Unfortunately, it took me a while to find that courage. I was using various excuses to delay taking action.

Excuse 1: “I can take course A/read book B. New knowledge will resolve my questions.”

Books, tutorials, and courses offer general knowledge, while the mentorship experience gives us deeper, personalized understanding. Mentorship works because you, as a mentee, get all the attention and support from the other person you respect and trust. In some situations it’s exactly what we need to take the next step.

Excuse 2: “My problems are not new/not interesting. I will waste someone’s time.”

As an aspiring mentor, I can confirm that mentors don’t look for new problems; they have enough of them at their jobs. As a mentor, I am excited to help someone find their way through a problem. If it’s something I faced myself in the past, then it is easier for me to guide the other person through it.

Excuse 3: “I don’t want to spend money on something that doesn’t guarantee result”

I have heard about expensive coaches who sell and upsell every second they talk to you. I overcame this fear by choosing from free options. I also figured out that most experts are very approachable when you DM them with your sincere ask for advice. Because there is no financial commitment, they are much more relaxed and honest. In the case of paid options, I will first book a short intro session to see if I’m comfortable with my choice.

Excuse 4: “They don’t know my situation and won’t be able to help”

It turns out that a mentor needs to know “just enough” to help me find the solution. As we discussed earlier, the answer may already be there, and all I need is trust and support. Kind words don’t cost us anything, but unfortunately, there is a huge lack of unconditional support in the world.

Excuse 5: “Mentorship is only for junior developers”

I think it’s time to clarify the terms:

Teaching - explaining in a very detailed way how to do things.
Mentorship - answering questions that require expertise/experience.
Coaching - asking questions that help the other person to solve their problems themselves.

The word “mentorship” is often used as an umbrella term for all three activities. Good mentors know when to give a very specific piece of information (teaching), when to share an example from their experience (classic mentorship), and when to ask an open question that welcomes a mentee to explore their problem deeper (coaching).

When I look at these definitions, I realise junior developers need more teaching: clear guidance and concrete steps. As they gain more experience, they require less teaching and more coaching, especially if they want to advance past certain career ladder levels.

Next steps

This article focuses on a formal mentorship that is supposed to last for a certain period to bring visible results.

After talking to several experienced mentors, I learned they had seen most of their mentees only once. It is totally fine to have occasional one-off sessions when needed. On the other hand, it takes time to build a trusting relationship and to explore challenging topics deeply. If you have a long-term professional goal, I welcome you to consider regular mentorship sessions.

Another important aspect not to forget is communication with your peers. From “The Mentorship Diamond” article:

You should have more contact with your peers than with mentors or mentees

At some point, you will become a mentor yourself. Being a mentor helps us grow in so many ways. I recently started as a mentor on the ADPList platform, and I will write about my experience soon. Stay tuned!

“Learning Domain-Driven Design” - the software architecture 🐒 book that makes sense

Sat, 07 Jan 2023 09:00:00 GMT

“Selling is hard, and personally, I hate selling. That said, if you think about it, designing software is selling. We are selling our ideas to the team, to management, or to customers.”
Vlad Knononov, “Learning Domain-Driven Design”

It’s 2023, and ChatGPT will probably write a summary of any book much better than I can. Finally, being personal and opinionated becomes an advantage!

My story

When a while ago I was preparing an onboarding plan for a new team member, I realised how many project-specific concepts, terms, and acronyms I had in my head. I decided to start a glossary and asked the new team member to research the meanings of the listed terms and acronyms by reading documentation, talking to other team members, or asking the client directly. Without knowing it, I started creating a “ubiquitous language”, a key element of the Domain-Driven Design approach.

First takeaway: do what makes sense. You’ll probably figure out later on that someone invented a methodology around that.

Many years later, I was lucky to catch Vlad Khononov at the GSAS conference in Barcelona and asked him how to become a better programmer. It’s a surprisingly difficult question, even for experienced developers. Take a moment to think of your own personal and opinionated answer.

Second takeaway: ask people questions that you care about and be open to unexpected answers.

Vlad advised starting with “A Philosophy of Software Design”, my all-time favourite among software engineering books. As I had already read it, Vlad had to come up with another answer, and coincidentally, it was his own book “Learning Domain-Driven Design”.

Third takeaway: read “A Philosophy of Software Design” by John Ousterhout if you haven’t yet

Back then, I had zero knowledge of DDD. I was aware of a few popular architecture patterns, and that’s it. As a Full Stack web developer, my day-to-day job was glueing existing services and frameworks together rather than drawing sophisticated UML diagrams. Yet I was intrigued by conspiracy around software architecture topics. Take a look at this famous definition for example:

“Architecture is about the important stuff. Whatever that is.”
Ralph Johnson

When I read “Clean Architecture” by Uncle Bob several years ago, I didn’t quite understand the book’s core ideas behind all that SOLID jargon, primarily because I couldn’t map the proposed “clean” solutions to my day-to-day experiences. Three years later, I finally started building that understanding, thanks to the “Learning Domain-Driven Design” book.

Fourth takeaway: keep exploring the topic that interests you until it clicks. It will eventually.

How I understand Domain-Driven Design today

Quoting Vlad, “Domain-Driven Design is about letting your business domain drive your design decisions.”

In the era of copy-paste-driven design, DDD suggests pausing and thinking deeply about the problem we attempt to solve with our favourite tools and patterns. It encourages us to build a shared understanding of that problem by speaking to business and, more importantly, by speaking the same (ubiquitous) language with them.

On a high level, DDD is about answering questions What? Why? How?

As people on all levels tend to jump straight to “How?” DDD offers some tools to help answer these questions in the correct order and, as a result, to build an appropriate software solution. Most DDD tools just make sense, similar to my glossary example at the beginning of this article.

EDA, DIP, OHS, ACL, ETL, CQRS… What?

It gets interesting when DDD meets the reality of modern software development. 20 years ago, when Eric Evans first introduced DDD, I was writing my first CSS and HTML code. The amount of tech acronyms has only grown since. In “Learning Domain-Driven Design”, Vlad walks us through all the common patterns and principles in a way that makes sense.

For example, I finally understood what Hexagonal architecture is and when to use it. On top of that, I’ve got an excellent overview of analytical data platforms. My favourite part of the book is Chapter 14: Microservices. I won’t attempt to summarise it here. Instead, I encourage you to read the book yourself if you are interested in a practical intro to the most common software architecture patterns such as Microservices, Event Driven Architecture, CQRS and more.

As a Full Stack developer, I found this overview very handy. I may not need all described patterns immediately, but I need to know they exist.

I must warn a fellow reader that a quick flip-through will not be enough if you are relatively new to software architecture. I had to take notes and re-read certain parts of the book to understand certain concepts.

Fifth takeaway: prepare for thorough reading to get the maximum from this book.

Design heuristics

After explaining the foundations for DDD, the book offers a good amount of advice on how to apply DDD in real life. In many cases, you can derive the appropriate implementation patterns after analysis of the business domain. If you picked the wrong implementation, no worries. The book suggests ways to migrate from one implementation pattern to another.

Another insightful heuristic is around testing strategies. There are three popular approaches: testing pyramid, testing diamond, and inverted testing pyramid. Vlad argues that there is no one right testing strategy and explains when to use which. I was able to prove it myself when I looked at my tests. I take testing seriously, but I rarely write unit tests in my project and instead focus on end-to-end and integration tests. It reflects the fact that in web, we often work with simpler architecture patterns (e.g. “Transaction script” and “Active record” from the “Patterns of Enterprise Application Architecture” catalog) because they are more appropriate for the task.

Sixth takeaway: DDD tackles software complexity, but it also tackles software simplicity, that is, how to not over-engineer our solutions just because we are excited by specific design patterns or technologies.

If you are an individual contributor without enough power to install DDD on a company level, the book outlines some baby steps you can take to shift the whole company towards DDD.

Seventh takeaway: you don’t need a software architect title to start using DDD in your daily work

The book wraps up nicely with a case study of applying DDD in real life. The author shares some of the mistakes he has made while learning DDD and how his understanding of DDD was evolving throughout the years.

To summarise

“Learning Domain-Driven Design” explains the ideas behind DDD and maps them to popular design and implementation patterns. As a bonus, you get introduced to Microservices, Event-Driven Architecture, Data Mesh, and more.

Some chapters are harder to read without the appropriate backend development experience. I treated it as a challenge and did my best to understand the CQRS pattern without ever seeing it in action. It is an opportunity for future writers to translate DDD ideas into examples tailored to specific audiences, e.g. Javascript developers. Back to the quote from the beginning of this article, we need to sell all these good ideas to developers who are very busy with tons of other stuff to learn.

There is a lot of work to be done in order to make software design best practices easy to understand and apply in practice. Many of the problems we face today have actually been discussed and solved in the past, but this wisdom has been lost in the back corners of the internet. Vlad Khononov’s book “Learning Domain-Driven Design” brings this wisdom back to us and explains it in a way that makes sense.

My approach to the command line

Mon, 10 May 2021 15:30:00 GMT

There is an idea that every developer should master tons of sophisticated tools and keyboard shortcuts to be truly professional and efficient.

My experience doesn’t confirm it. As an example, let me show you my command line setup. I’m not a sysadmin, but as a full stack developer with 10+ years of experience I use the terminal on a daily basis yet I’ve got a very basic setup:

No tmux
No aliases
No special .dotfile configs
No shell preference. I’m fine with zsh, bash, ksh, etc
No jokes on how to quit vim 🔫

My favourite terminal shortcuts:

Ctrl+R to explore the history
Ctrl+C to cancel / cleanup current command
Ctrl+L to clean the screen
Ctrl+A / Ctrl+E to jump to the beginning / end of the command string

My top-used commands

git
j (smart cd)
make
ls
rm
cat
grep
vi
yarn, npm, npx, composer, docker-compose and other project-specific CLI tools

You can grab your most used commands too: How do I see what my most used linux command are?

Why I stick to defaults

Apart from autojump, everything else in my setup is quite basic. I try to stick to defaults as much as possible. This is why:

Common use cases are easy to google.
StackOverflow is full of advice on how to do X, Y, Z in the terminal. In 99% of the cases the solution will use standard tools that are already available on my machine: ls, rm, cat, find, grep, awk, sort, sed, curl, chmod, etc.

Non-standard tools require installation.
If I make rg or ag my default search tool, I’ll have to install it on the remote servers, in the CI environments, in the cloud IDEs, on my colleagues’ machines. It’s not always possible.

Customisation requires more learning and memorising.
Now I need to learn how to use both the new tool (let’s say ag) and the standard pre-installed tool (usually grep). Otherwise, I won’t be able to work in remote environments, help a teammate (or receive help from them), debug a CI script, etc.

Updates and troubleshooting.
Custom setup can become outdated, can introduce bugs or security issues. I can simply forget that I installed a tricky git helper a year ago and it will cost me a day of troubleshooting at some point.

Learn the basics and have fun!

Most of the modern development stacks assume basic command line knowledge. The keyword is basic: you don’t need to make Vim your default text editor or master tmux to become a better developer. If you normally spend 30% of your time in, let’s say, Chrome DevTools and another 30% in VS Code, then you’d better master Chrome DevTools and VS Code first.

As a developer and Tech Lead, I think of the terminal mastering as something extra that I’m free to do if I want. After all, it can be a lot of fun! But I don’t have to be a command line geek, and you don’t have to either.

Question for you

What is your favourite CLI command or shortcut?

Mine is Ctrl+R shortcut to search through my command line history. This is how it works:

Hit Ctrl+R
Start typing any part of the previous command you want to run again, e.g. exec
You command line will be prepopulated with the most recent command that contained exec
If it’s not the right one, hit Ctrl+R again to cycle through older commands.

Please join discussion on DEV to respond 👩‍💻🧑‍💻

3 simple management tricks I learned as a Tech Lead

Thu, 08 Apr 2021 09:30:00 GMT

Developers often blame “bad management” when something goes wrong. I’ve been there too, I remember the pain.

For me, it was useful to sit on both chairs for a while acting as a Tech Lead. In this article, I share three dead simple tricks everyone can start using now to become better managers for themselves. No MBA required 🤓

1. Repeat (say it again)

Yes, the tricks will be very simple, even stupid, but they work! One of my favourites is repeating. It’s a very powerful yet underestimated technique.

Finding the courage to say something once is hard, especially when the topic is important to you. But don’t stop there! People forget, deprioritise and misunderstand all the time.

Internet is full of advice on how to say No, which implies that everything has to be said at least twice. Camille Fournier actually suggests you need to say it three times:

Finally, never underestimate how many times and how many ways something needs to be said before it sinks in. Communication in a large organization is hard. In my experience, most people need to hear something at least three times before it really sinks in. The Manager’s Path, Camille Fournier

Some examples where repeating is useful:

Remind about an ongoing problem if it was deprioritised.
Talk to someone else if the first contacted person wasn’t helpful.
Insist on prioritising some refactoring or housekeeping work.
Rephrase technical concept in plain English.
Keep pointing out the agreed coding practices until they are being followed.
Thank teammates for their help, again and again, in different ways.

Some channels may overuse repetition (e.g. TV series or popular non-fiction). It annoys us and we may think that saying the same thing multiple times is rude or dull. From my experience, if you are respectful and creative, everyone will appreciate your persistence.

2. Write full sentences (overcommunicate)

Remote work involves a lot of written communication via email and chat apps. Make your written communication explicit and straight to the point so that people don’t have to read 50 chat messages and two different Jira tickets to understand your last “@channel” message in Slack.

Two ways of saying “No update yet” about the hosting incident:

✅ No update yet. I’m checking with Mike from DevOps team about the issue with www.example.com deployment. I will come back to you in 15 min.

❌ No update yet. I’ll check with Mike about that issue.

(Who is Mike? Which issue? When will you check? When will my site go up!?)

Again, over-communication isn’t rude, it’s really the opposite. If something is obvious to you (e.g. there is an ongoing issue with www.example.com ), it doesn’t mean it’s obvious to everyone else. Give them the necessary context as part of your text message, and you’ll get meaningful responses faster.

3. Take care of yourself

If I would need to limit this article to only one piece of advice, I would keep this one.

You know better than anyone else when you are stuck or bored or confused. It’s very normal and it happens to all of us from time to time. Take action to get yourself out of it. If we all as individuals will take care of ourselves, many problems will be resolved much quicker and easier. Uncommunicated problems create more problems.

Your manager may catch some signals of your burnout when it’s too late. Help them and ask for a break sooner.

Your boss may have no idea that you want to leave the company because you hate DevOps work. Help them and ask for more frontend work in the upcoming project.

Your client has no idea that you are a morning person. Help them and ask to move late meetings earlier in the day. Repeat if it didn’t work from the first time 😃

There is no point in struggling at work. Happy people deliver better results, but what is more important, they make other people happier.

Hopefully, these simple tricks will make you a bit happier at work too!

Let Cloudflare CDN speed up your classic website like it's static

Sat, 08 Aug 2020 18:20:34 GMT

One obvious strength of static sites is their performance. The pages aren’t generated by the server but instead pre-built into HTML & CSS files.

Many of us developers have already played with the technology, built their own static site generator and learned the pros & cons of this approach. I won’t discuss all of that in this article. Instead, I will remind ourselves of something else that’s been there for years — CDN.

These days CDN setup should not necessarily be very complicated and enterprisy. In fact, I will be using free Cloudflare tier in my examples. Other CDNs have the same or similar setup.

How it works

When your web server returns a page, let’s say “https://www.mozilla.org/en-GB/”, it also returns Cache-Control header explaining to the external world how to cache this specific page. For example, it can say “do not cache me at all” or “cache me for an hour”, please.

Browsers and CDNs respect Cache-Control header when they serve web pages. If the page can be cached, they save it in their cache storage and next time serve cached version without ever touching your web server. That’s how a dynamic WordPress site can behave like static for the entirety of anonymous users.

Let’s have a look at https://www.mozilla.org/en-GB/:

HTTP status of the page is 200 meaning that this page was not cached in user’s browser yet.
Mozilla.org server returned cache-control: max-age=600, which means “Hey, browsers and CDNs: cache this page for 10 min max.”
Cloudflare CDN indeed has already cached this page (HIT)
I’ve got a cached version which is 96 seconds old.

If within those 96 seconds something has changed on that page, e.g. a typo has been fixed, then I will still see the outdated version for the next 504 seconds. To avoid the page with typo to be served from CDN cache, developers from Mozilla can either flush CDN cache from Cloudflare admin UI or by using their API.

Now let’s dig into the details.

Enabling cache beyond static files in Cloudflare

This step will vary for each CDN service. In Cloudflare, you need to create so-called “Page Rule” that will enable “Cache Everything” mode for specified page pattern. Example below:

Apply this rule to the entire domain
(Optional) Switch off “Always Online” feature in favour of stale-if-error (will be discussed below)
Cache everything (as opposed to caching only certain file extensions)
(My favourite one) Respect “Cache-Control” header from my web server (also known as “Origin”).

Note that I asked Cloudflare to follow Cache-Control directives returned by my web server. It gives me unlimited flexibility in configuring caching TTL for different pages. In the following section, we will discuss it further. For now, I have to add that in addition to item 4 you need to configure “Browser Cache TTL” setting in Cloudflare to “Respect Existing Headers”.

If you don’t want to mess with Cache-Control in your codebase, you can ignore item 4 and “Browser Cache TTL” setting completely. Cloudflare will add Cache-Control header for you anyway and you will be able to fine-tune it by “Page Rules”.

Adding Cache-Control header to your dynamic content

In my experience different site pages and query params may have different cacheability opportunities. Think of it as if parts of your site are completely static and others are very dynamic. With Cache-Control you can achieve this behaviour.

server.get("*", (req, res) => {
  if (
    // Allow to bypass CDN cache by adding ?bypass=cdn to URL.
    req.query.bypass === "cdn"
  ) {
    res.setHeader("Cache-Control", "no-store, must-revalidate");
  } else {
    res.setHeader("Cache-Control", "public, max-age=0, s-maxage=3600, stale-if-error=3600, stale-while-revalidate=30");
  }
  return handler(req, res, app);
});

The example above is a simplified Express handler to vary caching behaviour based on the incoming request. You can achieve something similar in any popular web framework.

Note that Cache-Control directive is a bit more advanced in my example:

max-age=0 - do NOT cache on a browser level
s-maxage=3600 - cache on CDN (shared cache) for an hour
stale-if-error=3600 - serve stale cached version for one hour more if the origin server is not available (supported by some CDNs)
stale-while-revalidate=30 - serve stale version while the new version is being fetched from the origin server (supported by some CDNs)

You can build your version of Cache-Control that will serve your needs.

Invalidating cache

In the case of a static site, you need to re-build and re-upload assets to your server. Some services automate this process so that content editors don’t have to deal with it.

We have a similar situation with CDN cache: if you want the newer version of the page to become available to the rest of the world right now, then you need to invalidate the existing cache. Cloudflare users can do it either in admin UI or via API.

If you use CMS e.g. Wordpress or Drupal, they may have plugins for automated cache invalidation.

Otherwise, you can call Cloudflare API directly in the appropriate place of your codebase. The most used API endpoint is POST zones/:identifier/purge_cache - purges cache for specific URLs.

Note that Cloudflare doesn’t offer cache purging by wildcard. There is “Cache Tags” feature on Enterprise tier but I have never used it.

Other CDNs offer cache purging via API too. For example, Fastly has soft purging in addition to hard purging. This is something I miss in Cloudflare API. Let’s say I updated content page in my CMS and it automatically purged cache for some URLs that were affected by my update. If I managed to break the site with my update, then purged URLs will be down for all anonymous users. With soft purge + stale-if-error you could stay always online.

Alternately to automated cache purging, you can just keep cache TTL very short (10 mins like in Mozilla example) instead of triggering automated cache invalidation on every content change.

stale-if-error or Always Online

As you may remember, I suggested to switch off Cloudflare’s “Always Online” feature (which is often enabled by default) in favour of stale-if-error. stale-if-error isn’t noticeable for the end users while “Always Online” adds Cloudflare banner at the top of your web page informing your users that the site isn’t working at the moment.

stale-if-error is a standard Cache-Control directive that is supported by other CDNs as well. It asks CDNs and browsers to serve stale cache if the page isn’t available on the origin web server. Different CDNs can understand page availability differently. For example, Cloudflare will respond with stale content only to the specific error codes:

500 or 503 error codes trigger neither Always Online nor stale-if-error.

To summarize

Modern CDNs (and HTTP) provide a simple and elegant way to make parts of your site behave like they are static. CDN cache protects the site from traffic spikes and makes some of the site errors and instabilities invisible for end users. It’s not just for heavy enterprises. A mid-size website can save computing costs of their hosting by enabling CDN cache for the most popular site pages.

Of course, you should still work on the performance of the original site but CDN cache can be nice low-hanging fruit in your journey 🍒

Liked this article? Have a question? Please join discussion on DEV 👩‍💻🧑‍💻

How to investigate technical solutions

Sat, 23 May 2020 20:00:34 GMT

In my previous post on the subject I suggested the long term approach to the learning problem: focus on general knowledge rather than on specific tools and implementations. But what if you need to investigate a new technical field right now, let’s say this week, to proceed with the project at hand? Tech leads do this kind of work regularly in order to prepare high-level estimates and architect new systems.

In this article, I will share my approach to a quick technical investigation. I apply it to new technologies and any other unknowns as they appear in my daily tasks. I mapped the steps to the days of the week, but the timeline can be scaled up or down based on the size of the problem. So, let’s get started:

Part 1: Monday

😍 You are great

It’s totally fine to not know something. Don’t treat it as your “fault” or a lack of talent/education/seniority. You are going to figure it out and you are great!

🔍 Be specific

Narrow down the area of investigation as much as possible. In practice, it means that technical investigation starts with business investigation. When the problem is defined, ensure you can’t solve it without further investigation. Sometimes people ask for AI, but their problem can be solved with a regular expression. Stop thinking that your solution isn’t “cool” enough. It’s super cool as long as it solves the problem.

🙋‍♀️ Ask people

If you need to proceed with further investigation, then first ask your colleagues and friends who were working on something similar in the past (don’t confuse friends and colleagues with random strangers on the internet!). There is no point in learning something the hard way if you can just ask your teammate for help. An extreme variant of this option is to hire a person who has the necessary experience and learn from them.

📝 Pick 10 random articles

Google your problem definition using different wording and pick 10 random articles and videos (it also can be one short book). List them in your notes and start reading them all from top to the bottom. Don’t try to figure out your final solution, don’t make any decisions just yet, don’t try code snippets suggested in the articles. Just read them.

Keep reading and taking quick notes. It can be a simple bullet list, a drawing or a mind map. Stop when you finished with your 10 articles. Sleep on it.

Part 2: Tuesday

🏁 Fill in the gaps

Review your notes and compare with the problem definition. You’ll notice some gaps in your notes. Google them again, find 2-3 extra resources and add them to your list. Finish the notes and stop gathering information. Most likely you have already learned just enough to proceed to the next step.

👯‍♀️ Show it to a teammate

Now it’s time to present your notes to someone else. Explaining the topic to another person will help you understand what you learned.

While presenting, reflect the fact that the information is not yet verified. For example, don’t say “The best A/B testing tool is X”. Instead, say “I found several authors who really enjoyed X”. Pay extra attention to the remaining unknowns (instead of leaving them out of the discussion).

Together, narrow down potential solutions to a minimum. For example, if you have five A/B testing services in your notes, pick two most promising based on what you learned so far and on the problem definition. Don’t worry that you may occasionally exclude the “right” solution from your shortlist. There is no one right way to solving any technical problem.

Part 3: Wednesday, Thursday, Friday

🏖 Try it in a sandbox

Finally, we are in the famous practice step. I remember times when I was putting together something new that I barely understood only to push it to production faster. This approach was fast at the beginning, but in some cases, it slowed down further development dramatically.

Before starting to write any code, prepare a list of outstanding questions that you want to clarify through practice. When the problem is small enough, you can start implementing the real solution without properly finishing the investigation. But in the general case, proofs of concepts should not go straight to production to avoid unnecessary risks.

✍️ Write a summary

Finish with a concise report that you wish had been written by someone else before you started your investigation. Don’t put too much effort in it - such reports usually become outdated in 6-9 months. Share the report with the team and agree on the next steps. Switch to something else for a little while to clear your mind.

To summarise

My quick investigation process includes the following parts:

Gathering & structuring information on a very narrow topic (X time)
Sharing with someone else and filtering out (X time)
Building proofs of concept to figure out some crucial details (3X time)
Putting together a summary for discussion and further actions.
Iterating.

This process is very intense because you consume and analyse a lot of new information within a short period of time. It also can be uncomfortable to touch something completely new and to feel stupid after being “an expert” in your field. As Josh Kaufman explained in “The first 20 hours” talk, the main barrier to learning something new is emotional. It’s often hard to start and even harder to finish. I hope that my article will help you to overcome those issues when you next time will be investigating a new technical problem. Remember, you are great!

Liked this article? Have a question? Please join discussion on DEV 👩‍💻🧑‍💻

The Tech Lead rule: Management first, coding second

Sun, 05 Apr 2020 15:30:34 GMT

I opened my previous post about 1:1 meetings with the following paragraph:

Every new Tech Lead will struggle to find time for coding in their busy day. That’s very normal because when you step into Tech Lead shoes you suddenly need to learn all those management tools from planning and prioritisation to decision making to conflict solving. You never know what you will need first, so you will have a fun time learning a bit of everything in parallel (and trying to meet your coding hours quota at the same time).

I now realised that the idea of that paragraph is not very obvious, especially if you are just about to start as a Tech Lead.

Tech Lead is a manager

It seems to be clear that we, Tech Leads, are developers, and we should write some code, should stay current and keep our hard skills sharp.

What is often forgotten or put at lower priority is that a Tech Lead is a manager and our management skills are the key to our success in the role.

It’s true that as Tech Leads we don’t usually have full-time management responsibilities (and often have no authority), but it doesn’t change the priority: management first, coding second.

Even if you’ve got a very small team and management bit takes just 20% of your time, that 20% is still the most important part of your job. If you deprioritise it or do it poorly, then your small team is in danger: they may miss the deadline, spend time on the wrong task, get stuck or blocked by another team, overengineer the solution, overpromise to the stakeholders, fail at their performance quotas without understanding what they did wrong. Tech Lead as a manager can prevent or notice such issues sooner. Tech Lead as a developer can only try to write the entire codebase alone (and fail at that).

Management first, coding second - once you start to see it in this order, it will become clearer what’s next.

Tech Lead is a developer

Usually, we learn the basics of management by watching how other Tech Leads and managers work. Some of us are good leaders naturally, and it helps too. Still, most of us grow into Tech Leads from Senior Developer role and we don’t have a degree in management. Furthermore, you may be affected by a bias that management isn’t that important and only creates problems for the dev teams.

It’s important to recognise that you are now supposed to do a new type of work, that you have never done professionally before. It’s time for opening your mind for learning and practising new skills. It’s not a good time for full-day coding tasks.

Management tasks

Now, when we have the priorities cleared, let’s review major areas of your management efforts.

📆 Invest in team planning

Help each team member to create a plan for their working week. It doesn’t mean that you need to assign tasks to everyone (sometimes you need, but it’s an edge case). Your goal is to create and maintain an environment where each team member can figure out what they will be doing tomorrow without checking with you/your manager/stakeholders every day.

You’ll need to have a plan for your week, too, and it should reflect the “management first” rule.

One common piece of advice to novice Tech Leads is to get better at time management. I think that you should first get better at mid-term planning (monthly and weekly). Then it will become easier to manage your time within each day.

📚Invest in knowledge sharing

Make sure documentation is treated seriously by the team. Lead by example: document things that are often asked by the clients and other team members.

Make yourself available for questions during the day. If you put yourself in DND mode for an entire day, you won’t be able to create an environment where people are willing to help each other. In such an environment, you’ll be able to step back from time to time, and nobody will notice.

🌀Invest in workflows and processes

Meet your new best friends: company workflows and processes. They are “reusable libraries” of management. They can help many developers stay productive and creative, just like software libraries and frameworks help us build projects quickly and consistently.

To elaborate further on this metaphor, software libraries should be carefully chosen and maintained by the technical team. The same applies to the workflows and processes in the company. No one software library works for all development projects, and no one workflow fits every software engineering team.

As a first step, make sure you understand and follow the existing organisational workflows yourself. As an individual contributor, you could sometimes think that they were an unnecessary bureaucracy. As a new Tech Lead, make sure it’s not the case, or initiate the change. Workflows should serve the teams, not the other way around.

Give extra focus to workflows that put you in a gatekeeper position (for example, pull requests can’t be deployed without Tech Lead approval). In rare cases, it may be a reasonable requirement, but usually, it indicates a problem.

👯‍♀️ Regularly check in with your manager

So now you keep an eye on the team. Start sharing your observations with your direct manager early, partly to let the problems bubble up. It can be a summary of what went well, what had to be fixed by you, and what requires senior management attention. One of the most important management rules is “No surprises”. If you share the team status regularly, then senior management will be prepared to step in when necessary.

Funny enough, they may see your problems from various unexpected angles. Be open to that. Sharing your vision helps to align the priorities in both ways.

Example 1

You: I have to manually perform project deployments and take database backups. It’s not a big deal for me, but I think it can be improved to follow best practices.
Manager: the project is growing fast, and the dev team should be prepared for frequent and safe deployments. Make DevOps initiative the main priority starting from next week.

Example 2

You: I have to manually perform project deployments and take database backups. I think it’s a major team blocker (and this is just not a fun job for me).
Manager: there will be no more deployments for that project starting from next month. It will be replaced with the new development project which should be the main priority starting from next week.

You may say that the manager should have shared the details about the future of your current project sooner. Of course, they would share at some point or they might have already shared it but you missed the point.

From my practice misalignments happen all the time because everything keeps on changing. Sharing your successes and problems with your manager regularly will help both of you to have “no surprises”, or at keep them at a minimum.

A final note that you should not be focused on problems only, otherwise your manager will start escaping from you.

Developer tasks

So, your team know the priorities, help each other when they have questions, and follow workflows to perform common tasks. You manager is aware of some problems that you faced and helps to fix them. Not everything is going so well, but you have a plan in place to improve things in the long run.

You still feel very busy and unproductive because you spend less time coding and more time planning and communicating.

🐌 Reduce your expectations

Some organisations explicitly set coding expectations for Tech Lead role. Others don’t do that because it may depend on the team and the project at hand.

In either way, you’ll have significantly less time for coding because:

You are expected to do some management
You are not good at management, and you need to learn how to do it well
You are performing technical oversight and switching context between several different tasks per day

Accepting this change was very hard for me. It took almost a year for me to understand that investing in my management skills will free up some time for technical tasks in the long term.

🥎 Pick small, not urgent tasks

When you include yourself in a sprint as a developer, prefer smaller tasks that don’t block other team members. If it’s not possible, then prefer pair programming or very close collaboration on a task so that someone else will be able to finish it without you.

🛩 Block time for coding sessions

This is a very common recommendation: book a time for coding in DND (Do not disturb / in airplane) mode, and everything will be fine. From my experience, it will indeed, if you follow all the other recommendations listed above.

I personally enjoy having 3-4hr focus slots at the beginning of the day, but we have our daily standup meetings in the middle of that slot. They immediately kill my focus as we start to discuss different aspects of the project, some problems and blockers that require my attention, and the new surprises that should be communicated up.

I accept this distraction because I find our daily standups very valuable from the management perspective. I could also skip, postpone or make them asynchronous. As a Tech Lead, when you make choices like this, you have to keep the organisation and the team as your priorities.

👏 Take off your Tech Lead hat

Normal Tech Lead schedule will not allow you to grow as a software developer at the same pace as it used to be. However, your technical expertise is crucial for running a technical team. Yes, you can learn from your teammates while reviewing the code. Yes, you can experiment with the code while you are working on your smaller tech tasks during your focus hours. Yes, you can read some blog posts in your spare time. Yes, you can build a pet project. It’s great, but not enough for staying current in the modern IT world.

Tech Lead role isn’t the final career destination for most of us. First of all, it’s very challenging because you are a manager and a developer at the same time, and you are kind of okay at both. That’s why folks often move on to full management or full development roles from this point. Your Tech Lead experience will help you succeed in either route.

Some companies periodically rotate Tech Leads in their teams. Others try to spread the management burden across the whole team (”🦄 No-Managers teams”). Finally, you can simply ask your manager to put you on another project for a couple of months. It may be enough to get refreshed and upskilled.

To summarise

It took me two years to realise that “How to find time to code?” is the wrong question for a Tech Lead. You should focus on getting better at management, and ask your boss to give you “management holidays” if you need to invest more time in your hard skills.

Tech Lead is a very challenging role, partially because we put a lot of pressure on ourselves and hesitate to ask our senior colleagues for advice. This experience is “unforgettable” as it changes your understanding of software development process. With this new understanding, you can do more either as a developer or as a manager.

Good luck!

Liked this article? Have a question? Please join discussion on DEV 👩‍💻🧑‍💻

Why 1:1 meetings are so valuable for Tech Leads

Wed, 01 Apr 2020 23:30:34 GMT

Every new Tech Lead will struggle to find time for coding in their busy day. That’s very normal because when you step into Tech Lead shoes you suddenly need to learn all those management tools from planning and prioritisation to decision making to conflict solving. You never know what you will need first, so you will have a fun time learning a bit of everything in parallel (and trying to meet your coding hours quota at the same time).

One cheap thing that you can start doing earlier in your career is to set up 1:1 (one-on-one, face-to-face) meetings with your team and direct manager(s). That’s low effort to schedule a monthly call into your calendar, and a huge investment into your people management capabilities.

First, let’s see why 1:1s are valuable, and then I’ll share some practical recommendations how to get started.

The value of 1:1s

1:1 meetings exist in management practice to build and maintain an essential human connection between you and another person who happened to be your colleague. In the long run, it simplifies all people management tasks that fall on a Tech Lead shoulders.

Many of us don’t have specialised people management skills when we start as Tech Leads. Most of us don’t realise how much people management work we Tech Leads actually do, so let me just list a few things to give you an idea:

People performance / handling low performers
Onboarding & mentoring
Engaging & motivating
Convincing people to get things right / follow the workflow
Handling drama queens / emotional moments
Handling complaints
Asking and giving help
Delegating
Firing staff (Oops.)

That looks like a full time job, but the funny thing is that Tech Leads are supposed to be aware of all these people management aspects and handle them on a basic level while spending a couple of hours per day max on it.

Instead of learning all of that in detail, you can invest in something that is a foundation of people management - human connection. Practising focused 1:1 meetings with each member of your team (and with your manager, of course) is the easiest way to get better in all those things at the same time.

Tech Leads are often generalists, and 1:1 is another general tool that can help to solve different problems.

How to run my 1:1s

There are books written on the topic, but you will need them only if you decide to move further on the management ladder. Otherwise, you can use the basic, “common sense” recommendations:

⏱ Start with monthly 45min meetings with 1 or 2 teammates. Add more slowly.

You should really stick to your company policy around 1:1s. If you don’t have one, I can recommend starting with monthly meetings and make them more frequently if needed. Some of my 1:1s are monthly, others are weekly or quarterly. What’s important is that they all are recurring, and I generally try not to skip them.

👯‍♀️ Discuss what you both have in common at work

Should you prepare some interesting intellectual topics to discuss on your 1:1s? Not at all. You can stick to what you already have in common: a project that you both are working on. It doesn’t mean that you should be discussing a task that is currently in progress. Rather, you can talk about long term vision, current development workflow, what was challenging and what was frustrating in the past month for the other person, etc. Making a discussion a bit more generic can suddenly reveal very concrete and interesting things.

💎 Feedback exchange

Again, books have been written on it. Feedback is the root of improvement and growth, so take it seriously and prepare before the meeting.

Give colorful positive feedback. Make sure it’s detailed enough. “Well done!” isn’t enough.
Give corrective feedback. Google different ways to do that. You should be framing it in “things to improve” message for the other person.
Ask for corrective feedback. If the other person is not prepared or shy, then try questions like “How I could help with X”, “What would be an ideal scenario of Y”, “I need your advice about Z” etc. Corrective feedback is a treasure that you must collect in order to improve. Try hard to get your treasures.

👂Practise active listening

Active listening is a skill that helps in many areas of our work, especially when talking to our customers and users. You can use your 1:1s to practise this skill. Start from noticing when you don’t understand or don’t really care about what the other person says.

Example: when a junior team member was explaining in detail how they tried to install the project locally, you were thinking about your next meeting in the background of your mind. Instead, you can ask a few questions to figure out if it’s a problem in the project documentation, installation script, the developer skills. Maybe everything is totally fine, but your junior team member is really worried that they spent 2 days on it and they will be fired because of that. Listen to them.

📒 Prepare private 1:1 document to take your own notes

You will need to remind yourself of the outcome of previous 1:1 meeting as well as keep notes for the next one. Simple Google Doc should work just fine.

🎭 Don’t play games

Don’t try to pretend that you are a friendly extravert who shares all the opinions of another person.It will not help you maintain a healthy relationship. Behave as usual.

🐢 Keep calm and have your 1:1

Don’t rush, don’t complain that you are very busy, don’t multitask while on 1:1. If you are not in the right mood / not prepared for your next 1:1, then better to postpone and come back prepared.

To summarise

1:1 is a simple and powerful management tool that is often underestimated by novice Tech Leads. Regular 1:1s fall into “Important, not urgent” category of work — they are an investment in your people management capabilities. You don’t need to learn anything specific to get started, and it will get better and better with practice 🌈

Practical thinking

Sun, 02 Feb 2020 00:30:34 GMT

I was first paid for some webdev related work in 2006. Since then, I’ve seen a lot of projects, played my role in several development teams, and worked closely with a few brilliant software engineers. Looking back and reflecting now, I think I have always been a mediocre developer, intuitively picking random opportunities and handling them well enough. In attempts to learn from better developers I was watching them and trying to copy their behaviour. I noticed a few things that they all do regardless of their specific role, seniority or tech stack. One of them is what I call practical thinking.

As you grow in your career, you’ll experience a lot of teachable moments, a lot of lessons in how things should or should not be. These can be “best practices,” or scars caused by mistakes. This unconscious buildup can cloud our thinking and reduce our creativity. When we close our minds and stop learning, we start to lose the most valuable skill for maintaining and growing a successful technical career. Technology is always changing around us, so we must continually experience that change.

Fournier, Camille. The Manager’s Path.

When I grew up, I suddenly realised that adults don’t think enough. Many of us are prisoners of our habits and habits of our relatives. We tend to overvalue our life experience and social status. We tend to avoid or replace thinking work with copy & paste from previous experience. It becomes more and more attractive as you become older. Don’t get hooked: stay curious and thoughtful.

The problem with applying this piece of advice in practice is that a developer can’t just sit down and think while their time tracker is running. First of all, it is not always encouraged by employers who imagine developers writing code 40hr/week. Secondly, it’s hard to switch our brain in thinking mode when we need a brilliant idea for your current task. Finally, popular web developer courses and learning materials often skip this bit and offer tools-focused rather than thinking-focused exercises.

What I noticed in behaviours of great developers is that they find a moment to think outside the box and apply results of their thought process to reality. This is what I call practical thinking.

Because of the habit of practical thinking, they generate more ideas, and observe promising ideas deeper. They ask more questions, and get more insights. They notice potential issues before they became a catastrophe. They see opportunities for themselves and potential in talented team mates.

Sounds great, and works great too, after some practice.

🤬 Start from pain points

When I face an uncomfortably annoying problem, I try to think about it from different angles and write down my thoughts. It doesn’t solve the problem magically, but it helps me understand different aspects of it much better. It’s easier to start building a habit of practical thinking from very uncomfortable problems because they are already scratching you on the background of your mind. You will want to resolve them.

🎨 Visualise your thinking process

Bullet list, mind map, whiteboard, colored pencils - find visualisation technique that works for you best. Human built-in RAM is very small for manipulating large controversial data sets. So use swap!

🤖 Automate

When you work on a boring task, think how it could be automated. In a worst-case scenario you’ll figure out that the task is actually hard to automate, but at least it will become less boring.

📆 Actively participate

When you are sitting on a meeting without being actively involved, ask yourself why. Did you come prepared for this meeting? Are other attendees feeling the same? How it could be improved? I know some teams dropped daily stand-ups because all attendees agreed on another way to share their status.

🎓 Share your knowledge and learn from others

When you are not satisfied by your team mate’s work, check if you can help them to improve. Is there hidden knowledge about the project that you can share? Are you open to alternative solutions that your peer proposes? Was a bug introduced because of code obscurity? How to improve it so that other developers will not repeat that mistake?

I listed just a few examples. You will find yours and develop your own style of practical thinking. Good luck with it!

Be prepared that your boss may not like that you think too much about something that is outside of your current tasks list. It’s senior leadership problem to re-focus employees on a company mission and give them just enough autonomy and responsibility, and this problem is not simple. Help your boss find the right problem for you to solve if you picked not the best one.

One final note. The more thinking you do as part of your job, the less chance you have of being replaced by robots.

My tech year in review

Thu, 26 Dec 2019 15:00:00 GMT

2019 was an interesting and productive year for me. At SystemSeed, I keep sharpening my Tech Lead skills as well as observe the outer space for promising tools, good advice, and inspiration. Unfortunately I spend less time sharing my knowledge publicly and contributing to the open source, and I’m grateful to thousands of talented developers who build amazing libraries, frameworks and modules (that I have to cope with). Without you, web development wouldn’t be so wild and creative job. I’m proud to be part of web development industry, and I love my job very much ❤️

Below are a few highlights from my tech work in 2019. All opinions are my own.

Books

As I get older, I tend to choose books over blog posts. By the end of the year I can barely remember a good article or YouTube video - there were too many of them. It’s much easier with good books: I’ve got only a couple of them to mention.

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

The authors of Accelerate book acknowledge that business leaders are often unaware of DevOps as a powerful and effective instrument for IT organizations. This book helps me to facilitate conversations about importance of DevOps with clients and stakeholders who may push back on everything that is not pure feature development. In fact what businesses often want is not just a feature, but rather an ability to develop and deliver features in a good pace, an ability to make changes as businesses learn from their users and evolve their strategies.
Business wants developer operations to be optimized for change. It’s everyone responsibility to ensure that DevOps is part of project scope naturally, part of planning and prioritization. Accelerate book is amazing in explaining that.

My video review for SystemSeed team is here:

A Philosophy of Software Design

This is a brilliant read that I can recommend to every developer regardless of their experience and specialization. You will definitely learn or re-discover something valuable about software craftsmanship.

I have noticed that the design-it-twice principle is sometimes hard for really smart people to embrace. When they are growing up, smart people discover that their first quick idea about any problem is sufficient for a good grade; there is no need to consider a second or third possibility. This makes it easy to develop bad work habits. However, as these people get older, they get promoted into environments with harder and harder problems. Eventually, everyone reaches a point where your first ideas are no longer good enough; if you want to get really great results, you have to consider a second possibility, or perhaps a third, no matter how smart you are. The design of large software systems falls in this category: no-one is good enough to get it right with their first try.

Apart from these two books, I would like to mention “Clean Architecture” by Uncle Bob (my video review here). It was a little bit hard to read for me because of special terminology and references to SOLID in every single paragraph.
If your team already speak SOLID language, it will be a good reiteration of “Clean Code” for them. Otherwise “A Philosophy of Software Design” might be a better first step. It does not introduce that many terms, and for me it was more intuitive, more inline with my own experience.

Technologies

Decoupled Drupal

As you may know, most of my experience in web development is somehow related to Drupal. Once I joined community back in 2011, it affected dramatically my further career and views on technology in general.

Last year I was working with Drupal 8 as a pure backend system. User facing applications were decoupled from Drupal and written in JavaScript (React, Next.js).

You can watch and read about decoupled Drupal in detail here:

If you want to investigate this approach deeper, consider one of the available boilerplate projects. Please don’t expect it to be super straightforward. Decoupled Drupal is quite far away from the popular JavaScript stacks in terms of developer-friendliness.

Kubernetes

Surprisingly, as part of my job at SystemSeed I had an opportunity to learn some basics of AWS, Kubernetes, Helm, Terraform and other hosting-related stuff. A huge benefit of running your own cluster is that you have unlimited flexibility on hosting level. Node.js, PHP, Go, Elasticsearch, Redis - everything can be dockerized and reused for both local development and production run.

My daily routines include basic operations with deployments, pods and jobs. I would love to have them automated eventually so that I can focus on building new features rather than on running the same commands in terminal.

To sum up, it turned out that Kubertenes isn’t as scary and complected as I thought. If you plan to touch it, I can recommend high level overview from our CTO: “Kubernetes, KOPS & Helm”.

Semantic UI

The other day I was reviewing the latest State of JS report. I found it a bit naive that most of developers who work almost only and exclusively with JavaScript consider themselves Full Stack developers. Full Stack is when you put Kubernetes and Semantic UI one by one in your tech list 😄

But back to my list. This year I had a chance to try Semantic UI and its React addon. It’s well documented, feature-rich and very developer-friendly library. At SystemSeed we used it for admin dashboard, but I can see its potential for other types of MVP.

As a side note, I’m intrigued by the raise of Tailwind CSS framework. In some cases component-based frameworks like Bootstrap or Material don’t fit custom design requirements. It such cases Tailwind may be a good alternative.

Auth0 & Okta for user management

These are two very different identity access management tools that I worked with recently.

Auth0 has a generous free plan with powerful APIs for developers and No-Code features for startups. If you plan to scale, Auth0 offers a lot of advanced features on their paid tiers. I had only positive experience with this service and can recommend it to everyone who considers cloud-based solution for user management.

Okta positions itself as Enterprise Identity Standard. If you work with larger organizations then at some point you will face a need to integrate with Okta. It’s the opposite to Auth0 in terms of learning curve and developer-friendliness. It’s fine to work with though, and it seems to have a huge list of features that make Okta attractive for enterprises.

JAMStack

A few paragraphs above I made a joke about Full Stack Developers. That was a sad joke for me. In fact, frontend developers can develop and deliver entire projects without traditional “backend”. Platforms like Netlify or Zeit make it very easy to build professional websites on top of JAMStack. Developers spend more dev time building project-specific UIs rather then setting up backends and APIs.

With free GitHub account they can host codebase and assets as well as set up project management workflow and CI.
On a free Rollbar plan, they can have error monitoring and alerting.
With Cloudflare they can have powerful CDN for great performance and Cloudflare Workers for running custom application logic without a need for a server, all for free.
With FaunaDB, they can store and retrieve their data, without a need for a server, again, all for free.
With Auth0, they can have secure login and user management, for free.
With Algolia…

I guess you’ve got the idea: everything that is not specific to the business can be delegated to a cloud service at a lower price then developing and hosting in house (It’s not JAMStack-specific though, and can be applied to any stack).

I’m curious if Full Stack in the State of JS report means an ability to set up appropriate third-party services and complementary NPM packages to get job done.

In general, I’m optimistic about this approach regardless of complaints about risks, data ownership, poor architectures. Javascript tech stacks unleashed creativity of hundreds of thousands frontend developers who wanted to start building their own things. As a next step, No-Code trend will allow non-techies to build complex applications without writing a single line of code. As developers, we may not like this trend but it’s already there.

React state management

React Hooks is one of those tech concepts that I found truly elegant and intuitive. Unfortunately, there was too much of unhealthy hype around them and around React state managers in general. I would prefer people to spend more time learning web standards and general programming practices rather then building yet another state manager for React.

React Native

It’s common to mention React Native when we list benefits of React over some other JavaScript frameworks. For me, one real benefit is that developers who already know React will learn React Native faster than Swift of Flutter. They still will need to learn specifics of app development very well, and read a decent amount of app-specific code, sometimes in Java or Objective-C.

For web developers who already know React and want to start building native apps professionally, React Native is a great choice, but be prepared to work hard.

Watch my overview of React Native for SystemSeed team here:

Strong Customer Authentication

If you build web sites for EU, you already know about GDPR regulation. The next challenge is SCA, Strong Customer Authentication for payments. As far as I know, initial plan was to enforce the new standard in September 2019, but many European regulators postponed it until the end of next year. One of online payment processors that was ready on time is Stripe. They released a new version of their API that is optimized for SCA with minimum amount of work for developers. I enjoyed working with their new API and as you may already guess I shared my experience with SystemSeed team: watch it here.

Tools

I’m not a computer geek, but I’m quite comfortable with terminal and can impress non-technical people who watch me pressing Ctrl + R all the time. Below are some tools that I use every day at work:

Macbook Pro 2016 mounted on an arm
Firefox and Chrome (but I try to avoid Chrome)
BetterTouchTool
Docker
PhpStorm
VS Code
iTerm
Evernote
1Password
Wakatime (for personal purposes, I don’t report data from it to my employer)
Pen and paper

What’s up next

I am a workaholic developer. I love working. I can forget about everything when I’m hooked by my next project, either routine or challenging. I know very well how “the flow state” feels (it’s amazing!), as well as how burnout and anxiety feel. I’m learning how to keep balance between work and rest, how to avoid perfectionism and do more with less.

Programming languages and frameworks are great, but these days I’m more interested in human side of software development. How to build working environment where humans feel safe and empowered to unleash all their intelligence and creativity?

In the past I thought that I must work hard so that later I would have time and resources for a creative and relaxed hobby. I thought I have to separate work and creativity. I don’t think so any more. We spend most of our active hours at work, so why wouldn’t we make them fun, creative and fulfilling?

I wish a creative decade to all of us 🎄

Automated releases in a cross-language monorepo

Sat, 14 Sep 2019 10:00:00 GMT

On monorepos

Monorepo is a popular way of organizing code bases in large organizations like Google, Facebook and Twitter. You can also find many open source projects that use a single git repository to store and develop multiple sub-packages. Some examples are Babel and Laravel.

If you are not familiar with the term “monorepo”, check out this 5 min video from Fabien Potencier, creator of Symfony framework.

I personally have been using this technique for many years without knowing its name. The idea is very simple: you store your backend/ and frontend/ folders in one repository. This is a natural approach for full stack developers who usually touch both folders on a daily basis. It is very handy to have entire project codebase in one place when you develop and test the application. Below just a few benefits that came to my mind:

Fewer repositories to maintain on GitHub (less git clone and git pull commands to execute)
Fewer steps to install full application on local machine
Less CI configuration to spin up and test the entire project
No mocking needed (all services are installed and available for testing without faking their APIs)
Easier to deliver entire features that involve backend and frontend work

On the other hand, this approach isn’t applicable to all teams and all organizations. Read an article “Don’t ask if a monorepo is good for you – ask if you’re good enough for a monorepo” to learn more about monorepo disadvantages. It’s important to remember Conway’s law:

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

In case of SystemSeed, monorepos feel very natural because they reflect communication structures in a flat team of full stack developers. For different kind of organizations, setting up a monorepo may require significant changes in development & collaboration practices, which is not always worth it.

Automated releases

Back to original topic for this post, let’s say we have a monorepo with two (or more) separate packages written in different programming languages: PHP for backend and Javascript for frontend. When changes are made in one of them, or in both, we want the corresponding packages to be released in Packagist for PHP and in NPM for Javascript.

Initially I prepared myself for writing a lot of bash scripts in our CI to make automated releases for both packages work. It turned out that everything has already been written in Javascript (Atwood’s law in action), and all I needed is to install and configure a couple of packages.

Step 1: install and configure semantic-release

From project description:

semantic-release automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package.

This removes the immediate connection between human emotions and version numbers, strictly following the Semantic Versioning specification.

If all your code is written in Javascript, you can skip further reading and go ahead with semantic-release-monorepo.

In my case, I had to install semantic-release for both packages separately.

Example package.json for PHP:

{
  "name": "@kalabro/mixed-monorepo-php",
  "version": "0.0.0-semantic-release",
  "description": "PHP subpackage from mixed-monorepo.",
  "author": "kalabro",
  "license": "MIT",
  "repository": "https://github.com/kalabro/mixed-monorepo-php",
  "release": {
    "plugins": [
      "@semantic-release/commit-analyzer",
      "@semantic-release/release-notes-generator",
      [
        "semantic-release-slack-bot",
        {
          "notifyOnSuccess": true,
          "notifyOnFail": true
        }
      ]
    ]
  },
  "scripts": {
    "semantic-release": "semantic-release"
  },
  "devDependencies": {
    "semantic-release": "^15.13.18",
    "semantic-release-slack-bot": "^1.1.2"
  }
}

Example package.json for Javascript package:

{
  "name": "@kalabro/mixed-monorepo-js",
  "version": "0.0.0-semantic-release",
  "description": "JS subpackage from mixed-monorepo.",
  "main": "index.js",
  "author": "kalabro",
  "license": "MIT",
  "repository": "https://github.com/kalabro/mixed-monorepo-js",
  "release": {
    "plugins": [
      "@semantic-release/commit-analyzer",
      "@semantic-release/release-notes-generator",
      "@semantic-release/npm",
      [
        "semantic-release-slack-bot",
        {
          "notifyOnSuccess": true,
          "notifyOnFail": true
        }
      ]
    ]
  },
  "publishConfig": {
    "access": "public"
  },
  "scripts": {
    "semantic-release": "semantic-release"
  },
  "devDependencies": {
    "semantic-release": "^15.13.18",
    "semantic-release-slack-bot": "^1.1.2"
  }
}

Note that Javascript version has “@semantic-release/npm” plugin enabled. This is default semantic-release behavior that I switched off for PHP. When CI will call semantic-release (later in this article), semantic-release will do the following:

Analyze all commit messages since previous release.
Decide which version number to assign to the new release based on Angular Commit Message Conventions.
Add a new git tag for this version and push the tag to the remote origin (along with changelog notes).
Release to NPM (optional, switched off for PHP).
Notify the team in Slack.

Step 2: Publishing to Packagist

To add a new package to Packagist you need to link a repository with a valid composer.json file in the repo root.

It means that I have to push PHP code from my monorepo to a separate PHP-only repo for Packagist to be happy.

To mirror monorepo to separate child repositories, I used splitsh-lite, the tool that is used by Laravel and Symfony for the same purpose. The tool finds commits that affected the package’s codebase and pushes them to another repository. Obviously, it preserves all commit information so that semantic-release can decide what kind of release to create for each package.

Step 3: Configuring CI

In SystemSeed, we’ve been using Circle CI long before I joined the team in 2015. I’ve never worked with other CI tools but they all seem to be quite similar.

You can find example setup for Circle CI in a demo project on GitHub.

CI setup contains two steps. First, on merging in master splitsh-lite script is triggered. It mirrors new commits (of any) to the corresponding child repos.

See Circle CI config here: https://github.com/kalabro/mixed-monorepo/blob/master/.circleci/config.yml#L13
See ./bin/split.sh code here: https://github.com/kalabro/mixed-monorepo/blob/master/bin/split.sh (inspired by the script in Laravel repo).

The second step is to trigger semantic-release for each child repo. Again, a simple Circle CI config handles it on every push into child repo: https://github.com/kalabro/mixed-monorepo/blob/master/js/.circleci/config.yml

Result

You can find full monorepo setup for a real project here: https://github.com/systemseed/falcon

Falcon repo includes Drupal distribution on backend (falcon/ folder) and complementary React frontend (falconjs/ folder). The latter uses yarn workspaces inside to organize multiple JS packages & templates.

All you need to start developing is to clone the repo and run make install. When you are done and your pull request is merged in master, CI will figure out what to release and which version numbers to assign.

Give it a try and let me know your thoughts!

Don't get lost in never ending learning curve

Sun, 17 Mar 2019 13:00:00 GMT

Yesterday I spent a few hours learning basics of Kubernetes and then another couple of hours upgrading this blog from GatsbyJS v1 to v2. The fact of mentioning these two technologies in one sentence illustrates the state of web in 2019. The dream of Lego for web, where everyone can grab a container with any feature from authentication to ecommerce and easily connect to their projects, comes true with its own side effects: additional layers of complexity and dependency on many third party providers.

As a result, we can see more and more specializing in the industry. There is a MySQL expert and there is a Webpack expert, and they barely have anything in common. In my opinion, specialization is the best strategy for junior and mid-level developers.

If you are Senior Developer or Tech Lead, or Software Architect, then you probably recall that your career path had multiple rounds of specializing on different technologies and tools within one domain. My own path started from basic HTML & CSS back in 2004. Then I installed LAMP and learned a couple of foreach tricks in PHP to avoid copy-pasting. 15 years later I find myself digging into Kubernetes stuff and it’s not the final destination for sure.

The truth is that it is very easy to get stuck in another loop of never ending learning curve. Even worse, it’s easy to become demotivated and depressed when after so many years spent in the industry you feel that you left behind.

I want to share a couple of things that help me to stay inspired and motivated to keep climbing the curve:

1. Focus on General knowledge

Instead of installing every hot new library and diving into implementation details I try to spend more time learning generic things such as Maths, Computer Science, fiction, etc. They help to focus on understanding concepts over gathering facts. It’s fine to learn more narrow topics such as frameworks or libraries if you can abstract from immediate implementation and let your mind think why things built the way they built and which concepts underlie them.

2. Automated Testing

Often I feel uncomfortable working with new technologies and stacks because I don’t trust them yet. They are strangers in the room and I don’t even recall their names, so how can I begin to trust them? The answer is damn simple: start writing tests from day 1!

After working for a while on a large project where I couldn’t keep in mind all implementation details and review all committed code, I realized how calm and relaxed I am when new code is being merged. Thanks to the great team, and, first of all, to good tests coverage, you don’t need to worry that all the fancy dependencies will go crazy and shoot you in the foot.

Unfortunately, there are not that many good learning resources about automated testing so I decided to write my own blog post series about it. You are very welcome to follow me on Medium to check them out.

P.S.

Obviously, it’s essential to maintain a healthy work/life balance and have coding-free retreats on a regular basis. When I’m stuck with something at work, in many cases I’m just tired. The silliest thing to do in such situation is to continue working or, even worse, to attempt to learn something new.

Not so long ago, I started experimenting with my work day to reduce amount of time spent in front of computer. This is probably a topic for another post, hopefully before GatsbyJS v3 release 😊

Thank you for reading and have an awesome ride in never ending learning curve!

Reading list: on technical leadership

Sat, 04 Aug 2018 20:11:34 GMT

I’ve got a couple of great resources to share with those who eventually found themselves in a team lead / tech lead shoes (just like me).

Progressing from tech to leadership

Great write-up from a security expert and experienced techie leader Michał Zalewski.

But first, let me start on a somewhat somber note: what nobody tells you is that one’s level on the leadership ladder tends to be inversely correlated with several measures of happiness. The reason is fairly simple: as you get more senior, a growing number of people will come to you expecting you to solve increasingly fuzzy and challenging problems - and you will no longer be patted on the back for doing so. This should not scare you away from such opportunities, but it definitely calls for a particular mindset: your motivation must come from within. Look beyond the fight-of-the-day; find satisfaction in seeing how far your teams have come over the years.

The Critical Career Path Conversation (video)

John Riviello shares his story from being a senior engineer, taking the managerial route and then back to an individual contributor position.

8 Tips for Being a Good Tech Lead

In the best teams I’ve worked in, the tech lead role is a little like an invisible conch shell that gets passed around between team members throughout the hours, days, and weeks. One person often holds this conch shell most of the time, but other people also get the chance to hold the conch when it is appropriate. If you find yourself in the tech lead role, don’t be possessive of it. Recognize when it is time to pass the role to someone else, and when it is time to take the role back.

Cognitive Bias And Why Performance Management is So Hard

Trying to motivate a person to do a task that they’re procrastinating on due to anxiety is likely to have the opposite effect — it makes the task more meaningful, and increases anxiety.

These and other great articles appear in a great Software Lead newsletter.

Decode Alias and Union Types in Elm

Sun, 21 Jan 2018 18:58:34 GMT

I’m so exited to open this blog with a post about Elm, a functional programming language for building web frontend. As a user, I interact with Elm almost every day — we at SystemSeed use Pivotal Tracker as a project management tool.

As a developer, I started playing with Elm after a year of React experience and I found some of Elm concepts very easy to get started with, especially if you are familiar with Redux.

Still, things like decoders are quite new to me and I recently spent some time reviewing the docs and demystifying decoders.

There are a lot of examples of how to decode JSON objects into Elm alias types. Let me start with yet another one and then enhance it to use union types.

Decoding into alias types

I’m going to decode the following piece of JSON from api.themoviedb.org into a Movie:

{
  "homepage": "http://www.thegodfather.com/",
  "id": 238,
  "imdb_id": "tt0068646",
  "original_language": "en",
  "original_title": "The Godfather",
  "overview": "Spanning the years 1945 to 1955, a chronicle of the fictional Italian-American Corleone crime family...",
  "popularity": 64.346383,
  "release_date": "1972-03-14",
  "original_language": "en",
  "title": "The Godfather"
}

Let’s take a look at Movie alias type:

type alias Movie =
    { title : String
    , description : String
    , year : String
    , language : String
    }

There are four simple string fields and that’s it, so it should be fairly easy to decode. Let’s pick up an appropriate mapping function map4 and write a decoder:

decodeMovie : Decoder Movie
decodeMovie =
    Json.Decode.map4 Movie
        (field "title" string)
        (field "overview" string)
        (field "release_date" string)
        (field "original_language" string)

map4 takes a function and runs four decoders to pass as params to that function. In our case map4 will call Movie counstructor and pass four decoded strings in the order which Movie counstructor expects. That looks pretty good so far exept the year field. I’d rather use integer for that. Let’s decode a string of format YYYY-MM-DD from our JSON into an integer field instead:

type alias Movie =
    { title : String
    , description : String
    , year : Int
    , language : String
    }

Below is an example solution for this task:

decodeMovie : Decoder Movie
decodeMovie =
    Json.Decode.map4 Movie
        (field "title" string)
        (field "overview" string)
        (field "release_date" string |> andThen decodeYear)
        (field "original_language" string)

-- Takes a string in YYYY-MM-DD format and tries to decode YYYY into integer.
decodeYear : String -> Decoder Int
decodeYear releaseDate =
    let
        -- Get first 4 characters from the left side of a string
        -- add pass them into toInt function which will return a Result.
        result = String.left 4 releaseDate |> String.toInt
    in
        case result of
        Ok year ->
            succeed year
        Err error ->
            fail error

andThen in string |> andThen decodeYear combines two decoders into one: first, decode JSON into a string and then call another decoder for that string.

You can also delegate Result handling from decodeYear function to fromResult helper from Json.Extra library. You can read more about it here.

decodeMovie : Decoder Movie
decodeMovie =
    Json.Decode.map4 Movie
        (field "title" string)
        (field "overview" string)
        (field "release_date" string |> andThen (decodeYear >> JsonExtra.fromResult))
        (field "original_language" string)


-- Takes a string in YYYY-MM-DD format and tries to parse YYYY into integer.
decodeYear : String -> Result String Int
decodeYear releaseDate =
    -- Get first 4 characters from the left side of a string
    -- add pass them into toInt function which will return a Result.
    String.left 4 releaseDate |> String.toInt

Cool! Time to play with union types.

Decoding into union types

Let’s introduce a new union type for the language field. That field will differentiate English movies from others and also store language codes and original titles of foreign films so we can display them in a specific way if we want.

type alias Movie =
    { title : String
    , description : String
    , year : Int
    , language : Language
    }


-- Language can be either English or Other.
-- Other encapsulates language code and original title values.
type Language
    = English
    | Other Langcode OriginalTitle

-- Langcode and OriginalTitle are just strings.
type alias Langcode = String
type alias OriginalTitle = String

First, I’ll create a function which takes a language code and an original title and returns a new Language:

initLanguage : Langcode -> OriginalTitle -> Language
initLanguage langcode title =
    if langcode == "en" then
        English
    else
        Other langcode title

There is nothing to do with decoders yet. We’ve just prepared a universal “constructor” to initiate Language from two passed params.

Those two params should be decoded into strings first and then passed to initLanguage. Sounds like map2:

decodeLanguage : Decoder Language
decodeLanguage =
    Json.Decode.map2 initLanguage
        (field "original_language" string)
        (field "original_title" string)

Finally, let’s call this custom decoder from our parent decoder:

decodeMovie =
    Json.Decode.map4 Movie
        (field "title" string)
        (field "overview" string)
        (field "release_date" string |> andThen (decodeYear >> JsonExtra.fromResult))
        (decodeLanguage)

Instead of extracting data into a field directly in map4 function I passed a custom decoder which will process multiple fields by calling map2 and then return Decoder Language which is what map4 expects in our case.

Full code example is available here: https://ellie-app.com/nQWbXjrTBa1/2

Please contact me in Twitter if you’ve got any comment on that. So far thanks for reading and happy decoding!

Building web in 2026

My tech year in review (2025)

Table Of Contents

Conferences

Blogging

Reading

Domain-Driven Design

DDD Obstacle 1: The name is overloaded

DDD Obstacle 2: Domain learning is a side quest

DDD Obstacle 3: It’s not interesting

What’s next

A story of one regexp

Not a database problem

The problem

18 min vs 7ms

A better regexp

The fix

Footnotes

React Alicante 2025

Table Of Contents

Sessions - Day 1

Building for You by Kadi Kraman

Developing Waku and Exploring Client State with React Server Components by Daishi Kato

Building Interactive Async UI with React 19 and Ariakit by Aurora Scharff

The 2025 State of React Testing by Daniel Afonso

Compilers, User Interfaces & the Rest of Us by Matheus Albuquerque

React Beyond the DOM by Erik Rasmussen

Legacy Starts Tomorrow: Surviving the Refactoring Loop by Paulina Chojnowska

Feature Flags 101: Transforming Your Development with a Simple Switch by Luis Oliveira

Building component libraries with designers, not for them by Przemek Krupiński

Local first is the new black by Miquel Company

Level up your React knowledge with vibe coding by Heather Thacker

How I used AI Workflows with Figma & Playwright MCPs to accelerate my development time by Aris Markogiannakis

Scaling a React Application from 0 to a Brazilian users by Dan Neciu

My CSS is Faster Than Your React! Writing CSS only React Search! by Evyatar Alush

Reacting to Surprises: Creating Engaging Hidden Features by Courtney Yatteau

Nearly Familiar: Can Web Developers Relate to Genealogy? by Kevin Maes

Sessions - Day 2

The State of React and the Community in 2025 by Mark Erikson

The Suspense Continues: ViewTransition and Activity by Chance Strickland

The Beachcomber’s Guide to Type-Safe Design Systems by Kathleen McMahon

Unleashing the Magic of JavaScript Generators by Mattia Manzati

The Dark Side of UI – Avoiding Common Frontend Anti-Patterns by Bree Hall

Navigating the hype driven world of AI development without going crazy by Kitze

Zen and the art of code maintenance by Beth Swingler

Fun with emails by Daniel Mocan

End-to-end testing: the hard parts by Kate Marshalkina

Deploying an app with Docker by Forbes Lindesay

Boosting React Native Performance with React Compiler: A Sneak Peek into the Future by Ilda Neta

Make development easier with your own browser extensions by Łukasz Nowak

Audio recording and playback complexity across browsers by Vinu Vijy Nair

The Missing Middle Ground: Fast & Real Testing for React Native by Łukasz Chludziński

Running WebAssembly in React Native Applications by Shivay Lamba

Practical guide to animation in React by Kateryna Porshnieva

My summary

Speaker experience

Popular topics

Videos

Bullet points from CityJS London 2025

What’s next?

React Paris 2025

Table Of Contents

Sessions - Day 1

Abracadabra: The Vanishing Network by Kent C. Dodds

Building a design system with React in 2025, what’s new? by Jean Burellier

I Can’t Believe It’s Not JavaScript by Jemima Abu

Demystifying Accessibility in React Apps by Kateryna Porshnieva

Goodbye, useState by David Khourshid

Type-Safe URL State Management in React with nuqs by François Best

React Server Components: Elevating Speed, Interactivity, and User Experience by Aurora Scharff

What we learned rebuilding the largest Nordic electronic retail website in Next.js? by Tomas Jansson

Bridging Code and Creativity: Level Up Your Game as a Frontend Engineer by Yu Ling Cheng

Sessions - Day 2

Using AI Effectively in 2025 by Tejas Kumar

Let’s build K.I.T.T. with JavaScript by Nico Martin

From Chaos to Clarity: Mathematical Foundations for Maintainable React Applications by Héla Ben Khalfallah

Work Smarter, not Harder with Chrome DevTools by Dominika Zając

A Tale of Two Components: Mastering A/B Testing in React by Violina Popova

At the top of the pyramid: Playwright testing at scale by Kate Marshalkina

React Query API Design - Lessons Learned by Dominik Dorfmeister