Sep 19, 2017
D2iQ
D2iQ
5 min read
Florian Leibert, CEO of Mesosphere, recently sat down with Ed Weissman to get his take on the process, management and skills required to design, write and maintain excellent software. If you're on Hacker News, you've probably read some of Ed's advice under his handle, "edw519". Here's what Ed had to say on managing engineers and being fanatical about code reviews.
From writing software to writing books.
I'm an application programmer with a focus on business-to-business, often as a contractor. I go into companies of all sizes to help them satisfy their customers. Somewhere along the line, the website called Hacker News came along. I was one of the first people on there and it was interesting because it was so different from everything else mainstream. I love to geek-out with my friends and on Hacker News I found like-minded souls and now I'm on there everyday answering questions. I didn't realize that by sharing my experiences, people would get that much value from them. And at one point, someone said that I should write a book. I'm a programmer first before I'm an author so I think the solution to every problem is to write software. Plus, I'd rather write software to write a book than write a book. I wrote some applications to dump everything I had said on Hacker News and a lot of emails I had exchanged on the subject, curated them, and turned it all into a book -- well, three now. As it turns out, I like writing prose as much as software and the best part is that I'm not spending my time maintaining someone else's book. [mes_cta image="https://assets.d2iq.com/production/uploads/posts/attachments/MESO_Mark_RGB-small.png" title="Who is Mesosphere?" description="The most flexible platform for containerized, data-intensive applications" link_text="LEARN MORE" link_url="https://mesosphere.com" position="right"]
Don't manage engineers. Lead them.
I have been a manager and a supervisor and a business owner. I have also managed teams when I was not an employee of the team and almost everyone that reported to me over the years says I was the best boss or manager they ever had. I tend to think the reason was because I wasn't trying to be a manager. I have a tremendous amount of respect for software engineers because I've always been one. I'm a programmer's programmer. In the digital economy, the new raw material is 1's and 0's. Programmers are today's tradesmen - 100 years ago we'd be the ones building the bridges, buildings, highways, and railroads. Today's products aren't physical, they're digital, which means that we, programmers, are the direct labor building the product of our age. We need to be treated that way. Our bosses and our customers and our users need to understand that. It's my experience that they very rarely do. Instead, they look at us as envelope stuffers or necessary evils or resources.
You don't manage engineers. You lead them. If I could wave a magic wand in any organization, that's the first thing I would want people to understand at any level of management. We are building the product. We are on the critical path. If you have an org chart with what looks like a pyramid with people at the bottom and people at the top, we should be at the point at the top. In an organization that builds digital products and software, you need to understand that we are direct labor. You're either building the product or you're helping those who do build it. If you're not doing one of those two things, then you need to get out of the way. Managers need to do three things only: tell us what you need built, give us the resources to build it, and stay out of the way.
Engineers need the right resources.
If you're responsible for a team of engineers, tell them what they need to do, give them their assignments, and give them their resources. Now, that's a big one. Resources could be a million different things. It might be a nice chair. It might be a certain tool. It might be an understanding of what the customer needs. It might be keeping everybody else out of the way. So you need to understand what resources your team needs and be able to provide it. And stay out of the way. It's a fine line between micromanagement and leaving people alone. I think the biggest thing I would teach anybody is to keep having fun. I would much prefer to have a manager with a technical background because they have a mindset that understands what we go through. That being said, you still have to keep your finger on the pulse of what's going on. Management is a big topic of conversation, but I think the biggest thing is have fun and get your work done and treat your people the way you want to be treated.
What you learn from 2,500+ technical interviews.
The most most important thing I look for when hiring an engineer is the ability to build whatever it is we're building. If you're interviewing a programmer and they have a concern about either sitting down at a laptop or going to a whiteboard or going to a pencil and paper, that's a big red flag. That would be like going to a dentist who didn't want to look in anyone's mouth. I think somebody who wants to be a programmer should embrace an opportunity like that. It's not about the code that you're asking them to write. It's about the discussion you have about what they wrote afterwards. And you never expect anyone to write anything perfect. Sometimes it's more important that you have fun talking about the code they wrote. Getting excited about solving problems together is what really matters.
For me, a good litmus test is whether the person was ever a one-person shop. My former CTO once told me he only hired two kinds of people: those who ran businesses or those who were managers before. As one-person shop you have to be able to talk to a user. You have to meet with customers, understand what they need, and find the right tools to build them what they need. You didn't sit back and wait for someone to solve your problems for you. You soldered wires if you had to and rebooted servers when they went down, all because you're the only one there. Those people tend to rise to the top.
Invest in documentation and code review.
I put in a lot of work upfront before any code is written. My process starts with pinpointing business requirements. In fact, I often spend half the total project time on that phase alone. The second phase that many people skip over is the technical specification. If you write technical specs, they can be peer-reviewed and QA'ed. I can't QA what's in your head. The better you do on business requirement and technical specification, the less work you will have to do later on processes like user acceptance testing, testing for scale, QA, etc..
I am fanatical about code reviews. Unreviewed code never enters the repository if I have anything to say about it. In fact, I like two steps of code review: one automated code review and then peer review with somebody who knows about the domain or the application as well or even better than the developer. Code review is not a cost. It's an investment.
Like Ed's advice? Check out his e-book, The Corporate Programmer Survival Guide, and more available on edweissman.com.
