Its Friday, you all know what that means! ... Its results day for practiseSafeHex's most incompetent co-worker!!!

*audience: wwwwwwooooooooo!!!!*

We've had a bewildering array of candidates, lets remind ourselves:

- a psychopath that genuinely scared me a little
- a CEO I would take pleasure seeing in pain
- a pothead who mistook me for his drug dealer
- an unbelievable idiot
- an arrogant idiot obsessed with strings

Tough competition, but there can be only one ... *drum roll* ... the winner is ... none of them!

*audience: GASP!*
*audience member: what?*
*audience member: no way!*
*audience member: your fucking kidding me!*

Sir calm down! this is a day time show, no need for that ... let me explain, there is a winner ... but we've kept him till last and for a good reason

*audience: ooooohhhhh*

You see our final contestant and ultimate winner of this series is our good old friend "C", taking the letters of each of our previous contestants, that spells TRAGIC which is the only word to explain C.

*audience: laughs*

Oh I assure you its no laughing matter. C was with us for 6 whole months ... 6 excruciatingly painful months.

Backstory:

We needed someone with frontend, backend and experience with IoT devices, or raspberry PI's. We didn't think we'd get it all, but in walked an interviewee with web development experience, a tiny bit of Angular and his masters project was building a robot device that would change LED's depending on your facial expressions. PERFECT!!!

... oh to have a time machine

Working with C:

- He never actually did the tutorials I first set him on for Node.js and Angular 2+ because they were "too boring". I didn't find this out until some time later.

- The first project I had him work on was a small dashboard and backend, but he decided to use Angular 1 and a different database than what we were using because "for me, these are easier".

- He called that project done without testing / deploying it in the cloud, despite that being part of the ticket, because he didn't know how. Rather than tell or ask anyone ... he just didn't do it and moved on.

- As part of his first tech review I had to explain to him why he should be using if / else, rather than just if's.

- Despite his past experience building server applications and dashboards (4 years!), he never heard of a websocket, and it took a considerable amount of time to explain.

- When he used a node module to open a server socket, he sat staring at me like a deer caught in headlights completely unaware of how to use / test it was working. I again had to explain it and ultimately test it for him with a command line client.

- He didn't understand the need to leave logging inside an application to report errors. Because he used to ... I shit you not ... drive to his customers, plug into their server and debug their application using a debugger.

... props for using a debugger, but fuck me.

- Once, after an entire 2 days of tapping me on the shoulder every 15 mins for questions / issues, I had to stop and ask:

Me: "Have you googled it?"
C: "... eh, no"
Me: "can I ask why?"
C: "well, for me, I only google for something I don't know"
Me: "... well do you know what this error message means?"
C: "ah good point, i'll try this time"

... maybe he was A's stoner buddy?

- He burned through our free cloud usage allowance for a month, after 1 day, meaning he couldn't test anything else under his account. He left an application running, broadcasting a lot of data. Turns out the on / off button on the dashboard only worked for "on". He had been killing his terminal locally and didn't know how to "ctrl + c a cloud app" ... so left it running. His intention was to restart the app every time you are done using it ... but forgot.

- His issue with the previous one ... not any of his countless mistakes, not the lack of even trying to make the button work, no, no, not for C. C's issue is the cloud is "shit" for giving us such little allowances. (for the record in a month I had never used more than 5%).

- I had to explain environment variables and why they are necessary for passwords and tokens etc. He didn't know it wasn't ok to commit these into GitHub.

- At his project meetups with partners I had to repeatedly ask him to stop googling gifs and pay attention to the talks.

- He complained that we don't have 3 hour lunch breaks like his last place.

- He once copied and pasted the same function 450 times into a file as a load test ... are loops too mainstream nowadays?

You see C is our winner, because after 6 painful months (companies internal process / requirements) he actually achieved nothing. I really mean that, nothing. Every thing was so broken, so insecure / wide open, built without any kind of common sense or standards I had to delete it all and start again ... it took me 2 weeks.

I hope you've all enjoyed this series and will join me in praying for the return of my sanity ... I do miss it a lot.

Yours truly,
practiseSafeHex

At one of my former jobs, I had a four-day-week. I remember once being called on my free Friday by an agitated colleague of mine arguing that I crashed the entire application on the staging environment and I shall fix it that very day.

I refused. It was my free day after all and I had made plans. Yet I told him: OK, I take a look at it in Sunday and see what all the fuzz is all about. Because I honestly could fathom what big issue I could have caused.

On that Sunday, I realized that the feature I implemented worked as expected. And it took me two minutes to realize the problem: It was a minor thing, as it so often is: If the user was not logged in, instead of a user object, null got passed somewhere and boom -- 500 error screen. Some older feature broke due to some of my changes and I never noticed it as while I was developing I was always in a logged in state and I never bothered to test that feature as I assumed it working. Only my boss was not logged in when testing on the stage environment, and so he ran into it.

So what really pushed my buttons was:

It was not a bug. It was a regression.

Why is that distinction important?

My boss tried to guilt me into admitting that I did not deliver quality software. Yet he was the one explicitly forbidding me to write tests for that software. Well, this is what you get then! You pay in the long run by strange bugs, hotfixes, and annoyed developers. I salute you! :/

Yet I did not fix the bug right away. I could have. It would have just taken me just another two minutes again. Yet for once, instead of doing it quickly, I did it right: I, albeit unfamiliar with writing tests, searched for a way to write a test for that case. It came not easy for me as I was not accustomed to writing tests, and the solution I came up with a functional test not that ideal, as it required certain content to be in the database. But in the end, it worked good enough: I had a failing test. And then I made it pass again. That made the whole ordeal worthwhile to me. (Also the realization that that very Sunday, alone in that office, was one of the most productive since a long while really made me reflect my job choice.)

At the following Monday I just entered the office for the stand-up to declare that I fixed the regression and that I won't take responsibility for that crash on the staging environment. If you don't let me write test, don't expect me to test the entire application again and again. I don't want to ensure that the existing software doesn't break. That's what tests are for. Don't try to blame me for not having tests on critical infrastructure. And that's all I did on Monday. I have a policy to not do long hours, and when I do due to an "emergency", I will get my free time back another day. And so I went home that Monday right after the stand-up.

Do I even need to spell it out that I made a requirement for my next job to have a culture that requires testing? I did, and never looked back and I grew a lot as a developer.

I have familiarized myself with both the wonderful world of unit and acceptance testing. And deploying suddenly becomes cheap and easy. Sure, there sometimes are problems. But almost always they are related to infrastructure and not the underlying code base. (And yeah, sometimes you have randomly failing tests, but that's for another rant.)