Hacker News new | comments | show | ask | jobs | submit login
Ask HN: How do I become a faster programmer?
53 points by hoodoof on Mar 21, 2015 | hide | past | web | favorite | 65 comments
I want to be a faster programmer, to increase my coding speed.

How can I do that? Is it even possible?

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




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.


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.


I guess it depends on the seriousness of what you're doing. In programming normal, non-critical code, Python and exploratory programming will speed you up quite a bit.

But if most of your time is spent debugging, then taking your time is probably worth it. And use tools that makes a lot of bugs impossible: Use a memory-safe language with strong typing and concurrency abstractions that prevent data races etc.

If you're making a big system where remembering where everything is is half the job, a good IDE with solid auto-complete might help. I'm a big fan of MS Visual Studio, though it has limited programming language support. I've heard good things about Intellij too.

If most of the code will be written by someone else then you want an opinionated programming language that enforces a certain style, like Ada or Go.

Finally, if your problem has already been solved, don't solve it again. Use Erlang for distributed systems, Ada for critical systems, Esterel for extra-critical systems that can afford to be slow, etc.


As a corollary to this, increase the size of your toolkit. The more tools you have available to you, the more likely you are to have a tool which solves the current problem in a way which is correct, clear, and concise. You'll also be better able to determine when to, and when not to, re-invent the wheel.

By toolkit, I mean:

- Programming paradigms

- Patterns (and Anti-Patterns)

- Metaprogramming

- Knowing when to mutate, and when to not mutate

- Algorithms

- Data Theory

- Knowing the value of stepping away from your code


The analogy I like is cornering a race car. The fastest way through a turn is a combination of velocity, distance, and traction. If the speed is too great, the line is too long. If the line is too tight, exit speed is too low.

Or the race car spins out.


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


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.


This is the answer I was looking for. Especially point 1.

Wish I could give multiple upvotes.

Organized optimization!


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.


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/...


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.


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.


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.


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.


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.


Great point about debugging.


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.


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.


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


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.


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.


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.


Morning people tend to get slower later in the day. Night people actually tend to get faster.

(There is some research that backs this up: http://www.personal.psu.edu/afr3/blogs/siowfa12/2012/09/earl...)

Know yourself and work during your peak time, not someone else's.


* 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...

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


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.


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... [1]: http://mollyrocket.com/casey/stream_0019.html [2]: https://www.youtube.com/watch?v=rX0ItVEVjHc


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.


I waste alot of time on self criticism.


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.


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.


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.


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.


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.


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.


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


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.


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


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.


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 .


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.


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.


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


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.


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.


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.


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.


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


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.


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.


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.


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_...


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.


Sit in a quiet room, alone


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.


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.


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.


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!


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.


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.


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


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


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.


Heavy use of IDE shortcuts can help



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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: