One of the most satisfying parts of my roles has been creating technical delivery teams; these are the engine room of a tech business. You often hear about a “10x” increase in productivity between an average developer and a “rock star” developer, but for me that pales into comparison compared to the differences created by the interactions between members of a team and the environment they work in.

This is the first of a multi-part series of posts on building a delivery team and will also include hiring, team composition, tools and processes.

Caveats

There are plenty of businesses where technology isn’t important, where software is used, perhaps with a bit of customisation, or a business that has a website solely for marketing. Those businesses can probably ignore most of this; these articles are addressed at businesses who at their core require the creation and maintenance of software assets.

These articles are also focused on the early start-up phase of these types of organisations, where typically a single product is being built by a delivery team of less than 20. There are changes that need to be made on the way to this size, but as it grows beyond 20, and significantly more people on the business side this model will start to fall down and additional orchestration and communications channels will be needed.

Our industry

There’s a tendency within the industry to polarise; to pick a technology that one likes and propose it as the panacea solution to everything, with every other technology being rubbish. I believe a lot of this is due to a fear of the unknown, and wanting to increase the value of ones current skillsets, a classic case of “if all you have is a hammer, everything looks like a nail”.

An often misunderstood debate is open source v proprietary; a lot of people believe that open source has become prevalent because it doesn’t cost any money, when proprietary software from the likes of Microsoft requires you to purchase licences.

Whilst this may be true for businesses at the seed stage, for a technology business where the operation of technology is the business it’s often deemed too risky to run this technology without professional support, and normally this professional support costs as much as a software licence.

The prevalence of open source is more down to the ability to participate in the community; to contribute to a products direction, fork it, patch it, help test it, etc; this is great if people are going to contribute, but most of the time that’s simply not the case – most people are consumers of, rather than contributors to open source projects.

I often see businesses make a call on technology stacks because they’re “open source and free”, with little intention of contributing to the projects and not understanding the professional support that will be needed as they grow. This feels wrong to me.

Choosing a stack

This article is going to be focused on the building of a modern web application; that is a series of backend services providing an API, which is consumed by a front end application and mobile apps.

When thinking about which technologies to use there are a number of facets to consider:

• Initial cost of tools / IDE : Whilst a lot of developers will use only a text editor, many still prefer facilities like code completion, intellisense, integrated debugging and refactoring that an IDE can provide. I’ve based this on the most popular tools I’ve seen and read about people using, that’s not to say there aren’t alternatives that are cheaper or more expensive for each case.

• Ongoing cost of tools : This weighs heavily against the Microsoft crowd, who whilst they have great tools that are free for the first few years on Bizspark, they have per-seat developer licensing when you leave that program.

• Availability of developers : How many developers are available in the area I’m hiring in; this is a combination of the skills prevalence on Linkedin and my personal experience.

• Cost of junior developers / Cost of mid range developers : what are the market rates for developers in the area I’m hiring

• Availability of important functions / frameworks : I’ve seen startups create needing to create database drivers to connect their chosen stack to their database of choice; this contributes little to a startup providing their product / model, so should be avoided.

• Likelihood to be popular in 3 years : Is it going to be kept up to date with modern tools and processes. Are you still going to be able to find developers? Will people still want to work with it?

• Language / Framework learning time : Most professional developers have a good knowledge of OO & procedural code, like C# or Java, switching between these and other similar languages is relatively straightforward. Switching to a functional programming paradigm in Scala is more difficult.

• Cool factor : good developers want to work with cool modern tech.

• Language maintainability : the verbosity of the code you write, the amount of boiler plate code you need to implement and type safety affect the maintainability of the codebase that is produced.

• Suitability for concurrent systems : multi-threading, shared, mutable state and traditional process models are one of the major contributors to running stable highly concurrent applications. Immutability and the actor model can remove the need for locking, keep your application consistent and help it handle exceptional circumstances that would otherwise grind the whole application to a halt.

• Existing large reference sites : Are there good examples of large organisations using it for core / critical functions, and contributing to the eco-system.

• Production / Hosting options : The hosting options for most of the major frameworks have started to converge on IaaS, PaaS or shared / self hosting. For newer technologies the deployment and PaaS offerings may not be so mature.

• Skills available from existing developer relationships : Do I know and trust people with the skills already that are available and can help us get things moving quickly without the recruiting risk.

• Architectural control : I want a consistent approach to application architecture, and have largely settled on MVC; whilst it’s possible to attempt to enforce other patterns on top of a chosen framework (like MVP on top of WebForms) but this is often not done well.

• Maturity : How long has the tech been around?

• Ease of setting up automation (CI, deployment) : newer technologies may not have patterns for this yet

• Interoperable with system X : the application being appraised may need to integrate with a specific database or other legacy API. Unless you want to be writing low level drivers you

NB. I’ve considered the developer related attributes outside London, as at the moment I’m not up to date on the London market. I’ll update it later this year (I’m hiring at the moment, if interested drop me a line!)

Results

I’ve modelled these options in a spreadsheet that can be downloaded here. The first version of this spreadsheet was a couple of years old, and a lot of the technologies I was considering then, and am considering now have matured and have similar scores, technologies that are becoming more popular now, like Go, or other tools you’re considering, could show more of a variation.

Choosing a stack for the client apps

The time of the pure JavaScript client apps has definitely come. With the speed and maturity of mobile browsers, and obsoletion of IE8 for most cases developers are free to create rich client interfaces in the browser, calling backend services for data and binding it on the front end.

Tools like Angular, Knockabout, Ember provide the patterns and plumbing to create modular, testable client-side applications. The biggest concerns with the single page style applications created with these frameworks are around deep-linking and SEO.

Tools like rendr take this a step further and run the same backbone application on the client and server, so that these issues are removed; if the server receives a request for a deep link within the application it processes it on the server and renders the page correctly.

For mobile it’s still very much about native apps for each platform you want to support; tools like phonegap that allow you to develop cross-platform are great in principle, but often result in apps developed to the lowest common denominator, and the experience on all platforms suffered.

LinkedIn and Facebooks apps, amongst others, use a hybrid approach of native functionality and HTML5 delivered from the server, attempting to get the best of both; a native feeling experience while being able to update on the fly and re-use functionality between platforms – expect to see if these technologies are open sourced as they mature.

The release of LinkedIn intro has provoked a lively debate on twitter about security and privacy. Privacy is a hot topic at the moment, but it seems like the tech scene has been particularly contrite about Intro.

As a technologist, what LinkedIn have put together from a user experience perspective is pretty amazing and elegant; both the functionality itself, and the way they deploy it without needing to manually set things up, instead using a combination of OAuth and an iOS provisioning profile. I could imagine an extremely complicated setup process for this, but they’ve really thought about how to deliver Rapportive to the masses on iOS.

I envisage other services taking this email proxy approach too, to augment the mail user experience. It would be great to be able to chain services together, and / or use tools like IFTTT, Zapier or yahoo pipes to introduce workflow and augment emails with functionality from different services.

Sure it’s not the perfect way to extend mail; having a plugin mechanism could be more elegant, but were that available in all likelihood some services would need to send the content of the mail to a server for analysis, surfacing the same concerns about a service having your data. A plugin mechanism would also have an extra round trip to the server for the analysis, with implications for user experience caused by delays while it happens.

I feel the alarmist reaction to the security / privacy side of things is just overblown. Google apps are widely adopted, we share our lives on Twitter, Facebook, Pinterest, et al. This data is being used by the businesses, for usage / behaviour profiling and for targeting and re-targeting ads.

Remember, if you’re not paying, you are the product. iIt would be great if every service offered the option to pay for it, and in return didn’t use my data. This would also be a great way to put the privacy issue to bed once and for all, and I’d be interested to see this done at least as an experiment. A cool hack project would be to calculate the value of a persons social media profile; people could then pay a similar amount to have their profile removed from the monetization schemes (an interesting aside from this is what uplift would be needed to counter any adverse network related issues).

As far as I’m concerned, I sign up for services that do cool stuff with my data. I’ll make a value judgement on whether to use a service, but if I am, and it’s free my assumption is that they’re monetising my data. I actually prefer targeted ads; if I have to see ads, it’s better if they’re for things I’m likely to be interested in buying.

Services have an obligation to not to lose my data; nobodies perfect, and as we know LinkedIn had a breach recently, but there are already (in the UK at least) data protection laws that result in criminal proceedings should a company not be taking acceptable measures. They’re certainly no more likely to lose my data from their servers than I am to lose one of my devices.

I’ve installed Intro, and continue to watch it but I’m not actively using it; whilst I liked Rapportive, the fact you have to use gmail on the web to use it is a big turn off (perhaps the intro solution could be extended to desktop). I also don’t use iOS mail, which I assume is more likely to be solved.

You might say I’m quite an argumentative person…. I enjoy nothing more than a debate with an intelligent person, during which I can educate them, learn something and push forward whatever it is that’s being debated.

This is an extremely important part of being in a team; the collective intelligence of a team is (or at least should be) significantly higher than any one individual so it follows that through debate and collaboration, the productivity / quality of output of a team can be improved. There’s always value in a fresh pair of eyes, and someone that can ask the ‘stupid’ questions and ‘what-ifs’, that can ensure an idea is fully thought through ahead of being actioned.

It’s often the case that one or more of the individuals contributing has emotional ownership of the thing being debated, leading to the potential for them to be defensive and to feel that any improvements or negative feedback reflect badly on them. It’s important to make it clear to everyone that this isn’t the case, that it’s the team that own these things and that improving them is also the responsibility of the whole team. It’s equally important to make sure that this is also understood / followed by other stakeholders in the organisation (especially management).

Here are some things I think are important in these types of debates, to help keep them productive:

• Don’t let it be personal; talking about ‘it’ directed at the idea, rather than ‘you / he / she / they’ the people implementing it can help to focus in the right places.
• Keep it professional; the tone of voice and volume being used can influence the conversation and how it’s perceived as much as what’s being said. It’s often difficult if people are really passionate about it, but try to keep emotions in check.
• Don’t fight a corner; the aim is to improve the result, not to win. I often switch sides multiple times during the course of a debate, and it’s a good idea to force those involved to do the same to improve this too.
• Make choices based on the evidence if you can; things are rarely black and white; metrics, effort to implement, cost and associated risks may all help you, and it’s often a good idea to optimise these variables. If you’re torn between sides, one of which is expensive / slow to validate and the other cheap / quick, go with the quick one first. If there’s something else that can be done to provide more evidence, that may be the correct course of action.
• Don’t procrastinate on a decision; lets face it, we make very few life or death, or irreversible decisions. It’s better to make the decision, execute quickly, validate and learn. The learning from the ‘wrong’ decision can provide further evidence for continuing to move things forward.
• Make sure everyone that has an opinion is heard; this is super important – don’t exclude anyone from the process, especially those that will be involved in the implementation. It’s critical to make sure those that have an opinion feel they’re heard, and that if those opinions aren’t being followed that there are legitimate reasons why. One of the quickest ways to foster an environment where debate doesn’t happen is to just ignore peoples ideas!
• When the decision is made, rally around it to make it happen. Moping, complaining or even worse actively working against the decision leads can significantly affect the morale of the team.

It seems to me that customer service is being largely forgotten these days, intentionally. The internet / e-commerce age has lead to massive efficiencies in distribution, for every business from books to travel.

It actually feels like we’re fostering a spirit of anti-customer service, “the customer is never right”. From Ryanair herding you onto a plane like cattle and bombarding you with adverts, to the complete inability to contact some web properties, businesses are actively trying to provide a bad experience, in search of profits.

Should every business be obliged to forsake profit and provide good customer service? Of course not, but I can’t help look at these businesses and think that I would be prepared to (and do, where I can) pay a 10-20% premium to get good customer service. I can’t be the only person who things that too? What % premium would people be prepared to pay?

I had a particularly un-helpful experience yesterday, hence the rant. I was late for a train, which was itself late and as I got to the platform the doors were closing. The dispatcher said “go to the back” where I saw the guard standing on the platform – I ran over as she got in, “too late” she said. Fortunately her door had a handle, which I opened and let myself in.

I’ve missed my fair share of trains, or planes, boats, buses, etc (in fact, I’m sat on the next train, having missed one on the platform this morning), but what has gone wrong with society that one human being would intentionally try to disrupt another’s day unnecessarily? Perhaps this is a problem bigger than customer service alone…

Good customer service is hard at web-scale, no doubt about it. That Amazon, possibly one of the companies that define web-scale, can do a pretty good job of it suggests it’s possible. If I ever need to return anything, which happens fairly regularly, I log in, open a web chat window and very quickly get return instructions and the item refunded / exchanged. Add in collect+ where they deliver stuff to my nearest corner shop, and I now favour Amazon whenever I can, to the extent where I’ll take a slightly different product to the one I’d intended rather than go elsewhere.

For those of us not servicing tens of millions of customers, start with an email address up that goes to a distribution list amongst your team. If you outgrow that use a tool like Uservoice or getsatisfaction to receive those emails, organise, monitor and report on them. However you handle these messages you have to be responsive to maintain the customers confidence (and have a shot at their wallet).

I’m asked so many times “how can I / my friend / my child get into programming?”

With the growing influence of technology in business, the amount of attention on the “tech startup” scene including the governments TechCity initiative, the widely proclaimed shortage of technical talent and numerous articles pushing software development as a top career choice, this is likely to be asked even more frequently. I’ve been iterating on an email response to people who ask and thought I’d share it.

There are plenty of resources on the web on every conceivable language and tool, but I haven’t seen anything that maps out how a learner can progress from nothing to a professional developer standard, leaving people confused about where to start and how to go about it.

My suggested plan is listed below, it’s not essential that they be followed in order, but each level gives the learner the building blocks they need to progress and offer a nice progression in my opinion.

• Learn the basic web page technologies
• Write lots of code
• Deploy a web page / site to a live environment
• Write lots of code
• Learn JavaScript and jQuery
• Write lots of code
• Learn a server side language and framework
• Write lots of code
• Get a grounding in multiple languages and paradigms
• Write lots of code
• Join meetups and open source projects
• Write lots of code
• Get some work experience
• Write lots of code
• Keep learning

The below is aimed at people new to software development, so a lot of detail has been ignored, and things simplified in an effort to get the learner moving as quickly as possible. Like an onion with multiple layers, as the learner progresses through the different stages, more details will be revealed to them.

Learn the basic web page technologies

Web pages are the building blocks of the internet, and the current suite of web page technologies; HTML & CSS are a good starting point for somebody wishing to get into programming. Manipulating a few text files, refreshing a browser and seeing the effects of changes can be extremely satisfying and starts to give the learner an understanding of how software is created.

You should also start to understand the building blocks of the internet and how they relate to each other; Http, TCP/IP, DNS, SSL, XML, JSON, client side and server side scripting.

Resources:

• codecademy
• Team tree house is also a good reference, although you have to pay for much of it:
  • treehouse HTML
  • treehouse CSS

Deploy a web page / site to a live environment

With a basic understanding of how to create a web page, the learner is able to create a landing page for their next idea. For friends, family, etc to be directed to it, it needs to be hosted somewhere accessible on the internet. Take a look at the available options; My personal favourite at the moment is Github pages, which lets anyone host ‘static’ websites for free, on a custom domain (I use octopress to create the static site), Amazon Web Services (AWS) hosts static websites (via S3) and full web stacks (via EC2) very cheaply. There are plenty of other shared hosting solutions to check out that will help you get your site up on the internet.

Learn JavaScript and jQuery

As soon as you have a static web application up and running you can start making it respond to your users actions; sticking with the “static” site idea, JavaScript allows you to make web pages interactive, but without requiring any additional server components beyond those covered above. Your website serves a JavaScript file in the same way as it would am html page, css file or image, and the JavaScript gets executed in the users browser.

JavaScript has an extremely good ecosystem of libraries to make dynamic pages easily, from jQuery to interact with and manipulate the elements on the web page to libraries that provide a “Backend as a service” for authentication, data storage, analytics, etc that mean you can quickly spin up extremely complex web apps with no server components at all. A good reference for these back end services can be found here and many of them offer free plans to get you started. MongoHQ is a particular favourite to allow your app to store any data it needs.

Resources:

• codecademy javascript
• codecademy jquery

Join meetups, open source projects and engage in the community

The community of software developers has to be one of, if not the most engaged communities, both on the internet (hardly surprising given these are the people who create the internet) and in person. Whilst you will occasionally come across people that want to obstruct, belittle and generally be a pain in the backside on the whole the community is incredibly supportive to people with a desire to learn, and who have made a bit of effort to answer their own questions before asking for help. A well worded query on google will often give you the answers you need, and when they don’t including evidence of what research you’ve done on your own “I read x, y and z but I still don’t understand why it doesn’t work the way I expected” in your questions will often lead to more favourable responses.

Discussing things with others, both in-person and online allows the learner to validate and build on their current understanding. The learners understanding of things they think they know will improve considerably when they explain them to others, and the conversations may also highlight issues with their understanding, or expand further into areas that weren’t previously understood.

Some tips:

• Join meetups and open source projects, and seek out further opportunities to discuss and to peer review your code and ideas.
• In-person code events, like coding dojos or code battles, allow you to tackle code challenges in a group, extend your knowledge base through working with other people and help you learn how to work in a team.
• Github has fundamentally changed the way the software development community communicates; if you see a project you want to contribute to it’s now simple to fork it, change what you want and then contribute it back to the maintainer for inclusion in their project. Github also helps you demonstrate a body of evidence that can help you in your conversations with potential employers.
• Share the code you write and engage in the community : places like stack overflow let you ask, and answer questions. Asking questions helps you further your understanding, answering questions, and the comments you receive, helps you validate and extend your understanding.
• Go to startup events, like Launch48 and Startup weekend, where you have the opportunity to apply your coding skills to a real life business problem. It doesn’t matter how far into your programming career you are – these events are always crying out for more programmers and any help is appreciated.

Resources:

• hackerrank
• codeeval

Learn a server side language and framework

The “Backend as a service” providers can provide a lot of generic functionality that your app needs, but most software developers still favour writing their own backends; there are numerous reasons for this, but suffice to say you’ll need to learn a technology that runs on servers.

There are so many options here it can be daunting, but for a beginner it can be boiled down to : Large corporations use the .Net and Java Enterprise stacks while startups use lighter-weight web frameworks based on Ruby, Python and JavaScript (JavaScript can run both on the client as discussed, or on the server using Node). Good developers learn multiple languages and frameworks and there’s plenty of transferable skills between them, so don’t get too hung up on making a decision; maybe do a few tutorials, speak to people in your area about what jobs are available, and jump in and start learning one. Right now my advice would be Ruby, or Node.js, but that regularly changes based on the market.

As you start extending your application to the server, you’ll be able to run it locally, but if you used the static website options above you’ll need to transfer to something that lets you run a server application so you can share it with people. heroku, nodejitsu, AWS and a number of other providers allow you to host your application for free; heroku is a favourite at present for most open source stacks, but research these and others to find the right solution for you if necessary. Another benefit of Heroku is that you’ll start learning another important tool : Git, which at it’s most basic level allows you to version your code and if using github, bitbucket or any other “hosted” system allows you to backup your code should the worst occur.

Resources:

• nodebeginner
• learn ruby in a month
• codecademy ruby
• codecademy integrate the twitter API

Get some work experience

With a working knowledge of how to build web pages and a backend language, you should get experience working in some different organisations. Reach out to companies via contacts you meet, or via workinstarups.com, enternships and other internship placement schemes. A company taking on interns is looking for people with good programming skills, the motivation and drive to learn the businesses technologies and a good cultural fit in their group.

Include good examples of your work from your Github account in your covering letter when you apply, and call out some of the interesting things they would find in your code, speak positively about your experiences but don’t be afraid to use examples of where you found difficulties to show how you overcome challenges.

Every companys working environment is different, and it’s important to experience a few so that you can start to identify the things you enjoy and those you don’t:

• Different projects use different languages, frameworks, tools, development processes
• On some projects you’ll work on one person projects, others in varying sizes of groups of people.
• Sometimes you’ll be developing “green field” applications from scratch, others you’ll be fixing and improving an existing code base.
• On some projects you’ll have very clear requirements at the outset, on others they’ll be more open
• On some projects you’ll be closely managed, on others you’ll be free to manage yourself

It’s important at this stage to start learning how to work in a commercial setting; you’ll need to hit deadlines, will learn how to track the work you need to do and what you’ve done, how to work with other stakeholders in a project (the sponsor, customers, other developers, testers, operations, business analysts, etc), how to use Version Control Systems (like GIT) within a wider team.

Get a grounding in multiple languages and paradigms

One thing universities do quite well, I would consider it to be the most important part of a CompSci degree and that’s to expose people to different programming paradigms. In the UK it’s often Fortran, Pascal and C or Java but unfortunately this is often a small part of their syllabus.

Currently the two styles of programming that are most widely used are Imperitive/Objected Oriented and Functional Programming, using either dynamic or statically typed languages.

It’s often possible to write both functional and imperative code in a given language, but some are better suited than others and learning one of each combination (statically typed & OO e.g. Java or C#, statically typed FP e.g. Scala, dynamically typed OO e.g. Ruby/Javascript, dynamically typed FP e.g. erlang) would give you a good base to work from.

Assuming you’ve got a solid understanding of JavaScript and Ruby a good next option would be Java, as it’s a widely used strongly typed language. There’s also certification available that can help validate your skills to potential employers.

References:

• the best book for the Java certification scheme
• book Java certification exam (worldwide)
• introduction to programming (with Java)
• free programming books

Keep learning

The industry will never stop changing; there are always new languages, tools, techniques and 3rd party applications and services that can help you solve your problems easier, reducing the amount of custom code you need to write and maintain and allowing you to focus on the tasks that relate to your projects problems. You need to keep your finger on the pulse and be evaluating these new tools.

The best universities around the world are offering degree level classes online too, often for free. These are a great chance to get that 10-20% of knowledge that you miss if you didn’t do a University CompSci degree.

There are loads of other interesting tracks on codecademy and treehouse from there, and loads of other resources on the web. Depending on what interests you you can look at different databases, different clients (Android, iOS, desktop apps for mac or windows, etc).

It’s at this point you need to start learning about “patterns”; common ways of designing / organising your code. The “Gang of four” produced the seminal reference on this and there are plenty of resources around the web where they’ve been well reproduced.

Write lots of code

You’ve probably realised that this recurs over and over again in my plan. I can’t emphasise enough how important it is to actually write code; it doesn’t matter if you’re writing code completely for fun (solving coding challenges), contributing to startups or open source projects, or creating websites or apps for your parents / friends / neighbours / paying customers – the most important thing you can do as a programmer is hone your craft.

Some tips:

• There are plenty of code challenges online; these come in the form of generic puzzles with a known solution, or potentially challenges without a solutuon sometimes paying prizes; the important thing is they give you the opportunity to excerise the raw skills that you learn and apply them to real problems. Check out code katas, http://projecteuler.net/, https://code.google.com/codejam/, https://www.hackerrank.com/
• Join meetups and open source projects, and seek out further opportunities to discuss and to peer review your code and ideas.
• In-person code events, like coding dojos or code battles, allow you to takle code challenges in a group, extend your knowledge base through working with other people and help you learn how to work in a team.
• Github has fundamentally changed the way the software development community communicates; if you see a project you want to contribute to it’s now simple to fork it, change what you want and then contribute it back to the maintainer for inclusion in their project. Github also helps you demonstrate a body of evidence that can help you in your conversations with potential employers.
• Share the code you write and engage in the community : places like stack overflow let you ask, and answer questions. Asking questions helps you further your understanding, answering questions, and the comments you receive, helps you validate and extend your understanding.
• Go to startup events, like Launch48 and Startup weekend, where you have the opportunity to apply your coding skills to a real life business problem. It doesn’t matter how far into your programming career you are – these events are always crying out for more programmers and any help is appreciated.

Wrap up

Following the path above a person with the motivation and drive, and working on the craft of software development full time should be able to get to the point where they could take work experience in 6-12 months and would be more employable than a lot of 3yr CompSci degree graduates. It’s also important to consider the costs and the debt most graduates are burdened with.

Because of this I personally believe a Computer Science degree is not the best option for a large proportion of people that want to get into programming. Most software developer roles are not pushing the boundaries of the field. Most software developers are using an existing suite of tools, languages and techniques to solve business problems.

Solving a programming problem is typically a combination of:

• Experience – What similar problems have I solved before. What tools and techniques did I use? How can I improve on that approach?
• Research – Who else has solved a similar problem before. What tools have they created that I can re-purpose? How can I improve on that approach?
• Learning & implementation – How do I apply the selected tools and techniques to the problem?

Current computer science degrees in the UK help a lot on the last part, giving the learner a broader knowledge in that area, but I would argue that the plan detailed above would get a learner more of the specific parts important to most employers (the general purpose techniques). By following the plan above and writing lots of code, the learner will have much better Experience and Research skills, putting them well ahead.

I’m not against university degrees; there are many legitimate reasons to go to University if you want to become a programmer: CompSci degrees and graduates of them are needed as the boundaries of the field do need to be continually pushed, with the results of that filtering down to the mainstream to utilise. Non subject specific and social reasons for going to University; expanding your mental capacity, critical thinking / analysis, getting away from home for the first time, becoming independent, broadening your horizons, finding yourself, not knowing what you want to do with your life, laziness, etc. These are valid, but people shouldn’t be afraid to be honest about which of them apply.

Doing a program as I’ve outlined here on your own, would require discipline and focus, and may be difficult for someone at the A-Level / university age. I’ve worked with a number of learning establishments on apprenticeship programmes and if the learner can find a suitable one in their area this is a great option. Some things to be aware of when appraising different programs:

• Many college IT apprenticeships focus on the networking and infrastructure side of things; these aren’t really suitable for someone who wants to become a programmer.
• It’s important to find a programme that loosely follows the above plan, and that uses modern languages in their teaching.
• I’ve found QA training in the UK to be pretty good – they have apprenticeships based on Java or .Net, and have a massive amount of other courses that you can include as part of the apprenticeship.

 Should I / when is the right time to teach my kids?

I’ve also been asked about this for younger children, and I have no experience of this, but the articles below should help.

• http://blog.enternships.com/post/53287729415/5-apps-to-trick-your-child-into-becoming-the-next
• http://lifehacker.com/how-and-why-to-teach-your-kids-to-code-510588878

I’ve been spending a lot of time recently thinking about what the next 3-5 years should look like for me. There are a number of options available to technologists, each with their own positives and negatives. When facing problems like this I like to get quantitative; figure out a model, put my options into it and then have it inform my decision.

I’d broadly categorise the options available as:

• A stable SME/larger corporation – the traditional option; becoming a small part of a large corporation. You’ll get a market rate salary, good benefits and career progression opportunities, but little in the way of equity. Depending on seniority you may not get much of an ability to control how you do your job, with things dictated from above, and you may find yourself working on the same things for an extended period of time.
• Join an agency or consultancy – brought in by other companies for specific projects, they offer a wide variety of work, good benefits and market rate salaries.
• Start your own consultancy / go freelance – Flexible and well paid, the market is currently hot but there’s no long term guarantee of work other than being good at what you do (and even then it could potentially dry up). Unless you grow it into an agency or large professional services company there’s little equity.
• Company builders – these are companies that build and spin out new companies. You’ll get a lot of support from the host company, allowing you to focus on those bits unique to your business and you’ll have a decent amount of funding to ensure you can hire as you’ll need to. You won’t have as much autonomy as a pure startup.
• Join / start a seed stage start-up – The chance to shape a company as you want to see it, the pace will be manic, the role fluid and you need to create / prove everything from scratch; the tech stack, business model, customer acquisition, sales process, admin processes, etc, but it gives you the opportunity to be a core part of a large idea. Incubators, accelerators and co-working spaces can all help to provide a support community around you. You’ll earn a lower salary, but will have a larger equity allocation giving you more of the potential upside.
• Join a later stage start-up – These will have a proven biz model and traction, and now need to scale it up to more customers. Can be anything from a group of 5 with £1m to a team of hundreds with £100m+. You’ll be able to earn a salary close to market rate and will get equity, giving you a potential upside in-line with the stage at which you join.

In making the decision, I think about the attributes of the roles that I care about, giving each attribute a score out of 10. I then think about how each option fares for each attribute, noting my thoughts (so I can recall it in future), also giving this a score from 10. For this decision I care about:

• Salary (score = 6) : How much will I be paid annually, including bonuses, commission, benefits, etc. This is moderately important to me.
• 3-5 yr financial outcome (9) : A combination of the amount of equity offered, the potential value and the likelyhood of it happening. Very important to me.
• Stability (5) : How long have they been around? If appropriate how long is their runway?
• Role (7.5) : What will I be doing?
• Tech stack (6) : What technology are they using? How much room for change is there?
• Market (7) : Are they working in an area that interests me?
• Team (9) : Who else will I be working with? How suitable are they for the business they’re building?
• Vision (9) : Where do they want to get to?
• Location (7) : Where are they based? How does that align to my agenda?

I then multiply these things together; so the score for each option by the importance of the option, adding them all together to give an overall score for the option – the higher the score the better the option. It was interesting to go through this exercise and the results support what I had been thinking qualitatively. It’s also easy now to plug in other options that arise and see how they compare.

You can see the result of my analysis in the attached spreadsheet here – I’ve removed any sensitive information, but feel free to clear it down and use it to model your own decisions.

I’ve seen a number of teams who proclaim to be ‘doing agile’, with varying levels of success. For me, and especially where the team isn’t in a complex environment (i.e. a hierarchy of agile teams / scrums of scrums, etc), the major benefit of agile is that it allows the team to be as efficient as possible, delivering as much business value as possible.

I’ve also seen agile often used as a positive spin on being disorganised; simply having little or no documentation, design or process does not an agile team make! A team in this state, using agile vocabulary actually compounds the problem; both through the differences between reality and what is presented to customers, prospective team members and other stakeholders, and because of the additional process and work associated with agile (retrospectives, planning sessions) that are ineffective and waste time when not used properly.

Below are some common traits I’ve seen in good teams, and how to spot when they may not be correct, I’ve often seen the opposite of these in teams and they can be easily spotted by talking to individuals in the team; you’ll often hear complaints, moaning and general dissatisfaction around these themes.

• The team either has an empowered sponsor / business owner available at least 80% of the time, or there is a good understanding of the acceptance criteria for work items being delivered. If you regularly have situations where the sponsors expectations aren’t met, this is likely to be the issue.
• The backlog is managed sensibly, with work coming into the backlog and the team managing it through the process. Work coming in directly to individuals is a common indication this isn’t happening.
• Work item estimation is done with a good understanding of what the scope / acceptance criteria are. Estimations based on a one line description are unlikely to be accurate.
• The team has an appropriate development process for their situation. If the team is less than ten people, in one room, a simple wall board should suffice. If you have remote team members you need to think about how they interact with it.
• The team is empowered to deliver, and to modify their development process. This should be handled in the retrospective with the team optimising as appropriate.
• The team has a culture of code quality, especially tests. You often see a reluctance to refactor code when a codebase has insufficient tests.
• The team has an engaged daily standup with a small amount, but not too much, back and forth between team members. A flat, boring update with everyone giving a 15 second update to the team leader doesn’t really add value.
• The team regularly contribute to each others features, through discussion, review, pairing and testing. A group of people working in isolation does not equal a team.
• The team ships regularly, whether this is to a UAT environment, or live features are being deployed regularly. If the shorter of a month, or two iterations go by and this hasn’t happened, it’s a bad sign.

Note I didn’t say you need to produce reams of documentation for this stuff, putting stuff ‘on paper’ and storing them somewhere centrally does help the team be explicit about expectations, but isn’t essential.

Do you recognise any of them in your team?

As part of a new business I’m setting up, I wanted to get a simple blog system online. In the past I’ve used Wordpress, and although I hate PHP have never found anything that made sense as an alternative.

For me the criteria for an alternative were : – Written in a language platform I was interested in – this is pretty much any common, current web stack, except PHP. – Feature rich with the ability to extend it, an abundence of extensions and an active community. – Has a straightforward and cheap cloud deployment mechanism.

But thinking about it again recently I’m more interested in: – Has a straightforward and cheap cloud deployment mechanism. – Very little maintenance requirement – a static deployment to S3 would be perfect – Allowing the post content to be edited locally in text files, in an open format – Have a number of themes available, so that I only need to pick one and write some content and off I go – This is less of a priority but I’m using node JS on a project I’m working on at the moment, which I’m new to, so any coding (extensions, templates, etc) being in Javascript would be ideal

This led me towards Blacksmith, https://github.com/flatiron/blacksmith, using an S3 static website for the hosting. I was pretty close to moving forward with this, but couldn’t find much in the way of themes. I’ve now settled (I think) on Octopress, and probably github pages for the hosting. I have a basic understanding of Ruby, and haven’t used it in anger – but I assume I’ll be able to pick it up should I need to.

I’ll now document the install process from my Mac.

I started by following these articles:

http://miguelcamba.com/blog/2013/04/22/tutorial-create-a-blog-with-octopress-and-host-it-in-github-pages/

The first issue I received was when running rake deploy, which returned this error:

"You have already activated rake 10.1.0, but your Gemfile requires rake 0.9.2.2. Using bundle exec may solve this."

Running “bundle exec rake install” fixed this.

The same went for the next few bundle commands, resolved using:

bundle exec rake setup_github_pages
bundle exec rake deploy

When running this deployment task I received the error:

## Pushing generated _deploy website
To -- removed for security --
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to '-- removed for security --'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.

One tip – when creating the repo in github, don’t specify a git ignore or a licence and this issue seems to be avoided. I did find a solution to this on stack overflow : http://stackoverflow.com/questions/17609453/rake-gen-deploy-rejected-in-octopress

Edit the Rakefile and look for this line:

system "git push origin #{deploy_branch}"
Alter the line by adding a plus (+) before the #{deploy_branch} tag:

system "git push origin +#{deploy_branch}"