Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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

share|improve this question

closed as not constructive by Jim G., gnat, Walter, Dynamic, Glenn Nelson Dec 24 '12 at 14:11

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

I'll suggest reading code complete in addition to pragmatic programmer too. You should also learn the subtleties of the language. – AbdulFattah Popoola Oct 11 '11 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 Oct 14 '11 at 15:43

6 Answers 6

up vote 11 down vote accepted

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.

share|improve this answer
Since nobody else mentioned the book, I'll add it here. If you want to write clean code, read Clean Code: – CaffGeek Oct 14 '11 at 14:56

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.
share|improve this answer
+1 and I'd add that code generation is also useful at times, such as with cog. – Spencer Rathbun Oct 11 '11 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.

share|improve this answer

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.

share|improve this answer
"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. – Péter Török Oct 14 '11 at 15:49

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.

share|improve this answer

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.

share|improve this answer

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