4 ms·
More of a legacy code thing, but in my experience a lot of devs will race towards labelling legacy code as "bad" code because it doesn't meet some superficial s
by Vanit 4y ago
More of a legacy code thing, but in my experience a lot of devs will race towards labelling legacy code as "bad" code because it doesn't meet some superficial standard. If I had a dollar for everytime I heard this from a dev as they start discovery on some new feature or necessary refactor, only for them to come back and say they realised there's a good reason the legacy code is the way it is. I was certainly guilty of this too when I was a junior/mid.
- epgui 4y agoI think people also have a hard time telling the difference between “bad code” and “unfamiliar code/patterns/abstractions/etc”. Familiar thing often “feel better” to us even when they’re quite bad. I’ve seen that bias at play when new people join a team.
- flippinburgers 4y agoBut has anyone ever looked at a program that was structured after "clean architecture" principles as outlined by good-ol' uncle bob and thought "yeah this was a great idea!". The answer is no.
- josephg 4y agoOh goodness, I've been programming for 30 years and I'm still in this picture and I hate it. I have to fight the temptation to judgement all the time when I read other people's code. Their code uses too many classes? Bad code! Its overly factorized? Under factorized? Too many dependencies? Too much reinvention of the wheel? All these things are obviously evidence that whoever wrote this code is inexperienced (and they probably have deep character flaws). I'm sure other people feel exactly the same way about my code, too. Its frustrating and dumb.
- vsareto 4y agoGood/bad code has changed radically over time, and there’s still a bunch of diverse opinions on it. It also means different things in different ecosystems. At the end of the day, the easiest way to deal with it is to find a social circle that shares your opinions. That’s the only situation where you get enough direct, useful feedback over time on whether something is good or not. This is actually better because you’re bringing the person back to the forefront instead of trying to judge code as objectively good or not
- epgui 4y agoFWIW, my learning velocity has typically been the highest when I’ve put myself outside of my comfort zone, in experienced teams. This could mean working with (competent) people who think differently, or working with a different language (my most formative was Clojure, as someone who had never even seen a lisp before), etc. Initially I bend over backwards in near-total deference, and over the course of a few months I start to feel like I’ve gained perspective. It’s the only way I’ve found to not carry the baggage of “my way” into new situations.
- epgui 4y agoI don’t know if that’s really something you can ever grow out of, honestly… And I feel the same way. But if it’s any consolation, it’s pretty much the same with any cognitive bias: you can never totally eliminate them, but you can make progress, and the first step is just knowing about it! :)
- hotpotamus 4y agoI work with 3 programmers who have worked together for 30+ years (probably a bit rare in any profession, especially tech), and if you talk to any 2 of them separately, they'll talk shit about the 3rd's code. I doubt they'd be surprised if I told them that.
- nerdix 4y agoThey probably talk shit about the others' code to their faces. After 30 years, they are probably like siblings. All the politeness and sugarcoating is gone. Say how you feel and move on. They are also probably intimately familiar with each other's preferences and they likely just don't care. "Bob doesn't like it when I do this but fuck him"
- hotpotamus 4y agoYeah, 2 of them bought houses in the same neighborhood and I generally think of them like siblings.
- roelschroeven 4y ago> I have to fight the temptation to judgement all the time when I read other people's code. Me too. But... Every so often it happens that I read bad code, with functions that are too long and complex or too short, or with misleading variable names, or a way too clever class structure, or whatever; cursing the person who wrote that code ... only to find out it was me who wrote that code. It makes me put things in a different perspective. I try to judge not too harshly.
- p1necone 4y agoI find I also often have the opposite problem. I'll encounter code that is actually poorly written and hard to understand/modify, but by the time I've put the effort into working out what's going on it's hard to properly remember just how much work it was to get to that point of understanding and so I don't actually fix it. It's like Stockholm syndrome for developers.
- ioseph 4y agoOn the flipside, if I'm learning a new paradigm all my new code feels like "Good code". For example recently learning RxJS and writing a complete mess of state spread across my app feels good because its "declarative" compared to the ugly previous "imperative code". I think part of it is the reward of the learning process itself, but I can see it being an addictive cycle.
- bluefirebrand 4y agoThen again, I also encounter people who use all sorts of patterns and abstractions that they learned in university, the code is actually an overengineered mess, but they refuse to believe there's a problem because they followed all of the patterns! After all how could code be bad if it follows a pattern?
- doctor_eval 4y agoAgree with everyone else and you want to go easy on people but then you get code like this: public class C { int x; public C(int x) { int x; this.x = x; } } and you waste an hour trying to work out why C(5) is not working as expected because god knows who would do that? (summarised from a real life example)
- arethuza 4y agoI something similar where a colleague (a long time ago) realised that someone had overload string assignment in the C++ code he was debugging to do something "special" depending on the value of the string.
- doctor_eval 4y agoAn old boss of mine used to say, "Sometimes I shake my head and wonder. And sometimes, I just shake my head."
- sheepybloke 4y agoI think it's also because you don't have the context of the full project. For example, a project I worked on had a lot of tacked on functions because every couple of years, we'd get pulled in on a contract to update the software. So you'd go in, complain about the software, realize why someone did it the way they did, and then add another chunk to it. You didn't like how it was, but you understood why it was the way it was.
- deckard1 4y ago> they realised there's a good reason the legacy code is the way it is. I was certainly guilty of this too when I was a junior/mid. It's one thing for a junior dev to do this. But try working with a bunch of amateurs that somehow got promoted to lead because they kind of worked with some technology at their prior job. It's amazing watching a company replace domain expertise with superficial framework-of-the-day knowledge. Especially knowing that these devs will move on in a year escaping the consequences of their actions.
- IshKebab 4y agoIf I had a dollar every time some bad old code broke because people never maintained it I bet I would be richer!