Really enjoyed Two Heads Are Better Than One, a discussion of the various ways technology has allowed humans to have “second brains.” I realized in some ways this blog is one such implementation; it’s a place I can capture thoughts and stories so that I can recall them later without keeping them in working memory.
As a bonus, via the article I discovered Obsidian, which I’m now dying to try out. I’m a sucker for Markdown and the power of plain text processing tools.
This summer my family and I went on a two week European vacation. Six cities in fourteen days is no joke, but we had a blast, saw a ton, and stayed healthy throughout. For something different, I thought I’d catalog our activities here.
Day 1 – Rome
Day 2 – Rome
Day 3 – Rome
Day 4 – Florence
Day 5 – Florence
Day 6 – Alps
Day 7 – Munich
Day 8 – Munich
Day 9 – Paris
Day 10 – Paris
Day 11 – London
Day 12 – London
Day 13 – Oxford
Day 14 – Journeying
And there you have it. Not a bad way to spend a fortnight.
I’ve mentioned before my penchant for minimalism, which is why for the past 8 years my code editor of choice has been Atom (in fact, I may have been a beta tester for it, my memory’s a bit fuzzy on that point). Which is why it bummed me out a bit to read it’s being shut down at the end of this year. Technology marches on, I suppose. I can’t blame GitHub Microsoft for wanting to consolidate development effort in their fully-featured IDEs, especially integrated cloud-based solutions like Codespaces.
Still, I’m going to miss Atom’s simplicity and customizability (I’d even contributed to a few plugins). It was robust enough to be a complete development environment (for my coding style, at least), yet snappy enough for quick one-off text file editor. For the former case I’ll probably get back into VSCode, and Sublime Text ought to do the trick latter. Though maybe I can use it for both?
Earlier this week I got an email from a recruiter. In itself, that’s not a remarkable occurrence, I’ve gotten 263 such emails since I started tracking them back in 2015. What made this one funny is that it was from my current employer.
I’m regularly asked about the corporate culture at AWS, and a common way I’ve described it is being like a large collection of small startups. This decentralization has a number of benefits, not least of which it only rarely feels like I’m working for a curmudgeonly big business (especially when compared to my last large company gig). But every once in a while the disadvantages show.
Besides the two resolutions I made for 2022, I’ve decided to try out a meta-resolution: every year from here on out, I will resolve to read the same number of books as years I am old (inspired by the coincidence that I finished 42 books last year, which happened to match my age). I track all my reading on Goodreads, where you can follow along if you’d like.
Given the above challenge, I wanted to determine how much of a time investment was going to be involved, and especially wanted an easy way to break it into daily reading targets that would keep me on pace. To do so, I needed two pieces of data: an average book size in pages, and an average time spent per page. My gut feel for these values was 300 pages and 1 minute, which led to a nifty conclusion: if I let A be my age, and aim to read A pages per day, which takes roughly A minutes, I should be able to easily complete my goal of A books over the course of the year (365 > 300, but I expect I’ll miss days here and there). Plugging in my current age of 43, that means a modest investment of 43 minutes per day is all it takes to achieve what otherwise sounds like a difficult goal. Isn’t that neat?
Neat enough that I wanted to validate my assumptions. For average book size, I downloaded the last 10 years of my reading records from Goodreads (I’ve been doing this a while): 84218 pages divided by 288 books gives an average size of 292 pages. My guess was pretty dang close, cool!
To measure my reading speed, I timed how long it took me to read 10 pages of three representative books: Multipliers (business/engineering non-fiction), Lifting the Veil (religious non-fiction), and The End of Eternity (science fiction). Resultant times were 6.5, 10.5, and 10.5 minutes for 10 pages, respectively, which averages out to 0.9 minutes per page. Once again, my intuition was reasonable.
One final statistic worth pondering: if I can hold to this meta-resolution, how many more books can I expect to read before I shuffle off this mortal coil. Thanks to Google, I know average life expectancy for a male in the United States is 75, so we’ll say I’ve got 32 years left. Thanks to Gauss, I can easily compute a sum from 1 to N with the formula N * (N+1) / 2. The sum of 1 to 75 is thus 75 * 76 / 2 = 2850, and now we need to subtract off years 1 through 42, which sum to 42*43 = 903, for a final result of 2850-903 = 1947 books. My Goodreads backlog is only 99 books long, so I guess I better start adding to it. Any suggestions?
Despite writing a bit about CDK nearly two years ago, it’s taken me some time to get a chance to really lean into it. Having now built out a couple real projects, I can confidently say that like it has its rough edges, like any technology, but overall it’s both powerful and fun.
If you’re so inclined, feel free to check out my most recent creation, a construct for deploying a Hyperledger Fabric network on Amazon Managed Blockchain.
# Easy as pie!
HyperledgerFabricNetwork(
self, 'MyNetwork',
network_name='MyNetwork',
member_name='MyMember',
)For my next trick post I’ll go through one of the aforementioned rough edges I discovered, and how it can hopefully be fixed.
I spent some time today chatting with an early career colleague who’s looking towards a future career in the dark arts software development. Being the kind of person that enjoys the sound of my own voice, I enjoy these opportunities to pontificate. One piece of advice I routinely give is that good engineers write well, and developing this skill will pay itself back with copious dividends.
However, that shouldn’t be read to mean that quantity trumps quality. Far from it, keeping things brief is usually more difficult than not (I know I’m bad at rambling, kinda like I am now). Which is why I found this little article on the value of the humble readme such valuable advice.
The other day I published a blockchain solution on Github, and while I’m pretty proud of the code, the readme is in bad shape (as of today at least). For my next project (a refactoring of the core of this solution into a reusable CDK construct) I think I’m going to write the readme first, as the above article suggests. We’ll see how it goes!
I’m a sucker for lists that contain pithy nuggets of truth. Here’s two great ones I found this week:
Some of my favorite statements, in no particular order:
If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system
Every system eventually sucks, get over it
Software engineers should write regularly
Always strive to build a smaller system
KISS, don’t be afraid, and boring > cool
The bottleneck is almost always the database
I’m naming this truism in honor of the co-inventor of the spreadsheet:
Bricklin’s Law
The probability of a project’s success is inversely proportional to the number of status tracking tools used by its team members.
Also, I think this is the first time I’ve used “pull quote” formatting on this blog. Neat!
In all my time thinking about how naming is hard, I’ve never come across a concise set of practical suggestions for choosing variable names in software. Until now. I’ve used the A/HC/LC Pattern my whole career, but never had a term for it. Honestly it could use a better name (naming is hard!) but the concept is solid.
There isn’t a single piece of advice in the above that I disagree with, and a few I absolutely love (my goodness do I hate context duplication in namespaced variables).