Carrier of a Software Engineer

Everyone begins as an entry-level engineer. To advance, you’ll need to be competent in several core areas:

Technical knowledge: You know your computer science fundamentals. You know how to use integrated development environments (IDEs), build systems, debuggers, and test frameworks. You are familiar with continuous integration, metrics and monitoring, configuration, and packaging systems. You proactively create and improve test code. You consider operations when making architectural decisions.
Execution: You create value by solving problems with code, and you understand the connection between your work and the business. You’ve built and deployed small and medium-sized features. You write, test, and review code. You share on-call duties and debug operational issues. You are proactive and dependable. You participate in technical talks, reading groups, interviews, and presentations.
Communication: You communicate clearly both in written and verbal form. You are able to give and receive feedback effectively. You proactively ask for help and get clarification in ambiguous situations. You raise issues and identify problems in a constructive manner. You provide help when possible and are starting to influence peers. You document your work. You write clear design documents and invite feedback. You are patient and empathetic when dealing with others.
Leadership: You work independently on well-scoped work. You learn from mistakes quickly. You handle change and ambiguity well. You actively participate in project and quarterly planning. You help new team members onboard. You give meaningful feedback to your manager.

There are four stages of competence (according to the book: Teaching for Learning):

Unconscious incompetence: means you are unable to perform a task correctly and are unaware of the gap
Conscious incompetence: means you are unable to perform a task correctly but are aware of the gap.
Conscious competence: means you can perform a task with effort.
Unconscious competence: means you can perform a task effortlessly

At the start of their career all engineers start out consciously or unconsciously incompetent. Your goal is to get to conscious competence ASAP. You must know how to learn, be mindful about growth obstacles and know how to ask questions in order to reach your goal as a conscious competent engineer.

Learning to Learn

Learning will help you become a competent engineer and flourish in the years to come. The field of software engineering is constantly evolving; whether you are a new grad or a seasoned veteran, if you’re not learning, you’re falling behind. Here is a digest of various approaches to learning at a new job:

Front-Load Your Learning: Front-loaded learning at the beginning of a new job will be uncomfortable—you’ll want to ship software and taking time to read documentation and fiddle with tools will slow you down. Don’t worry; everyone expects you to spend time ramping up.

Learn by Doing: Front-loaded learning does not mean sitting around reading documentation all day. We learn a little by reading and a lot by doing. You should write and ship code.

Experiment with Code: Run experiments to learn how code truly works. Documentation goes out-of-date. Coworkers forget things. Experiments are safe since you can run them outside of production, and nonproduction experiments allow for more invasive techniques.

Read: Spend a portion of each week reading. There are many different sources: team documentation, design documents, code, ticket backlogs, books, papers, and technical sites. “Code never lies. Comments sometimes do” Some companies have internal reading groups—ask around.

Watch Technical Presentations: PyCon, etc.

Attend Meetups and Conferences (Sparingly).

Shadow and Pair with Experienced Engineers.

Experiment with Side Projects: Companies have rules about outside work. Ask for your company’s policy. Don’t use company resources (your company laptop) to work on side projects. Don’t work on side projects at work. Avoid side projects that compete with your company. Clarify whether you can contribute to open source at work or at home.

Asking Questions

All engineers should ask questions—it’s a critical part of learning. Some new engineers worry about bothering teammates and try to figure everything out themselves instead. This is slow and inefficient. Others always ask questions without even giving a slightest try to solve the problem and irritate everyone. Asking questions effectively will help you learn quickly without irritating others.

Use these tips to be able to ask good questions:

Do Your Research: Don’t just search the internet. Information lives in documentation, wikis, READMEs, source code, and bug trackers.

Timebox: Set the limit before you start your research to encourage discipline and prevent diminishing returns (research will eventually stop being productive).

Show Your Work: Describe what you know when asking a question. Don’t just share your raw notes. Outline what you’ve tried and discovered succinctly.

Don’t Interrupt: Just like you, others are trying to get things done; they need to focus. When they’re in the zone, don’t interrupt them. Even if the question is easy. Even if you know they know the answer. Even if you’re blocked. Unless there is a critical issue, really, don’t interrupt them. (The trouble is, getting into “the zone” is not easy. When you try to measure it, it looks like it takes an average of 15 minutes to start working at maximum productivity.)

Prefer Multicast, Asynchronous Communication: In networking, multicasting means sending a message to a group instead of an individual destination. Asynchronous means a message that can be processed later, rather than requiring an immediate response.

Batch Your Synchronous Requests: In-person conversations are “high bandwidth” and “low latency.” You can cover a lot quickly. This is costly, though. Interrupting your coworkers affects their productivity. Avoid this by setting up dedicated time with your tech lead or manager for nonurgent questions. Schedule a meeting, or use “office hours” if they exist.

Overcoming Growth Obstacles

Knowing how to learn and asking questions isn’t enough. You must also avoid traps that slow growth. Two common impediments, impostor syndrome and the Dunning–Kruger effect, affect many engineers. You will grow faster if you understand what these phenomena are and how to overcome them.

Impostor Syndrome is often connected more to the feeling of conscious incompetence.
Dunning–Kruger effect is on the other hand often connected more to unconscious incompetence. Unconsciously incompetent engineers don’t know what they don’t know, so they can’t accurately evaluate their performance (or anyone else’s).

Note

Main sources:

https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/