Errors and using your ear

I had a new interview experience this week. I did a more traditional whiteboard style technical interview, which is something I hadn’t been asked to do before. It was an extremely educational and vulnerable moment for me because it made me realize what has become a part of my process and what I am reliant on when I solve coding problems. Specifically, using the errors and tests to solve problems.

Last week, I posted something about my experiences as a musician and learning in public. I can draw a nice parallel between this and being reliant on the sheet music. There is a relatively accurate joke about “How do you get a guitarist to be quiet? Put sheet music in front of them” that I see or hear relatively often, and there is a grain of truth to that. But for me, it wasn’t a problem. Part of studying for my degree with Doug Niedt was learning how to read, and sight-read, extremely well. So, if someone put music in front of me, it wasn’t a big concern. I would say all in all, it was a huge net positive, but there were some times when it was a hindrance.

When I am coding, I clearly like to build and run things to see what errors there are, and work from there. This is probably fine in most cases, and I was taught this way, both at Turing and through my own private study (especially in the C# Microsoft Learn things that I have done), but when that option is taken away, it made me a little more (or a lot more) self-conscious about what I was doing. I think in Ruby, it wouldn’t have been a big deal, but this was in C#, and I have learned that I still occasionally mix up the syntax with that and Go (which I worked in all summer) when I don’t have something pointing out a compiler error. After the fact, I made an example for myself to look at, so I can really see what the difference is and figure out what I was taking for granted using the errors.

Leave a Comment