DEV Community

Cover image for Productivity Tips From Developers to Developers

Productivity Tips From Developers to Developers

Anastasia πŸ„πŸ»β€β™€οΈ on January 29, 2022

*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...
Collapse
 
melvyn_sopacua_afcf30b58a profile image
Melvyn Sopacua
  • You don't get paid by size of commit or number of lines produced (if you do, get out of there). Avoid coding first, most likely what you are solving has already been solved. This forces you to think in abstracts about your problem (in order to find the package you need). Abstraction is at the core of programming.
  • Don't modify anything in get
  • Caching is a performance optimization and cause of many subtle bugs. Use with care.
  • 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".
  • Code formatting is not something worth spending time on in this day and age. Pick an opiniated formatter, configure it and run with it.
  • Bugs will happen. They don't define your self-worth or competence and avoid any company culture that make you feel worse about yourself when you left a bug in your code. Instead: Own the bugs, analyze them (ask help from seniors if you get stuck) and learn.
  • And last but not least: commit messages are not about what you did (I can read that in git log -p), but about WHY you did it. About the context of the change. Reference tickets. Summarize your analysis. This will tremendously help your future self, your new team mate or the person fixing a bug to understand the code and what happened to it over time.
Collapse
 
vbarzana profile image
Victor A. Barzana

Well said bud!

  • Also, if you REUSE please consider the maintainability "last commit date :)" of the project you are reusing and who is taking care of it. Number of stars, downloads, etc... Compare to other products similar.
  • Listen to others, but formulate your own point of view.
  • 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 elses eyes, you better waste 10 minutes of your time than 1 man hours of multiple colleagues.
  • Don't obfuscate/minify your code early on, leave that job to compilers, minifiers, bundlers.
  • 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.
  • Read a lot of articles every day so you find great posts like this!
  • Communicate, ask dumb questions to your colleagues, it doesn't matter, this shouldn't be a problem.
  • Make a todo list of all concepts you don't understand and ask someone to explain it to you with their words, usually this works better than watching a bunch of youtube videos or taking an online course. Instead, focus in what you love, you don't have to know everything, but sometimes you need to just get quick answers, this is the way!
  • Code when you are less tired, your productivity will increase 90% and you will see the results.

Have a wonderful way up to the top, you are already on the right track!

Cheers, peace and love!

Collapse
 
rolfstreefkerk profile image
Rolf Streefkerk

I will add, commit messages should link back to actual issue numbers in your Kanban board such that documentation, issues, bugs can be traced to code commits at all times.
This helps with on-boarding, new bug resolution, old bug resolutions, code understanding, and code documentation in general.

Collapse
 
janegareth profile image
Jane
  1. Know your development environment and tools. Know your editor like the back of your hand. What’s the quickest way to find a class or refactor a method? Take time to learn the shortcuts and use them in your work
  2. Take care of yourself. Sleep well, eat well, give enough rest to your head, do hobbies - live a healthy and exciting life outside work
  3. Document your code for yourself and your team
  4. Track working time. Developers often feel like they are not productive enough. Most of the time, it's not true. Use a free time tracker to record time you've spent on your tasks and document important actions and milestones
  5. Practice journaling. 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 your energy and life satisfaction and what drains it from you
  6. Meditate to stop your mind from wandering and to make it more sharp and focused
  7. Practice gratitude. It's a great tool from positive psychology that, if done daily, restructures your mind and teaches you to feel more positive and satisfied, value small things and feel more stable when moving towards your goals
  8. Take breaks. When you feel stuck, take a short walk outside to have some fresh air, give your eyes some rest and treat yourself with a cup of Joe

Hope it helps! :)

Collapse
 
nvspradeep profile image
Pradeep Nooney

Hey Jane, Nice tips!.
Regarding the journaling part, recently i also started using Notion, Please share the notion template structure if you can.

Collapse
 
janegareth profile image
Jane

Thanks, Pradeep!
Sure! You should be able to dublicate it to your account: painted-teller-bf3.notion.site/Hab...

Collapse
 
amanjaiswalofficial profile image
Aman Jaiswal

Never rush to code. 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

Collapse
 
flodev profile image
Florian Klenk

I personally can't completely agree with this but maybe I'm different with that topic.
I love the code first approach.
For instance for planning an Api it is incredible useful to me to write the code down how you will eventually use the api even though it does not exist yet.
It helps me understanding how the interfaces will be designed.
Also helps me in the frontend how components can be designed if I start writing the top component and how it will use the not yet existing sub components.
Nevertheless I still use the whiteboard for umls and other stuff.

Collapse
 
raphael_jambalos profile image
Raphael Jambalos

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

Collapse
 
amanjaiswalofficial profile image
Aman Jaiswal

Haha. Happens to all of us.

Collapse
 
barnsstasy profile image
Stasy Barns
  • Be a stoic. I'm not a big fan of phylosophy, but stoicism changed my attitude towards life and career. It teaches you to make the most of what you have, be a warrior that is headstrong, learn from mistakes and be mindful of what's going on in your life and career. Here are 10 priciples to help you get started.
  • Invest in noise canceling headphones. Whether you work in the office or from home, you need to concetrate to work in the flow.
  • Work out to stay fit and healthy and release stress
Collapse
 
incrementis profile image
Akin C.

To my previous self:
"
You will read more code than you will create code.
If you don't understand something, don't be ashamed.
Communicate your problems with your manager.
Take care of your health! That's the most important thing I can say!
Research the company you will be working for and understand that a 50% recommendation is bad.
Understand that many people in a company use MS Excel.
Understand that bureaucracy is an essential part of the job.
You will attend many meetings, so you will learn how to communicate and understand the tools the company offers for communication (Skype, Teams, Zoom, etc.).
IT department is generally slow, learn to be patient.
learn Git.
Understand Scrum.
Learn Confluence.
Learn how to create batch files to make your work easier.
Learn Bitbucket.
Understand tickets.
Your colleagues are not like your friends or family.
Study the organization chart of the company.
Create a code journal.
Document important events.
Take out legal protection insurance.

You did great for doing all of the above!

Sincerely

Me
"

Collapse
 
calogeroguagenti profile image
Calogero Guagenti • Edited

Very important:

  • Workout 30 minutes every day
  • Drink enough water
  • Don't be afraid to ask questions ("There are no stupid questions")
  • Listen to others but think with your mind
  • Read articles related to what you are working on at the moment. Every day!
  • Work Smarter not Harder. Don't code 14 hours in a row!
  • Share your knowledge without expecting anything in return.
  • Make mistakes
  • Be honest with yourself

Important:

  • Plan then code
  • Do not overcomplicate a simple task
  • Reuse existing code
  • Make it work then optimize
  • Write self explanatory code
  • Don't use beta things in production
  • Use Cache, but with care
  • Document the code
  • Estimate !== Deadline
Collapse
 
freeo profile image
Asa Jay

Estimate !== Deadline can't be stressed enough!

Awful to see what an estimate which you state yourself to others does to your psyche.

Collapse
 
kansoldev profile image
Yahaya Oyinkansola

I love your tips, but the problem is not coding for 14 hours, the thing is what did you achieve in that time

As they say, it's not the hours you put in, it's what you put in the hours.

Collapse
 
star_trooper profile image
Atharva Shirdhankar

I'm still junior dev so I don't have much productivity tips to give.
But I have to share something is that as a junior dev

  1. starting sharing knowledge with others in form of article/short explanatory video in other words "learning and building in public" .
    If you are sharing knowledge in form of article it will help others definitely but it will also make Documentation/writing skills of ourselves better.

  2. Try doing open source contribution.
    It will help you get experience by working on real world and widely used software/project. And even help you to learn huge codebase.

  3. And yes important thing
    soft skills >> technical skills
    Now a days developer jobs are moving remote so it becomes important having better collaboration and teamwork skills. Public speaking adds advantage .

  4. And one more important thing don't just go on drinking coffee to code for a long time instead drink more water that too helps.

  5. And as a junior dev use Twitter you will definitely learn a lot from professional devs through there tweets/threads and twitter spaces.

Collapse
 
prachiag profile image
PrachiAG

I don't use twitter but can you suggest some professionals which you think I can learn from?

Collapse
 
star_trooper profile image
Atharva Shirdhankar

There are so many.
Few of them are here on Devto too.

Start with Twitter and select the topics related to tech you will find many amazing professional.

There is whole big community of tech on twitter called as TechTwitter.

Collapse
 
Sloan, the sloth mascot
Comment deleted
Collapse
 
darkwiiplayer profile image
π’ŽWii πŸ³οΈβ€βš§οΈ

I don't know if I would call that a "productivity tip", but even then, saying of your own content that it "inspires everyone in the world" does come across as rather arrogant. Almost 3 million views is no small number, but hardly even close to "everyone in the world".

Collapse
 
thisjustin profile image
Info Comment hidden by post author - thread only accessible via permalink
This Justin

"I shared my story and it inspires everyone in the world to this day."
🀣🀣🀣

Collapse
 
darkwiiplayer profile image
π’ŽWii πŸ³οΈβ€βš§οΈ
  • Be lazy about writing code, not about planning
  • Automate yourself above all else
  • Only consider the far end of the productivity curve
  • Refactor all the time
Collapse
 
raphael_jambalos profile image
Raphael Jambalos

the first point hits real hard! so true tho!!

Collapse
 
raulmarindev profile image
RaΓΊl MarΓ­n • Edited

Please, could you elaborate a bit the second and third points? I believe I understand the second point but not the third one and I think I could be missing something helpful. Thank you!

Collapse
 
darkwiiplayer profile image
π’ŽWii πŸ³οΈβ€βš§οΈ

Automate yourself above all else

By this I mostly mean 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 in a weekly average.

Only consider the far end of the productivity curve

As in, 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.

Thread Thread
 
raulmarindev profile image
RaΓΊl MarΓ­n

Thank you! Very helpful information

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
 
sudarshansb143 profile image
sudarshan
  • Use standing desk and invest in the ergonomic Chair
  • Listen before you speak
  • Put proper comments (wherever necessary)
  • don' be emotional with you code, It is only a piece of letter
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
 
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
 
ihorklymenok profile image
Ihor Klymenok
  • Prioritize first
    Usually impact that you create is really important. Hours spent is not the target of the work. Prioritize in order to get rid of unimportant tasks.

  • Understand the domain
    Sometimes it helps you to propose much simpler solution and save your time and project costs.

  • Divide tasks to smart and dump
    Don't take a lot of smart/complex tasks in short period of time. Your mind fuel is not so big :)
    Instead, combine them with routine stupid tasks, where you can wear your headphones and do the job.

  • Find your velocity
    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 pressure that company trying to put on you.
    For example if you know that you will complete task in 3 hours, you can estimate it in 4 hours and have some space to think and slow down.

Collapse
 
ama profile image
Adrian Matei • Edited

My 20 sats in the following points:

  1. Write readable and not complicated/fancy code - you'll thank yourself later
  2. Don't just copy paste code snippets from stackoverflow - try to understand what is going on - use a snippet manager to save the useful ones, so you don't have to do "deep" searches on google again
  3. Read the docs first, then look for other blog entries to solve a problem
  4. Read the source code if the project is open source and the docs are not enough
  5. don't sell yourself cheap
  6. hands on projects / side projects are the best way to learn a technology
  7. stop wasting time - I took this matter in my own hands and developed a tool to manage my dev bookmarks and snippets to retrieve them fast and easy - Codever
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.

Collapse
 
adevdes profile image
Anam.DevDes

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 over confidence in my abilities, availablity 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

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
 
irveloper profile image
Irving Caamal
  • Dont' Rush, instead of that enjoy the process of learning new things.

  • Try to learn different things at the same time (like in the school) don't overwhelm your self with same topics for long periods of time.

Collapse
 
mrdanishsaleem profile image
Danish Saleem

Basic lessons I've learned throughout my learning process as dev

  • Plan the logic
  • Syntax is game
  • Practice
  • Meditation
  • Revise
  • Debug
Collapse
 
danwalsh profile image
Dan Walsh

"Anything worth doing is worth doing badly." β€” G. K. Chesterton

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.

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
 
thisisraj profile image
Rajkumar Thangavel • Edited

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, Not exactly a programming language. For example, like cloud service (AWS), softwares, softwares as a web-services kind of things. 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 not reading the documentation you could be reading unreliable sources. you could be reading from old sources. If the documentation 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 tutorial or playlist. But also have an eye on what the official documentation says. "Happy Learning"

Source : linkedin.com/feed/update/urn:li:ac...

Collapse
 
taijidude profile image
taijidude • Edited
Collapse
 
msamgan profile image
Mohammed Samgan Khan

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

Collapse
 
paulnthompson84 profile image
Paul Thompson

If you're blocked, ask for help

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
 
mmrahmad profile image
MMR Ahmad

Yes please. This is important for me...

Collapse
 
athifbinu profile image
Info Comment hidden by post author - thread only accessible via permalink
Athif binu

Tanges

Collapse
 
mikecarrascomx profile image
Miguel Carrasco

Only do it.

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