Thoughts on engineering culture
Photo by Anna Samoylova on Unsplash
Recently I’ve been thinking about running an engineering team and what practices it should discourage. Most of these ideas are rooted in past experiences I’d like to avoid.
One I especially dislike I call guarding. I’ve seen this behavior at almost all the companies I’ve worked with, some especially bad. Guarding is when someone suggests an idea with no intention of implementing it and then refers to this suggestion at some later time to gloat. An example:
Engineer: “We should change that password from Password123 to something more secure.”
(Engineer does nothing. Company gets hacked 2 weeks later)
Engineer: “I told you guys we needed to change the password. If only people had listened.”
Of course, changing a password is relatively trivial. A more realistic example might be: “We shouldn’t store passwords in plaintext. They should be salted and hashed.” or “We should start using a caching layer in front of the web server so it can handle a higher load.” If the server goes down, the engineer is first to remind everyone that he knew this was coming and had a solution for it, but it’s everyone else’s fault it wasn’t followed up on.
Ideally, the engineer would think about these improvements privately, then go ahead and change that password. At that point they can inform the team the password was changed to something more secure. They might research a secure hashing implementation for passwords and open a pull request, informing the engineering team that this practice is more secure.
But if you’re just planning to say these things in passing to illustrate your mental superiority, save your breath. Everyone is busy, so unless you have a concrete plan of action, it’s not helpful and it’s not necessary.
Guarding is usually the most frustrating when it comes from a dev manager. They emphasize “security”, “caching”, “horizontal scaling”, “docker” in passing, but they do not have a concrete idea of how these work or how they might be incorporated into your project. They don’t schedule any time for it and don’t provide technical direction. But when things go wrong it’s the engineering teams fault for not listening.
Now, there are cases when these things should be said: when prioritizing work during a sprint planning meeting or when discussing upcoming work with your manager, IF you believe this work will get scheduled. If it’s not likely it will be scheduled, then save your breath. You’re the one doing the guarding now.