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?
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?
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
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.
Technology-related work, like all work, is primarily a social endeavor. It’s surprising that so little effort goes into preparing aspiring technologists about this side of the business, especially given our propensity to be singularly bad at it. Hence this article.
Along related lines, I found the suggestions in What Makes a Great IT Consultant completely applicable to a broader set of technology roles, and would highly recommend it.
I’ve also finally started digging into The Architecture of Open Source Applications; it’s been hit and miss, but more of the former, so definitely worth the time investment. A statement that jumped out at me today (from the chapter on Eclipse) was that an API is a social contract just as much as it is a technical one. I like that way of looking at it; seems a natural corollary of Conway’s Law.
In tangentially-related news, season 2 of Ted Lasso comes out today. You should watch it.
Don’t run your tests with production data. Just don’t. Otherwise, your customers will end up with delightful emails like this:
In jobs past I was pretty cavalier with production data. I was never part of a major incident, but that was more due to luck than strong security controls and separation of concerns. Really thankful that my current employer takes this stuff as seriously as it deserves.
Apparently I really like the above phrase as a blog post title, because this marks the third time I’ve used it. I also once owned its equivalent domain name, where I hosted a blog where everything was themed around it. The blog itself I believe is still out on the Internet, but I’m not going to link to it; I’m not exactly embarrassed by it, but I am a very different person than I was 10 years ago when it was written.
The tagline on that blog was an interesting one: when experience is not retained, infancy is perpetual. That could certainly be said for experience in technical domains like software development, where there’s a bias towards the new, and few people spend time studying the history of the field. Which is why I couldn’t be more excited to have discovered The Architecture of Open Source Applications, a set of books that cover in detail a variety of programs that are used daily around the world.
I just need to finish The Expanse series first, only 2 books to go!
During interviews, a common question directed at me is what my day-to-day looks like. While it feels like a cop-out, the answer is that I do whatever my customers need me to do. Some days that might mean writing Python, Node.js, or Java. Other days it might mean terraform, CDK, or (ugh) CloudFormation. Still other days it might not mean code at all, but leading daily stand-ups, drawing architecture diagrams, writing documentation, giving training, or planning long-term goals. And that’s not to mention all my managerial tasks like 1-on-1s, goal setting, performance reviews, an mentoring, since I view my team as customers of a sort.
We talk at AWS of being comfortable with ambiguity. It’s a posture that doesn’t suit everyone, but pretty much any technical job of worthwhile complexity requires the ability to deal with unknowns. There are no hard and fast rules. No absolutes. System design, software development, team leadership, they are all just as much art as science, requiring both good intuitions and good data to get right.
Don’t believe me? Then consider how Stack Overflow tells it.
I was skimming over a few old posts, and came across this recap of the past year, which closed in a way that sounds quaint at best:
I’m eagerly anticipating the new normal of 2020. More to come!
Yeah, not quite what I meant.
Today my kids had to choose between virtual and socially-distanced on-campus learning for this fall semester (thanks COVID-19). The selection process involved picking their high school from a drop-down on the district website. Oddly we couldn’t initially find their school (Del Norte) in the list.
Why not? Well, it turns out that Google Chrome’s auto-translate feature was attempting to be helpful, and transformed it into “From North”. Which made me realize three things:
translate=no to their <html> tag to avoid this problem altogether.