I have 2 signs above my desk.

One says, "It doesn't matter". This is for when I get so stressed out, I have trouble doing anything. It helps keep things in perspective.

The other says, "Jabez Wolffe". His guide boat forced him to abandon his swim across the English Channel because they couldn't see through the darkness and fog, and it was too dangerous to continue. What they didn't realize was that they were only 100 yards from shore, but they had no way of knowing.

How far from shore are you?

I would suggest doing whatever you can to find out before making any decision.

[Aside: Please contact me off-line. I am in a similar situation and would like to talk.]

Original thread:  http://news.ycombinator.com/item?id=675256

Papa Bear:

  for(i=ii;i<iii;i++){
    for(j=jj;j<jjj;j++){
      for(k=kk;k<kkk;k++){
        doSomething();
      }
    }
  }

Mama Bear:

  for(YearCounter=FirstYearOfCycle;YearCounter<LastYearOfCycle;YearCounter++){
    for(MonthCounter=FirstMonthOfYear;MonthCounter<LastMonthOfYear;MonthCounter++){
      for(DayCounter=FirstDayOfMonth;DayCounter<LastDayOfMonth;DayCounter++){
        doSomething();
      }
    }
  }

Baby Bear:

  for(Year=FromYear;Year<ThruYear;Year++){
    for(Month=FromMonth;Month<ThruMonth;Month++){
      for(Day=FromDay;Day<ThruDay;Day++){
        doSomething();
      }
    }
  }
 
Original thread:  http://news.ycombinator.com/item?id=839675

I absolutely love what I do and can't imagine doing anything else.

However...I have had very few jobs where I was happy. I think there are 2 primary 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. (OTOH, 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.

There are lots of other things most of us don't like (difficult people, crappy code to maintain, poor management, difficult deadlines, etc.), but those are all part of the territory. I could live with them if I could work on what I want when I want.

Original thread:  http://news.ycombinator.com/item?id=673737

"Domestic animals give love freely to the least deserving, but their lives are short and their ends are often brutal. And it’s worth it. It is all worth it. Every day, even a sad day blurred by headaches and filled with business meetings, is magical and infinite."

I know this is hn, but thanks for the great thoughts.

This is the first time I have talked about this...

On October 8, 1991, we found a box on our front porch containing a kitten and a note, "Please take care of me." We named her Sarah.

Sarah was a cat who acted like a dog. Every time I came home, she came running to the car, screaming for me the whole way. She sat on my lap every single day as I wrote thousands of lines of code. She was my best friend and companion for years, longer than any human.

This past February, Sarah had started walking into walls. My vet thought she was going blind, a different reason for each eye. We started treatment immediately. She didn't sit with me when I worked anymore.

Then on March 8, 2010, I was in the middle of an intense piece of work and took my eye off her for 5 minutes. She walked off the balcony and fell to the driveway below. Her injuries were too much; she had to be put down.

I was surprised at how I reacted, inconsolable and unable to function for about a week. I sat at my terminal, but for the first time in my life, no code came out.

OP was right. Our companions can be magical and mystical. And no matter how much it hurt, it was definitely worth it.

The code is flowing again like it did for years with Sarah on my lap. Except now, it's her urn beside me, between my laptop and my monitor. Tonight was the first time I smiled about it. Thank you, OP.

Original thread:  http://news.ycombinator.com/item?id=1339413

1. Do not have access to the internet on your work machine. If you don't have 2 computers, get a netbook 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. OTOH, if your 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. More about that:

http://news.ycombinator.com/item?id=191275

4. Never text or IM when working. Have the cell phone nearby only for emergencies. For email, go to the other computer once an hour (see #1 above).

5. Try 48 minutes on, 12 minutes off. For long coding sessions, this works pretty well for me:

http://successbeginstoday.org/wordpress/2006/09/the-power-of...

6. Ipod.

Original thread:  http://news.ycombinator.com/item?id=869034

I agree with OP's assessment of the enterprise world; I do not come to the same conclusions.

I have been on both sides of the enterprise software sale many times and have concluded that a) it always sucks and b) it's rarely in anyone's best interest.

So instead of examining the current model and making suggestions for accommodating or improving it, I prefer to suggest an alternative.

I believe the best way to crack the enterprise software market is the same way to eat an elephant: one bite at a time through the soft underbelly...

Find a critical business function being done in Excel and provide an alternative web app.

Find a "business within a business" and automate it with modern technology. (Examples are small independent business units, warehouses, job shops, sample shops, anything a user has set up that can be autonomous.)

Provide a modern satellite system to augment and integrate with an existing enterprise monster. (A separate module for one function like payroll or fixed assets, special processes for marketing, engineering, manufacturing, etc.) The possibilities are endless. Somebody is not getting what they need out of SAP, Oracle, or whatever.

Provide a separate business unit with everything they need. This may be cheaper than the customer adding more licenses to their ERP system.

The key to this approach is staying under corporate IT's radar. The way to do that is by keeping your prices below your customer's boss's threshold.

How do I know this can work? Because it has, many times. I have implemented dozens of apps in enterprises that they thought they could never have because of the existing software and sales model.

And I remember history. At one time, IT departments were very threatened by PC's. They challenged their ivory tower with a mainframe and dumb terminals. So users just bought their own PCs from their expense budgets and forced IT's hand.

Lightning can strike twice. Users are once again tired of waiting 18 months for a fix and are ripe for a custom 37signals type of solution. Let the app rush begin.

Original thread:  http://news.ycombinator.com/item?id=760570

Very fast. Let me explain.

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

Mode B is generally much slower. Reviewing code, specs, or notes.
Refactoring code. Laying things out with pen and paper. When I have
enough work clearly laid out, I know it's time to get back to the
computer and return to Mode A.

The most important thing for me in Mode A is to see results, any
results, quickly and often. It doesn't matter how correct anything is,
just as long as it's progress (or sometimes, reverse progress). I like
to think of programming as making incremental progress in micro jumps,
evaluate where I'm at, and go for the next micro jump.

Some of the best advice I ever got was from a prolific artist friend
of mine who claimed, "I paint every day." So I started coding every
day. But that wasn't enough. Now I make progress every day.

There are many definitions of progress. Sometimes I copy a few hundred
lines of code, make a few changes, spit out a new app, and then start
applying micro changes. Other times I decide that I need to see
today and find a way to get there. Things don't always work out as
planned, but that's OK. As long as tomorrow's starting point is beyond
today's, I'm satisfied.

That's my definition of fast. Not sure that was what you were asking,
but I hope that paints you an accurate picture.

* * *

Follow up response to "I've never seen anyone able to design something
away from keyboard that doesn't change significantly once it's
written"

It does change once it's written.

The idea is to get a clear work plan on a "close enough" design. I
estimate that my first cut of anything is maybe 50% or so.

The idea is also to avoid sitting at the computer all day and then
being disappointed with how little I accomplished. Activity !=
accomplishment.

A little more background...

First term freshman year, 90% of science students took Chemistry I. On
Mondays and Wednesdays, only 50% of the seats in the dining room were
taken for dinner. Chem Lab started at 1:00 p.m. and dinner was at 6:00
p.m. So, most freshman chemistry students took more than 5 hours to
complete their lab work.

This never made sense to me. I took Chemistry I second term freshman
year. My lab partner and I made a pact to never miss dinner. We did
everything we possibility could to expedite lab time. We did all the
reading, planning, and reviewing other people's results before we
entered the lab. We even wrote our reports in advance, filling in the
results as we went. Our longest lab took 2 1/2 hours. Our shortest
took 1 1/4 hour. (We also both got A+.)

I still practice that methodology today. My computer is my lab and my
bed or sofa is my lab prep. Preparation takes as long as it needs.
Labs go fast. If they don't it's because I wasn't prepared enough when
I started.

Original thread: http://news.ycombinator.com/item?id=1544338

I have a simple guideline for real life interactions with others that carries over quite well on-line, "Deal with issues; ignore details."

It's amazing how well this works in person, especially when trying to get something done. My number one question to another is probably, "Is that an issue or a detail?" We can almost always decide together which it is. Then, if it's an issue, we deal with it, and if it's a detail, we move on to the next issue.

This has also saved me countless hours and aggravation on-line. If I post something and someone disagrees, I quickly decide whether or not it's really an issue and only engage the other if it is. I realize that this is just a judgment call, but I'd estimate about 90% of on-line disagreements are just details. In these cases, I think it's best to simply move on.

Original thread:  http://news.ycombinator.com/item?id=1057133

The single most important thing I do to "achieve laser focus and concentration" is to work in such a way that I don't need "laser focus and concentration" 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.

All analysis, design, and refactoring must be done at this time. I do not allow myself to sleep until the next day's work is laid out. I also do not allow myself to get back onto the computer. The idea is to have a clear "vision" of what I am going to accomplish the next day. The clearer the better.

This does 2 things. First, I think about it all night (maybe even dream about it). Second, I can't wait to get started the next day.

I always wake up and start programming immediately. Once I get going, it's easy to keep going. Any difficulties are probably because I didn't plan well enough the night before.

Not sure if that's the answer you're looking for, but whatever gets the work done...

Original thread:  http://news.ycombinator.com/item?id=191199

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.

Once he even spent a week of his own time on third shift, going over procedures and reports with factory supervisors. They didn't know who he was; they just figured someone from the main office sent him. He did a complete analysis in Excel which we used in a proposal. That got us hundreds of thousands of dollars worth of work.

I often challenged him, "You can't just do that," I would say. To which he would respond, "These people need help and don't even realize it. We have to find a way to show them." Then the inevitable, "It's better to beg for forgiveness than ask for permission."

Looking back, it didn't always work. It pissed off some people and burnt those bridges. But when it did work, we often concluded that nothing else would have.

I learned a lot in those days. I'm still not as fearless as my partner was, but I'd like to think I'm getting there. Thanks for the memories.

Original thread:  http://news.ycombinator.com/item?id=1435342