Deeply condescending commentary in those TODOs, and the commentary before it suddenly takes on a dark intent: to wow the junior with your wordsmithing and desire to lift them up, before tearing them down with the code review. Seems like the behavior of a bully senior, rather than a supportive mentor.<p>Sarcasm, insults and flowery nonsense like "write poetry" isn't code review, it's shaming.<p>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.
> 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.<p>> 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.<p>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.<p>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.<p>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<p>Next time you probably should take the guy and talk with him privately instead of publicly shaming?<p>Also "Python really is beautiful, Python is english...write me some poetry please." <i>cringe</i>.
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.
> - 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.<p>So well put.<p>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.<p>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?
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.<p>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.<p>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.