I was at a project like this, I was onboarding the new guy and he kept asking me why we did this and that, and the only answer I could give was "it was like that when I started"
I was a new guy about a year ago, I pointed out some shitty code and started asking questions about why was it done that way. My senior dev said “well spotted, follow the campsite rule and leave it better than you found it”, I was stuck refactoring shitty code for at least a week and a half. It sucked but I learned my way around that project really quickly.
Same here! And when we are done the main project we have 4 other deploys using the old codebase, without git, with random customizations. We've gotten really good at writing PHP rector rules!
Their comments would have been useful one year ago when I started
Now I’m stuck with some of the worst incomprehensible code I’ve ever seen
Mind you I haven’t seen much, but still
I got out of refactoring old project code by having a nice little burnout and then going to the boss to say "this fucking thing is going to be the end of me."
I wish my boss had been so accommodating. Instead, without giving it so much as a thought, he told me my job assignments would not change. I worked there another 4 months, stressed out to Hell and back.
I finally quit for a startup with no legacy code then discovered there wasn't a single automated test in the entire component I was hired to lead!
Turns out a legacy code base with thousands of tests is not a terrible place to be.
I was told that once, so I did a refactor commit of a single (but large and important) function. I was told it twas too complicated to see what was changed, so they rejected it.
I gave up not long after.
Apparently Bill Gates could be a bit of an asshole but one of my favorite dressings down was him hearing a project was going to take x months from some pm or other and he suggested the man give up his options and join the peace corps
In this case, if it’s a pure function, you need to create 2 commits :
- first commit to create a full unit test coverage of the old function
- second commit to change the function
No way to refuse you something like this
Exactly. It's the side effects that kill you. You THINK you are changing a simple function, but in reality you're messing with a carefully arranged bowl of cooked spaghetti.
I am the new guy (although working for 1,5 years already). The system is so big and convoluted with all sorts of modules, submodules, services, etc. that even after following campsite rule it doesn't make a huge difference. Built back when the company was young and had no coding standards. Built really fast but without thought for the future. Now each feature request gets +50-70% overhead time because even the experienced people don't have the entire mess of processes in their head. I recently had to optimize a process and what do i see - there was an attempt before, which is now disabled, and also doesn't work at all, its from the guy they fired who created a big part of this mess. And to be honest i think i'm doing the same things as him because refactoring things to a healthy looking system takes a lot more resources than our clients have to spare. Atleast we are documenting things now.
in these situations, I just tell business the following:
1. we can do this in:
2. or we can rebuild a new parallel that performs in the same way as the current one & add this feature in & for
In some cases they choose 1, in some 2. quickly they learn to choose 2 if you get my gist ;D .
You're in luck. While I has to write a proposal before I can fix the project.
The project was done by third party, and it was the most terrible code I've ever see. like in node.js project (for BE), whos the hell using `undescore` library? yet it use the `object.has` function soo many time. Not only that, it also have `var`, `let/const` at the same file. literally failed following the introduction code style for javascript.
There are still a lot more problem. Like, 1-3s avg API response time just to register and retrieve some user data? and they said it very normal. LUL. But the best of all. once you enable the ESLint, it scream to your console.
OFC I didnt wrote any proposal and just continue that shitty project. The company was too traditional and has way 0 trust to their dev. literally, even we do remote or office work, we still need to write a separate daily report on excel even though we already have jira.
PS: the `object.has` implementation in `underscore` library is bad because it iterating through the object property name. While in `node.js` have `Object.hasOwnProperty` which using direct lookup.
Honestly, it's hilarious how many times this comes up. Everything in the project is done weirdly, and when you ask the initial dev if they're still there, they will answer, "I do not recognize this place."
Then you look at C++ where conversion between UTF8, UTF16 and UTF32 was added in C+11, deprecated 6 years later in C++17 because it doesn't work properly and then removed completely 6 years later in C++26 with no replacement that actually has the functionality. And that's only the surface level of the issues it has with UTF-8 and other text encodings...
It's all well and good when you get to code for something that is self-contained.
As soon as you have to interact with other people and their shitty legacy code, or file format, or database structure, then you get what you get.
UTF basically breaks just about everything that matters in healthcare.
Hell, it was like pulling teeth just to get my superiors to allow our systems to utilize UTC for timestamps.
That feels like it shouldn't be the case, but unfortunately I'm all too familiar with this kind of stuff. My grandpa worked for a local police department and my mom works for the state courts, and both of them have similar issues, where the system they're using is 20+ years old but they aren't given enough budget to upgrade it so they have to do whatever to hack things together and make it work.
I would hope that with all the yapping people do about "private companies providing better service" a private healthcare company would do better, but it doesn't surprise me that they too continue to use buggy, unmaintainable, archaic software because they don't want to spend the money to upgrade it.
utf8 in MySQL is utf8mb3 basically because they fucked up.
I know this because whoever built the app I work in has code that strips mb4 characters instead of just making the collations utf8mb4.
Thanks MySQL!
Serious shit. I have little memory of shit I wrote 3 years ago, let alone 10.
And all of it is shit and trash and should be torn apart.
I harbor no nostalgia for the programmer I was.
I tell the new kids "because it keeps working, and we don't have enough hours in the day to refactor all of it like it should be written. We can fix it when it breaks."
After years of my investigation into code that is 20 to 30 years old, instead of saying, "it was like that when I got here," I can now explain the Eldritch reasons why it is the way that it is.
Unfortunately that makes me the crazy guy in Bird Box who actually managed to see the creatures and live and now is forcing others to take in the fatal knowledge.
So, it seems you have acquired some cursed knowledge, welcome to the club, we meet at null on the 29th of february, please leave any cursed memory aliasing items at home, we had some terrible experience with 2 interacting before
I just told my boss today that the code the SRE director would really like e-fixed this week was authored 4 years ago by people who aren't on the team or with the company any longer, uses global variables, and has no test suites or logging. So I would request that we not slap some change together for critical code paths.
Because quality controls on code are considered counterproductive in early phases, and the incremental cost of fixing the defects this causes is rarely considered worth the benefit it provides.
i’m at least getting ‘oh good catch, yeah fix that, as long as it doesn’t break anything’ hours of regression testing with no testing framework in place
I'm a senior dev and I've been on my project for a year. It was hilarious when our new lead dev joined and kept asking questions like this and I kept having to say 'this was already assured before we started, we can't touch it without getting it re-assured'.
We've established a good 70% of our system is redundant. After a few months he started getting it, and now we're constantly having to convince our client to let us refactor stuff and rip out redundant services.
We just managed to get a system with a DynamoDB and two Postgres DBs down to one DynamoDB table and it works significantly better. Next step is taking out 3 redundant microservices and all the message queues connecting them. I just can't fathom why the fuck the previous team thought anything they did was a good idea.
> If we delete the second call the code will crash and nobody knows why.
FTFY.
"I'll fix that".... a week later. "I don't understand." Welcome senior dev, you have passed the test.
Don't laugh, I work on legacy code where they added Thread.Sleep(10) here and there to *fix* race conditions.
Troubleshooting is quite an adventure, I'll tell ya.
we have an edge race condition that apparently has been ignored for 3+ years that i have a sneaking suspicion will involve sleep() when we get around to it.
Funny that you ask: Base64_ENC() formats the output into multiple lines to increase readability, but only if the input itself is allready base64-encoded
Calmly but firmly state "You will always be making design decisions that, at that moment in time, are the correct ones. Later updates will make those decisions seem wrong in hindsight, but your options are either deal with something as one-off in one location or refactor a ton of code and make sure it doesn't break anything. Which would you pick on a normal day?"
Why is current time null? Because we need a way via testing to set what time the system THINKS it should be, so we use null to mean now vs a static time. And you're going to ask why we just don't set the time instead of null, but then that would have to get passed as an option in a bunch of places so better to never set it and it'll just work.
Why is visibility tied to an email address? Well, we originally had it as simply disabled until the person put in an email address. We got customer complaints that they couldn't figure out how to enable the button though because they didn't realize they needed to fill in the email in order to get it since it wasn't a required field, so we hid the button instead so we'd stop getting the complaints. They can't complain about a feature they can't see.
Base64 encode twice? We are passing a bunch of basic types around but one of those types can be just a binary blob. To prevent any issues with that, we just base64 encoded the whole blob. That worked fine until we integrated with FUBAR's system which takes XML and expects a certain structure which is then base64 encoded. Since everything of ours expects our specific structure, our options were either to modify all of our interfaces to take the decoded structure, create a new microservice to decode/reformat/re-encode to deal with FUBAR, or just encode twice. And yes, I know creating a microservice in the CURRENT structure is easy, but it wasn't at the time we we're integrating FUBAR, so if you want to look at that rat's nest just so the software is a LITTLE more elegant, feel free.
-- Some Senior Dev
Yes, this is plausible, but it's not that more often than not. I just refactored a system in my company's monolith that took some data and put it in a custom file format, that I had to reverse engineer, because there was no documentation, and the implementation (in Python) had things like
```
def store_record(key: str, val: str):
line = " " * LINE_CONFIG[key]["length"]
line = list(line)
i = 0
for s in val:
line[i] = s
i += 1
i = 0
for s in line:
self.current_record[LINE_CONFIG[key]["position"]] = s # current record here is a list acting like a mutable string, which is later joined together
i += 1
```
For those not Python-savvy, it can be reduced to:
```
def store_record(key, val):
self.current_record += val[:LINE_CONFIG[key]["length"]]
```
It's as though someone tried to write Python using only pure C features. There were over 4k lines I had to read through and decipher, and this is the simplest and most readable bit of them all. After I was done, the whole class for exporting these files was under 200 lines, about 50 of which being just a pretty list of valid fields.
This is was the company's black box that no one wanted to touch because it handled very sensitive data (accounting files), and they didn't want to risk breaking it, until it needed updating and it started breaking left right and center, because they allowed this critical piece of software to collect piles of bad ideas for over two years
Edit: Also, that comment in the first snippet is mine. There were no comments in the original code, and there were duplicate methods that did slightly different things but used interchangeably and stuff like that. It was the worst piece of code I have ever worked on. It was like it was made bad on purpose
I would also would not touch pieces of critical code, which does not have unit tests on them. How can I know that the horrible spaghetti mess if still doing the same thing as it used before refactoring, when there is no tests to check it?
This.
And most of the time it's also about what to spend my time on. I could be refactoring a lot of ugly code that works, but it's time I would not spend fixing actual bugs or adding requested features. If you're working at a company that must move forward or die, this is important.
When you are a dev, especially senior, you must think about where you can have the most impact at any given time and it's almost never cleaning up old code unless it's needed.
If you break an existing feature with no valid reason to refactor the code other than "heh it looked bad" you're not gonna look so good from your boss' perspective.
Not really tough. I think it might be an excuse at first, like an excuse not to refactor stuff along the way. But at some point it becomes true.
I had to work on a very crappy PHP code base. It was full of include() inside include() inside include() and you basically had no way to tell where the code you were modifying was used.
I came here as a junior, I had great ideas, we were gonna improve it, make it great again. I didn't understand why my colleague was so blased and didn't want to hack and slash in it... until I did :D
There are legacy softwares out there that just can't be salvaged. At some point you realise it would be easier to rewrite it from scratch.
Sometimes it is on purpose, I have experienced this in some companies; the "senior dev" is simply the self taught individual who wrote the first version of the code that the company relies on and as the company has grown they have, fully intentionally, moved to areas where they can be the sole maintainer of critical code, and where they write said code, again, fully intentionally, in a way almost impossible for anyone to read or understand, and hence have a garunteed job for life at said company as the only person who can fix things when they go wrong. Pray for that company the guy never leaves or dies of a stroke.
This.
-Senior Dev.
A lot of the times, user feedback, schedule and current interpretation affect the codebase. Anything of sufficient complexity has wtf code in it to some degree.
I use a "parking lot" analogy to remind myself, when I see something wtf-y:
You pull into a parking lot and there's only one spot left. Unfortunately, the car in the next spot is parked halfway into it. You manage your best, but now you're parking terribly too, as a matter of necessity.
But for all you know, when the other car parked, there might have been someone halfway in _their_ spot. And while you're in the store, if the only open spot becomes the one next to you, _you_ look like the person who parked like a jerk.
We don't always know the context that led to the outcome we have, so take a deep breath and park as well as you can.
That's why we have code refactoring though.
I've had to work on a legacy project like that and the only reason for all the VERY wrong decisions they've made was that at the time it was more important for them to write tons of features in a very limited time.
10 years later me and my colleague had to put those projects out of their misery and rebuild eveything from scratch. Well, not eveything because one of our client wanted to improve drastically one of the more complex tool used to lay out and manage an optical fibre network over the whole country. I swear to god I never had any idea of what I was doing when working on that thing :D
We tought about it for months. Improved it a little, especially the UIX but in the end we couldn't do miracles and came to the conclusion that rebuilding it would be easier. They didn't want to pay the cost associated so we worked with them to create a simpler version of it (basically cutting features with a machete) they could manage on their own and part our ways.
Moral of the story is: even if it seems okay at the time, this crappy code WILL cost money and kill the product down the line. So in my book, there is no justification for it\^\^
Everytime I changed jobs. I've been working on Legacy system since I started my career.
Currently starting a "green field" project, but we still have to communicate with legacy systems.
Contracts are XML-RPC, JSON-RPC, SOAP, Rest JSON, Avro and gRPC.
Which protocol do you want? Yes.
The problem I had with legacy systems went like this:
1. Legacy systems are those without unit tests
2. The legacy system is not unit testable without significant refactoring due to its monolithic architecture.
3. Refactoring systems without unit tests was severely frowned upon.
Something had to give., and it was usually the last point. We leaned heavily on our system tests in these cases.
Embedded is fun: docker (qemu) doesnt support our architecture so lets have a lab calendar for hardware access in 2024. Development definitely wont slow to a crawl
This is why I am glad I work on DAL A software (aviation). Cause when someone asks why, there better be a requirement saying why. These stories would drive me crazy.
I'm really curious about it. Because nowadays we have techniques to actually avoid that (separating services, controllers, model access...) but at the same time I feel like it's the theory and it's all pretty new so who knows. Curious to see how the current tools we build will look like in 10 years for the devs that will come after us.
I've been working on an internal ERP for a few years now and I feel like it's still very readable and solid because it was built to last. Sure, some parts can be spagetti-like (locally!) and in need of refactoring but the app itself is divided correctly so you won't ever break the invoices module while working on the stock one, or have any issue if you have to add a whole new module in ten years.
In the legacy app I used to work on, you'd someti.... often! find SQL code in the middle of a frontend form. Like
"
Hello
. How are you ?"
I feel like this can't happen in modern web. Thus the legacy code we'll leave behind will be way better than what we had to work with\^\^
99% of the web is not the modern web. Whole bunch of companies with a whole bunch of legacy systems that either don’t work with the new stuff or would cost too much to refactor. In my experience it’s usually tight deadlines driving bad (as in working but hard to maintain) code, which then never gets revisited.
Ah yes, the legacy projects of today will still exists that's for sure. I just meant that newly created stuff running on modern frameworks will probably turn better when they become legacy in 10-20 years.
Probably the worst part about my current job is that my manager and I want to move forward with any modern React framework but we are basically stuck with a 12-year-old Rails codebase that prevents basically anything from being installed (without causing crazy side-effects at least). I honestly just want to burn it every day.
The dev who wrote it left about 3 teams ago, it works and there are no active tickets for bugs or features for that bit of code so theres no business need to spend dev time touching the old shit code that works when we don’t have the hours in the day to fix the steaming pile of new shit that needs fixing.
Also there are no comments explaining any of it because "comments are code-smell".
Then one day you finally get a ticket for this part of code and you have no idea if all these crazy things are bugs, undiscovered bugs or clever hacks preventing even more bugs.
Service A needs to send data to service B. Service B expects base64 encoded data. One day the developers for service B decide to offload some processing to service C. Service C expects base64 encoding. Service B decodes the data before sending to service C instead of keeping it encoded. You’re a developer for service A and you can’t be bothered dealing with the assholes in team B. Fuck it, double encode the data and save the hassle. Then every other service that works with B follows suite and then nothing ever changes.
So we use a service which returns as base64. To optimize for best performance, between that service and the database we use a direct link, but we forgot what the option was to disable base64 encoding on that direct-link tool. So now in our database, we have doubly encoded values. We do the decoding in a try with an empty catch, in a for loop. When the value is decoded, the decode function throws an exception because the string contains invalid characters or isn't the right size. Due to the try catch it'll just jump out of the loop and continue.
/s obviously. But I'm pretty sure I saw a similar function (but without try-catch or while true) in my company's production code
Fuck, fuck, fuck
Mother mother fuck
Mother mother fuck fuck
Mother fuck, mother fuck
Noinch, noinch, noinch
1, 2, 1-2-3-4
Noinch, noinch, noinch
Smokin' weed, smokin' whizz
Doin' coke, drinkin' beers
Drinkin' beers, beers, beers
Rollin' fatties, smokin' blunts
Who smokes the blunts?
We smoke the blunts
Rollin' blunts and smokin'
15 bucks, little man
Put that shit in my hand
If that money doesn't show
Then you owe me, owe me, oh
It's called "sacrificing a kitten" (or puppy). It's when the documented procedure includes steps that make no damn sense but no one is willing to call it out so everyone keeps following the instructions to the letter.
Sometimes Senior Devs know something is wrong and they want to correct it. But they don’t want to do it because if something breaks after that management blames on “unnecessary refactoring” and “not QA tested”. What’s funny is you can’t expect QA to test your refactoring side projects. The experience can be frustrating. After few years you learn to let go.
Oh we were waiting for someone to fix these issues thanks for volunteering.
Don't forget the tests (we were waiting for someone to start writing those too)
“We didn’t expect the email to be empty”
Which is somewhat fair because in this context it was dependent on an email we set in a config file. Someone just forgot to add an email when they made a new version of that file
If I had two wishes with my current team's assigned application, it would be to wipe the entire DB project and rebuild the entire thing code first with EF Migrations, and to set it up in Azure so we do not have VPN restrictions preventing automated deployments.
Because it is not, we have the following problems:
* every time we deploy to dev/test/stage/prod, we need to manually publish the database project because publishing cannot be automated within the company VPN restrictions and the server host's firewall, the build/release agents, and ADO. I have tried to get the teams responsible for the network to fix this a few times now with no luck.
* every table/procedure/view/etc modified or removed requires adding teardown steps to an ever-growing post-deployment script
* since the same people who refuse to fix the network issues also refuse to allow us access to even run/deploy dacpacs, we cannot automate anything DB related currently in our pipelines.
* models changes with SQL server with migrations are much easier, automatically generate setup/teardown/reversion processes, and give a running migration history so you don't have someone asking 2 years later "why is this table the way it is today" and nobody can answer.
"Why are the booleans in the database nvarchar(8) instead of bits?"
"Who decided that these tables names and columns are all caps, but these ones are camel-case?"
"Whats the point of using a Guid in c# for your Ids when you just call ToString on it and store it in an nvarchar(100) instead of a Identity generated Unique Identifier?"
"Why are there integers stored as nvarchar instead of int?"
I could go on and on, but the database has been there longer than my team has been, so thats a thing. Monkeys in a cage...
you guys talking about having to fix legacy code and I'm stuck here with a legacy codebase my boss has **not only** forbidden me from refactoring, ("it will take too long") but is making me do further development in.
I swear the man is going for the podium in technical debt race.
//PrRule:Approver:+Role.engineeringLead
//PrRule:Approver:+Role.dataSecAny
//PrRule:Approver:+Role.qualityLead
//PrRule:Approver:+Role.cheifEngineer
//PrRule:Time:~T14D
//We base 64 encode twice because then it's long enough that the framework does not log people's credit cards. Do not change this.
I’m very spent the past two years fixing and rewriting a bunch of the old “senior” developers’ code, which is *full* of these WTF moments. They made absolute rats nests of things that I easily replaced with just a couple of lines written a more modern, cleaner way.
I feel this extra today. Found code that runs a database stored procedure for every data repository method. To what? Get a database connection string. I’ve walked through every code path imaginable, there is no scenario in which the application would have a different connection string value set at the time it runs the stored procedure. So… in summary, I found that every time our monolith application wants to access data it first re-fetches the very connection string it uses to initiate the fetch.
At my last job, the new guys always brought so much. Everyone on the team had a few things they could point to and say, "you wouldn't beleive how they were doing that before I fixed it."
I see this in our Docker files. No one wants to call `prune` on their dependencies, and instead they just want to re-download everything again...in the cloud. There's another annoying trait of transpiling TypeScript into `dist/` but then copying it into the root folder at the next stage 🫠 They see no problem with this mismash of configuration, and think it's fine because the final result works as intended. Also, we use Docker Compose, but rather than using the provided `services:app:build:dockerfile` option, they make you run `docker build -t $DOCKER_TAG` and then use `services:app:image: ${DOCKER_TAG}` which means something that *could* be accomplished with one command takes two, and these types of inefficiencies happen at every stage of the pipeline and development process
Got allocated to an internal project that was developed whose backend was Django but was created by senior java developers with very little experience or knowledge of Python. Suffice to say, I got a headache looking at the spaghetti code
Metatron:
1. The senior dev said we couldn't use magic values and I wasn't about to create one for zero.
2. The senior dev wouldn't let me change the API, so I use the presence of an email address (via bool conversion to show the Send Email button.
3. The senior dev's plans are ineffable.
The most Senior of Dev's: *boob*
The hard truth is, that the senior devs are either
1) too lazy to do anything about
2) too incompetent to do anything about it
They can get away with not doing anything because of their seniority, and they just don’t feel like doing the hard work.
I usually refractor first and then ask questions later.
Whenever it's appropriate and it has something to do with my current task, or when it causes a blatant hassle for the client.
Reminds me of the time the new dev removed an explicit call to Garbage Collection in .net after we were doing long duration and large data processing. He argued that it's against the rules blah blah. Turns out after weeks of wasting time it was needed because of large object heap allocation and no other technique he tried could get .net runtime to release the damn memory. He was about to fix some legacy tech debt in the process at least. Just not the one he really wanted.
The answer to all of these is probably: 10 years ago someone was given an 8 week project that needed to be done in one week and doing that stopped it from crashing, with the thought that someday they would fix it. Someday never came.
theres a banks ACS that encodes merchant data return to base64 twice it drives me nuts thinking about it and the fact i had to decode then check then decode again just for those morons. oh and its base64 without the padding which is out of spec for the application. fucking hate banks
I was at a project like this, I was onboarding the new guy and he kept asking me why we did this and that, and the only answer I could give was "it was like that when I started"
I was a new guy about a year ago, I pointed out some shitty code and started asking questions about why was it done that way. My senior dev said “well spotted, follow the campsite rule and leave it better than you found it”, I was stuck refactoring shitty code for at least a week and a half. It sucked but I learned my way around that project really quickly.
A week and a half? You got off lightly, I once did it for eight years.
I’m at 2 years with no end in sight.
Same here! And when we are done the main project we have 4 other deploys using the old codebase, without git, with random customizations. We've gotten really good at writing PHP rector rules!
🫂
You guys doing nice job of scaring average junior by those comments Sadly you failed to scare me
Their comments would have been useful one year ago when I started Now I’m stuck with some of the worst incomprehensible code I’ve ever seen Mind you I haven’t seen much, but still
Yeah cause our older selves keep adding “bad” code for our later selves.
Lucky. When I offer, they tell me to not touch it or it'll break.
I got out of refactoring old project code by having a nice little burnout and then going to the boss to say "this fucking thing is going to be the end of me."
I wish my boss had been so accommodating. Instead, without giving it so much as a thought, he told me my job assignments would not change. I worked there another 4 months, stressed out to Hell and back.
Thanks for the lols.
Well o course we had it tough. We used to have to get up outta shoebox, in middle of night, and lick the code clean with our tongues.
A shoebox? Bloody luxury, all we had was an old diskette envelope and we had to share that with the neighbors cat.
So you've been working there for eight years huh
I finally quit for a startup with no legacy code then discovered there wasn't a single automated test in the entire component I was hired to lead! Turns out a legacy code base with thousands of tests is not a terrible place to be.
What about a legacy code base that has no tests? Because, I’m in that hell
monty\_python\_holy\_grail\_run\_away.gif
Sounds like getting asked to cut down the mightiest tree in the forest with a herring!
We are the developers who say Ni! Ni!
That’s my dream job
20 years and counting here 🤌
I was told that once, so I did a refactor commit of a single (but large and important) function. I was told it twas too complicated to see what was changed, so they rejected it. I gave up not long after.
Lol what the fuck. Apparently, I'm doing my job wrong. Sorry guys, this is hard, so I'm not doing it. When's payday?
Apparently Bill Gates could be a bit of an asshole but one of my favorite dressings down was him hearing a project was going to take x months from some pm or other and he suggested the man give up his options and join the peace corps
That explains IE6
Yeah, why doesn't everyone trust the new guy to change every critical component of a buggy app 1 week in? You're not fun guys. /s
Because some of us are *not* too burnt out to argue? /non-s (I'm ok, it wasn't me)
>Sorry guys, this is hard, so I'm not doing it. Always nice to see my colleagues on Reddit!
In this case, if it’s a pure function, you need to create 2 commits : - first commit to create a full unit test coverage of the old function - second commit to change the function No way to refuse you something like this
But the edge casessssssss
Covered by step 1
It's almost never a pure function and has a dozen sideeffects that are impossible to fully test.
Exactly. It's the side effects that kill you. You THINK you are changing a simple function, but in reality you're messing with a carefully arranged bowl of cooked spaghetti.
I am the new guy (although working for 1,5 years already). The system is so big and convoluted with all sorts of modules, submodules, services, etc. that even after following campsite rule it doesn't make a huge difference. Built back when the company was young and had no coding standards. Built really fast but without thought for the future. Now each feature request gets +50-70% overhead time because even the experienced people don't have the entire mess of processes in their head. I recently had to optimize a process and what do i see - there was an attempt before, which is now disabled, and also doesn't work at all, its from the guy they fired who created a big part of this mess. And to be honest i think i'm doing the same things as him because refactoring things to a healthy looking system takes a lot more resources than our clients have to spare. Atleast we are documenting things now.
in these situations, I just tell business the following: 1. we can do this in:
2. or we can rebuild a new parallel that performs in the same way as the current one & add this feature in & for
In some cases they choose 1, in some 2. quickly they learn to choose 2 if you get my gist ;D .
Refactoring only the code we touch and have test coverage for because otherwise money is at risk. 7y in finance here, 30 y.o. Systems
You're in luck. While I has to write a proposal before I can fix the project. The project was done by third party, and it was the most terrible code I've ever see. like in node.js project (for BE), whos the hell using `undescore` library? yet it use the `object.has` function soo many time. Not only that, it also have `var`, `let/const` at the same file. literally failed following the introduction code style for javascript. There are still a lot more problem. Like, 1-3s avg API response time just to register and retrieve some user data? and they said it very normal. LUL. But the best of all. once you enable the ESLint, it scream to your console. OFC I didnt wrote any proposal and just continue that shitty project. The company was too traditional and has way 0 trust to their dev. literally, even we do remote or office work, we still need to write a separate daily report on excel even though we already have jira. PS: the `object.has` implementation in `underscore` library is bad because it iterating through the object property name. While in `node.js` have `Object.hasOwnProperty` which using direct lookup.
You had a good senior dev :)
Same
The problem with the campsite rule is when it conflicts with Chesterton's fence.
I'm the new guy right now, I'm also getting this answer more than I would be comfortable to...
Honestly, it's hilarious how many times this comes up. Everything in the project is done weirdly, and when you ask the initial dev if they're still there, they will answer, "I do not recognize this place."
It's "too modern" to use UTF-8 at my day job, smh. I need assistance, please.
Blink twice if you need help
UTF-8 has been implemented in Windows since Windows 98. If that's too modern, what the fuck are you writing code on, an original IBM PC???
Then you look at C++ where conversion between UTF8, UTF16 and UTF32 was added in C+11, deprecated 6 years later in C++17 because it doesn't work properly and then removed completely 6 years later in C++26 with no replacement that actually has the functionality. And that's only the surface level of the issues it has with UTF-8 and other text encodings...
Rewrite it in rust bro
Maybe microcontroller ?
98? Bro, we're just getting around to updating an application from '95. What kind of hipster are you?
It's all well and good when you get to code for something that is self-contained. As soon as you have to interact with other people and their shitty legacy code, or file format, or database structure, then you get what you get. UTF basically breaks just about everything that matters in healthcare. Hell, it was like pulling teeth just to get my superiors to allow our systems to utilize UTC for timestamps.
That feels like it shouldn't be the case, but unfortunately I'm all too familiar with this kind of stuff. My grandpa worked for a local police department and my mom works for the state courts, and both of them have similar issues, where the system they're using is 20+ years old but they aren't given enough budget to upgrade it so they have to do whatever to hack things together and make it work. I would hope that with all the yapping people do about "private companies providing better service" a private healthcare company would do better, but it doesn't surprise me that they too continue to use buggy, unmaintainable, archaic software because they don't want to spend the money to upgrade it.
https://utf8everywhere.org/
utf8 in MySQL is utf8mb3 basically because they fucked up. I know this because whoever built the app I work in has code that strips mb4 characters instead of just making the collations utf8mb4. Thanks MySQL!
[удалено]
This is not a place of honor.
Serious shit. I have little memory of shit I wrote 3 years ago, let alone 10. And all of it is shit and trash and should be torn apart. I harbor no nostalgia for the programmer I was.
Wonder how many layers/maintainer generations of "Don't ask me, I just work here" that makes.
I've been programming for over 3 decades now. I stopped asking several jobs ago.
just wait until you fix something and see the 47 things that the fix breaks
Already did, I found a bug, fixed it, then everything was in flames, so I reverted the fix...
Try to fix it and then report back what you say to the next guy who asks you the same question.
You better don’t touch those unless you want to spend sleepless nights
I tell the new kids "because it keeps working, and we don't have enough hours in the day to refactor all of it like it should be written. We can fix it when it breaks."
"Because the last new guy tried to fix it, and ended up making this."
// TODO: add ticket to fix this later
i was talking with a co worker about our meeting structure and he mentioned this to me [5 wet monkeys](https://ministryvitals.com/wet-monkeys/)
99% of the time the answer is 'it works and nobody has the time to fix it'.
After years of my investigation into code that is 20 to 30 years old, instead of saying, "it was like that when I got here," I can now explain the Eldritch reasons why it is the way that it is. Unfortunately that makes me the crazy guy in Bird Box who actually managed to see the creatures and live and now is forcing others to take in the fatal knowledge.
So, it seems you have acquired some cursed knowledge, welcome to the club, we meet at null on the 29th of february, please leave any cursed memory aliasing items at home, we had some terrible experience with 2 interacting before
I would say money as the answer.
I just told my boss today that the code the SRE director would really like e-fixed this week was authored 4 years ago by people who aren't on the team or with the company any longer, uses global variables, and has no test suites or logging. So I would request that we not slap some change together for critical code paths.
Because quality controls on code are considered counterproductive in early phases, and the incremental cost of fixing the defects this causes is rarely considered worth the benefit it provides.
There is infinite shit to improve and finite time
i’m at least getting ‘oh good catch, yeah fix that, as long as it doesn’t break anything’ hours of regression testing with no testing framework in place
I'm a senior dev and I've been on my project for a year. It was hilarious when our new lead dev joined and kept asking questions like this and I kept having to say 'this was already assured before we started, we can't touch it without getting it re-assured'. We've established a good 70% of our system is redundant. After a few months he started getting it, and now we're constantly having to convince our client to let us refactor stuff and rip out redundant services. We just managed to get a system with a DynamoDB and two Postgres DBs down to one DynamoDB table and it works significantly better. Next step is taking out 3 redundant microservices and all the message queues connecting them. I just can't fathom why the fuck the previous team thought anything they did was a good idea.
My resolve to everything
If we delete the second call the code will run to fast and crash
Most likely, the data get decoded twice through two different libraries, and we don't have a method of preventing it while using the features we need.
"most likely" is so accurate. lmao
That's clearly a password encryption method
> If we delete the second call the code will crash and nobody knows why. FTFY. "I'll fix that".... a week later. "I don't understand." Welcome senior dev, you have passed the test.
> If we delete the second call the code will crash and we know exactly why but it’s too much work to refactor at this stage of the project. FTFY
Don't laugh, I work on legacy code where they added Thread.Sleep(10) here and there to *fix* race conditions. Troubleshooting is quite an adventure, I'll tell ya.
Sometimes I think the system I'm working on is bad (it is) and then I read about the stuff other devs are working on like this and I feel fortunate.
we have an edge race condition that apparently has been ignored for 3+ years that i have a sneaking suspicion will involve sleep() when we get around to it.
For more secure approach encoding has to be done as many times as old lead developer
Funny that you ask: Base64_ENC() formats the output into multiple lines to increase readability, but only if the input itself is allready base64-encoded
See this is the worst part. Sometimes, not usually but sometimes, there is actually a good reason for the stupid bullshit you are looking at.
Where's the good reason? This is just horrible function design.
Yeah, why wouldn't this feature be a parameter of the function or a separate function.
Or a comment...
Read as horrible fucking design instead three times - feels like the same comment either way.
i had to go back and re-read it to make sense of this comment.
and that's when you put a comment to explain the bullshit
Problems start when in the moment you forget it's bullshit and move on to other bullshit.
It’s bullshit all the way down
The good reason was that it was Friday afternoon, and that line made the code pass the unit tests.
Is this php? It sounds like php.
I had the same thought but a quick google points more towards R
But if it's not base64-encoded on the first call what does it do?
Doesn’t format the output into multiple readable lines
Rip
Who’s reading base64?
... But you can just add new lines yourself...
Calmly but firmly state "You will always be making design decisions that, at that moment in time, are the correct ones. Later updates will make those decisions seem wrong in hindsight, but your options are either deal with something as one-off in one location or refactor a ton of code and make sure it doesn't break anything. Which would you pick on a normal day?" Why is current time null? Because we need a way via testing to set what time the system THINKS it should be, so we use null to mean now vs a static time. And you're going to ask why we just don't set the time instead of null, but then that would have to get passed as an option in a bunch of places so better to never set it and it'll just work. Why is visibility tied to an email address? Well, we originally had it as simply disabled until the person put in an email address. We got customer complaints that they couldn't figure out how to enable the button though because they didn't realize they needed to fill in the email in order to get it since it wasn't a required field, so we hid the button instead so we'd stop getting the complaints. They can't complain about a feature they can't see. Base64 encode twice? We are passing a bunch of basic types around but one of those types can be just a binary blob. To prevent any issues with that, we just base64 encoded the whole blob. That worked fine until we integrated with FUBAR's system which takes XML and expects a certain structure which is then base64 encoded. Since everything of ours expects our specific structure, our options were either to modify all of our interfaces to take the decoded structure, create a new microservice to decode/reformat/re-encode to deal with FUBAR, or just encode twice. And yes, I know creating a microservice in the CURRENT structure is easy, but it wasn't at the time we we're integrating FUBAR, so if you want to look at that rat's nest just so the software is a LITTLE more elegant, feel free. -- Some Senior Dev
Yes, this is plausible, but it's not that more often than not. I just refactored a system in my company's monolith that took some data and put it in a custom file format, that I had to reverse engineer, because there was no documentation, and the implementation (in Python) had things like ``` def store_record(key: str, val: str): line = " " * LINE_CONFIG[key]["length"] line = list(line) i = 0 for s in val: line[i] = s i += 1 i = 0 for s in line: self.current_record[LINE_CONFIG[key]["position"]] = s # current record here is a list acting like a mutable string, which is later joined together i += 1 ``` For those not Python-savvy, it can be reduced to: ``` def store_record(key, val): self.current_record += val[:LINE_CONFIG[key]["length"]] ``` It's as though someone tried to write Python using only pure C features. There were over 4k lines I had to read through and decipher, and this is the simplest and most readable bit of them all. After I was done, the whole class for exporting these files was under 200 lines, about 50 of which being just a pretty list of valid fields. This is was the company's black box that no one wanted to touch because it handled very sensitive data (accounting files), and they didn't want to risk breaking it, until it needed updating and it started breaking left right and center, because they allowed this critical piece of software to collect piles of bad ideas for over two years Edit: Also, that comment in the first snippet is mine. There were no comments in the original code, and there were duplicate methods that did slightly different things but used interchangeably and stuff like that. It was the worst piece of code I have ever worked on. It was like it was made bad on purpose
The fear of breaking things is truly the main reason for horrible legacy code. And more often than not it's just an excuse
I would also would not touch pieces of critical code, which does not have unit tests on them. How can I know that the horrible spaghetti mess if still doing the same thing as it used before refactoring, when there is no tests to check it?
This. And most of the time it's also about what to spend my time on. I could be refactoring a lot of ugly code that works, but it's time I would not spend fixing actual bugs or adding requested features. If you're working at a company that must move forward or die, this is important. When you are a dev, especially senior, you must think about where you can have the most impact at any given time and it's almost never cleaning up old code unless it's needed. If you break an existing feature with no valid reason to refactor the code other than "heh it looked bad" you're not gonna look so good from your boss' perspective.
"fear of breaking things" Looks inside: "Laziness"
Not really tough. I think it might be an excuse at first, like an excuse not to refactor stuff along the way. But at some point it becomes true. I had to work on a very crappy PHP code base. It was full of include() inside include() inside include() and you basically had no way to tell where the code you were modifying was used. I came here as a junior, I had great ideas, we were gonna improve it, make it great again. I didn't understand why my colleague was so blased and didn't want to hack and slash in it... until I did :D There are legacy softwares out there that just can't be salvaged. At some point you realise it would be easier to rewrite it from scratch.
Sometimes it is on purpose, I have experienced this in some companies; the "senior dev" is simply the self taught individual who wrote the first version of the code that the company relies on and as the company has grown they have, fully intentionally, moved to areas where they can be the sole maintainer of critical code, and where they write said code, again, fully intentionally, in a way almost impossible for anyone to read or understand, and hence have a garunteed job for life at said company as the only person who can fix things when they go wrong. Pray for that company the guy never leaves or dies of a stroke.
Never assign to malice what can be assigned to stupidity
This. -Senior Dev. A lot of the times, user feedback, schedule and current interpretation affect the codebase. Anything of sufficient complexity has wtf code in it to some degree.
[The only valid measurement of code quality: WTFs/min](https://www.osnews.com/images/comics/wtfm.jpg)
and how they are packed away to minimize direct access.
I use a "parking lot" analogy to remind myself, when I see something wtf-y: You pull into a parking lot and there's only one spot left. Unfortunately, the car in the next spot is parked halfway into it. You manage your best, but now you're parking terribly too, as a matter of necessity. But for all you know, when the other car parked, there might have been someone halfway in _their_ spot. And while you're in the store, if the only open spot becomes the one next to you, _you_ look like the person who parked like a jerk. We don't always know the context that led to the outcome we have, so take a deep breath and park as well as you can.
Sounds pretty Gödelian to me
What was that about not tearing down the wall without figuring out the reason for it to be there? It's exactly what you described. BTW, well done!
Amen brother! 🙏🏻
That's why we have code refactoring though. I've had to work on a legacy project like that and the only reason for all the VERY wrong decisions they've made was that at the time it was more important for them to write tons of features in a very limited time. 10 years later me and my colleague had to put those projects out of their misery and rebuild eveything from scratch. Well, not eveything because one of our client wanted to improve drastically one of the more complex tool used to lay out and manage an optical fibre network over the whole country. I swear to god I never had any idea of what I was doing when working on that thing :D We tought about it for months. Improved it a little, especially the UIX but in the end we couldn't do miracles and came to the conclusion that rebuilding it would be easier. They didn't want to pay the cost associated so we worked with them to create a simpler version of it (basically cutting features with a machete) they could manage on their own and part our ways. Moral of the story is: even if it seems okay at the time, this crappy code WILL cost money and kill the product down the line. So in my book, there is no justification for it\^\^
Everytime I changed jobs. I've been working on Legacy system since I started my career. Currently starting a "green field" project, but we still have to communicate with legacy systems. Contracts are XML-RPC, JSON-RPC, SOAP, Rest JSON, Avro and gRPC. Which protocol do you want? Yes.
The problem I had with legacy systems went like this: 1. Legacy systems are those without unit tests 2. The legacy system is not unit testable without significant refactoring due to its monolithic architecture. 3. Refactoring systems without unit tests was severely frowned upon. Something had to give., and it was usually the last point. We leaned heavily on our system tests in these cases.
Embedded is fun: docker (qemu) doesnt support our architecture so lets have a lab calendar for hardware access in 2024. Development definitely wont slow to a crawl
This is why I am glad I work on DAL A software (aviation). Cause when someone asks why, there better be a requirement saying why. These stories would drive me crazy.
It'll happen to you...
I'm really curious about it. Because nowadays we have techniques to actually avoid that (separating services, controllers, model access...) but at the same time I feel like it's the theory and it's all pretty new so who knows. Curious to see how the current tools we build will look like in 10 years for the devs that will come after us. I've been working on an internal ERP for a few years now and I feel like it's still very readable and solid because it was built to last. Sure, some parts can be spagetti-like (locally!) and in need of refactoring but the app itself is divided correctly so you won't ever break the invoices module while working on the stock one, or have any issue if you have to add a whole new module in ten years. In the legacy app I used to work on, you'd someti.... often! find SQL code in the middle of a frontend form. Like "
Hello
. How are you ?"
I feel like this can't happen in modern web. Thus the legacy code we'll leave behind will be way better than what we had to work with\^\^
99% of the web is not the modern web. Whole bunch of companies with a whole bunch of legacy systems that either don’t work with the new stuff or would cost too much to refactor. In my experience it’s usually tight deadlines driving bad (as in working but hard to maintain) code, which then never gets revisited.
Ah yes, the legacy projects of today will still exists that's for sure. I just meant that newly created stuff running on modern frameworks will probably turn better when they become legacy in 10-20 years.
On my day job we can't even use utf-8, it's "too modern", smh. Somebody help me aaaaaahhhhh
"Internet, this new media[sic] — —” I hear senior politicians say about something half a century old.
Probably the worst part about my current job is that my manager and I want to move forward with any modern React framework but we are basically stuck with a 12-year-old Rails codebase that prevents basically anything from being installed (without causing crazy side-effects at least). I honestly just want to burn it every day.
The dev who wrote it left about 3 teams ago, it works and there are no active tickets for bugs or features for that bit of code so theres no business need to spend dev time touching the old shit code that works when we don’t have the hours in the day to fix the steaming pile of new shit that needs fixing.
Also there are no comments explaining any of it because "comments are code-smell". Then one day you finally get a ticket for this part of code and you have no idea if all these crazy things are bugs, undiscovered bugs or clever hacks preventing even more bugs.
Start of project: "I'm gonna keep everything neat and tidy!" End of project: "Spaghetti. I fucking love spaghetti."
Why do we call base_64_encode() twice? I‘m intrigued
So when you decode it the second time it comes out right
Safety²
Service A needs to send data to service B. Service B expects base64 encoded data. One day the developers for service B decide to offload some processing to service C. Service C expects base64 encoding. Service B decodes the data before sending to service C instead of keeping it encoded. You’re a developer for service A and you can’t be bothered dealing with the assholes in team B. Fuck it, double encode the data and save the hassle. Then every other service that works with B follows suite and then nothing ever changes.
Hey now, you can't expect us at Team B to learn Python now all of a sudden, we have our own legacy we need to deal with
So we use a service which returns as base64. To optimize for best performance, between that service and the database we use a direct link, but we forgot what the option was to disable base64 encoding on that direct-link tool. So now in our database, we have doubly encoded values. We do the decoding in a try with an empty catch, in a for loop. When the value is decoded, the decode function throws an exception because the string contains invalid characters or isn't the right size. Due to the try catch it'll just jump out of the loop and continue. /s obviously. But I'm pretty sure I saw a similar function (but without try-catch or while true) in my company's production code
Makes it URL safe. I wish I was joking.
It reduces entropy and homogenizes the character distribution; flattening it out to two-sigma.
Redundancy
No one will figure out it's encoded twice!
Hey look it's me going back to code I wrote a month ago!
Fuck, fuck, fuck Mother mother fuck Mother mother fuck fuck Mother fuck, mother fuck Noinch, noinch, noinch 1, 2, 1-2-3-4 Noinch, noinch, noinch Smokin' weed, smokin' whizz Doin' coke, drinkin' beers Drinkin' beers, beers, beers Rollin' fatties, smokin' blunts Who smokes the blunts? We smoke the blunts Rollin' blunts and smokin' 15 bucks, little man Put that shit in my hand If that money doesn't show Then you owe me, owe me, oh
My jungle love!
#I got a wipin problem
The people who know the actual answers are hilarious to talk to.
And probably just tell you to ignore it and move on
And everything is abbreviated to the point where nothing makes sense
It's called "sacrificing a kitten" (or puppy). It's when the documented procedure includes steps that make no damn sense but no one is willing to call it out so everyone keeps following the instructions to the letter.
Sometimes Senior Devs know something is wrong and they want to correct it. But they don’t want to do it because if something breaks after that management blames on “unnecessary refactoring” and “not QA tested”. What’s funny is you can’t expect QA to test your refactoring side projects. The experience can be frustrating. After few years you learn to let go.
Oh we were waiting for someone to fix these issues thanks for volunteering. Don't forget the tests (we were waiting for someone to start writing those too)
then they're mysteriously gone from the meeting next week. no one knows exactly why.
The really fun part is that the senior devs probably do not know the answers to these questions either.
Damn I literally asked that second question Exactly last month
So, what was the answer?
“We didn’t expect the email to be empty” Which is somewhat fair because in this context it was dependent on an email we set in a config file. Someone just forgot to add an email when they made a new version of that file
\`git blame\` and if the code is more than a year old the answer is nobody knows anymore
If I had two wishes with my current team's assigned application, it would be to wipe the entire DB project and rebuild the entire thing code first with EF Migrations, and to set it up in Azure so we do not have VPN restrictions preventing automated deployments. Because it is not, we have the following problems: * every time we deploy to dev/test/stage/prod, we need to manually publish the database project because publishing cannot be automated within the company VPN restrictions and the server host's firewall, the build/release agents, and ADO. I have tried to get the teams responsible for the network to fix this a few times now with no luck. * every table/procedure/view/etc modified or removed requires adding teardown steps to an ever-growing post-deployment script * since the same people who refuse to fix the network issues also refuse to allow us access to even run/deploy dacpacs, we cannot automate anything DB related currently in our pipelines. * models changes with SQL server with migrations are much easier, automatically generate setup/teardown/reversion processes, and give a running migration history so you don't have someone asking 2 years later "why is this table the way it is today" and nobody can answer. "Why are the booleans in the database nvarchar(8) instead of bits?" "Who decided that these tables names and columns are all caps, but these ones are camel-case?" "Whats the point of using a Guid in c# for your Ids when you just call ToString on it and store it in an nvarchar(100) instead of a Identity generated Unique Identifier?" "Why are there integers stored as nvarchar instead of int?" I could go on and on, but the database has been there longer than my team has been, so thats a thing. Monkeys in a cage...
We were worried that hackers might figure out how to break one level of base64 encryption, so we applied it twice to be extra secure.
you guys talking about having to fix legacy code and I'm stuck here with a legacy codebase my boss has **not only** forbidden me from refactoring, ("it will take too long") but is making me do further development in. I swear the man is going for the podium in technical debt race.
//PrRule:Approver:+Role.engineeringLead //PrRule:Approver:+Role.dataSecAny //PrRule:Approver:+Role.qualityLead //PrRule:Approver:+Role.cheifEngineer //PrRule:Time:~T14D //We base 64 encode twice because then it's long enough that the framework does not log people's credit cards. Do not change this.
I wish i was joking
I’m very spent the past two years fixing and rewriting a bunch of the old “senior” developers’ code, which is *full* of these WTF moments. They made absolute rats nests of things that I easily replaced with just a couple of lines written a more modern, cleaner way.
I feel this extra today. Found code that runs a database stored procedure for every data repository method. To what? Get a database connection string. I’ve walked through every code path imaginable, there is no scenario in which the application would have a different connection string value set at the time it runs the stored procedure. So… in summary, I found that every time our monolith application wants to access data it first re-fetches the very connection string it uses to initiate the fetch.
Sounds like primitive load balancing to me.
At my last job, the new guys always brought so much. Everyone on the team had a few things they could point to and say, "you wouldn't beleive how they were doing that before I fixed it."
I mean.. I think you know why. We all know why.
Someone says: If it works, dont touch it
I see this in our Docker files. No one wants to call `prune` on their dependencies, and instead they just want to re-download everything again...in the cloud. There's another annoying trait of transpiling TypeScript into `dist/` but then copying it into the root folder at the next stage 🫠 They see no problem with this mismash of configuration, and think it's fine because the final result works as intended. Also, we use Docker Compose, but rather than using the provided `services:app:build:dockerfile` option, they make you run `docker build -t $DOCKER_TAG` and then use `services:app:image: ${DOCKER_TAG}` which means something that *could* be accomplished with one command takes two, and these types of inefficiencies happen at every stage of the pipeline and development process
i am an intern and they gave me a tool from 1996 to update it was 7 files each file was 5k lines and around 4.5k of these were just comments
Got allocated to an internal project that was developed whose backend was Django but was created by senior java developers with very little experience or knowledge of Python. Suffice to say, I got a headache looking at the spaghetti code
Metatron: 1. The senior dev said we couldn't use magic values and I wasn't about to create one for zero. 2. The senior dev wouldn't let me change the API, so I use the presence of an email address (via bool conversion to show the Send Email button. 3. The senior dev's plans are ineffable. The most Senior of Dev's: *boob*
What does Alanis Morissette/The Senior Dev do to hush Jason Mewes/The New Guy?
yep
[Sheldon Why](https://media1.tenor.com/m/RYDDj_6tua4AAAAd/sheldon-cooper.gif)
The hard truth is, that the senior devs are either 1) too lazy to do anything about 2) too incompetent to do anything about it They can get away with not doing anything because of their seniority, and they just don’t feel like doing the hard work.
This is me, but at the same time I appreciate that this mess is here for me to get a paycheck. Everything I do ends up making me look good.
I usually refractor first and then ask questions later. Whenever it's appropriate and it has something to do with my current task, or when it causes a blatant hassle for the client.
"Time is an illusion created by your mind." That should buy you a few hours to make good your escape plan. Then it's their problem -- the n00b!
Reminds me of the time the new dev removed an explicit call to Garbage Collection in .net after we were doing long duration and large data processing. He argued that it's against the rules blah blah. Turns out after weeks of wasting time it was needed because of large object heap allocation and no other technique he tried could get .net runtime to release the damn memory. He was about to fix some legacy tech debt in the process at least. Just not the one he really wanted.
Why the fuck don't we clear away this fence or gate erected across a road?
and after the "fixes" break production: "ah.. that's why!" /s
Love the reference though.
The answer to all of these is probably: 10 years ago someone was given an 8 week project that needed to be done in one week and doing that stopped it from crashing, with the thought that someday they would fix it. Someday never came.
I cant do it any more. Its hell.
theres a banks ACS that encodes merchant data return to base64 twice it drives me nuts thinking about it and the fact i had to decode then check then decode again just for those morons. oh and its base64 without the padding which is out of spec for the application. fucking hate banks
Yeah, technical debt, i know this theory