Hacker News Reader

Comment by Alex3917 | Hacker News Reader

> I've noticed that often people micromanage because they don't trust their team

There's also some tasks that just shouldn't ever be done by one person. E.g. naming features and global classes and functions. There isn't any way to know if a name is intuitive to everyone else unless you actually ask everyone else. Although this the canonical example of bike shedding, I've never once had a discussion about what a bunch of things in some codebase should be called that didn't result in the codebase getting massively better.

View on HN

Yeah it is a bit funny that naming is the go to bikeshedding example because in my experience poor terminology surrounding a project can be hugely detrimental (e.g. names that have nothing to do with what is actually happening) and vice versa.

For awhile there, I was “the second opinion” if you outsourced a project. You’d hire people like me to tell you if it really would take 100 man hours to make photo uploads faster, or did they really patch a security issue, etc. It was pretty neat to read so much closed source code. But more than once, the developer would send obfuscated code and claim that it was how they worked on it. Only once did someone say, “oops, here’s the right version”.

Those projects taught me how important naming is, more than anything. Some people like to say that you don’t need names.

I’ll be the first to say that they’re probably right (considering the code executes) but damn does it make life easier when things are named well... and less expensive for everyone.

I'm curious, how would they obfuscate code and how could you tell?

Imagine every variable, class, file, and method name being gibberish with no comments. Also, no white space devs usually use to group related functionality in a method. You have to not only figure out what the heck is going on, but also why. It’s very difficult to figure out at first.

A normal code base has some (not always descriptive) names. But it’s at least useful for context.

Oh yeah, that's some pretty clear obfuscation. It sounds like a PITA to work with code like that.

I feel like controlling naming is a great example of micromanagement. I mean, if in addition to manager you act as a code reviewer then as a code reviewer you might suggest a name. Or if you are an architect in addition to a manager and you came up with a name for a thing that was your idea, then cool. But if Jim or Jane came up with a thing and named it, global or not, then ideally they have an established process to have that reviewed (like as part of normal code review) and ideally the manager stays out of it unless they are part of that process as a reviewer (not as manager). The reviewer-not-as-manager part is crucial since it establishes trust: you’re saying to your folks they can have that authority at an equal level to you if only they are a code reviewer. Flexing the manager muscle isn’t the right thing there IMO.

Yeah managers shouldn't be carte blanche naming things. Basically there should be discussions about names during the architecture phase of any project, and any name that gets flagged during code review should get brought up in some meeting that happens every couple weeks. What shouldn't be happening is passive aggressive comments constantly getting traded back and forth between developers and code reviewers.

Reply on news.ycombinator.com