Just listen to the talks and forget about taking any notes. You'll enjoy the talk more and your mind will be more open to creative thought. If you need to remember some detail later you can go back and look at the proceedings or email the speaker.
>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.
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.
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.
Ahh, the standard (and useless) analogy to civil (or mechanical) engineering. The things that civil and mechanical engineers make are trivial compared to software engineering. Why? It is simple. They have to *build* what they design in the real, physical world. The building part is hard, but the designing is easy.
Look at a bridge. Very simple. You take big, heavy, strong things and stack them up vertically and horizontally until you have something you can drive across. Or maybe you get "clever" and string a huge bundle of steel cable across a span and hang the big, heavy, strong things from the cable. The design is simple, the building is hard.
We in software engineering aren't constrained by having to build anything physical, so we can design things that are incredibly complex. The design is hard, the building is simple.
What you say is catchy, and sounds like it should be true, but it isn't.
When great programmers are creating truly great (and novel) applications the time to learn, fix, and modify someone else's code to do what you want it to do is similar to writing your own code. And in the end, if you are a great programmer, the code you write yourself will be better than what you found and then had to fix/modify.
Of course I'm not talking about re-writing a TCP/IP stack, a NIC driver, a graphics library, a thread scheduler, or the like. I did all of those things in part because I enjoyed it (I was sort of on a sabbatical) and in part because I knew it would pay off for me in the long run (I've already used my embedded OS on two substantial projects).
But this myth that whatever you are doing must have 90% of the code already written somewhere "out there" is just that, a myth. Yes, if you are doing something boring that is 90% just like a bunch of other things that other people have done then maybe that's true. For what I do, it is not true.
>So, you take the time to rewrite things like stdio?
For embedded work, yes. I have written my own embedded OS which includes my own style of streams, binary and formatted I/O, plus everything that you would build on top of streams (like serial I/O, TCP/IP, disk I/O, pipes, etc).
The only things I think I haven't written myself for my embedded work are the occasional math function (sqrt, atan, etc). For that, I've used the standard C library implementations.
>I am mostly an Assembly Language programmer and >it can teach some bad habits. I don't generally >trust anybody else's code...
I find that (not trusting other people's code) to be a good thing, no matter what language/platform you are using. I use assembly, C, and C++ for embedded and desktop programming. To the greatest extent possible I write all code myself.
For x86 embedded work, that means writing the MBR (and everything else on up) myself. For Win32 work, that means using a basic application framework that someone else wrote (and I've spent 13 years fixing and improving) and doing pretty much everything else by myself. (To be fair, I also use the IJG library for JPEG encoding/decoding. The IJG library is good stuff.)
Low latency and consistent speed can be just as important (or more important, depending on your use) as maximum speed.
I pay $135/month for a 1.5mbps synchronous connection in the United States. On the face of it that seems ridiculously expensive for what I'm getting. But that includes a/28 block of static IP addresses and the connection is *always* that fast. There are no slow times. There are no problems. (The longest "outage" I've seen in the past 6 months is about 5-10 seconds, and that's been 2 or 3 times.)
Of course I wish (like everybody) that my connection was faster. But I'll take a connection that always works and always delivers low latency and moderate speed over one that goes fast sometimes and slow (or worse, fails) other times.
Slashdot Mirror
Just listen to the talks and forget about taking any notes. You'll enjoy the talk more and your mind will be more open to creative thought. If you need to remember some detail later you can go back and look at the proceedings or email the speaker.
There are 10 ticks per second.
>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.
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.
Ahh, the standard (and useless) analogy to civil (or mechanical) engineering. The things that civil and mechanical engineers make are trivial compared to software engineering. Why? It is simple. They have to *build* what they design in the real, physical world. The building part is hard, but the designing is easy.
Look at a bridge. Very simple. You take big, heavy, strong things and stack them up vertically and horizontally until you have something you can drive across. Or maybe you get "clever" and string a huge bundle of steel cable across a span and hang the big, heavy, strong things from the cable. The design is simple, the building is hard.
We in software engineering aren't constrained by having to build anything physical, so we can design things that are incredibly complex. The design is hard, the building is simple.
Nicely said.
What you say is catchy, and sounds like it should be true, but it isn't.
When great programmers are creating truly great (and novel) applications the time to learn, fix, and modify someone else's code to do what you want it to do is similar to writing your own code. And in the end, if you are a great programmer, the code you write yourself will be better than what you found and then had to fix/modify.
Of course I'm not talking about re-writing a TCP/IP stack, a NIC driver, a graphics library, a thread scheduler, or the like. I did all of those things in part because I enjoyed it (I was sort of on a sabbatical) and in part because I knew it would pay off for me in the long run (I've already used my embedded OS on two substantial projects).
But this myth that whatever you are doing must have 90% of the code already written somewhere "out there" is just that, a myth. Yes, if you are doing something boring that is 90% just like a bunch of other things that other people have done then maybe that's true. For what I do, it is not true.
>So, you take the time to rewrite things like stdio?
For embedded work, yes. I have written my own embedded OS which includes my own style of streams, binary and formatted I/O, plus everything that you would build on top of streams (like serial I/O, TCP/IP, disk I/O, pipes, etc).
The only things I think I haven't written myself for my embedded work are the occasional math function (sqrt, atan, etc). For that, I've used the standard C library implementations.
>Can you compile C++ down small enough to use
>in embedded devices?
I use C++ (GCC) for embedded use. With these compiler flags you get sufficiently small (by x86 embedded standards) code:
-I. -O2 -fomit-frame-pointer -fno-rtti -fno-exceptions
>I am mostly an Assembly Language programmer and
>it can teach some bad habits. I don't generally
>trust anybody else's code...
I find that (not trusting other people's code) to be a good thing, no matter what language/platform you are using. I use assembly, C, and C++ for embedded and desktop programming. To the greatest extent possible I write all code myself.
For x86 embedded work, that means writing the MBR (and everything else on up) myself. For Win32 work, that means using a basic application framework that someone else wrote (and I've spent 13 years fixing and improving) and doing pretty much everything else by myself. (To be fair, I also use the IJG library for JPEG encoding/decoding. The IJG library is good stuff.)
>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.
Low latency and consistent speed can be just as important (or more important, depending on your use) as maximum speed.
I pay $135/month for a 1.5mbps synchronous connection in the United States. On the face of it that seems ridiculously expensive for what I'm getting. But that includes a /28 block of static IP addresses and the connection is *always* that fast. There are no slow times. There are no problems. (The longest "outage" I've seen in the past 6 months is about 5-10 seconds, and that's been 2 or 3 times.)
Of course I wish (like everybody) that my connection was faster. But I'll take a connection that always works and always delivers low latency and moderate speed over one that goes fast sometimes and slow (or worse, fails) other times.
Btw, I got an 88%. Would have been 91% if the above question had a correct answer. :)
You are correct, it is None of the Above.
"D" would be correct if it said *average* tax per person equals *average* government spending per person.
"A" would be correct if it said government *deficit* is zero.
The track camera is line scan and the swimming camera is a traditional video camera.
An Israeli company called BreezeNet.