What are some productivity hacks for developers?
Productivity and efficiency requires a number of factors for any given profession. From physical/health, psychological, emotional and a few more. What do you think developers need to set right for optimum results?
Some of these depend on the person / situation but here goes.
- Music or some other way to drown out ambient noise, invest in headphones, you'll be wearing them a lot and maybe for extended periods and they need to be comfy
- Make sure you know your tools (IDE, Debuggers, etc) and are comfortable with them. It helps a bunch when you at least know what you're doing there.
- Techniques that let you manage your own time (Pomodoro for example) are great in making sure you don't burn out on an issue or solutions you're trying to tackle.
- Always keep in mind that people smarter then yourself have gotten stuck on easier things then you're currently on. ;)
- When in doubt, ask other people, discuss, talk.
- Make sure you have a good chair / desk, I prefer to have the option to switch between standing / sitting for example.
- Get away from your desk, walk, stretch, get sunshine.
- Make sure you have a good keyboard.
- Try to let go of your mouse as much as possible it might be personal preference or your IDE that lets you use it a bunch but trust me, after 10+ years of working as a Full time Developer you WILL feel pains in your wrists eventually.
- Exercise outside of work.. when you're sitting for extended periods of time or even alternating between sitting you're still doing something we humans are not meant to do.
- Make sure you are hydrated.
Ketosis is an epic way, too. I have been doing it for nearly a year and my energy management is so easy now. Without the ups and downs of being hungry and eating then crashing... you can stay sustained for a nice amount of time in the morning through to early afternoon, get loads done and finish early.
Here are some simple tips for developers who wants to be productive:
- Don't think always about code, issue or problem. Only think when you're actually coding.
- While you're coding and face some problems or issues, don't deep dive at that time. Take a little break and come back to seat. Let's see how effectively you'll solve the problem.
- Make a schedule for extra activities like watching youtube, or any social media. If you keep doing such activity at an interval of time, then you'll loss your productivity. For eg. 1 hour at first hour of coding and half an hour of second half of coding.
- When you start coding, don't think or open any social media. Go deeply with your coding.
- Read code specific blog only if you're stuck with something that is relevant. Take 15 minutes of your time to know about such new thing that introduced while you were coding. And then take a 5 minutes break after reading. Just look around here and there.
- Do not hurry about your breakfast while you're working with some specific problem that might be finished after 5-15 minutes. Relax and finish your problem.
- At the off time (eg. when you at home), watch youtube channel that you're interested in.
- Take at least 8 hours of sleep. This will keep you fresh and will not ruin your work.
Know when to stop. Our brains, like any other muscles and body parts are subject to overuse and exhaustion. I found myself too many times being unproductive because I had gone for long periods of non-stop coding (and/or designing)...and honestly this is where bugs occur, where you make stupid mistakes, syntax typos and even worst. After a couple of hours stop, take a walk, go to the gym (this is what I do), do something else but reading or working on code.
Also, use the right tools, autocompletion saves hours of coding (and also stupid typos), git/versioning saves you from madness and going back in time when needed...and personally my tool of choice is VSCode which is constantly growing with dozens of tools that WILL make you more efficient with your time and code.
There are already a lot of great answers (all the points from Marius van Zundert are straight to the point), but there's one thing I'm surprised I haven't read: distractions. When you want/need to be productive, you need to be able to focus. Ambient noise is part of the problem (especially in open-space offices -_- ), but over the last years, I noticed many developers don't help themselves. Your phone is one of our worst enemies when it comes to being able to focus. Try some of these (depending on your own discipline and habits):
- block (almost all?) notifications when the phone is locked. My phone only vibrates (it's always in silent mode) for emergency-like calls. All the noisy notifications are only displayed when I manually unlock the phone (emails, twitters, slacks, ...) If you are on-call, Pagerduty is an obvious exception, but you get my point
- try to put your phone far from you (not in your pocket, not on your desk) and in silent mode. That'S another way to avoid the notification to break your focus
Try one of these simple rules and you should see a dramatic boost on your productivity, if you were guilty - like so many of us - of being distracted by notifications.
(on a similar note, I turn desktop notifications for emails or Slack only for important channels. Then I check the unread stuff from time to time, multiple times a day, so that I am not interrupted, but people don't have to wait for too long to get an answer)
Well Anayo, I believe music is in a category of its own. It's very related to ambient noise, but will vary a lot depending on the kind of music and your own personality. When I work in open-spaces, I find myself barely able to focus without music, because it's a good way to cut that ambient noise. But I am very picky about which music I listen to when I'm in work/focus timespans. And I am very easily distracted by humans voices. People talking in other rooms can get me out of focus (you can imagine how much I think open space offices are an aberration). So I need some music to be able to focus, but I do take great care: no lyrics ever, not too quiet nor not too energic to just be good at that ambient-noise-shutter role. People which are distracted by music could use noise/drone sound generators though, to achieve the same effect (but I find it very boring and even tiring after a few hours... but that's just personal taste) This has already been shared in other thread, but over the time I gathered a few playlists, 2 of them are public, whenever I need to focus at work. Obviously, everyone's experience is different, but it could help getting started. (And I like to have those playlist, so that as soon as some noise/distraction shows up in the office, I can just it play and not have to think or search for something to listen.... which would be switching from one distraction to another) Here's the 'quiet' playlist (soundtracks, cello, compositional ambient, drone, minimal music...) more than 68 hours as of today with more than 900 titles, playing it random should do the job) open.spotify.com/user/sebportebois/playlist.. And here's my jazz-at-work one, more energic, obviously more subject to personal taste (but when there's more ambient noise, it does a better job at shutting down these external distractions) open.spotify.com/user/sebportebois/playlist..
And when there's really too much noise, I sometimes switch to Meshuggah (yes, I'm able to work with this, and it even sometimes help me focus and remove all the anger after hearing too much stupid things from CEOs ;D ... but it's exhausting music and I'm not able to listen to that for too long =)
Sébastien Portebois Has explained it about as well as I could have, when I said "music" I didn't mean any kind of music (although that's certainly it's own thing) But mostly when coding I tend to listen to either Music without Lyrics (soundtracks, cello, compositional ambient, drone, minimal music... etc indeed) or in a language I don't understand.
- Understand the conditions that get you into the zone; and maximise the opportunity for those conditions to occur. eg. most devs I know need to organise their week to ensure they have big chunks of meeting-free time. Most need quiet and/or the right music. etc
- Understand the law of diminishing returns: very long hours don't work. There's a point where you are just writing absolute junk that you'll just have to refactor tomorrow.
- Time box debugging. If you've been staring at the same problem for two hours, go for a walk outside for a few minutes. If you've been staring at the same problem for a whole day, talk it through with a team mate.
- Make sure you understand why you're building something, not just the blunt what. Know what the company's strategy is, know what your team goals are, then you'll understand where your contribution fits in.
- Invest in ergonomics. Get a great chair, ergonomic keyboard, etc... whatever works for you.
- Have at least one non-coding hobby.
- Do some kind of exercise.
- When you take holidays, take holidays. No work email or chat, take a break from coding, let yourself decompress. Otherwise you're just spending your leave days for no reason and won't be fresh and ready when you officially go back.
People often neglect their hardware choices for the stuff that REALLY matters -- rrrz gamin blinkenlights nnn rrz lick-id coolin' being pointless bling.
Whereas your keyboard, mouse, and monitor are what you are going to spend 99%+ of your time interacting with.
When it comes to pointing devices, I HIGHLY recommend that for long term use to get a thumb-based trackball like the Logitech M570 -- though the older white Logitech TrackMan Marble's are in fact more ergonomically sound, the newer models do bring better accuracy and wireless to the table. The reason I recommend these is that it immobilizes the wrist and takes less desktop space, resulting in less arm strain. Almost all long term arm discomfort caused by a mouse is eliminated once you restrict the only part that has to move being your thumb!
On the subject of keyboards, GET A MECHANICAL WITH TACTILE FEEDBACK! Doesn't matter if it's clicky or non-clicky (though I favor the former) but the ability to 'feel' through the switches that YES, the keypress was registered can greatly speed up your typing... more so once you get a feel for the fact that the switches register the keypress before you bottom them out. Depressing the keys the whole way can in fact add to finger strain so a longer keystroke that you do not have to depress the full travel distance is a good idea. PERSONALLY I like very strong springs as it helps build up finger strength and reaction times -- for a LONG time I was a "IBM Model M or GTFO" kind of guy, but I recently picked up a keyboard with Cherry MX Green switches in it and it's a usable substitute. Mind you, a lot of limp-fingered pansies piss and moan that Cherry Greens are "too hard" to press... whereas for me with the oven mitts masquerading as hands the Greens are a little soft, and the blues are mushy crap. YMMV. If you're shlepping around on a rubber dome keyboard, you are likely hampering your productivity.
My workstation runs three displays of varying qualities too for good reason. Not all displays output the same colour gamut, so when designing it often helps to check what a cheap display, quality display, and IPS all do -- hence my left display being a cheap 24" 1920x1200 Envision, the right display being a decent quality 24" 1920x1200 Samsung, and my center display is a 27" 2560x1440 IPS. It's good to check your colour choices since what looks like beautiful shades of tan can often come out as hideous striped purple on cheap displays.
When it comes to monitors, I recommend that you do NOT go ape for the 4k style nonsense and instead focus on size and quantity. IF you do go for higher resolution and higher PPI, make sure you increase the default font size on the system (and any apps that let you set it manually) so that you can sit at a comfortable viewing distance. I'm often horrified the way people sit hunched over their displays with their faces plastered five or six inches from the screen... that's NOT good for you and a comfortable distance should be two and a half to three feet. Honestly if with your arms outstretched you can touch the display, you're probably too close from an ergonomic viewpoint. (Hence why touch-screens are pretty much useless for development)
Due to said appropriate seating distance, the "improvement" in pixels per inch of 4k displays should in fact be beyond 90%+ of the populations vision compared to a 21" 1080p display. High PPI has diminishing returns on desktop sized displays at comfortable viewing distances. In that way at normal viewing distances 4k is more placebo to sell you hardware with bigger numbers than it is fact. If you're close enough the difference matters, you're probably too damned close!
Though if you have a 40"+ 4k display at two or three feet viewing distance, THEN it makes sense. At 24" or less, not so much.
In terms of the software side, I recommend AGAINST IDE's and RADS. For the most part the so called "aids" they provide are often more hindrance than help, or teach you bad habits. Autocompletion is a stunning example of this where MOST of the time you could (or should learn to be able to) just type it in the same or even less time than the autocomplete would do it -- and in the case of things like block and tag completion you'll often find yourself spending more time correcting what the editor did than it "saved you" in typing.
The same goes for the illegible acid-trip that is colour syntax highlighting. Whilst it CAN in some cases help prevent errors like missing out on closing strings and comments, more often than not it causes code-blindness and eye-strain. IF you use it set the colours to as high a contrast with the background as possible so that legibility is not compromised -- SO many of the default schemes used by editors (and websites) are so far from accessibility minimums, that you're just BEGGING to give yourself headaches and nausea from it. ALSO probably part of why many developers seem to damned near press their schnoz against the display.
You're programming, you want to do it right you're going to have to type.
IDE's also tend to waste screen space on 'management tools' and 'sidebars' and all sorts of other crap that could just be better used to show and edit the bloody damned code.
There's an over-reliance on tools and off the shelf answers, and the industry -- and productivity -- suffers as a result. It's part of why I do NOT generally advocate the use of "frameworks" -- particularly on the front end -- as whilst they sell you on the concept using words like "easier" or "simpler" or "makes you more productive" in practice it's all marketing double-talk lies by people unqualified to write a single line of code in the underlying languages. Just look at train wrecks of developer ineptitude and ignorance like Bootcrap or w3.css
In that same way whilst finding an editor you are comfortable with is important, you shouldn't be completely tied to it. That's where IDE's and RAD's can really fail you as you become so reliant on that tool, you end up screwed if you end up working in an environment where that tool is unavailable. You should be able to sit down at ANY flat text editor on any platform and at least be somewhat proficient in whatever language you're working in. Again, over-reliance on specific tools is a recipe for failure.
One BIG thing to consider is where you plant your arse. A quality chair is important but people often make mistakes in the ergonomics. You can go "too comfortable" with chairs that are extra soft and let you slouch -- all that does is cause back strain. The 'bucket' of the seat should force you into a position where you cannot slouch, but at the same time not be uncomfortable. It should also be a material that breathes so leather, pleather, vinyl and so forth are right out. Say what you want about cloth seats, but at least you won't end up stuck to them or slicking them up with sweat. Over the years I've found that mesh-backed chairs are far more comfortable over the long term as they breathe, have give to fit your shape but still maintain proper support. This is where you're going to be for hours on end, don't skimp on it!
It's often scary how often I'll see people working on development that a base model Celeron with a couple gigs of RAM would be overkill on bragging about their brightly lit high-end multi-core machine, whilst sitting on a backless stool with a cheap-ass rubber dome keyboard, a cheap-ass stock mouse, connected to a 4k display with text set so tiny I couldn't read it at any distance. Priorities people!
... and whilst they are convenient on the go, laptops are NOT desktop replacements unless you connect a REAL keyboard and REAL display to them.
Finally as others have mentioned, schedule breaks. FORCE yourself to get up and walk away periodically. Sitting there for hours on end is always diminishing returns, even if you THINK you're "in the groove" the quality of your work will suffer -- EVEN if you're unaware of it at the time. I often queue up music playlists of specified times so that when the music stops, I know it's time for a break. The music also helps to 'drown out' background noise that can interrupt your workflow.
I use this technique for productivity focus (it is called Pomodoro Technique) : I work in 10 to 20 minute intervalls with breaks of multiple minutes in between. After every break I can reevaluate what I did and where my focus should remain on (or try to get back to one specific task if I lost focus and drop surrounding thoughts/information) and I take deep breathes, close my eyes and try to relax all my muscles with complete body awareness. It works great for me, I can be very productive in a small amount of time just by being aware of my focus, myself and my body feelings.
I would say that the most essential hack you can do is related directly to your work flow. Use an environment that keeps you as far away from your mouse as possible. Using an editor like Vim or Emacs will help, but it is often about more than just your IDE. Constantly switching over to your mouse leads to fatigue...
Using your OS from the command line is the biggest help. Whatever type of development your doing, it is important that you are able to navigate file systems and your tooling fast without making a geospatial image of what your doing. I personally prefer Linux, but there is a learning curve if you're new.
Another thing is to train your focus. Try reading a book on programming (or following a difficult tutorial) and set a minimum time you want to focus on it. You'll build up your ability to stay on task which is also one of the major benefits from saying away from the mouse for most things. The important thing is that you follow through with the time you set to spend on the specific task in one sitting. Focus is what sets 99% of developers away from the top 1%, whether they have an Ivy league degree or are self taught.