I could not disagree more with this article's tactical advice (though the intention is great). If I could go back in time and tell myself anything when I first got into engineering it would be "Be sure to take at least 20% of your day to not code, but rather to think about / engage with / socialize with others. Do not optimize for personal output, you will help the system most by improving the system rather than executing 25% more. And you can't improve the system unless you learn the social graces, speak the lingo, are in a good mood, appear patient, and aren't counting all the seconds that are 'wasted' by these interactions"
I think a lot of this comes down to what you want in life.<p>In my experience, if you’re a reasonably intelligent and experienced software engineer, and make some smart choices about where to focus your effort, you don’t <i>need</i> to put in much of that effort to live what most people would consider an enviable life. So you do that, become envied, get the validation, and feel generally pretty good about yourself.<p>But there is this nagging sensation that you could do more.<p>And it’s true, and that’s what this article talks about.<p>And underlying that, I think it’s important to look at the tradeoffs, and make a conscious decision about your life goals. As awesome as Carmack is, I’ll bet not many have sat down and thought about what it would be like to <i>be</i> Carmack and not themselves.<p>Of course, the magic is figuring out how to get as many of the benefits with as few of the drawbacks.
I often find myself slacking when I have to write code I am ashamed of.<p>Writing new stuff from scratch is fun, I have zero problem being motivated to code things that are hard or challenging. And I can keep focusing for a long time.<p>However, if my task is to shoehorn some code that I know to be crap into my project for x or y reason, oh boy, then I can drag my feet for a looooooooong time.
<i>I distinctly remember him saying "So if I get up to go to the bathroom, I pause the player".<p>You know what's pretty hardcore? Thinking that going to the bathroom is essentially the same as fucking off.</i><p>This seems like it might be one of those times when the person doing the speaking is being interpreted to say something he didn't mean to say.<p>The author seems to be coming from the direction of "count the time you weren't working as unproductive time in the day", while it's unclear from Carmack's statements (the subset referenced in the article, at least) whether he was considering that at all.<p>For an alternative perspective, consider that Carmack might have tracked the time he actively spent programming, and used that to measure commits or lines written/changed over time. He may not have minded the occasional interruption to clear his mind and reset. This changes the tone considerably, from one of "ruthlessly cut out 'unproductive' time" to something like "track your productivity when you're working to spot trends", and all it takes is looking at the situation from the other direction.
I am continuously grateful that twelve years ago after dropping out of college with a complete lack of focus I came back a year later and learned how to <i>actually</i> work hard. Outside of food and bathroom breaks, if a problem demands it I can work for hours on end without breaking focus (and love it!). It’s one reason that open office floor plans or a culture of interruption are absolute hell on my quality of life.<p>I’ve struggled at times though to figure out how to balance the need for off the cuff collaboration with teammates with the productivity that comes with isolation. I settled for what I estimate as a 40% loss at my last gig because it helped boost my teams’ overall productivity and improved the quality of our product. Having thought about it recently, I believe my ideal would be some kind of on/off cycle. Say, two days a week either remote or “quiet time” at the office, and three days anything goes.
I really liked this article and it's eerie at how I had those same productivity issues and ended up doing things similar to Carmack to track productivity.<p>Carmack used the CD player tactic to track his productive time, but a few years ago I used a schedule. I charted out every minute of my life. Every single time I context switched, I wrote down what I just did previously and for how long.<p>After doing that for a bit you begin to realize just how fucked up you are when you see a daily recap of "checked HN 25 times, checked email 20 times, watched 2 hours of Youtube videos unrelated to your field" and you barely inched forward on whatever you're working towards.<p>I found real deadlines really helps me. I mean, I had my next video course idea in my head for almost 1 full year and I kept putting off doing work towards it because I was getting small wins doing other stuff which prevented me from even starting something new.<p>Then someone hired me for freelance work and it just so happens what he wanted done matched what I wanted to do in my course almost exactly. It took me literally 20 hours (3 solid "no messing around" work days) to write about 85% of the material I wanted to do in the course. There's a lot more than just writing source code to finish a course, but that was something I managed to put off for an entire year but nearly completed it in a few days.<p>I don't know why, but when someone pays me to do something I shift from being a sloth into a hyper focused productivity machine. I haven't found out how to harness that power without external motivators and I've been at this for about 20 years (I work for myself, so I don't have a boss paying me).<p>I used to think I was never so stupid to have some type of fear of success but deep down I'm constantly battling my inner self on the topic so I'm beginning to think that maybe I have serious issues around that.
I love this post for celebrating hard work.<p>It feels like so much Silicon Valley culture is focused on giving programmers distractions at the office that are not work, like foosball tables and ping pong.<p>I like the idea that the reward of work is satisgsction with the outcomes rather than non work recreational perks.
How to be productive in two steps:<p>1. Use the right tool for the job - pen and paper when the idea is new in order to nail it down, then code later once all the obvious pitfalls have been ironed out on paper first. It's amazing how going through a few use cases can drastically speed up development time instead of just diving straight in.<p>2. Think about maintenance - write clean code, keep it simple, and write tests (or at least write testable code).<p>This article seems to suggest that you should work all day, consider toilet breaks as non-productive, and skip over exercise if you don't get your work done. A great plan if you want to work yourself into an early grave.
<i>If my coworkers were grinding through stuff that took them 20 hours, I'd be all "I work smart, not hard" with accompanying snarky eye roll, and I'd assume I could bust through an equivalent work load in four hours and still look like a goddamn superhero.<p>And sometimes I could, so, hey, validation! </i><p>This was me for a lot of years, then like the author I joined a really high performing team. Those guys (all men) cranked out a lot of code. I even told my wife, I wasn't sure if I could keep up. I really had to up my game, but I did find a lot of their code really wasn't the highest quality and they tended to write more code than they needed. I learned a lot from the situation, and every team since has been even more low performing. It makes it really easy to excel in the typical, Dilbert, Fortune 500 development team.
A lot of people hate it but I actually find the daily standup a good motivator to help getting shit done. The desire to be able to report something the next day helps keep me focused.
The advice is not all bad. I certainly agree that slicing a problem into small, concrete steps that can be achieved in less than a day (and then less than an hour, and then in the next five minutes...) as one of the central skills a programmer needs to develop.<p>I think what is missing is the exploration of how thinking of ourselves as "smart guys" makes us <i>worse</i> at our jobs. Intelligence isn't a substitute for being a good programmer. Churning out lots of useful, dependable, maintainable code involves a large body of acquired skills, habits and knowledge. When we pretend what matters is how "smart" we are, we get defensive when we get advice that we could do better, because "what, are you calling me dumb!?!!" We also blame other people's mistakes on their lack of intelligence, instead of considering how they could learn or how the system could change to better support them.<p>Study after study shows that a growth mindset leads to better outcomes: programming should embrace it.
I tend to think all the time in a coding problem, even while eating, going to loo, sometimes even in dreams. There is no bigger problem solver than a walk off the cold white screen. So productivity cannot be really measured in keyboard time.
I've been writing code for long time. No tool or methodology has helped me to become more focused, organized, productive and predictable as Org-mode. I do not start a task without clocking in or starting new org-pomodoro cycle. I take notes whenever I encounter a problem, get an idea or discover something new. Every morning I read my notes from the previous day, check how I spent my time. I'm not the smartest developer in my team nor the most productive. However, without Emacs and org-mode I don't think I would be even working in the same team.
Biggest take away here is that working hard pays off. Not a huge surprise, but it does seem like our industry has forgotten that. The increasing acceptance of allowing remote work is a contributing factor. Many remote people are great, but not everyone should be allowed to do it.
I started running RescueTime in the background on my work machine, and I like it as a reality check mechanism. It's not enforcing anything or firing off crazy alerts if I get off task, it just silently records. Then at the end of the day/week/whatever I can see how much of my time was productive vs unproductive.
My productivity hack is to disconnect from the Internet. Being extremely focused and isolated can mess me up if my work requires external feedback. I can go way off on the wrong tangent. But, if I know precisely what needs to be done, disconnecting is the way to go, for me.
If you're struggling with scrolling on a desktop, use the desktop link:<p><a href="http://bookofhook.blogspot.pt/2013/03/smart-guy-productivity-pitfalls.html" rel="nofollow">http://bookofhook.blogspot.pt/2013/03/smart-guy-productivity...</a>
I always work with a picture of my gravestone in front of me engraved with the immortal words "I wish I'd spent more time at the office"<p>You are old a long time. Don't waste your youth on stuff that will be forgotten by the end of next year.
For anyone who is interested, here is a nice app for productivity boost - <a href="https://www.rescuetime.com/" rel="nofollow">https://www.rescuetime.com/</a>
This is a great article, that I think can also be useful from manager/supervisor point of view.<p>I think 'mechanical' solutions can also help. I have been lucky that over the years when I felt like "slacking" instead of news or media, I would read technically relevant articles, or discussions.<p>Speaking of which, harray for HN! Billing R&D for this comment.
I would be coding now except that I'm travelling in Japan and have not figured out how to replicate my usual "visit Starbucks" pattern yet - they have cafes but not with power outlets, generally, so I have gathered that coming to one tends to mean phone or paper work only.<p>What I have noticed about my coding habits is that I need a cyclical approach. For a lot of features the task is in fact smaller than I think and just needs an initial direct attack. When it isn't, even if I know what has to be done additionally, I can usually add a stub in the right places and fill it in iteratively. Stubbing often breaks me out of experiencing friction.<p>This works up until the relevant code stops fitting in my head. Then productivity slows to a crawl and I'm far more likely to wander off. I don't have a direct solution for that. Rewriting the module in question sometimes works, but it seems to work best after I let the existing code "mature". The rewrite tries to preserve the inner parts while changing the context to unlock some more potential.<p>And there is a hard limit on what I can do before my brain shuts down. There is an aspect of training to it, and energy conservation too. Familiar problems are easy to spam out high quality solutions for - pages of code that just work on the first try. New ones need an R&D phase where the first few attempts reflect a shaky, uncertain approach. At a higher level of evolution - more edge cases, synchronization logic, and state to track - the code tends to require more activation energy, which compounds slowing productivity.<p>So I currently think explicit iteration might be key: when activation energy feels high, do maintenance work, and if you can't find low-hanging fruit then it might be the right time to do an architectural change(not rewriting the whole program, but changing up the menu of modules and dependencies to reflect current needs). This is especially true if the overall design goals changed along the way because it's hard to change course after you built the features. New designs = new modules.<p>All of this is a bit different from the work-ethic mode of the article, to which I would point to physical training as the model: You don't go all-out on your training every single day, unless you're a pro with trainers and a good drug regimen that can optimize the recovery time/progression ratio. A more reasonable goal is once or twice a week to push yourself on something you can track easily - lift numbers, time/energy, etc. The rest of the time all goes to recovery or a basic level of maintenance. Distractions during the day mostly reflect wanting to have recovery time, but not having it instituted in a fashion that would do so efficiently - nobody teaches brain work as a thing that needs any kind of rest and recovery period, but the fact of the matter is that making many precise decisions is tiring, high energy stuff. Lowering the precision to "only add stub code right now" is both lower latency and helps conserve energy. Likewise the tendency of code to progress from visual mockup(feature reports itself as working and maybe surfaces an interface but doesn't use the "real" data structures) towards an optimized algorithm reflects an approach of energy conservation.
hm, i like a lot of the author's suggestions, but they're missing one big piece of context.<p>underachieving is a symptom of work input not correlating to pay output.<p>why work more if you don't get rewarded for it?<p>for the joy of work?<p>sure, but then you are getting taken advantage of because you are putting more effort in than the company is paying you out. if you notice jobs that rely on the "joy of work" to get people to do them like science and video game development, you will find that wages are fucking awful for the effort that is put in.<p>and let me share a secret: that is 100% of the time going to be the case no matter what you do. they don't hire you for your own benefit, they hire you for their benefit. you get the scraps, even if those scraps seem like a lot of money to you. do not be naive about this because ignorance is to your immense detriment.<p>but let's say someone wants to be promoted. you might have to work hard to get promoted (assuming your social skills aren't enough -- they're far, far more important than actual productivity/quality) but you still probably don't have to be busy 100% of the time. you just need to produce X% more quality or volume than the next best person. greater values of X might get you noticed and promoted sooner -- maybe.<p>that isn't even fully up to you, at the end of the day. hence why "underachieving" is the norm.<p>hard work is not correlated to getting paid.