Lately I've been feeling like I don't really understand what I do. I can write code and get tasks done, but I don't feel like I could explain what I'm doing or like I understand the new things I've been exposed to enough to be able to execute on that knowledge. But this week I got a few reminders that I do understand more than I think and I'm selling myself short by saying that I don't.
While discussing my struggle to understand what I do with my manager, I mentioned that one of the topics I'm less comfortable with is redux, which we use in our codebase. She gave me an "assignment" to be able to give a high-level explanation of redux at our next meeting. As I was studying up on redux, it all started to sound familiar, and I realized that while I'm far from an expert on redux, I can explain what it is.
Redux is a state management tool that allows you to manage state at an application level. The "single source of truth" in redux is called the store, and that contains the current state. A component subscribes to the store, and that is where it gets state information. Actions are used to change the state. An action is dispatched (or sent) to the store, and based on the type of that action (and sometimes the payload it contains), the store will return a different state. A component that is subscribed to the store will then receive the new state and update as necessary.
None of this was new information to me, and I'm guessing that most people who have worked with redux already knew a lot of what I wrote in the previous paragraph, but just being able to articulate it and write it out in my own words helped me reinforce the fact that I do know what I'm doing and I'm not just stumbling through things blindly.
Another topic about which I've doubted my knowledge is React. I'm comfortable writing React, but I've never been confident in my ability to explain how it works or answer questions about React (which made job interviews super fun). This week I had an opportunity to pair with one of our backend engineers (who had no React experience) on a React task, and I found myself able to answer most of his questions. In fact, the more questions he asked (and he asked some really great questions that showed a deep desire to understand the code we were writing), the more certain I felt in my answers and explanations.
I even feel like I'm starting to learn more about topics and libraries that were new to me when I started this job. The project I'm working on uses state machines (with the xstate library), a topic with which I had no experience 6 months ago. This week I had to make some changes to one of our state machines, and I was very nervous. I had never made significant changes to the state machine on my own, and as I was working on my changes, all I could think was "I hope I don't break this."
By working in small chunks and fixing the errors caused by each change, I was able to get everything done. With the changes I made, I learned more about actions, guards, and state transitions. I had to create a new action and a new guard, and add those to our state machine. I enjoyed the opportunity to work with something new, but since I wasn't as familiar with the work, I was sure I had done something wrong. When I submitted the PR, I was hoping that any mistakes I made would be corrected, but it turns out I didn't make any mistakes (or at least none that my PR reviewer, who had originally set up that state machine, noticed), and the only comment on that part of the PR was about a possible optimization to make future work a little cleaner.
I still have a long way to go before I feel fully confident in my knowledge. I still hesitate when I try to explain things, and if you ask me if I think I fully understand the tools I work with, my answer will likely be no. But that's okay. I don't need to fully understand things right now. As long as I understand enough to solve problems as they come up (and hopefully be able to explain those solutions), I'm in a good place. Total comprehension can come later.