Programming – Page 2 – Walking Contradiction

Day 45: Composing Music and Code

I am not a musician. Yeah, I was a vocalist in a couple of bands in high school and college, but all I really did is copy the original song. The notion of coming up with a new approach to a song was way beyond my imagination.

I am amazed by people who can write their own original songs. How can you create a melody from… nothing? It really is beyond my ability to comprehend. Lyrics seem straightforward enough, but the music?

A few years ago at a conference I was hanging around in the evening with some friends, several of whom were musicians that had brought their guitars. One of them played a song, and I asked him where the song was from. He replied that it was one of his own. “Wait: you wrote that yourself?” That surprised the hell out of me!

Now that my curiosity was piqued, I couldn’t help but ask him how he does it. He replied that sometimes he has some little bits of music in his head, just a couple of notes. When he’s practicing his guitar, he’d just sit around playing some small riffs; just a few notes here and there. He’ll play one, then change it up a little bit, and if it sounds better, he’ll start working with that. Over time he’ll have a few more such bits floating around in his head, and every now and then he’ll play a few that just start to flow together. At that moment he can hear the overall melody, and he has to write it down, or record it – anything to capture it before it fades. It doesn’t matter what time of day it is, or what else is happening; he can’t do anything else until he has it down on paper/tape/whatever.

Now I understood: his process for composing music was very similar to what I experience when coming up with a coding design to a given problem. I’ll play around in my mind with a few approaches I’ve used in the past, changing them around as needed to see if that would work. At some point, though, the pieces seem to align themselves into the solution I need, and I can see it clearly in my mind. At that point, I have to write down what I’m seeing before I lose it. I can remember times when I missed appointments because I was heads-down writing such a solution.

The act of creation is remarkably similar for both cases: playing around with ideas/riffs, and once the solution “appears”, a furious effort to record it. And it’s that “playing around” part that is really hard to explain to others: to them, it just looks like you’re screwing around instead of working.

I do my best thinking when I’m walking, not when I’m planted in front of a keyboard. If you’re ever stuck trying to come up with a solution, try changing what you’re doing. Go for a walk, work on your garden, vacuum the floor – anything to move away from the computer and get your body moving. That act alone helps free the brain to make connections that it might otherwise never make.

Day 44: Employed Once More!

After 3 1/2 months of unemployment, during which I submitted countless job applications, became a regular on LinkedIn, learned the routines of the Texas Unemployment Benefits system, and sat through numerous interviews, I’m excited to report that I have a new job!

In a couple of weeks I will be starting at Nvidia as a Senior Python Developer, working on the tools for their GPU cloud. I’ve met the other people on my team during the video interview process, and they all seem like a bright bunch, so I can’t wait to start working with them!

It’s been difficult these last few months. It started with the pandemic and subsequent lockdown, which has affected everyone. Then came the layoff, with DataRobot letting 25% of its workforce go, including yours truly. It really wasn’t much consolation that I was only 1 of the 40 million or so in the US who lost their job in those few weeks – it still hurt.

Still, I have had it better than most. My wife still had her job, which was super-important financially. We also had some savings, so we weren’t living paycheck-to-paycheck like so many Americans have to. And it did give me some free time to work on my photoviewer software, and practice my newly-discovered sport of disc golf. It also gave me the chance to perfect my sourdough bread technique (yeah, I know – how cliché!). But there is only so much to do when largely confined to the house.

Which is why I started this daily writing exercise. Not just to fill the time, but to get down some of the thoughts that have been in my head for a while, and polish my rusty writing skills. And while it’s been difficult to always find something to write about, I have noticed that writing itself is feeling more fluid.

I will continue this daily project until I start the job on July 20. After that, I will continue to write, but just not on a daily basis. Going through this exercise has helped me enjoy writing more, and improved my ability to let a piece out into the wild without first obsessing with endless editing. That is probably the best thing I’ve gotten out of it.

Day 35: Chopped Candidate

Have you ever watched the TV show Chopped? If you haven’t, it’s a competition among 4 chefs. There are 3 rounds, and after each round, one of them is chopped (eliminated), until one remains. The winner gets a cash prize. This would seem like a good way to determine who is the best of the group, right?

The problem is how the competition is run: each round the chefs are given a basket of “mystery” ingredients that they can’t see until the round begins. And more often than not, the basket contains, shall we say, “odd” combinations. One such basket contained blood orange syrup, the African spice blend ras el hanout, hot cross buns, and lamb testicles. The chefs can add other staple ingredients, but those four flavors have to be featured prominently in the result.

And if that isn’t difficult enough, there is a time limit that is always ridiculously short. The chefs had 20 minutes to create an appetizer from the basket I described above: 20 minutes to create a recipe, determine what other ingredients to add, prepare and cook the food, and then plate it for a beautiful presentation.

I must confess that I find the show very entertaining, and have watched countless episodes. And I’m not alone: the show has been running for 44 seasons over the past 11 years. But let me ask you: if you were opening a restaurant, would this be the way you would select your head chef? I would hope not! Any restaurant that would spring surprises on their chefs and expect them to deliver first-rate food in impossibly short time limits wouldn’t last very long.

Which brings me to the point of all this: if you are interviewing for a programmer, do your interviews actually determine how well they would be able to work in your team? How positive their contribution will be?

Making a candidate live code a solution to a problem they’ve never seen before in a short period of time with people watching their every keystroke is the software development equivalent to being on Chopped. I certainly hope that your work environment isn’t anything like that. So why would you think that a live coding session in an interview tells you anything about their potential?

What artificial scenarios like Chopped or live coding interviews do is test a candidate’s ability to handle stress. Personally, I’ve never had a problem with live coding, but then again I’ve never had test anxiety in school, either. I’ve seen many talented developers choke under those circumstances, but that doesn’t mean that I wouldn’t want to have them on my team.

What does it say about your company as a place to work if the bar they have to clear is how well they can handle high levels of stress?

When I first started interviewing candidates when I was at Rackspace, the standard was to have one interviewer do a live coding challenge, and another ask one of those bizarre, abstract brainteasers (“Walk us through your thoughts…”). Once again, these practices just show how nervous someone is in what is already an inherently stressful situation. That link includes a juicy quote:

These types of questions are likely to frustrate some interviewees so watch out for those who aren’t willing to play the game. It’s an interview after all and you make the rules.
Mark Wilkinson, head of recruitment, Coburg Banks

It’s all a game to him, and if asking questions with no right answers eliminates potentially good candidates, tough. It sounds like he is more interested in seeing who can tolerate being bullied than finding the best people for his company.

After sitting through some of these types of interviews at Rackspace, I campaigned internally to change these practices, because I saw some intelligent and capable candidates get flustered and end up looking dumb. I found that there are better ways to determine if someone is a good addition to your team. Perhaps I’ll elaborate more about these in a future post…

Day 33: Discipline

Recently an online discussion about film vs. digital photography got me thinking. I absolutely love digital photography, and would never consider going back to film. Sure, it’s really tough to match the richness of color of Kodachrome 64, or the detail and subtle gradation of 4×5 black and white film, but to me, those are not the most important things when creating art. Those considerations are more like a measure of craftmanship than critical elements for conveying an idea.

However, I am so grateful that I grew up in the age of film photography because of the discipline it instilled in me. Every time you pressed the shutter button, you were spending money. Period. Contrast that to today, where images cost nothing: take a bunch of bad shots, who cares? Click the little trash can icon, and they’re gone. Doesn’t cost a cent.

If you were a poor, struggling student, as I was at the time, buying film was a good chunk of what was left of your money after paying for rent, food, and other essentials. So if I saw something interesting to photograph, I didn’t fire away, taking several exposures from a few different angles in the hope that one would be what I needed. Instead, I composed the image in the viewfinder, looking at it from various angles, and through this process learned to recognize what was important for the final image. Most of the time I walked away without taking the shot, because on further reflection, it didn’t seem worth it.

What if I had had lots of money to spend? I believe that I would not have developed the visual discipline that I have today, as there would never have been a need to limit what I shot. Without that discipline, I don’t believe that I would have become as good a photographer. Even today, with all my digital equipment, I still shoot as though every exposure means something.

In general, scarcity forces one to become disciplined. For example, when you grow up in an environment where food is in short supply, you learn not to waste anything, and to only eat enough to keep going. Back in the early days of computing, when both disk storage and RAM were expensive, you coded in a way to ensure that your program would fit into memory, and would require as little space as possible when written to disk. That parsimonious approach resulted in the “640K Ought to be Enough for Anyone” quote that Bill Gates never said, but keeps getting repeated anyway.

There’s something to be said for learning how to get through tough times. It’s a delicate balance, though – too much scarcity can damage you physically and/or psychologically. My mom grew up as one of six kids in a family during the Great Depression, and it definitely left its mark on her. She wasn’t a full-blown hoarder, but she definitely had a hard time throwing things away – “you never know when you might need it!” was her refrain. And we were not allowed to be fussy about the food we were served at mealtimes: you had to eat every bit on your plate before you could leave the table. That experience has had an effect on me, as I really hate to throw food out. Maybe it’s my mom’s voice still echoing in my mind.

Day 31: Using etcd As a Mediator

etcd is a database originally developed by CoreOS, and is most famously used as the database at the heart of Kubernetes. It is a distributed key-value store, which in itself is not all that remarkable. The thing about etcd that makes it so attractive is the ability to watch a key for changes.

Other key/value stores, such as Redis, have implemented a similar feature, and may work just as well for you. I’ve been using etcd for years, and it’s worked well for me, so I’ve never had a reason to try these other tools.

For most data stores, the only way to find if a particular value has changed is to poll. You issue a query for that value on a regular basis, and compare it to the last value returned to see if it has changed. This is terribly inefficient, especially with values that don’t change often. It’s also inexact with respect time, because your system’s reaction to a changed value depends on the interval between polls. Longer intervals, while less chatty, mean that more time will elapse between when the value changes, and when your application responds to that change.

Enter etcd. Instead of polling an etcd server for changes, you can watch for changes. This is essentially a pubsub system that requires almost no configuration to work. When a key is written to etcd, if there are any watchers for that key, a message is sent to them with the new value.

This is kind of dry in theory, so let’s look at a real-world application using this system: my photoviewer and photoserver applications. These applications allow me to display photographs on monitors that can be anywhere with an internet connection, and control each of those displays from a central server. They represent the ultimate convergence of my work as an artist and my love of programming.

Each display consists of a monitor (actually a TV, but all I want is an HDMI input) and a Raspberry Pi that runs the photoviewer application. Each display has a unique ID to identify it, and when a display starts up, it registers itself with the server. The server contains the settings for that display, such as the list of photos to display, and how often to change the displayed photo.

I have one such display in the kitchen of my home, and like to change the photos displayed on it from time to time. To do that, I go into my photoserver app and change the album for that display. Almost instantly the image on the display changes. How did that happen? The server is a virtual machine running in the Digital Ocean cloud, not local to the kitchen display.

The reason this works is that I’m also running an etcd server on another cloud instance. When I change any setting for a display, the photoserver app writes a new value for that display’s key. The key consists of the unique ID of the display plus the type of value being changed. For example, if I change the photos I want displayed for a display with the ID of 65febdde-3e8a-4c76-ab8f-d8a653e466c7, the server would write a value of a list of the names of those images to the key /551a441f-8aba-44b5-b70b-349af0be5b67:images.

That application uses the etcd3 library to watch my etcd server for changes to any key beginning with /<unique ID>. The watch() method is called with a callback method, and when a new key is written beginning with that display’s prefix, the value is sent to the callback.

The callback method sees that the full key ends with :images, so it passes the value (the list of image names) to the photo display method, which then retrieves the image and displays it. This happens in real time, without any polling of the server needed.

The original version of these apps used the traditional polling method, which seemed wasteful, considering that it was typically weeks between any changes being made. Switching to an etcd watch makes much more sense from a design perspective, and it greatly simplified the code.

Look for cases in your applications where a response is needed to a change in data. Using etcd as a mediator might be a good approach.