I've had a couple of moments today where I realized I should speak up about things I don't know. What I realized is that it's a signal that I need to ask for help and/or learn something new. I also realized that I'm not alone in how I feel. While it's scary to say "I don't know how to do something", really, speaking up is a strength. It gives voice to those people who feel the same way and haven't spoken up yet, or may never speak up. And points to assumptions and blindspots in education about the work we do. It's ok to ask the question (Or ye ole proverb: There is no dumb question). Especially in a space where we so often expect everyone to be an expert. There is probably always something to learn from someone else's questions.
So, here's what I don't know. Without any answers.
At my current job we use pull requests and code reviews to ensure a high level of code quality. We 'sidekick' the PRs to our coworkers for review and require that the sidekick give a seal of approval before we merge the code into the master branch.
Recently I've realized that when my coworkers ask me to review their work I hesitate. *_deep breath_* I hestitate because I don't know what to do. *_exhale_* I don't know what to look for in order to spot possible problems in their code. I don't know what questions to ask. I mean, I can look for semantic errors, but what about bigger problems? When do I tell them confidently that their work is good enough to ship? And bigger than that, how can I give constructive feedback to someone who is pushing me to approve their work because they are on a deadline?
I totally believe in the power of testing. Someone once told me when I was just learning how to code that tests would be the savior for my anxiety about the code that I write. And how I have learned that that is the truth. However, that assumes that you know how to write tests. This skill has been one of the harder things for me to learn as a developer. People speak lots of important talk about TDD and BDD and the importance of tests. As if writing tests just comes naturally. I think it's a skill just like writing good Ruby code. In reality there are good tests and bad tests. So, how does one write good tests? What's the best/easiest way to start writing tests for a piece of code? What should I test exactly (I would bet that no one writes 100% test coverage, nor should they)? And I had bigger questions once I stepped into a legacy code base with a large-ish test suite. How do I judge tests just by looking at them? How can I tell the test coverage? How can figure out areas that need tests?
I found it really helpful to figure out what I don't know. It gives me very clear guidelines for areas I need to improve in. And because I've formalized my questions I can sit with more experienced engineers and ask them for help or guidance. I then can share with others what I've learned. Hell, learning the skills needed to be a web developer is a moving target and honestly I feel like it's one of the joys of the job. So, here's to new neural pathways!