One week, and it turned out to be worse than that.

I was put on a project for a COVID-19 program in America (The CARES Act). The financial team came to us on Monday morning and said they need to give away a couple thousand dollars.

No big deal. All they wanted was a single form that people could submit with some critical info. Didn't need a login/ registration flow or anything. You could have basically used Google Forms for this project.

The project landed in my lap just before lunch on Monday morning. I was a junior in a team with a senior and another junior on standby. It was going to go live the next Monday.

The scope of the project made it seem like the one week deadline wasn't too awful. We just had to send some high priority emails to get some prod servers and app keys and we were fine.

Now is the time where I pause the rant to express to you just how fine we were decidedly **not**: we were not fine.

Tuesday rolls around and what a bad Tuesday it was. It was the first of many requirement changes. There was going to need to be a review process. Instead of the team just reading submissions from the site, they needed accept and reject buttons. They needed a way to deny people for specific reasons. Meaning the employee dashboard just got a little more complicated.

Wednesday came around and yeah, we need a registration and login flow. Yikes.

Thursday came and the couple-thousand dollars turned into a tens of millions. The amount of users we expected just blew up.

Friday, and they needed a way for users to edit their submissions and re-submit if they were rejected. And we needed to send out emails for the status of their applications.

Every day, a new meeting. Every meeting, new requirements that were devastating given our timeframe.

We put in overtime. Came in on the weekend. And by Monday, we had a form that users could submit and a registration/ login flow. No reviewer dashboard. We figured we could take in user input on time and then finish the dashboard later.

Well, financial team has some qualms. They wanted a more complicated review process. They wanted roles; managers assign to assistants. Assistants review assigned items.

The deadline that we worked so hard on whizzed by without so much as a thought, much less the funeral it deserved.

Then, they wanted multiple people to review an application before it was final. Then, they needed different landing pages for a few more departments to be able to review different steps of the applications.

Ended up going live on Friday, close to a month after that faithful Monday which disrupted everything else I was working on, effective immediately.

I don't know why, but we always go live on a Friday for some reason. It must be some sort of conspiracy to force overtime out of our managers. I'm baffled.

But I worked support after the launch.

And there's a funny story about support too: we were asked to create a "submit an issue" form. Me and the other junior worked on it on a wednesday three weeks into the project. Finished it. And the next day it was scrapped and moved to another service we already had running. Poor management like that plagued the project and worked in tandem with the dynamic and ridiculous requirements to make this project hell.

Back to support.

Phone calls give me bad anxiety. But Friday, just before lunch, I was put on the support team. Sure, we have a department that makes calls and deal with users. But they can't be trained on this program: it didn't exist just a month ago, and three days ago it worked differently (the slippery requirements never stopped).

So all of Friday and then all of Saturday and all of Monday (...) I had extended panic attacks calling hundreds of people. And the team that was calling people was only two people. We had over 400 tickets in the first two days.

And fuck me, stupid me, for doing a good job. Because I was put on the call team for **another** COVID project afterwards. I knew nothing about this project. I have hated my job recently. But I'm a junior. What am I gonna say, no?

No, MD5 hash is not a safe way to store our users' passwords. I don't care if its been written in the past and still works. I've demonstrated how easy it is to reverse engineer and rainbow attack. I've told you your own password for the site! Now please let me fix it before someone else forces you to. We're too busy with other projects right now? Oh, ok then, I'll just be quiet and ignore our poor security. Whilst I'm busy getting on with my other work, could you figure out what we're gonna do with the tatters of our client's business (in which our company owns a stake) in the aftermath of the attack?

When there’s a glaring user-facing issue in your company’s app that can cause the user to spend mobile data after specifically choosing a setting that’s supposed to prevent that.

And your boss says your fix is “out of scope for the current sprint.” And the product team agrees with him.

I ALREADY DID THE WORK AND HAD IT VERIFIED BY QA.

Sometimes I Hate agile. Then again, I don’t think we’re doing it quite right anyway.

Just found the most embarrassing security hole. Basically a skelleton key to millions of user data. Names, email addresses, zip codes, orders. If the email indicates a birthdate, even more shit if you chain another vector. Basically an order id / hash pair that should allow users to enter data AND SHOULD ONLY AUTHORIZE THEM TO THE SITE FOR ENTRING DATA. Well, what happend was that a non mathing hash/id pair will not provide an aith token bit it will create a session linked to that order.

Long story short, call url 1 enter the foreign ID, get an error, access order overview site, profit. Obviously a big fucking problem and I still had to run directly to our CEO to get it prioritized because product management thought a style update would be more important.

Oh, and of course the IDs are counted upwards. Making them random would be too unfair towards the poor black hats out there.

So I'm tasked with creating a single sign on link using documentation from the third party we are logging into. So far so good.

Well they don't support some of the fields our users will need--that we don't want to support (otherwise why use a third-party?).

Their solution is to make us the system of record so that when a user goes through the single sign on we pass this info as well. But it needs to be editable on their side well--because they won't give us an API for our system of record to update their side.

That's right only a user signing on from our system will update their side. Tough luck admins on our side. You get double duty due to the poor business decision to work with a company with lazy devs.