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

> 3. DRY is a religion here, to the point where everything is fragmented to hell. I have a hard time explaining but I feel like there’s a tradeoff where things can be split apart into their own modules to a degree that becomes counter-productive. Am I wrong about that?

There are three stages that almost every developer goes through. 1. Just code the shit up. Get it done and don't worry about structure. 2. Modularize everything! Design patterns, code reuse, code components, refactoring, getters & setters (cause attribute access is "harmful"), pointless doc strings, useless const declarations, and (shudder) microservices. 3. Nirvana. The stage where you realize what matters and what doesn't. You do not spend a month refactoring a bash script that will only be run once, for example.

I don't know you so I can't tell if you are in stage 1 or 3. Your colleagues definitely seem to be stuck in stage 2.

In my experience, you can't really teach people in stage 2 that what they are doing is wrong. They don't know that stage 3 exists so if you tell them that they are overdoing it, they'll think that you're a stage 1 scrub and/or sloppy. They have to realize themselves that they are wasting their time and that simple solutions almost always are better.

I thought I was in stage 3, but this whole experience has me doubting myself somewhat. Though, I know I'm not stuck in stage 1. The way I view myself is, I know I'm not a genius, so I do what I can to mitigate opportunity for mistakes, which means keeping things as simple as possible. Sometimes complexity is required but my team makes excuses for complexity.

I recommend that you write notes on which aspects of the code are poorly put together, for your own benefit now, and also so you can remember it in the future.

I did this at a previous job, where the application code base had some very unique (I hope) characteristics. I haven't read my notes recently but it's comforting to know that I have a record of it.

That's an excellent idea.

I personally note all the code I use in multiple ways, even if I'm the only owner. General design and architecture especially helps in over-modularized environments. I think I had a similar modularized nightmare at my last job where each file was split into 3 files too many. Taking notes on how they connect and even drawing our the graphs can help a lot.

Depending on how it would be received by your coworkers (sounds like not very well), you could make a main design doc in each repo and maybe sub documents in separate namespaces.

From your 3 points, I can tell that there are bad programmers in there, and it sounds like it's not you... if they cannot improve, you need to move on.

it sounds like it's not you... if they cannot improve, you need to move on.

Yes. Whether or not you are a good programmer is irrelevant in this particular situation. This appears to be a mismatch in programming philosophies. There's more of them than there are of you. Look elsewhere. Most of us have done that several times in our careers. It's no big deal really.

Move on. Life is too short.

You (or them) being a bad programmer or not is not really the question (even though you seem to be right).

I think you should step back from the code and talk to the people. Ask them why they did something like this or like that. Show them that you value their work but that it is a shame that you can't fully enjoy it.

Do not start a situation in which it is them vs you.

If you have to ask then you probably are!

But that's okay, know is half the battle. Maybe programming isn't your thing.

It took me a while, but I finally figured out I was disenfranchised programmer!

Now I write stock/options/futures algorithm and I'm super happy! (Oh and I don't care if my code is good or not as long as it makes money!)

I don't have anything to offer other than sympathy, but I just wanted to thank for this post.

I'm going through exactly the same thing as you, and asking myself the same questions. You're obviously more experienced than me, so it's actually reassuring that this happens to more senior people.

Don't waste your technical skills trying to solve personnel/cultural problems. Either get the point across to your supervisor, or leave. Of course, the supervisor may be part of the problem.

I don't think it is a matter of you being a good or bad programmer. If their setup is working for them and you don't like it then it's just a bad match.

Have you jumped in to understand bottom up how vue is structured? You’re just not used to the patterns it sounds.

Yes, I've worked on a lot of Vue projects now, this is unlike any other I've seen.

Well all three points are big red flags in my opinion I would also move on

Get another job. This one sounds like a toxic hellscape.

How long have you been there?

I started in October.

Ask HN: Am I a Bad Programmer?