Here’s a poster with a super short description of each one to help you keep track and find some new useful Linux tools.

Is it usual to not be allowed to use headphones/earbuds at work?

We cant at our offfice atleast. The explination was that IF clients come by the offfice it looks like we are having a lan party! 😂

F*** all this motivational/inspirational shit going on nowadays. We don't need cold showers, wake up 4:30 AM, or sacrifice time with loved ones just because our ego wants to be successful.

What if I don't want it, what if I just want to BBQ some chickens, drink Red Bull, and watch some Netflix shows until I die.

I don't want to own a Lamborghini, big apartment, live in a warm place with a nice view over the blue ocean, etc. This is just an illusional life-style story that every single person in the world wants, and the reason is so media and commercial companies can trick people to buy whatever they want.

I don't give a shit, we'll all die someday, I don't need these things in my life to make me feel happy or complete. I've seen people with everything, yet they commit suicide because the inner self is broken.

Just be happy with whatever you have, and stop going after things that won't really make you happy. The fact you have eyes to see, ears to hear, and hands to feel is worth billions in itself.

Wake up.

The riskiest dev choice...

How about "The riskiest thing you've done as a dev"? I have a great entry for that. and I suppose it was my choice to build the feature afterall.

I was working on an instance of a small MMO at a game company I worked for. The MMO boasted multiple servers, each of them a vastly different take on the base game. We could use, extend, or outright replace anything we wanted to, leading to everything from Zelda to pokemon to an RP haven to a top-down futuristic counterstrike. The server in this particular instance was a fantasy RPG, and I was building it a new leveling and experience system with most of the trimmings. (Talents, feats/perks, etc. were in a future update.)

A bit of background, first: the game's dev setup did not have the now-standard dev/staging/prod servers; everything ran on prod, devs worked on prod, players connected and played on prod, etc. Worse yet, there was no backup system implemented -- or not really. The CTO was really the only person with sufficient access. The techy CEO did as well, but he rarely dealt with anything technical except server hardware, occasionally. And usually just to troll/punish us devs (as in "Oops ! I pulled the cat5 ! ;)"). Neither of them were the most reliable of people, either. The CTO would occasionally remote in and make backups of each server -- we assumed whenever he happened to think of it -- and would also occasionally do it when asked, but it could take him a week, sometimes even up to a month to get around to it. So the backups were only really useful for retreiving lost code and assets, not so much for player data.

The lack of reliable backups and the lack of proper testing grounds (among the plethora of other issues at the company) made for an absolutely terrible dev setup, but that's just how it was, and that's what we dealt with. We were game devs, afterall. Terrible or not, we got to make games! What more could you ask for!? It was amazing and terrible and wonderful and the worst thing ever, all at the same time. (and no, I'm not sharing the company name, but it isn't EA or Nexon, surprisingly 😅)

Anyway, back to the story! My new leveling system also needed to migrate players' existing data, so... you can see where this is going.

I did as much testing and inspection of my code as I could, copied it from a personal dev script to the server's xp system, ... and debated if I really wanted to click [Apply]. Every time I considered it, I went back to check another part or do yet more testing. I ended up taking like 40 minutes to finally click it.

And when I did... that was the scariest button press of my life. And the scariest three seconds' wait afterwards. That one click could have ruined every single player's account, permanently lost us players ...

After applying it, I immediately checked my character to see if she was broken, checked the account data for corruption or botched flags, checked for broken interactions with the other systems....

Everything ended up working out perfectly, and the players loved all of the new features. They had no idea what went into building them, and certainly had no idea of what went into applying them, or what could have gone wrong -- which is probably a good thing.

Looking back, that entire environment was so fragile, it's a wonder things didn't go horribly wrong all the time. Really, they almost never did. Apocalypses did happen, but were exceedingly rare, and were ususally fixed quickly. I guess we were all super careful simply because everything was so fragile? or the decent devs were, at least. We never trusted the lessers with access 😅 at least on the main servers where it mattered. Some of the smaller servers... well, we never really cared about those.

But I'm honestly more surprised to realize I've never had nightmares of that button click. It was certainly terrifying enough.

But yay! Complete system overhaul and migration of stored and realtime player data! on prod! With no issues! And lots of happy players! Woooooo!

Thinking back on it makes me happy 😊

So we found an interesting thing at work today...

Prod servers had 300GB+ in locked (deleted) files. Some containers marked them for deletion but we think the containers kept these deleted files around.

300 GB of ‘ghost’ space being used and `du` commands were not helping to find the issue.

This is probably a more common issue than I realize, as I’m on the newer side to Linux. But we got it figured out with:

`lsof / | grep deleted`

Made it!!! Starting at CERN on September 1st! :)

A big thank you to you guys for the support in my previous posts!

Modern software has gotten so bad that it even gets sluggish at times on late 2018 flagship devices. Slow, cheap hardware like is usually developers' and fanboys' excuse, particularly when it comes to Windows stuff? Like hell it is.

Software "engineering" has become so.. terribly inefficient. I'd dare any developer worth their salt to rewrite their program to make it work on an early 2000's machine. After all, those can run pretty advanced GUI's, have a reasonable amount of hardware (just think about how large a gigabyte of RAM really is) yet should be able to make for a reasonable limitation set.

Hardware limitations are the mother of optimization. Not every person on the planet has a 32-core Xeon workstation with 64GB of DDR4 RAM and a GTX Titan in it. Whether your application performs reasonably well on your machine shouldn't be the metric. Try deploying it on that laptop you tucked into a shelf years ago and reevaluate.. please.

And definitely you Slack!! Slacking off, is that what inspired the name of that pile of junk?! 😡

!rant

After over 20 years as a Software Engineer, Architect, and Manager, I want to pass along some unsolicited advice to junior developers either because I grew through it, or I've had to deal with developers who behaved poorly:

1) Your ego will hurt you FAR more than your junior coding skills. Nobody expects you to be the best early in your career, so don't act like you are.

2) Working independently is a must. It's okay to ask questions, but ask sparingly. Remember, mid and senior level guys need to focus just as much as you do, so before interrupting them, exhaust your resources (Google, Stack Overflow, books, etc..)

3) Working code != good code. You are an author. Write your code so that it can be read. Accept criticism that may seem trivial such as renaming a variable or method. If someone is suggesting it, it's because they didn't know what it did without further investigation.

4) Ask for peer reviews and LISTEN to the critique. Even after 20+ years, I send my code to more junior developers and often get good corrections sent back. (remember the ego thing from tip #1?) Even if they have no critiques for me, sometimes they will see a technique I used and learn from that. Peer reviews are win-win-win.

5) When in doubt, do NOT BS your way out. Refer to someone who knows, or offer to get back to them. Often times, persons other than engineers will take what you said as gospel. If that later turns out to be wrong, a bunch of people will have to get involved to clean up the expectations.

6) Slow down in order to speed up. Always start a task by thinking about the very high level use cases, then slowly work through your logic to achieve that. Rushing to complete, even for senior engineers, usually means less-than-ideal code that somebody will have to maintain.

7) Write documentation, always! Even if your company doesn't take documentation seriously, other engineers will remember how well documented your code is, and they will appreciate you for it/think of you next time that sweet job opens up.

8) Good code is important, but good impressions are better. I have code that is the most embarrassing crap ever still in production to this day. People don't think of me as "that shitty developer who wrote that ugly ass code that one time a decade ago," They think of me as "that developer who was fun to work with and busted his ass." Because of that, I've never been unemployed for more than a day. It's critical to have a good network and good references.

9) Don't shy away from the unknown. It's easy to hope somebody else picks up that task that you don't understand, but you wont learn it if they do. The daunting, unknown tasks are the most rewarding to complete (and trust me, other devs will notice.)

10) Learning is up to you. I can't tell you the number of engineers I passed on hiring because their answer to what they know about PHP7 was: "Nothing. I haven't learned it yet because my current company is still using PHP5." This is YOUR craft. It's not up to your employer to keep you relevant in the job market, it's up to YOU. You don't always need to be a pro at the latest and greatest, but at least read the changelog. Stay abreast of current technology, security threats, etc...

These are just a few quick tips from my experience. Others may chime in with theirs, and some may dispute mine. I wish you all fruitful careers!

A young guy I work with burst into tears today, I had no idea what happened so I tried to comfort him and ask what was up.

It appears his main client had gone nuts with him because they wanted him to make an internet toolbar (think Ask.com) and he politely informed them toolbars doesn't really exist anymore and it wouldn't work on things like modern browsers or mobile devices.

Being given a polite but honest opinion was obviously something the client wasn't used to and knowing the guy was a young and fairly inexperienced, they started throwing very personal insults and asking him exactly what he knows about things (a lot more than them).

So being the big, bold, handsome senior developer I am, I immediately phoned the client back and told them to either come speak to me face-to-face and apologise to him in person or we'd terminate there contract with immediate effect. They're coming down tomorrow...

So part my rant, part a rant on behalf of a young developer who did nothing wrong and was treated like shit, I think we've all been there.

We'll see how this goes! Who the hell wants a toolbar anyway?!

I just completed my first live soldering project...

Converted my son's mobile (dangly plush animals and music not cell phone) from using 4 X C batteries (LR14) to using an AC-DC transformer

I hardwired it at 6v and it worked, and I didn't burn myself, and I cut a little gap for the wire and it's really snug so the solder is under no tension.

I tinned the wires beforehand like I knew what I was doing and for once I didn't fuck it up!

Sorry, just had to tell someone. The wife's asleep and she just won't understand.

This made me laugh

Me: *Opens GitHub issue*

Maintainer: "it's a known issue"

# issue closed