💡 "By failing to plan, you are preparing to fail." Benjamin Franklin

The best way to kickoff the new year is to do an adequate planning. In this post, I will dump down my thoughts on planning for software engineering career. Before we can start planning, we need to list a set of criteria of what we are trying achieve in a year.

To find these criteria, try to check the expectations of your role at work, for example if you are a senior software engineer, the role responsibilities can be anything from designing new systems, all the way to mentoring new engineers. Meaning, the planning should contain items to cover these responsibilities.

Lets write a set of criteria that we should fulfill.

• Design new systems / feature
• Implement (collaborate) in building new systems from a to z
• Spot bottlenecks and improve on the performance of current systems
• Mentor new engineers
• Improve the quality of the team in general

Also, it could be good to know what criteria that you are not responsible for.

• Lead a large team of engineers
• design a cross functional system
• design a new product
• propose or change a paved road

Based on your level, feel free to change the above criteria to fit your responsibilities. Now after we have the criteria ready, we can start creating the career planning framework.

The framework I am proposing here is the bucket framework. The following image shows the framework 😄.

Imagine that the whole year is like a bucket, and you have to fill out this bucket with rocks. You can pick few big rocks, and more of smaller ones. The big rocks represent the major project that takes the majority of the time. But at the same time, we can fit in few smaller rocks. Smaller rocks represent the smaller achievements (e.g., fixing the dev environment).

The nature of the big rocks should be totally different from the small ones. The big rocks (or major projects) should fulfill the following criteria:

1. They have a tangible value for the team and the company. For example, a new service or feature.
2. They are presentable. Meaning, you should be able to have a 25 minutes presentation about them with no issue. Usually they have a design document and sometimes a product document.
3. They can take few weeks to few months worth of work.
4. You should be able to acquire new skills working on them (both soft and hard skills)
5. You can get feedback from other team members.

The small rocks on the other hand differ from the big ones by the following:

1. Take short time to finish. Usually days
2. Already gained skills can be applied. Meaning, no new skill might be needed to learn in order to accomplish the task
3. Does not require writing a design document

Examples of the small rocks are fixing a long standing bug, participating in incidents, writing documentations.

Note: It is very important to collaborate with the engineering manager to make sure that all are within the same page when planning for the year according to the above framework.

In addition, while working on the projects, try keep an eye on the core values which you or your company adopt. Examples:

1. Continues Learning
2. Effecient Excution
3. Clear Communication

What about time? We need to be mindful that the time resource is limited. So be careful when planning to avoid over promising.

Based on the above framework, we can now start planning for the projects to work on. The following are just examples of projects:

1. Improve on the code quality of the team. Few examples:

   • Write a documentation of best practices
   • Watch test coverage and try to improve it a little bit
   • Create learning sessions about best practices
   • Pair programming sessions

2. Improve on observability. Few examples:

   • Make sure that logs are sufficient
   • Make sure the logs are readable
   • Can read dashboards.

3. Identify bottlenecks and performance issues

   • Keep an eye on code changes to avoid introducing performance issues
   • Read services profiles and identify any issue

4. Improve the stability of the dev environments / experience

   • Make sure everyone is having a seamless experience with the local IDEs

5. Help other team members

   • Schedule recurring 1:1 meetings with other team members

6. Sufficient documentations

   • Services
   • Runbook

If it helps, you can organize the projects planning using a table where each item can have a priority, size, and expected time to work on per week. Then try to limit the total amount of needed time to 40 hours (taking into consideration that a working week is 40 hours). The following table represents an example of weekly planning:

Happy planning for 2024 🎉