Slow coder

I wonder how you entered in Google , and who the hiring teams were when you yourself admit of no/slow coding skills.

Maybe C++ is slowing you down.

OP, have you experienced similar struggles with other type of work, or is it coding particularly? At Google, it's not uncommon for many developers to struggle this way, due to a combination of factors. Have you tried to seek help within your team yet?

Coding is frustrating for everyone, often. Get fluent with your editor of choice. Use tmux, especially to help keep alive remote sessions. Use grep a lot. Increase the amount of information you can see/compare at once (play with smaller terminal font, get a bigger monitor or several). Get comfortable with gdb. If you’re working on multiple PRs at once, clone a different copy of the repo per PR, so if you kick off a long build in one clone, you can work on a different PR in another. No idea how hard it is to grind for L5 at G so i cant say if sunk cost is worth continuing.

Keep coding without comparing yourself with others , comparing will slow you down in anything you do, being PM has also its own challenges.

You need to manage your time more effectively as an IC before you can become a GOOD manager since by then you will manage people. I used to get suck in 1 direction when debugging as well. Learn your tools and cut your loss early. Don’t just scroll through your phone or YouTube. Your switching and loss of focus makes the debugging process longer as you will have to get back into it.

If your heart isn't in software, then don't force yourself. But if you want to keep trying, then my suggestion is to become good at reading code critically. Once you do that, you can easily become good at writing code as well, because you will have a much clearer idea about how the system works (and doesn't work) and where you need to make changes for a particular feature/issue. To become good at reading code critically, you need to develop a product-focused and customer-focused mindset. Instead of trying to understand how a unit of code works, try to understand how a single small feature works end to end. Start from the UX. (The UX may not always be some html page, and sometimes it is, say, the database if your user is a business analyst. So make sure you identify the appropriate UX for your use case.) Then, only trace the code, service calls, database updates, etc. that are directly relevant to the "happy" case (no edge cases/failure cases). Do not get distracted by error handling or code related to other use cases. Focus on understanding how the various services, data stores, and apis are connected. Then understand how the various packages and classed within those services are structured, and how they interact. Also think about what may be a better way to structure these components to achieve the use case you're thinking of - this will either help you improve your architecture skills if your improvements are feasible, or help you more explicitly understand system limitations if not. Once you understand the end to end flow of one feature, then either think about a different but related feature, or edge cases for the feature you just traced. Imagine where in the system flow you would make changes if you were the one implementing them. Then, look at the actual code in those places, and see if the changes you expected are in the places you expected. Even if you are right, the next step is to trace that adjacent feature end to end and then catalog what pieces or edge cases you missed in your initial assessment. Do this as many times as you need to feel comfortable with your ability to reason about where you'd need to make changes for a new feature. Do not try to understand every feature or every part of the codebase, because you will forget most of it, plus things change quickly. The objective is just to establish enough context that you feel confident about reasoning about the codebase. Once you have done this, you will be able to code much faster, because you don't have to do as much research every time, and your understanding of established system patterns means you don't have to reinvent them for each new feature. If you need help with which feature you should start with for the trace-through, I would recommend asking yourself, "If this product was a startup product, what would be the MVP that addresses our target users' most critical problem?" And then, whatever use case that is, trace it through the system. That usually will give you the most comprehensive understanding of your codebase. I hope this was helpful.

From my experience, I read a lot of the user manual for my IDE. Not only is it a nod towards the devs, it also made my workflow much better as I knew a lot of the little details that made things easier and faster

TC ? Tc will give you shanti