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,
Turn off the computer. Grab a pencil and some paper. Sketch out your design. Review it with your peers. Then write the code.
Some ideas...
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.
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
"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.
Avoid polishing your code to the perfection, just make it work. That's what the business expects.
But often, increasing speed implies sacrificing quality.
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?"
Keep it simple.
If you use TDD, you should follow "red, green, refactor":
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!
Notice when you have been reading Stack Overflow for too long. The "Compiling" excuse only works for so long. :)
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.
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.
Learn to touch-type as quickly as possible.
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 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.
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
Knowing your IDE and framework well. Having to turn to Google for every little thing takes time.
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.
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.
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
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.
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.
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.
For me, getting good productivity is having a clear idea about what you are trying to achieve, and how you will get there.
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?
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).
