

Ask HN: What mental habits do fast coders have? - yoaipee

I want to become faster at building things. One mental habit I&#x27;ve noticed is that fast coders focus on which working features they&#x27;ve added and how long it took to add them. Slow coders tend to focus on building the right foundation for their project and expressing the solution in an elegant way. What else?
======
ddebernardy
Fast coders know their languages, frameworks and tools like the back of their
hand. They eat docs for breakfast, have a knack for memorizing it, and an even
stronger knack for making sense of it.

There's no shortcut: read the docs from the front to cover.

Not necessarily every single last page of it. But do make sure that you know
_and understand_ what is available and what is possible; well enough that
googling typically occurs when you have a reasonable idea of what you're going
to find already but don't have the specifics off the top of your head.

3rd-party libraries are a slightly different story, of course: you can't
reasonably be familiar with every single one of them. What you _can_ and
should know, though, is what your languages, frameworks and tools are capable
of and adequate for. This allows to be able to quickly locate any third-party
library you might need, and quickly evaluate their suitability and quality.

Another important aspect is the lack of distraction: when given the
opportunity to do so, faster coders tend to keep stuff like email and chat
off, and get to work hours at a time without interruption.

~~~
clyfe
_Fast coders know their languages, frameworks and tools like the back of their
hand. They eat docs for breakfast, have a knack for memorizing it, and an even
stronger knack for making sense of it._

Sounds like a job add at the Startup From Hell.

Fast is a subjective term. How would you quantify? LOC/hour ? Words per
minute?

There is no such thing as a "fast coder". You could differentiate from "mostly
beginner" and "somewhat experienced" but that's about it, and even that is
subjective.

I find "coder" a demeaning term and prefer programmer or developer.

Do you know a programmer that recommends himself as a "fast coder" ?

(Other than a job starved dev, in a low income country, to a low budget - low
quality dev shop ?)

As DHH says, the main factor of velocity is feature negotiation: shaving off
the 20% of stuff that takes 80% of time.

------
toast0
I get things done quickly with a combination things:

a) reduce reduce reduce. As much as possible, remove abstraction, remove
layers, remove lines of code. A few things are useful to abstract, but for
many abstractions, you optimistically trade the underlying complexity for a
new layer of different complexity; and then it usually turns out you need to
know the underlying layer too, so you actually have twice as much work.

b) I don't worry about getting things perfect (or locked down) the first time.
Most things are poorly specified and will need changes, and it's easier to see
what you really want, once you have something that's close. Usually, it takes
two or three times doing the same thing before you get it right; in that
spirit, don't stress over the first time. Also, the least amount of time
you've invested in the first draft, the least ego you sacrifice to throw it
away and do it right.

c) That said, use your experience to make more right choices than wrong ones,
especially for things that are hard to change later. Consider how you will
scale things: you don't need to make things scalable, but don't make it a dead
end.

d) code re-use (as in calling existing functions) is nice, but don't be afraid
of some near duplication: changing a core function "a little bit" to get it to
work for your new case is a significant time investment. If you're not
confident that the change will stick, copy and alter; you'll be more willing
to throw the changes away if you need to after that.

------
davismwfl
Build a snippet library. I have found smart people don't waste time writing
the same thing over and over again. I learned this lesson early from some
developers and it has always served me well. Not saying I am a stick to
measure anyone by, but I feel not relearning the same thing over and over
again has really served me well.

Also, learn your toolset inside and out so that you are worrying about use
case, not how to use the tools or specific programming language to solve your
problem. If you are only solving a use case, and not learning the toolset then
time moves much faster. I don't know any real numbers, but assume most devs
know 50% of the toolset (language, IDE, debugger etc), then highly efficient
devs know 85-90%. So they don't waste their time learning how to do something
but rather spend their time learning which route to take to solve the problem
correctly.

~~~
solomatov
Snippet library is called code duplication which isn't nice.

~~~
davismwfl
I do and don't agree with that. I keep a snippet library for things which I
can reuse between projects. I agree, if used wrong (like intra-project) it can
be bad, but that is no different than most anything. Use any tool wrong and
you will get bad results.

I have worked a lot in consulting, and either we create and share a common
library with clients (which some refuse) or we use a snippet library to stop
us from writing the same common code components. Better a snippet library than
having a good memory which means you might miss things and have to repeat
mistakes which costs you time.

------
collyw
Slow and done properly is probably preferable to fast. (There is a quote,
weeks of programming can save hours of planning).

Anyway, for "fast", think about what you are doing first. Write some psudo-
code algorithm on paper first. To get into the flow, avoid distractions, and
focus on one thing.

------
bwh2
In my experience, the highest quality code is often written by the fastest
developers. Among their skills, I notice a few things: 1) Discipline with
syntax. 2) Precise and accurate naming for variables, methods, etc. NPR
recently ran a story on the phrase "mise en place" that resonated with me
about syntax. I often see sloppy syntax and bad naming slow down developers.
They repeatedly trip over their own code. 3) Strong data manipulation and
transformation skills. Fast developers usually have a deep understanding of
the data structure they're working with and how to best manipulate it for the
desired outcome.

------
JoachimSchipper
The projects where I've wasted most time, in retrospect, were the ones were
the requirements were bad. Either the architecture was externally imposed
(without a proper understanding), or the solution was complicated by use cases
that the customers just didn't need.

Pushing back a little on hard-to-implement use cases usually wins you more
time than typing faster. ;-)

------
segmondy
They attack the problem first instead of thinking too much about it. Starting
solving for the smallest solution possible then working from there. Find
anything you have done before that you can relate the problem to, and use that
to solve it. Figure out your data structure fast and keep it as simple as can
be.

------
vahidR
It's like writing essays. They have already read and written a lot of code.
You will get to speed if you have written a plenty of them ... So from a
mental perspective, "Perseverance" is a bold feature ..

------
bennyp101
Also, memory. Remembering that you have already written a class/method/helper
somewhere that does what you want, and looking at that rather than writing
from scratch everytime

------
hoggle
Don't over-engineer, be bold - be specific.

"Overtly generalized code is the root of all evil."

