Not sure about intern, but I've onboarded a lot of new people and I love it. I just take 1-3 hours a day and have them share their screen and work on their task.

Once they're comfortable, the sessions turn from a pairing session to a planning session that doesn't last as long, and with a few 10 minute checkins.

Eventually the person ramps up. You just need management to carve out time for this so you aren't overloaded, and you need to make it clear that the person isn't interrupting you, it is part of your job to help them, even being proactive and asking people if they want an extra pair of eyes for those who don't feel comfortable asking for help when they need it

Yes, and it’s honestly more comfortable to share screens over Zoom than it is to try squeezing next to them at their desk in an office.

or using their disgusting equipment. I would absolutely refuse to use some coworkers keyboards or mice...

The timing slide caught my attention as well. 3 months for anything is fast...

They may well have had a good small scale success already, it seems like/perhaps, but still seems quite solid.

This is more like going to people's homes and collecting their ballots than anything you've posted. You've eliminated all nuance in your replies.

If you think you see a fire in a crowded building and you say something, even if there isn't a fire, it's way different than going into a building and causing chaos because you want to cause chaos

I was taken out to dinner and drinks, referred to as a new hire, and then ghosted. I had been interviewing for a while so it was fairly painful.

After reading, I wouldn't necessarily say he's 'gaming' the interview. It sounds like this guy really expanded his programming knowledge, wrote a ton of code, and learned to solve a wide array of problems.

If anything, it's a guide on how to learn everything you'd need to know to be a junior developer.

I'm getting tired of these pseudo-cool programming job titles. Guru, hacker, wizard, ninja.

I haven't met many well-functioning, self-described ninjas.

Until you want to undo something! Nano is definitely more user-friendly though. Some of the engineers I work with still don't know basic vim shortcuts, like 'w' and 'b'

I use a lot of "yw", "d4w", or "dd" ..

are there others life-saving useful as these?

How about find and replace?

:%s/foo/bar/gc

The "gc" will apply the find and replace globally, and ask for confirmation before changing an occurrence of "foo".

After googling this three separate times I finally just aliased it to an 'untar' command. I'll remember this for when I'm ssh'ed somewhere!

It just takes a while to be faster in the terminal than with the gui, and most people won't switch from the thing they're used to until they see significant advantages.

I remember when I first started using the terminal, it was slow and confusing. You had to read the man pages for every little thing. Discovering the command you want is tough, I'd be screwed without the internet.

Now I hate when I need to take my hands of the keyboard to use the mouse. What a waste of time!

Bash scripts are great if they're yours. My current project has ~20 large bash scripts that do all sorts of different things. They were all written by people who haven't worked on the project for two years. Anyone who needs to make changes there spends far too long trying to figure out what's going on. The scripts could have been written in the same language as the project, and it wouldn't take a whole day to make changes to them.

I think they wrote in Bash to avoid the interpreter startup time. But the scripts are run very infrequently and most of them start/stop long-running services.

That being said, getting a bash script to do the right thing is very satisfying!

Bash scripts for very simple series of commands; higher level scripts for when those sets of commands need logic wrapped 'round 'em. For example: provisioning for packer|vagrant, if you don't need to go overkill with puppet|chef.