As the sole developer in a startup, I had the luxury of being able to make a lot of decisions in the architecture and frameworks of our application.
Fast forward 4 years and an acquisition later, I have a team of 5 and a lot of times it feels like the wild west. People making whatever design decision pleases them: integer and enums for DB types in one place and string another, this framework for a problem and then a different framework for the same problem elsewhere, etc.
How do I go about enforcing consistency? It feels important to me but my team members seem to subscribe to the "if it works, it works" methodology.
I guess a big part of my question is: is it unrealistic of me to expect standards like this? I struggle with the idea of coming across as a dictator that stifles creativity but doing whatever they want seems to not be scalable.
Best Answer
What makes you so special?
My CPU says it works and I want to go home. Why are you bothering me?
You can deal with this attitude by forcing everyone to issue pull requests. But now the deadlines are looming. Bad code presses on the gates of your pristine castle and you finally give in to the pressure. Or you win only to find everyone leaves and no one uses your pristine castle.
There are plenty of tools that help with this issue. Source control, code reviews, coding standards, etc. but the heart and soul of the problem is your subjective opinions about what is best have to be seen as relevant. For that you have to earn and maintain their respect. Do that and this is much easier. Fail to do that and no tool or practice will save you.
The best way to do that is communicate early. Don't tell me "we don't use strings for our DB types in this shop" 6 months after I settled on the idea. Telling me it's been buried in the documentation for 2 years is no justification for letting me do that.
For whatever reason you have things you care about. If you care about them and have a point get those things communicated clearly before, during, and immediately after the coding of every module.
Code stalking is a wonderful practice. Invest in whatever tools and practices you need so you can review code within minutes of it being written. Pair program and the tool is simply a guest chair.
Why? Every second that passes after I write code exponentially increases the cost to change it. That's because my memory of the code has a half life. I start forgetting it the moment my bladder demands a break.
Reduce the things you care about to their underlying principles. Rather than hit me with a list of 101 rules to follow, give me the 10 principles that they violate so I can figure out what rule 102 should be on my own.
Empower me to impose my own vision by helping me see yours and we'll get along great.
Then don't dictate! Make this a positive experience. This isn't some new age hippy nonsense. It's basic psychology. You are trying to modify human behavior. Random and positive is the most reinforcing (just ask Las Vegas). If you go negative you have to be consistent with your reinforcement. That's an unobtainable pain. Be positive as you spread the wisdom and you can be casual about it.
I know where you're coming from because I've been there. You had control and now it's gone. You want it back. Well get over it. Now you have a team. They don't need to be controlled. What they need is leadership. What you need isn't control. It's influence. It works better and is a lot less work. Master that and relax. This should be fun.
Do it right and you can go on vacation and this will still work. How? By not just being a leader but by getting the others to be leaders as well. Once you've instilled your vision in the team they can work while you're gone simply by imitating what you've been doing. Mentor the newbies and encourage them to step up and influence others as well.
I know it's hard. We didn't go into this profession because we're good at dealing with people. We communicate best with code. That's fine. Just do it quick and often. Show me why yours is better. Listen if I say it's not. Do this while I'm still thinking about it. I love to code. There are few people on the planet that I can talk to about it. Be one of them.