You walk into a new contract to perform customizations to the company's proprietary web app. It's a mid-sized web app with a few hundred .aspx files and thousands of .cs files, with a detailed data layer. You're tasked to perform customizations to one of the more complex pieces of the web app, which uses third party controls and lots of code built around UI events.

The boss knows the answer to all questions, but he's only there about a quarter of the time, and when he is there he's only there for a few minutes and then he's gone for at least an hour again.

You want to be on your best behavior, but part of that is proving that you can be very productive. The person who originally implemented the code you're customizing has left the company. There is one fellow developer sitting on the other side of the cubicle. Since the boss is usually gone, you are tempted to ask questions to the other developer, but you know you're only given a few minutes / hours / days' grace to interrupt his/her workflow.

Question: How many minutes, hours or days is it appropriate to ask very trivial questions to the other developer in the boss's absence, such as "What's this object do, it's not obvious and I'm not seeing it referenced anywhere except here where it's updated", "Does the application have XX functionality that I can reference?", or "Do you know what I should do about YY behavior?"

 I asked this question in a "room" filled with fellow developers, and received very contrasting responses:

Answer 1: "Why don't you look at what the 'object' does yourself? 'Do you know what I should do about YY behavior' in my world becomes 'Where are the g**d*** SPECS?'"

Answer 2: "You're asking a really standard question for contract developers. It's really normal for a programmer that is being pushed too hard for fast development by the boss to write crappy code with little documentation and then quit from the pressure hehe. Then they hire someone else to fix the code. The question is, has the boss become more relaxed to allow the developer to do their job, or is the boss still just the boss. No doubt, to form good code, a programmer must never be rushed. But the boss is a boss first. Their duty is to productivity and revenue. There are good and bad bosses. Some bosses also know the employees that they're dealing with, but some are just delegators, not managers. You have to remember, bosses start as employees somewhere and are promoted over time. Some justly, some not so justly. They may or may not have the qualifications to be the boss. If it's possible, just map out the main functions of the program and concentrate on the areas that the boss is asking be reworked first. Try to take a little time each day to add comment summaries to each function if they arent already there. Start small. Over time you'll learn how the puzzle fits together and can address systemic problems then. More than likely the boss is watching you more to see how quickly you can analyze code and be self-sufficient. I'd limit the questions to only what is absolutely necessary with the other workers, hehe. The answer depends on the team and personalities, but [in the scenario you described,] you're too new to make that assessment. For now the answer is 0. Make a friend first."

Answer 3: "We have a mentor program here. New guys get a more seasoned person of their discipline to ask questions and get them up to speed. They also realize it takes anywhere from 3-9 months before the new person is self-sufficient."

When I was a teenager in 1994, I witnessed something that has followed me throughout the rest of my career. My father was going through a difficult period in his life, and he realized it had affected his job, so much so that he knew it was ending. In a discussion with his boss, he asked, "Did you expect me to hit the ground running?!" To which the boss replied, "Yes. I expected you to hit the ground running." This startled my dad, but he realized that his boss was right. And as he shared this experience with the rest of us, I could feel his pain. Even as I write this, I shed a tear or two for him, in memory of his anguish, because tough lessons like that are more devastatingly difficult to learn than anything else. Indeed, we as a family were all the way on the other side of the planet, in Nairobi, Kenya, on behalf of this job. And we had to turn back, and head back to the United States, because of a hard lesson learned.

I've had quite a few jobs in my career. I have sometimes (usually?) managed to show up trying to hit the ground running. And I generally succeed. I showe up being as productive as everyone else on the preexisting team within two or three days. I haven't been able to do that, though, without asking a lot of questions. But in no time flat I would turn around and have a lot of answers, too, that had been lost to the others on the team--I tried hard to make the most of my combination of industry experience and a fresh pair of eyes. Within weeks, I'd pooh pooh years-held workarounds to bugs and come up with better, faster, and more reliable solutions and share them with the team.

 

The more you know, the more you realize how little you know. (And if you don't know that then you're missing out.)

On the practical end, the above line ("The more you know..") shows itself proven when the questions being asked further the progression and involvement of development and deployment. Name any technical lead who is successful without being a great communicator, partly by the spoken word and partly by asking questions and listening to answers in order to forumulate the appropriate solution for the situation.

But I'll admit that on the flip side, asking a lot of questions up front in a new environment and situation makes a person appear unskilled. Personally, I think the opposite is the truth, but most employee folks don't realize it. An inquisitive mind is one who is smart enough to form the question--smart not only in choosing to do so and how to do so, but in knowing what questions to ask in the first place. Such is one who is also often careful not to sit around spinning wheels, which is a waste of not only that person's time but, more dangerously, the company dollar.

The mindset of the person who hates to be asked questions is usually driven by the frustration of being suddenly distracted from their work and having to face someone else's problem rather than their own. Seriously, though, how selfish. I knew a guy made me stand there and wait 5 minutes while he coded and occasionally held up a #1 finger ("one moment" gesture) just so I could get my 15 seconds out of him for an instant-answer question. How much time is lost to the question by the losing track of a chain of thoughts? I tend to think it's about double the time of the question. That said, though, if the question takes two minutes to answer and four minutes to refocus, that's six minutes lost, rather than another 5 minutes on top of it to wait, or thirty minutes lost to wheel-spinning by the asking party.

In my perspective, the most productive teams are the ones where all members are able to openly share the minds of the others, collaborate, and work together, for at least either a few short spurts during the day or for one or two dedicated hours during the day. This as opposed to coding in total heads-down isolation, with the same amount of time as otherwise spent collaborating, spent instead chatting about life and toys.

An IT / networking guy once told me, in the context of this, "What I tell the guys working for me is, 'Do what you can to try to figure out what you can for at least thirty to sixty minutes. If you still can't find an answer during that time, go to a co-worker, and if you still can't figure it out, only then should you come to me.'"

This attitude seems to be shared by many people in the technology industry; however, in the software engineering field, I am thoroughly persuaded that it is flat out wrong.

Do the math!

A) You spend two hours spinning your wheels. You finally reach what you think to be a eureka moment discovering the answer to your problem, but you soon discover that you were wrong. You spend another hour, and another after that, on false-guess workarounds to your problem. In the end, another hour is spent debugging your guesswork workarounds, but it all eventually gets functional, on your own.
Time/pay units wasted: 5 hours. And by the way, you're looking pretty sucky at this point.

B) You spend an hour spinning your wheels. You give up and talk to a permanent employee, who then gives up after fifteen minutes and so you go talk to the manager, who has the solution explained within five minutes. The co-worker loses another 20 minutes trying to get his/her mind back on track to what he/she was working on.
Time/pay units wasted: 2 hours (60 + 15x2 + 5x2 + 20 minutes).

C) You spend five minutes spinning your wheels. You give up and talk to your manager, who has the answer explained within five minutes.
Time/pay units wasted: 15 minutes (5 + 5x2).

Assuming that these scenarios are typical, only one conclusion can be made. From the perspective of the company's and tasks' best interests, there is no better person to have on your team than the one who asks a lot of questions up front. The more skilled individual will ask the more relevant question, not the lesser question. Questions that would solve the problem quickly--such as ideas and proposals in question form--rather than questions that introduce more questions.

Time spent spinning wheels is even more expensive if you're on a contract through a company like Robert Half Technology. Any company hiring through such a staffing firm is going to be paying out anywhere from 10% to 150% on top of what you're making. So when I'm working with an agency and I'm "out on the field", so to speak, as a contractor on a short-term "job" trying to accomplish some special tasks, I am absolutely frightened of spinning my wheels.

Indeed, while some managers would consider the highly inquisitive employee to be "high maintenance", supposedly "high maintenance" employees are proven to be shown to actually be the most valuable subjects of their management.

Incidentally, I don't just ask questions to fix my problems. Sometimes I ask questions to understand, so that I can be self-sufficient beyond the problem. I often ask questions to listen to the answerer's adjectives, word choice, side comments, and back stories. This is very valuable information that can really help in the understanding of the bigger picture and the way things are.

Not only do I feel free to produce questions, though, I also love to answer questions. Questions make me feel needed. They make me feel knowledgeable. They make me feel respected. No matter how extensive, complex, or brainlessly simple they are, and no matter how busy I am, I love it when people pick my brain.

The love of answering questions comes so naturally for me that I forget that other people hate it when I myself ask questions. But after so many jobs where I've been hounded for asking so many questions up front, I've reached some very important conclusions, of which I am beginning to feel strongly about.

1. I need to ask few or no technical questions from peers I don't know very well, because those whose time I am taking feel nothing like I feel when I enjoy being asked questions. Co-workers tend to hate questions like they hate bugs and spam. The manager, on the other hand, should be fully able to either answer the questions or to assign someone to answer questions. The manager's job is indeed to meet your needs. Both of you work for the same company. You don't work for the manager any more than the manager works for you. If the manager doesn't see it that way, and if the manager's refusal to give you his/her time or time with a co-worker is killing your productivity, then it's a crappy job and, if you have the option, you should look for work elsewhere. But if he/she is willing, no matter how intimidating, impose on your manager with questions, not your co-workers.
 

2. Companies and team leaders need to learn to train teams to embrace questions and teach people to enjoy answering peer questions rather than hate them. I don't know what it is that makes me so happy to be asked questions of, but I do believe it's a learnable trait. I'm also quite positive that it's something that can benefit a team and a company at large; I've only seen good come out of it, and the only negative I've seen has been flaring up of feelings and agitation. That, I believe, is correctable.

People need to be trained to be intellectually honest. This is a cultural mindset that says that:

• It doesn't matter what you do or don't know, your knowledge about proprietary systems is a proprietary company asset that belongs to the company, not to you or to any one individual.
• Answering questions earns you respect.
• Admitting you don't know something wins you the opportunity to discover from the questioner's findings.
• Being a go-to person is a role of leadership that brings you higher up the ladder (unless you refuse to answer, in which case respect goes through the floor).

3. Despite all that I've said, it's okay to put an end to too many questions. If someone is bothering you, it's fine to say, "Hey buddy, I think you're ready to be on your own now, if you have any further questions please save them for the manager." Completely okay. What's not okay is instead putting on a pouty face, making strange noises of irritation, lying through your teeth about how you don't know, and telling the boss that you're unable to get your work done because you're getting pestered. Until you've communicated a request for questions to stop (politely, ideally), that behavior is selfish.

I once had a guy sitting next to me who ignored me for one or two hours straight on a question that absolutely needed about sixty seconds of his time because he and I were the only engineers in the office and my hands were tied, before he spun around and shouted, "I don't f#$%'n know!!" This behavior is uncalled for. If I was a manager and witnessed that I'd fire such a person on the spot, with absolutely no care for what cost. That's beyond rude, it's reflective of a long-growing seed of unaddressed resentment and untrustworthiness, such being the kind of negative growth patterns that can tear a team apart and make it never function normally again until the problem is expunged. But that's just my view on that; I'm the one who got yelled at.

Over the last six or seven years, I've painstakingly perused the facts and details of what it is that makes the federal income tax applicable to the salaries of average Americans. For some time I was caught up in the "tax honesty movement" that was the following of Bob Schulz, Joe Banister (a former IRS criminal investigator who discovered that the income tax as it is being imposed was being unlawfully applied and that the IRS themselves were the criminals), among others. I quit my job and went independent for several years, in large part (but not entirely) so that I could sit down and just focus on learning and understanding what's really going on, without concerning myself with the repercussions of potentially perjering myself by signing a Form W-4.

A Form W-4 identifies a person as an "employee", and willfully signing one legally binds a natural person to the role of an "employee". An "employee" is a legal term. The term is defined in 26 USC § 3401 as "... an officer of a corporation".

That's not the entire definition, but it is the part that applies. What the "tax honesty movement" proponents incorrectly assumed, and what I eventually began questioning and demanding an answer to (and didn't receive), was that this "officer of a corporation" somehow meant a "public officer", as in, the President of the United States, or a military officer, or an elected representative. This assumption proved bogus; I found no tie-ins to this rather generic verbiage with that interpretation.

In fact, the failure of the "tax honesty movement" community to answer this question resulted in my decision to go back and look for a W-2 job again, since I wasn't cutting it on my own and practically every well-paying software development or consulting opportunity out there was a W-2 job.

Since then, I've been trying to make sense of the mess that the withholdings system is and how liability applies. As posted on the mailing list I moderate, and as I concluded and documented, for the most part, over the last few years, here are my repeated conclusions:

1. Federal currency is a federal government fiction. Money in its current form is not a barter exchange, it is created from nothing and set into motion by people who use it. Paper money, digital bank dollars, it is all government-created fiction. As is documented by The Creature from Jekyll Island, money is created from thin air. The principle of "Render undo Caesar what is Caesar" applies, because even on a basic dollar bill, the names "United States of America" and "Federal Reserve" are spelled out, just as the face of Caesar was printed on the coin in Jesus's day.
   • What the proponents of the "tax honesty movement" suggest is that "We The People are the caesars" because we are a democracy or somesuch. This is nonsense; that logic only applies to barter exchanges between natural persons who are careful not to associate themselves with federal taxing jurisdiction.
   • The question becomes, is it just for a people's government to impose an existence or receipts tax upon its own constituents directly? Of course it isn't. But then, the use of federally created currency is a privilege, not a right.
   • I only make this point to set aside the arguments about common law rights. This does not discuss what was taxed, but only that the federal government has the common law right to impose a tax on the income of federal currency, which is put into check by common law limits on federal scope and by the Constitution.
2. Taxing jurisdiction is limited to federal jurisdiction. The rights of the constituents are reserved by the Constitution. The Sixteenth Amendment does not expand the scope of taxing jurisdiction. In order for the federal government to impose a direct tax upon its constituents' incomes, the constituents must already throw themselves into federally taxing jurisdiction.
   • What the proponents of the "tax honesty movement" suggest in error is that federally taxing jurisdiction is limited to the political and peacekeeping activities of the government.
3. Corporations are extensions of both state and federal government. They are legal fictions. They have become so pervasive in modern society that people don't really know how to accomplish anything as a group anymore, be it a church or other non-profit organization, or a for-profit group of people, without filing incorporation papers and then going out and seeking an EIN from the IRS.
   • "Upon the other hand, the corporation is a creature of the state. It is presumed to be incorporated for the benefit of the public. It receives certain special privileges and franchises, and holds them subject to the laws of the state and the limitations of its charter. Its powers are limited by law. It can make no contract not authorized by its charter. Its rights to [201 U.S. 43, 75]   act as a corporation are only preserved to it so long as it obeys the laws of its creation."  HALE v. HENKEL, 201 U.S. 43 (1906)
     http://laws.findlaw.com/us/201/43.html 
   • While corporations are chartered by the state, they are federally recognized legal entities. Were this not so, federal circuit courts and the Supreme Court would be incapacitated from allowing state-chartered corporations to represent themselves in their courtrooms, since each state could have its own definition of a "corporation".
   • With state-chartered corporations being federally recognizeable, federal laws that generically reference "a corporation" are not limited to the corporation that the United States is. ("United States" is the proper noun of the legal entity of the federal government.)
4. An employee is an officer of a corporation. All you need to do to be an "officer of a corporation" is to be identified as a part of the corporation, to represent the corporation, or to sit in an office building and be told what to do by the corporation. The federal government has identified a list of qualifications of what makes someone an "employee" as opposed to an independent contractor, which covers things like whether the worker can dictate his own schedule, provides his own tools, etc. There is a fine line between a "casual employee" and an "independent contractor", but it's not entirely a question of paperwork but of whether the corporation is treating the natural person as one of its own "gears".
   • "But individuals, when acting as representatives of a collective group, cannot be said to be exercising their personal rights and duties nor to be entitled to their purely personal privileges. Rather they assume the rights, duties and privileges of the artificial entity or association of which they are agents or officers and they are bound by its obligations." UNITED STATES v. WHITE, 322 U.S. 694 (1944)
     http://laws.findlaw.com/us/322/694.html
5. Signing a Form W-4 legally and immediately causes all personal rights to be relinquished and all laws applying to an "employee" to be activated. You cannot validly sign a Form W-4 without signing in the correct signature blank, and said blank is clearly labeled, "Employee's Signature". This form falls under the jurisdiction of 26 USC § 3402, and "employee" of "Employee's Signature" falls under the jurisdiction of § 3401.
6. The employer is liable for the employee's income tax. This is the kicker, the reason why I'm posting this. The "tax honesty movement" proponents argue that workers who file Form W-4 should tell their bosses not to withhold anything because they're natural people and exempt from taxing jurisdiction. The reality is that they are employed, and the employer is obligated to withhold. 26 USC § 3403 reads, "The employer shall be liable for the payment of the tax required to be deducted and withheld under this chapter, and shall not be liable to any person for the amount of any such payment." This is a one-two punch: first it holds the corporation liable for the employee's income tax withholdings, then it forces the employee (and thereby the natural person who signed Form W-4 identifying himself as an "employee") to allow the withholdings to occur.
   • The income tax in a W-4 scenario is applied upon the corporation, which both the employer and the employee are party to. The employer is held liable because the corporation is liable, and the corporation is liable because it is a government-created fictional legal entity.
   • The employee becomes liable, in a sense, because the employee is a "component" (a gear) of the corporation.
   • The natural person is not liable, but the natural person cannot demand the non-taxed, agreed-upon salary amount because the natural person signed the Form W-4 identifying himself as an "employee", which causes §3403 to apply: "The employer shall be liable for the payment of the tax required to be deducted and withheld under this chapter, and shall not be liable to any person for the amount of any such payment."
7. The income tax is imposed before the natural person is paid. When I get my paycheck, I receive my paycheck with taxes already withheld. The question becomes, who paid the tax? The common assumption is that I did. The reality is that the employer did, because only the employer is identified by law (26 USC § 3403) as being liable for the tax.
   • Q: If the natural person is getting paid less than the agreed-upon salary, why can't he just sue the company?
     A: Because the employee filed a Form W-4, which forces the natural person into the jurisdiction of the tax withholding laws of 26 USC § 3401-3406, and as such the natural person, being an employee because he signed Form W-4 identifying himself as an "employee", has his hands tied from holding the employer liable for the withholdings. §3403: "... and [the employer] shall not be liable to any person for the amount of any such payment [of taxes withheld]."
   • Q: If the taxes are imposed upon the employer, rather than upon payment to the natural person, then when a natural person later files a Form 1040 to receive a partial refund, why does the IRS recognize liability for the withholdings less exemptions?
     A: When a natural person identifieds himself with the W-2 when sending Form 1040, he has already assumed association with the corporation which is under federal taxing jurisdiction. The employer is liable, but the employee is under the complete and total control of the employer; being one corporation, they are legally one and the same. By being an employee, the natural person is an agent of the corporation, and the government can do whatever it wants with its own legal fictions. The withholdings are technically just the pulling of money out from one pocket (the employee's wages) and into the other (the IRS).
   • Q: Can't a natural person disclaim being an "employee" when contacting the IRS to receive a refund?
     A: Sure, but then if the natural person signed a Form W-4 identifying himself as an employee then he already perjured himself.
8. It's not a "sin" to file a Form W-4 or for taxes to be withheld. For a few years, I believed it to be perjury, and a sworn lie and therefore a sin, to file a Form W-4 because I was only looking at the first part the definition of "employee", which reads, "For purposes of this chapter, the term 'employee' includes an officer, employee, or elected official of the United States, a State, or any political subdivision thereof, or the District of Columbia, or any agency or instrumentality of any one or more of the foregoing.". When I examined the other part of the definition, "The term 'employee' also includes an officer of a corporation," and that this qualified me, I realized that it was "safe" to file a Form W-4 and to go ahead and have taxes withheld. Since then, though, some religious kooks among tax protesters have accused me of being hell-bound and a proponent of Satan because I pay the income tax. While such rediculous silliness would not normally be worthy of being heard or for that matter spoken of, the fact that I have a Christian background and that I participated in the discussions with the "tax honesty movement" and agreed and still agree that the IRS engages in highly deceptive collection tactics, leads me to pronounce that I don't believe it to be a sin to select the easier of two victimizations. It is better to pay an income tax on a high salary than to not pay income tax on very scarce opportunities. The real question is whether it is a lie to admit tax liability, which would be a sin. It took me some time to consider it, but I have concluded that it is not a lie in the case of a W-2 employee, because I believe that I qualify as "an officer of a corporation" by playing an employee's role in a corporation.
9. Income taxes are only "patriotic" when they are applied to the priviledges of the taxing society. This is simply an issue of scope. What if mom gives her little boy Bobby a sandwich? The sandwich has cash value of $1. What federal government privilege applies in that transaction? None. What if some Japanese company gives a Japanese employee a paycheck, what taxing jurisdiction does the United States have in that transaction? None. Federal taxing jurisdiction only applies to federally taxable activities, and there is no shame in engaging in a life that is not federally taxable.
   • Income taxes do not pay for roads, and they do not build weapons for militaries. That stuff is paid for with other taxes. Rather, the wasteful expenditures that Congress invents is paid for with money that is created out of thin air. Said created money is established by way of bank loans issued by a private banking cartel. The income tax pays interest on these loans. But technically, there is no limit to the amount of cash Congress can spend on whatever they want because of the blank check they have with the bank.
10. It is still possible and reasonable to be tax-free. The income tax as it is imposed today is still ethically wrong and it is only applied legally by way of discriminating paper trails, not by broad federal taxing authority. This is not to say that income taxes in themselves are ethically wrong (see #1 above), but rather I'm saying that the imposition of the tax as it is usually applied today is ethically wrong. It's not the practice of taxing but the method and the reason--the method being coercion, willful confusion, brainwashing, and propogation of false premises, and the reason being to only pay interest on the virtual bank loans to the private banking cartel that the Federal Reserve is, said loans being the method by which federal currency is created. Ethics aside, the only ways to live free of federal income taxes are to:
    • 1099-based consulting does not work because it invokes a Tax ID (the sharing of your social security number), which the corporation or individual that pays out will use to report you as a receipt of income paid out. This is a technically incorrect situation since compensation for valued work is a fair equal exchange (not income), but it is reported nonetheless, and the reporting is voluntary by you by your giving out a tax ID (a social security number).
    • Perform barter exchanges, privately, with people who have no intention of reporting the exchanges with the IRS. Trading books for food, fixing someone's roof in exchange for them letting you live under it, these kinds of things are cashless activities and are not taxable.
    • Working for hire is a form of a barter exchange, unless you're engaging in the priviledge of being an employee of a corporation. However, see #1.
    • Never use a social security number in the context of anything that can result in the receipt of federal currency or can be recognized by government as having cash value.
    • Stock exchanges, IRAs, bank savings accounts, bonds, social security, these are activities that are directly associated with the federal government or Federal Reserve.
    • Real estate is hairy because there are some very significant local laws pertaining to licensing, loans, and all kinds of hairy paperwork, but theoretically with great care it may be possible to live independently by helping people buy and sell real property without involving federal taxing jurisdiction.
11. The real question is, Is it worth it? Most of society settles for adhering to the brainwashing that the tax system consists of. It is very difficult to make a living without settling for engaging in taxable activities. For some time, as a Christian I had my doubts that perhaps following through as such was submitting to the Beast, that using the social security number was the equivalent of having the mark of the beast in one's right hand (the card, the pen) or on one's forehead (remembering the number). Perhaps I'm going to hell for this, I don't know. But I do know that the only way out is to live like the other 80-90% of the world's population--to be without a bank account, to live in a world where this kind of paperwork and these issues are not in the scope of the simple act of trying to survive. Short of throwing everything out and leaving the country to live some kind of life of poverty, though, I see no realistic way of surviving in this society comfortably and with peace of mind without submitting to the income taxation system.

In or around the year 2001, the dot-com bubble collapsed, leaving a multitude of quality software professionals completely jobless. This in turn not only resulted in a drought of opportunities, it became a buyer's market. People who got a job doing software development after 2001 were surrounded by either a lot of non-American workers or else some really incredible geniuses the likes of which one would typically only meet a few times in a lifetime.

Unfortunately, it occurred to me that the post-bust drought may have "spoiled" the people who were hired post-2001 and have sinced moved up and now been promoted into management roles. Their expectations for new employees are steep, and for a while there I thought that expectations were too steep.

But perhaps it's not them. It appears to be a seller drought. It's been getting frustrating. Lately I've been finding myself scratching my head and wondering, where did all the experienced software folks go, anyway? The people who could "speak our language". On my first professional job back in 1998 where I wasn't trying to just do my own independent thing, I was surrounded by people who even today as I look back on them would probably give me a rise, so to speak, on their capacity to contribute to our current team's success, on the assumption that they have since evolved with technology and are proficient at C#, et al. These guys were really geniuses. They could program routers, manage bulk solicited e-mails with sendmail, maintain e-commerce systems with ASP classic and VB5 components, maintain data and sprocs in SQL Server, manage complete data import/export suites with complex user interfaces written in VB, and most of them were very interested in getting away from the Microsoft platform and into "real" development with Java. We're only talking about two or three people here, but there were few of us, mainly myself unfortunately, who were behind on all this and lacked the proficiency to stay productive on a daily basis.

Nowadays, while I still get to work with brilliant folks, I'm noticing that people who are really deeply wrapped up into software are really very scarce. Most people seem to come in two flavours: people who use technology to accomplish business objectives, and people who use technology to win a paycheck. Both are just using software. But the true software enthusiasts are really very uncommon. They are easy to detect online because they typically push out really cool software and share them with the public, stuff like Rhino Mocks and SubSonic. (One of these days I'd like to re-add myself to the mix.)

But I suppose what has happened is that with the workforce expanding by x% every year on a consistent basis, particularly with the dot-com bust now in our history books and no longer fresh in last year's memories, there also comes an influx of dilution of talent. I have no doubt that the software enthusiasts of old are still around doing great things and making great software. They are just rarer now because the need for more people in the industry has resulted in a lot more "kids" like the one I was back in 1998.

On the other hand, the old geniuses and respectable pros have made livelihoods for themselves, and sadly that does not bode well for geek culture. And what about all the free-time geeks? Call me old skool, but there was a time when "average developers" would task ourselves with weekly "network load tests", otherwise known as Quake LAN parties in the office. I haven't seen that in years. Now and then I still come across someone who spends every hour after work playing World of Warcraft or something. But it seems like everywhere I look, I am surrounded by either "normal people" or else geeks and gadgetheads who have essentially abandoned all aspects of geekishness in order to accomodate a wife's new baby, or else they keep their geekish behavior to themselves. From what I've been been able to find, the days of getting a co-worker to stick around after 5:30 and fire up a game to play over the LAN seem to have all but disappeared. And it's not really just about games; I bring up games because people at the office do play games, but they keep it at home, and it's as though they're ashamed to suggest gameplay at the office after hours even though it's completely allowed and tolerated. Typically the excuse, though, is family calls, almost like nature calls. But I did come across someone today who actually really plays first-person shooters, and I was glad to discover it. There just might be some hope for this world after all.

(The suggestion that there is some kind of correlation between LAN gaming and being some kind of experienced software development expert is really just my way of laughing at my own curiosities. There is no correlation. I just wish that there was.)

At work, in any workplace really, the leaders and supporters (including myself, in whatever role I play as a consultant or software engineer or otherwise) are notably hindered and evaluated for the value of the work on a one-to-one basis of how spread out they are. I tend to look upon myself with shame, for instance, when I see myself as a "jack of all trades, master of none", which is something I really don't want to be. I'd much rather be "knowledgeable of much, master of much", even if "much" does not come anywhere close to "all". I feel like I should be able to afford that since I am single, have no life except the life in front of my computer(s), and my sole hobby is software. Even so, I struggle to master my skills and to stay on top of current technologies.

When we take our talents and spread them too wide in the workplace, we find ourselves making excuses for not taking the time to produce quality work. Mediocre output starts getting thrown out there, and no one is expected to apologize because everyone was too busy to take the time to pursue excellence in the output.

I've started to notice that the rule of "spreading yourself thin makes you worthless" is a universal truth that doesn't just apply to people but also to software. I've been "nerding out" on alternative operating systems so that's where I'm applying this lately. The Haiku OS project is distinct from some other projects in this way. Tidbits of wisdom like this have been sticking in my head:

http://haiku-os.org/documents/dev/what_are_you_looking_at

While we developers are used to getting into "the zone" and flinging code that (mostly) works way it should, this is not the kind of focus to which I am referring. When developing an application, the main thing that must not remain as the sole focus is the technology. Technology is the means to the goal. Should we focus on the cool stuff we can build into software, we lose sight of what it is ultimately supposed to do — just like running a marathon while staring at your feet, one tends to not see problems until one quite literally runs into them. What is the goal? The ultimate goal is to write good, fast, stable software which does exactly what it is supposed to do — and nothing else — while making it accessible to the intended type of person, and only one person of that type. 

This goes along with so many different ideologies in software architecture discussions that had me scratching my head as I had a hard time swallowing them, like, "Don't add members to your classes that are not going to meet the needs of the documented requirements, no matter how useful they seem." It took me a few days to accept that rule, because I constantly have ideas popping up in my head about how useful some method might be but I couldn't show for the requirement for it yet. But I later learned why it was an important rule. Once it gets added, it becomes a potential bug. All code is a potential bug. The bugs get QA'd on behalf of the requirements, not on behalf of the presence of the class members. Of course, TDD (test-driven development) and agile / XP practices introduce the notion of "never write code until you write a failing test", so that your new experimental method becomes integrated with the whole test case suite. But now you've just doubled to quadrupled your workload. Is it worth it? Well, it might not matter for a few simple methods, but if that becomes a pattern then eventually you have a measurable percentage of experimental code versus actual, pratical requirements implementations.

There is one thing to keep in mind about the above quote, though, and that is the fact that the above philosphy applies to applications, not to operating systems. The above-quoted article is about building user interfaces, which is an applications-level subject. Whereas, the operating system should have, at one level, a reverse philosophy: technology over function. But let me qualify that: in an operating system, the technology IS the function. I say that because an operating system IS and MUST BE a software runtime platform. Therefore, the public-facing API (which is the technology) is key. But you're still focused on the requirements of the functions. You still have a pre-determined set of public-facing API interfaces that were determined ahead of time in order to meet the needs of some specific applications functionality. Those MUST be specific, and their implementations MUST be strict. There MUST be no unsupported public interfaces. And because the OS is the runtime environment for software, the underlying technology, whether assembly code vs. C runtime API vs. Common Language Runtime vs. Java Virtual Machine, etc, is all quite relevant in an operating system. I'd say that it's only relevant at the surface tier, but it's also relevant at lower tiers because each technology is an integration point. In the Singularity operating system, for instance, which is 99.9% C# code, it's relevant down the deepest tier.

The reason why I bring up Haiku OS vs. other open-source initiatives, as if they had contrasting interests, is because they very much do. Haiku does in fact have a very specific and absolute milestone to reach, and that is compatibility with BeOS 5. It is not yet trying to "innovate", and despite any blog posts indicating opinions otherwise, that may in fact be a very good thing indeed. What happened with the Linux community is that all players are sprawled out across the whole universe of software ideas and concepts, but the end result is a huge number of instances of software projects, all of them mediocre and far too many of them being buggy and error-prone (like Samba, for instance).

More than that, Haiku, as indicated in the above quote, seems to have a pretty strict philosphy: "focus on good, solid, bug-free output of limited features, rather than throwing in every mediocre thing but the kitchen sink". Indeed, that's what Linux seems to do (throw in every mediocre thing but the kitchen sink). There's not much going on in the Haiku world. But with what little it does have, it sure does make me smile. I don't suppose some of that .. or maybe a lot of it .. has to do with the aesthetic design talent involved on the project. Linux is *functional*, and aesthetics are slapped on as an afterthought. Haiku appears at first glance as rather clean, down to its code. And clean is beautiful.

Going around adding futuristic stubs to code is something I've been guilty of in the past but I've found it to be a truly awful, horrible practice, so much so it makes me moan with disgust and terror. It makes a mess of your public-facing APIs, where you have to keep turning to documentation (and breaking tests) to discover what's implemented and what is not. And it leaves key milestone code in a perpetual state of being unable to be RPM'd (released to manufacturers). The best way to write software is to take the most basic functional requirement, implement it, test it thoroughly until it works in all predictable scenarios, add the next piece of functionality, test that piece thoroughly (while testing the first piece of functionality all over again, in an automated fashion), and so on, until all of the requirements are met. In the case of an operating system, this is the only way to build a solid, stable, RTM-ready system.

Microsoft published some beta Managed DirectX 2.0 code a while back, and I posted on their newsgroups, "Why on earth are you calling this 'beta' when the definition of 'beta', as opposed to 'alpha', is that the functionality is SUPPOSED to be there but is buggy? Only 'alpha' releases should include empty, unimplemented stubs, yet you guys throw this stuff out there calling it 'beta'. How are we supposed to test this stuff if the stubs are there but we don't know if they're implemented until we try them?" Shortly after I posted that rant, they dropped the Managed DirectX 2.0 initiative and announced that the XNA initiative was going to completely replace it.  I obviously don't think that my post was the reason why they dropped the MDX2 initiative, but I do think it started a chain of discussions inside Microsoft that made them start rethinking all of their decision-making processes all the way around (not exclusively, but perhaps including, the beta / alpha issue I raised). Even if just one of their guys saw my rant and thought, "You know, I think this whole MDX2 thing was a mistake anyway, we should be focusing on XNA," I think my little rant triggered some doubts. 

The React OS project also had me scratching my head. Instead of littering the OS with placeholders of wanted Windows XP / Vista UI and API features while the kernel is still painfully unfinished, which indeed I have observed, what the React OS team should be doing is saying, okay, we're going to set these milestones, and we're not going to add a single stub or a single line of code for the next milestone until the current milestone has been reached. Our milestones are specifically and clearly defined:

1. Get a primitive kernel booting off a hard drive. Execute some code at startup. Master introspection of the basic hardware (BIOS, hard drives, memory, CPU, keyboard, display, PCI, PCIE, USB controllers).
   • Test, test, TEST!! Stop here!! Do not pass Go! You may not proceed until all tests PASS!!
2. Basic Execution OS. Implement a working but basic Windows NT-like kernel, HAL, FAT16/FAT32 filesystem, a basic user-mode runtime, a basic Ethernet + IPv4 network stack, and a DOS-style command line system for controlling and testing user-mode programs.
   • This implements a basic operating system that will execute C/C++ code and allows for future development of Win32 code and applications.
   • Test, test, TEST!! Stop here!! Do not pass Go! You may not proceed until all tests PASS!! 
   • Making this milestone flawless will result in an RTM-ready operating system that can compete with classic, old-school UNIX and MS-DOS.
3. Basic Server OS. Implement Windows 98-level featureset of Win32 API functionality (except those that were deprecated) using Windows XP as the Win32 API design and stability standard, excluding Window handles and all GUI-related features.
   • This includes threading and protected memory if those were not already reached in Milestone 1.
   • Console only! No GUI yet.
   • Add registry, users, user profiles.
   • Add a basic COM registration subsystem.
   • Add NTFS support, including ACLs.
   • Add Windows Services support.
   • Complete the IPv4 network stack, make it solid.
   • This implements a second-generation command-line operating system that will execute multi-threaded Win32 console applications.
   • Test, test, TEST!! Stop here!! Do not pass Go! You may not proceed until all tests PASS!! 
   • Making this milestone flawless will result in an RTM-ready, competing operating system to Windows Server 2000.
4. Basic Workstation OS. Focus on Win32 GUI API and Windows XP-compatible video hardware driver support. Prep the HAL and Win32 APIs for future DirectX compatibility. Add a very lightweight GUI shell (one that does NOT try to look like Windows Explorer but that provides mouse-driven functionality to accomplish tasks).
   • This implements a lightweight compatibility layer for some Windows apps. This is a key milestone because it brings the mouse and the GUI into the context, and allows the GUI-driven public to begin testing and developing for the system.
   • Test, test, TEST!! Stop here!! Do not pass Go! You may not proceed until all tests PASS!!
   • This milestone brings the operating system to its current state (at 0.32), except that by having a stricter milestone and release schedule the operating system is now extremely stable.
5. CLR support, Level 1
   • Execute MSIL (.NET 2.0 compatible).
   • Write new Windows services, such as a Web server, using the CLR.
   • This is huge. It adds .NET support and gives Microsoft .NET and the Mono project a run for their money. And the CLR alone gives understanding to the question of why Microsoft was originally tempted to call Windows Server 2003 "Windows Server .NET".
   • Test, test, TEST!! Stop here!! Do not pass Go! You may not proceed until all tests PASS!!
   • This introduces another level of cross-platform compatibility, and makes the operating system an alternative to Windows Server 2003 with .NET.
6. CLR support, Level 2, and full DirectX 9 compatibility
   • Execute MSIL (.NET 3.0 compatible), including and primarily
     • "Avalon" / Windows Presentation Foundation (XAML-to-Direct3D, multimedia, etc)
     • "Indigo" / Windows Communication Foundation
     • WF (Workflow)
     • .. do we care about InfoCard?

These are some really difficult if not impossible hurdles to jump; there isn't even any real applications functionality in that list, except for APIs, a Web server, and a couple lightweight shells (console and GUI). But that's the whole point. From there, you can pretty much allow the OS to take on a life of its own (the Linux symptom). The end result, though, is a very clean and stable operating system core that has an RTM version from the get-go in some form, rather than a walking, bloated monster of a zillion features that are half- or non-implemented and that suffers a Blue Screen of Death at every turn.

PowerBlog proved to be an interesting learning opportunity for me in this regard. There are a number of things I did very wrong in that project, and a number of things I did quite right. Unfortunately, the number of things I did wrong outweighed the other, most notably:

• Starting out with too many features I wanted to implement all at once
• Starting implementation with a GUI rather than with the engine
• Having no knowledge of TDD (test-driven development)
• Implementing too many COM and Internet Explorer integration points (PowerBlog doesn't even compile on Windows Vista or on .NET v2.0)
• Not paying close enough attention to server integration, server features (like comments and trackbacks), and Atom
• Not getting around to implementing automatic photo insertion / upload support even though I basically understood how it needed to be done in the blog article editor side (it was nearly-implemented on the MetaWeblog API side)
• Not enough client/server tests, nor mastery of C# to implement them quickly, nor knowledge of how to go about them in a virtualized manner
• Too many moving parts for a single person to keep track of, including a script and template editor with code highlighting

What I did right:

• Built the GUI with a specific vision of functionality and user experience in mind, with moderate success
• Built the engine in a seperate, pluggable library, with an extensibility model
• The product did work very well, on a specific machine, under specific requirements (my personal blog), and to that end for my purposes it was a really killer app that was right on par with the current version of Windows Live Writer and FAR more functional (if a bit uglier)
• Fully functional proof of concept and opportunity to discover the full life-cycle of product development including requirements, design, implementation, marketing, and sales (to some extent, but not so much customer support), and gain experience with full-blown VB6, COM/ActiveX, C#, XML, SOAP, XML-RPC

I suppose the more I think about the intricacies of PowerBlog and how I went about them, I have more and more pride in what I accomplished but that no one will ever appreciate but me. In fact, I started out writing this blog post as, "I am SO ashamed of PowerBlog," but I deleted all that because when I think about all the really cool features I successfully implemented, from a geeky perspective, wow, PowerBlog was really a lot of fun.

That said, it did fail, and it failed because I did not focus on a few, basic, simple objectives and test them from the bottom up.

I can't stop thinking about how globally applicable these principles are at every level, both specifically in software and broadly in my career and the choices I make in my everyday life. It's no different than a flask of water. Our time, energy, can be spilled out all over the table, or carefully focused on meeting specific objectives. The latter offsets a world of refined gold from a world full of mediocrity and waste.

There is one good thing to say about spreading yourself out in the first place, though. Spreading out and doing mediocre things solely for the intent of learning the idiosyncracies of all that gets touched is key to knowing how best to develop the things that are being focused on. One can spend months testing out different patterns for a simple piece of functionality, but experiencing real-world failures and wastes of efforts on irrelevant but similar things causes a person to be more effective and productive at choosing a pattern for the specific instance and making it work. In other words, as the saying goes, a person who never fails is never going to succeed because he never tried. That applies in the broad and unfocused vs. specific and focused philosophy in the sense that just pondering the bigger scope of things, testing them out, seeing that they didn't work, and realizing that the biggest problem was one of philosophy (I didn't FOCUS!) not only makes focusing more driven, but the experience gained from "going broad" will help during the implementation of the focused output, if only in understanding the variations of scenarios of each implementation.