Ask HN: How to improve code quality while maintaining decent velocity?
Now I'm a little worried that if my situation doesn't change, my career would suffer. I've started to watch a few videos online about design. But I'm not sure if they're going to really help as they usually talk about very basics which doesn't help in real world coding.
I usually take 3-4 tries with some significant amount of testing to get my code to a working state. I refer to stack overflow or ask my colleagues if I get stuck on some design / technology feature which I haven't seen before. I feel the above contributes to reduction in my speed of delivery and the rush to complete the deliverable on time, compromises the quality.
Are there any good ideas to improve one's coding / design skills significantly ? The challenge here is to deliver good quality code, while maintaining a decent speed of delivery.
179 comments
[ 8.6 ms ] story [ 231 ms ] threadThe longer I worked the more bugs I introduced and the more I looked for the bugs in the evening the worse it became.
Ensure a proper work-life balance and plenty of screen-free time. Do not spend the night gaming when you work onscreen all day already.
The ideal per day work hours are 4h! No joke. In case you have to work 8h or longer perform simple tasks in the remaining 4h (meetings, documentation, emails, errands).
Eat well, get enough sleep, exercise, meditate, go outside and the next day you will find the bug and fix it within 10 minutes.
Many programmers tend to be the prototypical zombies who never see the light of day and only survive on caffeine (give it up). Remember that you're human.
I can easily spend more time on screen, before or after work. But getting back into development after work really takes a lot of mental energy for me.
However, if 4h limit really exists, imo, it will be about focused hard stuff. Many many programming tasks are not difficult and you can safely easily do them longer. You can also mix programming with analysis, architecture, design, helping people etc etc easily being able to productively occupy yourself for more.
Obviously if you're doing routine work you'll be able to carry on much longer.
Concentrated coding is a bit like doing a college math exam every single day.
I've never met a developer who could consistently do good work for over 40(ish) hours a week.
My rule with my teams is that I expect them to be "present" (even if remote) for 8 hours. The norm is about 6 hours of that to be actually coding, the rest is communication (which is vital).
If there's an urgent deadline, I'll let people stay to about 10 hours. After that, though, they're just going to be damaging the code base, so I send them home. And at this point, this became a scheduling fault rather than a developer fault. And the developer gets time off in lieu if they do >8 hours.
I've learnt this set of rules from experience. When I was younger, I thought I could code for days straight (and once pulled a 36 hour marathon, which was a disaster). I was wrong. I've watched lots of other people do the same.
If you don't believe it, try it. Pick a project and work at it for 12 hours straight, and compare your bug count / code quality in the first couple of hours to the last couple of hours.
The 40h work week has been introduced by Henry Ford 100 years ago because even in factories with dumb menial work people were getting tired and breaking more than making after 40h.
In creative industries that require programming, graphic design, writing etc. you can't assume that people will be doing good work for as long as factory workers do who only have to focus on the same repetitive tasks.
Working longer hours does not "get more done". It just creates more problems.
1. Designing/Picking your data structures
As you begin to code, your output and data needs might change; this might need you to change the design of your structures. Some novice developers, might think 'screw it, I've gone this far already. I've already spent a few days on this. No going back now.' If more time was taken in the beginning to plan and choose, you might be able to avoid this.
2. Refactoring.
Leave yourself some time to refactor before you push a commit. Those extra few hours or day will give you time to really go through your code and tidy it up. Think of your first commit as a first draft, then do a couple of revisions before you squash and push.
Good luck.
Have you talked about this with colleges? It could be that they don’t see it the same way as you. And they are happy to work with you.
I think most companies are terrible at doing code reviews and focus way to much in the wrong thing. You, as a team should create value for the company, not talk about the cutting your slightly to long method up again and again.
For me this code review video really opens my eyes:
https://youtu.be/a9_0UUUNt-Y
What is 100% true, imo, is that you get better with experience if you are exposed to good practice . This can come from reading other people's code, getting reviews of yours, but also reading books about design or videos or talks...
Just coding alone will help but won't be enough, again, imho.
That's what you're doing.
Slow down. Spend more time planning what to build, discussing what the acceptance criteria mean, designing your code, writing tests, thinking about your data structures, etc.
It'll feel like your velocity is taking a hit but the fact you no longer have to do the work twice will likely mean you're actually delivering features much faster.
So more code reviews and design reviews for others and try to ask why whenever you don't understand what you are looking at. Asking questions is a sign of strength.
Spend a little more time on design, and whiteboard with a coworker before you implement. Draw the boxes and arrows of your approach and reason about where it will break. It will break on some axis sometime, tell yourself where it is.
Find a mentor. There are tons of folks who would spend an hour every week answering questions about design that you were too shy to ask in the bigger group.
Stop meetings when you don't understand a term. Ask for a clarification.
Talk to your manager, be open about wanting to improve this specific skill. Speaking as an engineering manager myself, one of the most fulfilling parts of my job is seeing someone ask for help and giving them a chance to stretch and learn.
Accept failures. A failure just means you learned something. I've seen some big failures and caused some big failures. I learned and moved on. That said, don't fail the same exact way more than once if you can help it.
Ask for peer feedback. Maybe no one else thinks you aren't performing. Maybe you've set up a false narrative about yourself.
Ask, specifically, "am I asking for help too soon or too late" and really listen to the answer.
In situations like this, if you don't make the decision to walk away, the decision will probably be made for you.
Hell no ! Asking good questions absolutely - asking generic questions that can be googled in less than five minutes shows that you either can't search and solve problema on your own or don't respect my time.
I've seen a lot of newbies take this approach when someone tells them this advice - I usually tell them after a few times and then if I see this pattern I recommend not keeping them because they end up being a net negative.
Also a confused guy stopping meetings is the worst - taking time out of the entire team who now has to listen to stuff they already understand explained again. Pull someone aside afterwards for clarification.
"Also a student stopping lectures is the worst - taking time out of the entire classroom who now has to listen to stuff they already understand explained again. Pull someone aside afterwards for clarification."
You are part of the reason why people are scared to speak up and ask "stupid" questions, and I feel like that ends up being a net negative.
If one is engaged in conversation, one should not restrain himself from asking whatever for politics/social issues.
Let the question be asked, it can be esaily dismissed or ignored if it's a bad/not useful question, but it can be asked too anyway!
Thinking that you get to ask for clarification whenever you feel like it just because you don't understand something is very self entitled - you have to consider the context first. If someone is explaining something to you directly or the purpose of the meeting is to teach something to the whole team by all means ask for clarification.
There is trade-off to which questions should be asked right now and which should not. Both in lecture hall and on meetings.
IMO, instructors who indulge this kind of thing do the whole class and especially the asking student a disservice because the opportunity for self-teaching is lost. Self-teaching is much more important than whatever the lesson of the moment is.
The whole value of being lectured by an expert in your field is that you follow along the material with them and can ask for clarification where necessary.
Unless there is a Q/A time, interruption of lecture for sure not good for the whole group.
I’ve even been in lectures with other professors watching where they will stop their colleagues to ask questions. In addition many of my lecturers would stop the class to ask us if we understood, and explicitly stated that they wanted to make sure we were following. This is even in lectures of 50+ students.
Questions are little tradeoffs, if everyone starts asking a lot of questions, obviously it will result in less information delivered in limited time.
This is very similar to no bug policy in software, if you enforce 0 bug policy, your development slows down to halt, thats why some stuff is always NOTFIX or low priority.
And don't ask just to show how clever creative you are to think of the question. And don't ask question you know answer to, and I am quoting schoolmate here, "so that other students hear the question too". Headdesk.
Eventually someone convinced prof that there cant possibly be well over 3000 meaningful questions and that forum quality will go down if we try.
* basic reading comprehension issues
* trivial matters that could have been looked up in an obvious reference
* completely unrelated tangents, asked out of idle curiosity
* questions asked solely to demonstrate "participation" (nothing wrecks a classroom like a "participation" grade)
In my experience, these comprise the bulk of questions that are asked in non-STEM university and graduate settings.
I don't call these questions stupid, but they are a waste of time, do not move the ball down the field at all, and discourage self-learning.
That for sure is a much worse outcome than the occasional “really?” kind of question. Some simple nudges to colleagues as checks (did you do the reading? Did you try to answer it yourself first?) before asking questions to keep things productive, for example, might be a good starting point rather than a Potentially more hostile approach that could frustrate well-meaning questioners.
The student was assigned reading material beyond their level. They will need mentoring, which a good teacher (i.e. senior developer) is well equipped to provide and should be willing[1] to provide. The teacher should also ensure that no other student is in the same situation but is hiding it due to risk of the social stigma.
> trivial matters that could have been looked up in an obvious reference
Student is not aware of resources available to them or does not yet have this habit. Provide them with pointers to resources, or engage them in habit-forming exercises for looking up references[1].
> completely unrelated tangents, asked out of idle curiosity
Idle curiosity is the best attribute (correction: skill) you can ask for in a student (any developer). Stifling it will cause a drop in creative thinking and therefore damage problem solving skills.
An unrelated tangent is unrelated only if the teacher (senior developer) does not possess the skills necessary to relate the question back to the topic at hand. Something made the student think of the so-called tangent. In such occurrences, explore[1] the tangent and how it may possibly relate to the topic at hand, with the help of the student, as a learning opportunity (an opportunity for the teacher, rather than the student, to learn).
> questions asked solely to demonstrate "participation" (nothing wrecks a classroom like a "participation" grade)
If a student participates just to demonstrate participation, this is usually because the class dynamics (work politics) are skewed against the student (damaging their self-esteem), or the rewards for good performance are not distributed evenly -on merit.
When you think a student is participating just for show, assume good faith. That is, assume that the student is genuinely interested and explore the idea together[1] with the student. If it turns out that the student was actually interested, you just prevented a misunderstanding caused by your own burn out. If they were participating just for show, you just helped them hone in on their skills and provided guidance on how to better participate in class (meeting/workplace).
--
[1] If you are not willing to do this, stop teaching (read: either stop hiring non-senior developers or quit). Your role in the university (read: workplace) as an instructor (read: senior developer) is not only to manage and produce research (read: projects and deliverables) but also to develop your students' (read: non-senior developers') skills. Earn your salary.
You are not the best at maintaining discipline ;) If this is happening with a lot of your students, seek out guidance from the more experienced teachers in your department that you know are liked/loved/adored by students or the cohort. (It helps if you attend their classes to observe their approach and the class dynamics.)
Somehow engage the student in the first 5 minutes of them looking at their phone. (Beware, they may have had an emergency before the class.) If you let them be on their phone for 20 minutes straight, the student knows that you don't care about their presence in the class. Or, worse, they now think you are one of those teachers who don't care about all or a subset of the students.
> when assignments are handed out - starts asking to explain everything again
This happens much more often than you'd think. Having the instructions clearly laid out in the assignment sheet usually helps. The quality of education they received prior to college (before your company) is usually worse than that they receive in college, leaving them confused starting with 100-level classes (and their confusion gets worse and more complicated as they advance).
> explain everything again
If, by this, you meant everything you talked about in class, ask the student to come to your office hours. You may have to accommodate their schedule, which usually is not too difficult though inconvenient.
Think of the teacher as the management. If the student (employee) fails (is fired) or drops out (quits), it is usually because of the teacher (management).
You sound like a non-parent trying to tell a parent how to be a parent.
There is 120 of us. Why the hell should 119 of us wait till teacher engage with the one person who is fiddling phone?
And most late arrivals are not due to emergency.
But it's not just that this attitude is unfair on the teacher/manager, it's that it's unfair on the other people they're responsible for. As a teacher or manager, you have finite time to devote to multiple people. If you make it a matter of policy that you will take the time to answer any question, no matter how unnecessary, and make no attempt to discourage avoidable questions, then you are in effect deciding that you will devote the majority of your time to the laziest, most selfish individual you're responsible for, while spending zero to little time on people who are too meek to make demands on the time of their constantly-busy mentor. There's nothing noble about what you're proposing here; it's an abdication of the responsibilities you have as a manager or teacher.
Adults are expected to maintain discipline on their own.
And meanwhile the rest of us is waiting twiddling fingers, because someone could not google that tangent or asked question anyone who is paying attention could answer.
This does not annoy just teacher. It is annoying students who were paying attention and were there whole time way more.
> If a student participates just to demonstrate participation, this is usually because the class dynamics (work politics) are skewed against the student (damaging their self-esteem), or the rewards for good performance are not distributed evenly -on merit.
When you have one-two people out of over 100 asking such questions all the time in multiple unrelated classes, the issue is not all of us or all those teachers.
> If they were participating just for show, you just helped them hone in on their skills and provided guidance on how to better participate in class (meeting/workplace).
Please, please, please, don't teach students to make meetings longer by asking tangents. That is for after meeting when those not interested can leave. Meeting moderation is literally about ability to keep discussion on point.
Seems like you've been in higher level STEM settings and your experience outside of that has been low level electives, you've had limited and unusually poor samples, or you're just speaking out of bias for (presumably) your own path in life.
I don't think people who are not "STEM" are generally going around navigating the world and school like uninformed, idiot freshman who don't know how to participate in their own education... At least not any more then people in STEM are ;-)
So I think that cultures are much different in that regard. A lot of it makes sense give topics that were taught. It is not that non-stem was inferior, it is that different topics have different pedagogy.
But, if students get points for asking question often enough, they will be trained to ask any question that cross their mind. They will be used to actively desperately look for any question to ask cause they are used to need that point.
I find this more in public talks than in classrooms, but yeah, that guy is always out there somewhere.
Well, for a classroom with high velocity that would indeed be an issue. Mixed capacity classrooms might help less apt students, but can at the same time slow down more advanced ones.
In real world projects you often get new people assigned to the team, outside people and some of them are very bad at evaluating context for asking questions.
I just had a cross-team sync meeting where this annoying guy from another team with no clue about our requirements or what we attempted started to drill questions on some random library choice - wasting the time of 10 other people and not arriving at anything other than being curios about the tech and wanting to talk about libraries.
Or the other day we had a junior argue with a PM about the requirements because he clearly miss-understood it - it took 10 minutes for the PM to drill down to the source of confusion and wasted 10 minutes of 4 people on the call ! Meanwhile two of us were eye rolling after 2 minutes about how stubborn this kid was when he was completely missing the point - this could have easily be don one a call after our sync meeting.
I would take a junior that comes late with his tasks but mostly works independently over a guy that's asking the rest of the team for every setback so he can deliver the stuff he promised any day of the week. Juniors are almost always a net negative for the team - the ones who know how to reduce that are a huge benefit.
Newbies often need more than a 'few times' to become net positive assets. They are junior, after all.
I consider myself lucky to be in a position to teach and curate happiness. I was once a junior and probably asked some stupid questions that I could have just Googled but I didn't know what I didn't know.
If people are holding up meetings with low level questions you likely have involved the wrong people in the meeting. Every problem presented in the original comment has a solution. By all means let someone go if they are struggling so much that they are unhappy, else it's on you for hiring poorly or leading poorly.
... Or they work for a (typical) organization that pays lip service to teamwork but punishes individually - by obsessing about meaningless metrics like “velocity”, putting everybody in a position where they have to choose between being helpful productive members of a team working together toward a common goal OR meeting the arbitrary goals and deadlines that lazy managers are actually incentivizing them with.
It is, however, important as a newbie to attempt to answer one’s own questions briefly before asking them, that’s one important way to learn and grow. My mentor at one of the best jobs I ever had instructed me on the day I was hired: “you must spend at least 5 minutes trying to answer your own questions, and also you must stop and ask someone as soon as you spend ten minutes trying to answer your own question.”
Sorry -- couldn't resist ;-)
I’ve always found its best to operate on the principle of “there are no dumb questions”.
Don't do this kind of thing. It's extremely unprofessional.
Chances are there are related things to work on that you haven't even noticed. And chances are ongoing feedback with someone with context about you is going to be much more useful than replies from internet strangers. I recommend finding a mentor. A nice side-effect is that thhis shows you're proactively addressing the shortcomings.
(1) Does what it is supposed to do and nothing more;
(2) Is easy to read;
(3) Is easy to change;
(4) Is efficient enough.
Note that these points are somewhat strongly ordered. If you have to make a trade-off between "maximal efficiency" or "can be read by the rest of the team", you choose readability, unless "maximal efficiency" is required to meet a customer deliverable ("acceptance criteria").
Note the word "required". As in, "we have promised our customers to service requests in under 2ms, and these rather unreadable performance optimizations are the only way we can do this", not "the lead programmer likes 'efficient' code". That's not to say you should be stupid about performance -- see (4), above -- but that your goal is to deliver value to the customer, not to build a technical monument to Donald Knuth.
That prompts the next thing we need to talk about: what do we even mean by "high velocity"?
Clearly it isn't just writing a lot of code. Were that the case, we could measure productivity in LOC/day. And it isn't in always using the minimum amount of memory or smallest number of CPU cycles.
From a business perspective, "high velocity" means "delivering working features to our customers as fast as possible... forever".
That last bit is important. You aren't going to get one feature request, scratch that off in a frantic 48-hour marathon of caffeine and hackery, and then be done with the rest of your career.
New feature requests, changes to existing features, unexpected behavior that needs to be changed... these are life as a programmer. Smart programmers recognize this, and build their code to be easily changed.
Now, you can't do this by trying to anticipate every future need. Building code to support an uncertain future is where the vast majority of technical debt comes from, because 90% of the time, you'll just be flat-out wrong, either grossly, or in sufficient detail as to render your attempt to defend against change moot.
Instead, you follow a set of coding practices that help you design systems and build code that can respond to future change, without having to know anything about what those future requirements might be.
To that end, I highly recommend Sandi Metz's POODR[1] and 99 Bottles of OOP[2].
Yes, the title of the first book ends in "Ruby". Ignore that part, as it's probably the best primer I have ever seen on building code for the real world.
I have also found that strong TDD -- and yes, I'm lumping BDD in with this, don't be a pedant -- has helped me to learn to write much higher-quality code over the years. Code that is fully-tested can be changed with a high degree of confidence that you haven't broken something unintentionally, and writing tests first forces a lot of highly beneficial design choices.
GOOSGT[4] is a good place to get started with TDD.
Last but not least, recognize that all of the above are skills -- you will need to devote time, and a lot of repetition to learning them.
[1] https://www.poodr.com [2] https://www.sandimetz.com/99bottles [3] http://www.growing-object-oriented-software.com
As for feedback I typically start the feedback cycle very early on so there are no surprises at PR time and remember that it's all about the knowledge creation not proving how great one is as a coder per se in other words get in the habit of asking "how would you code this?" to the person eventually looking at your PR
Even if one's implementation is rejected one's tests are still valuable, no?
I usually code in some variation of TDD or BDD where tests serve as a framework for refactoring and we iteratively improve our implementation while increasing our confidence that the solution actually fits the requirements
Here is my ten rules of coding in the spirit of Elmore Leonard
- naming is hard it's also the most important task take inspiration from the watch repair channel a name for everything and everything with a name coding is 99% naming and 1% organizing - never name anything "SomethingManager" it's an anti pattern and shows you have no idea what to name the thing - Code is twice as hard to read as it is to write - all writing is rewriting i.e. all factoring is refactoring - vulnerability means giving it your all i.e. aim to be a 100% coder who gives it their all rather than a 10x coder who bests the field - Never forget people used to do this stuff on punch cards and the first bug was a real insect also never forget people would kill for a chance to fill your shoes - dressing up for work shows you treat your role with dignity greater than just yourself and still matters if only as a nod to the originals like Alan Turing and Charles Babbage - if you only read one book read POODR - avoid silos like the plague a team only succeeds if everyone succeeds and knowledge workers are meant to spread the knowledge - remember Conway's lesser known second principle software is as fun to use as it was to write
That and hang in there for the rest of us we're here for you too
To the downvote brigade if you find my sentiments not to your liking how about an upvote for visibility with a snarky comment rather than an anonymous downvote?
As for taking 3-4 tries, I think that if you stick with it, you'll get better as time goes. Learning about design patterns, even if the tutorials seem worthless at first, might come in handy. Better to be aware of the patterns before you need them than after.
For the first 3-6 months, companies probably care more about having newcomers get up to speed on matching the style & convention of the existing codebase.
It helps to do an architecture review of the codebase and understand the overall code design focus, and pay attention to how the code is typically structured. you could also look at other people's code reviews to see what the common areas of design thinking are.
Additionally, sometimes code reviews for newcomers is more involved because we want to see how the person reasons about the problem. It's also helpful to get astonishment reports from newcomers during code reviews.
In either case, make sure you understand what is expected of you so you can be on the same page as those whose expectations matter (often a manager and your teammates).
If "velocity" is a buzzword that comes up in natural conversation, there's a pretty good chance that's the _only_ thing they're paying attention to. If you're put in the position of managing software developers, but don't know anything about software development, all you can pay attention to is how much time they're spending on "tickets".
You need to be able to explain the architecture of what you're programming, the reasons being:
- Code is processed by machines, but read by humans
- Code is read by many people, written by far fewer
- If you cannot explain design decisions, then expect criticism of it
- Naming is hard, but reading badly named code is even harder
Serious developer do not refer to stackoverflow. Developers should use stackoverflow only to lookup for names of functions or methods. Nothing else.
When you find what you are looking for, then you go reading the official documentations. In the extremely rare and specific case when the documentation is not there (and when you cannot change the library that you are using, why would you use a library without documentation?) then you go read the code.
If the majority of your time is spent copying and pasting (with slight modification) from stackoverflow you are extremely junior in that field.
I see it on myself, when I do backend work stackoverflow is not even on my tabs. But when I do some frontend for personal projects I just keep going back and forth.
Declaring such BS without a hint of doubt in the way you phrase it... Using SO does not make you a bad developer, having preconceived ideas about what makes a good developer definitely does not help you become one.
Using SO for something different than trivial lookup is a recipes for disaster and it says a lot about the quality of the work done.
Are your solutions overbuilt? Poorly documented? Introducing new patterns where they aren't needed?
The biggest clue I've got to work with is:
> I refer to stack overflow or ask my colleagues if I get stuck on some design / technology feature which I haven't seen before.
I'm searching up the problem as many ways as I can before I even get started. Even if I think I know how to do something, there could be a better way to do it.
> the rush to complete the deliverable on time
If you're rushing, you're doing something wrong. Here's a secret: it's way more important to be reliable than it is to be fast. Who's setting the deadlines? Is there a way you can squeeze more time? A lot of junior devs underestimate things habitually.
At the basic level, I try to have...
1) Comments in code
2) Meaningful function and variable names
3) Breaking large piece of code into small functions or methods.
4) Committing the code to GIT/SourceControl whenever a small incremental step is completed.
5) Discussing your design/worlflow with lead before the development also helps to have common agreement.
Sometimes, the code reviewers have difficulty in reading the PR if it spans multiple files or projects. In that case, I had to sit with them and explain the workflow and later they are able to review the PR.
Whiteboard a design with a colleague, socialize your ideas.
Open a “do not merge” pull request early and keep pushing changes to it. Keep your lead/mentor tagged and request early feedback.
In a large codebase there are usually many many conventions like “this is THE WAY we do such and such” and it’s important to pick these up. It can be difficult to find these they are not always well documented.
Really, practice. Build things. Write a lot of code for your job. Write a lot of code for yourself on whatever interests you. Put in the hours or keep putting them in if you already are and your knowledge will continue to compound.
* Use a statically typed language that allows fast refactoring. Ideally a typed functional language like Elm, Reason, OCaml, or Haskell.
I recently shipped a complex Javascript project (without types) and it is one of the few instances of my decade-old professional career where I had that level of confidence in the robustness of a piece of code I wrote. It remained sturdy in production even in the presence of unforeseen conditions. This was thanks to the habits I picked up from typed FP: parsing and validating all data at the boundaries of the system, better design by modelling data to make inconsistent states impossible, and automatically handling all edge-cases at all times.
So even if you don't actively use such a language in your workplace, there really is a payoff to learning it in making you a better programmer overall.
Not because you'll be using functional languages afterwards for work, but it changes your coding style - even in imperative languages. More towards pure functions and a cleaner separation between data and logic
I suspect this won't be immediately possible as I'm not certain what languages OP is allowed to use, but if OP has some wiggle room in what PL to use, then I would recommend that he look at the Domain Modelling Made Functional book by Scott W.
Like you say, the principles in the book apply to other languages as well, but it can be a faster feedback cycle to learn these lessons in a language that has first-class support for them. He will be able to use F# or its close syntax cousins OCaml, ML to model new features as domains and employ option types, pattern matching, railway-oriented-programming, and functions as interfaces to make his code more resilient, like you mention.
The bonus is that if OP uses the likes of F# or Scala, it can interop with C# or Java respectively within the same codebase.
To underline the importance of what you're saying - one of the most interesting learnings so far from the data we've seen (~400 developers using it for the last month to log issues in their code/processes, >1,000 survey responses) is that the average developer encountering an issue loses more than twice as much time in Planning and Deployment than in Writing Code. The reason the data shows for this is that when there is an issue in Planning it wastes a very larges amount of time.
The other trend we've seen is we ask developers how each Pull Request made them feel (Happy/Neutral/Sad). We have literally not yet had someone give feedback who felt sad! So you can make your team happy just by asking and listening :)
Anyway, for any big enough system or module reviews are relatively weak form of attestation. They mostly work as a sanity check and to ensure base level of cleanliness and design.
Better attestation is an automated functional test, best a full proof.
Curious if you can see a way that an automated functional test could pick up on the quality of design?
That means that a PR could be approved by Facebook and exactly the same code outright rejected by Microsoft.
My experience is that my code can be rejected by people with 5 years experience or less while I have almost 20 (professionally) simply because they have been in the organization and with the code longer.
It can still make you insecure, especially in your trial period.
When you think your code is ready to review, ask yourself what you could improve in twenty minutes or a half hour. If you’ve been working on something all day or for days, nobody is going to notice an extra thirty minutes.
Also code reviews are a training method at some places. They’re trying to normalize style and you don’t know it yet. Take the feedback seriously, yes, but don’t panic about it.
How long has it been since they hired somebody else? Stable teams can have serious blind spots about both the level of knowledge required to become effective, and they often aren’t used to having their ideas challenged (even if it’s only different idioms in code).
A big, decent organization will have the structures in place to help you learn this. I'd suggest bringing it up at your next 1:1: 'I'm a bit worried about how I did in these PRs <open browser>'. Your manager may also have the same worries, in which case you skipped that conversation along to the point of working on a solution, or you might find out that what you are doing is on-par and there is nothing to worry about. Training in new skills is bread-and-butter stuff for a mature organization, so I would look for support in your normal management chain.
Also be aware that not all code reviews are good. Engineers have opinions and may wield code reviews as a tool to impose theirs on others. In those cases it doesn't reflect you or the quality of your work.