This is the hardcore version of the more common "Google for help on something and get your own blog post/Stack Overflow answer coming up"! :-)

Yes, and it's comforting to know that even these people need to look up UNIX flags from time to time! Not really surprising, but a bit reassuring nonetheless.

That actually happens to me from time to time and I've learned to look through my own blog posts for answers before venturing out.

However, the worst situation is when I google for answer, find that ONLY my own blog post has something relevant and it doesn't answer exactly what I need -.- at that point, I'm like, "Google, I wrote this, I already read it, why don't you have something better to show me?"

This happens to be about once a year. I always find it equally funny each time though.

Exactly my thought. This has happened to me once. It was hilarious.

Given that he is listed as an author for ls, cp, mv, ln, rmdir and yes, yes as well, I can see how he might forget that he wrote su.

"Geez, what idiot wrote this code? Oh yeah, me."

I hate that feeling.

I think I hate that feeling because it usually comes up in the context of a bug. Something that's lived in the system for years. It's existed through a half dozen code reviews when related code is refactored.

Then some college grad comes in and starts asking all these stupid questions like, "why does this function loop n^2 times and not just return the number 42 every time?" You answer, "Well you see this part here, Billy, this is the important part it ... it calculates ... give me 2 seconds ... ... ... ... fuck."

I love when that happens! That's because I hate being wrong. I really really really hate it. I hate being wrong so much that I'm extremely grateful when people point out my mistakes. Then I get to stop being wrong and start being right! The satisfaction I get from that more than makes up for any amount of embarrassment stemming from the revealing of my mistake. It's not that I hate _appearing_ to be wrong. A little embarrassment never killed anybody. Rather, _being_ wrong is awful, even if nobody knows it, even if I don't know it.

I hate being wrong.

I try to engineer that specific feeling. Working on a very small team, or even alone, I'll intentionally rotate among projects on a timescale of days. When I eventually swing my attention back to a recent project, the additional set of eyes that makes bugs shallower is my own. I'm slightly different in the Ship-of-Theseus sense.

If I don't have a sufficiently large team in the space dimension, my best option is to increase its size in the time dimension.

Bold approach. That's really good thinking!

I love that feeling! It always gives me insight into my own thought process to see it as someone else would, and I always learn something from it.

This is the oppositie: "What wonderful sexy developer wrote this documentation that was so helpful? Oh, hey, it was me!"

I've had the same experience, only with prose (an old forum post of mine).

This article is a good reminder of why writing documentation (and commenting code) is important. Often the reader of your docs is you.

I did not expect that ending.

I was amazed by this paragraph, "Shortly thereafter, someone came running into the room and ... was worried about an attempted breakin."

Just think of a Network Administrator doing this every time there was a root login attempt that failed. They'd get a lot of exercise these days, that's for sure.

The reason probably was that this was highly unusual. There was no flood of break-in attempts from the Internet and the absolute majority of students usually have no curiosity and are only using such servers for lab assignments.

This reminds me how my first unix account at college was locked by sysadmins during the first day. I only knew "cd" and "ls" at the time... :)

What harm did you cause with cd and ls??

As far as I know, I didn't cause any harm. From what I heard, the sysadmins didn't like the floppy drives making noises on their Solaris x86 server.

I saw it happen in 2004. The University of Bristol has some strange options on their machines, such as home directories being globally readable unless you change it yourself (failure to do so isn't a defence if someone plaigarises your work), but the strangest one I saw was the total lack of ulimits on shared machines.

Every time someone tried to su the IT staff would show up and ask them what exactly they thought they were up to. That went a long way to instilling the idea that you shouldn't mess about doing things you shouldn't on communal hardware.

> such as home directories being globally readable unless you change it yourself

Also the case at University of Birmingham. Must be a default somewhere

At Durham University in 2000, "net send hello" at a Windows command prompt caused a message box to appear on every Windows computer on the uni network. I gave myself up to the bewildered IT department immediately.

Reminds me off my early days of discovering Unix commands. Except this was on my first job in a Bank running SCO Unix; a decidedly less forgiving environment than a University. I was the unofficial assistant sysadmin (long story) and running banner "hello"|wall in the middle of a busy day at the branch caused a fair bit of confusion. Thankfully we were a young bunch and sysadmin let me off with a somewhat stern warning.

Really? In my experience most devices don't allow password-based root login attempts to the world at large. Either they're only accessible via some sort of privileged network, or they're only accessible with a key.

Use it or lose it, it happens to the best of us. There is only so much I can remember at one time, I don't even worry about it, so long as I can find a way to look it up. I wish I had a photographic memory. Knowing that I don't, I don't obsess about remembering the details only the high level over view of things.

Typically for short command line options, I've noticed that if I stick with the first character of the word that immediately comes to my mind while contemplating, I'm able to recall it much easier and even after a longer time. Maybe something to do with how my brain is wired so sticking to the natural instinct results in repeatable results. If the option takes the last <n> lines from the file, "tail" immediately resonates so "-t" makes more sense and sticks to memory longer. Of course, with increasing no. of options, this strategy becomes less reliable.