> left inner join

While I do appreciate this joke (and I do hope this is a joke), I've recently had a project majorly held up because a lead dev didn't understand SQL. It's great to admit gaps but it's equally important to close those gaps.

> As a hiring manager I interviewed software engineers and tried to filter for object-oriented knowledge. Retroactively, it’s clear I was hypocritical.

As some one who has been on the other side of "rejected by an interviewer who didn't understand the thing they've interviewed you about" I, again, appreciate the transparency, but I'm not entirely feeling that the lesson has been learned in the case.

There was a time in my life where I felt ashamed that I didn't know calculus... so I learned calculus and my life has been better for it. While refusing to admit ignorance of a topic is particular problem in tech, confessing that you don't know something and gleefully stopping there is not much better. Holding people up to a standard you do not hold yourself to is a major problem in this field. The technical people I've learned the most from hold you to a high standard and hold themselves to an even higher one.

Of course not every engineer has to hold themselves to a high standard, but if you want to write a blog about a topic, then part of the requirements here is that you do hold yourself to a high standard. Yes, we all have gaps, and we shouldn't let shame get in the way of learning, but we shouldn't let shamelessness about what we don't know limit us either.

I am indeed learning, working to close those gaps.

For automated testing, I'm in the middle of reading Developer Testing by Alexander Tarlinder, with xUnit Test Patterns by Gerard Meszaros coming close behind. I'm also working through Test-Driven Development: By Example with my wife as we have time.

For SQL, I read Grokking Relational Database Design by Qiang Hao last winter, and I started SQL Queries for Mere Mortals by John Viescas this week. Sadly, my flub with "left inner join" was not a joke.

For OOP, I've been on a whirlwind tour: OOA&D With Applications by Booch et al., Object Thinking by David West, POODR and 99 Bottles of OOP by Sandi Metz, Domain-Driven Design by Eric Evans, IDDD and DDDD by Vaughn Vernon, Design Patterns in Ruby by Russ Olsen, Clean Architecture by Robert C. Martin, and Smalltalk Best Practice Patterns by Kent Beck. Still on the docket are Design Patterns by the Gang of Four, PoEAA by Martin Fowler, Smalltalk, Objects, and Design by Chamond Liu, and Object Design by Rebecca Wirfs-Brock.

> confessing that you don't know something and gleefully stopping there is not much better [...] we shouldn't let shamelessness about what we don't know limit us either

I promise you, this was not gleeful and this was not shameless. Shame and fear affected me for months on these issues. And I'm not stopping there... From the end of the article: "I’m going to continue to work on skill building, but now I feel free to write about it. If [...] you’d like to help me fill [my knowledge gaps], [...]"

> if you want to write a blog about a topic, then part of the requirements here is that you do hold yourself to a high standard

A high standard of writing, maybe. But plenty of great stories come from those who are striving for a high standard, not just those already in the upper echelon. It's what makes this place different from academic journals.

Not exactly your main point, but where’d you go to learn calculus? I did the usual classes in high school but none since, and I’d love to develop a better appreciation for it.