Conversations with Technology Leaders: Erik Meijer
Note: This post originally appeared in the ACM Queue publication for my regular column.
There are smart people in the world. And then there are *really* smart people. You know the ones I am talking about - the ones that are so impressive that it doesn’t matter what they do (academia, programming, engineering, or management) that you know if they are doing it, then they are doing it well.
And so for this issue of my column I wanted to share with you some of my favorite engineering and leadership lessons from one of the smartest people I know - Erik Meijer.
Whether you are a leader, a programmer, or just someone aspiring to be better I am sure there are some smart takeaways from our conversation that will help you grow in your role Oh, and if you read to the end you can learn his favorite interview question - see if you would be able to pass his interview. :)
What are the qualities that make someone an amazing engineer?
There is a paper called The Humble Programmer, and even though it was written in 1972 after all these years it is still super relevant. In the early days, programming was about puzzle solving or optimizing the computational process - those ideas are still there. Our world is very complicated, we are dealing with distributed systems, all kinds of models, neural nets, frameworks, new languages. And we don’t have the mental power to keep on top of every new innovation and idea. Mental power is our most precious resource.
Great engineers are the ones that are able to maximize their mental power.
Part of this is being able to leverage the power of abstraction. Focusing on what is important, and leaving out the unnecessary details. Sometimes details are important, other times they are not. We cannot talk about everything in absolute terms. Developers need to recognize these levels of abstractions.
A good engineer knows how to handle leaky abstractions and can go up a level or dive deeper down when needed. But that same engineer also has to accept that you can never understand everything.
We need to be asking how we can design systems so that computers can handle more of the work for us? A lot of developers are still creating programs as text. A lot of the tools we use to manipulate programs are still too primitive. We need to be much more mindful of how we can use computers to do our jobs.
The whole point of The Humble Programmer is that your brain power is your most limited resource so using smart tools is a good thing. A good developer understands that they can’t do everything, and knows how to leverage all the other tools.
Kate’s Takeaways: You should read (or re-read) the Humble Programmer. And always be on the lookout for ways to work smarter - better tools, intelligent systems, and enlisting help - focus your mental energy on the task with the most dividends.
What are the qualities that make someone an amazing engineering manager?
One of the first things is you have to have deep technical knowledge. But it also important to know possess self awareness, empathy, and emotional intelligence. You have to be able to understand other people and you have to be able to steer people and move people.
In management, there is a communication feedback loop. In one direction, a manager interacting with their reports requires emotional intelligence. He or she has to know what drives the other person to get optimal results. A great manager will help people do their best work.
The second part of the loop is the reports back to their manager, and the skill that matters here is empathy. You have to understand what they are trying to say. These are noisy channels. You might hear something but that isn’t what was said, and vice versa.
Each direction of the loop has uncertainty.
It is your job as the manager to make sure this communication is correct. It is on you to make sure that the feedback loop works. This creates a virtuous cycle - the better you understand your reports the more empathy and emotional intelligence you have in that relationship.
There can be problems, though. By taking a bayesian approach, you need to do error correction. One of the ways you get that error correction is through peer feedback and 360 reviews.
In your mind you create a model of someone. When something happens, you hear something or observe something then you are updating that mental model. This is where biases can be dangerous. In the beginning you don’t know anything about someone, but the more interactions you have over time the uncertainty in your model diminishes.
Kate’s Takeaway: Feedback loops are an interesting way to think about you interactions and relationships. If you want another lens on a similar topic Eric wrote this paper on the Responsive Enterprise that talks about these loops in an organizational context.
What book do you wish all software engineers would read and why?
How to Win Friends and Influence People.
That book gives you really complete ways to think about human relationships and how you interact with other people. It is written in a way that makes you consider the lessons by putting yourself in the other person’s shoes. How do they think or feel in these situations? And what can you do differently?
I make a copy of the book cliff notes and glue it onto the cover of my notebooks. Every two weeks I read the rules and refresh myself into doing the right thing.
The books I recommend for managers are ones by Jeffrey Pfeffer and Robert Sutton (professors at Stanford) since they are more evidence driven. A lot of books are more things people believe but there is no proof, you can’t always reproduce the results, so their books are better.no
Kate’s Takeaway: Whether it is “How to Win..” or a another book, figure out your own rules and revisit them regularly. Without some sort of external stimulus most of us will fall back into our default modes of socially awkward introvert, and so a paper taped to the inside of your planner or notebooks is a smart idea.
What is the the best piece of career advice you have ever received?
When I did my PhD, afterward in the celebration my advisor, Kees Koster, said to be at the intersection of theory and practice.
It is easy to dive into theory, or all the way into just practice - but the real interesting work happens between theory and practice. Try to understand both sides. The safe spot is in those extreme. Just theory is not enough and just practice is not enough.
Now there are a so many online courses, so many blogs, and lots of white papers. You can subscribe to The Morning Paper, go through the ACM Digital archives - a lot of people are making it easier to bridge gaps. Going back to the Humble Programmer, you can’t keep up with all of the knowledge that is produced. You don’t have to throw your hands in the air and say it is too much - you have to know how to spend your energy and brainpower.
Kate’s Takeaway: It is never enough to just do what is obvious. You have to dig deep. Devote time in your schedule to learn new things. Try to read a white paper per week, or per month.
What is your team process?
How does work get done? How do you communicate status?
A lot of things you read about process has very little evidence behind it. I don’t believe a lot process is scientific. Instead, I define guidelines and within those I don’t care how things happen.
My thinking has two main sources of inspiration: military and the Hacker Way.
Over time armies have figured out how to get things done and achieve their goals in an environment that is really chaotic and completely unpredictable. If you read the Marines Warfighting manual, and replace the word “war” with “software” - everything in there holds true.
So how do you deal with uncertainty?
What people do with processes is that they are trying to fight or control uncertainty. For example, someone can say just adopt zero inbox and your life will be awesome. In reality though, that isn’t really the case.
One of the things I like about Facebook is the Hacker Way. It is approach to building that involves continuous improvement and feedback. It is about computational thinking: how do you program the system, and how do you make the system do things that no one thought was possible?
Being agile is about communication. The process needs to change with the situation. You have to have a big picture of where you want to go, but any plan or process will shatter immediately when you hit your first bug, or something happens out of control.
In most projects there are two phases: an explorative phase and an execution phase. Your project should progress like a damped sine wave (where the amplitude gets smaller over time). You have to figure out what to build, and figure out what is the question we are trying to answer. In the beginning you want to increase the vertical velocity to get uncertainty under control, and then you want horizontal velocity to increase when you get into execution.
With prescriptive process, people are looking for a silver bullet to solve problems, but it doesn’t exist. It comes back again to the humble programmer; the world is super confusing and you have to embrace it and work with it.
Kate’s Takeaway: You have to make your process work for you. Imagine your projects progressing on a damped sine wave - first focus on finding the right questions, and then the answers.
Who is the best manager you ever worked for? What made them so great?
William Adams. He was my manager at Microsoft. He is an inspiration, and I am still trying to emulate him in my work.
There are several things I liked about him - one is the importance he sees in diversity. For example, feedback loops and prior assumptions - you need diversity to challenge your thinking. You have to actively put energy into creating a diverse environment so you are always challenging the status quo. Don’t get stuck in a local optimum.
The other thing is that he always focused on was people first. You want to create the circumstances where everyone can focus on their strengths. Always find the best job for the person. Try to get a sense of the progress and circumstances so you can get ahead of what is next. For example, if the project is winding down, make sure there is always a pipeline of new ideas. You have to make sure the pipelines are set up so they never stall - keeping things innovative.
Kate’s Takeaway: Think about the people around you. Do you have enough different opinions to keep your team out of a local optimum? How can you get more diversity?
What are the common mistakes that even good engineering managers sometimes make?
Your prior assumptions are not higher order - your assumptions about assumptions. I keep reading “How to Win Friends…” because I understand it is easy to fall back into my default behavior. That is the big thing, your work is never done - you never know and you aren’t perfect - there is always stuff to learn. You have to keep up with your trade and keep learning.
You have to keep pushing yourself to get better.
Once you get stuck and stop pushing yourself it is a big mistake.
Kate’s Takeaway: Think about some of the past lessons you’ve learned. What could you use a refresh on? What are some of the new things you want to learn?
What is your best interview question?
Given a type with 2 parameters r, a.
(a -> r) -> r
Prove this type forms a monad.
If you try to solve this question by brute force you are going to fail.
Thinking about thinking - you have to think about this abstractly. If you look at it from the right level of abstraction, it is easy. Ssounds really theoretical, but it is super practical. When you are using JavaScript you are using this function. It is a micro example of everything above into one single type.
---------
Being a great developer is hard - it requires constant learning and a passion for technology and science. The same thing is true for great technical leaders. There are a lot of smart lessons but perhaps the most important one is to always be pushing yourself, and to be smart about your brain power and energy (working smart).
Hopefully you enjoyed this interview and learned a few things that you can incorporate into your work and life. See you next time!
-Kate