Nope, it's not an absolute age limit issue. It's more a question of your peak throughput. I am still faster than my customer's employees these days but the ratio had dropped when I was around 40 compared to what it was at 30. I was still rooted in the Java world, to my own despair.
This survey from 2003 is to me the tip of the iceberg. As you say, Java and cie never delivered their promises. Today the corporate programmer job is cluttered by a bigger amount of insane details which have not much to do with solving the problems at hand. I am still connected to this world and it looks like it does not get less complex, on the contrary. I am convinced that this complexity is more a drain of brain power than an efficient way to build software. A derivative of the survey was the impact on motivation. The more crap you need to handle in your daily job, the more your personal throughput is impaired and the more likely your motivation will drop. It becomes a vicious circle. Without motivation, it's even harder to stay focus and dedicate your efforts to a task whatever is your age. You may spend much more energy trying to keep your focus. This does not improve as you age on the contrary. I am not trying to find an explanation to world hunger here, I am talking about optimization as you age and why it is something people should pay attention to. The fact that keeping track of huge piles of unnecessary details is a burden became obvious to me at a certain point in time (around 45). I was fed up by the drain of brain power and the never endless profusion of tools and frameworks coming by and their low return value. Between then and now the difference is to me quite obvious: - my performance improved back to the level I had when I was 30. - I reduced my brain workload by trimming these huge piles of low-value details. - I am not competing using the same tools, I found more efficient tools in terms of brain estate, I am more efficient. - I deal with complex problems in a different and much more efficient way than with corporate tooling. - I still hate accounting but can work on it with somewhat efficiently. - I seldom loose track of my car keys or wallet, I can visualize code while performing other activities :) I guess what I am trying to say is that you can compete with youngsters head to head but you should become wiser and choose your own terms when you are allowed to do so (which may not be an available option to many). In fact you can beat young people by a significant factor by doing so. Now if most of you suffer from hyperthymesia, the above maybe of no interest :))) Luc > 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. > > > -- Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad! -- -- 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.
