Wow! I think regardless of the junior this is a failure on the authors part not to handle this internally and instead write this blog post. He could have mentored the new guy, and he could have taken it as an opportunity to reflect on his teams practices.
To the actual commentary; I might be wrong but it’s giving me dogmatic vibes. All the things mentioned can be ok, sometimes good, and also bad in the wrong situations. Context matters. Doing the things described (in moderation) is not by definition bad.
This seems like a perfectly wasted learning opportunity for everyone involved. I would strongly urge the author to reflect on this as an important part of being senior is to lift other less senior people up so they can be productive and progress in their careers.
Honestly appalled at the way the author went about addressing this issue. All of these problems could be resolved by creating/requesting clear guidelines or just mentoring the newbie programmer.
You're re-describing the object in question using oversimplified, generalized terms to make it make it seem less significant/dramatic - the qualifier "random" as used here is a common hallmark of that style of sniping. It's certainly reasonable to disagree with the parent's opinion about the author's behavior, but this is a non-constructive, curt way to express it.
Regardless, I don't think the word "appalled" is totally off base. The author's attitude and actions are highly destructive in our line of work. It has real, concrete consequences and should be rigorously discouraged. "Complaining about a work situation" is a broad category, and it can cover a lot of little cases that don't really matter, but this isn't one of that subset.
An entire post made of 90% sarcasm is a junior writing style.
Also, the behavior described is not necessarily indicative of junior-ness. Sounds more like he’s not used to writing code as part of a team.
For instance, I put most of my code into one file. For years I didn’t understand these idiots who think that small functions and many files is easier to deal with than large ones… until I realized it was because I own all my code. I don’t work on a team. If I were on a team then my preferred style would create code merging hell.
I am not junior. But I am a mountain man when it comes to programming.
Hermit, yeah. I do a lot of collaborative work with testers, but my coding has been mostly alone. I have not been a production programmer for 35 years, and even then I worked almost alone.
I'm not junior in the sense that I have made my living as a consulting software tester for decades. I code usually to prototype things to demonstrate and teach about testing. My clients then pick them up and implement them as they wish.
For true prototyping, code quality is not very important, because my client doesn't want my code-- they want to see a possible solution.
Whenever I AM doing something with other guys, as has happened a lot more since the pandemic started, I try to adopt a more cosmopolitan practice.
I think that is right. But while some people might hear "hermit" and think of a hermetic monk, "mountain man" connotes more wildness. He might fashion his dev tools from the pelts of whatever animal he slaughtered last winter...
It's important to reflect, once in a while, about how BIG the world of software tech is. It's like a galaxy, with whole globular clusters in it that see the world entirely within their own Node.js or Lisp or whatever perspective.
I love HN because it is the one best way I have of tasting the incredible depth and diversity of that world. On the one hand it gives me a feeling that I know very little about software development... but on the other I realize that my own specialty (software testing as social science) is little understood by others. I'm a decent star within my own cluster.
So, maybe everyone who reads HN has a similar experience, no matter where in the galaxy they call home.
(Except that people who work in big teams on popular products are more in the center of the galaxy)
I've worked with newbie programmers that think they are senior. I've worked with mid-level programmers that think they are senior and always ready to label others as being junior. And I've worked with really senior engineers that never comment on someone's skill level and instead focus on how to build them up and help them grow.
I don't necessarily blame anyone for falling into these categories. Sure there are annoying egos and some people can be overly confident when it's unwarranted. But it can be very difficult for people to figure out where they fit, especially when they don't know what they don't know.
There is another category. Once I took a job in a new stack and was explicitly a junior dev in senior's clothing (no lying involved; the employer knew what they were getting). I thought it would be fun, but it was a deeply unpleasant experience. I realized then that you either stick with your basic stack or endure at intense ego pain with a half-life of ~4 years. It is NOT enough to have all the fundamentals down to instantly learn a new stack, the differences between languages is NOT just syntax, or a new build tool. It's an entire world in which you must learn to live. You can apply a lot of what you learned in the other world, but that will only help you make good decisions, and will NOT help you produce great code in the new world.
> that will only help you make good decisions, and will NOT help you produce great code in the new world.
Your code will be clear and, more importantly, you won't need to go back and change it because you took the time and had the knowledge to make good decisions.
Any code you write that interfaces with your old stack will seem uncanny and wizard-like to other devs.
Thank you for writing this so that I know I’m not alone. I’ve seen so many people act like it’s no big deal to switch tech stacks that I thought I’d try it myself. It has been a humbling experience to the point I often ponder about going back.
Glad it helped! I suspect that most people who don't think it's a big deal haven't done it for real and don't really know what it's like to do it in a professional environment. The pitfalls are many, not least of which is that you'll find yourself in the odd position of knowing a lot and being unable to express it in actual code. It's like having a stroke.
This is repulsive behavior on the part of the author even if his complaints were founded, but the justifications offered include some pretty subjective stuff on which the author, hypocritically, believes there is exactly one correct approach.
#8 (he writes too many comments, that means he has a superiority complex) is especially ridiculous.
Hmm. I find the post a little shallow here. Half these things are somewhat debatable and matters of taste. I think a lot of experience without a nuanced view of how universal best practices are (or aren't) is wasted experience.
Or maybe I'm defensive because I like fewer files, tolerate many parameters (It depends on why they're there!), and prefer bigger PRs when the alternative is 5 PRs that only make sense if you're looking at all of them.
I'm undoubtedly a senior or something like that, and I agree with your choices. And that the items in the article seem shallow.
Regarding file size, I've seen people insist on hundreds of tiny files to satisfy their interpretation of the SRP - single responsibility principle - to the extent a codebase is more difficult to read because half of the files are almost entirely boilerplate, pointing to boilerplate in other files. It makes some people happy, but doesn't always make a better codebase to work with. (Though for some things like, say, Glibc, that approach to systematic file layout is quite helpful, even when some files have only one non-comment line.)
I've also found when I see someone talking about uncomfortably small or large files, it's a mistake to presume what they have in mind. For some people, a 500 line source file is an enormous monstrosity that should never have existed. For others, 2000 lines (in the same language as previous) is a single good day's work containing one medium-size algorithm.
I also agree with you about about PR sizes, because I hold the view that the optimal unit of review (ie PR that makes sense) is larger than the optimal size of a well-explained logical commit. Although, the GitHub-encouraged culture of squash-merges conflicts with right-sized PRs and informative commits, so it's understandable there is conflict in that area. I'm not a fan of the GitHub workflow that many have been trained by exposure to presume must be good practice. GitHub didn't design that workflow for optimal software engineering, nor have they ever really tried to improve it. They designed it to make it easier for newbies and more casual participants to join in "social coding".
Experience tells me that there are many who would disagree with your views and mine, though. Ironically, the most dogmatic people are sometimes those who haven't been at it for as long and think they know best. (Though all ages are definitely represented in the dogmatic pile). Perhaps it's the author of the article who is the newbie?!
What a negative post. Each of these things that the author complains about is a learning opportunity or an opportunity for the company to improve their onboarding.
Single letter variable names? Maybe you need a style guide.
Massive CRs? You need code review standards.
Not testing code? Coverage requirements.
and so on. If the author chose to mentor the new hire rather than berate them on a blog post, they could probably change all these behaviors in a week.
I am really confused by this post. It definitely sounds that the senior developer might be a bit older thand the poster and might have a different opinion on how to do certain things. There is definitely the need for some conversations.
The critique is a mixed bag in my eyes, there are some things in there I wouldn't consider a bad thing. Like file size. Yes, you shouldn't literally put everything into a single file, but there are some pros and cons about it. Editors are usually really good about handling large files, but often not so good on working on lots of small files. Code which belongs together, should be together. I certainly think that the habit of having lots of files with just a few lines of code in each is a bad one. As with many things, the trick is to find the best balance.
Same with variable names. The closer the scope, the more they are used, the shorter they should be. Again, of course, with taste. Calling a loop variable i is actually a good practise, especially if it is an index. With nested loops that becomes a bit more careful to do. Of course anything with a large scope or infrequent uses across the code, should have a long and descriptive name.
I mean.... I have 12 years experience and I do each and every one of these things in the last year. I've submitted Pull Requests with 5k lines of code. Some things are impossible to efficiently test, or force the code to be contorted to satisfy the test. I'm currently editing an ancient procedural code base which is almost older than me and one of the files is over 50k lines. When we edit it we try to add comments as literally no one on the team has any idea how anything works. If you figure it out, you are almost guaranteed to not remember it by next week.
IMHO a lot of dogmatism leaves you over the years as it just doesn't matter. If you insist on a dogmatism you are limiting yourself and your team.
If the newbie was ill-fitted for the seniority level, its a recruitment screwup. If he's just someone with little experience, then the author is just being a dick.
Also, this kind of poorly-thought, hasty, angsty blog post makes me wish HN had a "sage" button.
Is it just me, or does the writer need to learn how to properly weave sarcasm into a story? I found it hard to read, for some reason. And really, he was able to learn that much from one code review? That the guy keeps to himself, is competitive, and avoids meetings? Or did the story weaving fail again?
I wouldn't want to work here either. It doesn't sound like the "newbie" was given any coding standards, the senior seems to think they are not necessary because his way is "the way". And besides, I'm not fond of meetings either, which makes me a newbie.
Is this a satirical article? I find it hard to believe someone would write like this behind their coworker's back. It certainly is written to sound that way though.
Yes, can you feel it? The awesomeness of backtracking issues?
And a few sayings, which I came up with[2] immeadiately after seeing this kind of crap:
* Using your ten-year-experience as your only argument is invalid. It is indeed possible to do things in a wrong way for ten years.
* The faster you climb up the career ladder, the more incompetent you will get, due to the lack of skill.
I hated working with them, because they knew everything better than me. I was "just a junior" to that time.
Oh well, I am glad, that I am not working with them anymore, otherwise I would become headless zombie administrators like them, who like to work quick and dirty all the time without having a thought about refactoring something.
Another saying; this time from Miyamoto Musashi[3], which I align and agree to:
* There is nothing outside of yourself that can ever enable you to get better, stronger, richer, quicker or smarter. Everything is within. Everything exists. Seek nothing outside yourself.
If I ever see the author of this post in an interview, I would immediately strongly recommend to not hire the person. This post reeks of arrogance and toxic work culture. The best thing the author should do is delete it.
The funny thing being, I much get the vibes of a nowadays senior programmers meeting a veteran programmer from the last century. (Maybe, he's avoiding meetings to not show off his grey beard? :-) )
It would have been more constructive for the author to make the same points as things they've learned that make a good coder rather than shitting on a colleague. Whether their colleague is using what the author would consider to be good practices or not, it sounds like the colleague is merely doing their best with the knowledge that they have and are apparently confident enough in their skills that they can get things done.
The truth is that neither of these individuals are demonstrated to be senior-level by this article. Unless otherwise is said, I take it that the author hasn't actually done anything to elevate this new coder. Yes, I'm making an assumption, but that's what I usually see. Rather than create systems to help newbies of any experience level, most people would rather complain than, say, create requirements around new code being tested, or having lint rules.
Most of the points the author makes are dubious.
> 1. He puts everything in one file.
There is no one answer on this. Prove that it's better. Oh, wait, you can't. And depending on the software community, it may be expected for verboten.
> 2. He creates single letter variables
I prefer verbosity, but some algorithmic things are better suited for single letters. Can be bad depending on how used.
> 3. He makes functions with loads of parameters
Honestly never understood why anyone gave a shit about the number of parameters. A better rule should be that a function should have a single purpose and only accept parameters related to that purpose. If there's a lot of parameters then either accept that fact, split the function up, or pass in named properties (or a hash). Even adding adequate JSDoc comments makes complex parameters understandable.
I do prefer to limit the number of parameters, but getting your panties in a bunch if someone uses more than 3 parameters is usually a complete waste of time. If you don't like it, let the other person merge their PR and then change it yourself.
> 4. He always makes massive Pull Requests
Depends on the task. In many cases, small pull requests don't make sense because individual changes are potentially breaking and the nature of the task isn't a linear progression of changes. Maybe he's making massive PRs because you're giving him far too complicated tasks for his experience level. An otherwise simple PR can easily balloon because the developer is learning a lot of concepts as they're going, and they can't predict the eventual size of their work.
> 5. He doesn’t want to write needs tests
Not everyone is taught about tests. They might hear about tests, but in general people see tests as a nuisance, and I understand why, because when I work on hobby projects I don't write out a bunch of tests for everything initially. It's not fun. But in a professional circumstance, tests are a lifesaver because it's evidence that your work is sound and that you aren't likely to get an emergency phone call in the middle of the night. If someone doesn't experience the virtues of writing tests, it's not obvious why one would go through the extra work.
The answer is to have standards around tests. Make it a requirement to at least have an integration, application, or e2e test for a change.
> 6. Keep your tests green
So you're saying this person is intentionally pushing tests that don't pass? And shouldn't you have a repository that prevents merging if tests aren't passing?
> 9. He avoids meetings
Maybe your meetings are bullshit. We're only hearing one side of the story on this. For all I know, you haven't invited him to these meetings on his calendar. I missed meetings in one of my first jobs because it turned out no one invited me to them.
> 10. He thinks he is competing with everyone
You've created an environment where he is competing with everyone. Instead of using him as a bad example on the internet, either figure out how to help him be the best he can be on your team or let him go (if you're in control of that).
Between the sarcasm and numerous grammatical errors, 50% of this article is unintelligible to me. I cannot understand what the author is saying at all on points 4, 5, and 9.
To the actual commentary; I might be wrong but it’s giving me dogmatic vibes. All the things mentioned can be ok, sometimes good, and also bad in the wrong situations. Context matters. Doing the things described (in moderation) is not by definition bad.
This seems like a perfectly wasted learning opportunity for everyone involved. I would strongly urge the author to reflect on this as an important part of being senior is to lift other less senior people up so they can be productive and progress in their careers.