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,
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.
Use an ergonomically optimized keyboard layout. Some are even aimed at programmers, through very accessible special chars.
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.
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 :)
Being excited about what you're doing is a great way to increase efficiency. Make sure it's fun!
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.
Use code generators whenever it's possible. Sometimes even Microsoft Excel (or OpenOffice Calc) turns out to be a powerful code generator tool.
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
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.
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?
"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.
CodeRush! Get it! Love it!
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.
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.
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.
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)
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.
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.
