Many programmers complain about speed when coding. For some it is a matter of typing speed for others it can be hardware or software issue and some need a better understanding of the tools they have at their disposal. 

The Absolute Basics

Starting with the absolute basics we look at simple ways to improve speed that may not seem obvious. However, many programmers will benefit in coding speed and quality with these simple improvements

  • Touch Typing
  • If you don't already learn how to touch type. Speed will greatly increase when not looking at the keyboard for which letter to type.

  • Keyboards
  • On the topic of keyboards, if your keyboard is problematic replace it. The investment in a nice keyboard is more than worth the expense. "Cheap" only saves money if you are really broke.

  • Coding Environment
  • Without getting into the debate of which IDE or editor is best using a real code editor with intellisense, word completion, and refactoring tools removes a lot of frustration and time wasted. 

  • Machine
  • One of the biggest reasons for slow coding is a machine that cannot keep up. Make sure that you have a machine that is actually fast enough. Pay attention to hard drive speed, memory, CPU, etc.

Reduce the Amount of Code

Use code completion tools and generate code with templates to cut down on the time wasted doing repetitive tasks. Convention always beets configuration. Use automated refactoring tools where possible for changes. Libraries are your friend so use them especially if someone else wrote and maintains them.

Cut Back On Errors

Plan your code before you sit down and begin typing it. Drill your typing skills for reduction of errors. Get up each day and run through a 5-10 minute drill. In line with the previous step using code completion, templates, and automated refactoring reduces errors.

Tips To Improve Your Actual Speed

  1. Learn The Shortcut Keys
  2. Your IDE or editor has shortcut keys designed to make coding faster. If you find you are repeatedly going to the menu for something learn it’s shortcut and practice using it. Post a “cheatsheet” of shortcut keys near your monitor so you can quickly glance at it. Included in the links are a couple of these one for Windows and the other for general OS functions that will work cross platform.

  3. Reduce Usage of the Mouse
  4. Try going a day without using your mouse. Not leaving the keyboard will reduce a significant amount of time during the day. With OS and IDE shortcuts it’s possible to not use the mouse at all.

  5. Avoid Context Switching
  6. Multiple monitors is a great asset to any coder. Time spent switching screens can be completely avoided by having everything you need right in front of you.

  7. Stop To Think
  8. When you realize that you are having to stop and think to get things done do so. Don’t mix the mechanics of writing with the process of design. Neither your writing nor your design will be best.

  9. Code What You Know First
  10. Start with code that you know you can get working first. Take care of the first order unknowns before tackling the second order or “unkown unknowns”. In addition this gives a dopamine boost by acomplishing a task just before starting the difficult work.

Bringing It All Together

Practice daily as mentioned above. First improve your typing speed and error rate. Then work on code katas. Finally this isn’t a test so keep cheatsheets around and use them as often as needed.

Nine commonly held yet erroneous beliefs that developers tend to have about work, employers, other departments, and more. While it is not an exhaustive list everything from interacting with others to interacting with databases, to changing specs mid project, and misunderstandings about how business works are covered.

These are the sort of critical mis-communications and non-optimal behaviors that distinguish a less experienced and less professional developer from those that have played the game a while and gotten some life experience. Being aware of these will help improve your employer’s (and fellow coworker’s) perception of you, as well as steer you away from problems that can cause you grief later.

  1. It’s not a big deal when software fails.
  2. Failure of software even a small feature of the software can lead to lost customers. Lost customers leads to lost sales. Financial disruptions to people that are counting on you and the software matter. These financial disruptions have lead to the failure of companies both large and small. Company failures have lead to people losing homes, going bankrupt, or even committing suicide. A fixable bug left unfixed can have long term consequences.

    Knight Capital Group suffered from this and lost twice the previous years net capital in 30 minutes in 2012 due to placing untested software in production. In 2003 a hospital in Michigan sent notifications so Social Security and insurance companies of the death of over 8,000 patients that were all alive and well. Even more serious during the Gulf War a software failure in the Patriot Missile System lead to the death of 28 soldiers.

    While it is not likely that you are working on a system that can cost lives if software fails the effects can still be devastating to those relying on the software to function. This doesn’t mean you should panic over bugs in software, but it does mean that you shouldn’t just let them slide either.

  3. The database will have to be switched out from under an application.
  4. This almost never happens. Most cases are partial switches and that is for performance.

    If it does happen, it’s impossible to avoid at least some rewrite of code. In their documentation Oracle suggests setting up a staging database then switching the live application to the staging database while you are making the transition.

    Use of ORMs (Object Relational Mapping) allows for abstraction of the database. However, they do not provide transparent switches of databases. Also, writing code that generically works across different databases often misses some of the best features of a particular database in favor of being generic. Performance and stability suffer from use of the lowest common denominator.

  5. Specs can’t change while coding.
  6. Uhhh… No!

    Sounds great on paper but isn’t true. Even NASA changes specifications as new information is learned.

    Where data is stored, how the UI (user interface) looks, how it communicates, and security can all change in the process of development. Developers have the idea that “we’re already coding this you can’t change the specs.” It’s painful to change and does have a cost. Discourage arbitrary changes or ones that could have been part of the planning.

    Just like NASA launches a rocket into space, you are launching an app into the regulatory environment. Complex systems like Earth’s atmosphere, the government’s regulatory environment, and the financial systems change too quickly to be static.

  7. Employers care about pedantic coding arguments.
  8. Unless it makes a quantifiable difference to the business, it probably doesn’t matter to the business owners. That is not something that is important to them, it’s not their world. It can become a problem when it is important to them but it’s not expressed in a way to convey the importance to the business.

    Important matters can be expressed in terms of technical debt. This is the concept that extra programming work (and therefore extra cost) will arise when code that is easy to implement in the short term is used instead of planning for the long term with usage of best practices.

    When you are constantly arguing over minutiae, your arguments over important matters won’t be heard. This is the whole developer who cried wolf scenario. Focus on what’s important and save the rest for private conversations with other coders.

  9. New technology is necessarily always better.
  10. Many developers are early adopters and fast adapters. Developers should stay on top of current trends in technology. Showing knowledge of the newest tech can help boost a resume.

    Resume driven development is not an accepted industry practice. New tech and frameworks are volatile. Resume driven development should be restricted to personal or side projects.

    Some very old technology is running critical infrastructures. There is a reason the older technology is still in use and still supported. It has survived the hype and proved stable. Be cognizant of the actual strengths and sustainability of both new and old technology.

  11. A snapshot of data tells you everything you need to know.
  12. Particularly insidious when writing to a database. Many times developers will write an app that creates a record and makes multiple changes to a database and feel the app is done because it reads and writes to the database. However there is no logging.

    Would you accept your bank only being able to tell you what your balance is, versus listing out the transactions that got you there?

    Logging is a first order concern of an application, it needs to happen from the outset. Some of the most valuable data you can collect is the data as it is happening. When collecting data for a system think of building fountains not statues. The steps of how the data moves has business and diagnostic value.

  13. The difficulty of scaling an application is linear.
  14. An ant can lift 50 times it’s body weight. An ant is very small. If that same ant were the size of a human, it’s own body weight would break it’s legs. Scale is extremely important.

    Tight optimizations that work at smaller levels of scale don’t work well at larger levels.

    Scaling an applications is linear, until it isn’t…

    Go and look at how many people hit Google’s home page. At the time of this post Google averages 3.5 billion searches per day. If you have a CSS class and you can take out 2 bytes from that class. Change the class name from logo to lg. That’s 7 Gb of network traffic saved by just 2 bytes.

  15. A project rewrite is typically a good idea.
  16. Project rewrites are very expensive and very dangerous. They are a good way to lose data or break entire system. In essence rewrites throw money away to get something that may not be as good as the original. Project rewrites might fix outstanding issues, but they will introduce NEW bugs. Now under a time crunch to release so new bugs are not fixed. Backward compatibility often does not get carried over.

    While you rewrite, your competition improves. You are running for months to stay where you are, while everyone else in the market runs to get ahead of you. Think back to an old browser that isn’t in the market any longer. The Netscape team decided to rewrite due to too much technical debt. In the meantime other browsers came out and moved forward.

  17. Good relations with people from other departments don’t matter.
  18. Most frequently between developers and sales. Sales teams are sociable, happy, and outgoing. To them a problem is an opportunity for growth. Developers however tend to be isolated and pessimistic. They see problems as more work and try to predict them before they happen.

    A good salesman walks across the street and doesn’t even look.
    A good developer looks both ways on a oneway street.

    The function of the sales team is to make promises to the customer to bring in money that pays the developers. The issues ensue when they make promises that cannot be kept. A good working relationship between development and sales teams can not only lead to better sales but knowledge of what customers want and ideas on where to focus development.

    Engage with other departments, go to lunch with them. Get to know the people and learn how they do things within your organization. Putting a name and face to the people in other departments humanizes them and creates a better understanding for how they contribute to the overall health of the company. Open a dialog for better understanding and communication.

As stated earlier this is not an exhaustive list but a few key beliefs that are held by many developers that need to be changed. Not all developers believe these and not all that do believe all of them. If one of these nine points hits a nerve with you ask yourself why? Why do you believe this or why do you disagree with this post? Listen to the episode for even more detailed explanations and a lot more examples. If you still disagree let us know in the comments. If we left out something that you feel is important also let us know.

Listen to the Full Episode

Join The Mailing List

Get Exclusive Content Directly From Will and BJ Mailed To You Each Week.
* indicates required