What are concrete examples of mistakes junior devs often make?
8 comments
"SELECT" isn't broken. (h/t The Pragmatic Programmer, by Hunt and Thomas) Junior programmers will sometimes think the problems they encounter are the fault of bugs in well-tested system software, rather than their own code. (1)
The implementers of the legacy code aren't stupid. It's very common for junior programmers, tossed into the swamp of some codebase that's been around for years through many different hands, think the code is junk and the original implementers were fools. Usually, it's just that the problem is much more complicated than the juniors understand, and that's how the code got that way.
New tools probably won't solve the problem. There's a tendency with junior programmers to whine about the antique tools in use, convinced that the new Foobaz framework or Language X will magically clear up the issues they encounter. But the problems with code usually aren't from the tools used to build the code - they're from failure to understand the requirements, and time/scope/resource constraints on development.
Perfect isn't as important as finished. It's easy to get caught up in perfectionism. It's a good excuse to avoid releasing something you find embarrassing into the world. But the more time you squander polishing that turd, the less time you have for the next tur... er, cool new project.
If you can't write a test for it, you don't understand it well enough. Writing good tests is hard. It's easy to fall into a trap of "That's too hard to test. I'll just sort of check manually to make sure it works". This will bite you in the ass later!
(1) My first really good bug as a junior programmer actually was a "SELECT is broken" kind of problem (technically, mmap() was broken). I went to a great deal of effort to prove to the senior programmers (and then IBM) that my code was actually correct and I had an OS bug. And if some junior programmer came to me today and said a deep system call like mmap() was broken, I'd laugh at her and tell her to check her code. So sometimes, SELECT actually is broken - just not as often as junior programmers think.
The implementers of the legacy code aren't stupid. It's very common for junior programmers, tossed into the swamp of some codebase that's been around for years through many different hands, think the code is junk and the original implementers were fools. Usually, it's just that the problem is much more complicated than the juniors understand, and that's how the code got that way.
New tools probably won't solve the problem. There's a tendency with junior programmers to whine about the antique tools in use, convinced that the new Foobaz framework or Language X will magically clear up the issues they encounter. But the problems with code usually aren't from the tools used to build the code - they're from failure to understand the requirements, and time/scope/resource constraints on development.
Perfect isn't as important as finished. It's easy to get caught up in perfectionism. It's a good excuse to avoid releasing something you find embarrassing into the world. But the more time you squander polishing that turd, the less time you have for the next tur... er, cool new project.
If you can't write a test for it, you don't understand it well enough. Writing good tests is hard. It's easy to fall into a trap of "That's too hard to test. I'll just sort of check manually to make sure it works". This will bite you in the ass later!
(1) My first really good bug as a junior programmer actually was a "SELECT is broken" kind of problem (technically, mmap() was broken). I went to a great deal of effort to prove to the senior programmers (and then IBM) that my code was actually correct and I had an OS bug. And if some junior programmer came to me today and said a deep system call like mmap() was broken, I'd laugh at her and tell her to check her code. So sometimes, SELECT actually is broken - just not as often as junior programmers think.
> If you can't write a test for it, you don't understand it well enough.
While this statement is generally true, I'm amazed how often people rely on substituting good architecture and composability of modules with tests. Like testability was some kind of magic chicken that made software good once somebody waved it over the codebase, while the tests are mostly useful for detecting regressions.
While this statement is generally true, I'm amazed how often people rely on substituting good architecture and composability of modules with tests. Like testability was some kind of magic chicken that made software good once somebody waved it over the codebase, while the tests are mostly useful for detecting regressions.
The ability to write tests is a fine measure of good architecture and composability. Excessive coupling is one of the top reasons tests can't be easily written.
Ok two personal pet peeves. 1: Check your code 100% before you say someone else is at fault. 2: You should assume the engineer before you had a reason for doing the things he did, do NOT assume they are an idiot until you have conclusive evidence that they are.
I say this after having spent a huge amount of time taking over code bases and figuring out that the reason people make engineering decisions sometimes have nothing to do with engineering. Many times the decisions are based upon some business process or "guidance" that led/pushed them down the path. That does not make the engineer or software necessarily bad, it makes the process or guidance faulty.
So many times as a consultant I come in and start researching the code and issues, and then work with the business to understand their issues. Then review the code and find that the code does exactly what they asked it to do (as stupid as it may be), but not what they intended. Do not assume an engineer before you made a mistake until you have proven they have. Assume you haven't seen all the facts initially and dig more. 80 or 90% of consulting is asking the questions to find out why more then how, understanding why tells you the how most of the time.
Just my 2 cents.
I say this after having spent a huge amount of time taking over code bases and figuring out that the reason people make engineering decisions sometimes have nothing to do with engineering. Many times the decisions are based upon some business process or "guidance" that led/pushed them down the path. That does not make the engineer or software necessarily bad, it makes the process or guidance faulty.
So many times as a consultant I come in and start researching the code and issues, and then work with the business to understand their issues. Then review the code and find that the code does exactly what they asked it to do (as stupid as it may be), but not what they intended. Do not assume an engineer before you made a mistake until you have proven they have. Assume you haven't seen all the facts initially and dig more. 80 or 90% of consulting is asking the questions to find out why more then how, understanding why tells you the how most of the time.
Just my 2 cents.
1) When someone comments on your pull request about how you could make your code more efficient - don't get upset - be happy to learn and get better at coding. And get back at your code and refactor it.
2) If someone is mean to you. Like really _mean_ to you, tell them. (Or tell team lead etc...) Some examples are: - UX guy jumping up on you grabbing your keyboard while in the middle of complicated rebase = not ok! - other developers not talking to you/ not helping you because they feel superior = not ok! - random people coming up to your desk demanding you take immediate action because they experienced 'some bug' = not ok! - people sending you cryptic emails "everything looks fucked up" = ... relax, tell them to send screenshots
3) Take breaks! I actually think this is one of the hardest points and I still cannot get myself up sometimes for breaks - but yeah - fucking take breaks! You don't need to go out with the smokers every 40 mins, but try to break for lunch and mayyybeee socialize (if your co-workers are actually sociable)
4) I can't believe I'm actually posting this but - if you happen to be a straight male and there's a female on the team... ugh... don't stare at her boobs or at her in general - talk to her about code - yes there are female coders out there and fyi they are just like you so don't be too creepy and listen to what they have to say about your code. -__-
2) If someone is mean to you. Like really _mean_ to you, tell them. (Or tell team lead etc...) Some examples are: - UX guy jumping up on you grabbing your keyboard while in the middle of complicated rebase = not ok! - other developers not talking to you/ not helping you because they feel superior = not ok! - random people coming up to your desk demanding you take immediate action because they experienced 'some bug' = not ok! - people sending you cryptic emails "everything looks fucked up" = ... relax, tell them to send screenshots
3) Take breaks! I actually think this is one of the hardest points and I still cannot get myself up sometimes for breaks - but yeah - fucking take breaks! You don't need to go out with the smokers every 40 mins, but try to break for lunch and mayyybeee socialize (if your co-workers are actually sociable)
4) I can't believe I'm actually posting this but - if you happen to be a straight male and there's a female on the team... ugh... don't stare at her boobs or at her in general - talk to her about code - yes there are female coders out there and fyi they are just like you so don't be too creepy and listen to what they have to say about your code. -__-
Looking at boobs and talking about code aren't mutually exclusive.
But one is encouraged (and is your job) and the other should be avoided (or you should be _really_ discreet).
And everybody oogles. It's just that men have a harder time being discreet about it :)
But one is encouraged (and is your job) and the other should be avoided (or you should be _really_ discreet).
And everybody oogles. It's just that men have a harder time being discreet about it :)
What does #4 have to do with being a typical junior-dev mistake?
Sounds like she was making a general point there. It seems ok to include in a list of junior dev tips, if for no other reason than a friendly reminder.
Also, many junior devs are fresh out of college, where boob-staring is a fond past time and hitting on classmates is a normal thing. But that's not acceptable in the work place.
They might also not be used to talking to women about code if their classes are predominately male. There are a lot of unrealized biases and bad habits that can go away with time and experience, but this is a good reminder for the introverted and extroverted alike: the women on your team are geeks just like you. Geek out with them!
Aside: I had to catch one of my own bad habits writing this post. I initially wrote "girls" instead of "women", which can be marginalizing terminology.
Also, many junior devs are fresh out of college, where boob-staring is a fond past time and hitting on classmates is a normal thing. But that's not acceptable in the work place.
They might also not be used to talking to women about code if their classes are predominately male. There are a lot of unrealized biases and bad habits that can go away with time and experience, but this is a good reminder for the introverted and extroverted alike: the women on your team are geeks just like you. Geek out with them!
Aside: I had to catch one of my own bad habits writing this post. I initially wrote "girls" instead of "women", which can be marginalizing terminology.
[deleted]
When trying to understand a bug, taking up a new framework, or anything with learning: don't read too fast. Read slowly and make sure you understand it. Read the stack trace. If you're 100% sure the documentation is lacking, read the source code, search through the issues, and ping the maintainer. Make a pull request while you're at it. It's okay to spend 1 day debugging by learning the foundations of a framework, rather than 1 day copy-pasting every StackOverflow answer you come across. That approach wastes your time without learning properly in the process.
6-10 years ago we didn't have all these frameworks and libraries. Junior devs are now faced with a mountain of these things that they can easily copy-paste without understanding what's underneath the hood. Make sure they keep the hacker ethos and try to open up those boxes from time to time, so that they'll understand the foundations of certain pieces of software.
6-10 years ago we didn't have all these frameworks and libraries. Junior devs are now faced with a mountain of these things that they can easily copy-paste without understanding what's underneath the hood. Make sure they keep the hacker ethos and try to open up those boxes from time to time, so that they'll understand the foundations of certain pieces of software.
Seconded!
It's definitely worth the time to point out edge cases, bugs, and documentation issues. 1 hour of your time to file a good issue might save you 10 hours in a month when the project maintainers resolve it, and everyone else in the community benefits from it.
It also gives you a chance to take your mind off the day to day grind, and perhaps do things the right way (like including stack traces and example code usage in the bug report). I find the process of contributing to open source projects very fulfilling, and it really brings out the craftsmanship in my work which is sometimes suppressed in the day-to-day.
It's definitely worth the time to point out edge cases, bugs, and documentation issues. 1 hour of your time to file a good issue might save you 10 hours in a month when the project maintainers resolve it, and everyone else in the community benefits from it.
It also gives you a chance to take your mind off the day to day grind, and perhaps do things the right way (like including stack traces and example code usage in the bug report). I find the process of contributing to open source projects very fulfilling, and it really brings out the craftsmanship in my work which is sometimes suppressed in the day-to-day.
The biggest thing I see is not considering edge cases.
They'll have a certain way they are checking a few cases (and maybe a couple tests), but they don't have the foresight to really try to break things. They will also make assumptions about how the code will be called, what entities will exist at that point, etc. that just don't hold in reality.
This typically manifests in code that works fine when they use it, and all the tests pass, but it breaks as soon as it gets up on the staging server, or as soon as somebody else tries to use it.
Also: Not listening to feedback from senior devs. Drastically underestimating the complexity of what they are working on.
They'll have a certain way they are checking a few cases (and maybe a couple tests), but they don't have the foresight to really try to break things. They will also make assumptions about how the code will be called, what entities will exist at that point, etc. that just don't hold in reality.
This typically manifests in code that works fine when they use it, and all the tests pass, but it breaks as soon as it gets up on the staging server, or as soon as somebody else tries to use it.
Also: Not listening to feedback from senior devs. Drastically underestimating the complexity of what they are working on.
- Over-engineer architecture (or the tech stack), including not-invented-here-syndrome.
- Underestimate dev time needed, especially the "second 90%".
- Early optimization, from unnecessary loops to unnecessary tech stack selection.
- Underestimate dev time needed, especially the "second 90%".
- Early optimization, from unnecessary loops to unnecessary tech stack selection.
- Why this project took 2 years if I can rewrite this in 2 weeks
- Code is messy, I should rewrite everything using pattern X, framework Y
- Who makes such awful design, it barely works
- Code is messy, I should rewrite everything using pattern X, framework Y
- Who makes such awful design, it barely works
This question has been asked sooooooooooo many times that some are worn out answering it.
Look at Quora. You will find a couple hundred answers.
Hope that helps.
Look at Quora. You will find a couple hundred answers.
Hope that helps.
The rest, it seems, comes down to mentorship/guidance/learning on the job.
But it also seems that some of this guidance can very easily be learned by the junior dev himself/herself (and thereby making mentorship more fun and less "What the hell, dude" for the senior engineer).
Is there a particular class of mistakes that junior devs almost undoubtedly make that they can make sure to be aware of before Day 1 on the job?