Hacker News Reader

Comment by LandR | Hacker News Reader

>> My advice is don't complain and don't attempt any significant rewrites for the first 6 months or so.

I would agree with this, you need to be careful. I've seen a friend start at a new company with a horrendous code base, bring up the issues and be let go because they hurt / offended the existing developers.

SOme people are really precious about their shitty code and can't take criticism, esepcially in small companies.

So get through your probation period then you can maybe start making noises.

View on HN

> SOme people are really precious about their shitty code and can't take criticism, esepcially in small companies.

It's very easy to criticize, often not easy to understand the situation where the bad code was written. Maybe the hastily-written code was the thing that saved a company from bankruptcy and was written by dedicated engineers, and bringing your friend to fix it was the plan all along, and what they needed was someone to fix the code and not decry everybody as stupid.

[I'm not saying this is what actually happened to your friend. I don't know your friend :)]

> It's very easy to criticize, often not easy to understand the situation where the bad code was written.

A lot of people seem to think that criticism of the code is the same as criticism of the person who wrote the code. They are not the same thing. Root knows I've written plenty of crappy code over the years for very valid reasons. You are not your code, saying the code sucks doesn't mean I think you suck.

> You are not your code, saying the code sucks doesn't mean I think you suck.

Some people take _any_ criticism of their code personally regardless of how constructive you are being.

I have had a person completely blow up at me for simply asking (literally a question - a valid question) "why did you choose to use a BindingList instead of a List?"

Maybe it was how I phrased it? People are tough to get sometimes.

And some people are sick to their back teeth of listening to new devs come in and whine about poor code without understanding any of the context. Perhaps you do know better than everyone else, but you ought to make damn sure of it before you open your mouth

The first course of action if you find some ugly/bad code is to ask a dev with more history with the codebase why it's like that. In my experience 9 times out of 10 the answer is "we know, it's like that because of reason but we haven't had the time to fix it yet".

Surely in a commercial setting the primary factor is RoI rather than time? Will rewriting this old, stable, code increase profits or substantial reduce revenue impacting risks?

#notacoder

Often, it's a simple case of business need. As long as the offices are clean, the business doesn't really care if the cleaning cupboard is tidy.

It applies to a lot of business areas. If you want to introduce new processes or fix any problems, you need to justify why you want to do that, and "This isn't very pretty" isn't generally considered a good enough reason. If something works, nobody ever got into trouble for leaving it alone.

> Surely in a commercial setting the primary factor is RoI rather than time

If it's a smaller company (op mentioned 50-100 people) they might not even know what RoI is, and/or might not care about it.

That's a strange comment, surely it's impossible to stay in business and not understand RoI to some degree.

Same thing. The time is the investment. There are always projects with better RoI so a rewrite is constantly at the bottom of the pile. "We'll get to it someday."

It really does depend, any code, especially bad code, is very rarely bug free. So if you ever need to fix a bug the amount of time you will need to spend and revenue you might lose during the time might be worth the refactor beforehand In my experience, software or product development is never really "done" Customers, users and business will ask for new features and change of old features, external dependencies and used services will change, hardware will change Not being able to move fast enough, train new engineers and adjust to changing requirements will have a cost If I can't trust my codebase not to break on any new change it will be much much harder and more time consuming ie expensive to maintain it

This is not applicable to every piece of code and roi should always be kept in mind but I'm my experience it is almost always the case

Not necessarily related to code, more or less you just re-wrote a sort of Chesterton's Fence:

https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence

I think if it's so frequent that you're sick to your back teeth of listening to people complain about your code, it's probably a really sure sign that something is very wrong with the code.

Haha, good answer :) It's rarely my code they're whining about though

> I would agree with this, you need to be careful. I've seen a friend start at a new company with a horrendous code base, bring up the issues and be let go because they hurt / offended the existing developers.

I'm not sure if I agree. As a programmer I feel my primary responsibility is towards the code, not the company, not my colleagues feelings, not the customer. There are other roles who speak for them (sales, product owner, managers, etc.), I speak for the code.

When you get into the office in the morning, you hang both your coat and your ego on the coat rack, you can pick them back up when you leave. If someone can improve the code by tossing away 3 years of my work, then by all means. Doesn't matter if the person who suggested it is a senior with 20 years experience or the fresh out of college guy/girl who started just last week. You judge the idea on it's own merits, not by who suggested it.

I really don't get the tendency of allistic people to involve emotions in parts of their life where it's not helpful at all.

> When you get into the office in the morning, you hang both your coat and your ego on the coat rack, you can pick them back up when you leave. If someone can improve the code by tossing away 3 years of my work, then by all means. Doesn't matter if the person who suggested it is a senior with 20 years experience or the fresh out of college guy/girl who started just last week. You judge the idea on it's own merits, not by who suggested it.

>I really don't get the tendency of allistic people to involve emotions in parts of their life where it's not helpful at all.

I complete agree

> You judge the idea on it's own merits, not by who suggested it. > I really don't get the tendency [...] to involve emotions [...]

You're absolutely right: if someone has a good idea for improvement, it should be adopted regardless of who they are.

The difficulty is that the suggestion of a total rewrite is not-infrequently prompted by a mostly-emotional reaction. It may not be taking all the important objective factors into account, so you have to be careful to assess whether it truly is a good idea.

I agree that ideas should be judged on their merits but you're still dealing with human beings. Someone could approach a bad codebase and say, "Here are some ways we could improve X, Y, and Z," but you could have another person say, "This was done in the stupidest way possible, we have to throw all this crap out."

If someone approaches things politely and professionally then no one should have a problem with constructive suggestions for improvement. But people sometimes approach things in a combative or disrespectful manner and that's when you run into problems.

> If someone can improve the code by tossing away 3 years of my work

But how do you objectively measure "improvement of the code"?

Maybe it's something fairly obvious like better performance, less bugs, etc, but a lot of times it's very hard to tell if there was actually an improvement or just a different way of doing the same thing, except at the added cost of re-implementing those 3 years of work.

And for the record, I agree with you in that you (we) should leave your ego at the door, and if some young whippersnapper can do better than you, then you should be able to leverage that and increase the productivity/performance of the team/company.

However I've seen it happen many times where someone thinks they will improve the code but in reality (like others have said) they don't have the correct context and forget about a lot of stuff that their "improvement" should take into account but doesn't... and then once they do the "aha!" moment kicks in and they realize why it wasn't as easy to improve as they first thought.

Disagree, joined a company 3 months ago. Started a huge refactor the first week in. Then, a bigger refactor the second month in. I feel I've already earn my credentials with these 3 refactors.

The directors and the team leader appreciate the honesty and my initiative to make the codebase healthier.

Like Ray Dalio says, 'don't tolerate shit'.

P.D: I rewrote a huge section of the application on Vue2 with SFC's. The other three developers who wrote backend mostly, tried to do the FrontEnd, but made a complete mess.

Reply on news.ycombinator.com