DEV Community

Cover image for How to Finish What They Started?
Abdul Rahman Zantout for Techhive.IO

Posted on • Updated on • Originally published at techhive.io

How to Finish What They Started?

So you're a new hire at your new company, you feel excited, and you want to jump right in.

Your manager briefed you about the project you're about to handle, wished you good luck, and went their way.

You sit down behind your computer. You launch your editor only to be perplexed by the complexity of the project.

You find monoliths, unstructured code and no documentation.

To make things worse, you have a strict deadline to make quick progress and complete the rest of the requirements.

You sit down for hours. You wrap your head around how the original author thought and coded.

You try to implement a simple feature, but another break.

You feel overwhelmed, your manager is understanding, tries to support you in the best way they can,  but there's not much else they can do to help you.

The deadline is approaching.

What do you do?

Draw a high-level diagram of how the software currently is.

It shouldn't matter if it's a UML diagram or a simple graph.

Visualizing the software you are working on should take you a few hours to complete, but will save you much more time when making decisions in the future.

Checking the design and the folder structures might give you a head-start (folder structure is not always a good indicator, however).

Visualizing what you're working on forces you to think hard about how everything fits together, and most importantly, how everything should fit together.

Try to figure out where do the new features fit in.

Try to add the new features in your new diagram. Worry about improving it later. This is critical, especially if you're on a strict deadline.

Properly segment the parts of the applications you're working on in a clear and concise matter.  You can, for example, segment by modules or by business features.

You are most probably dealing with a lot of legacy code: don't let that scare you. You should only care about the I/O of a function, class or module for now. Refactor later.

Document.

Think of it as your log.

Your predecessors probably did not document their code. Start by documenting the parts you are working on.

Keep your notes brief and straight to the point.

That way, you engage your mind and realize how everything connects.

Remember, you are doing this for future you too. So make sure you don't write anything that needs some forethought to figure out later.

First impressions last.

The days go by, and you still need time to work on some core functionalities, but you also need to demo your progress.

Start with the smallest features that make a significant impact.

You would be surprised how fixing a layout, a dropdown, or even a button can have a positive impact on your client's expectation.

Remember that you are likely building a product that non-technical people will use, not other developers. 

Some features or fixes might seem trivial for you, especially when you compare it to the complexity of another module or component. 

Such a small fix can go a long way for you, and make a lasting impression on the client.

Manage expectations.

Expectations matter. Your manager wants to see progress.

Telling the truth, even if it might cost you your job (9 out of 10 it won't, so don't worry), is the surest way to manage expectations.

Most people over-estimate what they can accomplish, give unrealistic deadlines, and often end up facing increasingly stressful situations.

They end up explaining to their clients and their managers why things went wrong, stress too much to fix the problems without strategizing their next steps and end up being overwhelmed and unproductive.

Don't be like those people.

Stay true, trust your abilities, give yourself time.

If you got stuck on a problem, take a break and solve another.

Make sure you set a schedule and stick to it.

Make sure to schedule the requirements you want to tackle.

Deadlines work.

Try to give yourself internal deadlines and set personal goals for the project.

When adding such deadlines and segmenting your requirements into smaller chunks, you feel more confident in delivering progress.

Update your schedule daily.

Some days a requirement you are implementing might take you less time to implement than anticipated. Sometimes more.

With trial and error, you learn how to assess better.

Make sure you keep your schedule up to date. Updating your schedule forces you to think ahead and plan your steps.

Deliver fast, deliver often.

Remember: 1% improvement every day is much better than none at all.

You want to make sure you deliver fast and often.

Divide your work into small digestible chunks. This way, you can release bug fixes, features, or even both much more frequently.

Small, incremental improvements are better than 50 improvements released at once in a longer time frame.

You also decrease the risk of breaking a working prototype: by working in chunks, you know exactly where to find the problem if the prototype crashes.

Ask for an extension if you had to

You did everything laid out here, but the project's scope was too big to handle.

Ask for a time extension and explain your reasons. You will most probably get it.

Don't be afraid of your client or your manager. They're as human as you are. As long as you stay true, everything should be fine.

Final Words

Getting a new job or promotion is an exciting and potentially pivotal moment in one's career.

Every new project comes with its own set of challenges and difficulties.

You have to hit the ground running to prove your value, especially in the face of those difficulties.

To do so, you need to be organized, efficient, and to manage expectations around yourself.

All the steps and examples we have explored in this article were adapted for more technical people. However, the main principles of organization and expectations management do apply for the challenges you face in any career or industry.

Top comments (0)