Ask HN: How are some people exceptionally productive?
136 comments
Never heard of the two people you mention, but I'll share what I've observed:
The 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."
The 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."
"looking things up"
To expand on this point, it's not the time it takes to look things up. It's the loops of trying and failing.
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.
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.
It's both - think of having to look something up on the Internet as an L1 cache miss, while having to look something up and then try multiple variations as an L2 cache miss (having the API in muscle memory so you don't have to think about it is a register hit). It may take you 3 seconds to write out an API call from memory, 3 minutes to search for it on the Internet, and 3 hours to diagnose a problem through trial and error. Occasionally even as much as 3 weeks - I've had bugs that lasted that long when it was a bug in the underlying framework, because you never expect that the bug will be in someone else's code.
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.
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.
I am not a programmer but I am able to do some "things". Starting with Unix in the 80's (and trying to do C) back when you had a book or two (and nobody to ask any questions). There were many times that I had to work 4 hours or longer just to figure out and iterate (to see what would actually work syntax wise) what I could easily search for today. One book or two, nobody to ask, total trial and error. I always tried to buy as many books as I could (which I typically had to find at a college bookstore an hour away) so I could at least triangulate an answer by a different discussion of the same point from different authors.
Also had those plastic syntax cheat sheets which I picked up.
Also had those plastic syntax cheat sheets which I picked up.
same here - it's been tough breaking the 'buy a new book' habit. If there's something I find that I want to save, I will either save the complete page, or just copy/paste the relevant text.
> 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
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
On the other hand, if you can do this and your co-workers can't, you may be tempted to write complex and entangled code, because the implications of each line are perfectly obvious to you.
Or you end up with something like Git, which is easy to use if you have the exact same background/education/philosophy as the person who wrote it, but has terrible usability for pretty much everybody else.
I don't have the same background as the "person that wrote it," and I consistently find the git command-line tools easier to work with than other tools (SourceTree, magit-mode, vim-fugitive, etc [1]). I think that in this case, it's just the mental model of a DAG[2] of commits that people have trouble wrapping their minds around. The tools are just there to help you slice and dice the DAG.
[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
[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
There are more DSCM implementations based on a DAG. (for example git, mercurial, bzr, monotone, codeville, fossil)
The only one that draws serious usability complaints all the time is git.
The only one that draws serious usability complaints all the time is git.
To borrow a turn of phrase from Bjarne Stroustroup, there are two kinds of software: software people complain about, and software nobody uses.
A couple of years ago the others were in use as well.
git won for various reasons, but the UI complaints certainly aren't because people don't understand DAGs.
git won for various reasons, but the UI complaints certainly aren't because people don't understand DAGs.
To be fair, some of the usability complaints aren't about the interface so much as things like:
* 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.
* 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.
I consistently find the git command-line tools easier to work with than other tools
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?
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?
When git was still one of many competing DVCSes - I tried darcs, and the CLI was pretty great. Spoiled for ever.
I like to joke git's motto would be "made by people smarter than you, for people smarter than you". It still rocks.
I realize these things are subjective, but git is not difficult to understand or use. Branching is a breeze. Merging is a breeze.
Oh, but you just don't. You just don't. Six months from now, the thing will have escaped your brain and you will have to look at it.
You are generally also your own cow-orker.
You are generally also your own cow-orker.
If you invest the time into acquiring a faster and larger mental cache, you are unlikely to handicap your hard-earned capability with complex code. In fact, the new visibility can increase simplification and reuse.
The same restraint doesn't apply to someone naturally gifted with an exceptional memory, since they never went through the acculturation phase :)
The same restraint doesn't apply to someone naturally gifted with an exceptional memory, since they never went through the acculturation phase :)
One thing I never quite understood: would these exercises also improve your memory when you're not using the techniques explicitly? Somehow having the information organized in your mind in a more cohesive manner, so that recall is always possible by traversing the graph...
Yes. It's like learning a new language, which changes how concepts are represented. Or increasing your vocabulary and improving your writing, which then influences thinking. Moving beyond the alphabet to additional symbols, opens up new options for both representation/storage and pointers/indexing.
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.
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.
Could you share link to the interview?
I would agree with this, just from the taste of it that I've gotten. The first time I did a CS assignment without looking up any java syntax felt like the first time achieving full speed on a bike at the age of 10, with all the freedom and possibilities that come with that.
PG wrote in one of his essays that he used to sleep in the morning, doing stuff involving others (like meetings) in the afternoon and coding in the evening and night to avoid interruption.
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.
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.
Isn't this an argument in favor of IDEs vs editors?
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...
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...
The way i view editors vs ides is an editor is a completely un-configured ide.
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.
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.
Code completion is great, and it certainly helps me go a lot faster.
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).
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).
> If you can avoid these and have a quick analytical mind, you can basically program as quickly as you can type.
Without stopping to think about design? I can't imagine that.
Without stopping to think about design? I can't imagine that.
The domains where most of these programmers work are in ones where the problems are fairly well-defined. For example, what's the design of ffmpeg? It takes in a well-specified video codec and outputs a video stream. What's the design of protobufs, MapReduce, or GFS? In each case they had several motivating examples built using earlier technologies, and knew exactly what the key metrics are that they wanted to optimize and where the bottlenecks were likely to occur.
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.
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.
That's a nice description, but up-front or not, in my view the design work should be counted as part of the programming. Maybe that's pedantic, but the idea of 'programming at the speed of typing' sounds positively dystopian to me.
Never heard of this "The ability to hold the entire program in your head." quote, but it's so true.
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.
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.
http://had.co.nz/ - Hadley Wickam - creator of many R packages. Taylor is the creator of awesome Laravel PHP framework, single handedly.
I'm just not sure how it's possible to have any API committed to memory these days, though I agree that if one picks a small number of dependencies as core tech, one stands a far better chance of doing it and will realise better productivity outcomes than someone who compulsively includes every 30-line $PITHYNAME.js novelty to hit HN and GitHub.
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.
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.
I think you've captured well the spirit of my comment.
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.
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.
IIRC Brad's approach was more of a social hack/MVP: wrote memcached in perl, convinced people of its obvious importance, let other folks write the C version (which I'm pretty sure he could have written, judging by his Go code).
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...
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...
2.) looking things up.
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.
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.
So don't use them. Virtually all my work at Google was with vanilla JS and I had the DOM APIs memorized in my head.
So how do you know you're not missing out, or more precisely, that you're not missing out and what you are missing out is so great that the productivity you gain from restricting yourself to the subset of tools you fully master does not compensate for what you are missing out - I am thinking of frameworks like Angular or React? I am asking that as someone who doesn't use the frameworks I mentioned and sticks with vanilla JS and DOM APIs.
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.
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.
That's the question everyone asks, right? People tend to be really insecure about the possibility that someone else might be doing better than they are.
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.
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.
Anybody who adopted Angular right out of the gate is kicking themselves now because everything they wrote in the last year is now obsolete. Hopping on the latest thing might be fun and you might learn a few things, but I'd prefer to wait for things to be fully battle tested and have a good history of support before I put it into production.
Another good reason is speed. It's rare for a framework to be faster than native DOM api's. And the app loads faster!
Another good reason is speed. It's rare for a framework to be faster than native DOM api's. And the app loads faster!
I'd love nothing more than to just use the latest DOM APIs, but every company I've spoken to in the last 5 years wants a framework. They feel more comfortable working with an app structure that everybody else is using to supposedly great effect.
In 2007, I finished my bba, received an angel investment, and started a company. Three months later (and with my investor's enthusiastic support), I started a non-profit street magazine. About two years later, I ended up in hospital with stroke symptoms and blood pressure on the 'how are you alive?' end of the scale.
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.
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.
So out of curiosity, in your case, was this overworked + crappy diet + lack of physical activity, or was this overworked + healthy/balanced/junk-free diet + some modicum of regular physical activity?
It started as a spiral of being overworked and not sleeping enough. As I slept less, my coffee consumption skyrocketed and my diet grew worse and worse. I tried to exercise three times a week, but between being tired, mild stomach problems from too much coffee and unhealthy food, and energy spikes, my intensity in the gym slipped and I eventually started skipping more workouts.
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...
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...
>mild stomach problems from too much coffee
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.
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.
I completely agree with you. It used to be nothing for me to drink 12 - 15 large cups of coffee a day. Nowadays, I might drink 3 - 4 cups a day and the difference in my quality of life has been astounding. Caffeine is a great performance enhancing drug, but coffee is a particular bad delivery method!
Burnout doesn't really have anything to do with diet or exercise. I suffered from it with a good diet and exercise. It's basically just your brain shutting down your stress system due to excessive long-term stress and/or negative outlook.
Burnout can absolutely lead to a poorer diet and a lack of exercise due to a lack of general motivation to eat well or stay active.
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.
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.
Thanks for your comment. It scared me a little and gave me a perspective. First thing: I hope you're all doing OK now and your health improves.
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...
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...
I'm actually doing great now - I had a very scary experience that ended in the emergency room and decided to completely change how I lived. I cut my coffee consumption, started eating better, started exercising properly, and started changing some of my more destructive habits. I've been doing entrepreneurial things again, but this time is totally different - heck, I'm writing this outside in a park!
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 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! :)
I think having something else to also do is critical. I'm a musician and I kept 70+ hour weeks in school, but 16 of those hours were at gigs, and Sundays were off limits for anything at all - no work at all.
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 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.
To be honest, my current problem is exactly the opposite - I can't get my mind on work. There're always at least three other projects occupying my mind that would be a much better use of my time than the day job except I wouldn't be able to pay my rent with them :(.
I recommend the book _Refuse to Choose_ by Barbara Scher. It is about how to use that Edison-like tendency of yours as an asset rather than having to stuff it all the time.
Maybe the side projects are too close to the day job? That's kind of what was nice about playing music - it was totally different.
If anything, it would be the job being too close to side projects. I learned programming to build cool things, the career was only a lucky accident for me.
Maybe just tell us about them.
One is a Mars colonization roguelike I'm designing every spare minute I have, the other is half-finished haptic device that only needs me to find the time to design and make a PCB (and solder components I already have), and the third would be a set-up for notifications from various home appliances via processing the noises they make. I have all the hardware for this already in place, but lack the time to code the required DSP.
Did you use/abuse caffeine/ritalin/..?
Massive caffeine abuse. I drank truly insane amounts of coffee.
how massive? I can't always plan my crunches, but since I started taking caffeine pills - I take 4 pills, equiv 4 coffees, right before really focusing on something, then I can relax in a different part of the day where it doesn't matter if it's slower. So I go between 0 and 8 coffees per day worth of caffeine, depending on what I'm doing. I've completely stopped drinking coffee and save a bunch of time that way (except socially.)
How does this compare with what you called truly insane?
How does this compare with what you called truly insane?
Consider taking L-theanine with your caffeine. When taken with caffeine, it smooths out the jitters and produces a subtle sense of clarity and focus; it will probably improve your ability to think on less caffeine.
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.
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 can't speak for hluska, but before my burnout I was up to ~700mg/day of caffeine via energy drinks. I qualified that as quite insane.
This site is fun, btw: http://www.caffeineinformer.com/the-caffeine-database
This site is fun, btw: http://www.caffeineinformer.com/the-caffeine-database
At the peak of my madness, it was nothing for me to drink 12 - 15 large cups of coffee over 12 hours at work.
1. Work on something that you MUST get done.
2. Plan your day the night before.
3. Wake up early and start working immediately.
4. Other people's "obstacles" are your opportunities to invent.
5. One day at a time, regrouping each night.
6. VERY short to do list at any given time.
7. 2 computers, work in 1 room, internet in another.
8. NO distractions while working (email, phone, others).
9. Short intense sprints with short breaks between.
10. Moderate & healthy eating.
11. Full night sleep.
12. Analysis time away from computer.
13. Clear (revisable) vision of end product.
14. Dinner with mate (or family) every night.
15. Have no other major projects (or interests) for now.
16. No day job.
17. Accept input from others, but go with your own gut.
18. No TV.
19. It's a marathon, not a sprint.
20. Get off Hacker News (stop posing, start acting).Like this list, very practical and pragmatic. Although normally reddit is not a place to go for increased productivity I thought PeaceH's guide for disciplined[1] was very helpful and provided a useful framework.
- 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...
- 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...
Number 11! Just that!
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.
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.
12. Corollary: Have a paper notebook. Writing by hand is incredibly helpful to organize and create ideas.
Little bit of background as to why I think I can answer this: Three years ago, I ran my own web design/development/marketing company, doing a lot of the front end UI/UX stuff, as well as the marketing plans for my clients. I did this, worked another full time job, voluntered 15 hours a week, and was taking 21 credits a semester. After that, for a year, I commuted 5 hours each way to attend a weekend post-baccalaureate medical program (full time) while working in a hospital full time (actually averaged 51 hours a week). Now, I'm a senior systems analyst with the same healthcare organization, I have a wife and 2 year old daughter, I'm working on my startup, and my manager and others are often commenting on how amazed they are at how much I get done, and I love my work-life balance. I don't feel like anyone is short-changed.
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!
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!
How do you deal with failure or stuck episodes?
I run. I've lost 50 pounds since the start of it all. Running clears my mind up, and I usually can just let my mind wander--that's often all it takes for me to come up with a solution to a problem I'm stuck on, and if I'm feeling like a failure, it's one thing that I know I can look at and say, 'You know, this was a total good. I ran x miles, I can accomplish something else today.'
I still have more weight I'd like to lose, but this has been a game changer for me. I love trail running!
I still have more weight I'd like to lose, but this has been a game changer for me. I love trail running!
1.) Write things down. Get organized. Google Calendar and Trello mean I never forget to do anything and I don't exercise brain power on remembering it all. This helps balance by being more relaxed. At night I don't worry about all the things I have to do tomorrow, which makes a lot of people sleep less. I say, "It's on my list, which I will tackle tomorrow." I sleep like a baby. I get things done.
2.) If you're looking for balance, take care of your body. 1 hour workout is 4% of your day. Make time for it, and do something active that you enjoy. (Even if that's playing DDR for an hour). Cook healthy meals in bulk ahead of time. Sick and dead isn't productive.
3.) Take breaks. When you feel your mind wandering, and you can't remember anything you've read in the past 5 minutes it's time to take a short break. Take 5 minutes, walk around the building, then sit back down. You might think you'll be so much more productive continuing to sit there working, but if you're working in circles or even making things worse, you are not being productive. Study Less, Study Smart is a talk by Marty Lobdell that eloquently discusses this. https://www.youtube.com/watch?v=IlU-zDU6aQ0
4.) Focus. Remove distractions. Close all the windows you don't need to work. Close your office door, answer your emails only once an hour. Whatever you need to do to focus.
2.) If you're looking for balance, take care of your body. 1 hour workout is 4% of your day. Make time for it, and do something active that you enjoy. (Even if that's playing DDR for an hour). Cook healthy meals in bulk ahead of time. Sick and dead isn't productive.
3.) Take breaks. When you feel your mind wandering, and you can't remember anything you've read in the past 5 minutes it's time to take a short break. Take 5 minutes, walk around the building, then sit back down. You might think you'll be so much more productive continuing to sit there working, but if you're working in circles or even making things worse, you are not being productive. Study Less, Study Smart is a talk by Marty Lobdell that eloquently discusses this. https://www.youtube.com/watch?v=IlU-zDU6aQ0
4.) Focus. Remove distractions. Close all the windows you don't need to work. Close your office door, answer your emails only once an hour. Whatever you need to do to focus.
This sounds counterintuitive, but: learn when to take breaks and step away from problems. Some of my most productive hours have been spent walking through parks, coming to crucial realizations or designing approaches that end up saving me days (or even weeks!) of wasted effort.
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.
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.
I've solved my most complex problems when I went for a run on the evening of the day where I got stuck.
There's something about stepping away and being able to step through each scenario and look at things from a different angle.
There's something about stepping away and being able to step through each scenario and look at things from a different angle.
I call these 'piss break revelations'. Especially when debugging or doing analysis, just take a quick break and suddenly you have new ideas.
I find this helps a lot. Many a time I've been banging my head against a problem for hours, only to realise the solution later on when I'm cooking dinner or taking a shower.
I do this too. Walks are wonderful for stimulation. Sometimes for me, it's a hot shower or short nap.
I am not like any of the people you described but here is what is working for me:
1. Make a list of things weekly that need to get done
2. Daily pull from weekly into your list for the next day
3. Be careful how you word your task list. Focus on process over outcome. This is a little hack to avoud procrastination. Example: spend an hour refactoring (process) x vs refactor x and fix failing tests (outcome)
4. Figure out the #2-3 critical items.
5. Timebox/pomodoro
6. Sleep, wake up early & eat your frogs in the morning
When i do all of this i am able to get a whole lot more done.
Also grab the book a mind for number. There are some interesting insights in productivity.
I have tried GTD etc but have found that for me this process works.
1. Make a list of things weekly that need to get done
2. Daily pull from weekly into your list for the next day
3. Be careful how you word your task list. Focus on process over outcome. This is a little hack to avoud procrastination. Example: spend an hour refactoring (process) x vs refactor x and fix failing tests (outcome)
4. Figure out the #2-3 critical items.
5. Timebox/pomodoro
6. Sleep, wake up early & eat your frogs in the morning
When i do all of this i am able to get a whole lot more done.
Also grab the book a mind for number. There are some interesting insights in productivity.
I have tried GTD etc but have found that for me this process works.
Chances are you are already productive. So, an anecdote:
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! :-)
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! :-)
Second this.
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
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
This! If a task is not on the list I don't feel good about completing it. It's like it never happened, and I look at the list and it's still full. "Nothing got done" scumbag brain says :)
Here are my overall tips
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.
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.
In my mind I'm a lazy person. My good hours are in the morning, and after that it only goes down. Right in the afternoon it's really hard for me to get anything done.
When I was studying at the university for exams, I learned more than 50% before noon, rest in the afternoon, and at 8pm, I was unable to keep anything in my head.
Now is the same, but if I haven't worked that much during the day, I can still crunch out some good code at 9pm. If I worked during the day, no way I can do that.
Yet, when I look back, I always had great reviews at my jobs. Some managers considered me more productive than others who I thought were more productive.
Next to my full-time job, I take care of our 3 kids together with my wife, and I'm programming a side project http://rpgplayground.com. I always had projects in my spare time. Some people with kids ask me were I can find the time. Yet, I still feel lazy all the time. In the weekends I'm beat. Sunday is terrible, but due to that I'm "super" productive on Monday (relative to the other days ;)).
I think it's hard to know by yourself if you are productive or not. Being productive 60+ hour per week? I highly doubt that. I even doubt begin 40+ hours productive per week. With productive I mean crunching out good code, while being in the zone.
I think a good day is being productive max 6 hours, on average 4. But it is impossible to do that in one go, and you also can't do something else productive during your resting time. If you look at athletes, they also don't train more than 6 hours in a day.
My good days are when I'm feeling energetic, positive, and am passionate about a clear goal, and like the 'zone' that I'm in, the problem I'm solving. Also, a good nights sleep can do wonders!
When I was studying at the university for exams, I learned more than 50% before noon, rest in the afternoon, and at 8pm, I was unable to keep anything in my head.
Now is the same, but if I haven't worked that much during the day, I can still crunch out some good code at 9pm. If I worked during the day, no way I can do that.
Yet, when I look back, I always had great reviews at my jobs. Some managers considered me more productive than others who I thought were more productive.
Next to my full-time job, I take care of our 3 kids together with my wife, and I'm programming a side project http://rpgplayground.com. I always had projects in my spare time. Some people with kids ask me were I can find the time. Yet, I still feel lazy all the time. In the weekends I'm beat. Sunday is terrible, but due to that I'm "super" productive on Monday (relative to the other days ;)).
I think it's hard to know by yourself if you are productive or not. Being productive 60+ hour per week? I highly doubt that. I even doubt begin 40+ hours productive per week. With productive I mean crunching out good code, while being in the zone.
I think a good day is being productive max 6 hours, on average 4. But it is impossible to do that in one go, and you also can't do something else productive during your resting time. If you look at athletes, they also don't train more than 6 hours in a day.
My good days are when I'm feeling energetic, positive, and am passionate about a clear goal, and like the 'zone' that I'm in, the problem I'm solving. Also, a good nights sleep can do wonders!
Find a task management tool that works for you and you will consistently use. It should be available to you at all times: At your desk and when you're out and about.
I recently settled on Trello after a customer showed me how he was using it. I have lists for:
- Inbox - I can put items in here easily: Trello widget on my phone, in Trello directly, or via email. Things sit here until they're moved to one of the other categories.
- Today - The things I plan to do today. I use labeling and mark things as either Work or Personal and use a priority flag for things that are very important.
- This Week - Things I want to get to this week
- Waiting On - Things I've acted on and am waiting on someone else to complete
- Later - Things I want to do but will get to later
- Done (this week) - Every week, I archive the previous weeks list and create a new one for the current week
This system works for ME, and your mileage may vary, but it's gotten me disciplined and focused on what to do every day and what to ignore.
Update: fixed formatting
I recently settled on Trello after a customer showed me how he was using it. I have lists for:
- Inbox - I can put items in here easily: Trello widget on my phone, in Trello directly, or via email. Things sit here until they're moved to one of the other categories.
- Today - The things I plan to do today. I use labeling and mark things as either Work or Personal and use a priority flag for things that are very important.
- This Week - Things I want to get to this week
- Waiting On - Things I've acted on and am waiting on someone else to complete
- Later - Things I want to do but will get to later
- Done (this week) - Every week, I archive the previous weeks list and create a new one for the current week
This system works for ME, and your mileage may vary, but it's gotten me disciplined and focused on what to do every day and what to ignore.
Update: fixed formatting
There is a bit of a selection bias at work. You don't get to see the years from when they were struggling punters like the rest of us. You also don't get to see the things they try, fail at, and then discard. You don't see how long it took them to make the thing, not in a real, emotional sense. If anyone paid real attention to how long projects really take to make good at the start of their projects, they'd never start. That's why so few people manage to start writing books: we have expectations of how long a book should be, we don't really have a good understanding of how "much" a program should be.
But it's also about organization and daily progress. A lot of my friends consider me to be extremely productive, but I think of myself as a terrible procrastinator. The reason they think I'm productive is because--in comparison to the zero effort they put into their purported side projects--I'm infinitely more productive than they are in doing just a few small things every day.
But all of that is just descriptive of What it looks like to be productive. Keeping a whole program in your brain is What you do when you have committed to being productive. Writing lists of tasks is What you do when you want to be productive. Getting up early is What you do. It's not How you get to that point. Even if you are stumbling through a project, having to constantly look up documentation, you're still being infinitely more productive than the 90% of people who don't do anything.
When you say, "I want to be that thing...", you necessarily have to also say, "... that means I will stop being this thing." I don't watch television. I don't follow professional sports. I don't work out at gyms. I don't read the latest books. I don't go to the latest movies. I don't play video games. I don't have a bowling league.
I code. I solder. I photograph. I draw. I write.
I decided at some point in time that I would make my life about creating things more than consuming things. Okay, yes, I do sometimes watch television, movies, sports, read books, work out, etc., but I do them with the frequency that other people remember to write on their nascent blogs.
You get to be productive when you decide to stop being antiproductive.
But it's also about organization and daily progress. A lot of my friends consider me to be extremely productive, but I think of myself as a terrible procrastinator. The reason they think I'm productive is because--in comparison to the zero effort they put into their purported side projects--I'm infinitely more productive than they are in doing just a few small things every day.
But all of that is just descriptive of What it looks like to be productive. Keeping a whole program in your brain is What you do when you have committed to being productive. Writing lists of tasks is What you do when you want to be productive. Getting up early is What you do. It's not How you get to that point. Even if you are stumbling through a project, having to constantly look up documentation, you're still being infinitely more productive than the 90% of people who don't do anything.
When you say, "I want to be that thing...", you necessarily have to also say, "... that means I will stop being this thing." I don't watch television. I don't follow professional sports. I don't work out at gyms. I don't read the latest books. I don't go to the latest movies. I don't play video games. I don't have a bowling league.
I code. I solder. I photograph. I draw. I write.
I decided at some point in time that I would make my life about creating things more than consuming things. Okay, yes, I do sometimes watch television, movies, sports, read books, work out, etc., but I do them with the frequency that other people remember to write on their nascent blogs.
You get to be productive when you decide to stop being antiproductive.
>When you say, "I want to be that thing...", you necessarily have to also say, "... that means I will stop being this thing." I don't watch television. I don't follow professional sports. I don't work out at gyms. I don't read the latest books. I don't go to the latest movies. I don't play video games. I don't have a bowling league.
Oh, absolutely. I was always rather creating than consuming and I noticed two things: people wondering "how do I keep up with all this stuff I do" and me wondering "when do they read all these books and watch all these shows they're talking about at parties and that I know nothing about". I have never read or seen such titles that some people would instantly invalidate my geek card if they learned about it.
Recently I've decided that I need to finally read Discworld and also started watching Doctor Who. Although I think I needed and well deserved a break, it makes me feel kinda uneasy when I go to sleep with just "watched some episodes/read some chapters" as an achievement of the day instead of "made this feature working/investigated and fixed this bug/finished another part of animation/recorded a new song" etc. (not counting stuff made at work of course)
It's just one or another indeed.
Oh, absolutely. I was always rather creating than consuming and I noticed two things: people wondering "how do I keep up with all this stuff I do" and me wondering "when do they read all these books and watch all these shows they're talking about at parties and that I know nothing about". I have never read or seen such titles that some people would instantly invalidate my geek card if they learned about it.
Recently I've decided that I need to finally read Discworld and also started watching Doctor Who. Although I think I needed and well deserved a break, it makes me feel kinda uneasy when I go to sleep with just "watched some episodes/read some chapters" as an achievement of the day instead of "made this feature working/investigated and fixed this bug/finished another part of animation/recorded a new song" etc. (not counting stuff made at work of course)
It's just one or another indeed.
Oh yeah, it annoys me to no end to be at a party, have people tell me "you have too much time on your hands" when they ask about and receive what I've been doing, then get scoffed at for not being a "true geek" for not having read this book or watched that movie. Or worse, having watched them recently, as an adult, rather than as a teenager when they did, so I don't appreciate it the same way they do through their nostalgia.
Not claiming to be a "highly productive person", but there are a few rules that I've learned along the way. These are true for me at least.
1) Context switching is expensive. Know your tools/language well, avoid interruptions.
2) You probably only have something like 4-5 hours max per day where your brain can effectively handle hard thinking tasks. Accept this and try to plan your day to get the most out of this time. For a lot of people this tends to be early in the morning, others late at night.
3) Plan all of your low cognitive tasks outside of this time. Bug reports, user support, whatever. I'm also a sysadmin so I have a whole bunch of these tasks.
4) If you have a lot of those low-cognitive cost tasks, make sure that they're well documented so you can have a wiki open on one monitor and a shell/web page/whatever in the other so you can get through lots of these quickly and without invoking many brain cells.
5) related to 2 - you probably only have a maximum of 50 hours a week where you can work effectively. The odd 70 week is probably fine, but do this on a regular/continual basis and your cognitive ability starts to decline, depression/burn-out/resentment and other things start to creep in.
6) related to 5 - keep some semblance of a work/life balance. Eat well, do regular strenuous excersize, see your friends/family, get away from work for a few days, etc.
7) enjoy what you do.
1) Context switching is expensive. Know your tools/language well, avoid interruptions.
2) You probably only have something like 4-5 hours max per day where your brain can effectively handle hard thinking tasks. Accept this and try to plan your day to get the most out of this time. For a lot of people this tends to be early in the morning, others late at night.
3) Plan all of your low cognitive tasks outside of this time. Bug reports, user support, whatever. I'm also a sysadmin so I have a whole bunch of these tasks.
4) If you have a lot of those low-cognitive cost tasks, make sure that they're well documented so you can have a wiki open on one monitor and a shell/web page/whatever in the other so you can get through lots of these quickly and without invoking many brain cells.
5) related to 2 - you probably only have a maximum of 50 hours a week where you can work effectively. The odd 70 week is probably fine, but do this on a regular/continual basis and your cognitive ability starts to decline, depression/burn-out/resentment and other things start to creep in.
6) related to 5 - keep some semblance of a work/life balance. Eat well, do regular strenuous excersize, see your friends/family, get away from work for a few days, etc.
7) enjoy what you do.
I think some people are just naturally more productive than others. They can just get going. I need to lay things out and plan. Some tips:
* 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.
* 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.
Set explicit, tangible goals every night. Make the time and space to work towards those goals with zero tolerance for distractions (waking up early and getting in 3 hours of quality work before your peers drink their coffee is a good strategy). When your goals for the day are complete, take some notes and set the goals for tomorrow. Then go play, eat well and rest. Rinse, repeat.
If I was to point out only one quality that I have seen stand out (personal experience working with similar people), it is Focus.
When they are doing something, they're extremely focused and quite often that results in not just the task finishing faster, but with desired quality. This reduces the time and number of iterations they need, creating more space for other things.
There is one factor I haven't seen addressed: mindset.
If you have certainty in what you're doing, if you have belief, it's a lot easier to be productive than if you're questioning everything ("Why am I doing this?", "Is there a better approach?"). That outlook on life has scuppered my productivity at times.
If you have certainty in what you're doing, if you have belief, it's a lot easier to be productive than if you're questioning everything ("Why am I doing this?", "Is there a better approach?"). That outlook on life has scuppered my productivity at times.
Besides general laziness, this is exactly the main factor hindering my productivity.
I can't answer this question, but what makes you think the "superhumanly productive" have a good work-life balance?
I can't answer in general, but I think I do :)
I like this quote attributed to John Carmack:
"Focused, hard work is the real key to success. Keep your eyes on the goal, and just keep taking the next step towards completing it. If you aren't sure which way to do something, do it both ways and see which works better."
See also this blog post by someone who worked with Carmack: http://bookofhook.blogspot.co.uk/2013/03/smart-guy-productiv...
"Focused, hard work is the real key to success. Keep your eyes on the goal, and just keep taking the next step towards completing it. If you aren't sure which way to do something, do it both ways and see which works better."
See also this blog post by someone who worked with Carmack: http://bookofhook.blogspot.co.uk/2013/03/smart-guy-productiv...
I do not consider myself super productive but am often told I am, so I'm answering in that context. If I had one "secret" to what I do, it's that I'd rather half-ass many things than perfect only one or two, because half-assing is "good enough" for the sort of things I do (I should not be a civil engineer or nuclear physicist, naturally). When I see great people failing to get traction, I usually see a perfectionist unable to release their work quickly enough.
I do not consider myself as very productive (and still try to learn from others). Some things that has helped me are
1. Increased water intake/Eat Well. I drink 1st bottle (300ml) with black tea (usually Oolong) and then refill with hot water. I make sure I am drinking water while I work. I am vegetarian and I take almost no sugar. I have replaced sugar with raw honey in my chai :-). I try to have more plant-based diet.
2. Take breaks. When I am stuck with the problem, I take either water-refill break/pee break/short walk to get me away from the problem, but possible solutions find me where ever I am.
3. Start day early. I usually like to start my day between 5.30AM-6AM. But I do not jump on emails/office work. I have a separate to-do list to learn/read different things (mostly technical). I start my day with it. That's my kick.
4. Less scanning. I use Asana in the Calendar view. As soon as I reach the office, I make sure the world is not crashing. I add tasks that need my attention and close the email. Then I add things I like to do (and aren't listed in my today's task). I start hunting these tasks. If I have some dependency on others(Ops for example), I create tasks/email them and move on with my agenda
5. Exercise. Not doing very much these days, but try to run for 20-25 minutes every evening, to have physical workout > mental workout (This is a key to good sleep)
6. Sleep well. I try to get somewhere between 7-8 hours every night. I need to learn to improve this area.
At the end of the day, I prefer a fulfilled day -> A day where I produced value to my company Plus I learned something new. That produced happiness which leads to productivity. Iterate.
1. Increased water intake/Eat Well. I drink 1st bottle (300ml) with black tea (usually Oolong) and then refill with hot water. I make sure I am drinking water while I work. I am vegetarian and I take almost no sugar. I have replaced sugar with raw honey in my chai :-). I try to have more plant-based diet.
2. Take breaks. When I am stuck with the problem, I take either water-refill break/pee break/short walk to get me away from the problem, but possible solutions find me where ever I am.
3. Start day early. I usually like to start my day between 5.30AM-6AM. But I do not jump on emails/office work. I have a separate to-do list to learn/read different things (mostly technical). I start my day with it. That's my kick.
4. Less scanning. I use Asana in the Calendar view. As soon as I reach the office, I make sure the world is not crashing. I add tasks that need my attention and close the email. Then I add things I like to do (and aren't listed in my today's task). I start hunting these tasks. If I have some dependency on others(Ops for example), I create tasks/email them and move on with my agenda
5. Exercise. Not doing very much these days, but try to run for 20-25 minutes every evening, to have physical workout > mental workout (This is a key to good sleep)
6. Sleep well. I try to get somewhere between 7-8 hours every night. I need to learn to improve this area.
At the end of the day, I prefer a fulfilled day -> A day where I produced value to my company Plus I learned something new. That produced happiness which leads to productivity. Iterate.
I definitely do not consider myself a "highly productive" person in the sense I believe you are referring to. I am productive though and have found little tricks that have helped me personally.
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.
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.
I'm modestly productive. I know a few exceptionally productive people. They did not learn how to do what they do, they just fell into being busy and didn't stop. Some of them attempt to push things farther(e.g. taking caffeine or pharma) but that is not the essential factor. The factors are more along the lines of personality, situation, and stress level. If they keep getting asked to produce something, and they really enjoy it, and it's not leaving them worn out at the end of the week, they can hold things there indefinitely.
IMHO, don't worry about quantity. Just focus on training and process. If you arrange your environment and daily activity in a way that leads to good work, it doesn't matter whether it's operating on cycles of six weeks or ten years. You get different kinds of work done on those cycles.
IMHO, don't worry about quantity. Just focus on training and process. If you arrange your environment and daily activity in a way that leads to good work, it doesn't matter whether it's operating on cycles of six weeks or ten years. You get different kinds of work done on those cycles.
You know being highly productive isn't everything...
But anyway if you see someone being fucking awesome at something, I can almost guarantee you that they have no special talent or "magic tricks." They have just spent, and are spending, lots and lots and LOTS of time doing what they are so good at.
But anyway if you see someone being fucking awesome at something, I can almost guarantee you that they have no special talent or "magic tricks." They have just spent, and are spending, lots and lots and LOTS of time doing what they are so good at.
I think this can be answered using analogy of a painter or a writer,
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.
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.
It's the little bit everyday that adds up. Like piano practice session, you don't wake up one day being a master, you grind it out over 10 years, every day little by little. The most productive sessions are the ones where you struggle at a slow pace because this is how you get better.
I've read some wonderful responses, especially nostrademons's. I don't see "minimizing technical debt" on the page yet, so I would like to mention it. This would require discipline, having grasped some/all of the overall picture, and foresight/planning.
I think it's more important to understand the pros and cons of going into technical debt. It's much like real debt: sometimes, by taking on debt in the short term, you can spring board yourself to a better place in the long term.
Ruthless eliminating technical debt would be like living life without credits cards, a mortgage, ...
Ruthless eliminating technical debt would be like living life without credits cards, a mortgage, ...
You have to give yourself the time and space to settle into "The Zone."
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.
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.
The two people you describe are experts in their fields and dedicated themselves to that small area.
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 :)
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 :)
Hadley Wickham has done a lot of really cool stuff, but how would you know whether he's exceptionally productive? You're probably thinking "well, what we see in terms of visible artifacts must only be the tip of the iceberg, he's probably killing it at work, at home and academically too." But you don't really know that.
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.
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.
The real hero of programming is the one who writes negative code. - Doug McIlroy
The cheapest, fastest and most reliable components of a system are those that aren't there. - Gordon Bell
You're not going to come up with a simple design through any kind of coding techniques or any kind of programming language concepts. Simplicity has to be achieved above the code level before you get to the point which you worry about how you actually implement this thing in code. - Leslie Lamport
The cheapest, fastest and most reliable components of a system are those that aren't there. - Gordon Bell
You're not going to come up with a simple design through any kind of coding techniques or any kind of programming language concepts. Simplicity has to be achieved above the code level before you get to the point which you worry about how you actually implement this thing in code. - Leslie Lamport
You can skim over all productivity tips and just get one thing fixed to be as productive as them - SHIP! It's no surprise that these people have that habit deeply ingrained in them and joy of shipping encourages them to do more.
A great little poem got posted here which I find highly relevant. [1]
[1]: http://finishonethingtoday.com/
A great little poem got posted here which I find highly relevant. [1]
[1]: http://finishonethingtoday.com/
For me at least, there are two thoughts (including mine) at the corresponding question on quora: http://www.quora.com/How-is-Hadley-Wickham-able-to-contribut...
I don't have good work-life balance but I work insanely productive. 70 hours a week on average. 23 years old.
Working 70 hours a week doesn't mean you are productive, just that you are working 70 hours per week. Being productive means getting things done.
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.
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 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.
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.
[deleted]
That just means that you work a lot, not that you get a lot done. :-)
Imagine if you were productive. You'd only have to work 40.
I kid.
I kid.
Not wasting time on HN helps a lot. My productive days are those where I'm very focussed and not distracted.
Discipline/focus is probably something holding most of us back.
I think touch typing helps in addition to holding the program in your head.
I agree. I would suggest http://www.typingstudy.com to learn to touch type...
Check Casey Neistat
> If you are a highly productive person (and yet have a good work-life balance), could you share your methods?
In order of importance:
Code:
- In order or priority when coding: Does what you want it to, easy to understand, good performance. You can re-write something that does what you want it to to be easy to understand, you can rewrite something that's easy to understand into something with good performance. And you'll generally learn something at each step of that chain which makes the next step easier, (or possible.)
- If working on the code, (not just trying to get a map of it in my head,) I only have one function open on my screen at a time. By that I mean that everything else will be collapsed or in a different buffer; somehow I won't even be looking at it. This does not, of itself, make you any faster – at least not that I'm aware of, it may lower some mental load that I haven't considered. However, if your code is so entangled that you can't write without having several functions open on your screen at the same time, then that's a very strong sign that that there's a poor abstraction at work. In which case it's often better to burn it to the ground and write a new one. Which brings us to:
- Burn it to the ground and start over. Specifically with respect to hunting bugs: Before diving into a function someone wrote, or that I wrote some time ago, to hunt a bug, I'll try to write a new function that does what that function reports itself to do, (or method if I'm using OOP.) Often, it's a lot faster to write something that doesn't have that error to begin with than it is to work out precisely what went wrong the first time around.
- Naming. Good naming is hard, and the decision as to what to name is non-trivial. It may seem obvious to you that a bit of code gives you something but it's not necessarily so to others. For this reason alone, though I don't like pair programming, I make time every couple of weeks to do it. It gives me some idea of what's non-obvious, both to me and to them. “What's this?” Having the right things named makes your code much cleaner and easier to manipulate.
- If the function doesn't fit on one reasonably sized monitor, in other words if it's longer than a couple of hundred lines, then chances are either I'm writing it wrong or I've made some sort of design mistake; the function is too general, or tries to do too many things. This is not a strict rule as the other, and obviously varies to some degree by the syntax of the language one uses. A relatively dense language like Lisp I'd say if it's longer than 40 lines.
- Don't use a new library in production code unless you have good reason to. There are far too many people who want to play with the latest cool toy just because it is the latest cool toy. Do that on your own time.
Work method:
- I don't have a to-do list, I have a calendar. This helps with managing interruptions and prioritising things. IME it's easy for people's to-do lists to grow far too large, without them paying any mind to when they're going to do things and the little inefficiencies involved in changing to each task. Someone comes up and wants something done I can look at the calendar and know what can be moved and when something can be slotted in.
- If I can help it, and this means unless someone very senior in the company tells me otherwise, I don't book periods of time shorter than an hour for a task. If there are a lots of little tasks that are related then I group them and book an hour. If there's only one little task, it's still an hour. Preferably, however, these are things that get pushed later in the week when they can be grouped.
- I don't have automatically checked email and I don't have any work-known email accounts on any non-work computers. I check my email at the start of the day and the end of the day, and that's it. Email is an enormous time sink.
- I have a separate work phone and home phone, and the work phone is turned off and lives in a locked draw in my office when I'm not at work.
- Strictly police your free time. If someone asks you whether you can just do this thing for them, or whether you can stay on that night to get something banged out… well, there are times to say yes, but most of the time the answer should be no. You probably need your down time. This also makes people take your time more seriously and lets them know that if you are staying on it is a favour.
- I only take holiday in week long chunks of greater. Contiguous time off is, IME, dramatically more rejuvenating than a day here and a day there.
- Have hobbies. All my best ideas have come from hobbies. Be that reading fiction and thinking 'I can make a shadow of that.' Or seeing cool art examples. Or meeting someone at a club who tells me about a problem they have. You might think that this is going to be a point about knowing what people want. It's not, although that can happen. It's a point about knowing how different people think about the problems which lets you generate more fitting abstractions.
In order of importance:
Code:
- In order or priority when coding: Does what you want it to, easy to understand, good performance. You can re-write something that does what you want it to to be easy to understand, you can rewrite something that's easy to understand into something with good performance. And you'll generally learn something at each step of that chain which makes the next step easier, (or possible.)
- If working on the code, (not just trying to get a map of it in my head,) I only have one function open on my screen at a time. By that I mean that everything else will be collapsed or in a different buffer; somehow I won't even be looking at it. This does not, of itself, make you any faster – at least not that I'm aware of, it may lower some mental load that I haven't considered. However, if your code is so entangled that you can't write without having several functions open on your screen at the same time, then that's a very strong sign that that there's a poor abstraction at work. In which case it's often better to burn it to the ground and write a new one. Which brings us to:
- Burn it to the ground and start over. Specifically with respect to hunting bugs: Before diving into a function someone wrote, or that I wrote some time ago, to hunt a bug, I'll try to write a new function that does what that function reports itself to do, (or method if I'm using OOP.) Often, it's a lot faster to write something that doesn't have that error to begin with than it is to work out precisely what went wrong the first time around.
- Naming. Good naming is hard, and the decision as to what to name is non-trivial. It may seem obvious to you that a bit of code gives you something but it's not necessarily so to others. For this reason alone, though I don't like pair programming, I make time every couple of weeks to do it. It gives me some idea of what's non-obvious, both to me and to them. “What's this?” Having the right things named makes your code much cleaner and easier to manipulate.
- If the function doesn't fit on one reasonably sized monitor, in other words if it's longer than a couple of hundred lines, then chances are either I'm writing it wrong or I've made some sort of design mistake; the function is too general, or tries to do too many things. This is not a strict rule as the other, and obviously varies to some degree by the syntax of the language one uses. A relatively dense language like Lisp I'd say if it's longer than 40 lines.
- Don't use a new library in production code unless you have good reason to. There are far too many people who want to play with the latest cool toy just because it is the latest cool toy. Do that on your own time.
Work method:
- I don't have a to-do list, I have a calendar. This helps with managing interruptions and prioritising things. IME it's easy for people's to-do lists to grow far too large, without them paying any mind to when they're going to do things and the little inefficiencies involved in changing to each task. Someone comes up and wants something done I can look at the calendar and know what can be moved and when something can be slotted in.
- If I can help it, and this means unless someone very senior in the company tells me otherwise, I don't book periods of time shorter than an hour for a task. If there are a lots of little tasks that are related then I group them and book an hour. If there's only one little task, it's still an hour. Preferably, however, these are things that get pushed later in the week when they can be grouped.
- I don't have automatically checked email and I don't have any work-known email accounts on any non-work computers. I check my email at the start of the day and the end of the day, and that's it. Email is an enormous time sink.
- I have a separate work phone and home phone, and the work phone is turned off and lives in a locked draw in my office when I'm not at work.
- Strictly police your free time. If someone asks you whether you can just do this thing for them, or whether you can stay on that night to get something banged out… well, there are times to say yes, but most of the time the answer should be no. You probably need your down time. This also makes people take your time more seriously and lets them know that if you are staying on it is a favour.
- I only take holiday in week long chunks of greater. Contiguous time off is, IME, dramatically more rejuvenating than a day here and a day there.
- Have hobbies. All my best ideas have come from hobbies. Be that reading fiction and thinking 'I can make a shadow of that.' Or seeing cool art examples. Or meeting someone at a club who tells me about a problem they have. You might think that this is going to be a point about knowing what people want. It's not, although that can happen. It's a point about knowing how different people think about the problems which lets you generate more fitting abstractions.
Lists.
The most important thing is to stick with the same technologies and become an expert in them.
[deleted]
If you are a highly productive person (and yet have a good work-life balance), could you share your methods?