Maximizing the amount of work not done is about eliminating waste, the first lean principle. This doesn’t mean being lazy or neglecting tasks; it only means doing the minimum necessary, regarding setting goals and the way to get there. A good place to start is acknowledging that everything that doesn’t put value in users or business hands is overhead (e.g. Scrum ceremonies, Git message rules, spreadsheets to organize everything). It doesn’t mean it’s bad; it only means that it’s support work. It may need to be done, but you need to question it and find ways to reduce it.
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.
In fact, Apple didn’t introduce the iPod until twenty two months after Creative’s entry into the market. […] The problem was, they advertised their product as a “5GB mp3 player.” It is exactly the same message as Apple’s “1,000 songs in your pocket.” The difference is Creative told us WHAT their product was and Apple told us WHY we needed it. Start With Why
📝 Since we’re talking about software, everything is technology. …
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? 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.
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…