
Leveling up as a Junior Engineer - GowGuy47
https://medium.com/masterpoint/leveling-up-as-a-junior-engineer-3f6880f8af1d
======
TurboHaskal
How to level down as a Junior Engineer:

    
    
      1. Start with the kool-aid: Read Hackers and Painters.
      2. Appeal to your fragile ego: Read The Bipolar Lisp Programmer.
      3. Learn actually interesting stuff: Read On Lisp, PAIP, Lisp in Small Pieces,
         The * Schemer series.
      4. Implement your own Scheme. With the help of your dog.
      5. Further down the rabbit hole: Read SICP.
      6. Unlearn Java, JS and PHP. Reject job offers containing such keywords.
      7. Engage in CL vs Scheme internet flame wars.
      8. Spend the most of your fertile years trying to find the perfect Emacs
         configuration (spoiler: it doesn’t exist).
      9. When the choice arises: Choose to learn Shen instead of Clojure due to the
         latter being too impure for you.
    

Congratulations! You are now unhireable. Not that you would like a job anyway.

------
djb_hackernews
My advice:

\- Never call yourself a Junior Engineer. If you have experience, even just a
little, you are an experienced engineer.

\- Develop your communication skills. The barrier to entry to start presenting
at meetups is extremely low, do that with the goal of presenting at tech
conferences.

\- Skip the side projects. Of the 10 or so water walkers I've worked with, 0
have github accounts.

\- Don't buy into the last paragraph of this blog. Software development isn't
hard, and the last thing you want to do is think you need to constantly keep
up with the latest and greatest tech. If you step back it looks a lot like an
industry that doesn't know whether it's coming or going, don't fall for the
trap.

~~~
zer0tonin
> Of the 10 or so water walkers I've worked with, 0 have github accounts.

I have the complete opposite experience.

~~~
jandrewrogers
Many of the very best engineers are effectively prohibited from having Github
projects. The deeper down the stack you are, or the more hardcore the computer
science you work on, the more likely this is to be true because your primary
work area is deemed a trade secret.

This isn't a major issue if you are an app developer because a side project
app is unlikely to convey valuable trade secrets. A database kernel engineer,
on the other hand, can't have any side projects related to databases that
demonstrate their skill level because such a demonstration would violate their
non-disclosure restrictions.

~~~
enraged_camel
>>Many of the very best engineers are effectively prohibited from having
Github projects.

Many, sure. But the OP's comment was "Of the 10 or so water walkers I've
worked with, 0 have github accounts."

Surely people understand how asinine it is to believe that a sample size of 10
of OP's "water walkers" is a representative sample?

~~~
chasote
This comes off a little aggressive to me. People should be able to provide
opinions and anecdotes on HN without the constant "citation needed" for
everything. We all know everything isn't fully backed by 4 studies that will
be presented here and now. Just say you disagree and offer why. It will
probably be an anecdote too.

~~~
enraged_camel
On the other hand, if everyone used "anecdata" to support their arguments, we
would never get anywhere.

If you want to make qualitative arguments, make qualitative arguments. What I
absolutely can't stand is lame attempts to lend weight in such arguments using
completely unverifiable and most likely non-representative numbers.

~~~
softawre
But the guy was just giving his opinion...

------
scottLobster
My continuing critique of posts like these is that they miss far more
fundamental keys to "leveling up": energy level and psychological issues.

I bring this up because in my experience the people who outright fail to
"level up" and are actively seeking out posts like this often lack the
fundamental ability to follow through on any advice they're given, regardless
of whether they agree with it or how good it is.

Perhaps the best example is side projects. The first thing you need isn't a
good idea, "soft skills", or even being particularly skilled at coding. The
first thing you need is enough time and energy to keeping going after an 8+
hour workday, combined with enough confidence to push forward.

For most people that means getting in shape, eating healthy, getting a full
night's sleep every night, developing a growth mindset of some variety,
dealing with anxiety, making day-to-day tasks more efficient, etc. Otherwise
all the good advice in the world is only going to lead to fragmented, half-
baked sputtering efforts that ignore the root of the problem.

As for the people who have all that stuff taken care of, then I guess this
information is of some value if it's the first time they're seeing it.
Otherwise it's largely a rehash of other innumerable professional development
blog posts. Which doesn't mean it's bad, but the people who really need the
help probably can't use it, and the people who can use it likely don't need
it.

~~~
neivin
Agreed.

Finding the motivation/discipline to keep up the conscious effort of improving
at anything is the hardest task of all.

~~~
LrnByTeach
> Finding the motivation/discipline to keep up the conscious effort of
> improving at anything is the hardest task of all.

Well stated, can't agree more !!!!!

------
srdeveng
IME, as someone who leveled up from jr to eventually sr in the same org over a
10yr period, the best advice I can give is be confident in your skills and be
willing to take calculated risks.

Teams are always chasing deadlines and resolving unforeseen issues as they
arise. The go-getter willing to volunteer to fix a problem that isn't already
on their plate gets noticed.

You won't be assigned 'save the day' type work outright as a jr, but the team
will find itself in a tight spot, and you need to volunteer to go above and
beyond to help fix XYZ even though it's outside your domain.

If you succeed, you have everything to gain. Fail? You're the jr, at least you
gave it the old college try while chipping away at your key tasks.

~~~
mrisoli
Leveling up in the same org is all about the company's cost.

Some companies(especially bigger ones with names that attract new grads) will
deny you a promotion if they believe you are cheap to replace(denying a
promotion often leads to employee unsatisfaction which causes them to leave).

Most companies, especially if they are having problems finding new engineers,
will just give you a promotion to keep you happy and because they can't afford
the time and costs of losing and employee, find and train the next one.

However, I think the article is more about personal improvement than proper
leveling up within an organization, in which case it's not about being
noticed.

------
boona
If you're interested in php and/or laravel I highly recommend laracast. He'll
go through the exercise of creating a certain feature, and then refactoring
that feature with an explanation as to why. And often, that refactor is the
difference between entry level code that just works, to intermediate code
that's scalable and easy to read. I highly recommend it.

~~~
Double_a_92
Would you recommend Laravel and PHP? I know PHP is seen as outdated by some
people... But now that that NodeJS/MongoDB hype is finally receding, PHP
actually seems like a sane alternative.

~~~
jajern
Any mention of PHP's merits at this point is going to start a flame war. It's
pretty easy to be a terrible developer with it. JS/Node can allow you to be
just as bad of a developer. The key to being good and getting a good start is
to learn the fundamentals of whatever language you choose. Don't pick a
framework and definitely don't rely on one without knowing a language.
Frameworks come and go. I personally like Python but mostly use PHP in my day
job due to it being the company standard for web apps. It works just fine for
the company's needs. Most people can learn the basics of a language in a day
so it may be worth running through a few tutorials in a few different
languages to see if there is something that suits you. In my opinion it's good
to have a toolbox of languages because sometimes a certain language is just
better than others at different things.

------
y-c-o-m-b
This posting really irks me. It's reminiscent of those "agile coach" marketers
that tell you "this is the REAL way to do agile". The only thing I agree with
is the mentoring. If you have a desire to learn and you can find a strong and
supportive mentor, then you will go far. All the other stuff in the article
feels like high school popularity contest tips. You don't need to do all those
things to "level up". Side projects are nice, but you'll find most people -
especially in corporate/business software - don't have side projects. Nor
should they have to. People have families and duties outside of software, so I
hate how there's a cultural push to be a huge github contributor; it pressures
ordinary folks to take time away from their other passions. Just be a good
person and willing to learn, that should take you far enough.

------
AngeloAnolin
"At least one per year that you actually ship (the hard part) at a minimum."

I would say that this would probably be on top of my list, because shipping a
working and usable software is a testament to all the learning, communication,
mentoring and pairing that you would get as you level up.

------
haburka
In my opinion, side projects don't have to ship. Some people do need to ship
side projects, some people do not. It's important to challenge yourself with
code, absolutely, but enforcing deadlines on yourself is usually just met with
disappointment when you don't do it. Additionally, by allowing yourself to
stop working on side projects when you want, you can focus on doing the parts
of coding that you enjoy which means you can find your preferences and
passion.

However, I do believe that everyone should be able to set up a server and a
web page to show off the functionality of any side project they make (or an
app). The best part about any side project is taking your phone out with your
friends and showing it off.

~~~
vhakulinen
> In my opinion, side projects don't have to ship.

Totally agree. I have had tons of side projects and most of those have just
been for fuzzing around with new and shiny (or old and solid) things. From
side projects, I have "shipped" couple of apps but have gained the most
experience from the ones that I haven't.

Also, the blog post mentions only books and blogs for reading. I've found that
reading issue tracker/PR and other forums closer to actual code has sometimes
been extremely helpful (in those cases, I tend to end up reading the code it
self from time to time).

------
mrisoli
My opinion for the article:

Finding a mentor is good, finding multiple mentors is better, just like the
article says you don't need someone to be with you at all times, you need to
learn from someone, if you have the chance to learn from multiple experienced
people around you please do.

Do not involve in the community just because you want to level up, do it
because the community helps you and you want to contribute.

Reading should be advice for any human being, not just for leveling up tech
skills, you could say the same for soft skills.

Side projects are not obligatory, but if you have the drive to do them you
should, it can be a fun and learning experience.

