Tag: Learn And Be Curious

Sharing Is Caring

Sharing Is Caring

By | | Comments 0 Comment

Last week I recorded a Q&A video session with a colleague for an upcoming team all-hands meeting. Ostensibly we were there to speak on the benefits of a recently-deployed internal tool that’s become quite popular. But the value comes not from the tool itself, but from those whom it empowers to easily share their work.

https://stackoverflow.blog/2020/05/14/the-most-successful-developers-share-more-than-they-take/

Maybe it’s just the self-reflection inherent to middle age (I turned 43 a month ago), or the heartfelt email my team received this weekend from a recent customer, but in some small way I hope that when I’ve gone I’ll have contributed my portion to the ongoing corpus of human knowledge, and further, that I was able to utilize said knowledge for the greater good. The only way for that to happen is to maximally share what I build whenever possible, whether through open source code repositories, high-quality documentation, or even this blog (modest though it may be). It takes extra work, but the work is worth it.

Doomed To Repeat It

Doomed To Repeat It

By | | Comments 0 Comment

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

By | | Comments 0 Comment

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

By | | Comments 0 Comment

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

By | | Comments 0 Comment

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

By | | Comments 0 Comment

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

By | | Comments 1 comment

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?

By | | Comments 1 comment

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

By | | Comments 0 Comment

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

By | | Comments 0 Comment

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!