Hacker News Reader

Comment by cwingrav | Hacker News Reader

I once opened up a government code base (in C) that lead with this: "void * * * * x;". It took a while to learn that code. Taking time is fine and good managers will support you, so long as you have something to explain what your time is spent on.

View on HN

I'm consulting a client right now and their C++ codebase is full of gems of this caliber. I eviscerate every single PR, and tell them what's wrong and why, and then their CTO just merges them into master without changing anything. All the while they pay me for it. Why? Fuck me if I know. They hired me to provide advice. I provide advice, and it's pretty expensive. I _know for a fact_ they will regret merging this shit. I can explain why, in a way a toddler would understand. And yet they still do it. Smh.

You might be going into conflict/criticism mode, which would make them unresponsive. Being right isn't enough to get people to change. I don't know at all if this is the case, just mentioning it, because you seem to be frustrated by the situation.

I actually asked them if this want me doing this. They said they did. This is only a minor part of what I'm doing for them - my work is mostly on the AI side.

Fear of missing out...

'This code was already worked on and we paid for it... it can't surely be that bad'

If you deliver something broken it's better than delivering nothing... you'd be surprised how often we get 'We'll improve it later' compared to 'You didn't deliver anything?'

But it wouldn't even take much effort to fix. It's not like all of it has to be rewritten or anything. And once my contract ends, they're kinda fucked - they don't have, and aren't going to be able to hire, anyone with my C++ and multithreading/concurrency expertise. If I were in their shoes, I'd take my advice like word of God while it's available, and try to learn to write better C++.

Are your reviews more like suggestions of how to do things better, or more like "this sux and here's why"? If any of your criticisms are related to something that a linter or static analyzer could catch, have you tried to get that tooling established in the project?

I am, of course, diplomatic. It's more along the lines of "This is not thread safe, if threads A and B call this function at roughly the same time, you will end up dereferencing a null pointer. Here's how to avoid this: <code example>". Tooling would catch some of this, if they were running it, which they aren't. But it would not catch bad design.

Reply on news.ycombinator.com