
Ask HN: How do I become a faster programmer? - hoodoof
I want to be a faster programmer, to increase my coding speed.<p>How can I do that?  Is it even possible?<p>At the moment I feel like I have no choice but to go at the pace that my mind allows me to operate at.
======
flyinglizard
By first becoming a slower programmer. I know it sounds very zen-like, but
when you give it some thought, you'd discover that most of your time is spent
bug fixing. Worse for us embedded guys, as it's really easy to get into the
build-download-run cycles and each takes much more time than a typical run
cycle on a .NET environment, for example.

Just realize that actual coding is the easy part, and concentrate on slowly
and properly designing what you're going to build and reviewing what you just
wrote. If I'm building something complicated, I'd take a day, maybe more, just
to think about it slowly. You can't rush a thought process. I'd implement it,
and I'd review it multiple times before even running it. Makes for the fastest
development, unless you're just thoughtlessly hacking on something
inconsequential.

~~~
jameskilton
Very much this. Software development is not a race to write down text to a
file. The majority of what we do is thinking, the coding part is the final
result. What does the user need to do? What can go wrong? How does this fit
into the overarching system? Does the design need to change to accommodate
this feature? and so on.

> At the moment I feel like I have no choice but to go at the pace that my
> mind allows me to operate at.

This is perfectly fine and exactly where you should be. If you force yourself
to work through problems faster than what your brain wants you to do, you will
make mistakes and spend more time cleaning up after yourself.

Following from that, to be a faster features developer, I have one simple
solution: write less code. It's taken me 10 years to understand the wisdom in
this but I assure you it's true. You will move faster, you will write better
code, and you will stop hating your past self so much.

As much as some people argue against this, software development is a creative
process. Creativity takes time. There are times where you are writing rote,
boring code, and for that you can speed up with editor tools (IDE stuff as
another commentor said) and learning to type faster, but make sure you
recognize when you need to slow down, and you'll find yourself becoming much
more productive.

------
keenerd
It is just like optimizing any piece of code. Log everything, identify
hotspots and improve them.

1) Time yourself. Keep a little text file with timestamps and brief fragments
of what is going on. Do this every time you have a mental context switch,
start a new sub-goal, accomplish something or give up on an attempt. Usually I
find myself logging something every 5-15 minutes.

1B) Documentation lookups should not be manually logged. Instead flush your
browser history for the day before starting and then save out a copy of that
when you are done programming.

2) Once finished, identify and eliminate time sinks. If you spent 15 minutes
writing boilerplate, refactor that out for the next time you need it. If you
spent 15 minutes looking for correct bit of previously refactored boilerplate,
organize your archived code. Look at what parts of the documentation you
visited the most and study them.

3) Always be trying new tools. There is no such thing as a silver bullet, but
there are some pretty impressive special purpose alloys. While tedious, it is
worth running previously-solved challenges though the new tools. (Subtract out
the time spent just thinking during the old run to correct for the additional
experience on re-running it.)

4) Practice! Find the smallest "unit of delivery" and deliver that as often as
possible. For example if you do games, do game jams.

By following these I am now 60x faster for one subset of competitive
programming (Mystery Hunt style puzzles).

~~~
falcolas
I particularly agree with point 3. We're programmers who routinely automate
other's tasks, we should spend some time each week automating our routines.

------
Spearchucker
There's a lot of advice here that says do this thing, or that. In my
experience of almost 30 years, you never become faster. Sure, the bread-and-
butter stuff like CRUD you get quick at. Not because you know your IDE
backwards, or because tests, or lean - but because you've done it before. Any
speed improvements (and quality) come from having done it many times before.
And even that isn't a guarantee. Because as you grow, your ambition grows.
CRUD that has a list and three buttons (add, edit, delete) morphs into
something that does multiple-select/delete, tracks changes, indexes a search
catalogue, lets you import and export the list, manage the list remotely, and
finally manage a remote list in a disconnected environment.

You'll find yourself wondering why it still takes you four weeks to do a CRUD
app, when you have all this experience, herds of war wounds and god-like
reputation. It's the best thing about software. There's always a better way to
discover, a new trick to learn from a green 20-year-old with 6 months'
experience... It's humbling, it's awesome and its tons of fun.

One more thing - people _are_ amazed at my speed and quality. Only because I
have so much code lying around by now that I can repurpose in hours, rather
than write from scratch in weeks. I spend my weeks doing the interesting
stuff. The other big thing experience gives you is the ability to recognise a
solution or approach to a problem in an instant, and _knowing_ that given
available time, people and skills that it's the right approach.

------
JBiserkov
Joe Armstrong, creator of Erlang and industry veteran:

Most time isn't spent programming anyway - programmer time is spent:

a) fixing broken stuff that should not be broken

b) trying to figure out what problem the customer actually wants solving

c) writing experimental code to test some idea

d) googling for some obscure fact that is needed to solve a) or b)

e) writing and testing production code

e) is actually pretty easy once a) - d) are fixed. But most measurements of
productivity only measure lines of code in e) and man hours.

[http://erlang.org/pipermail/erlang-
questions/2013-September/...](http://erlang.org/pipermail/erlang-
questions/2013-September/075427.html)

------
sairamkunala
If you want to write code faster - I have 3 letters for you - I D E. Learn
your IDE, be it vim, textmate, IntelliJ or emacs.

I used to use textmate (w/ default plugins) for HTML, CSS, Javascript and
Ruby. Now I discovered IntelliJ does stuff really fast and works.

IDEs/Editors have macros help you perform repeating work fast.

TextMate allows you to run shell commands inside the editor which is pretty
useful. There are few for Ruby if you want to see output of an execution as a
comment (see Avdi's screencasts).

There are shortcuts for performing tasks. In case your IDE does not provide,
use the ones which your operating system supports. Example for Mac OS X - you
can use Apple Scripts, Alfred, Keyboard Maestro etc.,).

Take time reading your IDE manual or help. Graphical UIs show tips and
suggestions. console based provide tutorials when you open without arguments.
With vi, use :help and follow the article. It takes months or even years to
understand and learn your IDE.

Talking about downsides, once you start using your IDE a lot, you will learn
about the downsides like 'pinky finger problem on emacs' (Google for this),
and then you'll realize you have to customize your IDE. Note: These are good
to have problems because you realize you are advancing.

For HTML, ZenCoding as a plugin came out 3-4 years ago where you can use
div.container>div.hello+div.details>span>a*3 (on tab) will expand and give you
html.

StackOverflow has lots of answers and details on discovery of productivity
tools.

~~~
coldnebo
I would also add: get to know your debugging tools really well. I'm constantly
surprised how many developers still use print logging to debug issues with
data structures. Sometimes it's hard to visualize what's going on in your mind
or with the code, why not let the computer "play computer" and actually see
what it's doing step by step.

We may not have the real time integration that Bret Victor demos, but a call
stack, watch list and breakpoints are a beautiful thing when you know how to
use them.

A REPL like Ruby's pry is also invaluable for exploring return data and
playing with data access syntax right in the console without long tedious
trial by error sessions. (I know this annoys the purists who think you should
know the data structures beforehand -- they are right; if you know what you
are doing, of course you'll be fast -- but sometimes even the smartest of us
don't know a service api changed without popping the hood.

Use _all_ the tools you can to understand what your code is really doing, not
just what you think it's doing.

------
QuantumRoar
You can't program (correctly) faster than you can think. However, you can
practice the translation from thought to code by understanding your language
really well and by getting a lot of experience with the kinds of things you
do.

For example, the first time you code a linked list, it's going to take some
time to get used to how it works and to program it correctly. The second time,
you might still need to look something up. However, once you got used to the
abstraction, you can simply type it down as fast as your fingers allow.

This has nothing to do with what your actual goal is but rather it's the
process of translating your thoughts to a particular abstraction that you can
directly write down in code in a particular framework (the programming
language). This abstraction layer varies for different programming languages
and you simply need to get used to it and gather experience.

I think of it as trying to speak a foreign language, e.g. English for myself.
I'll never get faster than in German at saying what I want to say (albeit,
there might be cases where English is way more efficient). The entire process
is simply limited by how well I'm able to translate thought into the
abstraction layer of speech. As everybody will tell you, this skill is greatly
enhanced by actually using the language in various contexts until it becomes
intuitive.

------
antonpirker
I would say:

1) get rid of distractions 2) stop creating bugs 3) get really good in
debugging

This sounds a little odd bug getting rid of distractions (set all you favorite
websites in /etc/hosts to points to 127.0.0.1) forces you to focus on the
problem. Stop creating bugs is impossible, but you can make your best afford
to test your code and write good code (read the book "clean code") But I think
the biggest speed improvement is if you are really good in debugging. It can
take a good debugger to find a bug in a distributed system in 15 minutes, a
inexperienced developer can spend over a day and have no clue what the problem
is.

~~~
rbosinger
I would agree with "debugging". I used to stare at the screen just
wondering/trying weird things without knowing why. Now I attack the problem,
rip it apart and look at _everything_. Not getting hung up on these things has
made me much faster.

------
EliRivers
All else being equal, the fastest code to write is the shortest, simplest
code. By being physically shorter there are fewer keypresses (although
actually pressing the keys is something I do for a very small percentage of
the time spent), and by being simple you will find it much easier to keep
track of what's going on where, and you will spend less of your cognition
keeping track of it all and can spend more solving the actual problems.

This will often involve moving your fingers away from the keyboard and forcing
yourself not to type anything until you have adequately solved the problem, be
it inside your head or on a sheet of paper or whatever helps you think. Some
people do find that tapping out some code helps them think, but be very
careful; if it's part of your pre-coding problem-solving, do not allow your
initial problem-thinking code to mutate into your actual code beyond the fact
that both of them exhibit a solution to the problem. The odds of your first
draft, pre-coding solution-exploring code being the best structure and layout
and style and so on, are so slim.

The fastest code I write to solve tricky problems tends to involve an hour or
more of thought and drawing and tinkering and examining the existing code and
tracing values and running the debugger, and finally a few minutes of typing.
Sometimes, if I'm very lucky, I simply delete a line or two of existing code
at the end of a half-day's examination and thinking. I then sit back and have
a minor fit of hysteria at what would have happened if I had tried to solve
that problem by typing first.

------
b2hdx
Code things in the absolutely simplest way you can think of and be ready to
throw it away at any time when you think you understand the problem enough and
have a good solution. Don't spend hours trying to design the perfect system,
spend those hours coding it stupidly with the thought that you're going to
throw it away later. Sometimes you do throw it away (but now you've gained a
lot more experience with this particular problem, so coding it again will be a
lot faster and with higher quality), sometimes you don't.

Either way, to code fast you just have to code a lot and throw stuff away a
lot. Don't listen to people telling you to stop and design the program
properly in an organized way before writing a single line of code, it almost
never works properly.

------
awalGarg
Other than what is already covered, somethings that I want every beginner to
know:

\- Writing some comments (somewhat pseudo code) before writing the actual code
_within_ the code file is useful.

\- Do not get obsessed with writing working code at the first try. This
happens a lot to beginners. They write one (or half) a statement of code, save
the file, and build/refresh to see if it is working, then repeat. Please do
not do this. Write code, and you can debug/fix typos later. It also builds up
your confidence.

\- Not reading the errors in the console is a big big big mistake. Please read
the console/error-log/whatever, instead of plainly looking at the code
dumbfound, thinking wtf is wrong with it. (This does not make you write code
faster, but in debugging faster).

Good luck ;)

~~~
coldnebo
Also this!

One of the things that makes me fast is something that was a premise that was
very slow to start with: "every error _means something_ , no error is random,
once you understand the error completely, you usually also understand the
problem."

Almost every time I have ignored an error without understanding it, it has
come back to bite me a hundred ways until I finally get it. It seems faster to
ignore the details and plow on, but those hundred missteps add up vs one sure
step, so practice reading those errors and understanding exactly what they
mean. When you know that you can choose to ignore them, but it's likely it
will be faster to simply fix the problem.

------
ThrustVectoring
Get more sleep, eat better, and work fewer hours.

I wrote a more object-level detailed answer about tools and getting better at
common tasks, but those are just side issues.

If you're tired, you will fuck things up. Fucking things up is much slower
than doing it right the first time.

Similar reasoning for eating well. I'd also recommend intermittent fasting -
the kind of biological effects that digesting food causes aren't good for
thinking well. Plus, breaking for lunch in an interruption, and not eating
lunch is a good way to side-step that.

Working fewer hours is the easiest way to get faster. Pretty much everyone
gets slower at programming later in the day. If you simply don't try to force
yourself through your least productive hours, you're going to be faster on
average.

~~~
n8m
I completely agree with that! I know so many people coding ridiculous hours,
and all they do is causing more problems the next day. _Less hours = Better
focus_

Plan your food and sleep. Probably exercise. Get a fitbit (or similar) and
find your sweet spot (sleep tracking is awesome with those things). When you
feel good- you're most effective.

If you're having deadlines, take long breaks and go back to work after you've
done something different (essentially shift working but within reasonable
hours).

Don't "overdose" yourself with energy drinks, or too much coffee/tea. I have
found that some energy drinks do affect my ability to focus negative. Same
with coffee- too much is limiting (my) ability to focus.

All those things helped me. It can be different for you, but it's probably a
start.

------
mparramont
* Stand on the shoulders of giants. Don't write code someone else already did, better than you [http://www.developingandrails.com/2015/02/a-social-network-i...](http://www.developingandrails.com/2015/02/a-social-network-in-rails-gem-by-gem.html)

* Embrace the keyboard [http://www.developingandstuff.com/2015/01/no-mouse.html](http://www.developingandstuff.com/2015/01/no-mouse.html)

------
larssorenson
I would recommend employing the Agile approach to development. Create and test
a wholly working prototype of whatever you're working on, be it a new feature
or extending a function. The key is that the prototype should not by any means
be the final product, instead aim to create something that is working and
accurate to a small step of the problem; an iterative approach to development.
This way, your tests grow with the functionality of your code and if your code
is well tested, it should function properly at every step of the way. Thus, by
the end, you have a fully implemented whatever that has solid tests and should
"Just Work". If this seems too slow or tedious, you can take the move fast and
break things approach, in which you simply create a rough prototype of how you
think the code should look, and work through the bugs until it does what you
want. You should still write tests, especially to help determine when you've
properly fixed the implementation. Keep in mind this involves a stronger sense
of underlying problems in bugs and needs good debugging skills to be
effective. It can take more time though if your initial prototype is too far
off.

------
yoklov
I'm going to disagree with most of the comments here which say that you can't
become faster, as I have become notably faster over the past couple of years
(perhaps 1.5-2x faster!!).

Basically, it was a fairly major coding style change that happened after
working with others in my industry (game development) and seeing their
prolific output of high quality code.

My process for writing code used to be:

\- Identify problem. \- Identify the abstractions that fit the problem \-
Implement those abstractions \- Write code to solve problem using those
abstractions.

Now it is

\- Identify problem. \- Write code to solve problem, pulling abstractions out
_if and only if they make sense and would actually be used_.

Honestly, I feel this leads to much better, cleaner and more understandable
code, however, it tends not to mesh well with what some people consider best
practices.

The resulting code tends to not be particularly object oriented, tends to have
large functions, and tends to perform very well due to having a very small
distance from what the code says to what actually needs to be executed by the
processor.

For more on this approach, see

[0]: [http://number-
none.com/blow/john_carmack_on_inlined_code.htm...](http://number-
none.com/blow/john_carmack_on_inlined_code.html) [1]:
[http://mollyrocket.com/casey/stream_0019.html](http://mollyrocket.com/casey/stream_0019.html)
[2]:
[https://www.youtube.com/watch?v=rX0ItVEVjHc](https://www.youtube.com/watch?v=rX0ItVEVjHc)

------
perdunov
I've noted that the utter lack of criticism towards your own work makes
programmers significantly faster.

On a more serious note:

1\. Vast and precise knowledge of algorithms and math: to avoid losing time
reinventing the wheel.

2\. Unit testing: to avoid losing time on obscure bugs.

3\. Prototyping: to avoid losing time trying to devise the optimal
architecture beforehand and on inefficient refactoring of the system when it
is already complex.

4\. Rational use of available frameworks and libraries.

~~~
hoodoof
I waste alot of time on self criticism.

------
soroso
IMHO, right now no one really can answer that. There are tools that can help
you speed up, such IDEs and online resources; and of course nothing replaces
practice and experience: the more experienced you are, more patterns of code
you're gonna have from top of your mind, essentially allowing you to jump
faster ahead.

The real problem now, is that the programming languages are now trying to
solve a weird dichotomy. Do you want a language which syntax allows you to
express your ideas in as few lines possible? Or do you want a language in
which the syntax itself is not that important (you'd be OK with
inconsistencies and lack of idioms) but that would have all batteries
included?

So I believe in this case you will need first figure out your programming
identity before worrying about your speed.

If you feel that speed for you means writing fastly well defined algorithms,
you might want to take a look at the modern functional languages. In them, it
really doesn't matter if you type fast or slow, or if you can think fast or
slow, all you need to worry about is to use the proper idioms properly to
achieve an implementation goal. If you manage to choose the right idioms in
the very first time you're writing something, you'll be debugging just tiny
typos.

If you feel that speed is getting things done fast - even if it means you
might be brute forcing your way out of the problem - you might want to take a
look in languages with very rich standard libraries like Java, PHP or Go. All
of them have issues with their syntaxes (respectively verbose, inconsistent
and bland) but because they have extensive standard library all you will to
memorize and practice is the call for tools they offer.

Then, I believe you will be able to say you're faster.

------
hoppi
Anything brand new will be taxing on the brain, once you have solved a similar
problem though it will be easier and faster. Just another case of learning and
utilising what you've already learnt.

Everyone has their own pace, some may just be naturally faster and that is ok.
They also might make more mistakes (bugs).

As other posts have mentioned, learning the language and libraries will help
you massively.

------
johannesboyne
It is a difficult question, and actually not quite clear in what context you
want to gain speed. Is it the pure coding or is it the development of
solutions? I'll go for the later ;)

Structure your work and try to develop a strategy. So think about (w)hat,
(w)hy, ho(w), (w)here, (w)hen. \- What: What is the core problem to solve? \-
Why: If it is a 'problem', why is it a problem, is there an existing solution?
If not, why is the feature important - empathize with the feature request. \-
How: What is your strategy, how do you want to conquer this task? \- Where:
Where does the solution has to be implemented to fit best? \- When:
Programming is a process (a timely and logical sequence of activities which
are required), thus define what step has to be done before the next. Example:
one should not start with the development of a "user scores database" if the
main objective is to build a jump-and-run game.

These steps are helping myself to be more productive.

------
sz4kerto
Be aware that you might not want to be one. Being fast at something implies
that you are really adept in it. I am mostly interested in stuff that's
nontrivial to me, and, as a consequence, I'm not particularly fast in it.
People tend to be very fast in modifying/changing their own code, but not
everyone can/wants to do that.

------
Bahamut
This is the wrong mentality, or is phrased poorly.

What you want is to become a better problem solver - solving problems better
means you can then waste less time with stray thoughts and spend minimal time
coding unnecessarily. For this, I highly recommend trying some elementary math
proof-based texts in number theory, abstract algebra, or real analysis. With
math, you learn how to structure your thoughts in a coherent fashion, then
logically rule out deadend/inefficient lines of approach. Speaking personally,
it has helped me immensely at figuring out the true source of bugs, and
creating the optimal fix for them at an impressive speed - most of this work
is without writing a single line of code.

When it comes to actually writing code, I have found it to just be an exercise
in repetition. As you write more code, you become more familiar with what you
can do, and with the right critical thinking skills, you can then become much
faster.

------
keyle
1- Learn your tools inside out.

Find out which shortcuts would give you the best keystroke / time earned
ratio.

2- Sharpen your skills inside out.

Truth is, to be very fast at something, you must have done it many times
before. I don't believe one can be fast at problem solving if it's the first
time.

Once you get the usual patterns squared, you can get quite fast at
implementing them.

3- Write in a more functional fashion

This has a strong tendencies to reduce bugs and that's where massive time
wasted can go.

4- Improve your understanding

Often slow speed is due to a lack of full understanding. Draw and redraw a
problem on paper until you have a good grasp of the problem. Mix it with other
concepts of real life (ie. arrays and stacks of dishes)

I think we were all slow before we were fast. Still there are many devs faster
than me. That said, I think creatively faster than them. I think we all have
our advantages/disadvantages based on the way that our brain is wired.

------
M8
Forget about maintainability and pick a language that hides errors: Python is
good, JavaScript is even better.

~~~
fsk
Or pick a strongly-typed language, so you can find errors at compile-time
instead of a couple months later when some weird hard-to-reproduce bug shows
up.

------
hopeless
You are not a 1960's typist.

Lots of replies here will tell you to practice typing, or learn your IDE etc.
That's all tactical stuff but I think biggest gains come from not writing the
wrong code to start with. Understand the user; understand their problem, the
real problem; and actually solve it

~~~
falcolas
I agree with this, but learning how to use your tools will provide the initial
boost, and let your tools get out of the way of your thinking.

------
arb99
Things like Vim can speed up coding, you spend less time on the actual editing
of the text. I used to just use vim (macvim in fact), but for php i recently
(1 year?) switched to PhpStorm with a VIM plugin. That was a huge speed
increase, being able to cmd+click on method names and be taken to its code and
probably about 20-30 other features i use in php storm that i never had in
macvim (even with a whole bunch of vim plugins).

(the vim plugin in phpstorm isn't perfect, but definitely good enough)

But I find the biggest speed ups are things like:

\- using frameworks (and knowing about them - so you know everything the
framework contains/can do) speeds a lot of things up. It helps to know a
framework inside out as well as a majority of the popular libraries that are
used with it.

\- And knowing what libraries exist to do whatever job you are trying to do
can save a lot of time. I think almost everyone has at one point coded
something then later on found a perfect library (or even 'snippet') that they
could use and would have saved a lot of time. As long as the library is mature
enough I'd always prefer to include a library and use that rather than spend
hours/a day/days/longer on coding something from scratch. It also helps if
something stops working - you can probably find someone with experience with
that library. Of course it does come with the disadvantage of it might not
100% fit what you need to do...

But it isn't like coding is a race. You often save a lot of time by going
slower and planning things out. I used to plan apps out in a text file, but
realised a few years ago that getting away from the computer and planning out
everything on paper (lots of sheets of paper, lots of arrows, lots of mess,
but in the end it makes sense) gets everything planned correctly before even
coding, so there is no need to refactor big sections of your app. I always
have a notebook of notes when programming now... even with lots of squiggles
and messy handwriting it helps a lot more than notes in text files or even
worse notes (like in depth to do notes) in /* comments */ or //comments .

------
woah
Actually cranking it out faster might be possible, but is probably not useful.
You will see the biggest gains in speed by learning how to code in such a way
that saves you labor in the long run. Expressing your ideas concisely will
allow you to accomplish more with the same amount of code. Expressing them
clearly will allow you to spend less time puzzling about it later. Tooling and
library selection is also big. Know what will save you time and know how to
use it effectively. Lastly, it's also important to know when to stop trying to
abstract and perfect, and just write dumb code to get things done. You've got
to have a good balance of smart and dumb.

------
techjuice
The first step is to insure that you have increased your regular typing speed
(wpm or words per minute) by doing the regular keyboard speed tests. Keep
doing these until your average speed is in the 200 range or higher.

By doing this you will also increase your reading speed which also helps
increases your programming speed. Your mind is the fastest thing you have, it
is the translating of what you are thinking or seeing to typing that slows one
down. This is why there has been work on trying to use your brain waves as an
output device so you can bypass having to type what you are thinking or
reading.

~~~
Erwyn
I assume you were speaking of CPM (characters per minute) and not WPM (words
per minute). Otherwise, I will really would like see you typing on a keyboard
that must be a hell of a show :p

------
funkyboy
Everything mentioned (IDEs, typing, automation) is a great advice. But the
greatest advice I have been given is "the best code is the one that you don't
write". And that's true in my experience. More code means more mess when you
have to debug. It also means more time for another developer to get acquainted
with your project. So before writing something I often ask myself "do I really
_need_ this?" It can be a function, a class, a module or even a graphical
asset. It helped me a lot, both on client and personal projects.

------
eemax
Learn to use your tools (e.g. your text editor, shell, window manager, etc.)
like a pro. Learn keyboard shortcuts and the advanced features, and customize
them to make them your own.

------
Grieverheart
I think the most important is to practice. If you program a lot, you will
eventually be able to do it faster. Your brain will develop a library of
common patterns you will be able to recognize and quickly implement. You will
also have to overcome common problems, such as over analyzing. I found I can
do this by first coding, and then thinking.

Other suggestions, such as using vim or an IDE, or practicing typing, I feel,
will only provide you with a small boost.

------
charlysisto
I believe your asking yourself the wrong question. It should be how do I write
better code ? Being faster (on the long term) can only be a side effect of
resolving this part first...

How ? By deepening techniques :

\- familiarity with the language \- knowledge of good architecture (SOLID if
your in OOP) \- knowledge of the domain you're tackling with \- balancing
abstraction with implementation according to the weight of a problem \- not
overtesting

Yeah becoming faster takes time...

------
roma1n
To gain speed, I'd say get extremely familiar with whatever standard library
your language/platform of choice uses.

Disclaimer: I am not a fast programmer.

~~~
s_kilk
Agreed. one of the biggest speed boosts you can have is not needing to look up
the documentation for your tools every thirty seconds.

So, either get more familiar with the tools, or use simpler, more effective
tools, or both.

------
louwrentius
The programmers who get the fastest results are the ones who sit down and
think/design first before they write a single line of code.

------
azam3d
Tips to be competitive programmer

0\. Type code faster

1\. Quickly Identify Problem Types

2\. Do Algorithm Analysis

3\. Master Programming Languages

4\. Master the Art of Testing Code

5\. Practice and More Practice

Read more about competitive programming free PDF book here. The tips are on
Chapter 1.2

[http://www.comp.nus.edu.sg/~stevenha/myteaching/competitive_...](http://www.comp.nus.edu.sg/~stevenha/myteaching/competitive_programming/cp1.pdf)

------
DrJokepu
Try to solve problems with less and less code. It will be quicker to write and
you'll have a smaller number of bugs to fix.

------
lwh
Sit in a quiet room, alone

------
SaimonSL
I worked on 100 of projects and my answer is by lowering the repeat cycle,
which is done by test driven development "rspec" or other testing tools. The
more detailed test the better but not too detailed. Also don't re-invent the
wheel, use library that already exist, maintained and has community support.

------
gamesbrainiac
Build a network, and ask for help whenever you are trying to do something
unfamiliar. The problem is never how fast you write code, but how quickly you
can add new features.

Having a large and supportive network allows you to quickly overcome obstacles
and piggy back off of other people's expertise while developing your own.

------
polskibus
You are faster when you solve a given problem for the second time in your
life.

By solving a problem I mean not just decomposing it mentally but also
executing the solution with chosen technical framework.

Practice a lot, pick a framework or two and understand its inner workings very
well - that's my advice.

------
chrisxcross
Don't google every error and use the top answer on stackoverflow to fix ist.
Read the docs and try to understand why your solution didn't work in the first
place. Basically this results in getting familiar with stdlibs and/or
frameworks.

------
device_exec
here is list of things that have helped me over time to do rapid development
while keeping it structured

1\. Clearly understand the goal and see it through the architecture/design
pattern that the code is supposed to take

2\. Know and memorize the basics and the system environment. If you are
learning the system, have a handy debugger

3\. Take a writers approach to coding. Breeze through your program while
maintaining styling/design requirements. Add TODO's wherever you think more
attention might be necessary but unimportant at the time.

4\. Usually during development multiple problems need to be solved in the same
function/file which creates frustrating distractions. If you face this
constantly try meditation, it works!

------
auganov
I'd say do "real" work everyday. Minimize programming "downtime". As brutal as
it sounds, for me there's nothing worse than being out of the loop.

------
anthonyby
@flyinglizard already mention zen-like style. So, stop using stackoverflow
programming and do really deep digging about every aspect.

------
freedevbootcamp
I agree with sairamkunala. Learn your editor. If you use vim or sublime, start
looking for plugins that make you more productive.

------
interdrift
I do the following : I solve problems for a certain period of time as fast as
I can and try to improve my previous score.

------
therealidiot
Heavy use of IDE shortcuts can help

------
gprasanth
[http://typing.io/](http://typing.io/)

------
chipsy
You can't solve individual problems faster(unless they're familiar problems,
which doesn't make you an "overall better" programmer, just better in that
problem domain). Every programmer tends to fall within a certain range of
time-to-solutions when they encounter a novel problem for the first time.
Innate ability is, in the end, not something worth worrying about because it's
also not a "universal", it applies to particular problems just like domain
knowledge. What you can do is create a workflow where you have fewer
incidental problems, and so you end up being faster and more accurate in your
coding all the time because you just don't run into trouble.

1\. Can you write less code? Not just code-golfing, although that is worth
experimenting with(see Arthur Whitney's code. Make an honest attempt to "get
it" without just giving up). You'll have to develop your own metric, but some
combination of - lines of code, new names declared, branch points, nesting,
subroutine length, etc. can usually tell you if you're progressing.

2\. Can you use fewer language features? There is an ingrained tendency in
many programmers to jump onto everything new in fear of being left behind, and
then use all of it at once on a project where it's wholly inappropriate,
becoming "that guy" who constantly reveals compiler bugs. But the features
that last over multiple generations are the key: People shipped good software
with it before, and they'll do so again, so if you stick to a conservative
subset and roll your own abstractions otherwise, you can use familiar
techniques everywhere, but enjoy an incrementally smoother experience with the
newer environments. (Of course, at the extreme end you also become "that guy"
who is coding everything like it's the 1960's, but at least that means that
you are probably productive in some way, if not really up to speed.)

3\. Although I dismissed familiarity in specific problem domains above,
diversity of experience with specific problems is better for your overall
abilities, because the natural grain of problems exposes different styles of
coding.

4\. Do you know your tools? Not just "I can use my text editor and compiler,"
but rather, have you tried to deeply evaluate all the technology available? If
you can use a simpler toolset, that's usually better, because something
simpler is easier to extend or replace. Something that is deep and intricate
and complicated is bad, because it becomes an edifice. True of the code you
write, of your coding environment's configuration, and of the tools you work
with, be it editing, builds, source control, etc. If you rely on a debugger
for everything, then you're at a disadvantage when you don't have it. So you
have to adapt to the situation.

5\. Do you put the data first? This is the flip side of the "edifice" remark -
your code never lasts, but your data does, and, less frequently but perhaps
even more importantly, protocols and formats you invent for passing around
data also last. If you're taking good care of the data, everything else become
possible. But if you tangle it up in a way that makes it hard to work with,
everyone gives up.

------
hasenj
I don't think a good programmer is a fast programmer.

Good programmers can solve problems and move beyond obstacles. Mediocre (or
bad) programmers can do some basic things but quickly hit walls and don't know
how to proceed.

Building quality software takes time. There's no way around it.

> At the moment I feel like I have no choice but to go at the pace that my
> mind allows me to operate at.

That will always be the case.

The only way to be "faster" is if you have more knowledge about the domain
you're working with and the technologies you are using.

