Comment by phendrenad2 | Hacker News Reader

Comment by phendrenad2 | Hacker News Reader

Programmers, left to their own devices, always create messes like this. They abandon objective measures of complexity and instead judge it based on the limits of their own mental capacity. If they can understand it (and they built it), then they think anyone can. They get bored and start doing things the most "clever" way.

This is why engineering leadership is crucial. You need an architect who's been burned by convoluted code before, who can push for objective measures of code quality and simplicity and (true) modularity (not just DRY-style thoughtless consolidation).

But we've seen a race to the bottom lately. Everyone is trying to do more with only junior developers, or senior developers who code like junior developers (just 3x faster and more convoluted).

And if you're at a startup, congratulations, your coworkers have all worked at other startups previously, where the determining factor as to wether the company succeeded or not was mostly on the business side (product/market fit) and they never got to see an unchecked engineering team slowly cripple a company from the inside.

The crazy thing I was hired because they allegedly wanted me to give opinions based on my experience. Like, they sense they're doing something wrong. But when I got here, it became obvious that no constructive criticism is really allowed. There are a couple of voices that dominate all conversation (team leaders) and they always win. I don't know what to do about it though.

The question I have isn't about programming then. It's who is you patron in this company?

Also the reason the front end guys don't want you around is they know or some of them know their code is a steaming pile.

That's a good question. I'm not sure I have a patron but I'll have to think about it more.

Your second point could be true.

Sadly it might be this job is both not for you and isn't set up to be effective. The person to fix this needs to be a team lead and aggressive.

Fair point. But another angle is in order for you to introduce some architectural changes, it better translate to improvements in the business-side metrics, which on most cases in hard to quantify beforehand, which leaves you into babystepping it as your only option.

In your shoes maybe i'd also see it as a challenge in my own soft skills. At the end of the day it's also about selling them that your idea has some potential.

I'm aware that most of our technical issues can't be fixed without a lot of refactoring / rewriting at this point, but I see our real issues to be "people problems" rather than technology problems.

Your comment gives me something to think about though, thanks.

And it sounds like the "people problems" don't want to be exposed as the problem. So they're trying to make it look like you are the problem.

From what you've said, the code objectively stinks, and the people are objectively unprofessional in problematic ways. You may not be able to fix it without getting rid of the team leaders. If you don't have either the authority to do that or the political pull to make it happen, then your best option is probably to run away.

You mention "objective measures of code quality and simplicity (true) modularity...", are you able to talk more about that? Know of any good resources? I feel like I can recognize convoluted code easily, and I'm able to avoid writing such code, but backtracking from it and saying "you should have done _this_" is much more difficult.

Please can you elaborate on the objective measures of code quality part? Do you mean to use static analysis tools like code climate? Also, if you don't mind can you share some good reads/books which cover these topics? Thanks

Reply on news.ycombinator.com