Inspired by @h3ll, this is a combination of current and former coworkers:

Awkward Wizard:
This guy has the social skills of a microwaved dog turd. He is a genius, but working with him is about as uncomfortable as sticking a grill skewer in your eye and twisting it repeatedly until close of business. He laughs at inappropriate times, and every time he does, an unborn child tears its own ears off. He explains things in a way that only himself and Satan understand, then talks to you like you're a child when you don't follow his logic. He is the guy you hide when the CEO is around. His code is immaculate.

Backstab McGillacutty:
This bowl of bile is the son of a bitch that takes credit for everybody else's work. When you do something good, he was miraculously involved, but when you mess up, this twat is the dicknose that brings it up in retrospective and calls you out by name to the boss. You can usually find these guys talking shit about the CTO, until the boss quits. Then they buddy up with the CTO and become a Joel Osteen-esque evangelist for everything the CTO wants in a shitty, underhanded attempt to climb the ladder. Fuck this guy.

Professor Fuckwaffle:
This coworker used to teach Computer Science classes. Their resume is amazing, and they can speak to the most complex of design principles. This is the shitstain that you hire because of their skill and knowledge only to find out that ol' fuckwaffle can't apply the shit they spout to save their wretched lives. You'll spend more time listening to fuckwaffle lecture than you will reviewing their code (because they cant fucking write any!) You know the saying, those who can, do, and those who can't, teach? Yeah, that shit was written for Fuckwaffle.

Last but not least:
Scrumdumb:
This guy isn't even a coder. This guy is worse than the the scum you pour out of the bottom of a slow-cooker that you forgot to wash last time you made chicken. He's a non-technical PM. You know the type, right? He usually says "cloud infrastructure," "paradigm," "algorithm," "SDLC," etc but has no grasp of any of them. He often opens his dumpster to spout off something like "You can just create a new class for that" while talking about HTML. I won't waste any more breath on Scrumdumb, he already creates enough work for me.

Rewriting my Swift app in React Native and being told I should get familiar with Redux now...

I have written some REALLY complex stuff in my career, but I simply cannot wrap my head around "state," Redux, or why.

After adding in Redux and converting to it's folder structure, adding a random action, type, container, and reducer, and my app still works the same way I'm left wondering: "why did I need this?"

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

!rant

That rejuvenating feeling when you've been trying to get a piece of code working for days, google hasn't helped, and you're just about to call it another lost day, when a random "what happens if I do this" solves everything.

I'm going to dream about puppies, prancing through a meadow, and rootbeer floats tonight!

Can't decide if I'm nostalgic or a hoarder.

Apparently I'm old, regardless.

Pseudo-rant:

I'm worn out from working a full-time job, working on my app, and having a family.

My app has potential, I launched it in July (iOS only so far) and am already well over 1000 active users. It's first week in the app store, it was in the top 100 for it's category.

It has some bugs that I'm working out, and some features that are in high demand.

I'm currently completely refactoring the API because I let it become spaghetti as I went from concept to v1.

That refactor means a rewrite of the website, and a major refactor of the iOS app, which is all fine and dandy.

On to the question: I am an engineer/architect, not a business major. I know I could really use help, and I know the perfect people to try to bring on, but also know I have nothing real to offer them other than a stake in the company.

As a developer, does a stake in a promising, but unproven company have enough prospect to sacrifice your time for?

Am I just being impatient, and should I continue nibbling at it myself until I get there, even if it takes a long time?

How do you determine the stake to give up, when you know that you COULD do it all yourself and keep all the monies?

I should have taken some business classes.

When you post an opening for a junior developer, and the only resume you get is a "Senior Developer with Team Lead Experience" you interview them anyway...

When that interview reveals their resume is fiction, and they're very junior.

Working a full-time job, then helping with the newborn/household, then staying up until 3am because it's the only time I have to work on my app.

After a year now, the burnout is strong.

Tips to reenergize?

Finally have the home office I've always wanted, with only a few more things left to do in order to consider it finished.

Power company loves me.

Wallet hates me.

When your coworker quits and the CTO (in an attempt to smooth things over) tells you (an engineer) "Don't sweat it, Engineers are replaceable."