I have a bunch of contesters fort the worst interview.

#1 The Dishonest Ignorant

Me: *asks question*
#1: *stumbles*
Me: It's okay to say that you don't know.
#1: *continues to ramble on without making sense*
Me: Well, okay. That is all. I don't think that this will be a fit.

#2 The fraud

Me: How would you rate your knowledge in object orientated programming?
#2: Very advanced! I am an expert!
Me: Can you state the difference of an interface and an abstract class?
#2: *surprised pikachu-face* Well not that advanced!

#3 The trickster

During a skype call (without video):

Me: *asks question*
#3: *keyboard sounds aclacking*
Me: Are you googling?
#3: No *click clack click a clack* ... and to answer your question: *starts reading from the first search results*

The real bummer is, that in all of these cases, just saying "I don't know" would have been fine. (The "expert" OOP-guy would still have some explaining to do.)

It's not like that our interview process resolves around trick questions or that you'd get kicked out for getting one answer wrong. Though how can I trust somebody not to lie to me on a daily basis if they fake their interview?

We keep the interview relatively basic and rely on real-word coding exercise anyway and it helps us to get an idea on where we would gain support from them and where we need to support them.

As a developer you spend a lot of time learning new stuff anyways.

It blows my mind.

Functional test are failing.

Expected: 7109
Got: 9000

Grep code-base for 7109. No findings. 0_o

Dig through test setup written by a drunk.

Find:

assert(actualPrice === 1800 * conversionRate)

Goddamnit. You shall not calculate your expected values in a test setup.

In ESnext, private properties are marked with `#`.

Who thought that was a good idea? No really, who thought that was a good idea?

Why not just -- I don't know -- introduce keywords like ... let me think ... public, protected and private!?

Why this:

class MyClass {
a = 1; // .a is public
#b = 2; // .#b is private
static #c = 3;// .#c is private and static

incB() {
this.#b++;
}
}

If this becomes part of the language, no JavaScript developer may joke about php usage of `$` anymore.

My colleagues: "We should fail for scalastyle issues! Warnings will get ignored! Nobody fixes them! We should enforce a clean code style!"

Also my colleagues: Create PR with loads of `// scalastyle:off` flags comments.

¯\_(ツ)_/¯

Don't reuse your fixtures!

Each test case should be isolated. Don't ever think just because some function requires a similar input, it's safe to reuse it ALL OVER THE PLACE.

Why? Because someday, you want to change one functionality of one unit.

And you adapt your tests, fix your code, and suddenly, by changing one fixture, you break dozens if not hundreds of unrelated tests and now you have to clean up that mess.

It's even worse for functional tests with all those interwoven parts so that it becomes hard to reason about the scope of your tests when lacking proper documentation.

How I know? BECAUSE I AM CLEANING UP YOUR MESS RIGHT NOW!

I jump on an existing scala project.

git pull && sbt compile test

Tests are failing.

Me: "Hey team, the tests are failing."

Team member: "That cannot be. They were passing for the the last run."

Me: "Did you run them locally?"

Team member: "No, on Jenkins. It was fine."

I check Jenkins.

Me: "What do you mean it's fine. The last successful deployment was on the end of May."

Team member: "The Pull Request checker always went through successfully."

I check how our Jenkins tasks are configured. It's true that the Pull Request Checker runs successfully yet due to a "minor misconfiguration" (aka "major fuckup") the Pull Request Checker only tests a tiny subset of the entire test suite.

Team members were were fine if their Pull Request got the "Success" notification on bitbucket's pull request page. And reviewers trusted that icon as well.

They never checked the master run of the Jenkins task. Where the tests were also failing for over a month.

I'm also highely confused how they did TDD. You know, writing a test first, making it green. (I hope they were just one specific test at a time assuming the others were green. The cynic in me assumes they outsourced running the tests to the Jenkins.)

Gnarf!

Team member having run the tests locally finally realizes: "The tests are broken. Gonna fix them."

Wow. Please, dear fellow developers: It does not kill you to run the entire test suite locally. Just do it. Treat the external test runners as a safety net. Yet always run the test suite locally first.

Is there a team that works truly productive and happy via an agile (scrum) workflow?

Or does it always distill down to an excuse for a chaotic workflow?

My experience and cynic nature has let me to assume the latter.

(That being said, I never had a dedicated scrum master to work with. So that may be the first of many problems.)

In the past, we used skype, hipchat, slack and now ... Microsoft Teams. What a tool.

Yes Teams, it makes total sense to tell me that my message is too long. I totally get it that you want me to rewrite my message and yes Teams, I should have rather attached it as a file to my message to begin with. Yes Teams, I wait for you to finish uploading those files before I can send the message. I'm sure there would be disastrous consequences if you send the message with my attached files as soon as you finished uploading. I don't even want to be productive. Thanks for helping me out.

Partner of ours claimed they are going to update their api. No breakage. My hopes were low and they did not disappoint.

Soon after the new version of their api went live, of course, loads of breakage. And the email contact with them is really fun.

Me: "Hello, since your update we get the issue A. Here's the complete communication."

Them: "We did not change the existing behavior. You are doing X wrong. Repeat that one call during the step and you should be fine."

Me: "Thank you, if I repeat the call, it does indeed work, albeit slower, since we are now repeating calls. Furthermore, our application was consuming your api for years and we did not change anything. So why is that step necessary now? Only after your update do our logs show errors from your API. And by the way, we now also have a issue with B. Why is that?"

Them: "Oh that's because your query the endpoint with "Fnord", try "Baz".

Me: "Yes, I do know that we query it with "Fnord" as that is what a previous endpoint of yours is responding to us. Why are we getting "Fnord"? What request do I have to make to get a "Baz" back?"

It feels like a game of wackamole. Squash one issue, ten more will pop up. I am one step away from becoming active-aggressive.

Deploying on stage.
Testing on stage.

Why does the issue persist on stage?

Testing on local. It is fixed!

Wtf?
Wtf!?
WTF???

Oh.

I did not merge my branch and deployed a new version on stage without any changes 🤦

It's Friday. I should go home.

Me: Asking a question that boils down to an xy-problem on stackoverflow.

5 upvotes

Me: Answering my own question pointing out that my question basically is an xy-problem and pointing out a direction to properly solve it.

4 downvotes

At least I am not the only one having a brainfart.

I really hate it when I work on a user story consisting only of a cryptic title: "Implement feature X".

Esp. when I missed planning during a holiday and can only wonder who in their right mind would have given it 3 points.

Why thank you.

Sometimes, just pulling the acceptance criteria out of somebody's nose takes days. It doesn't get better once I realize that not all external dependencies have been properly resolved. It's worse if there are other departments involved, as then you get into politics.

Me: "We are dependent on team X to deliver Y before we should have even planned this ticket. I'm amazed that our team was even able to estimate this ticket as I would have only raised a question mark during estimation meeting. We could have thrown dices during estimation as the number would have been as meaningful and I'd have more time to actually figure out what we should be doing."
Dev lead / PO: "I understand. But let's just do <crazy workaround that will be live until hell freezes over> temporarily."

It's borderline insane how much a chaotic work flow is branded as agile. Let's call it scrum but let's get rid of all the meaningful artefacts that make it scrum.

I just reviewed a pull request with a test case like (pseudo code):

# Test MyService

const mock = createMock(myService.myMethod)
.whenCalledWith("foo")
.returns("bar");
assert(mock.myMethod("foo") === "bar"));

Why though? Why are we testing the mock? What is happening here? This test has no reason of being there instead of a fuzzy feeling that we now have unit test to lure us into a false sense of security.

I asked why we don't do an integration test. Response was: "They are slow."

Well, duh, but at least they would actually test something.

What do you gain by asserting that the mock is working the way you set it up?

I embrace the removal of the audio jack on smartphones, and I like listening to music via my Bluetooth headset.

Yet why, for fuck's sake, is a double tap on the headset's play button mapped to Call Redial?

I have lost count how often I called someone by mistake. How is such on action a meaningful default? What were they thinking, were they thinking at all?

Everytime I turn on the goddamn headset, I take extra care to ensure that I don't doubletap yet it still often happens by mistake.

I rarely call people anyways on my smartphone anyways.

Doing pair programming while I was navigating on somebody else's computer, we hit a weird behavior that our code changes weren't reflected.

Trying everything it turned out: I forgot to save.

Yet: Why though would you make me save? And why did the IDE not warn me about compiling unsaved changes? I think it was eclipse for Java, oh well. What can I expect ...

Anyways, I have gotten so used to my editors autosaving content for me as I write it, that I completely forget about doing Ctrl + S myself.

I never understood the need to hit that key combination manually as if I break something: `get reset --hard` will help to get me to a working state. (And even if I mess it up differently, my IDE's local history also let me restore recent changes.) And if it is a workign state, then I like to commit early and often. and

I am really dumbfounded why people insist on hitting save themselves.

I had no idea of how to implement the logic of a ticket. That's why I started with creating some unit tests that failed. Then I continued working until they all passed.

So it works now.

I have still no idea of how I implemented the logic.

What aren't there any 2k 32 inch 144 Hz monitors out there that are: flat. I want to upgrade my home setup from a 24" setup, which is, you know, flat. Even back in the days of the CRT monstrosities I've spent a premium on getting a flat panel, as the outside curvature was a technical obstacle to overcome.

I don't understand the need to curve the display. It distorts the lines, hinders other people looking at your screen as you have to be in the right spot, and every camera records on a flat surface. Why should it be a good thing to go curved?

I am reminded of the 3D craze.

```
public someMethod(index: string): Promise<void> {
return Promise.resolve(someAsyncFunction().then(() => {
return;
})
.catch((error) => {
this.logger.error(error);
throw error;
});
```

Somebdoy doesn't know their async / await syntax but they wanted aboard the promise-hype train. There is an entire class in that style.

If a project's structure is shit, well of course, let's continue using it because "it is known". Doing it any other way "will add complexity".

That I wasted three days making my working code adhere to the clusterfuck of a structure, nevermind that. Let's continue. And yes, colleagues do agree that the structure is shit, though let's improve it ... later.

Or in other words: Suck it up, we always have done it this way. Fuck you and your ill-advised attempts of trying to improve it.

Well, if your tests fails because it expects 1557525600000 instead of 1557532800000 for a date it tells you exactly: NOTHING.

Unix timestamp have their point, yet in some cases human readability is a feature. So why the fuck don't you display them not in a human readable format?

Now if you'd see:

2019-05-10T22:00:00+00:00

vs the expected

2019-05-11T00:00:00+00:00

you'd know right away that the first date is wrong by an offset of 2 hours because somebody fucked up timezones and wasn't using a UTC calculation.

So even if want your code to rely on timestamps, at least visualize your failures in a human readable way. (In most cases I argue that keeping dates as an iso string would be JUST FUCKING FINE performance-wise.)

Why do have me parse numbers? Show me the meaningful data.

Timestamps are for computers, dates are for humans.

Don't run `npm install` on your build machine. Use `npm ci` instead.

You want to re-merge a branch after a previous merge has been reverted on the mainline branch?

That's easy! Just revert the revert commit and then merge again. Because logic.

This is just evil.

Unlocking a dark theme by inviting friends to a service I just wanted to try out.

Also the wording is annoying. Yes, I do want the dark them, I just don't want to spam my friends for it. Subscription process cancelled, dickheads.

I forgot my password to my mindfactory account, one of Germany's biggest online vendor for computer components. So I go through the resetting process, which is:

- apply for password reset
- get a mail
- confirm the mail
(So far, so good)

- get a mail with a new CLEAR TEXT PASSWORD

Is this the stone age!?

You never send an email containing the cleartext! You never even store the password as is!
You, as the provider, should never be able to know what the actual password was.

All you are supposed to do is to generate a random salt, and hash the user's password with the salt, and then you only store the salt and the hash. And whenever a user inputs their password, all you do is to check if the you can recreate the hash with the help of the salt and your hash algorithm. (There are libraries for that!)

If a user wants to reset their password? Send them to a mail with link on where they can assign a new password.

At no point should the password ever be stored or transmitted in any other medium.

In my company, we have been have been using skype, hipchat, slack and now Teams.

Yet somehow, email always survives.

I get it as a communication channel for external clients as everybody has an email.

Yet when you as a company are using a team messenger, well then use it as your primary communication tool NO EXCEPTIONS or don't use them at all.

I don't.

This image sums it up pretty much (even though it was made for university).

Source: https://onetwentyseven.blog/2017/...

PM: "I have an easy question for you."
me: "Well let me decide if it's easy."
PM: "Where do the images for X in project Y come from?"
me: "Good question. No idea. I will come back to you."

I have seen spaghetti php code, I have seen spaghetti JavaScript code, I have seen spaghetti python code. I have seen a lot of spaghetti.

Yet this Angular project appears like it was touched by His Noodly Appendage.

And only his Noodlyness knows what's going on in there. It's truly beyond my mere mortal means of understanding.

One of those debugging days where minutes feel like hours, and hours like days.

I had the bad luck of being asked to dive into a legacy project which was unmaintained for months, but of course it's still on prod. And very suddenly the urgent need arrises to change stuff.

Yet: the docker stack won't work. It builds fine but the stack crashes.

Long story short: some internal api URI were renamed and at some point one internal api started to always require an access token. Which we set for the stage, prod env yet somebody forgot to mention that to the devs of legacy-project.

That ain't too bad.

WHAT IS FUCKING BAD IS THAT YOUR SHITTY APP SWALLOWS THE ERROR MESSAGE!

I mean it's bad enough I have to `var_dump && die` your app since you never bothered to setup a xdebug that I could use out of the box, yet egregious fact that your app would catch a valid exception but transforms it into an "internal warning" is borderline insane!

It's ok to throw exceptions. It's ok to let your service die. That's how other will know what and where to fix it. (You may want to restrict the data visible to the outside, but that's a whole different conversation.)

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.