Live data from Hacker News

Don’t teach during code reviews

michaelagreiler.com

301–304 of 304 posts

Re: Don’t teach during code reviews

#301

Earlier quoted context omitted.

"Separation of concerns" as in splitting a simple thing into 12 files because you've had too many books about architecture?

As in not making a 10k lines function that does everything because you didn't read any books about architecture I get it, you've been burned out by Enterprise(tm) code. Going to the very edge of the other side isn't any better

A 10k loc function is just a program wrapped in a function. I find it somewhat fun to refactor those. And you're god damn right I cannot deal with this eldritch horror you architecture astronauts come up with anymore, I'll take the dumb code please :-) YAGNI + KISS >>>>> SOLID all day every day

Re: Don’t teach during code reviews

#302
post #136

Earlier quoted context omitted.

Well, here is one way to read your comment: "A feature not making it into a sprint" is your problem. You will get in trouble for that, it will make you look bad in front of your boss, etc. "Not following best practices" is not your problem. If the code turns into a mess, it's not you who will have to deal with the consequences, at least not you directly. As a manager you will demand that your senior developers fix th…

> "A feature not making it into a sprint" is your problem. You will get in trouble for that, it will make you look bad in front of your boss, etc. "Not following best practices" is not your problem. Hmm, almost like this concept of “sprints” is unhelpful. It’s rare that delaying a PR by 24 hours to get it right has any relevance to business outcomes, in fact it is often better for everyone in the long run. But with a…

Yep. At this point "scrum" (or "daily standups", but that's a separate issue), "sprints", or "burndown charts" are all run-for-the-hills red flags to hear about when chatting with companies, IMO. It shows a lean towards process for the sake of process, artificial deadlines and artificially subdividing work to fit within said deadlines, and sometimes a "we do this because everyone else does, without questioning it" cargo-cult mentality that often extends into the tech itself.

There's exceptions, clearly. And the process does work for some folks. I'm glad those people are happy. It has rarely worked for me, or for teams I've been on.

Re: Don’t teach during code reviews

#303
post #292

Earlier quoted context omitted.

You just described Paternalism...

You write that as if every -ism contains contains an automatic and universal value judgement. For those of us who don't subscribe to that model, do you think you can rephrase your argument without isms?

Do you know why children don't like to be told what to do by their parents? It's not because they can't do whatever they want. It's because as a child, your agency is taken away. You have no choices but those given to you, no information but what little is given to you. You live in a world of someone else's rules and decisions, someone else's tastes, someone else's lifestyle. You are forced to live the life someone else wants, rather than your own life. And you are often given restrictions not because it's what's best for you, but it's just what's convenient for the person in power.

Children are often not given the benefit of the doubt. Things aren't explained to them, and they're lied to. Much of the time parents don't even do what's best, but instead whatever they prefer. The child may actually be fine with what a parent wants. But rather than give the child the knowledge and tools to make their own decisions and come to their own conclusions, the parent forces their child to become subservient, removing their ability to be a free human being, making their own mistakes, achieving their own goals. Children often grow up stunted by years of biased information, and the inner working of the minds of others who have grown up in the same system.

Paternalism is wrong because it's wrong to think you know what's good for others. You may know what's good for you. And you may have some experience that tells you some potential consequences of specific actions. But by pushing your own desires and limited knowledge on a child, and not permitting experimentation, growth, or making one's own mistakes, the child does not really grow. They just become a poor copy of the parent, and just as limited. Later they internalize all this and try to justify it by doing the same thing to others or their own children. But it's just a coping mechanism for the trauma they experienced as a small human with no rights.

If you actually respect your co-workers, do not treat them like children. Do not condescend. Do not limit them. And do not prevent them from making simple mistakes. Give them information, teach them, sure. But only if they want to be taught. Not because you think you have some special right to tell people what to do, or force people into situations they didn't consent to.

As a senior myself, I am happy to share information and help people learn and grow. But I would never tell a junior what to do, or lecture them, or prevent them from making mistakes. Everyone deserves to come into their experience in their own way, and be an equal member of the team.

Re: Don’t teach during code reviews

#304

Earlier quoted context omitted.

As in not making a 10k lines function that does everything because you didn't read any books about architecture I get it, you've been burned out by Enterprise(tm) code. Going to the very edge of the other side isn't any better

A 10k loc function is just a program wrapped in a function. I find it somewhat fun to refactor those. And you're god damn right I cannot deal with this eldritch horror you architecture astronauts come up with anymore, I'll take the dumb code please :-) YAGNI + KISS >>>>> SOLID all day every day

>I find it somewhat fun to refactor those

I don't. I like to feel productive instead of having to do laundry before getting to the actual work because someone just went ahead without any regard for quality control

>YAGNI + KISS > SOLID

Agreed

Monster architectures are monster architectures, and yet going from Enterprise(tm) architecture to chaos architecture so you can't know anything about the system without carefully going over hundreds of lines of code isn't any better

Post reply on HN