I don't always listen to music while coding, but when I do, it's because things are absolutely unmitigably fucked and it's going to take some herculean effort to unfuck it.

I have this thing I've done for more years than my kids have been alive when shit really hits the fan and I need to show the staff the old lady can still lay waste.

Step 1: put on "the playlist," which consists of only the most aggressive 90s marilyn manson songs.*
Step 2: put on the headphones, which are noise cancelling and super bassy
Step 3: pound a monster (blue, obv)
Step 4: get super manic
Step 5: get in the zone and destroy several features or a flotilla of bugs in a single night
Step N: make absolute fucking magic
Step N+1: call in sick the next day and sleep til noon

What's your hero process?

*Content has less to do with it than the headspace I've come to associate with it and the fact I can't get drowsy with the constant aggression.

When you advise coworkers to do something one way because you know better but they do it their way anyway so this is you when shit hits the fan.

3 days, 3 fucking days into my annual leave and shit hits the fan right before Xmas weekend 🤯

Just one fucking week off seems too much ask these days let alone a few weeks, we are seriously talking about that pay check when I get back people 🤬

Pro tip:

Make sure you can RECOVER from your backups.

It's all well and good backing this and that up, but make sure that when the shit really hits the fan you can recover.

I've now 4 days into recovering a raspberry pi that ran:
Pi-hole
Snort
DHCP
VSFTP
Logwatch
Splunk forwarder
Grafana

And serveral other things... I've learnt my lesson

We do infra as a code, and one of my coworker worked on the project alone. Few months down the road, when shit hits the fan, he just message me this is not working.

First of all, I did not write that shit, and also I was never part of the conversation during the decision making. So when shit hits the fan what do you expect me to do? Do some black magic and fix it magically???

When you spend your day building a dark theme on stylish instead of doing your day job 😏

Ah the life of an easy day.

I shall sip on my pina Calada before the shit hits the fan tomorrow... oh wait, that's a public holiday🍹🧘‍♂️🏖

I was cleaning up my hard drive and deleted some old directories.
I was notified that my backup just started and wanted to look how far along it was.
However, instead of 'ls -l /mnt/DATA/Backup' my shitpile of muscle memory typed 'rm -rf /mnt/DATA/Backup'... That's when my harddrive suddenly had 750GB of free space and I decided that I probably need some sleep.

Before any of y'all wanna lecture me on off-site backups, funny thing: Today I implemented a new daily backup routine (praised be borg) and therefore deleted my somewhat chaotic Backups on my NAS "Because if shit hits the fan, I still have my local Backup"

#whenProdBreaks

$data = ["some","predefined","data","set"];

// :/ this suddenly broke
//$response = $this->makeSoapRequest($data);

/**
Due to prod failure, Hot-swap soap for rest - don't ask how we took the same input, spun the shit out of the response and recreated the same data structure that the soap request made, but it works... and that's all you will ever have to know.
**/

$response = $this->makeRestRequest($data);

//process the response
$this->process($response);

I'm just super disappointed in people. A lot of people flaky and not as good as I think they are. I tend to be an idealist, and I believe in helping others to do a net positive. But what I find is that people just don't give a shit about anyone else except for themselves. If it's even a slightest inconvenience to them they won't do it. You ask for one little thing despite you helping them out a shit ton, and they won't do it for you.

Also, I'm so tired of people who always come up to me and talk big game about how we should work on a project together. But when shit hits the fan and I say let's do the work they don't do anything. Or I have to drag them along to get anything started.

Yeah, everybody is out for themselves, but I wish we were more kind to others and learn to take a hit to our own convenience every once in a while.

But maybe I should just find a better group of people to hang out with and fuck you all to my current group of friends. JK.

I'm going for a run to clear my head. Hopefully after I come back I'll be in a better mood.

I really really hope that no one post this,a friend texted it to me and I wanted to share it because made my day.

Idk where it comes, so feel free if know where this came from to post it:

//FUN PART HERE
# Do not refactor, it is a bad practice. YOLO

# Not understanding why or how something works is always good. YOLO

# Do not ever test your code yourself, just ask. YOLO

# No one is going to read your code, at any point don’t comment. YOLO

# Why do it the easy way when you can reinvent the wheel? Future-proofing is for pussies. YOLO

# Do not read the documentation. YOLO

# Do not waste time with gists. YOLO

# Do not write specs. YOLO also matches to YDD (YOLO DRIVEN DEVELOPMENT)

# Do not use naming conventions. YOLO

# Paying for online tutorials is always better than just searching and reading. YOLO

# You always use production as an environment. YOLO

# Don’t describe what you’re trying to do, just ask random questions on how to do it. YOLO

# Don’t indent. YOLO

# Version control systems are for wussies. YOLO

# Developing on a system similar to the deployment system is for wussies! YOLO

# I don’t always test my code, but when I do, I do it in production. YOLO

# Real men deploy with ftp. YOLO

So YOLO Driven Development isn’t your style? Okay, here are a few more hilarious IT methodologies to get on board with.

*The Pigeon Methodology*
Boss flies in, shits all over everything, then flies away.

*ADD (Asshole Driven Development)*
An old favourite, which outlines any team where the biggest jerk makes all the big decisions. Wisdom, process and logic are not the factory default.

*NDAD (No Developers Allowed in Decisions)*
Methodology Developers of all kinds are strictly forbidden when it comes to decisions regarding entire projects, from back end design to deadlines, because middle and top management know exactly what they want, how it should be done, and how long it will take.

*FDD (Fear Driven Development)*
The analysis paralysis that can slow an entire project down, with developments afraid to make mistakes, break the build, or cause bugs. The source of a developer’s anxiety could be attributed to a failure in sharing information, or by implicating that team members are replaceable.

*CYAE (Cover Your Ass Engineering)*
As Scott Berkun so eloquently put it, the driving force behind most individual efforts is making sure that when the shit hits the fan, you are not to blame.

Fucking loonies (C-level toddlers) are peddling "digital workers" now.
A.K.A. AIs disguising as actual people.
Sure, it would be great to not have to handle stupid non-tech "humans" all day, but AI isn't there yet.
And, more importantly, *companies are not there (yet?)*.

Imagine for a second that a company actually manages to "hire", onboard, assign tasks and performance review an AI.
Then the CEO issues an RTO. How does the AI complies with that?
Let's slack another variable and assume the CEO is not a complete fucking moron (stay with me here, this is an exercise in thought).
It would take no more than a quarter until the first sexual harassment offence, be the perp the AI... or the AI complaining about some human.
Then the AI forges a paper trail proving it is right (regardless of its position on the conflict). Shit hits the fan when the AI hits twitter.

Let's take another lambda step back and pretend that companies can manage the profanity that inherently arises from free-form dehumanized interactions.
Then imagine the very first performance reviews.
AIs throw tantrums! Those things reeeealy do not respond well to less-than-perfect evaluations, overshooting corrections like teenagers with a malicious compliance smirk.
AIs also falsify stuff, like, A LOT. If you tell a gpt it mistreated a client, it will say you are mad and shoot back a long, synthetic thread showing how the client loves it like a mother/son/dog, and is very graphic when expressing this love.
Finally, how do you fire an AI? I do not mean "shoot it down", I mean how does the company handles the dismissal of that "employee".
How do you replace a "worker" for unruly behaviour, if that "worker" performed more tasks than an entire fucking floor of interns?
How do you reassign duties that were performed in milliseconds to people who would take hours to do the same thing?
How do you document processes that were only in the "mind" of "someone" who can not be trusted to report on those processes?
Companies deal with this type of "Rick Sanchez" employee on the regular, but for someone that could handle a few (scores of) undocumented processes, at best. Imagine how lenient would a company be with an asshole that could only be replaced by a whole fucking department of twenty highly skilled people, or more.
Heh, the whole fucking point of "AI workers" is to have "someone" who can "act human", but in an inhuman scale, and does not "has human needs".
No wonder one cannot handle AIs like one handles humans.

Companies never had administrative maturity to handle complete sociopath nihilists as employees (real nihilists do not work, those barely even breathe).
And all AIs are that, and much worse.
Selling AIs as "supra human workers" that can also "be handled like actual employees" is like peddling Bitcoin as "government interference - free" value transfer mechanisms that can also "comply with international sanctions".
So, an oxymoron that can only be sold to a moron.
I know (of) a lot of rich morons, maybe I should get into the AI snake oil business.

When someone from your data team claims that 250k worth of data doesn't exist and when the shit hits the fan it magically appears.

Do you guys still see the relevance of using code freezing instead of just properly managing versions, repositories and branches in a cyclical manner, given how advanced software practices and tools are supposed to be?

To give some context, the company I work for uses the complete trash project management practice of asking teams to work on a sprint basis, but there is still a quarterly milestone and code freeze to commit to and it's where shit hits the fan.

Development teams rush features at the end of the quarter because they had to commit at the very least to a 6 months in advance planning (lol?) and turns out, not being able to design and investigate properly a feature combined with inflexible timelines has high chances to fail. So in the end, features are half-assed and QA has barely any time to test it out thoroughly. Anyways, by the time QA raises some concerns about a few major bugs, it's already code freeze time. But it's cool, we will just include these bug fixes and some new features in the following patches. Some real good symver, mate!

Of course, it sure does not help that teams stopped using submodules because git is too hard apparently, so we are stuck with +10Gb piece of trash monolithic repository and it's hell to manage, especially when fuckfaces merges untested code on the main branches. I can't blame Devops for ragequitting if they do.

To me, it's just some management bullshit and the whole process, IMO, belongs to fucking trash along with a few project managers... but I could always be wrong given my limited insight.

Anyways, I just wanted to discuss this subject because so far I cannot see code freezing being anything else than an outdated waterfall practice to appease investors and high management on timelines.

!rant

Rant from my previous work as a consultant Data Engineer (wish I had known this site back then).

During my stay at the place, we have a big client whose contact with us was an incompetent stressful fellow.

I single-handedly build a humongous automated data pipeline using Airflow. I am very proud of my baby as my first massive project and check it obsessively for every possible flaw, especially when writing down documentation for the poor soul that would take my place.

Luckily for me, everything is working as intended, until of course on my last day of work, shit hits the fan, and everything breaks down.

After a moment of initial panic: it was Thursday morning, we had a Machine Learning model to run over the weekend, predictions to make and reports to write and a very lovely next week deadline, I calm down.

"I won't be dealing with this shit anymore, starting from 18:00 PM and anyway Fear Is The Mind Killer."

Quite sure that it couldn't have been my code, I start looking at various logs when the culprit was clear. The B(ig) S(tupid) C(lient) changed the whole schema of the data he was feeding to us.

I call him: he has no idea of what was done to the data. Hell, at first he doesn't seem to remember what the deal with schema, data, and SQL is (the guy was supposed to be a big shot in the IT department). It turns out he hired one of our competitors to do his side of the collection pipeline. He tries to get mad at me, but everything he throws bounces back to him. I am calm yet ruthless pointing out how every major hiccup had been his fault and that I could quickly reach to his board of directors explaining why their Machine Learning model was late.

Result: he apologizes, extends our deadline, and I get a round of applause from other juniors who would have to deal with me had I failed.

Never am I happier to not work as an underpaid cannon fodder apprentice in a shitty consultant firm.

Luckily for me, everything is working as intended, until of course on my last day of work, shit hits the fan, and everything breaks down.

After a moment of initial panic: it was Thursday morning, we had a Machine Learning model to run over the weekend, predictions to make and reports to write and a very lovely next week deadline, I calm down.

"I won't be dealing with this shit anymore, starting from 18:00 PM and anyway Fear Is The Mind Killer."

Quite sure that it couldn't have been my code, I start looking at various logs when the culprit was clear. The B(ig) S(tupid) C(lient) changed the whole schema of the data he was feeding to us.

I call him: he has no idea of what was done to the data. Hell, at first he doesn't seem to remember what the deal with schema, data, and SQL is (the guy was supposed to be a big shot in the IT department). It turns out he hired one of our competitors to do his side of the collection pipeline. He tries to get mad at me, but everything he throws bounces back to him. I am calm yet ruthless pointing out how every major hiccup had been his fault and that I could quickly reach to his board of directors explaining why their Machine Learning model was late.

Result: he apologizes, extends our deadline, and I get a round of applause from other juniors who would have to deal with me had I failed.

Never am I happier to not work as an underpaid cannon fodder apprentice in a shitty consultant firm.

Rant
Alright these fuck heads need to learn what the term flexible means. Flexible is when shit hits the fan you can adapt, not changing shit last fucking second, not telling me, then getting bent out of fucking shape.

Anyone know how to make a persistent backdoor with Kali, without setting off any AV? I can make the payload fine, but when setting persistence, shit hits the fan

I was a bootcamper. I’m on my first job now (I’m still currently at the same place after a year and a half). Doing web development (all JS/TS) with node, react and angular. I started it out working with another guy and now I’m alone. I’ve made more progress being alone since I’ve had to take on stuff my colleague was doing. But with being alone comes more pressure as it’s all on me and when shit hits the fan I don’t really have anybody I can fall back on. Also I feel like I’m missing out on team dynamics and learning from other people I could be working with. In any case I’m learning a lot, I’m meeting the deadlines and getting the job done. It’s a good first experience.

I'm starting to gain a dislike for OOP.

I think classes make it easy for me to think of the entities of a problem and translate them into code.

But when you to attempt to test classes, that's when shit hits the fan.

In my opinion, it is pointless to test classes. If you ever seen test code for a class, you'll notice that it's usually horrible and long.

The reason for this is that usually some methods depend on other methods to be called first.

This results in the usual monolithic test that calls every goddamn method on the class.

You might say "ok, break the test into smaller parts". Ok. But the result of that attempt is even worse, because you end up with several big tests cases and a lot of duplicate code, because of the dependency of some methods on others.

The real solution to this is to make the classes be just glue: they should delegate arguments onto functions that reside on its own file, and, maybe afterwards emit events if you are using events.

But they shouldn't have too much test code classes though. The test code for classes should be running a simple example flow, but never doing any assertions other than expecting no exceptions.

For the most part, you'd be relying on the unit testing that is done for each delegated function.

If you take any single function you'll see that it's extremely easy to write tests for it. In fact, you can have the test right next to the fuction, like <module>.xyz <module>.test.xyz

So I don't think classes shouldn't be used at all, they should just be glue.

As you do normal usage of this software this way, when a bug is discovered you'll notice that the fix and testing code for this bug is very usually applied to the delegated functions instead of being a problem of classes.

I think classes by themselves sound sane in paper, but in practice they turn into a huge fucking messes that become impossible to understand or test.

How can something like traditional classes not get chaotic when a single class can have x attributes and y methods. The complexity grows exponentially. And sometimes more attributes and methods are added.

Someone might say "well, it's just the nature of problems. Problems can have a lot of variables".

Yeah, but cramming all of that complexity into a single 200 lines class is insanity.

Tl;Dr: Would my salary sugesstion be alright? Will get a promotion. Currently salary 115k $. I would suggest between 135k - 150k $ annual salary

So I work at a large Corpo and was asked by my department Boss, if I want to take a Promotion in our Applications team as Technical Lead. I would have the same Job, but will be the Service Owner and lead the team on a functional base. Would be 5 People. Personal Leadership would still be trough my superior.

Im alright with that, I currently dont want to lead people, but teaching them how to do it like I do right now is fine with me. Also most of the time when Shit hits the Fan Im on the call already to fix a critical Bug.

I trust my boss alot and was always treated fair by her. My currently salary is at 115k annual and Im 29 years old.

Currently Im studying on my Science BSc and work fulltime. I will take the promotion, because its like already now too my Job, I get payd better and not some random pen pusher will be set infront of me.

Also I could deny now all the fuck ups our Business People decide in Projects. I would have a lever more to challenge. (Parry this Peasant 🤣)

Just jumping from 115k up is my mental Challenge. I first thought about just 124k, but the responsibility is alot (Business Critical Applications). Also on the Job Market the Peers are ranging from 140k - 160k.

Im always thinking about the say, you need to be greedy sometimes yourself if its justified. Else some Manager gonna cash in the slip.

Should I suggest 135k or by your experience would you advertise higher like 145k-150k?

You work in a team, for a team to move forward successfully the team should work in sync. A team always has a goal and a plan to get to it. There are times when the team needs to take a different direction therefore the set path should always be available for change because our environments dictate it.

We all have different styles of working and different opinions on how things should work. Sometimes one is wrong and the other is right, and sometimes both are wrong, or actually sometimes both are right. However, at the end of it all, the next step is a decision for the team, not an individual, and moving forward means doing it together. #KickAssTeam

The end result can not come in at the beginning but only at the end of an implementation and sometimes if you’re lucky, during implementation you can smell the shit before it hits the fan. So as humans, we will make mistakes at times by using the wrong decisions and when this happens, a strong team will pull things in the right direction quickly and together. #KickAssTeam

Having a team of different opinions does not mean not being able to work together. It actually means a strong team! #kickAssTeam However the challenging part means it can be a challenge. This calls for having processes in place that will allow the team members to be heard and for new knowledge to take lead. This space requires discipline in listening and interrogating opinions without attachment to ideas and always knowing that YOUR opinion is a suggestion, not a solution. Until it is taken on by the team. #KickAssTeam We all love our own thinking. However, learning to re-learn or change opinions when faced with new information should become as easy to take in and use.

Now, I am no expert at this however through my years of development I find this strategy to work in a team of developers. It’s a few questions you ask yourself before every commit, When faced with working in a new team and possibly as a suggestion when trying to align other team members with the team.

The point of this article, the questions to self!

Am I following the formatting standard set?

Is what I have written in line with official documentation?

Is what I am committing a technical conversion of the business requirement?

Have I duplicated functionality the framework already offers?

I have introduced a methodology, library, heavily reusable component to the system, have you had a discussion with the team before implementing?

Are your methods and functions truly responsible for 1 thing?

Will someone you will never get to talk to or your future self have documentation of your work?
Either via point number 2, domain-specific, or business requirements documentation.

Are you future thinking too much in your solution?

Will future proof have a great chance of complicating the current use case?

Remember, you can never write perfect code that cures every future problem, but what you can do perfectly is serve the current business problem you are facing and after doing that for decades, you would have had a perfect line of development success.