211–220 of 303 posts
Earlier quoted context omitted.
Prove what wrong?
I think comp1927 means Knuth proves that one can get better with age. Which is a fine point, but Donald Knuth is a difficult lead to follow.
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 b…
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.
I can explain this. It's a very old idea. The truth about the young hires is that they're cheap and the work they do isn't very important, but they're hired based on the potential to rise a level or few.
From an executive perspective, you don't hire juniors for the work they'll do, because it's usually not of high impact of value. You hire based on the probability that they'll be high-impact employees later. It's impossible to predict this at the individual level, so you're building a portfolio.
Of course, in 2015, the one-company-for-life model is pretty much dead and most people who get executive positions get them by job hopping at the first sign of an obstacle. Likewise, companies invest very little in their junior employees and tend to hire top-level talent from outside. So the biases from the old days don't really make sense.
If someone's 40 and still a junior or mid-level engineer, the assumption is that he's "too old" to become a high-impact employee in 5 years. It's completely ridiculous, these days. He could have been doing something else, like trying to make it as a novelist or working in a dive shop. It's a hold-over from the employment-for-life, gold-watch era.
For the consultant, he's not selling himself on some hazy "future potential" factor, so no one cares how old he is or (more relevantly) how old he'll be in 10 years.
Very few people actually think that young, junior programmers are more skilled or better at their jobs than the 50+ badasses. The issue is that the young juniors come with a 5% chance of being a high-impact, executive-level employee in 10 years. Since the people making big decisions are executives who tend to discount the importance of everyone but executives, this still matters... even though the one-company-for-life model is pretty much dead.
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 cat…
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.
Earlier quoted context omitted.
I'm quite sure there's more to software engineering than can be learned in 8-10 years. I spent 7 years working with one tiny part of formal software verification, and still didn't get to the bottom of it. Perhaps it's true in web development, where it does really seem like the industry is recycling ideas every 18 months. But there's far more depth to the field than just "JavaScript framework n+1" and "Yet another tas…
The point is not that there is nothing to learn after 8-10 years. There is enough to learn for multiple lifetimes. The point is that after 8-10 years additional learning/experience will not give you a competitive advantage compared to younger programmers. Also, I can see why someone would downvote my post above, since it describes an unpleasant reality. But I think it is crucial for young programmers to be aware of t…
The key is, no matter the age, to keep expanding your knowledge base.
Earlier quoted context omitted.
>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 wo…
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…
However, as you progress in your career become a specialist in a particular field. Avoid becoming a general programmer. So far I've had two programming careers, the first was a games programmer, a very specialised area. The current is building high performance trading system in the financial sector. These are both very liquid and specialised area.
This will increase the likelihood of you being in demand, and afford you the luxury of options.
Not sure I add much worth to the view portrayed by this article. However, as you progress in your career become a specialist in a particular field. Avoid becoming a general programmer. So far I've had two programming careers, the first was a games programmer, a very specialised area. The current is building high performance trading system in the financial sector. These are both very liquid and specialised area. This…
It's hard to predict the lifetime of the field you are planning to become an expert in.
Earlier quoted context omitted.
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…
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.
Earlier quoted context omitted.
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 technologie…
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.