Just finished watching Master of None, season 2. What a great show. It’s hilarious without being campy, poignant without being a downer. Aziz Ansari is very good at this. Also, now I just want to listen to old Italian music and eat food.
The first few years of my career, I edited the wrong file all the time. I could spend hours making changes, wondering why nothing was happening, until I realized I’d been tinkering in the wrong place because I was misreading a file path or not paying close enough attention to control flow.
Fast forward to now, and I’m pretty quick to drop a
raise "BLORP" in code I’m tinkering with if things aren’t working like I think they should. All hail puts debuggerering.
However, it turns out I found a new class of this operator error today. I was diligently re-running a test case, expecting new results when the test fixture file I thought was changed was the wrong file. Once I deleted the right file, I was back on my way.
Joyful and grumpy are we who can find new ways to screw up time ever day!
I do my best thinking:
- In the shower. I love to take long showers, and I love my tankless water heater.
- While talking. Something about my brain is wired directly to my mouth.
- When I’m not thinking. See also, the value of letting your mind idle, wander, or just walking away from a tricky problem.
Your thinking may vary!
A few folks suggested I try lazy enumerables to make my extremely chained style practical. I was curious about the actual costs of my style, so it’s time for lies and microbenchmarks! Turns out naively chaining a bunch of maps together isn’t very costly, so go with that to start.
Lazy came in much slower than consolidating the logic in one loop or chaining them without lazy. I thought, I must not have used lazy properly. Turns out, I’m probably showing that laziness isn’t well suited to iterating over collections without an early termination clause (e.g. a take, first, or find) and that for small collections (like an 87-line /etc/passwd), the cost of the lazy plumbing can noticeably outweigh the work done inside the loops. Thanks to Rein Heinrich for talking me to the bottom line!
Programming is easier when you know how to stop solving 100 problems with 1 fancy thing and solve 100 problems with 20 plain things.
I’m always thinking about Greg Borenstein’s words when it comes to technology churn:
The constant churn of web technologies hobbles the creation of timeless learning materials and continuity of knowledge across generations.
We should try harder on this.
Things I’ve noticed San Franciscans deeply despise:
- housing prices
- nearby events that aren’t actually held in San Francisco (e.g. the Super Bowl)
What if large open source projects appointed a community manager to handle things like codes of conduct and social spaces? Anecdotally, those who make large projects are often the worst at actually running a community. Even volunteer projects need management. Flat organizations will always be dominated by ad-hoc in-group politics. The internet we’ve created thus far is allowing terrible people to outpace good people by a long shot.
Things you might hear in commercials/promotions for software and beer:
“The first 96-calorie Pilsner”
“Invented the smooth-pour top”
“Next-generation build system”
“The database that beats the CAP theorem”
American software and beer, much innovation, many hands waving. Solutioneering!
I’m going to Vegas this weekend with my wife on a real vacation where we’re going to do as little as possible. Not run around Disney World all day, not drive up and down the southern California coast. Based on this little bit of research, I can’t wait.