Archive for the ‘apprenticeship’ tag
What makes a good developer?
Early last year I became very curious about what it was that made the best developers in the industry so good at what they do.
Jay Fields points out some things that he believes indicate that a developer is good at the end of this post but a former colleague and I tried to come up with a list of areas that any Developer needed to be skilled in to justifiably consider themselves good.
This is not an exhaustive list but it was just some ideas we brainstormed and I've expanded on them a bit.
Languages and Tools
The first skill any developer needs to have is an ability to work with programming languages and the main tools that are used with them. These could include build tools, IDEs, web frameworks, messaging APIs.
Although Martin Fowler talks about how he prefers design skills over language skills, I think it is important that you do have a good level of knowledge of at least one language.
These skills can best be acquired through practice, learning APIs, playing around with different frameworks etc. There are also infinite books available which go through the features of different languages which I won't list here.
In a Java development environment you might need skills in some of the following, for example:
Clearly the more languages and tools you are familiar with the more useful you become on any team you're on. Knowledge of different types of languages (e.g. static/dynamic/functional) can help bring different points of view in understanding how to solve problems.
Programming Paradigm
This concerns the design skills which Martin talks about. Martin covers it in much more detail, but one area this would cover is having a good understanding of object orientation which is vital for writing maintainable code with imperative languages.
An understanding of ways to approach different problems you might encounter in enterprise development by knowing different patterns and when to apply them is also useful.
The following books would make good reading in this area:
- Agile Software Development Principles, Patterns and Practices – Robert Martin
- Clean Code – Robert Martin
- Code Complete – Steve McConnell
- Design Patterns – Gang of Four
- Head First Design Patterns – Kathy Sierra & Co
- Enterprise Integration Patterns – Gregor Hohpe, Bobby Woolf
- Object Design: Roles, Responsibilities and Collaborations – Rebecca Wirfs Brock, Alan McKean
- Patterns of Enterprise Application Architecture – Martin Fowler
- Refactoring – Martin Fowler
- Refactoring to Patterns – Joshua Kerievsky
- The Pragmatic Programmer – Andrew Hunt, Dave Thomas
- Working with Legacy Code – Michael Feathers
Domain Specific Knowledge
Specific knowledge about the domain (e.g. Investment Banking) is vital for writing a system which is closely linked to the problems it is trying to solve.
Although a lot of this knowledge is acquired by the Business Analyst on the project if Developers can gain it too then conversations with users will be much easier to deal with as amongst other things the terminology they use will make sense.
Beyond this it is useful to understand the goals the business people have, the processes they use to achieve those goals. An understanding of the history of their business so you can see where their industry is going and why is useful for context.
Some domain knowledge can be gained by reading books – this is especially true once you start reading the books that practitioners are reading – but a lot of the knowledge can only be learned by speaking to or watching people who do that job for a living. For example I found out that Options, Futures and Other Derivatives is a very popular book in the investment banking world from my time working in that environment.
Eric Evans' Domain Driven Design details a way of writing code specific to the domain that you're working in. Specific domain related books are probably best located with an Amazon search.
With regards to learning domains, the approaches one can take vary from focusing very heavily on one domain and learning it inside out to getting an understanding of a broad set of different domains.
People Skills
One of the most important skills in software development is the ability to work effectively with other people – fellow developers, Quality/Business Analysts, clients, users, the list is endless. If you can do this effectively then you go a long way to ensuring your success.
All the skills of Emotional Intelligence as Daniel Goleman has termed it.
Some useful reading around this area:
Problem Solving
The ability to solve problems that don't have an obvious solution is key in software. Coding wise it could be debugging a class-path issue when deploying your application to JBoss or finding a tricky bug that a test reveals.
I found Debugging: The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems to be very useful reading around this area as it helps to keep you honest when solving coding problems and not over thinking the problem.
The best problem solvers logically go through the problem logically using small steps, investigating potential causes until they solve the problem.
Personal Management
The art of managing your time effectively, prioritising your work correctly and keeping focus on what's important. GTD is a famous book in this area although I think it comes down to experience and understanding the way to best exploit the way that you work.
Communication
This links to people skills but includes written communication, how you transmit ideas and your ability to persuade people.
These skills come in very useful when taking part in exercises such as pair programming for example.
I have read a lot of information around Neuro Linguistic Programming (NLP) in this area – Introducing NLP is a useful book to start with on this subject. NLP amongst other things is a gathering of techniques which effective communicators have been seen to use. NLP Weekly is a useful online resource.
Gaps
Acknowledging when the facts don't match your theory and keeping room for possiblity. In other words approaching things with an open mind, keen to learn other approaches to solving problems.
Go Meta
The ability to learn how to learn – the skill of skill acquisition – as well as knowing which skills to learn next and which to abandon.
Andy Hunt's Pragmatic Thinking and Learning strikes me as a book which covers most of these things. It has only recently come out but I will review it when I get my copy.
–
There are bound to be things I haven't considered for this list. I would like to hear other ideas. My underlying desire is to hear the skills that people are developing to make themselves a better software developer.
Construx have the idea of a Professional Development Ladder but I think you need to be a member to see a proper version of it.
My Software Development journey so far
While reading some of the rough drafts of Apprenticeship Patterns online I started thinking about the stages I have gone through on my Software Development journey so far.
I have worked in the industry for just over 3 years; 1 year at Reed Business and 2 years at ThoughtWorks. Over that time my thoughts, opinions and ways of doing things have changed, and no doubt these will continue to evolve as I learn more and more.
My time at RBI
I started working at RBI in August 2005 a few months after I finished University. My experience up to this point involved several years coding PHP in a very procedural way and a little bit of Java.
I was hired by RBI as a C# Web Developer and my work there involved working on several internal projects and looking after one of their websites.
At this stage I was still very much convinced that the art of software development lay in learning languages, so I used to spend all my time reading about C# and playing around with all the different APIs.
At this stage I was using Visual Studio without Resharper so I didn't have the ease of Refactoring or moving code around that I now take for granted.
One of my colleagues took me under his wing and started teaching me how to write better code – separation of code across presentation/business/data layers was my first lesson. Suddenly it became so much easier to make changes! All the code I wrote was still in a non TDD way and after one episode where I created a bug in production I started to think that surely there was a better way to develop software.
Eventually my colleague suggested to me that if I really wanted to learn how to write software then the best place to do so was at ThoughtWorks.
ThoughtWorks Days
I started working at ThoughtWorks in August 2006, hired through the TWU graduate program.
I thought I had a fairly good idea of how to write Object Oriented code but that theory was quickly disproved as I went through Object Boot Camp as part of my TWU training. The Single Responsibility principle was the overwhelming lesson learned as part of this. I also remember believing at this stage that it was all about Design Patterns.
I came back to the UK and did a couple of small projects where I first came across continuous integration and TDD before going onto my first big project.
I remember my first day on that project involved pairing with Darren Hobbs and being amazed at the speed with which he was able to move around the code using IntelliJ. It became clear to me that I had a long way to go.
Working on this project for the best part of the year I learned a lot, including how to write code in a Test Driven way, that everything you do in software is a trade off, but most importantly I learned how to master the IDE – if you can do this then you feel more confident and you can complete tasks much more quickly. This is always the advice I see given to new Graduates at ThoughtWorks – learn how to use your tools!
I moved onto my second project where I was immediately surprised at how much easier I found it to move around the code base than I had at the start of my first project.
We were designing a client side application so a big part of my learning here was around testing presentation logic. Jeremy Miller's blog proved invaluable at this stage.
It was also the first time I came across the concept of Domain Driven Design – it was amazing how much easier it was to develop software when the developers were using the same language as the BA, QA and in fact the business. InfoQ's cut down version of Eric Evans' famous book proved useful in helping me understand the concepts that I was seeing in our code base. I remember thinking at the time that I didn't need to bother reading DDD as it was all covered in this version – I was wrong!
We had an very lightweight version of Agile being used on this project – we tried to have minimal process and do as many things as possible just when we needed them. It was almost Lean in nature although this was never explicit. It was interesting to me how easy and fun software development could be when it was done like this.
My third project was the first time that I got the opportunity to work with legacy code – i.e. code that hadn't been unit tested. My early lessons on trade offs came back to me here as I realised that not writing unit tests is a trade off – you can choose to go more quickly initially by not writing them but eventually it comes back to haunt you.
I was working with Alexandre Martins on this project, and his enthusiasm for writing clean Object Orientated code gave me a new outlook on writing code. Working with him got me in the frame of mind of hating exposing the internals of classes and constantly looking for other ways to solve the problem when I was considering doing so.
Halvard Skogsrud's knowledge around concurrency was another eye opener for me around how non functional requirements should have an impact on the way that software is designed. It also introduced me to the way that other languages such as Erlang handle concurrency – and behind this the idea of having as much of your code immutable as possible to avoid threading issues.
During a debate at a ThoughtWorks Geek Night another colleague brought up Alistair Cockburn's Hexagonal Architecture, which was the first time that I had come across an Architectural Design Pattern. This is a useful technique when thinking about the design of systems at a higher level.
On my next project I did a lot of work around build and deployment which gave me the insight that developing software is about more than just the code. This was a lesson first taught to me by Chris Read a year before but it finally made sense to me.
A big part of this project was inter process communication between different components of the system which introduced me to the idea of event driven messaging. I immediately saw the benefits of this over the RPC style messaging I had seen previously.
I also had the opportunity to do some work with Ruby on Rails and in particular around the use of Active Resource. This introduced me to the idea of RESTful web services which feels like a much more natural way to communicate over the web than any of the other approaches I have come across.
In Summary
The interesting thing for me is that I didn't plan to gain any of these learnings, they came about as a natural progression from my interest in software development and from working on different projects with different people.
The biggest things I have learned since I started working in software development are that it is much more an art than a science and that there is no right or wrong, just trade offs that we should be aware of.
I still have a lot to learn but I thought it would be good to have a look at what I've learnt so far in the hope it can help others just starting out on their journey.
It would be interesting to hear about others' journeys and the similarities and differences you have experienced.
