More options:
- Go solo. At 40 you should be experienced enough to handle up to mid-sized projects, alone and on a reasonable time-frame. Try to pick projects that your clients will actually use, with new features and support contracts you will have steady income for the long-term.
- Go startup. Stop thinking you need to come up with the next über-for-x. There are plenty of opportunities for small sass shops that cater locally and provide sufficient income for a micro successful business. At worst you'll be acquired.
- Go sidetrack. I read someone said every business is a software business. Start a different career/business and you'll be doing the IT needs yourself. That alone is a huge competitive advantage.
These options allow you to continue programming after 40 and you should! It is an urban myth that past 35 programmers are not as good b/c they get tired faster or make more mistakes? The truth is that 20-somethings can put up with very long hours b/c they have the time (mainly due to not having a wife and kids) while 40-somethings have the experience to go right to the answer. That's productive vs efficient. I like to use a soccer analogy: a young defender is good when he's fast because he can outrun the attacker, while an old and slow defender is better because he knows where to stand and wait for the attacker. Experience is gold.
The problem with age is you become less flexible. If your have a business where you know what you will be doing in 6 months time then experience is great - when your plans change weekly then the flexibility of youth is what you want.
Define "less flexible", someone doing consulting has flexibility to pick and choose clients. Someone who continually learns is capable of picking and choosing technologies. I would think even someone in their twenties would have issues with "plans changing weekly".
I've known people with nest eggs happy to take cuts for something interesting.
But I also know with experience comes a skeptical eye for being asked to carry extra load for less upside (yet same or more risk).
A story from some time back told to me. Founders had a UI, an algorithm, and an idea. It had merit. They sought someone out to build and run the actual service. The funding was angel, the role was senior to C-level, but the salary offered was 40-60k cut for a senior engineer at the usual suspects, equity capped at 4% assuming a trade off in salary.
Risk and reward to build out infrastructure and productize someone's idea? I could certainly get a couple of people to build it out in a "get us to a-round funding" in those guidelines, maybe even beyond. But as expectations on a non-founding senior/early member, one would assume way too much risk for the potential upside.
It isn't non-technical founder seeking technical co-founder waters, but damn close.
Age makes employees less flexible in some senses like not being willing to put up with some of the crap that younger people will (60 hour weeks, endless crunches, etc.) I once did, but will no longer tolerate that crap from an employer.
But being older doesn't mean you stop learning, adapting to change, or lose the ability to deal with moving targets. I'm hopping rapidly between roles and widely varied tasks at my current gig better than I would have in my 20s or 30s since I've got more perspective and experience.
A more mature person might point out that if your plans change weekly you likely have a systemic problem, though, and would be more likely to point out the breakage.
>Age makes employees less flexible in some senses like not being willing to put up with some of the crap that younger people will (60 hour weeks, endless crunches, etc.)
This stuff is a false economy anyhow since it inevitably leads to a massive ramp up in technical debt even with the very best programmers.
I am not a young developer, yet I recognise what it is about youth that is attractive to employers. This is reality and I don't think there is anything to gained by pretending otherwise.
I am not suggesting that you don't have a problem if your plans change weekly, but unfortunately this is the way many businesses are run. When you have a very fluid workflow youth is very attractive.
It is not a matter of planning, but of adapting to change. I have worked in environments where change occurred regularly (outside forces at work) and I saw it was the young who coped with this change best.
I would need a concrete example but I'm not buying your assertion. Some of the most flexible people I know are all developers, irrespective of age. If you told me that older developers were more likely to ask questions and seek evidence before making a change I'd believe that. I find that most people confuse easy adaptation to change with pliability due to lack of experience.
I've seen the exact opposite. Startup, pivoted 3x in 3 years. The younger devs have a much harder time accepting he pivot and figuring out how to adapt. So without any more substantive evidence, my experience definitely refutes this silly argument that youth is more flexible.
> The problem with age is you become less flexible.
For those who use their minds, which should be common in this field, those effects become noticeable much later in life. For most of the working lifespan the dominant effect will be an increase in experience.
I'd say more generally, as someone in their early 30s, that my experience says that if you're changing the plan weekly, the problem isn't with the employee, flexible or not.
In general, if the plan is changing every week, that probably means that the work I did last week was mostly pointless. That's a great way to burn someone out.
Good news though! I do contract work, and if you insist on changing the plan every week, you won't need to worry about whether I'm flexible or inflexible. I'll happily fire a client who can't make up their mind and thinks that the best path is to change direction every week.
Inflexibility is in my experience more often associated with a person than with their age. I've seen 30 year old devs that were absolutely incapable of changing over to new tech as it became available and I've seen 55+ people dig in with gusto. It's a mentality thing. Sure, mentality can change over time, maybe someone that's older is going to give something new a little while longer before hopping on the bandwagon or maybe they've already seen something similar fail in the past which is why they might be reluctant.
But flexibility is a hard-to-measure parameter to begin with and you need to know the people and their reasons before you can make call about it rather than simply their age.
I'm over 40 and I've always worked as a consultant. Until recently I was the sole developer on a site doing eight figures in revenue (now I'm team lead). Without being arrogant here, if my skills match but someone doesn't want my level of experience, it's not a good sign for the someone.
On the flip side, I would love to throw out all of the languages and frameworks I've been using for the past few years and learn entirely new tech. That's part of the point of being in this business!
If you're a startup and have a bias against us greybeards, you're only hurting yourself. We'll learn your framework-du-jour and tell you how it bears an uncanny resemblance to something that didn't work so well in the past. Or maybe we've never seen anything like it, in which case we'll be delighted to cast aside all that old crap.
I usually summarize this thusly: "I have already made the mistake you are about to make". It should be obvious the time savings would worth it to "rent" me. And I am months away from my 40th birthday.
It's funny you should say that. A few years ago, at a company whose name everyone here knows I, an old gray-hair, almost lost my full-time job for warning a VP that she was about to make a mistake I'd seen before. I honestly thought she was joking when she told me about the approach she was going to use to deal with a "hard deadline" of four months. I laughed along with her joke until, with a shock, we both realized that I was actually laughing at her actual plan. She became indignant and ended our meeting (just the two of us), getting me transferred for "not being supportive of the team" and trying, unsuccessfully, to get me fired.
She gave the job to her three dozen "supportive" young programmers, who ended up taking 28 months (!!) to get the "4-month" project finally working.
So, after all that, did she eventually apologize and tell me that, yes, she'd made the same mistake I told her I'd seen before with the same results for the same reason, and that she should have at least asked me more about it instead of throwing me out? Of course not. This is the real world. She never spoke to me again and never forgave me.
To be honest, I don't find it that surprising. Being laughed at is not something people take kindly to. Of all the possible ways of letting her know that you thought her plan sucked, that was the one that was doomed to fail right from the start.
For sure. Don't be a dick is a pretty good strategy. However, I didn't get the impression that was his intent though: "I laughed along with her joke until, with a shock, we both realized that I was actually laughing at her actual plan".
Right. I was neither being "frank" nor intentionally laughing at her plan. She was smiling, and I thought she was kidding. I was smiling, and she apparently thought I was approving. Suddenly, we both realized we were wrong. Oops.
At that point, the damage was done. I tried to explain why her approach of changing N things simultaneously wasn't more efficient than changing N things sequentially because of the combinatorial explosion of interactions, but she wasn't technical enough to understand what I meant by that, which made her angrier, and when I suggested an approach that would give us a temporary "Plan B" just in case we "ended up a couple of weeks late", she declared me "unsupportive" and ended the meeting.
It was a failure of communication. Even before analyzing why or what happened, a failure of communication is something that arises out of actions of both parties and even the prevailing culture of the team.
Nobody really likes it, but half of the "politicality" of management has to be set in place to allow people to communicate with others who may or may not suffer from a sensitive ego and the company hasn't had time to figure it out yet. On top of that, it's usually a judgement call and may be a poor idea to formalize into your process an escape hatch based on judgement.
So maybe the original mistake was from the manager who presented a sensitive idea without enough seriousness to induce a careful response. Or the op who was too quick to feel comfortable interpreting it as a joke in what turned out to be a serious meeting. Or the culture which enabled the terms of the meeting to be ambiguous to begin with.
Only after that can you get into things like speculation on the maturity of the manager. It's actually quite a high maturity bar to jump over to stomach being laughed at by an expert. Not saying you can't set that as a goal, but merely that you ought to think about what happens when you find yourself dealing with someone who hasn't met that expectation.
I try to always write minutes from meetings. Sometimes I also send them out. Other times I just store them somewhere that has 3rd party timestamps (dropbox or googledocs).
My reading is that he wasn't laughing at her plan intentionally. Her plan was so bad that he thought she was joking, and he tried to be polite by laughing at the VP's joke.
There's nothing wrong with him. As I wrote above, as the brain ages, you get more experience and depth and foresight. The problem is that the decisions that use these abilities don't belong to programmers - they belong to managers (in this case the VP).
This is one of the main recipes for perennial frustration - be an older programmer trying to act like a manager from the bottom of the hierarchy.
The interesting thing about engineers is that they have very little tolerance for these destructive social shenanigans. Courtesy and politeness are one thing, but ignoring such a flagrantly flawed plan goes beyond courtesy and into professional negligence.
When empirical thought is your bread and butter, as it is in the case of software developers, it's hard to see why you should have to acquiesce to the VP's ego. If one intentionally stays off the political tracks, there really is no reason they should have to play unreasonable political games. Workplaces would be much more efficient if we accepted, or at least heard, the advice of the people who get paid for their expertise, instead of cowering in fear that we may damage the ego of some fragile soul who ended up in management because they were not competent to do any real work directly.
YMMV, but what one perceives as 'unreasonable political games' is highly personality-dependent. Most people have some set of behaviors that they find appropriate in some situations but not in others. For instance, wearing sweatpants to a wedding is generally frowned upon, for reasons that have little to do with their ability to maintain the body at a reasonable operating temperature. You can wear them anyway, but then you get to face the social consequences of doing so.
It's true that workplaces would be a lot more efficient under the regime you describe. It's also true that if my aunt had a dick she'd be my uncle. I'm suggesting that it might be a good idea for engineers to do the same thing as everybody else in the world and try to figure out when to wear sweatpants.
This is not anywhere near as socially tone-deaf as "wearing sweatpants to a wedding" -- it's more like showing up in a tux when everyone else caught the note on the invite "ironic dress only, please wear trash". The situation the parent described was the presentation of a plan of complete absurdity, which he advised against after realizing it was serious.
I agree with you that developers would be well-served by making a stronger effort to play along with the superficial niceties of corporate politics, but like I said, this transcends that and gets into a professional duty to advise against. If the workplace is so corrupt that reasonable opposition to a blatantly silly implementation plan can only result in the correct subordinate getting shuffled around and possibly fired, it's a liability for professionals to continue employment there.
I am now convinced that an idiot in a management position is unable to raise himself above the level of idiocy he is in - by any means. By definition, he should have to _listen_ and _weigh_ the facts being reported to him, not only to filter out the hidden agendas, but to also see all the facets of reality. Doing this would automatically exclude him from the idiots group.
Unfortunately most of management ones will not tolerate unaligned lower ranks and are unable to utter the words "he may have a point" to themselves and regroup and refocus.
Instead they will do whatever is necessary to remove the opposition.
See the Challenger for recent high profile examples.
You made my day. I meant "for" but indeed time is relative. I was 11 at the time and Challenger event is "recent" to me even now. Maybe because I was into stars and rockets and a friend showed me a newspaper cut with Challenger launch a year before or so.
as you allude to in your final paragraph, the unfortunate reality is that unless you're specifically assigned the task (in this case, the VP was), it's not your role to dictate the plan or criticize it to the level you did. at most, you can make your observations known once. this sort of thing very rarely ends in termination or quitting, but usually a sort of political/social alienation which you describe.
in reality, your only two options are either quit, or be the VP. as a non-executive/manager, you don't run the show, end of story.
HAHA, what? yes they are. what you're saying is that the at successful companies, individual contributors never get upset at the direction/architecture/decisions the executives and project managers choose - okay buddy.
You should quit working for her.
Either transfer to another department or if it is not possible - transfer to another company.
There is almost no upside working anywhere near her. She would screw up every meaningful project and attach failure to professional reputations of everyone involved.
What was the approach she was trying to use to deal with a "hard deadline"?
I can't give away too much here, but we had bought some companies and had to change our Web stack to show that we ate our own newly acquired dog food. That part was unavoidable.
I just assumed we would make a gradual transition, replacing the two stack layers one at a time, and starting each of those replacements with new, non-strategic web apps (ex: a mailing list signup sheet for some small event), always getting things working before extending the rollout. We would get as many things working as possible by the "hard deadline", and our customers for these new products (who would be developers themselves and would know that these were new products for us) would understand that a gradual replacement of our old technologies was just good engineering, not a sign that our new products weren't good.
But she told me with a smile that we were going to replace all of our Web apps simultaneously with a matched set of replacements showcasing what could be done with our new products (one of which would require using a version so new it wasn't even feature frozen much less production-ready, to show off our coming features) and, as long as we were changing two critical layers of the stack simultaneously, we would change all the other layers, too, right down to the OS and hardware "and just do it right".
And I assumed I was just laughing with her--yeah, yeah, very funny--until we both suddenly realized what was actually happening.
(And, I don't work for her. I was transferred elsewhere, and she was eventually laid off.)
Did you grow the site into 8 figures or brought on board? What was the site doing? I would imagine management would be terrified of reliance on one, bus-getting-hit-by developer.
You'd be surprised how cheap or short sighted managers can sometimes be. I guess from their point of view they might see a developer as overly expensive and dogmatic.
I've seen companies with 7-8 figures and reliant on just 3-4 devs with unique and non overlapping abilities. It's more common than you think!
I developed the site entirely. To be clear: The site is essentially the interface to the business. I won't say I developed it "myself," since I was in a team with non-technical people who knew what functions they wanted from the site. However I was the only technical person involved.
Now we have more developers, for which I am very thankful. Unfortunately, way too much knowledge is locked up in me, and I never have time to commit that knowledge to bits, paper, or oral history.
Believe me, buses and beer trucks have been discussed as possible ends to my consulting gig. It is my fondest hope that this business has key-man insurance on me. I'd be pleased to know that they have such insurance, but less interested in knowing how much the policy is for!
Having worked with Ruby on Rails in the past and with Play2 and Scala currently, I think I can answer that.
For your regular web app, both frameworks are mostly the same, both are boring - Rails is more productive for very common tasks, but Play2 is safer because of the underlying language (well, if you pick Scala, otherwise Java just stays in your way). Things get more interesting in Play2 when scalability or latency starts to matter.
That's when you discover that Play2's architecture is entirely asynchronous and that Play2 supports asynchronous responses and web sockets natively. It does so by means of futures [1], actors [2] and iteratees [3] (also being migrated to reactive streams [4]).
Of course, the easy route with Play2 would be with Java, however I recommend that you pick up Scala. By doing so you're going to get exposed to concepts from functional programming in a language sitting on a platform that's very much practical for real world use. There's also this book on functional programming in Scala that's amongst the best books written on the subject [5]. Functional programming changes the way you think and it's all about sanity, functional code being easier to test, being easier to parallelize and being much less prone to accidental bugs.
But while you're at it also consider learning Haskell, probably the best functional programming language available, because even if you're not using it, it's currently the lingua franca for FP concepts, so when reading papers and blog articles on interesting design patterns related to FP, most of them are described in Haskell. It also spoils you with its incredible type system, so a language like Scala will become the minimum that you'll tolerate, working in Java, C#, Python or Go becoming unbearable ;-) A really good beginners course is this one from edX [6]. And then go learn Clojure, because it's a really practical LISP that is also oriented towards FP, except that FP in a LISP is really different from FP in static languages like Haskell or Scala.
And you know, the best thing about this path is that you're not going to learn just a framework, or yet another language, but you're going to learn about functional programming, which is a concept that transcends programming languages with its related mentality and design patterns and is useful no matter what you're doing and in what language.
But then going back to Scala and Play2, well that's useful right now too. And did you know that Scala compiles to Javascript too and it's awesome?
In all honesty, I'd recommend the use of Erlang alongside a framework like Chicago Boss, N2O or Nitrogen over Play if you want the actor model concurrency, default asynchronicity and WebSocket support. It simply supports these ideas in a way that Scala cannot compete with, alongside its concurrent error handling, the OTP framework, location transparent distributed nodes out of the box, binary pattern matching and so forth. Issues of typing aside (success typing is still impressive), it is a much cleaner and more FP-focused language than Scala's chimera paradigm.
The actor model for concurrency is rather poor depending on use-case. I prefer to mix and match approaches. I mean, modeling concurrent state machines, with bi-directional asynchronous communication that makes you easily lose sight of how data moves in your architecture, what could possibly go wrong?
And yes, it's a pretty good model for concurrency, however I consider it to be a compromise on the way to finding better approaches. And in the meantime, it just feels wrong to use a language that forces this mentality on you, unless you have specific use-cases for which this model fits perfectly that is.
And also, on the FP side - many people say that Scala is less FP than other languages, like Erlang. That's a rather odd assertion, because my experience has been the opposite. But that's for another discussion.
Write a trivial app in both. Use your own judgment to determine the best tool for the job. It is entirely possible that the best tool will be neither of these!
The website in question is written in Ruby on Rails. Since v1.0 (and Ruby 1.8). And it is now on current Rails (and Ruby!). Rails is a moving target, to put it mildly.
If I had to render an opinion, I'd say I love Ruby. Rails I tolerate. Some parts of Rails are great; others are tedious. By its own admission, Rails is opinionated software. You may or may not share its opinions.
A novice doesn't know what tools he need. An expert has mastered the tools he has been given. A master starts thinking about the tools he COULD have :)
I absolutely agree. Over the years I've worked with many sharp guys that are 50+ and their experience always commands massive respect from me. People who dismiss the more experienced segment of the workforce are, to me, absolutely, inexcusably incapable of critical thought. If all one sees the glitz of the young guys at TechCrunch Disrupt and concludes that they're the only talented devs out there, I want nothing to do with that person in a professional capacity, to put it plainly.
The main problem with hiring grey beards, as you put it, is that a lot of them aren't amazing, but due to years, they have an authorative attitude and expect to be paid more than your 20 something devs. If it's my money, I'd hire the 20 year old with gaping holes in their knowledge who are willing and eager to learn over the 40s something dev who thinks their way is better because they're 10 years my senior. I have a lot of anecdotal experience where I've rejected folks who were lacking a basic understanding of the pro's and con's of something. These guys aren't rejected because they don't understand the subject, but because they fail to accept there are scenarios where doing something the other way is better, or that at the very least, things at a bit give and take. This, I postulate, is generally because these guys have 10 years of 1 years experience, rather than the experience they're trying to sell themselves as having. These are the type of guys who will struggle when they're older. That said, when it comes down to it, most of the guys I try to hire are older than me. Age isn't a deciding factor, they just tend to be better.
Something that really frustrates me is people who are more expert than me but can't justify their pronouncements. I had a high school friend who I'm sure was smarter than me claim, "No one does object oriented programming the right way [except him]," but when pressed would just deliberately play games and mystify. Most DBAs I've worked with had their preferred way of doing things, but were incapable of answering Why? It's not easy working with these people. I've come to really value a colleague who can teach---that is, who can explain why they choose what they do.
I'd say anecdotally 2 out of 5 times I've encountered this it's been someone covering up for their own lack of understanding. These are the worst and the most inflexible. All but one DBA I've worked with was this way. It's the natural result of cargo-culting.
2 out of 5 times it's because the person doesn't have patience to explain all the background you'd need to understand, or they don't trust that you have sufficient background. Sysadmins do this all the time. If you're smart and already pretty familiar with their field, it's very frustrating. This isn't as bad as the former case, but it indicates personnel conflict and lack of trust. It's understandable though, e.g. answering technical questions for business people. I've gotten pretty skilled at giving non-jargony, intelligible, short, "popularizing" answers, that also invite further questions if desired. But it's not easy.
And 1 out of 5 it's because people with experience have forgotten the reasons. I've been there too. Just the other week on a Rails project someone wanted to use an ActiveRecord default_scope of "where deleted_at is null", and I had felt the pain of that on past projects, but it took a while to dredge up the details from my memory.
Most of the above reasons don't correlate with age/experience, but the last one does. Experienced people have so internalized certain lessons that they've forgotten the reasons behind them. You could say this is a bit like Michael Polanyi's "tacit knowledge". In this case, hopefully they still have mental flexibility to recognize that nothing is 100%, and if you give them time to remember and communicate their reasons, you can have a reasoned discussion and make a good decision. But recognize that making people think in this way often "feels like work." You are asking them to exert themselves, so it's important to communicate in a way that isn't challenging their knowledge but asking them to share it more deeply.
That's actually a cracking point. I want to work with people who can defend their positions. The reasoning behind our decisions should be clear, if it isn't, you lose points against the guys who can do it. Luckily, age typically makes you better at this, which is what makes it really suspect when you get an older guy pulling an appeal to authority.
This is a great point. I try to get people to argue stuff on technical merits, and it's surprisingly hard to do. An example I work with now is the guy who bad mouths sql, non stop, and also promotes nosql non stop. He can't compare and contrast the two, even in general terms. Makes it impossible to have a discussion with him.
I try to be conginizant of where my biases are, and be able to support my assertions on technical grouds. When you do tht though, you often times see there are indeed many valid ways to do things.
"with gaping holes in their knowledge who are willing and eager to learn"
If you don't mind the 'learning' involving data loss, security breaches and competitive disadvantages... sure. Go for it.
I say this as someone who did learning 20+ years ago, and have lost data, had security issues, and had many of the issues that come with learning technology (and business). My employers and clients absorbed part of those learning costs. But make no mistake about it, we all paid a price for those mistakes. You also will pay something extra for hiring those who are "willing and eager to learn" - it's just the nature of the beast.
Thinking that price is the only factor, and that maybe someone will take "a bit longer" to get something done is naive.
"I've rejected folks who were lacking a basic understanding of the pro's and con's of something...This, I postulate, is generally because these guys have 10 years of 1 years experience".
Did you bother to be honest with them about why you "rejected" these folks?
I'm one of those "40 somethings" who don't always think "my way" is better, but I can generally tell you why "your way" is crap, what it'll cost in the short and long term, and what the less crappy options are. I don't generally have a single "my way" because rarely does one approach fit even most problems well.
Hi there, you seem a tad upset. You should probably note my last sentence where I point out most of the better folks who I want to work with are older. My point was that simply being older doesn't make someone better, and that I'd rather train a junior than deal with a stubborn incompetent senior team mate. Unless you think the latter applies to you, you probably shouldn't be upset, I'm not generlising, I'm pointing out that if you're good, you don't need to worry.
That said, the assumption that you know better than me because you're 10 years older is part of the folly of what I'm pointing out. Indeed, you may know more than I do in my area of expertise, however you should base that on fact and merit. You should not assume that's the case just because you're older than me. If you tried that in an interview with me, indeed, it wouldn't last long and as a blunt Scottish guy, you'd certainly know why.
"and that I'd rather train a junior than deal with a stubborn incompetent senior team mate"
I was pointing out that the 'junior' often has more hidden costs than people realize. If you really are training someone - that's great, but I see far too little of that, and often just a hiring of the younger person either because they're perceived as cheaper, or a fear that the older person won't be a 'team player' (sometimes meaning "won't rollover and do whatever we say, work overtime, etc").
I'm not upset at you.
"I'm pointing out that if you're good, you don't need to worry."
Hrm... you still need to worry some, because you still need the other parties to be able to recognize that you're good (and to do that you need to be able to identify folks who are savvy enough to do that, ad infinitum). I've seen a lot of good folks get passed over for flashier/trendier folks who end up wasting lots of time/money.
The one other thing that comes with age more is a different perspective on time - it goes much faster than it did before, and watching people squander resources is... sometimes difficult.
It's actually not a case of fearing there are people who are difficult to deal with,
I have absolutly no doubt you've experienced people who are stuck in their ways have as many hidden costs as the junior.
I've taken over from older devs who don't use version control, nor a dev environment, refuse to use frameworks or follow coding standards.
Should we honestly believe they don't have hidden costs? Would you really rather deal with them than train a kid?
Either way, I'm only trying to counter the "old is good". I fully accept there are amazing older IT workers, just not that older is always better.
I presume a troll? At 25 I graduated as MSc (physics), had not worked a day in the industry, and began my PhD studies. At 26 I figured computer graphics where much more fun than running quantum physical simulations in a lonely cellar and began my software engineering career. At which point I was still pretty clueless of the complexities of software engineering in the industry.
The time limit is not age but how much experience one has doing software engineering projects. One needs several unders ones belt, preferably some that have actually shipped so that one sees what the end user implications of the said products are. How long this will take? A couple of years? Hard to say.
>I presume a troll? At 25 I graduated as MSc (physics), had not worked a day in the industry, and began my PhD studies. At 26 I figured computer graphics where much more fun than running quantum physical simulations in a lonely cellar and began my software engineering career. At which point I was still pretty clueless of the complexities of software engineering in the industry.
How did it work out for you? I am curious as I am thinking of shifting from fin. applied math (econometrics) to SE ...
For me it worked pretty fine careerwise (I'm now 35 to be precise). I'm working now in the technology development department of a multi-discipline CAD vendor, everyone else is really talented and I mostly enjoy my tasks. I even get to write simple linear algebra like a QR decomposition now an then. The job is stable, mentally stimulating and my co-workers are sensible human beings - who are mostly way past their 30s and some over 50s.
I turned to software engineering because computer graphics gave and give me such a huge kick. I don't know what intrinsically motivates you so I cannot comment whether I would suggest the career for you or not. Here's the rub: software engineering can be viewed in some circles as blue-collar work, which means the work environments can vary quite a lot. Also, the discipline is really young, and it shows in the amount of cargo cult and bullshit quotes one finds peddled as "best practices". There can be gigs where co-workers are experts and those can be great, however, there can be lot of environments where co-workers are perpetual expert beginners and those can suck big-time (or so I've heard).
Realistically, software engineering is still a pretty solid career choice so from a sustenance point of view I'm sure there are far worse options one can choose.
If you graduate at 21 and start working immediately, by the time you're 25 you'll have 4 years of experience with a few shipped mid-size projects under your belt. It's not that uncommon.
> Go solo. At 40 you should be experienced enough to handle up to mid-sized projects, alone and on a reasonable time-frame. Try to pick projects that your clients will actually use,
As someone who has been 'solo' for a very long time, I have to heavily disagree with this opinion. Going solo isn't as simple or easy as what the OP seems to be implying. Going solo means you are essentially working two jobs at once as it takes a tremendous amount of work and dedication to network, find good projects and keep them rolling in to pay your bills. To further exacerbate things, each year the amount of competition that you face ramps up drastically as more and more workers enter the consulting world who are unable to price themselves correctly and are willing to work for less and less.
Furthermore, by going solo, you are now assuming 100% of the risk as to whether or not your new consulting business sinks or swims. Chances are, just like any start up, you will sink. Additionally, you will have added burdens such as insurance requirements, self-employment taxes, various state/county-level taxes (such as gross receipts taxes) and a laundry list of day-to-day operations that you will need to perform that aren't related to software development.
Going solo really isn't for most people and I wish we'd all stop perpetuating this myth that it is somehow easily attainable. Remember, a solo consulting business is the easiest business you can start, maintaining one is the most difficult business you can run.
i'd suggest that intelligent employers realize that the language and stack are only a very small part of building a product. The more interesting problems are hard not due to language, but due to algorithms, data structuring, design patters and general architecting et al.
The 10yr C++ programmer ought to have those things nailed, the junior may not know they even exist.
Right. The issue here is that there's a difference between a software engineer and a programmer. A programmer is measured by years of experiences with particular technologies. Programmers are unfortunately replaceable commodities as a result. Software engineers are measured by their ability to work within constraints to use ANY tools available to them to solve the problem on time and in such a way that it'll scale to load.
If you're in a workplace full of programmers, consider moving onto to a firm that hires software engineers. You may have to move out of state unfortunately since the culture doesn't exist everywhere.
that's a good suggestion. it will fall on deaf ears because employers don't read anything on the Internet and they hate engineers, especially old ones. they can't get basic things like don't sexually harass employees right, so how are they going to get age discrimination right.
> problems are hard not due to language, but due to algorithms, data structuring, design patters and general architecting et al.
This is where I think we do get some legitimacy to this discrimination though. Most places you go, people are implementing functionality that is not terribly unlike that which has been done for the last 20 years (I'm talking the generic business "enterprise" shop). However, there seems to be about a ~~20% turnover in tools, styles, patterns, etc every year, and in my opinion at least on some platforms, the implementation style is tending towards the most complicated possible over-architected solutions possible.
When you're young and single, you have all the time in the world to keep up to date on all this, but once you're married, not so much. So, while I could easily out-implement the more "current" people, I'm not up tp speed on everything in their toolbox, so I lose.
As you say, "intelligent employers" should realize this, but how are they to know the technology flavor or style du jour is a waste of time, when the industry itself can't figure it out? ("everything XML" as just one example)
In most software jobs, it's impossible to directly quantify value-added. So the engineer's salary is 100% determined by your employer's (or by proxy, manager's) opinion of how much value you add.
And those opinions are quite locally specific. In my current place, we value age and experience perhaps more than many other shops in SV. So you're right, I think it doesn't "generalize", it depends on one's work culture.
I'm not a fan of this plan B stuff when you're 40.
Where is the plan B for doctors? Where is the plan B for Lawyers? Why do these other professionals have respect in the their old age and not us software engineers/programmers?
How depressing.
> The half-life of an engineer, software or hardware, is only a few years.
And I still don't get this. Move out of software and you'll find loads of over 40's and over 50's engineers. Here in Perth I know loads of older engineers, that are given dignity and respect along with their peers in Medicine and Law.
This plan B stuff is because of the culture that surrounds programmers. If there is any plan B, it is to maybe start admitting that older programmers might actually be useful and worthwhile for employment, much like every other white collar profession.
It's true that a 40 year old might not be able to work as many hours as a 20 year old, but that doesn't mean each hour is worth the same. At 40, you'd hope that the older programmers hours put in are more considered with all their experience and are most certainly worth it.
The same goes for older Lawyers and older doctors, they might not be as energetic as 20 year olds, but with all that experience to make that much more of an informed decision, it certainly means the older generation can compete.
This is a culture issue.
> Software engineering reliably undergoes a major technology shift at least every 10 years.
I doubt any shift invalidates real fundamental knowledge.
Sure if your entire career has only been a couple of languages with very little algorithm theory, then true, but that's because you never studied the subject, on your own or formally, that isn't because you're 40.
For example, Doctors and Lawyers have to have the fundamentals down, it's very important. I guess it's true that not enough programmers have the fundamentals down and that is an issue.
But if you're 40 and have training in the fundamentals such as algorithms and design before even hitting the code, you should easily be able to adapt.
> The more irrelevant experience a candidate has, the more lopsided the utility/value equation becomes
Again this is a HR issue. A software engineer/programmer that starts their work from the design and algorithm level should be able to pick up a new language in a couple of weeks. This issue is mainly with the way we hire programmers not with the programmers themselves.
It's like the job ad for 10 years experience in Node.js when Node.js was 3 years old. Just because HR are clueless doesn't mean we need to all start changing our careers.
If you want my advice, it's learn that knowing people is as important (or more!) than what you know.
If you build up your career around being an expert and networking, you will be in a better position than the expert who knows no one.
I completely agree and the sad truth is that we software people do it to ourselves by devaluing the contributions of older/more experienced people.
OTOH if we move toward a more professional / credentialed / high-status profession that won't be all roses, what with exams, high barriers to entry, slow/uniform career progression, etc. I don't like not having a plan after 40 but I do enjoy how meritocratic the industry is, and how it really does reward hard work more than just, say, years worked.
>Where is the plan B for doctors? Where is the plan B for Lawyers? Why do these other professionals have respect in the their old age and not us software engineers/programmers?
They have unions.
Doctors and lawyers also have strong protections from foreign competition. It simply doesn't matter if you are the best doctor or lawyer if you trained outside of the United States. You won't be allowed to practise until you qualify in the US.
Or plan C. For younger engineers start thinking about financial independence. Software Engineers enjoy a high starting salary and an even higher mid career salary so it is entirely possible to achieve financial independence in your 30s-40s with a frugal lifestyle and smart investing.
Ya it is hard to say. From his POV - he is already "retired", so he has tons of time available and if doing things himself limits his expenses - win win.
For someone who is busy working.. it depends. If you get a salary to work 40h a week... does hiring a poolboy for $20 an hour instead of cleaning your own pool for a self-declared time worth of $50 an hour make sense? I am not sure. If you are consulting and your choices are bill 45h and have a poolboy, or bill 40h and have your own poolboy... then the logic is much more in favor of outsourcing your tasks.
The other trick is how much do some things really cost? I know to pay someone to put brakes on my car, I would pay the equivalent of $100-$200 an hour. For $100-$200 an hour, I will gladly crawl under my car and get dirty!
I think it depends a lot on the industry, a young SF based Rails / Django / based startup? I hardly see them hiring a 40 years old with kids that will ask for a salary higher than the CEO. A front end UI developer with knowledge of the latest Ember / Anguler / React / whatever they come up with next front-end tech? Perhaps they are more likely to find a fresh graduate (or just a self taught hacker who just rocks at HTML CSS and JavaScript) that is in their early 20's
But in big companies (Amazon, Google, Twitter) in enterprise software companies, banks, medical tech, finance, I think it's not that uncommon to find 40 year old developers. Most of the developers in my company average at way above 30. And we have a couple of engineers above 50. All of them are pretty kick ass Java developers and they all get tons of unsolicited recruiter spam.
(Maybe I'm delusional or in denial, or perhaps this is just the difference between industries, but I think that if you WANT to still do it while you are 40, and you keep yourself sharp, just like doctors have to keep up every year with the latest developments in medical research to stay relevant, then I think you can do it till you retire)
I think the reason many drop out of coding is that it is very time consuming to keep up, and some may want sometimes a less mentally demanding daily routine. Managing a team of engineers can be tough, but it's somewhat less mentally and intellectually strenuous and energy hungry as coding. Coding takes a lot of focus and sharpness, and sometimes it's simply hard grunt work, people sometimes get tired of it and want to move on to management (or being a "solution architect") or even product management.
I think the problem is that the 40 year olds chose on their own to do less coding at some point, and more management / IT / architecture. (e.g. the less good developers, those who don't pass the sort from 100 to 1 but still manage to land a job, eventually understand it's not for them and move on to other, not less important roles)
> But in big companies (Amazon, Google, Twitter) in enterprise software companies, banks, medical tech, finance, I think it's not that uncommon to find 40 year old developers.
I think there's a bit of survivor bias. More interesting are the stories of someone who's not at one of those large or old-school companies. There's a bunch of skills (MFC, Flash, microcontrollers) that used to define 95% of someone's job, and are no longer relevant.
"I hardly see them hiring a 40 years old with kids that will ask for a salary higher than the CEO."
This preconceived notion that a manager or CEO must earn more than their employees doesn't make much sense. It's just a status game. If that developer (regardless of their age) has skills and experience that the company needs, and those skills are harder to find in the job market than management skills, it makes sense to pay them a higher salary.
Nobody questions the fact that baseball players and movie stars and investment bankers are paid several times more than the president of the U.S., so why shouldn't developers who are in high demand be able to make more than a CEO?
I only became a semi-fulltime developer after 40, but I have the advantage of working for myself and 20 years of non- software domain experience. I think the key to developer longevity is having other skills so that once your percieved value as a developer declines you have other skills to fall back on.
Don't specialize in things that depreciate as rapidly as programming languages! C++ experience is quickly getting less relevant over time, but stochastic calculus, digital signal processing, machine learning, and distributed systems aren't. Some of those specialties get more valuable; in fact, sometimes, the forces that make things like C++ less valuable actually clear the way for things like distributed systems to become more valuable.
I was allowed to offer only a single bit of career advice, that'd be what I'd say: don't specialize in programming languages. They're a trap!
(But then, I'm not quite 40 yet, so I could be wrong).
Ok, lets see. The languages that I have seen come and go as intense fads:
* Easel
* Telon
* Powerbuilder
* Codfusion
* CICS (was actually taught in a "CS" course not too far from here)
* PL/I (may be not totally dead, sadly)
* IITRAN (maybe not that intense)
To Tom's point, I know of a project involving 300 Telon programmers who had to be let go when a massive project failed. Few who invested in the above technologies are working in them today.
More importantly than the article says, develop skill in solving business problems using your programming skills.
I was maintaining a custom piece of PL/I software until 2010 when I changed jobs, as far as I know the place is still using it. I suppose I have potential value as one of the few people (barely) under the age of 40 that have experience in it.
None of these are programming languages in the sense people normally use the term (with the exception of PL/1). They are propriety frameworks and tools. Even PL/1 was an IBM developed language.
Proprietary frameworks, products, and tools are definitely a terrible thing to base your career on. Languages such as C, C++, Java, Ruby, etc. are a good investment.
When you're young, it can be beneficial to specialize in the "here today, gone tomorrow" technologies, because it negates the advantage of all the greybeards and lets you get exposed to levels of responsibility you wouldn't have a prayer of reaching for 10 years otherwise.
I got my first tech job (at 15!) because I'd taught myself Java, which was then brand-new, and a number of local companies needed experience with that and this weird new technology called the WWW. Parlayed that into a bunch of web experience, often as sole developer or team lead. Parlayed that into a job at Google, where I got to learn information retrieval, machine learning, distributed systems, the stuff that actually has a shelf life.
Someone could certainly end up at the same place (skill-wise) by getting a Ph.D and then a job at Google. The thing is, if you take that path, you're also forgoing work experience, income, perspective on how the industry operates, and the opportunity to jump off into different careers if you find you like them better. My first job out of college was writing software for hedge funds, for example; it turns out I hated the financial industry, but if I hadn't, it wouldn't have been too big a leap to get a job at a hedge fund after that.
The trick is to not kid yourself into thinking that the twelfth Javascript framework you learn is still valuable. The first gives you opportunities, the second and third give you perspective. But after that, have a plan B for things you should be learning that you can't get on the web. All that Java Swing stuff I did around 2000? Basically useless. Ditto the PHP in college, and even my Django & Javascript skills are nearing the end of their shelf life. It's the stuff I've done besides that, the stuff I generally don't talk about on Hacker News, that makes me valuable
The PhD route is different from the work route, it's not any better or worse. The PhD route allows you to pursue original research, hone written and oral communication skills, and in general allows for very different life experiences. Also, the work you can get with a PhD "can" be quite different than without (e.g. from a pool of ever shrinking research jobs).
>Don't specialize in things that depreciate as rapidly as programming languages
C has been around since 1972 and is just as relevant as ever even as the popularity of C++ wanes. Python has been around since 1991 and is growing in popularity.
There is a trick to figuring out which technologies will stick around for the long haul, and it is one which most developers don't even think to try and hone.
My career advice would not be to not specialize in programming languages but to learn to distinguish programming trends from programming fashions and invest (with training/picking the right job, etc.) accordingly.
I doubt there is going to be much call for people with experience in Mongo in 5-7 years' time, for instance, but Postgres? Hell yeah. I predict increased demand for F#, too, but not so much for, say, Java (even though it won't go away).
I am a C programmer. C is my first language. I have shipped C code. I'm pretty sure I've literally shipped C code, in shrink-wrapped boxes. I took my kids to the museum today and hung out in the cafe pushing commits while they wandered around. What was I hacking on? A C compiler.
C is less relevant now than it was in 1996. A lot less relevant. Way, way, way less relevant. In 1996, most serious software was written in C. Today, only a tiny fraction of it is.
While true, in 1996 almost everybody knew C or C++. Now, you can get a CSc degree without learning a manual memory management language. While C and C++ are a shrinking segment of the entire market, the market is growing.
I don't get it when people say Java will be less popular. Today it is in most cases, my platform of choice. Modern Java is a damn fun development environment. You just need the right tools like Maven, IntelliJ Idea, Spring Loaded and so on.
I have written a lot of Java the last 2-3 years, with Maven, IntelliJ, and Dropwizard. This after years of C++, Prolog, and Haskell. Fun is not exactly the predicate I would attach to modern Java.
Of course, this is all subjective. But I can barely imagine that people coming from more expressive statically typed languages would like Java very much.
(That's not to say that the tooling for Java isn't extremely good.)
Yes, abstracting knowledge to the point of not being able to use or think in basic primitives is often counterproductive.
I can't think of a great example. It can apply to anything. Though your larger point stands, C++ is a not so great example. Many languages are roller coasters or extremely specialized. In contrast, C++ is on another upswing with C++11/14/17. It's used practically everywhere, especially in graphics, systems, and game development. A point worth mentioning is that good C and C++ developers are often capable of adapting to other languages and settings quickly. They're used to a lot of basic building blocks.
Worth noting that the style of C++ most common (in my experience) in game development is pretty far from what is considered "modern C++11 best practices", and the modern C++11 style tends to be frowned upon.
Thats not ubiquitous, but it indicates that despite the upswing, hitching yourself to that language is easier said than done.
C++ experience is quickly getting less relevant over time
I hear this often on HN and elsewhere, if I'd had to guess I'd also say it's true. But is there any proper evidence to support that? And in any case, it will probably still take decades before C++ will be gone. Maybe you could as well say: specialize in C++ now, in 20 years specialized companies will be begging on their knees for you to come work for them to keep their legacy C+++ stack working :]
don't specialize in programming languages.
Depending on the language you do need some level of specialization/mastering though else you might end up being writing very sub-optimal or even bad code in some languages. I'd say learning how to learn a programming language also pays off. Have you seen the amounts of SO questions for C from people who haven't reached a certain level yet? Their programs continuously crash or don't work as expected. Not necessarily because their intent is incorrect or they are bad programmers/engineers but more often because they lack proper understanding of C. Have you tried approaching Matlab the same way as any other language? Oops, there goes the performance. Working in Labview? It might look like it's easy (hey, all you gotta do is draw wires, right) but good luck building a medium sized application with it if you don't know at least some of the ins and outs. Now you might say 'if you encounter such problems you need to pick a better language' but that is just not how it works.
Agree and disagree. I think that learning the minutiae of a specific programming language might be an evolutionary dead end. I say "might be" because there are C++ engineers making $500k in HFT. Since we're both in the same city (Chicago) now, we both probably know some of them. C++ isn't dead yet, and it's not even close (but a mediocre C++ engineer is probably hosed).
What seems to happen as a technology fades out is that the number of jobs drops, while the pay in those jobs increases. There's a risk to it. If you continue to be qualified for those jobs in the depreciating technology, then you're solid. If you lose at the game of musical chairs, you can be screwed.
There's value in learning programming languages if you keep an eye out for the concepts that make them what they are, and if those concepts have a future, which is more likely. We may not need C++ in 25 years, but we are going to have low-level programming problems that require a C-like language (and fluency with assembly languages). Haskell itself may or may not be around in 25 years, but the problems it exists to solve and the value of static typing will still be relevant. Common Lisp is nearly dead, but Clojure is doing well. Languages die, but concepts hibernate at worst.
The people who will be screwed are the ones who specialized in minutiae of Java but forgot the computer science itself: the ones who got really good at JVM configuration and Spring and Hibernate but have completely forgotten how computers really work. The really good ones will always have jobs: there'll be Java work 50 years from now, just as there is Cobol work now and some of it pays very well, but the more average engineers who only learned The Java Way will be screwed: not good enough to get the dwindling (if well-paid) Java jobs and with too much atrophy of their general CS knowledge to handle whatever is next.
I don't think it's ever wise to specialize in only a programming language, even if it's a really good one like Haskell. I think it's important to have a lot of language-agnostic knowledge in one's skill profile in addition to knowing at least one language very well.
The C++ engineers making $500k in HFT are more due to the HFT part of their skills. As was said elsewhere, focus on solving business problems with engineering skills, not so much on the language.
Fair enough but my general sense of it is that extremely low-latency C++ is harder to learn than the finance part of the job. If that's wrong it's still what hiring managers believe.
I would like what you say to be true. However, I have three of the base skills you mention, but I can't get the time of day from most companies unless I did it in their language or platform of choice.
I think it is just a reality of the current state the industry is in. Everyone seems to want developers who are already trained and experienced in what they are using so they can "hit the ground running", at least for non-junior positions. I think that is the biggest impediment for more experienced developers.
Lets see every 20-30 year old we have brought in the past 3 years:
A) Is so arrogant they think they know it all. Then when they turn in the code it's barely passable and it become clear they are going to be difficult to work with.
B) Are overly emotional and they all take things way too seriously.
Now every 35+ person we have brought in for a project is:
A) Professional. Gets the job done and very well.
B) Sees the bigger picture and goes with the flow.
That's my personal experience but hey if I was management I would go with the 20 year old's all day long. As long as I did not know what they did or had to deal with them...Oh wait....
When I was a programmer in my 20s, I saw the same among my peers and tried to emulate an engineer in my 30s. I stayed mature, tried to focus on the big picture and was always open to advice from elders because I didn't know squat yet and was aware of it.
Just by doing that I excelled in many areas, and now as a n almost 40 year old developer I try to hire people who act like I did, and believe me they're out there.
When I was in my early 20s, did consulting stints while in grad school. One of my jobs, the senior engineer was a former Bell Labs white beard (literally) with his first 'program' hanging on his office wall :)
I remember most of my age group had enormous respect for the older engineers. But then, we didn't have Google and Wikipedia and entirely too facile access to information that lends the patina of 'knowledge' that is so easily obtained these days. So a lot of the aggressive posturing these days is really a symptom of the not knowing that you don't know that much yet ..
This is exactly why I enjoy reading HN.
As a 21 year old software developer, I do not understand how can someone be arrogant, just opening github makes me acknowledge what I still need to learn.
"B) Are overly emotional and they all take things way too seriously."
This can be a positive. My experience with 40+ year olds is that they tend to sacrifice user experience/security for what they know. "Our customers won't care if they have to use Internet Explorer with ActiveX as long as it gets the job done." My point is that an experienced programmer who is not up to date can be as detrimental an arrogant 20 year old. The 40+ year old programmer who stay up to date though... They are worth their weight in gold and I aspire to join them one day.
Edit: Background - Got really pissed off at a 40+ dev using active x to launch external programs and making it a requirement that our end users use IE with ActiveX enabled. Almost lost my job because management sided with the person who had more experience.
"My experience with 40+ year olds is that they tend to sacrifice user experience/security for what they know."
I'm sure there are some people who don't expand, though I am in my 40s and am constantly pressing for the best UX possible for customers. I've suffered enough with bad UX, I won't go along with inflicting that on anyone no matter how challenging it might be to fix. On the other hand I am (almost) always grateful for people pointing out bugs in things I write now, but used to be a lot more insecure about it. A hit to the pride is nothing compared to the pain of shipping something broken.
"A hit to the pride is nothing compared to the pain of shipping something broken."
Well said. This should be the golden rule of development. I feel that too often we (both young and old) don't ask questions because we fear the repercussions of appearing ignorant.
Depending on what industry you're in, it's quite possible that your users won't care if they have to use Internet Explorer with ActiveX. A number of older and slower-to-change industries still require IE6 on corporate computers; supporting anything other than that is counterproductive, because their employers' IT departments won't permit them to load other browsers anyway.
I can't know if you're in one of these industries, but one of the virtues of experience is knowing when something isn't important because you know facts about your particular niche that an outsider wouldn't.
That makes it far, far more likely that they're stuck on IE6. Last time I went to the doctor's office, I saw a lot of very old Windows machines. You may wish that the world was a certain way (and frankly, I do too), but that won't actually make the world a certain way.
If you want to win this technical battle, your best bet is to say "I'll implement it in ActiveX if you really believe it is necessary for the business. However, Microsoft ended support for WinXP and IE6 in 2014. They have been actively campaigning to get their customers off of it. There are A, B, and C startups out there with competitive offerings that work on the iPad. iPad market share among healthcare organizations has gone up from X to Y% in the last 3 years, while IE6 market share has declined from Z to W%. If we implement this software as an ActiveX control, we will lose out on $M in sales, with the worst-case scenario being that our userbase upgrades from IE6 and we find ourselves out of business with zero market. It's happening already, as you saw from the market share numbers I just shared with you."
Basically, put the fear of going out of business into your management chain, with the data to back it up. (And if you can't find that data - then your management is right, and you shouldn't bother upgrading.) That goes over a lot better than "I read you should never use IE6 for HIPAA data on the Internet."
True, but to be fair I did praise the 40+ year olds who stay up to date and know their stuff. Just slightly jaded due to the ageism at my current job and lack of fact checking by management.
Other 'sticks with what they know to a detriment' are devs that stick with SCMs such as svn or cvs or even rcs when things like git or mercurial are out there.
Younger devs who do have experience with this stuck in their ways behaviors and it can be frustrating and they try to side step it by not engaging the older devs.
Other 'sticks with what they know to a detriment' are devs that stick with SCMs such as svn or cvs or even rcs when things like git or mercurial are out there.
Don't mistake not buying the hype for sticking with something just because you know it. While there aren't a lot of reasons to favour RCS or CVS when Subversion exists, there are sensible reasons you might favour SVN over a DVCS for some projects.
It's been 10 years since git has been released, and in my personal case when this happened, there wasn't any good reason other than 'it's what I know'. The company started with SVN when git had been around for a while.
It's slowed down the company globally, prevents us from using various tools that don't have svn compatibility (like android's repo, gerrit or git's client side pre-commit hooks) and overall just been a relative pain the ass compared to git.
The very small edge cases that svn might be better at now did not apply to us. Notice I didn't say perforce, or google's custom solution in my example.
There are certainly good things about DVCSes like Git or Mercurial that you miss when using SVN.
On the other hand, every project I've ever worked on that has used Git still had some sort of centralised repository that was considered authoritative for controlled release purposes. The smart projects had a local server for this that everyone pushed to. The over-enthusiastic used GitHub, and in at least one case then found themselves unable to deploy when their systems were all up but GitHub was down.
Within that master repository, having a single linear history so you can identify exactly which code you've got in any given release with just a revision number is often helpful. In Git you simply don't have this, so you have to manually tag everything you might ever want to reproduce, which is basically everything on your master server, which requires extra hassle and clutters your log.
A separate but very practical issue is that SVN has worked fine on Windows for years. Git's support for Windows is getting better, but still far from ideal even today.
The sheer complexity of Git, up to and including data loss bugs because even Git's own scripts didn't track everything properly, is another recurring concern.
I've seen more than one very experienced developer, well aware of the pros and cons of different tools, argue for using SVN on a new project for these reasons alone.
Software is a tricky balance between practicality and ideals.
In this example, the older programmer may figure he can meet the real requirements faster and with less risk using technologies he's already familiar with. He might be right!
Unfortunately, there's also a good chance he's being lazy, or political, or etc.
Try to give it a really good objective look to see for yourself which one it is. If the latter, you can try to influence the developer in an ego-friendly way or consider leaving if it becomes unbearable. If your managers have no real technical experience themselves then they are useless in these situations.
Good chance it won't be the last time you have to deal with this sort of thing. (coming from an old-ish dev)
I think that there's a huge variation among developers regardless of age or experience. There are people who are 25 and believe they've seen it all, and there are 45 year olds who tell you they've seen it all. What they have in common is that they don't listen to your advise and refuse to learn new things.
What they have in common is that they don't listen to your advise and refuse to learn new things.
I was on a job interview a few days ago and was asked "What do you dislike the most about working with others on a team" and gave them your exact answer, thinking it sensible giving the state of software dev nowadays.
I could tell immediately that they didn't care for it one bit, and the interview ended a few minutes later. I don't really know what they wanted to hear, but that sure was not it.
I've seen some extremely capable young people, really, it was absolutely incredible how far ahead of their age group they were.
Once you seen enough people you realize the bell curve always seems to apply, the curve shifts right along the experience axis over time but it will always be there and there will always be outliers. Don't rule out the 20 year olds just because of their age either.
B) Are overly emotional and they all take things way too seriously.
I've noticed that some young devs have really, really hard time when we discover bugs in "their baby". This most likely relates to the underlying arrogance ("there cannot be anything wrong with my code").
I hope that all the future gigs I end up, I'm part of the effort to create professional environment where the younger devs can pick-up professionalism from the seniors.
But to be fair on myself and others, I was expecting something more intellectually challenging than what basically amounts to a job in 'abstract plumbing'.
Now I have come to terms with this reality life is much simpler.
Yes, web to mobile. Native mobile development is a hugely different beast from web programming, just as web development was a huge shift from desktop GUIs in 2000, desktop GUIs were a huge shift from DOS and other microcomputers in 1990, microcomputers were a huge shift from UNIX and VMS and other timesharing OSes in 1980, and timesharing OSes were a huge shift from batch-processing on IBM & other mainframes in 1970.
It's interesting that you say the transition has happened between web and mobile, because of a lot of people I know are getting up to speed in HTML 5, and are betting the next few phase of their careers on it. Maybe it's because South Africa is a few years behind the curve, but is there evidence that the share of web-based jobs is declining enough to be concerning, in the first world?
The interesting thing about waves of technology disruption is there is usually more than one wave in play at a time, and so a technology can both be disrupting and disrupted. The web was invented in 1989, popularized in 1995, and arguably the point where people realized "Hey, desktop apps are in trouble" was around 2004 when GMail and Google Maps came out. Even so, Dropbox was founded in 2007 as a desktop software company, and that hasn't stopped them from being worth a few billion.
Mobile apps were invented in the 1990s (Newton, Palm), popularized in 2008, and (at least in Silicon Valley) it's a big topic of debate whether the web is dead. In my old job - Google Search - I was still pretty secure as a web guru. In my new job - startup founder - I feel that I at least have to do my due diligence and evaluate the technology.
Whether it's a problem for your career depends on exactly what you want to be doing with your career. There are still people making a living off of COBOL and IBM mainframes. In general, consumer markets peak about 5 years after the technology is introduced to the general public (so microcomputer apps came into their own around 1980 with Visicalc, windowing apps around 1990 with MSWord and various office suites, webapps around 2000 with Google etc, mobile just starting to peak now with Uber/Instacart/etc.) If you're founding a startup you need to account for the time it takes to build your product, so in general you want to use technologies not more than 2 years old. If you're working at a company you don't want to use technologies until the companies that have adopted them have gotten big, so it's frequently 10 years or so after adoption.
I think a current bridge slowly being crossed is a move away from OO programming (along with GoF design patterns) towards functional languages.
GoF patterns provide structure (at the cost of complexity). FP patterns are simpler and succinct but aren't quite as cookie cutter and thus are less structured.
Probably the tick-tock of the pendulum swinging. As software became too unique to maintain, standard patterns were implemented. As standard patterns became overly complex, we swing back to more expressive constructs.
This uncertainty is one of the things that drives me towards getting a CS PhD and ultimately a research position rather than becoming a software engineer. Older researchers are very common in CS-related fields, both in industry and academia.
After reading stuff like this I never know what to think. I am 28 and just getting started. I hope to land my first developer position by the end of the year. So what am I to make of it? By the time I am competent enough I will be expendable? I am not discouraged but articles like these don't make sense to me. Almost everywhere I look and in every aspect of my life I am always "behind" and I don't feel like it but everybody is telling me I am...
A programmer will never ever ever ever be expendable, in fact, demand for programmers just grows everyday and we just started wiring the Internet on things. I am 40, I just had my first kid, I do not have a ton of karma in HN ;) You are never behind, just follow your own path...
Congrats on learning to become a developer. Always excited when people join the community. A few things:
1) that feeling of "being behind" never goes away. In fact, the more you learn, the wider the breadth of topics you will want to learn, so the feeling only grows. Software engineering is not a field which lends itself well to people who want to "learn the playbook so they can be confident they are doing it right". The main question is if you can spin "feeling behind" into a positive force, similar to what competitive athletes do.
2) if people are telling you that "you are behind" - ignore them and start hanging out with better people. There are more than enough talented people out there who want todo nothing more than help others while building up their confidence in the process.
I see no one else has mentioned another, even more obvious solution. Retire.
With the sky-high salaries it is possible to earn as a software engineer, it should be straightforward (not easy, but still straightforward nonetheless), to save enough to retire at the age of 40. After which, you can spend your remaining time as you see fit, working on personal projects or any other hobby that suits your fancy.
Or buy now and sell in 15 years or so. Move to Boise Idaho. 15 years of equity (ignoring appreciation) means you can buy a house twice the size outright.
Bay Area real estate has picked up, but timing 15 years to sell? Doesn't always work out as well as it could if things have cratered. There have been about three significant real estate collapses in the Bay Area in the last 20-30 years.
Some areas hold up better than others, but, say mountain view, a 20-something at his/her first/second job, unless has other means, isn't going to pick up property easily to hold for 15 years.
Affordable areas in a boom? Those most likely to take a serious crap in a downturn.
15 years isn't exact. Boom bust cycle is 5 years or so. If the market is down in 15 years, then just wait it out. I'm not even including appreciation in the calculations.
True, and not everyone will want to dig up and move to Idaho. Established roots, friends, etc. There is more to "home" than just the walls in which you sleep.
It's possible. I did it. I am 43 and I retired when I was 40. I lived frugally in Silicon Valley and saved and consistently invested more than half of my income.
It was a decision I made when I was 23. I remember doing a spreadsheet at that time to plan it all out. This was back before there were good references on how to plan it out. Some of my assumptions were a bit off, but I got there in the end.
Can you give more details on your story? I'm particularly interested in how much you needed to retire, and how you've set everything up to make yourself comfortable that you won't run out of money.
This subject has been researched in great detail. There's lots of great information all over the Internet. I recommend these two blogs if you want to learn more:
The TL;DR is this: you need to be able to live off about 3.5% of your portfolio for one year. That will allow you to avoid depleting your principal over a very long term, and also give yourself an inflation-adjusted raise every year so you maintain your spending power. Often people quote a “4%” rule, but I think it’s meant for people that retire at a more “normal” time in their lives. The extra 0.5% actually makes a big difference in the probability that your portfolio can fail.
So, if you have a million dollars, you need to live off $35K a year.
If you’re willing to really change your lifestyle, you can retire off $500K, which would give you $17K a year. It doesn’t sound like much in Silicon Valley, but that will put you in the top tier of income in a place like the Philippines.
I don’t want to post my own net worth because it might come across as chest-beating. I’ve been living in a few places that are a lot cheaper than the United States, so my expenses are low. Over the last three years I’ve been averaging living off slightly less than 2% of my net worth annually. So, I’m REALLY safe by the “3.5% rule”. My net worth is higher than when I retired.
I’m enjoying my life. Every day is a clean slate. There is nowhere that I have to be at two o’clock on a Tuesday afternoon. I can read or take a walk, go to the gym, or tinker with some computer language. I like this life. I sure hope I did all the math right, because if I have to back to a cubicle in Silicon Valley it’s going to be REALLY painful for me. No amount of free sushi by your employer is enough to compensate you for your lack of freedom.
Essentially, your income in retirement should not be dictated by your current income, but by your current level of expenses. If you can save a multiple of your current annual expenses, and that multiple is high enough to account for real-terms investment gains, you're financially independent: you don't need to work any more.
The number generally used is 25x, which corresponds to real-terms gains of 4% per year on your savings.
The S&P 500 is 50% above its 2008 peak on May 8, 2008.[1] That's a 5% annual compounded return ((210/140)^(1/7)). And that's using the 2008 peak: if I use the lowest price from 2008 (in December), your return would have been 8.8% annually. Inflation (at least in USD) has been benign during this period, so probably there has been a real 4% return during that period. I don't know how you concluded that you didn't get a 4% real return during this period.
If you look at the stock market over any short-term (<15 years) it will be quite volatile. Over very long periods it is more regular. If you're investing in the stock market, you must take a very long time horizon.
If you really want to understand this topic in more details and whether your portfolio is likely to fail over some period of time, I encourage you to play with FireCalc [2].
Yes but you must realize it can't work for everyone. Clearly you made some smart decisions that involved a lot of sacrifice to end up in this position, and I'm not denigrating that at all. But a) not everyone has the ability to make those sacrifices (child care, elder care, health emergencies, etc) and b) even following the same path as you did could lead to a different outcome. There is an element of luck that, again I'm not discounting your achievement, does factor into the outcome.
We need programming to be a real career. People shouldn't feel pushed out when they are in what in any other industry would be considered the prime of their career. This mentality is destructive not only for us but the economy as a whole.
Are there really people out there who actually believe that programmers are washed up by the time they hit 30?
I'm not kidding... do people really believe this? I always thought that was a fairy tale that employers tell to still-wet-behind-the-ears kids in order to pump up their egos so that they work untenable hours for meager pay
Yes, it has nothing to do with productivity but definitions. After 30 programmers see more options and its harder to keep them as cubicle/hipster drone.
Yes, it has nothing to do with productivity but definitions. After 30 programmers see more options and its harder to keep them as cubicle/hipster drone.
This article is wrong on the facts, but more dangerously offers wrong advice on life choices.
23 years ago, when I was 23 years old, I actually posted a Usenet question on this topic (archived somewhere?) asking where were all of the "old" programmers?
First off, people don't decpreciate, skill sets do. Of course someone making a high salary will be undesirable if their skills stay the same and become commoditized or less relevant. But the same would be true of a young person with the same salary/skills. Every time this happens the challenge becomes finding the next niche that is valuable, and that you like enough to devote lots of time to.
Secondly, a lot of older folks get siphoned off to management voluntarily. This can happen when a company doesn't have equal career ladders for tech and management. At good software companies you can advance as individual contributor up to a VP level, while other companies force a switch to management to continue progressing. And of course a few are natural leaders of people who want run a group, or try a cross functional gig. Some feel it's more prestigious to be director of whatever dept.
On age discrimination in tech, I hear about it anecdotaly, but haven't yet perceived it happening to me. Maybe it's just too early to notice, or maybe there will always be some people in tech who want to work with the best team possible regardless of age? Would I hire an 80 year old developer? They'd get the same questions as any 25 year old. Show me the code you've written over the last year. Shoe me how you communicate complex concepts in simple ways. Are you a dick to work with?
On being too expensive, the reality is there is an effective salary cap for everyone which is a function of company, role, skills, location, etc. You need to know what the cap is and realize if a company balks at going over it then it may have nothing to do with age. The calculus is what it is, older people are just more likely to hit the caps first.
Finally I must disagree with the comments I see about young people being less capable. Yes, experience is irreplaceable in certain contexts. However more often I notice the people doing really great work are a special minority of individuals that just have the right combination of smarts, drive, maturity, flexibility, luck, etc.
I'll try to remember to follow up on this post in another 23 years to discuss what has changed.
I don't know a single software dev over 40 who isn't employed, and I know many that age. None of them had to change fields. Some are managers, but most are "senior" devs. Many of these guys have been programming internet technologies since the later 90's.
It seems in the places I've lived (LA, DC) the salaries are pretty squashed together after 5 years experience. Basically anyone with that experience is getting a similar pay check +/- 15%. For many after 28 you are close to being maxed on your pay which would put you in the same spot this article plops the 40 year olds.
pay squash is why you should get out of field. engineering is the new proletariat, working at companies that rake in millions for pennies, while all managers above you get twice your pay just by organizing your time.
I don't see the managers above really making that much more. In fact I made less when I was team manager than half my team when I worked for a big public corp. The C level does make a lot more and/or the owners do but not all the management in between. With tech knowledge, though, you can escape the squash by starting your own business fairly easily. Not necessarily easy to create a successful business but easy to give it a shot.
Yes, I believe this is more a more accurate assessment. I bet at most large and medium-sized tech companies, there's not a huge difference in compensation among rank-and-file employees (both individual contributors AND managers), with some managers earning more and some individual contributors making more. Probably no more than a 2X difference between what a junior engineer makes and what a senior engineering manager makes.
However, there's going to be a HUGE gulf between what they make and what the senior executives make--anywhere between 3X and 300X. That's where you go to escape the "salary squash".
Engineering is certainly not a proletariat. Engineers make more money than most professions and have more interesting jobs as well as lots of respect from other professions (I am not an engineer and I can tell you lots of people admire engineers). Also, many professions experience "pay squash".
It's a myth that most managers make much more than programmers and that they "just" organize your time. Let's have a little bit of respect, not just for our own professions, but also for the people we work with.
>"It's a myth that most managers make much more than programmers and that they "just" organize your time."
Well, instead of just saying it's a myth and relying on averaged stats in the industry to satiate peoples' curiosity/jealousy, perhaps we should just all be more open about how much we all make. I.e. let's not make it taboo and "contractually-breaking" to discuss salaries openly.
I know, yes, our current employment culture won't easily handle the strain of all coworkers knowing each others' and their superiors' salaries. But I have noticed the trend reversing slowly.
I suspect that sharing salary info will result in a gradual downward grind in salaries, as people are offended by seeing someone make what seems like big money for easy work. This has been the case with public school teacher salaries.
I also think that salary data, with no corresponding ability data, will be meaningless.
not when compared to all other profession that require a degree, constant lerning and are higly specialized (each enginering branch is not interchangeable, as well as within the same branch specializing in one area reduces your employment prospects in others)
also, the majority of managers are not the one that are in charge, taking decisions, managing risks and settings directions; middle managers types are way more common. and I do respect those of them that work well, but they are so hard to find that I'll stand by the 'most' in 'just organize things'.
What professions would those be? Law and medicine are probably the two most people are thinking of.
Law does pay more for very successful people, but at the median it actually pays less.
Doctors do get paid more, but they also spend a much longer time in training. The amount of time that most engineers spend in training is more in line with the amount of time that PAs spend in training.
Let's not confuse engineering with programming. Most programmers aren't engineers (don't have engineering degrees, aren't comfortable with physics / calculus, etc.) Real engineers generally don't have these employment issues as they age.
Programmers are 'engineers' in the same way that those with an MCSE are 'engineers' -- they operate a computer and employ a unique and useful skill-set.
No true Scotsman. What's an engineer? I'd argue that people who studied software engineering for four or five years, then became software engineers, count as engineers. The fact that they don't have much insight into physics is wildly irrelevant.
In Canada, a programmer is certainly not an engineer. And for Canadians going for a TN visa to work in the US, programmers are not allowed. Usually they try to slip in as 'Systems analysts' or craft the job/acceptance letter to fit under an engineering discipline.
Software Engineers are engineers in Canada. A self taught programmer doing css/html is not an engineer.
I'd simply qualify someone as an engineer, iff they successfully graduated from recognized university from an accredited Engineering program. And a second possible scenario is if someone's managed to pass all the Professional Engineer's examinations independently (rare).
Not sure if one should favour 4 years in theory or 4 years in relevant work, for a programming position. For research, yes absolutely as it is straight carryover.
That's an employers decision, my post was not meant to comment on how well someone can program, given their qualifications. Best programmer I know does not have an engineering degree.
Not sure why I got down voted. A quick google search will reveal my comment is factual. At least in Canada where I'm from.
"meet PEO's stipulated academic requirements for licensure (hold an undergraduate engineering degree from a Canadian Engineering Accreditation board (CEAB)-accredited program, or possess equivalent qualifications), and, if required, successfully complete any technical exams."
Here in Canada, I cannot advertise myself as a professional engineer without an engineering license. I'm not saying that this is the way things should be done, mind you, but being an engineer is a legal distinction in some places.
A big problem was that most bright engineers were promoted into management, so the ones left programming at 40 weren't so bright. So not so much that age killed the skills, it's just a selection bias.
I think we've got better at that and bright engineers are just being promoted into senior engineers, so hopefully it's fixing the selection bias.
Interestingly nearly all the guys over 40 I know who are "senior" devs never wanted to go into management. They just said "no!". They are solid reliable devs. They are all doing fine. But then again so are all the guys who went into management. (Sorry, I write "guys" all the time 'cause I grew up in the midwest - not trying to make it all about males)
"most bright engineers were promoted into management so the ones left programming at 40 weren't so bright."
Just wow. Quite a bit of agism there. In my experience most CEOs are not technical, and thy want "business guys" in management. This ranges from big companies (my manager at Amazon had a criminal justice degree and could barely operate a computer, and his IQ was less than 100) to startups (often the CTO will be technical, but also a founder, so there's not a lot of opportunity to become "middle management" during the startup phase.
I'm approaching 50, am employed, though I've found that the job search is a bit harder now-- particularly with bay area startups I saw a %100 correlation: If the interview as on video (eg: they could see the white in my beard) I didn't get a second interview. If by phone (no video) I'd get offers.
Also, last year in Austin I made exactly %20 more than I did in Seattle in 2000. Kinda sad-- up %20 in 15 years-- that doesn't even cover the inflation over that time period. (and I was making more than everyone else there, including some senior people.)
I've decided I need to switch to management, as it's time. In fact it's past time, but I have found that too many companies-- particularly startups-- don't promote managers from engineers, they want "biz guys" who don't understand software to be the "managers" way too often. (at least outside of silly valley.)
Thought about that, but found a situation before trying it. I think I will do that next time... which is kinda sad, cause really, my experience makes me really valuable.
But in the end, would you really want to go work for a shop like that? If they don't want you based on the color of your beard, then I wonder what "other" surprises lurk around the corner..
I'm in my mid-thirties, so please take that into an account. Also I know that these are the questions that I have to ponder in the coming years, so your insights are highly valued.
there was a news once about a 40/50 y.o. guy ( I think he was from UK ) who couldn't get a job as a manager in US because he was semi-bald. So he shaved his head entirely and found a good position in a flash. I need to find the link , this was an interesting story.
Look is important,unfortunately, but it isn't always about age, sometimes you're too fat, or not white enough ...
I remember that story, it was on the front page of HN back in 2012. The guy shaved his head, did a fashion makeover, bought the latest iPhone or whatever, and then on top of that had eyelid surgery with the goal of making his appearance more youthful:
I just had dinner with two other devs tonight I randomly met at PyCon. Both of them do contract work, and have to turn away work. Neither of them ever specialized in any particular language; they both just focused on using code to solve problems.
There's always going to be a need for people who can walk in to a new situation, diagnose what's going well and what needs to be fixed, and carry that out.
I don't buy it. There are people of all ages on my team, and the same has been true at several other jobs I've had in the past few years. There is not even a particularly strong correlation between age and seniority.
My second observation is that in all the jobs I've had where this was not true, the company has not been particularly successful in the long run. It's unclear whether this is related, but it's interesting.
However, I can come up with an alternative statement that may be a better explanation of what some people seem to observe: if you are not a really good engineer by the time you turn 40, and you expect to be paid based on your "years of experience", get a plan B.
We work in a, relatively speaking, very young industry. It's very hard to draw conclusions by looking back at 20 years ago. Being in a young and highly-demanded industry pushes a lot of us into managerial positions earlier than normal. But essentially, I believe that a developer's age doesn't matter if he/she doesn't stop learning.
302 comments
[ 5.7 ms ] story [ 50.5 ms ] threadThese options allow you to continue programming after 40 and you should! It is an urban myth that past 35 programmers are not as good b/c they get tired faster or make more mistakes? The truth is that 20-somethings can put up with very long hours b/c they have the time (mainly due to not having a wife and kids) while 40-somethings have the experience to go right to the answer. That's productive vs efficient. I like to use a soccer analogy: a young defender is good when he's fast because he can outrun the attacker, while an old and slow defender is better because he knows where to stand and wait for the attacker. Experience is gold.
But I also know with experience comes a skeptical eye for being asked to carry extra load for less upside (yet same or more risk).
A story from some time back told to me. Founders had a UI, an algorithm, and an idea. It had merit. They sought someone out to build and run the actual service. The funding was angel, the role was senior to C-level, but the salary offered was 40-60k cut for a senior engineer at the usual suspects, equity capped at 4% assuming a trade off in salary.
Risk and reward to build out infrastructure and productize someone's idea? I could certainly get a couple of people to build it out in a "get us to a-round funding" in those guidelines, maybe even beyond. But as expectations on a non-founding senior/early member, one would assume way too much risk for the potential upside.
It isn't non-technical founder seeking technical co-founder waters, but damn close.
But being older doesn't mean you stop learning, adapting to change, or lose the ability to deal with moving targets. I'm hopping rapidly between roles and widely varied tasks at my current gig better than I would have in my 20s or 30s since I've got more perspective and experience.
A more mature person might point out that if your plans change weekly you likely have a systemic problem, though, and would be more likely to point out the breakage.
This stuff is a false economy anyhow since it inevitably leads to a massive ramp up in technical debt even with the very best programmers.
I am not suggesting that you don't have a problem if your plans change weekly, but unfortunately this is the way many businesses are run. When you have a very fluid workflow youth is very attractive.
i.e. you don't bother to spend an hour to plan a project. I don't think anyone wants to work at those kinds of places, young or old.
For those who use their minds, which should be common in this field, those effects become noticeable much later in life. For most of the working lifespan the dominant effect will be an increase in experience.
In general, if the plan is changing every week, that probably means that the work I did last week was mostly pointless. That's a great way to burn someone out.
Good news though! I do contract work, and if you insist on changing the plan every week, you won't need to worry about whether I'm flexible or inflexible. I'll happily fire a client who can't make up their mind and thinks that the best path is to change direction every week.
But flexibility is a hard-to-measure parameter to begin with and you need to know the people and their reasons before you can make call about it rather than simply their age.
On the flip side, I would love to throw out all of the languages and frameworks I've been using for the past few years and learn entirely new tech. That's part of the point of being in this business!
If you're a startup and have a bias against us greybeards, you're only hurting yourself. We'll learn your framework-du-jour and tell you how it bears an uncanny resemblance to something that didn't work so well in the past. Or maybe we've never seen anything like it, in which case we'll be delighted to cast aside all that old crap.
She gave the job to her three dozen "supportive" young programmers, who ended up taking 28 months (!!) to get the "4-month" project finally working.
So, after all that, did she eventually apologize and tell me that, yes, she'd made the same mistake I told her I'd seen before with the same results for the same reason, and that she should have at least asked me more about it instead of throwing me out? Of course not. This is the real world. She never spoke to me again and never forgave me.
At that point, the damage was done. I tried to explain why her approach of changing N things simultaneously wasn't more efficient than changing N things sequentially because of the combinatorial explosion of interactions, but she wasn't technical enough to understand what I meant by that, which made her angrier, and when I suggested an approach that would give us a temporary "Plan B" just in case we "ended up a couple of weeks late", she declared me "unsupportive" and ended the meeting.
Nobody really likes it, but half of the "politicality" of management has to be set in place to allow people to communicate with others who may or may not suffer from a sensitive ego and the company hasn't had time to figure it out yet. On top of that, it's usually a judgement call and may be a poor idea to formalize into your process an escape hatch based on judgement.
So maybe the original mistake was from the manager who presented a sensitive idea without enough seriousness to induce a careful response. Or the op who was too quick to feel comfortable interpreting it as a joke in what turned out to be a serious meeting. Or the culture which enabled the terms of the meeting to be ambiguous to begin with.
Only after that can you get into things like speculation on the maturity of the manager. It's actually quite a high maturity bar to jump over to stomach being laughed at by an expert. Not saying you can't set that as a goal, but merely that you ought to think about what happens when you find yourself dealing with someone who hasn't met that expectation.
There's nothing wrong with him. As I wrote above, as the brain ages, you get more experience and depth and foresight. The problem is that the decisions that use these abilities don't belong to programmers - they belong to managers (in this case the VP).
This is one of the main recipes for perennial frustration - be an older programmer trying to act like a manager from the bottom of the hierarchy.
When empirical thought is your bread and butter, as it is in the case of software developers, it's hard to see why you should have to acquiesce to the VP's ego. If one intentionally stays off the political tracks, there really is no reason they should have to play unreasonable political games. Workplaces would be much more efficient if we accepted, or at least heard, the advice of the people who get paid for their expertise, instead of cowering in fear that we may damage the ego of some fragile soul who ended up in management because they were not competent to do any real work directly.
It's true that workplaces would be a lot more efficient under the regime you describe. It's also true that if my aunt had a dick she'd be my uncle. I'm suggesting that it might be a good idea for engineers to do the same thing as everybody else in the world and try to figure out when to wear sweatpants.
I agree with you that developers would be well-served by making a stronger effort to play along with the superficial niceties of corporate politics, but like I said, this transcends that and gets into a professional duty to advise against. If the workplace is so corrupt that reasonable opposition to a blatantly silly implementation plan can only result in the correct subordinate getting shuffled around and possibly fired, it's a liability for professionals to continue employment there.
Unfortunately most of management ones will not tolerate unaligned lower ranks and are unable to utter the words "he may have a point" to themselves and regroup and refocus.
Instead they will do whatever is necessary to remove the opposition.
See the Challenger for recent high profile examples.
in reality, your only two options are either quit, or be the VP. as a non-executive/manager, you don't run the show, end of story.
There is almost no upside working anywhere near her. She would screw up every meaningful project and attach failure to professional reputations of everyone involved.
What was the approach she was trying to use to deal with a "hard deadline"?
I just assumed we would make a gradual transition, replacing the two stack layers one at a time, and starting each of those replacements with new, non-strategic web apps (ex: a mailing list signup sheet for some small event), always getting things working before extending the rollout. We would get as many things working as possible by the "hard deadline", and our customers for these new products (who would be developers themselves and would know that these were new products for us) would understand that a gradual replacement of our old technologies was just good engineering, not a sign that our new products weren't good.
But she told me with a smile that we were going to replace all of our Web apps simultaneously with a matched set of replacements showcasing what could be done with our new products (one of which would require using a version so new it wasn't even feature frozen much less production-ready, to show off our coming features) and, as long as we were changing two critical layers of the stack simultaneously, we would change all the other layers, too, right down to the OS and hardware "and just do it right".
And I assumed I was just laughing with her--yeah, yeah, very funny--until we both suddenly realized what was actually happening.
(And, I don't work for her. I was transferred elsewhere, and she was eventually laid off.)
I've seen companies with 7-8 figures and reliant on just 3-4 devs with unique and non overlapping abilities. It's more common than you think!
Now we have more developers, for which I am very thankful. Unfortunately, way too much knowledge is locked up in me, and I never have time to commit that knowledge to bits, paper, or oral history.
Believe me, buses and beer trucks have been discussed as possible ends to my consulting gig. It is my fondest hope that this business has key-man insurance on me. I'd be pleased to know that they have such insurance, but less interested in knowing how much the policy is for!
For your regular web app, both frameworks are mostly the same, both are boring - Rails is more productive for very common tasks, but Play2 is safer because of the underlying language (well, if you pick Scala, otherwise Java just stays in your way). Things get more interesting in Play2 when scalability or latency starts to matter.
That's when you discover that Play2's architecture is entirely asynchronous and that Play2 supports asynchronous responses and web sockets natively. It does so by means of futures [1], actors [2] and iteratees [3] (also being migrated to reactive streams [4]).
Of course, the easy route with Play2 would be with Java, however I recommend that you pick up Scala. By doing so you're going to get exposed to concepts from functional programming in a language sitting on a platform that's very much practical for real world use. There's also this book on functional programming in Scala that's amongst the best books written on the subject [5]. Functional programming changes the way you think and it's all about sanity, functional code being easier to test, being easier to parallelize and being much less prone to accidental bugs.
But while you're at it also consider learning Haskell, probably the best functional programming language available, because even if you're not using it, it's currently the lingua franca for FP concepts, so when reading papers and blog articles on interesting design patterns related to FP, most of them are described in Haskell. It also spoils you with its incredible type system, so a language like Scala will become the minimum that you'll tolerate, working in Java, C#, Python or Go becoming unbearable ;-) A really good beginners course is this one from edX [6]. And then go learn Clojure, because it's a really practical LISP that is also oriented towards FP, except that FP in a LISP is really different from FP in static languages like Haskell or Scala.
And you know, the best thing about this path is that you're not going to learn just a framework, or yet another language, but you're going to learn about functional programming, which is a concept that transcends programming languages with its related mentality and design patterns and is useful no matter what you're doing and in what language.
But then going back to Scala and Play2, well that's useful right now too. And did you know that Scala compiles to Javascript too and it's awesome?
[1] http://docs.scala-lang.org/overviews/core/futures.html
[2] http://akka.io/
[3] https://www.playframework.com/documentation/2.3.x/Iteratees
[4] http://www.reactive-streams.org/
[5] http://www.manning.com/bjarnason/
[6] https://www.edx.org/course/introduction-functional-programmi...
[7] http://www.scala-js.org/
And yes, it's a pretty good model for concurrency, however I consider it to be a compromise on the way to finding better approaches. And in the meantime, it just feels wrong to use a language that forces this mentality on you, unless you have specific use-cases for which this model fits perfectly that is.
And also, on the FP side - many people say that Scala is less FP than other languages, like Erlang. That's a rather odd assertion, because my experience has been the opposite. But that's for another discussion.
The website in question is written in Ruby on Rails. Since v1.0 (and Ruby 1.8). And it is now on current Rails (and Ruby!). Rails is a moving target, to put it mildly.
If I had to render an opinion, I'd say I love Ruby. Rails I tolerate. Some parts of Rails are great; others are tedious. By its own admission, Rails is opinionated software. You may or may not share its opinions.
NPM either disproves your thesis or has an exceptionally high amount of masters in its community for a language at that level of abstraction.
I'd say anecdotally 2 out of 5 times I've encountered this it's been someone covering up for their own lack of understanding. These are the worst and the most inflexible. All but one DBA I've worked with was this way. It's the natural result of cargo-culting.
2 out of 5 times it's because the person doesn't have patience to explain all the background you'd need to understand, or they don't trust that you have sufficient background. Sysadmins do this all the time. If you're smart and already pretty familiar with their field, it's very frustrating. This isn't as bad as the former case, but it indicates personnel conflict and lack of trust. It's understandable though, e.g. answering technical questions for business people. I've gotten pretty skilled at giving non-jargony, intelligible, short, "popularizing" answers, that also invite further questions if desired. But it's not easy.
And 1 out of 5 it's because people with experience have forgotten the reasons. I've been there too. Just the other week on a Rails project someone wanted to use an ActiveRecord default_scope of "where deleted_at is null", and I had felt the pain of that on past projects, but it took a while to dredge up the details from my memory.
Most of the above reasons don't correlate with age/experience, but the last one does. Experienced people have so internalized certain lessons that they've forgotten the reasons behind them. You could say this is a bit like Michael Polanyi's "tacit knowledge". In this case, hopefully they still have mental flexibility to recognize that nothing is 100%, and if you give them time to remember and communicate their reasons, you can have a reasoned discussion and make a good decision. But recognize that making people think in this way often "feels like work." You are asking them to exert themselves, so it's important to communicate in a way that isn't challenging their knowledge but asking them to share it more deeply.
I try to be conginizant of where my biases are, and be able to support my assertions on technical grouds. When you do tht though, you often times see there are indeed many valid ways to do things.
If you don't mind the 'learning' involving data loss, security breaches and competitive disadvantages... sure. Go for it.
I say this as someone who did learning 20+ years ago, and have lost data, had security issues, and had many of the issues that come with learning technology (and business). My employers and clients absorbed part of those learning costs. But make no mistake about it, we all paid a price for those mistakes. You also will pay something extra for hiring those who are "willing and eager to learn" - it's just the nature of the beast.
Thinking that price is the only factor, and that maybe someone will take "a bit longer" to get something done is naive.
"I've rejected folks who were lacking a basic understanding of the pro's and con's of something...This, I postulate, is generally because these guys have 10 years of 1 years experience".
Did you bother to be honest with them about why you "rejected" these folks?
I'm one of those "40 somethings" who don't always think "my way" is better, but I can generally tell you why "your way" is crap, what it'll cost in the short and long term, and what the less crappy options are. I don't generally have a single "my way" because rarely does one approach fit even most problems well.
That said, the assumption that you know better than me because you're 10 years older is part of the folly of what I'm pointing out. Indeed, you may know more than I do in my area of expertise, however you should base that on fact and merit. You should not assume that's the case just because you're older than me. If you tried that in an interview with me, indeed, it wouldn't last long and as a blunt Scottish guy, you'd certainly know why.
I was pointing out that the 'junior' often has more hidden costs than people realize. If you really are training someone - that's great, but I see far too little of that, and often just a hiring of the younger person either because they're perceived as cheaper, or a fear that the older person won't be a 'team player' (sometimes meaning "won't rollover and do whatever we say, work overtime, etc").
I'm not upset at you.
"I'm pointing out that if you're good, you don't need to worry."
Hrm... you still need to worry some, because you still need the other parties to be able to recognize that you're good (and to do that you need to be able to identify folks who are savvy enough to do that, ad infinitum). I've seen a lot of good folks get passed over for flashier/trendier folks who end up wasting lots of time/money.
The one other thing that comes with age more is a different perspective on time - it goes much faster than it did before, and watching people squander resources is... sometimes difficult.
Either way, I'm only trying to counter the "old is good". I fully accept there are amazing older IT workers, just not that older is always better.
At 25...
The time limit is not age but how much experience one has doing software engineering projects. One needs several unders ones belt, preferably some that have actually shipped so that one sees what the end user implications of the said products are. How long this will take? A couple of years? Hard to say.
How did it work out for you? I am curious as I am thinking of shifting from fin. applied math (econometrics) to SE ...
I turned to software engineering because computer graphics gave and give me such a huge kick. I don't know what intrinsically motivates you so I cannot comment whether I would suggest the career for you or not. Here's the rub: software engineering can be viewed in some circles as blue-collar work, which means the work environments can vary quite a lot. Also, the discipline is really young, and it shows in the amount of cargo cult and bullshit quotes one finds peddled as "best practices". There can be gigs where co-workers are experts and those can be great, however, there can be lot of environments where co-workers are perpetual expert beginners and those can suck big-time (or so I've heard).
Realistically, software engineering is still a pretty solid career choice so from a sustenance point of view I'm sure there are far worse options one can choose.
Focus on eliminating the very need for the problem to exist. Than on workarounds.
someday i might get there.
As someone who has been 'solo' for a very long time, I have to heavily disagree with this opinion. Going solo isn't as simple or easy as what the OP seems to be implying. Going solo means you are essentially working two jobs at once as it takes a tremendous amount of work and dedication to network, find good projects and keep them rolling in to pay your bills. To further exacerbate things, each year the amount of competition that you face ramps up drastically as more and more workers enter the consulting world who are unable to price themselves correctly and are willing to work for less and less.
Furthermore, by going solo, you are now assuming 100% of the risk as to whether or not your new consulting business sinks or swims. Chances are, just like any start up, you will sink. Additionally, you will have added burdens such as insurance requirements, self-employment taxes, various state/county-level taxes (such as gross receipts taxes) and a laundry list of day-to-day operations that you will need to perform that aren't related to software development.
Going solo really isn't for most people and I wish we'd all stop perpetuating this myth that it is somehow easily attainable. Remember, a solo consulting business is the easiest business you can start, maintaining one is the most difficult business you can run.
The 10yr C++ programmer ought to have those things nailed, the junior may not know they even exist.
If you're in a workplace full of programmers, consider moving onto to a firm that hires software engineers. You may have to move out of state unfortunately since the culture doesn't exist everywhere.
This is where I think we do get some legitimacy to this discrimination though. Most places you go, people are implementing functionality that is not terribly unlike that which has been done for the last 20 years (I'm talking the generic business "enterprise" shop). However, there seems to be about a ~~20% turnover in tools, styles, patterns, etc every year, and in my opinion at least on some platforms, the implementation style is tending towards the most complicated possible over-architected solutions possible.
When you're young and single, you have all the time in the world to keep up to date on all this, but once you're married, not so much. So, while I could easily out-implement the more "current" people, I'm not up tp speed on everything in their toolbox, so I lose.
As you say, "intelligent employers" should realize this, but how are they to know the technology flavor or style du jour is a waste of time, when the industry itself can't figure it out? ("everything XML" as just one example)
And those opinions are quite locally specific. In my current place, we value age and experience perhaps more than many other shops in SV. So you're right, I think it doesn't "generalize", it depends on one's work culture.
Where is the plan B for doctors? Where is the plan B for Lawyers? Why do these other professionals have respect in the their old age and not us software engineers/programmers?
How depressing.
> The half-life of an engineer, software or hardware, is only a few years.
And I still don't get this. Move out of software and you'll find loads of over 40's and over 50's engineers. Here in Perth I know loads of older engineers, that are given dignity and respect along with their peers in Medicine and Law.
This plan B stuff is because of the culture that surrounds programmers. If there is any plan B, it is to maybe start admitting that older programmers might actually be useful and worthwhile for employment, much like every other white collar profession.
It's true that a 40 year old might not be able to work as many hours as a 20 year old, but that doesn't mean each hour is worth the same. At 40, you'd hope that the older programmers hours put in are more considered with all their experience and are most certainly worth it.
The same goes for older Lawyers and older doctors, they might not be as energetic as 20 year olds, but with all that experience to make that much more of an informed decision, it certainly means the older generation can compete.
This is a culture issue.
> Software engineering reliably undergoes a major technology shift at least every 10 years.
I doubt any shift invalidates real fundamental knowledge. Sure if your entire career has only been a couple of languages with very little algorithm theory, then true, but that's because you never studied the subject, on your own or formally, that isn't because you're 40.
For example, Doctors and Lawyers have to have the fundamentals down, it's very important. I guess it's true that not enough programmers have the fundamentals down and that is an issue.
But if you're 40 and have training in the fundamentals such as algorithms and design before even hitting the code, you should easily be able to adapt.
> The more irrelevant experience a candidate has, the more lopsided the utility/value equation becomes
Again this is a HR issue. A software engineer/programmer that starts their work from the design and algorithm level should be able to pick up a new language in a couple of weeks. This issue is mainly with the way we hire programmers not with the programmers themselves.
It's like the job ad for 10 years experience in Node.js when Node.js was 3 years old. Just because HR are clueless doesn't mean we need to all start changing our careers.
If you want my advice, it's learn that knowing people is as important (or more!) than what you know.
If you build up your career around being an expert and networking, you will be in a better position than the expert who knows no one.
OTOH if we move toward a more professional / credentialed / high-status profession that won't be all roses, what with exams, high barriers to entry, slow/uniform career progression, etc. I don't like not having a plan after 40 but I do enjoy how meritocratic the industry is, and how it really does reward hard work more than just, say, years worked.
They have unions.
Doctors and lawyers also have strong protections from foreign competition. It simply doesn't matter if you are the best doctor or lawyer if you trained outside of the United States. You won't be allowed to practise until you qualify in the US.
He advocates doing things yourself, DIY etc.
If you can pay someone less to do something than you could earn in the same amount of time. Its better to outsource those tasks.
For someone who is busy working.. it depends. If you get a salary to work 40h a week... does hiring a poolboy for $20 an hour instead of cleaning your own pool for a self-declared time worth of $50 an hour make sense? I am not sure. If you are consulting and your choices are bill 45h and have a poolboy, or bill 40h and have your own poolboy... then the logic is much more in favor of outsourcing your tasks.
The other trick is how much do some things really cost? I know to pay someone to put brakes on my car, I would pay the equivalent of $100-$200 an hour. For $100-$200 an hour, I will gladly crawl under my car and get dirty!
But in big companies (Amazon, Google, Twitter) in enterprise software companies, banks, medical tech, finance, I think it's not that uncommon to find 40 year old developers. Most of the developers in my company average at way above 30. And we have a couple of engineers above 50. All of them are pretty kick ass Java developers and they all get tons of unsolicited recruiter spam. (Maybe I'm delusional or in denial, or perhaps this is just the difference between industries, but I think that if you WANT to still do it while you are 40, and you keep yourself sharp, just like doctors have to keep up every year with the latest developments in medical research to stay relevant, then I think you can do it till you retire)
I think the reason many drop out of coding is that it is very time consuming to keep up, and some may want sometimes a less mentally demanding daily routine. Managing a team of engineers can be tough, but it's somewhat less mentally and intellectually strenuous and energy hungry as coding. Coding takes a lot of focus and sharpness, and sometimes it's simply hard grunt work, people sometimes get tired of it and want to move on to management (or being a "solution architect") or even product management.
I think the problem is that the 40 year olds chose on their own to do less coding at some point, and more management / IT / architecture. (e.g. the less good developers, those who don't pass the sort from 100 to 1 but still manage to land a job, eventually understand it's not for them and move on to other, not less important roles)
I think there's a bit of survivor bias. More interesting are the stories of someone who's not at one of those large or old-school companies. There's a bunch of skills (MFC, Flash, microcontrollers) that used to define 95% of someone's job, and are no longer relevant.
MFC and flash can die though.
This preconceived notion that a manager or CEO must earn more than their employees doesn't make much sense. It's just a status game. If that developer (regardless of their age) has skills and experience that the company needs, and those skills are harder to find in the job market than management skills, it makes sense to pay them a higher salary.
Nobody questions the fact that baseball players and movie stars and investment bankers are paid several times more than the president of the U.S., so why shouldn't developers who are in high demand be able to make more than a CEO?
But baseball players are paid more than managers.
I was allowed to offer only a single bit of career advice, that'd be what I'd say: don't specialize in programming languages. They're a trap!
(But then, I'm not quite 40 yet, so I could be wrong).
More importantly than the article says, develop skill in solving business problems using your programming skills.
Proprietary frameworks, products, and tools are definitely a terrible thing to base your career on. Languages such as C, C++, Java, Ruby, etc. are a good investment.
I got my first tech job (at 15!) because I'd taught myself Java, which was then brand-new, and a number of local companies needed experience with that and this weird new technology called the WWW. Parlayed that into a bunch of web experience, often as sole developer or team lead. Parlayed that into a job at Google, where I got to learn information retrieval, machine learning, distributed systems, the stuff that actually has a shelf life.
Someone could certainly end up at the same place (skill-wise) by getting a Ph.D and then a job at Google. The thing is, if you take that path, you're also forgoing work experience, income, perspective on how the industry operates, and the opportunity to jump off into different careers if you find you like them better. My first job out of college was writing software for hedge funds, for example; it turns out I hated the financial industry, but if I hadn't, it wouldn't have been too big a leap to get a job at a hedge fund after that.
The trick is to not kid yourself into thinking that the twelfth Javascript framework you learn is still valuable. The first gives you opportunities, the second and third give you perspective. But after that, have a plan B for things you should be learning that you can't get on the web. All that Java Swing stuff I did around 2000? Basically useless. Ditto the PHP in college, and even my Django & Javascript skills are nearing the end of their shelf life. It's the stuff I've done besides that, the stuff I generally don't talk about on Hacker News, that makes me valuable
C has been around since 1972 and is just as relevant as ever even as the popularity of C++ wanes. Python has been around since 1991 and is growing in popularity.
There is a trick to figuring out which technologies will stick around for the long haul, and it is one which most developers don't even think to try and hone.
My career advice would not be to not specialize in programming languages but to learn to distinguish programming trends from programming fashions and invest (with training/picking the right job, etc.) accordingly.
I doubt there is going to be much call for people with experience in Mongo in 5-7 years' time, for instance, but Postgres? Hell yeah. I predict increased demand for F#, too, but not so much for, say, Java (even though it won't go away).
C is less relevant now than it was in 1996. A lot less relevant. Way, way, way less relevant. In 1996, most serious software was written in C. Today, only a tiny fraction of it is.
Of course, this is all subjective. But I can barely imagine that people coming from more expressive statically typed languages would like Java very much.
(That's not to say that the tooling for Java isn't extremely good.)
I can't think of a great example. It can apply to anything. Though your larger point stands, C++ is a not so great example. Many languages are roller coasters or extremely specialized. In contrast, C++ is on another upswing with C++11/14/17. It's used practically everywhere, especially in graphics, systems, and game development. A point worth mentioning is that good C and C++ developers are often capable of adapting to other languages and settings quickly. They're used to a lot of basic building blocks.
Thats not ubiquitous, but it indicates that despite the upswing, hitching yourself to that language is easier said than done.
I hear this often on HN and elsewhere, if I'd had to guess I'd also say it's true. But is there any proper evidence to support that? And in any case, it will probably still take decades before C++ will be gone. Maybe you could as well say: specialize in C++ now, in 20 years specialized companies will be begging on their knees for you to come work for them to keep their legacy C+++ stack working :]
don't specialize in programming languages.
Depending on the language you do need some level of specialization/mastering though else you might end up being writing very sub-optimal or even bad code in some languages. I'd say learning how to learn a programming language also pays off. Have you seen the amounts of SO questions for C from people who haven't reached a certain level yet? Their programs continuously crash or don't work as expected. Not necessarily because their intent is incorrect or they are bad programmers/engineers but more often because they lack proper understanding of C. Have you tried approaching Matlab the same way as any other language? Oops, there goes the performance. Working in Labview? It might look like it's easy (hey, all you gotta do is draw wires, right) but good luck building a medium sized application with it if you don't know at least some of the ins and outs. Now you might say 'if you encounter such problems you need to pick a better language' but that is just not how it works.
Agree and disagree. I think that learning the minutiae of a specific programming language might be an evolutionary dead end. I say "might be" because there are C++ engineers making $500k in HFT. Since we're both in the same city (Chicago) now, we both probably know some of them. C++ isn't dead yet, and it's not even close (but a mediocre C++ engineer is probably hosed).
What seems to happen as a technology fades out is that the number of jobs drops, while the pay in those jobs increases. There's a risk to it. If you continue to be qualified for those jobs in the depreciating technology, then you're solid. If you lose at the game of musical chairs, you can be screwed.
There's value in learning programming languages if you keep an eye out for the concepts that make them what they are, and if those concepts have a future, which is more likely. We may not need C++ in 25 years, but we are going to have low-level programming problems that require a C-like language (and fluency with assembly languages). Haskell itself may or may not be around in 25 years, but the problems it exists to solve and the value of static typing will still be relevant. Common Lisp is nearly dead, but Clojure is doing well. Languages die, but concepts hibernate at worst.
The people who will be screwed are the ones who specialized in minutiae of Java but forgot the computer science itself: the ones who got really good at JVM configuration and Spring and Hibernate but have completely forgotten how computers really work. The really good ones will always have jobs: there'll be Java work 50 years from now, just as there is Cobol work now and some of it pays very well, but the more average engineers who only learned The Java Way will be screwed: not good enough to get the dwindling (if well-paid) Java jobs and with too much atrophy of their general CS knowledge to handle whatever is next.
I think it is just a reality of the current state the industry is in. Everyone seems to want developers who are already trained and experienced in what they are using so they can "hit the ground running", at least for non-junior positions. I think that is the biggest impediment for more experienced developers.
A) Is so arrogant they think they know it all. Then when they turn in the code it's barely passable and it become clear they are going to be difficult to work with.
B) Are overly emotional and they all take things way too seriously.
Now every 35+ person we have brought in for a project is:
A) Professional. Gets the job done and very well.
B) Sees the bigger picture and goes with the flow.
That's my personal experience but hey if I was management I would go with the 20 year old's all day long. As long as I did not know what they did or had to deal with them...Oh wait....
Just by doing that I excelled in many areas, and now as a n almost 40 year old developer I try to hire people who act like I did, and believe me they're out there.
I remember most of my age group had enormous respect for the older engineers. But then, we didn't have Google and Wikipedia and entirely too facile access to information that lends the patina of 'knowledge' that is so easily obtained these days. So a lot of the aggressive posturing these days is really a symptom of the not knowing that you don't know that much yet ..
This can be a positive. My experience with 40+ year olds is that they tend to sacrifice user experience/security for what they know. "Our customers won't care if they have to use Internet Explorer with ActiveX as long as it gets the job done." My point is that an experienced programmer who is not up to date can be as detrimental an arrogant 20 year old. The 40+ year old programmer who stay up to date though... They are worth their weight in gold and I aspire to join them one day.
Edit: Background - Got really pissed off at a 40+ dev using active x to launch external programs and making it a requirement that our end users use IE with ActiveX enabled. Almost lost my job because management sided with the person who had more experience.
I'm sure there are some people who don't expand, though I am in my 40s and am constantly pressing for the best UX possible for customers. I've suffered enough with bad UX, I won't go along with inflicting that on anyone no matter how challenging it might be to fix. On the other hand I am (almost) always grateful for people pointing out bugs in things I write now, but used to be a lot more insecure about it. A hit to the pride is nothing compared to the pain of shipping something broken.
Well said. This should be the golden rule of development. I feel that too often we (both young and old) don't ask questions because we fear the repercussions of appearing ignorant.
I can't know if you're in one of these industries, but one of the virtues of experience is knowing when something isn't important because you know facts about your particular niche that an outsider wouldn't.
If you want to win this technical battle, your best bet is to say "I'll implement it in ActiveX if you really believe it is necessary for the business. However, Microsoft ended support for WinXP and IE6 in 2014. They have been actively campaigning to get their customers off of it. There are A, B, and C startups out there with competitive offerings that work on the iPad. iPad market share among healthcare organizations has gone up from X to Y% in the last 3 years, while IE6 market share has declined from Z to W%. If we implement this software as an ActiveX control, we will lose out on $M in sales, with the worst-case scenario being that our userbase upgrades from IE6 and we find ourselves out of business with zero market. It's happening already, as you saw from the market share numbers I just shared with you."
Basically, put the fear of going out of business into your management chain, with the data to back it up. (And if you can't find that data - then your management is right, and you shouldn't bother upgrading.) That goes over a lot better than "I read you should never use IE6 for HIPAA data on the Internet."
Why generalize from one encounter with one 40+ year old developer?
Younger devs who do have experience with this stuck in their ways behaviors and it can be frustrating and they try to side step it by not engaging the older devs.
Don't mistake not buying the hype for sticking with something just because you know it. While there aren't a lot of reasons to favour RCS or CVS when Subversion exists, there are sensible reasons you might favour SVN over a DVCS for some projects.
It's slowed down the company globally, prevents us from using various tools that don't have svn compatibility (like android's repo, gerrit or git's client side pre-commit hooks) and overall just been a relative pain the ass compared to git.
The very small edge cases that svn might be better at now did not apply to us. Notice I didn't say perforce, or google's custom solution in my example.
On the other hand, every project I've ever worked on that has used Git still had some sort of centralised repository that was considered authoritative for controlled release purposes. The smart projects had a local server for this that everyone pushed to. The over-enthusiastic used GitHub, and in at least one case then found themselves unable to deploy when their systems were all up but GitHub was down.
Within that master repository, having a single linear history so you can identify exactly which code you've got in any given release with just a revision number is often helpful. In Git you simply don't have this, so you have to manually tag everything you might ever want to reproduce, which is basically everything on your master server, which requires extra hassle and clutters your log.
A separate but very practical issue is that SVN has worked fine on Windows for years. Git's support for Windows is getting better, but still far from ideal even today.
The sheer complexity of Git, up to and including data loss bugs because even Git's own scripts didn't track everything properly, is another recurring concern.
I've seen more than one very experienced developer, well aware of the pros and cons of different tools, argue for using SVN on a new project for these reasons alone.
In this example, the older programmer may figure he can meet the real requirements faster and with less risk using technologies he's already familiar with. He might be right!
Unfortunately, there's also a good chance he's being lazy, or political, or etc.
Try to give it a really good objective look to see for yourself which one it is. If the latter, you can try to influence the developer in an ego-friendly way or consider leaving if it becomes unbearable. If your managers have no real technical experience themselves then they are useless in these situations.
Good chance it won't be the last time you have to deal with this sort of thing. (coming from an old-ish dev)
I was on a job interview a few days ago and was asked "What do you dislike the most about working with others on a team" and gave them your exact answer, thinking it sensible giving the state of software dev nowadays.
I could tell immediately that they didn't care for it one bit, and the interview ended a few minutes later. I don't really know what they wanted to hear, but that sure was not it.
Personally, I'd prefer your answer.
Once you seen enough people you realize the bell curve always seems to apply, the curve shifts right along the experience axis over time but it will always be there and there will always be outliers. Don't rule out the 20 year olds just because of their age either.
I've noticed that some young devs have really, really hard time when we discover bugs in "their baby". This most likely relates to the underlying arrogance ("there cannot be anything wrong with my code").
I hope that all the future gigs I end up, I'm part of the effort to create professional environment where the younger devs can pick-up professionalism from the seniors.
But to be fair on myself and others, I was expecting something more intellectually challenging than what basically amounts to a job in 'abstract plumbing'.
Now I have come to terms with this reality life is much simpler.
From web to mobile? What was the tough bridge to cross in the last 10 years?
Mobile apps were invented in the 1990s (Newton, Palm), popularized in 2008, and (at least in Silicon Valley) it's a big topic of debate whether the web is dead. In my old job - Google Search - I was still pretty secure as a web guru. In my new job - startup founder - I feel that I at least have to do my due diligence and evaluate the technology.
Whether it's a problem for your career depends on exactly what you want to be doing with your career. There are still people making a living off of COBOL and IBM mainframes. In general, consumer markets peak about 5 years after the technology is introduced to the general public (so microcomputer apps came into their own around 1980 with Visicalc, windowing apps around 1990 with MSWord and various office suites, webapps around 2000 with Google etc, mobile just starting to peak now with Uber/Instacart/etc.) If you're founding a startup you need to account for the time it takes to build your product, so in general you want to use technologies not more than 2 years old. If you're working at a company you don't want to use technologies until the companies that have adopted them have gotten big, so it's frequently 10 years or so after adoption.
GoF patterns provide structure (at the cost of complexity). FP patterns are simpler and succinct but aren't quite as cookie cutter and thus are less structured.
Probably the tick-tock of the pendulum swinging. As software became too unique to maintain, standard patterns were implemented. As standard patterns became overly complex, we swing back to more expressive constructs.
1) that feeling of "being behind" never goes away. In fact, the more you learn, the wider the breadth of topics you will want to learn, so the feeling only grows. Software engineering is not a field which lends itself well to people who want to "learn the playbook so they can be confident they are doing it right". The main question is if you can spin "feeling behind" into a positive force, similar to what competitive athletes do.
2) if people are telling you that "you are behind" - ignore them and start hanging out with better people. There are more than enough talented people out there who want todo nothing more than help others while building up their confidence in the process.
With the sky-high salaries it is possible to earn as a software engineer, it should be straightforward (not easy, but still straightforward nonetheless), to save enough to retire at the age of 40. After which, you can spend your remaining time as you see fit, working on personal projects or any other hobby that suits your fancy.
This is the route I am taking.
If you plan on living the life of a hermit workaholic, certainly reasonable with your life circumstances.
If you have a family, want to travel, or want to buy instead of rent, assuming the Bay Area, very idealistic.
Some areas hold up better than others, but, say mountain view, a 20-something at his/her first/second job, unless has other means, isn't going to pick up property easily to hold for 15 years.
Affordable areas in a boom? Those most likely to take a serious crap in a downturn.
It was a decision I made when I was 23. I remember doing a spreadsheet at that time to plan it all out. This was back before there were good references on how to plan it out. Some of my assumptions were a bit off, but I got there in the end.
http://earlyretirementextreme.com/
http://www.mrmoneymustache.com/
The TL;DR is this: you need to be able to live off about 3.5% of your portfolio for one year. That will allow you to avoid depleting your principal over a very long term, and also give yourself an inflation-adjusted raise every year so you maintain your spending power. Often people quote a “4%” rule, but I think it’s meant for people that retire at a more “normal” time in their lives. The extra 0.5% actually makes a big difference in the probability that your portfolio can fail.
So, if you have a million dollars, you need to live off $35K a year.
If you’re willing to really change your lifestyle, you can retire off $500K, which would give you $17K a year. It doesn’t sound like much in Silicon Valley, but that will put you in the top tier of income in a place like the Philippines.
I don’t want to post my own net worth because it might come across as chest-beating. I’ve been living in a few places that are a lot cheaper than the United States, so my expenses are low. Over the last three years I’ve been averaging living off slightly less than 2% of my net worth annually. So, I’m REALLY safe by the “3.5% rule”. My net worth is higher than when I retired.
I’m enjoying my life. Every day is a clean slate. There is nowhere that I have to be at two o’clock on a Tuesday afternoon. I can read or take a walk, go to the gym, or tinker with some computer language. I like this life. I sure hope I did all the math right, because if I have to back to a cubicle in Silicon Valley it’s going to be REALLY painful for me. No amount of free sushi by your employer is enough to compensate you for your lack of freedom.
Essentially, your income in retirement should not be dictated by your current income, but by your current level of expenses. If you can save a multiple of your current annual expenses, and that multiple is high enough to account for real-terms investment gains, you're financially independent: you don't need to work any more.
The number generally used is 25x, which corresponds to real-terms gains of 4% per year on your savings.
That has been very difficult (at least for me) since 2008.
The S&P 500 is 50% above its 2008 peak on May 8, 2008.[1] That's a 5% annual compounded return ((210/140)^(1/7)). And that's using the 2008 peak: if I use the lowest price from 2008 (in December), your return would have been 8.8% annually. Inflation (at least in USD) has been benign during this period, so probably there has been a real 4% return during that period. I don't know how you concluded that you didn't get a 4% real return during this period.
If you look at the stock market over any short-term (<15 years) it will be quite volatile. Over very long periods it is more regular. If you're investing in the stock market, you must take a very long time horizon.
If you really want to understand this topic in more details and whether your portfolio is likely to fail over some period of time, I encourage you to play with FireCalc [2].
[1] http://tinyurl.com/poz7trc [2] http://www.firecalc.com/
Why did you decide to take this route at 23? What were the drivers.
Thank you for sharing.
We need programming to be a real career. People shouldn't feel pushed out when they are in what in any other industry would be considered the prime of their career. This mentality is destructive not only for us but the economy as a whole.
I'm not kidding... do people really believe this? I always thought that was a fairy tale that employers tell to still-wet-behind-the-ears kids in order to pump up their egos so that they work untenable hours for meager pay
23 years ago, when I was 23 years old, I actually posted a Usenet question on this topic (archived somewhere?) asking where were all of the "old" programmers?
First off, people don't decpreciate, skill sets do. Of course someone making a high salary will be undesirable if their skills stay the same and become commoditized or less relevant. But the same would be true of a young person with the same salary/skills. Every time this happens the challenge becomes finding the next niche that is valuable, and that you like enough to devote lots of time to.
Secondly, a lot of older folks get siphoned off to management voluntarily. This can happen when a company doesn't have equal career ladders for tech and management. At good software companies you can advance as individual contributor up to a VP level, while other companies force a switch to management to continue progressing. And of course a few are natural leaders of people who want run a group, or try a cross functional gig. Some feel it's more prestigious to be director of whatever dept.
On age discrimination in tech, I hear about it anecdotaly, but haven't yet perceived it happening to me. Maybe it's just too early to notice, or maybe there will always be some people in tech who want to work with the best team possible regardless of age? Would I hire an 80 year old developer? They'd get the same questions as any 25 year old. Show me the code you've written over the last year. Shoe me how you communicate complex concepts in simple ways. Are you a dick to work with?
On being too expensive, the reality is there is an effective salary cap for everyone which is a function of company, role, skills, location, etc. You need to know what the cap is and realize if a company balks at going over it then it may have nothing to do with age. The calculus is what it is, older people are just more likely to hit the caps first.
Finally I must disagree with the comments I see about young people being less capable. Yes, experience is irreplaceable in certain contexts. However more often I notice the people doing really great work are a special minority of individuals that just have the right combination of smarts, drive, maturity, flexibility, luck, etc.
I'll try to remember to follow up on this post in another 23 years to discuss what has changed.
It seems in the places I've lived (LA, DC) the salaries are pretty squashed together after 5 years experience. Basically anyone with that experience is getting a similar pay check +/- 15%. For many after 28 you are close to being maxed on your pay which would put you in the same spot this article plops the 40 year olds.
However, there's going to be a HUGE gulf between what they make and what the senior executives make--anywhere between 3X and 300X. That's where you go to escape the "salary squash".
It's a myth that most managers make much more than programmers and that they "just" organize your time. Let's have a little bit of respect, not just for our own professions, but also for the people we work with.
Well, instead of just saying it's a myth and relying on averaged stats in the industry to satiate peoples' curiosity/jealousy, perhaps we should just all be more open about how much we all make. I.e. let's not make it taboo and "contractually-breaking" to discuss salaries openly.
I know, yes, our current employment culture won't easily handle the strain of all coworkers knowing each others' and their superiors' salaries. But I have noticed the trend reversing slowly.
I also think that salary data, with no corresponding ability data, will be meaningless.
also, the majority of managers are not the one that are in charge, taking decisions, managing risks and settings directions; middle managers types are way more common. and I do respect those of them that work well, but they are so hard to find that I'll stand by the 'most' in 'just organize things'.
Law does pay more for very successful people, but at the median it actually pays less.
Doctors do get paid more, but they also spend a much longer time in training. The amount of time that most engineers spend in training is more in line with the amount of time that PAs spend in training.
Programmers are 'engineers' in the same way that those with an MCSE are 'engineers' -- they operate a computer and employ a unique and useful skill-set.
In Canada, a programmer is certainly not an engineer. And for Canadians going for a TN visa to work in the US, programmers are not allowed. Usually they try to slip in as 'Systems analysts' or craft the job/acceptance letter to fit under an engineering discipline.
Software Engineers are engineers in Canada. A self taught programmer doing css/html is not an engineer.
I'd simply qualify someone as an engineer, iff they successfully graduated from recognized university from an accredited Engineering program. And a second possible scenario is if someone's managed to pass all the Professional Engineer's examinations independently (rare).
Not sure why I got down voted. A quick google search will reveal my comment is factual. At least in Canada where I'm from.
https://archive.org/stream/TNVisaForSystemsAnalystsVsProgram...
"Many people do not realise that computer programmers do not qualify under the TN Visa"
http://peo.on.ca/index.php/ci_id/2057/la_id/1.htm
"meet PEO's stipulated academic requirements for licensure (hold an undergraduate engineering degree from a Canadian Engineering Accreditation board (CEAB)-accredited program, or possess equivalent qualifications), and, if required, successfully complete any technical exams."
I think we've got better at that and bright engineers are just being promoted into senior engineers, so hopefully it's fixing the selection bias.
Just wow. Quite a bit of agism there. In my experience most CEOs are not technical, and thy want "business guys" in management. This ranges from big companies (my manager at Amazon had a criminal justice degree and could barely operate a computer, and his IQ was less than 100) to startups (often the CTO will be technical, but also a founder, so there's not a lot of opportunity to become "middle management" during the startup phase.
Also, last year in Austin I made exactly %20 more than I did in Seattle in 2000. Kinda sad-- up %20 in 15 years-- that doesn't even cover the inflation over that time period. (and I was making more than everyone else there, including some senior people.)
I've decided I need to switch to management, as it's time. In fact it's past time, but I have found that too many companies-- particularly startups-- don't promote managers from engineers, they want "biz guys" who don't understand software to be the "managers" way too often. (at least outside of silly valley.)
What about tinting ("dieing?" sorry for not knowing the word in English) your hair? It's superficial, but if it lands a job, it's fair.
I'm in my mid-thirties, so please take that into an account. Also I know that these are the questions that I have to ponder in the coming years, so your insights are highly valued.
Look is important,unfortunately, but it isn't always about age, sometimes you're too fat, or not white enough ...
Or black enough... Or female enough... Or Non-foreign enough (yes I got this one before)... All sorts of stuff, to be honest.
http://www.reuters.com/article/2012/11/27/us-valley-ageism-i...
http://www.dailymail.co.uk/news/article-2239277/CEO-Randy-Ad...
There's always going to be a need for people who can walk in to a new situation, diagnose what's going well and what needs to be fixed, and carry that out.
My second observation is that in all the jobs I've had where this was not true, the company has not been particularly successful in the long run. It's unclear whether this is related, but it's interesting.
However, I can come up with an alternative statement that may be a better explanation of what some people seem to observe: if you are not a really good engineer by the time you turn 40, and you expect to be paid based on your "years of experience", get a plan B.