Before I get to today’s topic, I would like to say thank you, to you. My little poem yesterday seemed to resonate with you. At first, I planned to write about it and its meaning today. But your responses indicated that it spoke to you. And I wouldn’t want to ruin this with my ramblings about it. So I’ll just finish with: I enjoyed this very much.
Lately, I spent some more time on Twitter.
Back then; I did it; I liked it much; Found it a necessary touch;
Never it challenged, I; then saw; A source without it; didn’t look too raw;
Since then it flows without it well Some purists call it living hell.
Back then; I did it; I liked it much; Found it a necessary touch;
Never it challenged, I; then saw; A source without it; didn’t look too raw;
Since then it flows without it well Some purists call it living hell.
[…] we do have formal rules that we should obey when writing code. A team has rules, and new team members need to learn them before trying to write any code.
That’s what I wrote yesterday. It’s my email so I can write whatever I think is correct. You’ll let me know through your answers if I am wrong.
My friend Tino answered on Friday and asked whether a university degree or certificates might function as a driver’s license.
We don’t have rules of the road for software development. You don’t have to stop at every red light or keep your speed below a specific limit.
Well, yes. We do have rules. If you write your whole program in only one file, someone will tell you that this is bad. At least I hope that’s the case! If you only use variable names like x or y, your coworkers will flag this during code review.
Every country I know has an obligatory driving license before you are allowed to drive a car by yourself.
No country I know has an obligatory coding license before you are allowed to code by yourself.
The longer the time that passed between the driving license and the current day, the more reckless and careless drivers have become. What I mean is that new drivers are careful. For the rules, for their passengers, for other cars and people.
I came across a very interesting article written by Herb Caudill, on different perspectives on rewriting software. He highlights 6 different stories of how a rewrite went. You can read about Basecamp, Netscape Navigator, Gmail, and others.
It is a long article, over 30 minutes according to Medium.com. And I am also sorry for linking to Medium. I don’t like them, and I resent sending them traffic. But this story might be worth it.
Matthias Berth is a German expert on software delivery and software quality. He politely disagreed with me on the idea that you should delete all your tests.
I decided to call this day “Video Wednesday” and record an answer as a video. I just posted it on LinkedIn, and thought you might like to watch it there.
It even has subtitles 😉
Matthias Berth is a German expert on software delivery and software quality. He politely disagreed with me on the idea that you should delete all your tests.
I decided to call this day “Video Wednesday” and record an answer as a video. I just posted it on LinkedIn, and thought you might like to watch it there.
It even has subtitles 😉
How can I get my coworkers to write better code?
We closed with this question, yesterday. If you want to be able to motivate your coworkers to write better code, you have to know where they stand right now. I already wrote a few articles onthis topic. Follow these links, and you’ll get a good idea on what to measure, how and why. You’re welcome.
After reading and measuring and talking with your coworkers, you are still left with the idea of motivating them.
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.
81% of respondents who were satisfied with their code review process were also satisfied with the overall quality of their software. Respondents who were not satisfied with their code review process were half as likely to be satisfied in their overall software quality, with only 40% respectively.
This is from a research study done by SmartBear.
This image tells us that the majority things code review is the way to go to increase code quality.
81% of respondents who were satisfied with their code review process were also satisfied with the overall quality of their software. Respondents who were not satisfied with their code review process were half as likely to be satisfied in their overall software quality, with only 40% respectively.
This is from a research study done by SmartBear.
This image tells us that the majority things code review is the way to go to increase code quality.
List of programming principles This is a nice list of principles you could (or should?) follow in your programming.
https://github.com/5minpause/programming-principles
Disclaimer: I forked the repository from the original source. I want to preserve it for you since I don’t know what will happen to the original.
While things like YAGNI and KISS are rather well known, there are other ideas that are put quite well.
Examples:
Encapsulate What Changes Orthogonality Inversion of Control To be clear: This list is nothing new.
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.
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?
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
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.
Chad clicked the button and created his pull request. He had worked on his feature really long — it must have been three weeks. Finally, it was time to integrate his changes into the master branch so they could go live with the new version of the app. This was the first huge feature that was his responsibility. His team lead, Janet, gave him the ticket for the task and he set out to write his code. “When it finally goes live,” he thought, “the churn of our users should drastically go down!”.
Primarily he had found many places in the app, where users committed some actions. Up until now, these actions weren’t registered anywhere, so nothing and nobody tracked them. There was no record of what the user did or didn’t do inside the app. Marketing alerted management that too many users did not renew their accounts, or outright canceled. In turn, management asked the developers to do something about it. Together the team decided to record all user actions and put them into a log of all activities for this user. This way they could make calculations which users were not active in the app and reach out to them to prevent them from abandoning the application, or so they hoped.
The development of the feature enabled Chad to take a thorough look at the whole application. After all, he had to integrate his code into all kinds of places. And so he did. Today he was finally ready to publish the code and begin the merging. To integrate it into the master branch so that it could get deployed, he had to create a pull request. “Since my code is well written and worked when I tested it, it shouldn’t take too long for this merge to complete.” was his conviction. He assigned the pull request to his team lead and another backend developer that he had talked to during lunch a few days earlier. Chad used the lunch to tell her about his progress on the feature, and she seemed interested. So another set of eyes shouldn’t hurt.
There are only two hard rules when doing code review with your coworkers:
Keep it professional. Don’t. Get. Personal. Don’t take it personal. 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!
