#JuniorProgrammer #CodingStruggles #LearningCurve
As a junior programmer, it can be disheartening to have your code rejected by a senior coworker, especially when you’re still learning and trying to improve. It’s important to remember that receiving feedback is a valuable part of the learning process, but it can also be intimidating to share your work with someone who has more experience. In this article, we’ll explore how to handle rejection from senior coworkers and turn it into a learning opportunity.
## Understanding the Rejection
It’s natural to feel discouraged when your code is rejected, but it’s important to remember that your senior coworker’s feedback is meant to help you grow as a programmer. Instead of viewing the rejection as a failure, try to see it as an opportunity to learn and improve. Understanding why your code was rejected is crucial for your growth as a programmer.
### Reasons for Rejection
There are several reasons why your senior coworker may have rejected your code:
1. Performance issues – Your code may not be as efficient as it could be, leading to slower execution times.
2. Best practices – Your code may not follow industry best practices or coding standards.
3. Scalability – Your code may not be optimized for scalability, leading to issues as the project grows.
## Turning Rejection into Learning
Instead of being disheartened by the rejection, use it as an opportunity to improve your skills and learn from your senior coworker’s expertise. Here are some steps you can take to turn rejection into a positive learning experience:
### Ask for Feedback
Don’t be afraid to ask your senior coworker for specific feedback on your code. Request a code review session where they can walk you through areas for improvement and offer guidance on how to optimize your code.
### Seek Guidance
If you’re unsure about how to optimize your code, seek guidance from your senior coworker or other experienced developers. They can provide valuable insights and help you understand how to improve your programming skills.
### Take Initiative
Take the initiative to learn and improve on your own. Research best practices, read industry blogs, and participate in online coding communities to enhance your coding skills.
### Practice, Practice, Practice
Practice is key to improving as a programmer. Take on side projects, tackle coding challenges, and continuously work on honing your skills to become a better coder.
### Embrace the Learning Curve
Remember that it’s perfectly normal to make mistakes and encounter rejection as a junior programmer. Embrace the learning curve and use rejection as a motivation to keep improving.
## Overcoming Fear of Rejection
It’s natural to feel intimidated by rejection from senior coworkers, but it’s important to overcome that fear and seek out opportunities for growth. Here are some tips for overcoming the fear of rejection:
### Open Communication
Initiate open and honest communication with your senior coworker. Express your willingness to learn and ask for their guidance in improving your coding skills.
### Build Confidence
Believe in your abilities and have confidence in your potential as a programmer. Remind yourself that rejection is a part of the learning process and an opportunity to grow.
### Embrace Feedback
View feedback, including rejection, as a valuable tool for improvement rather than a personal criticism. Embracing feedback will help you grow as a programmer.
### Stay Persistent
Don’t let rejection discourage you. Stay persistent in your efforts to improve and continue learning from your mistakes.
## Wrapping Up
As a junior programmer, it’s normal to encounter rejection from senior coworkers. Use rejection as an opportunity to learn, grow, and improve your coding skills. Embrace the learning process, seek guidance, and stay persistent in your efforts to become a better programmer. Remember, rejection is not a reflection of your abilities but rather a stepping stone to success. Keep coding and keep learning, and soon enough, you’ll be the one offering valuable feedback to junior programmers.
Have you encountered rejection from senior coworkers as a junior programmer? How did you handle it and what did you learn from the experience? Let us know in the comments below! #ProgrammingRejection #LearningFromRejection #JuniorDeveloperJourney
He sounds like a mad mentor.
A good mentor will do what you’re hoping for – set aside time to walk you through what can be improved on and why.
A good colleague will leave comments on your code and encourage you to reach out with any questions.
A poor coworker will behave like your senior and provide no advice, logic, or comment. Try not to hate these people – they don’t deserve our time.
Two things you can do:
1) Set up a meeting with the senior to go over your work and ask them questions about how to improve it. Hope they’ll get the picture, or do the same thing in the future.
2) go to your manager and ask for a mentor to help you with leveling up your skills. Manager may then go to the senior and tell them to be more helpful. Or you’ll get a different senior who is nicer!
Your manager should be looking to help you succeed so they look better when your work satisfies the requirements their manager gave them. Tell them you’d like a technical mentor and they should respond appropriately!
Have you tried asking really hard where you can improve your code?
Everything is a learning experience. Even as a senior guy now, I send PRs to devs under me on my team, and I often learn things from them to optimize my code. I just take it, implement it, and remember it. You’ll be experiencing that the rest of your career, so best to get used to it.
i was never a junior 🙂 because i came in at the right time when things drastically changed, so the old timers did not know how the new stuff worked.
however, you just have to ask them, even if you just ask, “before i spend a week on this, i was thinking i would tackle this using xyz. how would you approach it? can you give me a direction to go? because i don’t want to waste time so i though i should check with you first.”
as far as the efficient algorithms, you could just read a book or take a udemy course. normally you use pre-built tools for sorting and searching so you shouldn’t be writing that code yourself … but it does somewhat help to know the theory.
Are your MRs a lot of lines of code? If so, he might just be swamped with other work and not know the best way to answer all the issues.
If it’s a small MR, he should be able to walk you through some examples or explain it.
This is completely normal, but what you need to realize is that you’re taking it personally, which is totally normal and human.
But you need to learn to not think of it that way. Your senior isn’t criticizing YOU, he’s criticizing your code. And your code should be improved. Good code is important for the project, and learning to write good code is important for you.
Also, feedback like this isn’t just for junior coders! Experienced coders get critical feedback too.
I’ve got 25 years of experience and it’s still quite common for me to get lots of feedback on my PRs with suggestions of ways the code could be better. That’s the whole point of code review.
Code reviews aren’t an opportunity for you to get kudos for working hard. They’re an opportunity for you and your teammates to collaborate to get the best possible result.
The point isn’t whether O(n^2) is or isn’t good enough this time. The point is that in the future your senior wants you to be able to work on really important code where the difference between O(n^2) and O(n log n) really matters a lot, because that can be the difference between a task taking minutes vs seconds.
It will get better. After 20 – 30 PRs you’ll get much better, and pretty soon your senior will start approving things with little to no feedback. That’s how you’ll know you’ve learned a lot. And you’ll hopefully get positive feedback in other channels (like a 1:1 from your manager) so you’ll know you’re appreciated and valued, and you’ll be able to more easily handle getting feedback in a code review.
Edited to add: if you need more specifics, ask. But first, try to make an effort to take the feedback you got and make your code better. Make your algorithm faster. Do some research. Measure the actual runtime.
Theyre just gatekeeping. Colleagues do it all the time. They will block your solution for any reason while asking you to auto-merge theirs without question.
Push back on them. Ask them to make a benchmark showing that the performance is not good enough for the expected load. Make it look like they’re blocking forward progress.
try asking him for one thing that you could improve on.
Just for context, the difference between O(n^(2)) and O(n log n) is not small. If you have a list of just 1000 items to work on, an O(n^(2)) algorithm will take 1,000,000 steps, whereas an O(n log n) algorithm will take maybe 10,000 (depending on the log base). And that difference only gets worse as n grows.
If you know you can do better, and your coworker is saying that he knows you can do better, do you really need him to hold your hand? Could he be nicer about it? Sure. Maybe he figures that if he holds you to a higher standard now, you’ll hold yourself to a higher standard in the future.
We write non optimal code all the time. Unless it actually causes a performance problem it doesn’t matter. In fact trying to do everything in an optimal way produces unreadable unmaintainable garbage.
That’s not how it should work, if he’s going to say “this can be better” he has to take at least a little time to explain how. Generally speaking, too, we should be optimising for readability, not speed, if your way is obvious and clear to read, then that will generally be more desirable than faster code that is non-obvious to read.
Not all the time of course, if you were making a 3D games engine or something, but generally readability is the target, not maximum optimisation.
To be honest, i would do the same on his place.
A little not optimized code is not that big of a deal, for instance to take a median if it is not some very often used code – use the sort, why not, it wouldnt make sense to write some obsure algorithm just to save a little bit of time.
But what you described is not some minor factor but a o(n^2) vs o(n log n) this is straight up wrong alghorithm used, it is like using bubble sort instead of quick sort.
To show it on numbers for n = 1024 and log base = 2
n ^ 2 = 1024 * 1024 = 1 048 576
n log n = 1024 * 10 = 10 240
It is orders of magnitude faster to use n log n alghorithm.
It’s okay! Please don’t feel bad about code getting rejected during reviews. In fact when I have mentees under me, I usually judge their code even stricter than I do my other coworkers, because I want my mentees to learn while I’m available to help. I’m sure your senior would be happy to help walk you through it. Don’t be afraid of him.
First off, congrats on landing a job! Your first few years will be tough, stick it out past 4-5 and the gap between yourself and comp sci grads will narrow though.
He’s right to reject your pull requests. Suboptimal code fucks up products.
He’s wrong to blankly reject them without feedback. A competent senior should help mentor you, or at the very least, point you in the right direction.
I’m a self taught IT guy, but I sometimes submit code changes to our dev team. They appreciate this because it makes their lives easier. When I’ve missed something obvious, they’ll usually provide feedback like “in this case, using X would be more optimal than Y. While we have done Y in the past, I wonder if this could be optimised with X?”. This both leads me down a path of self learning and results in a better product shopping to market – this is what true senior development relationships should look like with juniors.
I remember submitting a bug fix once. It took two days to write and test. They came back asking me to write unit tests to ensure our builds checked these changes. The tests took two weeks! They knew this would be the case, and asked it to make sure I had properly considered the changes and understood them on a technical level.
I hate it too when I can’t get code done and have senior looking at every line. He means well. But it’s demoralizing so I like when I’m the only dev and I can get things done
When I started as a junior I had a senior dev who would tear my PRs to shreds. I’m talking like 30 comments on it sometimes. He was known to do that to everyone’s PRs but I had to realize I’m not my code. Be humble enough to realize it’s not personal and you’ll grow much quicker.
I had 2 Seniors who sometimes pair programmed with me and it honestly was the most stressful shit. 5 years later, I still don’t want to do it. They could’ve been a guiding hand watching, correcting, hinting better approaches. Instead I was told to write faster, stress the fuck out of me, pointed out every typo, which I made a lot of, because, well write faster, while not actually knowing what to do, basically dicdated me what to write while I had no clue what their intention was. How the fuck was I supposed to learn anything like that?
Fuck em. Within the first year I looked for a better Job with better pay.
I got one exactly a year after I started the first. Better team, nicer people, cooler and more technical Job. It was better. Not optimal but better. I quickly proofed an affinity for clean and readable code and architecture. I even documented the mess they had and made a proposition on how to make it better, which everyone liked, but wasn’t really valued higher up.
A friend of mine had an opportunity for me, so I switched Jobs again, after 1 year, increasing my income even more. Still a Junior they realised after less than half a year that Junior doesn’t really fit my title, so they removed the “Junior” part and increased my pay further. Unfortunatly due to some bad decisions that company went down the gutter. When the Risk amd Legal teams began to jump off, so did I. A good decision as most of the Software Engineers were let go not long after, and I didn’t have them to compete for Jobs around my area too.
Now I guide others and took all those lessons with me. I think our Juniors and Apprentices like me for giving reasons and hints for improvements in my review rejections. I want them to improve but also think for themselves so I don’t give them the Solutions outright, but hint where to look at next to get them where they need to be.
TL;DR: get what you can from the current Job to move along to the next, if the current one sucks for various reasons. There is little risk in looking for a new Job while working. Nobody in your company has to know until you give your notice.
Just take those lessons so you don’t become the asshole.
Your senior could definitely be doing more to to help you learn, and should be helping advise you. However that is more a leads responsibility, and the senior may already be overworked.
That being said, O(n^2) is not good. There are very rare instances where you cant find a better solution. You obviously know how to code. Now you have to learn to code better. And it will never stop.
How old is this senior? Some are just jerks trying to show others that they are better. I hate those types. Most are just insecure that the new guy can be self taught and now in the field when he have to get formal schooling and get loans etc. They are afraid to teach because if you become better they fear that their job can be handed to someone else.
To me when I was learning, as long as you get the logic down, that is the key. You can always clean up the code once you get more experience.
When I was in school, one of my professors gave us a project and after submitting it, he pulled me aside and asked me if I paid someone to do it as I am using functions that are not even in his curriculum. I just told him, the textbook that he was using will make my code longer and there are functions that do more than one thing at a time. I showed him the text book that I was using and that was that.
I’m a senior and I think there’s two important thinks to realize here.
1. Code review rejections will happen – don’t take it personally UNLESS..
2. If the senior is going to flat out reject a code review, they need to provide both justification for this and positive feedback on what they’d like to see change.
If it’s like you wrote and they just denied it and said “not optimal”, then they did a bad job code reviewing.
If I were in your shoes I would ping them and ask them for more feedback. Be willing to listen to what they have to say and justify any changes you think you don’t need to make.
Your senior is incapable of improving your code, that’s why he isn’t helping. Instead, he creates a harder task to you that he himself couldn’t fulfill.
You’ll find more of that type of people…
It’s not uncommon to face challenges and rejection as a junior developer. Many experienced developers, including myself, have gone through similar experiences early in our careers. It’s essential to view such feedback as an opportunity for growth rather than just rejection.
If your senior coworker is not providing constructive feedback, it might be worth expressing your willingness to learn and improve. Approach them with humility, acknowledging that you’re still in the learning phase and would appreciate guidance on how to optimize your code.
In a healthy work environment, seniors should be willing to mentor and guide junior developers. It’s understandable that you may feel apprehensive about asking for help, but most seniors are likely to appreciate your eagerness to learn and improve. They were once in your shoes and understand the learning curve.
However, it’s important for seasoned professionals to remember their own journey as beginners. Discouraging juniors without offering guidance not only hinders their growth but also perpetuates a negative work culture. Instead of dismissing their efforts outright, experienced developers should take the time to mentor and encourage their junior colleagues. By providing constructive feedback and sharing insights, they contribute to a positive learning environment, empowering juniors to overcome challenges and excel in their roles. Remember, the success of a team lies in fostering collaboration, support, and continuous improvement.
It’s shouldn’t be just flat reject. They should teach how to do it better.
“The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.”
— Donald Knuth, 1974
Before discussing optimisation at all, the team should have an explicit performance goal. If you have no specific performance target, you have no way to know that your system is already performant enough.
If you do have a performance target and you’re not hitting it, the team should be profiling the code to find out which specific code must be worked on.
Attempting to optimise everything is a naive approach to engineering a software system.
I’ll tell you what I do as a junior. Before I get my code reviewed, I feed the code into gpt and ask it to optimise it. It has actually helped me a lot to reduce the time and space complexity as well as remove any duplicate code.
you are taking things too much to heart.
Your anxiety is not because of him rejecting your code. your anxiety is because you think that you might get fired because of bad coding. If you don’t have that fear, you would gladly takes his opinions and improve your code performance.
You might not be able to code better but your perseverance will make the difference. I think that Senior coworker would actually love if you use his algorithm. stop wasting time on that thinking and continue coding.
I’m a senior, you need to reach out to him. Don’t be scared of senior devs.
He’s a shit senior. A real senior would help you solve the task together, and teach you the right way.
Shooting at code is too easy.
Some people are teachers and some are not. Some seniors see training as part of their responsbility (I do). Some do not.
Your responsibility is to solve the problems he points out. Code isn’t fast enough? Talk to your network, read a book, watch a video. Figure it out–also as fast as possible.
Your senior is your client, and clients just want solutions to their problems, like, right now, fast.
The sooner you can see that, the better you will be. (Lord knows it took me forever.)
What? He rejects your pull request without any feedback?
If he is a good senior he will call you and show you how things are done, not just reject things, that horrible and not good for anyone.
that doesn’t sound like a very good senior. A good senior talks you through your solution and makes suggestions. If there your n^2 solution threatens to cause a problem / cripple the system then yes you’ll have to rewrite that part of the solution. But that shouldn’t be rejection as much as help/guidance on how to improve. Does he at least give you pointers on what to change?
He totally should be walking you through your code and making suggestions. Otherwise why offer your code up for review at all?
You have to ask. Stop it.
Bro, n log n time complexity usually means there is somewhere happens sorting then two pointers or binary search or constant operation. It depends. Check what you can sort to optimise your solution.
don’t put your personal worth in your work – as a person and an engineer. no one’s above a little code review thrashing, just know that 1. you’ll get better, 2. it’s not a reflection of your worth
Ask your senior for guidance before implementing anything. This is how I avoided reworking. For me, they won’t reject my code. They just tell me what is wrong and ask me to fix it.
I think we’ve all encountered that one senior that behaves in such a way. I hope you have a mentor there to guide you at least? For what it’s worth, at least you’re completing tasks, pushing commits and creating pull-requests to the codebase. I commend you for that.
In my experience something like this should’ve been caught in design, well before review. I would probably run the design by a senior dev before writing the code to make sure you’re on the same page ahead of time. Some upfront design is both beneficial to you as well as more respectful for everyone’s time (as opposed to rewriting something after a full implementation was cranked out).
It’s not atypical for a problematic implementation that wasn’t discussed ahead of time to be outright rejected. I don’t know if your senior had any malicious intent but engaging with him earlier in the development process gives you some agreed upon standard to point back to if this happens again.
> But I do get dishearted when after I work hard on a task given to me by my senior he just rejects it outright because it works slower than it could be programmed to work.
lol why? It’s literally wrong, so he’s supposed to reject it.
Step your game up, ask for help, etc. Don’t just sit there and whine.
Just ask him. If it’s his job to reject, then it’s also his job to work with you to meet his expectations.
Just ask him. If it’s his job to reject, then it’s also his job to work with you to meet his expectations.
He should be giving you a code review. At least in writing if not in a meeting where you can have back and forth.
Just rejecting it out of hand with no comments or suggestions is completely useless.
You should consider outlining your approach and asking what better approaches are available. Especially if you know it can be improved.
A senior coder may have bigger responsibilities and tighter deadlines. So a good precept to live by is “I am not owed any mentorship. I will work in such a way mentorship is easier to offer”