For me it has to be dealing with other developers who don’t want to keen with the times.
I don’t mind anyone deciding they don’t want to learn new things, for whatever reason.
But when you’re in a team if you feel that way it’s unreasonable to expect the whole team to stop developing their skills for you.

Back in Hell, we had a “company summit” where everyone flew in for an all hands meeting.

It was three days long in a tiny office with very lacking air conditioning in the middle of a Las Vegas summer. Basically the entire thing was the CEO / goblin salesman king chewing at us and expounding about / proselytizing his latest and greatest sales ideas and how they’ll change the world. And randomly asking “which of you are HUNGRY?! Which of you want to be FILTHY FUCKING RICH?!” etc.

One good thing came out of it, which was that any and all new endeavors needed a “co-signer” and a sign off from development before we (developers, or more accurate: just me) would work on it. It reduced the growth rate of my backlog by like 80%, which was nice.

While dreading the “summit,” I hated him more than I had in quite awhile.

During the summit, I hated him more and even flipped him off.

After the summit, I swore to leave the revolting wreckage that was the company.

(And months later, I did just that —after becoming the sole dev and the only person holding the damned company afloat. When I gave him my two weeks’ notice, I absolutely relished his terror. And my time spent writing my 43 page no-sugarcoat handoff document that was guaranteed to scare off any hapless dev he might find. 😇)

But I digress, three 10-hour days with him and the rest of the sales team, the sleazy lawyer, the CTO who mentally checked out years ago, the yes-man contractor, and me. The only good thing that came out of that meeting was one good idea that he dismissed, and the sign off idea that saved my backlog a bit.

One of the sales people quit shortly thereafter. So it was a huge expense that wasted everyone’s time and added absolutely nothing of value to the company. GG!

Oh, it was also in the “totally better” office — meaning… cheaper, unfinished (literally plywood floors), and was one room in another company’s office, who often locked the door leading to their offices because they trusted him so much. But it was in downtown Las Vegas, with no parking at all, where gang members were hanging out almost every day, and it was next to low-income housing and weird no-service restaurants with shockingly high prices.

Weird and scary.
Very scary.

Totally carried pepper spray every time Mr. Goblin asshole forced me to go into the office. Didn’t get raped, though, or my laptop or car stolen. So that was nice.

Diary of an insane lead dev: day 447

pdf thumbnails that the app generates are now in S3 instead of saved on disk.

when they were on disk, we would read them from disk into a stream and then create a stream response to the client that would then render the stream in the UI (hey, I didn't write it, I just had to support it)

one of my lazy ass junior devs jumps on modifying it before I can; his solution is to retrieve the file from the cloud now, convert the stream into a base64 encoded string, and then shove that string into an already bloated viewmodel coming from the server to be rendered in the UI.

i'm like "why on earth are you doing that? did you even test the result of this and notice that rendering those thumbnails now takes 3 times as long???"

jr: "I mean, it works doesn't it?"

seriously, if the image file is already hosted on the cloud, and you can programmatically determine its URL, why wouldn't you just throw that in the src attribute in your html tag and call it a day? why would you possibly think that the extra overhead of retrieving and converting the file before passing it off to the UI in an even larger payload than before would result in a good user experience for the client???

it took me all of 30 seconds to google and find out that AWS SDK has a method to GetPreSignedURL on a private file uploaded to s3 and you can set when it expires, and the application is dead at the end of the year.

JFC. I hate trying to reason with these fuckheads by saying "you are paid for you brain, fucking USE IT" because, clearly these code monkeys do not have brains.

Linux is hard to learn and master. That's fine with me. Windows is intuitive, but not user-friendly. Linux has a steep learning curve, but then is far more user-friendly than any other operating system. To me, that steep learning curve was far more than worth it, as I now have a desktop that does whatever I want, and behaves exactly as I want.

People come to Linux hoping that it will be easy to pick up, and then get angry when it isn't. Then they claim that the community is toxic, because Linux users are happy with something they think is broken.

Linux is hard to learn, and that's fine. That's valuable, to me. That's part of the appeal to me(and millions of others). Linux is unforgiving when you lack the knowledge gained in that steep learning curve. That's fine with me too. As its userbase grows, so too does the number of knowledgeable people who work to make it better and invent more amazing things for it.

If Linux was easy to learn, it wouldn't be as good as it is, and to me, that's reason enough to love it.

!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!

Interviewer: Why do you want to work for Facebook?

Me: I'm keen on protecting people's data and want them to have a good user experience

Interviewer:

Me:

Interviewer:

Me: haha I'm joking I don't give a shit

Interviewer: haha omg I was like whaaatttt lmao

src: https://twitter.com/ArfMeasures/...

Friend :- Dude i made some changes and the code is not working now.
Me:- Bro, Do you even GIT it?
Friend :- No i don't GET it how it happened and how to restore it.
Me :- You destroyed my pun and my faith in your development skills -_-.