Yes let's create another clearly delineated group: junior devs vs senior devs, liberal vs conservative and so on. There are plenty of senior devs who would do the same thing.
The article wouldn't be that bad if it was titled "make an effort to understand before you are blindly copying from "Stack overflow".
Maybe the whole industry would do well learning the basics of coding.
I am a bit reductive but I really hate it when people draw these clear boundaries and then associate certain attributes with the groups they just created. There is no clear line between junior and senior and there is no clear line between liberal and conservative. These labels hinder improvement.
Back to Junior vs senior: there are plenty of senior devs who do exactly the same stuff. So in my mind it's not junior vs senior but people who think about what they are doing vs others who don't.
There is a strong tendency in some people to create unnecessary splits everywhere. In this particular case being a senior developer means little. The author could well make a point without creating an artificial divide.
He is talking about people who know what they are doing and why and others who don't. He shouldn't have used the terms "Junior" and "Senior". I am pretty Senior but I sometimes do stupid stuff do in a rush. that doesn't make me junior.
There are plenty of guys who have been around for only a short time that are better than people who have been there for years. You can't go by title or tenure. You have to look at each individual and see how skilled they are by their work and their attitude. Words like junior or senior don't help.
> You have to look at each individual and see how skilled they are by their work and their attitude.
And after you do this, then you have already " create another clearly delineated group".
And then how you communicate your finding to the rest of the team? This is the "skilled guy"? The "one that can do it?" And then how about the other that is not better?
Except that these are not two groups, but continuum. And often time senior does not have all that much experience, but a lot of confidence and read some blogs. And oftentimes junior does know more about something then senior (may be much better in css or framework), but is still not ready to work individually.
In many startups, senior has like 1 year of experience more
and just happens to be controlling "my way or the high way" type.
If you really want to reach someone, you gotta see him more individually then "junior" and you gotta consider whether what that kid might need now is a bit of autonomy and possibility to try things his way - including possibility to do miatakes and learn from them
If you can't do either, you are just micromanager.
There's a few things potentially wrong (or right, in fact, depending on context - maybe you want them to fall through) with those switch statements, so I'm not sure precisely what he's objecting to...
The first example would be better as a simple if..else. The second example is doing an instanceof check on every case where it ought to be using switch(get_class($object)).
`switch (true)` is insane, but it does actually work as the author intended it to in PHP. It just evaluates each of the case statements in order until one evaluates to true, so it's equivalent to an if/else chain.
Actually in the hardware world I see switch(true) a lot. It is very useful for creating a priority encoder. For example you have 3 interrupts with priorities int0 > int1 > int2. Then this code is pretty clean and concise:
Switch(true) {
Case(int0):
// Do stuff for interrupt 0
Case(int1):
// Do stuff for interrupt 1
...
As a senior dev, I'd recommend moving off of PHP or at least training junior DEV's how to code properly before using PHP. Even in the old days of BASIC with numbered lines you could teach solid principals. These languages just have more ways to screw up, which need to be understood by anyone using them. But to understand how and why you can screw up, you need to understand what good coding practices would look like.
PHP is a very strong language (Esp php 7.0) .. it's grown up a lot since the crap from 4 and early 5 branches.
There's totally nothing wrong with using PHP as it's found on most servers, and available just about everywhere.
Junior's should be trained though on best practices, how to write testable/maintainable/self-documenting code, the different Design Patterns and using things like repositories properly and why/why not to use them depending on size and scope of project...etc..
In case yo didn't realize it, when you create a compiler, you should invent a better language.
I made HolyC from God. It is divine intellect.
It is way better than C/C++.
the switch statements are enhanced.
It hilarious when you change an opcode when you write an assembler and someone retard thinks it is a different CPU or when you change a programming langugae when you write a compiler and the person thinks it doesn't compile. I wrote the compiler, you retard nigger. I have divine intellect, yew fucken monkey.
Beyond actually coding stuff, the day job, the primary focus of senior developers should be to educate and guide junior developers.
As a general rule the thing that gets a developer to start writing better code is when they eventually come around to the idea that writing tests and documentation is actually worthwhile. Then they start write code that they can write tests and documentation for, and then, as if by magic, their code improves.
As a senior the only thing you need to do is show them your tests and documentation, demonstrate why it makes life easier, and make sure they have time to do the 'additional' work of writing tests and documentation (juniors think it adds time rather than saving time; they think in the short term).
If you're feeling a little mean then you can decline their pull requests because the code doesn't have good enough test coverage. :)
There is a lot hidden in the "idea that writing tests and documentation is actually worthwhile." Few (any?) will argue against that. The problem is there are actually three skills embedded there.
I am coming to view it in three parts:
Testing code typically benefits most from being able to think about how the code is not supposed to act.
Writing code is typically describing what you want.
Documenting code is talking about how all of the code is supposed to work together.
I think most examples online that try and get folks better at any one of these, pick an example that is worthless for the other two skills. In particular, writing solid tests for a function or unit does little to help document how it will work with all of the other parts. Writing good documentation for a unit is trivial, so not often applicable to a person's day job. And then seeing the documentation for a full piece is often too much to include the code and tests. (I'm talking specifically about "blog" level articles.)
+1 on this.
First day for interns and junior devs is to write testcases and setup a proper debugger. Fresh graduates do not come with an understanding of testcases - usually they have heard about "The Social Network", Steve Jobs or Linux Torvalds. Everyone wants to rewrite the codebase .
Its when you lock them in a room with testcases and a debugger that understanding dawns.
(disclaimer: I'm self taught, did a few months of University but couldn't afford more - dirt poor family).
I'm a little confused(and more than a bit shocked), isn't this what University is suppose to teach?
I agree with the author about mentoring and passing on experience(infact as soon as I have reliable net I'll be checking out his links in that article, and any previous posts he has made), but how can you pass any course without learning the basics of a switch statement.
Although I do admit in guilty of copy/pasting some code I have gotten online :-p (purely just to get-shit-moving again when I'm stuck, I'll always refactor later to learn how it works exactly).
Unless I'm missing something (hell I would kill for a junior dev job without the expense of University :-p), how did these juniors pass their exams?
That's the thing. If they went to school for Computer Science, depending on the program, we aren't necessarily taught how to code. More about how to think and solve problems. I never had to use a switch statement in my Algorithms or Data Structures course.
I learned how to write tests after pairing with a person from Twitter on some Rails work a few years back. He randomly saw me testing things manually and then he was like, "Let me show you how to write tests for this so you don't have to waste time manually testing." And I've just written tests since then. But my University never taught us how to write tests for our code. Some professors gave us a test suite for our code to run against as a sanity check, but that's about it. I became a better software engineer through great mentorship and building stuff in my free time.
That's actually really surprising. Thank you for your input.
I had assumed it would have been -teach basics of code, explain the thinking behind it and why to use certain things at such time, then slowly expand upon that. Hmm certanly something for me to think about.
> How would you get a job a job as a junior dev without any form of dev training.
By demonstrating the skill of computer programming, a skill you can teach yourself at home anytime; you do not need on the job experience to gain this skill.
When I hire devs, I give them a toy problem to solve at home on their own time, and then I base my decision to hire on the potential I see in their solution. I don't care about experience, I don't read their resumes, I simply judge them based on the solution they provide.
Surprisingly, those with little experience and a natural aptitude generally write much better code than those with experience who aren't really cut out for the job but made a career out of it anyway and could solve any problem you give them. It's easier to train the first guy, than to teach the second guy how to be better.
> Side note: how could you be a Dev without knowing the fundamentals of how to code?
Learning to code requires neither a job, nor a degree; it merely requires the desire to learn and access to the internet.
Computer science isn't about programming though you need to learn some programming to do it, it's about computation and what it can do and can't do and what the fundamental limits of computation are and how to understand them and measure them. Computer science is the physics of programming; Computer science is to programming what physics is to engineering. Computer scientists create knowledge about computing, computer programmers use that knowledge to build things.
The way I did was by building side projects and showing my code off on github and things... Having a portfolio can help and then you just need to find one job to get a few years experience under your belt.
In practice, I think you'd be hard put to find a university CS degree that didn't involve a fair bit of programming. There was often more distinction in the past, especially at schools where CS came out of the Math department for historical reasons. But look at something like the Intro to Algorithms and CS class at MIT--there's a two-part MOOC on edX--and there's definitely programming. (Although it's clearly designed for people who already have some programming background. The assumption at top-tier schools tends to be that incoming students who want to major in CS already know programming to some degree, which has it's own set of problems but that's another topic.)
Hmm that an interesting point of view for those schools to take. I'm sure they have a reason for it, I just haven't quite figured it :-)
Putting it into something I'm more familiar with(eg formally trained), if I had a chef who had just finished his degree I'd certainly expect them to understand how flavours combine, every single standard cooking technique, basic soups, stocks and sauces, as well as able to prepare all standard western food from purchasing, through preparing from the full carcass (for meats) up to presentation.
Which for me I had assumed can degrees would do for programming.
Top-tier engineering schools tend to be pretty theory-heavy. To the degree they teach programming, it's mostly a means to an end. It's not MIT's objective that you can code a working website by the time you graduate. You may be able to but it's mostly a byproduct of being exposed to programming as part of various course work.
It's also the case that many/most of the students coming into a school like MIT to major in CS have been playing with computers for a long time. Which tends to lead to a course program that assumes more prior knowledge than is the norm with other types of engineering. Unfortunately, this has the effect of making it harder for students who don't have that prior background to get into computers in college.
The chef example is pretty different because any cooking school is very hands on and is probably pretty light on the theoretical underpinnings of the "science of food."
Hmm okay, I appreciate the reply, I don't necessarily agree it's the best course, but then again, I'm not a call major, so it's mostly gut feeling(always a bad place to start from haha).
Ok, I'm relatively new to professional coding (I tried to be an engineer for a while before being lured in by the programming money). I have a question: what exactly is a junior developer? I mean, if you don't understand how a 'switch' works, I would have thought that basically means you can't program, and shouldn't be working as a programmer.
Is it really the job of non-junior programmers to teach the junior ones how to code? What level would you expect a "junior C++ developer" to be?
> Ok, I'm relatively new to professional coding (I tried to be an engineer for a while before being lured in by the programming money). I have a question: what exactly is a junior developer? I mean, if you don't understand how a 'switch' works, I would have thought that basically means you can't program, and shouldn't be working as a programmer.
Generally I think misusing language constructs as in this 'switch' example - or misapplying patterns - are the hallmarks of a junior. They used the screwdriver handle to drive the nail in, and sure, it works, they just didn't know a hammer was available to do it better.
And without wanting to get too silly with the tools analogy, the eventual accumulation of those tools in your brain's toolbox is what makes you move from junior to mid to senior, but there's no clearly defined line of when that is, or which tools they are, because the field is so varied and each language/ecosystem carries its own nuances.
Junior is just a title, nominally it means you aren't experienced enough to work undirected. You could have amazing C++ language knowledge and still be a junior. You could also have very little but be skilled with another language. Even at a senior level you can get jobs outside of your immediate language experience. The difference being that a senior is expected to have enough experience to quickly pickup the language without too much mentoring and not need help with much else work wise whilst a junior might need help in all sorts of domains. Almost everyone regardless of level requires some onboard taking on a new job.
As an aside you should look at someone in aggregate rather than purely judging them by something dumb they did. If we all got judged so harshly on our silly mistakes or quirky knowledge gaps no one would be fit to program professionally.
And yes one of the things you will do at a senior level is mentor others in language use.
In my experience, a junior developer can't see as many of the potential pitfalls ahead, and tends to solve the immediate problem - as well as usually using the first solution they can think of or come across.
Which is fine; if you're straight out of school, you might not have a huge variety of resources to draw on. You haven't shot yourself in the foot often enough to figure out which directions aren't a great idea to point a gun in.
Is there any "safe space" I can escape the ever increasing stupidity of our civilization? I try MOOCs, university degrees, etc. but it's just getting worse and worse. It's like the Nothing in Neverending Story that was taking over the world...
(Did not read the article, judging only by its title.)
Do not teach switch statements, they are old hat and are error-prone.
Teach pattern matching statements. Actually, even kids understand them much better.
(To downvoters: yes, I mean using better, more adequate tools first, to teach the important principles. The traditional flintstone tools still in use can be taught later, from a vantage point of better understanding.)
I remember Nick Lowe in an interview saying one of the best things about getting older is you get less judgmental. He was talking about music and his example was that one day he realized: hey, Barry Manilow is actually pretty good.
Not all hats get old the same way. Between Cobol (1959), Fortran (1957), and Lisp (1958), some aged better than others.
C may be considered to have aged exceptionally well, despite its syntactical warts, like the declaration syntax, switch statement, lack of module system, etc. Unfortunately, some of these features were imported to other languages because of the familiarity, not because of e.g. good ergonomics or deep logic behind them.
I use it because if your switch is exhaustive, it's nice that the compiler can tell you exactly which parts of your code need to be updated when you add cases to an enum. (Also, in Swift, fallthrough is opt-in instead of opt-out, which is great.)
Laravel dev 4+ years... I use switch VERY rarely.. only if I have 4+ different possible outputs from the result of a variable... I also think switch's are kind of ugly and don't jive w/ my mindset.. I think more in if/then's... if using loops using laravel collections instead.
I tend to classify the developer track using terminology borrowed from American high schools. "Freshman", "Sophomore", and then "Senior".
The Freshmen are straight out of school. Hopefully the DO know how to write a `switch` statement (that's just basic competence)... but they typically know little or nothing about working in a team, source control branching strategy, unit testing, breaking tasks up into tickets and estimating them, and a thousand other aspects of real-world professional development.
The Sophomore phase is when you know enough to be dangerous. You've mastered all of those basics, and have set about learning more advanced topics. You've learned a 100 different design patterns from books or blogs, and can't wait to find excuses to incorporate each one somewhere (whether justified or not). You've learned Groovy/Scala/Clojure/Kotlin whatever, and lobby to migrate your company's application because going back to plain Java is too unbearable. Etc.
The Seniors aren't much more knowledgeable than the Sophomores. They've simply gone through enough ego-gratification, that at this point they have the confidence to demur on complexity and favor simplicity instead. They tend to write more documentation and code comments, explicitly declare their types for visual clarity, terminate statements with semicolons even if their language doesn't require it, etc. They can push back on bad business requirements, and tend to offer more conservative (i.e. informed and realistic) estimates.
Typically, the Sophomores teach the Freshmen. The Seniors teach the Sophomores. I've never seen anyone jump over the middle step.
> They've simply gone through enough ego-gratification, that at this point they have the confidence to demur on complexity and favor simplicity instead.
I think they've also made enough mistakes in their past to spot potential new ones well in advance - that's what makes them valuable, in my opinion.
A question on your model then: How does the progression of people through those "states" work. Are they judged by the team?
I've interacted with a couple of senior developers who - without a doubt - had considerably more experience in the industry, knew more about niche-specific technology etc. etc, but were worse in all the things you just listed for the freshmen than some of the people I studied with.
Experience and insight might get you very far, but there are also people who really don't care to learn new approaches on a certain topics, and those might as well be unit testing, versioning or even the readability of code.
I guess in bigger companies, this might balance itself out, but if your dev team consists of about five people, there's always the chance you're in for a surprise if you're the new hire.
iirc the last time i used a switch was to create a static factory method to instantiate objects. the static class had a static method that took an enum as input. the return type was an abstract base class. the method switched off of the enum, new'd up the type - did some common initialization - and returned the new object to the caller. this approach keeps your "creation" logic in one place.
This whole article boils down to "new hires require training". Is this surprising to anyone?
Yes, those are examples of bad code - I've written it, and in a code review (y'all do those, via reading pull requests or some other method, right? Your new hires don't just start shoving commits into master, right?), the senior developers pointed out my mistakes, and showed me the correct way to do things. Once I became a somewhat better developer, it was my turn to do the same thing for those who know less than I do - or even for those who maybe just got a bad night's sleep, and aren't at their best that day.
It is fucking frightening that this blog post needs to be written.
> This whole article boils down to "new hires require training".
There were also the parts about needless bickering in the PHP community, the responsibility of senior developers to guide junior developers, and the importance of keeping an open mind.
This has nothint to do with junior developers; this has to do with bad developers who don't know what a switch statement is. I'm glad they used it as a learning opportunity.
(Though, I'm kind of baffled how they didn't know this stuff.)
I'd like to mention that job title alone is no indication or measure of being a senior developer in my own personal opinion. Neither is years of experience.
I know many developers, who have years of experience, at one or many companies, startups and big (public) corporations, but continue to make what one could call junior or beginner mistakes, never seem to learn from past experience, and/or continue to commit and pull request bad, breaking code.
Also, I think calling out co-workers on a public blog (on the front page of Hacker News no less) and ridiculing their code, no matter how mind blowing, at any company, is not very professional. I don't care if you are at a young hot start up with twenty year olds or not even a formed company yet or work in a corporation with 80,000 other engineers.
I realize everyone probably has their own definitions of junior, senior, and whatever other level of development hierarchies we can come up with, but I personal think this blog post and copying code directly off a website willy-nilly like the article describes are both junior level or unprofessional attributes.
Disclaimer, I couldn't stomach finishing reading this post.
72 comments
[ 4.1 ms ] story [ 117 ms ] threadThe article wouldn't be that bad if it was titled "make an effort to understand before you are blindly copying from "Stack overflow".
Maybe the whole industry would do well learning the basics of coding.
i think it's a clear sign that you're being a bit reductive if you can compare "junior vs senior" with "liberal vs conservative" and not bat an eye.
Back to Junior vs senior: there are plenty of senior devs who do exactly the same stuff. So in my mind it's not junior vs senior but people who think about what they are doing vs others who don't.
So, is equally to hire a fresh grad or Linus Torvald? You can't figure if Linus or the fresh grad is a senior or a junior?
And after you do this, then you have already " create another clearly delineated group".
And then how you communicate your finding to the rest of the team? This is the "skilled guy"? The "one that can do it?" And then how about the other that is not better?
In many startups, senior has like 1 year of experience more and just happens to be controlling "my way or the high way" type.
If you really want to reach someone, you gotta see him more individually then "junior" and you gotta consider whether what that kid might need now is a bit of autonomy and possibility to try things his way - including possibility to do miatakes and learn from them If you can't do either, you are just micromanager.
And the first one is akin to:
[1] - tested on Safari, but still...
There's totally nothing wrong with using PHP as it's found on most servers, and available just about everywhere.
Junior's should be trained though on best practices, how to write testable/maintainable/self-documenting code, the different Design Patterns and using things like repositories properly and why/why not to use them depending on size and scope of project...etc..
I made HolyC from God. It is divine intellect.
It is way better than C/C++.
the switch statements are enhanced.
It hilarious when you change an opcode when you write an assembler and someone retard thinks it is a different CPU or when you change a programming langugae when you write a compiler and the person thinks it doesn't compile. I wrote the compiler, you retard nigger. I have divine intellect, yew fucken monkey.
As a general rule the thing that gets a developer to start writing better code is when they eventually come around to the idea that writing tests and documentation is actually worthwhile. Then they start write code that they can write tests and documentation for, and then, as if by magic, their code improves.
As a senior the only thing you need to do is show them your tests and documentation, demonstrate why it makes life easier, and make sure they have time to do the 'additional' work of writing tests and documentation (juniors think it adds time rather than saving time; they think in the short term).
If you're feeling a little mean then you can decline their pull requests because the code doesn't have good enough test coverage. :)
I am coming to view it in three parts:
Testing code typically benefits most from being able to think about how the code is not supposed to act.
Writing code is typically describing what you want.
Documenting code is talking about how all of the code is supposed to work together.
I think most examples online that try and get folks better at any one of these, pick an example that is worthless for the other two skills. In particular, writing solid tests for a function or unit does little to help document how it will work with all of the other parts. Writing good documentation for a unit is trivial, so not often applicable to a person's day job. And then seeing the documentation for a full piece is often too much to include the code and tests. (I'm talking specifically about "blog" level articles.)
Its when you lock them in a room with testcases and a debugger that understanding dawns.
I'm a little confused(and more than a bit shocked), isn't this what University is suppose to teach?
I agree with the author about mentoring and passing on experience(infact as soon as I have reliable net I'll be checking out his links in that article, and any previous posts he has made), but how can you pass any course without learning the basics of a switch statement.
Although I do admit in guilty of copy/pasting some code I have gotten online :-p (purely just to get-shit-moving again when I'm stuck, I'll always refactor later to learn how it works exactly).
Unless I'm missing something (hell I would kill for a junior dev job without the expense of University :-p), how did these juniors pass their exams?
I learned how to write tests after pairing with a person from Twitter on some Rails work a few years back. He randomly saw me testing things manually and then he was like, "Let me show you how to write tests for this so you don't have to waste time manually testing." And I've just written tests since then. But my University never taught us how to write tests for our code. Some professors gave us a test suite for our code to run against as a sanity check, but that's about it. I became a better software engineer through great mentorship and building stuff in my free time.
I had assumed it would have been -teach basics of code, explain the thinking behind it and why to use certain things at such time, then slowly expand upon that. Hmm certanly something for me to think about.
How would you get a job a job as a junior dev without any form of dev training.
Side note: how could you be a Dev without knowing the fundamentals of how to code?
I looked up a computer science course (https://ocw.mit.edu/courses/electrical-engineering-and-compu...)
Which seems to cover some programming. Surely something such as a switch statement would be included?
Edit: fixed course link.
By demonstrating the skill of computer programming, a skill you can teach yourself at home anytime; you do not need on the job experience to gain this skill.
When I hire devs, I give them a toy problem to solve at home on their own time, and then I base my decision to hire on the potential I see in their solution. I don't care about experience, I don't read their resumes, I simply judge them based on the solution they provide.
Surprisingly, those with little experience and a natural aptitude generally write much better code than those with experience who aren't really cut out for the job but made a career out of it anyway and could solve any problem you give them. It's easier to train the first guy, than to teach the second guy how to be better.
> Side note: how could you be a Dev without knowing the fundamentals of how to code?
Learning to code requires neither a job, nor a degree; it merely requires the desire to learn and access to the internet.
Computer science isn't about programming though you need to learn some programming to do it, it's about computation and what it can do and can't do and what the fundamental limits of computation are and how to understand them and measure them. Computer science is the physics of programming; Computer science is to programming what physics is to engineering. Computer scientists create knowledge about computing, computer programmers use that knowledge to build things.
Putting it into something I'm more familiar with(eg formally trained), if I had a chef who had just finished his degree I'd certainly expect them to understand how flavours combine, every single standard cooking technique, basic soups, stocks and sauces, as well as able to prepare all standard western food from purchasing, through preparing from the full carcass (for meats) up to presentation.
Which for me I had assumed can degrees would do for programming.
Well the more you learn I guess :-)
It's also the case that many/most of the students coming into a school like MIT to major in CS have been playing with computers for a long time. Which tends to lead to a course program that assumes more prior knowledge than is the norm with other types of engineering. Unfortunately, this has the effect of making it harder for students who don't have that prior background to get into computers in college.
The chef example is pretty different because any cooking school is very hands on and is probably pretty light on the theoretical underpinnings of the "science of food."
Is it really the job of non-junior programmers to teach the junior ones how to code? What level would you expect a "junior C++ developer" to be?
Generally I think misusing language constructs as in this 'switch' example - or misapplying patterns - are the hallmarks of a junior. They used the screwdriver handle to drive the nail in, and sure, it works, they just didn't know a hammer was available to do it better.
And without wanting to get too silly with the tools analogy, the eventual accumulation of those tools in your brain's toolbox is what makes you move from junior to mid to senior, but there's no clearly defined line of when that is, or which tools they are, because the field is so varied and each language/ecosystem carries its own nuances.
As an aside you should look at someone in aggregate rather than purely judging them by something dumb they did. If we all got judged so harshly on our silly mistakes or quirky knowledge gaps no one would be fit to program professionally.
And yes one of the things you will do at a senior level is mentor others in language use.
Which is fine; if you're straight out of school, you might not have a huge variety of resources to draw on. You haven't shot yourself in the foot often enough to figure out which directions aren't a great idea to point a gun in.
It doesn't mean you're a bad programmer.
Do not teach switch statements, they are old hat and are error-prone.
Teach pattern matching statements. Actually, even kids understand them much better.
(To downvoters: yes, I mean using better, more adequate tools first, to teach the important principles. The traditional flintstone tools still in use can be taught later, from a vantage point of better understanding.)
Those old hats are actually pretty good.
C may be considered to have aged exceptionally well, despite its syntactical warts, like the declaration syntax, switch statement, lack of module system, etc. Unfortunately, some of these features were imported to other languages because of the familiarity, not because of e.g. good ergonomics or deep logic behind them.
(This is to say nothing about PHP as a language.)
A modern goto of sorts: it has performance benefits [1], but not overall readability ones.
vs This somewhat unsafe form of switch-case made it into C, Java, C#, and JavaScript, and cases the great iOS SSL bug of 2014. [2][1] https://en.wikipedia.org/wiki/Duff%27s_device
[2] https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-got...
Both are less easy to misuse than C switch.
The Freshmen are straight out of school. Hopefully the DO know how to write a `switch` statement (that's just basic competence)... but they typically know little or nothing about working in a team, source control branching strategy, unit testing, breaking tasks up into tickets and estimating them, and a thousand other aspects of real-world professional development.
The Sophomore phase is when you know enough to be dangerous. You've mastered all of those basics, and have set about learning more advanced topics. You've learned a 100 different design patterns from books or blogs, and can't wait to find excuses to incorporate each one somewhere (whether justified or not). You've learned Groovy/Scala/Clojure/Kotlin whatever, and lobby to migrate your company's application because going back to plain Java is too unbearable. Etc.
The Seniors aren't much more knowledgeable than the Sophomores. They've simply gone through enough ego-gratification, that at this point they have the confidence to demur on complexity and favor simplicity instead. They tend to write more documentation and code comments, explicitly declare their types for visual clarity, terminate statements with semicolons even if their language doesn't require it, etc. They can push back on bad business requirements, and tend to offer more conservative (i.e. informed and realistic) estimates.
Typically, the Sophomores teach the Freshmen. The Seniors teach the Sophomores. I've never seen anyone jump over the middle step.
I think they've also made enough mistakes in their past to spot potential new ones well in advance - that's what makes them valuable, in my opinion.
I've interacted with a couple of senior developers who - without a doubt - had considerably more experience in the industry, knew more about niche-specific technology etc. etc, but were worse in all the things you just listed for the freshmen than some of the people I studied with.
Experience and insight might get you very far, but there are also people who really don't care to learn new approaches on a certain topics, and those might as well be unit testing, versioning or even the readability of code.
I guess in bigger companies, this might balance itself out, but if your dev team consists of about five people, there's always the chance you're in for a surprise if you're the new hire.
Yes, those are examples of bad code - I've written it, and in a code review (y'all do those, via reading pull requests or some other method, right? Your new hires don't just start shoving commits into master, right?), the senior developers pointed out my mistakes, and showed me the correct way to do things. Once I became a somewhat better developer, it was my turn to do the same thing for those who know less than I do - or even for those who maybe just got a bad night's sleep, and aren't at their best that day.
It is fucking frightening that this blog post needs to be written.
There were also the parts about needless bickering in the PHP community, the responsibility of senior developers to guide junior developers, and the importance of keeping an open mind.
(Though, I'm kind of baffled how they didn't know this stuff.)
I know many developers, who have years of experience, at one or many companies, startups and big (public) corporations, but continue to make what one could call junior or beginner mistakes, never seem to learn from past experience, and/or continue to commit and pull request bad, breaking code.
Also, I think calling out co-workers on a public blog (on the front page of Hacker News no less) and ridiculing their code, no matter how mind blowing, at any company, is not very professional. I don't care if you are at a young hot start up with twenty year olds or not even a formed company yet or work in a corporation with 80,000 other engineers.
I realize everyone probably has their own definitions of junior, senior, and whatever other level of development hierarchies we can come up with, but I personal think this blog post and copying code directly off a website willy-nilly like the article describes are both junior level or unprofessional attributes.
Disclaimer, I couldn't stomach finishing reading this post.