đŸ‘šâ€đŸ’» Clyde's Cookbook
github logo
Philosophy of Software Engineering Book Cover

Philosophy of Software Engineering

To be a good software engineer.

version 0.3 - Draft

This book is a guide for myself to follow on how to be a good software engineer. I will write a bunch of principles to follow and will ensure that I keep in touch with these guidelines.

What defines 'good'?

‘Good’ is not defined as satisfactory or to be the opposite of evil. ‘Good’ is used as someone who follows the practices in this guide. To be a better software engineer than you were yesterday.

Rule #1: Don't argue.

You’re not always right, and even if you are, the other person(/s) may have an agenda. Pick your battles.

Even though you may be right, assume you're not. There's no clear right path to solve a problem as there's always more than one. Even if your opinion/solution seems valid, someone of higher authority will likely turn it down. There may be multiple reasons for turning it down. Such as that the current process may be for their own promotion, as they may want to follow it to meet their career goals. It could also be because their job could be on the line as they've made promises to stakeholders. Lastly, it could be they have an understanding of the bigger picture or timeline that has not been communicated.

This is why you should avoid arguing. Rather, explain your point clearly to present your best case. See it from their eyes as well as your own. Share your perspective so they can see where you're coming from, but also be in their shoes. Don't push or raise high emotional tones. Most importantly don't get angry, this will hurt you more than anything. Putting someone into the defensive stance will only hurt your point of view as he/she will no longer listen to your point but only your emotions.

Once your point and case has been made and heard, if it has made no difference, weight up the pros and cons. Check whether it's worth the effort to go on forward or not.

  • Is your job on the line?
  • Will this prevent your promotion?
  • Will this help the business, leaders and your colleagues?
  • Is the current long term vision bad for you and the business?

If you answer “no” to all of these, then it's best to move on and let go. If someone is accountable for the current idea/process/solution and you disagree with it, you won't have to worry, he/she will take the fall. However, don't try and make the person fail. Do the job properly. Try and believe the person is right even if you feel otherwise, because who knows you might be wrong. You will always learn from it, either right or wrong.

Rule #2: Give it your best.

Even if you don’t like the work, do your best work. Make sure you let your team and your manager know what you feel about tasks you don’t favour.

There are times when you will pick up a task that you don't agree or enjoy doing. However, these tasks are usually the ones where you can grow in areas you normally wouldn't want to focus on. This is why it is important to "give it your best". Don't act to get this task done and out of the way. Challenge the task and find ways of improvement. Reading 'A Philosophy of Software Design' I've learned the concept of "Design it twice!". Just as literal as it is, your first idea might not be as good as your second. So compare the two and decide what's best.

Ensure what you're outputting is your best work. You'll be surprised to know that it is fun and you'll learn many things out of it. One assumption that you might be afraid of is that you'll continue doing more of these unfavourable tasks because you've done them well. Make it clear to the team or leadership that you've done your best to complete these tasks but you do not wish to pursue more of them because it is not an area you wish to grow in. Ensure you raise it to all key stakeholders and they will understand and adjust accordingly. If there are a large amount of these tasks that you particularly don't enjoy, you have to give in to the fact that you might have to do more but ensure that your manager is aware and that progress is being made to move into something different. If no progress is made, then it's best to weigh up your options and possibly somewhere else.

'Give it your best' isn't just for tasks you don't enjoy. It should be for everything. I believe that if you enjoy what you're working on you'll lean towards giving it your best as you wish to be proud of the work you're doing. If you're not giving it your best then you should reflect on what you're doing. Reflecting back as to why you're not outputting your best will realign you to your values and pivot however you can towards it.

Striving to be your very best will always lead you down a better path. It will make you realise what you don't enjoy and what you excel in.

Rule #3: Assume positive intent.

No one is out to get you, assume they’re coming from a good place. Cultural differences may cause communication differences.

Whilst chatting online have you ever read something and misinterpreted it as something bad? This can happen a lot, especially when different cultures communicate differently. For example in India they have a hard time saying "no". For example, I've asked a developer in India whether or not they've understood the framework, he replied "yes". When I asked a follow up question on how would you approach passing the data object through to the user interface, he froze and didn't know what to do. For him, saying "no" felt like it was the wrong answer to say as it would come off as if he didn't listen to what I was saying. In Australia, people can be more blunt or confident to say "no". Understanding that there are cultural differences in how we communicate is very important. This is why we must always assume positive intent. Mostly everyone will be coming from a good place. The intentions are not to do bad. So even though he/she might have said something out of the ordinary from your point of view, in their shoes, it might be the right way.

It is important to check in to what the person is saying and understand it from their shoes first before accusing any wrongdoing. This will spare many long winded discussions as the stance is no longer a defencive one but one of understanding. Repeat their point of view back to them and create confidence that you've heard what was said and then reply back to give your perspective and back it with evidence of what they've said. It could be that you agree 90% to what that person might have shared but if not communicated appropriately that remaining 10% you disagree with might feel like 100% of a change. This is because the person is put into a defensive stance and is feeling attacked.

Rule #4: When you see bad code, try to refactor.

Always improve code that you have ownership of, but communicate with owners first if you do not own it. If refactoring legacy code is too large, focus on delivering a better alternative for future progress.

Before you start on working on existing code your intuition will tell you whether or not you can set aside time to refactor. Intuition is led by understanding ownership and scope. I bring this up because if it's code that's under different ownership, that team might have it under tech debt to fix those items. So, it is best to consult with the owners first before you want to make changes. However, if the code is under your team's ownership it is the right thing to clean and refactor places of the code that you're touching. If your work item touches code that smells (bad practices) then it is your obligation to improve it. Adding to an existing bad practice will only encourage further bad practice by others who will follow your steps. It will also increase the amount of work for someone else to refactor, that someone else could be you again!

Sometimes a complete refactor is too much work. You might be picking up a codebase that has a lot of legacy code. Countless hours of code that has been implemented by a large number of engineers. Rather than dwell on the heavy lifting to untangle a mess you can always start a new pattern that follows a future path. Leave comments and deprecate the old ways of working and show a path to use the new alternative so that other engineers can be aware of the problems.

It is also important to note that you shouldn't refactor code just for your own understanding. What might make sense to you, may not to someone else. Ensure you're writing it as if it's in third-person and get as many eyes on it as possible to review the changes being made.

Rule #5: Take code reviews seriously.

Allocate a time in your day for reviews and read them carefully.

Large code reviews are overwhelming, and you will encounter them a lot in your career. It can take a lot of energy to context switch from your current work to then look at a code review. Knowing this, it is important to find a time of day where you allocate a specific time for this type of work. Mentally knowing that you'll be context switching will help you block your current tasks so that you focus on this. It is easy to get distracted when you're given a direct message through a chat application or when someone comes over your shoulder to ask you to review the code. This is why it is important to tell your colleagues that you have a time in your day when you will take a look. The only exception when you should look at a code review immediately is when there is a production issue and the changes need to be made as quickly as possible to resolve. Or, if you have release cycles and it needs to be reviewed before the cutoff.

Setting aside time is probably the most important part of this rule. The next important aspect is to read the changes carefully. Follow and read the code as if you're running the code and following the instructions as if you were the machine. Glossing over will allow you to pick up obvious problems captured by pattern reading. If you've done a lot of code reviews and have written a lot of code it is easier to spot common mistakes or things that stand out because your mind has developed a muscle memory of certain patterns. Generally we get away with this a lot, but bugs tend to slip through. This is why it is important to go in more depth and actually check the logic that happens in the code.

For large PRs it’s best to run the code locally and step through the changes. This way it’s easier to get a better understanding of the changes.

Rule #6: Run QA code reviews.

Don’t merge a Pull Request without doing a QA test with other member(/s) in the first to prevent chances of bugs or unmet task requirements.

If you're an owner of a Pull Request (PR) or you have the permission to merge someone's PR, run a Quality Assurance review before merging. There are times after merging that bugs may get discovered due to the changes added, or a missing feature, or even misunderstanding of the original task. Sometimes the code review is only focused on getting it working. A QA review is more focused on the feature/business/task aspect of the changes. Walking through the changes with 1 or more engineers will help you have confidence in the changes made as well as a shared understanding with others. It's a great chance for engineers to learn and share important questions.

Once the QA review has been approved the PR can be merged. However, if changes had to be made, a follow up code and QA review must be made. Repeat until all is approved. QA reviews can be exempt if there are no new features or business logic changes, for example, adding a lint rule or some minor visual change that can be shown via a screenshot.

Rule #7: Choose your meetings, don't attend because you're invited.

Just because you’re invited to a meeting, it does not mean you should always attend. See whether you can provide or gain value before joining a meeting.

You can say "no". Time is our most valuable asset. No matter how much money you make, you can't buy back time and you can't buy more time. If you feel that joining a meeting that won't add any value to your time then don't join, but don't be selfish. It's easy to just not go to a meeting because you don't like it, however this doesn't add future value. If it's an all hands meeting for a team that you're not a part of and you're invited, you don't need to go to it. If it's a team meeting that introduces a new technology but you don't like it, that doesn't mean you shouldn't join. You should most definitely join this meeting. Listen to what is being shared and then if you still disagree with it, raise your point of view to the team. You might feel like you're not getting any value from it, but your opinions will be valued to your team members. Whether they agree or disagree you've shared your thoughts and that can help raise valuable questions for discussion.

To separate meetings from which you should join and which you shouldn't can be categorised as; passive and interactive. If you're joining a meeting where you can't express your own opinions but only passively listen to something you don't deal with or are already aware; don't join. If the meeting is interactive and you can contribute to it, you should join. If it's interactive but you don't have anything to contribute and doesn't inline with your work or values, then you should think twice whether or not this is a value of your time. Joining a meeting where you're passive and not present, for respect to others participating you shouldn't be there.

Rule #8: Include everyone present in the meeting, don't let people be quiet.

Meetings should always be inclusive. Everyone present will have something valuable to say or ask. Find ways to include and encourage contributions.

When meetings get hijacked by what I call "loudspeakers" it's easy to become a listener. It's in our nature to follow a leader, we're lazy by nature, if someone steps up to take a leadership role it feels like a relief to have it taken off your hands. Try not to be that type of person anymore. Even if you can identify yourself doing that, that's a great first step. Once you become aware that you're either not present in the meeting or you're just listening, ask yourself "does this follow my values or is this directly related to my work?". If you feel like you're wasting your time, it's time to leave the meeting. If you feel that you don't agree with what's being said, raise your point of view or suggestions. This will bring value to yourself as well as others. It will enable an environment that will grow and where ideas can be challenged. If you don't feel like you can contribute, because you're new to the subject or new to the company, raising it to the members in the meeting can set certain expectations and will also welcome other participants in the meeting to also voice out.

So the first part is about not letting yourself be silent and recognize when you do. The second part is trying to encourage others. Not everyone will be aware about being present in the meeting or even they can be shy to voice their opinion. Usually the shyness comes because someone in the meeting might be heavily opinionated or they talk in a loud tone of voice. It's important to do a "round table". Even if you're not sharing the topic or have a grasp of the subject, raise it back out to the participants in the meeting; "does everyone understand what x is saying?". What you want to look out for is the silent ones to voice out. If the group still remains quiet, raise it to a particular person; "X, do you have any questions or opinions on the matter?". You have to be careful how you raise the question directly at someone, because the last thing you want to do is back them into a corner. If you do, it becomes a bit rude and the response you will get won't be of great value. Finesse the question so that it gives the person the ability to raise a voice that can be shared or even have them reiterate on the subject to get better comprehension.

The goal of rule #8 is to encourage meaningful meetings where everyone is included into the discussion. This is also to help you when you're hosting a meeting on a subject you're wanting to share or discuss and feel valued. Nothing is as bad as when you're looking over at the faces in the meeting and no one is present, and if you've got only 1 other person being involved in the discussion, it feels like you could just have this conversation with them.

Rule #9: Encourage retrospectives.

Encourage your team to be the best they can be. Discuss problems and learn what’s working through a retrospective.

To create a productive team, it's important to share team values and individual perspectives. Programming is a creative practice. There is no correct way to do tasks. Therefore, individuals feel empowered by the tasks they do. If you try to tell how individuals should do their work, it may cause friction if they feel as though it's wrong. This is why micromanagement doesn't work. Leaders must let their engineers work on their craft, as long as they achieve set targets and task accountability. Empowered engineers will share knowledge with other engineers to bring consistency and efficiency. This is where retrospectives come in.

Sometimes the team isn't working well together or as well as it could be. Having a ritual such as retrospectives can be a useful tool to raise what is working and what isn't. What is a retrospective meeting? It's a meeting that involves all team members. Managers can participate in the meeting but should not run the meeting or dictate it. In the meeting you outline 'the good' (What is working?), 'the bad' (What isn't working? or what can be improved?) and 'ideas' (Ideas for improvement). Generally this is done on a whiteboard or if held online, on a virtual whiteboard or a tool like Trello/Miro to create cards that can be placed into a column. All participants in the meeting will contribute to the board and fill entries for each of the columns. Once all participants are done contributing, participants will now vote up to 3 cards in each column they'd like to discuss. After voting, participants are then able to discuss on the voted topics, the number of topics to discuss will depend on how long the meeting will run for. Topics chosen should be done in order of highest votes within a column and not across all 3 columns. For each discussed topic, an action should be made and member/s assigned to the action for accountability. At the next retrospective, these actions should be raised to see if progress has been made.

I have found retrospectives to be the most valuable meeting for the team. Some argue it's a waste of time, but I believe they haven't run the meeting correctly. A retrospective must be a safe space and should not be recorded. All participants must be open, honest and present. If it feels like a waste of time, then it should be raised, pivot to change how meetings are run accordingly so the team feels like they're getting valued.

If your team isn't running a retrospective, encourage it now! If they don't want to run the meeting, ask why and evaluate their reasoning.

Rule #10: Find time for your career. Ensure you properly evaluate your worth and compass.

You will always be the driver of your own destination. Don’t wait for leaders to help you, as they’re also driving their own path.

I fall into this trap where I'm in the grind of continual work. Picking up items, creating new ones, moving them to done, and the cycle repeats. We should do mini-retrospectives weekly to ourselves on our work and our career. We shouldn't think of the long-term goal in these retrospectives, but the short-term ones. Our long term goals tend to change, software changes too frequently, it's hard to have a long term goal and not end up pivoting at some point. So it's better to have short-term goals and ensure that what we're doing leads us to them. For example, I had a goal that I wanted to start a book club (books based on self improvement) for my colleagues where we can have a safe environment for everyone to share their thoughts on the book. It was a weekly meet, and I found as weeks went, everyone was sharing personal experiences and areas for growth. I would check in with myself every week to learn how I can improve the meeting. Whilst this is a bit of an indirect approach to my career, it helped with building leadership qualities. I was also surprised to receive a number of feedback from people thanking me for setting up this book club as it has helped them.

You don't have to start a bookclub, find something small you want to do that can help your career and write it down. Check In every week to see if you're still aligning to that goal. If you start to feel like this goal is not right, that's ok, make a new one, but write down why it wasn't right. If you notice that you keep changing your goals, then maybe you haven't figured out what you want. This is a tough place, as you might end up feeling lost. If this is the case, try and make your goals even smaller. It could be that your goal is still too large. The important part is that you complete and grow from the goals you've set. However, if you’re just completing small goals and not growing from them, it will leave you stagnated and serve no purpose.

Rule #11: Don't be biassed towards a language or technology.

Nothing is forever, things will always change. Learn as much as you can to find the right tool for the job when time comes.

Technology continues to forever grow. Usually it grows for the better, making it better for its users. This is why you should not limit yourself to programming languages you have the most comfort in. Be familiar with the latest trends and be aware of technology strengths. For example, Javascript is a great language choice to work on frontend web development, but is not great when used for large scale backend development because it is memory intensive and slow when given a large number of requests. Rather, choosing Go would be a better option as it's a simple language, low CPU and memory usage, and easily deals with parallelism and concurrency. Go is also a simple language, so developers new to the language can easily learn and adopt it.

Being aware of your surroundings will help you make better choices and choosing the right tool for the job, rather than picking something that you're already familiar with.

Rule #12: Think high-level first before diving deep.

Having a high-level view of the architecture will make you design better, long-term solutions.

Before starting or prototyping a new feature it is important to make sure you have an understanding of the whole system at a high level first. I have often come across times when I've gotten half way through or nearing the end of building a feature and realised that there was something preexisting that I could have leveraged. Or I've missed an important component of the design that needed to be incorporated which could have been prevented with prior research and understanding of the high level architecture.

Having a solid high level understanding of the architecture you're working in will help you design better solutions. These solutions will become solid foundations for others to reference. You cannot always rely that other engineers will share the same level of understanding as you do, therefore you must present solutions that can help navigate future engineers to the right path. Having that high level understanding will make you write code and use design patterns that help share that understanding.

Rule #13: Read books on topics.

Reading books will leave lasting impressions that will last throughout your career and make you a better engineer.

Reading books has greatly improved my engineering practice. As a self taught developer I learned by watching tutorials on YouTube. This was back in 2012. The amount of shared software engineering knowledge back then was a lot smaller than it is today. I only learned how to write and use a language but didn't learn best practices, patterns, etc. Once I picked up books on programming, it taught me foundations that I've kept throughout my career. I still feel strongly about this today. I see it like this; it is easier and quicker to create a video than it is to write a book. Writing a book requires a lot more thought and time to process your ideas. I have found that books tend to leave a lasting impression more so than videos.

Make sure you read books that don't favour an existing opinion you have. Read a variety of books to form your own opinion. You may be surprised to know that you might change your mind after reading it. For example, I used to like the book 'Clean Code' by Robert C. Martin. After reading 'Philosophy of Software Design' by John Ousterhout my opinions changed and I agreed with a lot of what Ousterhout said.

Rule #14: Encourage culture.

Happy team = productive team. Find ways to promote a good team culture that will result in longer retention and better output.

The best and most productive teams I've ever worked in were ones that had a good team culture. Team bias is a real thing and it is easy to think your team is the best. I have worked with a lot of different teams. I've experienced good and bad teams. The worst teams I've worked in were interestingly the teams that focus heavily on work. They lacked team culture and only focused on work. Even though they only focused on the work/tasks at hand, they were also the least performing and slowest moving. To sum up as to why they performed the worst is because of their lack of communication and transparency. The team didn't communicate their problems as they did not feel safe and would only focus on defending their productivity and ensuring they can meet their criteria.

High performing teams did the opposite. They shared and discussed internal and external software topics. Share opinions on the current architecture whether they loved or hated it, and what could be improved. The team would work closely together and help each other on tasks. Held meetings like 'Lean Coffee' and 'Retrospectives'. Ensure meetings run and close on time. Build trust and a safe space to share open honest opinions and thoughts. Go to lunch together or if the team is fully remote, hold weekly/fortnightly meetings to play a game or discuss fun topics.

If you work in a team that isn't collaborating with one another, try introducing activities to bridge the distance and build trust with one another. A strong team will stick together and will retain retention even when features or tasks hit those moments of un-excitement.

Rule #15: Grow others which will grow yourself.

Mentoring others will also help you grow and will sharpen your communication skills. In the end-of-the-day you want people to rally behind you and by helping others you gain trust.

Whilst we seek a mentor to help us grow, we forget that we can also help others. If you're experienced or even if you have great knowledge in a subject/language/technology/etc this experience can be shared. I have found that teaching is harder than being taught. So by helping others it will also help you. It will teach you how to communicate effectively, think holistically and learn more about the subject you're sharing/teaching.

When it comes to presenting new ideas/features/products in meetings, you'll be using the skills gained from mentor/teaching others. Being able to simplify something complex or break it down into something that's easy to digest will help you gain followers to rally behind the ideas you're sharing. It will also build your leadership skills and those whom you have helped will also have your support.

Rule #16: Don't sit, act!

Understand that the bystander effect applies to software engineering as well. Always try to help and take on challenges head on.

I've witnessed multiple times colleagues who are faced with a blocking issue but don't reach out for help. Or if there are no tasks, they won't go out and find work to do or raise awareness that they've got nothing to do. Asking to be spoon fed won't get you far. You need to act as soon as you're faced with an issue. Tasks can be easily dependent on others, so keeping a blocked task delayed without taking initiative to unblock it will do nothing to help the team get closer to the goals.

The bystander effect also occurs in software development. It's easy to assume that someone with the right skillset will pick up the blocked task. The task will eventually be completed, if you're not working on anything or you're looking for the next task to pick up once you're finished, tackle these challenges. It is often the reason you ignore these tasks is because you're unfamiliar, but these are opportunities. These tasks will help you increase your domain knowledge and will make you a valued engineer.

This rule also applies to urgent tasks or alerts that have been triggered by a detector that something has gone wrong with a service you own. Take action to help resolve the issue. Find out if help is needed. Only back out if it is clear that someone has taken control of the task/alert/issue and no longer requires assistance.

Rule #17: Don’t rush, take your time.

Take your time and make sure you’re completing the work thoroughly. Rushing to get things done fast will lead you to cause mistakes.

I have often fallen into the spell of 'getting shit done'. I would quickly smash out tasks and be quick to raise pull requests. However, this has also led me to make changes that require follow up changes to fix bugs or breaking builds. If I'd had taken the time and not rushed in getting the task done I would have prevented poor quality.

Taking your time also lets you explore better solutions. Rather than hacking it together, you'll be thinking like an engineer and use principles to help you design and build better solutions. Depending on how much time you can work on a task you can think about providing solutions that will last and not be a band-aid fix.

Rule #18: Don't form opinions too quickly.

Rather than being quick to hate, take your time to learn the tool, once you’ve used it for long enough you can form a solid opinion.

Just because you've used something for 5 minutes and don't like it, does not mean you have enough knowledge to form an opinion. Rather try using it for a few months to really get an understanding and then form an opinion on whether you like it or not. Gain enough understanding that you can actually have a conversation with someone who is an expert in it.

Being able to form a solid opinion whether you like or dislike something will earn you respect from other individuals. This is because you’re providing value to others, helping them decide whether or not they should try it out.

Rule #19: Question everything.

Question everything, not to challenge but to gain deeper understanding, validate solutions, and identify potential issues early, with the goal of better serving the customer and avoiding rework.

After many years working as a software engineer, one thing I commonly notice that amazing senior software engineers do is to question everything. It is not to question the status quo or integrity. Rather it’s to further understand or analyse the problem or solution. By questioning, you help better understand the problem/solution and also help the questionee revalidate their own problem/solution. There have been many occasions where I have witnessed further investigations to be required before working on a solution simply by asking the right questions.

Figuring out what the “right” questions are is the difficult part which comes from experience, but I would simply start by wanting to understand how this helps the customer. By understanding the problem or the solution to the problem it becomes easier to ‘deep dive’ into something with given context. From there, raise questions about the architecture, if there are any internal customers or possible stepping on toes with other teams, etc.

It is better to question early, rather than work towards a solution fast and later rework it.

Rule #20: Follow best practices and standards.

Code consistency and readability is important. Make sure to follow best practices and standards defined in your team or organisation.

When working on your own projects you can do whatever practices you like. You can make your own or you can follow common best practices and standards found online or from a book. However, when working for an organisation, it is essential that you follow the best practices and standards set out by your team or even better, by the organisation. Following these guidelines are essential because it creates consistency. For us engineers, reading and writing in codebases not authored by us is an everyday task. Being able to quickly read and understand patterns and structure is important. It helps us identify, locate, build upon, understand and estimate solutions faster.

As an engineer you should strive for developer consistency and if there are no best practices and standards found, create it and share it to your team.

Rule #21: Practice communication.

Find ways to communicate your or your team’s work to people. You’ll learn to discover how to communicate effectively to certain teams/people, making you a leader.

Writing high performant and scalable code may seem like an essential skill to have to be a good engineer, being an effective communicator is more important. As you progress further into your career, your time being hands and writing code become less. Your job will mostly be communicating to other leaders. Being an effective communicator is a good part of being a leader. Your team needs guidance on upcoming work or understanding of the company’s vision. Communicating your team’s ideas to other teams or towards a company vision is important for the team’s recognition.

Even though you’re not at that level yet, or are becoming one, practising on your communication skills is important. To be at that Principle or Distinguished level you already are an effective communicator. Take every opportunity to share ideas, raise awareness, and walkthrough your solutions. Communicate with other teams and share what you’re working on. Write about problems you’ve solved or your team has solved in an internal blog or even better, with permission, to an external blog. Practising this communication will help you learn what works and what doesn’t when communicating to certain groups of people. You will start to develop skills to become a good leader.

Rule #22: Understand business value.

Understand the business value of a task. If it has no value, try to remove it, otherwise do it quickly. Define your team’s priority by the business value of tasks.

Unfortunately, not all work given to your team has business value. You may even have stuff in your backlog/tech debt that has zero business value. Understanding what has value is important, it helps you decide how much time you should spend on it or if it should be scrapped. Also make sure what you’re working on aligns with the business, because if it’s not, when it comes to letting people go, you’ll be a target.

Many junior to mid level engineers will only focus on delivering the work without knowing how much value their work brings to the organisation. Remember to ‘question everything’. If you want to provide impact you need to work on high business value products/features. If you get given work that has low value, raise it, and if it has to be worked on, do it quickly, but don’t fight against not doing it. You’ve demonstrated that you understand value but also that you’ll do the work if necessary.

When it comes to estimating, it is important to have business value sense so that it can also be known to the team. Work can be correctly prioritised. This makes you a good team player and a leader.