Junior programmer? This may help you(gist.github.com)
gist.github.com
Junior programmer? This may help you
https://gist.github.com/ciokan/51f7251fc1c348769574cab54f252502
14 comments
> please break down these pleasant chunks of unreadable code into model properties and use them here and anywhere else where you have such kryptonian blocks. Good code is readable, semantic, and easy to follow and update. I pitty the poor soul who would have to participate here with you :). I, for one, would probably delete and start over to spend less time. I know there are situations where it's unavoidable but this one clearly isn't the case. Python really is beautiful, Python is english...write me some poetry please.
> You have a lot of repetitions of datetime objects that can be stored in a variable. You have a lot of comparisons on the object that can be stored as model properties. Separate them and let these methods breathe please. This looks like callback madness in js. I can't even follow the parenthesis to grasp the flow of conditions here. Even my IDE formatter left me.
Wow. If I saw someone code review like this on my team, they would get one warning. If this behavior was repeated, then they would be fired. There is no place for condescension in the team, even from Senior -> Junior level developers. If anything, this is a great stepping stone for (kindly) teaching a jr. member how to refactor into code that is more readable. Unnecessary jabs like "i pity the poor soul... clearly this isn't the case... looks like JS... even my IDE formatter left me..." and snide hand-wavy remarks like "python is english.. write me some poetry" are only useful to stroke e-peens and push people down publicly.
What would have gone a lot further, in my opinion, was refactoring the code then sending it to the jr. dev and telling them that you refactored their code for them. Tell them that - if they'd like - you'd be happy to walk through the changes and explain why those things were helpful/useful. It's not a contest about who can write the best "poetry". It's about getting along, helping each other, and getting work done.
Jr. devs, if you are reading this, please don't despair. I promise that all teams aren't this bad to work on. There are places where you don't have to be afraid to be the butt of a joke in an HN post and you will actually learn things. If your team is more like the one in the post, you're much better off just leaving for your own sanity.
> You have a lot of repetitions of datetime objects that can be stored in a variable. You have a lot of comparisons on the object that can be stored as model properties. Separate them and let these methods breathe please. This looks like callback madness in js. I can't even follow the parenthesis to grasp the flow of conditions here. Even my IDE formatter left me.
Wow. If I saw someone code review like this on my team, they would get one warning. If this behavior was repeated, then they would be fired. There is no place for condescension in the team, even from Senior -> Junior level developers. If anything, this is a great stepping stone for (kindly) teaching a jr. member how to refactor into code that is more readable. Unnecessary jabs like "i pity the poor soul... clearly this isn't the case... looks like JS... even my IDE formatter left me..." and snide hand-wavy remarks like "python is english.. write me some poetry" are only useful to stroke e-peens and push people down publicly.
What would have gone a lot further, in my opinion, was refactoring the code then sending it to the jr. dev and telling them that you refactored their code for them. Tell them that - if they'd like - you'd be happy to walk through the changes and explain why those things were helpful/useful. It's not a contest about who can write the best "poetry". It's about getting along, helping each other, and getting work done.
Jr. devs, if you are reading this, please don't despair. I promise that all teams aren't this bad to work on. There are places where you don't have to be afraid to be the butt of a joke in an HN post and you will actually learn things. If your team is more like the one in the post, you're much better off just leaving for your own sanity.
Oh god, you must be fun to work with. /s
Next time you probably should take the guy and talk with him privately instead of publicly shaming?
Also "Python really is beautiful, Python is english...write me some poetry please." cringe.
Next time you probably should take the guy and talk with him privately instead of publicly shaming?
Also "Python really is beautiful, Python is english...write me some poetry please." cringe.
Junior Manager? This may help you: Don't publicly shame your staff or you may find yourself working alone.
Conceited. There is never an excuse for workplace bullying. You don't know how to manage if all you can do is criticise in your 'TODOs'. You are not as advanced a developer as you would like to think if your best solution is to rewrite.
The page is gone... looking at the comments here, I would say he learned the lesson
One thing that might not be crystal clear on a junior's mind is that we want code to read as close to "business logic" as possible - or as some people say, read like prose.
Sometimes they land on the job still on the honeymoon phase w/ technology, not having worked on a big enough codebase and stack, and not only take complexity as granted but actually find it exciting / stimulating.
A seasoned programmer learns to hate complexity and starts valuing expressiveness more. It takes some experience to be well calibrated on the complexity / abstraction axes.
Sometimes they land on the job still on the honeymoon phase w/ technology, not having worked on a big enough codebase and stack, and not only take complexity as granted but actually find it exciting / stimulating.
A seasoned programmer learns to hate complexity and starts valuing expressiveness more. It takes some experience to be well calibrated on the complexity / abstraction axes.
Does anyone have a mirrored or cached version of the post?
Let the frustration flow through you.
This was refreshing to read. I would have separated the checks out as simple functions as well or made it a class with more properties.
> - if it takes me more time to understand what you wrote than completely rewriting it you're of no use to me. Since I'm wasting that time anyway, I better write it myself and save the money spent on you.
So well put.
Too bad it's not just juniors who write code like this. I wish I could show the sample code and the TODO comments to one of the "senior" engineers I work with. Because it's exactly (and I mean, EXACTLY) like a few hundred functions he wrote in our codebase in the past few years.
How do you suggest this sort of change of approach to someone who's your peer instead of a n00b you're training up, without sounding condescending or insulting?
So well put.
Too bad it's not just juniors who write code like this. I wish I could show the sample code and the TODO comments to one of the "senior" engineers I work with. Because it's exactly (and I mean, EXACTLY) like a few hundred functions he wrote in our codebase in the past few years.
How do you suggest this sort of change of approach to someone who's your peer instead of a n00b you're training up, without sounding condescending or insulting?
Two mistakes in his reasoning that make that point in particular not well put:
1. It takes time, and only time, to develop this skill. It can't be ordered by fiat. He hired junior devs, so this is what he gets.
2. He's thinking in terms of absolute advantage, not comparative advantage. Even if he could code the item more efficiently, it's worth it for him to give it to them.
As for your peers, mandatory/automated testing, mandatory code reviews, automated formatting, pair programming: all are designed to teach people to be better programmers. Implementing some/all of the above won't directly cause an issue between you and the coworker and will help everyone's code become better.
1. It takes time, and only time, to develop this skill. It can't be ordered by fiat. He hired junior devs, so this is what he gets.
2. He's thinking in terms of absolute advantage, not comparative advantage. Even if he could code the item more efficiently, it's worth it for him to give it to them.
As for your peers, mandatory/automated testing, mandatory code reviews, automated formatting, pair programming: all are designed to teach people to be better programmers. Implementing some/all of the above won't directly cause an issue between you and the coworker and will help everyone's code become better.
As for point 2, if he's going to be reading it anyway, then there's no comparative advantage either.
Be better by example. A good project manager will see the value and you will be (hopefully) praised. Show him this post. Talk to him that you're having a bad time following his code. Rewrite some of his work and present it to him. These talks are always hard to initiate because they might not get the right message and turn on you. Good luck to you!
Sarcasm, insults and flowery nonsense like "write poetry" isn't code review, it's shaming.
And if we're being honest: TODOs aren't code review, either. Seems pretty amateurish, and worse, makes the horrible commentary part of the repo history rather than a separate artifact in an issue tracker.