What’s the minimum you should know about digital product design and why should you care?
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.
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.
Using the Testcontainers library is one of the ways to test your app’s data layer (in JVM languages). Let’s see a basic example.
Before starting, let’s clear out two assumptions:
- You want to test a data layer of a JVM application (I’ll use Kotlin and Gradle).
- You have Docker installed in your local environment. Ideally, you have it also in the deployment environment, to run the same exact tests that run locally.
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…
Technology can be put at our service as a means to make us feel psychologically safer in the team and the company.
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…
Sharing code is overrated and it’s abused as the solution to code repetition. What’s the alternative? The answer is related to cohesion, code hotspots, and the law of proximity.
Cohesion
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.
I feel a bit lost when I look at a project and all I see is technology. We use it to enable business goals, but I see it as a detail. This looks like a paradox so bear with me.
📝 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…
Feeling in a safe environment is a prerequisite for a happy and productive team. I’ll mention a software team as an example but it could be applied to other teams.
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.
Pathological organizations look for a “throat to choke”: Investigations aim to find the person…
In most cases, if you rely on comments to explain code, you’re doing it wrong. I’ll show you some ways to achieve self-documenting code. No, it’s not utopic.
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…
CODEX
Clean and hexagonal architectures can be complex topics. Let’s break them down using an iterative learning model.
Why another article about domain-centric architectures? In the beginning, I struggled to understand them, so I decided to write my own explanation by building progressively refined models — that way resembling the way we learn.
CODEX
I built a utility app to control Yeelight/Xiaomi LED Lights. It can be accessed from the Windows system tray.
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…
CODEX
Dependency Injection (DI) is the most common way to decoupling and separation of concerns, promoting testability and readability. Let’s analyze some related design patterns that I’ve spotted in some projects.
📝 I used Kotlin in the code samples, but all the patterns apply regardless of the language or runtime.
You don’t need a DI framework
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
DI is a design concern and the way to achieve it is to learn its concepts. If…
Luís Soares
full-stack developer
