Not having a website is boring. One day, I realized that there was nothing preventing me from not not having a website, and then the text you’re reading was written!
This site serves as a way for me to keep myself accountable. I tend to invest myself too heavily into my career, so I’ve taken all of the old coding projects that I wrote for fun and put them into a globally-accessible place as a reminder of how I got started. My brain is convinced that this will make it easier to create more of them, so we’ll see how that turns out.
That’s right! You’ve found yet another software engineer who decided to throw his own words out into the cacophony. Don’t worry, I realize that all of the good “you’re using <technology> wrong and this is why” blog ideas have been taken already, so I’ll be focusing on my experiences mentoring other developers.
Still reading?
Cool!
Do you remember the first time you used a debugger? When most people are learning to program, they learn the versatility of print-out statements, and these were my primary tool for making sure that my logic was behaving as expected. They work well enough, and they can be downright necessary if your development environment is convoluted enough, but they definitely have their limitations:
Accurate assessments are difficult to make, and self-assessments are often even harder. Our industry is fraught with overconfidence and self-doubt alike, and we can very rarely view our strengths and weaknesses with equal weight. Being a source of honest, accurate feedback for someone requires a lot of responsibility, and we need to be very careful with how and when we decide to give it.
So first things first, I think it’s important to get some definitions across. When I say that I’m “mentoring” someone, I don’t mean that I have some protégé following me around with a clipboard, finding wisdom in everything that I do.
