How To Nail First Years Of Frontend Developer Job — Time Management | by Szymon Adamiak | May, 2022

0
10

Learn to manage your most important asset – time

Photo by Kevin Ku on Unsplash

Programming is all about tradeoffs. Early in your career, you’ll discover you have to find a balance between different priorities – simplicity and performance, execution speed and ease of use, readability, conciseness, etc.

The thing that’s rarely mentioned, yet it’s critical for your career, is learning to manage your time. You can be the best developer in the world, but if you do not deliver on time, people will hate working with you. And you can get away with being slightly worse if your work is always on time.

Let’s learn how to manage your time within a day, in a sprint, and during the whole project in a way that will make you a valuable employee but will not undermine your growth.

You get into the office (or turn on a laptop at home), and here comes the first big decision of the day – what to do first?

In my experience, the great way is to start your day with the most demanding task. You’re likely to work the best when well-rested and your mind is fresh. Do not wait for inspiration, do not answer emails, and avoid procrastination at all costs. Get to the problematic code as fast as possible.

Time after lunch is excellent for doing less demanding, more repetitive tasks. It’s a great time to make calls and answer emails. After coding in the morning, you probably have some code to test, so do it. It’s also a time to review PRs or do other outstanding tasks that do not require much creativity.

For complex tasks, try to schedule longer periods of uninterrupted time. You can achieve much more in 90 minutes than in six 15-minute long bursts interrupted by calls, emails, and meetings.

To become an efficient developer, you have to enter a specific thinking mindset – thinking in drafts. Write the first version of the code to solve the task as fast as possible. That’s your first draft. Maybe it will not be any good, but you’ll explore some options and check if your approach is viable. Do not be afraid of failure. Assume you’ll fail at first.

Fast feedback is the best feedback.

If your method fails, try another one. If the code works, you can build on it.

Also, remember about the priorities. Do not get hung up on small details. If you can not build a UI element or can not implement a minor feature – leave it be. You’ll get back to it when you’re fresh. In the worst-case scenario, inform your manager that, for now, you can not do it.

Photo by Braden Collum on Unsplash

Imagine you are a part of the team building the next great Todo app. Your job is to implement components responsible for fetching, displaying, and editing tasks. Your deadline is two weeks.

This challenge comes with countless time-related decisions ranging from scheduling, optimization, and maintainability to the decisions of how long to work on a tricky part of the code and when to ask someone for help. Let’s get through all of the process one bit at a time.

To be a productive developer, you have to know exactly what needs to be done.

It does not matter how good your code is if you misunderstood the requirements. Being productive is different from being busy and hardworking. You are productive if you’re doing the things that push the project further.

For your task in the Todo app identifying essential features is easy. You need to fetch, display, and update data. But there are more unknowns than you think.

What tools should you use for making API calls? You may use your favorite stack to see if the rest of the team uses something else and need to rewrite the code. Who is responsible for validating or escaping data? Do you need to implement the design with pixel-perfect precision or do you need only a more or less accurate interface? Avoid wasting your time by getting as precise information as possible.

Set your priorities

You should schedule your work with one rule in mind – you want to know about the possible major problems first.

Things you can not control create the greatest problems. It often means you need to look at things that depend on other people and their work.

The first thing you need to do is to analyze the API endpoints. Ensure you know about all the necessary endpoints, check if they work, and return data or errors as expected.

More often than not, something will not work the way you need it. You may need help from the backend developers, and you do not know if they have time to do your bidding.

It may take a few hours or days to fix a back-end issue, and waiting may block your progress, so starting with it is crucial. This way, you can figure out a workaround or work on other product areas while waiting for the backend guys to address the blocker issues.

The second priority are complex algorithmic and structural problems. Think about all the algorithms and data structures you’ll need to use in the project. In front-end development, challenging algorithmic problems are relatively rare, but make sure you do not need to traverse trees or build a complex search functionality.

Complex data structures are more common. Usually, the data needs some transformations; you may need to use different structures for UI and requests.

Most of the time, you should leave implementing the UI for the end. HTML and CSS are usually the simplest. Also, from the manager’s perspective, they’re generally not as crucial as the core functionality.

Final advice

I’ve got two final pieces of advice on scheduling a sprint. Everything takes more time than you expect. So when planning your work, assume coding will take 1.5 times more than you think. Also, do not forget you’re responsible for testing your code. It does not matter if your company has testers; you want to ship tested software that works fine. Testers are there for edge cases, not basic lookup.

After examining all aspects of your task, you should have a general idea if it is achievable with your skillset and within a given deadline. If you believe you can not do it, let your boss know about it as fast as possible. Do not be afraid; most managers can handle respectful and sensible reservations. What they can not handle is a lack of reliable information on time.

In many cases, you’ll be waiting for someone. Maybe it’s a backend developer who needs to create an endpoint or a designer who forgot to prepare icons for you. Make the most of the waiting times. Do not take a break; move on to different parts of the task, or test your code. Developers work under time pressure, so do not waste time for no reason.

It does not matter how good you are; sometimes, things go off. If you know you will not finish on time, let your manager know as fast as possible. Missing the deadline is terrible, but it’s much worse to know you’ll miss it just half an hour before hitting it. Deadlines are important, but with good communication, they’s negotiable.

1*lzTcUUJyTDUKOkQvhSR 3A
Photo by Jo Szczepanska on Unsplash

The project is a sum of days and sprints, so you have to use the same rules in managing your time in the project. But projects also have another set of unique challenges, especially planning features and prioritizing.

The secret of efficient product building is the focus. Implement only required features, and make as few assumptions as necessary.

It’s common for developers to create solutions “just in case.” They assume the next feature may be needed and prepare their code to be developed further. It prolongs development time and adds complexity. And then the project shifts unexpectedly, and all additional code becomes unnecessary or even harmful.

Another issue is performance optimization. You should always have performance in mind. But you have to avoid optimizing code in the early stages of the project. Developers spend countless hours improving the performance of performant enough code. All code can always be additionally optimized, but most of the code should not.

Only when the project is mature it’s time to maximize performance. This way, you can find significant bottlenecks and start optimizing with them. Few millisecond improvements in other places are rarely worth dozens of development hours.

Use a similar rule of thumb when deciding how good your code should be. We all strive for modular, reusable, and maintainable code. But you can not write the perfect code; some things can always be improved. And time for the project is always limited. So try to write as good code as possible and always leave time for refactoring. But do not get stuck in endless refactors. Enough is enough.

1*fizuvSFId3u4ttSzzCE3bQ
Photo by Nagara Oyodo on Unsplash

The project you work on is vital for the company, but your progress is crucial for you. Regularly you’ll encounter problems you do not know how to solve right off the bat. If you struggle for an hour or two, you choose whether you should try working longer or maybe ask someone for help.

You’re much more likely to learn new things if you try to handle problems by yourself. But you can not impede the project by spending countless hours on simple features. Usually, the right balance is to ask for help after a few hours. If you’re stuck for two or three hours, leave the task and get back to it the next day. If after another two hours you do not have the solution ask others.

This way, you can reap the benefits of struggling with the challenge without slowing down the project. Of course, if your team is working on tight deadlines, the project is the priority, and you’ll need to ask for help faster. But as a general rule, remember that projects come and go, but your knowledge stays with you forever.

Source

LEAVE A REPLY

Please enter your comment!
Please enter your name here