Tag: Learn And Be Curious

Reap The Whirlwind

Reap The Whirlwind

By | | Comments 0 Comment

This summer my family and I went on a two week European vacation. Six cities in fourteen days is no joke, but we had a blast, saw a ton, and stayed healthy throughout. For something different, I thought I’d catalog our activities here.

Day 1 – Rome

  • Land at Leonardi da Vinci International Airport
  • Taxi ride to the hotel (aggressive driver kept us on our toes)
  • Jetlag recovery nap (essential)
  • Pizza at Taverna Rossini
  • Pico Gelato for dessert (tears of joy were shed)

Day 2 – Rome

  • Trevi Fountain
  • Colosseum
  • Piazza del Campidoglio
  • Pantheon
  • Lunch at La Soffitta Renovatio
  • The Vatican, including the Sistine Chapel and St Peter’s Basilica
  • More gelato at Pico
  • Quick dinner at the hotel before crashing in bed

Day 3 – Rome

  • Temple of Asclepius
  • Walk through Villa Borghese
  • Piazza di Spagna (the Spanish Steps)
  • Trevi Fountain (again)
  • Vicus Caprarius (ruins under Trevi)
  • Life-changing carbonara at Al Simeto (no one spoke English, a good sign)
  • Even more gelato at Pico

Day 4 – Florence

  • Morning train to Florence, and walk to our Airbnb that was right on the square
  • Accademia Gallery to see Michelangelo’s David (breathtaking)
  • Uffizi Gallery (Birth of Venus, amongst other masterpieces)
  • Life-changing chianti at La Buchetta, and the steak was pretty good too
  • Evening walk at the Piazza della Signoria

Day 5 – Florence

  • Climb to the top of the Brunelleschi Dome
  • Tour of the Duomo cathedral
  • Cappelle Medicee
  • Basilica di San Lorenzo
  • Trattoria Sergio Gozzi for lunch with an old friend (and killer truffles)
  • Battistero di San Giovanni
  • Palazzo Strozzi
  • Ponte Vecchio
  • Gelateria Edoardo il gelato biologico (obviously)
  • Quick pizza from a grab and go

Day 6 – Alps

  • Walk to the Florence train station
  • Train through Bologna, Bolzano, Innsbruck
  • Arrived in Munich in the afternoon
  • Dinner at Haxnbauer im Scholastikahaus (pork knuckles FTW!)

Day 7 – Munich

  • Bus ride to Bavaria
  • Neuschwanstein Castle
  • Quick lunch (sausages and beer)
  • Oberammergau
  • Linderhof Castle

Day 8 – Munich

  • Morning run in the Englischer Garten
  • Tour of Dachau (a sobering and essential experience)
  • Shopping in Marienplatz
  • Walkthrough of Peterskirche (including a climb of the tower)
  • Stroll through the Englischer Garten in the rain
  • Dinner at Hofbräuhaus
  • Midnight sleeper train to Paris

Day 9 – Paris

  • Taxi to the hotel to freshen up
  • Walk through Jardin des Plantes
  • Brunch at Clint (poached eggs, yummy)
  • Recovery nap (absolutely essential)
  • Shopping in Le Marais
  • Dinner at Robert et Louise (beef cooked over an open fire plus a Bordeaux)
  • Walk through Place des Vosges and Place de la Bastille
  • Cards in the hotel lobby

Day 10 – Paris

  • Stroll through Montmartre
  • The Basilica of the Sacred Heart of Paris
  • Eglise Saint-Pierre de Montmartre
  • Cheese sampling from a local shop
  • Walk past Moulin Rouge
  • Arc de Triomphe (only a couple quick photos)
  • Eiffel Tower (didn’t go up though)
  • Pont Alexandre III Bridge
  • Eglise de Saint Germain des Pres
  • Macarons from Boutique Pierre Hermé
  • Le Jardin du Luxembourg
  • Panthéon (photo from afar)
  • Cathédrale Notre-Dame (just an outside view)
  • Ile de la Cité
  • Sainte-Chapelle (beautiful stained glass)
  • Lunch at Brasserie Les Deux Palais
  • Quick walk past Musée du Louvre
  • Tried to tour the Catacombs, but alas they were booked out
  • Crepes from Au Beurre Salé
  • Well-earned sleep

Day 11 – London

  • Eurostar through the Chunnel (delightful train and fast!)
  • Tube to Pimlico station
  • Bit of recuperation at the Westminster Hotel
  • Tour of the Churchill War Rooms
  • Dinner at The Admiralty (Trafalgar Square)
  • Walk past Westminster Abbey, Big Ben, and Parliament

Day 12 – London

  • Several hours of exploration at the National History Museum (Dippy!)
  • Nap on the lawn at Hyde Park
  • Princess Diana Memorial Fountain
  • Science Afternoon Tea at The Drawing Rooms
  • Stroll over Westminster Bridge

Day 13 – Oxford

  • Morning train to Oxford
  • Fish and chips at Wig & Pen
  • Photos at The Eagle and Child (sadly closed due to COVID)
  • Shopping on Cornmarket Street
  • The Sheldonian Theatre
  • The Hertford Bridge (most photographed spot in Oxford)
  • Bodleian Library
  • Blackwell’s Bookshop (bought a rare Isaac Asimov book: The Clock We Live On)
  • Radcliffe Camera
  • University Church of St Mary the Virgin
  • The Bear Inn (serving Oxford since 1242)
  • Christ Church College
  • Merton College
  • Martyrs’ Cross

Day 14 – Journeying

  • Sleep in late
  • Depart Heathrow in the early afternoon
  • And land in San Diego in the late afternoon (hooray for timezones)

And there you have it. Not a bad way to spend a fortnight.

Crossing The Rubicon

Crossing The Rubicon

By | | Comments 0 Comment

There are a plethora of resources for those just getting started with software development, and best I can tell, most of them will do the job adequately well. But there isn’t nearly as much on what is needed next: guidance on how to get from “early intermediate coder” to “seasoned software engineer”. In brief, here are some suggestions:

  1. Study existing high-quality code; if you don’t know what good looks like, it’s nearly impossible to produce it.
  2. Write a lot of code. There’s no substitute for practice and putting in your time.
  3. Find someone who can give you feedback on the code you write, and humbly iterate per the guidance.

In my experience, an efficient way to do all three is to find a couple open source projects that need support, dig into their code, and submit contributions. You start from a base of quality code, get to write more, and you’ll get feedback through pull requests. And the icing on the cake is that it’s all done in public.

Spend a few years of doing the above and you’ll be well on your way to next-level programming expertise. It’ll also teach you how to code with a distributed and decentralized community of stakeholders, and that’s no small thing.

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.