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

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 don’t 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 won’t general 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. Don’t wait for inspiration, don’t 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 don’t 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-minutes 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 won’t be any good, but you’ll explore some options and check if your approach is viable. Don’t 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. Don’t get hung up on small details. If you can’t build a UI element or can’t 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’t 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 what exactly needs to be done.

It doesn’t 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 cannot 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 won’t work the way you need it. You may need help from the backend developers, and you don’t 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 don’t need to traverse trees or build a complex search jobs.

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, don’t forget you’re responsible for testing your code. It doesn’t 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’t do it, let your boss know about it as fast as possible. Don’t be afraid; most managers can handle respectful and sensible reservations. What they can’t 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. Don’t take a break; move on to different parts of the task, or test your code. Developers work under time pressure, so don’t waste time for no reason.

It doesn’t matter how good you are; Sometimes, things go off. If you know you won’t 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’re negotiable.

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 shouldn’t.

Only when the project is mature it’s time to maximize performance. This way, you can find significant bottlenecks and start optimization 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’t 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 don’t get stuck in endless refactors. Enough is enough.

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 don’t 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’t 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 don’t 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.

Leave a Comment