Hacker News new | ask | show | jobs
by takeda 1889 days ago
Eh, that describes exactly my last job (which wasn't bad, I liked my coworkers, but my last manager made it a horrible experience), worst job I had so far.

He wasn't bad as an engineer, but he had this crazy OCD to a point that even keys in YAML file should be ordered alphabetically.

He had his vision how things should be, and how he would implement them.

First, he was not happy that my solutions were done differently than what he would do.

Then, when I learned about that he wasn't happy and tried to do it the way he wanted by asking him question about it he told me that I required hand holding and as a senior should not need that. Yes I'm senior, but not a mind reader.

I would think that someone who majored in psychology would be better at something like that, but I guess the only thing he learned in psychology class was Socratic method, which he constantly overused when talking to others.

He though he was being clever but only made me think (because I couldn't say it to his face): "just fucking tell me what the fuck you want me to do"

Ugh, I'm so glad I don't have to deal anymore with this BS.

2 comments

> He wasn't bad as an engineer, but he had this crazy OCD to a point that even keys in YAML file should be ordered alphabetically.

Eh, I am guilty of that (for myself, I don't run around other people's code).

I don't know if it's OCD but I clearly remember the moment I decided to order keys (in yaml, json, etc.): after a debugging session where I lost time because I was scanning whole lists with my eyes, looking for a particular key and thought "it'd be easier if it was ordered according to alphabet and not domains of concern".

Wasn't there a debate/online conversation about `girly code` a decade ago ? About tabs, alignment, etc ? Thank you prettier :).

IMHO having this as a rule that keys in dictionaries are sorted alphabetically can be a valid rule. But this should be enforced in tooling, not "rules", and not through micromanagement. Much like using opinionated code formatters - like `prettier` you mention. It makes lives of everyone easier down the line.

Sometimes this comes from years of experience (mostly pain ;)). Some leaders, while coming from a good place - I want to help you, and others, avoid pain in the future - communicate it very badly - do it like that... because I say so!

> having this as a rule that keys in dictionaries are sorted alphabetically can be a valid rule

Ordering keys to prevent randomness is very helpful to spot changes when using "git diff", doing code reviews, comparing files side by side.

Often it helped me spotting bugs due to a missing or unwanted element.

I wish code linters had enabled by default with the ability to disable it with some simple syntax.

I had a look at prettier's github issues in the mean time and

> No, prettier tries not to change the semantics (specifically, the AST) of the program, and sorting imports/keys could break that guarantee. See here for more details and context, as well as links to similar/duplicate issues: #1684 (comment)

it makes sense not to make it a default.

https://github.com/prettier/prettier/issues/2460 https://github.com/prettier/prettier/issues/1684#issuecommen...

I think another option is to just let it go and you can "fix" it later if you want and have the chance. Just put it in a "cleanup" commit or something. Don't be passive agressive about it, make it a team practice. Sometimes people will change the style of your code, that's ok, it's not a slight against you.

However, if you get in a situation where people are changing styles back and forth then you need to talk it out. E.g. Alice inserts a blank line, Bob removes the blank line, Alice inserts the blank line again - time to talk about blank lines and code style.

In this case, if Alice sorts the dictionary keys and Bob couldn't care less, it seems both can have what they want by simply letting Alice sort the keys. And if it becomes a common thing instead of a one-off, maybe talk about it.

That makes it way easier for one person to find (who actually knows the names they chose for the keys) but just about impossible for everybody else.
Girly?
Thanks for posting the context for such a bizarre description. I can assure you that it's not worth continuing that train of thought.

However, if you want a positive, constructive frame the goal is self-documenting code. In that vein, here is a set of ideas I made a major contribution to amongst many other serious-minded software engineers.

http://wiki.c2.com/?SelfDocumentingCode

Haven’t read the articles, but wow, this idea needs a new name
Why? Does something being "girly" strike some kind of negative emotion? I don't think it is bad to associate organized and elegant code as feminine. You probably should read the article

> And there you have it. I think "girl code" is quite a compliment. Because caring about things like beauty makes us better programmers and engineers. We make better things. Things that aren't just functional, but easy to read, elegantly maintainable, easier--and more joyful--to use, and sometimes flat-out sexy.

Whether you see a trait as a positive or a negative does not mean it is useful to anyone to ascribe gendered terms to it.

A female software engineer who does not strive for beauty in code, is she less feminine? A male software engineer who strives for code beauty more feminine than the female one?

It is a useless argument to get into, when the actual way to describe the type of code would be a choice of "beautiful, sorted, structured, consistent" instead.

Gender, as such, has nothing to do with it.

Not at all, I'm just wary of reinforcing gender stereotypes.

Even in the conclusion quoted here, the author says "I think it's quite a compliment". As if when you first hear the term "girl code", you're supposed to think "ew", and the author is there to convince you otherwise.

Why not just call it neat or organised instead? Using a gendered term does nothing but appeal to stereotypes and solidify them.

It's a prejudice about the human doing the work. It's not complicated to understand what the problem is. You should judge the work on the intrinsic merits of the work, not the worker. Every human has the right to work and be evaluated on the work, independent of the nature of their birth.
F. This is my current manager.

I feel like this is more common among insecure managers than with secure managers. The insecurity shows up in micromanagement. Micromanagement takes many forms, all the way from verbal status updates to toxic code reviews to lack of coherence in project plans or career plans.

Until this recent manager, I never truly understood what micromanagement and insecure management meant. Maybe I was lucky to have good experienced managers in the past. Insecure micromanagement truly crushes my motivation to work.