A Skills Path for Engineers: Part 1 — Junior Engineer
What skills do Engineers need to progress in their careers?
No matter where you are in your career, this question is often asked by Engineers. In my role, where I now guide career development goals and plans, this question still gets asked in conversations I’ve had with Engineers.
I’ll be looking into the skills path covering 3 levels — Junior, Mid to Senior. From Senior Engineer onwards, people will often face a choice of Technical path or Manager path, which is a topic for another day.
I’ll break down the skills needed for these roles and describe what types of activities and behaviours mapped to each skill. Please note that the skills for each level can look different per company, however this is a general guide to help distinguish what the growth for skills look like.
Part 1 — Junior Engineer
At this level, you are finding your feet, so it’s important to remember something important:
You are going at your own pace and learning is an ongoing journey. Remember to find the right support and pace yourself. Remember to be kind to yourself. You will be absorbing and learning, you can do more as time goes by.
I remember at this level, I compared myself to the Senior Engineers and wanted to get to their level “One Day”. I also remember being intimidated and feeling dumb. Over time I’ve observed Engineers feel the same way, so that is why I think it is important to remember you will learn and get there in time.
Remember to ask questions, ensure you have a buddy and a team that supports you. You need an environment to thrive in and that starts with the right support systems in place.
Let’s now step through the competencies you will be starting with:
Understand Why
Understand the context of your environment.
What are we doing here? Why are we building this feature? How does the product work? How does the team work? Who is everyone in the team? Who else will I be working with?
It’s important to understand the purpose of the team, how this relates to the company and how the features being built relate to the bigger picture. This will drive building great products for your company and end users. This will drive the questions you ask and the decisions you make.
Understand the Codebase
This is one of the first steps for Engineers at any level.
When you join the team, it’s important to know a few things about the codebase — understanding how to navigate the codebase, where to find files, where the tests are located, how to compile, how to run tests, where to put code, how to run the application, how to test end to end or make API calls, following code from one file to another.
When you start picking up tasks, they will be smaller and bite size, aimed to learning one discrete piece of information at a time. Then they gradually form composite changes. For example you may find that you start with a ticket to add a banner that works in different browsers, then you build a component that works with local storage, then you build a component that encapsulates another component, to eventually building a more complicated component or page comprised of multiple components.
You learn to know where to put code, how to structure code, how to breakdown work, how to test it (testing covered later) and refactor code.
Task Breakdown and Delivery
You will need to learn how to breakdown work and deliver your tasks at a reasonable pace.
Task Breakdown
Tasks build up to a bigger feature that has timelines, dependencies and risks, so having an understanding on how this rolls up into the bigger picture is important.
The first step is understanding what to do and where to make changes. You will find that you need practice to breakdown the work. After a few tasks, you will have a better understanding on the scope of work, your capacity on what size tasks to tackle and form your ability to approach breaking down the tasks into reasonable size chunks of work.
After some time you will find you can pick up tasks and can determine the subtasks that will be tackled and communicate when you think the task is larger than expected.
Delivery
As you are in a team, the feature being built is broken into multiple tasks for the team to work on. Each piece is interdependent and requires coordination.
Being accountable and communicating risks starts at the task level, as this will impact the bigger picture. Being aware of how your tasks fits with other tasks is important too, it’s important to have an awareness of the purpose of other tasks, problems encountered or approaches taken to know how the project is tracking overall.
Remember: You are not expected to be delivering as much and as fast as the more senior members of your team. You are going at your own pace, which will gradually shift as you learn more and the complexity and size of tasks will change as you do.
Understand Domain
The architecture
Seek to understand how the systems and data flows for the domain you work in.
For example, if your team looks after the booking system, seek to understand what are the systems, what API calls are made, where does the API call flow to, what data is needed, what is the purpose of the micro-services in your domain.
Build the understanding so you know how this works in your team, so you know where changes need to go and eventually you can draw a diagram and explain this to others.
Learn one thing at a time, gradually learning each part of the stack.
Infrastructure
You may come across concepts like load balancers, containers (e.g. Docker) and related. You are not expected to master this, but having a high level understanding and know how to run simple commands for simple tasks will be needed. Such as how to list the Docker processes running, to listing the Kubernetes pods.
Remember, take one step at a time. Ask questions, and start with what you need to know now, start high level before gradually diving deeper. Learn what you need to know to be effective first.
Debugging
As you code, you will be faced with problems to solve.
WHY does the code not work?
I’m sure many people have been here. A skill you will need to develop is the ability to debug the code that you wrote or someone else wrote to understand what is going on.
For example, you will be tracing through the code, checking StackOverflow, reading documentation, adding breakpoints, adding logging, adding debugging statements, adding tests (again to be covered later) to help you understand what is going on.
You will learn about looking at logs on your local environment, to looking at logs on test environments.
Eventually you will become more adept at figuring out what is happening. It often helps watching others debug and learn techniques and tips other people have developed. As you pick up bigger more complex tasks, this skill will prove to be invaluable.
Testing
Why is testing important? This ensures quality, ensures that the branches of logic have been covered, ensures repeatability and confidence with code that is written.
When you make changes later or continue to add more code, the tests written will serve as a confidence measure that you don’t break functionality that was previously written.
You will first start with writing unit tests for the first tasks you pick up. You will learn about white box testing and testing branches of logic. Then you will learn about different layers of testing, depending on the frameworks you work in. For example if this was a MVC (Model View Controller) app, you would have unit tests and learn about mocking, controller tests, integration tests and end to end tests.
You will learn about the testing pyramid and why you have tests in each layer, and what constitutes the right amount of tests (hint: not always about 100% test coverage).
Other testing concepts that you may be exposed to, but not expected to master until later — Layout testing, Accessibility testing, Property-based testing, TDD, BDD, Performance Testing.
Seek to Understand Best Practise
As you start adding code, the first step is knowing where to put code. As you familiarise yourself with the codebase, you will start to pick up established patterns, such as why certain code is structured in different places, naming conventions, code styles etc.
You will come across code checkers such as static code analysers like Linting, Rubocop, Credo, Checkstyle (a few for some programming languages) and online tools such as CodeClimate or Codacy.
Patterns and guidelines will also appear in code reviews on your work and other people’s work, as well as technical conversations amongst team members.
Communication
This is an important skill to develop. It is important to communicate with others for a variety of reasons
- You need more information — when you start a task, you will need to ask questions for example, catering for different user types, or how something will be displayed
- You need help — providing context on the problem you are trying to solve, and the current issue you are facing is key before diving right in. Take a step back, explain the context before what is the current issue you are facing. This helps set the scene so others can help.
- You are collaborating with others — you seek to understand each other, break up work, problem solve together and ask each other questions. You will find you either need to provide a lot of detail or set the context before providing detail, to even resolving a conflict.
- You are explaining something to a non-technical person — for example, helping someone in another department, explaining something to a Designer, presenting at team demos. You will need to learn how to deliver information to different audiences.
- You are communicating your progress — this is important, because your tasks forms a bigger picture, so if you are stuck or facing challenges, if you communicate and paint the picture of your actual progress, your team will know how they can help and support you. Your team will understand the risks and dependencies to the project they are working on if you can communicate your progress effectively. For example, you could be providing an update in standup and the team could offer to help if you explain how you are stuck.
- You are in a group setting — at first, it may seem daunting to contribute questions and join in the discussion in the team as you are gaining context. Over time, you should be contributing, because it shows engagement, and adding value to discussions. For example you could be in sprint planning and raise a valid point about a missed scenario or need clarification on a story which helped provide a better estimate. Speaking up is important to surface important points that would otherwise be missed.
I remember an Engineer, who initially found they couldn’t contribute in team settings. In a private setting, they mentioned they couldn’t follow conversations, so we worked through what information they needed to help with following a conversation.
They also they needed to adapt the way they asked for help and explained concepts to different people, in order to collaborate effectively. After about a year, they were raising questions in team meetings, presenting at team demos and even presented to the team on a technical topic.
It takes time to build this skill, but it is one of the biggest assets in your career.
There may be competencies which also appear in other career matrices or career ladders which I did not touch on, so if you would like more information, there are a few career ladders I have referred to in the past
I hope this write up has helped with knowing what skills you need when you start a career as an Engineer. I’ll be following up with Part 2 and Part 3 covering the next 2 levels.
