
Juniors Literally Can't Write Switch Statements: What Sr. Devs Need to Focus On - bhalp1
https://dev.to/robdwaller/juniors-literally-cant-write-switch-statements-what-senior-php-developers-need-to-focus-on-986
======
pavel_lishin
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.

~~~
theSpaceOctopus
> 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.

------
onion2k
_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. :)

~~~
taeric
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.)

------
StevePerkins
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.

~~~
btschaegg
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.

------
IshKebab
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?

~~~
tbrake
> 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.

------
maxxxxx
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.

~~~
abiox
> Yes let's create another clearly delineated group: junior devs vs senior
> devs, liberal vs conservative

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.

~~~
maxxxxx
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.

------
marak830
(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?

~~~
viiralvx
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.

~~~
marak830
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.

~~~
ghaff
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.)

~~~
marak830
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.

Well the more you learn I guess :-)

~~~
ghaff
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."

~~~
marak830
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).

------
b3b0p
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.

------
ChicagoDave
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.

~~~
gremlinsinc
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..

~~~
ChicagoDave
Can you still ignore encapsulation and call methods across pages (classes)?

------
jankotek
I know senior Java devs with 20 years experience, who can not write switch
statement. It is pretty limited language construct.

~~~
paulddraper
It's weird, and even harmful in many cases.

A modern goto of sorts: it has performance benefits [1], but not overall
readability ones.

    
    
        switch (x) {
           case 0:
               doThing1();
               break;
           case 1:
               doThing2();
               break;
           default
               doThing3();
       }
    

vs

    
    
        if (x == 0) {
            doThing1();
        } else if (x == 1) {
            doThing2();
        } else {
            doThing3();
        }
    

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](https://en.wikipedia.org/wiki/Duff%27s_device)

[2] [https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-
got...](https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-
apples-ssl-bug-explained-plus-an-unofficial-patch/)

~~~
archagon
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.)

~~~
paulddraper
Scala pattern matching is the same.

Both are less easy to misuse than C switch.

------
eximius
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.)

------
zwischenzug
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...

~~~
meowface
I can't think of any case where `switch(true)` is what you actually want to
do, barring some weird compiler workaround or hack or something.

And the first one is akin to:

    
    
        if (data == 1) {}
        if (data == 2) {}
        if (data == 3) {}
        ...
        if (data == thevalueIactuallywant) { doSomething(); }

~~~
tonmoy
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
        ...

~~~
meowface
I stand corrected. Assuming no fallthrough, what are the advantages of this
over chaining if and else-if? Just to look cleaner?

~~~
consz
I believe the point is to explicitly take advantage of the fallthrough.

~~~
meowface
Well, then it would just be chaining if statements.

------
tjtrapp
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.

------
nine_k
(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.)

~~~
dang
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.

Those old hats are actually pretty good.

~~~
nine_k
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.

(This is to say nothing about PHP as a language.)

~~~
dang
Ok, I'll give you s/those old hats/that old hat/. I use case expressions in my
Lisp code all the time. Those are switches and they're pretty good.

~~~
nine_k
(case...) has no fall-through, the hallmark of the switch statement. Hence the
sanity of the former.

------
lanewinfield
Literally overuse of "literally."

------
charlesdm
Someone who can't write (or doesn't understand the concept behind) a switch
statement shouldn't really be called a junior developer...

------
bitL
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...

