5 ms·
+1 for "all the time". Today I have been debugging a critical piece of the system which is written in Python (none of the rest of the system is) and largely ha
by zimpenfish 2y ago
+1 for "all the time". Today I have been debugging a critical piece of the system which is written in Python (none of the rest of the system is) and largely hasn't been updated since 2020 and, you'll not be surprised, has no comments, no documentation, and a fucked up deployment system which makes me cry every time I have to think about it.
Last week I was debugging some similarly uncommented, undocumented, Go code from 2020 written by lunatics that is also a critical piece of the system.
It hurts.
- morkalork 2y ago+1 here too. The situation always comes up after some kind of fucked up acquisition. Nothing like inheriting an entire code base built on someone else's stack when all the original developers decided to quit or were laid off. Ancient versions of Python and Java, deployment done by pull and pray. Multiple versions of the same service in different places because they were half way through some modernization when it all came to an end. Fun stuff. Getting your bearings fast is a real skill.
- thatguysaguy 2y agoYeah from the title I thought this was going to be about leetcode problems, but this is truly something that comes up regularly. Where are these dev jobs where _don't_ have to figure out some mysterious issue in a barely maintained GitHub repo semi-regularly?
- evoke4908 2y agoYeah, I feel like jobs that don't require you to reverse engineer a bunch of stuff are the exception, not the inverse. Hall, I do greenfield embedded programming. Most of the code I touch is completely new; the entire codebase has been replaced and rewritten by me over the last three years. Not one other developer has contributed any significant amount of code. Even then, in this scenario, I'm still reverse engineering some arcane undocumented code at least once a week. Nobody ever documents their libraries properly so I have to rip everything apart to see how it works. Or I need to adapt some vendor example code or a GitHub repo into a slightly different form. Even just existing in the ESP-IDF environment I have to dig into the core code to figure out what the hell it's doing and where these error messages come from. If you can't read someone else's Gordian knot of undocumented code, I'd argue you are probably not very good at writing code. Reading bad code is a vital part of learning to write good code, and is generally just a fundamental core skill that every programmer needs to have.
- tayo42 2y agoHow are you defining bad code? Imo unreadable and undecipherabe code is one subset of bad code.
- dahousecat 2y agoI would argue, that in that vast majority of cases, the readability of code is the single most important metric.
- amluto 2y agoIf I encounter third party code that is terminally broken, I don’t really care how readable it is, except insofar as I can probably tell it’s terminally broken faster if it’s more readable.
- VyseofArcadia 2y ago> Where are these dev jobs where _don't_ have to figure out some mysterious issue in a barely maintained GitHub repo semi-regularly? Oh, my job is one of those. Our code is in Perforce.
- anankaie 2y agoThis is the most Software Engineer answer. Emphasizing only the distinctions that make no difference :D
- honestAbe22 2y ago[dead]
- icedchai 2y agoA repo would be nice. I was recently given a 500 meg .zip of "backend stuff" and asked to figure out what's going on. No repository, no history, the read me is useless, the APIs look like they were built by rabid animals...
- dudleypippin 2y agoMy favorite description of this sort of setup is "coded by vandals".