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:
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
splitting refactorings into two commits: changing the API and then changing the calling sites
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.
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.
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.
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.
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.
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?
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.
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.
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.