20 Productivity Tips From Developers to Developers
Tags: productivity, career, programming, motivation
Published: 2022-03-13 17:37:15

*header pic by Kelsey Wroten

Being a developer is not easy – it is a mentally demanding job that requires many soft and hard skills and a certain set of personal traits to work productively and don’t burn out. So instead of working your way through the profession on your own, you can learn from experienced developers who have faced the most common problems and have learned their lessons. By adopting their wisdom, you can save yourself dozens and hundreds of hours doing unproductive things, experience less stress and trouble and grow faster.

In this article, we’ve gathered 20 best tips from developers for other developers on how they can hack their routines and achieve more in less time. Save this article to get back to it later.

## 1. Know Your Integrated Development Environment

Integrated development environments (IDE) are software suites that provide basic tools required to write and test software. [Best IDEs](https://www.lambdatest.com/blog/best-ide-for-web-development/) provide a central interface with all necessary features, including code editor, compiler, debugger and automation tools.

> “Learn how to use your IDE. Pay attention to the refactorings it provides, learn the navigation shortcuts, learn its capabilities.” – [Adam Skinner](https://dev.to/demoran23)

## 2. Learn Command Line Interface

Command Line Interface (CLI) is a text-based interface used to run programs, manage computer files and interact with the computer. CLI allows users to interact with the system or other applications using [CLI commands](https://www.ibm.com/docs/en/ds8900/9.0.2?topic=interface-cli-commands).

> “Learn CLI commands, to search, replace, and edit on the fly.” – Joseph

## 3. Never Rush To Code

Developers rush to write code at the moment they receive specifications. But in reality, rushed code means that it will most likely require refactoring or cleaning up.

> “Think things through (and discuss them with the user or customer when relevant) before you write any code” – [leob](https://dev.to/leob)

> “Something my seniors taught me, plan first. Like really plan it in your head, writing the final thing down takes very little time. Figuring all of it out, that is what takes skill and patience” – [Aman Jaiswal](https://dev.to/amanjaiswalofficial)

> “This is so true!! When I first started out, I used to be so excited to jump into the code and get lost in it. Dozens of bugs later, I could say I’m a bit more wise” – [Raphael Jambalos](https://twitter.com/Jamby_Juice)

> “In code, it never pays to rush” – [Brian Marick](https://twitter.com/marick)

## 4. Avoid The Golden Hammer

[Golden hammer anti-pattern](https://sourcemaking.com/antipatterns/golden-hammer) is a cognitive bias that involves an over-reliance on familiar tools, languages and platforms. This approach limits your learning potential and tech experience and degrades the quality of your work. One size never really fits all.

> “Avoid the golden hammer. There is no one way to do something and learn early on to formulate your options, pros and cons and pick the one that works for that situation. Also avoid cultures that enforce this “one way to do something”.” – [Melvyn Sopacua](https://dev.to/melvyn_sopacua_afcf30b58a)

## 5. Review Your Commits

[Pre-commit code reviews](https://marcroussy.com/2017/06/15/pre-commit-code-reviews/#:~:text=Pre%2Dcommit%20reviews%20help%20get,get%20into%20a%20user's%20hands.) have many benefits: they help developers get timely feedback, catch bugs and bad designs, and learn from fellow developers.

> “Always review your commits before you send them, you will be amazed by how many bugs you will catch of yourself before getting into someone else’s eyes. You better waste 10 minutes of your time than 1 man hour of multiple colleagues.” – [Victor A. Barzana](https://twitter.com/vbarzana)

## 6. But Practice Focused Learning

There’s a big controversy over whether developers should specialize or not. On one hand, the broader your knowledge, the more opportunities will be available to you. On the other hand, you are at a high risk of becoming a “jack of all trades, master of none”, suffer from [impostor syndrome](https://www.geeksforgeeks.org/imposter-syndrome-in-software-developers-am-i-a-fake-developer/) and [developer burnout](https://www.actitime.com/productivity/how-to-prevent-burnout).

> “Don’t try to learn “everything”, it’s a waste of time. Learn the fundamentals, then one or two languages and frameworks, and that’s it – don’t jump on every new bandwagon, ignore the fads and the hype. Specialize – life is too short, you can’t get good at a dozen things.” – [leob](https://dev.to/leob)

## 7. Build Side Projects

Side projects come in many forms and have lots of different purposes but they have an important thing in common: they provide numerous benefits. Side projects accelerate your learning, foster creativity, expand your [developer portfolio](https://www.actitime.com/productivity/how-to-build-a-great-developer-portfolio) and sometimes serve as a source of extra income.

> “Hands on projects / side projects are the best way to learn a technology” – [Adrian Matei](https://dev.to/ama)

## 8. Write Readable Code

Readable code is one of the most important qualities of a good developer. Readable code saves developer’s time and effort by reducing debugging time and keeping it maintainable and easy-to-understand.

> “Write readable code, do not comment it out if the code is self explanatory. That’s the reason why you use clear variable/method names.” – [Victor A. Barzana](https://twitter.com/vbarzana)

> “Write readable and not complicated/fancy code – you’ll thank yourself later.” – [Adrian Matei](https://dev.to/ama)

## 9. Track Time

Developers should track their time for multiple reasons. First of all, time tracking helps developers optimize their work, identify [peak productivity time](https://www.actitime.com/productivity/make-the-most-out-of-your-peak-productivity-hours), plan and prioritize their workload. Freelance developers profit twice as much: they can use time trackers to assess project profitability and bill their clients.

> “Developers often feel like they are not productive enough. Most of the time, it’s not true. Use a [free time tracker](https://www.actitime.com/) to record time you’ve spent on your tasks and document important actions and milestones“ – [Jane](https://dev.to/janegareth)

![Online timesheet interface in actiTIME](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9wfkia8gxiyg58wobss8.gif)

_Online timesheet interface in [actiTIME](https://www.actitime.com/) where every user can select task parameters they want to see in their timesheets_

## 10. Use Buffer Time

Agile teams measure multiple [developer performance metrics](https://www.actitime.com/productivity/developer-performance-metrics), including team velocity – amount of work a team can tackle during a single sprint. To understand your personal workload limits and restrictions, you can calculate your individual velocity, add little time buffers to it when estimating work activities and enjoy working at a more relaxed pace.

> “Try to estimate and track the real amount of time that you spent on the task. After you’ll find personal velocity, you can control the pressure that the company is trying to put on you. For example if you know that you will complete a task in 3 hours, you can estimate it in 4 hours and have some space to think and slow down.” – [Ihor Klymenok](https://dev.to/ihorklymenok)

> “One really important thing I wish I was better at when I got my first job was estimating the time needed for getting something done. Not sure whether it was my overconfidence in my abilities, availability of a clear roadmap for the task in my mind (usually hindered by unexpected bugs) or both that led me to usually say less than what it actually took. Frustrated both me and my teammates before a senior helped me with this process. TLDR: Always keep a buffer when asked how much time some task will take to be done” – [Anam.DevDes](https://twitter.com/ADevdes)

## 11. Build Soft Skills

Writing good code is not enough – developers should also have solid non-technical skills, including communication, teamwork, [time management](https://www.actitime.com/time-management-guide/time-management-problems-and-solutions), problem-solving, critical thinking, patience and persistence.

> “Nowadays developer jobs are moving remote so it becomes important to have better collaboration and teamwork skills. Public speaking adds an advantage.” – [Atharva Shirdhankar](https://twitter.com/_Atharva_08)

## 12. Automate as Much as You Can

In his book ‘[The Passionate Programmer](https://www.amazon.com/Passionate-Programmer-Remarkable-Development-Pragmatic-ebook/dp/B00AYQNR5U)’, Chad Fowler talks about building a great career as a software engineer and automation is one of the tips that he gives. There are many aspects of the developer’s work that can be automated. You can implement automation tools for testing, code reviewing, documentation or take a closer look at your code editor for starters.

> “Automate your repetitive tasks; everything you do that can be automated. You know you’re on the right track when you use regular expressions in your code editor at least once per day on a weekly average.” – [DarkWiiPlayer](https://dev.to/darkwiiplayer)

## 13. Consider The Far End Of The Productivity Curve

Senior developers use productivity and automation tools that look and feel too complex to junior devs. So, juniors often go look and adopt alternative tools that turn out to be ineffective after they become a little more experienced. So, the tip here is to listen to your mentor and learn the tools they advise you to learn – the learning curve won’t be easy but your efforts will eventually pay off.

> “Choose the tool that may slow you down at first but will help you later on. To give a hyperbolic example: One may achieve more today if they use notepad instead of vim; but if it takes you a month to learn the basics of vim, the next month of increased productivity will negate the lost time of the first month, and beyond that it’s all saved time.” – [DarkWiiPlayer](https://dev.to/darkwiiplayer)

## 14. Invest In Tools of The Trade

Just as developers invest time in learning new languages and tools, they should also take their office tools seriously. If you work in an open space environment and the noize around distracts you, you should not hesitate to buy yourself a good pair of headphones! Or if you work from a home office, you should also make sure that the tools that you use for work are comfortable and reliable.

> “Invest in noise cancelling headphones. Whether you work in the office or from home, you need to concentrate to work in the flow.” – [Stasy Barns](https://dev.to/barnsstasy)

> “Use standing desk and invest in the ergonomic chair” – [sudarshan](https://dev.to/sudarshansb143)

## 15. Beware of Developer Burnout

Nearly every developer has experienced burnout, probably more than once, so most of you are aware of its catastrophic consequences, including people quitting their jobs and even dropping their careers. It’s very important to take care of yourself every day, be aware of the [developer burnout symptoms](https://www.actitime.com/productivity/how-to-prevent-burnout) and know how to recover from it.

“Learn to identify when you’re burned out. Stop working for the day, or take a nap or something. If you don’t, you’re wasting your time and possibly creating new problems for tomorrow.” – [Adam Skinner](https://dev.to/demoran23)

## 16. Practice Journaling

Journaling is a flexible and powerful tool that can take many forms and serve different purposes. You can use it for pouring out thoughts and emotion, which reduces stress and helps you cope with difficulties. Then, you can create a whole dashboard with daily bullet lists, habits trackers and more – for example, [Notion](https://www.notion.so/) serves this purpose perfectly. Whatever journaling technique you choose, it’ll most likely turn out to be beneficial to your mental health and personal growth.

> “I use tables in Notion to record my sleeping, eating, sports and activity habits, track productivity and mood. It might sound like a waste of time but after you have data for a few months, you’ll see what gives you energy and life satisfaction and what drains it from you” – [Jane](https://dev.to/janegareth)

## 17. Take Breaks

Our brains are less productive without rest, and it’s especially true for knowledge workers. “Our brains are like sponges,” [says](https://health.clevelandclinic.org/why-downtime-is-essential-for-brain-health/) Dr. Bea, psychologist. “They can only soak up so much information before they’re saturated, then they have to dry out a bit.” So make sure to schedule rest time and unwind.

> “Even if you work for 12 hours a day, you’re probably only productive for around three hours. What you really need is 4 hours of deep work with regular breaks. Take a short break after working for 45-60 mins.” – [Sachin N](https://dev.to/sachinchoolur)

## 18. Keep a Record of Your Daily Achievements

Have you ever kept a [developer journal](https://dev.to/jacquibo/why-you-should-keep-a-code-journal-code-journaling-pt-1-of-4-k35)? It’s an effective tool for tracking your growth, career goals and progress, unloading your mind and more. The greatest benefit of a developer journal is the fact that you can map out your career development strategy and record your milestones and achievements. It means that you not only have great reasons to celebrate your success, but you can also rely on this evidence to gain promotion, pay rise or even get a better job.

“Write down what you’ve completed each day before going to bed.” – [Sachin N](https://dev.to/sachinchoolur)

## 19. Don’t Be Afraid To Make Mistakes

Many developers, especially Junior developers think they are not capable of doing their job, they underestimate their abilities and are afraid to make mistakes. It’s important to remind yourself everyday that mistakes are important components of the learning process and there’s nothing bad about them. Mistakes also mean that you do your best. Because only those who don’t do anything, don’t even make mistakes.

> “Recognise that, as a junior dev, you’re not yet able to write (much less understand) complex code patterns and syntax, and that’s okay. Your solution to X problem won’t be as elegant nor efficient as a dev who has 20 years of experience, and that’s okay.
> It is always worth doing something badly, provided you are learning and growing while you do it. As long as you have a drive or passion for what you do, you will improve. Don’t try to rush it, enjoy the journey, never stop asking questions, and when you hit 20 years of experience (which you will eventually) remember that you are still and always will be a learner.” – [Dan Walsh](https://twitter.com/_Deedubbs)

> “Bugs will happen. They don’t define your self-worth or competence and avoid any company culture that makes you feel worse about yourself when you leave a bug in your code. Instead: Own the bugs, analyze them (ask help from seniors if you get stuck) and learn.” – [Melvyn Sopacua](https://dev.to/melvyn_sopacua_afcf30b58a)

## 20. Don’t Skip Documentation

Documentation is created to educate users about the product or software it describes. It sounds obvious, but most of us, non-developers included, tend to use the item, the software, the program right away: we tend to think that we can read the interface and figure out how everything works on our own. But when it comes to developers, it’s important that they read documentation and, more than that, refer to the official sources.

> “This is not a big mistake. This is something which all programmers do all the time Including me, and that is trying to skip the documentation and trying to work with new technology by yourself. This is fairly common If you are working with tools or softwares … We just jump into the UI and start using it.
> However, like Quote says that, “You can save lots of hours of debugging If you just spend 10 min of time reading the documentation”. If you are not reading the documentation you could be reading unreliable sources. you could be reading from old sources. If the documentation is available, why not just go ahead and do that ?
> My best practice is to actually take official documentation If it is available or else you can stick to video tutorials or playlists. But also have an eye on what the official documentation says.” – [Rajkumar Thangavel](https://twitter.com/rajkuttie)

## Ready to Become an Even More Productive Developer?

What is productivity after all? Productivity is the amount of work you do per unit time. But these components and productivity measurements are not as simple as that. We can’t [measure developer effort](https://www.actitime.com/productivity/developer-performance-metrics) and the work done by lines of code, bugs fixed, completed tasks or any other metrics because they are not equal and their number doesn’t mean productive work. Nevertheless, time is essential for planning work and understanding how much work we accomplish in a unit time.

So, consider registering your tasks and time spent on them using time tracking software. For example, [actiTIME](https://www.actitime.com/) is great for tracking working time because it provides a weekly timesheet interface, a browser extension and a mobile app. More than that, actiTIME integrates with JIRA, GitHub, JitLab and 2,000+ other integrations. Join 10,000+ companies like DHL, Philips and Xerox – try a [free 30-day trial](https://www.actitime.com/free-online-trial) (no credit card required).

<a href="https://www.actitime.com/?utm_source=dev.to&utm_medium=Syndication&utm_content=NewBanner">![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/y175wpb14rt8wfm2jrqe.png)</a>