Code Quality Q&A and Videos

Balancing these two approaches is crucial depending on the project and our own values.
1. Writing completely messy code that just works. In other words, making spaghetti
2. During a development, focusing on future scaling, readability, and cleanness by spending more time on the code.

Managers often prefer quick development that works from client’s perspective, which aligns more with the first approach. It’s really difficult thing to tolerate for me, as I don’t consider it to be good programming, even if the clients are happy.

Despite client satisfaction, I feel an ethical conflict.

Should I refuse these types of projects and their financial benefits, even though my stomach is empty? 🤣

Hi I have been watching on the taro courses.

I wanted ask is there a template that one can follow while writing test plan and how to map it for code reviews ?

Any example that can be shared to understand?

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 am thinking about finding a position at another company. But I am concerned about how to find something suitable. I am considering moving because I would like to work and learn at a company that practices better code quality: better separations of concerns, better testing. I've learned recently that code quality corresponds closely not only to speed of development, developer happiness, but, also stress. I don't know though how I would know about code quality from the interview process. I can imagine maybe asking multiple engineers from the company what they think during the interview process. Maybe ask engineers that I've worked with before from the company. Also, some companies may be reputable like Google. Or maybe some famous engineers work there like ThoughtWorks.

I am currently a Staff Engineer at a company, and I've worked for almost 6 years there. I've also been promoted at the company. I think there are factors that are important for me that keep me there. A flexible vacation policy that is actually flexible as I've usually taken about 5 weeks off a year, commitment to remote work, flexibility to set time off during workdays. On the other hand, even though I am one of the top committers to our code repository, I am not sure if I am getting credit for that here.

One thing that worked really well was that I started at this company when engineering was around 30-40 people. That meant work time was stable unlike an early startup, but the company was at an early enough stage that I really got to know a large portion of the code base, over multiple functional areas, before the code base kept growing and new teams were formed.

Regarding programming language / framework, I would prefer Scala. I also would like to learn ZIO. But I think that's secondary to the factor regarding code quality.

Could you give me advice as to how to search for jobs given the different factors that I've listed?

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.

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.

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?