This question reminds me of the greatest cook ever, my grandmother. She used no technology whatsoever. All of her tools had been her mother's which were probably manufactured in the 1800s. She chopped everything by hand in a wooden bowl. If anyone else helped her with the chopping, everyone at dinner could tell. She never used pencil or paper and measured nothing. She stood in line at the farmer's market, the butcher, or the grocery store and inspected every item. And absolutely nothing I have ever eaten since, in any restaurant or home, has been remotely close to hers. It was magnificent! And I miss it so much.
I'd like to think I have almost as much passion about my work. I use the most primitive tools, 24 x 80 green screen editor, no framework, no IDE, no debugger, and mostly pencil and paper. I savor every byte just as I imagine my grandmother savored every little detail of her cooking. I'm not trying to save time or be fast, I just aspire to creating Grandma-quality software. I only hope my software brings someone the same joy her food brought all of us.
I've used many different tools. And I rarely care how fancy they are. Ironically, the simpler, the more joy I have found along the way.
I work in 2 modes: (A) At the computer and (B) Away from the computer.
When I'm in Mode A at the computer, I'm cranking out lines of code, testing, revising, testing, revising, etc. This process must be very fast. Several hundred lines of code (or whatever) in less than an hour. A complete cycle in less than a couple of hours. My guideline is that if I'm not working that fast, then I must not be prepared to work that fast, so I don't deserve to be at the computer. I should be in mode (B).
1. Tools. I generally shy away from tools. I just don't like using anything that makes me more productive when I'm programming. I prefer to type out every line of code, occasionally cutting and pasting from the same program or something similar from the past, but not very often. I want the writing of code to be painstakingly slow and deliberate. Why? Because productivity is not the objective. Becoming one with my project is. I may not start as fast as others, but that doesn't matter. It's not how fast you start. It's how soon you deliver a quality product. Like memorizing a speech, cranking out the code by hand makes it firmware in my brain. It's not unusual for me to crank out 300 lines of code and then be able to reenter them on another machine from memory. So when it comes time to debug, refactor, enhance, or rework, those cycles go very quickly; that code is already in my brain's RAM and it got there the hard way.
Wanna know the biggest difference between you and me? I'm pulled. You're pushed. Let me explain:
I love building stuff. Nothing gives me a bigger rush than getting something working the first time. But I couldn't care less about the technology. If an abacus, two tin cans on a string, or some BASIC code on a Kaypro II did the job, then that's what I'd use.
What I really care about is how my software is used. And who uses it. There's an endless stream of people who need stuff and an endless stream of problems to solve. For individuals, groups, and businesses. When I encounter a new problem to work on, I use whatever I can apply in my tool box. Sure, I have to upgrade that tool box every so often because I need more to solve my problems, not because I love the toys so much.
"Work effective hours, not necessarily long hours:"
The best trick I have ever figured out for doing this is to separate all activities into "in front on my computer" and "away from my computer". If you are working ineffectively in either mode, switch modes. If you are still working ineffectively, consider a break.
I often sit in front of my computer, writing code, refactoring, or testing and realize that I'm getting nowhere. Then I conclude that the reason I'm not making progress is because I'm not quite sure "what" to do.
- Decouple analysis from coding. There are some things that should NOT be done in front of a terminal. Get a pencil and paper and go somewhere else. By the time you're done, you'll have plenty of stuff to code. (I have found that the main reason I get stuck is because I haven't spent enough time away from the terminal laying things out. I'm always in too much of a hurry to get back to work before I'm ready.)
- Get a customer. They'll give you something specific to work on. If it's maintenance, all the more reason to get to just dig in and get to work.
I absolutely love what I do and can't imagine doing anything else. However, I've had very few jobs where I was happy. I think there are 2 main reasons.
1. I want to work on what I want to work on. When I work on anything else, all I can think about is what I really want to work on. In a job situation, I rarely work on what I want. (On the other hand, a job that has me working on what I want is usually a great job.)
2. I want to work when I want to work. Sometimes, 8 to 5 works, often it doesn't. We were simply not meant to sit in cubicles without windows all day long. Enough said.
I like to keep it simple. My list has 1 item on it. I work on that until either it's done (often) or I struggle so much with it that I decide to change plans (rarely).
For the last 2 days, I've been writing a model configurator that explodes input parameters into individual objects. I probably have 8 or 9 things dependent on this (not really sure yet), so I plug away until done. Then I'll figure out the new only thing on my list.
I've tried every conceivable productivity hack and nothing has worked as well as this. I have scratch pads, paper on the wall, 20 colors of markers, and all kinds of automated tools for scheduling and planning. I've varied my diet, my exercise routine, my daily routine, and almost anything else I could vary, and none of it really mattered. All it ever really did was take focus away from the real task at hand.
The single most important thing I do to "boost creativity and/or productivity" is to work in such a way that I don't need to "boost creativity and/or productivity" to get my work done. This has to be done the night before.
I always quit all online work at least 2 hours before bedtime and print whatever I'm working on.
Then I go into any other room with program listings, blank paper, and pens (especially red!) and plan out all of tomorrow's work.
1. Do not have access to the internet on your work machine. If you don't have 2 computers, get a laptop for < $300 and connect it to the internet. They should be in 2 different workstations, ideally in 2 different rooms. The thinking is that if you have to get up, you'll only do it if it's really necessary. It works pretty well.
2. You should have 2 modes: coding and not coding. For coding, you should be at your desk coding. For not coding you can be anywhere, but not at your desk. One of my biggest problems is that I often find myself in one mode when I should be in the other. If you're having trouble writing code, then you probably don't know what to write. Grab source code listings, pen, & paper and get away from your computer. Don't come back until you know exactly what you're going to be working on. Better yet, until you're dying to work on it. On the other hand, if you're doing analysis and are stuck, stop. Go back to the computer and code something, anything small, just to get going.
3. End every day in analysis mode. Don't go to sleep until you have tomorrow's plan ready. You should wake up knowing exactly what you're going to be working on and excited to do it.
My single biggest secret for continuing to get things done, often working 12 hour days and 6 day weeks, is to love what I do.
I do not think of it as "work", as something to "get through", or as something difficult, unusual, "overload", or temporary. Quite simply, I sit at my computer 12 hours per day, every day, because "I want to", I love what I do, and I can't imagine doing anything else. I have been working like this for years.
In fact, I feel sorry for anyone else who doesn't feel this way. What a sad life to be spending so much time doing something that you have to force yourself to do.
"In addition to the usual work-day schedule, I expect all of the members of the group to work evenings and weekends. You will find that this is the norm here at Caltech."
Then you're doing it wrong at Caltech.
We are often quick to assume that MoreHoursWorked = MoreWorkGettingDone. This is true up to a point, but false beyond that point. Personally, I believe that evenings and weekends are usually beyond that point.
This reminds me of my first partner in our software/consulting service business. He was absolutely fearless.
We would always arrive at appointments very early so he had an excuse to "poke around". He'd ask anybody, the receptionist, someone in the breakroom, even the janitor. He'd see what was going on in the parking lot, the loading dock, even in the warehouse or factory. Seeing him in a business for the first time was like watching a kid in a candy store.
In our first meeting, he always knew something about the client's business that they didn't. He'd say things like, "Automating the inventory won't help if Fred and Jean are counting 2 different things." This always led to interesting discussion and often, follow-up business.
Maybe "boring" is not the best word. Maybe we are really talking about "more fun" vs. "less fun".
Naturally, some things are more fun than others, but I am never bored in my startup. Frustrated sometimes, yes. This week I lost a whole day because I had overlooked something simple one day last week. Had to retool the whole stupid thing when I really wanted to build the next level up. So the exciting part had to wait a day. No big deal. It happens. But was I ever "bored"? Hardly.
A little background. I sat in class bored to tears for 17 years. Then, I did work in 80 other companies (none of them mine) before I started this one. I have a clear vision of what I want and a fairly clear idea of how things should work. I love both the technical details and the people part. Usually, I can't wait to get to the next thing.
My solution? I simply stopped worrying about how much time I spent doing or not doing something.
I started focusing on one thing only: the delta between what I planned to have complete at the end of each day vs. what I actually completed that day.
On Thursday, my plan was to have items A, B, and C complete before I knocked off. A & B were done by noon. I overlooked 2 prerequisites for C and had to go back and do them, then do C, which took twice as long as I expected. I didn't finish until 2 a.m. I also spent x hours on line. So what?
You can have an interesting idea any time. The problem is that you may not even realize that you just had an interesting idea when you had it.
The journal is an excellent idea. I write everything down. When I look it over later, I'm usually embarrassed that I could have thought of anything so lame. But every once in a while, there are a few gems in there.
I always have pencil and a small notebook next to the bed. The best time for me to get good ideas is as soon as I wake up. The second best time is right before I go to sleep. I carry index cards and a pen at all times during the day, just in case.
Tell you why I don't like syntax highlighting (or any crutch). Ever since I read the chapter about Woz in Founders at Work. The thing that he thought made him so successful designing the Apple II: he knew every single little part of it intimately, like the back of his hand. That struck me like a lightning bolt. So that's how I feel about my code now.
If I want to do something, I read and reread and reread it over and over and over until I practically memorize it. THEN it's part of MY firmware, and that's when I really get insightful and productive. IDE's, syntax highlighting, etc. are just crutches that keep my real "programming muscles" from developing. I won't use them. Black and green is all I know.
Similarly: I used to know every phone number I ever needed by heart until speed dial came out. One day last year, I had the very frightening experience of not being able to call a regular number from someone else's phone. I have never used speed dial since. Anything that impedes my "brain exercise" is something I do without.
This is a hard and fast rule that I have always followed and is absolutely critical to my success. Just a few of the reasons:
1. I firmly believe that analysis, design, and planning is much more effective if it is done away from the computer. These are totally different activities from programming and they take a different mindset and environment. That's pretty tough to do if you use computerized tools to organize.
I love email. Why? Because I'm a programmer and I don't want to be interrupted. I like to keep the day-to-day things simple because my work is anything but simple.
I use gmail and everyone I know has my gmail address. It has excellent spam filters and it's easy to manage. Best of all, it never bothers me. When I'm ready for a break, I check and manage my email. It takes 5 minutes, just enough time to eat an apple.
Family, close friends, and some business associates have my cell phone #. They know not to text me because if I'm working, I will not respond. If I'm not working, the only response they'll get is "ok". If the phone rings, I know it must be important to talk. Usually not for long, then back to work.
I prefer to sit with my users. As you can imagine, this concept is met with a bit of resistance in corporate America.
I want to dwell with them and be a part of their lives. I want to hear them complain about their applications, their customers and vendors, their bosses, and each other. I want to know what they go through all day every day.
When I sit and suffer with them, the resulting software is always better. All the meetings, prototypes, demos, specs, etc., etc., etc. have never been able to deliver the same knowledge needed to develop their apps.
Some people advocate: 1) private offices for each programmer, 2) free, nicely catered lunch every day (everyone eats together and bonds), 3) usual internet stuff - comfortable office, dogs, flexible schedules etc.
On one hand, a little voice inside of me cries, "Yes! This is what it takes to produce great software: a programmer-appreciative environment."
On the other hand, another little voice claims, "This stuff is all well and good, but nothing more. It's cosmetic, not functional, like putting perfume on a pig."
I guess this is why I never post in language threads, we can go on and on all day. No one is right or wrong.
Anyway, I'll try to address your comments.
There are so many different versions of BASIC; it's possible we are visualizing very different versions. I am accustomed to using INFOBASIC dialects as in JBase or IBM'S U2 line. Everything numeric is represented as strings (integers) including dates, times, and decimals, so there is no typing.
- I impose discipline upon others. Since you can't just poke your head in with an idea, you have to think about it first (imagine that). If your email doesn't include enough data for me, I say so and hit "reply". Same for phone calls and voice mails. Signal to noise ratio increases dramatically.
- My performance metric is WorkCompleted / WorkPlanned because that's all people can witness. Not 101 other meaningless metrics like number of sessions running, time spent on internet, time spent BSing, time spent on cell phone, time spent at lunch, shirt color, or droplets of sweat on forehead.
- Wake up at xx:34 a.m. Start work at xx:37 a.m. (if I want to).
It's fantastic. It was built by Andrew Carnegie in 1895 and most of it is original. I get inspiration from the 20 foot ceilings and handmade ornamentation everywhere you look. They simply don't build things like this anymore. There are quiet reading rooms, large tables, plenty of light, and oh yeah, a Crazy Mocha coffee shop in the building. I use a cell phone dongle on my laptop and most people know that email is my preferred communication method.