Monday Links: Notebooks, Learning, and KPIs

Five interesting reads from the past month.

Lab Notebooks

I like the idea of keeping “lab” notebooks, especially to record the thought process for consulting clients. I’m a big fan of plain text. But the article recommends using pen and paper.

Read full article

Git Things

Git and Version Control are one of the subjects we have to learn ourselves. I prefer short Pull Requests with only one or two commits. I name my commits with a long and descriptive title that becomes a good title on PR descriptions.

This article shows “tactics” to better use Git. I really like these two:

  1. start by writing the commit message before the actual work and then amending it. Commit Message Driven Development I guess, to follow the XDD trend
  2. splitting refactorings into two commits: changing the API and then changing the calling sites

Read full article

Teacher and student sitting on a chair
It's never too late to learn about learning...Photo by Boston Public Library on Unsplash

10 Things Software Developers Should Learn about Learning

This article contains ten findings, backed by research, about learning and software engineering. Totally worth reading if you’re into learning about learning.

These are some of my favorite lessons:

  • “Expert programmers may have low or high working memory capacity but it is the contents of their long-term memory that make them experts.”
  • “Expert developers can reason at a higher level by having memorized (usually implicitly, from experience) common patterns in program code, which frees up their cognition.”
  • “The brain needs rest to consolidate the new information that has been processed so that it can be applied to new problems.”
  • “There is a key distinction between a beginner who has never learned the details and thus lacks the memory connections, and an expert who has learned the deeper structure but searches for the forgotten fine details.”
  • “There is no reliable correspondence between problem-solving in the world of brain teasers and problem-solving in the world of programming. If you want to judge programming ability, assess programming ability.”

If you don’t want to read the whole article, jump to the Summary section at the end.

Read full article

Why Most Software Engineering KPIs are BS and What to Do About it in 2024

Does your team measure story points too? The truth is we don’t know how to measure our work. I worked with a company that measured the percentage of completed tasks. It was a killing pressure. And once we have a metric, we start to game it. On the last day of the sprint, we saw people removing tasks so as not to mess with the final percentage.

From the article: “Engineering leaders (and sometimes non-technical executives) have often made the poor choice to measure output rather than impact”. The author recommends: “separate engineering health metrics to KPIs.” This is how the team feels vs the business impact of the work done.

Read full article

27 Years Ago, Steve Jobs Said the Best Employees Focus on Content, Not Process.

This article tells Steve Jobs’s opinion on office politics and bureaucracy and how often we think “paperwork” is the real work. Process vs Output. Also, this article shares how to keep the best team members around, those who are good at identifying the output.

From the article: “Success is rarely based solely on process. Success mostly comes down to what your business accomplishes.”

Voilà! What are the KPIs of your team? Do you measure story points or percentage of completed vs planned tasks? Until next Monday Links.

In the meantime, don’t miss the previous Monday Links on NDC Copenhagen.

Happy coding!

Two Lessons I learned after a finished project

Today I want to take a moment and reflect on a finished project. Last year, I worked as an independent contractor and engaged in short projects with a client. This project was a six-month effort to support group events, like weddings, conferences, and retreats, in a property management system.

This small project taught me more about leadership and communication than programming in general. These are the two lessons I learned from this project.

Lesson 1: Have uncomfortable conversations earlier

Inside our team, we all started to notice “certain” behavior in a team member.

He delayed Pull Requests for minor things, interrupted meetings with off-topic questions, and asked for 100% detailed and distilled assignments.

Even once, he made last-minute changes, blocking other team members before a deadline. It wasn’t a massive unrequested refactoring, but it frustrated some people.

From the outside, it might have appeared he was acting to jeopardize the team’s progress.

It was time to virtually sit and talk to him. But nobody did it. And things started to get uncomfortable, eventually escalating the situation to upper management, leading to a team reorganization. There was “no chemistry with the team.”

An empathetic conversation could have clarified this situation. Maybe the “problematic” team member had good intentions, but the team misinterpreted them. Who knows?

This whole situation taught me to have uncomfortable conversations earlier.

Woman in black long sleeves holding a mug
I hope that's not an uncomfortable conversation...Photo by Priscilla Du Preez on Unsplash

Lesson 2: Once you touch it, you own it

At some point, we needed to extend an existing feature. We needed to import an Excel file with a list of guests into a group event.

“You only have to add your changes on top of this existing component. It’s already working.” I bet you have heard that, too. That was what our Product Owner told us.

The next thing we knew was that the already-working component had issues. The original team was laid off, and we couldn’t get our questions answered or count on them to fix those issues.

What was a simple coding task turned out to be a longer one.

Before starting to work on top of an “already-working” feature, I learned to test it and give a list of existing issues. Otherwise, those existing issues will appear as bugs in our changes. And people will start asking questions: “Why are you taking so much time on this? It’s a simple task.”

Lesson learned! Once you touch it, you own it!

Voilà! These are the lessons I learned from this project: have uncomfortable conversations and test already-working features. Also, this project made me think it’s better to hire a decent developer who can be mentored and coached than a “rock star” who can’t get along with the team.

For more career lessons, check five lessons from my first five years as a software engineer, three lessons I learned after a “failed” project and things I wished I knew before working as a software engineer.

Monday Links: NDC Copenhagen

These are four NDC conferences from the past Copenhagen edition.

Iron Man or Ultron: Is AI here to help us or hurt us?

“We want our AI’s to be like an IronMan suite. Not like Ultron. If IronMan does something cool in his suit, he gets the credit for it. If IronMan is not in the suit, then the suit is just this empty shell”

Is everything difficult, or is it just me?

This is a walkthrough of some mental health issues we all could face while working on a knowledge job. From Anxiety to Sleep. This is a subject we all should put on the table and talk about without any shame.

7 Things Technical Leaders Can Learn from Disney Princesses

I really liked this one. I never thought that Disney princesses could teach us about leadership. I have to confess that I skipped the singing parts from this talk. These are some of the main points:

  • “Don’t turn too many knobs at once…don’t expect immediate results when dealing with teams of people”
  • “Lean on your own self-worth and validation because the higher up in leadership you get the less external validation there will be for you”
  • “A lot of great leaders don’t have superpowers. They’re just generalists.” Instead, they can unlock other people’s potential. “You’re role is a catalyst.”
  • “Find support mechanisms when you move into leadership. This may be coaches, mentors, support groups”
  • “If you’re passing on orders, you’re not leading, you’re just managing”
  • “There’s no such a thing as a perfect team.” “Great leadership is about figuring out how to make teams from of a group of people”
  • “One of your main things is to make crystal-clear and sure that the agendas between your primary and secondary teams are aligned”

How Work Works

This talk uses Queue Theory to tune how complex organization works. These are some of the main points:

  • “IaaS platforms are M/M/c where c approaches to infinite”
  • Recommended books: Continous Delivery, Building Microservices, Building Evolutionary Architectures, Principles of Product Development Flow, Accelerate, Team Topologies
  • “Change request boards predict low performance”

Voilà! Another Monday Links episode. Do you AI as part of your daily work? What leadership lessons can you share?

In the meantime, don’t miss the previous Monday Links on CQRS, Negotiating, and Project Managers

Happy coding!

Best of 2023

In 2023, I realized that I’ve been blogging for five years. I started this blog to keep some notes online. Since then, I’ve used my blog to share my learned lessons, answer questions, and rant out loud. I consider my blog as my time capsule.

Last year, I wrote 23 posts. I tried to write one post every other week.

I wrote a series of posts about NullReferenceException, “the billion dollar mistake,” and expanded it into a mini-course on Educative.

I updated my ASP.NET posts to use .NET 6.0, the most recent LTS version the last year.

In one of my client’s projects, I worked with ORMLite. I wrote about pasing a datatable as parameter and joining to subqueries. I was too lazy to write SQL queries by hand for those two edge cases. Also, I shared five lessons I learned while working with ORMLite.

I got an interesting question through my contact page. I could shared my advice on how to start an ultralearning project.

Five posts you read the most

These are the five posts I wrote in 2023 you read the most. In case you missed any of them, here they are:

  1. Goodbye, NullReferenceException: What it is and how to avoid it.
  2. Goodbye, NullReferenceException: Option and LINQ.
  3. Goodbye, NullReferenceException: Nullable Operators and References.
  4. Too many layers: My take on Queries and Layers. While working with one of my clients, I had to write a lot of response objects and mapping methods to implement read-only API endpoints. This post contains my thoughts on taking layering to the extreme.
  5. Goodbye, NullReferenceException: Separate State in Separate Objects. This is how to apply the “make illegal state unrepresentable” mantra to avoid the NullReferenceException.

Last year, I continued working as an independent contractor and content writer. I continued writing for NCache official blog. I started offering onsite courses and training in my city. Unfortunately, I saw a lot of coworkers being laid off. I hope they all had found “greener pastures.”

Voilà! That’s my 2023 in review and your five favorite posts. I hope you enjoyed them as much as I did writing them.

If any of my posts have helped you and you want to support my work, check my courses on Educative, download my ebooks and buy me a coffee on my Gumroad page.

Don’t miss my best of 2021 and best of 2022.

Thanks for reading, and happy coding in 2024!

TIL: How to color a website based on its URL. A visual aid and time saver

These days, I spent a while debugging an issue. After a couple of minutes of scratching my head, I realized I was looking at log entries in the wrong environment. I know! A facepalm moment. I decided to look for a way to change the colors of a browser tab or a website based on the URL I visited. This is what I found.

Coloring a website per URL

After a quick search, I found the URLColors extension in GitHub. It adds an opaque rectangle on top of a website. We only need to configure a keyword for the URL and a hex color. Optionally, it can make the rectangle blink.

For example, this is how I colored Hacker News,

// <site>, <color>, <flash|no>, <timerInSeconds>, <border-width>, <opacity>, #b58900, no, 0, 10px, 0.5

I used this extension to color the OpenSearch dashboard and other websites I work with. I use the Solarized theme and different color temperatures and rectangle width per environment.

This is what an OpenSearch dashboard looks like,

An OpenSearch dashboard with a red rectangle around it
An OpenSearch dashboard for a non-development environment

I go with a red and thick rectangle that blinks for Production-related environments.

Coloring Management Studio bar per connection string

I use a similar trick with SQL Server Management Studio. When connecting to a new server, under the “Options” button, we can change the color of the status bar,

SQL Server Management Studio 'Use custom color' option
SQL Server Management Studio 'Use custom color' option

Voilà! No more changes in the Production environment by mistake. No more time wasted looking at the wrong website. Colors are helpful for that.

Even we can change Visual Studio title bar color with the SolutionColor extension.

For more productivity tricks, check How to declutter sites with uBlock Origin filters and how to automatically format SQL files with Git.

Happy coding!