Public Service Announcement
This is a slash: /
This is a backslash: \
Website URLs have slashes. If you say “backslash” or “forward slash” when describing a URL, I will judge you.
That is all.
Automatic For The People
When I quit my first job after nearly 12 years, it was a shock to lose access to all the software I’d spent years developing. While I believe strongly in Egoless Programming, and resisting the notion of “my code”, so much reference material I’d built up was suddenly lost to me. I decided in that moment I needed to build up a portfolio that could not be taken away.
A few weeks ago I published Chrome Local Storage, a Python package that can read from and write to the Chrome’s browser’s internal storage, either one running locally or on an Android mobile device. The first draft didn’t have any CI/CD automation in place, but this weekend I fixed that.
It now automatically sets the version according to the git tag, runs some limited automated tests, runs a linter, scans both the code and dependencies for security vulnerabilities, and publishes builds to PyPI. All via Github Actions.
Did this project really need a complete pipeline? Not really, I doubt I’ll see much reason to modify it in the future. But I wanted to learn Github Actions, and I’d wanted to learn Poetry. Now I’ve done both, and have a publicly available reference to which I’ll always have access for when I need to build Python packages in the future. And if others need the same, they can use it as well.
Throwing In The Towel
I’ve said before that I enjoy thinking about organizations, continuously optimizing them to give the highest probability of the desired outcomes. Organizational ergonomics, if you will. I’m also a mathematician by training and a nerd, which is what made Applying the Universal Scalability Law to organizations such a fascinating read, because it puts statistical weight behind its arguments.
In the same vein, I thoroughly enjoyed the following two articles that take a mathematical approach to understanding variability in project estimation (a perniciously difficult problem in all technical work):
- Why software projects take longer than you think: a statistical model
- σ-driven project management: when is the optimal time to give up?
The latter’s provocative title hopefully piques your interest enough to read further. You won’t regret it!
Shakespeare On Tech
Yesterday I got to integrate one of my favorite idioms into a conversation: hoist on his own petard. I was discussing ways in which less technical folks can still evaluate an interview candidate’s technical competency.
Look, if you’re going to try to impress someone with your vast knowledge of all things computing, you better be able to back it up. Because it’s easier than you think to detect BS. One of the simplest ways that an evaluator of any level of technical depth can detect a fraud is to ask them to explain their solution as if their audience was a smart fifth grader. If they can’t map the details to metaphors in a comprehendible way, it’s unlikely they truly understand them either.
Third Time’s The Charm
Things I get wrong the first time, every time:
- Plugging in a USB device
- Spelling “separate”
brew updatevsbrew upgrade- The flags to
tar(obligatory)
We’re All Just Folk Now
Back in 2014, I read The End of Men; having just been hired by a startup run by a woman, it felt like a good time to explore ideas about why men have traditionally dominated positions of power, and how and when that might change. I don’t remember many details about the book itself (and apparently it’s somewhat controversial in conservative and progressive circles alike), but I do remember coming away challenged to do my part in centering women as I moved forward in my career.
Fast-forward to this past week, during which I happened to have many interactions with female colleagues:
- Two women presented a dashboard on team performance metrics to our team
- I got career advice from the female founder of a major cloud consulting company
- Three times I met with various female peers to discuss leadership transition opportunities
- I provided coaching to a woman just beginning her career in technology
- I partnered with a woman to conduct four back-to-back interview sessions
While there’s still more work to do to undo historic inertia, realizing that I’m surrounded by so many capable women from whom I can learn is an opportunity I hope only gets less rare.
Don’t Be Late
I’ll be the first to say that UX is hard, but honestly now, do I really need to specify a dinner reservation time-of-arrival down to the second?
If I had to speculate, the implementor probably just copied an existing time input widget without consideration of the use case. Situations like this are a reminder of a downside of code reuse; yes it might save some development time, but is it best for the customer?
Hooray For Heuristics
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?
Hodgepodge Advice
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
Doomed To Repeat It
Technologists are particularly susceptible to recency bias. It’s one reason why I try to read older computer science literature from time to time (especially work from the 60s and 70s). The Mythical Man-Month is my canonical example; it should be required reading for everyone who works with technology. The Psychology of Computer Programming contains timeless truths of what it takes to lead a team of software engineers. Donald Knuth’s The Art of Computer Programming is a dense, three volume work, but much treasure lies within. I’ve only finished the first book, but I came away with tremendous respect for the geniuses that paved the way for us fortunate souls who have IDEs, fast compilers, and gigabytes of RAM.
Today I read On the Criteria To Be Used in Decomposing Systems into Modules, a research paper by D.L. Parnas of Carnegie-Mellon University, published in 1972. While the details of the middle section weren’t terribly interesting, it’s the bookends of introduction and conclusion that impressed me. The benefits of two-pizza teams were clearly understood fifty years ago, for example (“separate groups would work on each module with little need for communication”) and the paper lays out a novel approach to decomposition (to me, at least):
“We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.”
The above resonates with prior posts I’ve written on abstractions, especially Out of Sight, Out of Mind. If the goal of abstraction is to hide difficult detail, we ought to modularize with that goal front-and-center.