

Ask HN: Are you a fast developer? - cwt

Why? What make a fast developer? Is it rarely having to learn new things? Is it learning a new technology before other people on a team? How do you measure your speed as a developer?<p>This concept has been bothering me lately. I&#x27;ve been working on a project for a few weeks and part of it took me a lot of trial and error(a week) to find a solution that took me 5 minutes to write. Did I waste that week?
======
leesalminen
No, of course you didn't waste a week. Every minute spent honing your skills
will be beneficial to you later on.

I've been told I'm a "fast" developer. I'm still unclear about what it means.
To me, it seems as though they really mean "You say what you mean and you do
what you say" or "You meet deadlines, don't bullshit and don't overbill".

Don't worry about what other people say. Focus on you - the rest will come.

------
bbcbasic
You can't objectively measure your speed as a developer. Attempts to try and
measure developers' speeds will cause perverse behaviors - like rushing code
to get it checked in quickly and making things less generic, splitting up bugs
(so more bugs are fixed per month) etc. And this would cause those developers
to actually slow down in terms of business value delivered.

Don't worry about speed, focus on effectiveness.

The trial and error thing - next time see if people can help you either in
your team or getting answers online etc. That may reduce the time spent in
trial and error but sometimes it is unavoidable.

------
pjbrunet
What makes me fast is I press Control-S and my code is live--working--in
production. Clients love it.

You have an idea--I make that idea work while we're on the phone. Slow devs
have six layers of red tape between their code editor and the production
server (version control, dev servers, prebuilds...) and they call that agile.

Fast devs keep it simple.

Fast devs are not afraid of their code, they know what to do. Code works the
first time, most of the time. That's a good feeling. With experience, you're
confident, most changes are easy and predictable.

~~~
sharmi
I doubt you have worked for long and experienced atleast one episode of the
cleanup following a substantial damage. If you are really as fast as you claim
you are, I suspect you have never worked with anyone before :)

~~~
pjbrunet
Been writing code for 30+ years. I did devops for OS/2\. I have seen stuff
break, like when Media Temple had a cluster fail and their backups failed.
Which is why you always do nightly offsite backups. I never trust a host's
onsite backup because they often fail. However, digging into backups for code
never happens because with experience you learn how to introduce changes. Also
remember, there's a 3rd and 4th backup copy: control-z plus the copy on the
production server. 5th backup copy if you count your code editor's backup
copy. 6th backup copy if you count the hosts onsite backup copy. And because I
use Linode, that means 4 archived backups. So yeah, that's about 9 backups,
just in case I forget a semicolon ;-)

~~~
sharmi
I dont even have a quarter of your experience. I do realize we have multiple
backups either intentionally or unintentionally. But one thing I found when I
don't check in code, and unfortunately have to resort to one of the backups,
is that a lots of time is spent finding out which is the latest and has all
the changes. Under really unfortunate circumstances, I have ended up with
different copies of the code having portions of the latest features and having
to merge. I have also had the bad fortune of cursing myself for deleting a
code file unintentionally and having to rewrite it from some other unfinished
copy. Makes me love version control systems. I always use one even for my
personal projects. That is my recipe for coding without fear. YMMV.

------
CyberFonic
Haste makes waste.

You can only make a comparison of speed if you compare developers on the basis
of equal robustness, efficiency, reusability, etc.

Once you get on top of the learning curve with any given set of tools,
libraries, etc - you would expect to become progressively quicker. But as you
have experienced, the learning part can take a lot of time. Assuming that your
eventual solution is better (on whatever criteria are important to the given
project) than the quicker alternatives then the learning was worth it.

------
Lorenzo45
The way I see it is it's all about experience. Now that you've experienced
that week of trial and error you can complete a similar problem in 5 minutes,
whereas someone inexperienced who doesn't have the knowledge you do will
certainly take much longer. The people who are fast coders have just done more
trial and error in the past and know how to deal with problems effectively.

------
goodbye_world
From my experience, I develop fastest when I have the following, in order of
importance: 1\. Adequate and frozen specifications. 2\. Tools. 3\. Libraries.
4\. Testing tools.

Even if you are working on your own pet project, get off the computer and
write some specifications whilst pretending you are the client. For the other
three I mean the thing itself and your experience in using those things.

------
mrits
I doubt it's much different than school. We were all fast before an assignment
was due. Very few of us maintained our productive habits everyday.

So the final product has just as much to do with work ethic as ability.

