Becoming an efficient developer - work smarter, not harder
While being effective at software development requires technical aptitude and experience, being efficient at it involves a skillset that doesn't always relate to the software engineering world. If you constantly feel that you never have enough time to get your work done, or you feel that you lack focus, get stuck frequently, get overwhelmed or even feel burnt out, it may be worth evaluating whether you are taking the necessary steps to becoming efficient at development. These side effects may totally be a result of you being actually overworked or having poor work life balance, but you will be surprised how often these are a result of software engineers not putting enough thought into engineering efficiency.
What engineering efficiency actually means varies by your level and years of experience. For example, a senior engineer may focus on things like good development practices, code review policies, documentation standards and communication channels to ensure that the process is as frictionless as possible for not only them, but their colleagues and junior engineers. On the other end, for new software engineers, engineering efficiency means gathering information to get unblocked, identifying the right communication channels, building a personal knowledge base, so on and so forth.
Start building your knowledge base from day one
When you start off, you will be reading a lot of documentation and other technical material. The problem is that documentation is written by one or more people to appeal to a broad set of people, which may or may not be in alignment with how you work and learn things. Therefore, it is always great to compile your own notes as you read documentation or watch technical presentations. This has three advantages:
First, taking notes helps you retain information faster and for longer, so you will pick things up faster
Second, if you identify that any of the material is out of date, or have errors, you can jot down how you can improve it
And third, if you end up mentoring someone else in the future, you can share your notes so that they have an alternate angle to the same material
Speaking of mentoring, always ask for a mentor or a ramp-up buddy if you don't have one
The initial ramp up to a project or a code base can be one of the most hardest and the most frustrating things as a new software engineer, often leading to the sense of feeling overwhelmed and unproductive. Regardless of teams doing their best effort to document and share details about the project, code and the infrastructure, it is not possible to always document every minor detail. And most of the times, it is those minor details that have become tribal knowledge, that get you completely blocked. To help avoid this, a ramp-up buddy is essential. A ramp-up buddy is basically someone who knows the project or the code base and is assigned as the dedicated person to answer your questions as you are ramping up. That way, you always know whom to go to and you don't feed bad interrupting random teammates. At the same time, from the ramp-up buddy's perspective, this time is factoring into their work load as well, so they don't have to feel like they are losing time when they are helping you.
Once you go past the initial ramp up period, this role can be fulfilled by your mentor for broader technical or non-technical areas.
Start establishing communication channels
When you start on a new team, chances are likely that you will work on a small bubble within your own immediate team. Don't get too comfortable with that idea. Start exploring areas outside your immediate team right away. Attend presentations, watch demos and read spec docs for any related area whenever you get a chance. This not only helps you understand the broader team goals, but also helps you identify what parts of the project different people work on. As a result, you build a catalog of subject matter experts that you can lean on when you need to. For example, say your next project is to add search capability to your team's feature. If you already know that someone else from another team has previously added a similar capability for another feature, you can have a quick meeting with them to understand their experience. Not only that, having context of people's interests and strengths makes up for a good conversation when you bump into them in the hallway, during lunch or at happy hour.
Start high level, then dive deep when learning a new code base
Learning a new code base can be daunting, especially if it's large and made up of many components. And you will hear different opinions on what's the best way to learn a new code base. Some will say small bug fixes are a great way to start while others will ask you to start reading pull requests for code reviews. I've found that the best way to learn a new code base pick a specific sub-component of a project -- let's say CRUD operations on a user object. Then ask a senior engineer to give you a very high level architecture diagram of how CRUD happens on the project, what are the scenarios a user gets updated and what are they entry points for that to happen.
Now take those entry points, let's assume a set of REST APIs and follow the code all the way through to the user being created, read, updated or deleted and all the way back to the API response. Take note of all the transformations that happen to the model, the services and methods that the code path goes through and try to map them to the high-level architecture diagram you initially got from the architecture review. Once you have a decent understanding of the workflow, do the same thing with the next component.
What you will notice as you learn more components is that as you go deeper downstream, code paths will start cross paths and you will come across services, classes, models or methods that you are already familiar with. Think if it like solving a jigsaw puzzle. As you fill in the pieces, they will naturally converge to areas that are already filled in. At the end of this exercise, you will have a much better architectural picture of the project.
Manage and be on top of you tasks diligently
It's really common for young engineers to just get lost in one vague task. Even if your company or team doesn't have a good task management system, that shouldn't stop you from managing your own tasks. This is also true not just for your work, but with everything in your life. Managing your time well is the number one thing that will help you get more done in less time and get the feeling of accomplishment. I have a ton of videos on time and task management, so I wont go into much detail here, but I will link those videos in the description below. The gist of it is to create a habit of breaking down your tasks into actionable work items that you can execute independently. Going back to an earlier example, "add search capability to current feature" is not a task. It is a deliverable, or a high level feature itself. This should be broken down into multiple tasks that are actionable. So read up on good productivity practices on how to decompose, estimate and track your time and you will reap the benefits quite quickly. And it is really important to start this habit early because overtime it makes you really good at estimating how long something takes. This lets your prioritize your work, organize and schedule them appropriately so that you don't get overwhelmed by a ton of backlogged items.
Don't stay blocked for too long & round-robin your questions when possible
Since you are new to the team, if you don't know how to proceed on a problem after a few hours of deliberation, it is likely that you are missing some key information to unblock yourself. This will happen quite frequently in the beginning. That's okay, and expected. What you should learn to do is to identify when to give up and reach out for help. There is no hard an fast rule for this, but if you are new, err on the side of asking question because otherwise you will likely go down the wrong rabbit hold wasting even more time. You will also notice that you will naturally gravitate towards the same person or set of people when you want to reach out. This happens because you feel comfortable with them -- because they appear nice, they seem less intimidating, or whatever the reason may be. However, refrain from always reaching out to the same person esp. if you know there are other folks who can also help you out. Try to rotate your questions between different people, unless this is a ramp up question and you have a dedicated ramp-up buddy as discussed in a previous point. There are two reasons for this:
First, you load balance your questions and don't end up interrupting or randomizing the same person.
Second, when you get answers for the same person all the time, you end up learning their style and thinking process. As a new software engineer, you want to diversify your learning sources. Seeking help from different people lets you get different perspectives on a similar set of problems.
