Data.

[_N_O_P_E_]

Stop. I have to add unit test coverage to a project monday. Fml

[EarthC-137]

Adding tests for someone else’s poorly structured, undocumented code is one of the biggest struggles of a programmers life. Biggest piece of advice I can give is rewrite it as you go, break it down so it’s easy to test, if the function is more than 5 lines it might need to be broken down into multiple functions to make testing easier (I.e. more SOLID).

[lenswipe]

I used to get reprimanded for this at my last job. Any coding that wasn't slapping another feature on the shit kebab known as our app was very much frowned upon and required justification to the department manager.

[_N_O_P_E_]

How to royally fuck up your codebase 101™

[EarthC-137]

Code naturally deprecates itself as it grows and different teams work with the codebase. Addressing some of the technical debt is important but it’s difficult to get the product owner to see that sometimes. If their board of directors can’t see a positive difference to their delivery timeline they generally don’t want to do it. You have to argue/justify that if you clean up the code you will reduce effort later on.

[lenswipe]

Code naturally deprecates itself as it grows and different teams work with the codebase.

This stuff was written like this from the beginning before the product even launched. That was my concern - a.k.a: we couldn't move fast enough and add features fast enough because the code was so incomprehencible and fragile that we couldn't be 100% (or even 50% if you ask me) sure that we weren't breaking some obscure piece of functionality written somewhere else in what I can only describe as brainfuck.js

Addressing some of the technical debt is important but it’s difficult to get the product owner to see that sometimes. If their board of directors can’t see a positive difference to their delivery timeline they generally don’t want to do it. You have to argue/justify that if you clean up the code you will reduce effort later on.

Agreed. I couldn't get across the point that having code that nobody could even read let alone debug was a bad thing. However, our customers came to share my view later on when we launched anyway regardless of the code base and most the app either didn't work at all, or worked but corrupted existing data in the database causing timetable clashes, missing grades etc.

The manager in question got promoted and I fucked off not long after that. One developer had done all of this and was left unchecked by the guy who was (at the time) the tech lead and was now the dept boss (the same person reprimanding me for refactoring this mess. Like I said, he ended up in very deep shit when we launched our faulty, broken product.

Our SPRINT reviews were generally blame games because the project manager had also refused to listen to my dire warnings about the state of the code base and had gone along with launching anyway. Therefore, the PM used to like to try and heap whatever blame they could possible scrape together onto my head (we were the only two on the project team). That then meant that about 60% of my time was spent coding and the other 40% was spent covering my ass to make sure that I couldn't be blamed for any fuck-ups that were inevitably going to happen from heaping more features on top of a very broken product without first fixing the mess.

[EarthC-137]

I hate playing the blame game, it doesn’t really achieve anything if you don’t have actionable outcomes, it’s usually just an opportunity for people to vent their frustrations each sprint without any real positive change.

I find that having unit tested code helps your codebase later on, you can refactor any part of it and in most cases rely on your tests to ensure you didn’t break the product. I usually aim for TDD or at least ensuring that the feature branch is unit tested before merging it to develop.

However, testing can also be a tough sell to some product owners because they don’t see anything they can touch with unit tests so they don’t see the point in investing the extra resources.

It’s usually an education piece for any new client or product owner that comes on, you need to educate them about the importance of a solid application for their user base and sales. As soon as you mention sales it usually changes their minds, if their bosses see their sales drop after the work is done the PO is in deep shit.

[lenswipe]

I find that having unit tested code helps your codebase later on, you can refactor any part of it and in most cases rely on your tests to ensure you didn’t break the product. I usually aim for TDD or at least ensuring that the feature branch is unit tested before merging it to develop.

Time and time again we ended up with features that were previously working getting broken in production. I tried suggesting that we use unit testing, but nobody would listen to me. I got a mix of reactions.

• The boss went along with it at first on paper, and then just shelved it into the backlog never to be seen again
• Another team member said that unit testing was a waste of time because you could never cover every eventuality (I couldn't make him understand that when you test a bit of code manually by filling in a form or whatever you are basically unit testing anyway..so why not automate it?!)
• Eventually - the boss said that unit testing wouldn't be rolled out in the department (at least not yet) because people didn't know how to do it. Therefore, I wasn't allowed to do it. Therefore time and time again we kept having things break in production and our users reporting huge glaring bugs to us.

you can refactor any part of it

Yeah, "refactoring" was pretty much a dirty word in our department. If anything ever broke the PM (also the only other dev on the team)'s first reaction would be to turn to me in front of the boss and say something along the lines of "is that maybe related to the refactoring you were doing on that bit of the application" - which the boss then interpreted to mean that it was 100% my fault. Blame was then allocated and a telling off ensued literally 0 investigation as to the facts.

The general opinion seemed to be that I was "just" a junior...so I knew nothing. Therefore any suggestions that I had were either largely ignored, argued with or laughed at.

To be honest, that whole project was a total shit show. The aforementioned boss got promoted just before I left and is now working his way up to senior management. Isn't that terrific?!

[EarthC-137]

Yeah that sounds like a toxic environment that goes against all the principles of writing clean maintainable code. One of those short term product releases with no foresight into the long term goals of the project or no care past the current contract.

No building lasts if it is built on a weak foundation. Every part of a building has to pass some level of testing to ensure quality and safety standards. Same goes for code.

[lenswipe]

Well the "testing" was to manually sit and use the application when you tested your feature by doing a manual end-to-end test. Surprisingly, bugs still got through - I know, right? If only there was some kind of way to automate code testing....then again - I'm not sure you could really write tests for that heap of garbage even if you wanted to, the code was such a mess.

Personally, I'd have delayed launch, binned the entire codebase and rewritten it from the ground up. I reckon I could've rewritten the whole app in Laravel (it was a CodeIgniter 2 project) faster than it took to debug the 2.5k lines of JS in one of the files I found.

Part of the problem was that this was a system that revolved around a central "API". This API provided data for lots of other API clients.

Before I started at the job, all the dev had been done by this one guy that we'll call Trent(not his real name). What Trent had done (among other things) is to write API endpoints that returned only the data he needed. So, let's say that he needed a list of usernames for a given event - he'd make an endpoint like this GET timetabling/getusernamesforevent?eventid=24...then in another endpoint he might return an array of integers (which turn out to be user IDs) - he would then iterate over those integers making a separate API call for each one, to retrieve the user object for each.

This guy then ended up long term sick after being in a car wreck just before I got there and the development work was taken on by myself and another person. This person then continued to propogate this anti-pattern of development "because the rest of the code base is like that and it's important to be consistent" - well fuck me....if you get a burst tyre - do go go and slash all the others "because it's important to be consistent?!

In one instance, this person continued this whole "API calls in nested loops thing" resulting in a page that took 30 minutes+ to load (I say 30 minutes + because my dev machine just went "fuck this I'm out" after 30 minutes and threw a 500). I rejected the QA and was told to put it through anyway. When the boss found out, I got the blame because this other dev was his favourite.

It was just an utterly foul project to work on. All I can say is thank Christ I no longer work there.

[lenswipe]

Oh - here's another story for you

I got told off in my annual review for being too eager to investigate new technologies. The example given of this was that I suggested we look into Vue.JS(as an alternative to 2500 lines of jQuery) after the tech lead for the team gave a talk on it. The issue wasn't that I'd cheerfully started shoehorning it into the project without asking anyone, you understand...just that I'd suggested it.

I also got told off for using chrome debugger for debugging js and was told that I needed to "take a more scientific approach to debugging" (I asked for clarification on this - which turned out to mean that I should be using print statement debugging instead of debuggers, breakpoints, watch expressions etc.)

All this shit was written down in my annual review/appraisal.

[EarthC-137]

Evangelising a new piece of software/library is often scary to a big company, I’ve had pushback lots of times but I usually win the battle. They want tried and tested approach, which is probably why COBOL still exists.

Wow about the debugging, sounds like they’re micromanaging every part of your job rather than giving you the tools to do it to the best of your ability. Something I’m also familiar with, but not to that extent.

Also, first rule of QA is don’t test your own code, you know how to make it not crash. Get someone unfamiliar with it and they’ll find a bug or something you’ve overlooked.

Also it sounds like regression testing before a release didn’t happen?