How do you deal with having a junior dev on your team? The main problems I'm encountering with them are poor attention to detail, inability to reason about software architecture, and lack of knowledge about development tooling. As a result of these three things, I'm spending 10-20% of my time dealing with this one person. Most of that time is spent on the following:
1. Explaining why the tests they wrote don't actually test the thing they're trying to test
2. Explaining how to use version control
3. Answering the same questions over and over
I tried nicely telling them RTFM with their version control questions, but they just fucked everything up and ended up needing more help. I tried pointing them at some beginner resources for software testing, but they apparently didn't understand it. Please help. I'm going crazy.
>inb4 give them time
It's been months.
>inb4 your fault for hiring them
I was not involved in hiring this person.
>inb4 you're an ass
Yes.
Junior devs
Other urls found in this thread:
construx.com
twitter.com
You are suppose to mentor juniors.
this
people come out of school with the bare basics of how to write a program
this is so that the first person to hire them can teach them how to write THEIR programs without conflicting instructions
you are just a bad teacher
I can commiserate. Sometimes the juniors learn, but there will always be the ones that still think they are in college and still try to half ass everything. I've been trying to instill good practices into the new hire for months now but I still have to remind them to compile and run the code before pushing it up. Some people are just going to be lazy and you just have to put up with it until their incompetency is finally made apparent to the higher ups.
Are there any good books for a new dev to learn best practices from?
I'm speaking as a literal retard
If it's been months there's no hope. Just fire him and hope you get lucky with the replacement.
I don't know specific resources, but incorporating advice people tell you about goes a long way. The other junior dev we hired writes the advice we give them down and incorporates that into the next features that they work on. Honestly being forced to learn things during the crunch is the best way to get skills down pat. Dive into the deep end and avoid the turds.
> Code Complete 2nd Edition, Steve McConnell
> Programming Pearls 2nd Edition, Jon Bentley
> Refactoring, Martin Fowler
> Applying UML & Patterns, Craig Larman
> The Art of Testing, Glenford Myers
> Conceptual Blockbusting, James Adams
> Software Creativity, Robert Glass
construx.com
Thankyou user
I'll also add:
>Clean Code, and
>The Clean Coder
Both by Robert Martin.
Both of the books hammer on unit testing and writing code that is easily testable (small, modular, non-dependent methods).
The latter focuses more on professional behaviors of a software engineer, how to talk to customers, etc.
If its been months and they cant grasp basic shit like writing tests and vc they need to be let go. Dont answer questions you have answers more than 3 times, yoi are enabling their failure.
It's expected that you help a junior to improve as a developer to actually provide value for the team, but for your own sanity please take into consideration the following:
1. Yes, you're supposed to answer questions regarding best practices, language idioms, program architecture and all the other nice things that otherwise juniors would learn by fucking up everything, or by wasting a lot of time reading blog posts while trying to compare conflicting opinions (with the added burden of having no experience to discern actual GOOD advice from just eloquent blogspam bullshit).
2. Less ambiguous questions regarding language or development environment features ("how to amend a commit?", "how to use this library to do X?", etc) should be asked less often, as they're searchable and usually don't benefit much from the input of someone more senior. Either you're using the library correctly and shit compiles, or not. An exception to this is of course if there's little documentation available, or the existing documentation is wrong, or the thing is so confusing/archaic that the only christian thing to do is to spare the junior from having to "understand" it (read: randomly try things until something works).
3. Team conventions regarding processes, architecture guides, code styling, what to avoid, test coverage rules, etc. should be documented somewhere, and where posible, they should be enforced by automated linting tools or similar.
4. Finally, there's no reason for answering the same question more than twice. The second time it happens, you make sure notes are taken (you may write the first few notes to get the message across, but if that doesn't happen then you'll need to be more explicit about it), and after the talk you send the links of any resource used to answer the question via email/irc/whatever.
Of course, all of this requires that the junior is acting on good faith and can learn somewhat autonomously. Otherwise you're just wasting your time.
Shut the fuck up go fuck off to stackexchange you think you're so high and proper man, you do not belong on this website. Jow Forums is for the young not dying greycunts. Go complain about your fucking retarded old man brain and old man problems elsewhere that has more normalfags
>still think they are in college and still try to half ass everything
You know it's really arrogant of you to think that they'd perform at 100% for your stupid fucking petty company if they didn't even give 100% at school. Why would they give a shit about WORK, dude it's fucking work, why would you break your back for your fucking shit job for someone else's shekels?
If I got to be a part of the hire committee sure, that would make sense. But when HR decides to hire some rando with no skills without asking for any input from anyone on the team it's pretty irritating. Working is just a part of life and when people don't carry their weight I have to pick up the slack. Enjoy the neet life while you can man, wish I could join you.
Can you give some data?
Rate each of them and post also their gender and their skin color.
I'm curious to know if there is any correlation.
Let them fuck up then make them fix it. Make them write documentation.
I wish I could be told exactly what to do and given super specific tasks. instead i'm given a vague task that I don't even have any idea how to start with frameworks I have never touched.
more than anything though, i wish i had more feedback in what i'm doing and how i could improve. I don't know whats expected of me.
Whenever I get help/guidance I learn a lot though and i actually feel like a half decent programmer. I wish i had a mentor like you OP.
Why would you get into programming if you don't like it? I enjoy coding and fucking around with computers in general, so for me going to work to code means getting paid for doing something I've been doing since high school for the joy of it. I'm actually shitty at it though, but whatever.
If your only interests are watching Netflix and jerking off, then you are a fucking parasite and a turbo pleb, and you should kill yourself asap.
Work is work
not that femanon but i kinda understand where she's coming from. i like programming and computers too. i like my job but i hate going to work. i don't work because i want to i work because i have to.
Because you're getting paid for it, and if you keep doing a bad job at it, you can be replaced?
>femanon
>she
No one here has a vagina, user.
Lmao. Too close to home?
I'd say do what you can but accept that their success is not under your control.
So one thing that might help is sitting down with them, picking a concrete problem that won't take too long to solve, and then walking them through it. You might literally have to tell them what key to press when. You might not have the patience for that.
When explaining how to use a program or the structure of an existing codebase, I think most people tend to give explanations that are too abstract and not helpful to someone with a very weak model of the system.
>go to college to be a programmer
>can't program after graduating
and people shill for college anyways
There is only one. They are genderqueer and have light green skin.
>Not knowing how to use version control
>Does not understand testing
This person is not a professional. This is not a junior dev, this is an intern.