via youtube.com
Yahoo! home page engineer Nicholas Zakas, author of 《Professional Javascript for Web Developers》，discusses frontend architecture for complex, modular web applications with significant Javascript elements.
2012年12月6日 星期四
2012年11月20日 星期二
2012年11月4日 星期日
2012年10月23日 星期二
Some advice from Jeff Bezos by Jason Fried of 37signals
Jeff Bezos stopped by our office yesterday and spent about 90 minutes with us talking product strategy. Before he left, he spent about 45 minutes taking general Q&A from everyone at the office.
During one of his answers, he shared an enlightened observation about people who are “right a lot”.
He said people who were right a lot of the time were people who often changed their minds. He doesn’t think consistency of thought is a particularly positive trait. It’s perfectly healthy — encouraged, even — to have an idea tomorrow that contradicted your idea today.
He’s observed that the smartest people are constantly revising their understanding, reconsidering a problem they thought they’d already solved. They’re open to new points of view, new information, new ideas, contradictions, and challenges to their own way of thinking.
This doesn’t mean you shouldn’t have a well formed point of view, but it means you should consider your point of view as temporary.
What trait signified someone who was wrong a lot of the time? Someone obsessed with details that only support one point of view. If someone can’t climb out of the details, and see the bigger picture from multiple angles, they’re often wrong most of the time.
Great advice.
via 37signals.com
2012年10月14日 星期日
2012年10月3日 星期三
Learnable Programming
via worrydream.com
Here's a trick question: How do we get people to understand programming?
Khan Academy recently launched an online environment for learning to program. It offers a set of tutorials based on the JavaScript and Processing languages, and features a "live coding" environment, where the program's output updates as the programmer types.
2012年9月28日 星期五
2012年9月25日 星期二
50% of Consumers Value a Brand's Facebook Page More Than Its Website [INFOGRAPHIC]
via mashable.com
A new survey shows that 50% of consumers say brand Facebook pages are more useful than the brand's website.
2012年9月20日 星期四
2012年9月14日 星期五
2012年9月10日 星期一
A Generation Lost in the Bazaar - ACM Queue
Quality happens only when someone is responsible for it.
Poul-Henning Kamp
Thirteen years ago, Eric Raymond's book The Cathedral and the Bazaar (O'Reilly Media, 2001) redefined our vocabulary and all but promised an end to the waterfall model and big software companies, thanks to the new grass-roots open source software development movement. I found the book thought provoking, but it did not convince me. On the other hand, being deeply involved in open source, I couldn't help but think that it would be nice if he was right.
The book I brought to the beach house this summer is also thought provoking, much more so than Raymond's (which it even mentions rather positively): Frederick P. Brooks's The Design of Design (Addison-Wesley Professional, 2010). As much as I find myself nodding in agreement and as much as I enjoy Brooks's command of language and subject matter, the book also makes me sad and disappointed.
Thirteen years ago also marks the apogee of the dot-com euphoria, where every teenager was a Web programmer and every college dropout had a Web startup. I had genuine fun trying to teach some of those greenhorns about the good old-fashioned tricks of the trade—test-restoring backups, scripting operating-system installs, version control, etc. Hindsight, of course, is 20/20 (i.e., events may have been less fun than you remember), and there is no escaping that the entire dot-com era was a disaster for IT/CS in general and for software quality and Unix in particular.
I have not seen any competent analysis of how much bigger the IT industry became during the dot-com years. My own estimate is that—counted in the kinds of jobs that would until then have been behind the locked steel doors of the IT department—our trade grew by two orders of magnitude, or if you prefer, by more than 10,000 percent.
Getting hooked on computers is easy—almost anybody can make a program work, just as almost anybody can nail two pieces of wood together in a few tries. The trouble is that the market for two pieces of wood nailed together—inexpertly—is fairly small outside of the "proud grandfather" segment, and getting from there to a decent set of chairs or fitted cupboards takes talent, practice, and education. The extra 9,900 percent had neither practice nor education when they arrived in our trade, and before they ever had the chance to acquire it, the party was over and most of them were out of a job. I will charitably assume that those who managed to hang on were the most talented and most skilled, but even then there is no escaping that as IT professionals they mostly sucked because of their lack of ballast.
The bazaar meme advocated by Raymond, "Just hack it," as opposed to the carefully designed cathedrals of the pre-dot-com years, unfortunately did, not die with the dot-com madness, and today Unix is rapidly sinking under its weight.
I updated my laptop. I have been running the development version of FreeBSD for 18 years straight now, and compiling even my Spartan work environment from source code takes a full day, because it involves trying to make sense and architecture out of Raymond's anarchistic software bazaar.
At the top level, the FreeBSD ports collection is an attempt to create a map of the bazaar that makes it easy for FreeBSD users to find what they need. In practice this map consists, right now, of 22,198 files that give a summary description of each stall in the bazaar—a couple of lines telling you roughly what that stall offers and where you can read more about it. Also included are 23,214 Makefiles that tell you what to do with the software you find in each stall. These Makefiles also try to inform you of the choices you should consider, which options to choose, and what would be sensible defaults for them. The map also conveniently comes with 24,400 patch files to smooth over the lack of craftsmanship of many of the wares offered, but, generally, it is lack of portability that creates a need for these patch files.
Finally, the map helpfully tells you that if you want to have www/firefox, you will first need to get devel/nspr, security/nss, databases/sqlite3, and so on. Once you look up those in the map and find their dependencies, and recursively look up their dependencies, you will have a shopping list of the 122 packages you will need before you can get to www/firefox.
Modularity and code reuse are, of course, A Good Thing. Even in the most trivially simple case, however, the CS/IT dogma of code reuse is totally foreign in the bazaar: the software in the FreeBSD ports collection contains at least 1,342 copied and pasted cryptographic algorithms.
If that resistance/ignorance of code reuse had resulted in self-contained and independent packages of software, the price of the code duplication might actually have been a good tradeoff for ease of package management. But that was not the case: the packages form a tangled web of haphazard dependencies that results in much code duplication and waste.
Here is one example of an ironic piece of waste: Sam Leffler's graphics/libtiff is one of the 122 packages on the road to www/firefox, yet the resulting Firefox browser does not render TIFF images. For reasons I have not tried to uncover, 10 of the 122 packages need Perl and seven need Python; one of them, devel/glib20, needs both languages for reasons I cannot even imagine.
Further down the shopping list are repeated applications of the Peter Principle, the idea that in an organization where promotion is based on achievement, success, and merit, that organization's members will eventually be promoted beyond their level of ability. The principle is commonly phrased, "Employees tend to rise to their level of incompetence." Applying the principle to software, you will find that you need three different versions of the make program, a macroprocessor, an assembler, and many other interesting packages. At the bottom of the food chain, so to speak, is libtool, which tries to hide the fact that there is no standardized way to build a shared library in Unix. Instead of standardizing how to do that across all Unixen—something that would take just a single flag to the ld(1) command—the Peter Principle was applied and made it libtool's job instead. The Peter Principle is indeed strong in this case—the source code for devel/libtool weighs in at 414,740 lines. Half that line count is test cases, which in principle is commendable, but in practice it is just the Peter Principle at work: the tests elaborately explore the functionality of the complex solution for a problem that should not exist in the first place. Even more maddening is that 31,085 of those lines are in a single unreadably ugly shell script called configure. The idea is that the configure script performs approximately 200 automated tests, so that the user is not burdened with configuring libtool manually. This is a horribly bad idea, already much criticized back in the 1980s when it appeared, as it allows source code to pretend to be portable behind the veneer of the configure script, rather than actually having the quality of portability to begin with. It is a travesty that the configure idea survived.
The 1980s saw very different Unix implementations: Cray-1s with their 24-bit pointers, Amdahl UTS mainframe Unix, a multitude of more or less competently executed SysV+BSD mashups from the minicomputer makers, the almost—but not quite—Unix shims from vendors such as Data General, and even the genuine Unix clone Coherent from the paint company Mark Williams.
The configure scripts back then were written by hand and did things like figure out if this was most like a BSD- or a SysV-style Unix, and then copied one or the other Makefile and maybe also a .h file into place. Later the configure scripts became more ambitious, and as an almost predictable application of the Peter Principle, rather than standardize Unix to eliminate the need for them, somebody wrote a program, autoconf, to write the configure scripts.
Today's Unix/Posix-like operating systems, even including IBM's z/OS mainframe version, as seen with 1980 eyes are identical; yet the 31,085 lines of configure for libtool still check if <sys/stat.h> and <stdlib.h> exist, even though the Unixen, which lacked them, had neither sufficient memory to execute libtool nor disks big enough for its 16-MB source code.
How did that happen?
Well, autoconf, for reasons that have never made sense, was written in the obscure M4 macro language, which means that the actual tests look like this:
## Whether `make' supports order-only prerequisites.
AC_CACHE_CHECK([whether ${MAKE-make} supports order-only prerequisites],
[lt_cv_make_order_only],
[mkdir conftest.dir
cd conftest.dir
touch b
touch a
cat >confmk << 'END'
a: b | c
a b c:
touch $[]@
END
touch c
if ${MAKE-make} -s -q -f confmk >/dev/null 2>&1; then
lt_cv_make_order_only=yes
else
lt_cv_make_order_only=no
fi
cd ..
rm -rf conftest.dir
])
if test $lt_cv_make_order_only = yes; then
ORDER='|'
else
ORDER=''
fi
AC_SUBST([ORDER])
Needless to say, this is more than most programmers would ever want to put up with, even if they had the skill, so the input files for autoconf happen by copy and paste, often hiding behind increasingly bloated standard macros covering "standard tests" such as those mentioned earlier, which look for compatibility problems not seen in the past 20 years.
This is probably also why libtool's configure probes no fewer than 26 different names for the Fortran compiler my system does not have, and then spends another 26 tests to find out if each of these nonexistent Fortran compilers supports the -g option.
That is the sorry reality of the bazaar Raymond praised in his book: a pile of old festering hacks, endlessly copied and pasted by a clueless generation of IT "professionals" who wouldn't recognize sound IT architecture if you hit them over the head with it. It is hard to believe today, but under this embarrassing mess lies the ruins of the beautiful cathedral of Unix, deservedly famous for its simplicity of design, its economy of features, and its elegance of execution. (Sic transit gloria mundi, etc.)
One of Brooks's many excellent points is that quality happens only if somebody has the responsibility for it, and that "somebody" can be no more than one single person—with an exception for a dynamic duo. I am surprised that Brooks does not cite Unix as an example of this claim, since we can pinpoint with almost surgical precision the moment that Unix started to fragment: in the early 1990s when AT&T spun off Unix to commercialize it, thereby robbing it of its architects.
More than once in recent years, others have reached the same conclusion as Brooks. Some have tried to impose a kind of sanity, or even to lay down the law formally in the form of technical standards, hoping to bring order and structure to the bazaar. So far they have all failed spectacularly, because the generation of lost dot-com wunderkinder in the bazaar has never seen a cathedral and therefore cannot even imagine why you would want one in the first place, much less what it should look like. It is a sad irony, indeed, that those who most need to read it may find The Design of Design entirely incomprehensible. But to anyone who has ever wondered whether using m4 macros to configure autoconf to write a shell script to look for 26 Fortran compilers in order to build a Web browser was a bit of a detour, Brooks offers well-reasoned hope that there can be a better way.
LOVE IT, HATE IT? LET US KNOW
Poul-Henning Kamp (phk@FreeBSD.org) has programmed computers for 26 years and is the inspiration behind bikeshed.org. His software has been widely adopted as under-the-hood building blocks in both open source and commercial products. His most recent project is the Varnish HTTP accelerator, which is used to speed up large Web sites such as Facebook.
via queue.acm.org
A Generation Lost in the Bazaar
Quality happens only when someone is responsible for it.
POUL-HENNING KAMP
Thirteen years ago, Eric Raymond's book The Cathedral and the Bazaar(O'Reilly Media, 2001) redefined our vocabulary and all but promised an end to the waterfall model and big software companies, thanks to the new grass-roots open source software development movement. I found the book thought provoking, but it did not convince me. On the other hand, being deeply involved in open source, I couldn't help but think that it would be nice if he was right.
The book I brought to the beach house this summer is also thought provoking, much more so than Raymond's (which it even mentions rather positively): Frederick P. Brooks's The Design of Design (Addison-Wesley Professional, 2010). As much as I find myself nodding in agreement and as much as I enjoy Brooks's command of language and subject matter, the book also makes me sad and disappointed.
Thirteen years ago also marks the apogee of the dot-com euphoria, where every teenager was a Web programmer and every college dropout had a Web startup. I had genuine fun trying to teach some of those greenhorns about the good old-fashioned tricks of the trade—test-restoring backups, scripting operating-system installs, version control, etc. Hindsight, of course, is 20/20 (i.e., events may have been less fun than you remember), and there is no escaping that the entire dot-com era was a disaster for IT/CS in general and for software quality and Unix in particular.
I have not seen any competent analysis of how much bigger the IT industry became during the dot-com years. My own estimate is that—counted in the kinds of jobs that would until then have been behind the locked steel doors of the IT department—our trade grew by two orders of magnitude, or if you prefer, by more than 10,000 percent.
Getting hooked on computers is easy—almost anybody can make a program work, just as almost anybody can nail two pieces of wood together in a few tries. The trouble is that the market for two pieces of wood nailed together—inexpertly—is fairly small outside of the "proud grandfather" segment, and getting from there to a decent set of chairs or fitted cupboards takes talent, practice, and education. The extra 9,900 percent had neither practice nor education when they arrived in our trade, and before they ever had the chance to acquire it, the party was over and most of them were out of a job. I will charitably assume that those who managed to hang on were the most talented and most skilled, but even then there is no escaping that as IT professionals they mostly sucked because of their lack of ballast.
The bazaar meme advocated by Raymond, "Just hack it," as opposed to the carefully designed cathedrals of the pre-dot-com years, unfortunately did, not die with the dot-com madness, and today Unix is rapidly sinking under its weight.
I updated my laptop. I have been running the development version of FreeBSD for 18 years straight now, and compiling even my Spartan work environment from source code takes a full day, because it involves trying to make sense and architecture out of Raymond's anarchistic software bazaar.
At the top level, the FreeBSD ports collection is an attempt to create a map of the bazaar that makes it easy for FreeBSD users to find what they need. In practice this map consists, right now, of 22,198 files that give a summary description of each stall in the bazaar—a couple of lines telling you roughly what that stall offers and where you can read more about it. Also included are 23,214 Makefiles that tell you what to do with the software you find in each stall. These Makefiles also try to inform you of the choices you should consider, which options to choose, and what would be sensible defaults for them. The map also conveniently comes with 24,400 patch files to smooth over the lack of craftsmanship of many of the wares offered, but, generally, it is lack of portability that creates a need for these patch files.
Finally, the map helpfully tells you that if you want to have www/firefox, you will first need to get devel/nspr, security/nss, databases/sqlite3, and so on. Once you look up those in the map and find their dependencies, and recursively look up their dependencies, you will have a shopping list of the 122 packages you will need before you can get to www/firefox.
Modularity and code reuse are, of course, A Good Thing. Even in the most trivially simple case, however, the CS/IT dogma of code reuse is totally foreign in the bazaar: the software in the FreeBSD ports collection contains at least 1,342 copied and pasted cryptographic algorithms.
If that resistance/ignorance of code reuse had resulted in self-contained and independent packages of software, the price of the code duplication might actually have been a good tradeoff for ease of package management. But that was not the case: the packages form a tangled web of haphazard dependencies that results in much code duplication and waste.
Here is one example of an ironic piece of waste: Sam Leffler's graphics/libtiff is one of the 122 packages on the road to www/firefox, yet the resulting Firefox browser does not render TIFF images. For reasons I have not tried to uncover, 10 of the 122 packages need Perl and seven need Python; one of them, devel/glib20, needs both languages for reasons I cannot even imagine.
Further down the shopping list are repeated applications of the Peter Principle, the idea that in an organization where promotion is based on achievement, success, and merit, that organization's members will eventually be promoted beyond their level of ability. The principle is commonly phrased, "Employees tend to rise to their level of incompetence." Applying the principle to software, you will find that you need three different versions of the make program, a macroprocessor, an assembler, and many other interesting packages. At the bottom of the food chain, so to speak, is libtool, which tries to hide the fact that there is no standardized way to build a shared library in Unix. Instead of standardizing how to do that across all Unixen—something that would take just a single flag to the ld(1) command—the Peter Principle was applied and made it libtool's job instead. The Peter Principle is indeed strong in this case—the source code for devel/libtool weighs in at 414,740 lines. Half that line count is test cases, which in principle is commendable, but in practice it is just the Peter Principle at work: the tests elaborately explore the functionality of the complex solution for a problem that should not exist in the first place. Even more maddening is that 31,085 of those lines are in a single unreadably ugly shell script called configure. The idea is that the configure script performs approximately 200 automated tests, so that the user is not burdened with configuring libtool manually. This is a horribly bad idea, already much criticized back in the 1980s when it appeared, as it allows source code to pretend to be portable behind the veneer of the configure script, rather than actually having the quality of portability to begin with. It is a travesty that the configure idea survived.
The 1980s saw very different Unix implementations: Cray-1s with their 24-bit pointers, Amdahl UTS mainframe Unix, a multitude of more or less competently executed SysV+BSD mashups from the minicomputer makers, the almost—but not quite—Unix shims from vendors such as Data General, and even the genuine Unix clone Coherent from the paint company Mark Williams.
The configure scripts back then were written by hand and did things like figure out if this was most like a BSD- or a SysV-style Unix, and then copied one or the other Makefile and maybe also a .h file into place. Later the configure scripts became more ambitious, and as an almost predictable application of the Peter Principle, rather than standardize Unix to eliminate the need for them, somebody wrote a program, autoconf, to write the configure scripts.
Today's Unix/Posix-like operating systems, even including IBM's z/OS mainframe version, as seen with 1980 eyes are identical; yet the 31,085 lines of configure for libtool still check if <sys/stat.h> and <stdlib.h> exist, even though the Unixen, which lacked them, had neither sufficient memory to execute libtool nor disks big enough for its 16-MB source code.
How did that happen?
Well, autoconf, for reasons that have never made sense, was written in the obscure M4 macro language, which means that the actual tests look like this:
## Whether `make' supports order-only prerequisites.
AC_CACHE_CHECK([whether ${MAKE-make} supports order-only prerequisites],
[lt_cv_make_order_only],
[mkdir conftest.dir
cd conftest.dir
touch b
touch a
cat >confmk << 'END'
a: b | c
a b c:
touch $[]@
END
touch c
if ${MAKE-make} -s -q -f confmk >/dev/null 2>&1; then
lt_cv_make_order_only=yes
else
lt_cv_make_order_only=no
fi
cd ..
rm -rf conftest.dir
])
if test $lt_cv_make_order_only = yes; then
ORDER='|'
else
ORDER=''
fi
AC_SUBST([ORDER])
Needless to say, this is more than most programmers would ever want to put up with, even if they had the skill, so the input files for autoconf happen by copy and paste, often hiding behind increasingly bloated standard macros covering "standard tests" such as those mentioned earlier, which look for compatibility problems not seen in the past 20 years.
This is probably also why libtool's configure probes no fewer than 26 different names for the Fortran compiler my system does not have, and then spends another 26 tests to find out if each of these nonexistent Fortran compilers supports the -g option.
That is the sorry reality of the bazaar Raymond praised in his book: a pile of old festering hacks, endlessly copied and pasted by a clueless generation of IT "professionals" who wouldn't recognize sound IT architecture if you hit them over the head with it. It is hard to believe today, but under this embarrassing mess lies the ruins of the beautiful cathedral of Unix, deservedly famous for its simplicity of design, its economy of features, and its elegance of execution. (Sic transit gloria mundi, etc.)
One of Brooks's many excellent points is that quality happens only if somebody has the responsibility for it, and that "somebody" can be no more than one single person—with an exception for a dynamic duo. I am surprised that Brooks does not cite Unix as an example of this claim, since we can pinpoint with almost surgical precision the moment that Unix started to fragment: in the early 1990s when AT&T spun off Unix to commercialize it, thereby robbing it of its architects.
More than once in recent years, others have reached the same conclusion as Brooks. Some have tried to impose a kind of sanity, or even to lay down the law formally in the form of technical standards, hoping to bring order and structure to the bazaar. So far they have all failed spectacularly, because the generation of lost dot-comwunderkinder in the bazaar has never seen a cathedral and therefore cannot even imagine why you would want one in the first place, much less what it should look like. It is a sad irony, indeed, that those who most need to read it may find The Design of Design entirely incomprehensible. But to anyone who has ever wondered whether using m4 macros to configure autoconf to write a shell script to look for 26 Fortran compilers in order to build a Web browser was a bit of a detour, Brooks offers well-reasoned hope that there can be a better way.
LOVE IT, HATE IT? LET US KNOW
Poul-Henning Kamp (phk@FreeBSD.org) has programmed computers for 26 years and is the inspiration behindbikeshed.org. His software has been widely adopted as under-the-hood building blocks in both open source and commercial products. His most recent project is the Varnish HTTP accelerator, which is used to speed up large Web sites such as Facebook.
from ACM Queue
2012年8月14日 星期二
Only 2% of People Can Multitask Successfully [INFOGRAPHIC]
via mashable.com
"Despite the numerous gadgets and apps that help us get through our days, research suggests that only 2% of people can multitask effectively. As for the remaining 98%? They’re actually lessening their productivity without even realizing it."
2012年7月20日 星期五
2012年7月16日 星期一
2012年7月11日 星期三
2012年7月9日 星期一
2012年7月6日 星期五
2012年7月2日 星期一
2012年6月29日 星期五
2012年6月25日 星期一
2012年6月24日 星期日
2012年6月19日 星期二
2012年6月18日 星期一
2012年6月16日 星期六
2012年6月14日 星期四
Daily Routine of a 4 Hour Programmer by Jay Janarthanan
Everyone knows the routine, get to work by 9 AM, sit in front of the computer, code all day, and head home at 5. Now, thanks to guys like Tim Ferris I have started to re-think how I work and what makes me productive as a software developer.
Recently, I made some big changes to my Monday to Friday schedule. For a long time, I did things just like all of the other coders I know. But during the second half of 2011, I started experimenting to see what type of daily schedule makes me most productive. This is still a work in progress, and I do not work on military precision - I may get up 20 minutes earlier or later, for example - but here is my current schedule:
4.30 AM to 7 AM: Meditation, Writing, Goal Review Family Breakfast
Getting up at 4.30 AM is actually not that hard. Everyone is a bit different, but the body generally needs 7 to 9 hours of sleep. The way to know if you are getting enough sleep is to wake up without an alarm. Just go to bed early enough and you can wake up at 4.30 AM also.
Immediately after getting up, I drink 16 oz of water—no coffee! I have not had a coffee in a long time, and I don’t miss it much. In fact, I feel better without it. Then I take a shower; I want to start the day fresh.
I meditate for 30 minutes every morning. It’s best to meditate just before or during sunrise, so any time before 6 AM for people in the western world. I am not going to explain why meditation is good for you; there is plenty of research on the net. If you want a good book on meditation I recommend Meditation for Dummies. Despite its name, it’s one of the best books I have read.
After that, I spend 30-45 minutes writing content for my blog. I will try to write between 500 and 800 words. I have found that I can pull it off if I do this task very well right after meditation. Plus, the brain works all night while we sleep, so its best is to do a brain dump before moving on to other mental tasks. A tip on writing: use this time for an initial brain dump. Don’t try to do research, editing, etc. until later.
Then it’s To Do List time. I check my emails, Twitter, LinkedIn, etc., and assign tasks. Speaking of tasks, I follow the GTD Method and orient my life around Omnifocus software. I run this on my iPad, iPhone, and MacBook Air (ok, so I am an Apple fan boy). Yes, Omnifocus is a bit expensive for a to-do list management software, but since my entire life revolves around it, it’s worth the price. I go through my list and compare it against my goals - everything from small objectives for today to long-term goals. Every item on the list should relate to a goal. If it doesn’t, I remove it.
Breakfast is next. There are several schools of thought on when you should have breakfast and what you should eat. I have experimented with lots of different things. I find that something fiber rich, low carb, and high protein works best for me. Ever tried oatmeal with peanut butter? Perfect! I also like to include fresh fruit and tea. Also, we try to have breakfast as a family. Sometimes we make it work, and sometimes not. My goal is to get this 100% this year.
7 AM to 11 AM: My 4 hour Programmer Time
This is the time that I use for coding. 4 hours a day may seem ridiculously small, but I have found that I can get more coding done in these 4 hours than most people can do in a week. Research has shown that people who have a consistent timetable deliver better than people with a random work schedule. For me, it’s 7 to 11 AM, every day. All I do is coding during this time, nothing else. There are a few ground rules:
First, turn off all communications - phone, email, chat etc. You should have no distractions. You can give a handful of people a way to reach you if something is really urgent. The people who might have a reason to contact me in an emergency know how to do it, and I have yet to have anyone use it. I have even trained my wife, who used to expect immediate answers to every question, to respect this 4 hour block. also you should work on a single project. Don’t try to work on 5 different things.
Second, Don’t take any breaks for e-mail, surfing on the net, or anything like it. Here’s why: In an hour’s time, I can get x number of functions coded. I have found that if I work for four continuous hours, I can deliver not just 4 times but 8 to 16 times that amount of work. You will experience this when you 100% focused on one objective and not thinking about anything else. This is what we call the Flow mental state. I plan to write more about the state of Flow in a future blog entry.
So why not apply the same principle to an 8 hour work day? Because there are limits on human productivity. The brain is just like a muscle. Can you continuously run on a treadmill for eight hours? Like our muscles, the brain needs occasional rest. The limit is a bit different for each individual. Through trial and error I have found that 4 hours is my max.
It is also worth mentioning that I don’t set an alarm for an 11 am stop. I finish work when I feel my brain is getting tired and my productivity is decreasing. Some days I work for 3 hours and some I work for 5 hours; 4 is the average.
I work from home to avoid disturbances. If you are based in an office environment, see if management will allow you to work from home during your most productive time. The daily commute to the office can undo the benefits of yoga and meditation. After you drive through traffic and hit all of that office noise, your brain may be so stressed that the benefits of meditation disappear. You will probably be more productive working from home.
11 AM to 1 PM: Gym, Lunch, and Shopping
I hit the gym every day. John J. Ratey’s book Spark: The Revolutionary New Science of Exercise and the Brain make a good argument for daily exercise so if you want the science behind why brain functions improve when you exercise read this book. Don’t try to do the same work out or even go to the same gym every day. I do yoga 3 days a week at a yoga studio, and spinning classes 2 days at a spinning studio and I do weights 2 days at my gym, where I have a trainer. Having some someone to push me is the best motivation so this is where a trainer helps you a lot.
I love the gym because of the extra services. You can take 5 towels with no wife around to complain. You can take a 30 minute shower with no one waiting outside the door and shouting “Are you done yet?”… Which happens a lot at my home.
I also make a point of shopping for groceries every day, usually at the Whole Foods which is walking distance from my house. Why shop every day? In many countries, especially throughout Asia, people shop for groceries every day instead of buying two weeks’ worth of stuff to store in the freezer and the fridge. This way, you buy only what you need and cut back on waste. How many times have you found some something unidentifiable in the back of your fridge or freezer and wondered if it was more than six months old? I grab lunch while I’m out. Whole Foods has a nice salad bar. Since I love Japanese food, I will sometimes hit my favorite joint for some sushi or a bento box.
1 PM to 6 PM: Learning and Talking Time
I try to stack my appointments so I do not have to drive to work every day. Usually, this time involves meetings, interviewing candidates, presentations, mentoring developers, code reviews etc. I do not do any coding during this time unless there are an urgent bug fixes or fires to put out.
I also dedicate significant time to learning. I spend a lot of time reading other people’s stuff, everything from books to blogs to code base related to technology and neurosciences I try to learn something new every day. The best way to stay motivated and on track is to write few lines of notes on each subject and then bookmark any references. Software like EverNote it is good for that.
Also look at what other products are on the market, the most productive software developer is someone who writes zero lines of code to solve a problem. I do not want to reinvent the wheel if someone else has done the work. This is where spending time on CodePlex, GitHub and Component Source helps.
I have taken a lesson from my wife’s experience during her medical internship. Every morning the new doctors spend time with patients. Then, in the afternoon, they all gather to discuss the complications they encountered and how they solved problems. In my case I try to conduct a post-mortem on my activities. I examine where I got stuck when I was coding in the morning, where I was chasing a bug or how I did a presentation, handled a meeting and so on. I try to learn from my mistakes and avoid repeating them.
6 PM to 8.00 PM: Family Time
My wife is a doctor and has a busy schedule but we do our best to spend this time as a family. We try to make dinner together. Then I work with my kid on his homework. (It’s amazing the amount of homework a 2nd grader gets, but that’s a blog topic for later.)
8.00 PM to 8.30: Reflection and Brain Work
I do not meditate in the evening. Instead, I sit down and reflect on the whole day. It’s amazing how much you learn and improve if you spend 15 minutes just sitting in a quiet place and reflecting on your day.
Next I create some work for my brain. It’s a well-known fact that the brain works as we sleep. So it’s best to assign it some work. For me, the following has been working well: I make a bulleted list of the things I need to write in the morning. I think of them like tags. I find it best to write it down instead of typing on the computer.
Alternately, I look at some programming / algorithmic issues. Again, I write or sketch it down. It’s amazing how often I end up with a solution the next morning! For these tasks I keep a nice, unlined, letter-size notebook. Something about writing on a blank sheet of white paper makes me more creative. I hit the bed between 8.30 PM to 9 PM. The earlier the better.
So that’s my daily schedule. It changes when I travel, of course; I spend a lot of time on the road for work. I have also not covered what I do on the weekends. But we’ll get to those things in future posts.
I would love to hear from others on what type of schedule they keep and what they find productive.
Jan-11 Edit : It looks like I am not the only one who gets up at 4.30 AM. 23 Successful People Who Wake Up Really Early
2012年6月4日 星期一
2012年5月31日 星期四
How tech companies are interconnected
Sarah Kessler and Nick Sigler examine the interconnectedness between major tech companies. I think this might be the beginnings of a tech version of Six Degrees of Kevin Bacon.
via flowingdata.com
2012年5月30日 星期三
2012年5月21日 星期一
2012年5月18日 星期五
Comparing the Value of the Largest Online Display Advertising Networks [INFOGRAPHIC]
via wordstream.com
Facebook IPO: Can Facebook Beat the How Much Is Facebook Really Worth? Comparing Facebook Advertising vs. Google Display Network
2012年5月16日 星期三
2012年5月15日 星期二
2012年5月11日 星期五
How Social Sites Make Money [infographic]
We turn to social media services to stay connected more and more each day. But even with hordes of devoted followers, how do these social sites manage to turn a profit?
2012年5月10日 星期四
Wake Up Call – If You Spend It, They Will Come [INFOGRAPHIC]
via app-promo.com
Maybe it would be more helpful, if the results were grouped by platform. anyway, it's great work.
2012年5月9日 星期三
INFOGRAPHIC: Social media - The why - Advertising, Branding, Marketing
infographic – social media – the why – media panther blog
訂閱：
文章 (Atom)
