There's this thought that keeps popping up in my head more frequently recently.

We are people who do heavy mind work. Our quality of life directly depends on our ability to come up with solutions. We've been training our minds for years, for decades, to get to the point where we are now.

Now stop for a moment. And imagine. You wake up one morning and you realize you can no longer code. You forgot all of it. You still can copy-paste answers from SO, but you don't know what questions to ask to get to those answers.... Your mind has pulled the DROP TABLE PROGRAMMING;COMMIT; stunt. From hero to zero in just 1 night.

You have no clue what happened, no idea whether you will recover. How does that affect your identity? Would you still try to climb the programmers' tree to the sweet spot you are in now? Would you choose some simpler profession instead, considering your age and time required to master that other profession? If you choose another profession - what would it be?
What would you do with your personal projects? You can't continue them yourself obviously... Would you let them die with the loss of your skills?

How closely is your profession related to your identity?

Now that I consider myself a person who's quite good in the field, this is becoming one of my fears. Sadly, it'll most likely come true someday. Either some accident or just old age, or even diseases/conditions at younger ages - there are so many things that could mess up your mind - the sole tool critical for our profession [to the picky ones: lumbers can't swing axes w/o hands, postman can't deliver mail w/o legs, politics can't lie without tongues, and we, engineers, cannot build with our minds even slightly off].

This is more just a note for younger and less experienced devs out there...

I've been doing this for around 25 years professionally, and about 15 years more generally beyond that. I've seen a lot and done a lot, many things most developers never will: built my own OS (nothing especially amazing, but still), created my own language and compiler for it, created multiple web frameworks and UI toolkits from scratch before those things were common like they are today. I've had eleven technical books published, along with some articles. I've done interviews and speaking engagements at various user groups, meetups and conferences. I've taught classes on programming. On the job, I'm the guy that others often come to when they have a difficult problem they are having trouble solving because I seem to them to usually have the answer, or at least a gut feel that gets them on the right track. To be blunt, I've probably forgotten more about CS than a lot of devs will ever know and it's all just a natural consequence of doing this for so long.

I don't say any of this to try and impress anyone, I really don't... I say it only so that there's some weight behind what I say next:

Almost every day I feel like I'm not good enough. Sometimes, I face a challenge that feels like it might be the one that finally breaks me. I often feel like I don't have a clue what to do next. My head bangs against the wall as much as anyone and I do my fair share of yelling and screaming out of frustration. I beat myself up for every little mistake, and I make plenty.

Imposter syndrome is very real and it never truly goes away no matter what successes you've had and you have to fight the urge to feel shame when things aren't going well because you're not alone in those feelings and they can destroy even the best of us. I suppose the Torvald's and Carmack's of the world possibly don't experience it, but us mere mortals do and we probably always will - at least, I'm still waiting for it to go away!

Remember that what we do is intrinsically hard. What we do is something not everyone can do, contrary to all the "anyone can code" things people do. In some ways, it's unnatural even! Therefore, we shouldn't expect to not face tough days, and being human, the stress of those days gets to us all and causes us to doubt ourselves in a very insidious way.

But, it's okay. You're not alone. Hang in there and go easy on yourself! You'll only ever truly fail if you give up.

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.

Today we interviewed a _very_ good Angular1 Dev, by chance we showed him the forked ngRouter module we use, after some debate he explained that we were using it incorrectly.. I asked if he'd used it before to which he responded:

"Yeah, I'm the guy who built it"

😅

For those of you who are having interviews ... remember this

Being paid to rewrite someone else's bad code is no joke.

I'll give the dev this, the use of gen 1,2,3 Pokemon for variable names and class names in beyond fantastic in terms of memory and childhood nostalgia. It would be even more fantastic if he spelt the names correctly, or used it to make a Pokemon game and NOT A FUCKING ACCOUNTANCY PROGRAM.

There's no correspondence in name according to type, or even number. Dev has just gone batshit, left zero comments, and now somehow Ryhorn is shitting out error codes because of errors existing in Charmeleon's asshole.

The things I do for money...

i love programming cz it's fucking awesome

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

36 Tb Of Cloud storage?
Ref: http://1mtb.com/how-to-get-36-tb-fr...
Ref: https://en.wikipedia.org/wiki/...
https://www.360.cn/

Hey guys
was browsing on Cloud storage and found this Pearl...
Virtually unlimited storage.
I know It's a Chinese service (so privacy = null) but to place huge files...
Who knows or uses this service that can provide us with some info?
Thanks