"You gave us bad code! We ran it and now production is DOWN! Join this bridgeline now and help us fix this!"

So, as the author of the code in question, I join the bridge... And what happens next, I will simply never forget.

First, a little backstory... Another team within our company needed some vendor client software installed and maintained across the enterprise. Multiple OSes (Linux, AIX, Solaris, HPUX, etc.), so packaging and consistent update methods were a a challenge. I wrote an entire set of utilities to install, update and generally maintain the software; intending all the time that this other team would eventually own the process and code. With this in mind, I wrote extensive documentation, and conducted a formal turnover / training season with the other team.

So, fast forward to when the other team now owns my code, has been trained on how to use it, including (perhaps most importantly) how to send out updates when the vendor released upgrades to the agent software.

Now, this other team had the responsibility of releasing their first update since I gave them the process. Very simple upgrade process, already fully automated. What could have gone so horribly wrong? Did something the vendor supplied break their client?

I asked for the log files from the upgrade process. They sent them, and they looked... wrong. Very, very wrong.

Did you run the code I gave you to do this update?

"Yes, your code is broken - fix it! Production is down! Rabble, rabble, rabble!"

So, I go into our code management tool and review the _actual_ script they ran. Sure enough, it is my code... But something is very wrong.

More than 2/3rds of my code... has been commented out. The code is "there"... but has been commented out so it is not being executed. WT-actual-F?!

I question this on the bridge line. Silence. I insist someone explain what is going on. Is this a joke? Is this some kind of work version of candid camera?
Finally someone breaks the silence and explains.

And this, my friends, is the part I will never forget.

"We wanted to look through your code before we ran the update. When we looked at it, there was some stuff we didn't understand, so we commented that stuff out."

You... you didn't... understand... my some of the code... so you... you didn't ask me about it... you didn't try to actually figure out what it did... you... commented it OUT?!

"Right, we figured it was better to only run the parts we understood... But now we ran it and everything is broken and you need to fix your code."

I cannot repeat the things I said next, even here on devRant. Let's just say that call did not go well.

So, lesson learned? If you don't know what some code does? Just comment that shit out. Then blame the original author when it doesn't work.

You just cannot make this kind of stuff up.

You know what?

Young cocky React devs can suck my old fuckin LAMP and Objective-C balls.

Got a new freelance job and got brought in to triage a React Native iOS/Android app. Lead dev's first comment to me is: "Bro, have you ever used React Native".

To which I had to reply to save my honor publicly, "No, but I have like 8 years with Objective-C and 3 years with Swift, and 3 years with Node, so I maybe I'll still be able help. Sometimes it just helps to have a fresh set of eyes."

"Well, nobody but me can work on this code."

And that, as it turned out was almost true.

After going back and forth with our PM and this dev I finally get his code base.

"Just run "npm install" he says".

Like no fuckin shit junior... lets see if that will actually work.

Node 14... nope whole project dies.

Node 12 LTS... nope whole project dies.

Install all of react native globally because fuck it, try again... still dies.

Node 10 LTS... project installs but still won't run or build complaining about some conflict with React Native libraries and Cocoa pods.

Go back to my PM... "Um, this project won't work on any version of Node newer than about 5 years old... and even if it did it still won't build, and even if it would build it still runs like shit. And even if we fix all of that Apple might still tell us to fuck off because it's React Native.

Spend like a week in npm and node hell just trying to fucking hand install enough dependencies to unfuck this turds project.

All the while the original dev is still trying TO FIX HIS OWN FUCKING CODE while also being a cocky ass the entire time. Now, I can appreciate a cocky dev... I was horrendously cocky in my younger days and have only gotten marginally better with age. But if you're gonna be cocky, you also have to be good at it. And this guy was not.

Lo, we're not done. OG Dev comes down with "Corona Virus"... I put this in quotes because the dude ends up drawing out his "virus" for over 4 months before finally putting us in touch with "another dev team he sometimes uses".

Next, me and my PM get on a MS Teams call with this Indian house. No problems there, I've worked with the Indians before... but... these are guys are not good. They're talking about how they've already built the iOS build... but then I ask them what they did to sort out the ReactNative/Cocoa Pods conflict and they have no idea what I'm talking about.

Why?

Well, one of these suckers sends a link to some repo and I find out why. When he sends the link it exposes his email...

This Indian dude's emails was our-devs-name@gmail.com...

We'd been played.

Company sued the shit out of the OG dev and the Indian company he was selling off his work to.

I rewrote the app in Swift.

So, lets review... the React dev fucked up his own project so bad even he couldn't fix it... had to get a team of Indians to help who also couldn't fix it... was still a dickhead to me when I couldn't fix it... and in the end it was all so broken we had to just do a rewrite.

None of you get npm. None of you get React. None of you get that doing the web the way Mark Zucherberg does it just makes you a choad locked into that ecosystem. None of you can fix your own damn projects when one of the 6,000 dependency developers pushes breaking changes. None of you ever even bother with "npm audit fix" because if security was a concern you'd be using a server side language for fucking server side programming like a grown up.

So, next time a senior dev with 20 years exp. gets brought in to help triage a project that you yourself fucked up... Remember that the new thing you know and think makes you cool? It's not new and it's not cool. It's just JavaScript on the server so you script kiddies never have to learn anything but JavaScript... which makes you inarguably worse programmers.

And, MF, I was literally writing javascript while you were sucking your mommas titties so just chill... this shit ain't new and I've got a dozen of my own Node daemons running right now... difference is?

Mine are still working.

couse, why suffer alone..

Here's my piece of advice for new devs out there:

1 - Pick one language to learn first and stick with it, untill you grasp some solid fundamentals. (Variables, functions, classes, namespaces, scope, at least)

2 - Pick an IDE, and stick with it for now. Don't worry about tools yet. Comment everything you're coding. The important thing is to comment why you wrote it, and not what it does. Research git and start using version control, even when coding by yourself alone.

3 - Practice, pratice and pratice. If you got stuck, try reading the language docs first and see if you can figure it out yourself. If all else fails, then go to google and stackoverflow. Avoid copying the solution, type it all and try to understand it.

4 - After you feel you need to go to the next level, research best practices first, and start to apply them to your code. Try to make it modular as it grows. Then learn about tools, preprocessors and frameworks.

5 - Always keep studying. Never give up. We all feel that we have no idea of what we are doing sometimes. That's normal. You will understand eventually. ALWAYS KEEP STUDYING.

Looks like I'm getting fired on Wednesday :)

Long story:

*I add first unit tests to project.

*Boss adds new functionality and breaks all the tests so I can't compile and write more for what I'm working on.

*Boss is very fragile and cannot handle any comment that can possibly be taken as a slight against him.

Me: "I wanted to ask what our policy on unit tests is please? Because we haven't really said how we are treating unit tests, and everyone myself included is not thinking about them. I also haven't added tests when I fixed bugs and this time your changes broke the tests"

Boss 10 minutes later: "I want to speak to you in private".

Boss: "you are too forceful and direct. You said I should have added tests."

Me: "yeah but I didn't mean in a nasty way"

Boss getting louder and more aggressive: "You are too forceful"

Me: "I didn't mean it in a bad way"

Boss: "I didn't want to add tests for that!"

Me: "then why add any tests?"

Boss: "Fine we are not having this conversation now!"

*Boss storms out

I decided I can't speak to the guy about anything without upsetting him spoke to the manager before I quit because I can't work like this.

That resulted in a meeting with my boss, his boss and the head of HR where I ended up savaging him and told them I can't bring up anything as I can never tell if it will offend him and that I spend ages writing emails and trying to document communications because I just can never tell if I will upset him. Also that I cannot bring up any ideas because I can't tell if he will somehow get offended and that I can't even write code because if I change something he wrote at some point he will get angry.

My boss claims that I am extremely forceful and disrespectful and that I am constantly insulting him and his decisions.

We go back over a ton of shit and I refute everything he says. In the end I have to have a meeting with him on Wednesday where we either get things straight, he fires me or I quit.

I think at this point that our relationship is too fucked for him to be my team lead on a 6 man team.

Side note I keep bringing forth ideas because we have one database shared between 6 Devs, no pull requests (apart from mine and another new guy), no test driven development, no backlog, no team driven story pointing, no running tests before merging, no continuous integration setup, no integration tests, no build step on merge, no idea of if we are on track to our deadline other than his gut feeling, no actual unit tests backend - just integration with a test db, no enthusiasm to learn in the team and no hope.

Manager: Hey how come you left so many comments on my PR?

Dev: Well you’ve just recently learned how to code so there’s going to be a lot of things to learn beyond what you’ve picked up in your online coding tutorials. Don’t worry it’s only minor things like you put everything all in one function, left outdated comments in the code, have if statements 4 levels deep, have a console.log after every line of code some of which log .env variables, skipped error handling, cast to “any” a bunch instead of using more specific types, didn’t write any tests and some unrelated tests are now failing due to a circular dependancy.

Manager: THAT IS SO DISRESPECTFUL!!APPROVE MY PR IMMEDIATELY. IT WASN’T EVEN EASY FOR ME TO CREATE THE PR, NOW I HAVE TO MAKE AN UPDATE!? YOU’RE THE DEV, YOU SHOULD FIX IT NOT ME!! NEVER COMMENT ON ANY OF MY PRS AGAIN.

WASM was a mistake. I just wanted to learn C++ and have fast code on the web. Everyone praised it. No one mentioned that it would double or quadruple my development time. That it would cause me to curse repeatedly at the screen until I wanted to harm myself.

The problem was never C++, which was a respectable if long-winded language. No no no. The problem was the lack of support for 'objects' or 'arrays' as parameters or return types. Anything of any complexity lives on one giant Float32Array which must surely bring a look of disgust from every programmer on this muddy rock. That is, one single array variable that you re-use for EVERYTHING.

Have a color? Throw it on the array. 10 floats in an object? Push it on the array - and split off the two bools via dependency injection (why do I have 3-4 line function parameter lists?!). Have an image with 1,000,000 floats? Drop it in the array. Want to return an array? Provide a malloc ptr into the code and write to it, then read from that location in JS after running the function, modifying the array as a side effect.

My- hahaha, my web worker has two images it's working with, calculations for all the planets, sun and moon in the solar system, and bunch of other calculations I wanted offloaded from the main thread... they all live in ONE GIANT ARRAY. LMFAO.If I want to find an element? I have to know exactly where to look or else, good luck finding it among the millions of numbers on that thing.

And of course, if you work with these, you put them in loops. Then you can have the joys of off-by-one errors that not only result in bad results in the returned array, but inexplicable errors in which code you haven't even touched suddenly has bad values. I've had entire functions suddenly explode with random errors because I accidentally overwrote the wrong section of that float array. Not like, the variable the function was using was wrong. No. WASM acted like the function didn't even exist and it didn't know why. Because, somehow, the function ALSO lived on that Float32Array.

And because you're using WASM to be fast, you're typically trying to overwrite things that do O(N) operations or more. NO ONE is going to use this return a + b. One off functions just aren't worth programming in WASM. Worst of all, debugging this is often a matter of writing print and console.log statements everywhere, to try and 'eat' the whole array at once to find out what portion got corrupted or is broke. Or comment out your code line by line to see what in forsaken 9 circles of coding hell caused your problem. It's like debugging blind in a strange and overgrown forest of code that you don't even recognize because most of it is there to satisfy the needs of WASM.

And because it takes so long to debug, it takes a massively long time to create things, and by the time you're done, the dependent package you're building for has 'moved on' and find you suddenly need to update a bunch of crap when you're not even finished. All of this, purely because of a horribly designed technology.

And do they have sympathy for you for forcing you to update all this stuff? No. They don't owe you sympathy, and god forbid they give you any. You are a developer and so it is your duty to suffer - for some kind of karma.

I wanted to love WASM, but screw that thing, it's horrible errors and most of all, the WASM heap32.

What if I told you..

..the //TODO comment you just added to your code will never get done?

I applied for PHP Developer

Interviewer: What is interface?
Me: it is class with unimplemented methods?
Interviewer: But why we use it?
Me: it acts as a contract so you can assure that
on implementing interface developer will follow
the same architecture.
Interviewer: that's okay but why is the need for an interface at first place?

I was irritated with the interview process as he was smirking
every time I answered.

Me: I never get a chance to do that kind of research. Truth is
even if you hire me your manager will declare the unrealistic deadline and won't care if I comment the code or know why we really need to implement an interface.

After he did not smile and I left the chair.

The moment when you can look back at all the comments you wrote to yourself well over a year ago that go along the lines of:

"Don't delete this!"

"I know this looks weird, but trust me!"

"You coded this drunk, you couldn't remember how, and you wrote this comment to remind you that you couldn't understand it sober."

Can all be brushed away, along with the kinda hairy code when you realise that in your attempt to ensure you didn't break code that worked and wasted time trying to understand that you didn't have the experience to solve it, you now have the experience to solve it.

I guess I had such huberis that I assumed I'd never understand a certain problem...

Code review time:

Hey Rudy, can you approve my PR? ??? Shouldn't it be can you review my PR?(thought to myself)
Anyway, as a new practice, we(royal we) do not approve PRs with js files. If we touch one, we convert it to typescript as part of a ramp up to a migration that never seems to get here. But I digress.
I look at the laziest conversion in history.

Looked like
Import 'something';
Import 'somethingElse';
Import 'anotherSomething';

export class SomeClass {
public prop1: any;
public prop2: any;
public prop3: any;

public doWork(param: any){
let someValue = param;
// you get the idea
return someValue;
}
}

Anyway, I question if all the properties need to be visible outside of the class since everything was public.
Then if the dev could go and use type safety.
Then asked why not define the return type for the method since it would make it easier for others to consume.
Since parts of the app are still in js, I asked that they check that that the value passed in was valid(no compilation error, obviously).
Also to use = () => {} to make sure "this" is really this.
I also pointed out the import problem, but anyway.

I then see the his team leader approve the PR and then tell me that I'm being too hard on his devs. ????

Do we need to finish every PR comment with "pretty please" now?
These are grown men and women, and yet, it feels oddly like kindergarten.

I've written code in the past that wasn't pretty and I received "WTF?" as a PR comment. I then realized I ate sh*t on that line of code, corrected it and pushed the code. Then we went to Starbucks.
I'm not that old(35), but these young devs need to learn that COMPILERS DO NOT CARE ABOUT YOUR FEELINGS!!!!!
Ahhhhhh
Much better.
Thanks for the platform.

I'm coming off a lengthy staff augmentation assignment awful enough that I feel like I need to be rehabilitated to convince myself that I even want to be a software developer.

They needed someone who does .NET. It turns out what they meant was someone to copy and paste massive amounts of code that their EA calls a "framework." Just copy and paste this entire repo, make a whole ton of tweaks that for whatever reason never make their way back into the "template," and then make a few edits for some specific functionality. And then repeat. And repeat. Over a dozen times.

The code is unbelievable. Everything is stacked into giant classes that inherit from each other. There's no dependency inversion. The classes have default constructors with a comment "for unit testing" and then the "real" code uses a different one.

It's full of projects, classes, and methods with weird names that don't do anything. The class and method names sound like they mean something but don't. So after a dozen times I tried to refactor, and the EA threw a hissy fit. Deleting dead code, reducing three levels of inheritance to a simple class, and renaming stuff to indicate what it does are all violations of "standards." I had to go back to the template and start over.

This guy actually recorded a video of himself giving developers instructions on how to copy and paste his awful code.

Then he randomly invents new "standards." A class that reads messages from a queue and processes them shouldn't process them anymore. It should read them and put them in another queue, and then we add more complication by reading from that queue. The reason? We might want to use the original queue for something else one day. I'm pretty sure rewriting working code to meet requirements no one has is as close as you can get to the opposite of Agile.

I fixed some major bugs during my refactor, and missed one the second time after I started over. So stuff actually broke in production because I took points off the board and "fixed" what worked to add back in dead code, variables that aren't used, etc.

In the process, I asked the EA how he wanted me to do this stuff, because I know that he makes up "standards" on the fly and whatever I do may or may not be what he was imagining. We had a tight deadline and I didn't really have time to guess, read his mind, get it wrong, and start over. So we scheduled an hour for him to show me what he wanted.

He said it would take fifteen minutes. He used the first fifteen insisting that he would not explain what he wanted, and besides he didn't remember how all of the code he wrote worked anyway so I would just have to spend more time studying his masterpiece and stepping through it in the debugger.

Being accountable to my team, I insisted that we needed to spend the scheduled hour on him actually explaining what he wanted. He started yelling and hung up. I had to explain to management that I could figure out how to make his "framework" work, but it would take longer and there was no guarantee that when it was done it would magically converge on whatever he was imagining. We totally blew that deadline.

When the .NET work was done, I got sucked into another part of the same project where they were writing massive 500 line SQL stored procedures that no one could understand. They would write a dozen before sending any to QA, then find out that there was a scenario or two not accounted for, and rewrite them all. And repeat. And repeat. Eventually it consisted of, one again, copying and pasting existing procedures into new ones.

At one point one dev asked me to help him test his procedure. I said sure, tell me the scenarios for which I needed to test. He didn't know. My question was the equivalent of asking, "Tell me what you think your code does," and he couldn't answer it. If the guy who wrote it doesn't know what it does right after he wrote it and you certainly can't tell by reading it, and there's dozens of these procedures, all the same but slightly different, how is anyone ever going to read them in a month or a year? What happens when someone needs to change them? What happens when someone finds another defect, and there are going to be a ton of them?

It's a nightmare. Why interview me with all sorts of questions about my dev skills if the plan is to have me copy and paste stuff and carefully avoid applying anything that I know?

The people are all nice except for their evil XEB (Xenophobe Expert Beginner) EA who has no business writing a line of code, ever, and certainly shouldn't be reviewing it.

I've tried to keep my sanity by answering stackoverflow questions once in a while and sometimes turning evil things I was forced to do into constructive blog posts to which I cannot link to preserve my anonymity. I feel like I've taken a six-month detour from software development to shovel crap. Never again. Lesson learned. Next time they're not interviewing me. I'm interviewing them. I'm a professional.

I have discovered a fresh hell

Some guy I’ve never met or heard of in the office lobbed a comment at one of my *approved and merged* pull requests. He doesn’t say anything specific, only that my REST urls are not in line with naming convention. That’s all he says, and I’ve already walked the URL consumers through the code and given them the URLS.

I’m really annoyed that this guy won’t just say what he has in mind, but fine whatever this is a professional environment and developers are not known for being a diplomatic people. Let it go and get your work done!

I do some googling and find an obvious change that needs to happen- I implement it, open a new pull request and inform my URL consumers of the change.

This rando still isn’t satisfied and still won’t say what needs to change. I am on round 3 of this wonderful cycle and this guy is acting all fuckin HAUGHTY about it. “Here is a list of conventions I found googling, you should read them even if it takes 4 hours because it will benefit your career”

Sure dog you’re probably right on that one but we are in a professional environment and at this point you are holding up production so you can wave your dick around! Just SAY WHAT YOU MEAN SO WE CAN MAKE THE CHANGES AND GET OUR WORK DONE

TL;DR Pluralsight should be ashamed for taking 299 USD a year and writing some very low-quality quizzes.

I've always heard that Pluralsight is a great platform having some high quality courses, so I chose it as a benefit, as our company was giving us some budget for learning purposes. I've paid (or rather the company did it in the end) 299 USD for this year, which, I guess is not much for US standards, but it is a lot for Eastern European standards.

I didn't actually get to the point of watching any of the courses, but I started to use a feature called "Stack up", which is a long series of questions in a specific theme, like Java, Kotlin, C++, etc., accessible once a day. I must say, I'm amazed by the fact, that people pay quite a great amount of money and they get something so poorly made with a lot of errors and stupid questions.

Take the question from the included image for example. Not only that the 2 possible answers are repeated (and thus I failed to select the correct one from 2 equal answers), but the supposedly correct answer is also missing some type specifications. No Java compiler will compile it this way as far as I know. There would be at least 3 ways to fix it.

Then there is today's gem (should be included as first comment) as well, where the answer is wrong in both Chrome 96, Firefox 95 and Node v10. Heck, THIS IS one of the reasons why you should never use `var` in your JavaScript code, but always `let` and `const`!

So the courses on Pluralsight might be good, but I would be ashamed, if I were to release something like this. People might actually try to solidify their knowledge by solving these quizzes but instead of learning something useful, they will be left with some bullshit. I just don't get how could they release a feature with so much incorrect information and I am kind of disappointed, even if I didn't try the courses yet.

Oh gee whiz fellas. I lived through my nightmare. Recently too.

(Multiple rants over last few months are merged in this one. Couldn't rant earlier because my login didn't work.)

I joined a new shithole recently.
It was a huge change because my whole tech stack changed, and on top of that the application domain was new too.

Boss: ho hey newbie, here take this task which is a core service redesign and implementation and finish it in two weeks because it has to be in production for a client.

Normally I'd be able to provide a reasonable analysis and estimate. But being new and unaware of how things work here, I just said 'cool, I'll try my best.' (I was aware that it was a big undertaking but didn't realize the scope and the alarming lack of support I'd get and the bullshit egos I'd have to deal with)
Like a mad man I worked 17+ hours a day with barely a day off every week and changed and produced a lot of code, most of it of decent quality.

Deadline came and went by. Got extended because it was impossible (and fake).

All the time my manager is continuously building pressure on me. When I asked questions I never got any direct/clear answers. On asking for help, I'd get an elaborate word vomit of what was already known/visible. Yet I finally managed to have an implementation ready.

Reviewer: You haven't added parameter comments on your functions and there aren't enough comments in code. We follow standards. Clean code and whatnot. Care for the craft verbal diarrhea.

Boss: Ho hey anux, do you think we'll be able to push the code to production?

Me: Nope. We care for the craft and have standards. We need to add redundant comments to self documented code first, because that is of utmost importance as Nuthead reviewer explained.
(what I wish I had said)

What I actually said: No, code is not reviewed yet.

And despite examples of functions which were not documented (which were written by the reviewer nut), I added 6-7 lines of comments for my single line functions describing how e.g. Sum takes two input integers and returns their sum and asked for a review again.

Reviewer: See this comment is better written as this same-meaning-but-slightly-longer way. Can we please add full stops everywhere even though they were not there to begin with? Can we please not follow this pattern and instead promote our anti-pattern? Thanks.

Me: Changed the comments. Added full stops. Here's a link for why this anti-pattern is bad.

Reviewer: you have written such beautiful code with such little gems. Brilliant. It's great to see how my mentoring has honed your skills.
.
.
.
I swear I would have broken a CRT on his stupid face if we weren't working remotely (and if I had a CRT).

It infuriates me how the solution to every problem with this guy is 'add a comment'.

What enrages me more is that I actually thought I could learn from this guy (in the beginning). My self doubt just made me burnout for little in return.

Thankfully this living nightmare will soon be over.

Github 101 (many of these things pertain to other places, but Github is what I'll focus on)

- Even the best still get their shit closed - PRs, issues, whatever. It's a part of the process; learn from it and move on.

- Not every maintainer is nice. Not every maintainer wants X feature. Not every maintainer will give you the time of day. You will never change this, so don't take it personally.

- Asking questions is okay. The trackers aren't just for bug reports/feature requests/PRs. Some maintainers will point you toward StackOverflow but that's usually code for "I don't have time to help you", not "you did something wrong".

- If you open an issue (or ask a question) and it receives a response and then it's closed, don't be upset - that's just how that works. An open issue means something actionable can still happen. If your question has been answered or issue has been resolved, the issue being closed helps maintainers keep things un-cluttered. It's not a middle finger to the face.

- Further, on especially noisy or popular repositories, locking the issue might happen when it's closed. Again, while it might feel like it, it's not a middle finger. It just prevents certain types of wrongdoing from the less... courteous or common-sense-having users.

- Never assume anything about who you're talking to, ever. Even recently, I made this mistake when correcting someone about calling what I thought was "powerpc" just "power". I told them "hey, it's called powerpc by the way" and they (kindly) let me know it's "power" and why, and also that they're on the Power team. Needless to say, they had the authority in that situation. Some people aren't as nice, but the best way to avoid heated discussion is....

- ... don't assume malice. Often I've come across what I perceived to be a rude or pushy comment. Sometimes, it feels as though the person is demanding something. As a native English speaker, I naturally tried to read between the lines as English speakers love to tuck away hidden meanings and emotions into finely crafted sentences. However, in many cases, it turns out that the other person didn't speak English well enough at all and that the easiest and most accurate way for them to convey something was bluntly and directly in English (since, of course, that's the easiest way). Cultures differ, priorities differ, patience tolerances differ. We're all people after all - so don't assume someone is being mean or is trying to start a fight. Insinuating such might actually make things worse.

- Please, PLEASE, search issues first before you open a new one. Explaining why one of my packages will not be re-written as an ESM module is almost muscle memory at this point.

- If you put in the effort, so will I (as a maintainer). Oftentimes, when you're opening an issue on a repository, the owner hasn't looked at the code in a while. If you give them a lot of hints as to how to solve a problem or answer your question, you're going to make them super, duper happy. Provide stack traces, reproduction cases, links to the source code - even open a PR if you can. I can respond to issues and approve PRs from anywhere, but can't always investigate an issue on a computer as readily. This is especially true when filing bugs - if you don't help me solve it, it simply won't be solved.

- [warning: controversial] Emojis dillute your content. It's not often I see it, but sometimes I see someone use emojis every few words to "accent" the word before it. It's annoying, counterproductive, and makes you look like an idiot. It also makes me want to help you way less.

- Github's code search is awful. If you're really looking for something, clone (--depth=1) the repository into /tmp or something and [rip]grep it yourself. Believe me, it will save you time looking for things that clearly exist but don't show up in the search results (or is buried behind an ocean of test files).

- Thanking a maintainer goes a very long way in making connections, especially when you're interacting somewhat heavily with a repository. It almost never happens and having talked with several very famous OSSers about this in the past it really makes our week when it happens. If you ever feel as though you're being noisy or anxious about interacting with a repository, remember that ending your comment with a quick "btw thanks for a cool repo, it's really helpful" always sets things off on a Good Note.

- If you open an issue or a PR, don't close it if it doesn't receive attention. It's really annoying, causes ambiguity in licensing, and doesn't solve anything. It also makes you look overdramatic. OSS is by and large supported by peoples' free time. Life gets in the way a LOT, especially right now, so it's not unusual for an issue (or even a PR) to go untouched for a few weeks, months, or (in some cases) a year or so. If it's urgent, fork :)

I'll leave it at that. I hear about a lot of people too anxious to contribute or interact on Github, but it really isn't so bad!

A bug is born
... and it's sneaky and slimy. Mr. Senior-been-doing-it-for-ears commits some half-assed shitty code, blames failed tests on availability of CI licenses. I decided to check what's causing this shit nevertheless, turns out he forgot to flag parts of the code consistently using his new compiler defines, and some parts would get compiled while others needed wouldn't .. Not a big deal, we all make mistakes, but he rushes to Teams chat directing a message to me (after some earlier non-sensible argument about merits of cherry picking vs re-base):
Now all tests pass, except ones that need CI license. The PR is done, you can use your preferred way to take my changes.

So after I spot those missing checks causing the tests to fail, as well as another bug in yet another test case, and yet another disastrous memory related bug, which weren't detected by the tests of course .. I ponder my options .. especially based on our history .. if I say anything he will get offended, or at best the PR will get delayed while he is in denial arguing back even longer and dependent tasks will get delayed and the rest of the team will be forced to watch this show in agony, he also just created a bottleneck putting so many things at stake in one PR ..

I am in a pickle here .. should I just put review comments and risk opening a can of worms, or should I just mention the very obvious bugs, or even should I do nothing .. I end up reaching for the PM and explained the situation. In complete denial, he still believes it's a license problem and goes on ranting about how another project suffering the same fate .. bla bla bla chipset ... bla bla bla project .. bla bla bla back in whatever team .. then only when I started telling him:
These issues are even spotted by "Bob" earlier, since for some reason you just dismissed whatever I just said ..
("Bob" is another more sane senior developer in the team, and speaks the same language as the PM)
Only now I get his attention! He then starts going through the issues with me (for some reason he thinks he is technical enough to get them) .. He now to some extent believes the first few obvious bugs .. now the more disastrous bug he is having really hard time wrapping his head around it .. Then the desperate I became, I suggest let's just get this PR merged for the sake of the other tasks after may be fixing the obvious issues and meanwhile we create another task to fix the bug later .. here he chips in:
You know what, that memory bug seems like a corner case, if it won't cause issues down the road after merging let's see if we need even to open an internal fix or defect for it later. Only customers can report bugs.

I am in awe how low the bar can get, I try again and suggest let's at least leave a comment for the next poor soul running into that bug so they won't be banging their heads in the wall 2hrs straight trying to figure out why store X isn't there unless you call something last or never call it or shit like that (the sneaky slimy nature of that memory bug) .. He even dismissed that and rather went on saying (almost literally again): It is just that Mr. Senior had to rush things and communication can be problematic sometimes .. (bla bla bla) back in "Sunken Ship Co." days, we had a team from open source community .. then he makes a very weird statement:
Stuff like what Richard Stallman writes in Linux kernel code reviews can offend people ..

Feeling too grossed and having weird taste in my mouth I only get in a bad hangover day, all sorts of swear words and profanity running in my head like a wild hungry squirrel on hot asphalt chasing a leaky chestnut transport ... I tell him whatever floats your boat but I just feel really sorry for whoever might have to deal with this bug in the future ..

I just witnessed the team giving birth to a sneaky slimy bug .. heard it screaming and saw it kicking .. and I might live enough to see it a grown up having a feast with other bug buddies in this stinky swamp of Uruk-hai piss and Orcs feces.

Storytime!

(I just posted this in a shorter form as a comment but wanted to write it as a post too)

TL;DR, smarts are important, but so is how you work.

My first 'real' job was a lucky break in the .com era working tech support. This was pretty high end / professional / well respected and really well paid work.

I've never been a super fast learner, I was HORRIBLE in school. I was not a good student until I was ~40 (and then I loved it, but no longer have the time :( )

At work I really felt like so many folks around me did a better job / knew more than me. And straight up I know that was true. I was competent, but I was not the best by far.

However .... when things got ugly, I got assigned to the big cases. Particularly when I transferred to a group that dealt with some fancy smancy networking equipment.

The reason I was assigned? Engineering (another department) asked I be assigned. Even when it would take me a while to pickup the case and catch up on what was going on, they wanted the super smart tech support guys off the case, and me on it.

At first this was a bit perplexing as this engineering team were some ultra smart guys, custom chip designers, great education, and guys you could almost see were running a mental simulation of the chip as you described what you observed on the network...

What was also amusing was how ego-less these guys seemed to be (I don't pretend to know if they really were). I knew for a fact that recruiting teams tried to recruit some of these guys for years from other companies before they'd jump ship from one company to the next ... and yet when I met them in person it was like some random meeting on the street (there's a whole other story there that I wish I understood more about Indian Americans (many of them) and American engineers treat status / behave).

I eventually figured out that the reason I was assigned / requested was simple:

1. Support management couldn't refuse, in fact several valley managers very much didn't like me / did not want to give me those cases .... but nobody could refuse the almighty ASIC engineers. No joke, ASIC engineers requests were all but handed down on stone tablets and smote any idols you might have.

2. The engineers trusted me. It was that simple.

They liked to read my notes before going into a meeting / high pressure conference call. I could tell from talking to them on the phone (I was remote) if their mental model was seizing up, or if they just wanted more data, and we could have quick and effective conversations before meetings ;)

I always qualified my answers. If I didn't know I said so (this was HUGE) and I would go find out. In fact my notes often included a list of unknowns (I knew they'd ask), and a list of questions I had sent to / pending for the customer.

The super smart tech support guys, they had egos, didn't want to say they didn't know, and they'd send eng down the rabbit hole. Truth be told most of what the smarter than me tech support guy's knew was memorization. I don't want to sound like I'm knocking that because for the most part memorization would quickly solve a good chunk of tech support calls for sure... no question those guys solved problems. I wish I was able to memorize like those guys.

But memorization did NOT help anyone solve off the wall bugs, sort of emergent behavior, recognize patterns (network traffic and bugs all have patterns / smells). Memorization also wouldn't lead you to the right path to finding ANYTHING new / new methods to find things that you don't anticipate.

In fact relying on memorization like some support folks did meant that they often assumed that if bit 1 was on... they couldn't imagine what would happen if that didn't work, even if they saw a problem where ... bro obviously bit 1 is on but that thing ain't happening, that means A, B, C.

Being careful, asking questions, making lists of what you know / don't know, iterating LOGICALLY (for the love of god change one thing at a time). That's how you solved big problems I found.

Sometimes your skills aren't super smarts, super flashy code, sometimes, knowing every method off the top of your head, sometimes you can excel just being more careful, thinking different.

Best advice so far: "KISS: Keep It Simple and Stupid"

That works every time because your design of the code will be understandable. Your code must seldom to be refactored. You aren't that asshole who never comment and document anything. And the most important part: The code works as designed without flaws!

Never comment, and you'll be rethinking your code every day like it was the first

Stop commenting out code blocks!

Either fix your shit or delete it.

I am open to argue what fixing may mean, as it is perfectly fine to make your broken code not reachable, e.g. via feature flags or skipping certain tests. Yet never ever should you comment those blocks!

So you say you want to keep it for historic reasons? You know, that is why we use version control! If you ever need certain functionality back, you can restore that state.

Each decent IDE also offers a local history where you can even restore code blocks that weren't even pushed or committed. So use that!

Commenting out test cases is a really bad habit, as you have no reminder that you shall restore it.

And no, a TODO and a FIXME won't count as a reminder as you have to actively look for them. And we all know how well that goes, don't we? (One time, I found a typo of a `TDO`. So even with a regular lookup for TODO, stuff will slip.)

Each test suite offers you ways to skip tests if there are valid reasons why they should not fail the build temporary and they offer colorful feedback. Yes, that means that your tests won't be green, but guess what: That's a feature! They shouldn't be.

That yellow is a fine reminder, aka warning!, that you should really fix your shit.

Commented code screams: "I DON'T KNOW WHAT I WAS DOING!" and it confuses the hell out of other developers ("Was this commented because of debugging purposes and should be active again or can I safely delete this!?") and adds verbose crap to the code base.

If you find yourself to be in a place that you comment code a lot, I also argue that your workflow is broken.

When you are using a decent debugger, there shouldn't that much of a need to comment in and out a lot of code in order to reason about your code-base.

Me: [jira comment] We have similar text for the mobile version of the site already. [includes screenshot of what site looks like now] Are you sure about this?

[radio silence for a few hours]

Me: [slack] I want to follow up.

Web Operations: What’s the issue?

Ooh k. Slack messages can have a tone.

Me: I just want to confirm we’re not repeating copy.

Web Ops: We’re not.

I complete the ticket and submit for review. The C-suite for my department reviews.

C-suite: [to web ops in JIRA comment] This looks weird. Is this right? [sends screenshot of my work because there is repeated copy, like I said there’d be]

Web Ops: [in JIRA comment] Oh, I thought X was questioning the request. X changed the wrong text.

C-suite: The website has always looked like that. You’re looking at X’s screenshot for the current website. Look at the screenshot I sent over.

Later, I complain because web ops was completely unprofessional with the comment about “questioning the request.”

C-suite: Web Ops is working hard. It’s our busy season and it’s their first time dealing with it. You know, I’m going to teach them some css and html so they can make content changes in the CMS and they’re not sending over changes so often and bothering you.

Me: [to myself] 🤨 wtf so it’s ok for web ops to treat me like dirt. And in writing. And with service that’s version controlled—JIRA emailed web ops comment to me. And lol no 😂 on teaching them how to code. That’s such bullshit. We all know you’d never allow them to edit the CMS because they’d fuck up the site. And they wouldn’t do edits anyway because it’s beneath them. And idk how this relates to web ops gross behavior.

A few days later.

Me: I was offered a job elsewhere. Here’s my two weeks notice.

C-suite: Can you push back your last day? It’s our busy season.

Me: Nope. Bye Felicia.

Write bad code, dont comment, do all these, if you want....
But never never never us

Windows as your server operating system

How can not one, not two, but many many things JUST be so wrong!? like..
Windows. (Yes. THE OS). Why? well... we begin with the garbage, right? the BLOAT.
cortana
mspaint
internet explorer <- wh..WHA?! wh?!?!
ms edge <- okay.. (I saying okay as in a figure of speech I would like to remove it honestly)

why can't I remove internet explorer, and they make another internet explorr called microsoft edge - you guessed it - I can't remove ms edge either.
What's next?! :D
bloat umbruella version -0.1? :D <- a new internet explorer. for 2042.

Cortana. <- some might say "that's not Sooo bad tho". It might not be, but if if it is for me - I would like to remove it.

Okay. okay. moving onto the software.
`V`-Yeah you guessed right. on the first letter.
VISUAL STUDIO.

my face: 😲
I compare visual studio to windows xp to internet explorer to windows overall. they share so much in common...

forced updates,
fixes,
BLOCKS you to compile programs because of NUMEROUS REASONS LIKE..
comment out "CRC303030 whatever" to ignore this message.
you need the build tools vx.x.x.y.x.y.x.t..z.z.z.(100 billion digits later)..x.x.Z OR alternatively you could re-target your solution by (...) (and now today I had enough, I dont see the retarget solution - And I am sure, WHEN I SEE IT - it will just be another problem..

... 💥

I am surprised how windows can run so fluently, with all this crap. Fluently as in actually being running. I am a fan of linux instead though but..
(question to me would probably be why you use windows not linux then?) sometimes I code on windows.. 🤦‍♀️

and it is a pain.

workloads,updates,options,BILLION OF OPTIONS, BILLION OF BUTTONS, stuff I never ever use, takes time to reinstall,install,remove, - windows also needs to restart after each simple thing.... (!?)

sorry. this was nice to write this rant. PHEW! thank GOSH this site exists! 😘 😍

I've lost count of the days at this point...

First things first, lets all praise musky for getting David Bowie stuck in my head for the next month or so, not a bad thing, his song choice was on point. Also the rants have become few and far between because apparently I have to be an "adult" and go to work, pay my bills, and other things that distract me from programming.

Okay, now to the actual dev stuff. I've started to think that maybe my scope of languages is limited somewhat to my comfort zone, which is only java at this point. So for my project (game development), I've decided to pick a language based on what will work best instead of what I'm comfortable with, my runners so far...

C++: The default go to for game development. I would chose this but if I did, my best C++ game would look like Frankenstein's monster and would be filled with terrible code. For that alone I have scratched C++ from my list, for lack of experience.

Java: My usual, my go to, my comfort zone. I don't want to be comfortable though, I want to learn things. That asides, java has tones of resources, frameworks, libraries, and tutorials available. In addition, it's also able to run on pretty much anything, huge ++. The cons are trying to find the best resources, frameworks, libraries, and tutorials to use for a particular situation and that can be hard and confusing. Java may still be my go to but I'll get to that with the next language.

C#: I have never touched C# in my life, and the only things I know about it are what I've heard or read. So far I've heard it is SIMILAR to java, based around C++, and has aged really well compared to other languages. I like that it is similar to java without it being the same language, it will force me to learn things over and you can never reinforce the basics enough. It also has the huge benefit of being Microsoft based while still running on iOS, linux, macOS, windows, and android. This gives me really easy access to implement a mobile version (in the future obviously), while being able to run well on windows, the default OS for most gamers.

Overall I will start writing in C# and see if I like it. If I don't it's no big deal, I still have a good option in java to fall back on. I'm open to hearing opinions on this topic, java vs. C# but please keep your bias nonexistent and you constructive conversation very high. If any actual game developers that have experience with both languages are out their, and reading this, please comment so I can pick your brain.

Some of you may ask about the android scholarship, I contacted google and told them android development wasn't for me so they sent someone a late invite and rescinded mine, hopefully someone else will put it to better use.

Holy god this is long. I'm sorry.

Oh boy this may be my best product review yet. I'm totally smitten with GitHub Copilot! I always put off trying it, but I finally gave it a try recently. Man, oh man, once I got a taste of it, there was no going back. This auto-suggest feature is pure sorcery! It throws out complete function suggestions while you type, and it's all based on the context of your code.

Let me tell you if you have never tried it, it's freaking awesome and super handy! I've been learning Python for less than a month, but thanks to the freaking Copilot, my Python skills have skyrocketed like for real. I know this because I tackled a Python project and nailed it. The client was stoked because it worked flawlessly, even though my Python skills are still a bit rough around the edges.

The coolst thing is hw clean my code looks, especially for a beginner. all I have to do to add a comment is type a double slash, and Copilot takes care of the rest. It suggests what should go on each line as I type, and it's scarily accurate.

You know what's wild? On the GitHub page, it claims that Copilot writes 50% of the code. But, dude, for me, it wrote way more than that!