DevOps is like working in sanitation. If everything works as it should, no one cares about you. But if there is a problem, everyone is up to their eyeballs in shit, and it is your fault.
Same as IT btw.

merged a complicated pipeline script based on 3 other scripts, and it worked the first time I run it.
Pretty sure There was a Disturbance in Force...

This was a long time ago, when I was working part time in my uni helpdesk. as part of the uni IT service, they offered ISP services at the dorms. It was cheap, and fast. This essentially allowed students living in the dorms to connect thier personal computers to the uni LAN. Then one day...
An ARP poison malware infected some of those computers. An arp poison attack is simple (look at ettercap) - it redirects network traffic via the affected computer, and adds malware to webtraffic to infect more computers. One of these on a network is bad enough, but when there more then one... traffic was redirected a lot. this caused the Dorm switches to collapse under the load. Fun times to work at the helpdesk...
The IT guys came up with a solution for this: they blocked the arp poision attacks at the firewall, and then disabled the switch port for the infected computer for 24 hours. so, when someone called with 'I have no internet!', we told them to bring us the computer, and installed an AV on it.
3-4 month the problem was cleared.

teach meta language concepts: what is an operator, literal, constant, statment, control flow. the recursive nature of staments. then go into objects/methods vs structs/procedures. then teach some java. then go into reflection concepts. then use reflection for something simple. then teach a bit of perl. then let them build something in python. Anyone who can pass through that will know how to Program in whatever you give him/her.
I wish my teachers talked about the meta programing, instead on focusing on the minutia.

well... I'm not sure...

Somewhere without morons, and HR. 🤔 maybe it is the same?

Always remeber:
The interview goes both ways. Ask the interviewer how he likes to solve problems, and how he works with ppl. This will give you the information to decide if you want to work with him or the company.
This is especially effective on HR: ask about thier corporate culture and how they deal with promotions/good people and how they deal with bad people.
And make sure you visit glassdoor.com before the interviews begin.

there is always somone smarter then you doing this shit.
Also, wait a week after you hear bright ideas from manament, and don't start work untill then.

working on a better captcha...

My working style in a nutshell...

ffs.
Got to the office in the morning. Boss says, ok we want to do a toast for one thing or the other. Got a nice glass of red wine. drank it. Nice wine. got back to my computer, and started to work. the boss man calls me back. I say whats up? he says, bottle of whiskey....

drunk coding is fun!

I used to work with another dev who had memory problems. This guy *literaly* could not remeber what he did yesterday...
So, he was trying to change one of the password screens we had in the app. This was a really simple screen. Logo, password prompt, and two buttons. He worked on this small change for two days, but everything he did did not affect the screen at run time.
So finally, he gave up and called me to help him... I come over, and look at his code. It looks ok. I make a small change, and see what happens. Nothing. I think for a moment, and delete the entire screen UI elements. Run the app. Nothing happens - screen still the same.
Then I got it - he kept changing the wrong screen... for two days....
took me a whole 5 minutes to figure out.

!rant & story_time
This happend to the startup I was working for at ~2011. I was a junior Android dev, working on a very popular app.
During experiments for a new feature, I discovered that the system AlarmManager has a serious bug - you can set a repeating alarm with interval=0ms. If your app takes more then 1 ms to handle the Intent, then the AlarmManager will start to fill up the intent Queue, with unexpected results to the OS. causing it to slow down, and reboot when it ran out of Ram. Why? my guess was that because the AlarmManager was part of the OS, then any issues caused by it caused the system process to ran out of ram, crashing it, and the whole system with it. the real kicker was that even after a reboot, the AlarmManager still had Intents queued, causing the device to bootloop for a while, untill the queue was cleared. My boss decided to report the problem to google, as this was an issue in the OS. I built an example app, that caused the crash 10-30 seconds after starting, and submitted to Google. Google responded later that day with "not an issue, no one will ever do this".
Well... At this point I decided to review the autoupdate feature in our app, to make sure this will not happen to us. We just released a new feature where a user can set an update schedule option in the app settings - where you could setup a daily, weekly, or hourly update for the app. after reviewing it, It looked good, and the issue was not triggered in the manual QA I did. So, it was all good. And we released an updated version to the store.
After we did an update-install, we discoverd that, there was a provlem reading the previous version SharedPrefs value for the update schdule settings, and the value defaulted to 0...
the result was, our app caused all our users to go into a bootloop, and because the alarm was reset when the devices booted up, the bootloop could only be solved in a factory reset, or removing our app, before the device rebooted, and then waiting a few reboot cycles.
We lost 50 places in the market, and it took us 6 months to get back to where we were.

It was not my fault, but it sucked big time!

bug comment in the tracker, from the new junior dev, during her first week:
"probably fixed by [other dev]".
Among the unhelpful comments, this was a special gem. really special. a What the Fuck did you mean by that special. Was it fixed or not? who fixed it? [other dev]? someone else?
it was better not to have any comment at all.
later that junior became a really good dev...

"If builders built houses the way programmers built programs, the first woodpecker to come along would destroy civilization." Gerald weinberg.

started by writing a perl script to crawl a website. The problem with that, is the fact ot affected the way I program. And not in a g/ood/i way.

what do you want to do in 5 years?

a singelton class with four public static fields.
when you all you is a hammer....