DEV Community

Cover image for How to Improve Your Development Experience

How to Improve Your Development Experience

Nick Karnik on September 22, 2018

To become a faster developer, you need to think beyond coding speed. You need to improve not only your core skills but also the physical environmen...
Collapse
 
codemouse92 profile image
Jason C. McDonald • Edited

Absolutely! Great post, Nick.

I'm quite blessed to have all of the above: a high back chair, solid oak desk, decently speedy laptop, CODE keyboard, and a lovely monitor which I attach to the laptop when I'm working at the desk. Oh yes, and my whiteboards and stockpile of notebooks, which I love.

I might add a few other things I suggest:

  • Decent headphones! Whether you listen to music or ambient noise, it's nice to be able to block out distractions. Personally, I adore my JVC HA-NC250 headphones. Superb sound quality, detectable cord, collapsible, and you can switch noise-cancelling on and off.

  • An operating system tailored to your workflow and preferences. Personally, I use Ubuntu 18.04, and do recommend Linux in general for programming. However, if you like Windows or Mac, just take the extra time to set it up exactly how you like it.

  • A TI-89 calculator, for cross-checking my math without having to switch windows. (Also, it's a fun, hackable device.)

  • A decent collection of programming reference books. Yeah, sure, the internet is amazing, but nothing quite beats the convenience of a well-chosen language handbook or code recipe book. eBooks are wonderful - I've got several dozen - but don't underestimate the usefulness of a paper book, especially when your screens are already full.

  • Pens, pencils, and whiteboard markers you can love. Seriously, you'll be spending enough time writing by hand that these are essential. I'm quite loyal to Pilot G2 0.38 mm pens, and Staedtler Norica pencils - I have literally never had one of the latter break on me, and the erasers are tops.

  • Sticky notes. 'Nuff said.


Back in the days, it was probably acceptable to use a text editor, but it is definitely not productive now.

I've got three I usually use: PyCharm (for Python), IntelliJ IDEA (for Java), and VSCode (for C++ and everything else). I'm reasonably comfortable with all of them.

However, depending on what you're building and what tools you know, a text editor and command line may well be faster! For me, I'm sometimes faster in C++ with command-line compile and debug than I am with an IDE.

In short, don't get so reliant on an IDE that you never learn the command-line tools. Good coders can work effectively without the fancy IDE tools (autocomplete, inline code linting, button-based debuggers). That doesn't mean there's anything wrong with an IDE - generally, they're just the most efficient tool - but you should never be blindly reliant.

By this point, I can write a decent chunk of C++ or Python in a text editor, and often have it run on the first or second shot. (Trying to get to 'works first time' altogether.) That sort of attention to detail means that, when I am working in an IDE, I'm considerably faster than those who are IDE-reliant.

Collapse
 
alainvanhout profile image
Alain Van Hout • Edited

Good coders can work effectively without the fancy IDE tools (autocomplete, inline code linting, button-based debuggers.

I have to take issue with that, because I'd consider any team member that write their (Java) code in a plain text editor to be a time waster. That does include them not leveraging an IDE for code writing, but more than that it includes the whole team's time when the bugs start rolling after a manual refactor.

(Only with that though, the rest is spot-on 😁 )

Collapse
 
codemouse92 profile image
Jason C. McDonald

And I'd counter that bugs from a manual refactor are largely because they never learned to work without the IDE holding their hand.

Go back in time a couple of decades, and we used to write very clean code. In binary. On punchcards. That worked surprisingly well on relatively few iterations.

Similarly, COBOL, C, and FORTRAN didn't have fancy IDEs back in the day, and yet we have a sizeable production code still running in those languages, some 10-20 years later. (We ran space missions on code written without an IDE, fer cryin' out loud.)

Now, that does not mean we shouldn't be using an IDE in writing mission-critical code, if we have it available to us. It's a superb safety net, and not using it would indeed be a waste of time.

However, my point is that, if a coder is unable to write good code in a plain text editor, that's certainly a skill they need to build (preferably on non-prod code!) If someone can write clean code in an editor, they can write clean*er* code in an IDE.

Conversely, the person who is unable to write clean code in a text editor will have far more bugs, and waste far more time fixing errors, in the IDE.

Put that yet another way, if you're hopelessly lost building a birdhouse with a handsaw and a screwdriver, power tools will only help you make a mess quicker.

Thread Thread
 
alainvanhout profile image
Alain Van Hout

I do see your point, but I don't consider writing without an IDE to a (useful) skill, anymore that I'd consider writing bytecode a skill (unless you have a very specific use-case that requires it). People were/are indeed able to write bytecode manually, but the expectations with regard to the productivity of an individual person were not then what they are now (that's in fact a reason why we have programming languages, libraries, frameworks, etc).

As to the carpenter analogy, my being able to quickly and accurately saw using an electric saw bench isn't affected at all by my not being able to produce similar quality with a manual handsaw and my leg to prop things up on ;-).

Thread Thread
 
codemouse92 profile image
Jason C. McDonald • Edited

Heavens, if you're using your leg to prop things up on, put down the tools and take up something safe. Like, maybe knitting. ;-)

Joking aside, if one cannot properly use measuring tools and a vice to saw manually, they will also have trouble using a modern electric saw bench. That doesn't nullify the usefulness of the modern electric saw bench, mind you. It's just that the benefit of the manual method is that you really learn how to measure, sight, and position - the same skills you need with the power tools, which aid but don't replace the need for ability - and you can't screw it up quite so quickly. Besides that, there may well come a time that you don't have your fancy laser-sight electric saw bench, but you have a vice and band saw. What do you do then?

The IDE issue isn't even remotely dissimilar. If you just become reliant on always autocompleting, and using lint warnings in place of your own good eyes and brains, you are now totally reliant on the machine to do the thinking. You get to the point that you don't know why half the syntax is there, which makes logic checking and debugging that much harder. If you don't know your own code, how is anyone else going to fare?

IDEs are useful for inserting what you already know should be there, but too often, coders use them to insert what the IDE thinks should be there, without actually knowing it belongs. You can always spot an IDE-reliant coder because, if you ask them to write something simple in a text editor in that language, they freeze. They can't even remember how the main function is supposed to be structured! It's a dangerous and shameful position for any programmer to be in, to not know the what and why of their own code. They're the ones who write the most and nastiest bugs.

Secondly, you may not always have your IDE handy when you are called upon to fix an urgent issue. Imagine your build has fundamentally broken, and the chain of responsibility means that you need to do something about it right now. You don't have the luxury of installing IntelliJ IDEA on your Uncle Steve's desktop; you need to bring up a private browsing tab (so your creds don't get stored), log into GitHub, and fix the fundamentally broken function that somehow got pushed to live prod. (Yes, this is a rare situation, but I've had this happen to me two or three times in my career). If you're IDE-reliant, you're entirely useless in this case. But if you know how to write the code without the IDE, you are capable of editing straight in GitHub, fixing the problem in less than ten minutes in one shot, and mitigating major disaster or inconvenience.

It's really easy to say "working with the manual tools isn't useful anymore," but as someone who has trained interns for almost eight years, I can assure you that it makes a profound difference, even with the odd case above aside:

  1. The coders who can work without an IDE can solve a problem with an IDE in easily half the time as one who is IDE-reliant. You're welcome to test this out (controlling for such factors as raw language familiarity and IDE familiarity). I know it's been proven time and again with my team.

  2. The coders who can work without an IDE write cleaner code in general, and their IDE-written code is still cleaner than that of their IDE-reliant peers.

Like I said, my first iteration is always fairly clean, and my second iteration nearly always runs as expected (barring exceptionally complicated algorithms). That's true without an IDE, having summarily and deliberately ignored autocomplete and Intellisense for nearly a decade in any language I was learning. Now that I (equally deliberately) use Intellisense in C++ and Python, I can clatter out a fairly complex, clean class faster than many coders I know, and the linters seldom find anything to whine about with it.

So, while one may not need to work without an IDE in production code very often, if ever, in real life, the skills gained from the ability make one's use of the IDE far more effective.

By the way, the expectations as to productivity "back in the day" were a lot stricter than now. One of my devs and best friends was a gentleman who worked in COBOL, FORTRAN, and bytecode on embedded systems for the US Army. (This guy actually met Rear Admiral Grace Hopper once, around that time, for context.) If we had to do half of what he and his crew did in one week at our jobs, we'd probably lose our minds.

Thread Thread
 
codemouse92 profile image
Jason C. McDonald

Irrelevant historical context, my buddy got one of R.A. Grace Hopper's nanoseconds when he met her, too. ;)

Thread Thread
 
alainvanhout profile image
Alain Van Hout

I do agree that there would be some generic benefit (i.e. all other things being equal), just not that it'll make an actual difference in how productive or reliable someone is at their job (and I've had enough encounters where considerable time and effort was wasted because someone thought they were so awesome that they coded better without an IDE).

So though I really enjoy the discussion, I think we'll have to agree to disagree on this one :).

 
codemouse92 profile image
Jason C. McDonald

FYI, I just turned this convo into an article.

Thread Thread
 
theoutlander profile image
Nick Karnik

That video is bloody AMAZING! Thanks for posting.

Collapse
 
theoutlander profile image
Nick Karnik

I agree with both of you. I think there's a certain skill that you build with coding in text editors as well as learn to appreciate IDE's. I think everyone should start out writing code in text editors. However, they must work with IDE's once they familiarize themselves. I don't think that's plausible nowadays because everyone is so much into instant gratification. Although, I might be old-school. :o

Collapse
 
theoutlander profile image
Nick Karnik

Thanks, @codemouse92 !

Also, thanks for all the suggestions. I tried to keep the article short and sort of left out some of these important things, so really appreciate it.

I have the CODE keyboard as well and have a hard time deciding between the two. I've been using my Macbook Pro's tactile keyboard, which has been replaced about 5 times now and again a few keys have popped out :|. I use the other keyboards with Windows mostly. Even when I configure the CODE keyboard to the Mac keyboard format, I find it weird to use with a Mac, so I'm thinking of getting the Mac keyboard (although, I have been contemplating for a while now because of the mediocre reviews).

As for notebooks, I contemplated a lot about Moleskin, but ended up trying and really loving the Bienfang Sketchbook. I love the 5.5" book as I can easily carry it around and it forces me to keep my notes concise.

I agree about headphones as well. I've invested in a couple of them over the years. Myt first major purchase was the older wired version 25 of the Bose QuietComfort 35 wireless hedphones II and then I upgraded to Bose SoundLink around-ear wireless hedphones II. I really love the wireless headphones for teaching and conferences. I'm looking forward to getting the new Quietcomfort 35 with noise-cancellation.

Agree with the OS. In the past, I've had to bounce a lot between various Operating Systems and always struggled with customizing them. Now, I'm so used to the Mac that even after using Windows for 25 years, I find it hard to go back to Windows.

Really love the idea of a TI-89 calculuator! I might consider getting one of those.

I don't find myself using programming reference books. However, I still own a lot of them. There are some that I love reading more than the others like Peter Norton's Assembly Language Book for the IBM PC.

Man, I love the Pilot G2 as well! Although, late last year I splurged and bought a nice Pilot Pen (something I've always adored growing up). I've used a pencil once in the last 4 years while designing a level for a serious game.

Haha, sticky notes are always good. However, I end up with such a mess and they never stay stuck to the monitors. I use Evernote a lot and the notes/sticky apps on the Mac.

That reminds me of the high-speed scanner that I bought. I ABSOLUTELY LOVE IT! It's the Evernote Edition of the Fujitsu ScanSnap iX500

Collapse
 
ben profile image
Ben Halpern

Very motivating post. I’m going to try and go the extra mile with my setup.

10–20 hours a day coding

Though I hope I never find myself coding 20 hours a day 😳

Collapse
 
danielsarmiento profile image
Daniel

I hope he meant a week.

Collapse
 
theoutlander profile image
Nick Karnik

20-hour weeks is about how much I try to work nowadays 😆.

Collapse
 
theoutlander profile image
Nick Karnik

A bit exaggerated I guess :D. 🙉 🙊🙈

Although I must admit that I've had my fair share of several 20-hour marathons back to back! A result of moonlighting on ~14 startups over the years 😱.

Collapse
 
phallstrom profile image
Philip Hallstrom

If you want a giant white board without breaking the bank, run down to HomeDepot/Lowes and look for something called "shower wall" (can't recall the exact name). 4x8 sheet of thin material used in shower walls. The surface works fantastic as a white board. Costs about $20.

Collapse
 
erebos-manannan profile image
Erebos Manannán

One thing that seems to be missing is spending time looking into new tools and ways of working that make you more efficient. E.g. instead of manually managing servers, everyone should nowadays use either configuration management tools (such as Salt Stack, or Ansible), or Kubernetes + Docker, or any other such highly automated environments.

If you end up with managing servers with configuration management tools, don't forget to use Vagrant for your development environment. For Kubernetes, check out minikube.

A comfortable environment

If possible I highly recommend an adjustable height table, and using it in the standing position regularly. It's better for your energy levels, and health.

Also switch that office chair to a gym ball, or any other such off-balance chair.

You need to get familiar with hot-keys / keyboard shortcuts. These are a huge time-saver.

There's a limit to this. Know a few of the most common things you do, otherwise just learn how to find the rest via the menus or something. You can easily spend more time learning shortcuts, than using them.

Every piece of code that you write, needs to be re-usable.

That sounds like you're wasting time where it doesn't need to be wasted, which sounds odd for a post that is focused on efficiency/speed.

Not everything needs to be reusable, and not everything should be written with the possibility that it might be reusable. If it doesn't seem like it's likely it will be reusable, you often shouldn't waste time on making it reusable.

Collapse
 
theoutlander profile image
Nick Karnik

Thanks for these great suggestions. I agree with your sentiment on writing reusable code. I was in two minds when I wrote that. I usually write code in a modular and reusable fashion without much effort. However, we definitely need to draw a line.

Collapse
 
erebos-manannan profile image
Erebos Manannán

Oh and I forgot to mention: stop drinking coffee.

One of the clearest efficiency killers I see every day is people riding the caffeine wave, trying to wake up, or crashing. Stop abusing caffeine and you won't have either of the issues.

Collapse
 
sandris profile image
sandris-

I would add that mouse is important, and it is worth considering ergonomic mouse with trackball.

Collapse
 
ccleary00 profile image
Corey Cleary

Agreed, I switched to an ergonomic mouse and keyboard a year or two ago and it made a huge difference. I use this one: Microsoft Sculpt

Collapse
 
theoutlander profile image
Nick Karnik

That looks cool. I used the Microsoft Ergonomic keyboard in the past until one day I decided to open it up to clean and could never put it back like new again 😱!

Have you seen the Ultimate Hacking Keyboard?

Thread Thread
 
ccleary00 profile image
Corey Cleary

I've seen a lot of keyboards that are "split" like that but not that one exactly with the different modules you can add in - pretty cool idea

Collapse
 
sandris profile image
sandris-

well, I used it for like three years and then palm started to hurt :| switched to Logi MX Ergo and it helped.

Collapse
 
theoutlander profile image
Nick Karnik

Indeed. I've tried so many over the years, but I really love the trackpad on the macbook pro. I'm thinking of replacing the mouse with an independent trackpad unit. A regular mouse is definitely bad for the posture and wrist in the long run.

Collapse
 
antonfrattaroli profile image
Anton Frattaroli

I always got annoyed if I didn't have my setup, and was coding out of the office, and have, over the years, eliminated any non-portable development dependencies. Just a laptop and a plug and I'm good. That way I can work in conference rooms, coffee shops, living room, bedroom, car, deskless. Phone has a wifi hotspot.

Collapse
 
theoutlander profile image
Nick Karnik

When I traveled with my family for a year, I had a hard time getting used to working productively on the MacBook Pro as my setup at home. A few months into it I absolutely loved that I didn't need much. After we came back, I worked only on that macbook for the following three months before trying a similar setup as before (which made me realize why I loved it so much to begin with!).

Collapse
 
erebos-manannan profile image
Erebos Manannán

There's a difference between "dependency" and "convenience". I don't depend on my extra screens, but at my office and at home I have extra screens to boost my efficiency. I can still work at any random location because my actual dependencies are minimal.

Collapse
 
antonfrattaroli profile image
Anton Frattaroli

My primary frustration was switching between keyboards. The laptop and peripheral keyboard keys were spaced differently, and my fingers couldn't switch easily.

Less so, but still frustrating, was window management when I was used to dual monitors.

I became dependent on those pieces of hardware in order to code happily.

Collapse
 
kspeakman profile image
Kasey Speakman

Great article overall.

I love working with C++ and C#, but there has to be a good reason to choose a compiled language.

Interesting idea, although I believe that compiled vs interpreted is perhaps too fine a detail on which to base a language decision. The other points you made (tooling and community support) are excellent attributes to use in the decision process.

Collapse
 
theoutlander profile image
Nick Karnik

You are right about that. I was thinking in terms of ease of use, versatility, and productivity. Although C# is very easy to use, the NuGet package manager is a nightmare.

Collapse
 
rdewolff profile image
Rom

Nice screen setup! Thanks for sharing!

Collapse
 
carlosaabud profile image
Carlos

Great post man. I concur with all of these

Collapse
 
almokhtar profile image
almokhtar bekkour

Awesome that was so helpful , thank you

Collapse
 
bloggersneed profile image
Abdullah Prem

Absolutely one of the great post and i have the chair you have mentioned, and you missed one tool, A coffee mug with hot coffee inside lol, joking.

Collapse
 
theoutlander profile image
Nick Karnik

Thanks, @bloggersneed !

Haha, a good coffee mug is a must!

Collapse
 
mikaleb profile image
Mikaleb

$1000+a chair, it's not for everyone's pocket x)