Ask HN: How to improve code quality while maintaining decent velocity?
179 comments
I suspect a lot of your issues could be solved by talking to someone before you start coding to make sure your approach is valid.
When PRs are getting outright rejected it is because you are making incorrect assumptions or decisions in your code that don’t match with what the rest of the team knows or wants.
Before you make a decision, get another perspective.
One common pattern I see in not-quite-yet-senior devs is that they don’t necessarily recognize the moments when there is more than one option, and they are making a choice. This happens all the time in programming. You are constantly making decisions and committing to particular solutions. If you are not aware of the choices you are making - you are picking the first idea that comes to mind (or the first stackoverflow answer) - there’s a really good chance you are picking wrong.
Also try to develop your instinct for the assumptions you are bringing to the table. Did you assume this code was just one-off stuff for a simple offline process? Do others on the team expect it to be reused as a library later in an online service call path? That difference of perspective will lead to vastly different expectations for how that code should be written.
So: Take more time before you start coding to talk through the approach you were thinking of taking with someone. Then, as you start coding, watch out for moments when you can make a choice and again, get some input.
Doesn’t need to be a long design session. Just a five minute pull-aside to get a consult on an approach.
This is why pairing is so effective, by the way - you get constant access to a second perspective.
When PRs are getting outright rejected it is because you are making incorrect assumptions or decisions in your code that don’t match with what the rest of the team knows or wants.
Before you make a decision, get another perspective.
One common pattern I see in not-quite-yet-senior devs is that they don’t necessarily recognize the moments when there is more than one option, and they are making a choice. This happens all the time in programming. You are constantly making decisions and committing to particular solutions. If you are not aware of the choices you are making - you are picking the first idea that comes to mind (or the first stackoverflow answer) - there’s a really good chance you are picking wrong.
Also try to develop your instinct for the assumptions you are bringing to the table. Did you assume this code was just one-off stuff for a simple offline process? Do others on the team expect it to be reused as a library later in an online service call path? That difference of perspective will lead to vastly different expectations for how that code should be written.
So: Take more time before you start coding to talk through the approach you were thinking of taking with someone. Then, as you start coding, watch out for moments when you can make a choice and again, get some input.
Doesn’t need to be a long design session. Just a five minute pull-aside to get a consult on an approach.
This is why pairing is so effective, by the way - you get constant access to a second perspective.
I think I'm quite good at detecting when my experience isn't able to suggest a specific choice with statistical significance. I have a generally good overview on whatever I'm designing, but it's hard to find a place where I can make good use of these capabilities (limited, escalation-allowing solo design).
Are there any lesser-known types of positions that require these skills? Preferably backend/core systems, not embedded or fronted.
Are there any lesser-known types of positions that require these skills? Preferably backend/core systems, not embedded or fronted.
This is an excellent suggestion.
I think an important question to ask before getting review is can other people understand and manipulate my code as easily as I can? Engineers who submit PRs without critiquing their own work (usually the moment they complete the ticket/task) are a liability, and can introduce some uncomfortable situations when it falls on peers to approve/criticize. Speaking from experience, my boss was very terse in code review sometimes, but it was the kick in the pants I needed to understand that my buggy, brittle code was unacceptable.
If you're looking for good resources, Clean Code by Bob Martin is a classic.
I think an important question to ask before getting review is can other people understand and manipulate my code as easily as I can? Engineers who submit PRs without critiquing their own work (usually the moment they complete the ticket/task) are a liability, and can introduce some uncomfortable situations when it falls on peers to approve/criticize. Speaking from experience, my boss was very terse in code review sometimes, but it was the kick in the pants I needed to understand that my buggy, brittle code was unacceptable.
If you're looking for good resources, Clean Code by Bob Martin is a classic.
+1 Clean Code is a fantastic resource.
Uncle Bob also has a video series that provides a good introduction to a bunch of design issues in an understandable format (but it's not cheap at $14/video): https://cleancoders.com/ . I've seen these videos transform the way teams code.
My other suggestion is to start paying attention to how your code "feels". If something is painful/boring/fiddly it's often the case that the design isn't a good fit for what you're trying to do. TDD is excellent for this because it will move the pain front and center where you can't ignore it.
Clean code and other resources will give you tools to use when the design isn't a good fit (I could use this technique here etc...), but recognizing when you need to step back and change the design will be up to you.
Uncle Bob also has a video series that provides a good introduction to a bunch of design issues in an understandable format (but it's not cheap at $14/video): https://cleancoders.com/ . I've seen these videos transform the way teams code.
My other suggestion is to start paying attention to how your code "feels". If something is painful/boring/fiddly it's often the case that the design isn't a good fit for what you're trying to do. TDD is excellent for this because it will move the pain front and center where you can't ignore it.
Clean code and other resources will give you tools to use when the design isn't a good fit (I could use this technique here etc...), but recognizing when you need to step back and change the design will be up to you.
Along these lines, I wonder a lot about understandings of and appreciations for systematicity among developers. In my career I've seen a disturbing number of engineers who either don't or can't seem to think in terms of systems, and make decisions with short-term solutions that don't consider the chain of consequences in the rest of the project.
Being able to take 100 steps back from the question at hand is critical to making the best possible decisions. Ask yourself: what are we really trying to do here? What is really the problem being solved? This perspective is going to affect your work even if it seems like your current task is just a small cog. You might just be able to make your small cog improve the effectiveness of all the other cogs.
Being able to take 100 steps back from the question at hand is critical to making the best possible decisions. Ask yourself: what are we really trying to do here? What is really the problem being solved? This perspective is going to affect your work even if it seems like your current task is just a small cog. You might just be able to make your small cog improve the effectiveness of all the other cogs.
> I suspect a lot of your issues could be solved by talking to someone before you start coding to make sure your approach is valid.
I'm not sure what kind of incorrect assumptions you are getting. But one thing that could signal you should ask about your approach is working in another team's codebase. Some of your problem could be making a technically valid choice that doesn't align with the codebase. Working on unfamiliar code can cause this.
Personally I had a previous job where I got into a few longer discussion about my approach after submitting a couple PRs with another team's tech lead. I was able to be more productive by talking with that lead about my task before starting the coding.
I'm not sure what kind of incorrect assumptions you are getting. But one thing that could signal you should ask about your approach is working in another team's codebase. Some of your problem could be making a technically valid choice that doesn't align with the codebase. Working on unfamiliar code can cause this.
Personally I had a previous job where I got into a few longer discussion about my approach after submitting a couple PRs with another team's tech lead. I was able to be more productive by talking with that lead about my task before starting the coding.
Write down the things you got called out on in review. Build a checklist of them. Perform a self review for them.
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.
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.
Great list, also spend money on a coach, both technical and soft skills. It will pay for itself many times over.
What kind of coach?
A bus to get you to the green place where they don’t talk about velocity.
Sorry maybe I’m dumb but I’m not following this.
It's a play on words. The great grandparent suggested hiring a coach, i.e. a mentor or instructor, to improve his skills. The word coach, shortened from stagecoach, also refers to an intercity bus (what I would have called a highway bus as a kid). So, the reply is suggesting taking the bus to another city where jargon like "velocity" is not used. It suggests the problem is the company culture rather than the individual. I thought it was quite clever.
i didn't get that one, but i did get the one about the grass, which is ultimately greener on the other side.
[deleted]
Seconded. It may be that you're in a toxic environment. In such places it doesn't matter how good your design is or how tight you're implementation, you still get hostility and nit picking on code review. And not in a constructive way. Sometimes it's not you, it's them. When development turns into a dick swinging competition, walk away. It's better for your health.
"walk away. It's better for your health"
In situations like this, if you don't make the decision to walk away, the decision will probably be made for you.
In situations like this, if you don't make the decision to walk away, the decision will probably be made for you.
If it does get made for you, don't take it personally. Just like dating, there's a better fit out there for you.
Sometimes it's this attitude that is toxic to profitability. OP didn't say it felt unfair, and it's not right for this community to constantly reinforce the "big bad wolf" theory of senior engineer dick swingery when someone honestly wants to get better.
>Asking questions is a sign of strength.
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.
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 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.
"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.
Right, but there is another side to this coin. There are good questions, and then there are questions that evince/exhibit:
* 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.
* 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.
Agreed, provided one is not so aggressive at preventing the questions you list that you effectively chill the environment for questions out of fear subsequent questions are “the bad ones”.
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.
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.
> basic reading comprehension issues
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.
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.
> 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.
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.
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.
The student arrived late, fumbled with his phone the first 20 minutes, then started talking with his neighbor about something apparently very funny and now - when assignments are handed out - starts asking to explain everything again.
> The student arrived late, fumbled with his phone the first 20 minutes, then started talking with his neighbor about something apparently very funny
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 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).
This mindset is toxic. Obviously teachers and managers wield some power to influence the success of those beneath them and have some responsibility for it, but they do not wield total power and should not bear total responsibility. In the end, some people have personal failings that you cannot fix, and that is on them, not on you.
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.
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.
> 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
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.
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.
> You are not the best at maintaining discipline ;)
You sound like a non-parent trying to tell a parent how to be a parent.
You sound like a non-parent trying to tell a parent how to be a parent.
> You are not the best at maintaining discipline
Adults are expected to maintain discipline on their own.
Adults are expected to maintain discipline on their own.
“non-STEM” — care to be more vague?
Just out of curiosity, where does your experience with "non-STEM university and grad settings" come from that you are judging and contrasting it so harshly with STEM?
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 ;-)
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 ;-)
Not him, but I used to sign up to various courses while coursera was starting and free. Which means courses from American universities. Non-STEM were more likely to mandate questions if you want good grade. It was a fight to convince teachers that it is bad idea in online setting at first. They were also more likely to try to force or encourage discussion between students even when questions were not mandatory.
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.
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.
Man, my favorite ("favorite") is the "I don't actually have a question, I just want to make sure everyone sees that I think I know something by rambling about it semi-incoherently and then trying to turn one of those run-on sentences into a question halfway through it."
I find this more in public talks than in classrooms, but yeah, that guy is always out there somewhere.
I find this more in public talks than in classrooms, but yeah, that guy is always out there somewhere.
In my experience, this happened just as much in STEM classes, if not more.
Friends of mine that are teachers say, if one student speaks up and says they don't get it. Then most of them aren't following either.
had this in Uni. I was the annoying student who asked questions all the time. After a few units, I had other students thank me for asking all those questions, because they also didn't understand but were too shy to ask.
Well the old adage of not caring of looking stupid or asking stupid questions.
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!
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!
Like someone else said - this is entirely different from a team setting - when you have a team of say 5 people and a newcomer - the new guy interrupting the meeting for every thing he doesn't understand is just sucking the time out of 4 other people on the team.
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.
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 has to be a balance. Usually in work meetings it is not so bad, because the groups are smaller and people asking questions are a bit older and more socially mature, and they can judge from people's reactions when their questioning should be taken outside the meeting, but in college lectures it can be absolutely devastating when there are a few underprepared or inattentive students who convince the lecturer to run the entire class at their pace so they can put in less effort outside the classroom. A teacher doesn't have to be cruel, but they absolutely should politely but firmly turn aside persistent questions that indicate that the student has not done the reading or does not have a grasp of the prerequisites. I sat through several classes in college where the professor decided to spend the first eight hours of lectures in a physics class, for example, reviewing basic calculus or linear algebra. That's an insult to students who have prepared for the class and showed up expecting to be taught physics, especially when there are plenty of seats in the calculus and linear algebra classes for students who need to learn that material, and it adds insult to injury when the final exam for the class is consistent across different lecture groups, and your lecture group is handicapped by skipping or rushing through the difficult material at the end of the semester.
>"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."
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.
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.
The purpose of a lecture is learning and the entire class is expected to have some minimum level of background knowledge.
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.
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.
There are simple questions that are being asked just to show initiative or to show that the student came up with question. A student asking simple question he could answer by himself or by looking into book in front of him if he bothered to think for 4 seconds is not gain for anyone.
There is trade-off to which questions should be asked right now and which should not. Both in lecture hall and on meetings.
There is trade-off to which questions should be asked right now and which should not. Both in lecture hall and on meetings.
[deleted]
Yes, exactly. Just made the same point.
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.
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.
Wow, I don’t agree with this at all. The odd question in a lecture can mean the difference between you following along the whole lecture and losing track completely after 5 minutes. The reason you are in the lecture is to absorb the lecturer’s exposition of a subject. If you miss out on that because you didn’t understand one small point near the beginning, you might as well just read a book and not attend lectures.
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.
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.
I am asking to first check whether the answer is not on blackboard right now, in your notes or whether cant be derived quickly.
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.
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.
This is maybe good on one on one lecture, but when situation is one to many, it is better to assume the part you don’t understand as a fact, and try to move on, then later try to figure out off lecture time.
Unless there is a Q/A time, interruption of lecture for sure not good for the whole group.
Unless there is a Q/A time, interruption of lecture for sure not good for the whole group.
Why? The point you’re confused about might be something that the lecturer genuinely didn’t explain properly, omitting some detail. I never remember being annoyed or feeling like my time was being wasted by questions in lectures, even when I knew the answer. Many times the questions clarified points I didn’t understand as well as I thought I did until a well thought out question was asked. Other people asking questions in lectures was a huge net positive for me in my education.
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.
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.
I support the Q/A time as I stated on my previous comment, so the professor stopping in the way, asking for questions and explaining them more in detail is for sure net positive.
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.
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.
The most epic was an online course with thousands of students (dont recall exactly) where you was required to ask three questions per semester.
Eventually someone convinced prof that there cant possibly be well over 3000 meaningful questions and that forum quality will go down if we try.
Eventually someone convinced prof that there cant possibly be well over 3000 meaningful questions and that forum quality will go down if we try.
One notable difference between meetings and lectures is the variance in skill level. In a lecture, it is reasonable to expect that if one student didn't understand something, he was not alone. A junior (or newcomer to a project) in a meeting, however, is a different story. That's a relevant distinction for deciding whether to write down your question for later, or speak up.
When a team hires a new person, they expect a lot of things to slow down for awhile as they explain things to that new person. This is the cost of onboarding. You pay the short term cost for the long term benefit. It is not fair to the new person or good for the team to refuse to invest in onboarding.
Lectures are explicitly for learning. Meetings aren't. Apples and oranges. There are stupid questions, and asking them predictably without awareness of the cost is a performance problem.
Either your team has a problem hiring the right people, or you guys are just horrible, snobby people to work with.
Newbies often need more than a 'few times' to become net positive assets. They are junior, after all.
Newbies often need more than a 'few times' to become net positive assets. They are junior, after all.
> or you guys are just horrible, snobby people to work with
... 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.
... 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.
I agree strongly that questions are critical and important and junior devs should always feel comfortable asking them. However, if you've never had to put up with useless, aggravating questions that only waste everyone's time, consider yourself lucky. There is definitely a difference between a snob and someone who doesn't do their own due diligence before involving other people.
Of all the mildly irritating experiences in the life of a developer I think juniors asking what you consider redundant questions ranks lower than office politics and a daily commute. Fortunately juniors can be sculpted by quality teamwork and leadership. My job as a tech lead is to be patient and use my experience to point people in the right direction. Some juniors don't know what questions to ask Google so I am glad they ask me and don't push a PR riddled with wasted time that I could have helped with.
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.
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.
Asking stupid questions from time to time is fine, asking stupid questions all the time while never getting anything done without handholding is not fine and will destroy team morale unless the person is fired.
There's a difference between "is it print or printf in python" and "I'm thinking about architecting this code in this way; what do you think?" I don't think they're talking about the former, and I hope for your team's sake you aren't talking about the latter.
The meeting might be 1 minute shorter, but the 50 minutes of time that one confused person lost when they stopped following for the rest of the meeting is also a waste, as well as the 10 minutes of time it takes the one person they pull aside to catch them up afterwards.
No - 50 minutes a junior spends trying to solve stuff on his own is 50 minutes invested in being more independent I consider that an overall gain.
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.
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.
That might be true for independent development work but not for meetings, which was your original point
If people on the team exhibit a pattern of asking stupid questions, it may reflect poorly on the team, rather than the person asking stupid questions. It could mean there’s a lack of proper training and proper communication, or at the very least a lack of good hiring practices.
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.”
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.”
I try to factor this in by, when someone asks me for help with something of that nature, I first reply "what have you tried so far". Its important, and so I don't feel bad saying "Go try X or lookup Y and then come back and we'll go from there". I feel like it's a reasonable trade off.
As a manager and a hiring manager, the first time you do this, I'd explain to you that software is built and maintained by a team and not individuals, so you need to do a better job figuring out how to help that individual or create documentation so the team as a whole doesn't run into this issue again. The second time you'd do this, I'd explain to you that you're not meeting expectations as a team member and you've got exactly this window to fix things. By the third time you would have been managed out.
Don't do this kind of thing. It's extremely unprofessional.
Don't do this kind of thing. It's extremely unprofessional.
This is like super simple. Every question should be asked, because others may have that question etc etc. The answerer should feel that they can defer the answer until afterwards or something.
I’ve always found its best to operate on the principle of “there are no dumb questions”.
I’ve always found its best to operate on the principle of “there are no dumb questions”.
"There are no stupid questions, only stupid people."
Sorry -- couldn't resist ;-)
Sorry -- couldn't resist ;-)
You might be over-estimating how much attention people are paying to your speed, especially if you recently joined.
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.
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.
Glad to see that most people agree with you. I've had a recent experience where I assumed this would be the case but it turns out I was underestimating how much attention my manager was paying to my speed, even just a couple months after being on the team.
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).
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).
> I was underestimating how much attention my manager was paying to my speed
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".
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".
This has been my experience as well, viewed from both sides.
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.
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.
One thing I always beg for at the beginning of a tenure is for scathing code reviews. Tell me everything your heart desires, if you have the time. The more we get of the way early, the less we need to worry when our minds are in sync.
I second this. If I had to rank in order of preference it's good and fast then good then fast. Don't assume speed is an issue unless you're being told so. Focus on good, speed will follow once you learn. It's a practicable skill.
Agreed. It takes time to come up to speed on a new codebase and with new co-workers. Be patient.
Without any further details I would suggest that this is entirely a communication issue and not one of code quality. "Good code" is not really something that can be defined, and learning general design patterns might help you in a general sense but I don't think it's going to fix this problem you're currently having. If your team is outright rejecting your PRs then knowing one other pattern or learning functional programming are not going to help you.
Next time you're writing something of any significance, speak to the people on your team who will be reviewing the PR. If you aren't sure of how to design it, come up with a design collectively. If you do have an idea, ask them to approve it on a high-level before you write any code. The entire thing should be a collaboration, not you coding for however many days before finally exposing your code to your team in the form of a PR.
This can be easier said than done, depending on how communication works at your company and on your team, but if your team and the people reviewing your code won't guide you a bit before and during your implementation of something then again I don't think knowing a couple more patterns is going to solve this problem.
Next time you're writing something of any significance, speak to the people on your team who will be reviewing the PR. If you aren't sure of how to design it, come up with a design collectively. If you do have an idea, ask them to approve it on a high-level before you write any code. The entire thing should be a collaboration, not you coding for however many days before finally exposing your code to your team in the form of a PR.
This can be easier said than done, depending on how communication works at your company and on your team, but if your team and the people reviewing your code won't guide you a bit before and during your implementation of something then again I don't think knowing a couple more patterns is going to solve this problem.
> I've been forced to change my design more than once during code review
Ouch. It should be quite rare to change your design after code review. Something is wrong here - either you've done something really unusual or your PR reviewers are being overly critical.
If your design is off, or it is way out of step with the usual style of your team, it's very late to change that during PR. There's a huge time cost, and it would be dispiriting for you.
I suggest requesting some pairing during your work on your next feature to get you up to speed with what the team expect. It's far more efficient to get guidance beforehand than retrospectively.
If your team is not keen on the idea of pairing, then getting a colleague to discuss your approach before starting might be useful.
If you want some specific recommendations, learn some functional programming techniques and read the classic programming books. /Clean Code/ has dated badly in some ways (try to ignore some of the crazier ideas) but it is excellent at provoking thoughts about how to lay out code.
Ouch. It should be quite rare to change your design after code review. Something is wrong here - either you've done something really unusual or your PR reviewers are being overly critical.
If your design is off, or it is way out of step with the usual style of your team, it's very late to change that during PR. There's a huge time cost, and it would be dispiriting for you.
I suggest requesting some pairing during your work on your next feature to get you up to speed with what the team expect. It's far more efficient to get guidance beforehand than retrospectively.
If your team is not keen on the idea of pairing, then getting a colleague to discuss your approach before starting might be useful.
If you want some specific recommendations, learn some functional programming techniques and read the classic programming books. /Clean Code/ has dated badly in some ways (try to ignore some of the crazier ideas) but it is excellent at provoking thoughts about how to lay out code.
Review your own code before asking for somebody else to review it.
My personal routine: before pushing code on the repo, run git rebase -i, review all your commits and change them if anything looks wrong (the commit message, some random crap being mixed with the actual content of your commit, silly mistakes, etc.). It will cost you around 2 minutes per commit maximum, and your pull request's quality will increase dramatically.
Also, git add -p when committing to review your work as soon as possible.
My personal routine: before pushing code on the repo, run git rebase -i, review all your commits and change them if anything looks wrong (the commit message, some random crap being mixed with the actual content of your commit, silly mistakes, etc.). It will cost you around 2 minutes per commit maximum, and your pull request's quality will increase dramatically.
Also, git add -p when committing to review your work as soon as possible.
This is great advice in general. Git is one of the best tools to help you organize your thoughts into digestible chunks, and a skill that I've consistently found to correlate with poor code at review time. One of the things that always enabled me to write high-quality documentation or reports is the constant review. Re-read each paragraph as you write them, iterate while your mind is on topic. If you write it lazily the first time, and never go back until you wish to review the entire feature, you may have already destroyed your time and effectiveness of your implementation.
It's a little difficult to give OP advice on their situation when it's unknown what product or workflow they're in. I've always found that if I'm taking too long testing or debugging, it might be a problem with the projects toolchain. If developers don't put in the time to make their projects testable and debuggable, those man hours will be eaten up over time.
It's a little difficult to give OP advice on their situation when it's unknown what product or workflow they're in. I've always found that if I'm taking too long testing or debugging, it might be a problem with the projects toolchain. If developers don't put in the time to make their projects testable and debuggable, those man hours will be eaten up over time.
You only get better with more coding experience. Try to learn from your mistakes. Most important, you are not your code. Don’t take it personal.
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
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
While I think coding experience matters, I've seen a lot of people with years of experience that never worked in environments favouring quality, who write functioning but very ugly code.
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.
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.
What I've found over 15 years is that 'good practice' various from place to place. All I'm really doing each new job is learning the local religion.
When I was still a coder - I moved on after a few years - I noticed that working long hours made my work quality suffer.
The 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.
The 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.
It's kind of funny how no one will admit in front of the boss that 4 hours of development a day is enough, but all developers I've talked with outside their work environment seem to think the same.
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.
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.
Yeah, sometimes I do fall in this vicious circle of overwork / decrease in productivity. Trying myself to get out of it, but the stress/anxiety surrounding a deployment/making a mistake is way too high for me to decisively get out of it.
Yeah, and that is the actual self-fulfilling prophecy. You make what you actually are afraid of happen by behaving in a way that causes the quality issues to appear.
Is it 4h for every person? Are there people who can do it for 12h every day, 7 days a week while delivering quality code and not getting burnt out?
I've been coding for >25 years, and leading teams for most of that.
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.
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.
It's always interesting to read about different management styles. As someone who leads a large development team, this breaks two of my golden rules. 1) Don't micromanage and 2) Don't assume a "Daddy knows best" attitude. At the end of the day, we're shipping a product and as long as everyone is meeting their expected goals, I don't really care if they spend 8 minutes or 80 hours in the office. I tell my kids when to go to sleep, not my employees. If they want to work longer hours and get more done, they'll receive comp time and a nice bonus.
I get that, except I've had to send people home who were clearly past the point where they were doing any good, but felt that they "should" stay and get the thing finished. There's a lot of that kind of thing around - people feeling that they need to work long hours in order to keep their job, or show that they're committed, or whatever. Sending them home deliberately reinforces a culture of not doing that, of being responsible.
Working longer hours does not "get more done". It just creates more problems.
Working longer hours does not "get more done". It just creates more problems.
Sure, some people can work longer than others but they also may get sick more often then. A friend of mine used to work 10h/12h and then game at night but was chronically ill with his skin. It only really got better when he went on vacation.
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.
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.
4h seems to be an accepted limit of any focussed creative activity. After that the quality of your output will start to decline until you're just giving yourself bugs to fix tomorrow.
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.
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.
Based on pretty much everything I have seen and read, no one can work 12h every day, 7 days a week and deliver quality. Simple, such person does not exist. People can spend a lot time in work doing all kind of adjacent stuff - staring into wall during long meetings, talking with colleges, staring into screen, etc etc. Too much overtime also leads to a lot of fixing of mistakes that did not had to be. No socialization outside of work invariably means a lot of unnecessary long meetings, because people need to talk and this is their chance.
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.
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.
It's less for me because by the time I get to work my mind has been running at 100mph since I woke up, thinking about physics or maths or the book I'm trying to write. I wear myself out within hours of waking up. By mid afternoon I'm wacked. Been the same all my life :(
It would really help if you gave us what feedback and questions on skills you exactly get and language you use. Anyway, stop focusing on speed. Focus on learning. Instead, take notes of what they complain about and systematically learn more about thing they say was wrong.
1.) It may be that you learn different standard of coding practices, they vary a lot between companies. Each company have groupthink of "this is definitely necessary" other companies never heard of or have completely opposite groupthink.
2.) It may be that you miss some fundamental skills, but it is hard to guess which it could be and point you to right direction without knowing more.
3.) Another orthogonal option: you might run into alpha coders making themselfs feel good and look great by overly criticising others. I am adding this as possibility, because that absolutely exists.
To distinguish 3, start taking notes of what feedback you get. First, if they are contradictory, then you know it is situation you are in. Second, that will allow you to not make similar mistake again, learn local culture and habits.
1.) It may be that you learn different standard of coding practices, they vary a lot between companies. Each company have groupthink of "this is definitely necessary" other companies never heard of or have completely opposite groupthink.
2.) It may be that you miss some fundamental skills, but it is hard to guess which it could be and point you to right direction without knowing more.
3.) Another orthogonal option: you might run into alpha coders making themselfs feel good and look great by overly criticising others. I am adding this as possibility, because that absolutely exists.
To distinguish 3, start taking notes of what feedback you get. First, if they are contradictory, then you know it is situation you are in. Second, that will allow you to not make similar mistake again, learn local culture and habits.
First of all, there is absolutely no shame in getting significant comments on a change or even in abandoning and redoing it entirely. It's too bad that your lead has let the idea that this is shameful fester. That is the point of code reviews. In fact I think the answer to your question of how to improve is exactly what you're doing: get lots of feedback on your code, really pay attention to it (instead of feeling defensive and ashamed, try to really understand why they are making the comment, think through what problems that are foreseeing), and try really hard to proactively take those comments into account for your next change. After that, the next best thing to do is to go read other peoples' changes. See what kinds of things they're doing and what kind of comments they're getting.
You sound to me like every early career employee experiencing imposter syndrome. That feeling might not ever really go away, but you're probably doing much better than you think.
You sound to me like every early career employee experiencing imposter syndrome. That feeling might not ever really go away, but you're probably doing much better than you think.
"there is absolutely no shame in getting significant comments on a change"
I had a manager who used number of comments received on your PRs as a key metric for code quality (high=bad, low=good), and number of comments you left as a key metric for productivity (leave many comments = good reviewer). It was all numbers based with him-- LOC metrics and the like were huge as well. Every day I worked for him I asked myself "Why do I choose to do this for a living?"
I had a manager who used number of comments received on your PRs as a key metric for code quality (high=bad, low=good), and number of comments you left as a key metric for productivity (leave many comments = good reviewer). It was all numbers based with him-- LOC metrics and the like were huge as well. Every day I worked for him I asked myself "Why do I choose to do this for a living?"
This sounds like hell, and just proves again that wrong metrics are way worse than no metrics at all. You wrote "I had a manager" so I assume you took corrective action :)
Neither quality nor velocity can be quantified. Keep that in mind when defending your changes.
As to design, it is also often very subjective. Some designs lead to less code: this at least is measurable. Others are outright clearer but this is less measurable. When discussing maintainability, stay focused on _realistic_ scenarios: what if we need to add an X, to handle Z in addition to Y. If you think a possible generalisation is not realistic, refer to your manager or with peers, head to head.
More important than design, get confidence that your algorithm is correct and show it. Show that you thought of corner cases and handled some of them, traced those you do not handle.
As to performance, be very clear about it: performance can only be _measured_. If you and a reviewer disagree on assumed performance, candidly ask if there is time to implement both alternatives and profile them. If you know your code will be less than efficient when some data gets too big, comment it in the code and explain why this is acceptable for now.
Oh and if there are comments on style, ask the coding conventions in force. When you have them _respect_them_ and refuse further changes on things that are left unspecified.
Finally, talk to people head to head (or by phone) and not only through the review system, where things escalate quickly. Sometimes you will learn new technical stuff, sometimes the reviewer will admit "maybe my proposition does not apply in your case". In any case you would have learned something and increased your understanding of the problem to solve.
As to design, it is also often very subjective. Some designs lead to less code: this at least is measurable. Others are outright clearer but this is less measurable. When discussing maintainability, stay focused on _realistic_ scenarios: what if we need to add an X, to handle Z in addition to Y. If you think a possible generalisation is not realistic, refer to your manager or with peers, head to head.
More important than design, get confidence that your algorithm is correct and show it. Show that you thought of corner cases and handled some of them, traced those you do not handle.
As to performance, be very clear about it: performance can only be _measured_. If you and a reviewer disagree on assumed performance, candidly ask if there is time to implement both alternatives and profile them. If you know your code will be less than efficient when some data gets too big, comment it in the code and explain why this is acceptable for now.
Oh and if there are comments on style, ask the coding conventions in force. When you have them _respect_them_ and refuse further changes on things that are left unspecified.
Finally, talk to people head to head (or by phone) and not only through the review system, where things escalate quickly. Sometimes you will learn new technical stuff, sometimes the reviewer will admit "maybe my proposition does not apply in your case". In any case you would have learned something and increased your understanding of the problem to solve.
"there were other times when my PR was outright rejected as it did not meet the required standards"
Are these standards published? If not then how are you expected to meet "required standards" that are not published? If so then why are you not reviewing your code yourself prior to the PR? Is training and/or mentorship provided for you to come up to speed with the required standards? Something seems off about this situation.
Are these standards published? If not then how are you expected to meet "required standards" that are not published? If so then why are you not reviewing your code yourself prior to the PR? Is training and/or mentorship provided for you to come up to speed with the required standards? Something seems off about this situation.
This is more common than it may seem.
I've worked in at least two teams where there were those non-written "standards" which one learned only after a few lengthy code reviews.
Usually a sign of people trying to cargo-cult themselves to good code.
At least one time it was simply a case of gatekeeping so that other developers wouldn't threaten that person's position.
I've worked in at least two teams where there were those non-written "standards" which one learned only after a few lengthy code reviews.
Usually a sign of people trying to cargo-cult themselves to good code.
At least one time it was simply a case of gatekeeping so that other developers wouldn't threaten that person's position.
That's toxic. Especially when you're making junior developers feel they're not doing a good job because their PRs are being rejected for not adhering to not-published standards. Wow. I'd be looking for another job in a heartbeat. Life is too short to be working with people like that.
I often practice test driven development. This can help, especially in dynamic languages, to structure your code in a way that forces you to keep it simple.
1. Write the test first, start with the smallest cases.
2. Write the code to make the test pass, the first thing that comes to mind which works.
3. Refactor what you just wrote. Use functions to remove unnecessary intermediate variables, avoid repetitive code by extracting common patterns, turn literals into parameters constants, etc.
4. Add another test, usually an inductive step. If your base case, smallest input is n, try writing a test that should pass for n+1.
5. Repeat 2-3 until the new test passes.
6. Add the smallest edge cases that should return an error result or fail.
7. Repeat 2-3 until the new test passes.
Keep building up those tests as you go. They should form a low-level specification of a module, class, or function that suits your needs.
Some high-level principles to think about when coming up with tests:
1. Parse, don't validate! [0] Code that takes data in from the outside world should do it best to parse it into an acceptable structure as early as possible so that code down stream doesn't have to check if the data it receives is valid or not.
2. Push effects to the edge If something has to talk to the outside world make sure it happens in, ideally, one place. Writing tests first ensures that your code is easy to test so putting effect-full code all over the place is painful.
3. There are different kinds of correct. Know ahead of time what success will be for your task. Passing tests is one kind of correctness. Functional correctness of the system is another -- you will want to reach to tools like TLA+ or Alloy to write specifications for the latter.
4. Talk to your team. Sketch out your ideas first and shop them around and spit ball them with other experienced team members. Get their take on it before you start coding.
[0] https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
update forgot the link
1. Write the test first, start with the smallest cases.
2. Write the code to make the test pass, the first thing that comes to mind which works.
3. Refactor what you just wrote. Use functions to remove unnecessary intermediate variables, avoid repetitive code by extracting common patterns, turn literals into parameters constants, etc.
4. Add another test, usually an inductive step. If your base case, smallest input is n, try writing a test that should pass for n+1.
5. Repeat 2-3 until the new test passes.
6. Add the smallest edge cases that should return an error result or fail.
7. Repeat 2-3 until the new test passes.
Keep building up those tests as you go. They should form a low-level specification of a module, class, or function that suits your needs.
Some high-level principles to think about when coming up with tests:
1. Parse, don't validate! [0] Code that takes data in from the outside world should do it best to parse it into an acceptable structure as early as possible so that code down stream doesn't have to check if the data it receives is valid or not.
2. Push effects to the edge If something has to talk to the outside world make sure it happens in, ideally, one place. Writing tests first ensures that your code is easy to test so putting effect-full code all over the place is painful.
3. There are different kinds of correct. Know ahead of time what success will be for your task. Passing tests is one kind of correctness. Functional correctness of the system is another -- you will want to reach to tools like TLA+ or Alloy to write specifications for the latter.
4. Talk to your team. Sketch out your ideas first and shop them around and spit ball them with other experienced team members. Get their take on it before you start coding.
[0] https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
update forgot the link
Talk about your idea before coding it up. Whiteboard it with someone. Try to guess how people will react. Over time, you'll train yourself to know the reactions and to shape your work to fit expectations.
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.
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.
Talk to your line manager. It is quite possible that there are some skills around building long-term maintainable codebases that you haven't learnt yet. Different companies have vastly different ideas about what 'good enough' looks like, and so this may be the first time you've had to think about these particular issues.
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.
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.
My suggestions for higher quality is to spend more time:
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.
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.
I have a saying that I use to annoy my boss when he demands things are done too quickly: "Why do it right when you can do it twice?"
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.
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.
I am working in web-dev at the moment and to be completely honest i have professional projects where i often push ridiculously chaotic code, because of time restraints.
I feel like most times i could have chosen a better way to do things, but i have to get things done quickly because the todo list is so long. It's difficult choice between technical debt versus slow but beautiful/robust architecture.
Working in my own company i often weigh the options between pushing often and fast, having a good deployment process that you can easily rollback, good error notification and being good in a debugger versus slow mindful development.
Trust me i would like to slow way down and really think things through, make interesting diagrams, think about the philosophy of different process and scenarios, drink a good cup of coffee and look out the window for half an hour pondering - but i feel like that's a privilege i don't have right now.
Though i try to meditate and to take a step back every day to slow things down and get a better overview.
I also feel like internet surfing, stack overflow, and screen use in general trains you quickly to get a completely fragmented way of focusing and remembering that we all need to actively fight if we want to regain clarity, focus, insight or beauty in what we do.
I feel like most times i could have chosen a better way to do things, but i have to get things done quickly because the todo list is so long. It's difficult choice between technical debt versus slow but beautiful/robust architecture.
Working in my own company i often weigh the options between pushing often and fast, having a good deployment process that you can easily rollback, good error notification and being good in a debugger versus slow mindful development.
Trust me i would like to slow way down and really think things through, make interesting diagrams, think about the philosophy of different process and scenarios, drink a good cup of coffee and look out the window for half an hour pondering - but i feel like that's a privilege i don't have right now.
Though i try to meditate and to take a step back every day to slow things down and get a better overview.
I also feel like internet surfing, stack overflow, and screen use in general trains you quickly to get a completely fragmented way of focusing and remembering that we all need to actively fight if we want to regain clarity, focus, insight or beauty in what we do.
Beware Imposter syndrome - it's likely you are over thinking this
Second, what is a decent speed of delivery? The thing that most affects speed of delivery is familiarity with the code base. The major, probably only reason senior devs are senior is because they are senior in that codebase. Pluck someone from Facebook and drop them in Google and they will face problems similar to you. Good ones will explore on their own, familiarise themselves, find mentors and build relationships to ask and guide themselves - and even write posts on HN to get guidance!
Thirdly, expecting speed of delivery is the fastest way to destroy a team - or a coherent codebase. People get panicked and either drastically drop their productivity or choose to code really safely, driving code reviewers / team leads to spend more time on managing - whereas removing project managers from the critical path and having an engineering quality as the prime driver is a major help (You night think you are being rejected because quality is too low (and that maybe) but what are the senior devs being driven by? deadlines or quality? That will affect the time they have for mentoring.
This fear is all pervasive - senior devs do t want to venture out of their comfort areas, partly due to time constraints (see project management) and partly fear of not knowing how to intersect with other codebases and people.
passing over code patches to another team is always an act of human relationships - you need time to get up to speed with the codebase, they need good patches to trust you and they need to give you time and mentoring to understand the code base and their taste.
Long story short - asking this is a good sign about you and a bad sign about the mentoring process you are under.
Second, what is a decent speed of delivery? The thing that most affects speed of delivery is familiarity with the code base. The major, probably only reason senior devs are senior is because they are senior in that codebase. Pluck someone from Facebook and drop them in Google and they will face problems similar to you. Good ones will explore on their own, familiarise themselves, find mentors and build relationships to ask and guide themselves - and even write posts on HN to get guidance!
Thirdly, expecting speed of delivery is the fastest way to destroy a team - or a coherent codebase. People get panicked and either drastically drop their productivity or choose to code really safely, driving code reviewers / team leads to spend more time on managing - whereas removing project managers from the critical path and having an engineering quality as the prime driver is a major help (You night think you are being rejected because quality is too low (and that maybe) but what are the senior devs being driven by? deadlines or quality? That will affect the time they have for mentoring.
This fear is all pervasive - senior devs do t want to venture out of their comfort areas, partly due to time constraints (see project management) and partly fear of not knowing how to intersect with other codebases and people.
passing over code patches to another team is always an act of human relationships - you need time to get up to speed with the codebase, they need good patches to trust you and they need to give you time and mentoring to understand the code base and their taste.
Long story short - asking this is a good sign about you and a bad sign about the mentoring process you are under.
* Learn to think about types first, and the algorithms as a natural consequence of the structure of your data. Richard Feldman: https://www.youtube.com/watch?v=IcgmSRJHu_8,
* 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.
* 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.
Came here to say something similar: Learn a functional language.
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
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 agree with you 100% and will amplify your comment with one of my own.
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.
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.
They say if you're the smartest person in the room, you're in the wrong room.
That you're being challenged, while it's difficult and you might not see it now, is ultimately a good thing. The uncomfortable feeling you're describing is called growth. The caliber of people around you is forcing you to grow, and that's going to be very helpful to you as a developer.
Seek out a mentor and actively seek their advice. Most people love helping others. The most important thing is that you don't try to hide from them, but that you're willing to openly discuss your areas of weakness and seek improvement. It's hard, but people will appreciate that.
It's true, people won't have patience for someone who isn't honest and delivers what they see as low quality work at the last minute, but they have tons of patience and even respect for the person who actively solicits and integrates feedback.
That you're being challenged, while it's difficult and you might not see it now, is ultimately a good thing. The uncomfortable feeling you're describing is called growth. The caliber of people around you is forcing you to grow, and that's going to be very helpful to you as a developer.
Seek out a mentor and actively seek their advice. Most people love helping others. The most important thing is that you don't try to hide from them, but that you're willing to openly discuss your areas of weakness and seek improvement. It's hard, but people will appreciate that.
It's true, people won't have patience for someone who isn't honest and delivers what they see as low quality work at the last minute, but they have tons of patience and even respect for the person who actively solicits and integrates feedback.
Is there a way I can email you? Off topic I know but just wanted to follow up on that other thread about Houston. My gmail is my HN handle.
I've emailed you.
I'm the founder of a startup that focusses on tech debt. (Context: mini survey app that sits in GitHub/Lab so the team can track what needs fixing)
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 :)
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 :)
Careful with social proofs. Normalizing deviance and groupthink are real phenomena.
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.
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.
Agreed - care is needed here!
Curious if you can see a way that an automated functional test could pick up on the quality of design?
Curious if you can see a way that an automated functional test could pick up on the quality of design?
Advice someone gave me in a similar situation: coding requires Mise en Place like cooking. Mise en Place is setting everything up and prepping before you start cooking so everything is easy to access.
In coding, this means thinking through how you're going to structure it, have answers for what pieces of code use service calls and what needs to be its own modules. Think about the data and what it looks like: what fields and names does this have? Does it require a set or list collection?
Following up on that train of thought watch the Simple Made Easy talk and really try to internalize what he means when he talks about design.
https://www.infoq.com/presentations/Simple-Made-Easy/
In coding, this means thinking through how you're going to structure it, have answers for what pieces of code use service calls and what needs to be its own modules. Think about the data and what it looks like: what fields and names does this have? Does it require a set or list collection?
Following up on that train of thought watch the Simple Made Easy talk and really try to internalize what he means when he talks about design.
https://www.infoq.com/presentations/Simple-Made-Easy/
I think one thing that may help that I haven't seen mentioned yet, is to read the codebase you are working on (not all of it, unless it's smaller than a novel)
Pick a certain starting point and follow it down the rabbit hole. Rinse and repeat.
A couple things I find helpful about this practice is: one, it let's you compare the over all architecture against the true implementation (which can vary), and two, it gets you comfortable with the implied standards--the things that can't/don't get written on a style guide (e.g. they keep prepared statements in a separate, common file)
Pick a certain starting point and follow it down the rabbit hole. Rinse and repeat.
A couple things I find helpful about this practice is: one, it let's you compare the over all architecture against the true implementation (which can vary), and two, it gets you comfortable with the implied standards--the things that can't/don't get written on a style guide (e.g. they keep prepared statements in a separate, common file)
First: read the book "Code Complete" from Steve McConnell. You don't have to read it sequentially, go right to the parts that you have more feedback in your reviews.
Second: take your code reviews as a great learning opportunity. Don't let it take you down. You are probably getting the "Impostor Syndrome", and it is a good thing since you now know that you need to improve. Take the review process as feedback about how to improve. This is Deliberate Practice at its best.
Second: take your code reviews as a great learning opportunity. Don't let it take you down. You are probably getting the "Impostor Syndrome", and it is a good thing since you now know that you need to improve. Take the review process as feedback about how to improve. This is Deliberate Practice at its best.
Meditate.
No, I'm seriously.
- - - -
Read "Thinking Forth" by Brodie ( http://thinking-forth.sourceforge.net/ ) and "Programming Pearls" by Jon Bentley ( https://archive.org/details/ProgrammingPearls2ndEditionJonBe... ) and sleep on them.
No, I'm seriously.
- - - -
Read "Thinking Forth" by Brodie ( http://thinking-forth.sourceforge.net/ ) and "Programming Pearls" by Jon Bentley ( https://archive.org/details/ProgrammingPearls2ndEditionJonBe... ) and sleep on them.
> I usually take 3-4 tries with some significant amount of testing to get my code to a working state.
This is probably the biggest problem. You are thrashing on a cycle of testing because your code didn't work properly the first time. Getting it right the first time, even if it feels slow, is usually faster than fixing it later.
In my experience this is what happens when developers focus on the "happy path", i.e. spending most of your time assuming your code will run in a perfect world, and writing tests to prove it.
You may want to try working backwards from the tests -- decide how your code should behave, especially in bad situations where inputs are null or your dependencies throw exceptions or your API calls fail. Write the tests, and then fix your code to make the tests pass. Use coverage tooling to make sure you covered what you thought you did.
If you still have problems, try asking some of your colleagues to spend half an hour with you to review your code before you submit it for review. Some of them will probably be happy to help the new guy, especially if you are trying to do a better job meeting their expectations.
This is probably the biggest problem. You are thrashing on a cycle of testing because your code didn't work properly the first time. Getting it right the first time, even if it feels slow, is usually faster than fixing it later.
In my experience this is what happens when developers focus on the "happy path", i.e. spending most of your time assuming your code will run in a perfect world, and writing tests to prove it.
You may want to try working backwards from the tests -- decide how your code should behave, especially in bad situations where inputs are null or your dependencies throw exceptions or your API calls fail. Write the tests, and then fix your code to make the tests pass. Use coverage tooling to make sure you covered what you thought you did.
If you still have problems, try asking some of your colleagues to spend half an hour with you to review your code before you submit it for review. Some of them will probably be happy to help the new guy, especially if you are trying to do a better job meeting their expectations.
"slow is smooth, smooth is quick" - always loved this quote.
this. Think more, type less.
Go for a walk/run and think about the problem, draw it out in your head and play around with different options. Then start typing.
this. Think more, type less.
Go for a walk/run and think about the problem, draw it out in your head and play around with different options. Then start typing.
If there is a chance to work with a mentor on your coding skills, grab it and start engaging in it. Having a mentor gives you a platform to sound out your techniques, doubts and ideas. Also a platform for you to received the right questions.
The velocity is only important to managers when they are using it for comparison against other engineers when doing performance reviews. Focus on getting it right the first time.
The velocity is only important to managers when they are using it for comparison against other engineers when doing performance reviews. Focus on getting it right the first time.
Lots of good advice in this thread but I would add something: your designs will almost always be wrong in some important ways because without implementing them you almost certainly don’t fully understand the trade offs. It’s better to have a culture where going back and rewriting things as new learning happens is accepted and expected, with an eye toward reducing complexity.
My personal opinion is that "Good Code Quality" is from good communication to the person reading the code.
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
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
Doing a lot of testing is totally fine. I recently got into a "Lead Developer" position and if I get a PR that is not well tested, the time I waste testing something that doesn't work is worse than waiting for the developer to properly test the thing before passing it on to me. I'd rather wait a bit more but be 99% sure that I could merge without additional testing. So, from my perspective, taking a bit more time with testing is no issue as long as you actually test all edge cases and your higher-up knows they can rely on your ability without having to double check everything.
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.
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.
It's hard to help without knowing what languages you work with and what kind of feedback you're getting.
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.
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.
Practice, practice, practice. Shave days of waste every year by having great documentation tools on your machine and LEARN the tools you use most so you can skip the google. Invest these saved hours into more important tasks.
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.
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.
What's critical here is onboarding. Perhaps your code is "fine" from a different perspective, but because it doesn't fit in with existing conventions, styles, libraries, helper functions, ect, it needs to be refactored?
For example, I work on a C# product. We have particular patterns for dependency injection, events, and multithreading. A newcomer from a different department once made a pull request that used static singletons and different event semantics.
In this case, the newcomer gave a lot of pushback because we do things differently than the textbook examples of C# that they're used to. Our way meets the design needs of our product, thus it's the "right" way. The way that this developer made changes would be "correct" in a different product with different design needs and conventions.
Normally, we avoid this by spending time with newcomers to explain the styles and patterns in our codebase. (In this case, this person from another department wasn't onboarded and just surprised us with a pull request.)
We do document our coding style and design patterns; but it's important to point out that documentation is no replacement for common sense.
If you've made it this far:
1: Professional programming isn't art or poetry; it's all about the finished product. Computer code is NOT a place for your self expression or creativity. (If that's important to you, go make some Wordpress themes or hack some other program to be skinned.)
2: It's important that professional code has consistent style and design patterns, otherwise it's extremely hard to read each time a module uses a different style.
2.5: Thus, the most important part of good style is trying to fit in with the existing style whenever possible. (IE, if you use tabs, but everyone else uses spaces, you need to switch to spaces.)
3: If this is a case of "growing pains," take the time to document your codebase's style, design patterns, ect.
For example, I work on a C# product. We have particular patterns for dependency injection, events, and multithreading. A newcomer from a different department once made a pull request that used static singletons and different event semantics.
In this case, the newcomer gave a lot of pushback because we do things differently than the textbook examples of C# that they're used to. Our way meets the design needs of our product, thus it's the "right" way. The way that this developer made changes would be "correct" in a different product with different design needs and conventions.
Normally, we avoid this by spending time with newcomers to explain the styles and patterns in our codebase. (In this case, this person from another department wasn't onboarded and just surprised us with a pull request.)
We do document our coding style and design patterns; but it's important to point out that documentation is no replacement for common sense.
If you've made it this far:
1: Professional programming isn't art or poetry; it's all about the finished product. Computer code is NOT a place for your self expression or creativity. (If that's important to you, go make some Wordpress themes or hack some other program to be skinned.)
2: It's important that professional code has consistent style and design patterns, otherwise it's extremely hard to read each time a module uses a different style.
2.5: Thus, the most important part of good style is trying to fit in with the existing style whenever possible. (IE, if you use tabs, but everyone else uses spaces, you need to switch to spaces.)
3: If this is a case of "growing pains," take the time to document your codebase's style, design patterns, ect.
Read Clean Code (they are in video form) or Code Complete 2 and Refactoring books and LEARN what makes a design better than another. Talk with your colleagues about design choices in person and ask why they think one design is better than another. I truly think it's learnable.
Everyone in a team has their own style of coding and designing. It becomes necessary to have a common agreement in a team environment. There are cases where we have to change our design or refactor to align with overall infrastructure and goals.
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.
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.
> 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.
If this is happening once you're in an integrated environment, then it is too late. A strong test driven development culture in the organization can help with this, and improve design - but if it's not already there, it's hard to justify the investment without first proving you can write quality code.
If this is happening once you're in an integrated environment, then it is too late. A strong test driven development culture in the organization can help with this, and improve design - but if it's not already there, it's hard to justify the investment without first proving you can write quality code.
Something I often tell junior developers:
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).
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).
[deleted]
One thing that I think would help (and would've helped the person's pr that I _just_ reviewed) is to look at the diffs that would be included, make sure the intentions / logic is clear...
As an example from said pr, a new field was added named "other"... in this particular context this doesn't have any meaning at all.. I had to look into the sql changes to see what this data was then add the suspected real name as a suggestion in the code review... don't do things like that :D...
So, all that to say, look at your diffs and do your own code review before you submit it.. make sure what you want to do is clear and makes sense...
As an example from said pr, a new field was added named "other"... in this particular context this doesn't have any meaning at all.. I had to look into the sql changes to see what this data was then add the suspected real name as a suggestion in the code review... don't do things like that :D...
So, all that to say, look at your diffs and do your own code review before you submit it.. make sure what you want to do is clear and makes sense...
A lot of great comments and suggestions. Something that I usually share with new developers is to get a feel for the machine. Get to know the system and its architecture even if you are writing your programs in a high level language. Try to imagine the computer as a friend that is fulfilling your request using its organs, the cores, the memory, the registers, the L1 and L2 cache and so on. Put yourself in its shoes and have some empathy for it. The discipline is usually referred to as mechanical sympathy and some of the best software I have used and studied was built around these principles.
Can’t really judge the kind of feedback you’re getting but larger companies have their own set of standards partially driven by problems they had to solve partially driven by whatever the alpha programmer(s) decided upon.
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.
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.
I would focus on making your PRs as small as possible. I think what you want to aim for here is getting consistent about merging some small amount of code every day; writing the code is the easy part, going through the review and addressing the feedback is the hard part. If you keep the code small, the review will be small. Then when you repeat the process tomorrow, you'll be able to take into account all the learnings from yesterday's review. Eventually review time will be shorter and your changes will get larger.
>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.
Check the PRs and read the existing code from others inside the company. Presumably those meet the company's standards, and will give you hints how to structure yours.
Read a couple of industry standard books like Clean Code and Code Complete too.
Check the PRs and read the existing code from others inside the company. Presumably those meet the company's standards, and will give you hints how to structure yours.
Read a couple of industry standard books like Clean Code and Code Complete too.
Try to get better at writing code that is easy to refactor. Good code is rarely written in one pass, but in iterative refinements.
So, instead of trying to get the definite code from the get go, start with a simple design (yagni and kiss) and evolve from that.
But there is no silver bullet. You can get faster but not by orders of magnitude. Quality code takes time.
Personally, I go after the feeling I had when I studied programming in the 90s. Simple algorithms that manipulate strings, ints, etc. and no so much after abstraction and composition.
So, instead of trying to get the definite code from the get go, start with a simple design (yagni and kiss) and evolve from that.
But there is no silver bullet. You can get faster but not by orders of magnitude. Quality code takes time.
Personally, I go after the feeling I had when I studied programming in the 90s. Simple algorithms that manipulate strings, ints, etc. and no so much after abstraction and composition.
I'd say that you should try pairing more. First to just discuss about validation on getting the problem right, then agreeing at least with someone else about the approach for the solution so you dissolve potential tensions about your new code. The goal of that is the opposite of surprising designs: gradual expected innovation.
If that works well and you and your team like each other, then you can go on. If that bare minimum is not working then find a new team a and start from day zero with this approach.
If that works well and you and your team like each other, then you can go on. If that bare minimum is not working then find a new team a and start from day zero with this approach.
If your at one of the "sought after" companies they have resources for you. Go to your manager for a one on one and ask for help. Where are the code standards, what classes resources do they have to better your design chops. Outside of manager look for someone who has beens there a while and is willing to mentor you.
If you don't get support from your current manager start looking to switch teams to find a manager that is geared towards developing you and making you a success.
If you don't get support from your current manager start looking to switch teams to find a manager that is geared towards developing you and making you a success.
You should probably stop thinking about your velocity for a while and instead focus on quality.
For your design phases, think thoroughly about all possible solutions and detail the pros/cons of each, then get it reviewed by your colleagues and iterate on that. The design phase might be slow, and it is OK. At least when you will end up implementing something it is likely to be of much better quality.
After a while this will become natural and your velocity will naturally go up.
For your design phases, think thoroughly about all possible solutions and detail the pros/cons of each, then get it reviewed by your colleagues and iterate on that. The design phase might be slow, and it is OK. At least when you will end up implementing something it is likely to be of much better quality.
After a while this will become natural and your velocity will naturally go up.
You are lucky as you are getting a lot of on the job training.
I would suggest swotting up on SOLID principles:
https://cleancoders.com/videos?series=clean-code&subseries=s...
something else you can try is to run your designs by a colleague before/during coding, preferably the same person that will do the code review
something else you can try is to run your designs by a colleague before/during coding, preferably the same person that will do the code review
They hired you because they already believe you will be a valuable contributor. So don't try to impress your colleagues, but rather try to collaborate with them. For example, instead of asking this question here at HN, approach your peer reviewers and ask them about it.
Another advice would be to explain as part of your PR (e.g., in the ticket) which design options you considered and why you chose the one you ended up with.
Another advice would be to explain as part of your PR (e.g., in the ticket) which design options you considered and why you chose the one you ended up with.
Refactoring, thinking, refactoring, thinking... will help you improve current codebase as well as discover new suitable code patterns for your need.
My advice is you should be getting to know your system well before writing code. Look over as many parts of the codebase you can, run unit tests and see how they're all written and put together. Hopefully then you can write in a similar style.
Also I've heard at FANG companies the first few months code reviews will get hammered to make sure people get in line. I'm not sure how accurate that is.
Also I've heard at FANG companies the first few months code reviews will get hammered to make sure people get in line. I'm not sure how accurate that is.
Are there any good ideas to improve one's coding / design skills significantly ?
There might be in the CRs you're mentionning. In other words, my advice would be to get the most out of those CRs as you can. Ask questions, encourage people to be critic with you, understand their point of view and learn. If you CR is rejected, get to the core of why it happened technically.
There might be in the CRs you're mentionning. In other words, my advice would be to get the most out of those CRs as you can. Ask questions, encourage people to be critic with you, understand their point of view and learn. If you CR is rejected, get to the core of why it happened technically.
Being conscious of this and wanting to improve is the first step. Get mentoring earlier on in the process, come up with an approach from a more senior dev before you start, check in regularly.
Your team might just be more opinionated when it comes to design. Some teams I've worked on are very particular about things, some are not.
Your team might just be more opinionated when it comes to design. Some teams I've worked on are very particular about things, some are not.
There's a lot of good advice here for dealing with constructive code reviews. They provide valuable learning opportunities.
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.
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.
Balance. A good programmer can balance between CapEx, OpEx, and business objective delivery depending on the business amount of testing.
> I usually take 3-4 tries with some significant amount of testing to get my code to a working state.
That's pretty normal. Try to use TDD, that is, try to test your code ASAP.
> I usually take 3-4 tries with some significant amount of testing to get my code to a working state.
That's pretty normal. Try to use TDD, that is, try to test your code ASAP.
The only thing you can do is to talk with your colleagues and ask them to help you. Only they can tell you how to improve your code quality, as they are the ones judging you.
You can tell you're at a good company when there are a lot of people that love to help others improve.
Don't think about velocity. Take as long as you need to get to a point where there is no longer any way you can think of to improve it. If you're not routinely pushing yourself to this limit, then you're limiting the extent to which you will grow as a programmer.
Make sure you understand the whole codebase, check their commits to get an idea of what they'd expect. You can of course suggest different approaches, and have constructive discussions, but first try to understand what they've built and adopt their style
> rejected as it did not meet the required standards.
can you give us some examples of this? Do you agree that your design didn't meet the standards?
Its entirely possible that your new team is being mean to you, I'v seen team politics play out in PR reviews.
can you give us some examples of this? Do you agree that your design didn't meet the standards?
Its entirely possible that your new team is being mean to you, I'v seen team politics play out in PR reviews.
Yeah the only way OP will get accurate advice is with an example or two. From my experience, always expect some nasty PRs in the beginning. Just because someone hired you doesn't mean you're entitled to respect, and many teams will make you earn it.
>From my experience, always expect some nasty PRs in the beginning. Just because someone hired you doesn't mean you're entitled to respect, and many teams will make you earn it.
Sounds pretty toxic tbh.
Sounds pretty toxic tbh.
https://softwareengineering.stackexchange.com/ sounds like it might be more appropriate for design questions than stack overflow.
Have you seen reviews for others? You may be surprised they end up in the same situation. If you have a strong team, then changes from the experienced people may be judged just as hard as yours.
I'm not gold plating but I've learned to not compromise on code quality. There is a lower level I will not cross, like an engineer who will not build a car without seat belts.
There’s some nice code beautification plug-ins our there, check them out for some inspiration and use them to help create uniform syntax structuring.
Don't worry- you sound like a completely normal, competent programmer, who is slightly more conscientious than average.
Well, first we should establish what we mean by "quality code". From my standpoint, both as an engineer and as a manager, quality means that the code:
(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
(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
Came here looking for POODR glad I'm not alone in suggesting this most notably TRUE software Transparent Reasonable Usable and Exemplary ought to be the norm in our industry
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 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?
Faster, better, cheaper. Choose two.
An alternative perspective (not a solution!) from my experience:
I currently work at a place in the valley as a senior lead and it is _impossible_ for me to submit a PR without comments/nitpicks requiring fixes. My colleagues seem to always want to change something for some reason, whether or not it is a necessary change. The feedback comes in from all skill levels. Honestly most of the time these changes can be (and should be, IMHO) ignored because of YAGNI and Not Invented Here. I can't count the number of times I have re-designed and implemented something to be more generic/abstract only to have that abstraction whither for _years_ without being used. Oh - and implementing our own wrappers for third party libraries? We do it all the time.
The challenge that I face is every time I get frustrated enough to push back and escalate, ultimately when discussing code reviews and velocity with managers, my colleagues drop the "Q" word and it's an argument-ending trump card: quality. If anyone can argue that any trivial change increases the quality of the code base, or can argue that my PR lowers the repository code quality, the argument is over. Regardless of whether or not it's objectively true, if it's subjectively true the argument is over and ultimately any feedback has to be implemented. Management doesn't budge on quality.
Ultimately though, end users and customers don't care about code quality (but the do care about product quality, there is a difference).
I have worked at this company for 6+ years. The product is uninteresting to me, but the people are actually a really good fit for me. We otherwise work really well together when doing actual problem solving, requirements gathering, manager managing, customer support, etc. It's frustrating to not be able to write code in one pass, but I've learned to 'accept' it - it's the nature of the beast. It's definitely not like this everywhere; I've worked at places that were much better about code reviews and merging code. Code that takes a day to design and get requirements for and a day to code and test will usually take a full week to get merged (not uncommon for it to stretch to two weeks). If management is fine with our velocity, then I guess I ultimately don't care.
Anyway, I recounted all of this for you to give you another data point and perspective. Some places thrive on this sort of torturous review process. I've learned to live with it. It's entirely possible that there is no way for you to 'improve' your way out of review hell. Instead of focusing on reading books and improving your design skills (which you should do anyway!) you might need to learn how to navigate the code review landscape at this new place, either by accepting it or playing the game.
I don't know how to tell you to play the game except get more involved in the review process as early as possible. Figure out what is important to people. I've gotten into the habit of "pre-screening" my reviews with one or two of the most problematic reviewers. I've gotten to the point where I will commit a pass of pseudo-code and have them give me feedback. It makes them feel better and wastes less of my time when it comes time for actual review.
I currently work at a place in the valley as a senior lead and it is _impossible_ for me to submit a PR without comments/nitpicks requiring fixes. My colleagues seem to always want to change something for some reason, whether or not it is a necessary change. The feedback comes in from all skill levels. Honestly most of the time these changes can be (and should be, IMHO) ignored because of YAGNI and Not Invented Here. I can't count the number of times I have re-designed and implemented something to be more generic/abstract only to have that abstraction whither for _years_ without being used. Oh - and implementing our own wrappers for third party libraries? We do it all the time.
The challenge that I face is every time I get frustrated enough to push back and escalate, ultimately when discussing code reviews and velocity with managers, my colleagues drop the "Q" word and it's an argument-ending trump card: quality. If anyone can argue that any trivial change increases the quality of the code base, or can argue that my PR lowers the repository code quality, the argument is over. Regardless of whether or not it's objectively true, if it's subjectively true the argument is over and ultimately any feedback has to be implemented. Management doesn't budge on quality.
Ultimately though, end users and customers don't care about code quality (but the do care about product quality, there is a difference).
I have worked at this company for 6+ years. The product is uninteresting to me, but the people are actually a really good fit for me. We otherwise work really well together when doing actual problem solving, requirements gathering, manager managing, customer support, etc. It's frustrating to not be able to write code in one pass, but I've learned to 'accept' it - it's the nature of the beast. It's definitely not like this everywhere; I've worked at places that were much better about code reviews and merging code. Code that takes a day to design and get requirements for and a day to code and test will usually take a full week to get merged (not uncommon for it to stretch to two weeks). If management is fine with our velocity, then I guess I ultimately don't care.
Anyway, I recounted all of this for you to give you another data point and perspective. Some places thrive on this sort of torturous review process. I've learned to live with it. It's entirely possible that there is no way for you to 'improve' your way out of review hell. Instead of focusing on reading books and improving your design skills (which you should do anyway!) you might need to learn how to navigate the code review landscape at this new place, either by accepting it or playing the game.
I don't know how to tell you to play the game except get more involved in the review process as early as possible. Figure out what is important to people. I've gotten into the habit of "pre-screening" my reviews with one or two of the most problematic reviewers. I've gotten to the point where I will commit a pass of pseudo-code and have them give me feedback. It makes them feel better and wastes less of my time when it comes time for actual review.
Having your PR rejected in a healthy environment means that your PR is radically far from the reviewer's expectation.
Having your PR rejected in a toxic environment can mean a lot of things, and a company sought after doesn't mean that it MUST be not toxic.
First, you have to make sure if both of YOU and YOU ENVIRONMENT is healthy. If both are healthy, proceed reading.
> The challenge here is to deliver good quality code, while maintaining a decent speed of delivery.
You made it sound like producing good quality code = slowness. FALSE. Seeming slow, good quality code boosts your team's velocity. BUT keep in mind: "quality" is "the standard of something as measured against other things of a similar kind; the degree of excellence of something". Your team has its standards, either is a derivative of other globally acknowledged standards such as https://blog.golang.org/go-fmt-your-code, https://github.com/microsoft/TypeScript/wiki/Coding-guidelin..., https://twitter.com/dan_abramov, etc, or self-made standards. You go follow them, make them happy!
Coding and design skill has a different definition than code quality. It is what punches up to the sky: the overall velocity, the success of the team, the balance of growth and culture retainment of the company, the development experience, the users' thumbs ups, amazements, and "this app is life changing" comments, the number of milestone celebration in All You Can Eat restaurants each years, the number of people rising up from junior to senior each years, etcetera etcetera.
Not only you make your team happy with the quality code based on their standards. You must always exercise to always improve your team, whether your team agrees or not AT THAT TIME. Keep searching for improvements, internally and externally. Occasionally fight with your team if you have to, if you have the right cause. And if it turned to be a wrong cause, accept and move on.
So...
> Are there any good ideas to improve one's coding/design skills significantly?
Yes. These are the tricks to a good code/software/system design and architecture:
1. Know the fundamentals! Go lower than frameworks and libraries! Analyze why existing codes are made that way! Think in strings, C, algorithm, data structure! Always pay attention top-down and bottom-up! Think in terms of time and space complexity! Separate complexity from complications! Be thorough.
2. Know the team! Know what is valuable for the team! Understand how your code impacts your team's velocity! Understand the mood of the team and use it! Contemplate how existing processes help or hinder the team! Consider suggesting to add or remove them if necessary! Make interfaces for others! Learn from the team! Cooperate with your team so that you guys can reach higher! Be critical to your team, conflicts can make you stronger! Be humble.
3. All that glitters is not gold. Some very popular libraries and tools that might not be as good as you think. Learn harder. Make something better if necessary. Think of both the big picture and the details at every step you make. Don't overweigh technicality over business requirement, and vice versa. Be critical.
> Now I'm a little worried that if my situation doesn't change, my career would suffer.
Be strong. Feel strong. But stay thorough, humble, and critical. And you need to care achieve them.
I've been there, laying afraid that my career might suffer. I've been in the reviewer's spot too, being too strict, forcing engineers to change the design, sometimes compromising the engineer's personal feeling.
BUT I've also successfully convinced and lead a rewrite the core of a pretty big project (which people are really afraid of the risk) so that the engineers feel safer when building on top of the core, and in turn make them tens times faster, while at the same time growing some newer engineers to the point of one of them being a lead of a team handling a pretty big project for a customer which is pretty prominent in the gaming industry, IN JUST HALF A YEAR. (sorry, but not sorry for bragging lol :D)
You never know what good things are coming to you when you start caring.
Some random nice stuff to learn that I remember might help you with the design stuff:
https://martinfowler.com/
https://medium.com/@thisdotmedia/the-cost-of-premature-abstr...
https://raphlinus.github.io/ui/druid/2019/11/22/reactive-ui....
https://www.youtube.com/watch?v=yy8jQgmhbAU
https://blog.dropbox.com/topics/work-culture/kim-scott-inter...
Having your PR rejected in a toxic environment can mean a lot of things, and a company sought after doesn't mean that it MUST be not toxic.
First, you have to make sure if both of YOU and YOU ENVIRONMENT is healthy. If both are healthy, proceed reading.
> The challenge here is to deliver good quality code, while maintaining a decent speed of delivery.
You made it sound like producing good quality code = slowness. FALSE. Seeming slow, good quality code boosts your team's velocity. BUT keep in mind: "quality" is "the standard of something as measured against other things of a similar kind; the degree of excellence of something". Your team has its standards, either is a derivative of other globally acknowledged standards such as https://blog.golang.org/go-fmt-your-code, https://github.com/microsoft/TypeScript/wiki/Coding-guidelin..., https://twitter.com/dan_abramov, etc, or self-made standards. You go follow them, make them happy!
Coding and design skill has a different definition than code quality. It is what punches up to the sky: the overall velocity, the success of the team, the balance of growth and culture retainment of the company, the development experience, the users' thumbs ups, amazements, and "this app is life changing" comments, the number of milestone celebration in All You Can Eat restaurants each years, the number of people rising up from junior to senior each years, etcetera etcetera.
Not only you make your team happy with the quality code based on their standards. You must always exercise to always improve your team, whether your team agrees or not AT THAT TIME. Keep searching for improvements, internally and externally. Occasionally fight with your team if you have to, if you have the right cause. And if it turned to be a wrong cause, accept and move on.
So...
> Are there any good ideas to improve one's coding/design skills significantly?
Yes. These are the tricks to a good code/software/system design and architecture:
1. Know the fundamentals! Go lower than frameworks and libraries! Analyze why existing codes are made that way! Think in strings, C, algorithm, data structure! Always pay attention top-down and bottom-up! Think in terms of time and space complexity! Separate complexity from complications! Be thorough.
2. Know the team! Know what is valuable for the team! Understand how your code impacts your team's velocity! Understand the mood of the team and use it! Contemplate how existing processes help or hinder the team! Consider suggesting to add or remove them if necessary! Make interfaces for others! Learn from the team! Cooperate with your team so that you guys can reach higher! Be critical to your team, conflicts can make you stronger! Be humble.
3. All that glitters is not gold. Some very popular libraries and tools that might not be as good as you think. Learn harder. Make something better if necessary. Think of both the big picture and the details at every step you make. Don't overweigh technicality over business requirement, and vice versa. Be critical.
> Now I'm a little worried that if my situation doesn't change, my career would suffer.
Be strong. Feel strong. But stay thorough, humble, and critical. And you need to care achieve them.
I've been there, laying afraid that my career might suffer. I've been in the reviewer's spot too, being too strict, forcing engineers to change the design, sometimes compromising the engineer's personal feeling.
BUT I've also successfully convinced and lead a rewrite the core of a pretty big project (which people are really afraid of the risk) so that the engineers feel safer when building on top of the core, and in turn make them tens times faster, while at the same time growing some newer engineers to the point of one of them being a lead of a team handling a pretty big project for a customer which is pretty prominent in the gaming industry, IN JUST HALF A YEAR. (sorry, but not sorry for bragging lol :D)
You never know what good things are coming to you when you start caring.
Some random nice stuff to learn that I remember might help you with the design stuff:
https://martinfowler.com/
https://medium.com/@thisdotmedia/the-cost-of-premature-abstr...
https://raphlinus.github.io/ui/druid/2019/11/22/reactive-ui....
https://www.youtube.com/watch?v=yy8jQgmhbAU
https://blog.dropbox.com/topics/work-culture/kim-scott-inter...
Good for you for recognizing that you are not performing to the standard that you know you can. Now it's up to you to use your tools and team to improve.
First of all, there is probably a style guide for your programming language at your company. Read it front to back. Your IDE may be configurable to automatically bring code up to these standards. "Look and feel" and using consistent language features are very important for others to be able to easily digest your code and be comfortable with it.
Second, there are likely resources for learning your common libraries (like your RPC and presentation libraries for example). Go through those thoroughly. Make sure you understand the common patterns and how they are used in the product you are working on. Apply this learning to your design before you start writing code.
Now that you have context, look at the specific feedback you've received and look for resources internally and externally for how to improve the issues that have been raised. Have you been misusing language features? Writing incorrect unit tests? Improperly using abstractions? Scoping functions incorrectly? Make sure that the feedback you've received follows the style guide and tool use cases. Come up with a plan to address the legitimate issues. As others have mentioned, writing a checklist of pre-review items and doing your own code review is indispensable, as well as learning how to make use of any integration testing environments and debuggers that you have access to.
Finally, ask your team leadership for help. Have a chat with your manager. Do this after you have done the research so you have some specific examples of mistakes you've made in the context of coding practices at your company and your plans to address them, including asking for specific mentorship prior to implementation, like design review. Why to ask for management's help and not go to the devs directly? your performance is their job - where a senior dev may not realize it's their job to mentor you until the manager asks them to. Letting your team leadership know that you are being proactive to address this issue will go a long way and unlock more resources that you need. Design review could be whiteboard sessions but I personally prefer design documents describing what the feature will do, why it is needed, how it will work, and what the implementation milestones are. You bring this to the session for editing/feedback, don't go empty-handed and expect to design stuff on the fly.
Regarding your velocity concerns, this will/should come up during your conversations with your manager about your skill development. One good way to improve perceived velocity is to break down features into smaller milestones and complete those at a quicker cadence. Having a design document/review will help do this.
Asking how to improve is the first step. Good luck!
First of all, there is probably a style guide for your programming language at your company. Read it front to back. Your IDE may be configurable to automatically bring code up to these standards. "Look and feel" and using consistent language features are very important for others to be able to easily digest your code and be comfortable with it.
Second, there are likely resources for learning your common libraries (like your RPC and presentation libraries for example). Go through those thoroughly. Make sure you understand the common patterns and how they are used in the product you are working on. Apply this learning to your design before you start writing code.
Now that you have context, look at the specific feedback you've received and look for resources internally and externally for how to improve the issues that have been raised. Have you been misusing language features? Writing incorrect unit tests? Improperly using abstractions? Scoping functions incorrectly? Make sure that the feedback you've received follows the style guide and tool use cases. Come up with a plan to address the legitimate issues. As others have mentioned, writing a checklist of pre-review items and doing your own code review is indispensable, as well as learning how to make use of any integration testing environments and debuggers that you have access to.
Finally, ask your team leadership for help. Have a chat with your manager. Do this after you have done the research so you have some specific examples of mistakes you've made in the context of coding practices at your company and your plans to address them, including asking for specific mentorship prior to implementation, like design review. Why to ask for management's help and not go to the devs directly? your performance is their job - where a senior dev may not realize it's their job to mentor you until the manager asks them to. Letting your team leadership know that you are being proactive to address this issue will go a long way and unlock more resources that you need. Design review could be whiteboard sessions but I personally prefer design documents describing what the feature will do, why it is needed, how it will work, and what the implementation milestones are. You bring this to the session for editing/feedback, don't go empty-handed and expect to design stuff on the fly.
Regarding your velocity concerns, this will/should come up during your conversations with your manager about your skill development. One good way to improve perceived velocity is to break down features into smaller milestones and complete those at a quicker cadence. Having a design document/review will help do this.
Asking how to improve is the first step. Good luck!
> Finally, ask your team leadership for help
Finally?
Surely the whole purpose of team leadership is to solve exactly this kind of problem. If the leadership is any good then asking for help will be regarded as positive not negative and will one to get expert, targeted, advice.
So instead of 'finally', I would recommended 'initially' or possibly 'immediately'.
Finally?
Surely the whole purpose of team leadership is to solve exactly this kind of problem. If the leadership is any good then asking for help will be regarded as positive not negative and will one to get expert, targeted, advice.
So instead of 'finally', I would recommended 'initially' or possibly 'immediately'.
Doing research before asking for help indicates that you're taking responsibility for your own success. Managers aren't babysitters.
There's a lot of feedback already in this thread, but if you're still reading, I wanted to share my process in case there's anything that was missed. This will help you, hopefully, fully complete issues the first time. Don't let any of these points block you, but you can generally go in this order.
1. Make sure you understand the requirements for the issue at hand.
Make sure you correctly understand all of the work an issue is supposed to encompass and no more. Use all available documentation, issue descriptions, designs, notes, and any other resources. As a last resort, as in the project is not well documented, start putting together questions to ask someone. Craft your questions in advance and ask them strategically and it will save you time. This is not all on you, better documentation, grooming, and other processes can help you work faster, and it might be something worth bringing up at a retrospective or using any other avenue you have for feedback after some research into what exactly is going wrong and what other people have done to solve it.
2. If you haven't already, start looking into completing the issue from a technical standpoint.
No issue exists in a vacuum, and there is probably already existing technical architecture surrounding the issue, or something similar that is already being done. Good code conforms to the standards around it, and a good team codebase looks like it was written by one person. Not copying code, but using it as a general blueprint can help you get past code review by following unwritten established standards of the team. Of course, if there are written standards, check those too. Make sure you understand all of the technologies used by the code you're following, it probably has documentation. Try to understand any technical decisions that don't seem clear. Follow the guidelines in the previous point for asking questions if you need to. If any technical decisions need to be overturned, consider making refactoring part of the issue if at all practical (this is a whole other can of worms, so you'll forgive me if I don't get too deep into it).
Keep in mind that version control tools can help you understand why a decision was made, particularly if you learn to use tools like `git blame` and `git log` (assuming your team uses git), or even more powerful integrated tools like [vim-fugitive](http://vimcasts.org/blog/2011/05/the-fugitive-series/) or [magit](https://magit.vc/manual/magit/index.html#Top) if you use something like VIM or Emacs.
If there are any new technologies and technical decisions that are part of your issue, try to gain a rough idea of what your implementation will look like and try to learn as much about the technologies as possible. If you are not in a decision-making position, it is best to run your ideas past someone who does once they are concrete if you can. Of course, sometimes, it is easier to just start writing code. How low level or high level your planning is up to you, but it should probably depend on the complexity of the issue at hand. Don't be afraid to take a couple passes at it, better now than later.
3. Start implementing.
When you are actually writing code, a good process makes all the difference. Some people use [TDD](http://agiledata.org/essays/tdd.html) or write all of their inline documentation ([example](https://jsdoc.app/)) beforehand, which can help you quickly refine and complete your implementation details without actually writing any code yet. This, again, helps you rework your ideas early on in the process. I use a mix of documentation, testing, and any [REPL](https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93prin...) that's available to me to test out code beforehand depending on the issue, which is not the most straightforward method. Try TDD at least once and see what works for you.
A good dev system can help a lot. If you can get the code into a working state and compile it often to test it, do so. Any other dev tools for testing, documentation, linting, debugging, etc. for the project, learn them and use them.
Once you're done making some changes, look over your code. Clean up anything you can, and don't be afraid to make another pass at it if you need to, especially early on.
Planning out how you're going to get things into a working state and split up your changes (commits in git) early can sometimes help, but sometimes it's easier just to clean up your commit history later as you're reviewing your changes (getting familiar with `git rebase` can help with this).
4. Submit your merge requests/pull requests.
If you can at all, get your code into a working, logically separated state often and submit small merge requests/pull requests often for review. This can help you correct your tragectory early on if you still need to take a different direction. Familiarity with git or the VCS you're using can help a lot with dealing with multiple branches of code. As with all things, give your pull request one final look-over before you submit it for review and clean up anything you need to.
tl;dr: understand everything you can, ask questions, plan ahead, take multiple passes early, and make small changes
1. Make sure you understand the requirements for the issue at hand.
Make sure you correctly understand all of the work an issue is supposed to encompass and no more. Use all available documentation, issue descriptions, designs, notes, and any other resources. As a last resort, as in the project is not well documented, start putting together questions to ask someone. Craft your questions in advance and ask them strategically and it will save you time. This is not all on you, better documentation, grooming, and other processes can help you work faster, and it might be something worth bringing up at a retrospective or using any other avenue you have for feedback after some research into what exactly is going wrong and what other people have done to solve it.
2. If you haven't already, start looking into completing the issue from a technical standpoint.
No issue exists in a vacuum, and there is probably already existing technical architecture surrounding the issue, or something similar that is already being done. Good code conforms to the standards around it, and a good team codebase looks like it was written by one person. Not copying code, but using it as a general blueprint can help you get past code review by following unwritten established standards of the team. Of course, if there are written standards, check those too. Make sure you understand all of the technologies used by the code you're following, it probably has documentation. Try to understand any technical decisions that don't seem clear. Follow the guidelines in the previous point for asking questions if you need to. If any technical decisions need to be overturned, consider making refactoring part of the issue if at all practical (this is a whole other can of worms, so you'll forgive me if I don't get too deep into it).
Keep in mind that version control tools can help you understand why a decision was made, particularly if you learn to use tools like `git blame` and `git log` (assuming your team uses git), or even more powerful integrated tools like [vim-fugitive](http://vimcasts.org/blog/2011/05/the-fugitive-series/) or [magit](https://magit.vc/manual/magit/index.html#Top) if you use something like VIM or Emacs.
If there are any new technologies and technical decisions that are part of your issue, try to gain a rough idea of what your implementation will look like and try to learn as much about the technologies as possible. If you are not in a decision-making position, it is best to run your ideas past someone who does once they are concrete if you can. Of course, sometimes, it is easier to just start writing code. How low level or high level your planning is up to you, but it should probably depend on the complexity of the issue at hand. Don't be afraid to take a couple passes at it, better now than later.
3. Start implementing.
When you are actually writing code, a good process makes all the difference. Some people use [TDD](http://agiledata.org/essays/tdd.html) or write all of their inline documentation ([example](https://jsdoc.app/)) beforehand, which can help you quickly refine and complete your implementation details without actually writing any code yet. This, again, helps you rework your ideas early on in the process. I use a mix of documentation, testing, and any [REPL](https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93prin...) that's available to me to test out code beforehand depending on the issue, which is not the most straightforward method. Try TDD at least once and see what works for you.
A good dev system can help a lot. If you can get the code into a working state and compile it often to test it, do so. Any other dev tools for testing, documentation, linting, debugging, etc. for the project, learn them and use them.
Once you're done making some changes, look over your code. Clean up anything you can, and don't be afraid to make another pass at it if you need to, especially early on.
Planning out how you're going to get things into a working state and split up your changes (commits in git) early can sometimes help, but sometimes it's easier just to clean up your commit history later as you're reviewing your changes (getting familiar with `git rebase` can help with this).
4. Submit your merge requests/pull requests.
If you can at all, get your code into a working, logically separated state often and submit small merge requests/pull requests often for review. This can help you correct your tragectory early on if you still need to take a different direction. Familiarity with git or the VCS you're using can help a lot with dealing with multiple branches of code. As with all things, give your pull request one final look-over before you submit it for review and clean up anything you need to.
tl;dr: understand everything you can, ask questions, plan ahead, take multiple passes early, and make small changes
"I usually take 3-4 tries with some significant amount of testing to get my code to a working state."
..this is a "code" smell to me. if you are jr, then ok, otherwise you got some serious problems nad put your focus in the wrong places.
anyhow, one advice i can give you, or anybody else, is - when you're doing it right, it just flows. when you're banging your head against a wall, you took a bad turn in your decisionamking process a while back and need to retract your steps. this one usually can save you from writing about 80% of useless code. when you are bored and are not looking forward to write something, you are on the right track. if you feel creative and full of energy, you are thinking on your feet and have no idea where it will lead you. sure, this is the best part of coding, the creativity, but not in the business world. that is for your personal projects. boring is good. be creative in preparation, not once you're already undertaking a task.
..this is a "code" smell to me. if you are jr, then ok, otherwise you got some serious problems nad put your focus in the wrong places.
anyhow, one advice i can give you, or anybody else, is - when you're doing it right, it just flows. when you're banging your head against a wall, you took a bad turn in your decisionamking process a while back and need to retract your steps. this one usually can save you from writing about 80% of useless code. when you are bored and are not looking forward to write something, you are on the right track. if you feel creative and full of energy, you are thinking on your feet and have no idea where it will lead you. sure, this is the best part of coding, the creativity, but not in the business world. that is for your personal projects. boring is good. be creative in preparation, not once you're already undertaking a task.
What a strange “sought after” company, where guidelines are not written and people just reject prs without a good reason.
Maybe I am over reacting to the way you wrote your comment and this definitely won't be liked by the general community.
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.
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.
> Serious developer do not refer to stackoverflow. Developers should use stackoverflow only to lookup for names of functions or methods. Nothing else.
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.
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.
Please read carefully my phrasing.
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.
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.
[deleted]
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.