Learn to prioritize, and value your time. You're not going to get much more done by working an extra 5 hours. Doing the same thing over and over again without getting tired is what computers are good at, humans have other skills.<p>So given limited time, you want to make sure you're spending it in way that produces the most:<p>1. Are you working on something actually worthwhile? This is a very personal decision, about your own values. More here: <a href="https://codewithoutrules.com/2017/08/07/do-something-useful/" rel="nofollow">https://codewithoutrules.com/2017/08/07/do-something-useful/</a><p>2. Are you solving the right problem, or just a symptom?<p>3. Are you solving the problem the best way?<p>4. Are you doing repetitive work that can be automated, as sheraz notes?<p>In the end you can't scale yourself beyond a certain point, but you can increase your impact by focusing on the really important things. More here: <a href="https://codewithoutrules.com/2016/08/25/the-01x-programmer/" rel="nofollow">https://codewithoutrules.com/2016/08/25/the-01x-programmer/</a>
Automation, templating, and and knowing when to ask for help.<p>1. Automation
I automate provision environments, deployments, tests, and the command line. Pretty much whatever I can in a reasonable amount of time.<p>2. Templating
I have a few project templates that already have the above automations scoped out. My ci/cd script, a makefile with common tasks, dockerfile skeleton, sensible playbooks. This lives in a skeleton git repo and cookiecutter.<p>3. Asking for help
I'm active on stackoverflow ,various slack communities and mailing lists. This is critical in moving my work along at a healthy clip. There is a lot to be said for figuring it out on your own, but I'm more concerned with delivering value than being academic or pedantic about my implementation.<p>These are the skills and behaviors I try to hire for and the ones I try to have for myself.
Learning to document well. I've written runbooks for tasks that would involve me reading through the code for a day and brought the time involved down to 5 minutes (and that can be handed to junior engineers or new hires). I've also seen really great documentation written by a senior engineer that cut days off of tasks, long after that engineer had left.