This is a really exciting post for me to write. For the first time in quite a while, I’m writing about something technical! At HubTran, we’ve found supportability to be an incredibly important part of writing software. We have a BackupIntegrationFile model that stores every file we receive and send as part of our third party integrations. This includes flat files, JSON documents and anything else that’s passed back and forth. We’ve found it to be a life saver when troubleshooting issues with our partners. The downside of this model is that it’s huge! We have hundreds of millions of records stored. We had a purge process that would clear out old records, but recently it just stopped working. Figuring out why was a lot of fun!
This week we are saying goodbye to Ally, our amazing customer support rep. While we’re sad to see her go, we’re incredibly excited about her next thing. You see, she’s not leaving us for another tech company or for another support job, she’s leaving us to be a writer for a TV show. How could we be upset about that?
Over the last few years, Michael Niessner and I have spent a lot of time looking at patterns that predict the success and failure of both software products and software engineers. We’ve done this both to improve our success rate at HubTran, but also to help us understand how to hire better software developers. While we’re still working on finding the secret to success and better hiring, we’ve found at least one combination of traits that is a sure sign that failure is around the corner. If we see Assumptions and Confidence, we know we’re looking at trouble.
I’ve been working on our 7 minute demo for the FreightWaves Transparency 19 conference. You might think that as CTO I would focus on the cool technology here at HubTran. While we have great technology like Elm on the front end, I won’t be mentioning it. The technology isn’t what’s important, it’s the value we deliver that matters.
Over the last year, I’ve been doing a lot of interviewing. As in, I have at least 8 interviews scheduled this week already. I’ve easily done more than 100 interviews in the last twelve months. During that time, I’ve learned a lot about interviewing. When I first started, my interviews were mostly rambling conversations. I had a few questions in mind, but I mostly just chatted with people. I did a great job of hiring people I liked to talk to, but my track record in finding high performing candidates was more mixed.
I recently read Getting to Yes, which introduced me to the idea of “principled negotiation.” The entire book is worth the read—negotiation tactics apply more broadly than you might initially think. I’ll give you an example!
Several of us just finished reading Radical Candor. I can say without reservation that it is one of the best management books I’ve read in a long time. At the same time, I’ve never read a book that pointed out my managerial shortcomings so quickly.
We’ve been doing a lot of hiring at HubTran recently. As part of that process, we’ve been looking at how we hire, specifically at how our unconscious biases can shape our first impressions. I was excited to see another company is thinking about this problem:
When was the last time you said “You’re right, I’m wrong?” If you’re like most people, it’s probably been a while. For most of us, those words are hard to say, especially about things that really matter to us. As hard as it is, saying “I’m wrong” can be incredibly powerful.
As we build and grow HubTran, we’ve spent a lot of time thinking about the culture we’re trying to build. I’ve written about the HubTran values before. Obviously these values are part of our culture, but they aren’t the whole story. It’s one thing to talk about what kind of culture you want, it’s another thing to make it real.
I’m excited to be a panelist at Digital Ocean’s TIDE SF: The Power Of Simplicity next week.1 Preparing for the panel gave me an opportunity to organize my thoughts on how we scaled HubTran. In particular, I’m going to focus on server scaling today. I’ll write more about scaling other parts of the organization in the future. Are you in San Francisco? You should come by! It’s free! ↩
In the past, I’ve written about playing soccer and how that has impacted my day to work. Outside of work, I also coach a soccer team of 6 to 8 year olds. This season was my seventh season coaching kids this age, and I feel like I’m starting to see the same pattern over and over.
Over the weekend, I had a great idea for a blog post based on It Doesn’t Have To Be Crazy At Work. I got to the office on Monday morning and wrote it. On Tuesday, I re-wrote it. On Wednesday, I re-wrote it again. On Thursday, I re-wrote it for the third time. Today, I realized it just wasn’t good. I’m a bit bummed about it, but sometimes that happens. In writing and in code, not every idea is a good one. Instead of publishing something I’m not happy with, I threw it away. In it’s place, I’m giving you a picture of my office dogs.
Last week, all of HubTran got together in Chicago for our second annual company summit. We spent three days together talking about what we’ve been up to and where we’re going. It was a great opportunity to get to know each other better. During the summit, a number of podcasts came up in discussion. I loved hearing about what people listen to, and wanted to share our podcast list! I was excited to see the variety of what we listen to. Sure, How I Built This is popular, but I was happy to see a variety of non-technical podcasts as well.
There are only two hard things in Computer Science: cache invalidation and naming things. – Phil Karlton
Hiring is one of the hardest problems in software development. When we hire, we’re trying to determine if a person has not only the technical skills necessary to work at HubTran, but also the interpersonal and communication skills. We need to know if they share our values and are capable of working remotely. At the same time, we need to help them decide if HubTran is the kind of company they want to work for.
This problem frequently appears in #testing on Elm Slack, and I’ve been curious about what a “dependency injection” API might look like. Dependency injection, in general, is quite simple. If you have something that you want to test (or just isolate), then instead of working with that thing directly, pass it as an argument wherever you need it! This repo is an example of what it might look like to use Dependency injection to make Cmds easy to test!
As a person who runs every day, I spend a lot of time listening to podcasts. A few weeks ago I heard Sam Sanders interview Niecy Nash and was struck by a comment that Niecy made:
One of my favorite parts of being the CTO of HubTran is building an amazing team. We try to do that a number of ways. Obviously, we want to hire outstanding developers (I’m email@example.com if you are interested in learning more!) but we also want to help the team improve. One method we’re using is a book club.
Getting support from a software company can be a painful experience. It's not unusual to spend 20 minutes on hold only to talk to somebody who is clearly reading from a script. They have no idea how to use the software they are supporting, let alone how to fix your issue. At HubTran, we want our support staff to be able to solve your problem quickly. That's why we've decided to have our development team provide our customer support.
To get started, we want to share a bit about the software development team at HubTran. In particular, we want to talk about our core values and some practices that support our values.