17 Mar 2025 #misc
Volume always wins.
When we start a new creative project (writing, coding, or painting), we aim to create something “perfect” on our first attempts. And we wait for perfection before we share our work with the world.
The truth is, those first attempts will be crap. Our first posts, programs, and paintings will be crap. Well, 90% of everything is crap.
But the more we practice, the better we become, and the closer to “perfect” we get.
That’s a lesson I learned when binge-reading Herbert Lui’s blog the other day. I read about the pottery class experiment. One half of a pottery class was graded on quality and the other half on quantity. At the end of the course, the half who went for quantity did better and got better grades. They focused on experimenting, learning, and improving along the way.
The more tries we do:
- We experiment more
- We become more confident
- We collect more data points
- We build a larger body of work
- We have more chances to succeed
- We understand our audience better
- We develop less aversion to failure
- We have more material to repurpose
- We gather more opportunities for feedback
- We create more points of contact with our audience
For your next creative project, go for volume: write 100 blog posts, write 100 short programs, or do 100 paintings. And don’t be afraid of showing your work. The more you create, the closer you get to “perfect.” Volume always wins.
16 Mar 2025 #misc
What’s the first thing that comes to mind when you think of Domain-Driven Design (DDD)? Entities and value objects?
These days, I came across this question on Reddit about DDD:
I’ve been struggling lately to understand the idea and the reason behind Domain Driven Design. However, I have come up with the understanding that DDD is just the implementation of the core domain in Rich-Domain models, creating a ubiquitous language to make technical development easier, bounded contexts and design patterns like aggregates, value objects, strongly typed IDs and so on.
It’s easy to confuse DDD with using entities and value objects. But that’s not the point.
At a past job, I had the chance to use DDD in small projects. Every two months or so, we started short projects to improve a hotel management software.
In most of those projects we used, and abused, DDD.
Here are two examples where we abused DDD:
#1. We used it on a CRUD application to text guests upon arrival. The project got behind schedule, in part due to forcing DDD on a project with a tight schedule. From that project, I learned some good lessons.
#2. In another project, slightly more complex, but still not business logic heavy, we followed DDD by the book. Almost literally we followed this book. We ended up with too many layers and mappings between layers just to read data from the database. Arrggg!
If we judge DDD by using entities, value objects, and aggregate roots, in these two examples, we did DDD. But we overengineered a solution that we could have simply done with an n-tier architecture or commands and queries.
DDD isn’t about aggregate roots, entities, and value objects.
DDD is about collaboration and understanding.
It’s about collaboration between stakeholders and developers to create a shared understanding of the business rules. And it’s about expressing that understanding in a shared language. From product people in user stories to developers, all the way through the code, and up to table and column names.
Aggregate roots, entities, and value objects are mechanisms to encapsulate that understanding inside boundaries in the code.
15 Mar 2025 #misc
“[Users] don’t care about your code—they care about results.”
That’s a controversial statement I found on this dev.to post. It got some virtual stones in the comments from “Clean Code” police officers. I used to be one too. I’ve changed my mind about it.
We don’t write code for the sake of writing code.
We write code to accomplish something for others:
Connecting them with loved ones in the case of Facebook, finding a romantic partner on Tinder, or getting a good and cheap room on Airbnb. Even for boring enterprise software, it’s about happier clients and more sales.
That’s what matters most to the users of Facebook, Tinder, Airbnb, and even boring enterprise software.
The other day, the VP of a software company I was contracting with taught me a lesson about Clean Code and other best practices:
“Clean Code is for us when we have to fix problems and deal with our own mess…users don’t care about that.”
It was a lesson I won’t forget, especially coming from a VP of a software company who had been a coder too.
We write code for humans. For two audiences: our future selves and end users.
Both audiences don’t necessarily intersect. Both audiences don’t care about the same things. For us and our future selves, it’s about maintaining code quality to add new features and solve bugs. For end users, connecting with loved ones, finding a romantic partner, getting a cheap room, and keeping clients happy and sales high. They care about what our code could do for them, not about the code by itself. Quality is there to support that mission.
14 Mar 2025 #career
I’ve stayed too long at stagnant jobs, and I regret it.
Staying too long at jobs cost me years and thousands of dollars. I left lots of money on the table. It made some of my skills get rusty.
But after connecting the dots, there were signs I failed to notice:
1. You’re not learning anything new
This is the #1 sign to look for. If your daily job becomes boring, that’s a sign. Or stay but diversify your source of joy.
2. There’s no room for growth
“You can build any role you want,” I was told.
That happened at a past job. I rejected the idea of being a team leader. I didn’t like how the role was designed at that place. It was a “wear all hats for the same pay” role.
And when I brought my ideas to the table, they got rejected with a “somebody else is already kind of doing that.” Staff Engineer? Software Architect? Right Hand? All of them.
It was a red flag I failed to notice.
3. It makes you sick
If your job makes you sick, physically or mentally, what other sign do you need? It’s time to take action. It’s time to run. Run, Forrest, run!
You can always get a new job, but not a new body.
4. You’re learning coping mechanisms
“OK, I just sent a message without a period at the end and without capitalizing the first letter,” my friend told me.
He was working from home and I stopped by for a coffee. In the middle of our conversation, he got a message from work and replied from his phone. There’s nothing wrong with that.
But to make sure his boss didn’t notice it, he didn’t add a period at the end of his message. Oh boy! I had just left that job no more than one year before that.
5. There’s no more money
The last time I heard “There’s no more money this year” when asking for a raise, the Hunger Games of layoffs started, until only a few ones were left standing.
I tried to convince myself I could stretch that job for another year or two. Wrooong! Eventually, layoffs knocked at my door too.
6. You have a bad boss
Often it’s hard to leave work stuff at work when going back home. A bad boss (whatever that means to you) will make you feel bad along with the people around you.
7. There’s no willingness to change
If after raising flags with your boss, you only hear “that’s fine. It used to be worse” or anything along those lines, that’s where change dies. Don’t waste more time bringing ideas.
Either you accept things the way they are or disagree with your feet.
8. It’s more important to find who to blame
If something goes wrong, it means there’s a flaw in a standard procedure or a process that let it happen. Finding who to blame only create a toxic work environment. Don’t waste time blaming. Fix the process.
From Brent Ozar, the SQL Server master, I learned that by the time we ask ourselves if we should leave, it’s too late. The best time to look for a job isn’t when you’re desperate. It’s when you don’t need one. Start updating your CV, reflect on what you truly want, and take control of your career. And don’t forget to read the fine print in job descriptions.
13 Mar 2025 #writing
If we look at the world as creators, there’s content everywhere.
I put on my creator’s glasses and watched Six Triple Eight, a Netflix movie about the only battalion of American Black women in Europe during WWII.
Here are the storytelling devices I noticed:
#1. The story starts somewhere in the middle, not at the beginning of the events. It starts with a scene of a plane being shot down in the middle of WWII. Then, it takes us back to the days before that incident and builds from there.
#2. This battalion ran the mail operation for the troops in the frontlines. So we follow a letter covered with blood from the first scene all the way throughout the movie.
#3. Apart from delivering letters, it tells us other stories:
- The story of Major Adams, the officer in charge of the battalion. Based on a real character.
- The discrimination Black women faced inside the Army.
- Lena, our protagonist, falling in love with the pilot from the first scene.
#4. It follows the problem/tension/climax/resolution technique:
- It starts with the battalion facing an impossible mission (delivering the mail)
- Being Black women in the Army, nobody believed in them.
- They completed the mission ahead of time.
- They earned the respect of the people who used to bully them.
#5. The entire story is told from the point of view of a single woman, Lena, our protagonist. Based on a real character too.
#6. Like any other movie inspired by real events, it wraps up with the real footage of the real Six Triple Eight battalion entering in Europe.
#7. The movie starts with a love story and ends with another love story. It ends the same way it started.