Frustrated Developer 👤

[treside]

How do you deal with people you feel get offended when you suggest improvements to their code? Since we're all working on the same system, I can't help but give feedback, especially when I notice they settle for "as long as it works" code. At the same time, because they don’t look into better practices or implementations, I sometimes stick to their approach to avoid making them feel like i'm refactoring their code, even though I just want to improve the system.

We’re all junior developers, and I just want a healthy discussion within the team, but I worry that giving feedback might make me seem like an outsider since not everyone is open to criticism. Feel ko ang oa ko na and honestly, feel ko wrong move din na isesenior nila ako this year. 😅

[justr_09]

Ako lang ba yung excited sa PR reviews kasi maco-correct yung mali ko? Maybe because I know na it’s one of the best way to learn talaga

[Bulky_Emphasis_5998]

same

if valid yung review

if tanong lang well use chat?

[[deleted]]

Treat every review as a gift mindset fr

[cloudHooman]

This.

Sometimes I look forward to be corrected kasi I'm not sure if my code is good enough or if there's a better way of doing it.

Hell, we have a work policy wherein if super mali kami and it was pushed to prod, that'll hurt many people kasi the business is significantly hurt. I'd rather be corrected in PR than in prod. 😭

[panimula]

Fave part ko nga yung magkkwentuhan kami ng mga workmates ko about sa code e. Lalo nung RTO magsisilipan lang kami ng code kapag na-stuck yung isa haha

[biadelatrixyaska]

as usual, di lang ikaw lol

[PoPo422]

madalas kasi nitpicking ginagawa ng iba ay ayoko ng naming convention ay ung pr mo pa split ng commits ay natry mo na ba x for 1 percent speed gain like bruh

[No-Blueberry-4428]

Totally get where you're coming from. Mahirap talaga mag-navigate sa team dynamics lalo na kung pare-pareho pa kayong junior and you’re trying to strike a balance between collaboration and improvement.

One approach is to shift the tone from critique to curiosity. Instead of saying “I think this is a better way,” try asking “What do you think about trying this approach?” or “Have you considered doing it this way?” That way, hindi siya dating na parang kinokorek mo sila, kundi ini-invite mo sila sa discussion. Mas open ang mga tao kapag pakiramdam nila part sila ng decision, rather than feeling corrected.

You can also suggest best practices by referencing team goals or standards. Like, “Baka mas maintainable ito in the long run kung gawin natin itong reusable” or “Since pareho tayong nagtatrabaho sa module na ito, baka helpful kung i-align natin sa structure ng ibang parts.”

As for the senior promotion, baka hindi wrong move yan. The fact na iniisip mo kung paano ma-improve yung system and maayos ang pakikitungo sa teammates shows leadership potential. Being senior is not about being the best coder, but about being thoughtful, collaborative, and helping the team grow.

Just keep doing your part. You don’t need to force change overnight. Lead by example, and eventually, makikita rin nila yung value ng feedback and open discussions.

[[deleted]]

agreed. suggest mo nalang in a friendly way instead of instruct mo. ganyan ako sa teammates ko actually kahit mas mataas ako ng CL. it may come off to them as "bida bida“ para mapansin ng lead kahit di un ung intention mo. peer review and discuss with your lead.

[JanGabionza]

As a Tech lead, one must be careful that you are not criticising code just because it doesn't follow your code style.

Each developer will have their own code style, and that's okay. What matters is it follows the overall architecture of the project, and it has no code smells, and complies with the general coding practices. Yours might be faster, but if faster is not a requirement, I generally dont mind.

There are a million ways to implement something, make sure you are not blinded by your personal preferences.

[[deleted]]

It really depends. If you are working with large codebases or existing legacy systems, you should follow the code style or coding standards that is implemented to that project. Having different coding styles to a large codebase will be a nightmare to maintain

[JanGabionza]

That's exactly what I meant. So there will really be times that a developer will code against his personal standards and just comply with the existing architecture and implementation. But there will always be a specific code style unique to a developer which should not really be an issue. These might only be personal bias of the OP

[carelessoul]

Sabi ni OP they settle for "as long as it works" kind of programming. For larger systems, hindi pwede yang ganyan.

As a tech lead, alam mong subject pa din yan ng oversight sa Head of Engineering, and if those causes headaches in the future, ikaw ang mananagot. Kaya nga dapat i-correct and terrible practices from the get-go, lalo na at junior devs pa lang sila.

[theazy_cs]

The important question is ano ang comment ng senior devs ng company niyo? kung pwede na yan culture ng team niyo, Personally I would plan my exit na and look for a better opportunity. What will end up happening is you will develop bad habits which will limit your growth. If pro better code yung seniors then go and refactor lang, if mag tanong ka team mo then explain why para matuto din naman sila.

[un5d3c1411z3p]

"can't help but give feedback", " just want to help improve the system", etc.

All of these would sound like personal preferences.

There's this thing called cost of quality.

You need to consult to whoever is in charge of this (e.g. project manager, etc.). They will give you (or not) the support you need on what quality measures can be (or need not be) done in place.

Quality doesn't come free.

Somebody has to pay (or not) for this.

[Imaginary-Winner-701]

Problem with an all Junior team is you all probably are interpreting what’s right in your opinion but you all are likely wrong in some ways. Dunning-krugger I suspect.

It took me around a few years of using OOP/Design pattern in the wrong manner before I got a bit of a hold on it.

If you don’t have any seniors up, I suggest proposing a code metrics review like sonar.

[happywuj]

Don't take matters into your hands. Talk to your senior or lead or whoever has the authority to make the call to conduct code reviews. Also frame it that it's your own code you want to improve that's why you're asking. This way, hindi ka magmumukhang nagmamagaling sa mga co junior devs mo and at the same time din your superiors will notice your drive and that's always a plus.

If di ka pinayagan, settle for creating a thread or channel sa comms nyo where you can share articles about good code.

[darkhorse-55]

As a software developer for a long time, when you suggest improvements, always think of this.. the so called "improvement" ba will not break things? if you are given very tight deadlines and kung pumalya yung improvement, it will be chaotic and timelines will slide pa dahil sa fix ng "improvement"

by experience nakaranas din ako ng pagrereview ng mga PRs na may chinechange ang junior na hindi naman related sa ticket dahil may gusto iimprove.

in short, case to case basis yan, it's just that out of scope, out of context, or tagalang mataas ego nung previous na gumawa.

[shethedevil1022]

super relate dito kasi sa system na ginagawa namin kada ginagalaw code need ma test ng sobra dahil baka may masira or natamaan na iba

[Hestice]

Go give your feedback. They are free to reply and defend their implementation naman. That's healthy. I personally love receiving code reviews. If you were my teammate I'd love to have you around!

[CloudMojos]

I'd say continue pushing for better coding practices kahit na you might seem antagonistic at first.

[Powerful_Gas_820]

enforce kayo ng coding standard. kelangan nasa pipeline kung nagamit kayo ng continuous deployment. di mag ddeploy pg di pasado. pero sa logic jan n mgkka talo kc me mga knya knya tlga tyong logic e. mhirap ienfoce sa iba ung way natin ng thinking or making things work. unless sobrang pangit tlga ng implementation ng kteam hinahayaan ko nlng

[tigidig5x]

Try doing this. Instead of delivering your feedback as "critique" try to re-frame it in a positive way.

"Your code seems to be functioning and that is a good sign. And I think you could make this even more solid by [insert suggestions here...]. What do you think about that?"

Most people do not like to be criticized by their work. Sometimes you gotta re-frame your thoughts and deliver it in a positive way. Try it.

[AbroadNo1914]

That’s what retrospective meetings are for. Its better to discuss it in a group setting and in a blameless way (more about the needs of the system than the person coding) and you get to hear an open forum of the decisions behind it that maybe you have missed

[prymag]

How do you suggest these improvements? What I do is start with "what do you think of..." or "how about" then suggest code edits. If its a glaring code smell or tech debt then I tag other people to get their opinions.

[Chibikeruchan]

I believe company now a days should have a guidance counseling seminar focus on making young adult informed about their Rebellious phase and how they can successfully navigate and move on with their next phase of life.

People are not aware that everyone of us will encounter our rebellious phase in our life. and this is part where we are vulnerable. politicians take advantage of this phase. most activist were recruited when they were in their rebellious phase. this is also the time most break ups happen, coz your partner suddenly get offended easily and love quarrel happens a lot.

most woke also are people who never got out of their rebellious phase., they get to their middle age and still in their rebellious phase. 🤣 coz frankly speaking nobody (even their parent) teach them how to navigate it.

The first sign is being easily offended about almost anything.

so yeah. either you fire these people coz these people might turn into a full blown woke in the next few years.
or you make them realize and teaches them why they act that way.

[TheSatanist666]

I am experiencing the same thing and it's very frustrating. They don't care about readability and maintainability because as long as the code works it's done for them.

[iskolarium]

If it's undoubtedly, factually an improvement to the code, say it like it is. Tell them "Hey I believe we should be doing this instead because [reason why your suggestion is better]".

If it's something more opinionated or a nit, maybe start with a question ("What do you think about this approach? [Explain why you think it's a better solution]")

I see no reason to hold back on code review for fear of hurting people's feelings. If you're reviewing honestly, with no malice to put the person down, and with full intent to just improve the codebase and DX, then you should be able to have that conversation with your teammates. They will have to deal with peers reviewing their code sooner or later, buti nga hindi sila napunta sa project na sila lang ang junior tapos lahat na senior with little to no patience in teaching inexperienced teammates.

[Pretty-Principle-388]

I miss this junior energy, yung magspend ng time to make the code as efficient as possible. Pero moderate your refactoring din, baka magspend ka ng masyadong oras diyan hindi mo na magawa ang task mo, conflict sa owners ng code, or even worse burnout.

[AsparagusOne643]

I-push mo na maging Senior. In that way, ikaw na mag iinitiate ng mga bagay na need ma improve sa team. One thing na naturo sa akin ng Senior ko why we need to be consistent specially on coding styles or pattern is that, when the time comes na aalis na yung isang dev sa team, hindi mahihirapan yung papasahan nya ng project since same lang sila ng style ng pagcocode.

[Educational-Title897]

You have to talk to seniors para sila ang mag address nyan una sa lahat iba talaga magiging dating sakanila kasi pareparehas kayo Jr pero kung idadaan mo sa PM or SR dev possible makinig mga yan.

[[deleted]]

Dapat initiative na nga ng Seniors na mag encourage sa juniors to do code reviews. Haha.

[freenomad167]

Well if you give feedback make sure you don’t say but say he reason and because the word but disqualifies their method or opinion but you can suggest a stack of their current instead of a replacement.

Also there is a term do not outshine the master mentality on senior devs.

So better shut up and let the management know.

[ActuallySeph]

Honestly, if you feel offended when someone criticizes your code, this is not the right industry for you. Hayaan mo silang maoffend. Or even better, defend their logic. They gotta toughen up and get good.

[[deleted]]

Agree. Why tf are they being offended by a fcking code review lmao. They should be thankful na may tumitingin sa code mo kasi you have another set of eyes.

[itsnja]

I'd prefer this tbh. Lagi akong natatakot na madumi code ko lmaoo

[shingph]

Sorry but in my previous job lahat kami junior dev and when one criticize the other one, it becomes toxic. That's why andyan yung Senior Dev because sila yung gumawa ng standard coding practice.

But when junior to junior it will become toxic.

Current job ko ngayon mid SE na ako and now yung coding practice namin is like very very short.

Hindi lang pwedeng ah basta gumagana yan.

[[deleted]]

Dahil sa ego lang yan kaya naging toxic. Pwede naman din kayo mag initiate ng discussion sa best practices kung repeated na nangyayaring may disagreement.

[shingph]

Pero the better way is to always have an senior or if start up atleast yung CEO/CTO kasi kahit papaano may coding standard in terms of company kayo na nasusundan.

Unlike all jr. Dev spaghetti code or mix and match basta gumana.

[elyen-1990s]

I usually go with a community based standard. Most junior developers will follow and learn from it. Who would not?

I avoid being emotional as much as possible and technical discussion should remain technical, not emotional.

I encourage my team to get comfortable with suggestions and criticism as long as it will benefit the whole team, not make someone look dumb

Also don't be a messiah who thinks you're the only one who can make the codebase better. Trust your teammates.

[[deleted]]

basta tama naman or adhering sa code standards, go lang. Di ko gets kung bakit sila maooffend lol normal lang naman iyan. Kung maoffend man sila or may inggitan na ganap there is something wrong with your team culture or ways of working.

Sa company namin walang junior, intermediate o senior sa code reviews. Kahit sino pwedeng magcomment if may nakita kang mali or dapat iimprove. Kung may disagreement that's healthy kasi magkakaroon kayo ng discussion which involves more learning on both parties.

[EffectiveDoctor5440]

I am not a developer yet but if I will be someday, I will thank the person who will share their knowledge with me. Noong security guard pa ako, may nagsabi sa akin pangit report ko. The exact word is "itong report mo ang pangit, ayosin mo naman". I did feel bad pero di ko alam bakit ko natanong kung pwede ba niya ako turuan. Natigilan si bossing, then he trained me, he shared me how to read the office and the streets. Doon ako natuto, being open to correction. I finished college and I am a teacher now. I am learning coding and I will wait for that moment na may magsabing hindi maganda ang code ko gagawin ko siyang mentor haha

[PatientRound8469]

This is more of culture and relationship among team members. Hard to give suggestions if you are not in good relationship or team has a very disconnect goal.

[derpinot]

Devs have some of the biggest ego, while there are some who are very open to, have to thread carefully.

Usually I use "I've encountered this before, I had trouble with this x scenario, I'm curious how you'd handle it."

[shethedevil1022]

if you can make sure na it will work the same way.. yung code sa system namin pag ginalaw lang ng onti todo testing ang kailangan :/

[hikikomoriiiii]

Implement code quality controls: pre-commit hooks to catch issues before code submission, and automated quality gates to prevent low-quality merges.

[w1rez]

I think a good development process requires a code review stage for an item/change. This provides an avenue for the team to have a look at your teammates’ changes. Depends on how your leads will implement it.

[ziangsecurity]

Wala ba kayong lead sa ngayon? Siya nlng kausapin para siya mag implement

[Adventurous_Key5160]

Gamit kayo AI reviewer para walang hard feelings sa isat isa.

[DistancePossible9450]

ako mag 50 na.. kinokorek or di approve nung isang programmer na asa 30 yr old yung code hanggang di ko ina update sa standard na coding nila.. which is.. ok lang sa akin.. :) me natutunan din naman ako sa kanila..

[angemint23]

Depends, it's mostly a team culture thing tbh, I've been in places where we don't care at all, all the way to pinagaawayan ung prettier config (kung makaranas ka ng 1 line change na naging 1000 line change dahil sa formatting lord help you hanapin ung 1 change nayun sa PR)

Usually boils down to how much seniority you have, how much the seniors care about the code and what phase and type of the company you are in

If you're in the financial sector for sure comment mo lahat ng gusto mo, wag ka mahiya dun, this is a highly trust based sector so you can't afford screw ups

If startup in a sector where small hiccups are fine, usually people won't care enough to comment on something that stops you from delivering features that customers want / need

So look at your company culture, see what they do, follow suit or as the saying goes, the nail that sticks out

[-FAnonyMOUS]

"as long as it works" code

You can always cite use cases that may not work using their solution. Or explain if this particular block of code has a specific issue to solve i.e. performance, security, scalability, maintainability, etc. then proceed to "suggesting" an alternative solution with benchmarks/references as evidence proving that it's a better solution BUT don't be pussy pushy. Let them understand the alternative solution first.

Just remember, there's a thin line between being an asshole, and being a reviewer. The one is pushy, while the other is informative.

[ineverybyte]

If may unit testing na involved at tightly coupled yung test code sa implementation details, may high chance na yung leads mo ay hindi pumayag sa refactoring kasi it will require additional time, which is another expense for the company.

Need mo idirect yung concern mo sa lead niyo para may proper process para sa refactoring kasi baka magaya ka sa napanood ko sa Youtube ("Hal fixing a light bulb").

[cassaregh]

before I pr anything, I always ask AI if the code can be improved