Leveling up as a Junior Engineer(medium.com) |
Leveling up as a Junior Engineer(medium.com) |
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.
- 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.
I have the complete opposite experience.
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.
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.
Well stated, can't agree more !!!!!
Put in your 8+ hours, then stop, and work on yourself.
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.
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.
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.
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.
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).
"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.
If you use Laravel and not raw PHP, you'll be fine.
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.
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.
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?
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.
Not saying this is universally true. Just another anecdotal sample.