7 ms·
Ask HN: Am I a Bad Programmer?
I’ve recently taken on a new job as a full-stack developer. In the past I’ve delivered fully completed projects without too much fuss.
I’ve also taken on legacy projects and been able to dive in and solve major bugs in old legacy code that other developers at those companies have been unable to solve.
The new job uses .NET on the backend and VueJS on the frontend. I’m not a pro at .NET but I’m familiar with the design patterns and I can read the code and understand it, and I’ve been able to make contributions in the weeks I’ve been here. Other than engineering themselves into a special kind of microservice hell, the code is workable.
The front-end code is infuriating. I’ve never seen anything so fragmented and modularized, and I don’t mean in a good way. I’ve never run into any project that I couldn’t work with until now. It’s only Javascript, I should be able to grasp what they have going on, but there are several problems that stump me:
1. They always use the most terse and clever syntax possible; without any comments or documents, I’m having a hell of a hard time figuring out what they were thinking when some code was written.
2. The frontend guys are somewhat hostile. If I ask a question, it’s always “simple” or “easy” and I get a terse answer that doesn’t really take the details into consideration. I feel like they don’t want me around and it’s nigh impossible to get someone to actually jump on a screenshare and pair on something.
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?
In a nutshell, am I a bad programmer? Am I an asshole? Am I just getting old? Time to quit? Feeling burned out already and I need to figure something out.
- draw_down 6y agoIt truly doesn't sound like you're a bad programmer. It does sound like the frontend codebase is organized in a way that you hate, but maybe not necessarily a shitshow. I'd say give it time, and maybe try to make friends with one of the frontend people, to perhaps gain insight why things are done the way they are. Eventually if you bang your head on this enough it should become less frustrating, though you will probably always hate parts of it like the super DRYness. And I'm with you, clever code sucks. Some frontend people really like the golf, I don't know why.
- pettycashstash2 6y agoHave you jumped in to understand bottom up how vue is structured? You’re just not used to the patterns it sounds.
- potta_coffee 6y agoYes, I've worked on a lot of Vue projects now, this is unlike any other I've seen.
- phendrenad2 6y agoProgrammers, 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.
- potta_coffee 6y agoThe 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.
- Gibbon1 6y agoThe 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.
- potta_coffee 6y agoThat'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.
- chaganated 6y agoMove on. Life is too short.
- Minor49er 6y agoHow long have you been there?
- potta_coffee 6y agoI started in October.
- thagerty 6y agoDon'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.
- patatino 6y agoWell all three points are big red flags in my opinion I would also move on
- J-dawg 6y agoI 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.
- bjourne 6y ago> 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.
- potta_coffee 6y agoI 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.
- jbn 6y agoFrom 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.
- simonblack 6y agoit 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.
- tubularhells 6y agoGet another job. This one sounds like a toxic hellscape.
- chad_strategic 6y agoIf 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!)
- eecks 6y agoI 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.
- itronitron 6y agoI 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.
- potta_coffee 6y agoThat's an excellent idea.
- jjice 6y agoI 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.
- bvcvbuiy 6y agoYou (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.