Earlier quoted context omitted.
I don't think it's the developers being myopic. For the most part, it's management that views development as a young person's game and encourages people to move out of the technical track and into the management track. If companies viewed programming as a long term career, they would put the pay scales in place to treat it as such. It's only a "trap" in the respect that in many (not all) places your pay maxes out as…
I thought this was a problem of managers for the longest time, but recently I read an argument once that convinced me of the opposite. Tu quoque: the "my boss doesn't understand" problem in companies basically comes from people working for people with lower IQ than them. It's not a skillset gap, it's a pattern-recognition gap. In the military, the best soldiers become officers, and the best officers become generals—e…
I would have hired Doug, but...
61–70 of 244 posts
Re: I would have hired Doug, but...
#62Earlier quoted context omitted.
Let's make it an even 4! Just turned 50 yesterday. Wrote my first contract program in 1982 when I was 17. Today I teach teams how to rock-and-roll. I also keep coding, but mostly as a hobby. It has nothing to do with programming -- I simply have too many irons in the fire to do all of the things I love as much as I want to.
I guess I might as well pile on. Turned 50 last year. Got my first paycheck for writing code junior year of high school (writing BASIC code on a Commodore PET!) Working on my fifth startup now.
If I may derail the conversation a little bit, may I ask if/how you use the things you've learned today?
I mean, is it things like paradigms that have stuck with you like OOP/functional/w\e, or do you always structure your exception handling in a certain way, no matter the language? Are there skills/technologies you've been using since you've started? For example little scripts of basic that you've never let go off that automate things like setting up build servers and the like?
Re: I would have hired Doug, but...
#63Earlier quoted context omitted.
For me, the thing that gets a bit discouraging at times is the feeling of riding a slow-motion merry-go-round. Every 10 years or so you see the same ideas start to come around again, only with some new paint and landscaping. I have found myself more than once thinking that learning about some new trendy buzzword is just ultimately a waste of time, since I will barely have mastered it before it's been replaced by the…
As a young person my biggest concern with hiring old people is that exact attitude: this is just like $IRRELEVANT_OLD_TECH. Yeah on the surface. $IRRELEVANT_OLD_TECH didn't catch on or it wouldn't be irrelevant but _why_ didn't it catch on? Powerbuilder failed, but was it because you couldn't write a good enough program that way on 1995s hardware? Or because it was ultimately a stupid idea? Somebody like me who has n…
Yeah on the surface. $IRRELEVANT_OLD_TECH didn't catch on or it wouldn't be irrelevant but _why_ didn't it catch on?...
I'm a young person, too. Lipstick on a pig doesn't make a cow, you know.
Arguments like "It's only similar on the surface" I've found tend to give too much credence to incidental properties - this runs on X, it's widespread unlike previous solutions, it's better at specific Y use case, etc. Yet regardless of underlying platform, the concepts do not tend to evolve quickly, and it is all too often the case that their limitations have been discovered either in academia or engineering practice. These limitations will eventually be uncovered again, and no one learns from their failures or successes. Where languages and platforms shift, architecture will always bite you.
As for the reasons why, that's another fallacy. It assumes the status quo always maintains an equilibrium of what is inherently technical superior, and that popularity implies great technical qualities. The reasons can be plentiful, often it's unfortunate historical circumstances.
It's comforting to think we're on to something truly new, but this is rarely the case: http://www.dwheeler.com/innovation/innovation.html
Re: I would have hired Doug, but...
#64Earlier quoted context omitted.
As someone in their late twenties who is just starting a career in programming, it makes me very, very happy to hear things like this.
Hahah don't jump to conclusions, and don't trust anyone over 30.
Re: I would have hired Doug, but...
#65Earlier quoted context omitted.
I guess I might as well pile on. Turned 50 last year. Got my first paycheck for writing code junior year of high school (writing BASIC code on a Commodore PET!) Working on my fifth startup now.
I can't imagine all the technologies and skills you guys have acquired. If I may derail the conversation a little bit, may I ask if/how you use the things you've learned today? I mean, is it things like paradigms that have stuck with you like OOP/functional/w\e, or do you always structure your exception handling in a certain way, no matter the language? Are there skills/technologies you've been using since you've sta…
Once you grok Lisp, everything else is easy. You come to realize that the vast majority of what passes for "new technologies" is really just a re-discovery of something that exists (or is easily implemented) in CL. That makes it a lot easier (if a tad frustrating at times) to keep up.
EDIT: CLOS, and generic functions in particular, are a HUGE lever that no other language has co-opted yet.
Re: I would have hired Doug, but...
#66Re: I would have hired Doug, but...
#67- Everything I've learned may be applied to most languages. Meaning that writing testable code generally translates from BASIC to Javascript.
- Programming should always make you feel stupid. Feeling comfortable with something means that you stopped learning new things.
- Experience != Knowledge. My biggest issue with some older programmers is that they tend to confuse experience with a language, codebase, or framework with knowledge. The more you learn the less experience you will have. Think about it. You start learning Javascript after years of working with C#. What does that experience work for now? You will surely have an understanding of all the basics. But you have not yet been bitten by the == and === operators. You have to get that new experience. As time passes you will realize that it becomes a game of knowing enough versus being experienced enough.
- New technologies are exciting. A lot of people are scared by them. They feel they will be replaced. Their comfy jobs taken away. I'm not scared of this. Change is exciting because it means that I will have the chance to learn something.
- New languages might be rehashed versions of older ones. But they contain something different: Somebody else did it. That's reason enough to give it a try. Javascript might not be the most universally praised language, and it doesn't really bring much new to the scene. Its still someones interpretation of how a given problem should be solved. You might not agree with it, but that wont stop people from writing lots of JS code.
- Nostalgia is fine. Don't let it get you. Sure, I miss typing BASIC into my old C64, but its no longer relevant. I could pick up demo'ing as a hobby and learn lots of stuff about old chips and memory management tricks. It wont really help me to stay employed much.
- All these new devices are scary! I grew up programming for one kind of device. Now I have to take into account tablets, phones, tvs, and whatnot. Embrace it. Mobile is here to stay. It will keep morphing and completely remove desktop computing as we know it. The same way desktop computers removed mainframes and terminals. It is scary. Try and get excited. There is nothing more mind blowing than watching a several months old child tap on a tablet to play a game.
/old guy rant
Re: I would have hired Doug, but...
#68Earlier quoted context omitted.
I guess I might as well pile on. Turned 50 last year. Got my first paycheck for writing code junior year of high school (writing BASIC code on a Commodore PET!) Working on my fifth startup now.
I can't imagine all the technologies and skills you guys have acquired. If I may derail the conversation a little bit, may I ask if/how you use the things you've learned today? I mean, is it things like paradigms that have stuck with you like OOP/functional/w\e, or do you always structure your exception handling in a certain way, no matter the language? Are there skills/technologies you've been using since you've sta…
The tech changes - I don't use BASIC or Z80 machine code day to day. The skills that I can speak to, and the skills I see from others with this level of experience, are problem solving and communication, and secondarily the confidence that comes from having made mistakes. Few projects fail miserably solely due to technical issues and skill; in my experience failures come about because of poor communication (including documentation, but also speaking, reading body language, office politics, etc).
Re: I would have hired Doug, but...
#69"Unlike Engelbart, I have re-tooled. I now work in JavaScript in the browser and on the server. I had to walk away from the codebase that I loved. I understood that the price of relevance is to give up fighting at some point and settle for a partial victory. I think I was right in the development environment I created. But right doesn't mean the world uses what you created." Yep. That's the key to staying relevant: c…
This. I see too many older developers who complain about ageism, but what's really going on is that they're essentially the same developer they were 2-3 years into their career. If you've been working in the industry for over 20 years, employers can and should expect that you've made the most of it. Those developers have very few problems with ageism. It's the ones that have become comfortable and stagnated that have…
If you're spending your free time learning about distributed databases, machine learning, cryptography--fields that existed in the 1990's but are more relevant and developed today because of the web--you're becoming a better programmer. If you're figuring out the latest "compile to JS" language or framework, you're wasting your time. You could do all that stuff in C++ or Lisp or ML. In 1994.
Maybe there are lots of programmers who don't stay current. But I also think there are lots of employers who can't distinguish between "staying current" and "keeping up with fashion."
Re: I would have hired Doug, but...
#70If you're not interested in purchasing the book, he gave an incredible hour and a half long demonstration of his system at the Fall Joint Computer Conference. Dubbed The Mother of All Demos [1], he displayed (for the first time in the world) remote video conferencing, hypertext, text editing, and a graphical windowing system. In 1968. Definitely worth a watch.
[0] http://www.amazon.com/What-Dormouse-Said-Counterculture-Pers...