5 Tips to Tackle Ambiguity as a Software Engineer

As our experience grows, the ambiguity of software engineering projects will increase, which can manifest in many ways, such as:

1. Being asked to do something you've never done before
2. The current task depends on the progress of others' work
3. The resources and known conditions of the project are less than your expectation

In these situations, we, as software engineers, can easily get anxious. And this is fundamentally due to the fear of uncertainty. But don't worry, today I will share five tips to help you better tackle ambiguity.

1. More communications

To deal with ambiguity, the first step is to ask more and communicate more.

Every project will have a primary person in charge, such as a manager, PM, or tech lead. They are the ones who assign tasks to you. Starting a conversation with them, then ask them to recommend others who can further assist you. These people can answer more specific questions and pull you into related email threads, work groups, meetings, etc., to get your questions answered better.

There are a few points to note in this process:

• In the very beginning, it's important to clarify the project's expectations with all stakeholders. You need to be aligned with the expected outcomes of the project, write them down for reference, and verify them regulary during each follow-up in the future.
• If you're not sure about something, just ask. Never assume. Few people in the workplace will be blamed for asking too many questions. The ones who mess things up are often those who neglect communication, and their excuses often include the word "I thought..."
• Take notes, listing all the vague and unknown questions in the project documentation. When you get the answers, add them promptly. This will make it clearer and avoid asking repeated questions.

Through asking questions and communicating, you have already gained a lot of useful information, but there are certainly still some unclear parts. This leads to another key point--you must be able to make decisions when ambiguity exists.

This means you need to:

a. Get a list of all the remaining ambiguity

b. Reduce the risk of your decision

c. Adjust quickly when unexpected changes occur

2. Prepare milestone doc and tech spec

The purpose of the Milestone doc is to clarify the stages (milestones) a project needs to go through from start to finish. Each stage needs to clearly state the objectives, timeline, and person in charge, which are also part of the ambiguity.

With this document, the project's accountability and check-in points are also clarified, which is highly beneficial for the tracking and follow-up of the project later on.

The role of the tech spec is to help you think more comprehensively about the details within the project. I suggest everyone have their own set of templates, which should cover the main aspects of the project, such as API parameters, module design, unknown issues, and risks, etc.

With the template, all you need to do is fill in the content accordingly. Those uncertain areas are where the ambiguity lies, which allows for earlier clarification, preparing for different scenarios, making risks more manageable, and better dealing with changes in requirements.

3. Validate your ideas early

Before the major implementation, we can quickly validate our ideas by developing prototypes and proofs of concept. If it's working, continue to iterate based on it; if there are problems, you can also detect it and adjust in time.

This method is particularly effective when integrating third-party libraries or APIs. Instead of reading a bunch of documents and worrying about whether it will work, it's better to quickly write a PoC to test after understanding the basic usage. It won't take much time, and the effect is clear at a glance. This avoids investing a lot of time in the early stage while validating, thus reducing risk.

4. Start from simple and independent parts

Dividing the project into smaller parts can help you better assess the complexity of each part and their interdependencies. If a part depends on multiple parts and there are many unclear areas, the risk is naturally greater.

On the contrary, if it is relatively simple and independent, the interference from uncertain factors is small, and you can start from it.

For example, if the backend API called by the frontend is unclear, you can start by building frontend components and using fake data. When the API is confirmed, just switch to real data.

5. Design your code to handle changes better

The more flexible the code, the better the portability and scalability, and the stronger the ability to cope with changes, hence reduces the impact of ambiguity. Engineering abstraction is crucial.

For object-oriented programming, the core points of design are high cohesion and low coupling, that is, strong association within modules and weak dependency between modules. There is plenty of related material, so I won't elaborate here.

Think more about whether your code will still work if conditions change? How to minimize code changes if that happens?

I suggest you draw class diagrams before coding, as it will make it easier to understand the relationship between modules. I also recommend understanding common design patterns and principles so you can be more efficient in designing good architecture.

In summary, ambiguity is inevitably present in projects. As long as you are mentally prepared and adopt the correct methodology, you can make steady progress and ultimately complete the project. I hope this article has been helpful to everyone.