Hi all,
As a developer, you read and write code — and lots of it. It might feel like it is the only thing that matters in our profession as we improve and become better.
But, more things matter when we want to become more productive and better at what we do.
In this article, I will share 20 tips that boosted my productivity and well-being as a developer big time and might work for you too.
1. Keep your work environment clean
A clean working environment grants peace of mind and can make you more productive (there have been studies).
2. Use tools that fit your needs
This might sound obvious, but still: use the right tools that work for you, rather than for someone else.
3. Review the code of others
Reviewing the code of other developers keeps you sharp and you might even learn new ways of doing things (or not doing things).
4. Drink your cup of coffee at the right moments
Coffee contains caffeine, which increases mental alertness. Rather than drinking a cup before going to bed, drink one when you aim to focus for 1-2 hours on a complex piece of code.
5. Get more familiar with version control
We all know how to commit, pull and push, but there is more: you can never be too good at it, and it's a crucial aspect of the profession.
6. Make sure you know the basics
More than often, it all comes down to the basics. Make sure you know it and that you can explain it to others (which is a sign of mastery). Basic knowledge of a language might fade, especially when using a framework.
7. Get good at communication
Communication is key. Working in a team or with a client? Make sure to communicate properly and avoid making assumptions about whether someone knows a thing that you know.
8. Write your tests
As Gandalf once said, "one should never underestimate the power of a tested codebase". No, but seriously — it grants great stability and might save you a lot of debugging time in the future.
9. Use communities
We all know how to copy and paste an error in the Google search bar and click the first Stack Overflow link that pops up. But, sometimes, asking the question yourself in a community might get you a faster, and often better answer that fits your case.
10. Write comments where needed
Your code might be quite complex and hard to read, even though you tried your best and the variable names are close to perfect. In this case, elaborate on it using comments. There is nothing worse than working in a complex codebase with zero comments.
11. Stop distracting yourself
Reflect on what distracts you during the day. Maybe your phone, a co-worker, or the #general channel on Slack. Whatever it is, try to avoid it when you want to get things done.
12. Trust the people you work with
Have confidence in your team and the people you work with. They were hired for their expertise, just like you. If you trust them, they will trust you.
13. Never ship right before the weekend
Seriously, don't (unless you like to solve a lot of problems on your weekends).
14. Learn more about design patterns
Design patterns distinguish working code from good code. Learn more about design patterns that apply to your development stack.
15. Look for & solve problems early
Never let (code and non-code-related) problems escalate or exist without being seen. Look for issues early and tackle them as soon as possible.
16. Save useful resources
Saving useful resources, such as articles, guides, tools or repositories will greatly improve your productivity and knowledeg in the long run. I use this Notion template for saving everything 🚀
17. Aim for functionality, not perfection
No one is perfect: and neither is your code. Aim for functional code, rather than trying to make it perfect. If it's functional, you can always improve it to make it better later on, but know when to leave it as it is.
18. Plans are allowed to change
It is normal for a plan to change during execution. If something doesn't work as what initially looked like it would, don't hesitate: adapt to the situation and re-plan.
19. There is no 'best' way to write code
The implementation of a function can be different while it gives the same result. When something works, it works. Don't be too hard on yourself.
20. Avoid bad posture and RSI
I don't see this advice very often, but it's too important to leave it out of this list. You only have one body, so be careful with it. As a developer, most of your time will be spent seated behind a keyboard and monitor. Watch your posture and don't sit down for hours. Stand up every 30 - 50 minutes (or even more often) to get yourself a drink or walk a small distance.
Bonus: work hard, but enjoy your profession
Many people tend to work very hard but forget about the most important thing of all: you should enjoy what you do. Not every aspect of being a developer might be as fun as the other but focus on the initial reason and things that made you choose to do this profession.
Afterword
I know that this list isn't very code orientated and doesn't contain any code snippets. But, after I've been doing development for years in my free time and as a full-time job, these things are incredibly important for me to stick to staying productive and motivated. There are many pieces of advice and reminders that I would like to share, but that's something for later. I hope that at least one of these tips might help you in you and thank you for reading 🙂
To read more articles I wrote, you can visit my website: https://larswolters.dev
Thanks,
Lars
Top comments (26)
I honestly think writing tests is hugely overrated. I've been a professional developer for 27 years (programming for 39) and have rarely used automated testing, or worked anywhere that strongly advocates it. This has never been a problem.
I agree that software can be written without using tests. I learned about testing rather late but personally I’ve experienced too many times that when fixing a bug in X place, the code in place Y broke and I knew about it due to failing tests 🙂
I would not completely agree with that, because I have been working as a Software Developer for almost 3 years and I have not wrote any tests for the first 2 years and as I am moving forward in the Software Development field writing tests seems a good option to maintain the maintainability of the code, because tests ensure you that the things that were working previously are working fine with the things that you have just built and nothing has broken.
Tests has also made the life simpler with the combination of the CI/CD, and yes CI/CD and other pipelines helped me as developer very much.
I agree with this 🙂
Err... what? Unless you changed the original thing while building the new thing, then the original thing will be working the same.
I didn't write any tests until after about 24 years as a professional developer, and then only when it was absolutely insisted upon (rarely)
what are you talking about man, any serious software have tests, and ALL kind of tests unit, integration and E2E, it helps a TON, I'm only 25 I work at medium/big company, we have a huge app developed over 3 years, and you have absolutely 0 idea when you are updating the code or creating new features that you are not breaking previous code, it helps you ship the code with a great level of confidence, with CI pipeline everything is automated, as we ship new versions every 2 weeks, a lot of times we have huge merge conflicts and breaking tests, and it's part of our job to fix them. There is only 1 RULE for tests, you need to write GOOD tests, not a test that will make you app difficult to change, or a test that will break everyday, these are BAD tests written by bad programmers.
If you are working on a small projects or even medium, or hoby project/side..., this is the only time you can omit test (ex: a small selling page with dashboard and some stats for small client, in this case yes you can omit, it's something that will not change often and very easy anyway), but other more complex cases hell NO.
Writing tests is not a question of liking them or not, you HAVE to, if the project require tests, it's inevitable for an APPLICATION, maybe not for a website that will never evolve or very little.
I don't know what you were doing for 27 years, but saying this does not make you a good programmer, neither worse, I know programmers that have 10 years EXP and in a very short time I became way better and got better positions, it's not about time ONLY, it's a combination of time, intelligence(sadly yes, bc i'm not that intelligent), hard work.
Let’s keep the comment section a place for discussion rather than taking it to a personal level.
If this post causes hostile / insulting comments towards another person, I will unpublish it instantly. Please let’s not take it that far 🙂
So answering with an honest opinion is considered taking it to a personal level ? and @jonrandy I never said it was the only way everytime, but in case it is the only way on the situations i just described, if i hurt your feeling i'm sorry it was not my purpose AT ALL, but to give you good reasons to re-consider your view, you can read again if you want. @larstw98 censoring me will not change reality, it's too easy to censor, not helpful for anyone, you are not qualified to decide if it was personal or not, let everyone decide in the comments, they will blame me if it's the truth, but by doing this you are just over using your rights, it's astonishing for me to see that, I never insulted someone, or being hostile, but i'm 100% honest and will make you reconsider what you are thinking, and if i'm wrong prove it to me with arguments, and i will be MORE than happy to take them and publicly say that i was wrong no shame for that, that's what i call constructive criticism, not telling you yeah it's good you can have your own opinion, that's bullshiet. But since you don't like constructive criticism I will not comment on you posts.
@jonrandy I don't believe that coding time aka "experience" is impressive by any mean, if this hurt you i don't know what to say, but i never said you were bad, in fact you can be better that me who knows. I think you or the Author completely missed the point, but anyway...
Heyo!
My name is Michael and I'm a Community Manager at DEV.
Reading through your previous comment, it did come off as a bit hostile to me and I can understand why the author would have chosen to hide this comment. While we want you to feel open to expressing your opinion, we ask that you please be respectful of different view points & avoid dismissive language like "I don't know what you were doing for 27 years" — see our Code of Conduct.
And, to be clear, the author has the right to hide comments on their posts as they see fit. This is described here in the changelog post when we launched the hide comments feature.
Whoa! OK, calm down there! I was just recounting my opinion and experience from my career so far. In this industry, you don't HAVE to do anything... sure there may be norms, but you should do what works for you, your project, and your team. If you're big into testing and it works for you - great! But that isn't the only way to do things.
I was thinking like you until I completed my first test-driven project.
Actually until right after I made the first big change after publishing.
I can say that tests give you self-confidence. I mean, I can change anything on this project without any doubt.
So I suggest you, give a chance to TDD at least one time.
This may change your mind too.
Believe me, I've tried it - a number of times. Really didn't like it. Just slowed development for no apparent gain. I found that it also impedes the free flow of ideas, and tends to stifle creativity
Bonus tip. Work with a mentor. You learn all sorts of little tricks that will put you light years ahead of your peers. Getting a mentor will probably add more stress/work to your life for a year or two, but certainly worth it.
Great one indeed. I will add it to part 2 I plan on writing in the future 😊
Thanks for your reply, but as stated in the article, I shared tips that worked for me and might help someone else. I don’t see how that is ‘forcing writing tests upon every developer out there’. If you don’t agree with it, then don’t do it 😎
In case you are wondering why testing is important, this post explains it very well 🙂
I disagree to varying degrees with every point in that linked post - but, as you say, it works for some people... so, each to their own 😀
Something small that also helps over time, if you use something (CSS selector or API or function) that you haven't before or are not used to.
Take some time, just read through the docs (not like you are going to write a test on it, but just to have a better understanding. I'm talking about like 10 minutes) and then play around with it. (in jsfiddle / local project / codepen wherever)
Not just to copy and paste for your use case now, but to understand it a bit better for possible use cases later.
I agree. Taking the time to read through something and pay attention to it makes you really understand what you are doing, rather than just how to do it.
& switch to a completely new Linux distro you have never worked with every 3 days.
And code with vim
Let's just conclude that it's the decision of a developer / development team whether to test a codebase or not.
@wojtekxtx It's more about what you test, You don't need 100% test coverage. But to say tests are for newbie developers, is a bit short-sighted.
If it takes you longer to manually test certain features with new code added every day, it may be useful to write certain e2e-tests to test the functionality. If certain logic is very complex, and you want to test every possible flow, or you want to refactor some logic, unit tests can be helpful.
Everyone makes mistakes and introduces bugs at times, junior devs, and seniors. If manual testing is your thing. Go for it, if you think an automated test is useful for your use case go that way👍
Exactly this!
I think we have a different mindset/opinion if I read your reply. And I won't try to convince you. Everyone has their own opinions, and I respect yours 👍
Because tests are tools in your developer toolkit to test changes as the application grows. Of course you can manually test everything, but why not use tests if they could be useful.
It's the same with tools, if it helps you do the job why not use them? If you want to do it without, go for it😀.
Even if you think as yourself as a senior dev that rarely makes mistakes or spots errors soon, the majority of the time there are more devs than just one on a project and it could help you catch a bug sooner if certain components are related.
Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more