This is so mean

I'm done with the 9-5 work culture. Remote work has changed the rules and I believe working 3-4 hours productively, providing some value to customers or your employee, is much better than just forcing yourself to sit 8 hours a day at your desk, attempting to look busy. Often you get bored and eventually you start to question the fact that do I really wanna work here.

This way I have 4 more hours each day to relax, which I might spend learning something new or thinking about a specific problem in the background, but it also helps me maintain my pace of productivity indefinitely, instead of having it slowly decline. I also feel good that I have done something valuable each day.

Productivity over activity.

Knock knock.
Who's there?
Opportunity. That is impossible. Opportunity doesn’t come knocking twice!

Great systemctl isn't supported in Windows Subsystem for Linux (WSL)....just great.

Any reaction to the "Pegasus" leak?

Here's a real tip for people new to the industry.

It's one of those things that's been said over and over again but very few can really seem to employ. I suggest you learn it /well/.

You are not your code. Criticisms of your code, ideas, or your thought processes, is not a criticism of YOU. You absolutely cannot take criticisms of your work personally.

We are engineers. We strive to seek the best solution at all times.

If someone has found a problem with your code or with an idea or whatnot, it is coming from a place of "this is not the best solution", NOT "you're an idiot".

It's coming from a place of "I'm closing this PR because it is not a change I feel suits this project", NOT "I'm closing this PR because it's coming from a woman".

It's coming from a place of "This feature request is ridiculous/this bug is not actually a bug", NOT "you're a fucking idiot, fuck you".

It's coming from a place of "I've already had to address this in a number of issues before and it's eaten up a considerable amount of my time already", NOT "I don't even know you and this I don't have time for a nobody".

You do not get to be bitchy to maintainers because they denied your request. It's not a reflection of you at all. But if you're arguing with someone who has maintained a piece of code for almost a decade, and they're telling you something authoritative, believe them. They're probably smarter than you on this subject. They've probably thought about it more. They've probably seen their code used in many different places. They have more experience than you with that codebase in almost all cases.

Believe me, if we cared about who was behind all of the issues, pull requests, etc. we get, we'd get NOTHING done. Stop taking shit personally. It's a skill, not a defense mechanism. Nobody has the time to sugar coat every little thing.

Let's normalize directness and stop wasting time during technical discussions into opportunities for ego-stroking and circle-jerking and back-patting.

From Datamation magazine circa 1968. Now you can really geek out your friends. This is the kind of stuff you can throw out at a party to kill any discussion.

Best Linux error, now in desktop form

Kid(age: 17): What kind of programming do you do?

Me: Well, I started writing scripts in Python, but in the last few months I moved to IOS development, so like making apps.

Kid: So you write scripts for phones?

Me: Not exactly—

Kid: Do you know what jailbreaking is?

Me: Yeah.

Kid: So do you jailbreak stuff?

Me: No—

Kid: Oh so you don’t really do programming.

:’(

Makes Perfect Sense..

What's your favorite programming quote?

If all you have is a hammer, everything looks like a nail!

This was something which my tech lead used to tell me when I was so obsessed with nosql databases a few years back. I would try to find problems to solve that has a use case for nosql databases or even try to convince me(I didn’t realise it back then) that I need to use nosql db for this new idea that I have, without really thinking deep enough whether the data in question is better represented using an sql schema or not.

Now, leading a team of young developers, I come across similar suggestions from few of my team members who just discovered this new and shiny tech and want to use it in production projects.

While I am not against new and shiny, it’s not a good practice to jump right in to it without exploring it deep enough or considering all the shortcomings. The most important question to ask is, whether some of the problems you are trying to solve can be solved with the current stack.

Modifying your stack requires more than just a week’s experience of playing around with the getting started guide and stack overflow replies. This is something which need to be carefully considered after taking inputs from the people who would be supporting it, that include operations, sysadmins and teams that are gonna interface with your stack indirectly.

I am not talking about delaying adoption by waiting for long list of approvals to get some thing that would bring immediate value, but a carefully orchestrated plan for why and how to migrate to a new stack.

Just because one of the tech giants made a move to a new stack and wrote about it in their engineering blog doesn’t mean that you need to make a switch in the same direction. Take a moment to analyse the possible reasons that motivated them to do it, ask yourself if your organisation is struggling with the exact same problems, observe how others facing the same issue are addressing it, and then make an informed decision.
Collect enough data to support your proposal.
Ask yourself again if you are the one holding the hammer.
If the answer is no, forge ahead!

That awkward moment when you alter your code to see if it work this new way, and doesn't, and undo does not work. *Weapons grade facepalm*

Said my code is self explanatory and doesn't need comments.

After few minutes "wtf is this shit?".