newsletter
- lines of code (per class, per file)
- number of commits per author per day
- Keep it professional. Don’t. Get. Personal.
- Don’t take it personal.
- Show your work early and often.
- Improve after receiving feedback.
- Repeat from step 1.
Confidence, or: How to assess your coworkers
Today I’d like to answer a question.
As a (project or product) manager, how am I able to assess whether my coworkers write good code?
It’s is a good question. It’s easy to see why a development team lead might want to know whether her direct reports write good code. And she probably has pretty easy means to find out. A project or product manager might care just as much—or he might only be curious. Either way, how could he judge the code quality?
Related to Friday’s email, if you wanted to know something about the software quality, you could ask your clients or users. Or you might already know because people are usually quick to share their opinions especially if something is wrong.
The quality of the code your coworkers write can be assessed with quality metrics.
You can take relatively simple metrics like
Or you could use a software as a service offering like CodeScene or CodeClimate or SonarQube. These offer advanced metrics that take a little more “Code-Fu” to gather.
The most straightforward, most effective metric is another one: Ask them! They are developers and work with the code all day. They will have an opinion on it. Perhaps they have a hard time to explain something they don’t like, depending on their seniority. But you will get some measure of quality. The more people you talk with, the more opinions you can get. And if their views are orthogonal to each other, you can offer to use static analysis to settle the debate.
The question I received had a second part as well:
… and how can I get them to improve their code?
I will offer an opinion on that one tomorrow.
Delete all your tests!
Sorry for not writing yesterday. My schedule did not allow it. I refrained from posting anything since it wouldn’t have been of sufficient quality for you.
On Monday I tried something new. I recorded the content of the newsletter as a video and posted it to YouTube and LinkedIn. While it didn’t exactly blow up, I am happy and excited about these changes. I want to try to stick with this. Today I switched things up. I first recorded the video, of which I’ve embedded a link to below, and then wrote the newsletter.
The subject says it already: Delete all your tests!
Testing strategies - Test management
You don’t need test management. You develop web applications. Your job is not rocket science. It’s demanding, and you are doing a fantastic part shipping features and making customers happy. Who needs test management to do that, right?
Let’s try three different points of view on this:
The software developer’s Pov
You code and you write tests, even perhaps before writing application code? Different project managers come to you with their projects and ask you to be part of the team. You have a reputation with them that you are able to ship. You have your hands in several projects and can choose which ones you would like to work on. Your manager sets up an appointment for the yearly review. You want to ask for a raise. On what ground should you get your raise? Because other employees value you and your work? Because of your reputation?
Testing strategies - Back to start
On Friday I gave you a very quick intro on how you could increase your test coverage and confidence for an application that has no tests. You can consider this the quick and dirty approach that works, when you have little time and just want to start somewhere.
Perhaps you should start at an earlier point. A proper way to start the journey to testing software is the state the question
Why do we test software?
Testing strategies
In an earlier email I asked you on your opinions as to what you would like to read more about. A bit like a “chose-your-own-adventure” style newsletter. BTW: Did you see that show on Netflix, where you can decide how the story unfolds? This was excellent. Although the nerd in me sees many ways how it was confusing for the user and how it could have been even better. But for a TV show? Wow, I am excited that dared to do that!
Anyway, the majority of the answers indicated that you would like to read something about testing strategies.
Only two rules
There are only two hard rules when doing code review with your coworkers:
Remember that you are talking about letters and symbols in files. Nothing more and nothing less. You are doing this to improve the results, the software.
You are not your code!
Indentation as a Complexity Metric
If you want to measure the complexity of your software, there is a lot of software, tools and software-as-a-service offerings available. These options can seem daunting and have a lot of onboarding time (the time it takes you to understand how to use them and get meaningful results).
If none of these things work for you, don’t despair. There is a simple way to get a high-level view on the complexity of your software. And it’s language-agnostic. It doesn’t care whether you write CSS, Ruby, Java or something else.
Show your work
I wanted to add something to the topic from two days ago: Quality in the eyes of your users.
There is a thing I did not mention. A practice that could help you and your team achieve a higher quality of your products:
Interfaces
In computing, an interface is a shared boundary across which two or more separate components of a computer system exchange information. (Source: Wikipedia.org)
You develop a web application that has a frontend for the users and a backend for the business logic and the data persistence. (This is a simplification, bear with me for a second.) Your frontend accesses the data from the backend through an API that the backend provides. This is the first interface. It’s right there in its name Application Programming Interface. But let’s ignore that one for another second. How does your frontend consume the API? Did you wrap the calls to the API in its own class in the frontend?
Quality in the eyes of your users
I bet that most people reading this won’t have UAT or QA. So what could you do to still achieve quality in the eyes of your users?
Yours users will spend more time with your software, like it and recommend it more, when they are happy using it. If we’re honest it might even be enough to make them not dislike the software. There is so much crap software out there, that people use to get their job done, that the bar is pretty low.
Two views on quality
During the last months I wrote a lot about quality and how to develop high-quality software. These letters dealt with topics like linting your code, testing and documenting it. I also wrote about the different perspectives and motives that might exist in your team.
But there is one view that I omitted more or less: The external view of your customers. They expect to receive and use your software. They expect it to be without bugs and to fulfill the role they “hired it for”.
Fundamentals
Taking note
Today I want to share a small little idea with you. An idea that can have grave consequences if misregarded:
When you schedule a meeting with your team, also share with the team who is responsible for taking minutes/notes. One person has to be responsible for that.
Evolve
Since I strongly believe that you can only achieve high-quality work if you trust your teammates, I am trying something today. I trust you.
I will show you a skeleton in my closet.
Frustration
How to train for a marathon
Measure it
I believe in improving the quality of your software projects. If you want to improve something, you have to measure it first. That idea was introduced by Peter Drucker, the famous management book author.
Now if I ask you, what metrics you could measure about your code quality, would you have an answer?