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.
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.
Leadership and communication are more important than coding for the success of a project.
Last year, I worked as an independent contractor and engaged in short projects with an American client. This project was a six-month effort to bring group events, like weddings, conferences, and retreats, to a property management system.
This was one of the projects that convinced me that unclear expectations and poor communication kill any software project, not libraries and tools.
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.
“You only have to add your changes to this existing component. It’s already working.”
I bet you have heard that, too. That was what our Product Owner told us to extend an existing feature. We needed to import an Excel file with a list of guests into a group event.
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. We were in the dark.
What was a simple coding task turned out to be a longer one. Weeks later, we were still fixing issues and closing tickets. Nothing related to our task.
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. It was already working.”
After that time, I realized something similar had happened in every job I’ve been in. I didn’t see that coming in this project.
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?
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.
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.
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 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
Voilà! No more changes in the Production environment by mistake. No more time wasted looking at the wrong website. Colors are helpful for that.
