Inspired by Tom MacWright’s Recently series, and to appease Beeminder.
Notes for junior developers
I’ll be starting working as a developer next week. As in any problem solving domain, problems I will get will have a few good and many bad solutions. My focus in this “first period” will be focusing on learning what makes a solution good, and when to make a trade-off for a worse solution for the sake of e.g. speed.
Developing problem solving expertise is difficult. Surely, I will feel lost, tried and tried, and hate everybody & everything. Here’s some advice from jae anne and Dan Abramov on how to tackle this.
In short, jae anne shouts a warning that anytime something works but you don’t understand it, you should treat it as it’s “not working” and your work not done. You just don’t give into the feeling of “I just want this damn thing to be done.”
In a sense, these are obvious. In another sense, it’s hard for me to tell “Up to which resolution should I understand what’s going on here?” before being able to use jae anne’s suggestion. That’s easier to do for me than following their advice, and is a pre-requisite too.
Command-line tools that compete with a Hadoop Cluster
Adam Drake wrote (many years ago) a short demo of what can be achieved with small, sharp tools.
I’m pretty happy if I can pipe two shell commands (and not lose any file), while Adam goes on to parallelize operations and all.
Inspiring stuff.
“Shorthand for shaping”
I’ve always found shorthand a bit magical. In my own way, I have about 7 shortcuts defined for espanso. That’s all I have to say about shorthand.
There are also custom (sometimes ad-hoc) shorthands that people use. Ryan Singer’s essay “Shorthand for shaping” is a short exposition of a custom shorthand of how he used a simple shorthand notation for thinking about a early stage design process.
Being someone who doesn’t know shorthand, neither designs anything, I found it pretty interesting to see that a sketch like this is part of the process:
