Second semester

Java - OOP Course

We had to write a game, an arkanoid clone

Neat shit

And a fun course, mad respect to the Prof.

BUT

Most students, including me had this ONE bug where the ball would randomly go out of the wall boundaries for no clear reason.

A month passed, sleepless nights, no traces.

Two months later. Same shit. Grades going down (HW grades) because it became more and more common, yet impossible to track down.

3 months later, we had to submit the HW for the last time which included features like custom level sets, custom blocks and custom layouts.

So before we submit the game for review, they had pre-defined level sets that we had to include for testing sake.

I loaded that.

The bug is back.

But

REPRODUCIBLE.

OMG.

So I started setting up breakpoints.

And guess what the issue was.

FLOATING FUCKING POINT NUMBERS

(Basically the calculations were not as expected)

Changing to Ints did it's job and the bug was officially terminated.

Most satisfying night yet.

Always check your float number calculations as it's never always what you expect.

Lesson learned, use Ints whenever possible.

Dev manager: Can you fix this issue?

Me: Yeah, but i cant reproduce it using the explanation given in the ticket. Can i get a step by step guide and a confirmation that the issue is reproducible.

Dev manager: you're the lead dev, you figure it out.

askdjasfkjksadjkasd!!
Do you want me to spend an hour not developing things trying to guess? because that is how you make me spend an hour not developing things

During QA for a huge project when our dev team was confident of the stability of the project, We started introducing small bugs, QA team use to raise bugs in Jira, we marked them as not reproducible.

Frustrated QA started coming to our cubes - at this point dev team worked in a perfect coordination like a man to man marking in hockey. While one dev asked QA guy to reproduce the bug in front of him while the other dev has already fixed it.

Continued for a couple of days till our team lead was satisfied with the revenge.

When a Java nullptrexception is not reproducible.

I hate Sass.

When installing all NPM dependencies with npm i, it's always quick, but not with sass. Ooooh myy goood. It starts compiling. It always misses something. Your node version is always not what sass needs. It pulls out gyp which requires some native shit. The build is never reproducible, it always fails with some horrible two mile long poorly-formatted stacktrace that is just gibberish.

More than that, sass is just poorly designed tool used by frontend fuckboys to write imperative, nonstandard, non-maintainable styles. If you know shit about css, you don't need sass.

I'm so happy it's going to die along with gulp. Webpack and css modules are here.

Yes, css-in-js that has a runtime penalty is also shit. If you like its syntax but dislike everything else, use Linaria. It has no runtime penalty and looks just like other css-in-js solutions.

One of those mysterious bugs that only happens on production. Want to solve it on your laptop, it's not reproducible. Staging server? Nope. Production?

HOW DARE YOU TOUCH THE LIVE SYSTEM?!?

Below is a transcript from work Slack today. Only the names and some code are changed. It ended up causing a bit of drama. DevRanters, what do you take from this?

---

Delivery Lead:
Hey Gang. What's the blocker for FEATURE-123?

Dev1:
FEATURE-122 crashed on iOS app when viewing Feature Introduction page.

Teach Lead:
I've talked about this with Dev1 on a side channel.
And diagnosed the stack trace.
It looks like there is/was some bad handling of a List in the Feature Introduction view logic.
But this is confined to changes that Dev2 is still working on.
(It's not present in master)
Dev2, what's your current position on this?

Dev2:
I have tested at my end with Dev1 but it seems to be working fine

Tech Lead:
There is a race condition related to the use of someList.first()
My guess is that theres a Flow of those lists defined, with an initial value of emptyList
And that on your machine, that Flow is updating with a new value quickly enough that it doesn't matter.
But on Dev1's, for whatever reason, it doesn't get there in time, hits the empty list and falls over.
The logic that's performing the first() needs to gracefully handle empty lists as well.

Dev2:
Where is that logic called?

Tech Lead:
Here's the stack trace Dev1 provided in our conversation earlier:
Caused by: kotlin.NoSuchElementException: List is empty.
...
at 3 iosApp 0x00000000 kfun:kotlin.NoSuchElementException#<init>(kotlin.String?){} + 00
at 4 iosApp 0x0000000 kfun:kotlin.collections#first@kotlin.collections.List<0:0>(){0§<kotlin.Any?>}0:0 + 000
...
at 9 iosApp 0x0000000 kfun:kotlin.coroutines.native.internal.BaseContinuationImpl#resumeWith(kotlin.Result<kotlin.Any?>){} + 0000

This line:
kfun:kotlin.collections#first@kotlin.collections.List<0:0>()
...says that it's first() being called on an empty list.

Dev1:
FYI: Dev3/Dev4/myself are seeing the same issue with the same stack-trace above.

Tech Lead:
So Dev2, have you introduced such a call?
Because I checked master branch and there isn't one, in that version of the file.
Ok, I'll check your working branch Dev2
...
Yes you have here:
var processed1 = someList.first()
var processed2 = someList.first()
...
Lines 123, 124.
Solution looks really straightforward guys.

Dev2:
Okay, I will fix that and push the change

Tech Lead:
Check if someList is empty and allow for generating / handling null processedValues in the view.

Now; I'm going to be straight with you here.
This issue has been discussed over several hours today.
I expect that either one of you could have gone through the process I did in the last 10 minutes above, and resolved it in the same way :point_up:

Dev2:
I went on a break and it's not reproducible on my machine

Tech Lead:
I didn't reproduce it on mine either.

Dev1:
Dev2 and myself are now on sharing screen to sort this issue out. Hope to update back later.

Tech Lead:
<Screen shot of diff with changed code>
:point_up: That change should do it.

Dev2:
Already have pushed the change.

Tech Lead:
...just seen it, is good - same approach :ok_hand:
Dev1 please let us know when tested on your machine.

Dev1:
That does it. It fixes the issues. Thank you, Dev2. I will pick it off from here.

Tech Lead:
Glad to hear it guys.

Dev1:
I have to say this that it is not because we are not working on the issue - Dev2 and myself (together with Dev3/Dev4) have been on this issue all this morning. It just difficult to connect the dot when it wasn't reproducable on Dev2's machine. I brought the issue up because I wanted to switch to working on other tickets while waiting for this to resolve. Still thank you largely for Dev2's work and your keen eyes that spot and resolve the issue quickly.

Tech Lead:
Noted Dev1.
I think the take-away has to be to read the stack-trace carefully... don't worry - we've all been guilty of not reading the error in full, at some point.
The stack trace said that the 'first' element is being referenced from an empty list - that's just logically impossible, right?
Looking for that call to first, we saw it wasn't in the code before, and is after (two of them, in fact).
So then we ask ourselves, how can we deal with an empty list - and then solution almost presents itself.
It didn't really take reproduction of the error to resolve.
Maybe working with a new tech stack creates an anxiety that every issue faced will have a complex solution related to that stack; but I think you'll agree, this particular issue really just required a deep breath and your trusty 'debugging skills 101'... don't lose them! :smiling_face:

Renaming a file is just too difficult for this piece of shit software.

Fixing bugs? Fuck no.

Fixing crashes? Fuck no.

Fixing the unnavigable IDE settings? Fuck no.

The IntelliJ platform is a bloated piece of shit at every level.

JetBrains cannot produce software that isn't held together by duct tape.

I can't name a single item of software they've ever produced that isn't a bloated piece of shit.

Even if you are prepared to waste a lot of time trying to file a bug report – which they usually just ignore or pretend not to be reproducible – you have to use another in-house heap of shit called YouTrack.

Have you tried using this piece of trash that masquerades as a bug tracker?

These people are fucking clinically insane.

While your IDE becomes unresponsive and crashes without warning, or your keyboard shortcuts just mysteriously stop working in the IDE, or indexing just stops working for no reason, why not check out their TikTok and Twitter accounts?

They've got an excellent PR team that knows how to polish a turd for public consumption, and to make money out of it.

"Just let me know when you're done (today) with that handful of JIRA tickets that are not reproducible, have no description, and include no error information. We need to get them into the next release."

Yeah. Yeah, I'll let you know real soon.

For me, it was when I was on a team doing government work. We had an entire team devoted to deployments etc which were handled via ansible.

Ansible was fairly new at the time (~2015, they had just been bought by RedHat) but the team was definitely doing a great job picking it up and creating install playbooks for _every_ piece of our distributed infrastructure (load balancers, application servers, queues, databases, everything).

I luckily left before stuff got too hairy, but last I heard they are more than 6 months behind schedule. They STILL can't get a reproducible install process with the ansible playbooks! And it's all due to tech debt ie not giving any time to fix things, so its just band aid after band aid.

It's really sad to hear because the sytem itself was pretty cool, completely horizontally scalable and definitely miles ahead of the program they've been using for the last 20 years.

Ha, Microsoft closes my easily reproducible issue with their Monaco editor as 'resolved':

> posted "resolution" is totally wrong, it's not even in the TypeScript typings of their own library or anywhere in the documentation

jesus christ today is not my day

seems like everyone already started chugging the Christmas eggnog, maybe I'd just give up and start do the same

Hire are a few tips to up productivity on development which has worked for me:

1) Use a system of at least 16gb ram when writing codes that requires compilation to run.

2) Test your code at most 3 times within an hour. This will combat the bad habit of practically checking changes on every new block you write.

3) Use internet modem in place of mobile hotspot and keep mobile data switched off. This will combat interruptions from your IM contacts and temptations to check your WA status update when working.

4) Implementation before optimisation... This is really important. It's tempting to rewrite a whole block even when other task are pending. If it works just leave it as is and move on to the next bull to kill, you can come back later to optimise.

5) Understand that no language is the best. Sometimes folks claim that PHP is faster than python. Okay I say but let's place a bet and I'll write a python code 10 times faster than your PHP on holiday. Focus more on your skill-set than the language else you'd find yourself switching frameworks more than necessary.

6) Check for existing code before writing an implementation from scratch... I bet you 50 bucks to your 10 someone already wrote that.

7) If it fails the first and then the second time... Don't try the third, check on StackOverflow for similar challenge.

8) When working with testers always ask for reproducible steps... Don't just start fixing bugs because sometimes their explanation looks like a bug when other times it's not and you can end up fixing what's never there.

9) If you're a tester always ask for explanations from the dev before calling a bug... It will save both your time and everybody's.

10) Don't be adamant to switching IDE... VSCode is much productive than Notepad++. Just give it a try an see for yourself.

My 10 cents.