Ask HN: What mental habits do fast coders have?

https://news.ycombinator.com/item?id=8608566

by yoaipee • 12 years ago

15 15 12 years ago

news.ycombinator.com

I want to become faster at building things. One mental habit I've noticed is that fast coders focus on which working features they'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?

vahidR• 12 years ago

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• 12 years ago

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

JoachimSchipper• 12 years ago

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. ;-)

collyw• 12 years ago

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.

davismwfl3• 12 years ago

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.

marcofiset• 12 years ago

So many times this. I see a lot of people using a very powerful IDE, and not even taking the time to learn the most basic shortcuts, like the "rename variable" refactoring, go to file/class/symbol, or setting up the IDE to auto-format the code based on the team standard, just to name a few.

solomatov• 12 years ago

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

davismwfl3• 12 years ago

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.

davismwfl3• 12 years ago

In addition/clarification to my other point, sometimes snippets are as simple as an AJAX post with proper error handling already coded, but in which the details of the specific call still have to be filled out. This just saves time, and means I get to stay focused on solving real issues and not recalling the details of an AJAX post error handling issue that has been solved prior.

segmondy• 12 years ago

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.

bwh2• 12 years ago

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.

toast0• 12 years ago

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.

ddebernardy• 12 years ago

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• 12 years ago

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.

hoggle• 12 years ago

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

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

Ask HN: What mental habits do fast coders have?

Related Stories