DEV Community 👩‍💻👨‍💻

Cover image for 20 tips on how to become a better developer in 2022
Lars Wolters
Lars Wolters

Posted on • Updated on

20 tips on how to become a better developer in 2022

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. You can't know everything

It is okay to not know something. Ask for help when you need it and don't put in countless hours in solving something on your own, when someone else can help you out within 5 minutes.

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 🙂

Top comments (30)

Collapse
 
jonrandy profile image
Jon Randy • Edited on

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.

Collapse
 
larstw98 profile image
Lars Wolters Author

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 🙂

Collapse
 
abdurrkhalid333 profile image
Abdur Rehman Khalid

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.

Collapse
 
larstw98 profile image
Lars Wolters Author

I agree with this 🙂

Collapse
 
jonrandy profile image
Jon Randy

tests ensure you that the things that were working previously are working fine with the things that you have just built

Err... what? Unless you changed the original thing while building the new thing, then the original thing will be working the same.

Collapse
 
jonrandy profile image
Jon Randy • Edited on

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)

Collapse
 
axibord profile image
Info Comment hidden by post author - thread only accessible via permalink
Aghiles Lounis

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.

Collapse
 
larstw98 profile image
Lars Wolters Author • Edited on

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 🙂

Thread Thread
 
axibord profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Aghiles Lounis

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...

Thread Thread
 
michaeltharrington profile image
Michael Tharrington (he/him)

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.

Collapse
 
jonrandy profile image
Jon Randy • Edited on

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.

Collapse
 
ramazanm profile image
Ramazan

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.

Collapse
 
jonrandy profile image
Jon Randy • Edited on

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

Collapse
 
wadecodez profile image
Wade Zimmerman

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.

Collapse
 
larstw98 profile image
Lars Wolters Author

Great one indeed. I will add it to part 2 I plan on writing in the future 😊

 
larstw98 profile image
Lars Wolters Author • Edited on

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 🙂

Thread Thread
 
jonrandy profile image
Jon Randy • Edited on

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 😀

Collapse
 
baasmurdo profile image
BaasMurdo

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.

Collapse
 
larstw98 profile image
Lars Wolters Author

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.

Collapse
 
maurerkrisztian profile image
Maurer Krisztián • Edited on
  • 21. Write your own javascript framework
Collapse
 
larstw98 profile image
Lars Wolters Author

& switch to a completely new Linux distro you have never worked with every 3 days.

Collapse
 
maurerkrisztian profile image
Maurer Krisztián

And code with vim

 
larstw98 profile image
Lars Wolters Author

Let's just conclude that it's the decision of a developer / development team whether to test a codebase or not.

Thread Thread
 
kev4ever profile image
Kevin van Schaijk • Edited on

@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👍

Thread Thread
 
larstw98 profile image
Lars Wolters Author

Exactly this!

Collapse
 
kev4ever profile image
Kevin van Schaijk • Edited on

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 👍

Why is that?

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

🌚 Friends don't let friends browse without dark mode.

Sorry, it's true.