April 2004 - Posts

The Highest Rated Entries
30 April 04 11:54 AM | Scott Mitchell | with no comments

A couple weeks ago I enhanced my blog so that readers could rate blog entries. I even wrote an article with the requisite SQL queries and User Control code and markup on 4Guys: Creating a Content Reader. I decided to take a few minutes out of my day and display the five highest rated articles. If you visit my blog you'll see on the left-hand side, beneath the Post Categories list, is a Top Rated Entries list. It shows the five highest rated entries that have at least three votes, and uses partial page caching so that it only updates twice per hour.

While whipping out this little blog add-on only took a few minutes, I should have known better that I wouldn't be able to just write code without going hog wild and writing an entire article, which stretched that planned five minute break into an hour long break. In any event, you can learn more at my latest 4Guys article, Improving the Content Rater.

Filed under:
What Programs Do You have Running 24x7?
30 April 04 10:23 AM | Scott Mitchell | with no comments

I saw a post yesterday on weblogs.asp.net, I believe, where a poor soul had forgotten to keep Outlook running and therefore hadn't been reminded of a few tasks he had added to Outlook's Calendar. That got me thinking: what computer programs do most folks have running all the time? I doubt most computer users have a certain set of programs that are always running (my parents, for example, turn their computer on whenever they need to use it and back off when they're done), but developers usually have their computers running 24x7, if not for the entire workday. So, during your computer's uptime, what programs are running throughout?

Here are mine:

  • Outlook
  • Explorer
  • .NET Framework SDK Documentation
  • Trillian
  • FeedDemon (been trying it out for a few days now; will probably post a review eventually)
  • Visual Studio
  • SQL Server Enterprise Manager
  • SQL Query Analyzer
  • UltraEdit
  • Mozilla FireFox

When I take off for a couple of days, like on the weekends, I'll shut down Visual Studio and SQL, but the above are pretty much running 24x7.

Filed under:
Adaptive Rendering
29 April 04 12:19 PM | Scott Mitchell | with no comments

After yesterday's post on Panel Weirdness some questions from Milan Negovan prompted me to write an article on how ASP.NET employes adaptive rendering. The HTML markup emitted from a Web control depends on the browser requesting the page.

Behind the scenes, the Page class creates an HtmlTextWriter instance based on the Browser object's TagWriter property. By default, the TagWriter property refers to HtmlTextWriter, which emits HTML 4.0-compliant HTML markup. For non-Microsoft browsers, the Html32TextWriter class is used instead, which emits HTML 3.2-compliant HTML. All of this information, thankfully, is configurable through the <browserCaps> section.

One issue that configuring the <browserCaps> section doesn't address is the validation controls and their client-side validation scripts. This, really, is another can of worms, as the System.Web.UI.WebControls.BaseValidator class annoyingly uses document.all to reference the client-side validator controls. (document.all is not supported in non-Microsoft browsers.) The short of it is that you have to create your own set of validation controls, such as Paul Glavich's DomValidators, which starts from scratch with the creation of a BaseValidator class that uses document.getElementById() instead.

Read the article, A Look at ASP.NET's Adaptive Rendering

Filed under:
Panel Weirdness
28 April 04 12:14 PM | Scott Mitchell | with no comments

I recently responded to a newsgroup post on microsoft.public.dotnet.framework.aspnet.webcontrols that I thought warranted a follow-up comment here. The posters question was:

I have a Panel control containing a few TextBox controls. The Panel is originally enabled, I enter data into the TextBox controls. When I submit, the Panel is disabled during the PostBack and the TextBox controls render greyed-out, and I can see the values in the TextBox controls....this is what I expected.

I submit again, the Panel is enabled during the PostBack. All of the TextBox controls within the Panel are now enabled, however, the values are gone. This doesn't happen with a TextBox control outside of the Panel that is also enabled/disabled.

The post then contained a sample ASP.NET Web page that illustrated the problem. Namely, it had a Panel Web control with a TextBox Web control inside of it, along with a CheckBox and a Button outside of the Panel. When the page was posted back, if the CheckBox was checked the Panel's Enabled property was set to False; if the CheckBox was unchcekd, the Enabled property was set to True.

I started by testing the poster's source code in Mozilla Firefox, my default browser. When the Panel's Enabled property was set to False, the TextBox was still editable and not grayed out, nor did I lose the TextBox value when posting back after it was disabled. Doing a view source illustrated why: the Panel renders as a <table> for downlevel browsers. Setting the Enabled property to False created a table with the attribute disabled=”disabled”.

Switching to IE6, I reran the test and was able to replicate the poster's problem. IE6 renders a Panel as a <div>. When the Panel's Enabled property was set to False, the following HTML markup was generated:

<div id="panelID" disabled="disabled">
<input type="text" name="textboxID" id="textboxID" value="valueEnteredOnLastPostback" />
</div>

Note that the disabled attribute only applies to the <div>, and not the <input>. (This was the case in Firefox, too, except instead of a <div> it was a <table>.) Interestingly, with this HTML markup, IE displays the TextBoxes as grayed out - however, I could edit them! What's really interesting, though, is that when the form is submitted, IE doesn't send back the values of the TextBoxes in the HTTP POST header. I guess it hits the <div>, sees that it is disabled, and then doesn't bother processing the <div>'s inner children. (Firefox always posts back the TextBox value, regardless of the value of the enclosing <table>'s disabled attribute.) Since the TextBox value is not posted back when the Panel is disabled, the TextBox loses its Text property value, resulting in an empty TextBox on postback. The solution to this problem is to explicitly set the TextBox's Enabled property to False - not just the Panel's.

The reason the problem exists is because when a visitor enters a value into a TextBox, and posts back the form, that value is not persisted into the TextBox's view state. Yes, the value is saved to the TextBox's ViewState property, but the view state for the TextBox is only saved if the TextBox's TrackViewState property is set to True. I'm going to gloss over the sticky internal details, but realize that the TextBox does not record its Text property value in its view state if the TextBox is a Password TextBox or if there is not an event handler wired up to the TextBox's TextChanged event. If the Text property is the only property set after the Initialization stage, then the TextBox won't record any view state information. The means by which TextBox's persist their Text values across postback is by having the TextBox value continually posted back in the HTTP POST headers... but when using a disabled <div>, the TextBox value is not posted back.

An astute reader might then counter, “Well, if what you say is true, then why does explicitly setting the TextBox's Enabled property to False make everything work? After all, when the Panel is disabled, the TextBox's value is not being posted back, right?” Right you are, but when you set the Enabled property to False explicitly, that has the side-effect of setting the TextBox's TrackViewState property to True, so both the TextBox's Enabled and Text properties will be persisted to view state, and hence be used to repopulate the TextBox.

A final question readers might have is, “How in the world did you find out all this stuff?” Through the book Developing Microsoft ASP.NET Server Controls; using Reflector to look at the decompiled source code of the System.Web.UI.Control, System.Web.UI.Page, System.Web.UI.WebControls.TextBox, and System.Web.UI.WebControls.WebControl; and using a view state parser (specifically, I used one I will be presenting in an upcoming article on ASP.NET View State on MSDN, but you could use Paul Wilson's View State Parser, or Fritz Onion's ViewState Decoder).

Going Independent - Taxes
27 April 04 02:27 PM | Scott Mitchell | with no comments

This is the third part of an ongoing series on going independent. The aim of these blog entries is not to convince one to stike out on their own, nor is it to encourage one to stay employed. It's merely some food for thought for those considering the transition... Part 1 talked about the pros and cons of being employed vs. being self-employed. Part 2 looked at some of the first steps that one needs to take to go independent. This part will examine tax issues surrounding self-employment.

Here's a riddle: what is the one question you could ask someone to determine if they were self-employed or not (short of asking them directly)?

The answer: Do you think taxes are too high? If you get a ho-hum answer, chances are the person is employed. If the person begins foaming at the mouth and goes on a 20 minute diatribe on taxes, you can bet the person is self-employed. Here's another possible question to ask: How much did you pay in taxes last year? If they don't recall, I'd bet dollars to donuts that they're employed.

Typically employed individuals don't have such a resentment toward taxes because their tax bill is collected for them by their employer before they receive their paycheck. As an employee, your employer withholds a certain percentage of your paycheck each pay period. Once a quarter, your employer sends a big check to the Federal and State governments. At the end of the year, when you fill out your taxes, your amount due is your tax burden less what you have already paid in. Some people naively get excited when they get a "refund" on their taxes - this just means you paid in more than you had to, in essence giving the government an interest-free loan.

When you work for yourself, you are your employer, so you are the one who sends the quarterly checks into the government. For those first making the switch from the employed world to the self-employed world, this process can be a bit of an eye opener. Four times a year you have to sit down and write both the Federal and State government a check. Make sure you have a good estimate of your income and make these payments accurately. If you overestimate, you're giving an interest-free loan to the government. If you underestimate, you have to pay a percentage based on the underestimation. (That is, if you underestimated by, say, $10,000, you might owe the government $10,250 - a $250 penalty for underpaying them during the year).

Additionally, there is employement tax. As an employee you pay income tax and social security / medicare. Your employer pays employment tax. (This is why companies like to hire contractors. As contractors they are not employees, so they don't have to pay them benefits or pay employment tax.) When you work for yourself you must pay self-employment tax. See http://www.irs.gov/businesses/small/article/0,,id=98846,00.html for more info. To quote:

Who Must Pay Self-Employment Tax
You must pay SE tax and file Schedule SE (Form 1040) if either of the following applies.
  1. Your net earnings from self-employment (excluding church employee income ) were $400 or more.
  2. You had church employee income of $108.28 or more.

The big difference in taxes between employed individuals and self-employed individuals, in my opinion, is a psychological one. As an employer, the tax withholdings are nicely taken from your paycheck automatically. It's not like you get paid $x and then have to write a check to Uncle Sam for $x/3. But being self-employed, you have to. Five times a year. (Once every quarter, and once by April 15 if you've not paid enough.) If you're at all like me, it will raise the blood a bit, because you will realize how much you are paying into the system, while others - your employed friends - don't seem to grasp it because their taxes are discretely taken out of their bimonthly paychecks, so they don't see it add up like you do. Furthermore, they aren't burdened by self-employment tax. Furthermore, their company provides health insurance and a retirement plan - those responsibilities are on your butt when you're independent.

The point is, as an employee you kind of live in an "ignorant, but bliss" world. As an independent, you see where every dollar goes - $x to Uncle Sam; $y to health/dental insurance; $z to retirement plan; etc. This is nice in that it breeds efficacy and fiscal awareness, but can be a bit disturbing when transitioning from employed status to independent status. It's like the Matrix - once you take the independent pill, you can't go back. Even if you do return to the employed world, you'll have a better understanding of how much things cost.

Filed under:
Interested in Reviewing Articles?
21 April 04 04:53 PM | Scott Mitchell | with no comments

Do you read MSDN regularly? If so, would you be at all interested in reviewing articles I am working on for MSDN prior to their publication? This would entail reading the article and providing any comments, constructive criticism, and feedback you'd care to share. Being a voluntary effort there'd be no deadlines or demands from me. I'd just send you the article I have completed before sending it off to my editor at MSDN. You'd then have, say, a week to read the article and your liesure and provide any comments/feedback if you were so inclined.

I would be interested in taking this approach because I think it could only help improve the quality of writing and information, as well as serve as a filter to catch any parts that need further clarification or tweaking. The benefit for you is that you'd get to have early access to my articles and help make the articles better for yourself and others.

If you have any interest in this, drop me a line [mitchell@4guysfromrolla.com]... (or leave a comment)

Filed under:
Tim O'Reilly on the State of the Computer Book Market
19 April 04 02:36 PM | Scott Mitchell | with no comments

As I wrote in a previous blog entry, you don't write computer trade books to become rich. In today's soft technical book market, there's a good chance that you'll not receive one penny of your royalty, instead just receiving whatever advance monies you agree upon with your publisher. This, at least, is the state for writing computer trade books geared toward ASP/ASP.NET developers. One thing that I've always wondered about, though, is how other types of books fare in the market. In absolute terms, as well as in royalty dollars, how does an ASP.NET book compare to one of those “Office 2003 for Dummies“-type books? Another question that had been on my mind was how ASP.NET books sold compared to PHP books, or JSP books. My initial assumption would be that there was a strong correlation between market share and book sales. That is, if there were twice as many Web developers working on PHP than JSP, a PHP-focused book would sell, roughly, twice as many copies as a comparable JSP book.

Some of these questions on sales numbers were answered for me when I stumbled across Tim O'Reilly's State of the Computer Book Market blog entry. Tim's entry, unfortunately, does not discuss why the technical book market is so soft, it merely takes a gander at some of the recent statistics from Nielsen BookScan. These statistics help answer some of the questions I addressed in the preceding paragraph.

First, Tim shows a graph (replicated below) of book sales by month, broken down into the various technical book genres.

This graph shows what I had assumed: application-focused books significantly outperform those books written for developers. This makes sense, as there are many more secretaries needing to learn the ins and outs of Word and Excel than there are developers needing to learn the latest programming language du jour. Too, Platform books are outselling software development books. I assume these are end users wanting to learn more about Windows XP, or Mac OSX. What's depressing is that software development books are virtually dead last. Yes, they're a smidgen above the Networking Admin books, but the only real distance it has above other categories of books are Unknown and Other. While it's great not to be in last place, it's a bit disheartening to say, “Well, at least we're better than Unknown and Other.”

The end of the year NetScan results for 2002 and 2003 show what all of us authors knew from our royalty statements: the technical book market shrank by nearly 11% from 2002 to 2003. While Tim doesn't share statistics pre-dating 2002, trust me - it has shrunk even more leading up to 2002.

Tim's entry shares one more interesting graph (shown below), which shows how books by platform fare. Notice that even though Windows boasts a 90%+ marketshare, only slightly more than half the books are targetted toward Windows developers or end users.

Tim notes this greater level of enthusiasm from Mac/Linux users than from Windows users, but does not venture a guess as to why Mac and Linux books sell a disproportionate number of books compared to their installed-base marketshare. Personally, I think the reason is that Windows users are less focused, on average, than Mac or Linux users. Now, I am not slighting Windows users by calling them unfocused. To see what I mean, consider the following: imagine you have a friend who says she wants a computer. You ask her what she plans do use it for. She says, “I dunno, surfing the Web, checking email. Games, maybe.” There are a lot of end users who buy a computer with no real point in mind. Maybe they get it because everyone else on the block has one, or because their kids keep bugging them to get one. The point is, what type of computer is this person going to get? One from Dell or Gateway or from Bust Buy or CompUSA. One that will come with Windows. They'll likely not fork over the dough for a Mac, and there's no way they'll have the know-how or patience to use Linux. So they end up with a Windows box.

Now, someone who did not get the computer to perform a focused task, what do they need a computer book for? They can figure out how to get online, how to chat with IM, and how to install and play a game they bought. These users aren't doing focused tasks that require an in-depth look at a particular topic. Hence, no sale here. Mac and Linux users are likely more focused. They got their computer for some very specific reason, and need to learn some very specific task very well. They won't balk at dropping $30 for a book to help them master whatever it is they are needing to accomplish.

Filed under:
Follow-Up to Allowing Readers to Rate Blog Entries
19 April 04 12:27 PM | Scott Mitchell | with no comments
In an ealier entry I discussed a new feature I added to allow my blog readers to rate individual blog entries, much like one can rate the articles on MSDN. I have written an article on creating the content rater at 4Guys called, aptly, Creating a Content Rater. The article includes the source code for the User Control, along with the stored procedures and table schema I added to my blog (which is running .Text 0.94).
Enhancing Your .Text Blog - Allowing Readers to Rate Blog Entries
15 April 04 04:12 PM | Scott Mitchell | with no comments

One of the things I really like about .Text is just how easy it is to customize and enhance it. Of course, the complete source is available, so you can customize to your heart's content, but I'm talking about customizing it without modifying the source and recompiling. I've had past blog entries about customizing and digging into .Text (see Giving .Text a Calendar View and Analyzing your .Text Blog), and wanted to share my latest enhancement here on ScottOnWriting.NET: the ability for readers to rate a blog entry and leave feedback on why they made their rating (just like how MSDN's online articles have a “Rate this feedback“ section at the end of each article). The end result, you'll agree, looks pretty much just like Microsoft's rating interface, save that mine only allows you to rate from 1 to 5 instead of 1 to 9. It uses cookies to do a half-assed effort at ensuring that folks only rate a blog entry once.

If you're interested in adding this rating User Control to your .Text blog, I'll have the source for the User Control and an article discussing it on 4Guys sometime next week. What is cool about .Text (at least .Text 0.94, the version I'm using) is that the page layouts are specified in User Controls themselves (in the /Skins/skinName/Controls/ directory). This means that I could, with just a quick edit in Notepad, adjust the main page so that after each blog entry in addition to the Feedback (xxx) link, there's also a Rate Entry link, which will take you directly to the interface to link the blog entry.

The natural extension to this would be to allow users to read / view the most popular (and perhaps least liked) posts...

(The Rate Entry option is only available by visiting the ScottOnWriting.NET Web site directly. I guess I could attempt to embed the necessary HTML into the RSS feed, but I doubt I'll do that, since for that (I believe), I will need to edit the .Text source and recompile/redeploy.)

To Code-Behind or Not to Code-Behind: That is the Question!
14 April 04 12:23 PM | Scott Mitchell | with no comments

The ASP.NET Dev Center on MSDN has started a Community Inbox where you can send in your questions to be answered by community leaders, such as Steve Smith, Andrew Duthie, Dino Esposito, and others. The most recently discussed question was: Should I use Code-Behind or Code-Inside? Code-Behind is the technique VS.NET forces you into when creating an ASP.NET Web application, whereas Code-Inside is the technique of using a server-side script block (<script runat=”server”>...</script>) in the HTML portion of the ASP.NET Web page.

Steve and Andrew chime in saying that Code-Behind is the way to go if you are using VS.NET, as it's the model the tool supports. Scott Hanselman essentially suggests to do what you want, as Visual Studio .NET 2005 will offer native support for either model. Dino has a dissenting opinion, stating that he's against Code-Behind. His main complaint is as follows:

What I dislike of VS.NET code-behind is that is requires an extra, mandatory compilation step and that forces you to deploy an assembly. I agree that this may be a negligible issue in the context of an enterprise project, however. All in all, I feel bad when I see that a keyword found in each @Page directive of a page created with VS.NET means little to the runtime expected to process that page. The keyword in question is CodeBehind. It's there only for the VS.NET editing purposes and ASP.NET gently skips over it. Try removing it and you'll see that the page is correctly processed but you'll have a hard time trying to re-edit it through VS.NET. The problem with code-behind is not with the technique itself--which is great and from a certain perspective even due--the point is the VS.NET implementation of it.

I think Dino is scratching at the surface of why Code-Behind in non-ideal, but he's a bit off the mark. It's not that Code-Behind is a good model, and there is just not sufficient tool support; rather, Code-Behind is a poor model chosen specifically because of the limitations of the tool (VS.NET 2002/2003).

I used to think Code-Behind was a decent programming paradigm. Sure, it had some weaknesses, but it was the required approach for building Web applications in VS.NET. It allowed for IntelliSense, debugging, etc. These views were shaken up a bit after talking to Andy Smith at the MVP Summit last week. Andy has just added a good entry on his blog titled Spaghetti, CodeInPage, CodeBehind, and CodeBeside, which articulates the points he made to me in Redmond. A definite must read. In addition to these shortcomings of Code-Behind, Andy also informed me that you could debug an ASP.NET Web page using the Code-Inside technique with VS.NET 2002/2003... granted, there's no IntelliSense, but debugging is possible.

Fortunately, this whole debate - and all associated confusion - over Code-Behind technique, is moot, as Visual Studio .NET 2005 will remove the need for Code-Behind as the editor will have IntelliSense in the HTML designer. Also, Code-Beside offers a panacea for the ills introduced by Code-Behind. As Andy points out in his blog entry, Code-Behind was a hack introduced to allow for ASP.NET Web page development in VS.NET 2002/2003. Thanks to needed upgrades in VS.NET 2005, the need for Code-Behind should vanish.

Filed under:
Going Independent - First Steps
14 April 04 10:55 AM | Scott Mitchell | with no comments
On Monday I started a series of blog entries called Going Indpendent, where I plan on looking at the legal, accounting, and - most importantly - the psychological issues one must contemplate when trying to decide whether or not to go independent. In today's blog entry I'd like to look at the first steps one must take when going independent - setting up a business. This talk may be U.S.-focused, as it looks at business models available here in the states.

Before diving into the options one has for setting up a business, I'd like to start with two quotes from colleagues that do a great job of highlighting the pros and cons of being employed. First, a strong case for being employed:

I personally enjoy being a corp employee. Great benefits! Decent pay. Great hours—no required O/T and paid time-and-a-half O/T. Low stress because deadlines are mostly internal and flexible. Paid training, travel, and expenses. Paid vacation. Paid sick time and even personal time. Work from home if need/want to on occasion. Get to work with and lead team(s). Paid to play with new technologies. Paid high-speed internet. Paid cell phone. Pension plan. Matching 50% to 60% 401(k) plan. Great people to work with. Job security/regular income. More or less guaranteed increases.

The above quote illustrates many of the benefits of being employed - a regular paycheck, vacation time, a steady cash flow, etc. But these advantages of employment are oftentimes employer-specific, as another colleague relates:

Unfortunately I am an employee and none of those things apply to me apart from regular pay cheque (so far, been shaky in the past). I still have to worry about cashflow (I have been pretty much 3/4 sales for 18 months now to prevent us going under), do get benefits but not greatest (2.5% into my pension and ... healthcare) but compare that to what others doing similar job get (even at same company)..., all of my vacations have been interrupted by either someone calling to notify me of some redundancies or a problem only I can fix (not always the case but noone seems to have brains, energy or confidence to sort things out on their own).

Not surprisingly, satisfaction at work has a lot to do with one's work environment. The point being, if you are miserable at work, the answer is not necessarily to go independent - it might be to just find another employer.

Types of Businesses
In the U.S. there are different models one can use when starting a business. These different models have different legal, accounting, and tax implications. The most common business models used for self-employed individuals are:

  • Sole proprietorship
  • Limited Liability Company (LLC)
  • Partnership
  • S Corporation
  • C Corporation

What business model to choose depends on a number of factors, such as tax implications, liability issues, whether or not you plan on hiring other employees, how many individuals you want to let claim an ownership in the business, etc. Over the next few sections we'll briefly look at each of these business models and discuss some of the pros and cons. Before continuing on, please remember that I am not a lawyer nor an accountant. My comments stem only from my research on the matter, and discussions with my lawyer and accountant. Be certain to discuss these matters and your options with a lawyer and accountant you trust before pursuing any of these business options.

Sole Proprietorship
The first (and simplest) type of business model is known as a sole proprietorship. This is a business owned by one person - yourself. The benefits of a sole proprietorship is in its accounting and legal simplicity. You don't need to fill out any forms or pay any special dues for a sole proprietorship (as you do with, say, a corporation or LLC). Your business income is reported on the 1040 Schedule C. There are a couple downsides to sole proprietorships:

  1. You are liable for the business! That is, say you need to buy $50,000 worth of equipment. You place an order and agree to pay on a schedule where you pay, say, $5,000 a month for 11 months. Now, imagine that the business fails after three months, and you close down shop after paying only $15,000 of the agreed upon $55,000. Well, guess what? You still owe $40,000, and the company you owe it to can come after your personal assets (like your car, home, etc.) to recoup their loss. Another, perhaps more applicable example: you decide to go independent as an independent consultant. In your first job you create an intranet application for a company that let's them manage their Web site structure. Due to a bug, when the client attempts to delete a single file, it deletes their entire Web site contents, which they hadn't backed up. If they decide to sue you for lost content/time/etc., your butt and your assets are on the line.
  2. Taxes are high. As a self-employed person, you'll need to pay self-employment tax on your net Schedule C income. This tax (called employment tax) is paid by your employer when you're working for someone else. When you work for yourself, you must pay it! Bummer, eh? (This is true for all business models, by the way. The comment is not specific to sole-proprietorships, but rather working for yourself!)

Limited Liability Company (LLC)
A Limited Liability Company (LLC) can be owned by a single individual, multiple partners, or even corporations - in either case, these owners are referred to as managers. The benefit of an LLC is that the managers have limited liability in the company. Returning to our earlier example, if your business was an LLC and you were sued by a client for code that deleted their entire Web site, only the business and its assets would be up for grabs - your personal assets, separate from the business, could not be touched. From my understanding, LLCs vary on a state-by-state basis. States differ on who can be members, what types of businesses can form LLCs, and so forth. The cost and paperwork for establishing an LLC differs from state to state. For individually owned LLCs, income is reported via the 1040 Form, Schedule C.

Partnership
A partnership is a business owned by two or more individuals. The parties involved in the partnership all contribute to the business and are expected to share in the profits or losses. The IRS does not treat partnerships as a taxable entity; rather, each partner must file his or her share of the profit or loss on their own tax return. Form 1065 is used to report income or loss from a partnership.

Things get a bit more complex if you are married and your spouse works with/for you. If your spouse work with you in your business, they are a partner. If your spouse is an employee, working for you, then the business can remain a sole-proprietorship, but you'll need to pay social-security, medicare, and other such taxes for your spouse. If you run a business jointly with your spouse, be sure to get all the tax and legal issues straightened out with an attorney and accountant.

S and C Corporations
A corporation is a separate entity that is formed to run a business. The ownership of a corporation is divided into a number of shares. A corporation is owned by shareholders. An S corporation is a special type of corporation in place for small businesses. It can have at most 75 shareholders, and does not require as much bookkeeping or paper filing as a C corporation. There are also shareholder restrictions with an S corporation, such as: shareholders must be U.S. citizens; partnerships or corporations cannot own shares; there can only be one class of stock; and others. A C Corporation is a corporation without the limitations placed upon an S-corp.

The benefit of a coporation is that it is, legally, a separate entity from its owners. That means the corporation assumes its own liability. A corporation is taxed as a separate entity as well. When you do work for a client, the client pays the corporation. You make yourself an employee of the corporation, and receive an annual salary. Since you are an employee of the corporation, the corporation must pay social-security, Medicate, and employement tax on your salary, just as any large company does for its employees.

Corporations are useful in a number of situations, such as:

  • Hiring employees
  • Having several individuals own a share of the company (such as family members, investors, etc.)

Corporations also have some useful tax advantages. For example, a corporation could setup a 401(k) retirement plan for its employee(s), where it matches employee contributions.

The downside of corporations is that the paperwork and fees to setup a corporation are much higher than establishing an LLC, sole-proprietorship, or partnership. In addition to the paperwork for setting up a corporation, additional quarterly and/or annual paperwork is needed as well.

Wrapping Up...
When deciding whether or not to go independent, it is important to have an understanding of the legal issues you will need to address, one of which includes forming the suitable business model, be it a sole-proprietorship, an LLC, a partnership, or a corporation (likely an S-corp). Before making any decisions, take the time to research your options - there is plenty of information online at IRS.gov and your state's Secretary of State Web site. Once you have "done your homework," be sure to sit down with an accountant and lawyer that you trust, and discuss the legal and tax implications for the various choices you have. Also realize that forming an LLC or corporation requires paperwork and filing fees, so expect to pay between several hundred and several thousand dollars to accomplish this, depending on the state you live in and your lawyer/accountant's rates.

In my next Going Independent entry I'll turn from the legal issues to the accounting issues, examining how self-employed individuals are taxed. It's different enough from the way employed individuals are taxed, enough so that a discussion on the psychological issues is warranted. Until then!

Filed under:
Going Independent - Is it for You?
12 April 04 01:28 PM | Scott Mitchell | with no comments

After talking with a couple of colleagues who are contemplating making the switch from working with a company as an employee, to trekking out down the self-employment path, I thought that I might be able to share some advice on the transition. Making the switch can be a daunting process. There are legal issues - what type of business do I form? A limited liability? A partnership? An S-corp? There are accounting issues - how do I file my taxes? Do I need to make quarterly tax payments? What will my tax burden look like? How much more do I need to earn per month being self-employed to enjoy the same life style as I enjoy as an employee? Most importantly, there are psychological and personality issues - are you self-motivated? What is your perception of money: as something that is meant to be saved; something that is meant to be invested; or something that there never seems to be enough of? All of these issues take center stage when beginning the journey of self-employment, and all should be weighed carefully before making the switch.

This blog entry - and the ones that will follow - are aimed at those who are contemplating going independent, and are seeking advice or anecdotes from those who have already made this transition. Today's blog entry looks at the pros and cons of employment vs. self-employment. It focuses more on the psychological and personality issues rather than the legal or accounting issues. Future entries will examine drudging through the legal goo necessarily, and tax implications associated with self-employment.

Let me preface this series of blog entries with the following disclaimer: I am not a lawyer, nor an accountant. In case you glazed over that last sentence, let me repeat it: I am not a lawyer, nor an accountant. My comments on legal and accounting issues should not be taken as gospel, but as a somewhat informed opinion. I have been self-employed since completing my undergraduate degree back in 2000, and have gone through the legal and accounting issues associated with becoming self-employed. So my opinions on these matters are educated ones forged from experience, but they are not backed up by years of study, certifications, or practice. I do, however, think I'll be able to accurately address many of the psychological and personality issues, which, naturally, will be most valuable to those with a similar disposition as myself.

Everyone's experiences differ, so I hope to stimulate discussion among others who are self-employed. With any luck, others will feel compelled to share their stories, mistakes, and successes in going independent...

The Benefits of Being Employed
Before deciding whether or not to go independent, it's vital that you understand what you'll be leaving. Being employed has many benefits that are nowhere to be found when working for yourself. Typical benefits of employment include things such as:

  • Consistency - a steady paycheck, regular working hours
  • Flexibility - paid vacation / sick time
  • Employer-Paid Fiscal Benefits - Health/dental insurance, regular raises / bonuses, a retirement plan with (perhaps) employer matching

When you are self-employed, you are your employer. This means setting up a retirement plan is your responsibility. Contributing to it is your responsibility. When you take time off - for vacation, personal matters, or illness - you're NOT getting paid. That steady paycheck is as steady as your availability, marketing, and work ethic. Regular working hours? Ha! You work when your client wants you to.

Due to this, self-employment is not for everyone. It is not for those who need a steady source of income, such as someone living paycheck to paycheck with a family to support. Self-employement is not for those who have trouble motivating themselves to work. Some people need the consistency of a 9 to 5 job; some folks need a manager giving them action items and tasks to complete. There's nothing wrong with this type of person, but chances are someone with this personality will have a hard time making it on their own. Working for yourself requires discipline and much more hard work than working for someone else.

The Benefits of Self-Employment
While being employed has a number of benefits, it also can carry with it a number of disadvantages. These disadvantages are based largely on your work environment. If you're one of the lucky ones and work in a fun, friendly, metally challenging atmosphere, on a project you find interesting, then why oh why are you thinking about going independent? If, however, you are one of the millions who find themselves dreading waking up the next day, as it only means another hour-long commute through traffic to an office building you've dreamed about destroying, then self-employment looks better each day.

Working for yourself carries with it a lot of freedom. You are your own boss. You can wake up whenever you please. Your morning commute is likely to your home-based office. If you want to take off the afternoon, no one is stopping you. You can spend an hour writing a blog entry on going independent. Of course, with that freedom comes responsibility. When you take that hour to write a blog entry, you're not getting paid. If you roll out of bed "whenever," you'll likely find yourself not motivated to start the day working.

For some people, working for yourself can have a strong effect on their own sense of self-worth. That is, there are some folks who, if they work for a company that goes bankrupt, they simply find another job and don't interalize the company's demise. If, however, they were to work for themselves, and didn't succeed, they'd take the failure as a comment on their own personal worth and capabilities. People who tie their business success to their personal worth should steer clear of starting their own business, as the vast majority of businesses fail. Those who are really successful at business typically fail more than they succeed. (Donald Trump, for example, has gone bankrupt before. Billionaire Paul Allen, co-founder of Microsoft, has had many investments since his departure from Microsoft that have not panned out. Steve Jobs has had many successes - and many failures - at Apple, being fired from his own company at one point in time.)

The point is, even in a successful business, there will always be setbacks. If you do trek out on your own, it is important to take these setbacks in context. Do not let the setback discourage you from continuing, or deminish your sense of self-worth. Rather, when those setbacks to happen, step back, observe, learn, and move forward.

Moving Forward
I plan on writing future entries about this topic. I'd like to follow this entry with one on the legal issues surrounding starting your own business. Namely, what options exist for forming a business, and what tax/legal implications they involve. In the meantime, for more information let me recommend Johnathan Goodyear's articles on going independent. In Part 1 Johnathan looks at how to determine if you have the will and personality to be an independent consultant; in Part 2, Johnathan examines techniques for marketing yourself to attract future business.

Filed under:
An Extensive Examination of Data Structures: Part 6 Available
07 April 04 07:07 PM | Scott Mitchell | with no comments

Part 6 of my extensive examination of data structures is now available. Part 6 provides a look at sets. Sets are a construct used to represent an unordered collection of items, and are common in mathematics for describing properties of numbers. Interestingly, programming languages like Pascal (and its derivatives, Oberon and Modula) provided a set construct in the language. In fact, there is even a programming language called SETL that offers sets as first-class citizens in the language, just like strings, integers, and Booleans in C# or VB.NET.

Following a discussion of sets, along with examining how to create a Pascal-like set data structure, the article turns to a more common need - efficiently maintaining a collection of disjoint sets. A collection of sets are said to be disjoint if there are no similar members between the sets. There are many real-world situations where you might need to maintain disjoint sets. For example, consider that someone gave you a list of people in a town, where each townsperson provided their father's name (assume no two people share the same name). You are then tasked with determining who in the town is related to one another. That is, you should be able to efficiently answer the question, “Is Tim related to Ed?” The approach to take here is to group the townspeople into disjoint sets, where each disjoint set represents a family tree. You can then determine if any two individuals are related by determining if they are members in the same set. This article discusses two data structures that can be used to represent disjoint sets, and how their structure affects the efficiency of those operations being performed upon the sets.

Filed under:
MVP Conference Wrapped Up Today
07 April 04 06:08 PM | Scott Mitchell | with no comments

The MVP Global Summit concluded today, with in-depth sessions for each of the various MVP groups. The three-day summit was both educational, interesting, and entertaining. What I enjoyed most was not the tech talks, but the opportunity to meet and converse with other ASP.NET MVPs with whom I've communicated with many times in the past, but only virtually. I had a good two or three hour chat with Darren Neimke, James Avery, and Andy Smith on a wide variety of topics from Terrarium to XHTML to the future of ASP.NET to the negatives of the code-behind class model. Some smart guys with some interesting and unique views on a wide array of topics. I also had a good half hour talk with Scott Watermasysk about .Text features and architecture.

Filed under:
I'll be Blogging from the MVP Conference Next Week
03 April 04 01:32 PM | Scott Mitchell | with no comments

My flight to Seattle leaves too early tomorrow AM. I'll be up at the Microsoft MVP Conference from Sunday through Thursday morning, and will make an attempt to blog about the experience at least every other day. This is my first MVP Conference (was knee-deep in finishing grad school last year), so I'm looking forward to the experience and the opportunity to meet so many people with whom I've communicated with virtually over the past two years, but have yet to meet face to face.

The next few months look like they're going to be busy ones. After getting back from the MVP Conference, I have family coming into town. I've got a trip back to the Midwest planned for mid-May. I'll also be attending TechEd in late May this year, as it's in my own back yard (San Diego), and then I'll be getting hitched in June, and then off to Europe for a week and a half.

I've also got some upcoming articles on the MSDN ASP.NET Dev Center, which should appear over the next month or so. The first is on building accessible Web applications while the second one looks at using HTTP handlers.

Filed under:
More Posts Next page »

Archives

My Books

  • Teach Yourself ASP.NET 4 in 24 Hours
  • Teach Yourself ASP.NET 3.5 in 24 Hours
  • Teach Yourself ASP.NET 2.0 in 24 Hours
  • ASP.NET Data Web Controls Kick Start
  • ASP.NET: Tips, Tutorials, and Code
  • Designing Active Server Pages
  • Teach Yourself Active Server Pages 3.0 in 21 Days

I am a Microsoft MVP for ASP.NET.

I am an ASPInsider.