My last job evaluation included just one weak point: timeliness. I'm already aware of some things I can do to improve this but what I'm looking for are some more.
Does anyone have tips or advice on what they do to increase the speed of their output without sacrificing its quality?
How do you estimate timelines and stick to them? What do you do to get more done in shorter time periods?
Any feedback is greatly appreciated, thanks,
Getting Things Done is also immensely helpful.
I have a short attention span anyway, so these books help me keep my foc... what was I doing again?
Practice. That, and getting your hands on productivity tools that allow you to go faster.
For example (you didn't mention the platform on which you work), in the .NET environment, there's Resharper.
Avoid polishing your code to the perfection, just make it work. That's what the business expects.
But often, increasing speed implies sacrificing quality.
Turn off the computer. Grab a pencil and some paper. Sketch out your design. Review it with your peers. Then write the code.
Re-use - I try to factor out any clever bits from previous projects, so I can use them again in future ventures. It's always worth asking yourself "could I use this again someday?"
Practice and hard work.
You need to put the time and effort in. As you become more comfortable and confident with whatever tools your using, speed and creativity should follow.
If you want to improve any particular skill, it may also help to design exercises which will let you work specifically on that. If your slowness is in the design phase, try to find design problems to work on online. Redoing the same exercise will let you complete it faster and practice speed. I personally like TopCoder's algorithm exercises for practising sheer programming speed. They have design challenges too, but I have not tried them.
Really, really learn your editor. If you use an IDE make sure you're using all the features it offers. Get a cheat sheet to learn the keyboard shortcuts for your editor of choice. If you're using a shell set up shortcuts for commonly used directories
Knowing your IDE and framework well. Having to turn to Google for every little thing takes time.
Keep it simple.
If you use TDD, you should follow "red, green, refactor":
Learn your development IDE in and out. Learn the shortcut keys. Learn to use the mouse less. I find that this saves much time for me.
Do it right, the best way, first time. If that means you have to stop and think about it for a while before you start, then do it. Works 90% of the time.
Some ideas...
The technique that I use is evolutionary prototyping
You can google for more info - but if the need is to produce something quickly, it's about the only way to go. Plus, it has the benefit that when the users says that he likes it, your'e done (... and can start doing the documentation).
"Does anyone have tips or advice on what they do to increase the speed of their output without sacrificing its quality?"
Many, many people strive for "ultimate" quality at the expense of something that is (a) simple, (b) reliable and (c) correct.
The most important way to speed up your development is to simplify what you are doing so that it is absolutely as simple as possible.
Most folks that have problems with delivering on time are delivering way, way too much. And the reasons given are often silly. They're often just perceived requirements, not actual requirements.
I've heard a lot of people tell me what the customer "expects". This is a bad policy.
Build the simplest possible thing. If the customer requires more, build more. But build the simplest possible thing first.
Think before what to do !!!
Design the Program in your mind or better with pencil and paper . Then your experience and Practice will provide the rest of things :)
Notice when you have been reading Stack Overflow for too long. The "Compiling" excuse only works for so long. :)
Read Neal Ford's excellent book The Productive Programmer.
It's full of lots of useful tips.
And, as mentioned elsewhere, read the docs for your tools. I'm always learning new things for Vim by reading Vim wikis. Similarly, just reading through the man page for bash or zsh always gives new tricks to use.
I read something a long time ago about optimization that really stuck with me. I don't remember the source or the exact words, but the gist of it was, "The only way to make a program run faster is to make it do less. Any other plan is just that." The same goes for humans. The army also has a saying, "Haste makes waste." Doing the same things we do now, but faster, will only create problems. There are many different plans for becoming more productive out there, and I'm not saying they aren't effective, but they won't be tailored to your needs. You're better off looking at what you do and finding the things you do that aren't productive, and cutting those out. Any other plan is just a watered-down version of that.
Are you slower than your colleagues, or are your estimates more overoptimistic?
To produce software faster, I've found the best thing to do is to learn your runtime API as best as possible. Don't type out list logic when a LINQ extension will do; don't build a bunch of event listeners when binding will work, etc.
As far as estimation, that comes with experience. You can make use of estimation software out there to help you figure out better estimates.
Personally, I found with junior level developers, take whatever their initial estimate is and multiply it by 2, then double it. This will account for all of the learning, meetings, wasted time, etc. The more senior level developers tend to work at a factor of 2 over their estimates.
Often times, the question is not if your estimate was wrong. It's did your estimate account for all the right things? Are you giving your estimates and timelines in terms of coding effort or in terms of calendar time? Think about all the time in your day and how much of it is actual, productive coding vs. meetings, learning, debugging, etc.
Two things that might be implied, but I haven't seen among the answers here yet that increases productivity are:
Use some sort of build and deployment scripts. Compiling, deploying, restarting app-server and such musn't suck up either time or focus, it should be a one-click kind of thing.
Have some sort of version control. Having to code without being able to roll back a change is like trying to walk on eggs
It's always the same sole decision, fast development vs. quality, readability, extensibility. Drag and drop of controls and infinite code-behind files (quick and dirty) or modularity, patterns and practices (long term investment)?
In my honest opinion, everyone must invest in the long term way of coding. As time passes, the fast development is going to be of great quality as well.
However in case I didn't understand your inquiry, and you are seeking answers in terms of practical aspects of fast development, like tooling, code generators and other stuff, my opinion is to start using Resharper and learn as much you can about your IDE :)
A couple of ideas come to mind:
Get other opinions on your estimates - Are there other developers that you could ask something like "Hey, do you think you can get this kind of feature done in this timeframe?" The idea being that other people's input may help with accuracy in some cases as someone may note a bunch of things you missed in making the estimate.
Hone your estimation skill - Start tracking how off you are on the estimates and why you are off: Are other work items causing deadlines to not be met? Are you consistently underestimating how complicated something is? Are you giving an entire timeline when it isn't practical,e.g. what is asked is vague enough that merely getting a prototype up will take weeks and then there should be a re-evaluation of what else is to be done? Doing this may help the most in building that skill so that if you say something will take x hours, you can have confidence in that because you have done it over and over and over again. An alternative way to state this is merely practice, practice, practice.
Granted you probably already considered these, but I just thought it worthwhile to state this for those others out there that may not have considered these ideas.
Download all your languages/libraries documentation locally to your computer, then unplug your network cable/turn off Wi-Fi.
Not trying to be funny here. This really helps me!
Avoid switching tasks too often. Distractions and task switching can kill a day, even if you use tools like Mylyn to manage your tasks.
Figure out a granularity (e.g., 30 minutes) and only work on things related to the task at hand. Anything else (new bug reports, emails about other issues, procedural matters that are unrelated) is delayed at least until the "next checkpoint". Make sure to disable popping up email notifications so you won't get sucked in.
It's especially effective if you have a buddy on your team who will let you know if things really melt down and require your immediate attention.
Re-negotiate the estimates and timescales. Make sure you are the one who says how long something will take, and don't succumb to any "well, we need it done sooner" or "how about a stretch-target" suggestions.
Read Joel Spolsky's article on estimates, which basically advocates breaking the piece of work into small chunks, and estimate each one. If any of them are counted in days, break them down further until you have everything estimated in hours.
Learn about The Zone, learn how to get yourself into it, and learn how to recognize when you aren't in it.
Once I am "in the zone" I am extremely productive and code just flows out of me, often I can get 2 or 3 days coding done in 1 day. But I find that often its hard to get to that place, I find myself procrastinating, getting distracted by other things (Stack Overflow for example).
Quote from what-tricks-do-you-use-to-get-yourself-in-the-zone
Your desire to be a "faster" programmer by itself is laudable. However, not delivering on time does not mean you are slow, it means the project was planned poorly. Being a "faster" programmer will not help; it just means you'll whoosh past the deadline faster.
You (and your team) are doing one of the following mistakes (or all of them):
There are multiple ways you can address any of the three above. But before you can improve on any of them, you need to know why things are going the way they are. Do a postmortem on the last two or three projects estimates vs. actual time taken and figure out where the extra time went.
I'll repeat it again - being slow at writing code won't cause missing the deadline, if you've planned it properly to account for that fact.
Here's what works for me:
I've seen several comments that you should spend less time on Stack Overflow. If you're using it right, Stack Overflow should make you more efficient, not less. Steer clear of discussions and focus on using it to get work done.
Use code generators whenever it's possible. Sometimes even Microsoft Excel (or OpenOffice Calc) turns out to be a powerful code generator tool.
Re-use old projects assets.
Take a day to learn your IDE. If it doesn't provide tools like snipets, code auto-completion... consider getting a new one.
Put shortcuts to everything in key places so you can access things faster.
Get a second screen if that's not already the case.
Don't check your emails too often.
Try focusing on only one task at a time. If this is not possible, keep close track of what you're doing and don't get lost between 15 unrelated tasks.
Use paper. When I work I always have a printed version of my tasks on which I can take notes, cross off and so on. It's way faster than going on a different screen to read something or write something. At the end of the day I take 10 minutes to copy everything into the system. I realized it saved me some time every day.
Simply put, White board -> break down into testable requirements into tasks (I've used Team Foundation to keep track of each task and how long it should take.)
Use testing to ensure that you are getting what is required done, nothing more nothing less. (Don't worry about performance yet.)
Go from requirement to requirement and test after each is done. After each task is completed you should have an accurate estimate of the time remaining.
When all requirements are done go back and "polish" it.
Doing the leg work first forces one to iron out all the requirements which saves time by doing things right the first time.
If done properly this should allow more time to be spent on Stack Overflow :)
Good luck
What are your time bottlenecks? I find that thinking is my usual bottleneck, so improving my typing speed (already good) would do approximately nothing. On the other hand, if typing is not fast and natural to you, it may well be slowing you up.
Are you trying to do more than is required? Usually, a business will want lots of good work out of you rather than less but more polished work, and adding features that aren't going to be used wastes time and money with no business return.
Are you being too hasty? Under time pressure, people frequently skimp on up-front design and planning, hoping that it'll work out anyway. It frequently doesn't.
Are you handling time properly? Development requires chunks of uninterrupted thinking time, or you'll be inefficient, and hence slow.
First of all, you shouldn't be designing a system based on a few meetings with end users. In fact you shouldn't be involved with the requirements phase of a project, that's for the business analysts and end users to work out.
Second phase should be your technical requirements, this is where you will start to work with the business analysts to come up with a solution to the requested specification.
Now is the important part. Make sure you understand both the end user requirements and the functional requirements, there's no use you starting out something only to find it didn't meet users expectations. Speak up if you don't understand something.
Now, time to hit the editor. But my approach is to never write real code, always write an absolute stack of comments first, do it in pseudo code if that's easy for you, whatever it doesn't matter, as long as it's clear and easy to read/understand.
Once you've done your comments you can start either a) writing your test cases b) writing the implementation.
Depending on your environment you would be best starting with (a) but sadly most start with (b) and then try force the tests to meet the implementation. Frankly speaking though, if you were part of a large company there would be a department writing the test cases for you before you even start doing anything.
Everyone says 'checking email' but consider the time you spend writing highly technical email. I can easily spend an hour writing a single email. To fix it, I could either 1) not write as much, or 2) put off the technical stuff (and the stuff that requires me to read code to answer) until it is absolutely necessary.
Since many of the other answers talk about doing designwork, I'll just stick to the pure mechanical aspect of coding faster. Most of this is probably obvious, but I'll say it anyway since I notice that many of my co-workers don't do some of these things.
Remap your IDE keyboard shortcuts so you can do most of them with your left hand. This frees up your mouse-hand for fast and furious code outlining/refactoring.
Learn how to navigate your cursor and select text using a combination of Ctrl, Shift, arrow-keys, Home and End.
Below is my C++ setup ( Visual Studio with Visual Assist X ). I have a Norwegian keyboard, so please bear with me:
Alt-Z : Change between .h and .cpp
Ctrl-Shift-< : Context sensitive jumping through references. (< for me is the key left of Z, you english guys don't have one of those. Map it to Ctrl-Shift-Z then. )
Alt-| : Implement method. By writing the header first and just hitting Alt-| all the time you can make the whole class outline in a few seconds.(| for me is the key beneath escape.) This is especially true if you place the cpp and header files next to each other in the text editor so the header doesn't get obscured every time you perform the action.
Alt-R : Renames symbol under my caret.
Alt-D : Adds a documentation template for the selected function.
This, in addition to lightning fast code completion, makes left hand refactoring possible.
You and your boss/evaluator need to determine how much time you actually have to program. Take out the meetings, emails, documentation, testing, other interuptions from the time you are expected to work and see what is left.
Try to monitor your time to get a benchmark of how long certain tasks take. There will be productive times (for me early in the day or any stretch of time I get at work without interuptions) and unproductive times. Find an average.
You may determine that a given task takes 8 hours to program, but I doubt you will get that done in one day.
I would also try to compare yourself to others. The corporate culture may be to put in a lot of hours.
Well, I think I'm not slow, but the work I'm given tends to fill the available time.
Regardless, I oftentimes hear "Gee, you did that quick", but it's not from being a fast coder, it's from coding less.
I think the main way to code less is to think like a DSL. If you can't get the code generated for you by a preprocessor, then write a code generator. It doesn't have to be fancy. The objective is, if you are given a single stand-alone requirement, to minimize the number of source code differences needed to implement that requirement. Ideally, that number is 1. If you can get it down around 3-6 on average, that's pretty good. (It's not just that you're writing less. The smaller this number is, the smaller is the number of bugs you're putting in, and that really saves time.)
To do this, I recommend doing performance tuning, because then you will find out what coding practices lead to the greatest slowdowns, and they also lead to bloated code. In particular, excessive data structure and event/notification-style programming. Those things alone contribute massively to code volume.
Much code volume these days is due to the user-interface, especially if it is dynamically flexible. I stumbled on a way to do that part, called Dynamic Dialogs, which has a tough learning curve but shrinks the UI code by roughly an order of magnitude.
You'll have to find your own way on this, I'm afraid, but best of luck.
There are a bunch of great ideas here. To help me get in the 'zone' I use a timer set at 27 minute intervals. I find once I'm in work mode it's easy to work well beyond the buzzer and working with flow is painless. Getting there is hard though.
There's only one way to do this.
Type faster!
I refer you to Atwood's We Are Typists First, Programmers Second.
Code snippets, experience and never ceasing enthusiasm. Always read stuff: programmer blogs, books, literature, other peoples' bad code. You'll get faster if you get a wider view on stuff. If you can imagine all kinds of complex background processes involved, and you really know the whole complexity of the target system.
The Pragmatic Programmer's Handbook is kind of awesome: it's about best practices and major pitfalls of many different aspects of software development. Rubber ducking and stuff sounds blatantly nerdy and stupid. However the nature of most programming problems is that we tend to think much too complex. I'm a great fan of simple and easy solutions: no great tricks, no super-elegant hacks: just using the simplest solutions.
If your team is good you can try to work collaboratively: Bespin and some other frameworks nowadays allow editing one file together. That's awesome if you're really into it and see your coworker doing the magic ;).
Before you start developing:
Every time you're interrupted, you'll slow down as it takes your mind time to get back on track with its thoughts. I've heard figures that for each interruption, it takes the human mind 5-10 minutes to reset back to the thought process it had before the interruption. With that much time per interruption, it doesn't take much to waste the whole day.
People in our company have actually taken to blocking off time in their calendars and then moving to an empty conference room for a couple of hours each day.
Keep your personal life in order. Get lots of sleep, eat healthy, and take vitamins - especially if you have an iron deficiency. Stay away from "the drink" - if you know what I mean. And remember, "Both Wine and Women can lead a wise man astray."
Also, create templates of your code and a "code generator" that works using regular expression patterns. IF you find yourself copying and pasting, then searching and replacing similar classes, automate this process. I did this for my PHP projects, in which I can create a CRUD application, complete with all the basic MVC components, based off my data tables - the data models all look the same except for the data tables they represent, so these are setup in templates and used to generate my initial code. Saves hours of typing.
Finally, tell all people involved with the project that the code is going to take 1/4 to 1/2 times longer than YOU think. Negotiate more breathing room for yourself, early on. "Late" is a relative term. When changes occur in the project, mid-stream, let everyone know up front that 8 more hours of work has been added. A tracking system, such as one offered in "FogBugz" might be helpful to yourself and managers to anticipate how long its going to take to get something done, based on previous experiences. I try to take the tact, "It wasn't late - I used the proper amount of time it takes to complete this function - it merely took longer than we expected."
Another programmer may say, "Well I could have done it faster..." Maybe, maybe not, that's not a point worth debating or beating yourself up about - there's always going to be some "smart" guy trying to push that button. He'll slow you down if you think about it! Its always a bad situation when its your boss, though. At that point, I'd consider looking for another job, cause that sort of boss is an arrogant JERK, in my book.
I think they key word here is "timeliness". They didn't say you were too slow, rather that you were not timely.
In project management, it is important for the manager to be able to estimate when your work items will be complete with accuracy. I suspect that the main reason why your efforts were not deemed to be timely is that you frequently had items that were not delivered on schedule, and were delivered much later than scheduled.
To improve your timeliness, you might want to spend more time understanding how long it will take you to complete a particular work item given your skills, experience, and the domain. This will allow you to give better estimates to your project manager. The key here is "better" ... you could deliver on time more frequently by padding everything with a fudge factor, but what you really want to strive for is a more accurate estimate.
I would discuss this with your manager to see if this is actually the issue. Otherwise, you might end up programming twice as fast, promising things in half the time you used to, and still getting criticized for your timeliness because your estimates will still have the same error factor.
The one thing that I have noticed affecting my speed the most is motivation and having fun. This may seem Fuzzy, but when I'm motivated and doing something that I find fun I can be extremely effective. On the other hand when I'm neither it really feels like I have to push every single line of code out of me.
Find your sweet spots, what really motivates you and what kind of tasks do you really enjoy doing? And can you affect your planning so that you can do this? For me it's when I get to solve problems and design issues, and when I feel that I have a part of the project.
A few months ago we had a small project that our small team was assigned to do and it was a really important and very unrealistic deadline to it. However we were all very motivated and had great fun doing it and got it done in time, with a happy customer. The reason for my motivation was that we were very involved in the project and had to come up with creative ideas for it. I also got to do the parts that I really enjoy.
However recently I have been involved in a project where I'm basically being a code monkey, just doing mind numbing and frustrating tasks, or just having quick-fixing stuff the fastest way possible which I know will come back and bite me hard sometime in a near future, and it has been painfully slow.
So what is your sweet spots?
When actually writing code, CodeRush helps quite a bit especially when you've mastered its shortcuts. Plus it's free :D
I spend a little bit of time each week just looking for new creative ways to do things that may or may not be directly related to what I'm currently working on. Often I'll find new tricks or tools I was never aware of that speeds up my workflow.
Try checking your emails with longer intervals and stop using online social tools like Twitter, facebook etc.
Use this wallpaper.
Try to work with open front view. I usually use conference room when its free, it helps me focus!
Try to work with other programers around you.
Pretty much all the answers have been said to death in numerous places here and elsewhere. Or, at least I've heard it to death. Learn your IDE, learn to type faster, use frameworks, use code generation, etc., etc. Yes of course these things will help and I doubt there are many programmers who are masters of them all. But being the type of programmer that asks these questions and frequents sites like Stack Overflow you knew these things already. Did you merely want to here them repeated or did you just want to vent a little?
But what if we were able to get to that state? I mean master all these suggestions? What would happen then? Well. I'd guess that time-lines will be reduced even further. And again, we'll revert to a perception of quality. I mean, our craft has definitely progressed and become more and more productive over the decades. But has quality increased during this time (excluding the very early years of course)?
My answer is simple: quality software takes time! You can only trade one for the other (quality/speed). But yes we all know that however we're not honest about the degree to which that trade-off often ends up on the speed end of the scale. And we are even greater liars early on in projects!
I say that you are not at fault here. The problem is the perception people have of how long quality software should take. We fool ourselves in believing we are capable of creating quality software with the types of time-lines our managers or even we guesstimate. We do not make quality software. We write software that works but sometimes with flashes of quality in certain corners of an application.
So what can we do about this? We can't just convince our bosses that we need to double or triple the investment in each of our projects. I say lead by example. Create a truly great piece of software as a side project. Put your own time into it and do not compromise. All the while pay attention to how you progress. Make note of the apparently unrelated tasks you've had to put an unexpected amount of time in and see if you can justify it. Contrast this with all the other projects you've worked. Be brutally honest with yourself and all aspects of this analysis. Can the extra things you did with your quality software be neglected in "real" projects at work? But maybe your attempt failed. What was the reason? Did you get bored and just rushed to get the core features done? I've yet to do something like this myself which is why I end off this thought with some doubt - but I intend to give it a real go. I'll keep you posted :).
Finally, I think most (if not all) performance evaluations are twisted and extraordinarily manipulative. You can't throttle quality and speed at 100%. Your boss should be scoring you against a standard that is set by the organization. The organization's standard on the trade-off between quality and speed. Lets imagine that OrangeSoft Inc. expects 33% quality and 66% speed. So if you're writing code that has maybe a third of the unit tests it should but making it up with speed and reduced delivery time you should score near 100% on your review! (These are pretty rough analogies but you get the point). But instead, what happens is that Bob writes code extremely fast but which is notoriously buggy. So on his performance review he'll score 3/5 for quality and 5/5 for speed. Carol on the other hand writes code much slower but produces significantly less bugs. She scores 5/5 for quality but 3/5 for speed. Either way Bob and Carol get docked on their raise. Is it possible for any employee to get a perfect score? Is this fair?
Q:What do you do to get more done in shorter time periods?
A: Everyday come to office and write what all you would want to finish on that in (sticky notes) outlook notes. Start working on that order of the items. Believe me at the end of the day you would feel you have done what you had planned and thats a great feeling.
Pair program -- this has all sorts of benefits:
Become intimately familiar with your IDE.
If your IDE is Visual Studio, then I highly recommend Sara Ford's book.
Note: Just making things work is worse!! As some mention just to hack in things till they work will make you faster just for the moment. Bugs will come in however which somehow count also in terms of how fast you program. If I have to write some piece of functionality and I invest in writing it good, having a good design, possibly well tested (with Unit tests) and say I'll need half a day. But assume that was it and your feature works and you don't have to touch it again. Another programmer, just focused on a fast achievement of his goal, will make (possibly) a bad design, due to missing testing he'll not consider (be aware of) boundary, exceptional cases. He'll need 2 hours (let's say). Bugs will come in, he'll again have to touch the code, fix it, possibly extend it (hours will be invested again). Code will be hard to maintain etc...resumé: at the end he'll spend much ore time and frustration will be higher.
"Timeliness" is not the same thing as "fast". If that was the problem your evaluation should have just said "slow". So be before you take the path you propose, make sure you know what is expected of you.
It could mean anything; it might even mean that you don't get into the office until 20 minutes after your colleagues, or that you have poor time management. That may be nothing to do with your 'programming speed'.
I probably spend most time designing and planning; it is easier to plan tasks from a good analysis and design, and you will then give better estimates that will be believed. Moreover from a good design, coding becomes a lot simpler and more directed process. It also makes it possible to divide up a task and distribute it amongst other developers.
The trick is not to write code faster, but to write working code faster.
The sooner your spot a bug, the less effort it is to fix it - this is the primary thing which affects programmer performance.
It's not about how fast you type, or how fast your compiler is, it's about the speed at which you can identify bugs and fix them as you go.
Therefore, I'd suggest pair programming as a way to be faster - it really does avoid bugs. That and test-driven-development. Having two pairs of eyes makes it more than twice as hard for bugs to slip through (I think anyway).
Other tips would be
Write less code.
Banish Not-Invented-Here and make good use of existing libraries/frameworks/toolkits to provide common (and generally non-defining) functionality so that you only need to write what's new. For the parts that you do need to write yourself, build them with re-use in mind so that you won't have to write them again for the next project.
Even if you don't increase the number of lines of working code you produce per day, you can still get more done in less time by making each line do more.
Choose fast editor, fast compiler, and write software with fast execution time. This way you can make ten times as many mistakes as normal programmer and still become better than others. That's probably one the reasons google applications are so popular. Web development is filled with nasty bugs, and writing more software on buggy platform is pain the ass. But the response time between editing code and seeing outcome is so fast that it's still easier to make that mountain of garbage work than extending c++ programs. :)
Spend more time putting things together in your mind than in front of the IDE. When you have a plan, you already have most of the work already done. Implementing is just the other 20%. If you get stuck while writing code due to platform-specific problems, stick to the plan, and keep on implementing and testing the rest. In the end, tackle all the spots you've left behind, solving them one by one - it's possible that some will be related, and solving a few might be enough to figure out the rest. I usually use workarounds for such problems, adding "//TO CHANGE" comments at the particular places in code, and rewrite the ones that have the most impact on quality and performance in the end, if I don't have time to resolve all of them by the deadline.
Use an ergonomically optimized keyboard layout. Some are even aimed at programmers, through very accessible special chars.
Build your own code library
Every time you code a new feature try to keep it generic as possible, but not too generic. In the short term this will be a little slower, but in the long term as your code libary gets bigger, each new project will be completed faster as a lot of business applications have similar needs (not always) but close enough that a lot of code can be reused.
Faster doesn't mean better. If you manage to be a faster and better programmer. It all comes down to balance. How long you can do that ? Thinking, patience and planning always pay off. Sometimes "fast" in developement world could bring worst results.
Deconstruct. Break whatever you're building into smaller features that you can implement in stages. Then, whenever you have any of those smaller pieces done and you've tested to confirm it doesn't break anything, deploy it and show it to the Powers That Be.
Using small iterations will often help you finish the larger project faster and better, because you're getting feedback as you go and you won't need to backtrack and redo as much. But even if it doesn't, you're showing constant progress, which has a solid psychological benefit and restores your manager or client's confidence.
Test-driven development also helps a lot with this approach. At first it may seem like writing tests first slows things down -- but it gains that time back in bugs you'll avoid, and depending on how you write them, the tests themselves could be a deliverable you can show to the Powers That Be and confirm the app's behavior even before you write it all.
If you are programming in C then learning bit hacks is a must for becoming a faster programmer. Also read coding practices by top rankers at Topcoder.com. Their code is very small and efficient.
Get stable, stay stable.
Build something that implements a small bit of the functionality, and make sure it works, end-to-end. Then, keep it working as you add new bits of functionality. Yeah, this is partly a TDD practice, but it makes sense even if you don't do TDD.
The rationale is that every time I've seen someone with 2 weeks of code that had never been stable, it always takes another 2 weeks to get it stable.
If you stay stable, you remove that uncertainty, and also give yourself a way to scope down near the deadline if necessary.
The obvious counter-argument is that doing this will take more time than just writing it once, as you will do extra work be stabilizing non-final code. I don't buy this for a second. When you have code that works, you change 5 lines, and something breaks, you know exactly where the break must have happened.
If you have 10,000 lines of code that never worked, and you have to find a break, you have a ton of code to search through.
Small, incremental changes on a system that is consistently stable FTW. Go slow to go fast.
Write your own productivity tools. They may take time initially to write, but the pay off can be big over time.
Some tools that I've written that I use all the time:
I've written lots of other small tools in my time that have fallen by the wayside, but it was still worth the effort.
Work from home. When I have a tough deadline and I need to focus completely on a problem, I tell my boss that I am working from home. This lets me set up my environment optimally, reduces interruptions, and lets me focus like a laser beam on the problem.
Become a faster programmer by slowing down when you are designing and coding.
It might feel slower, but your throughput will be faster than those code jockeys who turn an iteration in 4 hours, and then need 6 rounds of QA before their code passes.
You'll get faster with experience and memorize the API a lot more.
My days of searching the web for fragments of code are a lot shorter now that I've learnt to code better.
Oh, you may also want to try using functional programming concepts and lamda to cut down your code :)
Re: How to estimate and stick to it:
When estimating, remember Hofstadter's law as well as this quip: "Everything takes longer than it does". Take a reasonable guess as to how long something should take, then double or triple it before it comes out your mouth. There will be complications, setbacks, distractions, things you forget, etc. Better to under-promise and over-deliver than vice-versa.
On sticking to estimations, do your best to complete your work efficiently. When problems come up, communicate the delays early. This gives everybody time to adjust their expectations. If your explanation is reasonable, you may be given more time or assistance or have distractions (like a noisy neighbor) removed from your path.
The following practices are well known but often neglected for various reasons, often due to tight deadlines, so they deserve mentioning here (in effect, these are mechanism for spending time in advance to avoid spending more time later):
Do test-driven development; it'll help you write only the amount of code that is actually required and, will help you avoid the introduction of bugs when adding features or refactoring
Write comments, but only where the code is complex enough to warrant it
Refactor and simplify your code often
Use decent source control software (like Git or Mercurial) -if your employer uses something else, use your own locally-
Commit code changes often: for every feature or refactoring, do a commit, as reverting will be less costly to you if something goes awry
Don't be afraid to branch; Git especially has a very fast and "safe" branching mechanism (for instance, in comparison to Subversion)
If you fire all the "net negative contributors" to your codebase things will begin to improve ;-)
If you're on a team where you're outnumbered by people writing bad code, just getting them to stop coding will improve your productivity - because you'll have less tricky, broken code to fix and less overly complicated mechanisms to think around.
I personally think its all about code re-usability. Unless your doing fully custom things every single time, you should have a library of common use functions you can turn to. I have a utils.php in which i have a whole "junkyard" of functions that i have used on previous projects. Saves a TON of time when i have to do something similar.
Good luck and don't get discouraged. I think we've all felt slow or "dumb" at times. I know i have!
Use static analysis tools.
They help you find more bugs at compile-time you would otherwise had to track down at runtime.
Especially when building multithreaded applications they are a REAL help.
For me, getting good productivity is having a clear idea about what you are trying to achieve, and how you will get there.
Being excited about what you're doing is a great way to increase efficiency. Make sure it's fun!
The only clear thing I've found that works is to be free of distraction. Which, in some environments, is impossible. But being able to focus on the specific task and ONLY on that task will likely outweigh anything else. Those context switches are really big time sinks.
I really enjoy listening to music while I program because I feel like it relaxes me and I can focus.
A comfortable chair. I don't ever use my school's computer labs to program because the office chairs are incredibly uncomfortable.
Eat something beforehand because nothing kills my motivation like nagging hunger.
I think that sketching out your idea on paper, remember that stuff, is a great way to flesh out some ideas. As programmers, whether professional or hobbyists, we spend soooo much time staring at the screen, that having another outlet on which to put your ideas is good. I find that scratching things out, drawing hasty lines linking ideas, circling things, underlining, etc. all add to the emphasis on an idea and can really help you sort out an idea much faster than attempting to structure it right off the bat or in some computer-aided form.
Another thing that helps is prototyping small parts. Listened to a TED audio podcast last night where the speaker was discussing building small structures out of spaghetti sticks and marshmallow, apparently this is a pretty widely-used study to test social construction abilities of small groups...anyway, the groups that always did better, besides architects who understood reinforcement and building construction were children because they used a stream of constant feedback to get results. I think you can also throw this into a programming idea where you see that doing little things and getting results is not only more productive but a lot more fun and useful than building some giant construct and then spending days debugging it....that's killed some of my "fun" ideas in the past for sure.
When I'm at the office and I need to maintain my focus, I close my e-mail client. Nothing destroys efficiency for me faster than the constant temptation to "take a quick look" at whatever message just arrived. I've also been toying with the Pomodoro Technique for managing disruptions and maintaining focus.
These are all good suggestions. I would add my own productivity technique which is to know how to get things done not only with minimal code but with minimal redundancy code.
Generally this means the less data structure the better.
To make code with minimal redundancy requires creativity and willingness to do things in ways that might impose a learning curve. That's the price of the productivity. Here's one example.
