September 28, 2014

Learn TDD with Codemanship

Software Development Isn't Just Programming

Alerted to a piece on wired.com this morning about a new website, exercism.io, that promises programmers the "deep practice" they need to become good enough to do it for a living.

You won't be at all surprised to learn that I disagree, or why.

Software development, as distinct from programming, requires a wide and complex set of disciplines. The part where we write the code is, in reality, just a small part of what we do.

In particular, how can such sites exercise that most important of developer muscles, for collaborating?

The Codemanship Team Dojo, which I occasionally enjoy putting client teams through and have run with some large groups at conferences and workshops, provides a very clear illustration of why a team full of strong programmers is not necessarily a strong team.

Problems that seem, in isolation, trivial for a programmer to solve can quickly become very complicated indeed the minute we add another programmer (Hell is other programmers.)

Folk have got to understand each other. Folk have got to agree on stuff. Folk have got to coordinate their work. And folk have got to achieve things with limited time and resources.

This, it turns out, is the hard stuff in software development.

I know some technically very strong developers who consistently seem to fall flat on their faces on real teams working on real problems for real customers.

Don't get me wrong; I think the technical skills are very important. But I consider them a foundation for a software developer, and not the be-all-and-end-all.

For my money, a well-rounded learning experience for an aspiring software developer would include collaboration within something approximating a real team, would include something approximating a human customer (or customers, just to make it more interesting), would require the resulting software to be deployed in front of something approximating real users, and would encompass a wider set of technical disciplines that we find are necessary to deliver working software.

And their contention that professional programmers need "hundreds of hours" of practice is missing a trailing zero.






June 13, 2014

Learn TDD with Codemanship

Real Long-Term Apprenticeships In The UK - We Found One!!! Are There More Like This?

So, I'm inspired again.

Someone sent me a link to this web page detailing software apprenticeships in the South West of England and in Wales for Renishaw Plc.

I think this might be the first genuine, long-term apprenticeship I've seen offered by a real, credible employer in the UK. You may know of other examples, but more about that in a minute.

Years of personal research into this had led me to conclude that the apprenticeships on offer - what little their were - simple were not credible. They tended to be short. They tended to be technology or vendor-specific. They tended to be, well, a bit "Mickey Mouse", preferring to skip the tough stuff and the disciplines of writing software under commercial constraints in favour of "cool stuff" that may play well in digital agencies but is a poor foundation for a resurgence in UK tech.

There are three things I'd look for in an apprenticeship:

1. Is it long enough and in-depth enough for such a complex discipline?

2. Does it lead to a degree or equivalent internationally-recognised qualification? (Let's face it, even the best devs - without a degree - can hit a glass ceiling.)

3. Does the employer pay for it - or at the very least, doesn't charge for it.

The Renishaw software apprenticeship appears to tick all three boxes.

I'm not aware of any other schemes that currently do. Perhaps you are?

I'd like to hear about it if you do, so I can compile an online resource for potential apprentices interested in learning to be a good software developer.




May 14, 2014

Learn TDD with Codemanship

5 Years Of Codemanship

This month sees the fifth birthday of my training and coaching company Codemanship.

I created the company in 2009 to take advantage of the growing demand I was getting to run workshops and coach teams in what we're currently calling software craftsmanship.

I wanted to put into practice ideas that had been swimming around in my silly old head for several years, especially relating to how good development teams happen.

I firmly believe, based on my own experiences and on the available evidence, that good software development is a product of good software development cultures, and that culture happens bottom-up over a long period of time.

The boss cannot demand good development culture. Management edicts just don't work in this space. Nor can we expect it to happen overnight. You can't send your teams on a 2-3 day course and expect them to come back transformed.

Through Codemanship, I focus on developers and their habits and instincts, helping those who want to improve to gradually shift the patterns that are their default behaviour.

Our BBC TV Platforms case study illustrates how this can be done and what effect it might have, but there are many ways to skin a rabbit, and many routes to becoming better crafters of software. Over the last 5 years, I've worked with many different organisations and thousands of individual developers, and helped them to discover their own path, just as I once discovered mine.

Outside of the day-to-day work, Codemanship has also been busy in the community, and I've been blessed to be involved with some great events and initiatives, like producing a West End comedy show to celebrate the code-breakers of Bletchley Park, organising the original international Software Craftsmanship conference, and curating and contributing to the Music By Programmers album to raise funds for a programming club at The National Museum of Computing.

I'm most proud, though, of one extra-curricular activity; my apprenticeship with Will Price, a CS undergraduate who's working with me to help plug the gaps in his education on the practical side of "just how do we write software?" We're reaching the end of our first academic year - though there'll be much for us to do during the summer break - and I'm very pleased with how it's turned out so far. I'll be traveling the length of breadth of the land talking about it, and hopefully encouraging a few of you to try something similar.

Finally, just to say a huge thank you to all our customers, without whom none of this would be possible. I'm very lucky to have the chance to work with you all.

So, that's 5 years of Codemanship. So far, it's been the most fun, the most challenging and the most rewarding experience of my career, and I've got my fingers crossed that there'll be many more years of this to come.






January 9, 2014

Learn TDD with Codemanship

Seeking Volunteers To Mentor Undergraduate Apprentices

Are you an experienced and well-rounded software developer?

Could you spare 2 hours a week to mentor an undergraduate in the practical disciplines of software development that will almost certainly not be covered in their degree studies?

I'm looking for a dozen or more solid mentors who'd be interested in taking on an undergraduate "apprentice" starting in October 2014.

You will have:

* Strong and diverse software development experience, encompassing a number of programming languages and platforms in a variety of problem domains, applying a range of development methods

* Experience of mentoring developers, perhaps even of training them

* A genuine interest in nurturing promising talent, without asking "what's in it for me?" (if you have to ask, you're the wrong mentor!)

* A bit of spare time every week (the more the better, but a couple of hours a week on average for one-on-one coaching and preparation)

* A good Internet connection

If you think this may be you, and would like to find out more, please drop me a line.





April 6, 2013

Learn TDD with Codemanship

Science & Software

Pairing with my apprentice-to-be, Will, on Friday, we got to chatting about the increasingly intimate relationship between software development and science.

i was reminded of something I heard at university (back in the days when we wrote our dissertations with quills). A PhD student who I hung out with had been working on a large-scale simulation of atoms in a crystal lattice to try and crack the problem of why washing powder clogs. His code was written in FORTRAN and was designed to run on the HP minicomputer - a monster of a computer, almost as powerful as my Android phone!

His research was building on work done by a previous PhD student, who had also written code to simulate the same crystals. His PhD was predicated on the assumption that he'd be able to take the existing code and adapt it for his research - in much the sdame way that an algorithm to traverse a tree and search for something could be adapted to traverse the same tree and search for something else.

Problem was that the existing code was impossible to understand, and the person who wrote it was long gone. This person lost several months rewriting the simulation from scratch.

Now, this was more than two decades ago. Much physics was still done with pen and paper or in the lab. But, increasingly, more and more research was done almost entirely using software to either search through large amounts of data collected from experiments, or to simulate physical systems that would be too expensive - or even impossible - to recreate in the lab.

I'm told by friends who carried on with physics that software-based research is much more common these days. And they often share anecdotes about the trouble software causes them that sounds jolly familiar. I wouldn't be surprised if a lot of research time and money isn't being lost to the kinds of problems we come up against daily in business when software's involved.

When I studied physics, they encouraged us to keep a diary of the lab work we did. The idea was that if, for example, we got run over by a bus, someone else could read our lab diary and continue our research. Hoorah - progress continues unabated.

The lab diary codifies your method. These days, I suspect, the method may - in at least some key cases - be codified as software. If you can't understand the software, you can't understand the method, and you can't continue the research.

Similarly, if the software is buggy, then your method is buggy, and your results and their conclusions are suspect. Cue faster-than-light neutrinos. The interactions of subatomic particles at CERN are interpreted by software. My first instinct on hearing the sensational news was "I'd like to read their code".

As science becomes more and more reliant on software, the integrity of our science will rely more and more on the integrity of our software. As yet, this is a fringe topic in physics. Universities may teach computer programming and computational maths, but they don't really help or encourage students to write software to a high-enough standard.

I can't help feeling that some element of the discipline of writing good software would benefit science students. But a science degree is already a big ask in terms of time commitment. Throwing in a day a week of "software craftsmanship" or "software engineering" may be the straw that broke the camel's back.

I do think, though, that the model of apprenticeship I'm proposing to trial with Will (and A.N.Other, if I can find the right person) could present a solution.

This is something I'm going to give more thought to.



August 17, 2012

Learn TDD with Codemanship

Software Apprenticeships Summit, Sept 20th

On Sept 20th I'll be chairing a summit for people interested in long-term mentoring of aspiring software developers.

I'll explain a bit of the background. For the last year, I've been looking into this whole question of apprenticeships for software developers, talking to employers, universities and professional bodies who might be interested in getting involved. And guess what? They aren't.

With very few exceptions, it seems, the traditional alliances between employers, higher education and professional institutions hasn't got legs when we're talking about real and genuinely meaningful apprenticeships for developers.

This leaves two main groups still in the game. There are young people out there who are interested in learning how to be software developers and who've contacted me asking about apprenticeships. And there are practitioners who've expressed willingness to take on apprentices in some form.

The good news is that, in theory, that's all we need to get started.

I plan to take on two apprentices in the next year. Alas, I'm not in a position to offer them employment. Doubtless, many of us won't be. But what I am able to offer is ongoing guidance and mentoring, as well as opportunities that they might not otherwise have found.

As a mentor, I'll enter into a contract with my apprentices that stipulates a roadmap for what I want them to learn and to do, and will work with them on a regular basis - e.g., a couple of hours a week - to offer guidance and to pair program with them.

Once a year - probably during summer recess - I'll ask my apprentices to undertake a significant challenge. They'll be tasked with creating working software of the order of a dozen or so use cases for some good cause. I'll be acting as the "customer" and monitoring their progress, keeping an eye on the quality of the software they create.

Year on year, the challenges will get more sophisticated and the quality bar will be set higher. My aim is that after a few years, the projects will be not just like real-world software development, but a whole heap better than that. Being fiendish, I plan to make them build on the code they wrote in the previous year, and improve it year on year. Yes, that much better!

Outside of development skills, I'll also be helping them out by paying for them to attend a couple of conferences each year, so they can meet real developers and see what the zeitgeist is like.

I'll be asking them to blog throughout, and eventually to teach and mentor other developers, as I feel that can be a hugely valuable experience.

And, if they do well, I'll be promoting them as professionals as they become fully rounded developers. My hope is that when they apply for their first development job, they'll not just have solid development skills, people skills and experience of writing software under similar constraints to industry, but they'll be known quantities in our community, with a body of work people can look at, blogs, talks at conferences and other public-facing stuff people can judge them on. And judge me on, as their mentor.

Perhaps in 5-6 years time, Codemanship might be in a position to take them on full-time. But that is not the be-all and end-all. I'm fully prepared that this will cost me time and money and that I personally won't gain (in those terms) from doing it.

For those among you who feel that anyone who does all this and gets nothing in return is a fool, I'd like to introduce you to this thing called society. Software development as a whole could benefit, and that's plenty benefit for me. I'll also get a kick out of doing it. I'm funny like that.

What I'd really like is to see a bunch if us take on apprentices, and then we can share this experience and amplify the benefits. If we can agree on a basic foundation that would mean that any apprentice mentored by us would have to achieve a shared vision of what we think it means to be a software developer, and co-ordinate and collaborate, I believe a lot more could be achieved at a national and maybe even an international level.

So I'm organising this little get-together at Bletchley Park on Sept 20th to set out my stall, so to speak, and explain what I'm going to be doing, and then no doubt have a lively discussion with others like me, kicking ideas around in an informal setting, to see if we can begin to point ourselves in roughly the same direction.

My proposal is that we form a loose alliance beneath a recognisable banner - e.g., a guild, or an institute, or something else that wouldn't look out of place on an apprentice's CV - establish a foundation for skills and knowledge (without smearing marketing hype all over it, I hope) and also decide where/how we set the bar for mentors. Because not every developer's necessarily going to be a great role model, let's face it.

This alliance might do little more than promote a shared vision, act as a gatekeeper to fliter out ne'er-do-wells, and maybe organise a conference where applicants can meet mentors once a year (in the spring?), and possibly even graduation challenges where apprentices prove their metal on a bigger project.

Strength in numbers, basically.

If you're think of mentoring a software developer, and would like to talk with others like you, I really hope you can join us on Sept 20th.





August 14, 2012

Learn TDD with Codemanship

I Was Worried About Apprenticeships. Now I'm Resolved.

I'm worried.

No, not about whether New Girl will get another series.

I'm worried about apprenticeships. Apprenticeships for software developers, specifically.

Over the last year my focus has been shifting inexorably towards apprenticeships. Whichever angle I approach it from, I seem to always arrive at apprenticeships as the best potential answer to the question "where will the next generation of great software developers come from?"

I've been talking to employers, to aspiring apprentices (one of whom I have decided to take on as my own "apprentice" when he begins his degree studies, and I'm looking for one more, if anyone out there's interested), as well as to various august institutions of learning and professionalism, and a whole bunch of drunked conversations with my fellow practitioners.

And what I'm hearing - the general themes that are emerging - worry me.

Theme Number 1 - sing along if you know the words - has emerged from employers. We are at odds. Most practitioners I give any credence to believe that an apprenticeship of 5-7 years might be sufficient time to "grow" a proper software developer. Most employers don't think beyond 3 years. If companies were to take on apprentices, I fear they would be looking to "speed up" this process, taking many shortcuts and ultimately lowering the bar. The evidence corroborates this. I've seen a lot of companies offering inadequately short apprenticeships of a few months, maybe a year. the longest I've seen is 18 months.

Theme Number 2 is differing expectations about where the bar should be set. I, as you probably know, have little interest in cultivating anything short of excellence. Maybe if you're hiring developers out by the hour to clients who can't tell the difference, then mediocrity is worth money to you, but I've worked with those teams and I would be vehemently opposed to real apprenticeships becoming part of that scam. Let's start as we mean to go, shall we; honestly and with noble intentions. But how many employers have such high standards? Indeed, how often have you worked in a place that rewarded striving for excellence over vulgar politicial pragmatism? I am not interested in apprenticeships for greasy pole climbers. They belong in business schools.

Theme Number 3 is most troubling of all. Institutions that could support and co-ordinate apprenticeship schemes at national and international levels have given me strong hints that they're viewing apprenticeships as a source of income or as a source of greater influence. None seem all that interested in the apprentices themselves. My fear is that, seeking the largest audience possible, apprenticeships under their governance might be designed to fit the lowest common denominator.

Theme Number 4 is a common sentiment among those who fear they might lose out to apprenticeships; in particular, institutions of higher education. I make no bones about it - education for software developers isn't working. Kids are spending 3-4 years studying computing or software engineering and emerging blinking into the harsh light of the real world effectively still at square one as software developers.

This could be because universities are preparing them for a world that doesn't exist; a world where we generate code from UML models and use mathematical proofs to test our shopping cart code. Most computing graduates have never written a unit test. Most computing graduates have never refactored legacy code. Most computing graduates have never worked on a shared code base at the same time.

I've spent 12 years trying to collaborate with universities on developing courses that offer real hands-on experience of actual software development - and not just a week's worth - and it always falls down at the same hurdle. Universities teach what they teach because that's what their teachers know how to teach. Inevitably our partnerships evolve from enthusiastic lunches with departments heads who are "100% with me all the way" to frustrating meetings with senior lecturers with beards and sandals who 100% insist that the course must contain a module on Z and on compiler design.

The fact is that more than half of computer science graduates who work in software took a CS degree because they wanted to work in software. Nobody's denying that the theory's useful. And nobody's suggesting that they don't teach them the theory. But the brick wall I hit time and again is this insistence that the real world has got it wrong, and students have nothing to learn from those of us who debase ourselves by working in it. And so theory's all most computing graduates get. And, especially in software engineering, a lot of that theory is demonstrably wrong.

My ultimate goal is that apprenticeships should work. And they'll have to work in the real world, where employers are short-termists, where excellence isn't valued, where companies and institutions have their own agendas, and where the academic institutions won't help you because they can't.

In my mind, that just leaves you and me.

An employer's unlikely to commit to 5+ years during which time a considerable amount of learning's going on (though, it's going on all the time under their noses no matter how experienced their developers are - but don't tell them, or they'll assume you're not busy enough and relieve you of some of that "slack"). But I can. I know I can (sudden death or unexpected eloping to Fiji with Julia Sawalha permitting.)

What I can't do is pay someone for 5+ years.

And so we come to the compromise where our plucky apprentice gets to have her cake and eat it.

The world carries on as normal. Kids seeking careers as great software developers take their A-Levels, apply to university and do their computing degrees along with all the consultancy fodder. They study hard. They graduate. They apply for jobs as software developers. Just like they were probably going to do anyway.

The change I'm proposing happens alongside all of that. A person with considerable proven knowledge and experience working as a software developer takes them on as an apprentice.

They spend time with their apprentice every week (maybe a few hours on Skype of a weekend, maybe a face-to-face) guiding them, mentoring them and helping them to develop as fully-rounded software developers. This commitment - this bond - between the apprentice and their mentor (let's not call them "masters", eh?) will endure for years. Certainly well into the apprentice's career, with the amount of guidance needed gradually diminishing until this becomes a relationship of equals.

As well as guiding them to become better developers, we would also nuture them as professionals - gradually introducing them into the software development community and encouraging them to actively engage with their peers and do more than just write code for money.

Eventually, I would hope these apprentices will become mentors themselves, and perpetuate the relationship from one generation to the next. And, as mentors, we would be as much defined by the achievements and the conduct of our apprentices as we are by our own.

To avoid saddling them with an experience that means little to the rest of the world, I'd also seek to engage with other mentors and apprentices to build a consensus that means that my apprentice can command the same respect for her achievements from another mentor as that mentor might give to their own apprentices. Yes, I'm afraid this is going to mean that we'll need to agree on some things. That, in itself, will make for an interestingf experiment.

So this is the end of my journey of research on apprenticeships, and the beginning of my journey doing it for real.