If your IDE found

10 errors

and 47 warns

would you correct them

or let them slip.

YO ...

His palms are sweaty

Knees weak, arms are heavy

The tests are failing already

Code spaghetti.

He's nervous,

But at his laptop he looks calm and ready
To squash bugs

But he keeps on forgetting

What he wrote down, the whole team goes so loud

He opens his file, but the code won't come out

He's chokin', how, everybody's jokin' now

The deadline run out, times up, over, blaow!

Snap back to reality, oh there goes file integrity

Oh, there goes documentation, he choked

He's so mad, but he won't give up that easy? No

He won't have it, he knows his whole header's code

It don't matter, he's dope, he knows that, but he's broke

He's so stacked that he knows, when he goes back to his mobile home, that's when its

Back to the office again yo, this whole rhapsody

He better go capture this moment and hope it don't pass him

Note: All credits to the original owners of these phrases.

A big project in my company. Had some annoying race condition that caused data to get deleted when two processes finished in the wrong order they hit the dB and override each other’s work.

Long story short. Fixed the bug and in the process the codebase shrunk by 60%. I didn’t have to delete the rest of the code, but the bug was due to a function in the legacy section of the code, and found out that it was the only function used in that section.

So I deleted it. Rewrote the function so it upserts. And bam. Smaller, cleaner code :)

Proudest bug squash? Probably the time I fixed a few bugs by accident when I was just trying to clean up an ex-coworker's messy code.

So I used to work with a guy who was not a very good programmer. It's hard to explain exactly why other than to say that he never really grew out of the college mindset. He never really learned the importance of critical thinking and problem-solving. He did everything "by the book" to a point where if he ran into an issue that had no textbook solution, he would spin his wheels for weeks while constantly lying to us about his progress until one of us would finally notice and take the problem off his plate. His code was technically functional, but still very bad.

Quick Background: Our team is responsible for deploying and maintaining cloud resources in AWS and Azure. We do this with Terraform, a domain-specific language that lets us define all our infrastructure as code and automate everything.

After he left, I took on the work to modify some of the Terraform code he'd written. In the process, I discovered what I like to call "The Übervariable", a map of at least 80 items, many of them completely unrelated to each other, which were all referenced exactly once in his code and never modified. Basically it was a dynamic collection variable holding 80+ constants. Some of these constants were only used in mathematical expressions with multiple other constants from the same data structure, resulting in a new value that would also be a constant. Some of the constants were identical values that could never possibly differ, but were still stored as separate values in the map.

After I made the modification I was supposed to make, I decided I was so bothered by his shitty code that I would spend some extra time fixing and optimizing it. The end result: one week of work, 800 lines of code deleted, 30 lines added, and a massive increase in efficiency. I deleted the Übervariable and hardcoded most of the values it contained since there was no possible reason for any of them to change in the future. In the process, I accidentally fixed three bugs that had been printing ominous-sounding warnings to the console whenever the code was run.

I have a lot of stories about this guy. I should post some more of them eventually.

I don't know who you are. I don't know what you want. If you are looking for ransom, I can tell you I don't have money. But what I do have are a very particular set of skills, skills I have acquired over a very long career. Skills that make me a nightmare for bugs like you. If you let my program go now, that'll be the end of it. I will not look for you, I will not pursue you. But if you don't, I will look for you, I will find you, and I will debug you.

I would be have to say waking up to fix bugs really works better than coffee

I made a huge mistake

I got "in the zone", I was coding so nice and fast and everything was working, so I didn't want to commit every single minute and then have to go back, cherrypick commits squash them revert them etc.

So I didn't commit anything at all... Now if I were to commit the commit would modify 2 files, create 26 new files and delete 2 files.

The changes include moving from JS to TS, implementing a desearialization scheme, implementing a server class and wrapper client classes, with common type interfaces for different requests...

So now I need to save my changes somewhere, go back to the last commit and slowly incorporate the changes.

I'm dumb

I love git stash.

It's helps a lot for doing refactors to me. I guess it's not the most complex workflow, but it wasn't obvious to me when I started with git. Let me explain.

Refactors. As you start writing the first lines of a refactor, you start to notice something: you're changing too many things, your next commit is going to be huge.

That tends to be the very nature of refactors, they usually affect different parts of code.

So, there you are, with a shitload changes, and you figure "hey, I have a better idea, let me first do a smaller cohesive commit (let's call it subcommit) that changes a smaller specific thing, and then I'll continue with the upper parts of the refactor".

Good idea, but you have a shitload of changes nearly touching every file in your working copy, what do you do with these changes? You git stash them.

Let's say you stash and try to do that smaller "subcommit". What sometimes happens to me at this point is that I notice that I could do an even smaller change inside this current "subcommit". So I do the same thing, I git stash and I work on that even smaller thing.

At some point I end up `git stash pop`ing up all these levels. And it it shows that git stash is powerful for this.

* You never lose a single bit of work you did.
* Every commit is clean.
* After every commit you can run tests (automated or manual) to see shit is still working.
* If you don't like some changes that you had git stashed, you can just erase them with git reset --hard.
* If a change overlaps between a stash you're applying and the last "subcommit", then
if they differ, git shows conflicts on the files,
if they are identical, nothing happens.

with this workflow things just flow and you don't need to wipe out all your changes when doing simpler things,
and you don't need to go around creating new branches with temp commits (which results in bloated temp commits and the work of switching branches).

After you finish the refactor, you can decide to squash things with git rebase.

(Note: I don't use git stash pop, because it annoys the fuck out of me when I pop and you I get conflicts, I rather apply and drop)

let me preface with the fact that I'm now known at my new job for being the resident cli hipster. I can't lay any claims to knowing if it's "better" but I like it, I don't care if you do or don't, it just works for me and my flow

so at my job, we generally squash all our commits into one commit and delete the source branch upon merging; i accidentally committed all my work to an old, already merged branch, so my boss tells me it would be more of a PITA with the weird references we would encounter by merging the branch again, rather than just cherry pick the commits into a new branch, which i'm like "eh, fine.".

HIM: "You want to share your screen so we can resolve this?"
ME: "k"
HIM: "Oh, you won't be able to do this in a terminal, you are going to have to load up a GUI of some sort"
ME: "lawlz, no you don't"
HIM: "i highly doubt you will be able to accomplish that, but if you wanna make an ass of yourself, i'll humor you"
ME: "yeah, watch this"

> git log > log.txt
> git checkout <new branch>
> git cherry-pick <copy-paste-full-commit-hash-here>
> git push

ME: "done"
HIM: "what? there's no way you did it that easily, where are all your other commits???"
ME: "i usually try to amend my commits since we squash them anyhow. it really helps in situations like this"
HIM: "well, you go girl"

roll that up in your fancy degree and smoke it, why don't ya?

One of the worst practices in programming is misusing exceptions to send messages.

This from the node manual for example:

> fsPromises.access(path[, mode])

> fsPromises.access('/etc/passwd', fs.constants.R_OK | fs.constants.W_OK)
> .then(() => console.log('can access'))
> .catch(() => console.error('cannot access'));

I keep seeing people doing this and it's exceptionally bad API design, excusing the pun.

This spec makes assumptions that not being able to access something is an error condition.

This is a mistaken assumption. It should return either true or false unless a genuine IO exception occurred.

It's using an exception to return a result. This is commonly seen with booleans and things that may or may not exist (using an exception instead of null or undefined).

If it returned a boolean then it would be up to me whether or not to throw an exception. They could also add a wrapper such as requireAccess for consistent error exceptions.

If I want to check that a file isn't accessible, for example for security then I need to wrap what would be a simple if statement with try catch all over the place. If I turn on my debugger and try to track any throw exception then they are false positives everywhere.

If I want to check ten files and only fail if none of them are accessible then again this function isn't suited.

I see this everywhere although it coming from a major library is a bit sad.

This may be because the underlying libraries are C which is a bit funky with error handling, there's at least a reason to sometimes squash errors and results together (IE, optimisation). I suspect the exception is being used because under the hood error codes are also used and it's trying to use throwing an exception to give the different codes but doesn't exist and bad permissions might not be an error condition or one requiring an exception.

Yet this is still the bane of my existence. Bad error handling everywhere including the other way around (things that should always be errors being warnings), in legacy code it's horrendous.

Been making minor refactors to code base. Ran into something that resembles and behaves like a brainfart. Accepts arguments, uses them to query DB then completely disregards result and builds own result yielding dubious output.
Dumb as I am, went to investigate the story behind it. Maybe some weird business rules involved.
Git gave commit. 100+ files changed. Nice one.
Went to original story and there it was, clearly stated, like a true moronic decision: "Squash all feature commits to a single commit". No specs, no description, no explanation... Nothing.
Well... FUCK YOU TO!

Question about git. I worked on dev branch and made 10 commits.

Then I squash merged 10 commits from develop to master and made a release build.

Now problem is if I make a pull request from develop to master bitbucket will still show that master is behind (because develop has fixes in 10 commits while master has all of them squashed in 1 commit).

Now my question is whats the best way to make sure master and develop are synced (basically that master would have everything what develop has) ?

should I just merge master into develop back after the release?