*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...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
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.Well said bud!
Have a wonderful way up to the top, you are already on the right track!
Cheers, peace and love!
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.
Hope it helps! :)
Hey Jane, Nice tips!.
Regarding the journaling part, recently i also started using Notion, Please share the notion template structure if you can.
Thanks, Pradeep!
Sure! You should be able to dublicate it to your account: painted-teller-bf3.notion.site/Hab...
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
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.
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
Haha. Happens to all of us.
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
"
Very important:
Important:
Estimate !== Deadline can't be stressed enough!
Awful to see what an estimate which you state yourself to others does to your psyche.
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.
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
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.
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.
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 .
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.
And as a junior dev use Twitter you will definitely learn a lot from professional devs through there tweets/threads and twitter spaces.
I don't use twitter but can you suggest some professionals which you think I can learn from?
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.
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".
"I shared my story and it inspires everyone in the world to this day."
π€£π€£π€£
the first point hits real hard! so true tho!!
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!
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.
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.
Thank you! Very helpful information
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?
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.
Along with the correct set of tools, setting up the right mindset is essential to being productive.
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.
My 20 sats in the following points:
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.
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
Here are some tips I've learned over the years:
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.
Basic lessons I've learned throughout my learning process as dev
"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.
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.
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...
dev.to/taijidude/productivity-tips...
search more, write less....
but make sure that, you know what you are doing...
If you're blocked, ask for help
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
Yes please. This is important for me...
Tanges
Only do it.