If, like me, you are working on frameworks but are not completely up to speed on MSBuild you may have tried to use xcopy in a Post-build event to copy your binaries to a distribution folder. As an old Unix guy I have to scratch my head at “xcopy has exited with code…” errors. Use Powershell instead for behavior that makes sense:

Powershell.exe  -command "cp $(TargetPath) $(SolutionDir)\Output"
Powershell.exe  -command "cp $(TargetDir)$(TargetName).pdb $(SolutionDir)\Output"
Powershell.exe  -command "cp $(TargetDir)$(TargetName).xml $(SolutionDir)\Output"

Powershell works better than vanilla MS DOS commands for your build needs.

I lit up my Twitter stream in frustration today when I sat down to create a playlist on my Nokia Lumia 920. Zune software, which is still my #1 choice for music playing, is out of the picture for WP8. The “music” app can create playlists but seems unassociated with the phone. The Windows Phone WinRT app cannot create or edit playlists. The steps I found online to create a playlist on the phone are annoying and error prone.

Once you’ve created a playlist on the phone there is no way to add/remove/change the order of songs. Wow. I was poking around to see if there was a way to do this in code and came up empty handed. I also hoped that perhaps the playlist format was something I could parse and build an editor for. I found the following by exploring the phone:

Looks promising, but I’m unable to open these files using code or any application, including Sysinernals.

All I wanted was to more easily build an energized playlist for my Wednesday night workout. I’ll leave the profanity to my twitter stream and just say that the shipped playlist experience on Windows Phone 8 is DoublePlusUngood. The only relief I’ve been able to get so far is that the “Reference” tab does in fact let you remove & reorder songs on a playlist on the phone:

I’ve only tested this on Windows 8 so far. Not great, but I hope this helps someone out.

I am honored to announce that I've been accepted to deliver a talk at That Conference this summer. I was unable to attend the first ever That Conference due to a scheduling conflict last year, making me double happy to be able to attend this August. Full details on my session can be found here. I hope to see many familiar faces there as well as connect with those of you I've only known virtually up to now.

Getting Started With Machine Learning

 Data mining, Big Data, predictive analytics, machine learning. Developers hear these buzzwords constantly but may not have a firm grasp of exactly what is involved in this exciting area of computer science. In this talk we'll explore some fun and easy to understand yet practical examples of both supervised and unsupervised machine learning. Example code will be in C# and we will focus on logic and algorithms over hardcore math.  Come and learn how to make your software better just by feeding it more data!

 Level: 200 - Category: Other

While my Taekwondo and Hapkido training are getting me close to my pre-children level of fitness, I have been avoiding running. TKD is hard on my shins and the sciatic nerve has been acting up again lately. Here's to hoping the chiropractor can work some magic because I'm entering my first race since the 2003 Al's Run:

 

http://www.wisconsinzombiemudrun.com/

 If you're interested in running with me or heckling, I'll be running at 11:30am.

I’ve been reading Alex St. John’s blog for a while, and it’s just amazing. His stories of ancient Microsoft history, his tracing popular video game features to fundamental human behavior shaped by evolution, his insistence on the importance of hard work and commentary American Privilege. A couple of his articles lately, though, have kicked me right in the throat. If you have any entrepreneurial aspirations, I highly recommend:

Educated Idiots

Café Easy

I might also throw in this less recent one from Hanselman:

I’m a Phony. Are you?

Over Sharing Inbound

I sometimes feel like these articles were written directly to me, probably because I’ve internalized a lot of guilt. Guilt about not taking action on my ideas. After all, since software is eating the world it doesn’t seemed too far fetched that every competent software developer is sitting on a gold mine. The only thing between me and amazing success is the will to make it so. Yet, I have no idea what I did with my 20s (professionally) and despite often thinking about and working on business ideas, I’m still a wantrepreneur in my late 30s. The Saint’s comments on work-life balance are what really got to me. My week night schedule might be something like:

•    Get up at a questionably late hour, go to my good-paying job.
•    Come home, make an unnecessarily elaborate dinner.
•    Hang out with kids, clean up, etc.
•    Hang out with wife
•    Devote a few pre-bedtime brain cycles to open source projects, blogging, continuous learning, and modeling stuff for one of my business ideas.

Unsurprisingly, I can think of no successful business owners who share my story. Have you ever read an interview with a truly successful individual that sounded anything like “Yeah, we worked 10 hours a week or so on this, no big deal, until it was done and we hit it big.”

I’m doing better than I ever have before in my life, yet it’s still not enough. One of the reasons why I haven’t been participating in community as much is because I’ve been writing huge amounts of code. It’s not enough, it’s not getting done fast enough for my taste. There needs to be more hard work. Some people may find themselves in an existential dilemma trying to figure out what to cut out so there’s time for more productive work. In my case, this has been an evil exercise. I shouldn’t spend less time with my kids! Surely not less time with my wife! I need my sleep and exercise. I need my movies and video games to decompress from the “hard work” and “stress” of my day job. Yet I shed a tear when I think about how much time I played Diablo 3 last year. (Not really, but I should be ashamed!).

This is where The Saint’s words hit home. If you’re content with the overall trajectory of your life and career, there would be nothing wrong with seeking balance between work/sleep/games/movies/wife&children/hobbies.  If you’re not, though, you need to think really hard about how much down time and “balance” you actually need. If you’ve always wanted to be a blogger with a million followers or a successful Micro ISV writing phone apps, or to become an independent consultant,  what value will you place on ‘balance” when you look back and realize you are no closer to those goals than you were years ago?

Golden Hours

The real problem in insisting that a few days of productivity entitles one to some marathon gaming sessions or re-watching all of Battle Star Galactica is the value of the particular hours when most of us are doing our side work or learning projects. I call these the Golden Hours.

Many of us, in our day jobs, are not afforded much focus. We may be committing code on multiple projects, reviewing our peer’s code, and generally participating in various unfortunate unproductive activities. No so during the Golden Hours.

My home workstation setupis slightly better than what my employer gives me. There’s a door I can close and I can play music through my excellent Klipsch PC speakers. The house is quiet, my family is asleep, there’s some red wine on my desk, and the time of night where my mind is most awake and focus approaches. What to do with this time?

If you have the numbers available, take a look at your favorite PC games (or Xbox or PS3) and see how many hours you spent playing your favorite games. Suppose that number was 400 hours last year. (oh, if only it were a mere 400 hours last year) At your day job that 400 hours may represent a fiscal quarter worth of office hours and you may have built a major module or accomplished a similar cog-in-the-machine type of contribution. But now, you’re at home. You’re using only the tools you love, only the libraries and frameworks you love. No architect has told you what you can’t do and how you can’t do it, no scrum master has told you Boring Crud Screen must take priority over Interesting Problem from a later sprint. The Golden Hours where you are awake and in your most productive environment approach. Now what could you do in 400 hours?

This, for me, is the true tragedy of seeking balance with hobbies, entrepreneurial dreams, and the stuff that actually must get done. Many of us have ambitions and skills, but proceed to spend the most productive time we have available surfing hacker news, watching zombie movies, online gaming, engaging in meaningless debates on twitter, or re-connecting with people we hated in high school on Facebook.

You may in fact reach a point where your brain is Jell-O and you truly need some downtime in order to return to productivity. Most of us probably indulge ourselves way, way too early though. I suspect that, like training your body with a “couch to 5k” program, you can train your mind to expect a life of more and more productive work and less and less Archer or Game of Thrones.

It’s easy for a programmer to do incredibly well in America today. If you want more, though, If you want to be really disgustingly successful, you must evaluate every activity through a simple heuristic: is this simply indulging my entitlement to wealth and leisure, or is this moving a possible revenue stream forward?

Related Articles:
A Different Kind of Entity Framework
Entities Live in Repositories (this article)

Regardless of where your data comes from, or winds up, it's good to have an abstraction around that storage mechanism. While it's unlikely your business is going to throw away it's investment in <<Big Enterprise DB>> any time soon, it's certainly a boon to testability. Much the of the modern development community has decided that the appropriate abstraction is the Repository.
An Entity that can be saved & retrieved by itself (without being part of some bigger object graph) should be fetched & stored using a repository.

For learned DDD people, we will revisit the concept of Aggregate Root another time.

I've seen a lot of simple repository definitions over time, and mine is particularly .NET and LINQ friendly. The only thing you may question is the separation of the Read and Write methods into different interfaces.  While I'm not necessarily dreaming of CQRS, it's wise to separate the read and write channels to avoid Liskov Substitution errors: many entities may not support write operations because they are read-only in your application. You could make the same arguments for Create and Delete, but I find read vs. write is a good place to start.

The Repository:

    /// <summary>
    /// A read-only store for retrieving IEntities
    /// </summary>
    public interface IRepository
    {
        /// <summary>
        /// Current work context
        /// </summary>
        IUnitOfWork UnitOfWork { get; set; }
    }

Repository of T

    /// <summary>
    /// Typed read-only operations for retrieving IEntities with a known Id type
    /// </summary>
    /// <typeparam name="TEntity"></typeparam>
    /// <typeparam name="TId"></typeparam>
    public interface IRepository<TEntity, TId> : IRepository where TEntity : IEntity<TId>
    {
        /// <summary>
        /// Load & return all
        /// </summary>
        /// <returns></returns>
        IEnumerable<TEntity> Get();

        /// <summary>
        /// Load 1 by Id, or default(TEntity) if none found
        /// </summary>
        /// <param name="id"></param>
        /// <returns></returns>
        TEntity Get(TId id);

        /// <summary>
        /// Return all TEntity matching the predicate May require an aggressive load.
        /// </summary>
        /// <param name="predicate"></param>
        /// <returns></returns>
        IEnumerable<TEntity> Get(Func<TEntity, bool> predicate);
    }

Write repository of T

    /// <summary>
    /// Mutate operations for IEntity&lt;TId&gt;
    /// </summary>
    /// <typeparam name="TEntity"></typeparam>
    /// <typeparam name="TId"></typeparam>
    public interface IWriteRepository<TEntity, TId> : IRepository where TEntity : IEntity<TId>
    {
        /// <summary>
        /// Create a new TEntity with an auto assigned id, or default(TId)
        /// </summary>
        /// <returns></returns>
        TEntity Create();

        /// <summary>
        /// Create a new TEntity with a given Id
        /// </summary>
        /// <param name="id"></param>
        /// <returns></returns>
        TEntity Create(TId id);

        /// <summary>
        /// Persist these targets
        /// </summary>
        /// <param name="targets"></param>
        void Save(IEnumerable<TEntity> targets);

        /// <summary>
        /// Persist this target
        /// </summary>
        /// <param name="target"></param>
        void Save(TEntity target);

        /// <summary>
        /// Remove these targets from persisted store
        /// </summary>
        /// <param name="targets"></param>
        void Delete(IEnumerable<TEntity> targets);

        /// <summary>
        /// Remove a single target from persisted store
        /// </summary>
        /// <param name="targets"></param>
        void Delete(TEntity targets);
    }

Wait, what's that IUnitOfWork in there? We'll have to save that for another day. This article, like the Entities article, was fairly short and
just establishes a simple baseline. In the next article we'll start to tackle the real substance of what this Shinto stuff is about. You can review these interfaces at https://github.com/damonrpayne/Shinto/tree/master/HandWaver.Shinto/Shinto.RepositoryModel

I have always considered stock options to be Monopoly Money. I came of age in the 80s and 90s and grew up watching the creation of Microsoft Millionairs and .Com millionairs but I never put much stock (pardon the pun) in this as a source of wealth. It's easy to look at successful companies like Microsoft whose stock split so many times and think of stock options as a path to wealth for the average worker bee.

I've spent my career up to this point in the midwest, and I saw some of my friends working heroic hours to make something happen for their company. Their motivation was going public and (at least) paying off their homes with stock sale proceeds. For a long time part of my fear of stock options was due to a bit of small-minded thinking: I couldn't envision any of these small Wisconsin companies making it big, and therefore viewed these stock options as essentially motivating a lot of free effort for the company by promising the moon to employees eager to cash out on a big deal.

My main issue, though, is that I find employees are generally woefully under-educated about exactly what kind of stock they are given and what they can do with their stock options. This Ars Technica article is just the latest in a long stream of examples. Stock Options, and Common Stock in general, often exist at the pleasure of the company. This is not to say that in-writing agreements are discarded at will when it's convienient, but rather that employees are not usually presented with the whole picture. You will happily sign something saying "We are granting you XXXX shares of Common Stock" without knowing there may be so much preferred stock that the likelihood of you getting any money out of a company sale is incredibly small. As Dell employees are now finding out, the bylaws of any company may also allow so many restrictions to be placed on stock options that only the narrowest sequences of events could even lead to an employee exercising & selling in a moderately profitable fashion.

As an aside: this also brings to light one of my personal biases. I'm extremely old-fashioned in that I greatly prefer stocks that regularly pay dividends out of profit. I find this a much more sound concept than the current practice of what essentially amounts to speculation on stock price. So many non-market forces (rumors, etc) can affect the market valuation of publicly-traded companies.

As the article about Dell points out, the higher you are on the food chain the more likely you are to do well with company stock. Call me cynical, but it's hard to look at this situation and call it anything but the top-decision makers fixing the game in their favor. Enron-style practices that allow executives to sell stock while employees are in a blackout period are common. Preferred stock agreements that gaurantee minimum share prices for executives even to the point of employees earning nothing from a sale are common.  The rules are complex and often hidden in secret company charters or in SEC filings that only employees with extremely deep financial knowledge can decipher. While the premise of encouraging the best employee actions by giving them a piece of the pie is a sound one, it's sometimes hard to look at these stories as anything but a case of fraud.

 

Related Articles:

A Different Kind of Entity Framework (this article)

Entities Live in Repositories

 

Before I can get into some of the Machine Learning and Event Sourcing topics I want to discuss I need to establish an Entity Model.

This is not an ORM. While those certainly have their place, and features like code-first in modern frameworks are expanding the number of places where they are appropriate, there are still many places I prefer to use something a little more rustic: hand-coded SQL for example.

If you haven’t read it already, I highly recommend the DDD bible:

There are a lot of reasons why you might choose to use or not use an ORM, for me performance is often a huge concern. You may simply need features not offered my your ORM of choice: specific kinds of change tracking, serialization, UI bindability, inability to use the base classes required by an ORM, specific cache strategy needs, or for other reasons.

Starting with Simple Entities

We’ll start by defining a simple interface and implementation of an Entity. An Entity is an object (representing data) whose lifetime is defined by some kind of Key or Id. Keys will often be a primitive or struct.

    /// <summary>
    /// An Entity has a key(Id) representing its identity. Implementors should consider overriding Equals and GetHashCode
    /// in terms of this key
    /// </summary>
    public interface IEntity
    {
        /// <summary>
        /// Return the Id
        /// </summary>
        /// <returns></returns>
        object GetId();

        /// <summary>
        /// Set the id
        /// </summary>
        /// <param name="value">New Id value</param>
        void SetId(object value);
    }

Since we’re programming in C#, it would be a crime not to provide a generic version:

    /// <summary>
    /// An Entity with a typed key
    /// </summary>
    /// <typeparam name="TId">The id type, often a value type</typeparam>
    public interface IEntity<TId> : IEntity
    {
        /// <summary>
        /// The Entity Id of the given instance. Should be implemented in terms of Get/SetKey()
        /// </summary>
        TId Id { get; set; }
    }

Next Steps

You would be forgiven for thinking this article was not very inspiring. If you’d like the current code, such as it is, check it out on GitHub:

https://github.com/damonrpayne/Shinto/tree/master/HandWaver.Shinto

Over the course of the following articles, I will lay out useful features that resurrect some of my more popular Silverlight articles.

Software developers, more specifically talented software develoeprs, are unicorns according to a recent venture beat article. ⁽⁰⁾

 I am fond of quoting the "Software is eating the world" article. Salaries, benefits, environments, and creative signing bonuses are constantly in flux as the startup communities of Boston, New York, Silicon Valley, and Seattle compete with each other and with more established companies for software development talent. Scopely went so far as to offer $11,000 wrapped in bacon as part of an over the top signing bonus/publicity stunt as they sought out the Most Interesting Engineers in the World.

I think, indeed, it would be hard to overstate the need for skilled software engineers these days. Given this urgent need it's surprising that a huge, energetic, hard-working and incredibly skilled pool of software developers is being ignored by these talent-hungry organizations. I am speaking of course about all the software developers who do not live in one of these recognized technology meccas. To be sure, startups along with established technology giants like Amazon or Microsoft are always willing to interview qualified developers from a flyover state. It is nearly always a requirement, however, that one relocate to one of the coasts. No matter what developers, housing, or Bacon costs in Seattle, you can not work remote.

It's the Collaboration, Silly!

The inability to work remotely for the most talent-starved companies has long perplexed me. I asked a friend who works at a very successful Silicon Valley startup if she could provide more perspective on this topic. She look at me, and, apparently unaware she was stating something so obvious it bordered on cosmic absurdity, she stated "Well, it's just so much easier to work together when people are co-located."

Of course it's easier. The Currents of Information that flow around the office, the impromptu water cooler conversations that lead to a breakthrough, the ability to pull the right few people into a room to whiteboard a difficult problem: these can all be marvels of productivity and problem solving. Not only is this an obvious boon to driving business value, but software developers like it! Gone are the days of the software geek in a dark room littered with pizza boxes and empty cases of Mountain Dew, we like interaction with other skilled developers and (gasp!) business stakeholders too. Yes, it's clearly better to be under the same roof, but we're talking about escalating salaries⁽¹⁾, offices that look like entertainment complexes, and bacon-wrapped cash.

How many trips from Kasas City to Seattle could $11,000 plus the cost of bacon⁽²⁾ finance for a talented software developer? What is the conversion ratio between attractive relocation packages versus plane tickets, hotels, and food? Given ever improving technology and bandwidth, can US companies figure out how to collaborate across the country? The world? There are certainly precedents. Skype, for example, allows its engineers to live whereever they want and often features customer success stories on its blog. Vertigo has remote people in several states. My friend Steven Murawski lives in Wisconsin and just started work for Stack Exchange. These high profile companies are the exception that makes the rule look extremely odd. 

Cultural Bias?

While I can't precisely put my finger on it, there are also some Vibes of Bias I've sensed when talking to people in other areas of the country.

According to my friends in California, there appears to be no sane reason why you'd want to live in a fly over state. You must clearly value fishing and binge-drinking over technology to live in a cultural wasteland like Wisconsin, Ohio, Missouri, Indiana, or Montana. You must appreciate less than optimal weather to opt for tolerating a cold Minnesota winter every year instead of the superior climated of Sacramento. If you took technology seriously, or if it was more to you than just a way to fund your deer hunting habit, you'd move.

The fact is, there are literally millions of people living in the fly over states, many of them brilliant software developers. Some of these people may have gotten married to people with less yearning for a fast-paced lifestyle on the coast. Some of these people may have close family ties to the area, kids in school, or are anchored to a bad real estate situation. I even know people who have commited the ultimate act of apostasy: left the West Coast to return to the Midwest.

Shortage?

For whatever unfortunate and misguided reasons an enormous percentage of the American population cannot, or choose not, to relocate to a hot technology area on the East or West coast. Yet both attention and Venture Capital flow so much easier to these areas than to a fly-over state. Is there a shortage of Talented Software Developers, or is there a a shortage of Talented Software Developers who had the foresight to establish no roots in a flyover state?

There is a huge opportunity here for the businesses who make this work.

Footnotes:

⁽⁰⁾ I'm a fan of Pluralsight and not picking on them. That writeup did inspire me to write this article though.

⁽¹⁾ Salaries really only seem to be escalating in certain areas of the country, which I will address in a future article.

⁽²⁾ Obviously over time the travel costs could start to outweigh a signing bonus. Regional salary differentials due to lower cost of living in non-coastal states likely provide enough room to negotiate a better salary for the employee and cover regular travel costs.

 

The difficulties of finding, hiring, and retaining great software developers does not end with filtering out the non programming programmers during your interview process. Any career minded individual must also be constantly thinking about the future. Am I learning enough here? Am I being recognized for what I'm contributing? Is this organization actually incenting the kind of behavior it claims to value? Do I need to try to get a different title that represents my contributions in order to sell myself to my next employer?

Does your organization have a universal and transparent system for evaluating title changes? Is it clear to you what you'd need to do in order to Level Up ? Unfortunately, it's likely not the case where you work. In fact, many people may find themselves with titles (and therefore salary ranges, recognition, and opportunities) that are unhinged from their contribution relative to other employees. Why is that slacker over there a Senior Software Engineer III while I languish as a mere Entry Level Software Grunt II. Your may not have titles, as many titles, or such boring titles, but keep reading.

My wife is a Registered Nurse. The hospital system where she works uses the odd title of 'Staging' as a rough descriptor of skill and therefore salary bands. A nurse can be from Stage 1 through Stage 5. Leveling up is done through the process appropriately called "Staging". The organization has guidelines around staging. When you are a student nurse in training you should be a Stage 1. A nurse who's recently graduated and passed the state Boards (examinations) should be a Stage 1 or 2. Once you have some work experience you will be invited to Stage again, and after a year you ought to be about a Stage 3.

The requirements for successfully Staging at each level are published and transparent. While there is some subjective evaluation: talking to people who have observed your work, etc. there are also various objective requirements, written work, and an oral interview with a small panel that evaluates your fitness for whatever Staging level you are seeking. If you successfully Stage Up, you get a merit increase outside the annual cycle and are more or less considered more of a Senior nurse (in terms of ability, not age) than people of a lesser Staging level.

This carries appeal for a lot of reasons. For one, the process seeks to be evidence based rather than purely due to putting in your time, hanging out with the right people, or job hopping to get a new title. The fact that Staging to a new level requires a significant amount of effort on the part of the nurse also resonates with me: I'm not going to promote you just because it was time. Rather than wondering how your co-worker got to Stage 4, it should be very clear to you what you'd need to do in order to get to Stage 4. If you want to.

I'm not sure what the hospital would do if a nurse tried to stage three times in the same year, but presumably a failure would be accompanied by strong evidence of what was lacking.

In software development, one sought-after title by some is "Software Architect"; to some this is distinct from and superior to being a mere Developer. I happen to agree quite a bit with Joe Duffy on the role of the Software Architect, but in my own way I try to also provide an objective path to anyone who approaches me and says "I'd like to become more of an Architect..." There are things I think you should understand. There are seminal works I think you probably ought to have read. Ultimately, though, in our field, you become a Software Architect by hanging a sign outside your door that says "Damon Payne: Software Architect". (You may want to consider replacing my name with yours) You may succeed, you may fail, but if you're paying attention and you're open to thinking about why you've failed you will learn a lot. You'll keep those things in mind and ask better questions next time. One day you'll leave work and think to yourself "Hey, I really am a Software Architect".  Does "fake it till you make it" work sometimes?

In our world of fakers, pretenders, non-programming programmers, and job-hopping, could we promote software developers more like nurses?