In this article, I write about how to eliminate your own debt and stop producing more. This method is mainly inspired from my experience with top software engineering teams and lean manufacturing practices. You will benefit most from this article if you often find yourself struggling with too many things you’d like to fix and not enough time.
In product development, product debt typically refers to anything that either ruins the user experience or the internal productivity, and is caused by how the product is designed. …
Did you map out all the concepts, objects, structures, their properties, action they can perform or receive, and the relationships them? Have you share this modeling with your engineers? Does your design reflect the information architecture?
Did you seek how the design will impact the existing product? List the key user journeys impacted by the problem.
Did you fill your design with data from the real world? See if the data exists, and what kind of values it actually takes. Make sure the design works with 0 data or a lot of it.
All possible error cases must be handled explicitly. What happens if the user makes a mistake? …
Talking to users is one of the highest-leverage activities an organisation can invest in, but is also difficult to get right.
This is a one-stop-shop introduction to the fundamental principles behind good user research.
We often assume, without realising it, that everyone thinks like we think and likes what we like. Generalising based on our own experience is actually a cognitive bias called the availability bias.
Designers and business leaders must fight this bias by interacting as much as possible with users.
But there is a catch. Talking to users does not automatically yield useful insights, and very often can lead in the wrong direction. Users don’t purposely lie to us, but things people say are different from things people actually do. …
“I feel great ! I have a fantastic team working with me now. […] It’s all because I have a team of A players.”
This is my summary of Who: The A method for recruiting by Geoff Smart and Randy Street.
The scorecard is what you seek: the mission, the outcome and critical competencies.
The mission: An executive summary of the job purpose. = why you need to hire for this role. Example: “Double revenue over 3 years by signing large contracts with industrial customers. …
Domain-Driven Design is an approach to software development based on making your software deeply reflect a real-world system or process.
“Domain” in Domain-Driven Design officially refers to a “sphere of knowledge and activity around which the application logic revolves”. In other words, the “Domain” is what is commonly referred to as “business logic” in the software world.
In Domain-Driven Design, business logic is considered to be the heart of the software.
You’ll find in this article an introduction to Domain-Driven Design that mostly follows what is explained in Eric Evans’ book. …
At Inato, all our web apps are contained in one monorepo (front-end apps, APIs, …). We use yarn workspaces to manage all of these packages.
To host and run our apps, we use Heroku.
The standard Heroku setup only works for the 1-app-1-repo use case.
So, here is a quick guide on how to host and run multiple apps from multiple yarn workspaces contained in a single Git repository on Heroku.
Disclaimer: this guide assumes a basic knowledge of Heroku (See Getting Started).
Let’s say you have a single Git repository containing multiple applications in yarn workspaces like so:
│ ├── web-client
│ │ └── package.json
│ └── api
│ └── package.json
└── heroku.build …