Ask HN: How are some people exceptionally productive?
Some people seem superhumanly productive. For example Hadley Wickham (ggplot2), Taylor Otwell (Laravel) etc. They are creators as opposed to managers (who have the luxury of delegating and managing). How can they produce so much consistently, at such a high quality?
If you are a highly productive person (and yet have a good work-life balance), could you share your methods?
136 comments
[ 3.0 ms ] story [ 187 ms ] threadThe two biggest time sinks in everyday programming are 1.) communicating with everyone else and 2.) looking things up. If you can avoid these and have a quick analytical mind, you can basically program as quickly as you can type. So the secret to being insanely productive is to work as a solo programmer in a domain where you are thoroughly familiar with all the tools, enough that you have your API calls completely committed to memory.
If you look at most programmers who have a reputation for being insanely productive, they all follow this pattern. Fabrice Bellard works pretty much exclusively in C, mostly on signal-processing or low-level emulation. Rob Pike works all in Go using the plan9 stack. John Carmack is all games and 3D graphics, using OpenGL. Jeff Dean has two major interests - distributed systems and large-scale machine learning - and works basically exclusively in C++.
I read an interview with Guido van Rossum, Jeff Dean, and Craig Silverstein within Google where they were asked basically the same question, and the answer all of them gave was "The ability to hold the entire program in your head."
There are memory improvement techniques, developed over centuries, which can help. Think of it as latency reduction in a source code memory palace.
http://mt.artofmemory.com/start
[1] I haven't used TortoiseGit, but I do imagine that having file browser menu items for files that are maintained by git could be useful from time-to-time, but I would still be using the cli most of the time.
[2] Directed Acyclic Graph
The only one that draws serious usability complaints all the time is git.
* Unreasonable ideas about the idea that commits/history can be rewritten, so therefore "nothing is safe."
* Arguments over how some git commands are similarly named to svn commands, yet don't do the same thing. The svn way is the 'right' way, and git is 'doing it wrong,' but really it's just an argument about familiarity (sharing many traits with arguments over Mac vs. Windows keyboard shortcuts, for example).
* Complaining about a recoverable error because they don't know about the reflog.
* etc.
I'm sure there are legitimate complaints, but most of the complaints that I see are around things like that.
git won for various reasons, but the UI complaints certainly aren't because people don't understand DAGs.
Yes, but how many weeks and months did you spend learning all the quirks? http://git-man-page-generator.lokaltog.net
that people have trouble wrapping their minds around.
If you create a product and just tell people "sorry, you're not smart enough to understand it," was it a good idea?
The same restraint doesn't apply to someone naturally gifted with an exceptional memory, since they never went through the acculturation phase :)
You are generally also your own cow-orker.
Eventually, images come to mind without awareness of the retrieval process. The slow part then becomes translating the images back into alphabet-based language, for communicating with other people.
I've recently switched from C# to Ruby. In C# I'd consider myself as close to an expert as an ordinary man can get. I never had to look anything up, but more importantly... it was rare that I was confused why something didn't work. In fact most of the time when I saw something not work I knew exactly what I forgot.
In ruby, where i'm less familiar. I'm surprised every now and then. It's not the "go to the internet and search" part that looses time. It's the "let's try this, and see if it works". I might spend an hour on writing 3 lines of code. In C#, I might forget the 3 lines, but I know roughly what they are... and if i had to look it up I can confirm if it's the right 3 lines in minutes.
Obviously avoiding the 3-week bugs will save you more time than the 3-minute lookups, but you can continue to improve significantly by turning many of those 3-minute lookups into 3-second typing bursts.
Also had those plastic syntax cheat sheets which I picked up.
In addition to memorizing APIs, etc., I like memorizing where I've done "function X" in past projects.
That way when I encounter something similar (that's probably not on Google/StackOverflow), I can grab it from your previous project. Then copy/paste/tweak.
Well, shit. Is this even possible in web development these days? With the exception of jQuery, there hasn't been a single JS or backend framework that I've used from one year to the next.
If you were at Google I suppose that you had lots of technical conversations with colleagues so you more or less knew about the latest trends and their benefits, but it's harder at a smaller company or working on your own.
Another good reason is speed. It's rare for a framework to be faster than native DOM api's. And the app loads faster!
The short answer is that you don't - there is always the possibility that someone has invented something that lets someone else do your job way more effectively. But you accept the risk that you're missing out for the certainty that you're getting features done and code written quickly. And periodically, maybe look around and try some of the new inventions that seem to be getting traction to see if they really do make your job better.
The key point is to rely on your own data and observations rather than the opinions of others.
Without stopping to think about design? I can't imagine that.
That doesn't mean there's no design work involved - far from it, I recall reading through the design notes for both GFS and MapReduce while I was at Google and being amazed at the possibilities they'd considered. But the design work is largely up-front: it's picking among alternative high-level architectures and figuring out what the consequences of that choice will be. Once the choice has been made, you don't need to make a whole lot of follow-on decisions; a lot of the code follows strictly from the choices you made up-front, and you aren't writing a line and thinking "Oh, was that a good idea? I better do it some other way". It also helps that these high-productivity programmers are highly experienced, and they specialize in a domain, so they've seen many of the low-level pitfalls before and avoid them instinctively.
It's a very different experience from writing end-user code. I'll work on a webapp, get some data on the screen, and then discover "No, the flow is wrong; we should present this and this widget independently on another screen and alter these other widgets based on the values there", and then that will have a cascading effect throughout the program that requires a bunch of other changes. By contrast, when I wrote an HTML parser, the behavior was already fully specified by the HTML5 spec. I had to make a few judgment calls regarding "What's the ideal API for client code? What are the boundaries of responsibility for this parser? What data representations should I use?", and I ended up having to revise them significantly, but that was largely because it was my first major C library, and a more experienced C programmer would know instinctively what the right choice was. Much of the time spent on the parser was straight-line implementing the spec and then tracking down bugs in the implementation.
Still, I grew up writing backend C in Linux environments, focusing heavily on socket programming, protocols and systems generally. I cannot help but feel that rapid development was a lot easier back then, and coding felt more rewarding. Part of that is definitely age; I'm 29 now, been writing C since I was 10, and started to feel consciously "burnt out" on coding around 20. (Basically running on motivational fumes ever since.)
However, there's more to it than that. C had a small and generally static standard library that one committed to memory easily with a little experience. Sure, one had to consult man pages from time to time for system calls, but in the grand scheme of things, writing code was a very original exercise, since so little could be taken for granted. That's why, even though I had to write 10x the lines of code, with my own lists and hash tables (notwithstanding GLIB etc.), I felt massively more productive after a coding marathon in those days.
I really feel that the practice of programming has shifted radically in its intellectual content since then. Primarily, we're wiring together prefabricated Lego blocks nowadays; when I write code in modern languages, I've got 27 browser tabs open and seem to spend 95% of my time looking up the fine points of how this Lego block connects to that one. Java is the archetype for this, but it happens even in more terse, expressive languages. Clearly, there are some productivity benefits from all this, being able to develop at a higher level while taking for granted many data structure primitives and wrappers, and I'm not blind to that. Still, it seems like the real art these days has shifted to adroitly and dexterously figuring out new APIs and libraries.
And there's so many of them! Verily a diarrhoeal explosion of APIs, libraries and dependencies. Even if you're impervious to the latest fads and fashions, the technology is shifting rapidly from year to year, and with it, entirely new documentation, methodologies, reference manuals -- an entirely new skill set, practically.
So, I'm hard-pressed to imagine how I'm supposed to ingrain APIs into motor memory when they are so numerous, expansive, and ever-shifting. Overall, I feel that my productivity as a programmer has declined considerably, even if the overall efficiency of lines of code has gone up. Pragmatically speaking, I'm not sure I'd trade in the overall productivity gains of all the abstraction for the halcyon era of C programming, but I definitely find it challenging to motivate myself to code when the primary skill set seems to be in looking things up.
The point that I didn't mention - and that may partially answer your question - is that the other thing all of these "highly productive programmers" did is narrowly specialize in a particular niche where there weren't good existing solutions but are a number of potential users. There are still C libraries that remain unbuilt! Actually, with the decline of good C programmers and the rise of scripting languages, the relative demand for quality C libraries has probably gone upwards if anything. Usually these programmers (along with more recent ones like Zed Shaw and Mongrel, Brad Fitzpatrick and memcached, or Salvatore Sanfilippo and Redis) identified a specific need, solved it quickly and efficiently, and then leveraged the fame & reputation from that successful open-source project into a good job at a company that lets them do what they want or a series of consulting engagements supporting that software.
That's what I need to do. I almost did a few years ago, but unfortunately made the mistake of exclusively licencing the project to the customer, for a very cut-rate price. It was a gamble, as it was skunkworks, so it could have paid really well. Instead, it paid crappily, while demand for it elsewhere was abundant. Alas, IP...
As much as I prefer the philosophy of Emacs/vim/sublime + cmdline tools, code completion is never great (see Yegge's "grok" rants).
I really enjoyed a project I wrote in Java inside Eclipse, because code completion really helped me not open Google all the time. But I hate everything else about Java...
Contrast with Go, where achieving flow is hard because you can't even f* compile with an unused import. And I love everything else about Go (fast compiles, easy deploys).
(One could argue that if I haven't memorized the smallish Go standard libraries I'm not smart enough to work in the field...)
Notch livecoding a "minecraft clone" for Ludum Dare is a great display of what you talked about: familiar problem, familiar environment, great speed. Unfortunately we can't do the same with Fabrice or Jeff...
But beyond this, it's an argument in favor of smallness. Java needs code completion because the standard libraries are huge - a tech stack + domain where your interface with the outside world is much smaller (eg. DSP in C) is much easier to memorize than one where the interface surface is huge (eg. Swing and Java).
for example your go problem can be solved using goimports http://godoc.org/golang.org/x/tools/cmd/goimports Using this tool you don't have to worry about those imports and it can be configured to automatically run on save in most editors.
Ben Horowitz wrote in his book that the most productive management style is to assign one task only to one person and allow him to make decisions on his own without to force him to discuss everything with a bunch of people.
IMHO the key to productivity is managing your tasks/team in a way avoiding interruptions and reducing communication to the minimum.
Because of this, I beg anyone who wants to be as highly productive as I was to please take care of your body and your mind. It's better to be productive for forty years than highly productive for two years and then dead.
I don't want to hear about another dead hacker.
It all spiralled because all of those things made me less effective. So, I not only made more mistakes but those mistakes kept me up later and later at night...
This is a problem I've ran into in the past but on fairly severe scales. I was drinking at least 2 pots (~24 cups) of coffee per day and ended up in the hospital a few time due to stomach problems. I've sense limited my consumption of coffee and switched to pure caffeine pills (mixed with water) and my quality of life has improved quite dramatically. Gone are the constant bathroom trips and stomach issues! Obviously reducing the overall caffeine intake is extremely helpful as well but coffee as the method of ingestion is just not good on the body.
At minimum it would be correlated with poorer diet, in that if you're overworked, finding time to take care of yourself becomes increasingly difficult.
How does this compare with what you called truly insane?
This site is fun, btw: http://www.caffeineinformer.com/the-caffeine-database
http://www.sciencedirect.com/science/article/pii/S0301051107...
(Lots of other articles about the effect cited in https://en.wikipedia.org/wiki/Theanine too)
If you are using caffeine for energy, you probably should improve your diet first, instead, and make sure you get enough sleep (which I know can be hard in crunch mode, but it makes your awake time much more productive). I love my coffee as much as the next person, but using caffeine to drive my ability to work has never produced good effects.
I'm a bit envious of all the great hackers getting plenty of nice Open Source projects done (mostly Rust community, because that's what I'm into). Secretly, I would like to be a open-source-star-developer, but I can't see it ever happening...
Between dayjob, family-time/babywork (newborn son) I squeezing any time I can get for my hobby Rust projects, and I still feel like I don't get much done.
I eat OK, drink just two coffies a day, but maybe I should get more sleep, slow down and hit the gym...
It sounds like you've got a lot to live for - if you would ever like to talk, my email is in my profile. Be safe and thanks for your kind wishes! :)
It wasn't gigging but just jamming when I later was in startup land for a few years. I found the effect the same. You need something to get your mind completely off work.
It'll pay off for kids like us some day.
Maybe you are crushing it and doing 120 hours work of work in 70 hours. Or maybe you are doing 70 hours of work in 70 hours.
Or maybe doing 35 hours of work in 70 hours.
I'm not sure how many hours I do, probably around 35. I start at around 8am and work till about 6, but take long breaks during the day.
I find that I'm much more productive if I take a lot of breaks -- long hours don't necessarily result in getting more stuff done. I've never had a problem getting all the stuff done that I need to do, and I tend to be more productive than most other developers I've met. In fact, sometimes doing no work for a day or two is a good way to limber up for a difficult project.
I kid.
I noticed that when I make lists of things to do, and I see progress on the items ticked off, I know I am productive. No anxiety after that. (I usually write down the number of hours taken to complete each task and sometimes flip through the list to reassure myself with indulgent self-adulation).
Without the list, even though I am killing items, I still feel unproductive. It's that bizarre.
Make a list! :-)
Making a list helps you to focus only the things that really matter, and prevents you to quickly jump to reactive-mode.
Also if you archive those lists daily, you end up with a nice work log that you can quickly scan in the future, looking for past references.
https://en.wikipedia.org/wiki/Behance#Action_method
1. when I have a ton of things to do, I schedule or bucket them and then work on one at a time. My giant todo list is in a different doc and I only have a mini one with up to 3 tasks that I look at regularly. When I remove those tasks, I add the next three. Then you only have 3 things to do instead of 300. Small hack but works great to not feel overwhelmed.
2. Practice your focus and willpower so that you can stay on one item at a time and not feel like you need to check FB/email/etc every 5 minutes. For some people this is really hard, but it is a skill you can improve.
3. Figure out the fastest, easiest and most efficient way to do things and then do it that way. This covers everything from the commute to coding and project management.
4. If your office is driving you crazy, schedule "meetings" on your calendar to block out dedicated work times. Put your headphones on. If people still don't get the hint, tell them you are busy working on x right now and can talk to them in an hour.
5. Most importantly, work when you are working and live when you are not. I don't check my email on weekends. People have my phone number and if something is important they will text me. Leave your work at home. Even if you are the CEO most things can wait until you get back in the office.
I've noticed that when I fix my sleeping, I am less wasteful, less tired, less distracted and ultimately less anxious about my lack of productivity.
The truth really is that we will never finish our respective "baking". The freagin' cake will always need some final touch or a redo! It never ends.
Stopping for the day and believing that you deserve your rest for the next 8-9 hours is what I define as productivity.
- Action: Get stuff done with focus, this is the part that most people think about when they say productive - Reflection: Have a clear vision of what you want to do and refine it as you go along - Influences: Interact and learn from others. Talk to people, read, give presentations, etc.
I see lots of people focus only on action and never make time for reflection and influence as they aren't obviously checking things off the todo list.
[1] https://www.reddit.com/r/getdisciplined/comments/2dd7yh/advi...
They share a lot of common ground - both work on software solving a common problem, that really just needed one person to dedicate themselves to fully understanding the problem and to do a very high quality job.
Neither has had particular commercial success through doing that, but both have excellent reputations that they are now able to leverage.
If you those are your role models, you need super-expert knowledge and dedication. And, some means of supporting yourself to do that - Wickham's work fits alongside his PhD and professorship, and Otwell has been taking one day a week from his work.
Tough. Good luck :)
Along the same lines, the best advice I ever received was from an old music teacher: do less, better.
Also: if you think "delegating" and "managing" are luxuries and somehow antithetical to creation, I'm guessing you haven't done much of either.
There's something about stepping away and being able to step through each scenario and look at things from a different angle.
Obvious stuff: minimize distractions and interruptions. Allow the problem before to assemble itself and present itself to you. Then you become a scribe, working as fast as you can.
In this state, I can sometimes write pages of code that run the first time (although not a recommended best practice, lol).
As mentioned in another reply, this highly productive state is easiest to reach when you are working with familiar tools and aren't attempting anything too out of your comfort zone.
This flow state is hard to come down from, so you will need to make sure that you give yourself time to come back to earth. Don't do this too close to an RL deadline, like bedtime. Your family may not get much out of you for an hour or so.
* Create some sort of system for capturing and organizing your tasks (like GTD)
* Immediately do something if it takes less than 2 minutes to do
* Prioritize all your tasks. I prefer using the Eisenhower Matrix. Prioritizing also includes delegating and eliminating tasks.
* Start waking up earlier (like 5:30). It's quiet, there's few distractions, and it's empowering to get a ton done and then realize it's not even noon yet.
* Decide what your Most Important Task (MIT) is and do that first thing in the morning (important!)
* Make your tasks specific and actionable. Not "Study for exam," but "Review chapter 2 notes on X section." You can also break tasks down until it sounds stupid, but much easier to do.
* Batch similar or small tasks together and set a time to do them
* Schedule your day on a calendar. If it doesn't go on, it doesn't get done. You don't have to get super specific with tasks. Just block out chunks of time to do work. Also schedule your breaks and your not-working times (important!)
* I like listening to background sounds. Either classical music or using Coffitivity/Noisli. Also helps train my brain so that whenever I hear it, I know it's time to work.
Ruthless eliminating technical debt would be like living life without credits cards, a mortgage, ...
So what's my dirty little secret? Three simple things: I keep a to-do list, the items on the list are incredibly clear and take, at max, 2 hours, and finally, I switch gears if I have to wait on other people (i.e. I don't surf the net while I wait for an email to approve workflow, I simply switch to another item on my to do list)
I am INCREDIBLY focused on execution, and if I have a task that I know can cause my mind to wander, I limit the amount of time I spend on it (for example, I have research potential repository structures, 1 hour, on my to do list right now).
I used to write things like 'redo startup website' on my to-do lists years ago. Now it's '1. rewrite main copy on landing page to highlight x feature 2. rewrite faq to include a, b, c questions. 3. change contact form to say 'sign up', reset analytics'. Make your tasks granular, tactical, and limit the time frame. I also start my day with a maximum of 6 things on the to-do list, and I rank them based on priority. As I start to cross things off the list, I add more to the next day (or for later that day if I am finishing things faster than I had anticipated). Finally, before I go to bed at night, I make sure I have 6 items on my to do list for the next day, so I can hit the ground running.
Plan ahead. Break it down. Prioritize. Write things down. Regardless of what you do for a living, or where you are in life, you can definitely use this method to improve your productivity. Good luck!
I still have more weight I'd like to lose, but this has been a game changer for me. I love trail running!
1. If I am working on a large project I try to keep it split into very small pieces. I only work on a small piece at a time and switch between pieces often. This keeps my mind going. It also helps if you start to get stuck and lose focus by looking things up or just outright losing interest in what you are working on. By breaking it into small pieces you tend to complete more items and it tricks your mind into staying focused (at least for me). As someone else pointed out, a big time suck for developers is having to look things up. If I know that I want to get 20 things done in a day, I will work to get as many as possible done before I get stuck having to look something up. Sometimes I find that doing other things will freshen my mind and I no longer need to look it up.
2. If I find myself getting stuck or losing focus, I get up immediately and do something else non-work related. I may go for a 15-20 minute walk, grab a cup of coffee, or read HN.
3. I try to go to sleep at, or around, the same time every night and try to wake up at, or around, the same time every day. Being in a routine helps.
4. Watch what you eat/drink. I used to drink a couple beers every night, smoke, and drank a lot of soda. I stopped drinking 2 years ago (I still have a beer every now and then at events or with dinner on occasion), I quit smoking (been a year now), and gave up soda entirely (haven't had one in 3 years). Combined with exercising more and watching what I eat I have found this alone the biggest improvement to my staying focused and being productive. I also used to eat late at night, which didn't help my sleep cycle and also is bad for your health in general. I forced myself to get on a more routine diet, or at least eating cycle.
A great little poem got posted here which I find highly relevant. [1]
[1]: http://finishonethingtoday.com/
wherein you look at their body of work and think how is this possible
when it takes ages for me to finish a rather mediocre painting/blog.
The more time you spend with your stack the better you will get
as you develop something akin to muscle memory and a deep buffer
as evident with say a pianist or guitarist.
Nothing wrong with role models, but you're not going to help your work-life balance by comparing yourself to only their best and most visible output.