My main goal is to call out the attention to the product designer’s role. The main target readers are developers and product managers. Let’s start with why.
Isn’t product design for designers? Product design is all about solving users’ problems and that’s hopefully a team concern. Nobody is telling you to do their jobs (don’t be the one looking over the designer's shoulder suggesting colors), but a healthy team has no set-in-stone turfs. Intra-role collaboration is a win-win undertaking — throughout the cross-pollination of different perspectives, everyone learns and the product gets better.
Before starting, let’s clear out two assumptions:
There are multiple techniques available to test your app’s data layer that I covered before:
Let’s focus on testing the data layer with a real database. To achieve it, we could launch the database outside of the testing environment, but that requires external setup and deployment, whether by manually creating a…
This is the continuation of my previous article:
Since we’re talking about software development, technology is surely fundamental in fear and risk management. Confidence in the system equals increases psychological safety as you feel safer to make mistakes. In other words, we put technology at our service to reduce or eliminate the impact of mistakes. The book Accelerate explores this connection further.
Jakob Nielsen proposed the 10 Usability Heuristics for User Interface Design in 1994 (later refined), which are a landmark in usability. Some of them serve as good mnemonics when adapted to the use of technology in a software…
Cohesion refers to the degree to which the elements inside a module (e.g. a class) belong together. High cohesion means all the code in a module is related; low cohesion means that the module contains unrelated pieces of code.
Modules with low cohesion can lead to code hotspots — they’re like black holes of code and attract every feature. They harm modularity because they bind multiple features together. They make your codebase ill. Since there are multiple reasons to change hotspots, they grow indefinitely and are often a source of merge conflicts.
📝 Since we’re talking about software, everything is technology. To avoid confusion, when I say technology I mean the things that are outside the scope of your business domain, like databases, queuing systems, I/O, interacting with APIs, frameworks, etc.
Technology is pervasive and can hinder your codebase. However, many of us are technology evangelists so it’s very easy to fall into that trap on a new project. Fast forward a few months and all you see are HTTP filters, monitors, JSON, command handlers, SQL, etc. Now look at your code, take a step back and think about how you can…
Maslow’s hierarchy of needs is a structured pyramid of human needs.
Notice that personal security lies within the safety needs, just above the physiological needs. If we don’t satisfy those lower-level needs, how can we unleash the ones above, where creativity and innovation can happen? If you’re struggling to survive, how can you think about politics or culture? Studies show that psychological safety allows for moderate risk-taking, speaking your mind, creativity, and sticking your neck out without fear of having it cut off.
This is not a case against code comments. This is a case in favor of self-documenting code — not having code comments is a consequence of it.
In my case, the “code-needs-comments” myth comes from the university. The rule to make your code self-explanatory rather than using comments existed in all companies I was at and it worked out fine. So what are the problems with code comments?
Subjectivity. Comments are subject to the reader’s interpretation. Natural languages are ambiguous but code doesn’t lie.
Code never lies; comments sometimes do. Ron Jeffries
They allow bad code to exist. Comments are…
Why another article about domain-centric architectures? I struggled in the beginning to understand the clean architecture, so I decided to write my own explanation in a way that resembles how we learn: by building progressively refined iterative models.
I’m a fan of Xiaomi/Yeelight LEDs, especially because they can be used as smart home devices. You can control these lights with Xiaomi Home, Google Home, or Yeelights apps, but I wanted something that I could use while I was at my Windows PC so I didn’t have to look for the smartphone, unlock it, and look for the app and open it.
I imagined something in the Windows tray, which, with minimum clicks, allowed me to control the LEDs. I searched the web for a while but there was nothing. I found Yeelight Control (not working), Yeelight UWP, Yeelight…
📝 I used Kotlin in the code samples, but all the patterns apply regardless of the language or runtime.
I use frameworks and libraries when it pays off. In what concerns DI, I recommend doing it manually. Check how clear and effective vanilla DI is:
val coffeeProvider = CoffeeProvider(System.getenv("PROVIDER_URL"))
val coffeeNotifier = CoffeeNotifier()val coffeeMaker = CoffeeMaker(coffeeProvider, coffeeNotifier)
“Dependency Injection” is a 25-dollar term for a 5-cent concept. [… it] means giving an object its instance variables. Really. That’s it. Dependency Injection Demystified