Human Interaction, Books »

[7 Oct 2014 | 123 Comments]

From time to time I like to look back and see what I have learnt over the year. I have just finished a role which has tested my human relation skills more than my technical skills. As always I look to other peoples previous experience to learn from, books being one of the best sources of information. I’ll quickly go through my reading list this year which others might find useful.

Crucial Conversations – This has probably been the most valuable book to me. It taught me techniques to handle those tough conversations which can be pivotal in dictating future events. I’m not saying I’m perfect at this but at least I am much better at it than I used to be.

Start with Why – This was a great read and made me re-evaluate how I should frame the work that I ask people to do. Inspiring people to do their best work is hard. Giving purpose to the work people do is truly inspiring and when people have done that for me I have felt my happiest. By using the techniques in this book I hope to be able to do the same for others in the future.

Lead with a Story – This was an interesting book and re-enforce the concepts in ‘Start with Why’. Story telling is a very powerful tool but not something that I have previously used to good effect.

Good Strategy / Bad Strategy – This has brought clarity to my bigger picture thinking. Knowing how to create the ‘kernel’ of a strategy (Diagnose the problem, set a guiding principle, define proximate goals) has been really useful in organising the things I work on.

The ONE Thing – This book showed the power of focus, to pick and achieve one thing at a time to do some truly amazing things. I would read this in conjunction with ‘Good Strategy / Bad Strategy’ as it aligns closely with picking ‘proximate goals’ to achieve.

Influencer – This book is filled with techniques to identify ‘vital behaviours’ and ways they can be changed to get positive results. This ties together a number of the other books, such as ‘Start with Why’ where inspiring people with things of intrinsic value is more powerful than essentially rewarding people with traditional ‘bonus’ schemes.

YES! – This is a very interesting book on the 50  things that make a big difference when you try to get someone to say yes. It is a good read and has some real nuggets of information in it. Such as the dangers of using negative social proof in a marketing campaign to how to use a ‘compromise’ product to drive sales.

The Tipping Point – This book looks at examples of how products ‘tipped’ to provide massive growth. It looks closely at the law of diffusion when trying to get your message out to the market.

The 4-Hour Work Week – This grabbed my attention as I has good techniques in how to create some ‘passive income’ streams which require little attention from day to day. It has some great ideas on how to live a fulfilling life with all the extra time that you would then have.

How to Win Friend & Influence People – This is the classic human relations book. This thing is it all seems so obvious. Basically respect people you deal with, find common things you appreciate, listen to what people have to say. It was very useful to have all these things re-enforced when reading this book.

Steve Jobs – This biography of Steve Jobs was great. As a techie I was wonderful to find out more of the history of my industry. Steve had an amazing life and it was interesting to see how he inspired people, which essentially was straight out of ‘Start with Why’. However he could have probably done with reading ‘Crucial Conversations’.

Books, Software Developement, coding »

[1 Feb 2014 | 198 Comments]

I am currently pulling together various materials I have found useful over the years to create some short reference materials for software developers I am managing. This is just a quick reference list of the books that I have found very useful in shaping my opinions on the practical implementation of software development.

Clean Code – A handbook of agile software craftsmanship

This book gives detailed guidance on how to write software that is easy to read and maintain in the future by following S.O.L.I.D coding principles. It challenges many long held beliefs about how software should be written with well-reasoned arguments.

Refactoring – Improving the design of existing code

This is ‘the’ book to refer to when you want to change the design of existing code whilst not changing its behaviour. By following these methods is it possible to keep the existing functionality whist reduce the size of the codebase making the code more maintainable and extensible in the future.

xUnit Test Patterns – Refactoring Test Code

This book provides tried and tested strategies and patterns for structuring automated unit tests. It explains in detail what has to be considered when writing tests to ensure that they do not become more of a burden for a software project than an asset.

Dependency Injection in .Net

This book provides in depth and very clear explanation of what Dependency Injection is and how it should be used to realise the benefits it provides. Whist the excellent examples are in .Net the content in this book applies equally to any object orientated programming language.

The Art of Unit Testing

This book provides practical examples of how to write Unit Tests in a maintainable way. This book combined with Dependency Injection in .Net provides excellent working examples of how to structure code in a testable way.

Working Effectively With Legacy Code – Michael Feathers

This book provides tried and tested strategies for maintaining legacy code that does not currently have automated test coverage. It describes the various problems that you will encounter when trying to maintain or change existing code and what has to be considered

Books, Employment, Software Developement »

[12 Oct 2012 | 307 Comments]

 

Why I’m writing this post

Over the last few years I have taken on a mentor / coaching type role from time to time for some up and coming software developers and I have found myself repeating my thoughts on what they should focus their energies on to progress their careers each time. People who know me know that I believe in DRY (Don’t Repeat Yourself) so I have decided to write this advice down for future reference, and perhaps some people I haven’t met yet will find it useful!

Do not rely on other people to look after you, you need to look after number 1

I think my most important bit of advice is for software developers to look after themselves. It can be very easy for enthusiastic developers to be worn down and loose any love for software development by the daily grind of work and especially when the effort (and often the extra-ordinary effort) they go to is not recognised or fully appreciated. We primarily owe a duty of care to ourselves and our career. The harsh reality is you cannot expect anyone else to do this for you. How do you do this?

Get a balanced approach to work and life, it’s ok to say ‘No’

The thing that I found that wears down enthusiastic developers more than anything is when they are too accommodating and put themselves under pressure by always saying yes (or ‘I’ll try’ which is always understood to be a ‘Yes’). I used to do this and one of the pivotal moments in my life was when I discovered the power of the word ‘No’.

As unbelievable as it might sound to some developers it is ok to say ‘No’ to development request on a project. You need to be reasonable and allow people to turn their request into a ‘Yes’. I like to have an easy to understand process in place for people to give me a requests. My personal choice is usually something based on a Scrum type approach. A simple backlog of items which people can add tasks to with a priority. I take a couple of weeks worth of  top priority tasks at a time and work on, delivery those new features then rinse and repeat.

Except for the obvious P1 issues, if people understand the process they seem happy to follow it, allowing you to say ‘No I can’t do that today but add it to the backlog and make the case it is more important than the other items and you can have it in ‘x weeks’. Its amazing how many ‘urgent’ issues dissolve into nothing after a few days.

For a good read about Balance and software development by Nathan Gloyn

Invest in your skills and set yearly goals

I like the saying ‘You cannot score without a goal’. The idea here is to spend time objectively and strategically thinking what would be good for your career and define some tasks to complete that will help you get there. Without doing this it is easy to end up in a Skills Drift, suddenly realising 5 years have passed and wondering ‘How did I end up here?’.

Setting yearly goals was the bane of my life when I had to do it in a formal structure at a consultancy but as a freelance with no corporation to hide behind all I’ve got are my skills to offer people to get work. I have to be and show I am at the top of the game in my field. I do this by taking some control of my own destiny and improve or gain relevant skills buy setting goals. DOING THIS IS REALLY IMPORTANT.

The practical application of this is to do this pick fun things to do, ‘I’ll learn a new programming language this year’, ‘I’ll complete a reading list of these <insert list here /> titles’, ‘I’ll attend x number of user group sessions’ (even better, give some presentations), ‘I’ll answer 10 stack overflow questions’, ‘I’ll write 6 blog posts’, ‘I’ll write a phone app with a Cloud backend’. These are the sorts of things I task myself with, they are cheap, interesting and packed full of learning value. These tasks should also help keep you interested in software development in general.

If you can get a budget to take a course and get a bit of paper with the word ‘Certified’ on it then go ahead but be aware that often they are sometimes not seen as a good indicator of your skills. See this post from Martin Fowler about the Certification Competence Correlation. 

Update your CV every year

This follows on from the previous point but make sure you update you CV every year. I found when I had nothing to add to it after a year it was obvious if my skills were stagnating and I was entering a Skills Drift. When this happens try to change this by talking to your manager for more training or something new to do. This might not work so. The saying i read in Jeff Atwood’s book Effective Programming: More Than Writing Code  ‘Try to change your company otherwise change your company’ applies here.

Write Clean Code

Any code you write will be read many, many, many times in its lifetime. So please try and make you code easy to read and understand. This does not mean just adding comments as this is generally a sign that the code is bad and not readable on its own (Martin Fowler calls comments ‘deodorant for bad (smelly) code’) .

Clean Code should be S.O.L.I.D so it is highly cohesive, loosely coupled, well named, easy to test (with tests please) making it easier and and safe to change sometime in the future.

My favourite resource and inspiration for explaining clean code is ‘Uncle Bob’. His style is quite zany but the message is very important and based in decades of experience in writing code. http://www.cleancoders.com/ 

Software development show be seen as a craft and there is a growing movement to make this a more mainstream idea and improve the quality of software development. http://manifesto.softwarecraftsmanship.org/ has lot of interesting information on the subject.

Admit when you don’t know

One thing that screams ‘inexperienced programmer’ is when they never say ‘I don’t know’ or even worse is when they do things and make statements which are based on obviously flawed assumptions of how things work and they see it as failure if they need to concede they were wrong. I recognise a good experienced developer or someone who is open to new or better ways of doing things as someone who is quick to identify the gaps in their knowledge and question what they think they know. When they are not sure (having evidence / experience to backup their argument) and are challenged will say ‘I’m not sure but I’ll find out’.

If I know you only have a few years experience I have a rough idea on how much stuff you probably know and expect to hear ‘How do you do that’ or ‘Is there a better way to do this’, ‘I don’t know how to do that’. While I expect this please don’t make me repeat the same advice or explanations over and over, it makes me feel you know value what I say. Make sure you learn from the things that people tell you.

Software development is like anything you learn, it takes many many years of practice and learning to become an expert in it. Research puts a time of about 10 years to become an expert in anything I’ve been doing this for over 10 years and am still learning and improving my skills every year, so perhaps I’m a slow learner! There are no short cuts, put in the hours, get experience be open to learning and you will get better.

Work smarter not harder

This follows on from the ‘Admit things when you don’t know’. If you find a task repetitive, long winded, error prone then it is probably worth the time to investigate if there is a more effective way to solve the problem. You might find that the answer is a revision to how you are currently solving the problem or perhaps there is a whole other technology or process that you might be able to use to make life easier.

Code generators, web frameworks, off the shelf products, open source projects, different languages, new software tools are examples of things that with some time invested in them can pay back multiples times over..

It is hard to do investigate and evaluate all these things on your own. To get an introduction to these things it is often better to hear from others who can summarize their field of expertise and if you find it interesting / relevant you can spend more time learning it it detail. See if you can go to some industry conferences, go to user groups, follow expert in you field on twitter, ask how other people are doing things on Stack Overflow, this is all part of you continuing self development. If you are lucky you might be working with someone who has done the research but see if you should still seek out new and improved ways of doing things. Once you get new knowledge see if you can share it with your peers in the industry.

Reading List

One of my favourite sources of quality information is books. Blogs and forums are useful for acute problems you need solved immediately but I find usually only treats the symptom of my lack of knowledge. Online media is great but there is a lot of shit on the Internet and sometimes it is hard to know when you stepped in it.

To treat the cause of you lack of knowledge you need to invest time in learning this missing bits of the jigsaw from a quality source that has been designed to tell the whole story. For me this is where books come in. The are significant bits of work contributed to by many experts in the field, with and army of people editing, reviewing and proof reading it to make sure it of a high standard. Books can describe the history and reasoning behind the designs and approaches of what you want to learn about. Below are some books which I would recommend to anyone wanting to do software development (there are more but this is what is on my Kindle at time of writing!).

Extra curricular activities

There is one thing that makes someone stand out as a developer who enjoys what they do an want to learn and that is what they do outside of the 9 to 5 job. So I encourage every developer to do something and it ties back to the early section of investing in your skills.

Create something

To really learn you need to do, so create something in your spare time to try out new ideas or technologies you’ve heard of. It’s the best way to get proper understanding of what things can do. Good types of projects are websites or mobile phone apps as they are easy to show people.

Sometimes I have found that my own projects are what keep me interested in programming when the work that pays the bills is dull and un-inspiring.

Get involved in an Open Source Project or two

If you want to get a springboard into learning a technology then get involved in an appropriate open source project. This is easier than ever with services like GitHub and CodePlex. The other great thing with doing this is that a lot of tool vendors, like JetBrains, will allow you to use their top of the range products for free on these projects.

This allows you to see how other people write code, structure their ideas and solve technical problems as well as getting feedback on how you write code, Don’t forget that there is no ‘correct’ approach and these projects with take an opinionated approached on how to tackle a problem. You might agree or disagree with the different approaches but make sure you keep your mind open to learn about the strengths and weaknesses of the different solutions.

Blog about things you have learnt

Get a blog going as somewhere to record things you learnt, did or think. You might not think that you have anything of interest to say on a blog, if that is true then nobody will read it but more than likely someone out there will appreciate your nuggets of information you throw out there. I’ve even found the answer to my own problem via Google on my own blog years after I  had originally solved the problem..

The thing I find about writing posts is that it forces you to really think about the subject, which really helps me understand the subject more. It also shows that you know stuff and is a good indication you are someone that likes to share and help others.

Attend community events

There are a lot of user groups / hack days going on all round the country. It is easy and cheap to attend these and you get to meet lots of like minded people. You never know who you might meet and learn from. The developers I’ve met at these events are of all abilities and backgrounds, from corporate IT workers, to start ups to people working on some of the biggest brand name websites in the UK.

In Summary

Being a developer can be one of the most rewarding and fun professions to be in. The industry is evolving so quickly it can sometimes feel a bit overwhelming but exciting at the same time.

There is a significant risk that you miss out on this excitement because the daily grid of un-inspiring projects using out dated technologies wears you down. You can easily become a battery hen 9 to 5 developer who looses the love they once had for the work. I have met a lot of these guys and it is a crying shame for our industry. As the country's economy evolves i can only see the demand for quality software developers will increase.

So my parting words are these:

Invest in yourself and give a little back to the industry and you will have a good chance of riding this growing technology wave to having a fulfilling career in software development.

Books, Software Developement »

[6 May 2008 | 0 Comments]

I have read a lot of books over the years which has given me a lot of knowledge and good practice on how to develop software.

Probably the most important book I've read has been More...