Conceiving of technical debt as dirty dishes is popular, although it could always stand to be even more popular.
Also do your dishes. Like, in reality. The ratio how happy it makes others who live with you vs. effort required is arguably higher than any other single act available to you. An enormous number of couples’ therapist salaries are made simply convincing people that doing the dishes is important.
Intellisense and a linter? You still need to pack/turn on/unpack a dishwasher; your code can’t clean itself but tooling can help make it faster for you than without it.
I used to be a “soaker” with the kitchen sink until we had a baby.
Nothing worse than waking up to make the kid some breakfast and having to wash every dish you need to get it done. Now I am steadfast on doing the dishes every night to start the day in a clean kitchen.
No kidding! It reminds me of a meme from a clip of the Simpsons cartoon where one of the characters is shown to be living in a rundown apartment with no furniture or food and he says “Don’t tell anyone how I live.” I guess that’s gotta be me based on my desk space…
I’m curious if anyone has any team wide practices for knowledge sharing in this area.
I ask because “better” spends on values. For example, I’m writing a rust tutorial and I COULD introduce more abstraction to make invalid state impossible at more layers, however that code would add indirection, and it’s unclear if it’s meaningful or not. I chose to make the example simpler, faster to write instead of choosing to harden it against accidental misuse. Neither is better, they prioritize different values. Sometimes things are messy because the author was learning and knows better now, sometimes they are messy because
In my ideal world developers would share strong “do this” and “not that” opinions, the always and nevers. And even some “this is okay” cases of “we can’t make this better, even though it seems suboptimal it’s fine”. Ideally listing out their values for why they feel some code is better than others so if we turn these feelings into a linter or shared style guide then we preserve enough info revisit old decisions/opinions. But I’ve not seen that done in a way that’s not just one dev ad-hoc writing down their preferences. I genuinely want an inclusive team-wide framework for continuous improvement and learning. Does that make sense? Any suggestions?
The author makes the assumption that everyone is in alignment on what dirty tasks and things everyone wishes someone else would clean up, but in my experience alignment is truly the hardest part. The best devs I’ve worked with would happily nerdsnipe themselves all day every day over refactorings and tinkering. But it makes them terribly slow sometimes and the process take forever. I feel that if we spent time learning how to improve continuously (yes the wording strikes me as a bit on the nose) that they would feel empowered to ship suboptimal things and take more risks, knowing that there was space for tidying later (I like that more than the loaded “clean” word). I know how to do that as an individual, but don’t know how to drive that as a process as a team. Suggestions?
“Cleanliness” is not formalizable. To your point, people disagree on what is or is not “clean.”
The only antidote I’ve found for this is team-building / team “connecting.” What I mean by this is looking for the moments where you bring up a topic with a teammate, and something just clicks between you. This happened to me the other day with a teammate on the subject of Go channels for example.
This kind of stinks, because this is a pretty fuzzy suggestion. But, I think there’s extreme value in nurturing these connections between everyone on the team. And there are things you can do to be more intentional about making them happen.
A group code review is another good example. Where you review code amongst multiple people. This gives a place for the team to analyze and comment on real code, and share that process together to build connections.
Conceiving of technical debt as dirty dishes is popular, although it could always stand to be even more popular.
Also do your dishes. Like, in reality. The ratio how happy it makes others who live with you vs. effort required is arguably higher than any other single act available to you. An enormous number of couples’ therapist salaries are made simply convincing people that doing the dishes is important.
My life has greatly improved since I got a dishwasher. What would that be in software terms?
Intellisense and a linter? You still need to pack/turn on/unpack a dishwasher; your code can’t clean itself but tooling can help make it faster for you than without it.
I used to be a “soaker” with the kitchen sink until we had a baby.
Nothing worse than waking up to make the kid some breakfast and having to wash every dish you need to get it done. Now I am steadfast on doing the dishes every night to start the day in a clean kitchen.
Maybe I should do this with code too.
…is this a joke that went over my head, or are my standards just really low? Now I’m questioning how much clutter is “normal”.
No kidding! It reminds me of a meme from a clip of the Simpsons cartoon where one of the characters is shown to be living in a rundown apartment with no furniture or food and he says “Don’t tell anyone how I live.” I guess that’s gotta be me based on my desk space…
I’m curious if anyone has any team wide practices for knowledge sharing in this area.
I ask because “better” spends on values. For example, I’m writing a rust tutorial and I COULD introduce more abstraction to make invalid state impossible at more layers, however that code would add indirection, and it’s unclear if it’s meaningful or not. I chose to make the example simpler, faster to write instead of choosing to harden it against accidental misuse. Neither is better, they prioritize different values. Sometimes things are messy because the author was learning and knows better now, sometimes they are messy because
In my ideal world developers would share strong “do this” and “not that” opinions, the always and nevers. And even some “this is okay” cases of “we can’t make this better, even though it seems suboptimal it’s fine”. Ideally listing out their values for why they feel some code is better than others so if we turn these feelings into a linter or shared style guide then we preserve enough info revisit old decisions/opinions. But I’ve not seen that done in a way that’s not just one dev ad-hoc writing down their preferences. I genuinely want an inclusive team-wide framework for continuous improvement and learning. Does that make sense? Any suggestions?
The author makes the assumption that everyone is in alignment on what dirty tasks and things everyone wishes someone else would clean up, but in my experience alignment is truly the hardest part. The best devs I’ve worked with would happily nerdsnipe themselves all day every day over refactorings and tinkering. But it makes them terribly slow sometimes and the process take forever. I feel that if we spent time learning how to improve continuously (yes the wording strikes me as a bit on the nose) that they would feel empowered to ship suboptimal things and take more risks, knowing that there was space for tidying later (I like that more than the loaded “clean” word). I know how to do that as an individual, but don’t know how to drive that as a process as a team. Suggestions?
“Cleanliness” is not formalizable. To your point, people disagree on what is or is not “clean.”
The only antidote I’ve found for this is team-building / team “connecting.” What I mean by this is looking for the moments where you bring up a topic with a teammate, and something just clicks between you. This happened to me the other day with a teammate on the subject of Go channels for example.
This kind of stinks, because this is a pretty fuzzy suggestion. But, I think there’s extreme value in nurturing these connections between everyone on the team. And there are things you can do to be more intentional about making them happen.
A group code review is another good example. Where you review code amongst multiple people. This gives a place for the team to analyze and comment on real code, and share that process together to build connections.