Debugging

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.

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?

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'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?

As part of my story or task, often times I have to understand and contribute to other codebases or solve bugs that involve understanding flow of other codebases. What is the best way to navigate this when you are suppose to solve an issue where you have to understand an external codebase in order to contribute or fix an issue?

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?

A little context: I joined my company back in Jan and have been doing really well. I’ve been consistently pushing code, owning projects, and creating good relationships with my colleagues.

This week I’ve been really sick and it feels like nothing is going right. I have been running an experiment for a couple months and today I found out that one of the arms is bugged because I introduced it a while ago. After a scrambled meeting with my lead and manager, I addressed the bug and pushed a fix but because of freezes my bug fix won’t actually be in til after year end. My manager stated that they wouldn’t have expect an engineer to not notice a bug like this go on for so long.

The business side is actually not even interested in the bugged arm and would like to go with an approach I proposed earlier in the project.

I’ve learned a lot since I pushed the bugged change and my code and communication has improved but my managers comment plus all the news about layoffs and perfs and PIPs has had my anxiety through the roof the past few weeks. Anyone else feeling the same?

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 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?

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 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?

How can I unblock engineers on the team without getting into the weeds and debugging the issue myself or pair programming with them?

Right now, I create work tickets and add context so engineers can easily pick them up. Engineers will then come to me with technical problems as they get blocked on these tickets, which requires a lot of time from me.