DEV Community

Cover image for Productivity Tips From Developers to Developers
Anastasia 🏄🏻‍♀️
Anastasia 🏄🏻‍♀️

Posted on • Edited on

Productivity Tips From Developers to Developers

*header pic by Shen Comix

Remember when you were a junior dev and you didn't know how to progress faster, what productivity tools and appoaches to use, what kind of mindset you need to adopt. What tips and tools would you give to a younger self? What important lessons did you learn as a dev?

Please, share in the comments!
I'll pick some of your answers for my next article.

Latest comments (47)

Collapse
 
kansoldev profile image
Yahaya Oyinkansola

I would say learn how to share stuff online about what you know or are learning (2hat I am currently doing)

Understand the problem you are trying to solve, before writing any code. Having the understanding will make writing the code much easier

My 2 cents

Collapse
 
taijidude profile image
taijidude • Edited
Collapse
 
sheriffderek profile image
sheriffderek • Edited
  • Write less code. Once you start writing it - everything slows down / and your perspective gets boxed in. Just write it on paper / or in comments - or draw a picture.

  • Talk with people about your idea with someone else and see if you can get another way to look at it and maybe learn something. Learn in public.

  • Create small prototypes and show them to humans on real devices. They'll notice things you didn't and then you can incorporate those things.

  • Use a time timer to time-box and also to force yourself not to work.

  • Stop pretending you can multitask.

  • Actually know how to use your computer well. It's your main tool.

  • Sleep. Working "hard" is not working smart.

  • Have a social life. Otherwise, what's the point?

  • If you watch a tutorial, don't code along. Just take notes on the concepts

  • Stay out of the CMS for as long as possible, because that's the biggest bottleneck

  • Avoid anything that isn't absolutely necessary. Do you need that package, library, buildtool, future-tech-debt-machine? Do you need smartsheets, trello, monday, and more tasks to take up your time? Or would a simple README be even better?

Collapse
 
msamgan profile image
Mohammed Samgan Khan

search more, write less....
but make sure that, you know what you are doing...

Collapse
 
jaywhy13 profile image
Jean-Mark Wright

Here are some tips I've learned over the years:

  • No question is silly! I wish I could reclaim all the time I've lost thinking my question is dumb and I kept silent. I lost many opportunities to learn, question assumptions, make an impact and help others who were just as puzzled as I was!
  • Read, read and read some more! This is one sure way to ensure growth along your software journey. I remember many years ago I read Clean Code and I felt like discarding some of my previous years! So much has already been figured out! Learn from other people's mistakes!
  • Don't lose time fighting for relevance. I lost a lot of time doing things just trying to be feel more relevant and valued. Understand that you are doing your best and concentrate on building/working on valuable things. If you're working in an environment where you don't feel valued, move on.
Collapse
 
mikecarrascomx profile image
Miguel Carrasco

Only do it.

Collapse
 
icyjoseph profile image
Joseph • Edited

Learn CLI commands, to search, replace, and edit on the fly.

Save snippets and document them heavily.

Working with people is actually the hard part of the job.

Code review your own submissions, harder than you review others.

Collapse
 
demoran23 profile image
Adam Skinner

Learn how to use your ide. Pay attention to the refactorings it provides, learn the navigation shortcuts, learn its capabilities.

If you're a professional, invest in the best tools. You're investing in making yourself a more effective and efficient programmer.

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.

Focus on the fundamentals. Learn your language and its syntax.

Annotate your code with your intentions, not your implementations.

Names should carry semantic weight.

Don't abbreviate things in variable names.

Follow the idioms of your language.

Collapse
 
sachinchoolur profile image
Sachin N

Along with the correct set of tools, setting up the right mindset is essential to being productive.

  • 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.
  • Determine what you need to accomplish each day.
  • Write down what you've completed each day before going to bed.
  • Get 8 hours of sleep.
Collapse
 
leob profile image
leob • Edited

Analysis is all-important, think things through (and discuss them with the user or customer when relevant) before you write any code, that's my number 1, number 2 and number 3 point. Part of that is - trust your gut feeling, when a solution does not "feel" right, in 90% of the cases that is because it isn't right - this is something that could have saved me from trouble more than once.

Then point number 4 (and 5, and 6) - 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.

Yeah and I'm now a pretty big believer in automated testing, even though on 95% of my projects I didn't do it, lol, but I'm now convinced that I should - when done well it saves you time, increases quality, and can even help you with design.

Some comments have been hidden by the post's author - find out more