Juniors Literally Can't Write Switch Statements: What Sr. Devs Need to Focus On
dev.to
dev.to
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.
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.
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.
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.
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 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.
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."
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.
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..
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();
}
if (x == 0) {
doThing1();
} else if (x == 1) {
doThing2();
} else {
doThing3();
}
[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.
(Though, I'm kind of baffled how they didn't know this stuff.)
And the first one is akin to:
if (data == 1) {}
if (data == 2) {}
if (data == 3) {}
...
if (data == thevalueIactuallywant) { doSomething(); } Switch(true) {
Case(int0):
// Do stuff for interrupt 0
Case(int1):
// Do stuff for interrupt 1
...[1] - tested on Safari, but still...
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.)