Hacker News new | comments | show | ask | jobs | submit login
Leveling up as a Junior Engineer (medium.com)
90 points by GowGuy47 on June 19, 2017 | hide | past | web | favorite | 30 comments

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.

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.

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

I have the complete opposite experience.

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.

>>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?

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.

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.

But the guy was just giving his opinion...

fwiw I know 6 'water walkers' and none of them have github accounts.

Not saying this is universally true. Just another anecdotal sample.

My guess is it's subfield/language dependent.

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.


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

> 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 !!!!!

This is so incredibly on point. I wish I had something else to contribute, but this is already so well stated. I just want to highlight for others how important this advice is.

Put in your 8+ hours, then stop, and work on yourself.

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.

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.

Also, if the problem is above your skill level: take something routine off the plate of a senior engineer to free them up to tackle the big problem.

The work was going to get reassigned anyway, because it's more important that the senior guy fix a release blocking issue than do that work, but it makes you a proactive part of the solution, even when you can't directly contribute: you're still helping make sure all the ducks are in a row for release.

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.

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.

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.

I use Laravel and PHP for my job at a trendy start up. We use it to spit out JSON. I have no complaints, it's an absolutely fantastic framework - good support for the set of actions common to most web apps via the community and libraries.

Laravel is a lot of fun and has a lot of helpful opinions. Sometimes you outgrow it, but generally it covers like 90% of use cases.

If you use Laravel and not raw PHP, you'll be fine.

PHP is career killer. Its makes you worse developer, confine you as web developer and have poorly paid jobs.

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.

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

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.

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

If you don't already have experience / are trying to break into the industry, side projects that have actually shipped are one indicator of potential impact.

"Potential" because some people farm out side projects on upwork etc. That kind of project management is also a valuable skill but it's not the same thing.

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact