Before I became a developer I thought that the most important skill for the role was hard technical knowledge. That is, being fluent in a few popular programming languages and acquiring the knowledge and experience to produce a reasonably complex application.
Skip forward a few years and my thinking has changed. This is based on my own experience working as a developer creating software for businesses. Projects I worked on were typically database-driven intranet web applications or back-end business data processing services.
Now I would say that hard technical knowledge probably only accounts for fifty percent of the job. The skills which should make up the other half are so-called “soft” skills: Speaking with the business to accurately determine requirements, working collectively as a team to deliver a product and fitting development work into a pre-planned timeframe.
In fact I would say even go as far as to say that in day to day situations in a development environment soft skills will help you out much more than in-depth technical knowledge. Sounds crazy I know! You are a developer.. You should be coding! The reality though is programming is often the part of the job you do at the end of the development process.
You start the work by figuring out what you need to develop? What should it do and what does it need to look like? The beginnings of answers to these questions can often only be found by initiating conversations with the business, or non-technical people in the organisation who have first-hand knowledge of the business requirement you are attempting to fulfil. But developers will often look to the code to try and find answers there instead of prompting a dialogue: We can poke around in the data until it makes sense? There must be an existing class that does the same kinda thing we can use/modify?
The result is often that a development team will slave over a product for months but working off the bare bones of a specification. They’ll do their best to implement features they think the business needs. Code will get over-engineered with additions that no one asked for. Features the business does need will never be anticipated because they wasn’t included in the specification and no one ever told the development team to add them.
This way of working can produce applications which don’t do what they need to: Fulfil the requirements of the business problem they are being built to solve. The business guys are unhappy because it doesn’t help them. The developers are unhappy because they’ve worked really hard and, in the worst scenarios, their application doesn’t even get released into production.
Part of the problem is developers spend a lot of their time studying technical skills. Sometimes from huge books which explain how to craft quality code without compromise. They come out the other end raring to develop the best applications the world has ever seen. While this approach certainly isn’t bad it doesn’t fit the real world most of the time. The average business environment is geared around balancing the amount of development effort required to deliver a product, within a budget to enable the business to (let’s be blunt here) make money!
If you are a developer in a business environment who can relate to the above difficulties I would suggest reading a short book for a change: Extreme Programming Explained by Kent Beck
It’s only about 160 pages long and doesn’t require a large investment of reading time. It’s not a technical book but it does give you suggestions on how to implement technical solutions within the framework of a business environment.
Extreme Programming (or XP for short) is part of the family of development methodologies which is known as “being agile”. If you are used to working in sprints and having scrums you’ll be aware of agile. If you are working in sprints but are struggling to figure out how to estimate or fit actually writing the code into the user stories you are planning, XP and this book may help you.
I especially like the pragmatic attitude of this book. It readily accepts that all or some of the practices of XP won’t work in all situations, with all teams or even with some types of people. But it does try, through realistic suggestions, to help you leverage some of the techniques to make your life easier. Even if you don’t feel you can, or want to, adopt XP as a whole, I’m betting there will be at least a couple of tips in this book which you will find useful.