article
-
Invite me to give a workshop on software design and architecture, testing or how to write better code
-
Try to use gamification. This could mean that you publicize the code quality metrics and make it a game to increase the score. The weekly winner gets a price (a half-day off of work?). Better: Make it a team effort. Let them all be winners because it was probably not one person that created all the code in the first place, right?
-
Send them to workshops, conferences or use learning sessions to help them understand how a better/different way to write code would help them with their job.
I sincerely believe that engineers, programmers, developers, coders, and hackers (which one are you?) take pride in their work. They always try to do the best they can. I haven’t yet met a single person who deliberately wrote shitty code. Perhaps it was a byproduct of too little knowledge or experience. But never was it their intent. If you help them level up, they will get better. And your code and products will too.
- Encapsulate What Changes
- Orthogonality
- Inversion of Control
Answering a comment about 'Delete all your tests'
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 😉
Motivation, or: How to get your coworkers to write better code
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.
I am good with code and perhaps with words (you decide). Motivation is a “people-topic”. This is psychology. I do know a good book, a classic that you could read: Peopleware: Productive Projects and Teams The contents in the book will help you understand how to build a great team, how to motivate people and understand their goals. You could adapt this knowledge and make them write better code. Other ideas:
2018 State of Code Review Study
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. This might be true, or it might not. The quality of a review depends 100% on the knowledge, ability to communicate and the time a reviewer takes to dive into the code. Static analysis is way down in second to the last place. Unit testing is right behind code reviews.
I could argue either way. My problem with this study is the term code quality. Code quality to me means that you talk about things like coupling/cohesion, readability, and maintainability, adherence to standards, low bug count. Quality metrics your code exhibits. Code review is not the best tool to increase this metric. Robots and static analysis are. You need impartial tools that hold you to a strict standard. People don’t do this. They are lazy. If you talk about software quality, on the other hand, that’s where you need people. Thinking about and discussing software architecture and design, debating about usability. Fine-tuning the visual design of a product. This is where reviews are the go-to tool for the job.
I guess this distinction was unclear to most participants. That’s a shame.
You can read the study here. I don’t link to their signup form for the study. They ask details like your phone number before you can download it. That’s bad practice, hence the direct link. I’d be happy to hear your thoughts on this. Do you make a distinction between code and software?
2018 State of Code Review Study
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. This might be true, or it might not. The quality of a review depends 100% on the knowledge, ability to communicate and the time a reviewer takes to dive into the code. Static analysis is way down in second to the last place. Unit testing is right behind code reviews.
I could argue either way. My problem with this study is the term code quality. Code quality to me means that you talk about things like coupling/cohesion, readability, and maintainability, adherence to standards, low bug count. Quality metrics your code exhibits. Code review is not the best tool to increase this metric. Robots and static analysis are. You need impartial tools that hold you to a strict standard. People don’t do this. They are lazy. If you talk about software quality, on the other hand, that’s where you need people. Thinking about and discussing software architecture and design, debating about usability. Fine-tuning the visual design of a product. This is where reviews are the go-to tool for the job.
I guess this distinction was unclear to most participants. That’s a shame.
You can read the study here. I don’t link to their signup form for the study. They ask details like your phone number before you can download it. That’s bad practice, hence the direct link. I’d be happy to hear your thoughts on this. Do you make a distinction between code and software?
List of programming principles
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:
To be clear: This list is nothing new. I do like the way they put it together, the idea that it’s growing and the further resources they link to.
Have a look!
A story about a feature gone bad
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.