Ask HN: Coding Quickly; How?
30 comments
If you're a novice, of course it is normal to consult outside resources a lot. With PHP it will require an obscene amount of memorization since there aren't really any strict naming or parameter conventions within the builtins lib. Plus, you've got to recall everything about the framework, too. I've been developing with Django for a couple years now and I still have to look up stuff I don't use that often. It just isn't efficient to try to memorize every single detail.
Don't worry too much about people who claim to have made an app in 30 hours or something. Chances are they (a) used something familiar to them and (b) most of the code came from existing libraries, APIs, etc. For what it's worth, I flag everything with some sort of development time in the title because I find it to be both arrogant and largely irrelevant (you made a URL shortener in 5 hours?! Do you want a cookie?!).
If you want to write code faster, write more code. You will get faster. That's about it.
Don't worry too much about people who claim to have made an app in 30 hours or something. Chances are they (a) used something familiar to them and (b) most of the code came from existing libraries, APIs, etc. For what it's worth, I flag everything with some sort of development time in the title because I find it to be both arrogant and largely irrelevant (you made a URL shortener in 5 hours?! Do you want a cookie?!).
If you want to write code faster, write more code. You will get faster. That's about it.
That's the single best reason to use a good IDE live VS.NET + ReSharper. There's simply no reason to ever pull up the documentation because it is all right there.
Need to do something with Sockets? Type "sock"+SHIFT+CTRL+SPACE and a list pops up with everything you can do with Sockets, even if it's stuck way at the bottom of some obscure namespace you never would have found (let alone thought to import). All the classes have descriptions and constructor info. All of it is hooked into the docs and examples with F1.
I've done Django in Eclipse recently, and I'm currently doing a bit of PHP consulting, also in Eclipse. Even with all the right plugins, I still find myself on Google constantly, just like you describe. It's frustrating being expected to memorize things, especially when you know that you wouldn't need to if only you had better tools.
Need to do something with Sockets? Type "sock"+SHIFT+CTRL+SPACE and a list pops up with everything you can do with Sockets, even if it's stuck way at the bottom of some obscure namespace you never would have found (let alone thought to import). All the classes have descriptions and constructor info. All of it is hooked into the docs and examples with F1.
I've done Django in Eclipse recently, and I'm currently doing a bit of PHP consulting, also in Eclipse. Even with all the right plugins, I still find myself on Google constantly, just like you describe. It's frustrating being expected to memorize things, especially when you know that you wouldn't need to if only you had better tools.
In general, having O(1) access to everything you need during development will greatly increase your productivity (it will help achieve and sustain flow more often). You might (or rather, will) have to write some tools to achieve that. This is where having an easily extensible environment like Emacs comes in.
"Chances are they (a) used something familiar to them and (b) most of the code came from existing libraries, APIs, etc."
That's almost always true, but perhaps that's the lesson right there. People (other than development snobs) don't care what you used to build it or whether you had prior experience in the field, but they do care that you can get something to them quickly that satisfies their needs. So maybe the takeaway is a.) learn some useful libraries, and learn them well and b.) use what's familiar to you.
That's almost always true, but perhaps that's the lesson right there. People (other than development snobs) don't care what you used to build it or whether you had prior experience in the field, but they do care that you can get something to them quickly that satisfies their needs. So maybe the takeaway is a.) learn some useful libraries, and learn them well and b.) use what's familiar to you.
I am a huge proponent of writing as little code as possible. To that end, making use of third-party libraries, frameworks, and so on are marks of a great programmer (to me). Even still, a product should speak for itself; it should not have to be justified by the amount of time it took to create it.
(b) most of the code came from existing libraries, APIs, etc
In my opinion the "X in Y hours" articles can be useful. If they can make a fully functional service in a short time due to libraries, those APIs and libraries might be of use for others.
If someone made an article called "Copy of Google Reader in X hours" that used a good JS and feed parser library, it would be interesting to many that would otherwise not know about these libraries
In my opinion the "X in Y hours" articles can be useful. If they can make a fully functional service in a short time due to libraries, those APIs and libraries might be of use for others.
If someone made an article called "Copy of Google Reader in X hours" that used a good JS and feed parser library, it would be interesting to many that would otherwise not know about these libraries
I measure my production time in days, not hours, so any tips on just how to "code quicker"?
Code less.
That isn't being flippant. Code you don't write is code you don't have to debug. It is code you don't have to integrate with your other functions. It is code you don't have to refactor. It is code that requires no maintenance.
I got the first version of my application up, running, and out the door in 8 days at a "normal work week" rate. I'm not a particularly good programmer, I just cut the feature set for 1.0 to the bone. Since then it has been three years now of iterations on the existing codebase that typically add a just a few hundred lines at a time.
I also rely -- heavily -- on libraries and frameworks that do stuff better than I could, and on Google for code references whenever I'm doing something which is new to me. (It took me probably 3 years until I could write Swing apps without a browser open. By that standard you'd think I'd be able to do it for Rails by now... but not quite, unless it is a pretty basic app.)
Code less.
That isn't being flippant. Code you don't write is code you don't have to debug. It is code you don't have to integrate with your other functions. It is code you don't have to refactor. It is code that requires no maintenance.
I got the first version of my application up, running, and out the door in 8 days at a "normal work week" rate. I'm not a particularly good programmer, I just cut the feature set for 1.0 to the bone. Since then it has been three years now of iterations on the existing codebase that typically add a just a few hundred lines at a time.
I also rely -- heavily -- on libraries and frameworks that do stuff better than I could, and on Google for code references whenever I'm doing something which is new to me. (It took me probably 3 years until I could write Swing apps without a browser open. By that standard you'd think I'd be able to do it for Rails by now... but not quite, unless it is a pretty basic app.)
"Code less."
I find this philosophy depressing in the long run. If the first concern that pops to mind whenever you need to add a feature or change something is "how can I do this in the least amount of code", you'll be depressed when comes the time to code something that simply inherently takes a huge amount of code to tackle. You'll be less likely to make that big refactoring that would greatly enhance the consistency of your codebase and facilitate further developments.
As it is, my codebase is a place I spend most of my life in, so I like to keep the place tidy and know where everything is. I want to feel at home in my home.
I find this philosophy depressing in the long run. If the first concern that pops to mind whenever you need to add a feature or change something is "how can I do this in the least amount of code", you'll be depressed when comes the time to code something that simply inherently takes a huge amount of code to tackle. You'll be less likely to make that big refactoring that would greatly enhance the consistency of your codebase and facilitate further developments.
As it is, my codebase is a place I spend most of my life in, so I like to keep the place tidy and know where everything is. I want to feel at home in my home.
Coding less is key. But, for the code you do have to write, and for deciding exactly how to code less, the underlying talent has to do with managing risk by decomposing your problem into small chunks.
Once you have your "problem" pared down to the minimum needed, if you can decompose your system into lots of small parts that you can analyze easily and make darn sure are correct, then you can code without having to backtrack and do costly debugging. You'll also find that writing the code also goes more quickly once you do this. "Knowing where to start" also becomes much easier if you do this.
Once you have your "problem" pared down to the minimum needed, if you can decompose your system into lots of small parts that you can analyze easily and make darn sure are correct, then you can code without having to backtrack and do costly debugging. You'll also find that writing the code also goes more quickly once you do this. "Knowing where to start" also becomes much easier if you do this.
Code less.
Start out with a plan, and spend as little time as you can in the prototype/experiment stage. Write down what you need to do to create a "minimum viable product".
A minimum viable product model is what all "coded in X hours" web-apps create. Quite literally, just launch as soon as physically possible; if you expect not-required-but-cool-feature-1 to take an extra 2 hours to create, and you really think would add quality to the product without adding unnecessary bulk, then just add it to the 'post-launch to-do list'. You have a massive advantage creating a web-app — the ability to instantly add features after 'launch'. Don't waste it!
And to help with creating a minimum viable product, always do Test Driven Development. While this actually adds to the amount of code you have to write, generally you will get the app finished quicker, or at the very least, it'll help you stay on track.
Cutting the feature set is by far the best way to speed up your launch time. And you'll get a huge amount of new perspective on what features are really necessary once the product is out there with people using it. So, take a good hard look at everything you think needs to be in v1, then cut that in half.
I think that the more you code in a language the quicker it will come to you. For example I can usually churn out python, which I've been using for a while. However I'm just starting Objective-C and I need to consult Apple's reference library every other line of code. But it's not like riding a bike. I used to be able to write Fortran code like mad and now I can barely remember any of the syntax at all(possibly a good thing).
My issue is not so much remembering syntax and common algorithms but "brain drain" and typically take breaks all too frequently. Hacker News does not help with this.
My issue is not so much remembering syntax and common algorithms but "brain drain" and typically take breaks all too frequently. Hacker News does not help with this.
My understanding is that BillG had to rip the radio out of his car back in the day. He needed to think, and he couldn't stop himself from listening to music while he was driving.
We have the noprocast feature.
We have the noprocast feature.
Noprocast is a good feature, but I use SelfControl(http://visitsteve.com/work/selfcontrol/) to block other sites as well. Highly recommended.
"Is it normal practice to consult php.net and google like mad when developing?"
If by php.net you mean the language manual, then yes. You will consult the language manual less and less, but you will always have new libraries to pick up, not to mention platform documentation.
Eventually you will know so many different things that you will seek to learn how a given system differs from another system you already know. You will end up getting a book on a new technology you have never used and jump straight to chapter 5, for example, or flip to the appendices, or read the dense 50 page spec over a cup of coffee. Sometimes, specially for protocol wrappers, you might skip the whole manual and retain the help of a disassembler of a packet sniffer. Sometimes you will start attacking a given implementation from its weak entry points: first the test cases, to see how something is used; then the header files, etc. You can skip on a whole new fangled thing by reading the BUGS and TODO files, if they exist (be weary of their absence more than their presence.) You will get an eye for the brittle by skimming the source and see how the developers implemented a few standard things. I have dumped way too many weak C system applications by just looking at how the developers implemented command-line parsing, for example. This will help you narrow down what you actually need to use, and from there you can choose the easiest one to learn of the few good remaining options (at some point you will learn to isolate library use-points by wrapping calls to other people's code in functions/modules, so you can replace them in one tidy place.)
At some point, also, you will end up googling for error messages more than actual tutorial help. This is specially true if you're interfacing with infrastructure software like an RDBMS or system libraries.
It always takes long to write the first solution, but as you write many different kinds of software, you will develop a portfolio of useful solutions you can apply in other works. Projects that are written fast are also the ones that don't teach you anything; it's not flattering to have churned out something quickly, it just means you're not pushing yourself (which shouldn't be a goal in and of itself, btw.)
Don't worry about the speed of development and just try to write small, fun programs that solve your immediate needs (if no need is apparent, then brag points; nothing motivates like the kudos of your peers. Ok, maybe cash, a red Ferrari and a night at the Vegas strip ;-)
At some point, also try to broaden your horizons. PHP is not exactly a fun thing to work with.
If by php.net you mean the language manual, then yes. You will consult the language manual less and less, but you will always have new libraries to pick up, not to mention platform documentation.
Eventually you will know so many different things that you will seek to learn how a given system differs from another system you already know. You will end up getting a book on a new technology you have never used and jump straight to chapter 5, for example, or flip to the appendices, or read the dense 50 page spec over a cup of coffee. Sometimes, specially for protocol wrappers, you might skip the whole manual and retain the help of a disassembler of a packet sniffer. Sometimes you will start attacking a given implementation from its weak entry points: first the test cases, to see how something is used; then the header files, etc. You can skip on a whole new fangled thing by reading the BUGS and TODO files, if they exist (be weary of their absence more than their presence.) You will get an eye for the brittle by skimming the source and see how the developers implemented a few standard things. I have dumped way too many weak C system applications by just looking at how the developers implemented command-line parsing, for example. This will help you narrow down what you actually need to use, and from there you can choose the easiest one to learn of the few good remaining options (at some point you will learn to isolate library use-points by wrapping calls to other people's code in functions/modules, so you can replace them in one tidy place.)
At some point, also, you will end up googling for error messages more than actual tutorial help. This is specially true if you're interfacing with infrastructure software like an RDBMS or system libraries.
It always takes long to write the first solution, but as you write many different kinds of software, you will develop a portfolio of useful solutions you can apply in other works. Projects that are written fast are also the ones that don't teach you anything; it's not flattering to have churned out something quickly, it just means you're not pushing yourself (which shouldn't be a goal in and of itself, btw.)
Don't worry about the speed of development and just try to write small, fun programs that solve your immediate needs (if no need is apparent, then brag points; nothing motivates like the kudos of your peers. Ok, maybe cash, a red Ferrari and a night at the Vegas strip ;-)
At some point, also try to broaden your horizons. PHP is not exactly a fun thing to work with.
The fastest way for me to code is to unplug from the internet completely. Get all your necessary documentation available in offline documents so that when you code, you don't get distracted by Hacker News :-).
Plus, your memory tends to improve since you'll actually be able to figure stuff out on your own than googling every little thing.
Plus, your memory tends to improve since you'll actually be able to figure stuff out on your own than googling every little thing.
this is _really_ good advice - I find when I'm coding in a coffee shop then I feel more productive because the internet is a really big distraction.
I have the documentation on my laptop as well as the framework source code, so whenever I need to look someting up it's there. Having to make an effort to look stuff up means that my brain has more of an incentive to memorise it.
And practise, practise, practise. These things come over time.
I have the documentation on my laptop as well as the framework source code, so whenever I need to look someting up it's there. Having to make an effort to look stuff up means that my brain has more of an incentive to memorise it.
And practise, practise, practise. These things come over time.
Focus on being efficient rather than quick. Charging off in the wrong direction will slow you down. Paralyzing yourself by over-complicating decisions will slow you down. Move forward at a steady rate and you will get things done faster.
Of course, there is an element of experience and practice. To mitigate this, select good tools and learn them well. You should not need to consult php.net because you should have an editor that provides inline help. You should not frequently need Google because you should have a smattering of algorithms and idioms that can be re-applied. (For example, a large class of text validation and processing problems can be solved trivially with regular expressions.) "Recipe" style books can assist in developing go-to approaches for common classes of problems. Knowing the important bits of the standard library will help you avoid writing unnecessary code.
Last, but not least, avoid writing code that you don't need right now. This can be big stuff like features you haven't thought through very well. Or it can be small stuff. For example, there's an unfortunate tendency for people trying to do object-oriented programming to define getters and setters for everything. There's no reason to do this (in fact, there are plenty of reasons to not do this, but that's for another discussion) and these little wastes of time start to add up fast.
Of course, there is an element of experience and practice. To mitigate this, select good tools and learn them well. You should not need to consult php.net because you should have an editor that provides inline help. You should not frequently need Google because you should have a smattering of algorithms and idioms that can be re-applied. (For example, a large class of text validation and processing problems can be solved trivially with regular expressions.) "Recipe" style books can assist in developing go-to approaches for common classes of problems. Knowing the important bits of the standard library will help you avoid writing unnecessary code.
Last, but not least, avoid writing code that you don't need right now. This can be big stuff like features you haven't thought through very well. Or it can be small stuff. For example, there's an unfortunate tendency for people trying to do object-oriented programming to define getters and setters for everything. There's no reason to do this (in fact, there are plenty of reasons to not do this, but that's for another discussion) and these little wastes of time start to add up fast.
You still consult Google and the language reference, but much less frequently. Generally, if you want to get feature release time down to hours instead of days, you'll need to have the "core" of the language in memory. That usually includes language syntax, string methods, data structures API, whatever basic IO library you're using (files/database/network), and various other simple utilities. You'll know when you see them, because you see them repeatedly.
The other point that I haven't seen brought up here is to have a clear goal in mind. Know what you're building, because you can't build it otherwise. Unfortunately, this is often kinda tough if you're developing a new product, because your initial ideas for what makes a good product are almost always wrong, and you tend to discover that as you start implementing. So I've found it helps to think of your code as temporary: I know what I'm building this iteration, and I'll just go code it up and see how it works, but it's assumed that I'll have to throw it away anyway and build something better next iteration.
The other point that I haven't seen brought up here is to have a clear goal in mind. Know what you're building, because you can't build it otherwise. Unfortunately, this is often kinda tough if you're developing a new product, because your initial ideas for what makes a good product are almost always wrong, and you tend to discover that as you start implementing. So I've found it helps to think of your code as temporary: I know what I'm building this iteration, and I'll just go code it up and see how it works, but it's assumed that I'll have to throw it away anyway and build something better next iteration.
I wrote the first version of my app in 2 hours - but it took a year of iteration to become a salable product.
(1) the first version worked, but it was the minimal feature set you could imagine. That's one way to code fast.
(2) The 2 hours doesn't include thinking about it, designing it and using other tools in the same area. So I really just typed it in 2 hours. The lack of bugs just showed that I understood the problem, and that the design of the code was simple enough to be trivial to debug (and having minimal features). This is another way to code fast.
I use google, docs, etc for sample code. I use it in two ways: (1) to help me understand; and (2) if it's not at the core of what I'm doing, I'll imitate how others do that part (e.g. how to use an API). The idea is to carefully apportion my time and energy - it's easy to waste heaps of time understanding something incidental to my task, when that time and effort is needed for understanding the important things.
Understanding is the difficult part. That's what programming is really about for me - not the looking up docs/typing/debugging.
(1) the first version worked, but it was the minimal feature set you could imagine. That's one way to code fast.
(2) The 2 hours doesn't include thinking about it, designing it and using other tools in the same area. So I really just typed it in 2 hours. The lack of bugs just showed that I understood the problem, and that the design of the code was simple enough to be trivial to debug (and having minimal features). This is another way to code fast.
I use google, docs, etc for sample code. I use it in two ways: (1) to help me understand; and (2) if it's not at the core of what I'm doing, I'll imitate how others do that part (e.g. how to use an API). The idea is to carefully apportion my time and energy - it's easy to waste heaps of time understanding something incidental to my task, when that time and effort is needed for understanding the important things.
Understanding is the difficult part. That's what programming is really about for me - not the looking up docs/typing/debugging.
Coding is a lot like cooking. Sure, it's fun to cook from scratch, but if you're running a restaurant (cooking for a living, in other words), you'd better learn to get most of the hard work done before the dinner crowd hits. "Mise en place", they call it.
Developing works pretty much the same way -- they key to quickness when you need it is to have most of the grunt work done beforehand. That comes partly free with language features and libraries, but you'll find that, over time, you will have amassed a lot of code that pretty much does what you need. If you've done that properly, you'll find that you have essentially "added features" to the language you're working in -- and after a while you will find yourself writing code not in PHP, but in your own dialect of PHP (or whatever the core language is). That class (or function) that took you all day to write and debug? It takes 5 seconds to include it the next time you use it. That coupla annoying lines you seem to type every time you open your IDE/editor? Save them as a snippet or make them part of your default boilerplate -- it's quicker to select them and delete than it is to retype the damned thing when you need it. That part of it does take time to accumulate.
Even when the problem is a new one, it's often faster to extend the language in the ways you need it to be extended before you tackle the big picture. Some languages are a little easier to program bottom-up like that (PG gives excellent illustrations of that in the essays "Programming Bottom-Up" and "Beating the Averages"), but you can do something very like that in almost any language, and there's no better time to start than now. But do remember to add your greatest hits to your personal language library -- it'll save you loads of work if you ever need it again.
Developing works pretty much the same way -- they key to quickness when you need it is to have most of the grunt work done beforehand. That comes partly free with language features and libraries, but you'll find that, over time, you will have amassed a lot of code that pretty much does what you need. If you've done that properly, you'll find that you have essentially "added features" to the language you're working in -- and after a while you will find yourself writing code not in PHP, but in your own dialect of PHP (or whatever the core language is). That class (or function) that took you all day to write and debug? It takes 5 seconds to include it the next time you use it. That coupla annoying lines you seem to type every time you open your IDE/editor? Save them as a snippet or make them part of your default boilerplate -- it's quicker to select them and delete than it is to retype the damned thing when you need it. That part of it does take time to accumulate.
Even when the problem is a new one, it's often faster to extend the language in the ways you need it to be extended before you tackle the big picture. Some languages are a little easier to program bottom-up like that (PG gives excellent illustrations of that in the essays "Programming Bottom-Up" and "Beating the Averages"), but you can do something very like that in almost any language, and there's no better time to start than now. But do remember to add your greatest hits to your personal language library -- it'll save you loads of work if you ever need it again.
I've been programming ruby on rails apps for about 9 months now and I can tell you that things definitely speed up over time. I still have a few browser windows open with the ruby and rails apis ready, and I still make heavy use of google to solve problems quickly. I think it's the little steps that individually don't cost much but on aggregate really slow you down that will steadily disappear and improve your efficiency.
Sharpen your tools and remember the problems you are trying to solve. Building software is just like building anything else and the first effort should be getting your tools in the proper state - that means having a good IDE, a good and private workplace, clean directory structures on your (hopefully linux) PC. Basically, you should learn programming environments (eclipse, emacs) and PCs (how exactly does this thing work? Coding = telling a computer what to do). Knowing what problem you are really trying to solve will avoid the biggest pitfall in programming - premature optimisation. Get your environment setup, focus in and separate problems into various smaller, isolated sub-problems. Stay clear on what you are doing and don't get side tracked by "interesting" problems. Honestly, I would say you should try to get away from PHP and learn a proper compiled language - Java is my favorite.
Consulting php.net isn't an issue. I've been programming PHP for years and the language is so inconsistent I wouldn't be surprised if even the developers check their documentation every so often.
But, please, don't code for speed, code for quality. I can't tell you how many cesspools I've seen as a result of "rapid development". Namely, Lighthouse and github are some of the buggiest and unstable applications I've ever used.
They're still great applications, but dammit, when every new ticket goes to a milestone that expired years ago (Lighthouse) and I currently have "-1" unread messages (github), I can't help but be annoyed. Lighthouse more than github.
But, please, don't code for speed, code for quality. I can't tell you how many cesspools I've seen as a result of "rapid development". Namely, Lighthouse and github are some of the buggiest and unstable applications I've ever used.
They're still great applications, but dammit, when every new ticket goes to a milestone that expired years ago (Lighthouse) and I currently have "-1" unread messages (github), I can't help but be annoyed. Lighthouse more than github.
We spent months building GitHub's issue system and had a lengthy beta period. No one experienced the bug you're referring to until the feature went public. Shit happens, you fix it and move on.
Don't get me wrong, I love github, but it seems like every bug on sites I use exists on a site that was developed with Rails or some other framework that advertises rapid development. I'm not accusing you of incompetence, but out of every site I go to it's the one that's most often got some feature disabled because it was too buggy, unplanned, or what have you. Granted, it's also the one with the most new features popping up.
Yes, shit happens, but there's a pretty strong correlation between agile development and bugginess, whether it's the mentality it encourages or some other factor.
Yes, shit happens, but there's a pretty strong correlation between agile development and bugginess, whether it's the mentality it encourages or some other factor.
Thanks, I was considering if someone were to say "don't worry about being fast". Since I like sports, I made it a point to say "quick", because in sports being fast could mean messing up and being sloppy, whereas "quick" has a much more positive connotation. I do NOT value making sloppy code, rather I'm just hoping I can learn from guys much better than me, and how they work smarter.
Thanks for the comment.
Thanks for the comment.
It takes about two years to become deeply proficient in any language/framework. Up until then you'll get faster, look stuff up less, and churn out code faster.
Unrelated to that is the domain-specific knowledge, which has a different effect - you don't get faster, you learn what code to write, and more importantly, what code not to write. In the long run, it probably has more effect on productivity than being comfortable with a language. How long this takes really depends on the domain.
My experience with 10x programmers (I don't count myself in that group) is that it's the second area where the big productivity gains lie.
Unrelated to that is the domain-specific knowledge, which has a different effect - you don't get faster, you learn what code to write, and more importantly, what code not to write. In the long run, it probably has more effect on productivity than being comfortable with a language. How long this takes really depends on the domain.
My experience with 10x programmers (I don't count myself in that group) is that it's the second area where the big productivity gains lie.
Something that Google's first employee said recently stuck with me: "I would say the single most important thing an engineer can do to be effective is to pick the right problem to work on." Alas, he had no idea how to do that (or rather, he obviously had a very good idea how to do it, but was unable to put it into words), but the quote resonates a lot with my experience. I've wasted so much time on projects that in retrospect weren't really all that important - I coded them quickly, and learned quite a bit that came in handy later, but the problems themselves were basically non-problems.
My stats prof used to take about "Type 3 errors." Type 1 and 2 errors are part of a basic stats course. Type 3 = "solving the wrong problem."
My understanding of type III was that it was "Right for the wrong reasons." I suppose it might not be a standard term ;-)
What ojbyrne said. Also, something that takes quite a bit of time to learn is when to give up on a library/framework and just reinvent the wheel (which I recently did---nftw() did everything I needed, except I couldn't get it to not follow symlinks; I found it easier to roll my own version).
Not to language flame, but I think that php has a longer learning curve in this respect. Because of the huge number of functions available, there's a lot to memorise.
Learning an API is the hardest part of any new technology because of all the rote work.
Contrast this with something like python/django or ruby/rails - sure there's a lot to learn in the frameworks, but the language themselves are fairly small.
This means glue code is really quick to write, and you only really have to look at the framework documentation.
Learning an API is the hardest part of any new technology because of all the rote work.
Contrast this with something like python/django or ruby/rails - sure there's a lot to learn in the frameworks, but the language themselves are fairly small.
This means glue code is really quick to write, and you only really have to look at the framework documentation.
"How do I get to Carnegie Hall?"
"Practice, practice, practice."
One thing, though: "Fast programmers" are not monolithic. Yes, you will be faster in an environment where you are not constantly looking up API functions. The world's fastest Perl developer that has never encountered Erlang is not going to turn into a fast Erlang developer overnight. He'll learn Erlang better than a novice will given the same amount of time, but it will still take time.
"Practice, practice, practice."
One thing, though: "Fast programmers" are not monolithic. Yes, you will be faster in an environment where you are not constantly looking up API functions. The world's fastest Perl developer that has never encountered Erlang is not going to turn into a fast Erlang developer overnight. He'll learn Erlang better than a novice will given the same amount of time, but it will still take time.
more practice.
reading code also helps.
But if coding, anything new (anything meaning - anything outside the domain(or even the current library) can put me off. When this happens,I feel like i have no control over the language, then I look it up and find more features, better ways to implement it, get depressed about my ignorance. The better of us here learn to implement it anyway and get better.
I should also add - I've been coding well over 5 years and the looking up web resources has deferred my learning any language via implementation. There is always some code online that I can refer to and refactor to my needs. Now, I find it hard when I want to code the same logic by myself. (Wonder how many have the same feel..I know many of you are true hackers, but how about the few of us?) AND when I try to implement without looking up, it really strains me and takes a lot of time(which i don't get in my enterprise world!) and plus the fake ego of having x years of x language and not able to write a working program.
Anyone?
But if coding, anything new (anything meaning - anything outside the domain(or even the current library) can put me off. When this happens,I feel like i have no control over the language, then I look it up and find more features, better ways to implement it, get depressed about my ignorance. The better of us here learn to implement it anyway and get better.
I should also add - I've been coding well over 5 years and the looking up web resources has deferred my learning any language via implementation. There is always some code online that I can refer to and refactor to my needs. Now, I find it hard when I want to code the same logic by myself. (Wonder how many have the same feel..I know many of you are true hackers, but how about the few of us?) AND when I try to implement without looking up, it really strains me and takes a lot of time(which i don't get in my enterprise world!) and plus the fake ego of having x years of x language and not able to write a working program.
Anyone?
When you hear us talking about how fast we can move, we neglect to point out the years of moving slow that got us to this point.
I have 10 years worth of C# and Javascript libraries that I've written to handle just about any situation I can come across, as well as a home-built data framework that's more powerful than Rails, and an automated build & deploy setup that can get a new project up in minutes. These are the reasons why I can crank out a new database driven site in a matter of hours. No matter what it is, it's mostly already built.
So my advice would be to simply do your job and put in the time. Pay attention to the things that slow you down and write libraries that speed those things back up. Build yourself a set of tools and constantly improve them.
Five years from now, you can crank out a one-day clone of whatever flavor-of-the-month billion dollar site is popular at the time, and everybody will thing you're a genius.
I have 10 years worth of C# and Javascript libraries that I've written to handle just about any situation I can come across, as well as a home-built data framework that's more powerful than Rails, and an automated build & deploy setup that can get a new project up in minutes. These are the reasons why I can crank out a new database driven site in a matter of hours. No matter what it is, it's mostly already built.
So my advice would be to simply do your job and put in the time. Pay attention to the things that slow you down and write libraries that speed those things back up. Build yourself a set of tools and constantly improve them.
Five years from now, you can crank out a one-day clone of whatever flavor-of-the-month billion dollar site is popular at the time, and everybody will thing you're a genius.
[deleted]
My 2 biggest helpers to "coding quickly":
1. I have written over 10,000 programs, but I have started about 5 of them from scratch. I just grab the closest thing and proceed to change it. I realize that doesn't help you much right now, but it tells you the same thing you'd hear in any endeavor: start building now.
2. When you start building now, build "building blocks", pieces of code you can use over and over again. A good program that's 300 lines of code could have as many as 100 calls to other functions or subroutines. Isaac Newton achieved greatness by "standing on the shoulders of giants". You should do the same thing, even standing on your own shoulders once in a while.
1. I have written over 10,000 programs, but I have started about 5 of them from scratch. I just grab the closest thing and proceed to change it. I realize that doesn't help you much right now, but it tells you the same thing you'd hear in any endeavor: start building now.
2. When you start building now, build "building blocks", pieces of code you can use over and over again. A good program that's 300 lines of code could have as many as 100 calls to other functions or subroutines. Isaac Newton achieved greatness by "standing on the shoulders of giants". You should do the same thing, even standing on your own shoulders once in a while.
For me, it's all planning. I consider myself a terrible coder, so I have to lay out everything first. Working from that plan, I get things done fast.
Think of it like giving a speech. Write the speech, revise it, and then go over it in your head (The "practicing in front of a mirror" part doesn't really apply here.) Then, finally, give the speech. You might stumble over a few words, or have to consult your cue cards occasionally, but there's nothing wrong with that. You'll do it less as you give more speeches.
Think of it like giving a speech. Write the speech, revise it, and then go over it in your head (The "practicing in front of a mirror" part doesn't really apply here.) Then, finally, give the speech. You might stumble over a few words, or have to consult your cue cards occasionally, but there's nothing wrong with that. You'll do it less as you give more speeches.
I google more before deciding how to code to a specific problem. I want to understand the problem better, see how it's been approached by others, if there are standard approaches, etc. This helps me crystallize my thoughts and get quick prototypes put together.
Your question is about your "internal toolkit" and your speed when coding. As your experience becomes richer and more varied, your feel (or dare I say, taste) will improve and you'll be quicker because of it. A problem will tickle some part of your brain and you'll have a much more intuitive understanding of how to use your external tools (php/kohana) to best solve it. For that you do need some strong understanding of what's available in your development language of choice - memorization isn't the answer, but you should be able to remember off-hand that library X solves problem Y and might apply here . . .
It has been valuable to me to expand my knowledge of development styles and languages, so try to work in some tasks that use some very different stacks than php and kohana. If you can find a good mentor or peer group, I think that can be valuable in your growth as a programmer.
There's a bit of the gunslinger mentality floating around right now re: coding speed. Stuff like the Yale programming class where data exists on the time it took students to correctly solve a programming assignment (http://www.joelonsoftware.com/printerFriendly/articles/HighN...). The conclusion made there is "(t)he quality of the work and the amount of time spent are simply uncorrelated." So right now, hackers seem to be making sure people know how much faster they are than everybody else. Ignore a bunch of this fluff.
There are arguments that if you're not one of the "rock-stars" you'll never create software as beautiful as one of the 1-in-100 hackers. I think this is a little true (innate talent is something that exists) but we as hackers should think more about our work as craft. Maybe most people can't be wonderful artists, but craftsmen (and women) have built some beautiful things over the years.
So work on your code as a craftsman. Care about it. Read what others do. Ask for feedback. Develop a habit of deliberate coding. Be patient, and be your own worst critic and best supporter.
And good luck - what we do is quite a bit of fun.
Your question is about your "internal toolkit" and your speed when coding. As your experience becomes richer and more varied, your feel (or dare I say, taste) will improve and you'll be quicker because of it. A problem will tickle some part of your brain and you'll have a much more intuitive understanding of how to use your external tools (php/kohana) to best solve it. For that you do need some strong understanding of what's available in your development language of choice - memorization isn't the answer, but you should be able to remember off-hand that library X solves problem Y and might apply here . . .
It has been valuable to me to expand my knowledge of development styles and languages, so try to work in some tasks that use some very different stacks than php and kohana. If you can find a good mentor or peer group, I think that can be valuable in your growth as a programmer.
There's a bit of the gunslinger mentality floating around right now re: coding speed. Stuff like the Yale programming class where data exists on the time it took students to correctly solve a programming assignment (http://www.joelonsoftware.com/printerFriendly/articles/HighN...). The conclusion made there is "(t)he quality of the work and the amount of time spent are simply uncorrelated." So right now, hackers seem to be making sure people know how much faster they are than everybody else. Ignore a bunch of this fluff.
There are arguments that if you're not one of the "rock-stars" you'll never create software as beautiful as one of the 1-in-100 hackers. I think this is a little true (innate talent is something that exists) but we as hackers should think more about our work as craft. Maybe most people can't be wonderful artists, but craftsmen (and women) have built some beautiful things over the years.
So work on your code as a craftsman. Care about it. Read what others do. Ask for feedback. Develop a habit of deliberate coding. Be patient, and be your own worst critic and best supporter.
And good luck - what we do is quite a bit of fun.
"just know" is long-term memory. That's the technical, correct term, and is exactly what it says.
And at expert levels it is what separates the truly good programmer from the novice, and even the "talented" young. Realizing this, as long as you keep learning, no fear. The only price is continual practice: effort and time.
That also means be constantly self-aware. If things are going too smoothly, it means it's time to pick up something new.
And at expert levels it is what separates the truly good programmer from the novice, and even the "talented" young. Realizing this, as long as you keep learning, no fear. The only price is continual practice: effort and time.
That also means be constantly self-aware. If things are going too smoothly, it means it's time to pick up something new.
Pre requisites:
1. Type without watching on the keyboard.
2. Use IDE with autocomplete (Zend Studio in your case)
3. Use Zend Framework of CodeIgnite
4. Read a lot how to do it before you do it.
After some time you will have enough experience not to think how to implement this or that - this is most important.
Follow http://gettingreal.37signals.com
PS. Don't give up PHP
After some time you will have enough experience not to think how to implement this or that - this is most important.
Follow http://gettingreal.37signals.com
PS. Don't give up PHP
You will eventually memorize the important bits of a language, and that will make your time decrease. Furthermore, you may learn a new style/language where the paradigm just "fits" you right. Both of these will make your times decrease, although a quick time is not necessarily a good thing. Remember that oopses can happen more easily if you're blazing away on the keyboard.
Development environment. Get auto complete and api lookup in your dev environment.
Keep it simple. Most php you need to do can be done with a few commands (function, str_replace, mysql_query, while(mysql_fetch_array), includes and logic statements)
Keep it simple. Most php you need to do can be done with a few commands (function, str_replace, mysql_query, while(mysql_fetch_array), includes and logic statements)
I found to do something well, with clean code, documented methods, and tests, it takes more than a few hours. I operate on days not hours for those sorts of things.
Now if it's a quick script and not production code, then I'm usually pretty quick.
Now if it's a quick script and not production code, then I'm usually pretty quick.
Think, then think again, then code.
Visualize. Code structure should morph as you discover the problem more.
If you feel like a contortionist, you're probably doing it wrong - think Cirque du Soleil acrobat instead.
I can hardly remember what I did 5 minutes ago. No programmer has a mind index of all of the libraries in PHP. If you have that kind of memory, consider an extended visit to Vegas.
I've been coding PHP for ten years and I still have to look up the argument order for array_key_exists() and a few others.
stop reinventing the wheel. if you run into a problem chances are hundreds of others have run into the same problem and a reusable chunk of code is available.
Switch languages.
This was down voted.
I'm voting it back up.
Not all language flames are useless.
Coding in some languages can be 10x or more productive than coding in other languages.
Picking the right language to give you that 10x speedup is far more important than lots of other hints that give you 5% speed ups.
http://www.paulgraham.com/avg.html
I'm voting it back up.
Not all language flames are useless.
Coding in some languages can be 10x or more productive than coding in other languages.
Picking the right language to give you that 10x speedup is far more important than lots of other hints that give you 5% speed ups.
http://www.paulgraham.com/avg.html
Good coders copy, great coders steal.
Google is your best weapon.
Always wear your balaclava while coding.
http://www.thermalshop.co.uk/balaclava-season-pi-135.html
Google is your best weapon.
Always wear your balaclava while coding.
http://www.thermalshop.co.uk/balaclava-season-pi-135.html
I am a novice programmer developing with php/kohana. I measure my production time in days, not hours, so any tips on just how to "code quicker"?
Is it normal practice to consult php.net and google like mad when developing? Or do the fast programmers "just know" over time? Memorization?
Thanks for any tips, all stacks welcome.