There are 10 ticks per second.

What did you do with the half floppy? Hold files less than 180K?

>First, your personal assets are shielded from
>liability from business problems you might
>encounter, this is a litigious society after all.

Not really. If you do something stupid then piercing the S-Corp layer isn't that hard. At the end of the day you are really a sole proprietor, and having paid a few hundred bucks to file some paperwork isn't going to work any magic in court.

>One of the best tax benefits is that I can legally
>cut my SS and medicare taxation by a huge amount.

This would work if the owner of the S-Corp was someone else. As the sole owner of the S-Corp and the only person who does any work for the S-Corp then you are deemed to be an "active" owner. You owe SS and Medicare on all of the income, including the pass through income. You may not report the income this way, but you should be. I'm guessing you haven't been audited yet.

> [writing off mileage and other stuff]

You can do all of that without being an S-Corp. It goes on Schedule C.

> [health care options]

I have great health care through my spouse, so I've never looked into this.

There may be good reasons to incorporate, but I haven't seen any (for my situation at least). Having an S-Corp does make your tax avoidance strategy appear somewhat legit. Without the S-Corp there would be no way to even pretend that you don't owe the SS and Medicare tax. I'm afraid though that the IRS will force you to stop pretending once you get audited. Good luck.

Reasonable advice, except for the part about incorporating. As an individual consultant it will make little or no difference in taxes or retirement plans whether you incorporate or not. And incorporating just adds another layer of paperwork.

I happen to be 39 myself, have worked at home as a consultant the past 18 years or so, and have never found any compelling reason to incorporate.

I just turned 39. I have BS and MS degrees in Computer Science from MIT (1988-1993). Before today, I had never heard the term "Liskov Substitution Principle," though of course I understand, use, and rely upon it every day.

The LSP is not mentioned in the index of my copy of "Abstraction and Specification in Program Development" (Liskov and Guttag). Btw, I never had Prof. Liskov as a teacher. Guttag taught 6.170 when I took it.

I don't use an on-screen calculator, you insensitive clod.

You are correct; I do not get bug reports directly from users. They are filtered through people who are very knowledgeable about the product. That said, any actual bug is always sent to me. I define a bug to be crashing or any obviously bad behavior as well as a feature not behaving how we claim it should. "Make application play alert sound when Foo happens" is not a bug, it is a feature request.

We get very few actual bug reports, and when we do get them I almost always fix them within a day or so of receiving the report. Why is that so hard to believe? This is a product that has been evolving for over 15 years and I am the only person who has ever worked on the software parts of it.

I believe that "the long run" is, at most, a couple of years. If your application is a prototype, or a proof of concept, or something you are building to convince some VCs to fund your idea then you may be right.

If you are building something that will be used for many years, will evolve over those years, and must be very reliable during all of those years then I believe that the best thing to do is to have a very strict "everything must be understood" policy.

I won't say exactly what the product is, but I'll describe it. It consists of ~10k lines of code that run on a custom piece of embedded hardware plus a desktop application (to control the hardware) consisting of ~120k lines of code.

While true, that's not the point. ;)

The point is that a focus on writing excellent code in the first place and then fully understanding and fixing bugs when they are discovered results in a much better product. I don't think many organizations stress *fully* understanding all observed behavior.

Far too many programmers see things that make them say "huh, that's odd" and then never investigate. I'm not sure whose fault that is (the programmer's or management's) but it is a serious problem. In my 20+ years of professional programming there have been fewer than 5 occasions when I didn't (eventually) fully understand some observed behavior. For some people that happens 5 times a month.

It's not that I'm some genius. Sometimes it takes quite a while to figure out what is going on. The important thing is to keep investigating. (And the important thing for management to do is let you keep investigating.) Fully understanding something always pays off in the long run.

You are absolutely correct. I have the luxury of being the only person who has worked on this project since its inception 17 years ago. When a bug is reported, I can usually figure out what is causing it within 5-30 minutes. In a similar amount of time it is usually fixed.

A large multi-programmer project is very different.

The most widely used application is used by thousands of people in over 50 countries. I consider it a "project of substance." :)

I fix bugs as they are reported. There are currently 0 outstanding bugs in the various software projects that I maintain.

Your writing (spelling, grammar, etc.) may be contributing to your lack of success. Seriously.

>but you probably have SDSL

Correct.

>and you get an SLA. and IP space, with reverse
>DNS control, and proper support. and and and...
>you've got 16 IPs

No SLA, but I get the rest.

>who is your provider?

One Communications.