Technology Status Update 2016

by Jon Davis 10. July 2016 09:09

Hello, peephole. (people.) Just a little update. I've been keeping this blog online for some time, my most recent blog entries always so negative, I keep having to see that negativity every time I check to make sure the blog's up, lol. I'm tired of it so I thought I'd post something positive.

My current job is one I hope to keep for years and years to come, and if that doesn't work out I'll be looking for one just like it and try to keep it for years and years to come. I'm so done with contracting and consulting (except the occasional mentoring session on code mentor -dot- io). I'm still developing, of course, and as technology is changing, here's what's up as I see it. 

  1. Azure is relevant. 
    The world really has shifted to cloud and the majority of companies, finally, are offloading their hosting to the cloud. AWS, Azure, take your pick, everyone who hates Microsoft will obviously choose AWS but Azure is the obvious choice for Microsoft stack folks, there is nothing meaningful AWS has that Azure doesn't at this point. The amount of stuff on Azure is sufficiently terrifying in quantity and supposed quality enough to give me a thrill. So I'm done with hating on Azure, after all their marketing and nagging and pushing, Microsoft has crossed a threshold of market saturation that I am adequately impressed. I guess that means I have to be an Azure fan, too, now. Fine. Yay Azure, woo. -.-
  2. ASP.NET is officially rebooted. 
    So I hear this thing called ASP.NET Core 1.0 formerly known as ASP.NET 5 formerly known as ASP.NET vNext has RTM'd, and I hear it's like super duper important. It snuck by me, I haven't mastered it, but I know it enought to know a few things:
    • It's a total redux by means of redo. It's like the Star Trek reboot except it’s smaller and there are fewer planets it can manage, but it’s exactly like the Star Trek reboot in that it will probably implode yours.
    • If you've built your career on ASP.NET and you want to continue living on ASP.NET's laurals, now is not the time to master ASP.NET 1.0 Core. Give it another year or two to mature. 
    • If you're stuck on or otherwise fascinated by non-Microsoft operating systems, namely Mac and Linux, but you want to use the Microsoft programming stack, you absolutely must learn and master ASP.NET Core 1.0 and EF7.
    • If all you liked from ASP.NET Core 1.0 was the dynamic configs and build-time transpiles, you don't need ASP.NET Core for that LOL LOL ROFLMAO LOL LOL LOL *cough*
  3. The Aurelia Javascript framework is nearly ready.
    Overall, Javascript framework trends have stopped. Companies are building upon AngularJS 1.x. Everyone who’s behind is talking about React as if it was new and suddenly newly relevant (it isn’t new anymore). Everyone still implementing Knockout are out of the loop and will die off soon enough. jQuery is still ubiquitous and yet ignored as a thing, but meanwhile it just turned v3.

    I don’t know what to think about things anymore. Angular 2.0 requires TypeScript, people hate TypeScript because they hate transpilers. People are still comparing TypeScript with CoffeeScript. People are dumb. If it wasn’t for people I might like Angular 2.0, and for that matter I’d be all over AureliaJS, which is much nicer but just doesn’t have Google as the titanic marketing arm. In the end, let’s just get stuff done, guys. Build stuff. Don’t worry about frameworks. Learn them all as you need them.
  4. Node.js is fading and yet slowly growing in relevance.
    Do you remember .. oh heck unless you're graying probably not, anyway .. do you remember back in the day when the dynamic Internet was first loosed on the public and C/C++ and Perl were used to execute from cgi-bin, and if you wanted to add dynamic stuff to a web site you had to learn Perl and maybe find Perl pearls and plop them into your own cgi-bin? Yeah, no, I never really learned Perl, either, but I did notice the trend, but in the end, what did C/C++ and Perl mean to us up until the last decade? Answer: ubiquitous availability, but not web server functionality, just an ever-present availability for scripts, utilities, hacks, and whatever. That is where node.js is headed. Node.js for anything web related has become and will continue to be a gigantic mess of disorganized, everyone-is-equal, noisily integrated modules that sort of work but will never be as stable in built compositions as more carefully organized platforms. Frankly, I see node.js being more relevant as a workstation runtime than a server runtime. Right now I'm looking at maybe poking at it in a TFS build environment, but not so much for hosting things.
    I will always have a bitter taste in my mouth with node.js after trying to get integrated with Express and watching the whole thing just crumble, with no documentation or community help to resolve it, and this happened not just once on the job (never resolved before I walked away) but also during a code-mentor mentoring session (which we didn't figure out), even after a good year or so of maturity of the platform after the first instance. I still like node.js but will no longer be trying to build a career on it.
  5. Pay close attention and learn up on Swagger aka OpenAPI. 
    Remember when -- oh wait, no, unless you're graying, .. nevermind .. anyway, -- once upon a time something called SOAP came out and it came with it a self-documentation feature that was a combination of WSDL and some really handy HTML generated scaffolding built into web services that would let you manually test SOAP-based services by filling out a self-generated form. Well now that JSON-based REST is the entirety of the playing field, we need the same self-documention. That's where Swagger came in a couple years ago and everyone uses it now. Swagger needs some serious overhauling--someone needs to come up with a Swagger-compliant UI built on more modular and configurable components, for example--but as a drop-in self-documentation feature for REST services it fits the bill.
    • Swagger can be had on .NET using a lib called Swashbuckle. If you use OData, there is a lib called Swashbuckle.OData. We use it very, very heavily where I work. (I was the one who found it and brought it in.) "Make sure it shows up and works in Swagger" is a requirement for all REST/OData APIs we build now.
    • Swagger is now OpenAPI but it's still Swagger, there are not yet any OpenAPI artifacts that I know of other than Swagger. Which is lame. Swagger is ugly. Featureful, but ugly, and non-modular.
    • Microsoft is listed as a contributing member of the OpenAPI committee, but I don't know what that means, and I don't see any generic output from OpenAPI yet. I'm worried that Microsoft will build a black box (rather than white box) Swagger-compliant alternative for ASP.NET Core.
    • Other curious ones to pay attention to, but which I don't see as significantly supported by the .NET community yet (maybe I haven't looked hard enough), are:
  6. OData v4 has potential but is implementation-heavy and sorely needs a v5. 
    A lot of investments have been made in OData v4 as a web-based facade to Entity Framework data resources. It's the foundation of everything the team I'm with is working on, and I've learned to hate it. LOL. But I see its potential. I hope investments continue because it is sorely missing fundamental features like
    • MS OData needs better navigation property filtering and security checking, whether by optionally redirecting navigation properties to EDM-mapped controller routes (yes, taking a performance hit) or some other means
    • MS OData '/$count' breaks when [ODataRoute] is declared, boo.
    • OData spec sorely needs "DISTINCT" feature
    • $select needs to be smarter about returning anonymous models and not just eliminating fields; if all you want is one field in a nested navigation property in a nested navigation property (equivalent of LINQ's .Select(x=>new {ID=x.ID, DesiredField2=x.Child.Child2.DesiredField2}), in the OData result set you will have to dive into an array and then into an array to find the one desired field
    • MS OData output serialization is very slow and CPU-heavy
    • Custom actions and functions and making them exposed to Swagger via Swashbuckle.OData make me want to pull my hair out, it takes sometimes two hours of screaming and choking people to set up a route in OData where it would take me two minutes in Web API, and in the end I end up with a weird namespaced function name in the route like /OData/Widgets/Acme.GetCompositeThingmajig(4), there's no getting away from even the default namespace and your EDM definition must be an EXACT match to what is clearly obviously spelled out in the C# controller implementation or you die. I mean, if Swashbuckle / Swashbuckle.OData can mostly figure most of it out without making us dress up in a weird Halloween costume, surely Microsoft's EDM generator should have been able to.
  7. "Simple CRUD apps" vs "messaging-oriented DDD apps"
    has become the new Microsoft vs Linux or C# vs Java or SQL vs NoSQL. 

    imageThe war is really ugly. Over the last two or three years people have really been talking about how microservices and reaction-oriented software have turned the software industry upside down. Those who hop on the bandwagon are neglecting to know when to choose simpler tooling chains for simple jobs, meanwhile those who refuse to jump on the bandwagon are using some really harsh, cruel words to describe the trend ("idiots", "morons", etc). We need to learn to love and embrace all of these forms of software, allow them to grow us up, and know when to choose which pattern for which job.
    • Simple CRUD apps can still accomplish most business needs, making them preferable most of the time
      • .. but they don't scale well
      • .. and they require relatively very little development knowledge to build and grow
    • Non-transactional message-oriented solutions and related patterns like CQRS-ES scale out well but scale developers' and testers' comprehension very poorly; they have an exponential scale of complexity footprint, but for the thrill seekers they can be, frankly, hella fun and interesting so long as they are not built upon ancient ESB systems like SAP and so long as people can integrate in software planning war rooms.
    • Disparate data sourcing as with DDD with partial data replication is a DBA's nightmare. DBAs will always hate it, their opinions will always be biased, and they will always be right in their minds that it is wrong and foolish to go that route. They will sometimes be completely correct.

  8. Integrated functional unit tests are more valuable than TDD-style purist unit tests. That’s my new conclusion about developer testing in 2016. Purist TDD mindset still has a role in the software developer’s life. But there is still value in automated integration tests, and when things like Entity Framework are heavily in play, apparently it’s better to build upon LocalDB automation than Moq.
    At least, that’s what my current employer has forced me to believe. Sadly, the purist TDD mindset that I tried to adopt and bring to the table was not even slightly appreciated. I don’t know if I’m going to burn in hell for being persuaded out of a purist unit testing mindset or not. We shall see, we shall see.
  9. I'm hearing some weird and creepy rumors I don't think I like about SQL Server moving to Linux and eventually getting itself renamed. I don't like it, I think it's unnecessary. Microsoft should just create another product. Let SQL Server be SQL Server for Windows forever. Careers are built on such things. Bad Microsoft! Windows 8, .NET Framework version name fiascos, Lync vs Skype for Business, when will you ever learn to stop breaking marketing details to fix what is already successful??!
  10. Speaking of SQL Server, SQL Server 2016 is RTM'd, and full blown SSMS 2016 is free.
  11. On-premises TFS 2015 only just recently acquired gated check-in build support in a recent update. Seriously, like, what the heck, Microsoft? It's also super buggy, you get a nasty error message in Visual Studio while monitoring its progress. This is laughable.
    • Clear message from Microsoft: "If you want a premium TFS experience, Azure / Visual Studio Online is where you have to go." Microsoft is no longer a shrink-wrapped product company, they sell shrink wrapped software only for the legacy folks as an afterthought. They are hosted platform company now all the way. .
      • This means that Windows 10 machines including Nokia devices are moving to be subscription boxes with dumb client deployments. Boo.
  12. imageAnother rumor I've heard is that
    Microsoft is going to abandon the game industry.

    The Xbox platform was awesome because Microsoft was all in. But they're not all in anymore, and it shows, and so now as they look at their lackluster profits, what did they expect?
    • Microsoft: Either stay all-in with Xbox and also Windows 10 (dudes, have you seen Steam's Big Picture mode? no excuse!) or say goodbye to the consumer market forever. Seriously. Because we who thrive on the Microsoft platform are also gamers. I would recommend knocking yourselves over to partner with Valve to co-own the whole entertainment world like the oligarchies that both of you are since Valve did so well at keeping the Windows PC relevant to the gaming markets.

For the most part I've probably lived under a rock, I'm sure, I've been too busy enjoying my new 2016 Subaru WRX (a 4-door racecar) which I am probably going to sell in the next year because I didn't get out of debt first, but not before getting a Kawasaki Vulcan S ABS Café as my first motorized two-wheeler, riding that between playing Steam games, going camping, and exploring other ways to appreciate being alive on this planet. Maybe someday I'll learn to help the homeless and unfed, as I should. BTW, in the end I happen to know that "love God and love people" are the only two things that matter in life. The rest is fluff. But I'm so selfish, man do I enjoy fluff.  I feel like such a jerk. Those who know me know that I am one. God help me.

image  image
Top row: Fluff that doesn’t matter and distracts me from matters of substance.
Bottom row: Matters of substance.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5


ASP.NET | Blog | Career | Computers and Internet | Cool Tools | LINQ | Microsoft Windows | Open Source | Software Development | Web Development | Windows

A Career Reset: Back To Development

by Jon Davis 14. January 2014 17:17
I haven't been posting consistently but neither has anything been consistent in my professional life lately. 2013 turned out to be the most difficult year in my 16 years of professional development--and that's saying a lot, considering from 2000 to 2004 after the dot-com bubble burst I was barely making five-digits and ate dollar meals while I worked 16-20 hours a day (and slept 12 hours, and saw daytime flip every couple days) for myself trying to learn the ins and outs of basic micro-ISV and independent consulting. 2013 was worse. It started out with me being assigned by (at the time) my consulting firm employer to fill another seat in an already overloaded project that was already sinking. A month later, the client abruptly laid off some 150-200 or so contractors, including myself, and a couple days after I got home I was laid off. Now as awfully annoying and painful as that was, I did not blame my employer for that. Their position was that they suddenly had a bunch of people on the bench without an assignment, and it was not profitable to have them all sit on the bench waiting for an assignment because bench time is still salary pay. I totally got that. It made perfect sense. And I was grateful that they said they would take me back if I came back when project opportunities opened up--so much so, in fact, that for the next four months I worked part-time as a contractor for someone I never really intended to stick around with, so that I could come back and demonstrate my loyalty.
What did have me scratching my head, however, was that some of the best talent in the company, including my manager, were also laid off. And when I did come back and say, "Please hire me back?", I found out that some people subsequently quit. When these changes occur, the dynamics of the entire company changes. People who were in seats of equality now sit in seats of power, and they're learning the ropes of leadership. Mistaking the role of leadership for the role of authority (they are not equivalent; being a leader has prescribed authority but only to support the leader's actual responsibilities), the worst case--and yet apparently the default scenario--is that in their immaturity in such an abrupt role, the perceived necessity on their part to backstab and cut throats makes its way into their tempted hands, the hands of their newfound authority.
I Disagree.
I made some obvious mistakes when I was accepted back with the company. As a new person on the assigned project (a rather intimidating one, one that had 50 or so projects in the Visual Studio solution, an existing migration from CoffeeScript to raw Javascript, and a new migration just beginning going from Backbone to Knockout), I believed it was imperative that I receive guidance, even as a senior developer, from the peers and leaders on the team regarding shared resources, without wading through hundreds of files, as well as regarding what would constitute embraceable proper coding conventions in the new migration effort. I also insisted that new feature stories be properly clarified and documented since anything assigned to me may end up on someone else's plate (i.e. I might be laid off again, or something similar). I still believe these things. The problem was, these things require the cooperation of the team, and the team was already shaken, just like I was, by recent history of layoffs and quitters. They were managing their stress by cutting themselves off and enjoying the camaraderie that they had already established within their cliques. I was the new guy, one with opinions. I was a distraction. And where I was pursuing healthy discussion, they wrote me off after only a few short words. Basically, I wasn't likeable with this particular team, and I while I hadn't forgotten how I was coming across as a person I was too dependent upon validation feedback that never came, at least not discreetly and directly from my leads in an effort to resolve the patterns. It really didn't help that I had high blood pressure and didn't have medication for it; I had headaches and my heart was pounding, I was on the edge and couldn't focus. I disagreed with disagreeable things not vehemently but perhaps pesteringly. Most regretfully, I made a huge mistake of using false-rhetoric ("I can't even read that") to deliberately make a point about unnecessary code complexity where my words if taken literally could only be taken as "I'm too stupid for this job". And unfortunately, rather than giving me direct feedback about how I came off to help me identify areas of blindness--not a single word--they relayed their frustrations up the ladder. An hour after I showed up to work one day and the team was huddled in a corner, backs turned, discussing (finally) why I deserve no respect and basically ripping me to shreds, out of nowhere, a company exectuve shuffled me onto an elevator and told me that I had been pulled off the project because I "lack skill". 
Besides the weaknesses observed on the part of the team, I knew what went wrong on my part as well. That four-month timespan between getting laid off and getting re-hired was spent working part-time, for a client who was not interested in modern coding conventions, and the rest of my time wasn't even spent thinking about software at all. I was taking a career break, tinkering with video editing. If I knew at the time how much this was going to cost me I would have made much different choices. This is not the sort of industry that one can afford to stop thinking in code. I showed up unprepared. This was a huge mistake, one I don't intend to ever repeat. But more importantly, the choices I made of presenting myself to the team was not a fit for that team's culture. In fact, while even today I believe I was right in my expectations of the team to accomodate discussion and documentation, I was wrong to demand it. In fact, I should have kept my mouth shut. Showing up and making demands as the new guy, and freaking out when I don't get the leadership from the leaders that I need, isn't how teams work. This was a relatively large team; developers, QA, and project management combined, there were probably around 30 people in the meeting rooms, and I didn't hesitate to open my mouth and tell those who were writing things down how they should be written. Clearly, everyone in the room learned the rule about rudeness, that the rudest thing a person can do is to call someone "rude" in front of others. But I guess in my temporary moments of thoughtlessness I was jumping around the edges of social appropriateness and trying to rely on immediate feedback to help me find that line. It didn't work. I just made myself look like an ass. It is unfortunate that no one I worked under criticized me privately afterwords. A designer fellow did, but I tended to wait to hear it from my leads. It's unfortunate that they just disappeared, and some time later I had to hear it from an executive who was relying solely on upstream feedback.
I spent the next three weeks on the bench. I spent that time learning how to write Android apps in "native" Java. I watched software development opportunities come in and were discussed even with new recruits, but apparently that previous project's feedback issued up to the leadership tarnished my reputation as a developer so badly that my next assignment was in system operations--a DevOps role--working remotely without a single peer and not a single person from my company working alongside me. Yes, ops. PowerShell, SCOM, IIS logs, performance reporting. I sucked at this! Maybe not so much the PowerShell stuff--actually, the PowerShell stuff I did was pretty cool, I had fun with that. But ultimately I knew going into this that it was over. I being the one who was described in a company dinner announcement as "the elephant in the room" upon my return was no longer welcome in his capacity as a developer. And every day I was stressed out about ops-related concerns and dealing with a difficult client who already had a history of contractors quitting on him was another day I couldn't get my head in gear around my passion in development. I voluntarily resigned in November.
I have been on the job hunt ever since. The fact is, I am indeed a senior-level software developer. I have learned my lessons, even as some of them are reminder lessons previously learned years ago. I have been trying to catch up since November on what is going on in technology space. It has been crazy over the last year or two, how much has changed. Javascript is the new de facto industry coding language, for example, and as simple a language as it is, it is a difficult language to master, and while I don't hate the language, I do struggle to enjoy reading other people's Javascript code. The coding conventions of proper development with Javascript is also widely varied, since no one entity prescribes its best practices (no, not even Douglas Crockford), and all the various most popular libraries for both client and server (Node.js) have almost completely different ideas of what constitutes "good code". My responsibility in the industry as a senior-level software professional is to digest the bulk of what is very well embraced, identify the commonalities of ideals such as the implementation of [revealing] modules (as with Require.js), disambiguate the confusing semantics (prototypal inheritance is the opposite of using object.prototype.*), appreciate the good and bad of each of the popular client libraries (Knockout, Angular, Ember, et al), glean from alternative approaches to server solutions (Node.js, Nancy, OWIN, ..), stay on top of what has changed in the .NET stack (ASP.NET MVC 5, C# 5 [async], EF 6 ..), and remain mindful of enterprise software patterns and practices (DDD, BDD, etc). I still feel like I'm scratching the surface just listing these, there's so much more than this to know, but, again, the more you know the more you realize how little you know.
I'm also feeling the pain, yet again, of the staleness of this blog, not just the content, which is frequently lame, but the blog software. I am probably going to rewrite my blog engine. (This one wasn't written by me anyway, though I've built them in the past.) I've been down this road before, and had some false starts, and I'll reiterate, it's not that I think that blogging software is still interesting or representative in any way of some special class of software development. Besides the details of Atom, OPML, Blogger API, etc., to the ignorant mind a blog is just a sorted list, a list of blobs of formatted text. There is more to it than that, but that's not what matters, and that's not why I need to do it at some point. Others have stated it [link], writing a blogging engine is a good step in practicing the basics of modern web development. In my case, I might take up a major tweak of Ghost, adding publishing APIs (if missing) and WYSIWYG editor support, all the while staying in Javascript and Node.JS. Why not the .NET Framework? Why, because I already know it, I don't need to prove it to myself that I know it. Then again, I might anyway. I haven't started yet. Well, I have, but multiple false starts leading to abandon leads me back at the drawing board--which is good. It forces me to check up on what's trending today

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5



In Consideration Of Going Solo

by Jon Davis 21. June 2013 07:46

I’m beat. I spent today packing up items I had valued—a guitar, a nice camera, a big collection of Stargate DVDs—to ship off to various buyers around the country. I had no regrets as I went dumpster-diving at Guitar Center trying to fetch a shipping container suited for the size and shape of a guitar. After all, I need the chump change this transaction will produce. It will cover a fraction of my rent.

Ever play the game EVE Online? I used to. But I was never particularly good at it. I tended to enjoy the agent missions, and I was just not quite good enough to be of great help in PvP team versus team gameplay, mainly because I was terribly intimidated by actual human beings. Nevertheless, I came back to it now and then for a month or two, each time I’d look for a corp (EVE’s equivalent of a guild) to join. I’d end up staying solo, though, and ultimately I’d let the account subscription expire again, either before or after I’d get dismissed from the corp for not logging in enough. Each time I play EVE, indeed each time I tell myself “okay I’m going to do better this time at devoting my attention to a corp”, it becomes more pointless, because a) my corp history would be increasingly filled up with a strangely high number of employment records, and b) I’d be the new guy in the big, long-standing corp again. I’d have to learn the names again. I’d have to understand the corp’s ways of going about the game again. And they’d look at my history and detect what I already know—I’m either a flake or I’m a creep. Not that I choose to be either. But this was a lose-lose situation, and a vicious cycle. And so I end up logging back into EVE Online now and then, just me, hauling some simple battleship, knocking out non-player characters as I do mundane agent missions. And then I get bored by it all, and stop logging in .. until next time.

It does sadden me that I fear that my EVE Online profile and history may be a reflection upon my real-world employment history. And it isn’t even that I don’t have the capacity to be an excellent team member, or to produce excellent output, or to exhibit a personality that people can get along with. It’s that, to say as much, is a little jarring. I can be an excellent team member; I can produce excellent output; I can exhibit a nice personality. What happens, unfortunately, is that each day, indeed each hour, I have to choose to do these things, because the moment I let up my guard, my natural tendencies kick in. And they are ugly. And when it happens, I run the risk of being no longer the man of charm and professional skill, but a man of incidents. A loose cannon. And after a lot of internal checking, I am left with a mess of conclusions.

1) I have lacked the ability to demonstrate respect for authority. And it isn’t that I don’t recognize authority or appreciate how finances and business operations flow. It’s that my bosses are always wrong. Just kidding. It’s that as time has gone on my own experience in the industry has begun to match or exceed my bosses and so now I am forced to go along with the imposition of the business structure of the business that hired me on the basis of that structure alone. I can no longer earn stripes by gaining knowledge and experience in the field, I now have to earn stripes by brown-nosing. And this feels wrong to me. But it is the way it is, and that’s just life in the “real world”: if you want to work for a company as an employee (as per your signature on a Form W-4) and be its b---- then get in the kitchen, shut up, and make the man a sandwich. Do it now, grunt, or every second the man has to wait it’s another dollar taken out of your bonus! There is simply no ability to put soul into this. My desire to be motivated to succeed and to do well tends to be based upon the success of the business and upon the quality and world-changing impact of the business’s product. Instead, as the grunt, it becomes based upon the success of my boss, upon the quality and performance of my duties, and upon my compliance to allow the boss to dictate the measurements of “quality”, which if it’s right then it’s opportunity for me to learn, but if it’s completely wrong it’s the active practice of ritualistically worshipping Satan. And this is one area in which I tend to explode in disgust. Tact and self-control have gotten a lot better over the years, but it’s still an area for improvement.

1008337_607242282626833_1150274984_o2) My history precedes me. Life has been a long journey of learning about myself, about other people, about corporations, about all kinds of things, and in this journey I’ve suffered an awful lot of failures. Failures are success stories because you learn from them—well, that’s nice, except that my history precedes me. And at 36 years old—wait, I’m 36, right?—I’ve begun to get pessimistic. If a job didn’t work out over here, and another job didn’t work out over there, who really do I want to work for? I’ve learned that I do not want to work for someone I admire because rejection as the grunt hurts a lot. Does this mean I want to work for someone I dislike? Of course not. Well if I choose not to have an opinion about who I work for, I run the risk of lacking loyalty and, well, soul in my work, but at least I wouldn’t be disloyal either.

So I end up here. I’ve been here before. It has never gone well—on the other hand, I apparently end up back here anyway, and it’s actually a little more peaceful here. The only thing missing is soul. Soul is passion. Soul has made things miserable in the past, where applying it was in hopes of making things wonderful. So if soul has made things go bad, why? Is this an attitude problem, a skill problem, a focusing problem, an approach problem, a setting problem, or a target of interest problem? Discipline? Maybe I'm just imbalanced. Could it be all of these? Yes, I suppose it could. So perhaps I should drum up some new rules to consider on this, based on these things:

Attitude – Be passionate with a proper attitude among others. Does my passion make others feel kicked around or like they’re being told they’re inferior? Too selfish. I should find out if others have similar passions; if so, I should refocus my passion on enjoying their similar passions when I am with them. Also, I should always be appreciating the practices of the team that work, and not get too hung up on practices that don’t work, because the ones that don’t work always have someone’s ego associated with them and they were perhaps passionate about setting them up. They had a passion that I should appreciate even if the output didn’t match mine.

Goals – I need goals to have an objective I can target and pursue while harnessing the power of passion and skill. Goals should derive out of an attitude check, not the desire to make money or be a boss. Neither making more money nor being the boss reduces stress--in fact, it makes it worse. Living a simple life is remarkably mind-cleansing, and I can only imagine what kind of stress a top-tier leader must have to go through. On the other hand, if money is seen as a tool to do the world good, a means to make the world a better place, and likewise being a leader is seen as an opportunity to make the business owners or executives happier and doing that while accomodating the needs of the grunts is looked on as a welcome opportunity, these are not bad drivers for goals. Neither is passion a bad driver (unless my passion is in basket weaving). So setting up goals pertinent to technology skills growth is certainly ideal, especially in a field where technology is always evolving. As a Christian, I also have some eternal goals; as one who believes in God I desire to make whatever I do pleasing to Him. If I had a family and my interests were in making a wife happy, again, making more money is not a goal in itself but setting up a budget and adhering to it might be. I might like to marry someday; I should start practicing budgeting. I also want to have some residual income flowing in; I should set goals to write a book, or write software that I can sell. Figuring out which goals to prioritize so that goals that become projects can see the light of day is a lot of work but necessary.

Skill – A passionate web developer should always be learning, and should always be practicing by either looking for problems to solve or creating problems in a sandbox at home that can be solved safely there. If there’s not enough time to learn and to practice, perhaps there isn’t enough focus on the passion! I’ve also found that it’s easy to build up a surface-level understanding of development concepts or tools, but can be difficult to master them. Master them.

Focus – I’m guilty of not being able to focus. I tend to have A.D.D., but on the other hand I can get around this tendency by adjusting my environment (choosing or making a clean place) and restructuring my priorities and the sequence of approaching them. Some people have tried The Pomodoro Technique to deal with time management, and have had some great success.

Approach – It is not enough to tackle a passion. I need strategy. And my work needs to integrate cohesively with others’ passionate output. What happens when you get five musicians in a room and so they practice and play a solo—all at once? You end up with chaos. The whole notion of “you need strategy”, however, is too vague to demonstrate in words because every situation is completely unique to the problems and personalities involved. I just need to use my head—not just left-brain logic but also right-brain intuition.

Setting – Having a passion in Objective-C is great if you’re working at Apple or in an Apple-oriented shop. It’s not so great if you’re in a Java or .NET oriented shop. This example is too obvious, though. Being passionate about restaurant point-of-sale systems is borderline dangerous if I'mtrying to lose weight and the workplace is Dunkin’ Donuts. Passions + Setting should not conflict with Goals.

Creativity – Creativity is that necessary component that allows me to stop stomping around asking everyone "hey I need ideas so I can build upon my passions, help me?" I'm guilty of doing that and it's pretty lame. Creativity is itself a skill that needs to be developed. Passion and creativity build upon each other. If I'm not creative enough I should get more passionate. If I'm not passionate enough but have some seedlings of creativity sprouting up, I should keep building on that creativity, passionately.

Target of Interest – For years, I’ve had Ruby on Rails books sitting around, and have had Ruby installed, but I never made Ruby on Rails my passion. How likely is it that my whole world would be turned upside down if I dropped ASP.NET and focused that on Ruby on Rails? I think it would be pretty hairy. Rubyists would argue that I should, that it could only be better. But I am confident in the capacities of ASP.NET MVC, and so my target of interest in my passion is well chosen I believe. But what about other passions? Keep exploring. Find something that clicks. Or, fall in love again with what is proving already to work for me (i.e. ASP.NET MVC).

Discipline – I suppose one of my biggest problems has been that I tend to get A.D.D. when I read or when I do pretty much anything. At home I have 19+ personal projects lined up and the list is so overwhelming I end up hunkering down and playing PC games instead. To address this problem, I have had to prioritize my projects, and I printed this out and taped it to my computer monitor at home:   


I need to build up a greater curiosity and interest in the practices that I work with. Programming used to be fun. That and more should still be fun – it should be fulfilling. But regardless of how I feel, I should be driven by wisdom, and by the desire to be a greater, more proficient, and more respectable person in the field. 

Balance – Passion without balance makes people rich but it is more likely to make a person crazy. I don't mean to necessarily clock out at 5pm or 6pm. If I get back on my computer at home I've found no balance. I need to step away from the computer. Go to the gym. Go swimming. Go for a walk. Meet up with friends. Study the Bible and pray (yes I'm like that – or want to be). Go to a sports game. Actually I'm not into sports .. maybe I should go anyway, and bring a friend. Go spend a weekend up at the Grand Canyon. Stop playing PC games for free time. Have more responsibilities, outside of "personal projects". Take care of people. Become more well-rounded.

At the end of it all I should keep circling back around to all of these, giving special heed to attitude and balance. These are the elements that are making me a more whole person, while becoming a better, more mature person in the field of software and web development.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5


Career | Health and Wellness

Hiring The Inquisitive Mind

by Jon Davis 25. September 2008 18:40

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.

How Income Taxes On Salaries Really Work

by Jon Davis 14. October 2007 12:02

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) 
    • 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)
  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.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , , ,

Career | Taxes

Where Have All The Cowboys Gone?

by Jon Davis 5. October 2007 00:45

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.)

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5


Software Development | Career | Web Development

Don't Spread Yourself Too Thin

by Jon Davis 2. September 2007 20:32

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:

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.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5


Open Source | Computers and Internet | Operating Systems | Software Development | Career | Microsoft Windows


Powered by BlogEngine.NET
Theme by Mads Kristensen

About the author

Jon Davis (aka "stimpy77") has been a programmer, developer, and consultant for web and Windows software solutions professionally since 1997, with experience ranging from OS and hardware support to DHTML programming to IIS/ASP web apps to Java network programming to Visual Basic applications to C# desktop apps.
Software in all forms is also his sole hobby, whether playing PC games or tinkering with programming them. "I was playing Defender on the Commodore 64," he reminisces, "when I decided at the age of 12 or so that I want to be a computer programmer when I grow up."

Jon was previously employed as a senior .NET developer at a very well-known Internet services company whom you're more likely than not to have directly done business with. However, this blog and all of have no affiliation with, and are not representative of, his former employer in any way.

Contact Me 

Tag cloud


<<  May 2021  >>

View posts in large calendar