I would have hired Doug, but...(liveblog.co) |
I would have hired Doug, but...(liveblog.co) |
I'm not saying that people don't get tired/slower as they get older (I struggle with it), but I don't think it's inevitable.
Edit: seriously, what is your env like? Are you into windows, osx, unix, linux?
I sometimes find myself getting tired of technology and while I love software development, I often think about not doing it anymore. After a while it gets old constantly dealing with other people's decisions.
An easy example is working with Powershell Remoting can be a nightmare if you're not intimately familiar with both Windows itself and Windows Remoting specifically. It's extremely hard to simply use it as a shell without so much deep knowledge, something I don't find to be the case on unix systems.
Absolutely not an attack on Windows, just a recent example I've come across where I don't want to have such a deep knowledge of Windows, but I'm forced to in order to deal with a tech that, in theory, should help me be productive without having such deep knowledge.
I have my days where I just get tired of it all. The day I realized IIS forces you to load DLL's in child applications because the parent loads a DLL (even though they can use separate app pools) is one example. I can't imagine why that's the default.
I find myself having to go home and work on things like homegrown emulators and the like just to keep up my love of technology.
I feel like you have the beginnings of an entrepreneur here. You should start something that solves this problem you're seeing. The last 2 people I've heard make similar comments ended up starting their own tech-consulting firm. :)
1. "Hate it when X becomes Y and you actually just wanted Z"?
2. "Make an app or start a company that can assure people that X will become Z as quickly and painlessly as possible"
3. ??? (Something to do with YC).
4. "Become a millionaire"
I feel you here. I've been the go to sysadmin at every startup I've worked it. Whether it's Windows Servers, vSphere clusters, VLANs on HP or Cisco, it gets old doing the same thing at a different datacenter every couple of months. Especially when you have to learn some vendor specific crap that will almost NEVER be relevant to anything else outside that specific use case.
Thankfully I've been able to move (push? ;) my clients onto more open technologies like Linux, LXC, Openstack etc. all of which means the skills I learn doing this sysadmin stuff are at least tangentially relevant to my main job (unified comms development).
Ultimately like a lot of oldies here (myself included ;) working on the stuff you really want to do in your spare time is where you learn the cool stuff that helps you land the next great gig.
I also like the way open source options have completely eliminated the necessity for me to work with commercial languages and technologies, which I always found a bit tedious.
It truly is an exciting time to be a software engineer. Barring any serious illness or accident, I'm looking forward to doing it for another 30 to 40 years.
I find it fascinating that the gradual adoption of new technology maps onto human time spans like this. This makes me optimistic that even technology that is far ahead of its time can succeed when developed with patience.
Maybe I should do a graybeards Meetup group or something. Get some reverse-discrimination going...
Yes, the field can be insular, yes, there's benefit from cross-pollination from other disciplines, but the field is vast, and it's reach is still expanding. There are plenty of people immigrating and emigrating from CS that are sharing ideas, you don't have to be one if you don't want to be. If you're happy with what you do, and you can make a living doing it, enjoy it. It's privilege, not a curse.
I am in the opposite side, I am also very excited about computer science so I focus now on sales and business development because I can earn much more than developing software. Now coding is a hobby again and a complementary knowledge to sales.
I.e. There are plenty of 20-somethings that learn one tool and don't want to switch. Don't blame age on a 50-year-old being stuck using the tools they know; blame the person.
You see, in this career you have to be willing to drop everything and learn a new thing. All the time. Make learning new things part of your career.
My strategy is to watch for the “next big thing” and stay at the leading edge of that. 10 years ago, for me, it was the Ruby language, and that has borne much fruit. Now it looks like it’s becoming Elixir, so I’ve been building up a portfolio in that language… just for fun (and maybe profit. Well… Probably profit, down the line.)
Are there 20 to 50 times more Ruby jobs than Elixir jobs right now? Probably. Were there 20 to 50 times more Java jobs than Ruby jobs 10 years ago? Yes. (See where I'm going with this strategy?)
I may not stay as fast as the newest coders, but I will write better code in less time than the guy who writes faster code with more embedded technical debt (which must be paid off in spades, with time, later on), and I’m pretty sure that my ability to mentor others is top-notch, and any good company with 40+ cohorts in management (if also including younger on the front lines) is going to recognize all of that.
I also think that (like it or not… and yep, I struggle with this too) it’s even more important as you age to stay on top of your health… especially in a sedentary job like engineering. It may be a conflating variable here- the demands of family and career (in addition to the effects of age) may add to an engineer’s waistline and double-chin and consequently reduce his “oomph” (or to put it blunter, his T), and ALL of this may contribute to a distaste by the younger teams in hiring the 50+ engineer… Not the age itself, per se, but the impression and deleterious health effects that may typically come along with it. It would be interesting to see statistics which took fitness into consideration.
It may of course seem inappropriate to mention, but the statistics are out there-
http://www.canada.com/health/Bias+against+obese+people+incre...
http://listverse.com/2013/09/27/10-frightening-ways-we-discr... (scroll down to #8)
http://business.time.com/2012/05/02/why-being-overweight-cou...
I DO NOT condone this (heck, I'm a bit overweight right now and these stats are working against me... I'm just aware of them), I'm just wondering if this is a conflating variable.
To all you budding and early-career engineers- If you're doing it because you love it... Don't worry too much. Just stay on your toes, be willing to learn always, and by all means DO NOT EVER "marry a company." The age of the 30-years-at-one-company committed engineer is DONE. You need to look out for #1. Your career will benefit greatly if you switch jobs every so often... Employers do not have your best interests at heart. Don't believe me? http://www.forbes.com/sites/cameronkeng/2014/06/22/employees...
Lastly, if you're 5+ years into this career, NEVER settle for 2 weeks' vacation to start. It's not only a load of bullshit, it's institutionalized hazing AND it hurts the employer (because you'll be less productive overall for the same pay)! http://www.theatlantic.com/business/archive/2012/08/the-case...
What do you think about golang or rust?
from time to time, i would see our team hiring engineer with gray hair and requiring special mechanical keyboard, and we all thought "mm.. interesting."
Well youngster, you seem to be falling behind the latest trends. Maybe you're not as young as you think. Don't you know all the fashionable programmers/gamers are using mechanical keyboards?
Go ahead and aspire to management if you want, but don't assume everybody wants the same as you. And I hope your attitude changes before you achieve it.
PS: mechanical tenkeyless keyboards ROCK!
I like when the older programmers are more hands on, because I can learn a lot from them.
I also use mechanical keyboards.
- 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
Yep. That's the key to staying relevant: change with the times.
best slogan ever
I'm 37. I think ageism is a very real problem and I hope people will consider doing more suing even if they don't have to. Some people need to be sued. We need some class actions.
Right from the top down of Silicon Valley ageism is rampant and in your face. For example, Sam Altman has publicly made explicitly agist remarks.
You kids may not think its a big deal now but give it ten years or so. You will see.
Of course in 10-15 years everyone will be in the same boat, being completely ignored by the ASIs.
Exactly, so why give them any credence now?? You only give these people power if you do. That's great that's what Sam Altman thinks; he's "young", but ya know, when he's 50, then what? He'll probably say "oh, that's obviously not how I see things now". Or Zuck. He's ancient to a 19yr old and the only reason he doesn't care about this is because he's rich and runs Facebook.
I'm older than you and have been through enough startups and honestly I've dealt with ageism enough to the point that it doesn't even phase me anymore - I've moved past it. But this is because I've made it that way. If people don't want to work with me, np, there are plenty of other opportunities out there.
Sure, you might not get hired at the hot startup you just interviewed at. But honestly, if that's the case, who cares? Make your own way, your own rules and then you can decide to hire young or older people or not.
If 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...
function secondsSince (when) {
var now = new Date ();
when = new Date (when);
return ((now - when) / 1000);
}
Or this is just a very case specific function and the input is already sanitized in a way that is prepared for this function?
github is here: https://github.com/scripting/pagepark/blob/master/lib/utils....
Everybody has been influenced by Engelbart, but nobody uses NLS. Merely the ideas went into all the computers that we use today. Engelbart was so frustrated because he had more great ideas, but they were difficult to develop and he couldn’t get funding.
Winer specifically mentions Userland Frontier. It was a useful tool, which I’m sure helped with the development of RSS, just as NeXT Project Builder helped with the development of WWW. The problem with the Engelbart comparison is that there are countless other development environments, many of them free and/or not in a dialect of C and/or available via git, while the Mother of All Demos was unique.
I think the open-sourcing of Frontier was too little, too late. Frontier is an impressive achievement, but I don’t see why it should be interesting to me.
I've played with folks in their late 80s, and most of the folks I play with weekly in a large jazz band are between 50 and 70. I also play bi-weekly with an orchestra with members ranging from 12-82.
Maybe I lack the same perspective I lacked when I was younger (and thought that 45 was pretty old), but I absolutely don't see how 60 is old. 80 is old, maybe, but 60 just isn't that old, and I don't mean that in the attitude sense, as with:
"The ones that love me say I'm really young, and I appreciate that. I think they mean my thinking is flexible, and I'm excited about the future, like a young person might be."
So is he in touch with Roky?
Working in the web industry, the second-hardest thing I find (after pace of change/fascination with "New! Shiny!") is the vision of people can be measured in months to 3-4 years. Applications are not built with the thought they will be running in a decade; it's assumed they'll be rewritten in New Language X with New Architecture Y long before that.
To older programmers: if you work in the web field, how do you handle/deal with this?
What processes is he using? What tools and underpinnings that allow him to quickly try out new ideas?
When we bring on young people they have a ton of energy and are excited to try every new thing which, don't get me wrong, is awesome. But they do occasionally criticize me for moving too cautiously, even though I am plenty excited about trying new things. I always think to myself, call me back in about 15 years and we'll see whether you evolve into the rockstar that you envision yourself to be, or else if you stagnate, burn out, move onto something else, etc. I always hope they do become the rockstar.
As for learning new programming skills I still enjoy it, but I think this is because for me languages/frameworks/algorithms are just tools. The real fun is in using the right tool to solve a complex problem.
What is the gift that will keep on giving? Write about what you know. Write about your experiences and insights. Even thousands of years from now people may come across your work and given the advances they will be living amongst will almost certainly be interested in what you had to say.
(The artist that did that music video is 74)
The people that are resourceful will always find a way. Sometimes this may mean on your own, sometimes with a group. But as long as you can keep learning and just 'do things', you will be light years ahead of those that don't know what to do and look to other people to tell them.
From Steve Jobs:
"Everything around you that you call life was made up by people that were no smarter than you and you can change it, you can influence it, you can build your own things that other people can use."
It's hard sometimes (a lot of the time??) to get over that bit where 'no one is smarter than you'. (I'm not as smart as a Google PhD, am I??..) Once you can and you chart your own course because you are resourceful and confident and someone who can do things, then you won't need to ask the question you asked. :)
Good Luck! (I'm still on this journey)
Did some nice things professionally, too.
This is the most absurd sentence I've read in weeks. Wow, man. Talk to some people a bit older than you, maybe, and realize that you haven't done anything.
You're fortunate that you've done what you have wanted to achieve at 30 yrs old.
Unfortunate that you feel like you're done at age 30.
Software engineering is such an entitled world, it is ridiculous. As someone who has seen the world of menial work, I will never, ever leave it. I feel blessed. You should too. You just don't know it.
A common version of this is to complain about a lack of vacation time (even though you have 4 weeks, plus holidays, plus sick time, plus sometimes getting to work from home), as if struggling menial workers barely making above minimum wage are spending half the year in the Bahamas. [Note: this paragraph is written from a US perspective.]
"Golden handcuffs" is a similar term. It's not that there is no validity to these notions or that the phenomenon of golden handcuffs doesn't actually occur, because it most certainly does. It's just that, in their typical usage that I see, these terms are used to invent an abstract struggle that upper middle class people are supposedly facing in order to assuage guilt over their own fortune.
My friend who was a plumber recognized this. He also realised that plumbing is not something that you want to be trapped in. As you age it get's harder and harder to be constantly crouching down and contorting yourself into those hard to reach areas. So he jumped ship and is retraining as an architect.
Programming doesn't have that limitation. Barring the odd bit of RSI there is nothing to stop you coding until the day you drop.
http://www.homeharmonizing.com/wp-content/uploads/2013/09/si...
I like software, but for instance, I really couldn't make the same as a photographer (plus, I don't want to shoot weddings or people or stock photos and stuff...).
However there are some great examples of stock traders becoming potters and things like that, so it CAN be done, you just have to change what things you are addicted to - or earn a bunch first :)
For the record, I've been programming professionally for close to 25 years, and I still love it - http://henrikwarne.com/2012/06/02/why-i-love-coding/
But where do you go? You haven't "seriously tried doing anything else" for the last 30 years. A trap is a trap because you cannon leave it.
How would be that possible?
Good spirit and even better understanding of the Zeitgeist :)
The one problem is being slave to Apple and Google having absolute control of the OS, software and apps you can run. The only plus is their hegemony does help with security but neither one of them is even remotely trustable with the keys to every personal computer on the planet. There is irony that the creator of the big brother commercial in 1984 is increasingly, you know, big brother.
P.S.
Not sure how Daves self promotion blogging rose so far on hacker news. It actually has almost nothing to do with Doug Engelbart. He was just name dropping, something he often does, before doing what he usually does, self promotion. Yes there is that age discrimination angle which plays well with some old programmers, but not me.
People who spend their time complaining about discrimination should spend more time doing something that people will value regardless of your age, sex or gender. At that point your age, sex and gender become irrelevent especially on the Internet which tends to be blind to these things until you wear them on your sleeve. Dave likes to use his age to promote a martyr complex angle.
Ive looked at most of Daves recent projects and none of them are particularly interesting.
For pros (programmers) there will continue to exist dedicated large displays, pro keyboards and whatever else. Look at professional gear of audio or video engineers, or CAD users, they have pretty impressive devices to use with computers. It's just not what mass users have at home.
Fully offline desktop computing will remain possible, much like running a C64 or an MSX machine (possibly in a form of new, much cooler hardware) remains possible. It's just not very relevant.
I wonder when smartphone platforms will become self-hosting.
We've largely circled back to the mainframe/terminal model, except with a prettier face. Your mobile device is the terminal, and the server cloud is the mainframe.
The thought is: "What, again!? Haven't we buried this weakly-typed language back in the 90s, years before C# had been released?"
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 next new/old thing.
On the other hand, it gets easier since none of the concepts are new anymore, and I tell myself, "hey, if you want to pay me to build a client-server app in the browser like it was 1995 (substitute Powerbuilder for Firefox/Chrome), great, happy to take your money."
An example of what I mean: the Apple Newton, and then 10 years later the Palm Pilot, and then 10 years later Windows CE and flip-phones supporting J2ME, and then 10 years later touchscreen phones and tablets. There have been four generations of "mobile app developers", but only the latest generation has seen any traction for their apps. This time the idea stuck; it will stay around, rather than coming around again.
If something like Paypal's prototype service (beaming money from one Palm Pilot to another) were set in this "revolution" of mobile instead of that one, it would be much more successful.
Though that means that you have acknowledge that things were not all that great back then as you remember - which seems to get harder as one grows older.
Today Functional Programming is introducing all kinds of new ideas and approaches, and while I often find FP people over-earnest and irritating, I'm still able to recognize that they offer something new, even if it isn't all they think it is.
Impure functional languages like Haskell have shown that it's possible to get many of the advantages of a purely functional language while still being able to implement side-effects, which is an amazingly cool trick despite Haskeller's annoying insistance that their side-effect-ful "language" is "purely functional" even if they have to redefine "language" to make it true.
This is true of all the supposedly "pure" functional languages, which universally come with caveats that amount to "disregarding all the sex I've had, I am a virgin", but that's just a somewhat off-putting quirk of the community. The languages themselves are full of interesting ideas that are being adopted by less purity-obsessed languages, and this is a good thing in the same way that the OO-purism of SmallTalk drove other more mainstream languages to adopt OO ideas and bring them in adulterated form to the unwashed masses (which had the nice side-effect of driving the purists nuts, and who doesn't want to see that?)
So I personally get the feeling that it's a great time to be alive and active as a software developer. We're barely out of the "bash rocks together to make hammer-like-thing" era of programming, and we get to be part of the most explosive growth phase of the most important technological growth curve in human history: the algorithmization of work.
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 never heard of Powerbuilder would have to look into the technology, which would take longer but it would prevent me from just dismissing it because "this has been done before".
Remember it isn't what you don't know that gets you, it is what you know for damn sure that just isn't so.
I am not saying this is the case for all old developers, but it would be my concern.
Because every hour I spend investing in a new stack and its details is an hour I can't spend thinking about product-level details, can't spend learning more learning about organizational-level matters, can't spend on improving more timeless investments like statistics, math, and soft/interpersonal skills. Not to mention fun things like music and travel and enjoying the company of people you like.
It wouldn't be so bad if most of the new shiny things in the software world were an order of magnitude better. But saying that 1/4 new frameworks or even languages present tha kind of power/productivity jump would be optimistic.
It's also hard to predict what will be popular five years from now. I thought that using Javascript on the server was pants-on-head retarded, but it's very popular, with no signs of passing on.
There is value in keeping up with trends, but on the flip side there is value in sticking with sound ideas, even if they are not necessarily attractive in the labor market, and learn enough to be employable or self-sustainable in some regard.
I would say server-side JS might not necessarily be a great long-term prospect, at least in part due to limitations with SMP and unwieldy concurrency models. Even if it persists, the value of knowing might be more of a labor necessity than any inherent utility.
Because programming operates on lots of trends and conjecture, knowing which ones not to waste time on is a much more valuable skill than jumping to stay "relevant".
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."
And yet I do feel the ageism. I understand it and I'm not angry about it, but it's real, nonetheless. It's not a good feeling.
When coerced to a number, it's the number of milliseconds since January 1, 1970.
If you wanted to know the number of seconds since January 1, 1970, you could divide by 1000. Since JavaScript will do the coercion for you automatically you can pretty much treat a date object as if it were a number.
This is basically a utility routine that I use for debugging messages to say how long an operation took.
Here's an example of its use:
https://github.com/scripting/myWordEditor/blob/master/script...
It's especially nice because JavaScript automatically does real arithmetic on the division, so you get fractions of seconds displayed in the console.
I use this routine a lot. Helps me spot performance problems. Nice to have, not a crucial routine.
Hope this helps! ;-)
Typically I believe new Date() is current time/date (http://www.w3schools.com/js/tryit.asp?filename=tryjs_date_ne...) in my experience.
As far as your question how to deal with 5/8/2015, and 8/5/2015, to be honest I don't know that answer.
a Date can be constructed with either a number of milliseconds since the epoch or a string in a format recognised by the Date.parse() method (IETF-compliant RFC 2822 timestamps and also a version of ISO8601)
So far I love it. It's bent my brain into pretty shapes.
It borrows a lot from Erlang, which it sits on top of, such as incredibly fast process spawning, and the OTP library.
But its syntax is sooooo much nicer (at least coming from Ruby).
The potentially extreme fault tolerance ("nine nines" is not unheard-of), and things like hot code deployment, appeals to me as a web developer.
It also has some unique features as far as languages go, I believe... such as full-fledged macros in a non-homoiconic language.
If you want to dabble in it, Dave Thomas' book on it is awesome: https://pragprog.com/book/elixir/programming-elixir
I went into my thoughts on Go here, a week or 2 ago
https://news.ycombinator.com/item?id=9409803
I went into my thoughts on Elixir here, around the same time
http://www.austinpsychfest.com/portfolio-item/the-13th-floor...
It's kind of funny... I just thought he was some random (occasionally iffy, somewhat nutty) drummer.
I know I have friends that don't want to resign themselves to a life of programming/software engineering/whatever you want to call it because they see a ceiling to their compensation, or career path. Theres only so many numbers they can tack on to your title before it becomes meaningless.
You really only escape the ceiling going into business for yourself. And there probably has never been a time where it's easier to go into business than the last decade, because of the relatively low cost and high reward of developing software. Maybe that's why programmers are often restless, because the path to wealth seems close at hand (even when it's much harder than it seems, and requires many more skills than just programming).
Low-wage jobs are their own cyclical trap, which can lead to not enough resources to improve your situation and apathy towards your day-to-day life. You can easily get stuck in a rut.
I don't think that neither the lawer nor the physician when they get home keep thinking about what their job...
For us coders is different, there was a question like: "What you think while you are coding ?" the majority of the answer was "nothing", the most part of my job is done when I am away from the keyboard, when I walk, dream, read, talk with other people...
I love it, but I am also scared that I am missing a whole word just because I am too focus on computer for a not even too long while...
I think any dedicated professional will have issues at some point unplugging themselves from their profession to pursue other facets of life.
RSI is no joke.
People wonder why I don't trust doctors, it's not that I don't trust all of them, just most I've dealt with are suspect. There really needs to be a better physician review resource online.
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.
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?
I can clearly that each year more and more interesting things appear. The speed is also increasing, in way I can't digest it all. It's difficult what to choose, to prioritize is the key to deal with it.
I always get myself wondering how much new things I will see next years.
I'm 30 now, and I started with 17.
So now when I sometimes think of my mortality, the thing I regret is the programming I can't do when I'm gone. Or maybe there is programming after death? I'm hopeful. :)
In the meanwhile, the free time that's opened up from not programming as much is being wisely invested. I'm working hard on my guitar, and before I go dammit, I'm going to shred like a pro!
Well, there's no law against things being both terrible and popular. It is quite common.
Apple Newton: 1993
Palm Pilot: 1997
Smartphones: ~2002
iPhone: 2007
Android: 2008
iPad: 2010
I remember the day that I got java 0.7 running on my spark 20. I would never touch the STL again, never have to worry about malloc and #def overwrites. No more gdb.
There's not much nice for c/c++ devs, pity them.
How many C/C++ programs?
I guess now people think I'm a crank; I posted here that I thought doctors just don't spend enough time with their patients and it's worrying and I was downvoted and mocked pretty hard.
Unfortunately I'm not confident that online resources would allow better decisions. I'm not convinced that patients would, by and large, do a much better job evaluating the quality of their doctors' care. The doctor who just gave patients antibiotics whenever they asked for them, whether or not it was appropriate, would probably be more popular in such a service than the doctor who took the time to understand their condition and explain that that wasn't an appopriate treatment.
I like to think of it like evolution. Most mutations are not advantageous and die off quickly. The ones that are allow you to outcompete competitors. I've learned 3 new languages this year, toyed with 2 new data stores, and played with/read about countless frameworks and libraries. Most of these technologies took up less than an hour of my time. Some I devoted a half day of hacking with. Others I stuck with for longer. From all of this, I've filtered it down to a handful of tools that I'd consider using in specific situations. This is what I consider staying current. I consider this to be between 10% and 20% of my job as a leader in my engineering org. And it's what I feel that I need to do so that when it's decided that we need to use something other than what we're using now, I feel that I can come up to speed on that new technology quickly.
It gets frustrating interviewing developers who, for the past 20 years, have programmed nothing but Java. Sure, they know a few libraries within the Java ecosystem but, for the most part, all their learning from the past decade was domain-specific knowledge from their last job. And then they want to be rewarded for that "experience" at a new employer. Sorry, that's not going to happen. I can hire a newly-graduated university hire who's more willing and able to put in the time to learn for half what I'd have to pay you. That's not ageism, that's common sense. On the other hand, when I encounter a developer with 20 years experience under their belt that has used that time wisely and has enough tools in their utility belt to make Batman jealous, I'm more than willing to bring them on and pay them accordingly. They'll be a great mentor to all the younger hires I'm forced to make.
The key point of contention that I have with you is that I don't consider time spent learning to be wasted. Ever. Learning itself is a skill that needs to be practiced, even if that means learning something that you'll never use.
One can write object oriented code (with clear modules and interfaces) in plain-old-C (see "C Interfaces and Implementations"), just as one can write Fortran in Ruby (and I don't mean by creating a DSL sensitive to positions of characters in a line).
Shouldn't having the knowledge of what you could do in 1994 make you that much better suited to doing it in 2015 even if you have to spend a few days learning the faddish way of expressing the concepts?
Some day a person younger than you will say "this is just like Javascript that failed back in the day".
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
Leaving aside the (substantial) ageism issues here, it looks to me like your reading of the GP's complaint is incorrect.
It's not a judgment that $NEW_TECH is going to not catch on or otherwise fail because it's just like $NOW_IRRELEVANT_OLD_TECH.
It's the observation that much of the $NEW_TECH that catches on and succeeds for a time often turns out to offer approximately the same utility as $NOW_IRRELEVANT_OLD_TECH... and similar adoption costs, which we pay over and over again. We rent rather than buy.
There are counterexamples I can think of -- new tools/abstractions/practices I've adopted that have resulted in near order-of-magnitude gains. But the ratio of these to other $NEW_TECH that just sort of shuffles the dirt around... well, that probably approaches another order-of-magnitude relationship.
And there's also the argument about the aggregation of marginal gains (see Brailsford and the British cycling team); approximately the same utility isn't quite the same thing as exactly the same utility and I don't think that should be overlooked. In fact, I think one could put together a specific case that the GP is arguably not correct in making an even comparison between Powerbuilder and webapps on precisely such a basis.
Still, an aggregation of marginal gains approach only ends up helpful if the marginal and opportunity costs are low.
How often do you find that's true for $NEW_TECH over $NOW_IRRELEVANT_OLD_TECH?
And since we're being free with judgments about age here (generalizations, naturally -- not that you or I would ever let such general thinking affect our judgment when it comes to individuals)... do most young developers really have enough knowledge and experience to answer that question effectively?
Further, most people seem to have little appreciation of the difference between order-of-magnitude gains and shuffling the dirt around. Certainly, there are those who are wrong in assuming anything new is just dirt-shuffling, but for anyone without experience, everything offers an order of magnitude. And this really is an engineering discipline---$NEW_TECH is never as good as its proponents say, but it the best trade off in some circumstances, while $OLD_TECH is never as bad (or good) as the "general consensus" would have you believe, while it is almost certainly inappropriate under some scenarios.
One the one hand, I suspect ams6110 was referring more to those things we give names like "pattern," "architecture," and "paradigm," maybe even "stack," "platform," or "library" than to languages. On the other, my suspicion may be wrong, and I'd agree with him about it if it were anyway; so little that's been developed in the world of programming languages recently is anything new, and what isn't is as often as not a poor reimagining of something Lisp or ML had figured out pretty damn well ages ago, thank you very much.
Still, though, progress has been made even on the mainstays, even if the industry hasn't quite caught on yet.
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—even though these are all different skill-sets—because it's more important to have a good general than to have a good soldier, and so if you could, theoretically, do both tasks well, then the military's comparative advantage in allocating your brainpower is to make you a general.
In tech, we see a "career track" of engineers that attempts to be a meritocracy, with the engineering leads and fellows being the guys who have been there the longest—but that's more like the NCO track of the military, valuing experience for the job they're doing, but not the raw brainpower and tenacity to do jobs well generally. Management, meanwhile, is not-at-all a meritocracy; managers hire from outside based on credentialism, and engineers are "pushed into" management based on credence from fellow devs (the same thing you get from being a battle-tested NCO), rather than being "pulled in" by an actual need.
This isn't true in any modern military.
And there is some truth I am told in the old adage that the NCO's really run the Army they just let Rupert pretend he's in charge.
And what, exactly, is it that you're losing? You can have a pretty damn fine life without getting anywhere near the 1%.
The best gift I was ever given was to grow up on a farm. I'm doing way better than my peers.
The 1% are living in a way that will last longer than they will, on a scale that the rest of us won't achieve in our lifetimes. That's okay, certainly, but to pretend like there's no reason to work towards the 1% is silly.
'My name is Ozymandias, king of kings:
Look on my works, ye Mighty, and despair!'
Nothing beside remains. Round the decay
Of that colossal wreck, boundless and bare
The lone and level sands stretch far away.Under this model, 100% of the public discourse would be devoted towards achieving money and status. That does not mean that everybody (or even a majority of people) pursue those goals, only that people who do talk about it a whole lot more than people who don't.
It's $521,411 per household[0] (the household bit is probably where we're getting confused).
$500k, $400k, either way, the goal is as I've stated; once you've taken care of yourself, you start wanting to take care of others. There is always motivation to make more, until everyone is provided for, and even when you've provided for everyone you care about, providing for the general wellbeing of humanity becomes a priority (Gates, Buffet, et al).
[0] -- http://www.usfunds.com/investor-library/frank-talk/what-does-it-take-to-be-in-the-top-1-percent-not-as-much-as-you-think/#.VUqZYtpVikoAnd I've found that you start wanting to type faster, to create even more noise. So it might actually make you more productive, in a weird way.
For me it's always been about problem solving rather than simple fascination with some particular technology. If I can solve a problem with a keyboard macro in Emacs, great. If it requires Perl or Java or javascript, so be it.
I try to use the tool that's appropriate. If I can solve a problem quickly and move onto something more interesting, one-and-done.
If I have to stop and learn something new (e.g., WKWebView in iOS ObjC) to get my task done, so be it, and I'll put in some late nights to get there because at my age, I'm a bit paranoid about looking bad so I try to give the good folks at HQ no reason to doubt me. I spend a lot of time on Stack Overflow and Youtube doing concentrated learning.
But the real thing is what others have also mentioned: properly defining a problem that needs to be solved, proper communication, keep good records, and try to maintain transparency, honesty, and pleasant comportment at all times.
Honestly the older I get, the less I notice people's age. If someone half my age knows something I don't, then the way I see it, they have something to teach me. I've been to many conferences and watched many youtube tutorials where the teacher was very young (from my wizened perspective) but the information is why I'm there and that's all I care about.
What do I think about young people? (you didn't ask but I'm saying it anyway)
I love young people. They have so much spirit, so much energy and creativity. I keep hearing critical (snarky) things about millennials this, X-gen that. But I don't see it. The young people I've been around (for a while I was back in school full time, surrounded by 20-somethings and a few 30-somethings) were a joy. Fun, humorous, inquisitive.
Everyone has his faults, not least myself, and I believe as we get older we become more tolerant of others' faults and shortcomings. In fact that may be the single hallmark of growing older (apart from physical issues).
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.
So much this. (From a soon-to-be geezer who's staring down 40 soon.)
Check out Dylan, Julia, and my old hobby language Magpie[1].
I highly recommend guile to anyone who wants the battery included nature of common lisp. I know that racket is also a great choice here, I just have little experience with it.
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).
There's plenty of languages I've used over the years that I have no use for today, or hardly even remember: Basic, FORTRAN, assembler, Pascal. None of those languages even had exception handling, so it's hard to say that it influenced my thinking on the subject, except by forcing me to be familiar with the alternatives.
Today it's C++ and C# that pay the bills, with as much Python as I can sneak in. Next up in the queue is Javascript, for which I'm admittedly overdue, but that one's entirely on my own time.
Python is the interesting one of the bunch. I was exposed to it about 1995, when a coworker selected it as an embedded scripting language for our product. I didn't pay much attention to it at the time, as it was outside of my immediate responsibilities. It was selected again as an embedded scripting language at my next employer around 2003. This time I paid attention, and came to love it. It's the language that lets me turn my thoughts into results the fastest.
Thanks for asking the question, I've never stopped to think about my programming history in this much detail.
1 8 + A 5 + 0 0 + 6 5 + 0 1 + 8 5 + F A + A 9 + 0 0 + 8 5 + F B + 4 C + 4 F + 1 C
I remember how much like some kind of incantation it was. I still get that feeling. And I've had the good fortune to work some fun, powerful, and interesting magic with those incantations.
I suspect that most younger people haven't yet seen their tech choices slip into decay and disuse. And they hang on tightly, hoping to expend less effort in learning as time goes by and they master that tech. It's a vain hope. The essential part of the experience is the underlying creativity, the joy of getting to the next ledge, and really understanding what a marvelous thing a computer is.
Not sure I have any specific sources to share (others might) but after working with all types of hardware, languages, business realms and what not... you start to see patterns. Human behavior patterns, mostly; the same sorts of needs were there 30 years ago as are here today. People need stuff done yesterday, don't know how to describe what they want, oversold a client on something, etc. The numbers may be bigger, the gigahertz faster, and the memory far greater than people could have imagined, but the problems of translating what people say in to what they want via code is ... fundamentally still the same.
A 16k RAM module was ... $200 in my early days. Then a few years later I got 512k for only $150. Today I can get a 16 gig USB stick for $10, at at a local grocery store checkout aisle no less.
No doubt technology has changed and become more ubiquitous. Peoples' expectations of what's possible and what's normal are somewhat different today than 10-20-30 years ago, but the communication problems are still largely the same. Who's in charge of a project? What are the parameters? What defines "success"?
I'm not sure there's any real silver bullet here - most of the "mythical man month" stuff (from even before my time!) is still largely true (speaking in generalities because I can't think of every single line right now).
Learn to figure out how to communicate better - emails, phone, IM, paper, phone, f2f, etc - they all require different skills, and have different impacts on different teams.
Happy to answer more specific questions here or via email - mgkimsal@gmail.com - not sure if I'm just rambling now or not.
The main thing I learned was to be able to look at code and determine if it was going to actually do what I wanted it to do without having to run it through the debugger a couple times.
It's important to spend time thinking about and reviewing code when edit, compile, and test cycles start to get long. There are a lot of instances where that still applies, such as with multi-threaded programming, integration testing or long running jobs.
I also learned the value of having muscle memory for APIs. Sure you can look things up in a jiffy, but actually rote memorizing stuff that is used often can speed development up.
Throughout this thread, I've noted a distinct lack of dogma about everyone's evolution as a programmer. While I imagine there was some of it during the popular phase of many of these languages, it's nice to see mostly pragmatism in everyone's career journey.