Dealwithit by Christoffer Hauthorn Boisen

Deal With It Attitude for Coders Gavin Davies This book is for sale at http://leanpub.com/dealwithit This version was published on 2012-11-30 This is a Leanpub book. Leanpub helps authors to self-publish in-progress ebooks. We call this idea Lean Publishing. To learn more about Lean Publishing, go to http://leanpub.com/manifesto. To learn more about Leanpub, go to http://leanpub.com.

ÂŠ2012 Leanpub

Tweet This Book! Please help Gavin Davies by spreading the word about this book on Twitter! The suggested hashtag for this book is #attitudeforcoders. Find out what other people are saying about the book by clicking on this link to search for this hashtag on Twitter: https://twitter.com/search/#attitudeforcoders

Contents Dedication

Introduction

What’s all this about?

iii

Who is this guy?

Part 1: Overall attitude

Attitude over Aptitude?

Be courageous in ignorance

Be professional

Be resourceful

Don’t try to prove how smart you are

Don’t worry about being the brightest

Open Source your knowledge

CONTENTS

Seek to build community

Take the initiative

Donâ&#x20AC;&#x2122;t be precious!

Do it scared if you have to

Part 2: Tools, learning and technique

Have respect for books

Always pressure test

Think testing

Automate like your name was Dan

Performance matters

Measure, donâ&#x20AC;&#x2122;t guess

Get your tools right

Build a solid technical foundation

Be deployment minded

CONTENTS

Choose your libraries carefully

No source is set in stone

Learn to spot antipatterns

Donâ&#x20AC;&#x2122;t be tied to a single technology

Part 3: Wisdom for the long haul

Have achievable goals

Accept that failure happens

Treat people as people

Take care of yourself

Beware burnout

Dealing with burnout

One thing at a time

Part 4: Communication is key

Documentation is communication!

CONTENTS

No unnecessary docs

Keep emails short

“Just” is the worst word

Social problems can’t be solved with tech

Dealing with suits

Beware meetingitis

Part 5: Some closing advice

Never stop learning

Keep it in perspective

Who do you think you are telling me all this?!

Signing off

Acknowledgements

Dedication For Mum and Gail, teachers to the core

Introduction “Deal With It.” That’s a strong phrase. One interpretation is “here’s how it is, you have to put up with it”. It can be a bratty, unilateral, condescending, dismissive statement. Another interpretation is “let’s cope with things how they are, but work hard to change them for the better”. An encompassing, generous statement. This book is about choosing how you, as a software developer, deal with our industry and your day-to-day work. “Most of the time, it’s your thinking, not your talent, that holds you back.” - Rick Warren¹

¹https://twitter.com/RickWarren

What’s all this about? I’ve been working in software for a long time, and I wanted to write the book I wished I’d had when I started out. I wanted to encourage myself, and encourage others, and pass on the development experience of a decade and a half. That might sound like a lot to you, or it might not! There are a lot of technical programming books, this isn’t one of those. I wanted to write a book on the attitude side of things, which is just as important to being successful as a coder - in terms of being good to work with, a proper attitude is absolutely vital! I had long wanted to do this, but felt a book was a lot to take on. I mentioned this, and one of my colleagues, Rod, responded “nah, you can just sling together 60 pages these days and call it ‘the good parts’!” So here it is - the good parts of what I know! To borrow a phrase from Zane Lowe - this is our book. Mine and yours. It should get you thinking, give you ideas, perhaps help you out of a rut. You might not agree with everything that I say. I’d be worried if you did! This book is in short chapters. One thing at a time. Isn’t that the best way to do things?

iii

Who is this guy? I’m just some guy, you know? If we’re going to spend some time together, though, I’ll fill you in on what I do. My job title is “Principal Software Developer”. I work at Box UK, a software consultancy I’ve been at for over 5 years, during which time we’ve grown from about 22 staff to over 75. We take on all sorts of projects; streaming media, CMS builds, framework development, throwing huge hunks of data around, responsive websites, mobile, bespoke apps… Before Box UK, I worked mostly for small outfits, although I had a brief stint at a large company that felt rather too Dilbert for comfort. Day-to-day, I operate as developer-in-test and quality evangelist. I work with devs to improve their skills. I perform code reviews. I give training. I will automate anything. Vitally, I write code. “Can this guy teach me anything?” you may ask. Perhaps I can’t - I doubt I’m any smarter than you - but this is our book, and as you hold it, I hope you take space to think, to let your mind wander, to reach your own ideas. That’s what books do for me. That is why I love them so.

Part 1: Overall attitude

Attitude over Aptitude? “We Are All Fallen Creatures and All Very Hard To Live With” C.S. Lewis So I’ve told you a bit about me, but it’s just as important who you are. This may sound strong, but I feel attitude is as important as aptitude. I’ve had a lot of very clever colleagues - some of whom I just couldn’t work well with. I’m hard to work with too, but there are some things that the greatest people I’ve worked with had in common. 1. Open to unfamiliar approaches 2. Challenges hirself to develop new skills 3. Willing to share knowledge An archetype that you will likely encounter in your career is the supersmart computer scientist who works in his own isolated silo and spends a lot of time sneering at those who know less. No matter how smart Mr Sneer is, he can be a detriment to morale. Don’t let this kind of person put you off in your quest to improve, or drag you down to his level. This book is about dealing with the challenges of the software industry. My belief is that if you get your attitude right, and be willing to learn, grow and share, then the knowledge will come.

Be courageous in ignorance “Endeavour to be the dumbest guy in the room” - unknown You will be ignorant at some points in your career. That’s OK. I’ve stopped trying to hide my ignorance, I will ask questions. You just need a little courage. At Uni in ‘98, I had a fellow joint honours student in my yeargroup. Sam was extremely sharp, but being joint honours, didn’t always have the cross-knowledge the straight CS guys had. Every lecture, Sam would ask a question. Sometimes, one of the hardcore techie guys would groan, eager to leave, but Sam would persist unabashed. He always got his answer, and you know what? There was invariably someone else who needed that answer and it was often a nervous young Gavin Davies. I had the pleasure of working with him on a group project and his willingness to ask questions taught me a lot about professionalism. It’s not about hiding what you don’t know. It’s about having the courage and determination to get it right. You may also be helping others. Choose to be brave.

Be professional Some people don’t understand the difference between being professional and being corporate. Perhaps I don’t understand it either, but here is my take. Being professional is doing a good job to the best of your ability. It’s communicating well. It’s being honest and friendly and efficient. Being professional does not imply wearing a suit and displaying no personality or sense of humour. In fact, lack of humour makes communication ineffective, because people will disengage. Most of the most professional people I know don’t often rock up to work in sharp suits (except you, Mr Knight!). Rather, they show up with sharp skills, a great attitude, a willingness to learn and share and an enthusiasm for their work that drives them on. Putting jokes in your docs or wearing a band t-shirt is not unprofessional. If you are sloppy, slapdash, condescending, know-it-all, non-communicative, or rude (particularly to clients) - THAT is unprofessional. Being the best version of yourself in your workspace that you can possibly be is professionalism. That’s my take.

Be resourceful Our jobs can be daunting, I know this. I have to do it scared most of the time. One way to truly annoy me, though, is a dev who doesn’t try at all. Imagine a dev, let’s call him Montague Marwood. Monty starts work at a new company and is on your team. You show him the ropes and give him training on the application you’re working on. You direct him to training materials and documentation and give him a simple starter problem to solve. Two days later, Monty hasn’t made a single commit. You ask how he’s doing and Monty says “oh, I didn’t really understand feature x so I haven’t really done anything.” You could argue that you could have perhaps pair programmed with Monty, or the problem it should have come up in daily standups. What I’m trying to illustrate, though, is that some people, if they can’t solve a problem, will just kind of sit there and not even mention it. Please don’t be like this. Never just sit there with a problem doing nothing. You must be resourceful. Talk to your teammates. Study the docs. Run the unit tests. Ask questions on your IRC channels. Browse the code. Communicate! It’s OK to hit roadblocks, but you MUST actively attempt to solve the problem!

Don’t try to prove how smart you are “Be kind, for everyone you meet is fighting a hard battle” - John Watson One of the most tedious things a dev can do is constantly try to prove hirself to be smarter than hir peers. There is a marked difference between enthusiasm for the subject and conceited arrogance. If one of your peers asks you a question, your attitude should be “how can I help my peer?”, not “here is an opportunity to show how clever I am.” If are not careful, you can leave others feeling belittled and discouraged. Answer the question without saying things like “don’t you even know THAT?!” or “that’s obvious!”. You want to foster an atmosphere of communication, and you will not do that if you are seen to look down on others. Remember, you all have to work together. Everyone has strengths and weaknesses and there will always be those whose abilities in software seem almost otherworldy in their comprehensiveness. If this is you, then consider your response carefully. Always help others to grow where you can.

Don’t worry about being the brightest “I trust that I am not more dense than my neighbors, but I was always oppressed with a sense of my own stupidity in my dealings with Sherlock Holmes” - Arthur Conan-Doyle I know how Watson must have felt. I worked for two years next to a guy who was so incredibly capable that I would go home from work feeling that I knew literally nothing. I found it morale crushing when I would spend hours at a problem only to find he could solve it in ten minutes. This was largely a problem with my attitude. It took me a long time to be OK with this. I was used to being amongst the sharpest, but in the wider world, I had to accept that some people were simply cleverer than me, and that’s OK. There will be, in most organisations, exceptional developers. There is an often-quoted metric from Fred Brooks’ classic book “The Mythical Man Month” that some some developers are 10 times more productive than others, but I think this can be taken out of context. We don’t all have to be Linus “I’m Clever” Knuth to do a good job and make a good living! (bonus points if you get the movie reference there ;-)) Learn all you can from the super-exceptional guys. As I said earlier, don’t compete. Encourage, learn. Don’t beat yourself up. For me, this has been perhaps the hardest lesson, and some days I’m still learning it.

Open Source your knowledge “I’m doing a free operating system just a hobby, won’t be big and professional like gnu for 386 (486) AT clones.” - Linus Torvalds Open source is far more than being able to grab a few libraries and pretend you’ve read their source code; it’s a way of thinking. I’m not saying you have to go “full Stallman” (although I have an immense respect for him), but here is how I see it. Jealously guarding your knowledge and skills is an insecure thing to do; if you feel that you are in competition with your co-workers, then something is wrong in your attitude. If you are willing to give your knowledge away freely, you can actually encourage yourself as well as those you teach. At Box UK, we started doing tech talks about 4 years ago. This was inspired by something Joel Spolsky said about Brown Bag lunches. It is simply a meeting where one person tells the others about something s/he has learned - I’ve given tech talks on Require.js, clean code, refactoring and many other topics. Starting with a core of devs, many people in the company now participate in tech talks, so we constantly benefit from one another’s knowledge. Good software companies want people who are brave enough to open source their knowledge. Sharing your knowledge pushes you to really know what you’re talking about!

Seek to build community “No Man Is An Island” - John Donne Me and some of the boys (sorry grammar folk, I couldn’t bear to say that in a correct manner, it just felt alien!) put on a monthly event in Cardiff called Unified Diff². At the very first event, Carey Hiles spoke about the dangers of being a lone developer. I was a lone developer - or close to it - for the early half of what I guess you’d call my career. I fell into bad habits. I failed to learn what worked and what didn’t. I had no real understanding of scalability, source control, coding standards or teamwork until relatively late on. I read things online, but with nobody to discuss them with, only loosely understood them. Now, I am blessed with an abundance of community. Unified Diff puts me in with devs of all backgrounds. I work with over 30 devs now, and we share ideas in tech meetings, in pull requests, over IRC, from casual chats, and in our drywipe-walled “war rooms” as Carey calls them. If only I’d had this when I was 20 and starting out! You may not work for a large company. That’s OK. Make sure, though, that you regularly meet with devs, listen to podcasts, and get involved!

²http://unifieddifff.co.uk

Take the initiative “You must be the change you want to see in the world.” Mahatma Gandhi I occasionally hear people complain about their workplace, saying “oh, it’s OK for you, but we don’t have what you guys have at Box UK”. Well, we all worked hard to create that culture. Before complaining that other companies seem to have it better (grass is always greener, right?), consider what you can do in your workplace. Start small. Something like “link Tuesday” is a good way to get things moving - once a week, encourage people to share interesting and relevant developments. This can get people talking and moving forwards. Tech meetings work wonderfully for sharing knowledge. You could start doing them one lunchtime a month. If you don’t have Continuous Integration, at least set it up on an old PC or something. These are just some ideas - hopefully this book will help you to think of your own. The main point? Make it happen. You’ll seldom get anything handed to you on a plate, but with persistence, a good attitude and competent management, you can impact your culture.

Don’t be precious! “Programmers must fight the natural tendency to treat their programs as part of themselves” - Gerald Weinberg, The Psychology Of Computer Programming. Your source code is not you. Your knowledge or lack thereof is not you. If someone criticises your work - and they will - and many devs are extremely unsubtle - then don’t take it as an attack. Try to hear what they are saying. Yes, it will probably still hurt the first few times. If we are precious, though, we will never put our code out there for review. We’ll never have that courage. We will never gain the benefits of people reading our work, critiquing it, suggesting improvements. If we never give anything away, we never show our hand, then we are relying solely on our own knowledge and experience. Don’t hold too tightly onto your code. If you do, you may open your hands one day to find them empty after all. Be bold. Open source your work on Github or similar. Let people in. Work with people from the community we mentioned earlier. If you don’t, how are you going to improve?

Do it scared if you have to Adapted from a blog post I wrote for Box UK³ I feel out of my depth a lot of the time. You would be surprised how many senior software developers, if we were honest, would say the same thing. The younger guys seem to know all the latest technology and paradigms. The other senior guys seem to be so solid and consistent. If you’re anything like me, you’re a terrible self-critic and you often lack confidence. Well, on the whole I’ve done OK over the years despite my lack of faith in my own abilities. That’s because of one thing my mother always says to me that she got from Christian author Joyce Meyer: “Do it afraid.” I refuse to let fear rule me. If I don’t grok the technology I’m using, I’ll read up on it, experiment. I’ll progress in baby steps. I won’t let the black abyss of what I do not know swallow me whole - instead, I’ll grab a torch and explore. I’ll cut the problem down. I’ll ask for help. I’ll go for a walk. Don’t let fear hold you back: can you do the same few things for the rest of your career? Probably not, technology and culture move on. Don’t let fear hold you back. Do it afraid.

³http://www.boxuk.com/blog/software-development-doing-it-scared/

Part 2: Tools, learning and technique

Have respect for books “No matter how busy you may think you are, you must find time for reading, or surrender yourself to self-chosen ignorance.” Confucius A number of years ago, I wrote a blog post entitled “Coders! Y U no read books?!”⁴ and I stand by it today. Books are a wonderful thing, and just because we work online doesn’t mean we should limit ourselves to solely using online tutorials, StackOverflow and videos for our development. I include e-books in this, of course, I’m not that backward! A book allows you to sit and soak in your own thoughts. The gradual, expansive experience of reading gives me most of my best ideas. I have solved innumerable technical problems whilst lying in a good hot bath reading something by Kent Beck or Martin Fowler. Don’t try to read too fast or too much. The important thing is the space it gives you. If your mind wanders, let it wander, inspired by the text. I found that the book “Pragmatic Thinking and Learning” by Andy Hunt was absolutely marvellous for giving me ideas. I’d read a paragraph and it would unlock whole trains of thought that I lazily sauntered down. A joyous experience!

⁴http://www.boxuk.com/blog/coders-y-u-no-read-books

Always pressure test “You must move, have a sense of timing, and progressive resistance that resembles what you would receive on the street.. That’s Aliveness” - Matt Thornton, Straight Blast Gym⁵ In November 1993, several people got exposed. At UFC #1, fighters from all around the world were defeated with apparent ease by a Brazilian Jiu-Jitsu (BJJ) guy named Royce Gracie. Where many martial artists dubbed their styles “too deadly” to spar and pressure test in training, the Gracies would travel around testing their style against whoever would take them on. Unlike many styles, BJJ practitioners trained against resistant, non-compliant partners. Therefore, Gracie’s techniques work when put to the test. The same is true of software development. You can talk all you want, but you must pressure test your software. Unit tests should be part of a project from day one. Measure, don’t guess, at load testing. Run automated vulnerability scanners. Use coding standards checkers and mess detectors. YOU want to be the one to know the weaknesses of your “style”, not some script kiddy. Make it part of your build loop if you can. Don’t tolerate vague, static, esoteric “grab my wrist” nonsense. Pressure test all that you do.

⁵http://www.straightblastgym.com/interview01.htm

Think testing Here are 7 reasons to unit test that I gave in a blog post Pragmatic Code Coverage⁶: 1. To answer the question “does the code do what I think it does?” 2. To break a problem up 3. To encourage good design and loose coupling (untestable code is bad code!) 4. To write exploratory code 5. To show your working and provide documentation (e.g. testdox format) 6. To prevent regressions 7. … and because otherwise you’re being a cowboy! People talk about BDD vs TDD like they were in opposition. Here’s my take. TDD says; “this program does what I, the developer, wrote it to do.” BDD says; “this program does what the customer wants it to do.” Both are useful, and you must write tests. Be pragmatic, though. If a region of code really is untestable and isn’t just badly factored, then annotate it with @codeCoverageIgnore or whatever your framework supports. Tell other developers what your code should do. Describe your code by writing descriptive tests. ⁶http://www.boxuk.com/blog/pragmatic-code-coverage/

Automate like your name was Dan “If it doesn’t have a job on Jenkins, it doesn’t exist” - Gavin Davies Sorry to quote myself in this chapter, I know that’s incredibly vain of me but I couldn’t find a better one! Every project should have some form of CI. Are you on Github? Then you can probably use Travis. Some kind of build is essential. It should be a case of running a single Ant, Rake, Phing, Nant, Leiningen or WHATEVER script. Your build should do at least the following: 1. Run unit tests 2. Check coding standards adherence 3. Static analysis/linting Additionally, remember the old phrase “once is funny, twice is silly, three times is a smack in the chops”? Well, my version is “once is manual, twice is a bash script, three times is, I dunno, Puppet or a Perl script or something, y’know, whatever’s relevant”. You can automate a lot of things. At Box UK we have a phrase for mindless, repetitive work. We call it “troll work” and will automate our way around it in a heartbeat.

Performance matters “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil” - Donald Knuth I’d say this quote is taken out of context about 97% of the time! People often just use it to dismiss making optimisations in early phases, and even worse, to dismiss optimising at all! What Knuth is actually talking about is the difference between, say, the following lines of PHP: 1 2

print "this is foo"; echo 'this is foo';

The latter is a tiny amount more efficient, but that kind of microoptimisation is harmful if it absorbs a lot of developer time for no real return. BUT YOU MUST CONSIDER PERFORMANCE. Benchmark your system as soon as possible. For example, “how many requests a second can it serve”. Every commit should not worsen these numbers, and should improve them if possible. Keep a log of performance stats and work to improve it by eliminating bottlenecks using REAL data, not guesswork. Profiling is another vital tool. Measure, don’t guess.

Measure, don’t guess You should know how many requests per second your application can handle on given hardware, or how many frames per second your game gets on the Xbox, or that you get an A-grade in YSlow. You can run CLOC in your Continuous Integration loop to give you stats on your project size. You can measure cyclomatic complexity programmatically. Metrics are useful. Measure things, don’t just use guesswork and “intuition”. If you say to a project manager “I spent 4 hours improving performance” and you don’t give any figures, then you might as well have been playing Quake Live! It doesn’t have to be hard. There are plenty of tools. Have a look around for something that will work for you. Get into the habit of providing figures whenever possible.

Get your tools right “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” - Abraham Lincoln The Pragmatic Programmer has an excellent chapter on this, which I will not regurgitate here. Don’t get caught up with “Analysis Paralysis”, though. Craig Marvelley talks about this pitfall on the Box UK blog⁷. At some point, you have to make a decision and go with something! A little upfront effort can often give a lot of return, but it can be taken too far! Experience, pressure, and colleague knowledge should all help you know when the point is to stop working on tools and start cracking on with the product! I’d say the essential tools to have set up early are: • • • • •

Know your editor! Communications channels for devs and the client Bug tracker Source control Continuous Integration running unit tests and coding standards as a minimum • Automated deployment - automated as far as possible, anyway!

⁷http://www.boxuk.com/blog/analysis-paralysis-and-the-editor

Build a solid technical foundation The latest and greatest is often transient. Say 4 programming languages come out in a month. How do you know which one to learn? SQL or schemaless databases? Which of the 55 frameworks to pick? All of them? None? Bunch of shell scripts and hope?

Don’t panic :-) . You can build up transferrable knowledge. University didn’t give me much in the way of practical skills, but it did give me a decent understanding of the theoretical underpinnings of computation. If you can handle Knuth, read Knuth! Even if you’re like me and most of his stuff is a bit much for you maths-wise, it’s good to understand things like pointers, data structures, memory management. Knowing these things is transferrable. It won’t go out of date any time soon. Knowing how to lay out code comes with time. You can’t know everything. Just make sure that whatever you’re building, it’s underpinned with at least a fairly solid understanding of the underpinnings of computing.

Be deployment minded Always keep in mind where your code is going to end up. Have a runbook (as mentioned elsewhere in this book). Test it on the target platform. Try to work on a representative environment - a tool like Vagrant can be a massive help here. How are you going to manage assets? If you don’t consider deployment until it’s time to release, you might hit some problems. It’s a good thing to get deployment in place early, and as automated as possible! If you have an operations team, make sure relationships with them are good and that your work is as easy as possible to deploy. Involve operations as early as possible - give them an idea of what you’re using (if you have a lot of freedom to pick tech!) and listen to what they’ve got to say. In my experience, these guys have a lot of useful input and several times I’ve been talked out of using whizz-bang new technology in favour of something reliable and stable - and that is a good thing! Of course, sometimes the shiny new tech is the right fit for a project, but that decision should be made as a business, not on the whim of a coder! It’s a hard one - you want to keep your skills fresh, but any tech you use absolutely must be supportable within reason, with good resources available if anything goes wrong.

Choose your libraries carefully Adapted from a blog post I wrote for boxuk.com⁸ These days, most of us build on the top of other people’s work, in the form of libraries, modules and frameworks. This gives us a massive head start - reinventing the wheel is seldom an option. Be careful what you pick though. Ask yourself: 1. 2. 3. 4. 5. 6.

Does the license allow me to use it? Is it battle hardened? Does it perform well? Is it open source? Is the project still active? Does it have a good reputation?

If the answer to any of these is “no”, then the library may not be a good choice. You don’t always have to use the very latest and greatest cutting edge stuff. That can be useful for personal projects and unusual problems, but if it’s getting deployed to thousands of users, or if it has to have high uptime, or if it’s hard to deploy or update like a mobile app, then tried-and-tested is the wiser option. Don’t let neophile tendencies cloud your judgement!

⁸http://www.boxuk.com/blog/trusting-the-libraries-you-use

No source is set in stone “If you’re afraid to change something it is clearly poorly designed” - Martin Fowler At some point, if you haven’t already, you’ll inherit a legacy system - some old beastie that no-one wants to look after any more. I’ve had several of these over my working life. It’s usually a mistake to totally rewrite a working system - it will take far longer than you think. Use refactoring to gradually improve the design. Every commit you make should make the product better. You may wonder; “why bother?” Well, your attitude should be that you don’t want the next maintainer of this project to suffer so much as you did! Start small. Respect working systems, but do not shy away from improving them. Get a second opinion where you’re not sure, and ALWAYS use some manner of unit test when refactoring. Then, your changes not only improve the system design and reducing technical debt, but also add to the application’s selfdescription. Refactoring is a crucial technique. I strongly recommend Martin Fowler’s book on the subject. It gave me hope and heart to maintain and improve several really bad systems.

Learn to spot antipatterns Based on a blog post I wrote for Box UK⁹ Antipatterns are the antithesis of a design pattern - they are definable ways of making things horrible and terrible! Antipatterns are to software what being stuck in a lift with Jar Jar Binks is to personal space - invasive, unpleasant and downright frustrating. The good news is that learning to spot this antipatterns can help you avoid creating them yourself, and sometimes you can refactor your way out if you get stitched up with one! I’d suggest reading up on the following to get rolling with the concept: • • • • •

Golden Hammer Not Invented Here Continuous Obsolescence Ball Of Mud Wild Wild West

⁹http://www.boxuk.com/blog/web-development-antipatterns

Don’t be tied to a single technology “The best developers are always broadening their horizons and adding to their arsenal by exploring new tools and techniques on a regular basis.” - Carey Hiles - Head of Development, Box UK¹⁰ Using a single technology can make you narrow minded. I’ve met people who are so locked into, say, the .Net or Java stacks that anything else seems terrifying to them. Well, if you want to stay on that stack for your whole career, I guess those technologies aren’t going away. I’d still say, though, that a broader perspective is beneficial. Explore other paradigms - if you’re an Object Oriented developer, look into Functional Programming. If you mostly do databases, have a go at programming with an ORM (Object Relational Mapper). It’s worth getting a feel for other things with an open mind - you’ll often find that you can get excellent perspective and insight by broadening your approach a little. I don’t think it’s bad to specialise. I do think, however, that part of being a good specialist is understanding the alternatives to your approach. Otherwise, you’ll be a hammer and everything will look like a nail.

¹⁰http://www.boxuk.com/blog/box-uk-technology-agnostic

Part 3: Wisdom for the long haul

Have achievable goals This is adapted from a longer entry on my personal blog¹¹ A long-term project can be hard work. It’s easy to lose sight of goals, and drift when it feels like actually DELIVERING something is simply out of sight, over the horizon. Then, suddenly, that intangible deadline begins to rocket towards you and a frenzied “crunch time” begins. This is one of the reasons devs people tend to work on their own projects outside of their day jobs - because these projects tend to be feel achievable, and the sense of progress is tangible. It’s greatly underestimated how much developer morale affects productivity. Unhappy devs will twiddle their thumbs and fiddle around with toy projects, sighing at the thought of another arduous day working on the “goal over the horizon”. That’s why agile - or any kind of iterative development - is helpful from a psychological standpoint. Short term goals are incredibly motivating because you have an achievable target. You aren’t trying to fit the universe into your headspace at once - you are instead working over a short period to reach a goal that remains in sight.

¹¹http://gavd.co.uk/2012/09/how-agile-can-keep-up-morale-on-long-termprojects/

Accept that failure happens “For though a righteous man falls seven times, he rises again” Solomon “Experience: that most brutal of teachers. But you learn.” - C.S. Lewis You’re going to get things wrong. You’re going to make mistakes. No matter how hard you try, no matter what best practises you follow, some day you’ll DROP DATABASE on a live server, or do what I did and accidentally email the text of Edgar Allen Poe’s “The Pit And The Pendulum” to several thousand users (oops!). Give yourself a break. For me, this is hard; I’m instinctively tough on myself, so if you’re wired like that then I know how it is. Think, though; “would I be so annoyed if one of my coworkers had made this mistake instead of me”? Try to put your mistakes into perspective. Definitely learn from them. Do all you can to put things in place to prevent mistakes happening again. It can be hard to come into the office the morning after a catastrophic screw-up. That’s a mark of a true professional, though. Get up, don’t give up! Know that we’ve all made mistakes. Forgive yourself, learn, grow and teach.

Treat people as people “Someone who is exceptional in their role is not just a little better than someone who is pretty good. They are 100 times better.” Mark Zuckerberg “You’ve been misled: If you wanted a job avoiding people, personal relationships - software development is not it.” - Bob Marshall¹² One of the most loathsome aspects of our industry is the casual reference to human beings as “resource”. There are two reasons why this is dangerous. Firstly, it is dehumanising. Each “resource” is a person with goals, hopes, aspirations, unique abilities and insecurities. Secondly, it is unprofessional and narrow minded. You’ve probably heard quotes like the one from Mark Zuckerberg above. People are not interchangeable. For example, if you put me on a web application project, I would probably do OK as I have a lot of experience there. If, however, you put me on a 3D triple-A gaming engine, I would be totally out of my depth. Try to see the strengths and weaknesses in all of your peers and work in a way that brings out the best in them.

¹²https://twitter.com/flowchainsensei

Take care of yourself Eating badly will make you feel exhausted. Lack of exercise will make you lethargic. Lack of sleep will make you straight up slow. As coders, we REALLY need balance in life, more than most! We spend hours a day sat in chairs coding. It’s vital to get out there, socialise, eat decent food, get exercise. Funnily enough, stepping away from the keyboard is where I often solve the hardest problems! I’ve so far been unsuccessful in convincing an employer to pay me overtime for the “genius idea I had in the bath last night” (OK so the rice pudding ice lollies were a flop), but seriously - letting your mind decompress, letting your body take over - that will help your mind to work! I recommend reading Andy Hunt’s “Pragmatic Thinking and Learning”, some fascinating stuff about cognition in there! Personal bugbear: please, guys, DON’T come in to work if you’re ill! We work in the software industry; most of us can dial in! Far from being heroic, dragging yourself in when you are ill is NOT “being a trooper”, it’s deeply unprofessional. Spreading a malady around the office will damage morale (as everyone has to hear you snuffling and coughing), and when it spreads, productivity will drop across the board. Be sensible - go to the doctor, rest up, look after yourself!

Beware burnout “Burnout: A debilitating psychological condition brought about by unrelieved work stress” - Veniga and Spradlcy Burnout is a real thing. There is nonsense in some software companies about working long hours, as if that’s what “working hard” means (sigh). The truth is that you can only put in long hours for so long, perhaps one week a month, and then you’ll burn out. I’ve overdone it and burned out several times, and it’s really not pretty OR productive. You will learn more and be more focused if you’re fresh. We all have to pull the occasional long shift, but no matter what the corporate culture, don’t be guilt tripped or bullied into working long hours as a matter of course. Studies show it’s not good for you or the business: I’ve heard people speculate that Apple could have released the Lisa months earlier if they hadn’t worked their engineers into the ground. Calmly and politely restate that you can work better if you remain fresh. If you have to, read studies on burnout to give yourself leverage. Also, make sure you eat well. I fight a constant battle against fizzy drink and chocolate addiction - I feel so much better and work much smarter when I’m on sushi and green tea!

Dealing with burnout Adapted from a blog post on my personal blog¹³ Burnout is SRS BIZNIZ in software, but if you DO get burned out, don’t worry - it’s not the end of the road! I’ve been through it several times and am still alive! We’ve all got a lot to do. Sometimes, we HAVE to take a lot on, because mortgages don’t pay themselves. It’s tough, especially if you live alone. This is why, to survive burnout, I recommend: 1. Keep trustworthy people close. Don’t alienate people when you’re busy. Don’t treat people as things. 2. Eat as well as you can. It’s so hard when you’re exhausted and you come home and would rather cry than cook for yourself, but just don’t sit down until you have something ready. 3. Take time out for yourself, to pray, meditate, read – whatever it is you do to get your mind right. 4. Don’t be too proud to ask for help. 5. Get away from it all if you can. Get some perspective. It’s often surprising how much the world DOESN’T fall apart without me – I’m certainly not indispensible! This may or may not help, but if you’re suffering burnout, know that if you can get some space, it will pass. Sometimes the right way is through, sometimes it is to first go back a little. ¹³http://gavd.co.uk/2012/10/recovery-from-burnout/

One thing at a time You can’t learn everything. You can’t even try to learn everything all at once. As I write this, my learning tasks on my personal Trello board include: 1. 2. 3. 4.

getting properly up to speed with Git use SSH a little better see if App.Mobi is as good for games as Steve says improve my C

This is too much. Therefore, I’m focusing heavily on Git at the moment - watching videos, talking to people, and I’m grasping it fairly well now. There is a lot to learn in the software game. You’ll never know it all. Don’t be afraid to chat to people, don’t be afraid to be wrong. Also, don’t assume other people are necessarily right. If you want to learn something, you have to read about it, watch it, talk about it, and vitally you absolutely must use it. Set a problem and solve it - but don’t try to take on too much at one time.

Part 4: Communication is key

Documentation is communication! When you pick up a project, it can be hard to even get it running. I’ve often been in the situation where I’ve checked out or cloned a repository and I have no idea how to use the application! There’s an old computer science term: the runbook. It’s kind of a retro term, but it works for me. I use “runbook” to mean a file that tells you how to use an application. Usage examples should always be in your documentation. Never be vague, be specific. Above all, in this age of ludicrously named libraries, your runbook should tell you precisely what the application actually does! Many Github projects are a good example of this; they should always have a file in the root called README.md, telling you how to test, use and extend the project. Try to bear in mind that others don’t have your knowledge. Get your colleagues to check your runbooks in the same way as they would code. It doesn’t have to be highly detailed, but it does have to get somebody going quickly. It’s the information you’d want if it was you.

No unnecessary docs We’ve looked at runbooks, so am I contradicting myself here? I don’t think so. If you’ll forgive me something of a “businessy” term, it’s all about ROI (Return On Investment) here. As are most things. Documentation reaches a point of diminishing return. Don’t try to specify things precisely that will change a lot - instead, focus on communicating the things that will remain fairly steady usually, the public interface. People can read your code if they want the details; written documentation should take the runbook approach from the previous chapter. Always ask yourself questions like: “is this going to change? Will anybody need to know this to use the system? Am I adding complexity or clarification?” If the documentation you were going to add can be served by simplifying the system, you may be better off spending the time in that way. Write documentation. Your project is NOT complete without it. Just be sensible about how far you go.

Keep emails short “Omit needless words.” - William Strunk I have spent far too many hours of my life composing emails that nobody read because they were too long. We call them “longcat emails”. Longcat is long! Nobody likes a wall of text. It’s hard to read. Give a short summary. Make your writing concise. Get your point across. If it’s an in-depth topic, it certainly belongs somewhere better - such as on a Wiki or in the runbook for a project. Perhaps all your email need say is “Hi guys, if you want to use the FooBar application, the docs are here”. Much like Excel, if you’re considering using an email, think; “is there a better way?”. An email is not easily indexable (unless you’re fortunate enough to have Google as your mail provider!). Be brief. Precise. Concise. Bullet points are your friend. information.

Use hypertext by linking to

You don’t like receiving long emails, so it’s safe to assume that others don’t either.

“Just” is the worst word Just - in the sense of “merely” - is my Least Favourite Word. Here’s an example:

Me: “I got a flatscreen TV at last! Anyone know a handyman who could mount it for me?” Dude#1: “You don’t need anyone else to do it, you just drill holes into the wall and (some jargon I didn’t understand)” . The “just” in Dude#1’s response was well-meaning, but it implied a large amount of implied knowledge. It also contained the implied assumption that my wall is structurally sound and suitable for mounting a TV stand - I honestly have no idea what I’m talking about and that’s probably clear! You see, I have absolutely no frame of reference for DIY - if it can’t be fixed with duct tape and violence, it can’t be fixed by me! Therefore, when someone on IRC asks “how do I cache this?” I would try NOT to say anything like “just use Varnish” or “just use Memcached”. Much more helpful is something like “have you tried Varnish?” or “could you use Memcached?” It’s just not on!

Social problems can’t be solved with tech Sometimes, you may encounter a problem in your business and think of a technology that might help. An extreme and ridiculous example - you think employees are wasting time, so you start automatically tracking when they’re not typing. Think carefully before you do, though - some problems are due to factors like the culture of the workplace, the attitude of workers, the way management treats staff. In fact, imposing technical restrictions should be a last resort. Sometimes it’s tempting to use some technology or other to solve a problem, when really, it’s training, communication and respect that will make the problem go away. Don’t try to automate people. Try to inspire them.

Dealing with suits OK I’ll admit - the title of this chapter is a trap! . We coders have a tendency to think we could do everyone else’s job better than they could. Surely, we could manage this project better. Of course, we could have the network running smoother. Sell more copies of the product? No problem! That’s what we tend to think sometimes, anyway! It’s not necessarily true. Also, we often belittle people by calling them “suits” or “drones”, which is just as dehumanising as a coder being referred to as a “resource”. People in other roles have a whole set of pressures that are different to ours. In the same way as more business-oriented people may not understand how much of a setback being interrupted from “deep hack” mode is, how that can lose hours of productivity, many coders do not understand the pressures of dealing with clients. What is more useful than sighing, eye rolling and belittling people in other roles is trying to communicate your pressures, and trying to understand their pressures. We might not get through to them, they might not get through to us, but let’s at least try to collaborate.

Beware meetingitis You gotta have some meetings - they’re one of our main methods of communication! Often, a single face-to-face can be worth weeks of email dialogue. If, however, a coder spends all of hir time in meetings, something is definitely awry. Short meetings are better than long ones - my attention span is between 20 and 40 minutes, depending on subject matter! That said, ANY meeting at all is disruptive - don’t let anyone fool you; if you have to go into a meeting, you lose your working context - the variables, patterns and tasks in your head. From what I’ve read, that takes 20 to 40 minutes to get back. The number and length of meetings we attend is often out of our hands, but here are my tips: 1. Be positive about meetings. Within reason, meetings are a good thing. 2. Keep meetings brief. More than an hour and you’re probably rambling. 3. Stay on-topic. Meetings can waste massive amounts of time otherwise! 4. Limit meetings if you can. More than 2 meetings a day is incredibly destructive to coder productivity. 5. Take away actions. Don’t just sit there passively! 6. Make sure your line manager is aware that the impact of a meeting also includes context switching. Meetings are essential to productivity, but in themselves, they are NOT productivity! Be smart and proactive about them. 42

Part 5: Some closing advice

Never stop learning “Unless you are continually improving your skills, you’re quickly becoming irrelevant. And when you’re irrelevant, you’re no longer credible.” - Stephen Covey In our industry, perhaps more than any other, we have to keep improving. As coders, we have never “arrived”. Our skills are never good enough. That’s pretty difficult to accept sometimes. It’s tempting to believe that some day, I will be a “complete” coder. Not so! It’s not achievable. What IS achievable, however, is to be better than yesterday. Therefore, an attitude of continual, humble improvement will stand us in good stead. This is where community is particularly important. Being around people with different skills to us is really helpful. Other languages, paradigms, ways of doing testing, patterns, deployment methods, automation and virtualisation techniques… Don’t sweat becoming “perfect”. Simply keep learning, and have the humility to never make out that you’ve achieved programming greatness!

Keep it in perspective “What good is it for a man to gain the whole world, yet forfeit his soul?” - Jesus Christ Working in software can seem all-consuming. I’ve had months where I’ve worked up to 14 hours a day, up to 7 days a week. I would never encourage this; it’s totally unproductive if nothing else. We can be obsessive types. What I said in the chapter about viewing people as people, though, that extends to you as well. If we don’t get any downtime, our work actually suffers. Avoid working from home if you can; there is then no psychological disconnect from “work mode”. If you’re a freelancer, it’s worth checking out a collaborative workspace such as Cardiff’s IndyCube¹⁴ - this is a great idea to help you be in community even as a sole trader. Family and friends are hugely important. It is healthy to engage with the wider community. Keeping fit is good for the whole person. Don’t let the job take what makes you unique away from you. Don’t let the job totally define you. Sometimes, the most professional thing you can say is “I have done my best, and I need to take care of my own needs” - if you do not rest and play, how can you work? History’s wisest people have all taken time out.

¹⁴http://indycube.com/

Who do you think you are telling me all this?! “I don’t mean to say that I have already achieved these things…” - Paul of Tarsus Well, I’ve given a lot of advice! So I guess this is all stuff I’m doing, is it? Umm… Well, on a good day, yes! A lot of this is based on what works for me. I’m far from perfect, though. I’m appalling in the mornings - it’s scarcely worth talking to me before 10:30am! Some days, I find conversation a real effort. I have quite pronounced ups and down in mood. I, like many coders, have strong ideas on a lot of topics and have to try to remember not to steamroller over other people’s perspectives. I can get insecure when people are clearly smarter, more balanced, or better communicators than I am. A lot of this book is written with myself in mind, to encourage myself, and I hope that some of the advice I’ve given is helpful to you. Perhaps me being honest about my weaknesses is helpful to you too! “It is not important to be better than someone else, but to be better than yesterday” - Jigoro Kano, founder of Judo

Signing off I decided I would write this book to be small, concise, and direct - I wanted this book to be as readable as possible. I hope that you enjoyed it! I wrote on 8.5” pages in Google docs with 2” margins using 14pt Arial to restrict me to columns of about 45 characters to encourage me to be concise. I then exported to HTML and imported into Leanpub and continued to work on it in the Markdown format. I wanted each page to stand alone, to get a single point across, and to have a quote or a story. I wanted each page to be something you could hand to a co-worker that they could read in a minute or so and hand back to you. Hopefully you’ve found something encouraging in here. Get out there and do it! If you have at least some aptitude and your attitude is right, then you can improve, and find your work more satisfying. You can impact your culture positively. You can be a good example to yourself and others. Be honest. Be brave. Be yourself! “Courage is not simply one of the virtues but the form of every virtue at the testing point “ - C.S. Lewis

Acknowledgements A huge thanks to Dayle Rees¹⁵ for the encouragement in writing this book, and not least of all, for designing the front cover! Thanks also to his lady Emma for allowing me to use her awesome cover photo - that little capuchin’s face is priceless! Thanks to Box UK¹⁶ for over 5 years of employing me! I’ve never worked anywhere where there’s so much opportunity for innovation and development. Thanks to Stu, Carey and Benno for having a read through and sanity checking the book! Thanks to my girl Annie, I love you! Big up Warren, Carey, Craig and Rod - team Unified Diff¹⁷! Hold tight Woodville Baptist Church¹⁸! Easy the City Arms, Cardiff’s best pub!

¹⁵http://daylerees.com/ ¹⁶http://www.boxuk.com/ ¹⁷http://unifieddiff.co.uk/ ¹⁸http://www.woodybap.org.uk/