Since I didn’t know how to program last year, it’s better to write my thoughts down now before I become a tech elitist who can’t relate to people who don’t know and don’t care about the difference between interpreted and compiled languages.
1. Don’t treat developers as commodities
Why would you treat anybody in your organization as commodities? If your team hired the right people, you should value each of them.
2. Simple things can often be complex (and complex things can be simple)
So don’t expect seemingly small changes to be done in the blink of an eye. And understand that pushing developers to work quickly increases the risk of human error resulting in buggier code. Unfortunately, there’s often no precise way to tell how long a change will take unless you’ve looked at and written some of the code.
3. Balance the amount of trust and bullshit detection you have for your developers
This balance depends on your personal relationship with the developer and the amount of technical expertise you have yourself. The better your personal relationship with the programmer, the more you can safely depend on them. But you also need to hone your bullshit detector so you won’t be pushed around or misled or flat-out deceived. You don’t want developers telling you something will take five days when it’ll really take five hours just so they can take it easy and watch cats yawning on Youtube.
Here’s a great article on being a competent engineering manager.
4. Developers are people like anyone else
Common sense for beneficial human relationships still apply. At the end of the day your relationship with your developer colleagues is like your relationship with other people in your life.
People who write code are people (for the most part) like anyone else. They aren’t like this
and they shouldn’t regard themselves as like that. They eat, sleep, are angered by unsympathetic people who cavalierly demand new features, like to tackle interesting engineering problems, and are happy when their work is appreciated and valued by end users.