Again, if you are a typical W-2 wage earner, those things CANNOT be deducted, unless you enjoy trying to explain them to your friendly IRS auditor (and having them denied). You can't be a business owner without a business, which most wage earners don't have. If you try to invent one, or even have a legit side business but attempt writing off non-business things to it, you are just asking for a very expensive trip to tax court and possibly prison for tax fraud. The IRS publications are pretty clear on what is and is not deductible for an employee. Your email example, just to cite one case, is explicitly excluded if we are talking about an employee checking email at home (see the example on page 4 of Pub 529).
I disagree. If you're a standard working stiff with nothing but W-2 and maybe some interest income, it's highly unlikely that your itemized deductions will be anything more than taxes, mortgage interest, and charity. You probably won't qualify for medical or miscellaneous deductions because of the AGI percentage requirements. You might have child care credits, but that's a credit, not a deduction. You don't need a professional to work that out.
Yes, some people have special circumstances, but it's just incorrect to set a general expectation of being able to "recoup thousands of dollars". For most people, it's not going to happen.
Now, if you are self-employed, that's different.
The 1065 and K-1's are filed on paper since I can't be arsed to buy the TurboTax version that has that stuff in it. I do use Turbo basic to e-file our personal fed return. I do the state return on paper, again because TT wants too much for the PA state forms.
I've done the free web-based returns (both TT and Taxact) in the past for doing the kids' returns when they were in college. They are fine for trivial returns but get annoying quickly for more complicated stuff. I recall Taxact in particular making me re-answer questions repeatedly because I needed to go back and edit something.
I've never felt the need for an accountant. The stuff can be a little tricky but for most people it's not that bad. If you have limited oil drilling depletion allowances and suchlike stuff, that might be different...
It's really simple:
If you have a job, you can get a job.
If you don't have a job, getting a job is harder.
"Promised" is an elusive word, but assuming that the $70K offer comes thru, why not take it unless he has a gaming company offer in hand? which I assume he doesn't. It's always a good thing to be able to afford housing and food while looking for the job of one's choice.
Besides, he might be surprised, and like the promised job. (Or, it might be a small step above a Siberian work camp. One never really knows about these things until one tries it; but of course the same goes for the "dream" job at a gaming company!)
Whether coding standards really matter for maintainability generally depends on how much information you expect to be carried by the formatting.
We generally assume that indentation follows block structure, so indentation standards tend to be very important. I've wasted hours over bugs that were hidden by incorrect indentation.
Naming conventions may matter if the coding standard dictates a different styles for different scopes (e.g. LeadingCapital for global names, etc), or if type info is embedded in the name (pszFoo, lBar, etc).
Beyond that, coding standards help readability but that's about it. That may or may not be an issue depending on the team involved; one benefit of a uniform look is that you get less of "You're stuck fixing that code forever because I can't read it".
Whitespace standards (outside of indentation) are generally of marginal to no use IMHO. I'd follow reasonable whitespace standards, just for that uniform look, but nobody should be spending hours on it. The fancier the coding standard, particularly as it applies to variable naming, the less useful it is in general.
You shouldn't be losing "hundreds of hours" in code reviews, though. Either you're deliberately being obtuse about things or your coding standards are insanely complex, or uselessly ambiguous. There are a number of things I don't like about the coding standard I work in now, but I stick to it anyway because it makes the code more uniform and easier to read. Have you tried doing the same?
AOA indicators aren't perfect either. What do you do when the AOA vane ices up and sends an incorrect position? It's easy to say "add sensor X" but then you have to deal with the implications of sensor X failing or sending bad data.
The biggest issue, quite frankly, is that the pilots didn't do anything they were supposed to do. They didn't perform the lost airspeed procedure. They used low altitude stall procedures when confronted with a high altitude stall onset (the two are very different). It was a thorough screw-up from beginning to end, unfortunately. The contributions of the airframe design to the accident were minor at most, and it's difficult to see how presenting different information would have helped a couple of pilots who had already ignored everything else the airplane had told them.
and airliners.net also. The ones who know what they are talking about are unanimous in that it had little to do with the non-backdriven controls; the pilots flying were so disoriented that it probably would have taken a giant flashing sign saying "you're falling out of the air, dummies!" to get them to nose down.
And anyway, FBW != back-driven controls. The thread title is wrong and misleading. Boeing uses FBW too, but they back-drive the yoke and throttles. This has been discussed plenty as well, and there's no inherent advantage to one way over the other.
"The irony-meter is off the charts..."
Particularly since this article is immediately followed on the page with "Baboons learn to identify words". It seems that at least some baboons haven't learned to associate sense with those words.
The cracks are in aluminum wing rib feet. Has nothing to do with composites.
"Rockets required bits of "unobtanium" during the 60s."
Not really. I don't doubt that there were some advances in high temperature materials, but jet engines were driving the same research as well. The stuff in 60's engines were nowhere near the theoretical edge that a hundred thousand kilometer long carbon fiber nanotube is.
The early rocket engine problems were mostly related to learning about injector voodoo (the F1), the physical properties of liquid hydrogen (RL10 Centaur), and understanding the bearing and sealing issues related to high powered turbopumps (any number of early engine explosions). None of these required anything like the fundamental advances in material science that an elevator will need.
Yeah, I wasn't impressed. Rockets may be inefficient, but they are a hell of a lot better than anything else we have currently -- at least, anything that doesn't require large quantities of unobtanium. Space elevators are right on the edge of what is maybe barely possible in a few years, never mind the past 50.
He does mention the key fact about getting to orbit -- the need for a massive horizontal velocity -- but it almost sounds like he doesn't really comprehend the energetics involved.
He had some valid points about payload sizing, but as far as I know that has been a non-issue for years if not decades.
I have a basement home office as well, with a leaky door. There's no point in keeping the house heat up since it doesn't help. I simply put pants on under my bathrobe in the winter.
Count a +1 for pair networks. Reliable, solid, and not annoying. Their plan offerings were simple and easy to choose among, last I looked. (I picked one 11 years ago and haven't had to change.)
I have had interactions with them exactly twice, and once was them offering a constructive suggestion as to spam handling. That's the kind of provider I like, all walk and no talk.
Yeah, good luck with that. Have a second career ready?
I once consulted on a large program that had been written in as convoluted a manner as possible, with few or no comments. The guy who wrote it used to brag about "job security". Well, when the company finally allocated a budget to replace the program, they not only fired the guy, but made sure that as many people in that industry as possible knew about it. He was unable to find a new job in programming, and last I heard, he was trying to sell cars somewhere down south.
You might have job security for a while, but it's gonna catch up with you.