Smart Guy Productivity Pitfalls (2013)
bookofhook.blogspot.com
bookofhook.blogspot.com
>I still screw off during the day. I am not a code grinding automaton. I read Facebook, chat with others, Tweet, shop on Amazon, get coffee, read forums, write blog posts like this one and I'm totally fine with that.
I know people who produce less code but outperform on many more important metrics (salary, title, being valued at the company, whether they make their company more likely to succeed)
Here's a hint: https://www.linkedin.com/in/brian-hook-3743861
Were you to apply the mentality of "get work done productively" to other domains such social / mobile, IT, or ecommerce, you get a different approach, which is exactly what you described: taking an 80/20 approach of coding and designing, optimizing for team productivity rather than individual.
Unfortunately, most of us are just happy with our performance. We are having "meh" performance and then we look at others that achieve things and we think its luck and good timing.. While there are cases of luck/good timing, in most cases people spit blood, coding/hustling endless hours, pushing themselves constantly, being modest about their knowledge, being methodic and efficient. And the best part is that they are like pigs in mud, they enjoy it to the max. Even if everything failed, they would still emerge with a sense of achievement, just like kids playing with legos.
This is what the take away from this article should be, choose your path and execute like a boss. You are not a snowflake that can do things in 1 hour vs. 1 week, you are a spoilt kid thinking you are awesome, ending up wasting your true potential.
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 need 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.
But there is this nagging sensation that you could do more.
And it’s true, and that’s what this article talks about.
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 be Carmack and not themselves.
Of course, the magic is figuring out how to get as many of the benefits with as few of the drawbacks.
The best take away for me is to have a good measure of productivity and I think 'pausing the CD is a great idea.'
20 years ago it was all people trying to maximize. Now it’s about people wanting work life balance and such.
My alternate theory is that pretty much only really dedicated developers were in web forums in the 90s so it was a lot of self selecting. Now the industry is much larger and the Internet is the default and everyone is online.
Also if he doesn't get his work done, he skips his fitness (ju jitsu) training and works instead? Does he think this is actually a healthy attitude?
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.
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.
So much code no matter where you go will be something like this. You'll have to make something work even though all the code surrounding your feature is a dumpster fire that is so hard to predict, that you'll pull your hair our worrying about all the ways your feature will break.
When I get to build a new system from scratch? It's a breeze! I get thousands of times the amount of work done in the same amount of time.
That's one of the reasons why I don't like working on UIs. The code tends to be messy. I often have to test in environments like IE for Windows. And I don't actually care about how things work as long as they work.
That happens sometimes. It is then that I remind myself how much a I make a minute plow through it.
You know what's pretty hardcore? Thinking that going to the bathroom is essentially the same as fucking off.
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.
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.
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’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 suspect a good metric to use here is how valuable you perceive your collaboration time to be. i.e. if all your collaboration time was highly valuable and productive, you wouldn’t feel a need to change your balance.
Thus, I’d suggest looking for ways to increase the value of collaboration time. I wonder if your issue stems from simply being more productive/experienced than your peers, which could give you the sense that collaboration slows you down.
And I did. And it was hard as hell. But I graduated and for the first time I really felt a sense of personal accomplishment. I hadn't finished college because someone told me I was supposed to, I did it because I wanted to.
Once I left college and I got to work full-time in my field of choice this lesson paid dividends. When I have a problem I really enjoy trying to solve, the hours can melt away. When I have a problem I really don't want to solve, I can still sit down and force my way through it. And don't get me wrong, my brain still fights against me in those moments ("Hey guy, go check Hacker News or Reddit!"). But most of the time I am able to recognize when it is happening and reign it in as necessary.
Gains in focus time (for me, anyway) are incremental, so it’s not like you wake up one day and can focus for 12 hours straight. Accept that it will be a slow road, and just keep trying to stay focused longer, whenever you sit down to work.
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.
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.
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.
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.
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).
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.
On its own I'm confident that won't work because it's not new money, but funnily enough I have a deeply rooted scarcity mindset (I constantly think I'll wake up one day and won't be able to generate another penny), so maybe it would work in the end if I gave myself a no strings attached "reward fund" for completing tasks.
Some type of weird permission to spend X amount per month on non-essentials. I currently live so below my means that it would probably be comical for most people as an outsider.
That by itself is not the problem. It is a weight on your productivity, sure, but the real problem is if you watch 2 hours of YT videos and don't come off in a better mental state to do the work you slacked off on. I find that what helps me the most is finding the most "productive" ways to slack off, so you're not just avoiding thinking about work, but are actively recharging. So, pick your slack carefully and it should be less of a problem, maybe even a positive part of your work routine.
It all boils down to bad habits and broken mindsets. There's that old saying of if you want to get something done, ask the busiest person in the room to do it.
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.
I like the idea that the reward of work is satisgsction with the outcomes rather than non work recreational perks.
I see that more as decoration to make the place look cool
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.
2. Think about maintenance - write clean code, keep it simple, and write tests (or at least write testable code).
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.
And sometimes I could, so, hey, validation!
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.
I've been the person not liking the accountability in the past as I've struggled with very 'bursty' productivity and so the original article resonated with me. I've also come to appreciate the accountability as the parent commenter has.
The reality of scrum is so far divorced from its claims it's a joke. Scrum is anti-agile, the antithesis of every agile principle. It's managers micro-managing their staff.
Fundamentally it's process and tools over individuals and interactions.
I think what is missing is the exploration of how thinking of ourselves as "smart guys" makes us worse 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.
Study after study shows that a growth mindset leads to better outcomes: programming should embrace it.
One thing I'll say is that it might not be for everyone. I attempted to show several people how I use org mode to organise myself and quite a lot of people are uncomfortable organising themselves. They seem to get distracted when they think too much about what they are doing and have trouble maintaining their concentration. It is actually the opposite for me. If I don't have my notes, I'm off thinking about what I want to have for dinner, how to save the world, wondering why you can't make a hard cheese from yogurt, etc, etc. Speaking of which... time to go to work...
* - In case you were wondering, pizza, you can't but you can do your best to make it a bit better, and you need rennet to split the kappa casein from the casein micelles in order for the casein micelles to stick together using dissolved calcium and phosphate -- yogurt solidifies by reducing the pH to the point where the casein is at it's ioselectric point (pH ~4.6) and it can glob together (but never as tightly as if you remove the kappa casein).
We all know people who are allowed to coast solely because they're friendly with a lot of people in the office. Many employees depend heavily on this halo effect, and expect to be able to wink and nod their way out of what is sometimes sickening incompetence -- and the kicker is that much of the time, this works well.
It's psychologically easier for people to trim non-productive remote workers because there is no physical absence to miss, and the people in the company are less likely to have a deep personal bond forged over years of lunch breaks and the like. It's a purer professional context, at least as far as our profession is concerned.
Declaring yourself a remote worker is a declaration that your work product stands on its own as a representation of the value you provide, and that you don't need to depend on niceties like "he tells really funny jokes by the water cooler" to stay employed.
http://bookofhook.blogspot.pt/2013/03/smart-guy-productivity...
You are old a long time. Don't waste your youth on stuff that will be forgotten by the end of next year.
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.
Speaking of which, harray for HN! Billing R&D for this comment.
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.
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.
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.
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.
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.
underachieving is a symptom of work input not correlating to pay output.
why work more if you don't get rewarded for it?
for the joy of work?
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.
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.
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.
that isn't even fully up to you, at the end of the day. hence why "underachieving" is the norm.
hard work is not correlated to getting paid.