Readability is a relationship between an artifact and an audience, and we all know that. It's not just the artifact, but here is a funky example.
I got a great new overdrive pedal for Christmas. It looks like this:
The weird bit is that usually the bass/treble EQ controls are together, and the volume/gain controls are together.
This time they're not and that was confusing to me.
Why such a weird order?
Well, the order is completely sensible.
100% brilliantly correctly placed and reasonable.
Just in a way I wasn't considering.
The bass EQ setting is applied before the gain.
The gain is applied before the volume.
The treble adjustment is post-everything.
so, yeah, placement mirrors the signal path.
Once you know that there is no other ordering of the knobs that makes sense.
I didn't even have to look to write these posts.
I know exactly where they are and exactly what they mean, and can even base decisions on that.
There is a shared understanding between the artifact (a pedal in this case) and its audience (me, as a guitar player) that makes it readable, memorable, logical.
Sometimes to reach that shared understanding you raise the level of the audience, sometimes you raise the degree of understanding embodied in the artifact.
But once you are there, you have this beautiful union where the makers, the artifact, and the audience are together in a meaningful way with the purpose of the thing.
Do this with source code and tools.
Please.
Silly sidenote: I asked for it because I thought it would be funny that I'm "Tim" and it's "Timmy," then I researched it and saw how revered it is, now I know why. A wonderful present: I'm enjoying it very much.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
so, OO, right?
What people are doing with Java typically is nothing like OO.
Imagine you're creating your own language specific to your problem domain and solution domain.
That's a beginning.
A language in which you can solve your problems in your domain and stack.
It doesn't exist, btw. Java, JS, Python, C#, Smalltalk -- they're not it. They're the language you build your language in. You don't implement the solution in Java. You implement your solution in the language you've built in Java.
The problem is that you have two locations in space, a bunch of roads, and you want to route a path from one place to the other.
Don't do that in ints, strings, functions, and doubles.
Do it in places, paths, and routes.
In other countries where you drive on the left, the rule is "say left except to pass" and this works. In the US (where we drive on the right) we don't do that. Cars are in all the lanes. There IS a system though.
The far-right lane (remember we drive on the right) is the "ramp lane." People are always slowing to get off the highway, or coming on slow and speeding up.
You'll be always accelerating/decelerating there, so don't drive this one. Go left.
If I'm involved in a task and it's not completed yet, then people may want to talk to me about it or ask questions.
Eventually it's done, and there is less reason for people to need my attention on that topic.
So, the more work I have in progress and incomplete, the more reasons people have to talk to me.
When I have a lot of work in flight, and I'm trying to work on something else, then all those conversations will be felt as interruptions in the work I'm doing now.
So here's what I wanted to think on today: Continuous Improvement.
It has two features to consider:
* It's about making improvements
* It's continouous
Let's take the 'continuous' bit first:
* You're not in it for a burst or for a while, you're in for good.
* Nobody has completed their continuous improvement program. Ever.
* It's not "hopping from rock to rock" - improvements sustain and accumulate.
If you "improve" by expending greater physical effort and endurance, you can't do continuous improvement. Working harder isn't an improvement at all.
You have to sustain if you're to be continuous. Lower the level of effort necessary to succeed, don't brute force it.