Good headphones are good

I've had a lot of headphones over the years, but until recently I never really had any good ones.  You know, headphones that cost more than $30.  But now I do, and I have to say it really makes a difference.

It started with Christmas.  Every year my company gives out a cool company Christmas present, customized with the company logo.  Well, this year the gift was a pair of Beats Studio3 wireless headphones.  These are really nice headphones.  I never would have spent that kind of money on headphones for myself, but they might actually be worth it.  They're quite comfortable, have a cord and Bluetooth, have good battery life, charge quicky, and have noise-cancelling.

The only problem with the Beats is that they're not super portable.  I mean, they're fine, but they're full-sized headphones and they block a lot of background noise even with the noise-cancelling turned off.  They're not optimal for things like jogging, or those times when I'm doing chores around the house and want to listen to  a podcast in one ear while I keep the other one free to listen for my kid.

So to that end, I bought a set of Raycon E25 wireless earbuds.  They're not Beats, but they're actually quite nice.  They're comfortable (as earbuds go), sound great, and come with a highly portable case with a built-in battery.  They're perfect for ad hoc listening, such as when washing dishes, or when exercising.  And while Bluetooth can be a pain in the neck at times, I have to say that wireless earbuds and headphones are much more convenient.  You don't realize what a pain it is to always be catching wires on things until there are no wires to catch.

So if you don't have a good set of headphones, and you have the money, I recommend you get one.  It's one of those little things that really does make a much bigger difference than you'd think.

A good take from a doctor

Apropos of my previous post, here is a similar take, this time from an actual doctor specializing in infectious disease.  So it's not just me.

The short version: while COVID-19 is a serious matter, right now he's more concerned about the response to it than the virus itself.  People are losing their composure and doing crazy things, and it just makes the situation worse than it needs to be.

So keep calm.  If you're relatively young and healthy, you'll probably be fine, even of you catch the virus.  Just wash your hands and take reasonable precautions to protect the sick and elderly around you. 

And actually think about what you're doing.  Don't be like the clerk in Home Depot who insisted on standing a foot and a half away from me, or like the woman in Wegmans who was wearing a face mask while carrying around a cup of coffee.  Be sensible.   I know things are stressful right now, but it's not the end of the world - we will get through this.

A nice support package from work

On Friday I got a nice care package from the office.  They sent one out to everybody as a nice reminder of normalcy.  If we can't get to the free snacks, they'll send the free snacks to us!

My care package from the officeThe good people in Datto operations are the best.  They always do a fantastic job of keeping up morale and taking care of everyone.  Thanks, guys!

Hunkering down for the pandemic

This week started "work from home for the foreseeable future."  It's pretty much going to be nothing but sitting around the house and going out in the yard for a while.

This is because, in response to the coronavirus epidemic, pretty much everything is cancelled.  Last Thursday the news announced the first case of COVID-19 in my Monroe County, New York, where I live. That morning my boss advised all his reports to feel free to work from home.  The next day, the CEO sent out a message that we were closing most of our offices and ordering everybody to work from home.  On Saturday the county closed down all the schools.  Over the course of the rest of the week, the state government announced progressively more closures, and yesterday put the state on "pause".  This means pretty much everything is closed, i.e. all businesses deemed non-essential. I'm still not 100% clear what counts as "essential", but it's not much beyond food and medical care.

Fortunately for me and my family, I made good career choices in my youth.  As a professional software developer, working remotely is generally not a challenge for me.  I'm also fortunate to be working for a company that sells BCDR solutions with a subscription model.  Particularly with the increased move to telecommuting, the need for backup solutions is not going to go away, and our subscription services mean that the company will have recurring revenue even if new sales decline.  So not only am I in a profession that is well positioned to weather a crisis like this, I'm working for a company that is not in any immediate danger of going out of business.

Sadly, this is not the case for many people.  My brother, who works for the state unemployment agency, is already preparing for a massive influx of claims as people who aren't able to work from home go on unemployment. Local non-profits have already started sending out solicitations for donations and people on social media are calling for everyone to support local businesses that will be hard-hit by the closures.  I don't know what impact this pandemic will have on economy, either locally or nationally, but it will definitely be bad.

And let's not forget the maniacs who are hording toilet paper and hand sanitizer and generally causing way more problems than they're protecting themselves from.  Or the other maniacs who are convinced that the pandemic is some kind of political conspiracy theory and take pride in flouting even common-sense safety measures.  I don't mean to downplay the seriousness of CONVID-19, but some of the reactions have been completely out of proportion to the threat.  This is not the "insta-death virus", but it's not just a case of the sniffles either.  It needs to be taken very seriously, but it's not a reason to panic.  Panicking always makes any situation worse.

At this point, my only hope is that the response to the virus won't do too much damage to society as a whole.  Yes, it's a serious issue; yes, lots of people will die; yes, the state needs to take decisive action to slow or halt the spread of the virus.  But let us not forget that while the risk of illness is shared by all of us equally, the costs of the response are not.  More of the weight will undoubtedly fall on those least able to carry it.  While people like me will probably be pretty much OK, the status of those affected by business closures an quarantines is far less certain.  So while it's important that we take steps to protect the people who are most in danger from the virus, it's also important to protect the people who are harmed by those steps.  There are no free lunches - everything has a cost and everyone is worthy of consideration.

More Vim-as-IDE pointers

A while back I came upon this article on using Vim as a PHP IDE.  It's got some very good pointers, although the author may have gone a little over the top on trying to mimic the behavior of PHPStorm.  I haven't tried all of those plugins, but quite a few of them are in my Vim config.

If nothing else, the article gives you a good sense for just how powerful Vim is when it comes to extending its behavior.  It's actually pretty impressive.

Cover art for The Pragmatic ProgrammerEarlier this year,  finally read through The Pragmatic Programmer.  It's been sitting on my bookshelf for...at least 15 years now.  I'd read parts of it before, but never went through the whole thing.  Anyway, it contains a section on choosing an editor, and one of the things they stress is extension.  You need to be able to customize your editor to extend its functionality to suit your workflow.  The idea is that the editor is one of your primary tools of code-craft and you need to make it truly yours.  You need to learn to use it well and completely, to make it an extension of your hand.

So far I'm finding Vim to be a pretty good choice in that regard.  Partly this is due to its raw power, but to a large extent it's also due to its age and the ecosystem around it.  Vim is a very old tool and it's very mature and stable.  This is a very good thing, because it means that there are lots of examples and documentation for how to use and customize it.  If you want do do something new with Vim, there's a good change that someone already wrote a plugin to do it.  And if not, there are plenty of plugins out there that you can use as examples. 

Being mature and stable also means that things are unlikely to change out from underneath you.  Sure, new features are still being added, but the basic functionality has been largely unchanged for a while.  This is what you want from a good tool.  If you're going to invest a lot of time and effort to get good at using a tool, you want that investment to retain its value.  You don't want to spend three months every couple of years re-learning because the tool vendor decided to re-architect their product or switch to the latest trendy programming language.

So while Vim may be old and boring, there's something to be said for being old and boring.  When was the last time you saw an old, boring person on The Jerry Springer Show?  Doesn't happen.  New and interesting may be exciting, but there's a reason why telling someone "may you live in interesting times" is supposed to be a curse.

Code sharing, pros and cons

A few months ago, the DropBox blog had an interesting article on code sharing in their mobile apps.  It was a good reminder that developers should be mindful of not fetishizing code re-use.  Like so many things in engineering, re-use is generally good, but still involves trade-offs.

The short-short version of the article is that DropBox originally had the idea to share code between their iOS and Android mobile applications.  After all, why write the same app twice when you can do it once?  Well, it turned out to be a really bad idea.  Because they were doing things for both platforms in a custom, non-standard way, they ended up taking on a lot of extra work just for the sake of re-using the code.  And not just in the amount of extra code they had to write in terms of custom libraries and tools - there's the extra effort of bringing new developers up to speed.  In fact, they eventually realized that it would actually be less work to just write everything twice and ended up abandoning their code-sharing approach.

Of course, this is an extreme case.  Trying to share code between two radically different platforms with different native implementation languages is bound to generate some issues.  A more prosaic example is the left-pad debacle.  You know, the one where a developer removed an 11-line JavaScript "library" from NPM and broke half the internet's deployment scripts.  But in that case, the scale was reversed - instead of trying to share a significant amount of code between a couple of projects, the left-pad package shared a completely trivial amount of code between an absurdly huge number of packages.  But the underlying problem is similar.  By trying to share that 11 lines of JavaScript "the right way", you end up taking on an external dependency that now has to be managed and probably generates more long-term maintenance effort than you saved from not writing the code yourself.  (I mean, seriously, why use a library for something that any half-competent programmer could write in less than 15 minutes?)

On the same theme, I've seen similar problems in client-side JavaScript.  I've worked on a codebase or two where large portions of the front-end were essentially cobbled together out of jQuery plugins that sorta-kinda work together, but not really.  Clearly the intention was to save effort by re-using existing components, but it didn't quite work out.  Sometimes it was because they didn't play well together, other times it was just that one of the components was not very well written.  In a couple of cases, after examining the plugins and the desired behavior, it became apparent that I could just write a version that did work cleanly in an hour or so - less time than it would take to debug the third-party plugin.

Of course, that's not to say that re-using code, whether your own or someone else's, is a bad idea.  It's clearly not.  Sometimes you find yourself writing nearly identical components for multiple projects, in which case it probably makes sense to abstract that into a shared library.  Or maybe there's a third-party library that already does more or less exactly what you need, in which case it probably makes sense to just use it.  That's all fine.

My point is just that "re-use some existing code," like any other idea in engineering, comes with trade-offs.  Sometimes those trade-offs are minor, such as the cost of managing a dependency that buys you a really big chunk of functionality.  Other times, they're pretty major, like the opportunity cost to DropBox of breaking all of the standard platform tooling.  Either way, the important thing is to think about those trade-offs and evaluate them honestly, not just jump to an "easy" answer.