1. Buy boxes of orange juice, almost past their expiry date.
2. Put boxes on the hot office windowsill for a few weeks.
3. Cool down juice in fridge.
4. "Hey dear coworker, would you like a refreshing juice box on this hot spring day?"
5. Watch coworker retch and vomit, spitting blue-grayish juice over his desk, crying: "Why would you give me old moldy juice without checking the date?"
6. "Do you remember when you told me you didn't have time for unit tests? THIS IS WHAT HAPPENS, DAVE, THIS IS WHAT FUCKING HAPPENS WHEN YOU DEPLOY UNTESTED CODE.... NOW FINISH YOUR JUICE!"

toxic workplace; leaving

I haven't wanted to write this rant. I haven't even wanted to talk to anyone (save my gf, ofc). I've just been silently fuming.

I wrote a much longer rant going into far too much detail, but none of that is relevant, so I deleted it and wrote this shorter (believe it or not) version instead. And then added in more details because details.

------

On Tuesday, as every Tuesday, I had a conference call with the rest of the company. For various, mostly stupid reasons, the boss yelled at and insulted me for twenty minutes straight in front of everyone, telling me how i'm disorganized, forgetful, how can't manage my time, can't manage myself let alone others, how I don't have my priorities straight, etc. He told the sales team to get off the call, and then proceeded to yell and chew at me for another twenty minutes in front of the frontend contractor about basically the same things. The call was 53 minutes, and he spent 40 minutes of it telling me how terrible I've been. No exaggeration, no spin. The issues? I didn't respond to an email (it got lost in my ever-filling inbox), and I didn't push a very minor update last week (untested and straight to prod, ofc). (Side note: he's yelled at me for ~15 minutes before for being horribly disorganized and unable to keep up on Trello -- because I had a single card in the wrong column. One card, out of 60+ over two boards. Never mind that most have time estimates, project tags, details, linked to cards on his boards, columns for project/qa/released, labels for deferred, released to / rejected from qa, finished, in production, are ordered by priority, .... Yep. I'm totes disorganized.)

Anyway, I spent most of conference call writing "Go fuck yourself," "Choke on a cat and die asshole," "Shit code, low pay, and broken promises. what a prize position," etc. or flipping him off under the camera on our conference-turn-video-call (switched due to connection issues, because ofc video is more stable than audio-only in his mind).

I'm just.
so, so done.

I did nothing the rest of the day on Tuesday, and basically just played games on Wednesday. I did one small ticket -- a cert replacement since that was to expire the next day -- but the rest was just playing CrossCode. (fun game, fyi; totally recommend.)

Today? It's 3:30pm and I can't be bothered to do anything. I have an "urgent" project to finish by Monday, literally "to give [random third party sales guy] a small win". Total actual wording. I was to drop all other tasks (even the expiring cert lol) and give this guy his small win. fucking whatever. But the project deals with decent code -- it's a minor extension to the first project I did for the company (see my much earlier rants), back when I was actually applying myself and learning something (everything) new, enjoying myself, and architecting+writing my own code. So I might actually do the project, but It's been two days and I haven't even opened single file yet.

But yeah. This place is total and complete shit. Dealing with the asshole reminds me of dealing with my parents while growing up, and that's a subject I don't want to broach -- far too many toxic memories.

So, I'm quitting as soon as I find something new.
and with luck, this will be before assface hires my replacement-to-be, and who will hopefully quit as soon as s/he sees the abysmal codebase. With even more luck, the asshole king himself will get to watch his company die due to horrible mismanagement. (though ofc he'll never attribute it to himself. whatever.)

I just never want to see or think about him again.
(nor this fetid landfill of a codebase. bleh.)

With luck, this will be one of my last rants about this toxic waste dump and its king of the pile.
Fourty fucking minutes, what the fuck.

Python. Changed a function to return a tuple instead of one value in some database code. Tests pass, gets deployed, everything works. End of the month comes. Suddenly, we get a report that we're draining people's bank accounts and credit cards.

It turns out there was an untested bit of code inside the billing process that used this function. It used the function that was changed. To make matters worse, when the exception was thrown, the billing had already completed successfully, and due to another unrelated bug it would retry despite this.

So, needless to say, type safety and good unit tests are things I prioritize nowadays.

1. Humans perform best if they have ownership over a slice of responsibility. Find roles and positions within the company which give you energy. Being "just another intern/junior" is unacceptable, you must strive to be head of photography, chief of data security, master of updating packages, whatever makes you want to jump out of bed in the morning. Management has only one metric to perform on, only one right to exist: Coaching people to find their optimal role. Productivity and growth will inevitably emerge if you do what you love. — Boss at current company

2. Don't jump to the newest technology just because it's popular or shiny. Don't cling to old technology just because it's proven. — Team lead at the Arianespace contractor I worked for.

4. "Developing a product you wouldn't like to use as an end user, is unsustainable. You can try to convince yourself and others that cancer is great for weight loss, but you're still gonna die if you don't try to cure it. You can keep ignoring the disease here to fill your wallet for a while, but it's worse for your health than smoking a pack of cigs a day." — my team supervisor, heavy smoker, and possibly the only sane person at Microsoft.

5. Never trust documentation, never trust comments, never trust untested code, never trust tests, never trust commit messages, never trust bug reports, never trust numbered lists or graphs without clearly labeled axes. You never know what is missing from them, what was redacted away. — Coworker at current company.

I quit and my last day is next week.

Apparently management has decided that I should spend my last day implementing a new feature for a customer where I have been the only developer, and release it to production (without first implementing it in test) the same day. A feature that potentially could cripple a whole workflow if done wrong.

Of course I advised not to release untested code to production on a friday, just before the only person that knows how it works leaves the company. But no, “the customer reaaaaaally wants it before summer, so just be careful not to write any bugs”.

I’m not saying that I’m intentionally gonna write bad code - but if I do, I’m not gonna pick up the phone when it calls.

"Can you work on this ticket? It's kind of urgent."

-- "OK"

"And could you please not refactor? Just get this done."

-- "Why? What's the issue?"

"The logic is complex. We should not break it."

-- "Erm, that's what the tests are for. So yes, if the need arises, I'll refactor. The tests are my guidelines if the logic breaks or not."

There's a reason we create tests. So let's not hinder code base improvements by some random fear that stuff might break.

If breaks due to refactoring, we'll fix it by adding a valid test case during and then fixing the bug.

If my refactoring does not break the tests, I'll assume the code base is stable.

If your code is untested, then we have a complete different problem.

Had a meeting with my boss earlier. Got yelled at for:
a) Working on a high-priority, externally-committed ticket (digit separators) that i was 85% done with on the Friday afternoon before my vacation instead of jumping to a lower-priority screwdriver ticket that just came in. Even though my boss agreed with me that what I did was exactly what I should have done, it's still bad because I was apparently rude to product by not doing as they asked?
b) Taking too long on that digit separator ticket that amounts to following a gigantic mess of convoluted spaghetti and making a few small changes, and making sure it doesn't break the world because it's all so fucking convoluted and fragile as hell. Let's not even mention my 4-10 hours of mandatory useless meetings every week.
c) Missing something that wasn't even listed in that same ticket -- somehow my fault? -- so I very obviously didn't test my work. Even though specs all passed and QA also tested and signed off on it as working and complete. Clearly half-assed and untested. Product keeps promising/planning UATs and then skipping them, and then has the audacity to complain about it.
d) Not recovering fast enough from burnout and daily mental breakdowns. I can still barely get out of bed and you want me to be super productive? Got it. Guess what? I'm being amazingly productive for my mental health. But my boss, Mr. Happy-go-lucky, thinks depression is dropping your icecream cone on your clean kitchen table, and this three-ton pile of spaghetti is "maybe a little messy, I guess."

So I need to somehow "regain the confidence" of both him and product because I'm taking awhile on difficult tickets (surprise), while having these ridiculous breakdowns (surprise), and because I don't fix things that aren't even listed in the fucking tickets (fucking surprise) -- and worse, that the lack of information is somehow entirely. my. fault. (surprise fucking surprise)

GOD I HATE THESE PEOPLE.

This is going to be a long rant, coz this is the only way to vent out my frustration against our tech head.

Yesterday, while our fucking twat tech head was playing around in company aws account, he terminated the production server. By mistake, apparently. Coz he doesn't know shit about server management. But that egoist ass won't admit and fucked the production server.

And then ran away. We developers sprang into action. Updated dns to point to staging server, setup virtual hosts, env files, point to prod database, force flush dns cache. All systems were up and running in 30 mins. And since it was staging server, it had lot of untested features and codes, and we spent rest of the day fixing the bugs.

And that tech head, who ran away hiding his tail between his legs, after he fucked the server, came back after systems were up. And started cracking jokes, that "so many features got released in 1 day" . "We cut server cost by shutting down 1 server."

We were struggling and working in full throttle to make the services running again. And that fuckity fucker was cracking jokes.

And I don't even know what excuse he gave to ceo for the downtime. I am pretty sure he would have made up some crappy excuse to hide his fucking mistake. That ass never admits his mistake. I am thinking to go to ceo today and tell the real story and get that faggot head fired or at least a strict warning.

Job listing I just saw:
Our lead and only developer just retired after 15 years of maintaining the codebase. We need someone who is capable of working with large amounts of undocumented and untested code.

PS: This was a company that makes medical software.

Friend: I just love the adrenaline rush caused by bungee jumping
Me: I just love the adrenaline rush caused by deploying untested code to production server on a Friday night

PM asked us to skip the unit test and just deliver untested application to SIT environment due too tight timeline. But when there are defects raised by tested, PM asked why got bugs and asked us to fix them immediately while we have to develop other new features at the same time.

My cat is looking at me like he's doing an untested deployment on a friday at 5.

Yes, Mr. Client. It is extremely wise of you to demand changes on release-day. Of course it won't go smoothly, untested and buggy as it will be.

Explaining to the client that you can't push untested changes to production and expect it to be bug free.

Russian Roulette - Developer Edition:

Have a random generator for a number between zero and one hundred. Every developer present picks a unique number.

The generator must then reroll until somebody's number of choice is the result. It is now this person's responsibility to begin an untested deployment at 4:59pm the next available Friday.

As a developer, I want to write clean code and I want managers that understand the importance of clean code. I don’t want to work with people who force me to deploy untested code because "we need this feature working today".

"I'm almost done, I'll just need to add tests!"

Booom! You did it, that was a nuke going off in my head.

No, you shouldn't just need to add tests. The tests should have been written from the get go! You most likely won't cover all the cases. You won't know if adding the tests will break your feature, as you had none, as you refactor your untested mess in order to make your code testable.

When reading your mess of a test case and the painful mocking process you went through, I silently cry out into the void: "Why oh why!? All of this suffering could have been avoided!"

Since most of the time, your mocking pain boils down to not understanding what your "unit" in your "unit test" should be.

So let it be said:

- If you want to build a parser for an XML file, then just write a function / class whose *only* purpose is: parse the XML file, return a value object. That's it. Nothing more, nothing less.
- If you want to build a parser for an XML file, it MUST NOT: download a zip, extract that zip, merge all those files to one big file, parse that big file, talk to some other random APIs as a side-effect, and then return a value object.

Because then you suddenly have to mock away a http service and deal with zip files in your test cases.

The http util of your programming language will most likely work. Your unzip library will most likely work. So just assume it working. There are valid use cases where you want to make sure you acutally send a request and get a response, yet I am talking unit test here only.

In the scope of a class, keep the public methods to a reasonable minimum. As for each public method you shall at least create one test case. If you ever have the feeling "I want to test that private method" replace that statement in your head with: "I should extract that functionality to a new class where that method public. I then can create a unit test case a for that." That new service then becomes a dependency in your current service. Problem solved.

Also, mocking away dependencies should a simple process. If your mocking process fills half the screen, your test setup is overly complicated and your class is doing too much.

That's why I currently dig functional programming so much. When you build pure functions without side effects, unit tests are easy to write. Yet you can apply pure functions to OOP as well (to a degree). Embrace immutability.

Sidenote:

It's really not helpful that a lot of developers don't understand the difference between unit, functional acceptance, integration testing. Then they wonder why they can't test something easily, write overly complex test cases, until someone points out to them: No, in the scope of unit tests, we don't need to test our persistance layer. We just assume that it works. We should only test our businsess logic. You know: "Assuming that I get that response from the database, I expect that to happen." You don't need a test db, make a real query against that, in order to test that. (That still is a valid thing to do. Yet not in the scope of unit tests.)

When you have no option but to push untested code to prod, also, you don't trust your shitty team.

When you push seemingly harmless untested code to production server which breaks the whole application...

End user when criticizing a developer for 'taking long' to create something of value from scratch:
(4 hours later): "What's taking you so damn long? Are you retarded?"

Oh I don't know, maybe I have to make sure that tests in my code run well, maybe I have to evaluate everything to meet the custom satisfactions of the user for his ever-so-custom requirements and I also have to make sure I discard what they don't like? And maybe it takes time to deliver a quality product, and so on?
Or would you prefer I deliver an untested product that I didn't bother to think about and I haven't bothered to make sure it matches with their requirements?

What end users don't understand is the involvement in a quality product.

So I’m working on a project right and I don’t run it after writing 104 lines of untested code and it doesn’t work.

Which is expected but then I do some stuff and fix that, I get a new error which is great cause I’m getting closer.

Cut to tonight. I’m trying to hunt and kill this bug. And after doing nothing but copying the code to another text file so I can upload that copy and get help.

I decide to run it with a little just print statement in it to make sure it’s definitely broken and I’m not asking online for no reason.

And.. it works.. WHAT???

I uncomment the rest of the function and get rid of the print statement and scream because ITS WORKING!!

I MEAN IT HAS BUGS BUT THEYRE BUGS I CAN FIX AND FOCUS ON AFTER I FREAK OUT ABOUT IT WORKING AFTER ME CHANGING FUCKING NOTHING.

"Hey, we got this new untested artifact a few minutes ago. Can you deploy it to the 2500 POS in production and stay at the office in case something goes wrong?"

This fucking guy create a mess of a code, more than a spaghetti code, a clusterfuck of shit untested spaghetti code, and the project is actually getting well, our customer is getting bigger but everytime there is something to be added, its a fucking pain to add, and when something breaks, almost every thin breaks, and the shitty guy who wrote this code is quitting and its fucking up to me to clean up all the fucking mess, fucking asshole.

DOCUMENT AND TEST YOUR CODE KID, DONT BE A FUCKING SPAGHETTI PROGRAMMER

I really want to stress that we should add the ticket for adding the missing test cases in *this* sprint and not postpone it any further.

-- "Isn't there something more important to be added instead?"

There. ALWAYS. Is. Something. MORE. Important. The real problem was that we implement the test cases in the past to begin violating our definition of done. We have to fix and one point and we have to own that decision as nobody else will care about passing tests and test coverage. It's our job to care for that.

Yes, we can instead focus on all the other high-priorities task that should have been done yesterday, yet that won't change the fact that large part our codebase will remain an untested messy blackbox just asking for weird bugs and wild goosechases in the future.

Don't hide behind "high priority tasks". A job is done when it is fucking done and tests are part of that. Hurrying from one important task to the next will just mean we'll never do it. There is no better time than right now.

If code coverage got left behind in the past, then we'll have to suck it up in order to fix it as soon as possible, otherwise we'll just suck forever.

PCs are a clusterfuck these days. Microsoft has abandoned the niceness of Win-7 and opted for Win-10 - with spyware, untested forced updates and forced online licence checks to make sure you have to get the shit. Macs are total crap, and Apple doesn't care because they instead prefer to milk customers with overpriced iShit. Linux sucks and looks like a Soviet tractor, but at least, it doesn't fuck up itself just by switching it on.

I had Linux as only OS from 2001 to 2010, and while I obviously can deal with it, I finally hated it enough to switch over to Win-7. From 2020 on, it looks like I will be back because Microsoft has managed to fuck up Windows even worse (and then these suckers wonder why Github users don't trust them). Maybe I'll buy a Tux when I install Linux so that I can punch it in the face.

Progress was yesterday - today it's about damage control. Welcome to a world where the brightest CS guys are thinking about how not only to shove up even more ads into peoples' asses, but how to also transmit lab data of the poo.

My company is (supposedly) all about collaborative work, pair programming, getting on calls and cRaCKinG tHinGs ToGEtheR. Also (and rightfully so) we’re not supposed to approve any PRs if tests weren’t created/updated.
Of course that applies to all but the old timers in the company who simply act like lone cowboys. They fall off the face of the earth for two-three days then reappear with monster PRs full of untested code.

Leave it up to the plebe then to try to make sense of the mess they’ve created, to challenge them with the fact that the PRs are lacking tests (only to be met with excuses about not having anymore time to spend on the subject).
Reprimand the plebe for not reviewing PRs thoroughly enough. Leave it up to them to fix the resulting bugs.

I’ve lost all trust in our managers, tech leads, lead devs and their guidelines and rules that only apply to others but rarely to themselves. These people that then have the audacity to criticize the tech team in it’s entirety for not being rigorous enough in its processes.
Fuck them all

If 2020 were a software, everything happened because that one dev keeps pushing untested code into prod

rant="""
It's too many features for me to keep up with. And the client just bounces between this matrix of all the possible permutations of them, refusing to admit that he is asking for mutually exclusive behavior in more than one place. I have mentioned to him at least 12 times a year that there is too much going on, not organized, we need to simplify, prioritize, or we will have 100 half baked untested features.

Of course it is more or less made it out to be that this is all my fault, or at least it's hard not to feel that way when I say:

It will be a long time before X will be working, we need 25 other things first.;

Next day he asks:
Have you made any progress on X;

I reply: Now we need 24 things to be done at this rate it will be a month.;

He replies:
Ok but I need this yesterday. How about if you add a new feature Y that does everything X does without those 24 things?;

I reply: That will not work at all like X. Y is just X + 1 more feature.

He replies: Ok well I need Y so when you're done with X I need a way to do it like Y also. I just thought it'd be easier.

EASIER TO ADD MORE FUCKING FEATURES YEAH SURE THATS EASY AS FUCK YOU FUCK FUCK FUCK. He's a nice enough guy, pretty smart compared to my first few paying gigs, but wtf really? How do I come out and tell you I need 25 days and you ADD more work? This was one example.

IN TWO days he has added 12 features. And during the week has asked for 29 UI interfaces to be COMPLETELY different. This is becoming COMMONPLACE. Every week there is either a huge change, or a conversation like about that finds its way into the entire business flow inside an dout.

The worst thing is: I TOTALLY understand what he needs. I feel that HE doesn't. This weekend I spent literally HALF of his retainer on getting equipment into my hands to bring it back to find out it DOESNT WORK. Why aisn't HE doing this so I can finish the features from NOVEMBER that HE NEEDS in order to PROCESS SALES.

I've tried and tried but I just can't get through to this client what a tremendous waste of time his \"process\" is, for lack of a better word. Constant changes, contsant additions, lack of clarity, needless repetition and contradictions, constantly adding moonshot ideas to compete with every industry in the region, and not beta testing anything until something goes wrong.

Fuck this guy! His business is failing and I felt responsible for the longest time but it is clear to me that if I wanted to save his business I would have to ignore 95% of his feature requests. I ignore 50% now because of the stress in trying to determine which of the 3 different paradigms he is talking about changing. I will lose this client, and I feel like he will sue me to get all of his money back. He holds me to very little honestly - BUT WEEKLY reminds me that he won't be able to pay me next month if feature XY and Z arent ready!

If a developer is CLEARLY overwhelmed, it makes NO sense at all to continue to PILE ON feature after feature
"""
try:
while true:
rant+=", after feature"
except DevHeadExplodes as inevitable:
raise YourDevsRatesOrLookElsewhere(inevitable)

Business Continuity / DR 101...
How could GitLab go down? A deleted directory? What!
A tired sysadmin should not be able to cause this much damage.
Did they have a TESTED dr plan? An untested plan is no plan. An untested plan does not count. An untested plan is an invitation to what occurred.
That the backups did not work does not cut it - sorry GitLab. Thorough testing is required before a disruptive event.
Did they do a thorough risk assessment?
We call this a 'lesson learned' in my BC/DR profession. Everyone please learn by it.
I hope GitLab is ok.

When you catch developers rolling out untested changes to production that have a huge impact on your clients workflow... And they don't tell anyone so you find out because your clients are yelling on the phone about some change affecting their work flow.

So I wrote a service a couple of years ago to generate PDFs from some documents. Fully working, covered it with tests (unit and integration). Code was clear and easy to follow.

I've been promoted and the engineer that took it over just went in and rewrote half of it. That would be fine, but they also just deleted every test. So now it's untested.

Glad that's not my problem anymore, I geniunely hope it breaks

Copy-pasting 90% of our entities including logic and merging some - creating thousands of duplicated lines - and then creating views for those abnomalies just to speed up the ORM fetching which could have been done with a single join...

Took me some time to delete all of that fking shitty untested code full of bugs...

My team and I are working on a huge project that's been in development for years.

First deadline was in the fall last year. We were never going to make that.

Then we were supposed to be ready just after the summer holidays (months ago). We didn't make that either.

Then we were supposed to launch last week. Didn't happen, still too many critical errors and unfinished, untested features.

Now we are having daily meetings to discuss whether we'll be ready to release... that day!

Meanwhile, stability issues and other critical errors keep popping up. The product is barely finished and has not been through rigorous testing with all the latest features and bug fixes. Not to mention that we don't really have a deployment pipeline either.

And here's the kicker: The customers don't know this is coming. It's highly anticipated, but only internally. It is a replacement for an existing product, which strives towards not changing the frontend too much.

Why do we rush it so? I get that a deadline can help motivate you to reach your goal, but how motivated will we be if the launch fails and we get buried in bugs and missing features?
Would it not be better to launch it with at least the confidence of knowing that we've tried to test it properly?

So, this has happened to me quite a few times
I write about 100 untested lines of code (I know, bad practice) and then go ahead to test it
As expected, the program crashes
Spend hours debugging, to no avail
And then I add a print statement to check where the code stopped, and hey presto! The code completes execution
I remove the print statement, the code gets stuck

Also, the codes don't use any low level functions that might be interfered by print statements anyhow

Till today, never understood how a print statement helps codes execute properly

In a previous job, I was trying to organize a common repository with our shitty business partner so we could both be able to contribute our part so our work would not overlap. Not like they cared anyways.

One thing I quickly noticed is those fuckers would just straight up commit untested changes on master and cripples our whole testing and prod deployment at times because we were depending on a shitty IoT service they provided us onto which we had no control whatsoever.

I told my boss, who was often complaining about them being unreliable in the first place, I would simply restrict them from merging and commiting to develop or to master without my approval. We cannot keep working like this.

He told me that we could not impose on them our work practices and that I should not try to piss them off. To be diplomatic.

I politely and professionally refused to do it, but he did change his mind in the end. He and I left not too long after. I guess he felt obliged to respond that having his job at stake but you cannot condone voluntarily shitty work.

Forgive me for I have sinned.
I doubted software from India could be as bad as you always hear ... I was proven wrong ... now I have to take the consequences ... an untested, Indian Web-API

This was initially a reply to a rant about politics ruining the industry. Most of it is subjective, but this is how I see the situation.

It's not gonna ruin the industry. It's gonna corrupt it completely and fatally, and it will continue developing as a toxic sticky goo of selfishness and a mandatory lack of security until it chokes itself.

Because if something can get corrupted, it will get corrupted. The only way for us as a species to make IT into a worthy industry is to screw it up countless times over the course of a hundred years until it's as stable and reliable as it can possibly be and there are as many paradigms and individually reasonable standards as there can possibly be.

Look around, see the ridiculus amount of stupid javascript frameworks, most of which is just shitcode upon vulnerabilities upon untested dependencies. Does this look to you like an uncorrupted industry?

The entire tech is rotting from the hundreds of thousands of lines of proprietary firmware and drivers through the overgrown startup scene to fucking Node.js, and how technologies created just a few decades ago are unacceptable from a security standpoint. Check your drivers and firmware if you can, I bet you can't even see the build dates of most firmware you run. You can't even know if it was built after any vulnerability regarding that specific microcontroller or whatever.

Would something like this work in chemical engineering? Hell no! This is how fucking garage meth labs work, not factories or research labs. You don't fucking sell people things without mandatory independent testing. That's how a proper industry works. Not today's IT.

Of course it's gonna go down in flames. Greed had corrupted the industry, and there's nothing to be done about it now but working as much as we can, because the faster we move the sooner we'll get stuck and the sooner we can start over on a more reasonable foundation.

Or rely on layers of abstraction and expect our code to be compilable on anything the future holds for us.

I really don't understand this particular Government Department's IT Unit. They have a system and network to maintain except:

- They don't have a DBA
- They don't have a dedicated Network Engineer or Security Staff
- Zero documentation on all of the systems that they are taking care of (its all in each assigned particular staff's brain they said)
- Unsure and untested way of restoring a backup into a system
- Server passwords are too simple and only one person was holding this whole time and its to an Administrator account. No individual user account.
- System was developed by an in-house developer who is now retired and left very little documentation on its usage but nothing on how its setup.

But, the system has been up and operational for the past 20 years and no major issues whatsoever with the users using it. I mean its a super simple system setup from the looks of it.

1 App Server connected to 1 DB Server, to serve 20-30 users. But it contains millions of records (2GB worth of data dump). I'm trying to swing to them to get me on a part time work to fix these gaps.

God save them for another 20 years.

I am the unit test guy now, please send all of your untested and poorly thought out code my way to be tested

I quite often run untested scripts on production systems or hot fix JavaScript files on live using Emacs...

How can a big company as Facebook, allow that many functions of its website are just untested?

I make you an example, access the mobile version of Facebook from browser, go to a group and change the notifies settings, then refresh the page. The settings returns as before! If I did something like this I'd get fired in less than 0.1 seconds

Untested code has bugs that cause catastrophic failures in code and I get asked "How the hell did you even find that?!" by a manager on another team.

I pressed enter to post form data.

Just pushed to production an untested feature implemented using code from StackOverflow.

Let's see how this goes

Shows perfect results.
PM: Nice, integrate that into the latest version.
Shows bad results.
PM: Your integration must be wrong.
Show him the file diff, no difference in my implementation.

It's funny how the exact same feature goes to shit immediately after they push all these untested changes.

I promise to donate once half of my monthly gross income to charity for research on ASD, the year that I'll be able to enjoy all of my holidays without some smartass thinking that it's a great idea to deploy a huge untested upgrade to Production.

The Odyssey of the Tenacious Tester:

Once upon a time in the digital kingdom of Binaryburg, there lived a diligent software tester named Alice. Alice was on a mission to ensure the flawless functionality of the kingdom's latest creation – the Grand Software Citadel.

The Grand Software Citadel was a marvel, built by the brilliant developers of Binaryburg to serve as the backbone of all digital endeavors. However, with great complexity came an even greater need for meticulous testing.

Alice, armed with her trusty testing toolkit, embarked on a journey through the intricate corridors of the Citadel. Her first challenge was the Maze of Edge Cases, where unexpected scenarios lurked at every turn. With a keen eye and a knack for uncovering hidden bugs, Alice navigated the maze, leaving no corner untested.

As she progressed, Alice encountered the Chamber of Compatibility, a place where the Citadel's code had to dance harmoniously with various browsers and devices. With each compatibility test, she waltzed through the intricacies of cross-browser compatibility, ensuring that the Citadel would shine on every screen.

But the true test awaited Alice in the Abyss of Load and Performance. Here, the Citadel's resilience was put to the test under the weight of simulated user hordes. Alice, undeterred by the mounting pressure, unleashed her army of virtual users upon the software, monitoring performance metrics like a hawk.

In the end, after days and nights of relentless testing, Alice emerged victorious. The Grand Software Citadel stood strong, its code fortified against the perils of bugs and glitches.

To honor her dedication, the software gods bestowed upon Alice the coveted title of Bug Slayer and a badge of distinction for her testing prowess. The testing community of Binaryburg celebrated her success, and her story became a legend shared around digital campfires.

And so, dear software testers, let the tale of Alice inspire you in your testing quests. May your test cases be thorough, your bug reports clear, and your software resilient against the challenges of the digital realm.

In the world of software testing, every diligent tester is a hero in their own right, ensuring that the digital kingdoms stand tall and bug-free.

Ops wants to use an untested feature in production

Dev points out the high risk of doing so, and refuses to be accountable to any fallout

Ops gets bitchy and demands that Dev activate the feature

Ops executes the feature

Production breaks over the long weekend (Canada)

Ops complains to Management

Dev is blamed by Management

Do you guys still see the relevance of using code freezing instead of just properly managing versions, repositories and branches in a cyclical manner, given how advanced software practices and tools are supposed to be?

To give some context, the company I work for uses the complete trash project management practice of asking teams to work on a sprint basis, but there is still a quarterly milestone and code freeze to commit to and it's where shit hits the fan.

Development teams rush features at the end of the quarter because they had to commit at the very least to a 6 months in advance planning (lol?) and turns out, not being able to design and investigate properly a feature combined with inflexible timelines has high chances to fail. So in the end, features are half-assed and QA has barely any time to test it out thoroughly. Anyways, by the time QA raises some concerns about a few major bugs, it's already code freeze time. But it's cool, we will just include these bug fixes and some new features in the following patches. Some real good symver, mate!

Of course, it sure does not help that teams stopped using submodules because git is too hard apparently, so we are stuck with +10Gb piece of trash monolithic repository and it's hell to manage, especially when fuckfaces merges untested code on the main branches. I can't blame Devops for ragequitting if they do.

To me, it's just some management bullshit and the whole process, IMO, belongs to fucking trash along with a few project managers... but I could always be wrong given my limited insight.

Anyways, I just wanted to discuss this subject because so far I cannot see code freezing being anything else than an outdated waterfall practice to appease investors and high management on timelines.

Legacy code = untested code.
Don't write legacy code, act like a professional since day 1.

When you love the company you work for, and your boss is amazing; but you're stuck with Zend Framework 2 and PHP on a 1.2m LoC untested legacy system...

Every time we have a release, "Release Engineering" stops building our test environments from master. I've been preaching Continuous Deployment for months and here we are with the most broken system. The build actually builds all test environments AND prod from the same branch because "it's easier" for "Release Engineering". So now I have to wait for the code freeze on release and hope RE doesn't fuck up and deploy an untested branch to prod... AND hope we're given enough time to test and debug the next release since we can't right now...

Run untested SQL on prod db. Yeah I love adrenaline

The fucking release process. We release weekly which is stressful for both Devs and QA’s. Everything should be committed/promoted in our DVCS by Thursday and should be verified beforehand. The problem is, QA’s doesn’t take development builds, they only want to take whats fucking next in release. In other words WE. FUCKING. RELEASE. UNTESTED. SOFTWARE.
Man, BA’s have it easy on our team.

How many here have tested your app, but still felt you left something out or untested?

I'm not going to get any real work done today, am I...

Here I sit waiting for the next problem to pop up because of silly untested edge cases by this team.

Ugh... 😮‍💨

I had a pretty good year! I've gone from being a totally unknown passionate web dev to a respected full stack dev. This will be a bit lengthy rant...
Best:
- Got my first full time employment dev role at a company after being self-taught for 8+ years at the start of the year. Finally got someone to take the risk of hiring someone who's "untested" and only done small and odd jobs professionally. This kickstarted my career, super grateful for that!
- Started my own programming consulting company.
- Gained enough confidence to apply to other jobs, snatched a few consulting jobs, nailed the interviews even though I never practiced any leet code.
- Currently work as a 99% remote dev (only meet up in person during the initialization of some projects.) I never thought working remotely could actually work this well. I am able to stay productive and actually focus on the work instead of living up to the 9-5 standard. If I want to go for a walk to think I can do that, I can be as social and asocial as I want. I like to sleep in and work during the night with a cup of tea in the dark and it's not an issue! I really like the freedom and I feel like I've never been more productive.
- Ended up with very happy customers and now got a steady amount of jobs rolling in and contracts are being extended.
- I learned a lot, specialized in graph databases, no more db modelling hell. Loving it!
- Got a job where I can use my favorite tools and actually create something from scratch which includes a lot of different fields. I am really happy I can use all my skills and learn new things along the way, like data analysis, databricks, hadoop, data ingesting, centralised auth like promerium and centralised logging.
- I also learned how important softskills are, I've learned to understand my clients needs and how to both communicate both as a developer and an entrepeneur.
Worst:
- First job had a manager which just gave me the specifications solo project and didn't check in or meet me for 8 weeks with vague specifications. Turns out the manager was super biased on how to write code and wanted to micromanage every aspect while still being totally absent. They got mad that I had used AJAX for requests as that was a "waste of time".
- I learned the harsh reality of working as a contractor in the US from a foreign country. Worked on an "indefinite" contract, suddenly got a 2 day notification to sum up my work (not related to my performance) after being there for 7+ months.
- I really don't like the current industry standard when it comes to developing websites (I mostly work in node.js), I like working with static websites (with static website generators like what the Svelte.js driver) and use a REST API for dynamic content. When working on the backend there's a library for everything and I've wasted so many hours this year to fix bugs and create workarounds related to dependencies. You need to dive into a rabbit hole for every tool and do something which may work or break something later. I've had so many issues with CICD and deployment to the cloud. There's a library for everything but there's so many that it's impossible to learn about the edge cases of everything. Doesn't help that everything is abstracted away, which works 90% of the time but I use 15 times the time to debug things when a bug appears. I work against a black box which may or may not have an up to date documentation and it's so complex that it will require you to yell incantations from the F#$K
era and sacrifice a goat for it to work properly.
- Learned that a lot of companies call their complex services "microservices". Ah yes, the microservice with 20 endpoints which all do completely unrelated tasks?

My first words to one fresh graduate , which just started his backend path:

Untested code is a garbage waiting to be collected. Even if some companies / teams somehow manage to do miracles and to work with untested code... that's just a pre-death fantasy of a dying man.

I am the technical lead in a project which uses a C# based framework. It's a lot of drag and drop, and C# scripts can be embedded for fancy stuff.

Scripts in general are not hard to do, it's harder to understand the business rules rather than the code itself.

I got hired as a junior to build this project from scratch as an MVP, and we need another junior to add enhancements and minor changes required from our end users. Since management wants me to move on working on more mid-senior development stuff, I'm supposed to be only supervising the juniors work (in the hopes that one day they'll be able to work on their own).

We've had bad luck filling this position. Our last hire is a guy like 17 years older than me, supposedly with experience in said framework but OH DEAR GOD.

Fucktard can't understand requirements and corrections, isn't able to deliver a 20 line script without fucking up. I give him a list with 3 mistakes to fix and only fixes two, crap like that.

Now, hear me out, the mistakes are stuff like:

- Unused variables
- Confusing error messages
- Error messages written in spanglish (mix between Spanish and English, we're located in Latin America)
- Untested features, this is the worst of all.

You may say "but he's a junior", sure. But as I said, he supposedly has experience, more years in IT than me, and fine, you're allowed to fuck up a few times on your first tasks but not make the same mistakes over and over, specially since we've already sat down and addressed these issues in presence of the CTO.

Fuck this guy. I genuinely dislike him as a person also, he is from another latin country and we have some serious cultural differences. For instance, he insists on sucking your ass constantly, being overly well manered (we already saluted with the whole team at the daily stand up, stop saying hello, good day, regards in each of your fucking chat messages or task submissions), and other mannerisms that are hard to translate, but whatever, all of these attitudes are frowned upon here. They're not necessary, we just want to keep it simple, cordial and casual and see you deliver the crap that you're being paid for with a decent level of quality.

On Monday the CTO comes back from vacation, I'm looking forward to that meeting, gonna report his ass, there is evidence everywhere on our issue tracker.

"Untested code is broken code"

Unless deadlines are near and you're palming the project of on some other poor dev.

I pushed some untested changes yesterday to my course team's code repo, and it broke one thing. Let that be a lesson to ALWAYS TEST CHANGES BEFORE PUSHING THEM! > _ <

I added this message to one of my commits:

Untested as Windows is being difficult and won't let PyQt run and Linux us being difficult and won't boot, but probably works

😉

In hindsight, sending WoL to an untested machine while 30 kilometers away was not a very smart idea.

The machine is up, but does not respond to pings and is unreachable.

Upper management has a huge meeting and decides NOT to merge in buggy or incomplete or untested code just because it's the due date (you know, quality over quantity? And an attempt to cut back PM's unrealistic expectations)
2 sprints later: "So we're going to go ahead with the merge. Yes, we know the feature isn't complete, but we promised blah blah blah"
So much for that <.<;;

I keep telling myself "I can do this, I can change this", but then I'm forced to write untested undesigned spaghetti code cause we need another hotfix for 3 hours from now...

For some reason, out of no where, I made this word up. It's called Moop, and it's definition is paradoxical. It means "everything and nothing, anywhere and nowhere, etc". So one day at work one of my coworkers pushed his untested commit to the master branch of our 25k project. To make matters worse, he deleted all other branches and previous versions of the project. Our project manager heard about it and became so angry that he almost broke our no-curse-word-policy. So he called is all together to get around it so he could properly vent.
Project manager: "Guys I'm extremely angry at James (the one who pushed the untested source code to our commercial project, ruining it)
Me: well, I have a word that we can use
Project manager: what is it?
Me: Moop
You can guess what the next few weeks at work was like. All of my coworkers had to fix the crap James made, including myself. So the conversations went like this: "The mooperfluffer James should have never mooped with us!", "MOOP YOU JAMES, I HOPE YOU HET MOOPED TO HELL YOU MOOPUP!!!!!", "Hey James, guess what! I hope you moop yourself". Our boss became a strong moop user and spray moop all over James workstation. We put moop in his cup, his laptop keyboard, even his thumb drive. We downloaded moop.exe to his PC so we could moop his kernel.

Today James' life is officially mooped.

Just got back to a solo project I hadn't touched in 5 months due to having other priorities. The whole thing is probably less than 1k LOC split over a half-dozen files and I'm not sure whether I should be angry at my past self for leaving the most recent part untested and insanely bug-ridden, taking almost an hour a fix, or be happy that past me organized and documented everything well enough for it to only take almost an hour to fix.

I think you already know by now, but I have to say it. The update of the discord app is utter shit, brought only downgrades to me and they still refuse to fix bug that have been prevalent on their platform for years to force their shiny, new, untested bullshit down your throat

What should I do, I have a central function that is not documentated and no test-cases are written for it. I have no clue what the method should really do, I know that it works in 99.9% of all cases otherwise we had much more bugs. Now there is one Unit-Test that reports an issue. I tracked it down to this method, no one touched the method nor the unit-test.
My logical thinking says that there is one statement missing, but it could also fuck up another part of the code... (This project has a bad testing coverage :'( )

What would you do?

- copy paste the method for this special case (I would hate me so much for breaking DRY)
- inheritance?! (Would make it more complex and then it would be still untested / undocumented)
- YOLO changing oO?! (hope for luck, just joking)

P.s it's an edge case unit test, the client / customer probably wouldn't realised it if it happens