Hacker News new | past | comments | ask | show | jobs | submit login
Smart Guy Productivity Pitfalls (2013) (bookofhook.blogspot.com)
319 points by andreaorru on Mar 6, 2018 | hide | past | web | favorite | 84 comments



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 read the article as speaking more about (1) developing a disciplined mindset, and (2) applying that to coding in the context of game development. For me, the article is a reminder that productivity is a mentality and commitment, rather than a metric.

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.


I think this is up to interpretation. Optimizing for output could mean "improving the system", polishing your soft skills, rather than spending that 20% learning how to code in assembly. On the other hand maybe that assembly knowledge would have lead to creating something that would make others more productive, and end up saving years of combined humanity productivity. It is entirely up to the human in question on how time is utilized.

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.


From the article...

>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'm not sure that was what the article was suggesting. I didn't read the advice as only being directed towards the production of code (though I'll admit that that was it's focus and I didn't read too closely) but rather the setting and completion of set short term goals which may encompass affecting social, bureaucratic or systemic change.


Think the author said he was spending 80% of his day not coding, and was spending too much time on reddit, facebook, twitter, etc. Though the article certainly would have benefited from a mention of the benefits of coming up for air (he mentioned email as an unproductive task, which I certainly wouldnt agree with)


Sites like reddit, Twitter and Facebook are more like feeding a dopamine addiction. It's not really a healthy break to take. Taking breaks is good if you go for a walk, talk to a co-worker, meditate, grab a coffee, do some stretches, go to the gym. Breaks are not good if you're getting your dopamine hits on various fun websites. I mean they're fine as long as you mentally treat them like having a beer or launching Steam and playing a game for a bit. Should you be doing those things at work instead of getting your work done and heading home? Probably not.


Brilliant, had always lumped those together. But it is easy to end a walk.


You're probably not the audience, then. Some of us can really identify with it and have used these kinds of tips to help our focus. I've never been a 60-hour-a-week (let alone 80) kind of guy except when things are absolutely emergency on-fire. I have a very healthy work-life balance which REQUIRES discipline when you're actually working.


and if it were me it would be the absolute opposite.


No offense, but compare your GitHub profile to someone who "grinds" like https://github.com/bketelsen. There is far too much confirmation bias in regards to work-life balance and ability to actually produce. As far as clichés go, I believe that "if you do what you love, then you don't work a day in your life" == productivity.


In what world do you live in where you can judge someone's productivity by a public github profile?


Only clueless hiring managers assume that a lack of activity on Github means a lack of productivity.


I'm not sure that's the right comparison, and it illustrates my point. The correct comparison is how much we help our companies, not how much code we output.

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)


You REALLY should look into who the author is...

Here's a hint: https://www.linkedin.com/in/brian-hook-3743861


Wasn't about the author--I totally agree with author. I was replying to the top commenter, who seemingly is a software engineer and disagrees with the author. I think if anyone has read the history of Carmack, Carmack would agree that productivity is all about incredible focus and his amount and quality of code he output would be his measure of success.


I think a lot of this comes down to what you want in life.

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.


To me, the article is more about the delusion of how productive some people think they are. It's one thing to know that you really put out 2-3 hours of good code and be satisfied with it. It's another to think I've worked 10 hours a day while being distracted by Slack and surfing the web.

The best take away for me is to have a good measure of productivity and I think 'pausing the CD is a great idea.'


There’s another delusion around spending 20 hours on the wrong code and declaring success. You were efficient but not effective.


Yeah it's all trade offs, the OP mentions he works until 8pm at the end of the article; I wonder what social life that leaves for after work exactly?

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?


For someone in search of the almighty self imposed productivity metric, in sure it seems healthy. But for the rest of us, it's stupid.


Its been an interesting change over the last decade. Programmer oriented forums used to be all about becoming a super coder. Now inevitably 50% of the time there will be a comment saying, "You know you really could get away with caring less". I suppose that's true - but then why even read the article.


We’re all secretly ambitious, but get beat down by being assigned to building CRUD apps. :-)


I fear that there’s some secret forum where are all the supercoders live and I’ve been left behind because I’m too dumb.

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.


The industry got older. There was a massive growth on at the late 80's and earlier 90's, but although the number of people on IT kept growing, it is much slower now.


I agree and working at a place like id Software is definitely not the place to get complacent. Lots of big enterprise companies are totally fine with that type of work though and you can easily get through your whole career without ever working super hard - or maybe you work hard when you start, get kinda burned out and then don't anymore.


I often find myself slacking when I have to write code I am ashamed of.

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.


Having to wade through code I hate has the same effect on me. Doubly so if I have to test it in an environment I hate. Triply so if I am trying to accomplish a goal I don't care about.

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.


> Triply so if I am trying to accomplish a goal I don't care about.

That happens sometimes. It is then that I remind myself how much a I make a minute plow through it.


This. 100%! I find whenever I have a career crisis, or lack of motivation, it is because of this right here.

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.


So much irony here. Some other poor soul has to come along and procrastinate fixing your old code because you didn't want to and moved on to some other company.


True, but not a decision of my own making. I'm talking about times where I explicitly recommend a refactor to get things in good working order, but I'm forced by my manager to not do that, and instead get it done ASAP.


If only we could build all own systems from scratch. I guess I'd be lucky to finish a working terminal emulator, editor and shell in my lifetime, and maybe a window manager as a stretch goal.


Ironically, you then leave and someone else has to pick up your old code - or offer to build a new system from scratch. So the cycle continues.


This is me right now. I want to work on more go projects but I need to complete this legacy backbone javascript project that hasn't been touched in like two years....The code I'm working on right now is pretty notorious even to other teams.


Oh man I feel your pain. I spent so much time working on a Backbone project wondering what the purpose of all that MVC structure was, and I still don't know.


I am the exact same! Also, if it is some mindless donkey work that is pulling out modules from certain places and refactoring it just so as to fit with a new pattern, I procrastinate, waste time on the internet and question the meaning of life. But if it's a challenging problem, or even writing code from scratch, I will bulldoze through it and finish stuff super quick.


Amen! Especially when there's so much technical debt that you can't predict whether you'll need to fix two or five unrelated issues before you can accomplish what you originally set out to do (if you can still remember what that was by the time you get there).


I distinctly remember him saying "So if I get up to go to the bathroom, I pause the player".

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.


Not likely. Carmack did a write up of a recent vacation: https://www.facebook.com/permalink.php?story_fbid=2110408722...


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 actually 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.

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’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 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.


How did you learn to work hard without breaking focus?


I'd say it was an unintentional lesson in the merits of grit. When I went back to school my attitude towards my non-computer science courses did not change -- I still very much disliked them. However what did change was that I decided I was going to graduate no matter what. It didn't matter how I felt or how much I'd rather do something else, I was going to study and graduate.

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.


As someone who also had a longish path to learning to work hard, the answer for me was simple: practice.

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.


When I see people comment that they can only focus on code for a few hours, I feel like a freak. I can focus on any one thing for 16 hours per day, indefinitely. I don’t know why. I don’t use tricks. And it energizes me. I have very low social needs. I doubt I’m neurotypical. I doubt John Carmack is.


Virtually everyone I've met who has tried it says that 3 days a week remote is optimal. This is also my experience -- unfortunately I live on the other side of the world from my office at the moment so I'm permanently remote.


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.

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.


checked HN 25 times, checked email 20 times, watched 2 hours of Youtube videos unrelated to your field

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.


What you're describing is really just a guilt free reward.

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.


No idea if this will work but an interesting motivational trick could be to put aside some of your money into a separate account and use it as a budget to "pay" yourself for tedious yet important tasks you want done.


I never thought of doing that, thanks. Is this something you've done in the past?

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 doesn't work if you aren't motivated by shopping.


I love this post for celebrating hard work.

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.


where I work, we have that kind of entertainment stuff in ludicrous quantity, but it's literally never used, except for the interns on Fridays evenings.

I see that more as decoration to make the place look cool


How to be productive in two steps:

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.


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.

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.


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.


I think the accountability is why a lot of people hate it.


No, it's because you're being treated like a child and it's micro management. No-one should have to justify their job every single day.


The daily stand up concept was popularized by Scrum which is pretty opposed to micro management and treating people like children. Maybe it gets used that way in some companies practicing cargo cult agile but it's not the purpose.

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.


SCRUM is micro-management and treating people like children. That's the core of scrum.

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.


Scrum doesn't even have managers and doesn't specify any particular tools so I'm not sure what you're basing these claims on. By "the reality of scrum" do you mean that the way it's actually practiced in some teams is "far divorced from its claims" (probably often true) or do you mean that the framework of scrum is inherently flawed even if practiced as designed? You haven't made a case for that.


Why not?


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.

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.


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.


Oh yeah, Rich Hickey's famous: "hammock time"


I think there's a distinction to be made with stepping away from the keyboard and thinking idly about a problem while doing something else and what Hickey means by "hammock time", which is a more dedicated application of thought to the problem domain, analysis, and design. Both can be useful, but I think they're different.


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.


I'll second that. And before anyone asks, it doesn't have to be org mode (although org mode is the best tool I've used). I have approximated the same with markdown when I've been trying to show how to do it to people who don't like emacs.

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).


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've spent almost my whole career as a remote worker. You're definitely right that not everyone can handle it, but my experience is that most of the time, unproductive remote workers get cut much faster than their co-located counterparts.

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.


Working hard can pay off. That doesn't mean it always does.


Needs (2013) here. Bookofhook is a really good blog though!


I just subscribed to rss, then saw the last post was 2014 so I think is dead.


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.


I've been wondering if there is an open, light alternative to RescueTime for some time. I don't really need their graphics package- just output an excel sheet with the data, do only _some_ data crunching and leave the rest up to me.


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:

http://bookofhook.blogspot.pt/2013/03/smart-guy-productivity...


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"

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 - https://www.rescuetime.com/


This is a great article, that I think can also be useful from manager/supervisor point of view.

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.


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.

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.


hm, i like a lot of the author's suggestions, but they're missing one big piece of context.

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.




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: