This is really turning into a blog about coding. Apologies to less nerdy followers.
I want to talk (again) about friction. Things that slow us down. How some friction is good, and some is bad.
Deterring thieves
My classic example of “friction” is the lock on the door of your house. There is some ideal world in which you don’t need a lock on your door. Everyone can be trusted.
This makes life easier for you. You don’t need to carry keys. You don’t risk losing keys. You can easily get into your house while carrying 6 bags of shopping. Your children can come and go as they please. That would be a nice world.
But the lock is a necessary piece of friction. It slows you down, but it has the benefit of keeping unwanted people out of your house.
Equally, there might be a world in which you need more than one lock. Perhaps a locked bar across the door. Perhaps an additional electronic lock with biometrics.
This might be necessary “good friction” in some crazy world. But it might be “bad friction” too – you’ve overdone it and caused yourself a ton of cost and frequent inconvenience for no real benefit.
You can do this with code too
For those that don’t know, I’m a staunch advocate of static analysis. I used to wonder why people cluttered up their code with docblocks, but now I have tooling that uses typehints in them, I can really see the benefit and I encourage them.
Docblocks and typehints can be good friction. Yes, they can slow you down a bit, but used wisely they can detect some errors early, ensure you handle edge cases, speed up code review, and give you more confidence in your code.
But… despite being a static analysis advocate, I know that it can be used badly, and so I’m an advocate of cautious and incremental adoption. Use types and static analysis where they help you. Don’t use them when they are in the way and not helping. That’s silly.
Bad use of TypeScript seems to be particularly common. On Shop Talk Show this week Dave and Chris were discussing using AI coding tools like Co-Pilot and they said this:
“Part of it’s like TypeScript’s mad and I don’t know how to make it un-mad. It’s like ‘Just tell me what to do… make it shut up.”
“I love hovering over a red TypeScript thing, scrolling down to the bottom of the tool tip and saying ‘Fix with Co-Pilot’… and if it fixes it, I don’t care”
Which is just really sad. This is bad friction. If types aren’t helping you, get them the hell outta the way! Stop using them. They’re not bringing you value (the “I don’t care” bit) and they’re slowing you down.
I, like Chris and Dave, find TypeScript is too demanding. BUT I can get a lot of value out of using JSDoc – it can get you as much of TypeScript as you want without even needing any build process. You can get the benefit of adding in some simple type information without going overboard and tying yourself in knots just because your editor showed some red lines and you fixed them with AI without really understanding what was going on.
This excellent post was what inspired me and got me going on this JSDoc journey.
And because JSDoc can just be sprinkled in when you need it, it can be adopted incrementally in an additive way. It can be done as “good friction”!
(Yes, there is probably some way to do this with TypeScript as well, but I’ve not seen it done in practice.)
Nico Verbruggen said today:
Friction is always the bottleneck.
When APIs don’t work as expected.
When things break in obtuse ways.
When tests are flakey.
When clients change their mind.
It’s almost always friction that slows software development down.
I totally agree. But these are all examples of bad friction. And I also think that friction can speed us up, and make us better developers.
But you need just enough of it, and not too much.
And the difficult wisdom is knowing how much friction is good.