aonemd

2025-12-25 09:32

Fri, 26 Dec 2025 09:32:00 +0100

2025-08-30 17:36

Sat, 30 Aug 2025 17:36:00 +0200

I don’t care how the code got in your IDE.

I want you to care.

I want people to care about quality, I want them to care about consistency, I want them to care about the long-term effects of their work. LLMs are engineering marvels, and I have the utmost respect for the people who’ve created them. But we still need to build software, not productionize prototypes.

2025-07-02 20:05

Wed, 02 Jul 2025 20:05:00 +0200

Beware the Complexity Merchants

2025-06-20 21:20

Fri, 20 Jun 2025 21:20:00 +0200

What is Modern Software Engineering?

Why Software Engineers Need Strong Opinions

Fri, 20 Jun 2025 00:00:00 +0000

This is my introspection on why voicing opinions on software engineering is difficult, why it’s important for engineers to have their own voice, and how to voice your opinions without it being too painful.

Why is it hard to talk about software engineering?

Compared to other branches of engineering, software engineering is a fairly recent field. Today, we have software engineers who are probably older than software engineering itself. Software is also a field that’s constantly evolving and changing. As a result, software engineering is not a fully established discipline. That also makes it difficult for everyone to agree on standards, rules, or regulations.

Of course, some applications of software engineering — medical device systems and avionics for example — require more rigor and stricter rules than others. However, that doesn’t change the fact that most of software engineering work out there is just like the wild west.

Without clear standards and regulations, engineers are left to figure things out on their own often with conflicting views and practices.

I experienced this ambiguity firsthand early in my career. I remember starting out as an apprentice software engineer, and as any enthusiastic youth who read Clean Code, I used to hold more black-and-white opinions when a lot of my more experienced colleagues didn’t. However, as I matured in the industry, I started to let go of my previous convictions and wear the “it depends” hat a lot more. With more experience, I learned about the trade-offs of my and other engineers’ decisions, and held on to fewer opinions. I became less certain and more cautious in forming opinions.

But letting go of certainty came with another challenge. I often found myself stuck more between decisions and the myriad of options available to engineers everyday.

That indecision taught me that while it’s important to keep the trade-offs in mind, having clear convictions can be as essential when navigating the chaos of modern software engineering. I had traded black-and-white thinking for endless shades of gray — and sometimes, that made it harder to move forward!

Why Strong Opinions Matter?

In today’s world, engineers are faced with a lot of options, trade-offs, and ways of working to consider before making a decision. While this abundance might seem like a blessing, it often becomes noise — leading to decision fatigue even before the actual problem-solving begins.

This is where convictions play a crucial role: clear, well-informed opinions help eliminate this decision fatigue and analysis paralysis across the software development life cycle. In an environment where everything “depends”, strong opinions function as the compass that guides our engineering decisions.

With this clarity, engineers can contribute to setting standards, uphold consistency, and most importantly, focus on the team’s core goals. Although strong opinions are sometimes seen as dogmatic, in my experience, they often come from a pragmatic perspective.

As engineers become more senior, they take on the responsibility of shielding the team from wasted effort and misdirected energy. Indecision and split opinions, open the door to internal friction and endless bike-shedding . In moments of disagreement or indecision, senior engineers must help bring the team back from its drift and put an end to endless debates, ultimately driving the team towards efficiency and alignment.

The Etiquette of Strong Opinions

Voicing your opinions, just like brushing your teeth before visiting the dentist, comes with its own set of unspoken rules.

In my experience working with engineers from different backgrounds and with varying degrees of strong opinions, the problem usually isn’t strong opinions but rather how these opinions are expressed.

First and foremost, opinions should be based on experience and maturity — not on dogma or cargo-cult thinking. Too many opinions today are pure hype and click-baiting (or rage-baiting as I’ve recently come to know it) and not from hands-on experience. Twitter, YouTube, and LinkedIn are all filled with armchair engineers, self-proclaimed tech gurus, offering advice they’ve never had to apply themselves whereas the real insight usually comes from engineers who have been quietly solving hard problems for years.

Second, advocating for your opinions is as important as the opinion itself. It might differ depending on the opinion but I’ve seen and practiced one of or all of these at times: face-to-face discussions, quick video calls, writing RFCs (Request for Comments) documents, creating a POC and holding a demo for the team.

Conflicts are bound to happen. There’s really no going around it. One great piece of advice I once received from one of my former managers about team dynamic and conflict resolution: to learn to pick your battles. Not every situation needs to become an argument and certainly, not every opinion needs to be said. And know when to hold your ground and when to let go.

Finally, it’s important to stay humble and open to different opinions or have Strong opinions, gently held.

If you’re starting out: be patient and focus on observing. Absorb as much as you can and evaluate as you gain experience. Opinions take time to form and establish.

If you are a senior engineer: solidify your convictions. Over time, we tend to develop patterns and follow them all the way. Refresh your convictions every now and then, question them, revisit your tools and methods. You think VSCode is the best? Learn something else, then use Vim anyway . Love JavaScript? Great but maybe you haven’t seen Ruby…

Conclusion

From my own (still short) journey, I’ve learned that firm convictions is how we navigate the uncertainty and complexity of software development. Specially today in the age of artificial uncertainty, it’s more important than ever for engineers to be particular about our craft, to distinguish the wheat from the chaff, with firm convictions that are shaped by experience, not hype.

Write With Conviction

Mon, 09 Jun 2025 00:00:00 +0000

Recently, I have picked up writing again after a long break. And Although I’m out of shape, I’ve been pushing myself to write regularly — and hopefully publish — on my blog. It’s been almost 10 years since I first started, and despite posting sparsely, I’ve kept coming back!

As I revisited my older posts and my many, many drafts (and titles, I like titles) that never saw the light, I noticed a pattern in my writing: it’s significantly harder for me to write opinionated pieces.

Even for the posts I did publish, there are a few I decided to hide or delete entirely — often because they leaned heavily on personal takes. Ironically, I even wrote an article about how hard writing is… instead of just writing what I really wanted to say.

Looking back, I can now see why. Since I began writing, I have made a conscious effort to sound objective and put a lot of focus (more than I should’ve) to strip my opinions away as much possible — a form of self-censorship . I’d often beat around the bush before I hesitantly get to the point I want to make. That made writing painful and dreadful to me.

In contrast, the easiest posts to write were the purely technical ones. With technical writing, the rules are clearer and the writing just flows easier. You are either correct or you’re not. If I say “The C language is compiled,” there’s not much to debate. Or if someone says “a monoid is a monad in the category of endofunctors,” yeah — I won’t argue with that. There’s a higher level of certainty in technical truths.

However, with opinionated writing, it’s a different beast! You could be flat out wrong from the get-go. You need to anticipate counterarguments and refute them. You risk being misunderstood. You risk coming across as confidently and arrogantly wrong. The stakes are higher.

And I think now I realize where the struggle comes from: doubt. Over the years, as I’ve gained more experience and matured as an engineer, I’ve also become more aware of how much out there that I don’t know. Knowing there are so many unknowns is humbling but it also brings with it doubt and hesitation, and sometimes that spills into my writing.

I’ve come to find that the antidote to hesitation is conviction. Writing with conviction matters. No one wants to read a hesitant writer just like no one wants to listen to a hesitant speaker. Conviction, owning your perspective, and stating it clearly give your words gravity. It doesn’t mean being arrogant or stubborn; on the contrary, it conveys honesty and courage.

So I’m trying something different this time: I’m learning to write with conviction again so no more hiding behind forced objectivity or self-censorship, just writing what I believe, as clearly as I can.

2025-05-31 11:46

Sat, 31 May 2025 11:46:00 +0200

Programming is terrible, here’s a photography crash course .

2025-05-27 13:15

Tue, 27 May 2025 13:15:00 +0200

Focus on People : Despite how many tech companies eventually end up with empty imitation and cargo-culting, the gist of the talk is valuable “Focus on People”.

2025-05-21 11:39

Wed, 21 May 2025 11:39:00 +0200

I like this analogy on AI competitive programming benchmarks from AI Has Us Between a Rock and a Hard Place :

Competitive coding benchmarks are like solving a riddle but software development is like solving a murder…

2025-05-15 20:09

Thu, 15 May 2025 20:09:00 +0200

I love this part from Minimum Viable Curiousity :

“When faced with change or an aggressive unknown, I take a deep breath, count to four, place my feet firmly on the ground, and ask, “Do I really understand what is going on here? Really?” I start with curiousity because curiousity informs action. Action creates consequence, and when consequence shows up, you start learning.”

2025-05-12 15:00

Mon, 12 May 2025 15:00:00 +0200

I’ve been in the The valley of engineering despair for the past few weeks and it’s nice to have a word for it!

2025-05-12 12:22

Mon, 12 May 2025 12:22:00 +0200

We need more calm companies .

2025-05-11 15:18

Sun, 11 May 2025 15:18:00 +0200

Cognitive load is what matters .

The Last Tech Stack You Will Ever Need

Fri, 09 May 2025 00:00:00 +0000

In life, there’s a great value in being in the middle — rather than the extremes. And in contrast to what society today deems “boring”, there’s real value in being boring and choosing boring: stable, reliable, consistent.

That principle applies just as well to software engineering, particularly when it comes to tooling, tech stacks, and system design. As engineers, many of us are naturally drawn to tinkering and experimenting. We enjoy hacking and trying new tools and approaches.

I’m certainly guilty of this. Early on, I spent so much time building the perfect development environment, the perfect Linux desktop, writing my own taskbars, configuring Vim, trying i3wm, using Suckless tools … the list goes on. But in hindsight, I haven’t spent nearly enough time using these tools to actually build meaningful things. I can confidently say I have done enough customization for the next 10 years.

Of course, there’s value in mastering and improving your tools. But that’s different from becoming obsessed with perfection instead of solving real problems!

This is specially true in the context of software engineering ¹ — as software engineers, we are hired as problem solvers, to help businesses fulfill their needs. That means our role is not to chase the latest most hyped tool or framework endorsed by tech-fluencers. It’s to provide value using technology, not to use technology for its own sake.

Every new tool or technology introduced into an organization brings with it hidden costs: learning curve, adoption friction, maintenance overhead, and added complexity in the tech stack. These costs rarely justify the marginal gains of using the “hot new thing.” Most importantly, each addition chips away at consistency — the very thing that makes systems maintainable and teams effective.

In fact, the most painful projects I’ve worked on were not necessarily the most complex. They were the ones that lacked consistency; where every piece of the project uses its own toolchain, language, or structure — what a colleague of mine calls “passion projects.”

As software engineers, working in an industry that’s at the center of internet fads and tech bubbles, what truly sets great engineers apart is how they approach their craft. They set and follow standards, choose battle-tested technologies, and prioritize consistency over what’s trendy. That attitude fosters a shared understanding which scales across your entire organization. It makes development smoother for you and your team today and also for the poor soul who inherits your code years from now.

At the heart of it all, software engineering as a craft is not about novelty but rather, it’s about reliability, consistency, and delivering value. While experimentation can sharpen skills and deepen understanding, endlessly chasing new tools or paradigms often distracts from the actual goal: solving real problems effectively and sustainably. The best engineers are not those who use the flashiest stack, but those who understand the cost of every technical choice and optimize for long-term clarity and maintainability. Choosing “boring” and proven technologies isn’t a lack of ambition — it’s often the wisest engineering decision.

I deliberately use the term “software engineering” here instead of just “coding” or “programming” since each one carries a different connotation. Programming is definitely a big part of software engineers’ job, but it’s not the whole picture. ↩︎

2025-05-08 16:54

Thu, 08 May 2025 16:54:00 +0200

No Matter What .

2025-05-08 08:16

Thu, 08 May 2025 08:16:00 +0200

We teach about the XY Problem . On the flip side, as engineers receiving questions or requests, the most fundamental habit is to ask “Why?” If not to be able to provide better help then at least out of curiosity.

2025-05-05 18:30

Mon, 05 May 2025 18:30:00 +0200

Sycophancy is the first LLM “dark pattern”

2025-05-04 16:25

Sun, 04 May 2025 16:25:00 +0200

And on that note, I find this video Internet Fatigue: Why This Place Sucks Now very relatable now.

2025-05-04 16:13

Sun, 04 May 2025 16:13:47 +0200

I resonate so much with this article On Blogging about revisiting old writings and doubts! It’s also in a way, closely tied to the current consumption focused internet.

Automated Resume Builds With Docker and Gitlab

Sun, 05 Feb 2023 00:00:00 +0000

As a certified Hackerman, I write my resume in Markdown. I also maintain an open source version of the template I use on Github .

The template is written in Markdown and I wrote a small build script that uses pandoc and wkhtmltopdf and some CSS to generate PDF and HTML versions of the markdown file.

Since we’ve already established that I’m officially a masochist, I have to mention that I use Arch btwᵀᴹ. So typically, after updating my system, and opening my text editor, it’s totally expected that I might get an error along the lines of:

lib*****.so.42: cannot open shared object file: No such file

Recently, on a rainy night, I ran my build script and got something similar to the dreaded error messages above. I spent some time searching the lovely Arch Linux [SOLVED] forums and going from one error to another. I don’t remember what the problem(s) was exactly but it was something related to a version of Python and a version of some QT5 library that I didn’t bother to solve this time.

Enter Docker

Since nowadays most problems in the world seem to be solved though some form of containerization and Kubernetes and rust, I also decided to build my resume in a Docker container.

As any good Docker user, I started with an Alpine image but then found out that wkhtmltopdf is not available in Alpine repositories anymore. So I had to use an Ubuntu based image and installed all the necessary packages that I usually install natively on my machine. I also needed to install some Microsoft 😱 proprietary package from Ubuntu repositories for the fonts I use in the CSS which gave me some headache to install in the beginning.

In the end, I run the build script inside the container to build the resume PDF then I use docker cp command to copy the file from the container to my host machine.

This is how the Dockerfile looks like:

FROM pandoc/core:latest-ubuntu

RUN apt update && \
      apt install -y software-properties-common && \
      add-apt-repository multiverse && \
      apt update && \
      echo ttf-mscorefonts-installer msttcorefonts/accepted-mscorefonts-eula select true | debconf-set-selections && \
      apt install  --reinstall  -y xvfb libfontconfig wkhtmltopdf fontconfig ttf-mscorefonts-installer && \
      fc-cache -f -v

ENV SRC /usr/src
WORKDIR $SRC
Add . $SRC

RUN pandoc --version
RUN ./build.sh build

And here’s the build script:

#!/bin/sh

SOURCE=resume.md
TARGET=resume
CSS=resume.css
OPEN_COMMAND=xdg-open # replace with `open` for macos

case "$1" in
  build)
    pandoc --pdf-engine=wkhtmltopdf -t html5 --css "$CSS" -o "$TARGET".pdf "$SOURCE"
    ;;
  build-docker)
    docker build -t resume .
    container_id=$(docker run -d resume:latest)
    docker cp $container_id:/usr/src/resume.pdf ./resume.pdf
    ;;
  build-html)
    pandoc --standalone --css "$CSS" --from markdown --to html -o "$TARGET".html "$SOURCE"
    ;;
  open)
    "$OPEN_COMMAND" "$TARGET".pdf &
    ;;
  *)
    echo "Usage: $0 {build|build-docker|build-html|open}"
    exit 2
esac

exit 0

Now, when I want to build my resume on my machine, I simple run the build command:

./build.sh build-docker

Automated Builds

Finally, I added Gitlab CI/CD to my setup to get automated builds on git push.

Since the build script expects that the docker command exists, I needed to use a Docker in Docker image, or dind as a service:

image: docker:latest
services:
  - "docker:dind"
build:
  stage: deploy
  script:
  - ./build.sh build-docker
  artifacts:
    paths:
    - resume.pdf
  only:
  - master

With this setup, I can now simply push my changes and go to Gitlab and download the latest version of of my resume through Gitlab’s UI.

You can find the full source code of the template and the setup on Github at hackerman-resume .