It has been beaten over the head till no end about folks asking “how do I get into the tech scene?” or “how do I land a six-figure job in tech?” and so on. However, arguably the more important question many need to ask is “how do I make a positive impact as a junior engineer?”. This is a question where the answer is two-fold and may even prove to be valuable for the former question(s).

At the core, I believe we can all agree that when it comes to the tech industry (perhaps, really, most industries) hiring criteria for skillsets are often best looked at as two main categories: soft skills and technical (hard) skills.

As a junior engineer, these soft skills are far more likely to deliver tangible value. On the downside, they are also the more arduous, by a mile, skills that one can learn and make part of their toolkit as an employee. Often, people can spend years to polish and countless interactions with users, coworkers, or c-suites that perhaps don’t go well and becomes a hard lesson to learn.

Alas, here are a few tips to the trade that a former junior has learned along the way and hopefully can help you to onboard into your new role and strategize your learning path to become the senior engineer that you strive to be.

The first major hurdle and one that can shape the rest of your junior days is aligning your perspective with reality. Often I saw other juniors thinking that they needed to keep up with the seasoned veterans on the first day, first week, or first month. The reality is, though, that everyone knows that you are a junior…. because, well, you are. Remember that.

A good organization and team will understand and there will not be an expectation that you know everything for a bit. Depending on the task at hand, perhaps not even the first full quarter — or longer. Heck, if you were to ask some people who had been at the organization for a while, you’ll find that most need a refresher on some things here and there — and that is okay!

Instead, a good junior needs to exhibit a few qualities to supplement this gap in knowledge. They need be curious, aware of their limitations, the bravery to try and fail, and probably the most important — ask for help. The latter is key. More often you will find that organizations, within reason, would prefer to answer questions and help you out when you are stuck than you spending hours upon hours spinning your wheels when you are really stuck on a problem (just don’t forget to truly try to solve it yourself).

In general, for something trivial, this could be 30 minutes to an hour at most. Fail quickly and learn. If in doubt on an appropriate time, ask a coworker, manager, or a mentor (if assigned) for the team’s general rule of thumb.

Technical knowledge will come with time and practice. Cultivate patience and learn.

Often times I’ll see juniors jump head first into a task eager to show off their problem-solving skills only to get stuck on not understanding the software they are working on or the environment they are working in. This results in them being deep into the task not knowing how they got to where they are and thus not knowing where to even start in the documentation to solve it themselves and instead they must resort to heavily relying on a senior engineer.

Partly, this is due to a story for another time on proper documentation (stay tuned), but let’s face it, there are likely more organizations with subpar documentation than we’d like to admit.

Rather, a good junior engineer will pump the brakes and find where and read through the documentation first. This isn’t to say that it must be memorized and you will be able to fully understand the systems or environments you are working in, but at the least you’ll understand the basics of what you’re working and how it is structured so when (not if) you need it you will be able to get a head start on finding a solution to your problem or question more often. This will help show your coworkers and bosses that you are able to work through problems on your own.

For added bonus marks, if you find any gaps in the documentation, write it down and work to have it incorporated. This will show initiative as well as assist you in learning how to write documentation in the organization’s style.

My other senior coworkers love to joke that all new juniors strolling in are “unbroken”. The years or decades of office politics, long hours, tedious tasks, and whatever other silliness that comes about just hasn’t gotten to them yet.

While this is not necessarily, false, the unmentioned positive is that this provides some great opportunities for you that you may need to take the initiative on to identify. As a fresh engineer you have all specialization paths ahead of you and taking on an annoying ticket for a senior engineer will award you with not only brownie points and the change chance to deliver actual value to the organization, but the opportunity to find your calling (or not).

Remember, though, that it is important to not abandon a task unless instructed to. If you decide to take on a ticket — ensure it gets done one way or another.

Where to begin other than… COMMUNICATE.

There is a common misconception in the world of business that tech is where people who have no people skills and are recluses go. Don’t get me wrong, there are people like that, but it is far from the norm. Communication is unbelievable important and knowing how, when, and what can make or break your career.

Let’s dive a little deeper.

https://nohello.net/en/ … enough said.

Jokes aside… we’re all busy and time is a valuable commodity. Chat has evolved and the more we can all chip in and save each other time the better. Thus, when communicating with anyone in your day-to-day happenings skip the pleasantries only first. You can still include the pleasantries with your question or request, though, and should!

The tech industry is a team effort through-and-through and the opinions of your colleagues is important. Every little detail compounds and affects your brand within the office.

Be kind, pleasant, and considerate in your conversations and discussions. As a fresh set of eyes on the work being conducted you may come across weird procedures or odd decisions with a feature of an application you’re working on. While this different perspective can be welcome, phrase it in a constructive way and illustrate why it would be beneficial to consider without berating the current state. We’re a prideful bunch and can be sensitive about our work.

This has been slightly touched upon already in terms of when to ask for help. However, we can take that lesson and apply it to even more typical conversations. After all, software development and its lifecycle is heavily entrenched into project management which is mostly expectation setting with stakeholders.

Early communication is vital. If you identify a major hurdle in the plans that is certainly going to cause a delay — speak up! The earlier this is brought to everyones attention, the easier it is come up with a successful plan to address it.

However, do not cause a “boy cried wolf” situation either. People are smart cookies and sometimes even the most odd piece of a project may be like that for a reason. Couple with with curiosity to understand something first without jumping to conclusions and dumping a big ol’ bucket of judgement onto the table.

As a junior engineer, what you communicate can be difficult. Oftentimes you will find yourself eager to make a change for the better and show off what you can accomplish — which is great. Although, you must understand that, that eagerness must be reigned in and instead turned into fresh perspective and curiosity. Do not speak in absolutes (unless you are 110% certain), but rather suggestions along with facts on how said suggestion is relevant and viable.

Building off of this, communicate value-adding discussion points/questions. Learn what is a gap in your understanding of the subject matter or a gap in the overall team’s understanding. This will assist you in deciding whether to ask your question in front of everyone in a meeting or after the fact one-on-one with your manager or a colleague.

As a junior engineer, you will not be responsible for the lifecycle of the application. However, you should understand the basics at the very least of Application Lifecycle Management (ALM).

At the core, ALM focuses on four stages:

These stages breakdown the process of creating an application from conceptualization of business needs and goals and data and security to software development and testing and finally landing in the ongoing maintenance requirements for bugs and new feature implementation.

There is far more to learn about this topic than I can cover within this article. I would suggest to take a moment to read https://www.redhat.com/en/topics/devops/what-is-application-lifecycle-management-alm article from Red Hat to supplement what I summarized above.

Nonetheless, the most important takeaway here is to understand all that goes into making the magic work and how the dominoes fit together. This will prove valuable when making decisions and prioritizing your work.

An engineer that understands not only the code, but the business needs and can communicate with them is invaluable to an organization.