DEV Community: Derek Hammer

A Remote Work Office

Derek Hammer — Fri, 15 May 2020 17:56:55 +0000

Due to a pandemic, we are all now remote workers, and when we can return to our offices for work is still unknown. For some, the opportunity to do work remotely has inspired them to continue to pursue that after work can return to offices. And, as I interview with companies across the industry, more and more of them are looking at the numbers and getting over their fear of remote work.

Working remotely is a skill on its own. There's a lot to dig into there, but I wanted to talk about something a little more light and fun. For the past 2+ years I've been working remote and have really enjoyed making my space super functional for me. So, here is me just breaking down my office.

So, this is the overview of my office. You'll see a few key things here. First, I have a standing desk. Very key. Mine came from Uplift, but the truth is that most direct to consumer standing desk companies get all of their components from the same factory in China, and so the quality is going to be pretty much the same (you can even order the components from Alibaba if you're brave enough to try and make your own). I went with Uplift based on recommendations and because I liked some of the styling.

My standing desk looks out the window, too. This is key for me.. I like the outdoors and the sun. I have a trail behind my house that as I am typing this a kid on his bike is riding up and down it. It's a great little background that beats any kind of desktop background image!

Let's talk peripherals. Probably the most hotly contested topic in desk setups. I use a custom built Iris keyboard that's ultra quiet and has a nice split ergonomic form factor. This helps me with my posture, which I'm generally concerned about. This isn't a necessary component for a good office setup. Before I was using a relatively cheap, premade mechanical keyboard that wasn't in an ergonomic form fact. It worked great.

I use a magic trackpad on my development machine because I am mostly using hotkeys all day. I'm a vim user, and so my development is 100% keyboard based. Movement around the operating system is mostly keyboard based, and when I do need to use the mouse the nice thing about the trackpad is its small footprint.

The other key peripheral is my pen and notebook. I always have a notebook on my desk (even the PC desk has a separate notebook). I use a fancy fountain pen (not expensive, just makes me feel fancy). But, I love taking handwritten notes. It helps me stay engaged and keeps my mind active during even the most rote of meetings.

This is a super cheap monitor that had a decent refresh rate and a mounting bracket on the back. It floats, so it takes very little space on my desk, and it sits quite high for, you guessed it, posture reasons. The camera is a logitech 1080p thingamajig. It works; definitely recommend getting a logitech cam and just forgetting that camera problems were ever a thing.

Last thing on my standing desk is my tablet. It's relatively cheap and I got it to play around with doing some 3D modeling and 2D graphic design. It's attached to my PC, actually, and not the Mac, mostly because I don't use it for work. If I want to draw something for work, I have an iPad around the house that I'll sit on the couch and draw using that, but it doesn't seem to happen too often. The reason the tablet is on the standing desk is that its just more comfortable for me to draw standing up.

Okay, the PC desk. I mostly use this for recreation. I draw, model, play video games, talk to friends, browse reddit, etc. on my PC. It's nice having a separate machine to do that stuff on because it helps make clear delineations between "work mode" and "chill mode" when you're in front of a computer screen.

The peripherals here are all steel series. A friend of mine works there and it influenced me to go all in on trying their stuff. It all works great. And, you can see that there is a notepad on that desk, too! Love notepads.

This was just a fun little post to write about my setup. It isn't super complicated but it is super comfortable for me. And, honestly, that's one of the great things about working from home. You can build it to fit just your needs exactly how you want it and leave it at that.

Deploy on Fridays

Derek Hammer — Sat, 05 Oct 2019 17:35:44 +0000

Developers should aim to deploy on Fridays. Not as some Platonic ideal that only big companies (or small companies) can reach, but as an active project that the team embraces until it is reality. This post aims to outline WHY and HOW, and at the end there will be a bit of a discussion about call outs vs shaming.

Deploying on Fridays is a touchstone practice for displaying confidence, flow, reactivity, and maturity of your team and processes. Not being able to deploy on Friday means a deficiency in one of these areas, and each of them are things that measure the effectiveness of teams no matter the size of the company that they belong to.

Confidence

Confidence to deploy is NOT confidence that your code has no bugs. It is confidence that the systems that transport new versions of the code into production are safe AND that if the code does have bugs the team has sufficient mechanisms to deal with that eventuality.

For deployment mechanisms, this should be a well oiled machine that you regularly run and maintain. For lots of reasons we won't get into here, a shaky deployment system is problematic for your team, but in this case it means that whenever you want to put code into production you are always questioning if the code or the deployment is the real problem. Instead, if the confidence that the deployment system is high, the culprit becomes pretty immediately clear.

Dealing with bugs in code is where things become nuanced here. Up until this point, I've stated things as a broad stroke that apply to all teams, and I do believe that. However, different teams are going to require different levels of response to bugs to maintain confidence. If you are a critical, 24/7 system that has millions of customers, the processes to deal with a bug are going to be different than the startup with no customers in production. That's okay. The key here is that you have two things:

The ability to recognize when something is wrong. This might be a manual QA process (very costly), an automated verification suite, strong observability into system performance, automated bug reporting, etc. If you are looking for a place to start here, I would strongly encourage looking at a tool like Honeycomb.io that give you world-class observability regardless of your size.
The ability to do something about it. This could be configuration to enable/disable the feature, this could be rollbacks (manual or automated), this could be dark releasing features in the first place, this could be having graduated rollouts of features that you can turn off, or it could be a policy of "live with it until Monday".

How you solve the two things is up to your team and situation and so confidence isn't about what tools you use or process you have to deal with things, it is about being confident that you can regularly put new features into production without being scared of the consequences of pushing that deployment button.

Flow

For these next three, all of them are super important but could be whole topics of research themselves. I will touch briefly on them, why I think they are important, and why deploying on Fridays is a positive indicator for them.

Flow is the cadence of production that individuals or teams output. A good flow would be a regular, sustainable delivery of features/bugfixes/upgrades/etc. at an even distribution. The reason that this is good is that when flow is disrupted, you will always incur startup cost. One way to think about it is this:

Good flow is starting your computer in the morning and being able to write code continuously until the end of the day, doing shutdown procedures, and starting anew the next day.
Bad flow would be the computer requiring a restart every 30 minutes, forcing you to restart your servers, text editors, load context into the computer, etc.
Great flow would be #1 but without the shutdown/startup procedures.. which is why most people just suspend their laptops instead of shutting them down.

If you were to put a block on deployments on Friday, this is creating a period of time where productivity intentionally drops and flow is disrupted. It creates an unevenness in the output of the team, where you will start to see things like Thursday and Wednesday people are starting to try to stack changes. This lopsidedness creates further disruptions in the flow of the team, where maybe Thursdays and Mondays become heavier deploy days that the team is dealing with batched deployments because of the desire to get work done around the Friday flow disruption.

Friday deployments don't fix all flow problems (not by a long shot), but the absence of them can be a big disrupter to a team and, thus, are an indicator of how well the team is operating.

Reactivity

Sometimes you'll see technologists talk about "MTTF" and "MTTR" and "reactivity" is what they are talking about. MTTF stands for Mean Time to Failure. Specifically, this means once I discover a bug in production, what is the period of time I expect there to be until I discover the new bug. This has been a metric used to espouse the benefits of QA, testing, pre-prod environments, etc. MTTR stands for Mean Time to Recovery. That is once we discover a bug, how long should I expect until that bug is fixed. MTTR is a metric used to talk about systemic recovery mechanisms like rollbacks, roll forwards, and overall process efficiency.

There is a natural, but very wrong, correlation to draw between MTTF and # of Deployments. The thinking is that the more you deploy, the more change you introduce into the system, and thus the more issues that you'll have. The opposite turns out to be true. First, we must understand that reducing the # of Deployments doesn't actually introduce less change to the system. The units of change to software are commits, not deployments, and thus the number of changes in a system with 10 deployments of 1 commit versus a system with 1 deployment of 10 commits are the same. How we get to the reverse of the natural correlation is that by analyzing system dynamics, we've noticed that small commits done often result in less bugs and a better MTTR. There are lots of reasons for this, but one of the easiest to understand is that it's a lot easier to grok/validate that the deployment of a single CSS change than to do the same when its 3 CSS changes, a permissions change, a database migration, and a new API endpoint.

MTTF is still a good metric, but it should be used in conjunction with MTTR as a way to look at the health of the system. When you are more responsive to your system (as measured through MTTR), you systems get healthier.

Some people that advocate for not deploying on Fridays will talk about having bugs pop up less often, or the impact that it will have on their weekends. Both of these are sympathetic viewpoints, but the data shows that if you focus on MTTR instead of MTTF, you can get make Friday deploys a non event that will not have an impact on your weekends any more than a No Friday Deploys policy. This step seems big to some people, but is easier than it seems at first. Quick deployments and rollbacks fix most of MTTR and are fairly low cost.

Maturity

This is a loaded word, but this refers to team maturity in the "X Maturity Model" sense. Specifically, the maturity I'm looking for here is the team's recognition that software isn't done until it is in production and that developers should be shepherding the commits they make all the way to users (and, honestly, beyond, but that's a different topic). The internalizing that changes you make aren't thrown over a wall or left for someone else to deploy at some point in the future indicates a team that is moving in the right direction.

Ownership at the individual developer level all the way to production is the healthiest ownership model I've come across, and is only enabled by developers being able to push their code into production any time after the developer believes it is ready. Forcing changes to be queued breaks that culture. I've seen this first hand with very good teams / developers that once a "deploy train" was introduced, this sense of ownership degraded over time. Before we turned it around, the developers were asking to hire a specific person to do just deployments just to deal with the fallout of such trains.

Call outs versus shaming

Finally, the thing that prompted me to write this was a discussion on Twitter that's been happening over the course of several months now. There are a group of individuals that bask in the "virtue" of not deploying on Fridays. They spout this belief far and wide and seem to be a bit immune to changing their mind on the topic.

I think it is fair to call these individuals out. To describe their actions as unhealthy for the developer community and to advocate for people to abandon this approach to software development.

For other people, their reality is that they do not deploy on Friday. That doesn't mean they are bad people. It doesn't mean that we should shame them. For many people, they are doing what they think is best. That's okay, I'm happy to discuss with anyone approaches and paths forward to getting into a better place. Others know they are in a bad place and are actively working to get to a better place. Awesome! Heroes. All of you.

Conclusion

Deploy on Fridays.

Self documenting code [a rant]

Derek Hammer — Mon, 03 Jun 2019 16:20:27 +0000

I am going to start off with an example. This particular interaction is one that I've had in multiple situations throughout my career. When talking about comments, well-factored code, clean code, or anything along similar lines, there can be someone who make the argument

Self documenting code is a myth. Developers that argue for self documenting code are just lazy and don't want to do the work necessary to keep code maintainable.

This comment is the source of my rant.

Commentless?

The absence of comments is not the defining characteristic of self-documenting code. Instead, self-documenting code is one that eliminates otherwise necessary comments with clean, straightforward source material. This has a number of benefits:

It reduces the total lines of code (with comments).
It reduces the diaspora of knowledge spread over multiple lines when one line would do.
It reduces the memory overhead of the reader.
It reduces the chance of a comment and code disagreeing with each other due to bit rot.

All of these add up to better understanding of the code, meaning faster and better changes over time.

Ugly, undocumented code

For an illustrative example, let's put some code down that I might have written in college.

class Animal {
  public int kills(bool pred) {
    int r = 0;
    for(int i = 0; i < k.size(); i++) {
      if(new Boolean(k[i][0].get('kill')) && (!pred || k[i][0].get('type') == 0) {
        r += 1;
      }
    }
    return r;
  }
}

This ugly, undocumented code could, for sure, be improved through some comments. Let's add them.

class Animal {
  // gets the number of other animal kills
  // 
  // Boolean pred if true, return only predator kills
  public int kills(Boolean pred) {
    // k is the instance variable for all kills, plants and animals
    // the resulting number of kills
    int r = 0;
    for(int i = 0; i < k.size(); i++) {
      if(
       // is this interaction an animal kill?
       new Boolean(k[i][0].get('kill')) && 
       // are we not search for just predator kills?
       // or is this an animal kill type?
       (!pred || k[i][0].get('type') == 0)
      ) {
        r += 1;
      }
    }
    return r;
  }
}

I think it would be hard to argue that, in this case, the comments aren't necessary (assuming no changes to code). In fact, I will often do exactly this style of commenting if I'm looking at a hairball of code that I do not understand, encoding my understanding into the code as we go along.

The big tools

Creating self-documenting code has many layers, but you could cover about 95% of changes with just two tools: Rename Variable/Method and Extract Method. Let's apply each of those here, leaving the comments in. For this exercise, I'm going to add a /* Refactoring: Comment */ to explain what I did.

class Animal {
  // gets the number of other animal kills
  // 
  // Boolean pred if true, return only predator kills
  /* Rename: kills -> getAnimalKills for convention following and clarity */
  /* Rename: pred -> onlyIncludePredatorKills for clarity */
  public int getAnimalKills(Boolean onlyIncludePredatorKills) {
    // k is the instance variable for all kills, plants and animals
    /* Rename: k -> allPlantAndAnimalKills for clarity */
    // the resulting number of kills
    /* Rename: r -> result for clarity */
    int result = 0;
    for(int i = 0; i < allPlantAndAnimalKills.size(); i++) {
      if(
       // is this interaction an animal kill?
       /* Extract Method: isAnimalKillAt(i) for clarity */
       isAnimalKillAt(i) &&
       // are we not search for just predator kills?
       // or is this an animal kill type?
       /* Extract Method: isPredatorKillAt(i) for clarity */
       (!onlyIncludePredatorKills || isPredatorKillAt(i))
      ) {
        result += 1;
      }
    }
    return result;
  }

  private Boolean isAnimalKillAt(int index) {
    return new Boolean(allPlantAndAnimalKills[index][0].get('kill'));
  }

  private Boolean isPredatorKillAt(int index) {
    return allPlantAndAnimalKills[index][0].get('type') == 0;
  }
}

And, now let's remove all of the comments, just to see how it goes.

class Animal {
  public int getAnimalKills(Boolean onlyIncludePredatorKills) {
    int result = 0;
    for(int i = 0; i < allPlantAndAnimalKills.size(); i++) {
      if(isAnimalKillAt(i) && (!onlyIncludePredatorKills || isPredatorKillAt(i))) {
        result += 1;
      }
    }
    return result;
  }

  private Boolean isAnimalKillAt(int index) {
    return new Boolean(allPlantAndAnimalKills[index][0].get('kill'));
  }

  private Boolean isPredatorKillAt(int index) {
    return allPlantAndAnimalKills[index][0].get('type') == 0;
  }
}

Here, we have a method that is now "self documenting." However, this code is not necessarily clean. Questions I would continue to ask:

Why is there a magic number of 0 in the allPlantAndAnimalKills data structure?
Why is type an integer?
Why does kill == true mean that it is an animal kill?

These questions could potentially be fixed through further refactoring. For example, maybe we just rename the 'kill' key to 'animalKill'. But, others may be too costly to fix right now or there may be a complicated reason why they need to be that way. The answer to these questions is where comments are useful.

Comments are to explain why

We use comments to explain why something is out of the ordinary. Or something that is very complicated. These explanatory comments should be answering the question: Why is the code made in this particular way? There can be some helpful "what is this?" text. But, to me, the why is way more important. Let's use our example one last time.

class Animal {
  /*
   * This data structure represents kills within the ecosystem
   * that belong to this animal.
   *
   * [
   *   // kills array
   *   [
   *     { 'kill' => 0, 'type' => 0, 'x' => 0, 'y' => 0 },
   *   ],
   *   // metadata array
   *   [
   *     { 'killsInDesert' => 0, 'killsInSea' => 0 }
   *   ]
   * ]
   *
   * This is a very complicated data structure that undergirds
   * our entire system. We've extracted most of the data out of
   * this into better typed data structures, but we have not yet
   * eliminated this for all use cases.
   *
   */
  private List<List<HashMap<String, Integer>>> allPlantAndAnimalKills;

}

Here, the comment is doing something that the code is not. It is describing the motivation of the author/editor of the code. They want this complicated data structure to go away, but haven't been able to push it over the edge just yet. This could be the catalyst that a new developer touching the code for the first time needs to invest in just getting rid of the whole bad data structure in favor of something that is better.

Note that there is also a what. This what is valuable in this case because of the type system abuse. In theory, you could make all of that information be encoded into some kind of psuedo type system that operates just on this data structure. I won't get into too much detail here, but just to say that it is possible to get rid of the what even in this very complicated case. But, no code is ever going to be able to catch the Why?