Tag: Learn And Be Curious

Doomed To Repeat It

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.

There’s Gold In Them Thar Hills

There’s Gold In Them Thar Hills

In my conversations with fellow engineers, git comes up quite a bit. I find myself regularly giving advice both tactical and strategic on its effective use. Learning it in detail is a force multiplier, but few people do. Part of the problem is that training materials are all over the map.

Which is why I was so pleased to discover Git from the inside out. Without question the best introduction to git I’ve come across. It perfectly balances teaching basic commands while also explaining what’s actually happening. Despite having used git at a fairly advanced level for 10 years, I still learned some new things, for example that each git add creates an immutable blob object that is retained for a while even if you git add the same file again, and even if you never commit it. Also that it’s pretty easy to decode raw git objects should you ever need to; here’s a script I wrote to do just that, if you’re curious.

I’ve said before that abstractions are valuable, but they’re not excuses to avoid learning internals, because critical information lies beneath the surface. At the risk of pretentiously quoting myself:

When things go wrong, the engineer must descend into the particulars, and an inability to minimally reason about, if not fully grasp, what lies beneath an abstraction can prove fatal to the debugging process.

I didn’t write the above with version control in mind, but I surely could have. Engineering organizations are full of developers who run stuck the moment a git command fails. You don’t have to be that developer!

I Appreciate You

I Appreciate You

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.


Mount Rushmore

Mount Rushmore

I wish I had the time and talent to write like Joel Spolsky. He’s one of my favorite people in the public sphere of software engineering. Here’s a couple articles I read yesterday, they’re both oldies but goodies:

  • Making Wrong Code Look Wrong – I’ve never been of fan of the “data type prefix” in variable names, so I was biased going into this discussion. But I was pleasantly surprised to hear the actual history of Hungarian Notation and that misuse of it was based on a misunderstanding of “type” vs “kind”.
  • The Law of Leaky Abstractions – I’ve talked about abstractions before, they’re a central concept to the art of software development. Getting them right is hard; in fact, it might just be impossible.

You should check out Joel’s whole blog. It’s great.

On The Brink

On The Brink

I’m currently sitting at 998 reputation on Stack Overflow. Anyone willing to upvote some of my answers to push me over 1000?

Speaking of which, most software developers are rapid consumers of Stack Overflow, but how many give back by actually answering questions? About 8 years ago I started trying to spend a bit of time each week contributing, and while my consistency dropped off after a few months, it was a rewarding experience. It didn’t hurt that I was also trying to beef up my online presence during a season of job hunting.

My current workplace has an internal developer Q&A site which I’ve just recently started actively contributing to as well. For one, it’s good writing practice. And also because learning is best done in public.

Getting Warmer

Getting Warmer

This past summer my family and I took on a little project: we bought a house in Lake Arrowhead and listed it on Airbnb. Because it’s useful to both see and remotely control the temperature there, we had a dual-zone WiFi-enabled Honeywell thermostat installed. And because I’m a nerd, I wanted to track its settings, and the corresponding outdoor temperature, over time.

Behold the Temperature Collector. It runs in AWS Lambda and polls both the thermostats and a public weather API every 5 minutes, writing the results to CloudWatch metrics, where I can then graph them on a dashboard. Pretty nifty!

While I was at it, I added support for a Nest thermostat, which I have here in San Diego. And because I love writing automation, I have terraform code to deploy it all. If you need a simple example of how to create a Lambda that runs periodically, you’re welcome to steal it. That’s the beauty of learning in public.

Isn’t It Ironic?

Isn’t It Ironic?

Today I saw the following commit message in a code repository:

fix typi

It wasn’t me this time, but I’ve been there. We should all strive for better. There are dozens of guides on how to write good commit messages. And if you mess one up, as long as you haven’t pushed, git commit --amend is your friend.

Other than learning to type faster and more accurately, there are few activities I know of that can rapidly level up a developer’s effectiveness than becoming fluent with git. And I don’t mean just the basics, but really digging into the details and practicing until it becomes second nature. Start by reading Pro Git, cover to cover. You won’t regret it.

Like All Good Things

Like All Good Things

The Morning Paper is wrapping things up, as explained in its final post. A treasure trove of computer science deep dives, it will be missed. But I can certainly relate to the desire to move on, especially when a global pandemic has brought life’s various priorities into sharper focus.

Luckily for all of us there is a rich back catalog of posts that could keep one busy for months. Do check them out. Need a place to start? Here’s my absolute favorite: Applying the Universal Scalability Law to organizations.

Put A Bow On It

Put A Bow On It

I spent a bunch of time over the holiday cleaning up some Python tools I’ve written, and packaging them up for easy distribution via an internal PyPI repository.

The endless list of things to learn never ceases to amaze me, in this case I got to play with tox for matrix testing/packaging, and twine for publishing. Also got a lot better at writing setup.py files and integrating quality tools like flake8 and safety.

Here’s a couple helpful write-ups that I found when researching best practices for Python packaging:

Packaging a Python library
Python packaging pitfalls

In the course of the above, I also found it necessary to inquire about modifying an open-source tool for measuring code coverage. Turns out it was easy enough to make the modification and submit a PR to the maintainer. If you’ve never contributed to an open-source project, I highly recommend it!

Something Different

Something Different

All the time spent indoors during the pandemic quarantine has afforded unique opportunities for creativity. Last night we played some D&D as a family, and to get in the right mindset, I wrote a backstory for my character. Thought I’d post it here for posterity. Enjoy!

I never knew my parents; no one did. I was left in the dead of night on the portico of the Second Temple of The Mother, naked and shivering. Reverend Shaeltiel brought me in, and quickly became like a father. As I grew, it became clear I was more than human. Not just because of my lanky frame and luxuriously long and straight hair. The reverend had never seen anyone with my thirst for knowledge. By my sixth year-day I’d memorized the entire Sacred Codex, and by my tenth there were no more books in the temple library I hadn’t read at least twice. Still I craved more.

It first happened during a thunderstorm. I laid awake, reciting an ancient poem to myself in a failing attempt to soothe my anxieties. Simultaneous with a flash of lighting outside my window, I felt a prickling sensation on my hands, and behold! Little arcs of electricity bounced between my fingers. I caught my breath, and the sparkling stopped. I would get no sleep that night.

Early the next morning I went to Reverend Shaeltiel and explained what happened. He sighed, and brought me to his study. Only behind the heavy doors did he tell me that he’d long feared for this day, for my prodigious intellect had tapped into forces older than any beings on earth: the elemental forces. He explained that with further study and practice, I could master these forces. How did he know this, I asked. Because he too could command them. It was a skill forbidden by the church, however, and in his zeal for faith he’d resisted its practice. With time, he said I could do the same, but first I had to learn control.

For months we trained together, always in secret. I brought forth light from darkness and summoned great bolts of fire from my hands. From a hidden chamber in his study, Reverend Shaeltiel provided massive tomes containing even greater possible feats where even the great storms could be tamed and focused. My knowledge grew, and my power grew with it.

In retrospect, it was inevitable that I’d be exposed, for there are to be no secrets in the Faith of the Five, and this was a small temple, in an even smaller village. I’d been practicing a thunderclap incantation, and how I might combine it with an amplifying focuser. Little did I know the resulting shockwave would explode from my chambers, shattering the stained glass in the adjoining sanctuary and echoing across the valley. Reverend Shaeltiel came running, his eyes met mine, and together we came to the same conclusion: it was time for me to choose: either embrace the rules of the faith and rein in my burgeoning abilities, or find my fortunes elsewhere. I chose to go.

That evening I left the temple, and now I quest for further knowledge and how I can bring the power I wield to defend truth and justice, and to show to myself and the templars of the Faith of the Five, that they needn’t fear the ancient elemental forces. They are but tools for a greater purpose, a purpose only the future can reveal.