41–50 of 60 posts
The only problem for being a programmer in 40s and 50s is that it is really hard to find a job. This pretty much the only problem, but I guess that is a big problem :(
That really depends. On the internet nobody needs to know that you are 40 or 50. Finding a permanent job at a SV company may be harder, but freelancing / contracting is not.
Actually burning midnight oil is a myth. I mean we all know the myth: You grab your coffee, black as night and sweet as sin, you sit in front of your computer with your favourite IDE on. Then you code until the sun sets and you go home with a majestic smile on your face. Because, you - the lonely coder - has saved the day. Yet again. I mean I was really into this image when I was 20. Now, after had some experience in…
Earlier quoted context omitted.
That really depends. On the internet nobody needs to know that you are 40 or 50. Finding a permanent job at a SV company may be harder, but freelancing / contracting is not.
That is 100% true. Unfortunately, large chunk of new (and good paying) jobs are created by these new companies which require "cultural fit".
That comment says nothing about what percentage of companies are like that. I don't have enough data to know if they're common or rare.
I'd guess that the signal:noise ratio of jobs available at age 50 gets better. Ninety percent of software jobs are shitty, but I also think that companies offering shitty jobs are more likely to age-discriminate, because older people are not likely to fall into the premature emotional investment trap.
People who want to be coding in their 50s should follow this advice. It's burning yourself out on arbitrary deadlines for meaningless business bullshit that pushes a lot of us out. A 5-year burnout, at any age, is pretty much impossible to recover from in this industry.
Programming becomes less bipolar (for lack of a better word) as you get older because you stop getting emotionally invested in things that don't deserve it, and you also become more willing to steal an education at work (thus ensuring that, regardless of what your project does, you'll be fine).
It's really interesting to see the perspective of an older peer when it comes to development. I've been writing code since I was 10 (19 years ago) and have been doing it professionally for about eight years. To look back sometimes and see the differences in myself as a coder and wonder about what it will look like going forward is a favorite wandering for my brain. I think the one thing that I find most common in my…
Work at good companies, and the people you work with will be good.
Yesterday's post was closer to the actuality of a programmer than this one. To reiterate what I said yesterday, when you are coding professionally, you don't choose what technologies to use, you don't pick projects that itch your creative side. You're just part of a production steam roll. Passion is irrelevant in this discussion. What matters is how fast you can deliver and whether you are more billable than the next…
I do, at least some of the time.
>you don't pick projects that itch your creative side
Right I'm doing contract work, so actually I do tend to pick the interesting projects. Before that I had a job where I specified the technology that I was using -- and that everyone else had to use. Before that I picked a job that used technology I wanted to be using. And so on...I haven't been "forced" to use a technology that I didn't think appropriate for a long time (unless you count the idiot decisions by Google and Apple to use Java and Objective C, respectively, but I've been minimizing my contamination by both).
And it was exactly passion and an urge to learn, just as the guy described in the article, that enabled me to be in this position. My contract work pays up to $125/hour, and I'm rapidly approaching age 50, so what were you saying about "medium wage"? Or do you work for Wall Street and make twice that now?
Or maybe you've got the wrong job? Or you don't have a passion for programming? As he said, if you don't have it, you'll burn yourself out and go elsewhere.
The only problem for being a programmer in 40s and 50s is that it is really hard to find a job. This pretty much the only problem, but I guess that is a big problem :(
And I'm in my 40s.
And I've been turning down full-time employee offers for years. Contracting suits me better. That or a "founder" role.
You need to specialize. And to be good at your specialty. Mine has been games for years, but this time I leveraged my Android experience to get a contract doing embedded Linux software.
For the record, my job is "good paying": Nearly $100/hour. And it's hourly, so the one time I had to work a long day to meet a deadline (nearly 10 hours! Oh no!) I got paid for it. :)
So keep your skills fresh and relevant and age doesn't matter -- except in one important way. People will see you and think "this guy has a life, so he isn't going to be pulling constant 12 hour days," and they (foolishly) think that's a drawback. But at least for me, I'd laugh at them for not wanting to hire me -- because I sure-as-hell wouldn't want to work for someone who expected that.
"But large scale, high stress coding? I may have to admit that's a young man's game." No, it's a stupid person's game (sure it's mostly men, but not 100%). I'm 55 and have been coding professionally since 1981 and started in school in 1973 or so. One thing I've learned for sure is that coding yourself to death is not worth it in the end. People who want to be coding in their 50s should follow this advice. It's burnin…
An easy way to turbocharge a team of hot-shot young developers is as follows: Tell them to not come in over the weekend (unless there is a seriously important deadline that cannot be handled any other way, and this has been discussed with the team). Tell them to go home in time to be able to go out to dinner or catch a movie (tricky, because odds are good that they are coming in to work late, and we do want everyone doing roughly 8 hour days, five days a week). Tell them to spend less time coding and more time planning.
It can take a few weeks for the improvements to materialize, but overall productivity will go up. Code quality will go up. Energy and enthusiasm will go up. Once you see these upticks, you can work on all the other things that the team needs to do to improve their code.
And then when the shit hits the fan and you do need to push the team, there will be room to push them. They will have energy reserves they can draw on. They will have trust in you as a manager. They will be able to draw on that extra 10%.
Marathon coding is a great way to deliver a terrible product that is hard to maintain