I noticed that overtime with experience that the curve of learning shifts from trying to learn a language or technology (the way it works) to how to develop applications faster and with less code. I am very interested to see how other developers have minimized the time it takes to get applications to market.

I know for a fact that by learning just one thing it can save you a ton of time. For example I started learning lambda expressions and code that normally took 3 lines now only takes 1 and is alot faster to type.

Another angle is shortcuts and tools in an IDE itself. For instance I can't believe I didn't know how to remove unused using statements from my source code so I used to do it manually until I found out there was a tool in VS for removing them.

Are there any resources for learing faster ways of developing applications? Keyboard Shortcuts, tools, programs, references? Is there like a reference where one can learn these things? If not can you please share how you learned some of these tips?

NOTE: This question is geared towards .NET, C# and the Visual Studio IDE

  • I'll suggest reading code complete in addition to pragmatic programmer too. You should also learn the subtleties of the language. Commented Oct 11, 2011 at 19:07
  • Don't do error checking. That way you complete 90% of the project in 10% of the time and call it 100% complete. IOW, you don't waste that other 90% of the time to finish the last 10%. Seriously, all your examples and most of the answers are about the writing code part, which in the big scheme of things takes next to nothing compared to deciding what code should be written and all the testing. Your accepted solution is by far the only one that will save significant time and mainly just the part of creating simpler solutions.
    – Dunk
    Commented Oct 14, 2011 at 15:43

6 Answers 6


Programming applications faster isn't about reducing the number of lines in them. It's about simplifying the solution. Just because it's shorter, doesn't mean it's simpler.

The less complex the solution, the less likely it is to have mistakes.

Typing code isn't what is slow. We aren't paid to type. We aren't really even paid to write code. We are paid to create solutions to problems.

Sometimes an elegant, simple, correct solution is more lines. Some times it's less. The key is that it's correct, and easy for you and the next developer to understand what it does. The computer has no problem understanding what you write. Code is for people to read.

Having said all that. Resharper is a GREAT tool to improve the speed you can program, and aid in creating clean code that is easy to maintain.


Read The Pragmatic Programmer, it contains lots of good advice to help you become faster.

A couple of them, as I remember:

  • (as you too noted): Learn your tools well. Learn key combinations for commands you use often. All mainstream IDEs have keymap cheat sheets. Implied: learn one tool (IDE) and use it whenever you can.
  • Learn a scripting language. Often you can save a lot of time by putting together a short shell / Perl / ... script instead of e.g. manually searching / processing a huge logfile.
  • (probably even more important in the long run): understand your problem as well as you can before you start coding. You may save time by writing shorter, more concise code, but the best saving in the long run is not having to write that code. There may be a library out there which you can reuse. Or it may be that the client doesn't actually need the feature you are thinking of (or she needs something entirely different from what you thought she wanted).
  • Automate everything you can: tests, build, deployment, documentation generation etc. Reduce repeated manual work to the minimum.
  • Continuously refine and improve your tools and processes, identify problems and fix them as you go, adapting to the changing world.
  • 1
    +1 and I'd add that code generation is also useful at times, such as with cog. Commented Oct 11, 2011 at 20:40

My answer is: resharper, resharper, and... resharper :-) You could of course write some code snippets in Visual Studio or live templates for R# in order to minimize all repetitive tasks. Once you create a new code functionality, document it in Google docs, or your/company's wiki, because you may need it again in the future, and then you can just do a simple copy/paste work. Also make sure that you have a good knowledge of SOLID principles. Nothing can boost your productivity as much as good knowledge of design patterns and SOLID principles.


We seem to be focusing on the coding aspect of development; so I'll stay there.

Learning C# (for example) is not the same thing as learning how to program. Badly written code is kwap no matter how fast it's written. And the idea that "well, the faster I can get it down on paper, the faster I can fix it" is a fool's errand. Hear me now and believe me later: Writing code well is far superior to writing code fast.

Learning HOW is a long road, but taking the time for that will make your development process faster.

A couple of practical insights from my journey:

  • Read Code Complete. This is the starting point for quality coding. This book really helped me understand those cute quips we've all heard - "write useful comments" for example. We all say it but it is rare to actually see it.

  • Thorough design. Within the same (larger) project I got to write code where the class design was pitiful, not object oriented, and moronic; in a different piece of the project the classes were very well designed.

    Interestingly the designer (of the good stuff) was getting grief from developers and program management alike for "taking too long" and "it's not simple enough", etc. But the contrast in the speed of coding for these two vastly different baselines was astounding. Well designed classes makes for faster coding and FAR LESS ERROR PRONE code. The former piece spent months in vicious test/reject/fix cycling while the latter sailed through testing in days.

  • If given the opportunity re-write crapCode from scratch, do it. The before and after picture I got gave me a deep understanding of how all these coding principles, paradigms, etc come together holistically to make excellent code.

  • "If given the opportunity re-write crapCode from scratch, do it" - only if you have an exhaustive set of automated tests with which you can prove that the new code functions exactly the same way as the old one. And even then, you are probably better off refactoring the code gradually over time. Big rewrites rarely help speeding up development, rather the contrary. Commented Oct 14, 2011 at 15:49
  • only if you have ... tests. Refactoring is not the point. By all means write tests as the code is redone from scratch. But existing tests are tightly coupled to the existing code and you do not want that interfering.
    – radarbob
    Commented Dec 7, 2015 at 16:52

In addition to the other good answers so far...

If you're looking for ways to produce code faster, have you looked into developing a code generators for repetitive patterns of code? The idea is to write a program that produces more code to use in your main program.

Example: you need to write a series of simple CRUD queries for a large number of tables, each with a large number of columns. The details of these are given to you in an Excel spreadsheet, and to make things interesting, the requirements for these tables change now and then. One solution would be to write a macro for the spreadsheet that generates the CRUD queries and the code to execute them. This way you can generate queries for 1 or 10 or 100 tables with the same amount of effort (once the macro's written). When the requirements change and columns are added/removed/renamed, regenerating the queries is very easy. You might end up with more code (in terms of LOC) in the end, but since you don't have to manually maintain it (if there are special exceptions to these queries, they should not be generated, but tweaked by hand), it's not so bad.

This may not apply in all situations, but it's fairly generic and I've used this successfully in a few places. Sometimes writing a code generator in Java or C# makes more sense, depending on the situation.


In addition to the answers posted:

0-Define requirements accurately to minimize re-work and major time consuming fixes, and consider the design-first approach.

1-Don't shoot yourself in the foot - Recognize your/your team's capabilities vs. requirements vs. time available before you commit to fancy features and focus on the core value of the application.

2-Use tools. There are very good tools to generate code and tools to help your end user generate reports if applicable.

Not the answer you're looking for? Browse other questions tagged or ask your own question.