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 environment, tooling and your approach to problem-solving.
If you are just starting out, don't get bogged down by the details. I have an elaborate setup because I work from home and I have been programming for over 25 years!
You will build expertise over time and fine-tune what works best for you. I am sharing what worked for me.
A comfortable environment
I cannot stress enough on how important a good sized desk is. You need enough space for your machine(s) and ample room to doodle. Make sure you can place a notepad, tablet, lamp, etc. and still have room to work comfortably.
What goes along with this is a super comfortable chair with armrests. I would highly recommend getting a headrest. If you’re going to spend 10–20 hours a day coding, you need a good chair. Even simple things matter such as how the armrest can adjust or where the neck support is placed, etc.
Find the right hardware
It is important to work on a fast development machine so you aren’t waiting too long for your code to compile or application to render. The same goes for a good keyboard, mouse, and monitor. These things can add to the fatigue. I remember when working with Java 1.0, my research project took about six months to implement and I literally spent 3 months out of those waiting for the code to compile.
A multi-monitor setup is extremely important. I use a 43″ 4K monitor as my primary monitor and two 24″ HD monitors on either side. This works perfectly for most of the complex applications. The reason is that you need enough real-estate to get a good overview of things like the code editor, debugger for services, debugger for UI, browser, email, stackoverflow/forums, dashboards, SSH sessions, Spotify, dev.to :), etc. Using a laptop is fine, but I find that I am very efficient when I see everything at once and don't have to constantly switch between windows.
Pick the right programming language
Regardless of what it is you’re working on, make sure to pick a language that has great tooling around it and community support. For example, Javascript, Python, and Ruby are common choices these days for most projects. I love working with C++ and C#, but there has to be a good reason to choose a compiled language.
Find the right tools
Back in the days, it was probably acceptable to use a text editor, but it is definitely not productive now. You need to find the right software tools. You need a very good Integrated Development Environment (IDE) since this is where you spend most of your time. You need to find something that allows you to stay within that environment. Some good choices are Visual Studio Code, Webstorm, Pycharm, etc.
Learn the core Computer Science theories & concepts
- Data Structures
- Algorithms
- Design Patterns
- Math
- Problem Solving
You can find tutorials online for all of the above on YouTube, Udemy, Coursera, Udacity, etc. You should also go beyond just learning theory. Start coding these algorithms & data structures as it will help you improve your understanding of how things work and help you learn good coding practices.
Think of ideas to work on to solve your own problems and use those to hone your skills. This is a powerful combination and it helps keep you motivated.
High-level thinking / Architecture
You need to go beyond writing code to thinking in abstract terms. Think of breaking down the problem into big boxes with lines between them on a whiteboard (or notebook). You need to think of how to solve problems on paper first. In a corporate setting, you will also end up writing software design documents. Often, these are helpful at uncovering fundamental issues in the implementation ahead of time. Building good software is all about thinking through the process and breaking the problem down into modules that can be reused.
Soft skills
It is important to learn how to communicate and also interpret what is being communicated to you. If you can understand a problem/feature request from a customer or your team and translate it into proper requirements with an incremental plan on how to modularize the solution, you will save a lot of time during actual development.
Generally, I've spent most of my time on the whiteboard thinking about solving the problem and coordinating with other members of the team. I would say that coding is probably 60% of the work. However, these days I'm working as an Independent Consultant.
In Closing
At the end of the day, you will spend time on a keyboard and in front of a monitor crafting your code. You need to get familiar with hot-keys / keyboard shortcuts. These are a huge time-saver. This is something I try to observe when I interview candidates.
In addition, you need to automate anything and everything. You are an engineer first and need to apply your skills to make your job easier. If you find that you are repeating yourself, you need to find a way to automate it. Every piece of code that you write, needs to be re-usable. You also need to write test-automation so that you reduce the likelihood of breaking your code and wasting time finding and fixing problems later on.
Familiarize yourself with the plethora of libraries, frameworks and SaaS products that simplify your life. However, build expertise in at least one of them. At the same time, be sure to spend some time understanding how various technologies work and avoid using them blindly.
Finally, before you start coding, take enough time to understand the requirements and make high-level diagrams on paper. If you can solve the problem on paper first, it is just a matter of labor after that.
If this article was helpful, ❤️ it and follow me on Twitter.
Top comments (37)
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.
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.
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 😁 )
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.
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 ;-).
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:
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.
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.
Irrelevant historical context, my buddy got one of R.A. Grace Hopper's nanoseconds when he met her, too. ;)
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 :).
FYI, I just turned this convo into an article.
The Curse of the IDE
Jason C. McDonald
That video is bloody AMAZING! Thanks for posting.
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
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
Very motivating post. I’m going to try and go the extra mile with my setup.
Though I hope I never find myself coding 20 hours a day 😳
I hope he meant a week.
20-hour weeks is about how much I try to work nowadays 😆.
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 😱.
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.
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.
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.
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.
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.
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.
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.
I would add that mouse is important, and it is worth considering ergonomic mouse with trackball.
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
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?
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
well, I used it for like three years and then palm started to hurt :| switched to Logi MX Ergo and it helped.
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.
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.
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!).
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.
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.
Great article overall.
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.
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.
Nice screen setup! Thanks for sharing!
Great post man. I concur with all of these
Awesome that was so helpful , thank you