When you work with code every day, you start to notice things that can be done faster or make your code cleaner. It's one of the skills you develop over time as you get exposed to different projects. Keep in mind that some of the things that help you work more efficiently have nothing to do with your computer.
The things around you and how you keep your work area organized impact you. Do you ever get tired of moving things around or trying to find things? When you need to add features or refactor code to fix bugs, these few tips might help.
Set up your development environment
That could mean adding a theme to VSCode or deciding how you want to arrange your workstation. Your development environment is more than just your computer and the extensions. Think about the space you're in and try to make it feel right for you. Maybe you need less light or a different desk.
The area you work in is just as important as the settings on your computer. Those computer settings are important though. Make sure your brightness and quick keys are set up to make you more comfortable. Try to add as many shortcuts as you can for tasks you do all of the time. It moves things along a lot faster.
Take advantage of typing
Adding types to a project can be gradually done as you add new features and refactor code. Doing so can help you find potential issues before they become a problem because you know what data to expect. It takes some getting used to, but once you have types in your project going back is really hard.
Have a separate folder for helper files
Sometimes you have complex apps that have many reusable functions and types that can be grouped by their general functionality, like custom hooks and types for specific APIs. When you put all of these groups in one folder instead of having them spread across your app, it makes long term maintenance cleaner.
This is one of the ways you can make sure you aren't repeating code through your app. It gives everyone on the project a specific place to put helper functions and new developers can find things faster.
That's why people work on packages and maintain them. They save you so much time. If you want to customize them, you have options like extending a package and adding your own functionality. Many packages will let you import the specific methods or parameters you need without installing the entire package when you're looking at performance.
Include permission/role considerations early
When you're developing an API, you want to make sure that certain users have access to different information. That's why it's important to think about user roles and permissions early in development. Different permissions will completely change how users interact with the API so that can add to your development time because you have to account for different scenarios.
That's why it's important to think about these before jumping too deep into development. Talk to the project or product managers and see how an endpoint will be used so you can start planning for those weird edge cases.
Plan before you code
It's way more fun to jump in and start writing code, but it'll save you a lot of time if you plan first. Even if you have a formal sprint process where you review tasks with your team, take some time to make plans for your own tasks. Think about how you want to tackle an issue or new feature.
Try to break it down into the steps you think it will take to implement changes before you make them. When you can break the task down into the smallest pieces of work you can think of, writing the code becomes clearer.
Write docs as you code
Write those document comments above functions and parameters that are used in multiple places in the code. That way when you hover over them in other parts of the code, you'll be able to see what needs to passed in and what return value to expect. Don't be afraid to write helpful comments around complicated code either.
Adding little notes will help you and future developers quickly figure out what they are looking at. Also creating a little external doc that the team can refer to will help with bringing in new people. It could be something as updating the README to mention some of the oddities of the code.
These are some of the things I've noticed while working on different projects in my developer journeys. Hopefully these make sense and are useful! Do you have anything else you'd add?
Top comments (1)
Yes and no
Very rough high-level breakdown, yes. Detailed task breakdown, no. Most of the time things will not turn out as your breakdown predicts. Doing such a breakdown will usually make the task take longer overall as you waste time on a plan you end up diverging from and throwing out.
This realisation comes from 25+ years of development experience