Tag: Frugality

No Silver Bullets

No Silver Bullets

I thoroughly enjoyed the advice given in Scaling with common sense, probably because I’ve violated each of those principles at various times in my career, and are (hopefully) wiser for doing so.

But the real gem was a link to the following sketch:

I’ve been in that meeting, both as the speaker, and as the listener. Whenever I hear someone say “just move to microservices” like it’s some kind of magic spell that instantly fixes all problems, I want to go full-on Andy Bernard and punch a hole in the wall.

The Dark Side Of Reuse

The Dark Side Of Reuse

Every branch that bears fruit, he prunes it so that it may bear more fruit.
– John 15:2

Deleting code feels so good, especially when it’s code I’ve written. It’s an emotion predicted by the Creator’s Curse, and it also make sense under the lens of this article, which challenges developers to write code that’s “easy to delete”.

Too often, especially in academic settings, or with inexperienced engineers who don’t have the experience of the dirty hacks required to keep an actual real-life system running, there’s a view that good software engineering practices are like the Ten Commandments, never to be violated. But for every rule, there’s any number of exceptions, and I loved the way the author laid out these tensions.

OOPs I Did It Again

OOPs I Did It Again

Have you ever looked at a heavily object-oriented codebase (Java, I’m looking at you) and immediately felt dumber? Did the design patterns touted as the ultimate in software craftsmanship sound amazing when you studied them in school, but now every time you see them in real projects they result in layer upon layer of confusion?

You are not alone.

There is no one approach to rule them all when it comes to software development, and while I wouldn’t be quite as hard on object-oriented programming as the articles linked above (yes, there are multiple ones), it’s not the only, best, or even appropriate pattern to use in all circumstances.

Truth And Consequences

Truth And Consequences

Yesterday I was in an all day meeting preparing for a large customer demonstration. Ran into a bug that turned out to be a misunderstanding of how JavaScript handles truthiness. Consider the following code:

if (person.address) {
  console.log('Address is ' + person.address);
}
else {
  console.log('No address.');
}

Seems clean enough right? Not so fast. If person.address is null, no problem. However, if person.address is an empty object, that evaluates to true, and the code fails to do the right thing. To me at least, this is non-intuitive behavior.

I started this blog with a discussion of why I love Python, and once again it behaves more intuitively. Empty dictionary, empty list, None, and empty string all evaluate to False. So the code works in a broader-variety of cases:

if person['address']:
    logging.info('Address is ' + person['address'])
else:
    logging.info('No address.')

Isn’t that nice and clean?

As an aside, most developers have become so accustomed to bracketing punctuation (e.g. braces, semicolons) that they assume there’s no other way. Personally I’ve come to love the lack of noise in Python syntax, and I think you will too.

Duplicity

Duplicity

The problem I described in my last post is relevant to more than just useless code comments. Check out these helpful and totally not redundant download instructions I found on a website today:

I sure am glad the extra text is there to clear up any confusion on which version I needed.

Diligence Is For Lazy People

Diligence Is For Lazy People

I wrote yesterday’s post almost a full day in advance, which hadn’t happened before in the (admittedly short) history of this blog. It felt really nice when my daily 9am writing reminder went off to simply click “Publish” and get on with my day, instead of hitting snooze and hoping I get back to it later.

It brought to mind my sophomore year of college, where I learned the value of discipline. My fiancée was at a school ten hours away, and I had a randomly assigned roommate with whom I had nothing in common (and despite his pedestrian physical appearance managed to have three simultaneous girlfriends for most the year, but that’s a different story). I also had a class schedule that finished by 2pm every day.

Since I had little reason to get back to my lonely little dorm room so early in the day, I got in the habit of hanging out in the library studying until dinner. I quickly discovered that this routine completely freed my evenings and weekends of schoolwork. And that was awesome. I wasted gobs of time playing video games during those hours, and didn’t feel the slightest bit bad about it, because my work was done.

It’s Elementary

It’s Elementary

There are really only two tasks a company must perform:

  • Make great products
  • Sell them for a profit

Each employee, no matter her job title or role, must contribute in some way to one or both of those two goals. Any other task is only a means to one of these ends; everyone involved does well to remember that.

And yes, I realize strictly speaking products and services are two different things, but for the sake of pith can we consider the latter a type of the former? Thanks.

Z Is The Most Important Letter

Z Is The Most Important Letter

(I’ve been asleep at the wheel for far too long here, time to dive back in with a truckload of mixed metaphors).

Do you get enough sleep? Americans are chronically sleep-deprived, and a body of research is growing that tells us how damaging a lack of rest is to every other area of life (see, for example, this fantastic article). The particularly troublesome aspect is how sneaky the damage can be, manifesting itself in subtle ways over time.

A large part of being a professional software developer is taking care of your meatspace hardware. And that means getting regular sleep. The image of the late-night coding warrior who bangs away at the keyboard until the wee hours of the morning may play well on TV, but it’s false. The most effective engineer is one who rests.

Slimming Down

Slimming Down

Yesterday I migrated a bunch of microservices from the baseline Node 6 Docker image to an Alpine Linux version that I custom-built to be as small as possible. Average image size went from 800MB to 80MB across the 6 services, for a total savings of over 4GB per deployment.

Not a bad way to spend a day.