Tag: Frugality

Hooray For Heuristics

Hooray For Heuristics

By | | Comments 3 comments

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?

Put A Bow On It

Put A Bow On It

By | | Comments 0 Comment

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.

Putting Pen To Paper

Putting Pen To Paper

By | | Comments 0 Comment

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!

Hodgepodge Advice

Hodgepodge Advice

By | | Comments 0 Comment

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

Whatcha Been Up To?

Whatcha Been Up To?

By | | Comments 0 Comment

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!

A Rose By Any Other Name

A Rose By Any Other Name

By | | Comments 0 Comment

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).

No Silver Bullets

No Silver Bullets

By | | Comments 0 Comment

I thoroughly enjoyed the advice given in Scaling with common sense, probably because I’ve violated each of those principles at various times in my career, and are (hopefully) wiser for doing so.

But the real gem was a link to the following sketch:

I’ve been in that meeting, both as the speaker, and as the listener. Whenever I hear someone say “just move to microservices” like it’s some kind of magic spell that instantly fixes all problems, I want to go full-on Andy Bernard and punch a hole in the wall.

The Dark Side Of Reuse

The Dark Side Of Reuse

By | | Comments 0 Comment

Every branch that bears fruit, he prunes it so that it may bear more fruit.
– John 15:2

Deleting code feels so good, especially when it’s code I’ve written. It’s an emotion predicted by the Creator’s Curse, and it also make sense under the lens of this article, which challenges developers to write code that’s “easy to delete”.

Too often, especially in academic settings, or with inexperienced engineers who don’t have the experience of the dirty hacks required to keep an actual real-life system running, there’s a view that good software engineering practices are like the Ten Commandments, never to be violated. But for every rule, there’s any number of exceptions, and I loved the way the author laid out these tensions.

OOPs I Did It Again

OOPs I Did It Again

By | | Comments 0 Comment

Have you ever looked at a heavily object-oriented codebase (Java, I’m looking at you) and immediately felt dumber? Did the design patterns touted as the ultimate in software craftsmanship sound amazing when you studied them in school, but now every time you see them in real projects they result in layer upon layer of confusion?

You are not alone.

There is no one approach to rule them all when it comes to software development, and while I wouldn’t be quite as hard on object-oriented programming as the articles linked above (yes, there are multiple ones), it’s not the only, best, or even appropriate pattern to use in all circumstances.