Ask HN: What is 1 thing that can take a Junior's career to the next level? - hgailo
======
jjguy
Take the time to understand the whole system you work within, not just your
little stovepipe.

That system may not be technical, but procedural. It will include other
business functions. It may include your customers. In any system, there is a
clear "start" and "end" that encompasses a complete process and reason for
being.

You'll find that in most organizations, people stay in their little corner, do
their little thing, not caring much about what happens to the left and right
of them. That leads to inefficiencies and missed opportunities.

If you understand the larger system, you'll be able to see opportunities
others are blind to. Point a couple out and -if you're both respectful and
right - it won't take folks long to think "man, this guy really gets it!"

~~~
sampl
A great way to do this: join a small startup. I did, and I learned more in the
first week than I could have ever hoped to at my old job.

Also related: [https://schloss.quora.com/Design-doesnt-deserve-a-seat-at-
th...](https://schloss.quora.com/Design-doesnt-deserve-a-seat-at-the-table)

~~~
shados
assuming both the startup and the "big company" you compare it to are great in
their respective categories, I find it to be a wash. My career was split
pretty 50/50 between startups and big companies (about half dozen of each as
my sample size), I found them to be similar in term of learning. You just
learn different things.

At a startup you're more likely to do everything and wear all the hats, see
things from the beginning and build stuff from scratch. That also means you
don't get to see as much of how tech debt can be efficiently paid off, how to
maintain large systems, or can't have the hindsight 20/20 of all the solutions
to problems startups face.

My early careers was mostly startups, and I felt I had learnt a ton. Then
joined bigger highly successful tech companies, and realized there were much
better ways to do everything I had seen (solutions that would have worked at
the startup scale in many cases)

------
binarymax
As a frequent mentor of junior developers, having been one myself and managed
dozens in my career, the answer is COMMUNICATION.

Technical skills will come naturally over time. But to improve your technical
career, you will be working with people who are not technical. Learn how to
describe technical changes and aspects in layperson terms. Practice
presentation and documentation skills (perhaps even join a group like
Toastmasters to improve). Learn to triage issues and set expectations through
email and discussion in a rational and calm manner.

~~~
spcelzrd
Also, learn to write clear and correct sentences in your primary language. You
will communicate better and you will be perceived as more intelligent.

------
n0us
Not spending all day on HN.

------
dsschnau
I think the most important factor for my own professional growth has been
working with people who know more 'stuff' than me. Every job I've had I've
learned _tons_ from my coworkers. I wouldn't know frontend if I hadn't
partered with a guy who was a CSS pro, I wouldn't be good with Azure if I
didn't work with a guy who was already really good with Azure.

Obviously it takes a lot of legwork on your own part, but having the guidance
helps a whole lot.

------
robertelder
I would say that getting the right internship will make a huge difference.

In 2009 before I went to university I was still living at home, splitting
firewood in the middle of nowhere in New Brunswick, Canada to make a bit of
extra money. This turned out to be an activity with an effective wage of about
$10/hour.

In 2012 I was interning at NVIDIA in Santa Clara. Interns get lots of special
treatment to indoctrinate you into the company, so I got to meet the CEO and
he invited all the interns over to his house. Of course, he would probably
never remember me, but I can't think of many other ways to move so quickly
into a place where you could actually have some influence.

------
jknoepfler
There is no single thing. There's a grocery list. It starts with:

1\. Finish shit on time.

Has a bunch of things that mean: 2...99...: Understand to the best of your
ability what you finished, how it fits into your business, and what could be
done better.

And ends with the most important rule:

100: Don't be an asshole

edit: 101: proofread what you write

~~~
bmelton
Note that "Finish shit on time" is almost a subset of "being able to estimate
well". Having mentored and hired more than a few junior devs, if I could
stress ONE thing to make them better developers, it would be to focus on
figuring out how to estimate accurately.

Estimating accurately has a variety of criteria, like knowing the system
you're developing against well enough to understand pitfalls and hurdles,
knowing how much time will be spent discussing the task at hand, etc. It's not
just "this is how long it will take me to write <x> function"... but it is
absolutely critical to getting shit done on time, as it literally helps you
define what on time is.

~~~
yellowapple
On a related note, the concept of "underpromise and overdeliver" is useful to
internalize here. Delivering a product early / below budget after a high
estimate is usually a lot better than delivering a product late / above budget
after a low estimate.

------
hack_edu
In my experience, a familiarity with the command line along with the
associated general systems/server exposure will elevate your career faster
than anything. For those with such exposure already I'd recommend diving
deeper and become an expert in the tools your existing team uses for systems,
release, and deployment. These skills also open up new career paths you may
opt for in the future.

While most of us are probably comfortable enough running make/grunt/gulp/etc,
that comfort typically stops there. Knowing how to set up and manage your own
systems will both make you more useful on your team and visible in the org.
This is especially true for junior front-end folks.

------
shados
It's just time really.

The amount of time will vary depending on your background, degree, existing
experience, and sure enough, luck. But it's just time.

In the current state of the industry, a senior is just "someone who's been
around and did/saw some stuff".

It gets a lot trickier after that step. But for a junior, just keep doing what
you do and try to do it better while learning/seeing as many things possible.
Basically, just give it time.

------
thwd
To master a lot of the most "hard core" programming concepts, dive into
parsers and compilers. It will give you a perspective and generality that will
permeate the rest of your career. It gives you arguably the most high-level
perspective on all things related to programming and the paradigms therein.

------
erichurkman
1) Be helpful. Colleague beating her forehead against her desk debugging
something? Go help. Account manager running into a bug? Go help. Sales team
encountering pushback from a potential customer? Go help. You'll learn a ton.

2) Learn why you're building something. Not just the technical 'why', but also
the business 'why'. Yes, you should understand why you're using RabbitMQ over
Redis. You should also try to understand the business case that you're solving
– in as much depth as you can get. The stronger you align with what your
business needs, the more valuable you become, and the harder problems you will
be solving, an the more you'll have the opportunity to learn.

------
chrisa
Find someone more senior; ask questions; listen.

------
js8
Why there should be just _one_ thing?

Anyway, assuming programming:
[https://github.com/braydie/HowToBeAProgrammer](https://github.com/braydie/HowToBeAProgrammer)

------
scoj
Ship a product. By doing that, you'll have to figure out SO much stuff from
front to back. Doesn't even have to be your product, it could be moonlighting
project. Just ship something from start to finish.

~~~
dhd415
Being able to ship something is definitely important as there are a lot of
junior (and even more experienced devs) that just can't seem to finish a
project.

Also, stick around for a while after it's been shipped or deployed and see
what kind of difficulties the ops guys have with it if it's a SaaS product or
the customer support team has if it's a locally-installed product. There is a
huge difference between shipping a working product that is simple to operate
and support vs. one that requires constant care from an expensive ops or
support team.

------
kenning
Probably the upside down t-shaped graph of expertise, where you know a lot
about one topic and a little about everything else. I believe this happens
sort of naturally if you just work where you're needed because you'll get
pigeonholed as the person who can do X whenever it needs to be done, then you
can branch out when X is finished. I'm not sure because I'm still pretty
junior myself.

You get a similar effect from repeatedly reading hn, because you'll read
articles on topics you know about and then branch out when you're bored of it.

~~~
majewsky
I don't think it happens automatically. It requires some natural curiosity.
Some people just work on the assignments as they are given to them (which is
not a bad thing per-se, just different from the regularly-hyped rockstar or
ninja programmer).

------
jaypaulynice
Work in a startup and try to do a little bit of everything (code, devops,
marketing, selling). Be really good at 2 of those at least and just hit the
ground running.

You might not know how to do something, but ask to do it anyways and learn it
on the go. Big corporations will not give you that kind of opportunity so you
have to find a startup or create one yourself.

Code and blog a lot and put everything on GitHub and try to get people to star
your projects and follow you. Learn to design, architect and structure your
code for large systems.

------
ejcx
Written communication. Writing concise, direct, accurate, and easy to read
emails/jiras/etc.

If you're a dev or not this holds true. Your boss and your bosses boss are
busy. Help them understand what you do by writing your thoughts clearly.

The other is finishing. Work on things you can finish. Don't aim to rebuild
Rome in an afternoon. Doing the dirty work to take something from 90% to 100%
is HARD. Finishing things adds so much value and for some reason people are
bad at it.

------
Confusion
Think and talk about the functional problem instead of thinking and talking
about a specific technical solution.

And the next level above that: think and talk about the business problem the
proposed functionality is intended to address.

Making the distinction between requirements, functional design and technical
design is very helpful, but in many places this has been obscured and rendered
difficult by bureaucracy and process.

------
crisopolis
Not calling themselves Junior.

~~~
jasonkostempski
When I read that, I laughed, then realized that is literally all it takes and
is exactly how I made the transition.

------
itamarst
The ability to work independently. E.g.:

* Being able to design a small project from scratch and execute it to completion.

* Knowing when to ask for help and related time management skills: ([https://codewithoutrules.com/2016/03/02/asking-for-help/](https://codewithoutrules.com/2016/03/02/asking-for-help/)).

------
bichiliad
I think questions like this aren't really going to get you the answers you're
looking for. There's no one-step fix to becoming a better employee, just like
there's no one-step fix for anything. You've likely already heard the advice
that will help you improve: be perseverant, work smart _and_ hard, stay
organized, and be empathetic.

~~~
noxToken
Fact is that you will get 30 different answers from 100 different people, and
even with same answers from different people, you'll get different reasons for
why they chose that answer.

No, you won't get some silver bullet that's going to propel you to the top in
5 years. I don't (possibly mistakenly) think that's the point. You're going to
get a list of criteria specified on a person-by-person basis that speaks to
their personal experience as a junior dev turned senior, a junior rising
through the ranks, a senior mentoring lots of juniors, etc. Most of the
information given will probably be valid. It is then up to OP to parse through
the information, and they'll have to figure out what's most applicable to
their situation.

------
xs
Get a mentor. This takes a bit of luck to find a mentor (or great boss) but
the rewards are massive. They'll teach you what's relevant to study/learn,
they'll teach you what to focus on to get the most return, they'll be a back
stop to technical questions, they'll be endless knowledge, they'll be a role
model.

------
nunez
Telling your manager that you want to be at the next level and what you want
to bring to the table.

why?

If that manager is good, they will bend over backwards to give you a plan,
hook you up with the right people and ensure that you get that promo quickly.

Why?

Because it makes them look good. Amazing, even.

Understanding the mechanics of the business you work under and talking to
people on the profit-side won't hurt, though.

------
neom
Learn how the business works.

~~~
xemdetia
I think this should be higher in this stack of random things because that's
just one of those things that makes someone seem naive. Ok, you are junior
person in a company- can you explain how your paycheck is funded? Can you see
why what you are working right now directly benefits your business? Why is
this area of the system more critical than that area of the system? What is
the customer perspective on whether this works or not and will it affect the
money?

Much like the other mention of communication this is just one of those things
you learn on the job and outside of school/solo work. This knowledge also
helps guide your decision making/architecture work with dealing with a system
over time as well as general decision making/prioritization.

------
yotamoron
Figuring out 'what makes you itch':
[https://www.youtube.com/watch?v=khOaAHK7efc](https://www.youtube.com/watch?v=khOaAHK7efc)

------
jimmoores
Having the buck stop with you. With nowhere else to turn, you have to step up
pretty fast. It forces you to own your decisions and not run to more senior
people to help with your problems.

------
DodgyEggplant
Interaction. It's what one does, and what the environment does and how the
interaction goes. What ever you do in the wrong environment, will not help,
and vice versa.

------
meesterdude
The "next level" is for you to define. For me, it was communication and
design. For you it might be a new language or simply better test coverage.

------
Jdam
Switch jobs.

------
jp57
Stop looking for 'one thing', or One True Way.

------
austincheney
The things I have seen work:

* Solve the problems other developers are unwilling or incapable of solving.

* Create helpful (and portable) tools

* Learn analytics and increase your communication skills

* Be helpful

------
AdieuToLogic
Software is the manifestation of a solution to a problem. Define the problem
which needs to be solved.

------
adamnemecek
Read a shitton of open source related to your area and try to apply it to your
project.

------
officialjunk
talk to your manager or find a mentor. what's needed to move up can vary based
on where you work. for more general advice, or if you are self employed,
there's a lot of other good comments here.

------
lefstathiou
Humility

------
drio
Understand what the ego is and how is trying to hold you down.

------
xenadu02
100,000 hours of practice. The easiest way is to ship products. When you feel
like you've somewhat mastered whatever you are currently doing look for
opportunities to learn a new framework, language, platform, etc.

~~~
tyingq
10,000 maybe? 100k hours is 11 years @ 24 hours a day / 7 days week.

~~~
Humdeee
Sleep, eating, bathroom breaks, and exercise are for the weak.

------
patothon
lots of work (classic craftmanship learning cycle (build 1000 potteries as
fast a possible, get better each time))

------
jp57
Stop looking for the 'one thing'

------
grey-area
Work with people better than you.

------
karmajunkie
There's no one thing that's going to be the line which, after crossing, you
can safely stop calling yourself junior. Indeed, I've worked with many
"senior" developers who I would have considered junior outside their area(s)
of expertise (and I myself fall into this category as well!)

When I'm conducting interviews and looking for hints that someone might be on
the verge of "levelling up", I look for qualities that indicate someone has
stopped following a preset path and is instead able to do their own
pathfinding. That is, given a direction and a general set of guidelines, how
deep are they able to go in order to solve this problem? If I tell you, "Hey,
we want to add file uploads to this UI" in a Ruby project, do you:

A) immediately go searching for a gem to handle this?

B) Look for an AWS interface gem?

C) Look at S3's HTTP docs and write their own class for handling?

D) Stop and ask if we want to host the files ourselves or using a storage API
of some sort?

Each of those may be the right answer. A is what I would expect a junior (and
likely most others) to do, and its a defensible choice in that file uploads
are likely not interesting enough to spend much time on. B) is what I would
expect from someone who knows that storage to S3 is pretty easy in most
libraries, and therefore it may not be worth the dependency of something like
Carrierwave, electing instead to write a thin wrapper around the interface
(and whether they use it directly in application code, or write the wrapper,
is an excellent way to discern whether they're just below or just above the
line between junior and mid-level). If they're coming from a different
platform background though, they might just be unaware of something like
Carrierwave/Dragonfly/etc. Option C indicates that they're probably pretty
comfortable getting deep into a problem, though perhaps not always making the
best choices about where to spend time (but you get a pass if this is an
interview setting, its really hard to know as a candidate what the other side
of the table is looking for.) Going with option D often indicates the
confidence to push back on requirements and make sure you're writing the right
code, not just what the ticket or client asks for.

The thing is, none of those in isolation is going to definitely indicate that
someone is a junior or more advanced. They're all just pieces of evidence and
have to be taken with other points of evidence to determine the answer to that
question.

Other things I'd probably try to focus on if I were trying to level up:

* Know your tools. I don't care whether you use vi/vim, emacs, spacemacs, Sublime, atom, intellij or one of its brethren, or even textmate—know how to use it effectively to navigate your project and handle your top ten tasks like finding the implementation of a class or running your tests.

* Know your CLI. I don't care that you know every flag to every possible command in the terminal. but realize that an IDE is usually just a layer over a lot of CLI tools that you should be able to handle in their native environment.

* know how to read a stack trace effectively to find the root cause of an error quickly.

* get good with taking constructive criticism. Humility is an important attribute in any team member.

* Don't fall into the trap of thinking you know one tenth of what you believe you do. Don't think in absolutes, and don't argue with every potentially incorrect statement someone makes.

* ask questions more than make statements. Whether its "Can you help me understand why you do that this way?" or "Why is the customer asking for this feature?" it will serve you well throughout your career.

------
sairamkunala
Hard Work and Discipline

------
hboon
Find a mentor.

------
lgas
Experience.

------
zuzuleinen
Proactivity

------
mdip
There are many things you can do, and not really "one" silver bullet, but I
feel the most important are "soft-skills" and a hyper-focus on learning. You
asked for one, but the two of them are so deeply connected, I feel they
warrant being included together.

Communication/soft-skills has already been mentioned so I'll leave it with the
simple "At the end of the day, regardless of how smart you are, if you cannot
work well with others and you're not the sole employee/owner, your value is
very limited".

The biggest problem I've found being a software developer is exposed by this
phenomenon referred to as Imposter Syndrom[0]. In a lot of fields, there are
good ways to measure yourself and your skills against others. In software
development, it's a difficult thing to measure. You can become an "expert" in
the core language you write in -- understanding the common patterns, standard
libraries, and common features -- and no matter how much your abilities
increase, what you know is far less than what you don't know.

Even today, with resources like StackOverflow, open-source material and source
repositories with endless amounts of code available, learning corners of your
specialty is hard. Your resource may be "out-of-date" (which happens within
weeks, rather than months/years) or might be so specialized that there's just
nothing out there[1]. Because of Imposter Syndrom, your developers are not
quick to point out their weaknesses, but knowing the strengths/weaknesses of
your coworkers helps you to be effective and to know who to tap when you get
stuck. Unlike "that person in the forum", they have a vested interest in
making you better -- you'll reduce their workload the more effective you
become. Provided you're good at establishing relationships/friendships with
others, they'll actively _help_ you to become better and there's no better way
to learn than one-on-one with someone who has the skills you lack. Knowing
their weaknesses allows you to better focus your study on areas that the team
has gaps (tip: offer up your own deficiencies and others will open up about
theirs).

A lot also depends on what corner of software development you're focused on.
If you're focused on web front-end development, you have a much easier time
learning what you need to learn, and more jobs available to shine in, but you
also have a huge amount of competition and a greater distance between Junior
and Senior. In a highly specialized area -- mine was Skype for Business
development -- you have fewer job options, almost no resources but a much
smaller distance between Junior and Senior since simply having experience in
_one_ of the APIs already puts you near the middle. At first, I was tempted to
say that being in the latter category is helpful, but having done it and
reflecting on how painful it is when you run into a problem and have,
literally, nobody to turn to for help[2], I can't say that I recommend it.
Picking an area of focus that is somewhere in the middle might be a good idea.
:o)

On learning, figure out what techniques are most effective for you. I don't do
well in lectures, and I don't have the patience for video tutorials. I took a
class about 20 years ago on effective book study (it was called "speed
reading" at the time, but has nothing to do with these gimmicky techniques
taught by apps, today). I learned how to skim/scan material and take effective
notes while doing so, allowing me to consume huge books in hours, and "read"
those books for information several times over a period of a week/month. I
felt like I had a "super power" and exercised this ability to the tune of
about 6-10 large volumes per year. When I need to learn something, I look for
a good, thick, book on the subject, set a goal for completion and relentlessly
pour myself into it. For programming, I know this requires me finding a
personal, useful, project to build, an "instructional book" and a "reference
book". Give me those three things and the language, framework or pattern in
question will be cemented in a way that allows me to use it at a practical
level.

[0]
[https://www.hanselman.com/blog/ImAPhonyAreYou.aspx](https://www.hanselman.com/blog/ImAPhonyAreYou.aspx)

[1] My area of focus until very recently was developing software for Skype for
Business using some of the (very excellent) APIs provided by Microsoft.
Unfortunately, the number of people who are doing professional development in
this software is small due to its target audience being enterprises. You just
don't have a large number of hobbyists writing libraries on the weekends. The
primary API I used to develop in, UCMA, had one half-chapter in one large book
written in 2007, none of which is helpful to new developers due to it being
_wildly_ out of date. The documentation for this API is mostly
"Undocumentation", and I've encountered very few APIs that have as many sharp
edges, parts that don't work as you'd intuitively expect or simply don't work
in any way resembling the documentation.

[2] I can't tell you how many times I've googled a problem and ran into
solutions where the answer was provided by a person I worked with that I could
have tapped on the shoulder. Or the two times I googled something, saw the
answer (in one case, slightly _disagreeing_ with the approach) only to
discover that the person who wrote it ... was me. Just goes to show that
anything in software that you've written six months ago might as well have
been written by someone else.

------
redwoolf
Time.

------
0xdeadbeefbabe
Less thinking about yourself.

