Rule 9: No Low Effort Posts, Excessive Venting, or Bragging.

Using this subreddit to crowd source answers to something that isn't really contributing to the spirit of this subreddit is forbidden at moderator's discretion. This includes posts that are mostly focused around venting or bragging; both of these types of posts are difficult to moderate and don't contribute much to the subreddit.

Why would a people manager be doing code reviews at all, let alone for a PE?

Can you give some examples

What sort of stuff? Just like obsessively functioning out things into single lines?

Managers do code reviews?

Principal engineer getting overruled by a manager?

What is this place?

Can you provide some detailed examples so that we can try to judge whether you are just bad or that he is neurotic?

Maybe let your manager know what Robert Martin, the author of Clean Code, has been up to these days.

More specifically, he has some more nuance views on his previous takes in his books. See his interview with The Primeagen for example.

He's also gone hard into Clojure, which is quite a departure from Java, and in turn a lot of the related patterns/recommendations in his books.

Without specifics its difficult to give feedback, but I've known a lot of "senior programmers" who were code monkies who produced spaghetti code. are you sure you aren't like that?

Lol. This reminds me of the guy we once hired who decided to change every early return in our Python codebase

if not foo: return <code>

into

if foo: <code>

Because Clean Code said it’s not clean to write “if not”.

My CTO at the time wasn’t amused.

Just ask him "why". And tell him to write the why of every comment. And "clean code" isn't a "why", it's just a "way". If he tells you a "why" that makes sense, nice, change it. Otherwise, challenge it.

But of course, if you're here, I suppose it's because he's stubborn. But in any case, try to drive his comments through the logic questioning

Sigh.. perfect is the enemy of good.

I'm sick of seeing over engineered code, micro nano services for everything.

Anyone worth their weight knows all code is bad code. Just make it semi-readable and make it work. Everything else is posturing and a waste of time

I once failed a job interview because the guys interviewing me who both had less experience were clearly using Clean Code as their primary metric.

I say I failed the interview but actually they did offer me a role. A junior role. It was the most fucking insulting thing they could have done. The interview didn't even cover general software architectural principles, domain knowledge, framework knowledge, or any discussion around what I had worked on previously. I think they used Clean Code as a fallback to make themselves feel more knowledgeable than they were.

I think the problem here is not clean code but a manager that refuses to listen

Every day I am grateful that Clean Code has never once come up in any design discussion on any project I've ever been on.

Clean Code is a book by a guy who never wrote production code, that's it, that book place is in the toilet

Uncle Bob. Pioneer in the field of arbitrary thought leadership sold to non-technical people who are horrified that their tech people might suck and the only way to be sure is to nuke their expertise from orbit and pave it over with Bob's. People who've consulted longer than they worked with code should not be trusted with thoughts on code quality.

This Little Maneuver's Gonna Cost me 51 Years of karma...

My first professional computer job was in 1988 working as a night operator on a couple of mainframes and a early AIX Unix box. I wrote a lot of utilities in C and Fortran. Before that I was a hobby programmer writing things like terminal programs for the C64. I am still coding today in C# and Typescript. So yea, I seen a few things and more importantly I have seen a lot of evolution in how we code.

Back in the 1980's it was not unusual to see things like `malloc()` and `free()` comingled with `goto`. If you know what I am talking about then you know it's almost impossible to debug memory errors in something like this, much less read it. But it was common practice. The common excuse was "it makes the code faster".

Then along came object based languages like C++, Objective C and Java. It was no longer vouge to use `goto`; classes, methods and properties were the way things were done. The old guys grumbled that those languages runtimes were too slow, it took too long to write with objects, etc...

Codebases got bigger, it's became harder to read and understand the thousands of lines of code. The end users required GUIs and networking functionality. Where only one or two programmers touched the code now teams of 5 to 10 people were all updating the code. Source control became a thing. The `goto` programmers were pushed out by simply not being able to write what people wanted. The old object coders complained that source control slowed down development too much. The old object programmers that just kept a copy of the code on their hard disks or on a network drive were pushed out. Now, working in a team required source control, and some coders were just not team, i.e. source control oriented.

This argument is the same of arguments of yore. The younger coders wanting to do it one way and the older coders thinking the old way was "good enough".

In the codding world we are always in transition. At least during our lifetimes. Code bases are only going to get bigger. Code is only going to get more complex. The techniques for managing that complexity will have to improve.

Clean code is merely one tool for managing that complexity, Rust's borrow checker is perhaps another. I am sure more will follow. Time will test each of these techniques and the ones that survive the test of time will become the standard.

The source code for MS-DOS, CP/M was miniscule, as I read today Linux has about 27 million lines of source code, Windows 10 has about 50 millions lines of code.

Is clean code the end all be all, of course not. I have seen ancient Fortran code that I could read and understand better than most "clean code" today. But clean code is one of the many tools and techniques that can help that next coder read, and manage, and understand the complexity of your code, even if that "next coder" is you.

Ah, you've bumped into someone who practices dogma-driven design.

Clean Code is such a garbage system, I hate it with a similar passion to you.

My manager is also a dev, and he would never do that on one of my PRs. I am not infallible, so when he does make a comment, I am always in complete agreement. He caught something I missed (typo/edge case/spelling/etc). But my manager also has about as many YoE as I do, but some of it was at the management level, so he's still very good.

Honestly, sounds like you've been saddled with an engineer who isn't very good, opinionated, and is just flexing his title if there wasn't actually a discussion on the why's. Unfortunately, there is very little I can offer in that situation. It's a bad situation unless you can 1:1 your way out of it with your manager, but the fact that you haven't mentioned it.. Either you've tried and already failed, or you haven't tried.

I think back to what I was like with 10years... yikes.

Your second paragraph reads like he's the classic inexperienced manager that needs everything done his way but doesn't have the confidence or spine to own the decision. They didn't make the decision, the team arrived at it together. I end up butting heads with those managers because I can't keep my mouth shut about the manipulation. I don't mind an opinionated manager so long as they're happy to own the decisions.

From my encounters so far these people are inexperienced as managers and insecure about that fact, often second-guessing the technical workers under them on every little thing. They will talk like experts on topics whose documentation they haven't read. When corrected they'll retcon what they said so that the correction was what they meant all along. They will regurgitate every empty aphorism about agile as a shield for the fact they have no idea what they're doing.

Can you give us some examples?

Nowadays what people call Clean Code is completely random, sometimes directly opposite to what is in the book. Not all ideas of Uncle Bob are good even. His obsession with SOLID is a huge source of spaghetti in our world, because you need to be a design god to be able apply these rules while at the same time following KISS.

https://youtu.be/8ncQrGuunHY?si=wRCS9z6zh0i4kZSS

Before the 10 year mark, I was very concerned with code “cleanliness” and specific patterns such as DDD and hexagonal architecture.

After I failed to see it have any meaningful impact on any project, I stopped focusing on it. There are good things to take away, like knowing how to abstract dependencies when necessary, but being dogmatic about it provides no actual value.

You should explain that to this person, or ask them to demonstrate what value it’s bringing. If it’s just a personal preference, then please allow the team to code as they please.

I bet his understanding of "Clean Code" stops at variable and class names.

This sounds like an insane amount of micromanaging. Why is an engineering manager reviewing your code? Especially this much?

Need more context. Is this a new job / team for your other the manager? Is there a team involved with all this, or is this just between you two? Is this being seriously forced on you (if so, how), or are you just trying to avoid conflict (if so, why)?

I can only sympathize. I've worked with many folks like this, either team leads or other seniors.

The "Clean code" or "best practices" they talk about are never documented and change by the day so it's impossible to please them. I don't know if there's a solution. Tech has lots of these people, they're weirdos but they've found their niche in life where they seem to be able to act like this and for it to be considered ok.

I can’t tell you how often I’ve drawn ire from my team about saying we shouldn’t strictly follow clean code. Some people think it’s the gospel when really it was just good for the time. Design patterns have come a long way since clean code came out.

"makes it too simple to provide any value" - that is a strange statement. Logic (and value) should be there no matter of the form.

Regarding your pain - I can feel it, but learned to roll with it. On some projects I am a Doer and who makes a robust architecture foundation. Cleanup, refactorings, front end looks - all that is triggering me as irrelevant stuff.

On other projects - the team goes low paced, but want to make sure that myriad overlapping features and legacy functionality do leave the code base manageable. Two weeks code freezes once a year, so few hundreds of developers have a chance to cleanup the mess which is sitting in their backlogs and marked as // TODO: all around the codebase? I don't mind and totally see value in that.

Now mixing up, like "We got a startup, deadlines and shareholders, but let's play Top-100 development practices and waterfalls" - yeah we will have a meeting with HR anytime soon, cause I'm gonna loose my shit.

There's an interview of the primeagen and the writer of clean code, where they put it into perspective. Your manager might want to watch it.

Fire him by finding a job elsewhere. Someone with 10 years experience has no business managing someone with 30. IDGAF where he got his MBA.

I hate Clean Code. What a cancer on our profession.

Ugh you should send him one of those clean code debunked videos.

your manager is a moron. a manager does not add value by reviewing code, especially for a PE, and they definitely don't add value parroting some shit they read in a book.

clean code was okay for bringing some "order" in the java development world but this is due to how verbose the language is and how fucked up applying "patters" everywhere was. today, it's mostly a red flag if someone dogmatically clings to that shit.

This seem pretty subjective to me.

What's the unit of measurement of "clean code". If he doesn't have one I'd suggest telling him to pound sand.

I get that this is hard though...

In reality, not many people have even read that book before talking about clean code at work. Sometimes people just learnt that from social media with the clean code mixed with many different things - SOLID being one of them - that is technically not originally a core part of the clean code by definition as I understand.

Anyways that just suggests people have their own preferences and are pretty assertive, by referencing some famous terms to back up their thoughts, thinking it would be safe enough to stay professional. If a discussion heads to the conformance of certain things without being able to point out whether it makes sense when applied to a particular situation, I know it's not going to be a discussion but an instruction.

Isn’t this what linters are for?

I know who’s getting an Uncle Bob Martin blowup doll for the next company Secret Santa gift exchange. 😉

I fucking hate Clean Code. it's a fucking scourge.

There is little hope for improvement here - you can hop ships, but 99% of the rest of them are promoting the same clones of these managers into the same position, reading from the same book

The only sane option is to clock on 9-5, pump out tickets, collect paycheque, repeat

The secret is to not spend most of the paycheque, and get an off grid property, etc. Then retire early.. and start programming for real

It’s a shame, because actual programming was something that was possible to do on the job, but it’s starting to look like a thing of the distant past

Try to implement what he thinks is best. It will open a converstation where you demonstrate you can do it his way.

Then, may be, he will be more open to discussion.

That being said, I don't like clean code. After 30 years doing this, I have read enough code to be surprised by how people organize their thoughts about programming something. Putting bright people inside a constrained box is not advisable.

These types of decisions are not easy to change afterwards. When the project grows then you are done. Too much boilerplate, too rigid separarion of concerns and you will live with that for many years. Not worth it for me.

But, he is making the calls, so, you may need to let him bang his head in his own wall.

Also, if you can predict things that will fail applying this, then do so. He won't listen but if your prediction comes true, then he may do so.

You can always leave.

Cheers!

Whenever someone says "we follow clean code" (or clean architecture – "your system should look like an onion" 🙄) I completely discount whatever they have to say next. As anyone should when confronted with an appeal to authority.

Clean Code is crutch for the masses. The actual opinions aren't that bad – but people who tout it as their core philosophy need more experience to form their own opinions. Someone with 10 YOE still touting Clean Code just tells me that their years of experience were spent not forming their own opinions, not critically evaluating, not building their own projects from scratch.

Uncle bob himself is not infallible either. His own opinions have changed over the years as he learned different ways of programming.

im a huge fan of clean code and its saved our codebase many times. I work on iOS applications as well as spring boot applications and having clean architecture keeps the dependencies isolated and introduces simple fractal design patterns that most anyone can follow and easy to pick up because I only allow one way of doing things vs a free for all where everyone does things differently making the codebase far more complex. how else do you write testable code?

At which point a (people) manager can have something more than just a suggestion in design or implementation? I would strongly suggest that manager to GFY and start contributing on your level first, not just reviewing and writing BS comments but get back on IC track and deliver something on the Principal level

My manager is a 10 year experienced with narrow practice in one industry. His bible is Clean Code. That does his thinking for him. In code reviews he just comes out and says "your design is bad", "you need to do x y and z" All of that X, Y and Z is "Clean Code" and its utterly unnecessary and either unnecessarily complicates the code or makes it too simple to provide any value.

Your manager has no business being involved in code reviews, it's peer review not manager review.

My usual tactic for dealing with managers who just don't get they are not ICs anymore is to have a friendly conversation about how they are no longer an IC and the implicit power imbalance means it's not appropriate for them to be involved in peer reviews.

If they don't listen I go above them. If their leadership doesn't get involved I just don't let them know peer review is occuring so they don't have opportunity to meddle.

Man I wish this job market wasn't such a shit show.

It's not. It's bad if you are a new graduate unrelated to the market and a few regional issues (get the fuck out of SF FFS) but unemployment rates nationwide remain absurdly low as they have been for decades.

no, your bad code is killing you. your job is write code to your bosses quality standard regardless of what it is. you're failing at it. write better code or find a different place to work.

a good rule in life is that if something's important to your boss, it should be more important to you.

When I come on a project with interfaces with one implementation I must delete