Brett Hutley's Blog » coding

Developers as Capital

brett — Tue, 06 Dec 2011 14:43:01 +0000

I've just been reading this Forbes article called "The Rise of Developeronomics". The author argues that because increasingly software is the core value proposition that differentiates companies from each other, that software developers are more and more becoming the wealth creators in society. The author recommends investing in software developers as a way of leveraging your own capital. This article builds on an earlier article by David Kirpatick called "Now Every Company is a Software Company".

The article is making the point that programmers are becoming a core economic factor for successful companies, so much so that large companies are buying smaller companies purely for their programming teams. He points out that companies such as Google nurture young programming talent as a strategic investment.

Of course the message is hugely appealing to me as a software developer. My own opinion is that technology is exponentially increasing the potential "value space" for possible investment. For example, consider the introduction of Facebook. With that particular advance in social networking, it opened up all sorts of opportunities for individuals and companies to promote themselves and establish new kinds of dialogues with their clients. With this advance, a large number of opportunities were created, which in turn leads to more specialised development that wasn't possible before the large-scale take up of social networking. Thereby creating a lot more potential work for a larger number of programmers.

If companies don't keep up with the introduction of new technologies, they run the risk of falling behind their competitors. Not only those competitors who are able to utilise technology to make their workers more productive, but also those competitors that make better use of social networks and internet search to gain new customers and retain older ones, and data modeling and analysis to determine new markets and optimise existing ones. It seems to me that not only are developers the creators of wealth, but we are currently living in a technological arms race.

Kanban

brett — Wed, 09 Nov 2011 13:08:53 +0000

I was browsing a list of tools and services for a lean startup a couple of days ago, when I noticed that many of tools implement a Kanban methodology. I had never heard of Kanban, so I took a quite trip over to Wikipedia.

"Kanban is a method for developing products with an emphasis on just-in-time delivery while not overloading the developers". Hmmmm, that sounds good. Upon further reading, I realised that this is the methodology that the introductary video at Trello was aimed towards. I have been playing around with Trello for a couple of weeks, but hadn't really got my head around how best to apply it.

My curiosity was piqued, so I went and bought one of the seminal books on applying Kanban to the agile software development process - Kanban, by David Anderson.

In the book, David talks about applying 5 principles to the software development process:

Visualize the workflow. This is the benefit that Trello brings to the process.
Limit Work in Progress. This means that work is "pulled" from another part of the workflow, when it is needed.
Manage Flow. The flow of work through the system needs to be quantitatively analysed.
Make Process Policies Explicit.
Improve Collaboratively.

It's definitely a methodology I'll be trying to apply to my own startups.

Written by Robot

brett — Fri, 04 Nov 2011 13:58:01 +0000

I've just read two blog posts on creating written content programatically. The first was the article How I automated my writing career by Robbie Allen. This article gives a brief description of how the author's company generates web-site content automatically using the quantitative analysis of data.

The second blog post is about generating a Monty Python parody using markov chains. Even though the code is very simple, it generates very convincing nonsense!

How long will it be before the prose in our stories, the plots on our TV series, the lyrics in our songs are all machine generated?

Not a programmer!

brett — Mon, 31 Oct 2011 13:42:57 +0000

I read the post "Don’t Call Yourself A Programmer, And Other Career Advice" on the weekend. It is mostly aimed at permanent employees at companies, although I thought there were some useful takeaways for contractors as well.

Below is my summary of the points that resonated with me:

Engineers are hired to create value for the company, not to write programs. There is big demand for jobs that add value to an organisation, but aren't that interesting. The programs are a means to an end - the end being doing something that reduces costs, or doing something that increases profits. So your only goals are to add revenue and/or reduce costs.
It's better to work for a Profit Centre rather than a Cost Centre.
Language isn't too important; A good programmer can pick up a new language fairly quickly. In my experience, if you work as a contractor you will mostly need to have at least 6 months of demonstrable experience at the particular language your client is using to get the job.
Networking is important, as most jobs are given to people as a result of networking, rather than a cold job application. A good agent will help to mitigate this.
Study negotiation! "It is a little disconcerting that negotiation skills are worth thousands of dollars per year for your entire career but engineers think that directed effort to study them is crazy when that could be applied to trivialities about a technology that briefly caught their fancy."
The most important professional skill is communication. This means being able to communicate effectively in memos, emails, conversations, meetings, and presentations.

Emacs and Ruby on Rails

brett — Tue, 17 Nov 2009 17:17:19 +0000

There is an Emacs mode for working with Ruby on Rails (of course). The main project page can be found here. In order to get everything set up, I had to do the following:

First download the latest release of the project and extract it into your emacs library directory. I install most of my extensions into a directory of my $HOME called "~/my/cfg/emacs". This creates a subdirectory called "emacs-rails".

I then added the following lines to the end of my .emacs file:

(setq load-path (cons
                            (expand-file-name "~/my/cfg/emacs/emacs-rails")
                            load-path))
(require 'rails)

The package depends on the emacs lisp files in the ruby distribution's "misc" directory. If you don't have them, grab a copy of the ruby tarball, extract, and install them in your emacs library directory.
The package also depends on a emacs function called "find-recursive", which I grabbed from here.

EDIT - OK, more useful to me at this stage is rhtml-mode which gives me syntax hi-lighting for rhtml files and can be downloaded here. Also apparently rinari is the successor to emacs-rails.

Testing when developing software

brett — Wed, 26 Aug 2009 10:25:44 +0000

Alecco Locco has summarized the SQLite presentation entitled A Lesson In Low-Defect Software at this URL: SQLite: A Lesson In Low-Defect Software. Now, I'm a big fan of SQLite, and this summary has pointed out a few things that I need to improve in my own development process - namely, more comments (apparently SQLite has a comment:code ratio of 2:1), and automated full coverage testing.