19 Mar 2025 #career
Many things have changed over the past 10+ years in my career—technologies, mindsets, and even what I value most from my career.
I switched from Java to C#. I switched from JavaScript to Xamarin to ASP.NET to ASP.NET Core. From being the “new guy” in my first job to sitting in meetings with the CEO in one of my last jobs. It was a small company, maybe not that impressive.
Apart from those, here are 9 subjects I’ve changed my mind about:
1. Databases
I used to hate working with databases.
I hated them so much that I traded tasks with a coworker at a past job. He did my database tasks in exchange for his API-related tasks.
Avoiding learning about databases made me take down a server. I wrote a query with a function around a column in a WHERE clause. Ooops! Don’t do that!
Everything changed when I decided to learn about databases from scratch, with a beginner’s mindset. My googling took me to Brent Ozar and his courses.
Databases and SQL Server aren’t my kryptonite anymore.
2. Clean Code
I read Clean Code back in ~2013.
After that, I became a Clean Code police officer. I looked for Clean Code infractions everywhere around me. I was following and preaching the book.
Eventually, I learned that not all code is created equal and worth the same. Everything is a tradeoff. And we shouldn’t blindly follow best practices.
3. Certifications
“Azure Blah Blah Blah Associate” or “Google Blah Blah Blah Developer.” That sounds impressive.
When I started coding, I wanted to pile up all those certifications. Until I learned these certifications are often a marketing strategy from the certifying company. Every once in a while, they change the certification tracks and you have to start again. And of course, pay again.
Instead of certifications to prove my “knowledge,” I opted for just-in-time learning in the context of real projects.
And if you’re chasing certifications to make your CV look good, if your CV is in a pile (physically or virtually), you already lost.
4. Optimizing everything
I went from finding small improvements on a random line of code to finding the biggest improvement I could gain with minimal effort, after gathering the right metrics, of course. That’s one of the lessons I learned from Brent Ozar. See #1 again.
5. Climbing the corporate ladder
I used to believe I could climb all the way up to the top of the corporate world.
I was wrong! Anyone can add new steps to that virtual ladder. Anyone can change the entire ladder and you’ll have to start climbing all over again. At any point, someone can say “you’re not ready yet. Keep working hard. Next year.”
I’ve seen only one successful climb in over 10 years. She joined as an intern and yeeeears later, she became VP of something. It was at my first job. When I joined, she was already VP. Somebody told me the legend.
Instead of climbing somebody else’s ladder, I decided to build my own and define my own success metrics.
6. Working hard
“You only do your job and clock out on time,” he said.
I was on a 1-on-1 with an ex-boss. I don’t remember if he brought up the names of coworkers who worked harder than me. Maybe he implied that in his feedback.
Funny thing is months later, when the Hunger Games of layoffs began, all those who worked harder were the ones leaving first.
Apart from working hard, there are other ways to stand out, of course while being in the right place. Do a good job and clock out on time.
7. Being passionate
I hate seeing “passionate” anywhere online. On job listings, CVs, and personal blogs.
What does passionate even mean? Working extra hours, arguing about code style on code reviews, or contributing to open source? I’m not sure anymore.
For me? All that passion faded away. I learned to diversify my sources of joy and stopped trying to only find fulfillment from a job.
I’m not passionate anymore.
8. Being a full-stack developer
I started writing WebForm apps, then web apps with Bootstrap and Knockout.js, then mobile apps with Xamarin.
Until I wrote my first REST API with ASP.NET Web API. I didn’t like the “pace” of the front-end ecosystem. Too many frameworks and “something.js” libraries. And too many issues about colors and alignment. It wasn’t my type of thing.
I stopped trying to become a “full-stack” developer. Often, that’s an excuse to hire fewer people and overwork others and pay low salaries. Sorry, but not sorry.
Mmmm…Well, now that AI is “taking” our jobs, maybe we all have to become full-stack developers. And maybe I’ll change my mind about this and write anoter post.
9. Being the best coder
I don’t want to be the best coder on a team anymore.
I believed cracking symbols on a page was the way to go. I’ve learned that the best coders stay coding. And there’s more than symbols on a file. The hardest part of software engineering isn’t the code, but “people and interactions.” And that’s where the real growth happens.
18 Mar 2025 #career
What exactly does a C# backend software engineer do?
These days, I found this question on Reddit about the type of tasks we C# developers do:
“Do you find them exciting or just routine? Do they help you grow as a developer? Or is it mostly about finishing tasks quickly, making small adjustments, and moving on? Curious to hear your thoughts!”
It’s 8:45. Time for the daily meeting.
You join the meeting. “Good morning.”
Then you look through the window, scroll on Hacker News, and check your phone while you wait for your name.
“Yesterday, I worked on the task to yada, yada. No blockers.” Yes, another meeting that could be an update on Teams or Slack or an email.
It’s 9:15. Time for a coffee.
You pick your next ticket.
Another pair of REST endpoints to power a screen on the web application. You come up with request and response objects. And you contact the front-end developer to share those two objects, so nobody is blocked while the endpoints are ready.
You come up with validations, entities, and value objects to populate your core domain. Yes, you’re kind of doing DDD. Write some tests. Fire up your Postman and see if everything works.
That was the writing part.
Now, the reading part. The web application uses a grid with dynamic filters and ordering. It seems like a task for dynamic SQL. But you’re too lazy to write SQL queries by hand. It’s 2025 and the world has ORMs. Life is too short to write SQL queries by hand.
You need to pass a list of IDs to a query. You could use a string and send the IDs separated by commas. Passing a table type is the solution. But…Surprise, surprise, your ORM doesn’t seem to support tables as parameters.
Noon. It’s lunchtime.
You step away from the screen to grab some food and give your brain a rest. At least, that’s the plan. But you can’t stop thinking about your task. “Why it isn’t working? What am I missing?”
When you’re back from lunch, you pull down the source code of your ORM and go down a rabbit hole. There’s no way you’re writing SQL queries by hand. Not today. “Here it builds the SQL query from the mapping object…“ Great. Progress. But still nothing. You keep going down the rabbit hole, determined to find the answer.
One method leads to another. One break point here and there. Until finally, you find it. “Here it is. This ORM uses a converter to populate the underlying DbCommand object. I could use that.” The solution is kind of hacky, but it works.
You write a converter and a simple test to prove you’re right. Then you port that converter to your Database project and add some docstring comments to document your hacky solution.
It’s almost 5:00 PM.
You’re tired from that debugging session.
But it was rewarding. You proved that sometimes being lazy means being efficient. By the end of your debugging session, you know a bit more about the internals of your obscure ORM. You have a trick you’ll use in future tasks. And you have an idea for a good blog post.
It’s time to create a pull request.
You slap a title, a description, and some good comments here and there to explain what you found. You change your ticket status on JIRA and ping the default reviewer for this project.
Time to unplug from work.
It’s 8:45 the next day. Another daily meeting.
This time, you don’t scroll Hacker News, but go directly to your PR.
As usual, one reviewer is suggesting renaming a variable. And you forgot to cover one or two lines. Yes, the official guideline is 100% coverage. Arrggg!
Some of your coworkers find out the trick with the converter. For the first time in a while, you get a compliment in one of your PRs. Yay!
That’s just one ticket. There are more. Hopefully QA doesn’t find any issues in the search logic. Fingers crossed, all the issues are “move this label,” “this textbox isn’t green enough… .” Nothing you have to care about being a backend developer. Your UI is Postman, and everything is working fine from there.
Everything because you didn’t want to write SQL queries by hand. Lazy? Maybe. Clever? Absolutely.
That’s why you chose backend development: the satisfaction of solving tricky problems. And that’s just another day in the life of a random backend engineer. Based on true events, because backend development could be boring, and yes, sometimes, a little wild.
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.