Discussion on: Some things I learnt from working on big frontend codebases

[Omri Lavi]

Amazing article, thank you! I plan to read most of the linked contents very soon.
I have a question - what do you do when your opinions about tests (or readable code) are different than your team's opinions? For example, if you find yourself working with a team that doesn't find the value of tests.
Thanks again :)

[Stefano Magni]

what do you do when your opinions about tests (or readable code) are different than your team's opinions?

That's a great question 😊

I never dealt with such a situation for a long time. Time makes the difference here, because when we speak about the short term, hoenstly there is no differences. If we speak about the medium and long term, instead, tests and code readabilty make a huge differrence.

Anyway, the approach is alwayus the same: I focus on the most important parts to improve (for instance, in a distributed company with a lot of devs, tests are more important than readability of the code itself. TypeScript Discriminated Unions are more important than code indentation, etc. especially if you consider the advent of Copilot etc.) and:

1. I act as a model: most people do not have strong opinions, and when they see "the quality" of how more seasoned devs work they tend to emulate.
2. I propose things: I get in touch with the authors of the code, I propose improvements, I jump in a sync call to discuss them, I listen to the proposals of the other ones, and also I show/demostrated what is the added value of my approaches.
3. I do some refactors all my own and I jump in a call to discuss it with the author. Please note that, in this case, it's important to let original code as is, even if it leaves room for improvements and even if I refactored it. From the authors' perspective, you are respecting their work if you do not change it. The next time, there is a chance they will follow your suggestions because they know you respect them.
4. I keep track of real-life examples that show that I'm right, and I keep them in a separate txt of mine. Then, when needed, I can recall them and point people there. It's hard to deny the evidence 😊

All the above means accepting that 90% of your suggestions (especially if you are a nitpicker) will not be considered at all... But the remaining 10%, the most important ones, maybe yes. And it's a great exercise for me too! Because as a perfectionist, I need to always learn more and more that not everything have the same importance.

What do you think? Do you have different direct experiences? 😊

[Omri Lavi]

Thank you for the detailed reply!

in a distributed company with a lot of devs, tests are more important than readability of the code itself

I never thought about it, but I totally agree. On larger companies, each team usually owns its own codebase. They usually know who to approach when needing clarifications about the code. What they usually don't know is which part will break when something changes - that's where the importance of tests really shines.

I really like the 90%-10% approach, it makes a lot of sense to me. In some way, it can be parallelized to an important skill of a good developer: understanding what's important, and compromising where needed (e.g. on a quality vs. speed consideration).

I also think of myself as a perfectionist, but I try taking a pragmatic approach. Usually when I review a PR, I tend to be very pedant, and leave comments about "smaller" things as well. However, I make sure to emphasize what's important and what's not, and on the summary note I explicitly say what needs to change to get an approval from my end. I make sure not to become a burden, otherwise people will avoid approaching me.
When taking part on "live" sessions (e.g. design reviews), I try being more "nice", considering what's really important to me, and start by raising only these issues. In some ways, it's a bit harder than doing it "offline", since you need to analyze the details quickly. On the other hand, since it's usually face-to-face, people tend to be more receptive to the feedback.

What's your experience on this regard?

P.S.
I really like the content you write, both the subjects and the style. Keep up the amazing work!

[Stefano Magni]

Sorry for the delay, I was on vacation 😊

I really like the 90%-10% approach, it makes a lot of sense to me. In some way, it can be parallelized to an important skill of a good developer: understanding what's important, and compromising where needed (e.g. on a quality vs. speed consideration).

Could you tell me how you all use it in your company? 😊

However, I make sure to emphasize what's important and what's not, and on the summary note I explicitly say what needs to change to get an approval from my end.

That's an interesting approach I did not think about. Here, I always use Conventional Comment to express the importance of every single comment (since most of them are nitpicks).

When taking part on "live" sessions (e.g. design reviews), I try being more "nice", considering what's really important to me, and start by raising only these issues.

I do the same 😊

In some ways, it's a bit harder than doing it "offline", since you need to analyze the details quickly.

I have the same problem, usually my mind needs a bit more time to analyze things and lot of times I get back to the other dev later in the next hour with more thoughts 😊

On the other hand, since it's usually face-to-face, people tend to be more receptive to the feedback.

Also: it requires less time to convince people face by face than async IMO 😊

I really like the content you write, both the subjects and the style. Keep up the amazing work!

Thank you so much, it means a lot to me 🤗

[Omri Lavi]

Hey Stefano, Thank you for the reply! I hope you had a good vacation 😊

Could you tell me how you all use it in your company?

I'm not sure if it's used by everyone in the company. Personally I keep a mindset similar to what you described: I understand people have a lot on their plates, and not all my suggestions can be applied. Since I understand that 90% of my suggestions may not be implemented, I try hard to find the 10% that are crucial, and should not be ignored (as I see it). It's a matter of prioritization and compromisation 😊

... I always use Conventional Comment ...

Wow, that's a great convention, I never heard of it! I think that using this depends heavily on the company's culture and size. In a smaller company, I believe it's easier to get a broader agreement about such convention. In a medium or large company, with different groups and sites, it's very likely that not everyone will agree about the benefits of such convention. This may add friction in a worse way than PR comments with no convention 😆
I wonder how larger companies integrate with such conventions in a way that is accepted by most of the workers... Do you happen to know about such processes?

... lot of times I get back to the other dev later in the next hour with more thoughts

I need to start doing this more 😆 I find myself many times trying to provide a solution quickly, just so I won't have to deal with another thing on my plate. (And perhaps since I want to be seen as "the guy with the answers" 😋). I should follow you as example more often, and take the time offline to think of an answer.

[Stefano Magni]

I wonder how larger companies integrate with such conventions in a way that is accepted by most of the workers... Do you happen to know about such processes?

I could tell you that in my experience, it simply happened organically. Who leaves 0/1 comments do not use it. Who leaves a lot of comments start using it when they see you using it. I think it's the best approach instead ot pushing it to everyone 😊

I should follow you as example more often, and take the time offline to think of an answer.

FYI: this takes time, obviously 😊 and I need to balance when to do it and when not otherwise it could ruin my days in a while 😊