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.
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.
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.
> 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.
Or the race car spins out.
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
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).
Wish I could give multiple upvotes.
Organized optimization!
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.
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/...
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.
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.
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.
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 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.
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.
(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.
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.
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.
- 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 ;)
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.
* Embrace the keyboard http://www.developingandstuff.com/2015/01/no-mouse.html
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
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.
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.
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.
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.
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.
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.
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
(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 .
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.
Other suggestions, such as using vim or an IDE, or practicing typing, I feel, will only provide you with a small boost.
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...
Disclaimer: I am not a fast programmer.
So, either get more familiar with the tools, or use simpler, more effective tools, or both.
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_...
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.
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.
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!
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.
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.