When you are at a crossroads, what helped you to decide?

I have two great job offers, and though my gut feeling is telling me to go one way due to tech stack and first communications, the other opportunity is (slightly) better paid and the company is much larger and nationwide active.

"It would be great if the feature would be implemented either today or tomorrow."

Well, nice wishful thinking. It does not constitute an emergency on my side though.

"Just start ahead"

I am supposed to transform calls from one api to another one. Yet there's no documentation, ambiguous code statements, no examples of what values are contained -- but sure, let me just start assuming how the whole thing is supposed to work. That won't lead us more into a murky waters at all.

Even more frustrating: We own the api. We should be able to tell by the access logs how we are queried. Yet for some reason, access logs cannot be accessed and I shall "just work from the swagger defintion".

Well, that swagger definition is broken, its example are shit (somebody liked to use undefined in optional fields, making me wonder even more what the heck is going on here), and I have no idea of what I am doing. Fun times.

I always confuse `for..in` with `for..of` and have to look up their respective meaning. Again.

It drives me crazy.

Do you have any mnemonic on this? How do you remember the difference?

(Now, as in this very moment, I know that for..in is for looping over keys of an object and for..of for looping over iterators. But tomorrow I will have forgotten it again.)

Sometimes people want to be too smart. If you want to consume a handful different restful API, it might make sense to abstract away some common functionality in your client implementation — yet to assume they follow the same convention in how their URI is built is borderline insane.

All I wanted to do was to change one API to a newer version, and now the implementation breaks for at least two other because it was done in an Abstract class and now I have to untangle that mess.

In some cases code duplication wouldn't be that bad. Even if an otherwise unrelated API seemingly share the same contract, still assume it has its own contract. You never know how those API evolve and I proclaim they will evolve towards breaking your assumptions.

"Could you help on project X and implement that straight forward feature?"

So I clone the repo. Run the tests in the main branch. 20 tests fail.

Yes, this will be fun and very simple ...

Uploading an xslx file to office365 to download it as an ods file only to be able to convert it to a csv file via libre office.

Direct conversion attempts with other tools would either fail converting the xslx file or break cells' values (ssconvert, soffice --headless -c, gnumeric).

One of those things where I fail to understand why it has to be so complicated.

Am I the only one who wants to be able to write functions in a human readable way, allowing for parameter in-between the words?

Instead of defining:

const enforceStringEndsWithChar(string: string, char: string) => {...}

I want to define it as:

const enforce(str: string)EndsWith(char: string) => {...}

.
.
.

I'll see myself out.

Did you ever think time estimations are hard? If so, did you ever try adding your actual taken time months after working on a ticket?

The "unit" in unit test does not mean your ENTIRE APPLICATION. Ever heard of scope!?

I am amazed how often people write overblown test setups, mock hundreds of unrelated services, just to test one tiny bit of logic.

That bit of logic could have been a pure function.

For that pure function you could write a dead simple unit test. Given that input, I expect that output. Nothing more, nothing less. (It helps even more if the pure functions only accepts primitives, like string and numbers, or very simple immutable value objects).

No I don't care that the service is used by another service, as your mocked interaction also doesn't test the service as a whole but you just assume the happy case most of the time anyway. You want to test the entire application? Let's not use unit tests for that but let's use a different kind of test for that (integration test, functional tests, e2e-tests).

If you write code in a way that easily allows for unit testing, your need to mock goes away.

Why yes, it makes total sense for a variable called `$connectionString` to only accept either booleans or integers ... wat

Also beware the beauty on how well that names conveys the variable's intent.

FML

After months I finally received an email from the external partner's support team!

```
Please be informed that we consider your Incident "XXX: How to Y?" as closed with status: Closed.
```

Why thank you.

As I was refactoring a class in a TypeScript project, I changed calls from `this.config` to `this.getConfig()`.

Suddenly, the tests were failing as somehow the live credentials were used from within the test.

Digging deeper I discovered this.

interface Base {
public config;
public getConfig();
}

So far so good. Wondering why config needs to be public, though nothing too shabby, let's look further:

class MyImpl implements Base {
constructor() {
this.config = this.getConfig()
}

getConfig = () => someGlobalVar;
}

┻━┻︵ \(°□°)/ ︵ ┻━┻

Why would you do this? This breaks dependency injection completely.

In the tests, we were of course doing:

testMe = new MyImpl();
testMe.config = testConfig;

So even though you have a getter, you cannot call it safely as the global var would take precedence. It's rather used as a setter within the constructor. WTF.

Sad part is that this pattern is kept throughout the entire codebase. So yeah for consistency!?

(And yes, I found a quick workaround by doing

getConfig = () => this.config || someGlobalVar;

though still, who in their right mind would do something like this?)

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.