We have all seen gifted programmers who seem to have an innate ability to code circles around others. These coders are like the 12 year old prodigies you see banging out Scott Joplin tunes on the piano like nothing. I'm sure there are many Monks blessed with this kind of skill.
But leaving the gifted ones aside, how long does it take for the "normal" person to code fluently? By "fluently" I mean being able to code about as effortlessly as one types out prose in their native language into the keyboard. It means not having to think about the mundanities of grammar or spelling or syntax. Instead, you just let the ideas in your head flow kind of magically out from your brain and into your fingertips. It also means you know a lot of the basic tropes and idioms to express yourself in a clear, compact way without much effort. Maybe every once in a while you consult a dictionary or thesaurus but by and large you can bang out something relatively quickly without much struggle.
As a programming hobbyist who has never worked alongside other programmers, I'm curious to know if this state is achieved by most professional programmers and what it takes to get there. Are we looking at 2 years of full-time programming? 5 years? 10? Or maybe programming is by nature an activity that starts and stops in fits and is never quite effortless? I'd be interested in hearing some experienced programmer's thoughts on this and what it took to get you to a blissful, effortless state of coding.
|
Re: When does programming become automatic (if ever)?
by Your Mother (Archbishop) on Apr 12, 2016 at 23:15 UTC
|
I came in as a hobbyist and had no mentors because as I slowly adapted to doing coding at work I was not in coding jobs so had no immediate access to role models. It took me really painful stretches of time to learn really simple things. I think I was unaware of perldoc for nearly the first two years I was (partially) paid to write Perl. On that point: Re: Perl Certified!, many Perl basics eluded me but I had no problem with references and other quote-expert–unquote Perlisms because they were necessary to solving problems.
It’s the person, not the time. Plenty of professional programmers are awful because they don’t care. They clock in and out and finish their projects. Some professionals love it so they go home and read, tinker, try new languages, participate in forums, publish open source code, submit patches to others. One of these hackers is worth, quite literally, 20 or more of the other in terms of productivity.
You can become quite good at anything with 2 years of dedication. A real expert in 5. There is more to it than that, though, as alluded above. Give this a spin: Great Hackers.
| [reply]
[d/l] |
|
|
| [reply] |
Re: When does programming become automatic (if ever)?
by BrowserUk (Patriarch) on Apr 12, 2016 at 23:27 UTC
|
I agree with the other responses: it depends; but I have a corollary that may be of help to you.
Do you enjoy the process of programming? Do you hanker to improve? Does it irritate you when you know that despite that your current code "works"; it's not quite right?
If you can answer yes to any one of those; you'll probably become proficient in a time that is closer to the lower estimates than the higher.
If you answered yes to two; stick with it, you have a good career ahead of you.
If you answer yes to all three -- honestly -- then work it; your abilities will (probably; provided you do not burn yourself out; many do) grow exponentially; and if you get the requisite piece of luck; good things are your destiny.
And if that last one sounds like a generic astrology prediction; you're not wrong. There is no predicting luck; but it is a requisite.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
Re: When does programming become automatic (if ever)?
by QuillMeantTen (Friar) on Apr 13, 2016 at 07:35 UTC
|
Greetings,
Even if I'm no professional (not yet) I have seen how professionals code (thanks to attending courses by computer science researchers).
The "code fluently" thing is not even remotely the most important. After a bit you will know the syntax and be able to write syntactically correct code as fast as you write english. But because code compile does not mean it is well designed or even works!
One of the greatest lessons I received was from one of the heads of the research lab in my university. At the time he was teaching basic algorithms, complexity, computability.
At first I had some issues with the use of those metrics and I would sit and wonder while he explained to us that with enough practice, anybody can come up with a crappy design on the fly and make code that *should* work but would take a thousand year to run on the intended dataset. To be truly gifted is to be able to sit and come up with a GOOD algorithm.
He used to have the coffee break test: launch the program, take a coffee break and if at the end of the coffee break it still is not done then have a harsh look at your algorithm
Now what is a good algorithm? Not a complex one, but easy algorithms can be the most complex. You are looking for the best solutions regarding time and space parameters. This takes experience, this takes time and practice.
After five or six university projects in about as many languages I have started to understand what he was saying. I have stopped using the "mad dog" coding style where I would sit at the keyboard and crank out write only code that I could not go back to afterward. I'm not saying that I'm completely over it but I'm better than before. It took me some practice.
A friend of mine who went to an engineer school before university never had that problem. Sure he cranked out code more slowly but god it was beautiful code. Each statement was thought out for testing, debugging and at the end of the day he accomplished more than I did because when he was finished there only was some glitches to iron out while I had to go down the jungle with a flamer to find every monster I had created in my path.
Being able to code circles around someone else does not mean you have to actually type. Its more about being able to design. And the worst thing you can do for your ability to grow is to let code get in the way of programming. Program first, then code.
| [reply] |
Re: When does programming become automatic (if ever)? (never!)
by LanX (Saint) on Apr 13, 2016 at 06:13 UTC
|
The question is problematic because "automatic" is rather subjective.
One part of the problem is that we are not fighting to control stupid machines anymore but the products of other programmers. Whenever we've climbed a mountain we are confronted with a bigger one behind the valley.
Another part is the way to measure productivity: I had colleagues praised for their productivity who just copied, pasted and adjusted boilerplates. Completely ignoring the long term cost of maintenance.
On the other hand I met colleagues in the past impressed about my coding tricks while I am not at all satisfied about my productivity.
I hope you understand now why I doubt that it will ever become automatic. ..
(Update: ... and if it could be done "automatically" why do we still need a human programmer then? )
| [reply] |
Re: When does programming become automatic (if ever)?
by Hassmaschine (Initiate) on Apr 13, 2016 at 06:19 UTC
|
I've been a hobbyist Perl programmer for about 10 years now - well, I guess I'm never going to be "fluent", although I'm definitely further along than I was when I started by piecing together parts of different programs I found on the internet.
It's kind of like visiting a foreign country to me - I know how to ask where the bathroom is and can order drinks, but I can't necessarily have an in-depth conversation with the locals. I can also get the gist of a conversation and understand the basic meaning of a sentence through the context of the situation, but without that I would be fairly lost.
I suppose if I had more time, I could become more fluent - but as my survival doesn't depend on me being able to write programs, progress is glacial. The funny thing is, I've tried to learn other languages (briefly), and the only thing that seems to "click" with how I think is Perl, even though I'm definitely not a particularly great Perl user.
I've never worked with programmers either. Honestly, I'd probably be embarrassed to share any of the Perl programs I've written during the last 10 years! It would be exactly like me trying to explain in broken Spanish, or German, that I'd like another beer...
| [reply] |
Re: When does programming become automatic (if ever)?
by FloydATC (Deacon) on Apr 13, 2016 at 11:50 UTC
|
A good programmer will never sit down and just start typing. They will think long and hard about the problem and THEN basically just dump the finished program from the brain and into the computer. To an observer, this may seem like "ideas flowing magically" but those ideas have already been through a complicated thought process.
Only if you've solved the same problem many times before can you go straight from task to solution, and most programmers would rather kill themselves with a rusty spoon than have to solve the exact same problem twice.
-- FloydATC
Time flies when you don't know what you're doing
| [reply] |
|
|
| [reply] |
|
|
THIS I find important. Basically, you build yourself a knowledgebase of code snippets so you know how to write a for loop, or a regexp that matches what you want. You keep a list of all commands in your head, so you know what you can do with them, and are able to query quickly the correct syntax (either in your head, from perldoc or from older scripts).
This is your Perl ROM. This is "learning the language".
Now, you also need the structure of the program, the way it connects with other software or user, and be able to hold that in your head in order to "design" the complete flow, without going into details.
THAT needs to go in RAM, and getting your brain fit enough to hold it all takes a while.
And you have text/program editors that help with that (gives you a list of the subroutines you have defined, or the variables you have used so far; your RAM registers). Or hold the dependencies and requirements in mindmap software.
This RAM is generic and it's what stays with you when they say: "Learning another language is easy", because you interchange only the ROM part (which could be only a cheat-sheet of all functions). And, like muscles of a bodybuilder, this RAM part of your brain needs to stay lean. (analytical problem solving)
Sometimes, you step out and go prototyping to get something you want and do not do often: read a weird format, connect successfully to a database and encapsulate that in a function, which you can later use in your program. Learn the AT commands of your dialup. This research part if either brute-force coding (prototyping) or library hunting/testing (anyone dived into CPAN before, like this? It's a sea of modules). These new code snippets are then incorporated into your ROM, and now you can use your RAM to knit them together.
If you have the time, this is also the moment to write test cases for these new things.
So. What is programming to you? The ROM part or the RAM part?
If it is the RAM part, you are good at high level design, and interfacing with the customer to get a list of requirements and balance these with constraints to come to a not-yet-coded software.
If it is the ROM part, then you like transforming the high level design into a detailed design and code away, loose yourself in the code.
If both... then, you are a candidate for automatic programming, where while talking to another person, the information is stored in a tree, and relations are matched and you are basically programming while talking.
| [reply] |
Re: When does programming become automatic (if ever)?
by Discipulus (Canon) on Apr 13, 2016 at 08:54 UTC
|
But leaving the gifted ones aside..
So you want my opinion: ten years are enough to practice basic things fluently, at least for me. I had no scientific backgroud, nor a programming one. I work now as sysadmin and I try to automate many tasks with Perl so when I work with Perl in my main fields I write programs quite fast. When i go to explore other fields (such web programming using Dancer2 for example) I still suffer of slow learning times.
The fact is that I like programming in Perl because I feel it as a sane interaction with the machine, so mostly in the past, i passed many hours of my spare time programming. I have many limits and many things to improve: testing and preparing good distributions are ontop of my todo list.
It is many times a matter of aptitude: what is your standard for good software? Perl make the job done quickly: this is a good thing but can limit you in the research of good software at the state of the art of Perl programming. I tell the difference between Perl programmers and Perl scriptor. see Re: A use strict confession, with real questions. (Perl scriptors and Perl programmers) and the whole thread to see what i mean.
L*
update: traversing my main boilerplate directory it seems i have wrote lot of programs (without takin in the count remote systems and private home pc)
find -name *.p[lm] | perl -lne "$h{(localtime((stat($_))[10]))[5]+1900
+}++;END{map{print qq($_ $h{$_})} sort keys %h}"
2012 1176 (but this year i restored from bkp..)
2013 205
2014 1210
2015 730
2016 54
There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
| [reply]
[d/l] |
Re: When does programming become automatic (if ever)?
by Anonymous Monk on Apr 13, 2016 at 08:54 UTC
|
After many years of using Perl, I still don't always remember the order of arguments to substr or splice, but what I can do is type perldoc -f splice at lighting speed...
Point being, one way to get good at Perl is to know where all the documentation is. Having read or at least skimmed all of the documentation of Perl, a few books, and many CPAN modules at one point or another, I know what tools are available and where to look when I need something. | [reply]
[d/l] |
|
|
Replying to you but for the OP's benefit. I think you're aware of everything I'm about to write.
This is really an important revelation, I think. A year or so before I started picking up Perl I became faster in a Unix environment than just about everyone at work. It wasn't aptitude as much as comfort (I wasn't scared to try new things), good typing skills, and laziness. Typing orderstat and specstat and friends six thousand times a day was for the birds. Alias o and s afforded one finger typing, and automatic mouse-selection-buffer copy plus one button pasting meant I was faster out of the gate than everyone else. alias pd "perldoc" has been in my .aliases since I learned it exists. I live by Ctrl^R on the command line.
In an age of instant documentation, being an adept librarian/researcher is equivalent to years of training. And having comfort with the tools means that once you find something, you can make it trivial to reuse. One that comes to mind–
alias hs "perldoc -m HTTP::Status | perl -ne '/\A\s+100/ .. /510/ and
+print'"
| [reply]
[d/l]
[select] |
|
|
Agreed! Another one to add to the list: sometimes it's easiest to just test something. Not sure about precedence? perl -MO=Deparse,-p -e ... Not sure what context something is in? sub ctx { warn wantarray ? "list\n" : "scalar\n" } Something else? Whip up a quick script using one of the Test:: modules. Data::Dumper and friends debug 75 to 95% of my problems. And so on...
| [reply]
[d/l]
[select] |
|
|
Talking about "automatisms" ...
> I still don't always remember the order of arguments to substr or splice,
that's actually a good idea for extending snippets in my IDE (yasnippet/Emacs) ¹
> what I can do is type perldoc -f splice at lighting speed
actually I could also expand the embedded documentation to reflect this in my IDE
> at lighting speed...
unfortunately not at light speed, often you are redirected to other perldocs
like in
perldoc -f m
m// The match operator. See perlop.
¹) other suggestions for not memorable interfaces? caller ? what else ? | [reply]
[d/l] |
|
|
| [reply] |
|
|
|
|
> that's actually a good idea for extending snippets in my IDE (yasnippet/Emacs) ¹
for the records some trivial templates for yasnippet, which is derived from textmates standard and is similar to snippMate for vim.
Not too far away from Abbrevations in Komodo.
# -*- mode: snippet -*-
# name: caller;
# key: caller
# --
my (${1:$package}, ${2:$filename}, ${3:$line}) = caller;
$0
# -*- mode: snippet -*-
# name: caller(LEVEL)
# key: caller
# --
my (${2:$package}, ${3:$filename}, ${4:$line}, ${5:$subroutine}, ${6:$
+hasargs},
${7:$wantarray}, ${8:$evaltext}, ${9:$is}_require, ${10:$hints}, ${11:
+$bitmask},
${12:$hinthash}) = caller(${1:$LEVEL});
$0
please note that both versions of caller are expanded with the same keyword + TAB and you can chose from a dropdown between both versions.
here the example for splice
# -*- mode: snippet -*-
# name: splice @ARR ,OFFSET ,LENGTH ,LIST
# key: splice
# --
splice @${1:ARR} ,${2:OFFSET} ,${3:LENGTH} , ${4:LIST...};
since I can include code (elisp but also bash or Perl) I'd like to find a way to delete the commas of skipped arguments instead of creating 4 versions for drop down... but I'm still at the beginning.
Vision: Ideally these snippets could be generated from POD-examples and show the documentation¹, I think DBI is a good candidate.
PS: thanks to Tux for suggesting the return values for stat, (local)time, and caller (with or without args)
¹) probably best realized in combination with autocomplete-mode ... unfortunately emacs-wiki seems to be down at the moment... | [reply]
[d/l]
[select] |
Re: When does programming become automatic (if ever)?
by choroba (Cardinal) on Apr 12, 2016 at 23:03 UTC
|
I wanted to reply that you need 10000 hours of practice to become an expert, but when googling for the source, I discovered it might not be true.
($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
| [reply]
[d/l] |
|
|
This reader also has trouble with that source whose author appears not to know the distinction between his word, "rebuffs," and something whose meaning is closer to the intent (as inferred from context): "rebutts" or possibly even "refutes."
Worse, that article lacks another word, "aptitude," which describes at attribute that's almost certainly variable... and relevant.
UPDATE: shamed by the typo in "distinction" that I failed to notice during initial proofreading; now corrected. Aaaaargh!
| [reply]
[d/l] |
|
|
| [reply] |
|
|
Yeah, very interesting point, my immediate reaction might also have been to refer to the 10,000 hours thing.
But at the same time, I know that most people I have seen in development teams will never be really good programmers, even after 10,000 hours or even twice as many of development, let alone real hackers. Perhaps only 10 to 20% of them, at most. Talent or intelligence may probably have some role, but dedication and commitment even much more.
To become really good at programming, you really have to love doing it so much that, maybe, you write a new open-source application or start learning a new language when you get back home in the evening. Or something weird like that, whatever. But clearly something that the majority of paid developers probably won't do.
Having said that, I still believe that there is some merit in the 10,000 hours (or ten years) idea: even if you are very talented, you also need a lot of experience to get really good. Some particularly gifted people may achieve that in 7,000 or perhaps even 5,000 hours, others may need more than 10,000, but clearly a lot of hours of practice is needed. Practice and real dedication, of course.
| [reply] |
Re: When does programming become automatic (if ever)?
by jmlynesjr (Deacon) on Apr 14, 2016 at 18:43 UTC
|
Programming doesn't exist in a vacuum. Don't discount the vast amount of domain knowledge that has to be acquired and mastered and reacquired and remastered over the course of your career. This is in addition to the easy part of learning several assembly languages, Fortran, C, C++, Perl, OS APIs, Database APIs, Networking APIs, Window managers, human factors...
James
There's never enough time to do it right, but always enough time to do it over...
| [reply] |
|
|
| [reply] |
Re: When does programming become automatic (if ever)?
by graff (Chancellor) on Apr 15, 2016 at 03:05 UTC
|
I've been coding in perl for over 20 years now (I wrote C for about 10 years before that), and I'm always looking stuff up, because the man pages are good enough (and I've gotten good enough at reading man pages) that I don't go out of my way to memorize stuff. (If I happen to remember how a given module or function works, that's fine, but not essential.)
As for just sitting down and writing code, I pretty much always start every new script file by writing the man page for it. That's the only way I can be sure that I know what I'm doing, and whenever I haven't done that, as often as not I get confused before I get very far. | [reply] |
|
|
I'm always looking stuff up, because the man pages are good enough ... that I don't go out of my way to memorize stuff
As that may be, but in order to look stuff up; you need to know what to look up.
At the beginning with any new language, the steepest part of the learning curve is knowing where to look and what to look up.
And it has knock on effects for your whole approach to both writing the code; and structuring the application; even how you think about the problem.
The best evidence for this are the flavours (C-ish; OO-ish, Fortran-ish etc.) of code you see in SoPWs from newbies to Perl. You can often make a good guess at not only how much programming experience they have; but which, if any, previous language they have experience of, just from the way they approach the problem and the style of code that produces.
Making effective use of Perl means becoming one with its operator rich environment and its built-in data-types; and making your code play to its strengths.
The worst code you'll see is that modeled after JS or Java or C++; which tries to write everything-is-an-object code in a language that has better solutions for many problems.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
There is no "set" time. for anyone. We are all creatures of habit, and basically lazy.
As a result, if you can look at things you are good at in "life", you will find that you will
fairly quickly become fluent (automatic) in those areas in programming.
For example; My strongest area is in efficiency. I have found that I seem to recognize patterns far faster than those I've met, or know.
As a result; while I do not qualify myself as an expert in Perl, by any means. I can
rip apart a program created an "expert programmer" in seconds, and more; remove, or re-write
portions of that program quite easily. Maybe that just makes me more a "Hacker", than a
programmer.
But don't you have to be a Programmer, before you can be a Hacker?
Point being; If you can classify, or categorize the areas you are proficient at in life.
You will most probably find that you will become proficient in those same areas, where programming is concerned -- think "habit" && "basically lazy". It (those areas) comes "easily" to you. :-)
EDIT
P.S. Great meditation BTW. Thanks for posting it!
¡λɐp ʇɑəɹ⅁ ɐ əʌɐɥ puɐ ʻꜱdləɥ ꜱᴉɥʇ ədoH
| [reply] |
|
|
|
|
| |
|
|
Re: When does programming become automatic (if ever)?
by chacham (Prior) on Apr 13, 2016 at 15:09 UTC
|
Projects tend to have an individual feel. Becoming fluent in the language is only a qualification to be involved, but actually coding it well requires an understanding of the idea and overall feel.
Once the project is mature enough, it to some extent drives itself. When that point, that idea, that understanding, clicks, it can be very easy to sit down and code additions to it. Extensions become obvious and trivial. But before that point, there's a lot of time spend on reaching that level of understanding, whether through thinking or the code-erase-rewrite cycle.
| [reply] |
Re: When does programming become automatic (if ever)?
by cavac (Parson) on Apr 14, 2016 at 08:30 UTC
|
I'm pretty sure that really depends on the person involved. It's a bit like learning a new (spoken) language. There are a few people who can pick up a new language in a few weeks, others spend a lifetime.
It also depends on the problem you are working on. If you've done something similar before or using one of your standard constructs, you will get fluent quite fast. If you do something totally different, you might have to use subsets of the programming language you seldomly, if ever, have used before. Same goes for using your mother tongue: You might have used it for decades fluently, but that doesn't automatically mean you can write a medical record or a set of laws in it without effort, as these often use special forms of the language with words you mostly never use in your day-to-day communication.
"For me, programming in Perl is like my cooking. The result may not always taste nice, but it's quick, painless and it get's food on the table."
| [reply] |
Re: When does programming become automatic (if ever)?
by flexvault (Monsignor) on Apr 14, 2016 at 21:54 UTC
|
nysus,
Never!
When I started programming, I mastered a computer with 16 hardware instructions, and I could write poor code semi-automatically.
Perl is a world unto itself; where each day someone can learn something new, something wonderful and something different. Enjoy re-learning a function that has been improved by the Perl developers and realize 'automatic' is for computers and not for 'humans'. YMMV!
Best Regards...Ed
"Well done is better than well said." - Benjamin Franklin
| [reply] |
Re: When does programming become automatic (if ever)?
by nysus (Parson) on Apr 14, 2016 at 16:00 UTC
|
What tools are pros using to fix or avoid basic syntax errors? If I code for a couple of hours and then run the code, I regularly find a dozen or so basic errors like missing semicolons, misspelled variables, unmatched brackets, etc. I'm using syntax highlighting in vim which helps to a degree but misses some really obvious stuff.
| [reply] |
|
|
I write the code in a way to be able to run it more often. In fact, I usually make it (or better, its test suite) run automatically every time I save any of the files. So, I'm fixing the errors as I progress.
($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
| [reply]
[d/l] |
|
|
| [reply] |
|
|
| [reply] |
|
|
