What are concrete examples of mistakes junior devs often make?
There are plenty of resources out there for learning language paradigms, discrete math, and CS theory, so that's firmly on a junior dev's shoulders to take up,practice, and eat, breathe, and sleep.
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?
17 comments
[ 0.21 ms ] story [ 53.1 ms ] threadLook at Quora. You will find a couple hundred answers.
Hope that helps.
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.
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.
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.
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.
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.
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. -__-
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.
Stop apologizing to everyone. There is nothing wrong saying girls vs women. Who gives a shit in grand scheme of things, unless you are also SJW. Live free in the land of the brave.
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 :)
>>>Straight
What the fuck this has anything to do with question OP posted? Do you lack reading comprehension ?
Question OP is asking is about coding and work related stuff and what you are spitting is social justice warrior ship.
People like you are the reason why there is so much gender gap. Even if there is no issue , SJWs like you create one without context.
DO NOT again post anything like on this site where people come for good advice. Go back to Reddit or your safety net Tumblr.
- Underestimate dev time needed, especially the "second 90%".
- Early optimization, from unnecessary loops to unnecessary tech stack selection.
- Code is messy, I should rewrite everything using pattern X, framework Y
- Who makes such awful design, it barely works
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.