Code Quality Q&A and Videos

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.

I've looked through the code quality course but for the purpose of an interview can I get a checklist of things that the interviewer will be looking for in terms of code quality?

For reference I'm a junior SWE and I plan to use Python.

How do I become a better coder? I get shit scared while coding, especially while in an interview.

I recently had three coding interviews and I withdrew myself from consideration because I froze during these coding rounds and couldn’t code a single thing. Always feeling I am not up to the mark.

My current role doesn’t require too much in depth coding, but I want to get back into it and be confident of my coding skills. How can I go through with it?

A strong theme on Taro is that good testing distinguishes a good engineer from a great one. Thinking of good test cases is not trivial, and I would like to know how the great engineers at Taro approach testing.

For example, my company is working on a program (program B, say) that picks up and validates payment requests from program A and sends them to program C, which issues payments, after which program B notifies program A that payment has been issued. I have been put in charge of thinking of test cases, with the biggest concern being duplicate payment issuing.

I have only been able to think of 8 test cases that may actually occur in the program. I have been asked to think of 20-30, and I'm finding it quite difficult to do so. I've only written test cases that can occur assuming the program works as expected, i.e. in which the user does something unexpected. For example, at a certain point program B reads data from a file into the database and moves that file into a directory called "archive". I could hypothetically write test cases for the program's behaviour when the file did not successfully move to "archive", but intuitively this seems trivial.

I believe I probably am thinking about testing in the wrong way / have insufficient knowledge of testing theory. I approached it by starting with what Alex calls the "happy flow", the way the user is supposed to use the program. I then thought of multiple ways the user could mess up when using the program. My next strategy is to go through the code and see what could go wrong (a sort of "white-box" approach), but this is low-level and time-intensive, so I wanted to ensure that it is a good testing strategy. Most testing I've seen thus far has been "black box", i.e. ignore the code and just play around with different user actions.

As always, the advice is very appreciated!

I am a mid-level engineer at an HFT company. I've been with my current company for around 7 months and another similar one for 2.5 years previously. My biggest career issue so far has been poor attention to detail, which leads to me to always miss small mistakes I make.

For instance, I always review my own PRs myself before sending to reviewers, and clean up plenty of issues I notice myself. But then my reviewer will point out some kind of bug, or something I forgot to do, and in retrospect it will be immediately obvious to me. Alex often mentions the importance of being able to get most of your PRs accepted in one attempt, but for anything > 30 lines this simply feels like a pipe dream because I am so terrible at noticing things until it's too late.

(For the record, I'm very thorough with test coverage, but when I simply forget to implement something, I of course forget to test it too).

Another more specific example is that our process of verifying features in production is sometimes a bit involved, and requires changing config in several places. I knew what to change, did so and tested everything, then told my manager the feature had been verified. Later on he was looking at the configs (not sure whether he did it to check my work or for some unrelated reason) and pointed out that I did not actually set everything as I intended to, and therefore the feature wasn't verified correctly. I realized mistake I made (ran a command to change a bunch of files in the wrong directory) but only after the fact, and it cost me embarrassment and extra work.

I think I'm quite good at the other aspects of software engineering: coming up with impactful ideas and executing on them independently, picking up domain knowledge and areas of the codebase quickly, fixing bugs (my own or others'), presenting on my work, etc. So I've been able to eke out "meets" and even "exceeds" reviews at my first job because I had significant impact despite blundering all over the place.

But my deficiencies in this area make me fearful for my career, as I am always worried about making just enough mistakes to get PIP'd or fired. Furthermore, we don't have levels here, but I doubt I can make it to the equivalent of Staff or even the senior level with this kind of defect.

Does anyone have advice on how I can "train my brain", as it were, to improve at this ASAP and make sure I don't go down the wrong trajectory? Thanks!

Hello everyone,

I joined Meta a couple of months ago as an IC5, coming from a predominantly Java background. Recently, I've started working with the PHP codebase, which is somewhat new to me. I've noticed that my diffs tend to undergo several rounds of revisions, which not only delays their integration but also consumes more engineering time than I'd like.

A fellow engineer pointed out that my diffs are often too lengthy, leading to extensive feedback and additional iterations. I'm actively looking for ways to streamline my review process and improve the quality of my submissions.

Here’s what I’m considering to reduce the review cycles and improve my coding approach:

1. Reducing the Size of Diffs
2. Pre-Review Checks: -- Any suggestions here would be great

I would greatly appreciate any advice on:

• Strategies or tools that could help in catching potential issues early.
• Best practices for structuring PHP code and managing larger changes in a PHP environment.
• Any insights on transitioning from Java to PHP, particularly with regard to common pitfalls or key differences I should be aware of.

Thanks in advance for your help! I'm eager to learn from your experiences and improve my contributions to our projects.

When evaluating folks for promotion or in general developer experience in terms of measuring productivity of an engineer (junior, mid-level all the way up to tech lead), how is this measured when building any one particular project for 3 months?

I see Alex talk a lot about # of commits when evaluating the work of a code machine and watched the course he had on code quality, but can we give a more concrete example of what would be considered a single commit in a day/week that is substantial enough to satisfy at as such for a responsive web app, or a native (Android/iOS) app on any particular project?

I am thinking of scope since a lot of the time I can build a prototype from scratch - everything sans deploying fully into production (for an AI project or some other responsive web / native iOS app) within two days (think hackathon style) but not completely sloppy or super polished, but something working/basic functionality (and that has a number of commits), but I think I'm having trouble grasping what number of commits on any particular stack is considered substantial in a single day/week and expectation wise per month or quarter on a intermediate vs. long-term project for two quarters or a year? I think I lack clarity and wonder if I will be as performative or hyper-perform compared to my peers (like I can code fast and even without using a CoPilot, but I wonder about code quality and depth rather than simply throwing something together or fluff commits - a bunch of installfest does not count, obviously).

I complained to my skip manager about my colleague's (their manager) code review standards, but ultimately discovered deficiencies in the quality of my own pull requests. As a result, I believe I have lost credibility. How can I regain trust and credibility in this situation?

I just watched Alex’s ”Level Up Your Code As A Software Engineer“ course. I wanted to ask about the first portion of the “Better Code Strategy” module.

A part that resonated with me is where Alex said he sees many junior devs fall into a trap of full stack when trying to specialize, which hinders them in the long run. It makes total sense that people would rather hire a 9/10 on front end than a 5/10 at front and back. I was in this situation at my previous employer - new grad role with a 4 month ramp up program. I didn't do so well on front end in training, and was told that I’d be placed in a back end role, so it “wouldn’t matter anyway”. Guess who got placed doing front end work? I had barely any support so I had to figure out everything myself. I was the only front end person on that team - the only other dev there was an L6 in back end. I also wasn’t good at communicating back then, so I was hindering the team a lot. 9 months later, I started handling front end. And right when I got good at handling front end tasks myself, I was told the architects wanted the apps my team was working on to make API calls to the backend rather than mid tier… so the team shifted focus to backend. I lost all my gains on backend by then, so that sucked. Another learning curve, within 2 months I gained independence. A week after I was told I was doing really well, I was laid off. Many people at the company outside of my team voiced that they put me in a "bad" position. I also point the finger at myself, because there was a lot that I needed to take accountability for.

Eventually, I got another job, doing database work. When I look at SQL, I see consistency in SQL and other coding languages. APIs, cloud, data, it all needs databases! To understand the world of code, it’s like everything draws back to databases. In my current role, as long as I pass the onboarding phase, then I can achieve excellence anywhere I go in my career with incredibly transferrable skills. Although I feel like I found where I’d like to dedicate time to specializing to get to the upper echelon of software engineering, I noticed I’m somebody who doesn’t mind what I do because I like everything I’ve seen so far. That’s why I figured to go for the niche that is “best” for all around career growth. With this in mind, what do you think the best fields to specialize in are?

What are some good books or online resources for learning how to write better code? I am looking for actual code examples demonstrating best practices for someone who already has programming experience but who wants to improve. Examples of topics I am looking to see covered would be whether a function should always include a return, when it makes sense to use try-catch instead of handling bad input with control flow, or when to use different approaches for handling invalid input.

I know that launching a product with bugs shows a reactive approach. Similarly, if a reviewer catches an issue you missed, that’s also reactive.

But what if you’re thorough in writing and testing your code locally, and you catch a missed dependency before even raising a PR? You fix it yourself without anyone else noticing. Does this reflect positively on you for solving it on your own, or does it still look bad because it was missed initially?

Taking it a step further, say you forget a simple null check, causing errors in your unit tests. You catch this yourself and fix it, but technically, you were still being reactive.

So, how do people realistically measure “reactive” vs. “proactive”? And how are scenarios viewed where you catch and resolve issues on your own while writing code?

I will be interning at Meta during this summer. After watching Alex's amazing video regarding Meta's internship, I learned that interns are expected to perform at the level of an E3 new grad by the end.

I want to make sure I am correctly understanding the key signals a junior/new grad software engineer should be demonstrating. From what I understand, I come up with the following:

• Coding velocity (code output)
• Coding quality
• Independence (can unblock oneself without too much reliance on mentor)
• Debugging
• Asking great questions
• Responds well to feedback
• Builds great relationships with team members
• Disambiguation

I'm sure there is more to be included, so please feel free to add anything I may have missed. I hope this list could be helpful to other interns/new grads who are seeking to improve their skills.

Assuming code first engineers care deeply about perfecting code while product engineers care deeply about shipping out solutions, how does one put up with an mentor that is a code first engineer to the extreme?

The one engineer on my team is known for being a code first engineer: the type that will ask every lesser ranking engineer for rewrites from every PR, takes a week to review small tickets, prefers to miss deadlines instead of pushing decent code to prod, and will not compromise on design decisions until months have gone by.

Sure, its great to learn from someone with top-notch code quality with past experience at google. I'm also confident my testing skills have improved a LOT since I started. On the other hand, having to rewrite most PRs I produce just to submit work late has destroyed my reputation as a junior engineer on my team. And for the majority of the time my team lead disagrees with this extreme code first mentality so I end up in the middle of arguments on the smallest design choices, waiting for a resolution before picking a solution.

How have you found balance between perfect code and shipping fast?

Code quality makes a lot of sense even on its own. Yet my company is early and a small team with no one specifically dedicated to software engineering. We used to have a software engineer, but they were not a good fit and they no longer work for the company. I have been tasked with code reviews. How can we incorporate documentation well from early stages with technical writing, and how does this best play into code quality?

Is your team using test automation? If so, what's your approach to automation, and what are the main challenges you face?

I'm especially curious about: What strategies has your team implemented to tackle your challenges and make test automation more effective?

Recently, I was helping migrate my team’s entire codebase from a legacy Java DateTime library to the newer, built-in Java DateTime library.

I’ve never performed a migration before, so I don’t have context to know whether this kind of migration is typical (my current team isn’t very good). 

Some of the features of the migration:

• The codebase primarily contains poorly written unit tests or tests without assertions (and no E2E or integration tests)

• Consequently, we tested the application by setting up a separate environment, simulating user flows, and manually verifying results inside the DB

• The migration took over a month to perform - meaning constant merge conflicts from new changes to resolve

What might a migration look like at a good tech company? 

In my company (early stage so there is not a formal code standard, this is also not yet production code it is R&D code) the ML code for preprocessing the data is a long list of function calls, ETL, pandas stuff to manipulate, clean, and process the raw data. Then there's obv a ton of other function calls for ML -- split data, remove missing vals, run it thru ML models and call test methods

This makes it hard to write clean code bc

1. There is very little code reuse to make stuff modular
2. In most SWE cases there are increasing layers of abstraction. But here there is no obvious way to abstract away stuff since most of it is a long list of sequential processing code

Things I'm doing

• Breaking into classes (1 for model, 1 for preprocess, 1 for tests, etc...). But even these are just becoming long functions or a python file with 20 functions
• Trying to make the scripts function based so that when I make a function call it is clear what this function is supposed to do