You sound a lot like me now. I'm a typical "work hard play hard" twenty-something, and if it was possible for me to be working smarter, I don't see it. I probably spend my first 40 hours solving/understanding the problem, and the next 30 hours refactoring the code to look like my mental model of the solution. I'd love to slow down but it's just doesn't seem possible to ship a high quality product given our schedule. Some of the senior folks work saner hours, but it's not at all obvious if their output is higher quality than mine, or even equal quality (this isn't a slight--i'm getting twice as much zone time as them!). If they're 'working smarter' than me, I can't see how, other than having already paid the learning curve for a large class of problems.
Can you give concrete examples of how you work smarter now, compared to your twenties?
Right out of college, I tended to prefer building things on my own, rather than using existing patterns or frameworks. I did this partly because I wanted to learn the "fundamentals", and partly because I was arrogant (or stupid, some probably said).
One day, a senior developer gave me a book on design patterns. I was floored. I started applying them and found the quality (and maintainability, reusability, etc) of my code increase tremendously.
Over time, others have given me more tips on improving my efficiency. From something as simple as learning keyboard shortcuts and customizing an IDE's UI, to unit testing and handy shell scripts, I found myself saving a lot of time.
Of course, you may be doing all of these things already, in which case, you may already have a pretty optimized work technique already.
On a managerial level:
I'm a believer that if you put the right team together, 1+1=3. So my value has shifted from being an individual software developer to someone who can put together teams of developers insanely smarter than I am, then remove all the roadblocks out of their way so they can build great things. I still write some code, but while my value as a developer has dropped tremendously, my value in managing a team of developers means our overall output is greater than the sum of our parts.
In other words, I increased my "value" by becoming a manager. Of course, that kind of a role change is not for everyone, but that's what I did.
Another example is one of prioritization. Sometimes it's only realistically possible to do X units of work a day (let's say 10 units), and sometimes a person is asked to do Y units of work a day (let's say 30). That means 20 units aren't going to get done; it's just not possible. Trying to squeeze in more would result in a lack of quality (due to lack of sleep, exhaustion, etc). So what can one do? Do the most important 10 units first. It sounds pretty obvious, but in the heat of the moment, I sometimes found myself wanting to do the 10 easiest units first, not the 10 most important. Proper prioritization made a big increase in the quality of my output as well.
> One day, a senior developer gave me a book on design patterns. I was floored. I started applying them and found the quality (and maintainability, reusability, etc) of my code increase tremendously.
Careful with that. The purpose of design patterns is to give a name to something you already do, not to find new things that do that aren't needed (cough Spring Framework, J2EE). I am sure you aren't doing that, just wanted to make sure the messaging is more clear.
The Design Patterns Book didn't initially help me when I started programming. However, after working on several substantial Java, C++ and Perl projects I've picked it up and again and was able to identify what I've done and what the standard libraries I use do: "oh, java.util.HashSet is an adaptor bridge from from a hashtable data structure to the Set interface" or "boost::graph uses visitors to implement multiple dispatch based on different edge/vertex types". Now, I'll often make sure to use standard design patterns for my APIs when possible (e.g., Iterator interface, rather than accepting an anonymous classes/function objects if all I want to do let them lazily stream data one at a time).
> The purpose of design patterns is to give a name to something you already do, not to find new things that do that aren't needed (cough Spring Framework, J2EE) ...
> Now, I'll often make sure to use standard design patterns for my APIs when possible (e.g., Iterator interface, rather than accepting an anonymous classes/function objects if all I want to do let them lazily stream data one at a time).
You're absolutely right. Thanks for catching that!
Can you give concrete examples of how you work smarter now, compared to your twenties?