Yes I Still Want To Be Doing This at 56(thecodist.com)
thecodist.com
Yes I Still Want To Be Doing This at 56
http://thecodist.com/article/yes_i_still_want_to_be_doing_this_at_56
22 comments
Actually, it is not a myth. I have done this, more when I was younger, but it still happens occasionally.
One reason for the midnight oil is that the phone stop ringing, everybody else goes home, there are no distractions. Another reason is that the business demands it. Let me give you an example. There is a story that the folks at WordPerfect, which had (and still has, if my mother is any indication) fiercely loyal customers. They had a very family-oriented company culture, and nobody stayed past 5. Microsoft did not go home at five, except maybe at 5 am. Microsoft ate their lunch.
In several situations, I could not get access to computers until after the day shift went home. In Portland, while on co-op during college, I would walk to work at about 0200. The path took me past a bakery that was in full-on baking mode. While building a real-time medical data system, we had one production computer and a second computer that was occasionally used for production at night, so we worked nights to integrate both parts of production so that the other computer would be available for development all day.
And sometimes a problem will grab you and not let you go. The story of fluidics has as its beginning a 36 hour creative burst by its major contributor. And there are problems that I have worked on that have a multi-hour daily mental ramp-up.
The myth part of this is that you can get away with doing this constantly. You can't. As you say this very act should be resorted when you have no choice.
What the midnight oil has taught us in the industry is that the best programming is done in an environment free of interruptions, and that the plentiful availability of development equipment removes scheduling constraints previously imposed on programming.
And I am older than those two numbers and still occasionally pull the midnight oil.
One reason for the midnight oil is that the phone stop ringing, everybody else goes home, there are no distractions. Another reason is that the business demands it. Let me give you an example. There is a story that the folks at WordPerfect, which had (and still has, if my mother is any indication) fiercely loyal customers. They had a very family-oriented company culture, and nobody stayed past 5. Microsoft did not go home at five, except maybe at 5 am. Microsoft ate their lunch.
In several situations, I could not get access to computers until after the day shift went home. In Portland, while on co-op during college, I would walk to work at about 0200. The path took me past a bakery that was in full-on baking mode. While building a real-time medical data system, we had one production computer and a second computer that was occasionally used for production at night, so we worked nights to integrate both parts of production so that the other computer would be available for development all day.
And sometimes a problem will grab you and not let you go. The story of fluidics has as its beginning a 36 hour creative burst by its major contributor. And there are problems that I have worked on that have a multi-hour daily mental ramp-up.
The myth part of this is that you can get away with doing this constantly. You can't. As you say this very act should be resorted when you have no choice.
What the midnight oil has taught us in the industry is that the best programming is done in an environment free of interruptions, and that the plentiful availability of development equipment removes scheduling constraints previously imposed on programming.
And I am older than those two numbers and still occasionally pull the midnight oil.
These are two different things. One is working at night, and the other is working non-stop. I like working at night (I wake up at 1ish pm and go to sleep at 4-5) because it's more quiet.
I don't put in 16-hour days, though. There's a clear distinction between the two, and "burning the midnight oil" refers to the former. You can get the advantages of working nights without overworking.
I don't put in 16-hour days, though. There's a clear distinction between the two, and "burning the midnight oil" refers to the former. You can get the advantages of working nights without overworking.
I agree, and I think the ramp up time plus the intoxication of total absorbtion almost mandates some degree of obsessiveness that makes programmers more similar to artists than other types of engineers - there has to be peace and quiet and you have to lock into the problem and once you are locked in it is difficult and unpleasant to disengaged.
I'm not quite sure about the long-term solution. Normal family life has never been something that many artists are capable of (i.e. Van Gogh), and perhaps companies need to be more accommodating of employees that work two 10-16hrs bursts a week, rather than the normal 9-5.
Personally, I am in the "at risk" category for leaving the industry for this reason -- it is both burn out and lack of interest. I don't know, I still think there is some great code left in me, but it needs more challenging problems then I am facing at present.
I'm not quite sure about the long-term solution. Normal family life has never been something that many artists are capable of (i.e. Van Gogh), and perhaps companies need to be more accommodating of employees that work two 10-16hrs bursts a week, rather than the normal 9-5.
Personally, I am in the "at risk" category for leaving the industry for this reason -- it is both burn out and lack of interest. I don't know, I still think there is some great code left in me, but it needs more challenging problems then I am facing at present.
An interesting thing I've noticed is that burning the midnight oil works really well if I haven't been coding all day. It can work marvelously - it's quiet, nobody bothers me, the internet is asleep and I have a clear focus.
But if I've already spent the whole day thinking, then decision fatigue kills my productivity completely. Some might say I'm just tired, but it isn't related to how much sleep I'd had, just how much time I've spent thinking.
But if I've already spent the whole day thinking, then decision fatigue kills my productivity completely. Some might say I'm just tired, but it isn't related to how much sleep I'd had, just how much time I've spent thinking.
Or even worse, spent the whole day dealing with bureaucracy and mundanity and meetings and crisis management... Forget about getting any actual work done.
I once spent the night on the stern of a sailboat with 6 cans of Red Bull, debugging a Mac driver for a piece of hardware that may end up being used by Foxconn to test iPhones.
I would have been much more comfortable in the cabin but the marina WiFi network didn't reach that far.
Why burn the midnight oil? It was either that or no sailing out next morning to spend a week at sea.
I would have been much more comfortable in the cabin but the marina WiFi network didn't reach that far.
Why burn the midnight oil? It was either that or no sailing out next morning to spend a week at sea.
That just seems highly irresponsible though - you are working on adrenaline and caffeine to get a product out so you can go away and be offline for a week right after. I've been in your shoes before, and tight deadlines can warrant the need to just get shit done - but I also make sure I am around after some brief rest to handle any additional issues.
In college I used to dream in/of code. More than once I've fixed things in the hour or so that I was about to fall asleep, got up, made the changes half asleep, and went back to bed. More often than not, it actually worked the next morning.
In those days (85-90) version control wasn't a big thing with a 1MB machine, 65MB HD) but my habit of "take a manual snapshot of my current project at the end of every day" is the result of one or two failed "sleepcoding" events.
Tangent: reading the post the other day about how Turbo Pascal fit in 40kB blew my mind and brought back many good memories. I also realized I was much smarter then.
In those days (85-90) version control wasn't a big thing with a 1MB machine, 65MB HD) but my habit of "take a manual snapshot of my current project at the end of every day" is the result of one or two failed "sleepcoding" events.
Tangent: reading the post the other day about how Turbo Pascal fit in 40kB blew my mind and brought back many good memories. I also realized I was much smarter then.
I don't think it's about time/schedule but rather intensity. I would agree in that the majority of application code really is just little bits of accumulation - piling on another feature or fixing another bug. Those are things you do optimally if you're lazy, knocking off a few each day while spending the rest with non-coding tasks. And with those tasks the slow pace is beneficial in giving yourself room to examine all angles and stop yourself from a trap later on.
You only need to pull the long hours when a big impact is really needed - generally, learning something new or introducing major new concepts into the codebase. With those projects, slicing up the hours is detrimental to understanding of the problem. You still don't want to make an unnecessarily complicated solution, but long hours make necessary complexity easier to tolerate.
You only need to pull the long hours when a big impact is really needed - generally, learning something new or introducing major new concepts into the codebase. With those projects, slicing up the hours is detrimental to understanding of the problem. You still don't want to make an unnecessarily complicated solution, but long hours make necessary complexity easier to tolerate.
I don't think anyone really knows what they are going to do 20 or 25 years into the future. I like coding and expect to code for a while. But, I understand that I have also changed a lot since I was pulled out of the womb 26 years ago.
I've gone to work after staying up all night before, and produced code that looked unfamiliar to me the next day. Some of it had stupid mistakes, but on the other hand, some of it was "I wrote that?" in a good way.
Granted, I'm not writing CompSci research papers on what I do at work, so the difficulty level might have something to do with it.
Granted, I'm not writing CompSci research papers on what I do at work, so the difficulty level might have something to do with it.
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 guy.
The other parameter in this equation is Money. I am sure I can find a low stress dev job working on a project that I am actually interested in but at age 50 i don't want to be living on medium wage making ends meet. I'd rather work on a high stress job, while I am young, with a decent salary, giving it all I have and by 40 I'd have secured my future enough that I can do something else ... my two cents
>you don't choose what technologies to use
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.
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.
A contract worker with a luxury of selecting which client's projects to work on and get paid $125/hour. You realize your are the 1%. The 99% have more constraints and hardships.
I am "the 1%"? Not nearly, if you mean "THE 1%," which starts at around $350k per year.
If you just mean the top 1% of developers? Well, maybe I AM in the top 1% of developers, though I don't know how anyone could measure that. But the point is I got here through passion. And the point of my reply is that passion IS relevant to this discussion.
And that it's only not relevant to people who don't experience it with regard to programming. Honestly, I don't know if someone who doesn't experience passion can CHANGE that; you're passionate about what you're passionate about, and telling yourself to obsess about something seems like it just wouldn't work.
So don't take this as any kind of criticism; I'm not saying you're Doing It Wrong. Just that passion DOES make a difference; when you have it, you have no reason to listen to people who tell you that you'll be irrelevant and no one will hire you when you're 45, because you'll be keeping yourself relevant out of habit. Just don't claim that it's not relevant in general, because it is. Climbing to the top of ANY profession or other endeavor really requires it; the most obvious example being Olympic athletes, who typically don't start out at the top of their sport, but achieve the top by being more passionate (and therefore obsessive) about practicing.
It makes me want more terms for "programmer" or "developer" (and not including "rock star", which has connotations that annoy people). There's such a range of skill encompassed by those terms that they're practically useless, and they spawn debates like the above where people have 15 different ideas what a "programmer" is (in yours, I'm in the top 1%, and in mine, I hang out with "typical" developers, and yet a lot of people I know work on interesting projects with an option to contract). Heck, pretty much everyone at Google is in a similar situation, in that they can (typically) switch projects easily if they get bored. And there are far too many developers at Google for all of them to be in the top 1%, I think.
If you just mean the top 1% of developers? Well, maybe I AM in the top 1% of developers, though I don't know how anyone could measure that. But the point is I got here through passion. And the point of my reply is that passion IS relevant to this discussion.
And that it's only not relevant to people who don't experience it with regard to programming. Honestly, I don't know if someone who doesn't experience passion can CHANGE that; you're passionate about what you're passionate about, and telling yourself to obsess about something seems like it just wouldn't work.
So don't take this as any kind of criticism; I'm not saying you're Doing It Wrong. Just that passion DOES make a difference; when you have it, you have no reason to listen to people who tell you that you'll be irrelevant and no one will hire you when you're 45, because you'll be keeping yourself relevant out of habit. Just don't claim that it's not relevant in general, because it is. Climbing to the top of ANY profession or other endeavor really requires it; the most obvious example being Olympic athletes, who typically don't start out at the top of their sport, but achieve the top by being more passionate (and therefore obsessive) about practicing.
It makes me want more terms for "programmer" or "developer" (and not including "rock star", which has connotations that annoy people). There's such a range of skill encompassed by those terms that they're practically useless, and they spawn debates like the above where people have 15 different ideas what a "programmer" is (in yours, I'm in the top 1%, and in mine, I hang out with "typical" developers, and yet a lot of people I know work on interesting projects with an option to contract). Heck, pretty much everyone at Google is in a similar situation, in that they can (typically) switch projects easily if they get bored. And there are far too many developers at Google for all of them to be in the top 1%, I think.
I understand where you're coming from. PASSION (with capital letters) is important. PASSION for programming is what got me to get a BA and MA in computer science. It's what makes me sit in front of my computer working on side projects whenever I have a chance to. However, the point of this article and the original one is not that. These articles speak of the day to day stress loaded routine job of a regular* developer. And this is where passion (with lower case letters) is not important. My point about the 1% vs the 99% is that not everyone works for Google, Facebook ... In fact, all the contract workers I know struggle a great deal to make ends meet. We need to broaden our analysis to the sate of programming in the whole world. I am not talking about silicon valley or the bay area, which I consider to be the 1%. I had the chance of working in mid-west USA and in a foreign country and I have friends working in other countries. All I can say is that the majority of them don't want to be programming when they are 50.
Programing is power. Why do big tech companies pay $250k for basically a risk-free position to a good programmer? The key is knowing how to apply that power to making money.
When you are young you put in the hours to learn the craft. It's like any craft really, you need to put in a lot of time and effort to get good at it. At the same time you should be learning something about the world and how programming can solve problems in it. Maybe in business or something else. But at any rate, by the time you're 40 you should know how to make programming work for you. You definitely don't want to isolate yourself in a world of code without understanding how it succeeds or fails to provide ROI, otherwise you'll hit 40 and still stuck on the hamster wheel (or at best with a temporary nest egg).
When you are young you put in the hours to learn the craft. It's like any craft really, you need to put in a lot of time and effort to get good at it. At the same time you should be learning something about the world and how programming can solve problems in it. Maybe in business or something else. But at any rate, by the time you're 40 you should know how to make programming work for you. You definitely don't want to isolate yourself in a world of code without understanding how it succeeds or fails to provide ROI, otherwise you'll hit 40 and still stuck on the hamster wheel (or at best with a temporary nest egg).
I'm 43. I concur Mr. Wulf that "large scale, high stress coding" is "a stupid person's game". Now, some people find a thrill in coding under pressure. More power to 'em. Yet we see too many developers accidentally ending up in high stress coding situations and thinking that is the norm and accepting it as their fate. There is no reason it should be this way. Professional programming should be and can be fun, enjoyable, creative. As Mr. Wulf states, our profession offers an unusually wide variety of projects, tools, teams, and working environments.
Choose poorly from among this variety and you'll burn out. Choose wisely and you'll have a long, enjoyable career with plenty of extra mind and body capacity for other interests. It's up to you.
Choose poorly from among this variety and you'll burn out. Choose wisely and you'll have a long, enjoyable career with plenty of extra mind and body capacity for other interests. It's up to you.
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 career has been coworkers, within 10 years of retirement, that have just given up and no longer put in what's needed to be a coder. I enjoy the company of someone who has had more experience (it's part of how you learn) and love to hear about the battles that the people before me had to fight.
I start my day by asking myself some questions. Where is the technology at right now? Where is it going? How does it relate to my job? How does it relate to my interests? How does it relate to what I've done in the past? Where am I at as a developer? The problem is that people stop asking themselves all of these questions and start weighting towards a few in particular.
I think the one thing that I find most common in my career has been coworkers, within 10 years of retirement, that have just given up and no longer put in what's needed to be a coder. I enjoy the company of someone who has had more experience (it's part of how you learn) and love to hear about the battles that the people before me had to fight.
I start my day by asking myself some questions. Where is the technology at right now? Where is it going? How does it relate to my job? How does it relate to my interests? How does it relate to what I've done in the past? Where am I at as a developer? The problem is that people stop asking themselves all of these questions and start weighting towards a few in particular.
I'm in the middle now. I've had several opportunities to work with software developers in their 50's. Without fail, the experience was good.
Work at good companies, and the people you work with will be good.
Work at good companies, and the people you work with will be good.
On the subject of working a lot of hours, this article argues that a 40-hour work week is optimal (you don't get more done even if you work longer hours) http://www.alternet.org/story/154518/why_we_have_to_go_back_...
I would argue that in those 60 hours work week or 90 hours work week people mostly idling, staring at the screen, or browsing the web, or doing other stuff. The real work happens in much less time. Most companies equate face time in office as work and thus people just put in long hours there.
Yeah. Everyone is different. I don't have a spouse, kids or dog. I like it when I'm working on a problem and the world goes away for 10-12 hours at a time. I can get a lot of work done in a week where I work 60-70 hours. I'm sure many people can't and on average, 40 hours may be optimal but there is no way that 40 hours is optimal for me when I'm doing something interesting.
Having said that, I've also been burnt out working for startups. You can do 50-60 hours a week for many months but at some point you need a break. I've done it for 18 months but after that, I was pretty useless for several months.
One way I take a break is to work as a software contractor (which I'm doing now.) This pays well and is almost always a 40-hour per week job. It also tends to be pretty boring but it gives me a chance to recharge.
BTW, to relate this back to the topic, I just turned 50 and hope to continue writing software for at least another 20 years.
Having said that, I've also been burnt out working for startups. You can do 50-60 hours a week for many months but at some point you need a break. I've done it for 18 months but after that, I was pretty useless for several months.
One way I take a break is to work as a software contractor (which I'm doing now.) This pays well and is almost always a 40-hour per week job. It also tends to be pretty boring but it gives me a chance to recharge.
BTW, to relate this back to the topic, I just turned 50 and hope to continue writing software for at least another 20 years.
I for one do have a spouse and a child, no dog though :(
I have worked probably the same amount of hours when I was younger but due to other responsibilities that came up after I got married, I had to stick with the 35 - 40 hours work weeks.
I was recently involved with a very small shop (5 people, 3 full time developers) and it really took a toll on me. I got caught up in a project that had no end in sight and really caused me great frustration and a sense of not accomplishing anything which contributed immensely in my decision to walk away.
Right now I'm taking a long break but still update myself with what is going on in tech & programming in particular. I have always been a coder (only job I ever had) and I can't see myself doing anything else.
BTW, I just turned 50 myself. So here's to another 20 years of writing software. Cheers!
I have worked probably the same amount of hours when I was younger but due to other responsibilities that came up after I got married, I had to stick with the 35 - 40 hours work weeks.
I was recently involved with a very small shop (5 people, 3 full time developers) and it really took a toll on me. I got caught up in a project that had no end in sight and really caused me great frustration and a sense of not accomplishing anything which contributed immensely in my decision to walk away.
Right now I'm taking a long break but still update myself with what is going on in tech & programming in particular. I have always been a coder (only job I ever had) and I can't see myself doing anything else.
BTW, I just turned 50 myself. So here's to another 20 years of writing software. Cheers!
I only skimmed that article, but I don't see anywhere it says 40 hours is optimal. I only see where it says every hour beyond 40 is harmful:
"By the eighth hour of the day, people's best work is usually already behind them (typically turned in between hours 2 and 6)."
It sounds like 30 hours might well be optimal, but has simply never been tested.
"By the eighth hour of the day, people's best work is usually already behind them (typically turned in between hours 2 and 6)."
It sounds like 30 hours might well be optimal, but has simply never been tested.
You're right. Good point.
Actually it has. See Kellogg's 6 hour day
That looks like it's about round-the-clock shifts for factory workers. I can think of a lot of differences between that and, say, computer programmers that might render the conclusion less relevant.
For example, I don't know any software companies in the world that build software with 3 8-hour shifts of workers.
For example, I don't know any software companies in the world that build software with 3 8-hour shifts of workers.
I'll never stop coding. I may not continue as a professional, but there will always be the creative itch to scratch. Creative in the sense that I feel compelled to create, not that it's necessarily fine art. It's not limited to software, either. I love working on my house, I like to cook, to tinker with hardware projects. That 'click' I get from creating something is just so rewarding, and I hope that will always be true.
> Every morning I read a number of websites devoted to technology and programming to see what is new.
I looked over at his sidebar hoping to see a blogroll. Remember when people used to do that ... about 5 years ago? I wouldn't call it irony, but reading about coding at 56 while getting nostalgic for 5 year old internet practices is a strange juxtaposition.
I looked over at his sidebar hoping to see a blogroll. Remember when people used to do that ... about 5 years ago? I wouldn't call it irony, but reading about coding at 56 while getting nostalgic for 5 year old internet practices is a strange juxtaposition.
Thanks for the post. It's inspirational to see something like this. You seem to have a very good attitude about working and software development / learning and it helps me to feel better and overcome my own sometimes negative attitude. I'll be reading your whole site.
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 :(
I'm in a second-class tech job market (not in a big city, even), and my skills got me two interviews and a job offer in DAYS.
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.
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.
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".
I would argue that a company that rejects a competent 50-year-old on "cultural fit" is not worth considering unless you're desperate. That's douchey even by VC-funded startup standards.
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.
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.
Its a matter of perspective and preference. When you are young you don't mind fidgeting with things, leaning their inner working and trying to get something to work. When something is done you can point to it proudly and cry 'I did that'. As you get older you start to lose your patience with technology and sympathize with the user a little. Your perspective could be - 'Why wont this just work !'.
Perhaps it is a matter of patience. I would not know since I'm not 56 yet. OP - A toast to the fire that is still burning within you. May it keep burning for a long time. Have fun writing code.
Perhaps it is a matter of patience. I would not know since I'm not 56 yet. OP - A toast to the fire that is still burning within you. May it keep burning for a long time. Have fun writing code.
Good coding is half art, 1/2 science. During creative periods I can go on coding for hours with out even realizing it. When I work like that, I easily go through the night pulling the "midnight oil". The only difference between now (at 50) and then, is the recovery time from the all nighter. Lately I tend to be less motivated to do it so often.
Absolutely, I always refer to coding as 'creative logic'. :) The Art of Happiness At Work by the Dalai Lama and Howard Cutler is a great book. It talks about flow/being in the zone and after reading about that, I've really felt lucky to have experienced that mode of pure focus and true moment oriented existence.
I was never a person that stayed up all night coding, though. I'm a morning person and my body/mind were always like "no way". But, that being said, I have woken up many times at 3 or 4 and cranked all the way through until 7 or 8 that night. So I think it just depends on your natural biorhythms.
I'm not 50 yet, but already am finding it harder and harder to get a 'good day' of coding in with a wife and 8mo old son. Besides distractions galore, my next big loss is sleep. I definitely feel that side and I'm even having a hard time sometimes remembering things in conversation. I think of it as not having my ECC ram. :)
However, like many other postings, I will probably code until I die or until I just can't understand anything anymore. Then I'll probably just back to my 8-bit machines and assembly; the days when things were simpler. The quintessential old man out of step. Heh.
I was never a person that stayed up all night coding, though. I'm a morning person and my body/mind were always like "no way". But, that being said, I have woken up many times at 3 or 4 and cranked all the way through until 7 or 8 that night. So I think it just depends on your natural biorhythms.
I'm not 50 yet, but already am finding it harder and harder to get a 'good day' of coding in with a wife and 8mo old son. Besides distractions galore, my next big loss is sleep. I definitely feel that side and I'm even having a hard time sometimes remembering things in conversation. I think of it as not having my ECC ram. :)
However, like many other postings, I will probably code until I die or until I just can't understand anything anymore. Then I'll probably just back to my 8-bit machines and assembly; the days when things were simpler. The quintessential old man out of step. Heh.
I am curious which area the OP has been working on. I would say the work pressure is a function of the management, the requirements, and the sector where you work on. For example, mobile applications tend to have shorter release cycles, and therefore a much hectic schedule.
shorter release cycle doesn't have to be hectic; what makes it hectic is unreasonable number of features which is poor planing. You will end up coding 24/7 in cycle of any length if workload to deliver all in given time frame is greater than what you can deliver working only regular hours. That is poor planing regardless of sector and length of release cycle
Boy, if I could make it to 40 that would be a doozy. I do wonder if programming will be obsolete in a few decades and if the things we've programmed will start programming us. Well, I guess they already do in a way.
My dad is 49 and he still works on projects till 11-12 in the night. Ask him and he always says 'I am doing a build, no idea how long will it take'
I have been coding since I was 11... I am 23 now. I cannot imagine a different outcome for myself.
I read that as someone who really wasn't able to continue being a chemist into his 50s.
Are unpaid overtime common in the States?
"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 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).
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).
People who want to be coding at all should follow this advice.
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
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
I mean I was really into this image when I was 20. Now, after had some experience in the field I see that, this very act should be resorted when you have no choice. If you have a tight deadline and all you have to do is code, I mean not think and code but just code - no abstractization is involved, this works. But if you have to plan-code a project this approach sucks. Because you get tired as the night progresses and tired minds do make mistakes. A lot. So while the bugs coalesce you go into smart fixes. Because it has to end tomorrow, right? Then when you return to your code one week/month/year later you'll say: - What the heck have I done here?!
Resting is as important as coding for a coder IMHO. No need to burn ourselves out for a myth. And yes I want to do it when I am 50 or 60.