Uh, Luc, are you suggesting anybody over the age of 30 can't code 
productively any more? Because it sure sounds like that.  If so, that seems 
like a curiously ageist argument to make in a Clojure thread.  I'll leave 
it to the legions of skilled and productive programmers over 30 to 
contradict that particular idea, if they want to.   Anyway, I learned the 
basics of 4 new programming languages, one new programming paradigm and a 
new NoSQL DB last year, and I just turned 50, so we're not all over the 
hill just yet!  But I agree with the argument that less code means less 
burden on the developer, whatever their age, as well as being much easier 
to maintain in future.  That's a no-brainer, really.

As for the 2003 survey you quote, the timing seems suspicious. Firstly it's 
10 years out of date, and with new languages (hello Clojure!), tools and 
techniques emerging all the time, I really don't see how it can be terribly 
relevant today. Another point is that the early 2000s were dominated by the 
rapid expansion of enterprise Java into every available niche. I know from 
my own experience at the time that switching applications from proprietary 
client-server platforms to 3-tier J2EE was a massive productivity sink, 
despite the fact that I was very excited by Java originally. Industry 
experience has amply demonstrated since then that J2EE has never really got 
any easier or more productive, despite the enterprise Java development 
sector being increasingly dominated by relatively young graduate 
developers.  Indeed the pitiful productivity and horrible complexity of 
enterprise Java were key reasons why Rod Johnson invented Spring, and why 
Rich Hickey invented Clojure. But I can imagine that a lot of experienced 
developers around 2003 must have been feeling pretty disillusioned and 
frustrated at the loss of productivity once they moved into J2EE. I know I 
was!

Finally, if you were to run a similar survey today, you might find that 
many developers are being forced out of development roles by other factors 
- ageism in the workplace, offshoring/onshoring to replace expensive local 
staff with cheap offshore workers, relatively low salaries for hands-on 
technical roles, the ongoing impact of the 2008 financial crisis, and so 
on. Some of this will also be more prevalent in the commodity software 
services sector e.g. offshoring is more likely to hit big commercial J2EE 
projects than smaller, smarter and more agile Clojure projects, I suspect. 

So I think the real world of employment and developer productivity in the 
IT sector is rather more complicated than blaming everything on the alleged 
effects of ageing synapses.

Now, where did I leave my car keys....

On Friday, April 12, 2013 1:18:50 PM UTC+1, Luc wrote:
>
> +1 
>
> Everyone will experiment this if they try to mantain their coding ability 
> as they age. 
>
> The average career length of a programmer is 8 years in the US (2003 
> survey) and 
> the main reason invoked by those that left is their perceived lack of 
> productivity. 
> They could not get in that euphoric state were code pours out like water 
> out of Niagara 
> Falls. No more endorphines, no fun, ... 
>
> No wonder if you look at the effect of aging, working memory estate is the 
> first part of the brain under attack. Any attempt to hold on a myriad of 
> details 
> while coding is futile as you age. 
>
> Working memory is were your consciouness lives. You can compare this to 
> RAM 
> but it's not expandable, on the contrary :) 
>
> The second thing suffering from aging  is the path pulling stuff from long 
> term memory 
> (compare this to pulling page frames from swap space). 
>
> Long term memory seems to hold until you die except if you get caught by 
> one of a few 
> brain specific diseases. (Alzheimer screws up everything starting with 
> working memory). 
>
> As you age you may relive "forgotten" souvenirs because some nerve cells 
> are locks to 
> hide these in long term memory, some may fail as you age. If we were to 
> remember 
> everything we experienced at once we would all be impotent. But it does 
> not carry a big 
> penalty compared to loosing part of your working memory. 
>
> Any work you are involved into requires pulling stuff from long term 
> memory in 
> working memory. This includes concepts and procedures/syntax 
> (from a software perspective). 
>
> Depending how you learned, this will bring more or less useful items in 
> your working memory. All the associations you made over your 
> lifetime are attached together hence the importance of "forgetting" some 
> in your long 
> term memory. There ain't enough space to deal with all of these at once in 
> your 
> working memory. 
>
> The visual cortex is even smaller, this is why we can get fooled by 
> illusionists. 
>
> Learning concepts (deep learning) should come first versus surface 
> knowledge (procedures, syntax, ...). The latter can be replaced over time 
> easily 
> if it is attached to concepts (more like leaves in a tree). 
>
> Otherwise as technology changes, it's almost a clean start each time 
> technology 
> changes. People may get attached to surface knowledge because it's the 
> only thing 
> they acquired over a number of years. Any change can then become quite 
> disturbing. 
>
> Luc P. 
>
> > When reading such concise code you must always remember that it is very 
> > compressed and says a lot in a few words. So it is really the 
> information 
> > density that is disturbing the newcomer, not the legibility. 
> > 
> > If the same code was expanded to 50 lines of Java code, then yes, each 
> > individual line of code would be easier to comprehend, but that would 
> only 
> > give you a false sense of productivity because you'd be spending more 
> total 
> > time to comprehend all the lines, and then even more time to grasp the 
> > function as a whole. The human short-term memory is very limited and 
> > Java-like syntax stresses it a great deal more than concise FP-like 
> syntax. 
> > 
> > -marko 
> > 
> > 
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to