3 ms·

I'm one of these people. It's not just a matter of being "smarter", it's the way in which we think. I can analyze a complex system in my head and see the connec

I'm one of these people. It's not just a matter of being "smarter", it's the way in which we think. I can analyze a complex system in my head and see the connection between the beginning and the end, most people have to reason about each step. So as a result I'm prone to overcomplicating things, and I have to remind myself to stop and try to think of other ways to do things, what trade offs I'm making and the like. Sounds to me like these guys aren't quite self aware enough for that yet, or they don't understand the debt that comes from increased complexity, maybe they haven't had to rework a system they built years ago or that someone else built. Tell them there's no free lunch. If they're making efficiency gains they're borrowing from the future in the form of technical debt, they're increasing complexity and therefore increasing difficulty in maintaining and using the code in the future. Remind them that when they take that aspect into account they're not being efficient, and ask them if there is a more efficient way to accomplish the same thing without increasing complexity. Tell them to take a moment, become disattached from their proposed solution, and try to reason on ways that it might make things harder for other people in the future. That's a key point, because it might feel easy as pie to them. And if they can come up with a way to do what they want without a continued maintenance commitment and another thing to store in their heads forever then you will reconsider it. Your goal here is to make them better engineers by teaching them to think about the implications of added complexity. Right now their solutions seem so simple to them. They've got talent and potential, but they're not great engineers yet.

in9 4y ago
Solid advice. One thing that I also became aware of is to not care a lot about workflows, and don't let workflows from the engineers leek into the system. The reason why I say that is that at some point I worked on a system (first to design and implement it) that for me was very nice and ergonomic, but in the end was full of some quirks and patterns that mostly worked for my workflow. When other engineers joined I clashed with them a lot over those decisions and me imposing a hard structure onto others work/workflow. When I became a manager and had the opportunity get familiar and re-implement another system, those types of choices and clashes, now from the opposite perspective (I didn't know the code and disagree with all of their implementation choices) really showned me I) the importance of the system design to guide improvements/features and II) how useless it is to dictate how someone should do their job. I essentially learned that micromanaging sucks, but you get the point :D

in9 4y ago

Solid advice. One thing that I also became aware of is to not care a lot about workflows, and don't let workflows from the engineers leek into the system. The reason why I say that is that at some point I worked on a system (first to design and implement it) that for me was very nice and ergonomic, but in the end was full of some quirks and patterns that mostly worked for my workflow. When other engineers joined I clashed with them a lot over those decisions and me imposing a hard structure onto others work/workflow. When I became a manager and had the opportunity get familiar and re-implement another system, those types of choices and clashes, now from the opposite perspective (I didn't know the code and disagree with all of their implementation choices) really showned me I) the importance of the system design to guide improvements/features and II) how useless it is to dictate how someone should do their job. I essentially learned that micromanaging sucks, but you get the point :D