[{"_1":2,"_86":-5,"_87":-5},"loaderData",{"_3":4,"_38":-5,"_39":40,"_72":73,"_84":-5,"_85":-5},"root",{"_5":-5,"_6":-5,"_7":8,"_22":23,"_24":25,"_26":27,"_30":31,"_36":37},"user","shoppingCartId","shoppingCart",{"_9":10,"_11":12,"_13":14,"_15":16,"_17":18,"_19":20,"_21":14},"id","no-cart","count",0,"free",true,"updatedAt","2026-02-17T16:37:17.792Z","paymentGateway","STRIPE","cartItems",[],"loading","locale","en","readerTheme","system","constants",{"_28":29},"paypalClientId","AX53Cwz8jR6rVVzzZiZNWWXl0dGagi-GZrjG-S3Ua14E5nrKMn7DxDQ730O4R8LusLPp49ALn6aRVaEy","publishers",{"_32":33,"_34":35},"companies",[],"universities",[],"needsLocaleCookieSync",false,"routes/_store+/_readers+/read_/route","routes/_store+/_readers+/read_.$slug/route",{"_41":42,"_66":67,"_68":69,"_70":37,"_71":-7},"book",{"_43":44,"_45":46,"_47":-5,"_48":49,"_52":53,"_55":56,"_64":65},"title","Deal With It","slug","dealwithit","metaText","coverFeatured",{"_50":51},"url","https://d2sofvawe08yqg.cloudfront.net/dealwithit/s_featured?1620362770&1620362770","coverFeatured2x",{"_50":54},"https://d2sofvawe08yqg.cloudfront.net/dealwithit/s_featured2x?1620362770&1620362770","authors",[57],{"_9":58,"_59":60,"_5":61},"Z2lkOi8vbGVhbnB1Yi9TdG9yZTo6UHJvZHVjdEF1dGhvci8yOTAw","name","Gavin Davies",{"_62":63},"username","gavd","showReadLinkString","sample","parts",[],"toc",[],"isUnavailableOnline","unavailableMessage","routes/_store+/_readers+/read_.$slug.$chapterId/route",{"_43":44,"_74":-5,"_41":75,"_81":-5,"_82":83},"content",{"_76":77,"_43":44,"_47":-5,"_45":46,"_64":65,"_78":79,"_80":-5},"previewContent","

\n\n\n

Dedication

\n\n

For Mum and Gail,
\nteachers to the core

\n\n

Introduction

\n\n

“Deal With It.” That’s a strong phrase.

\n\n

One interpretation is “here’s how it is, you have to put up with it”. It can be a bratty, unilateral, condescending, dismissive statement.

\n\n

Another interpretation is “let’s cope with things how they are, but work hard to change them for the better”. An encompassing, generous statement.

\n\n

This book is about choosing how you, as a software developer, deal with our industry and your day-to-day work.

\n\n

“Most of the time, it’s your thinking, not your talent, that holds you back.” - Rick Warren

\n\n

What’s all this about?

\n\n

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!

\n\n

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!

\n\n

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’!”

\n\n

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.

\n\n

You might not agree with everything that I say. I’d be worried if you did!

\n\n

This book is in short chapters. One thing at a time.

\n\n

Isn’t that the best way to do things?

\n\n

Who is this guy?

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

Vitally, I write code.

\n\n

“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.

\n\n\n

Part 1: Overall attitude

\n\n

Attitude over Aptitude?

\n\n

“We Are All Fallen Creatures and All Very Hard To Live With” - C.S. Lewis

\n\n

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.

\n\n

Open to unfamiliar approaches
Challenges hirself to develop new skills
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.

\n\n

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.

\n\n

Be courageous in ignorance

\n\n

“Endeavour to be the dumbest guy in the room” - unknown

\n\n

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.

\n\n

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.

\n\n

It’s not about hiding what you don’t know. It’s about having the courage and determination to get it right.

\n\n

You may also be helping others. Choose to be brave.

\n\n

Be professional

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

Being the best version of yourself in your workspace that you can possibly be is professionalism. That’s my take.

\n\n

Be resourceful

\n\n

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.

\n\n

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.”

\n\n

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.

\n\n

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!

\n\n

Don’t try to prove how smart you are

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

Don’t worry about being the brightest

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

Open Source your knowledge

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

Seek to build community

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

Take the initiative

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

Don’t be precious!

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

Do it scared if you have to

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

Part 2: Tools, learning and technique

\n\n

Have respect for books

\n\n

“No matter how busy you may think you are, you must find time for reading, or surrender yourself to self-chosen ignorance.” - Confucius

\n\n

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.

\n\n

I include e-books in this, of course, I’m not that backward!

\n\n

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.

\n\n

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.

\n\n

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!

\n\n

Always pressure test

\n\n

“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

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

Don’t tolerate vague, static, esoteric “grab my wrist” nonsense. Pressure test all that you do.

\n\n

Think testing

\n\n

Here are 7 reasons to unit test that I gave in a blog post Pragmatic Code Coverage:

\n\n

To answer the question “does the code do what I think it does?”
To break a problem up
To encourage good design and loose coupling (untestable code is bad code!)
To write exploratory code
To show your working and provide documentation (e.g. testdox format)
To prevent regressions
… and because otherwise you’re being a cowboy!

People talk about BDD vs TDD like they were in opposition. Here’s my take.

\n\n

TDD says; “this program does what I, the developer, wrote it to do.”

\n\n

BDD says; “this program does what the customer wants it to do.”

\n\n

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.

\n\n

Tell other developers what your code should do. Describe your code by writing descriptive tests.

\n\n

Automate like your name was Dan

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

Performance matters

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

Measure, don’t guess

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

Get your tools right

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

Build a solid technical foundation

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

Be deployment minded

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

Choose your libraries carefully

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

No source is set in stone

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

Learn to spot antipatterns

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

Don’t be tied to a single technology

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

Part 3: Wisdom for the long haul

\n\n

Have achievable goals

\n\n

This is adapted from a longer entry on my personal blog

\n\n

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.

\n\n

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.

\n\n

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”.

\n\n

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.

\n\n

Accept that failure happens

\n\n

“For though a righteous man falls seven times, he rises again” - Solomon

\n\n

“Experience: that most brutal of teachers. But you learn.” - C.S. Lewis

\n\n

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!).

\n\n

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 co-workers had made this mistake instead of me”?

\n\n

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.

\n\n

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.

\n\n

Get up, don’t give up! Know that we’ve all made mistakes. Forgive yourself, learn, grow and teach.

\n\n

Treat people as people

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

Take care of yourself

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

Beware burnout

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

Dealing with burnout

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

One thing at a time

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

Part 4: Communication is key

\n\n

Documentation is communication!

\n\n

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!

\n\n

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.

\n\n

Usage examples should always be in your documentation. Never be vague, be specific.

\n\n

Above all, in this age of ludicrously named libraries, your runbook should tell you precisely what the application actually does!

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

No unnecessary docs

\n\n

We’ve looked at runbooks, so am I contradicting myself here? I don’t think so.

\n\n

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.

\n\n

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?”

\n\n

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.

\n\n

Write documentation. Your project is NOT complete without it. Just be sensible about how far you go.

\n\n

Keep emails short

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

“Just” is the worst word

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

Dealing with suits

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

Beware meetingitis

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

Part 5: Some closing advice

\n\n

Never stop learning

\n\n

“Unless you are continually improving your skills, you’re quickly becoming irrelevant. And when you’re irrelevant, you’re no longer credible.” - Stephen Covey

\n\n

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.

\n\n

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.

\n\n

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…

\n\n

Don’t sweat becoming “perfect”. Simply keep learning, and have the humility to never make out that you’ve achieved programming greatness!

\n\n

Keep it in perspective

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

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

\n\n

This chapter appears in the full version of this book! Please visit the book’s LeanPub site to get the whole book!

\n\n

Signing off

\n\n

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!

\n\n

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.

\n\n

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.

\n\n

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.

\n\n

Be honest.

\n\n

Be brave.

\n\n

Be yourself!

\n\n

“Courage is not simply one of the virtues but the form of every virtue at the testing point “ - C.S. Lewis

\n\n\n\n

Acknowledgements

\n\n

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!

\n\n

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!

\n\n

Thanks to my girl Annie, I love you!

\n\n

Big up Warren, Carey, Craig and Rod - team Unified Diff!

\n\n

Hold tight Woodville Baptist Church!

\n\n

Easy the City Arms, Cardiff’s best pub!

\n\n\n

\n\n","tocStructure",[],"publicChapterContent","nextChapter","sections",[],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]

Table of Contents

Dedication

Introduction

What’s all this about?

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

Seek to build community

Take the initiative

Don’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’t guess

Get your tools right

Build a solid technical foundation

Be deployment minded

Choose your libraries carefully

No source is set in stone

Learn to spot antipatterns

Don’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!

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