Welcome to another issue of Practical Software Design.
This week we'll be talking about:
Testing Readability
On Being Human
Learning things that don't change
Testing Readability
A radical (and maybe silly) idea.
Imagine if you could test the readability of your code.
I declare "that's readable" all the time.
What evidence do I have? 🤷♂️
Well... not much.
Apart from that fact that I was in a meeting where me, myself and I all agreed…
…that code I just wrote is awesome.
Yes, smug mode engaged.
My work here is done.
Then 6 months later I return to that "readable" code... and I'm cursing myself.
"What the heck does that do?"
"Yeah, nice job past me."
Turns out the past me was an idiot.
This has happened to me repeatedly...
...and yet I still don't have a good antidote for it apart from "more code reviews".
Which is nice and all... but hardly scientific.
There's a whole discipline devoted to user testing user interfaces.
The UX folk know how to structure the interview, how to ask questions, and how to understand the user's mental model.
Why not an equally disciplined approach to testing the subjective readability of our code?
Imagine if a PR could be run through readability tests, where 10 random developers from all over the world could see your code, and were asked questions like:
What does this do?
How does it work?
What parts do you not understand?
I hear what you're saying "We do have that, John, it's called Open Source!".
Sure, but this would be for private repos.
This app could compile all those responses together and maybe even give you a "readability score" - a bit like Code Climate.
It would give you a sense of which parts were most confusing.
Then you could make changes, resubmit and see if the code was easier to read or harder.
Please let me know your thoughts by replying to this email!
On Being Human
Human > Technology
Let's be human.
Why should you care?
Obsessing about coding, engineering and technical skills is a beautiful thing.
Regularly I find myself up late at night coding.
Especially when I'm obsessed with a topic like I am at the moment. *
But after a while of this, I start to feel weird.
Disconnected.
Empty.
Did you know that 15% of men say they have zero close friends? **
Last night I went out to a meetup, connected with humans in person, and it felt great.
As engineers, we focus too much on the tech and not enough on the human.
Some ways to become more human:
Write for humans first and computers second
Take time to get to know your colleagues
Ditch the jargon and enterprise speak
Go to meetups (yes, real-life in-person meetups
Connect with others on LinkedIn and via face-to-face conversations
Sit in on some user tests of your product. You'll learn a lot. 🤯
As AI becomes more and more A Thing, we'll value human connection more and more.
* The topic is nullable architecture, but that's for another post
** According to American Perspectives Survey, conducted by the Survey Center on American Life
Learning things that don't change
Don't learn another framework.
Don't learn another language.
⭐ Learn things that don't change. ⭐
Jeff Bezos' advice to the founders of BaseCamp 15 years ago?
It was the same.
"Invest in things that don't change".
What doesn't change in software?
Designing software that's easy to change.
"How ironic!" Shut up Alanis.
The majority of talks, courses and books, are on new tools, languages and frameworks.
That's nice... but where are the books on design?
On refactoring?
On making code that's easy to change?
Sure, there are the classics.
But this subject doesn't get anything like the attention it deserves.
The syntax of a language is relatively easy to learn.
The idioms of a language are more difficult and have more value.
They teach you new ways of thinking.
Software design skills last for life.
No matter the framework or language.
What Next?
I have two options:
Book a 1 hour coaching session (normally $200, FREE for a limited time)
Have a great week!