Debugging Q&A and Videos

Every time, when my manager asked me to do some changes to the repository that is totally new to me. I became scared.

I prefer to do research by myself first. But I got lost in the new repo by reading file by file, and don't get the clarity.

So I ask the repository owner to provide documentation, mostly they don't maintain documentation, and even if they do, it is not updated or it involves a lot of detailed feature-wise documentation, which is usually not relevant to my requirement.

Then, I call the POC of that repo, but I couldn't figure out what is the right question to ask in the first call. Over time, I ping him asking questions whenever I face hurdles while achieving the requirements.

Sometimes, I put a debugger or logs to understand the flow of code.

The above processes took a lot of my time.

What is your suggestion to get clarity in the new repo such that I can complete my requirements in less time?

I get a lot of JIRA tickets for bugs where it's not clear what the fix should be. How can I find the problem area and relevant code faster with these issues?

I work in as an iOS engineer. My current company is a startup that's scaling up fast. In classic startup fashion, testing was historically not a top priority here. As a consequence, we struggle with lots of manual QAing and low code confidence when modifying pieces of poorly tested legacy code.

This has improved in the past year simply by unit testing every new piece of code by default and by introducing unit tests in legacy code as we touch it, boy scouting style.

At this point, I think we need to step it up and I'm looking forward to formalising a testing strategy for our mobile team.

Here are some ideas I have:

• In the realm of unit tests:
  • I want to introduce API contract tests because our back-end API lacks documentation. In these tests we'd unit test the way we build our requests to API endpoints, and we'd have a sample JSON response from the server to test that the app can parse it into our data models as expected.
  • I want to introduce localisation tests because our app supports many languages but we are always manually testing localisation. In these tests, we'd assert that the outputs of our formatting logic are the ones we want for different locales.
• In the realm of user interface tests:
  • I want to introduce snapshot testing, because right now the only way we can test that our views are rendered as expected for different view configurations (for example RTL vs LTR, empty content, loading content, content in verbose languages, etc.) is manually.
  • I want to introduce UI tests (sparingly, only for key flows) because we have no e2e tests. Currently, key flows are tested manually and frequently to prevent regressions, which takes lots of time.

What other testing strategies can I propose to establish some standard we can use to further improve our code confidence, reduce bugs, and rely more on automated testing?

How do the top tier tech companies approach mobile testing?

In particular, I'm having trouble figuring out really complex bugs. For example, on my current project, we're auditing a lot of the existing feature set to see what issues they have so we can fix them as we revamp them. I'm happy to find lots of issues, but I have no idea how to fix them, even after finding a code pointer.

I talked with a senior engineer on my team for help, and they were able to get more color on the situation. However, they mainly were able to do this as they have been in the org for a while and knew who to go to for what: I can't replicate that deep knowledge they have as I'm fairly new to the company. How can I create a systemic process I can follow to figure out these situations?

I recently made a string of silly mistakes related to a particular project that led to a few bugs being deployed to production. I think I incrementally got more and more overwhelmed and stressed by the project because my initial fix caused a bug and from there I fixed that bug and inadvertently caused others.

I'm concerned about how this might play out with my EM. How I can best approach owning this set of silly mistakes without it having a negative impact on my reputation due to my low code quality mistakes partly caused by the stress of the situation?

My tech lead asked me to write up a mini bug report for our our engineering retro and this morning my EM was asking about what the report was for because I had written it down as part of my weekly goals in our stand ups. My EM has low context on the complexity of the work we do and is far from the code - tending to over index on any signal he come across.

I just went through my performance review and I'm meeting expectations so I don't have a formal review for a while. I'm about to go on vacation for a while so I'm hoping this fades into the past but still I'm not sure exactly how to play this now so it comes out in my favour before I go away.

I'm on-call this week and I'm met once again with a strong sense of not having a clue what I'm doing. I know the majority of the job of engineering is trying to work within a legacy system but I feel like I'm missing tactics to help me make any progress at all. That and having to switch contexts to address alarms and queries has meant that I actually made no progress today whatsoever so this is part rant and part question - any tips on confronting a wall of overwhelm and making progress towards the most impactful bugs?

I have just joined a new team, and have my first coding task. I am currently terrified about taking the first step and writing some code and testing it.

I have spent a lot of time researching solutions, but have found myself bit in the past because of a lack of testing and research, and also am just terrified of breaking things.

What are some suggestions for getting over this fear, and how can I be more confident that the testing and implementation cover all edge cases and won't have bugs?

I was assigned a P1 bug, and when I started to dig deeper into it, I found out that actual code was written by some other team and we have just used that code/object to build a small feature. I got a bit lucky that someone in my team told that the team ‘A’ owns that code/object. I was given a POC, but it turns out that they have left that team. I would like to have a POC to close out this bug.

For additional context: It is still not clear if it's the feature or the bug that's broken, that’s why we need to get clarification from the other team. Here's a high-level example to make things more clear: There is an object named "Product" which is a generic one, team ‘A’ built another object called "Product Category", and we added a field to that object. Now unless I ask some senior folks in my team it is really hard to understand who owns "Product Category".

Given all these unknowns, how can I navigate this situation and make sure this bug is resolved properly?

On most projects that I worked it was enough to have a high-level of how the higher picture of the code works and for the most tasks it was enough to copy paste and adapt existing code and for debugging it was also enough to have grasp the high level image.

However, I worked only on maintenance projects, that weren't very innovative. In order to have the chance to work on a good project how well should I know the tech stack?

For example for the stack: java/spring/elasticsearch/kafka/AWS, should I know the newest annotations or how the framework works under the hood, and probably be able to extend the framework, how to debug machine on VM etc?

Is there any sort of metric with respect to how in depth you should know your tech stack? Because in order to write code in a tech stack you don't need a lot of time to learn if you know the basics, but to write state of the art code I feel like you need years.

I'm working on myself to perform like a senior software engineer at a FAANG company, and by doing your courses and following you on youtube, I understand that being a good at debugging is one of the greatest qualities.

But I am facing couple of problems.

• I work in a project where the technical debt is huge, the documentation is complicated (sometimes in code, sometimes on google drive, sometimes in the form of an algorithm written in French by a non-technical person).
• Only people who have been working with code for 3 years or more seem independent (And they only have time for themselves), thus, many of us sometimes feel lost.
• A lot of money has already been invested and it is in production. So no time to rewrite the services, where more than 100 people contributed.

Do you have any advice or steps to deal with this type of problem? I know that among the FAANG there is a 0% chance of having this case, but still, any advice will mean a lot to me.

A year back I joined a Big Tech company as a mid-level software engineer. I had 5 years of work experience mostly in not-so-famous startups and I joined a large tech company after doing my masters.

It's been a year since I joined but I regularly feel like I don't belong here. I go through alternating waves of confidence and self-doubt. When I am not able to debug simple issues in a new microservice, I feel dumb. I feel like the senior devs on my team are just able to solve everything and I am still struggling after a year. I have been through a round of layoffs and re-org and am not sure about the kind of work I will be doing in the future.

I want to be promoted to senior engineer level but constantly get feedback that I am not assertive, opinionated, and take more time than usual to complete ambiguous tasks. I see everyone getting promoted around me and I don't understand why I can't seem to be improving. I am very motivated and willing to slog hard, but it seems like I simply don't get it or am not smart enough. Everyone around me just feels smarter and more experienced.

I feel like moving to a smaller company with not-so-high coding standards and ditching big tech because it will be more up my forte. I am aware that I won't grow there. It just feels frustrating to be stuck at a junior-mid level, 7 years after my bachelor's. But I also know I am not at that level yet.

Any advice on how to go through this problem to the other side will be lovely.