Engineering
Towards More Effective Communication
In the last few weeks, I’ve received several emails from co-workers that were well over a page long. As soon as I see that wall of text, I’m instantly filled with dread. After reading each message, I was left with a sense of confusion. What was I supposed to take from that? Is there something I am expected to do now?
Faster Feedback
If you’re a developer who has done TDD, you probably know what a big difference fast running tests make. By isolating your code and limiting dependencies, you can get quicker feedback which allows you to make progress more quickly. At HubTran, we’re using that same concept of rapid feedback as a way to verify customer value in our features.
Self Selection In Hiring
“I appreciate getting to know you, but I’ve decided not to accept your job offer.”
Saying Goodbye
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?
Assumptions and confidence
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.
Starting With Value
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.
Interview Questions
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.
Inventing Options
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!
Some Valentine's Day Love for Radical Candor
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.
Blind Hiring
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:
The Power Of Being Wrong
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.
What You Say and What You Do
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.
Scaling Economically
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! ↩
Confidence and Competence
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.
Sometimes You Throw It Away
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.
What We're Listening To
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.
Let's Talk Naming Y'all
There are only two hard things in Computer Science: cache invalidation and naming things.
– Phil Karlton
Hiring and Technical Interviews
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.
Practice and Intentional Improvement
I’ve written before about being intentional about improving.
About a year ago, HubTran started moving our main application over to Elm.
We’ve recently hit the point where we have more Elm code than JavaScript in production.
This is exciting, but as a person who hasn’t really learned Elm, it’s also a bit scary.
Over the last few months, I’ve really started digging in to Elm.
At the same time I’ve started playing organized soccer after taking 30 years off.
These things may not seem related, but bear with me for a bit.
Testing Cmd's in Elm
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!
What We Can Learn from Niecy Nash
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:
HubTran Starts a Book Club
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 mmangino@hubtran.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.
Developers as Support
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.
Welcome to the new HubTran blog!
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.