Nothing is more important to the success of your team than selecting the right people to be part of your team.
Hiring engineers that can help your team excel can be especially difficult. There are lots of stereotypes and misinformation floating around about what a ‘good’ engineer is like. Here are some practical tips to help you identify the type of engineer that will add velocity to your team.
Hire Passionate Engineers
Good engineers enjoy coding. They really enjoy coding. They do it for fun and in their spare time when they are not at work. Whether all the time…
“If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” ~ Albert Einstein*
It doesn’t matter how efficient you are at getting things done if you are solving the wrong problems.
To produce the best results, you don’t just need to understand the problem statement, you need to understand the problem. By addressing the root cause of a problem instead of just alleviating the symptoms you can produce elegant, less costly, and longer lasting solutions.
Let’s examine an example of what it means to understand the problem…
Why is it that some teams excel and other teams fall on their face? Is it talent or luck? Is there a magic sauce we can sprinkle on a team to make it high performing?
There is no magic. No key to turn or mantra to follow. But over time you can build teams that perform in excess of the individual talents of its members. Talent does matter, but a good team of average individuals will, with consistency, outperform a mediocre team of super star individuals.
To create a high performing team, you need to do four things:
Code reviews are critical for creating quality software but they are often done poorly and inconsistently. By adding process to your team’s code reviews, you can reduce bugs, increases code quality, and help your engineers level up.
Here is a checklist that will increase the value of your code reviews.
1. Do you understand the problem you are trying to solve?
2. Does the change solve the problem?
3. Can the code be easily maintained?
4. Is the code readable and easy to understand?
5. Does the code deal with performance appropriately?
6. Are team coding standards adhered to?