Already know *how* to program, but how do I getfaster at it?

[NTB]

Any suggestions? This is probably the one thing I worry about most, from a technical standpoint. I know I can understand and use various programming languages; in fact I've been working as a programmer for just over 2 years. But I have a hard time keeping up with the other members of the team. I don't want to cut corners to keep up, but I don't want to find myself being the reason that something comes in late, either. Getting better just takes time and experience - i.e. practice But, aside from that, there have to be better & quicker ways to work with what I already know. At least, I hope so.

As far as the things I work with (in case anybody has any area-specific tips)...well, that covers quite a bit of ground:

SQL (Teradata, DB2, Informix, and now MS SQL Server, too)
Perl (on both Windows and UNIX)
UNIX Shell scripting (Korn Shell)
COBOL & JCL on IBM mainframes
Java & Javascript

Nathan

 

[Woosta]

Vim, Sed/awk & other commands, multi monitors, multitasking ability and a high wpm ( 130ish ) .. works for me

 

[EagleKeeper]

Learn the tools that you use for programming in your given environment.
Practice and the ability to visual the problems/attack plan will help.

Learn when to sit back and think the issues out.

Be aware of when you are becoing frustrated and stop.

 

[Woosta]

Oh another thing, if you're doing something easy or just talking in general and have a project you need to work on, I like to just code in my mind before I even start so I know what to do beforehand.

 

[Markbnj]

How do you know you aren't keeping up? Is the measure expressed in lines of code? How about defects per 1000 lines?

Programming fast is highly overrated.

 

[sourceninja]

My secret. I have HUGE personal code snippet library. It's all the stuff I've written over the last 10 years. Well at least all the stuff that is still relevant today. I've actually built entire projects out of just copy and paste from this catalog and some minor tweaking / testing.

 

[wwswimming]

i visited with the founder & chief programmer of a medium-sized software company
in San Diego. for him, it was 2 hours of Kundalini Yoga, which involves meditation &
deep breathing, before the programming workday.

for another programmer who started an ISP in San Diego, he told me that Ashtanga
yoga "changed his life", by helping him cope with the stress of 12 hour workdays etc.
he's since started a larger company and has become quite wealthy.

for some programmers, it's that lunchtime swim.

for the head of security at one place i worked (not a programmer), it was a 12
pack of diet Coke every day (= CAFFEINE & several trips to the restroom).

everyone has their routine.

 

[lozina]

My secret? Performance Enhancing Drugs.

It all started with one legendary team in our office called the "STAR Team". They whipped out projects like there's no tomorrow and everyone was wondering how they could do it so fast. The standard stimulant caffeine was suspected at first, but most of the other teams drank far more coffee than them and didn't have nearly the performance.

Then one time time they got caught by the vending machine stocking boy who found them taking some pills in the break room. He went to get his manager and he got back int time to catch them still there and hand over the pills- amphetamines.

There was some shock of course but all the other teams got the light bulbs in their heads and started taking them too. They began using all sorts of substances in any perceivable way to increase their performance like artificial oxygen carriers, cannabinoids, beta blockers, anabolic steroids, you name it they tried it. This caused a big anti doping campaign by the managers who started subjected programmers to random drug tests. Many people got caught and drove the practice further underground and made them come up with ways to mask their substance abuse with secretion inhibitors, diuretics or plasma expanders.

But me, I just snort coke every morning and pay off the guy doing the drug test.

 

[Markbnj]

But me, I just snort coke every morning and pay off the guy doing the drug test.

Then you code really fast for an hour, and spend the rest of the day staring at the screen through bloodshot eyes.

 

[SJP0tato]

Originally posted by: sourceninja
My secret. I have HUGE personal code snippet library. It's all the stuff I've written over the last 10 years. Well at least all the stuff that is still relevant today. I've actually built entire projects out of just copy and paste from this catalog and some minor tweaking / testing.

This pretty much sums it up: The fastest programming you'll be doing is when you're repeating something you've already created/designed sometime in the past. Slight adaptation to something you know/knew backwards and forwards is infinitely faster than developing something you've never personally had to create.

 

[KIAman]

Keep an organized code library. If oo, keep a dll library of your most often used functions and routines. Hell, most of everything I code nowadays reuse most of everything I keep.

 

[brandonbull]

Originally posted by: SJP0tato

Originally posted by: sourceninja
My secret. I have HUGE personal code snippet library. It's all the stuff I've written over the last 10 years. Well at least all the stuff that is still relevant today. I've actually built entire projects out of just copy and paste from this catalog and some minor tweaking / testing.

This pretty much sums it up: The fastest programming you'll be doing is when you're repeating something you've already created/designed sometime in the past. Slight adaptation to something you know/knew backwards and forwards is infinitely faster than developing something you've never personally had to create.

I'll second that. I've reused a lot of, and copy-n-paste is a lot faster than inventing the wheel every time. Also learn as many keyboard shortcuts you can.

I almost forgot the part about knowing how to google for solutions to problems you run into.

 

[IHateMyJob2004]

Originally posted by: Woosta
Vim, Sed/awk & other commands, multi monitors, multitasking ability and a high wpm ( 130ish ) .. works for me

If you need to type at 130 wpm, you are doing something wrong because there is no way to develop elegant code that works that fast.

I kinda laugh at this whole "keeping up" thing to. Alot of the answers people provided are laughable and shocking at the same time. Coding is only 20% of the job. The other 80% is requirements gathering, documentation, design and qualification testing. If a company is spending more than 50% of the time/budget actually writing code, the reason for that is that the code probably crashes all the time and bug fixes are being made 24/7.

The only code that works is code that is tested. And to write good test procedures, you will be spending more time thinking than typing.

Sadly, alot of the answers given in this thread relate to people where I work that have less than 3 years of experience. Alot of newbies don't understand that coding fast is a bad practice and only going to piss off those with experience because experienced software engineers know where fast coding habits will lead. It leads to buggy, convoluted code that is unmaintainable.

Not exactly software, but this is a key point about where time should be spent in software.
Right now I am pounding into a co-workers brain(fresh out of school) that he needs to document what is being installed on the various PCs. To put everything(liek patches) in one folder on the server and when done, burn that stuff and hand it over to Configuration Management along with development environment documentation. Using version 1.2 of Foo can cause big time headaches 3 years later when only 1.3 is available years later or you only have the unpatched installation disk. Try finding patches for old version of Borland C++ if you don't believe me). What is even more fun is not knowing what patches you used several years prior and when you try to reproduce something years later, you get binaries that don't match and some missing bug fixes that certain patches resolved.

 

[Woosta]

Originally posted by: IHateMyJob2004

Originally posted by: Woosta
Vim, Sed/awk & other commands, multi monitors, multitasking ability and a high wpm ( 130ish ) .. works for me

If you need to type at 130 wpm, you are doing something wrong because there is no way to develop elegant code that works that fast.

I kinda laugh at this whole "keeping up" thing to. Alot of the answers people provided are laughable and shocking at the same time. Coding is only 20% of the job. The other 80% is requirements gathering, documentation, design and qualification testing. If a company is spending more than 50% of the time/budget actually writing code, the reason for that is that the code probably crashes all the time and bug fixes are being made 24/7.

The only code that works is code that is tested. And to write good test procedures, you will be spending more time thinking than typing.

Sadly, alot of the answers given in this thread relate to people where I work that have less than 3 years of experience. Alot of newbies don't understand that coding fast is a bad practice and only going to piss off those with experience because experienced software engineers know where fast coding habits will lead. It leads to buggy, convoluted code that is unmaintainable.

Not exactly software, but this is a key point about where time should be spent in software.
Right now I am pounding into a co-workers brain(fresh out of school) that he needs to document what is being installed on the various PCs. To put everything(liek patches) in one folder on the server and when done, burn that stuff and hand it over to Configuration Management along with development environment documentation. Using version 1.2 of Foo can cause big time headaches 3 years later when only 1.3 is available years later or you only have the unpatched installation disk. Try finding patches for old version of Borland C++ if you don't believe me). What is even more fun is not knowing what patches you used several years prior and when you try to reproduce something years later, you get binaries that don't match and some missing bug fixes that certain patches resolved.

I'm not advocating poorly ( fast ) written code ( with no thinking involved - or a minimal amount of researching/googling ), it entirely depends on the project at hand. If I was coding something new to me, I obviously wouldn't be coding at max speed because I'm not as familiar as I am with something that I do as often in which I'm much faster. I'm going to go ahead and agree with sourceninja - a lot of the stuff that I have is already written out and I just throw in snippets with vim. I think the OP wanted just some tips on how to get a little more productive.

Coding fast isn't a bad practice, it entirely depends on your level of expertise, and whereas your domain might be application development ( C++/Windows/Java ) mine is more on the web front end with things I'm very familiar with ( Ecmascript ) so I don't really need to do as much researching as you do because I've already attained a certain level where I can pretty much teach others how it's done despite not taking any courses or attending college ( yet ) for that matter.