Something I know about myself is that I learn best when I make lots of quick attempts at something. This works better for me than spending longer on each individual step. Like when I learned to make clothes: I had an awful lot of unwearable garments.
I think it's fun that other people (including my partner) learn best by paying monumental attention each (sub-)step of their first attempt, wanting to get it perfect.
You learn how you learn, in more ways than one.
Something that John Ousterhout recommends in their books on software design is designing something twice, because you probably won't get it right the first time, even if think you definitely should get it right the first time.
This past week I've made lots of little tweaks to software. A few "oh, when you do X, could we make sure Y happens" or "oh, wouldn't it be nice if B was automatically calculated when you put in A?".
I have found myself, more than ever, relying on the ability to completely undo all changes to file(s), and take another run at it.
Sometimes it's because the footprint of a "simple" change spirals, other times it just "feels" wrong, other times it just breaks.
If I was a clever man, maybe I'd be able to foresee which approaches are likely to be chaotic and messy. But, too often, something doesn't work the way you'd expect, or some of your own code isn't quite flexible enough yet (and now isn't the time to make it flex).
Making it easy to hit the eject button, and feeling happy doing it, feels like a close second - and something that I think lets me ship higher quality software quicker.
See other articles