We are hiring at SafeNet consulting.  Specifically, I need a senior .NET person or three.  I can't think of anyone I know who's looking for a job right now so I'm going to throw this out to the public and see if anyone can help me out.

Why would you want to work at SafeNet?  Well, here is my take on it:

I worked for two other consulting companies before coming here.  Each one started out good but I ultimately became disgruntled. This is not an attack on anyone, just pointing out some of the things I don't like about traditional consulting models.

Salary: Its fairly complicated to come up with a fixed salary to fairly compensate a consultant.  Expected utilization, expected billrate, and various other value-add activities you perform have to be taken into account.  If you do convince your boss you are worth keeping on staff even if you are not profitable, chances are you're at the top of the list to be let go when things go downhill.

Sales & Extras: Consulting companies consider their staff to be a second sales force, and why not?  A consultant's relationship with clients and potential clients (places their friends work, etc) are usually of a different and very useful quality than a salesperson's relationships (Sales-Ninjas excluded).  Despite the fact that everyone admits how valuable this under the radar sales activity is, companies are loathe to offer compensation even when a sale is made that couldn't have been made without the consultant.  The most common answers are "That's part of your job" or "This benefits everyone/Grows the company so we're all doing better/etc".  Unless you have equity in the company beware the "Growing the firm" argument, and unless you live under a rock you probably know that you can make the same (or very close to it) salary at a non-consulting firm without the unpaid sales guy part of your job.

Non Competes and Freedom: This is the biggest one.  I'd rather not give too many examples but I had one manager go so far as to tell me they wouldn't let me write a book I was working on unless I let people at the company review it.  Doing small billable side work, large billable side work, creating products on the side, or making an HTML page for your friend at the barber shop can all be squashed by the non compete you signed when you took a job.  Wisconsin happens to be a Right-To-Work state which means most non competes would not stand up in court.  Chances are your employer can afford the legal battle better than you can though, so even if your agreement is ridiculous your bound by default.

Companies do not own you, so how is SafeNet supposedly better?

Salary: Let's get this out of the way.  You don't get paid when you're not working.  You get an hourly rate which is quite a bit higher than your effective salary would be at a normal firm, and you put some money in the piggy bank for the times when you're not working.  A good rule of thumb is to plan for around 2 months of downtime.  I'm confident I'll be working most of the time, and after doing the math I'll make a lot more here than most other places would be willing to pay me.  Obviously this puts part of the onus on you to "Be Placeable". 

Sales & Extras: SafeNet gives you a business development credit when you bring them work and leads.  This credit takes the form of a per-person, per-hour commission to you.  The same goes for referrals: if you get someone to come work @ SafeNet you get a per-hour bonus for as long as you both work there.  While these amounts do not quite measure up to what a full-time sales person or recruiter's commission would be, I am not a full time sales person or recruiter so it seems fair to me.  These conditions and dollar amounts are written into your employment contract, so its not a "wink-wink we'll give you a Best Buy gift certificate if you bring us a $750,000 project" type of deal.  To me this seems fair and reasonable for all parties involved.  Sure, there is a little risk, but I'd rather make more when I'm billing and make less when I'm not billing in exchange for some other freedoms...

Non Competes and Freedom: This is the best part.  If you are not billing for a month, you do not have to come into the office and work on some inane pet project of the management.  You can come into the office and maybe get paid for the inane project, or study, or sleep in and watch Soaps all day, or study for a certification or play Doom3.  This is a huge draw to me, since I have so many nerd side projects that I don't have time for.  I can't wait to be on the bench (sorta) so I can keep my daughter home from daycare and finally catch up on my DirectX projects and such.  Also, have you ever been put on a ludicrous project copying CSV files into a FoxPro database or upgrading Windows98 to Windows 2000 because that's the only billable work the firm could find you?  You're in the driver's seat: you don't have to do it if you don't want to.  SafeNet's non compete is very simple and very side-work friendly.  Unless you are doing side work for a big client they are trying to break into,  and your side work doesn't affect your 9-5 gig you're fine.

After reading all of this you may wonder "Why not just go independent?"  I thought the same thing, and who knows, I still may someday.  The single biggest benefit is that I don't really need to spend any time selling myself.  There is a full time sales staff pounding the pavement to place me and get a good rate for me.  SafeNet also manages benefits for me so I don't need to worry about the cost of singe-party health insurance, 401k administration fees or anything like that.  SafeNet has the formula about right: the $10-$20k per year more I could make being independent isn't worth the headaches and added risk of being my own sales guy.

So yeah, if you've got the skills,  send me your resume if you're interested in getting a big pay raise and having complete freedom over your career.

I believe that every good developer should be familiar with the idea of leaky abstractions, after all we live in a time when many of our computing concepts involve higher and higher levels of abstraction in our coding model.  I might go so far as to say that Joel characterizing this notion of Leaky Abstractions is a noteworthy contribution to the field of software development.  I like to know what's going on behind the scenes of any tool that I'm using, in case the abstraction breaks and I am forced to pull out my pipe wrench and fix some plumbing.  Perhaps this makes me a "Computer Science Elitist" or a Dinosaur who still has a "close to the metal" mindset in an age of abstraction.  I like to know what's under the hood.

XML Web Services in .NET is a big abstraction.  This abstraction tells me that I don't need to worry much about XML.  This abstraction tells me that if I put [WebMethod] on a method, it will handle the plumbing of SOAP endpoints and my clients can interact with this code via discoverable types and I don't need to worry about how things are serialized.  There are many cases where these great (and they are great) XML Web Services are leaky abstractions.  Some of the more well known ones involve DateTime parsing and Serialization and such.  I'll share a new one today to illustrate Leaky Abstractions.

I return Messages from my web services.  One of the types inside my message is an enumeration, defined like so:

    [Flags]
    public enum PullOption
    {
        None = 0,
        PullChangesOnly = 2,
        PushChanges = 4,
        EmptyTableAfterPush = 8,
        StoredProcedure = 16
    }

The system handles enums well enough.  Note also that I have used the [Flags] attribute.  Whenver I see [Flags] I have to do a double take to make sure I'm not writing code that is hard to read or maintain; often times, especially when dealing with the Win32 API, there are so many different options to deal with that [Flags] really is the best way to go about it.  This code works fine on the server.  Now, on my client, I notice that the results I get are not quite what I expected.  The whole abstraction of XML Web Services and WSDL.exe in .NET is broken, and I have to start looking under the hood.  My OperationDescription for this enum field looks something like:

<PullOption> None or PullChangesOnly or PushChanges or EmptyTableAfterPush or StoredProcedure</PullOption>

and the WSDL looks something like:

I got the new Mobile Developer Power Toys today and started messing around with them.  The new ActiveSync based remote display is working well, and I think some of the other tools (RAPI_Debug, RAPI_Shell, JShell) might just help me with some of my more bizarre mobile issues.  I'm glad to see Microsoft is releasing more debugging tools because quite frankly, ActiveSync is my sworn enemy at this point.  This is not good when you are primarily doing mobile development.  ActiveSync 4.0 is actually seems quite a bit better than previous versions but there are still quirks.  I should not notice any networking quirks if my device is going through ActiveSync.  Microsoft, are you listening?

OK, so, I have quite a few things on the burner right now as well as some items optionsScalper would call "Off the Block".  As Murphy's Law would have it, several "Critical Must-have improvements" came up in two of my side projects.  One of them is a mobile application I support.  I have come to think of ActiveSync as my sworn enemy.  Being such a critical component it should just work but as a casual parusal of the user groups will tell you, it does not.  I have an issue where trying to FTP 50 or more files from the device eventually "locks up" making any new FTP connections until Active Sync is stopped/started again.  I was hoping Active Sync 4.0 would solve the issue, but no such luck.  If I can get ShellExecute of repllog.exe to work I should be able to detect the error situation and bounce active sync to fix whatever ActiveSync proxy/network quirk this is.  If anyone knows all the possible command line args to repllog.exe on CE.NET it would save me some time.

 I finished this book on the plane coming back from Tech Ed.  The book is pretty well laid out and if you download the source code for all the samples to read as you go along everything makes a lot of sense.  If I had never even looked into game programming before and this was the first book I'd read, the book would be highly motivating; it leaves one with the feeling of "Holy crap, I could actually do this."

If you've never done game programming before, I'd suggest going through the motions of doing the 2D games before getting into all the Managed D3D stuff.  2D games have all the same elements: game loops, render loops, collision detection, etc and you need to learn all those things before moving on to more complicated vectors.  Reading this book also gave an introduction to DirectInput, DirectSound, and DirectPlay: the developer story for making a DirectX game is really fantastic. While there is always a performance hit for working within managed code, as Tom Miller points out Managed DirectX is a very thin wrapper and in terms of pure graphics performance the managed apps get very similar framerates to the unmanaged apps.

I'm going to re-work my current Tank simulation with DirectInput and some sound before moving back to my neural net.

Nothing super interesting to report from Friday: I saw a few of the obligatory ASP 2 demonstrations.  I don't know why I'm not tired of these yet.  Perhaps it is because I've done more web development than anything else in my career and its nice to see the developer story finally getting close to where I think it should be.

That wraps up TechEd for me.  All in all, I give it a B.  It accomplished my goal of getting me excited about work again, but a lot of the content was not as in-depth as I would have liked.  I think I'd like to try doing one conference a year.  Next year I think I might try the PDC.

Now that I'm back I have a to-do list a mile long, including catching up on all my side work and trying to make up as much of the 40 hours I missed last week as I can.

I was going to post about all the architecture talks I attended Thursday, and about how I feel we need to adopt more rigorous language when describing what an Architecture is and what the attributes of an Architecture are.

But, instead, I will save that for later and talk about the attendee party.

In the 90s I managed to miss all the craz JavaOne parties and such so TechEd was a big deal to me.  For the attendee party Microsoft rented Universal Studios exclusively for TechEd attendees and their guests.  The rides were running but the park was empty except for us.  Jen and I were able to go on every ride we cared about and some of them twice, with just 10 minute waits.  How cool is that?  I would definately say Universal Studios probably isn't worth the price of admission with the two hour lines, but without the lines it was really a great time.  Not only did we have the place to ourselves but there were stands placed every 50 feet or so with free beer, wine, and chewy pretzels.  Needless to say, we had a great time and didn't get home until late and I missed my Friday morning talk concerning management and the SOA enterprise.

 I saw several good talks yesterday but by far the most interesting was Jocham Seemann's talk about the Domain Specific Language tools they are working on for Visual Studio 2005. (Side note: he must not have grown up in the US, I did not see the battle scars he would certainly have acquired defending himself and his name) The idea behind the DSL tools is to provide a common set of Designer tools. Designers tend to have common elements such as shapes, decorations, and connectors. Consider an ER modeling tool vs. a UML class diagram tool: their basic notions are similar but the exact semantics differ. Using the DSL tools you define the semantics of your custom language. You detail what entities are in your domain space, what attributes they have, what types of connections they can have to what other entities, etc.

The DSL tools have a lot of built in support for code generation, using an ASP-like tag syntax, similar to CodeSmith as well.  The tools allow you to define validation rules and such as well, and handles persistence of your models for you.  Once your tool is done, you can click a button to build a visual studio add in so that other developers working within your problem space can use your Domain Specific Language.

My question is why stop there?  Why limit the use of this tool to visual studio users?  Suppose you work in a business with a fairly well defined domain, such as selling mutual funds for a specific company.  If you could define your domain entities, attributes, connections, rules, etc and then put this tool into the hands of people like, oh, say, business analysts you may have a very powerful code-generation and/or documentation tool that is usable by the people who supposedly know the business best.  I have built some custom designers in .NET 1.1 and its not exactly easy, a "Generic DSL" tool would be an interesting challenge and potentially a very useful product to a business as well.  I'll have to dig up the DSL team's URL out of my notes and download the DSL plugin for Visual Studio 2005.

 

In other news: Microsoft released a June 2005 update for the Managed DirectX SDK.  The first time I downloaded it a resource bundle seemed to be missing and it didn't work.

Saw some excellent sessions at TechEd on Tuesday.  The first was by a blogger I've been reading for a while, Scott Hanselman.  Scott has a lot of interesting and humerous observations on his site, including such gems as "Can we use WS-Powerpoint for this" and various Zen mantras related to .NET coding.  Then quotes in his powerpoint reminded me of something I've been into for a long time, which is writing Haiku about topics such as coding and everyday life. For example

Asynchronous call
Such an efficient method
Of getting work done

I should really poste more .NET related Haiku, as I'm sure its something that would benefit the community immensly.  Back to Scott's talk: the topic was about code generation.  I've been getting more interested in this ever since a local client disallowed me to use a CG tool to generate Types from a datastore.  I'm like a small child that way, making it forbidden makes me want to do it more.  Scott showed a lot of interesting code generation best practices and ideas including:

• Generating Big word docs as part of your build process
• Generating unit tests and CHM files along with your code
• naming conventions to indicate what files are generated
• Using XSD and WSDL for creating your Domain Specific Languages
• How to make your own XSD files available to VS 2003 so you have intellisense support

And a lot more.  The most interesting part is that Scott did all this in VS 2003, no built in DSL support or partial classes.  I became interested enough in this to switch one of my sessions on Wednesday to a talk on the DSL support in VS 2005.

My favorite talk of the day had to be one concerning adding voice support to mobile devices using Speech Server.  This is something casey has been using for a while and had good success with.  It still amazes me sometimes how Microsoft can take some incredibly complex problem spaces and make them accessible to almost anyone.  The speech server model is a web-application model, and adding SALT-like support to your pages is incredibly straight forward.

There is simply too much to learn.