Many people try to come up with a great name all at once. This is hard and rarely works well. The problem is that naming is design: it is picking the correct place for each thing and creating the right abstraction. Doing that perfectly the first time is unlikely. Let’s talk about evolutionary naming. Continue Reading »
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 »
Posted in post | Leave a Comment »
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.
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 »
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 »
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 »
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 »
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 »
I find one of the important early mind shifts to be a switch from thinking of unit tests as test to thinking of the set of all tests as your spec.
If your spec is clean, you could delete your product code, hand it to someone, and they would implement the same product, with roughly the same design.
If your product code is clean, you could delete your spec. Hand the code to someone and they could extract the spec from the code, ending up with a similar spec.
The first of these is called TDD. The second is called working effectively with legacy code. Continue Reading »
A couple centuries ago, fires were seen as a natural side effect of cities. If you put that many businesses and houses together, sometimes it would just all burn down. Cities were useful, so you accepted that every once in a while a whole lot of people would die in a fire.
Much of the software world is in the same state today. Bugs are seen as a natural side effect of code. If you build systems that solve that many interesting problems for people, sometimes it will just all screw up. Software is useful, so you accept that every once in a while a whole lot of people’s work will die in a bug.
The people building and debugging software today have similar methods of working to the people building and de-firing cities then. But today, fire fighting and city planning are different. They prevent fires. Fires still happen, but no cities burn down and few people die. Let’s do the same with bugs. Continue Reading »