You can't always work smarter day in day out, and expect to beat someone who is both smarter and willing to put in more hours.
> when I hear comments like "work smarter rather than just
> putting in more hours", I wonder if that's not just
> rationalization for simply not wanting to work longer hours
> because people in that age group generally have other life
> obligations, and eventually become overpaid and
> uncompetitive status.
Working smarter generally means planning before writing code, thinking about how one's work will integrate into the larger system and how to make that code reliable, maintainable, and extensible.
It also means picking your battles and directing effort where it will count.
With experience coders learn that endlessly coding generates errors and shortsightedness. Sure, there is a small percentage of coders who can code error-free for much longer than most, but most coders will be most productive when keeping to a regular 40-hour work week. And even super coders are susceptible to burnout. [1]
[0] http://www.igda.org/?page=crunchsixlessons
[1] http://www.alistapart.com/articles/burnout/
EDIT: format link list.
I have a largely different opinion on this, working smarter just means doing the right thing instead of the wrong thing. I realize that is vague and I think the reality is vague here. Investing the time to write 'reliable, maintainable, and extensible' code is the right thing to do when it's the right thing to do, it's the wrong thing to do when the it's the wrong thing to do. Being older shouldn't mean that you always write 'reliable, maintainable, and extensible' code, it should mean that you realize when it's warranted and when it is not. My experience is that this isn't the case, 'older' coders (and I safety quote older because I'm not convinced that age is the true differentiator) tend toward 'reliable, maintainable, and extensible' at all costs. That just isn't the right answer all the time. I'd venture a guess that some of the stigma that exists about 'old coders' is related to this.
- do the thing - do the right thing - do the right thing the right way
if you don't understand the benefits having some 40 or 50+ year old devs on a team brings - watch some Jim Weirich videos
As others have pointed out, working longer hours is actually counterproductive. The 40 hour work week and paid vacations were not introduced out of kindness, they were introduced because employers found out that they actually improved overall productivity.
However, particularly in highly cognitively demanding fields, even 40 hours is likely too much, actual productive work is more around 20-25h per week at best. If you try to do more, you will accomplish less.
> eventually become overpaid and uncompetitive status.
Yes. If you continue to do the same things in the same way, you will definitely be uncompetitive. As you grow and grow older, you should be accumulating at least knowledge and hopefully a little bit of wisdom.
As the old joke goes: "One chalk mark $1; Knowing where to put it $49,999."
Meaning you have to find ways to leverage your hopefully increasing abilities to shift into jobs/roles where you provide more value. Like bringing architectural oversight to teams/projects, mentoring, answering questions. If I can prevent a more junior developer from spending a day or two chasing down a blind alley by giving a couple of minutes of advice, that's pretty valuable. And scalable, because I can give a few minutes of advice to a whole bunch of developers over a given workday.
Or if I manage to introduce an architecture that reduces code by say 50% while at the same time making the code simpler, I've just doubled the team's productivity, with likely more compounded savings in the future.
https://www.wikiwand.com/en/1835_Philadelphia_general_strike
I knew plenty of younger developers who spent nights/weekends doing proofs of concepts they could show at work.
It did make them look better more competitive than other people who just put in the hours.
I spend a lot of time doing side projects just to stay competitive.
I learned a lot from him and never doubted him on this fact. Unfortunately I've also worked for younger bosses who have yet to make that connection.
No it's not. As someone who's had 10 jobs by the time I was 25. I can attest that.
You can be 10 times more productive by picking a solution that achieves the same for 10 times less effort. And that's what you should do all the time.
Whenever you take wrong decisions (let's call that "the design phase"), you have to compensate by doing 10 times the work down the line.
That's where the experiences come in. Whatever you have in mind. Already seen it. Already done it.
In practise, that means I could play ping pong 4 days a week and still be more productive than most people, because they will do work that require a week to be done, while I will do work that require only the last day, to achieve the same result.
The downside is that it's getting boring and irritating to see other people trying to tackle the job in a way known to be wrong (which they can't realize because they don't have the experience).
Unless you are surrounded by sea of incompetent workers, I find it hard to believe that one can be 4 times more productive than most people, on consistent basis.
Has enterprise software development become so narrow in amount & scope of assignment given to one person, that quantifying your productivity relative to others is actually possible?
While in some very constrained, straightforward coding challenges it might be hard to find orders of magnitude improvement, a lot of designing software has a huge range of solutions. It might be the case that a single org doesn't get to compare.
My Monday's afternoon: Read hacker news all day and eat ice cream. Thinking about what to poc next (of course, that counts as work).
Coworker Monday's afternoon: Tried to migrate a thing in place to get the new improvements. Didn't make a backup. The update failed and fucked the system. Stayed until 8pm to un fuck it. (Then we'll have to continue restoring it fully tomorrow).
See. He's worked full time and overtime already + many hours lost (for both of us) because we had to fix shit in emergency + many hours lost by other people who are impacted.
That's a ton of overwork and negative productivity. I could eat ice cream for half the week and still be significantly more productive than that.
P.S. This example is for toying around with production systems, it's easy to understand and evaluate. We can do examples with bad design decisions that destroy the project and are 100 times worse :D
That's not unusual in my experience. I've gone down the wrong path a few times, but I'd like to think I've suffered enough to think twice now. Let's call that suffering "experience."
Or people typing in "google" into google's search box? Or how it feels watching someone copy&paste data in Excel instead of using a simple formula?
That's what's happens on a software architecture level as well.