Debugging

I was working with a friend today helping her deal with some issues... she's never been a dev before and she's been tossed in the deep end of developer life.

Thinking like a programmer is something that generally takes some time to grasp. It's such a weird mindset that you have to get into. And to top it off if you don't know how to solve the basic problems you can't even search for solutions to problems.

Take for instance an error you get when running a command from the shell:

Can't stat file /home/foo/.ssh/dir/file

You can't even search for that unless that is a super common error.

But the thing with debugging is to start to question assumptions -- even assumptions that you didn't even think you had in the first place like the command ought to work.

Let's first assume a Unix-y environment for this example...

So let's first go to cd ~. You do an ls.

You don't see .ssh. Assumption: the .ssh directory should have been there.

Oops. No one told you that files that begin with a dot are hidden by default. Well, some things you just have to learn the hard way I suppose. Assumption: you can see files.

ls .ssh/dir/file

Can't access file. Assumption: files in your home directory are readable by you.

Fine... ls -la

Oh look, .ssh is owned by root and you don't have read access to it. WTF? Ok... well let's do a quick dive into the Unix security model.

sudo chown foo .ssh

Re-run the command and it still fails. cd .ssh; ls -la Fuck, the subdirectory is still owned by root. Assumption: CHange OWNership changes everything.

eyeroll

sudo chown -R foo .ssh

Re-run it. Assumption: the instructions you're trying to follow are correct.

Finally you get another error message... but this one is finally actionable -- or at least searchable.

Thinking like a programmer is something that is learned; it's learning all the ways you can be wrong without even knowing you could be wrong in that way.