
What are concrete examples of mistakes junior devs often make? - lpcrealmadrid
There are plenty of resources out there for learning language paradigms, discrete math, and CS theory, so that&#x27;s firmly on a junior dev&#x27;s shoulders to take up,practice, and eat, breathe, and sleep.<p>The rest, it seems, comes down to mentorship&#x2F;guidance&#x2F;learning on the job.<p>But it also seems that some of this guidance can very easily be learned by the junior dev himself&#x2F;herself (and thereby making mentorship more fun and less &quot;What the hell, dude&quot; for the senior engineer).<p>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?
======
beat
_" 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.

~~~
dozzie
> _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.

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

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

------
kalzium
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. -__-

~~~
erbdex
What does #4 have to do with being a typical junior-dev mistake?

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

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

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

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

------
petervandijck
\- 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.

------
tuyguntn
\- _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_

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

