Yes I Still Want To Be Doing This at 56
thecodist.com
thecodist.com
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.
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.
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.
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.
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'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.
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.
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.
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.
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 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.
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.
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.
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.
Work at good companies, and the people you work with will be good.
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 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!
"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.
For example, I don't know any software companies in the world that build software with 3 8-hour shifts of workers.
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.
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.
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.
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.
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.
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).
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