Rationale for name change.

This blog is inspired by the article 'The Ghost Who Codes':

http://www.troyhunt.com/2013/02/the-ghost-who-codes-how-anonymity-is.html

I realized that I am probably one of his 'ghosts who codes'. However, while there are many reasons why such a categorization is unfair to those like myself (and I will indulge myself to present a quick counter-argument here), I also realize that the best way to deal with the situation is just to go along with the crowd, and that's what this blog is for. I believe the intentions of the author's piece are to help those like myself, and I would be remiss to not take it as a kick on the pants! ;)

Firstly, however, I want to make a quick counter-argument. Off the top of my head, I can think of several reasons why someone (such as myself) may be 'A Ghost Who Codes'.

1) Different kind of coder from a different era:

There are many reasons why a developer may seem like one of the 'ghosts' from the article. Firstly, it should not have escaped anyone's attention that it's a different generation of coders who are making up the majority of the community noise.

I became a software engineer when it was still mostly termed 'computer programmer' and the next career steps where 'analyst-programmer' then 'systems analyst' at the top. This was before the dot-com era, where computing was taught in the school of maths, before the internet really existed (we used to run SLiP in terminal sessions with modems to access Gopher and Newsgroups and large commercial providers has 10-20 concurrent connections to the internet available for customers).

Needless to say, before the dot-com era, it wasn't cool to be a software engineer, it wasn't known for attracting high salaries, and it certainly didn't attract the sort of person that thrives today who has strength in various forms of social networking and blogging about their achievements. And although this may seem harsh, a lot of us retreated in general from the first era of online Q&A forums such as MSDN and Javalobby v1, became grounds for endless flame-wars from developers with more energy to share their opinions than to consider them carefully ;)

My peers and friends from the companies I have worked at mostly share this trait, being possessed of a high level of technical ability rather than social. That's not to say that they don't communicate effectively however, on the contrary, communicating solutions technically to business users via high quality formal business communications is usually something that our generation does very well, but it's not the same sort of skill as you need to create an engaging blog.

2) Hostile corporate environment:

Despite the idea that good developers contribute to open source in their free time, I've yet to see it any significant contributions made like that. While developers may *say* they are doing it in their free time, those that do so usually do it with the sanction of their employer.

Unfortunately, not all employers are ideal in that regard. Many are frightened of the legal issues around open source, such as financial institutions, and many are hostile to the idea that an employee is spending his time on matters not directly related to solving the task at hand and moving on to the next one.

In some cases, such as in the UK, the existence of a full time employment contract gives your employer more rights than would seem obvious, including certain rights to work you would do in your free time if it can be seen as even tangentially related to your day job. It is for this reason that 'moonlighting' is seen as problematic for employers in the UK. In such an environment, it is rational to be as discrete as possible about any open-source or commercial side efforts, if not to avoid being involved altogether.

3) commercial side projects instead of open source ones:

Sometimes a persons side projects are also commercial. Whether that is freelancing in your free time, working on a start-up, or making apps for mobile platforms. Obviously, blogging about these is often not possible.


***

As I mentioned previously, it's usually easier to go along with the flow than to fight it, especially when the flow is in the right direction in the first place. In my case the only practical option, as I am bound by commercial constraints, is to try to do the following in this blog.

1) I will be going over many of my smaller projects that can be shared, particularly collections of utils, and extracting them into a libraries that I can share. The first of these is the one I have named 'toolkit' and is up on github.

2) I will be discussing in general terms many of the other projects I am or have worked on, although I will not be able to share code from these projects, I will try to illustrate a concept with a code snippet where possible. You will have to forgive me for not being able to offer more.

However, because all of this is literally in my hour of free time a day (I am a father of two young children, one of whom is on the spectrum) you will have to forgive me for being terse and to the point when I post.

Originally, I set up two blogs, shortly before becoming a father (and not realising what that would entail!) One for blogging my personal and generally ranty opinions ('And Other Curious Things'), and the second for a project of explaining what I thought was the prevailing ail in software development which was a lack of understanding about how to do good software *design*. That blog ('The Art of Heresy')was not going to steer away from controversy. However, that idea turned out to be rather ambitious considering my new status as a family-man. I still intend to do the blog about design, but for now I will be adding this blog ('The Ghost Who Codes') to go through my existing code and explain briefly my design choices, and this will take the majority of my energy for the time being.