If Programming Languages Were Girls:

Java: Your current girlfriend, you've been going steady for a while now. Things are okay.

Kotlin: The girl Java finds you cheating on, she's just amazing, and you wish you'd met her sooner.

Visual Basic: The girl you accidentally started a relationship with because you didn't know how to say no. But quickly realised your mistake and regretted it.

JavaScript: A childhood friend you occasionally hook up with. But you could never settle for a relationship with them.

Python: A bossy, manipulative girl who quickly turned things sour. But everyone else loves her because of her huge libraries.
-----------------------------------------------------
My and a co worker were joking the other day about what programming languages would be like if they were girls. This is what we came up with (Original inspiration: the Distracted Boyfriend meme (Feel free to add your own!)).

A man goes inside a pet shop and starts to move around the cages to scout the pets. He sees a monkey with a price of 5000$ and goes to the merchant to ask for details. Hey mister, the monkey…what does it know to worth that much money? Well, it knows Windows 95, 98, 2000, and also knows Word, C++, Visual Basic and last but not least, it knows how to play computer games. - Good monkey, it's worth the money. He goes and finds another monkey with a price of 10000$ and again he will ask the merchant. "What does this monkey know?" "It knows Linux, Unix, Corel and Autocad." "Nice, even I don't know those things." On a last scout run he finds another monkey just sitting there with a price 20000$. The story repeats, and he goes with a lack of confidence to ask the merchant for details. "And what does this monkey do for that ridiculous amount of money?" "I never saw her doing anything, but the other two call her Project Manager!"

Why you do this JS ?

Excuse me boss!

During increment time
Boss : There are 50 bricks on an Plane. If u drop 1 outside. How many
are left?

Employee : That's easy, 49.

Boss : What are the three steps to put an elephant into a fridge?

Employee : Open the fridge. Put the elephant in. Close the fridge

Boss : What are the four steps to put a deer into the fridge?

Employee : Open the fridge. Take the elephant out. Put the deer in. Close the fridge.

Boss : It's lion's birthday, all animals are there except one, why?

Employee : Because the deer is in the fridge.

Boss : How does an old woman cross a swamp filled with crocodiles?

Employee : She crosses it because the crocodiles are at the lion's birthday

Boss : Last question. In the end the old lady still died. Why?

Employee : Er....I guess she drowned....err...

Boss : No! She was hit by the brick fallen from the Plane that's the problem, you are not focused on your job....You may leave now!!!

Moral: If your boss has decided to screw u, no matter How much u prepare u will be screwed.

a cool command for your repetitive "cp" bot work

5 Types Of Programmers

1.The duct tape programmer
The code may not be pretty, but damnit, it works!
This guy is the foundation of your company. When something goes wrong he will fix it fast and in a way that won’t break again. Of course he doesn’t care about how it looks, ease of use, or any of those other trivial concerns, but he will make it happen, without a bunch of talk or time-wasting nonsense. The best way to use this person is to point at a problem and walk away.

2.The OCD perfectionist programmer
You want to do what to my code?
This guy doesn’t care about your deadlines or budgets, those are insignificant when compared to the art form that is programming. When you do finally receive the finished product you will have no option but submit to the stunning glory and radiant beauty of perfectly formatted, no, perfectly beautiful code, that is so efficient that anything you would want to do to it would do nothing but defame a masterpiece. He is the only one qualified to work on his code.

3.The anti-programming programmer
I’m a programmer, damnit. I don’t write code.
His world has one simple truth; writing code is bad. If you have to write something then you’re doing it wrong. Someone else has already done the work so just use their code. He will tell you how much faster this development practice is, even though he takes as long or longer than the other programmers. But when you get the project it will only be 20 lines of actual code and will be very easy to read. It may not be very fast, efficient, or forward-compatible, but it will be done with the least effort required.

4.The half-assed programmer
What do you want? It works doesn’t it?
The guy who couldn’t care less about quality, that’s someone elses job. He accomplishes the tasks that he’s asked to do, quickly. You may not like his work, the other programmers hate it, but management and the clients love it. As much pain as he will cause you in the future, he is single-handedly keeping your deadlines so you can’t scoff at it (no matter how much you want to).

5.The theoretical programmer
Well, that’s a possibility, but in practice this might be a better alternative.
This guy is more interested the options than what should be done. He will spend 80% of his time staring blankly at his computer thinking up ways to accomplish a task, 15% of his time complaining about unreasonable deadlines, 4% of his time refining the options, and 1% of his time writing code. When you receive the final work it will always be accompanied by the phrase “if I had more time I could have done this the right way”.

What type of programmer are you?

Source: www.stevebenner.com

My co-workers hate it when I ask this question on a technical interview, but my common one is "what is the difference between a varchar(max) and varchar(8000) when they are both storing 8000 characters"

Answer, you cannot index a varchar(max). A varchar(max) and varchar(8000) both store the data in the table but a max will go to blob storage if it is greater than 8000.

No one ever knows the answer but I like to ask it to see how people think. Then I tell them that no one ever gets that right and it isn't a big deal that they don't know it, as I give them the answer.

string excuses[]={
"it's not a bug it's a feature",
"it worked on my machine",
"i tested it and it worked",
"its production ready",
"your browser must be caching the old content",
"that error means it was successful",
"the client fucked it up",
"the systems crashed and the code got lost" ,
"this code wont go into the final version",
"It's a compiler issue",
"it's only a minor issue",
"this will take two weeks max",
"my code is flawless must be someone else's mistake",
"it worked a minute ago",
"that was not in the original specification",
"i will fix this",
"I was told to stop working on that when something important came up",
"You must have the wrong version",
"that's way beyond my pay grade",
"that's just an unlucky coincidence",
"i saw the new guy screw around with the systems",
"our servers must've been hacked",
"i wasn't given enough time",
"its the designers fault",
"it probably won't happen again",
"your expectations were unrealistic",
"everything's great on my end",
"that's not my code",
"it's a hardware problem",
"it's a firewall issue",
"it's a character encoding issue",
"a third party API isn't responding",
"that was only supposed to be a placeholder",
"The third party documentation is wrong",
"that was just a temporary fix.",
"We outsourced that months ago.","
"that value is only wrong half of the time.",
"the person responsible for that does not work here anymore",
"That was literally a one in a million error",
"our servers couldn't handle the traffic the app was receiving",
"your machines processors must be too slow",
"your pc is too outdated",
"that is a known issue with the programming language",
"it would take too much time and resources to rebuild from scratch",
"this is historically grown",
"users will hardly notice that",
"i will fix it" };

!rant but sometime you need to share some positive vibes.

Found out I could get $50 credit for digital ocean from github because I am a student.

So now I can learn a lot for free, and if I mess something up I can just create a new machine.

So now I am first learning how to work with docker and the communication between containers.

Good to see people want to encourage devs :)

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

Y waste money on a case anyway when u can hav ur own badass rig

Me right now.

Give a man a program and he's happy for a few days.

Learn a man to program and ruin his life 😈

When you are just about to give up..

Just a tip for all those in need...

Found this one on twitter

👌👌👌

Not again...

What do you do when you have a big array filled with strings?

longStory.sort