4 ms·

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 fix

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.

tormeh 12y ago
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.
jameskilton 12y ago
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.
brudgers 12y ago
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.
falcolas 12y ago
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

tormeh 12y ago

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.

jameskilton 12y ago

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.

brudgers 12y ago

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.

falcolas 12y ago

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