
Ask HN: Lessons you wish you knew when you were Junior developer? - gls2ro
I was wondering do you have some recommendation that would help along the learning path of Junior to become very good at what one does?
======
forgottenpass
Don't fall for the memes. The overlap between what people talk about online,
and what people are succeeding with in industry are way way smaller than you
think.

Some people can't be bothered to blog. Some people aren't allowed to blog.
Some people are paid to write blog posts they know are bullshit bad advice.

~~~
namenotrequired
Do you have any examples?

------
shubhamjain
I wish I knew that 'superficial' expertise at a particular technology isn't a
pre-requisite for most tech jobs. Two years back, I was invariably anxious
about not knowing Angular / Rails / Django and how it disqualified me from
getting my foot in the door in many companies.

I later realised, how daft it would be for any company to have a stringent
demand for knowledge in framework / library without putting the general
"getting-things-done" talent into the equation. The sheer velocity of the
changing landscape makes it a horrible way to judge an engineer. Additionally,
I wish I knew that soft skills in communicating well, giving feedback, and
understanding business goals make up for more points than a breadth of tech
skills.

~~~
madamelic
You should look at GitHub.

Most of their listings include a "Must have 3 years of experience in Ruby on
Rails".

~~~
kzisme
That's the unfortunate part - it seems like most places you have to take your
own personal time to learn a language enough to transition between careers.

Unless you're a developer with 10+ years of experience or something, and the
company/job you are applying for overlooks your lack of knowledge in a subject
area.

------
itamarst
Here are some mistakes I've made as a junior engineer:

\- Not checking code well enough when working in a new and unfamiliar language
(I broke production)

\- Not negotiating my salary (almost took a massively underpaid job)

\- using an obscure technology when I should have used something mainstream

The list goes on...

I'm writing each of my mistakes up as a weekly email, so if you want to avoid
all the mistakes I've made in 20 years of software engineering check out
[https://softwareclown.com](https://softwareclown.com)

------
tahpot
You need excellent communication skills to become an excellent coder.

You need to clearly describe bugs for other developers, write documentation,
explain why a particular technology / framework / pattern is the best choice,
understand what a client / product manager is wanting... the list goes on.
Eventually, you will hopefully be training and supporting other developers.

How much of your time will be spent coding and how much will be spent
communicating with others about your code?

------
pattrn
As a junior developer, I overvalued minimizing development time and maximizing
correctness. It turned out that writing code for other people to read and
modify was a more difficult skill to improve, was more rewarding when
successful, and enabled entire teams to move faster. It also turned out that
focusing on improving the experience for my team actually improved my personal
development more rapidly than before.

If I could send a message to my past self, it would be, "Empathize with
coworkers, customers, and family. Everything else will follow."

------
afarrell
If you don't have the resources you need to complete a project, don't be
afraid to speak up. If the documentation for a project is in another language,
it is far cheaper for the company to pay for professional translation than for
the project to putter along and fail as you struggle with google translate.

Similarly, if the end-goal of a project is not clear, don't be afraid to stop
things and ask.

Judge new tools by the quality of documentation and how possible it is for you
to get a clear mental model.

In interviews, always as what their onboarding process is.

If someone asks for a time estimate and you don't know the answer, don't let
them pressure you into lying. Hold your ground and say you don't know.

~~~
hga
Your first two and last points should included an implicit "Don't be afraid of
being shown the door", or "Don't be surprised if your complaints are
essentially ignored" and you might as well leave.

I.e make it a highest priority to build enough of a finical cushion that doing
these things are even an option.

------
lojack
In regard to various software engineering literature and quotes (hofstadter's
law, mythical man month, etc) while there's some truth in what they say, what
you'll take away is absolute lies.

\- Just because you can't reliably estimate a project doesn't give you an
excuse to refuse to give an estimate. We get it, your estimate will be off.
Whats important is that you communicate deadline changes early and often.

\- Contrary to everything you hear, software projects can be finished on time.
Most of the time we procrastinate at the start of a project and crunch at the
end. Stop procrastinating at the start and more projects will be completed on
time. Which brings me to...

\- If you fail to complete a project on time and failed to communicate this
impending delay early, this is 100% your fault. This isn't the fault of some
stupid law, or book you read. You slacked off and as a result couldn't
reliably see how much work was involved in the project and by the time you
realized it was probably too late. This is on you.

~~~
TeeWEE
I totally oppose this. Sometimes there are to many unkowns to give an
estimation. Its better to NOT estimate because it doesnt hold any values.

'finished on time'.... This is the waterfall approach. Its broken in its core.
So i also disagree with that.

~~~
lojack
> Its better to NOT estimate because it doesnt hold any values.

This is the core of where I disagree. Giving estimates provide tremendous
value to those who depend on your work. It allows them to plan and forecast
future needs.

You're rarely ever working in some kind of bubble where your work is this
mysterious thing that can be done tomorrow or in 4 years. I've never
encountered a situation where there's so many unknowns that you can't come up
with some number. Requirements change, timelines change, that's all fine.
Businesses should be able to adapt to change. Being in the complete dark is
much worse.

> 'finished on time'.... This is the waterfall approach.

I'm not sure what you mean by that? Things can't be late just because you're
"agile"?

~~~
namenotrequired
> I'm not sure what you mean by that? Things can't be late just because you're
> "agile"?

I think TeeWEE means that in modern practice a product isn't "finished", it is
launched but continually improved afterwards.

~~~
lojack
And to that (I know, not your words) I'd say he's incorrectly making the
assumption that projects and products are synonyms, when they aren't. Projects
are completed all the time, even in Agile.

------
awareBrah
Few things off the top of my heads

\- horrible at negotiating and playing it safe

\- biggest mistake was probably being afraid to read source code of third
party libraries when the docs led me to a dead end. Always read the source

\- stop trying to make everything DRY, duplication is better than obfuscation

~~~
kzisme
How often do other programmers make use of third party libraries?

I use them fairly often to parse things or make things more seamless, but is
that the general way people go about solving problems? Is that wrong?

Implementing a OSS library yourself seems overkill, but at what point is it
worth writing something yourself?

~~~
HeyLaughingBoy
Third party libraries should be the nails and screws of the software world:
you should be able to trust that they are fit for the job and not waste the
time building them yourself.

The main reason to write it yourself is if the libraries you find are crap, or
you can't find any at all.

------
zer00eyz
Learn to read code.

Learning to read code is a hell of a lot harder than learning to write it. It
takes practice, patience and ultimately a language with a high quality working
debugger. Once you learn to read code in one language it isn't hard to learn
to read it in another.

Love your IDE/editor, and make sure that you have split views (viewing parts
of the same file or two files at once). This feature is essential to being
able to read code!

Figure out the difference between "I wouldn't do it that way" and "this code
is bad". It isn't terribly hard to leap from one to the other.

Find a mentor! I can't stress this one enough. That guy (or gal though they
are rare) pushing fifty who is still an engineer, they are that good, don't
want to manage, love their craft, and have seen some shit. They will talk your
ear off (probably) for coffee.

Lastly writing code is part of the job, once you have master that learn
everything you can about your business. Spend time with accountants, CS
people, Systems Admins, the IT guys... they are all going to teach you things
that will make you better at your job.

------
EliRivers
Once you've finished learning anything new, and your job is becoming
significantly more routine, start looking around for the next job (with a pay
rise). Rather than learn new things on your own a few hours a week, you can
get paid (more) to learn new things at work for many hours a week. Three
significantly different jobs over ten years will make you far more competent
than the same job for fifteen or even twenty years.

If you get to five years in the same job, take a long hard look at yourself
and check that you are actually still learning and still making yourself more
valuable and still improving (which I would expect to really only happen if
you weren't actually doing the same job as you were in the first of those five
years).

------
mattgibson
Unit and integration testing not only make code less buggy, but lead to a calm
state of mind.

Bugs show themselves quickly, along with which method is failing, so the fixes
are fast and effortless when you break stuff. Massive refactoring doesn't
scare you, and you sleep soundly with no fear of hidden breakages after each
new release.

------
mobiuscog
Don't use a framework or library until you have written a simple variation of
it yourself (ideally, this could apply to everything, but you need to find the
correct balance).

~~~
afarrell
That sounds like you would need to do a whole lot of work before you could
start writing code that is useful to the business that hires you. If your
first job out of uni is working at a company that has built a site in ruby on
rails, you shouldn't refuse to handle tickets until you've reproduced rails.
Also, if you want to learn backend web development, it is far easier to first
work through the djangogirls tutorial and learn how django works and then
build a stripped-down version of it.

I would replace it with "Don't add a new framework or library unless you can
get a clear mental model of it"

~~~
mobiuscog
I wasn't referring to 'business' practices though - this is about becoming a
good programmer.

What the business needs, will never be the best way to become good.

By all means shove stuff out the door quickly at work, as you'll then be fully
startup-ready.

Just spend your own time learning from first principles and actually
understanding how things work.

"No one knows what he can do till he tries"

~~~
afarrell
I'm not saying "shove stuff out the door quickly". I'm saying that frameworks
are tools that can help you:

1) Accomplish things.

2) Gain one overarching-if-shallow view of a problem domain works

However, they can also be a pile of complexity that prevents you from
understanding problems or moving forward. The question to ask is: Can you form
a solid mental model from the documentation? If you can, then the framework is
useful and can be a decent curated entry-point into understanding something.

You'll still want to take that shallow understanding and dive deeper.

------
kafkaesq
You know, the term "junior developer" is rather new, actually. If anything it
used to just be "entry-level".

In any case, I find it most distasteful. No one should accept it as a part of
their job title for any length of time, other than out of pure, survival-
driven necessity.

~~~
kasey_junk
Does it change the conversation in any significant way to call it "entry level
developer"?

Is the complaint about "junior" implying age? I'm trying to understand.

[edit] further is the term "senior" developer also problematic?

~~~
kafkaesq
The term "junior" itself has certain negative connotations. Among the various
dictionary entries we have, for example:

 _adj. Low in rank; having a subordinate role, job, or situation._

 _n. One of less experience or inferior standing in his profession than
another, who is called his senior; one employed as the subordinate of another,
especially at the bar._

 _n. term of address for a disrespectful and annoying male_

I'm cherry-picking these, of course (out of a body of mostly neutral
variants), but the point is, these negative touches do carry across.

"Senior" is a bit different, somehow (mostly because it's no intrinsically
defined in terms of negative attributes like "inexperienced" or
"subordinate").

------
andrei_says_
Figuring things out is a process. Don't expect to write production-ready code
at first run.

Every step of the journey informs the outcome and sometimes the destination.
Code and logic change -- so learn to program in ways hat adapt to change.

\---

Try new things and concepts in tiny single purpose projects.

\---

Ask for help, programmers like to explain things.

\---

Ask why from your business users. Multiple times, until you get the context.
Once you have the context, you can create freely and come up with better ways
to do things. If you don't position yourself in this way, you may end up with
people trying to control you like they would a tool or a sock puppet. Having
people's hands up your bum is no fun.

\---

Fight for uninterrupted focused time. This is your spice and the spice must
flow.

------
goo
Here is some insight that has helped me, some my own advice, some paraphrased
from other sources, and I credit the source when I have it in my notes:

\- There is no "silver bullet" for managing the complexity of user needs.
Instead, (good) software is characterized by not a static state of "solving
the problem", but a continuous refinement-- an existential struggle against
incidental complexity.

\- Have a very positive mindset, and inspire the same in your team.

\- highly reliable websites for small companies:
[http://www.kalzumeus.com/2010/04/20/building-highly-
reliable...](http://www.kalzumeus.com/2010/04/20/building-highly-reliable-
websites-for-small-companies/)

\- Learn your debugging tools well: Get good at Chrome Debugging tools, pdb,
visual studios debugger, or whatever the debugging environment is for your
project.

\- “… never consider your education complete or your opinion above questioning
regardless of your title, your years of experience, your awards and
accomplishments, or anything else that isn’t rational argumentation or
evidence. Retaining a healthy degree of humility, constantly striving for
improvement, and valuing objective metrics above subjective considerations
will go a long way ..." ([http://www.daedtech.com/how-software-groups-rot-
legacy-of-th...](http://www.daedtech.com/how-software-groups-rot-legacy-of-
the-expert-beginner))

\- This is a marathon, not a sprint.

\- Practical engineering advice: [https://www.quora.com/What-are-the-best-
kept-secrets-of-grea...](https://www.quora.com/What-are-the-best-kept-secrets-
of-great-programmers/answer/Jens-Rantil?srid=V3G&share=1)

\- Read books. I can especially recommend Refactoring by Martin Fowler and The
Pragmatic Programmer as a more introductory text (affiliate links:
[http://amzn.to/2ekPnTL](http://amzn.to/2ekPnTL) and
[http://amzn.to/2ekJQMK](http://amzn.to/2ekJQMK)). Understanding why and how
to do scrum effectively is really important too -- I waited too long to read a
book that laid that out for me
([http://amzn.to/2ekPxul](http://amzn.to/2ekPxul))

\- Good programming advice from Kent Beck:
[https://www.facebook.com/notes/kent-beck/mastering-
programmi...](https://www.facebook.com/notes/kent-beck/mastering-
programming/1184427814923414/)

\- Eventually, you will have to choose between engineering management and
continuing to be close to technology. Trying to do both is a recipe for
burnout. Some people might be able to do both simultaneously without trouble,
but you're probably not one of them.

\- Always be looking for ways to remove yourself as a bottleneck. This needs
to be done both on a technical level and on an organizational level.

\- Push back as necessary against demands of your time and energy that are not
in harmony with your needs as a technologist.

\- Good programming comes from good habits. (in that vein: copy-and-paste is
the devil.)

\- Seriously, read books. It's incredible how much good advice is out there.

~~~
madamelic
>\- Good programming comes from good habits. (in that vein: copy-and-paste is
the devil.)

Hardly.

Copy-and-paste is fine if you understand how and why it works. Magic is bad
but forcing yourself to needlessly re-invent the wheel is a dumb idea in
itself.

~~~
goo
I'm not suggesting that C+P is magic, or a tool that should not be used.
Understanding how and why C+P isn't really important. Being careful to only
copy tokens or lines that don't introduce bugs (or making sure to modify those
lines once you've copied them) IS really important. It's one of the more
common ways to accidentally write bad code, and although of course I (like
everyone) use C+P as a tool too, I think it is valuable to be aware of the
increased risk. It's like driving. You're gonna drive, or someone on your team
is, but it's one of the highest likelihood activities for accidental death.

------
thefastlane
figure out who makes the decision on your raise/bonus, and make sure you
nurture a positive relationship with that person. usually your boss; maybe a
group of managers, etc.

------
navyad
\-- read more code.

\-- write code then reflect on it.

\-- connect to like minded peoples.

\-- communicate clearly and effectively to make sure your message is conveyed
the way you wanted.

