After 4 years, I’ve updated and re-written Naming as a Process as part of Deep Roots (my company which focuses on teaching these techniques as part of Code by Refactoring). The new version now contains the previously-missing final article!
Naming is a Process, part 2: Missing to Nonsense
After 4 years, I’ve updated and re-written Naming as a Process as part of Deep Roots (my company which focuses on teaching these techniques as part of Code by Refactoring). The new version now contains the previously-missing final article!
Good naming is a process, not a single step
After 4 years, I’ve updated and re-written Naming as a Process as part of Deep Roots (my company which focuses on teaching these techniques as part of Code by Refactoring). The new version now contains the previously-missing final article!
Improving the Perfection Game
Other people’s insights are crucial when you want to get better at something. One of the best ways to get those insights is the Perfection Game. But one part of the game has always bothered me: the numerical score for the performance. I think I’ve fixed this problem. Continue reading “Improving the Perfection Game”
Gender bias in my hiring history
I have hired a lot of people. I have hired more men than women. I have also hired a greater proportion of female applicants than male. Both of these are critical to understanding the bias in my field (software development) and what to do about it. Also, both are indirect results of something else.
Most of the industry optimizes hiring decisions for individual performance. They assume the best company performance comes from strong individual performance.
They are wrong.
Learning faster and more deeply
I can change the rate at which I learn things. So can you. It doesn’t depend on topic or natural inclination. It doesn’t depend on intelligence. It’s all in how I set up my learning experience.
I am not a professional instructional designer but I pair with them. I am a professional coach. And I am a professional learner. Here are the techniques I use to learn, instruct, and coach more effectively. I hope you find them useful. Continue reading “Learning faster and more deeply”
Making good estimates (with martinis)
I typically ignore planning in this blog. Not because it isn’t important, but because it isn’t important until later. You need to be able to deliver if you want your plans to mean anything.
However, there is one topic that I think worth discussing: estimating your work. I find this worth discussing because I see so many people do it wrong and suffer massive pain that they could have avoided.
Which causes deadline pressure. Which prevents them from making the improvements that would help them deliver. Continue reading “Making good estimates (with martinis)”
Metrics: are we doing TDD?
A manager recently asked me how to measure whether the teams were unit testing. He believes that they are. He has heard strong alignment among ICs and managers. He also knows that the teams have no way to see if they actually are unit testing or how well.
He, like most people, asserted the use of code coverage as the core metric. Both total and per-commit delta.
I agree that we need some optics. I just think code coverage is a crap measure. Continue reading “Metrics: are we doing TDD?”
Using code review to support change
Someone I know had the following conversation recently during code review:
- [WontFix] //depot/[elided].cs: Line 232
- [reviewer]: Unit test this directly
- [author]: the integrations test this. Don’t see any direct benefit of UT it directly. (26 minutes ago)
He wanted advice on how to get past this. His goal is to get his team to write direct unit tests, as opposed to multi-unit component and integration tests. But how? And what does he do in code review to help the team accomplish that in specific cases? Continue reading “Using code review to support change”
Don’t standardize MVPs!
I got a question this morning:
We are struggling to define a standard MVP across the teams. Do you guys have any suggestions for us?
One question: why do you need a standard? What problem are you really trying to solve?
I ask because the point of doing MVPs is to support validated learning. It assumes a development process that is based on running experiments to learn things, not on building things to a definition / spec.
Experimentation is inhibited by over-standardization, so you must be wanting to do this for some other reason (probably status reporting or other forms of status). Continue reading “Don’t standardize MVPs!”