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.
Hashnode is a friendly and inclusive dev community.
Come jump on the bandwagon!
💬 Ask programming questions without being judged
🧠 Stay in the loop and grow your knowledge
🍕 More than 500K developers share programming wisdom here
❤️ Support the growing dev community!
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.