How becoming a parent made me a better coder

Yes, yes I know, it's common to see people you know have a kid and then become one of those insufferable types who thinks they've unlocked some secret achievement that 'you wouldn't understand until you have a child yourself'. They start lecturing people and giving advice as if it's been passed on to them via a sage, mystical power.

I'm not one of those. This isn't one of those lectures.

Nevertheless, having a child has made me a much better husband, person, colleague, coder, you name it! Mainly because there are a few areas where you have to up your game if you're going to survive the gauntlet of raising a successful, helpful human.

Having a growth mindset

I came across this term on a poster in a school visit. It was a comparative list with a very negative set of outlooks on one side and a more 'growth-minded' set on the other. Obviously aimed more at the primary school's level, examples included:

• I can't do this (negative) | what else can I try? (growth)
• I've tried everything (negative) | what am I missing? (growth)
• My friend's always doing well (negative) | what can I learn from them? (growth)

It's inevitable as a developer that you will hit some kind of wall; whether it's something new that you don't fully grasp yet (cough Redux ) or a difficult challenge to solve using JavaScript. And, when you hit these walls, it's easy to feel overwhelmed, or not good enough, or just stuck.

By shifting my thinking, by applying these sorts of positive repurposing of dead-end mental pathways has helped me rebound and hit my goals, especially when it comes to overcoming challenges at work.

As a bonus, because of the repetitive and objective nature of training this mindset into your little one (i.e. another human), it becomes easier to help motivate your colleagues into action - Pro tip: baby voices work less on your colleagues!

Compromise is key

Have you ever tried to enter an argument with a small child? No? Well, it's a bit like that scene in Interstellar where they go onto the planet on the black hole's event horizon and one hour there equals seven years everywhere else. Except the argument is the black hole, you age seven years regardless of where you are and end up losing whichever way you spin it...

Seriously though, you want to raise a decent, reasonable human being, so it's natural to want to object when they lie on the floor screaming like you've stabbed them because you brought the blue cup instead of the red (spoiler alert: they asked for the red cup to begin with).

Whilst you want to get your way (having them act less possessed), they want their way (however unreasonable that is) too and it's important to allow them to have their needs acknowledged and met to a degree, without caving and teaching them that screaming equals results.

When it comes to developing, this is just as true. I've never been a 'I want it all my way' type and I think of myself as a team player, but I will admit that I've had my nose put out of joint a few times because I've felt that a particular choice wasn't the right one for a particular project.

Being objective and reasonable takes practice and thought. In the end, sometimes it is better to reach an accord and move on for the greater good than to dig in and cause momentum-killing friction within a project, only because you didn't get your way.

Good enough > perfect

Dealing with a small person who has their own ideas, wants and time-schedule means that you have to make decisions that sometimes result in getting out the door a little underdressed, or with random socks (to be fair, I do this on purpose) or without brushing your hair quite the way you'd like to.

Chasing perfection is a fools errand. Occasionally, you just have to do a good job and improve it as you go.

MVP, ship now, fail fast, nightly releases. There are lots of terms that we use in our coding world that align to the idea of doing something well and working on it, above getting something perfect that never sees the light of day.

It's helped me to really see the value in building things efficiently that can be worked on and moulded as we go, rather than developing a fully-featured masterpiece that will probably never exist.

Action > planning (usually)

Similar to the last section, how many times have you sat in meetings about meetings about planning, only to have walked away with less time on this earth than you started with and no clear plan of action?

It's all too easy to get caught up in the fine details and the need to have everything nailed down, ironed out and planned within an inch of its life, rather than making something happen and shaping it as it grows.

With the child, last minute curve balls are always coming up and you have to deal with them; planning - certainly with any degree of magnitude - doesn't happen or go as planned.

Relating to developing the webs, over the course of my career I've discovered that this approach of deciding on a direction and setting sail, adjusting course as you go is far more rewarding than drowning in plans.

This is one of the overall themes of using Agile. Yes, I know, it's not as simple as that and there are definitely planning stages involved, but the general approach is to define a set of actions and work on them to deliver a feature or function in short, iterative timeframes.

Focusing on action over (too much) planing helps in a number of ways:

• you can ship features and deliverables sooner
• shipping early(ier) means you can get feedback and real-world metrics sooner to inform direction and improvements
• changes in scope or direction are less jarring and cause fewer problems

Of course, there are situations where people's lives depend on getting it right first time so this isn't great advice for everything. However, when it comes to most situations, especially software development, I firmly believe in action above the quagmire of over planning.

Rediscover by reimagining

Kids have a great ability to take something ordinary, say a wooden spoon, and transform it into a work of magical imagination, becoming a sword or a magic wand. When you join in, seeing through their eyes, you start to engage and unlock some of that imagination that's all too often lost or buried by the routine of adulthood.

Bringing it back to coding the code, how often have you left a new framework or library to gather dust because it became a chore, or too mundane, losing some of its appeal or spark?

Now, you're unlikely to take a CSS framework or technique and turn it into a rampaging dinosaur or sword of ages, but by talking with advocates on Twitter, in the workplace or discussing possible ideas and use cases with colleagues, you might just rekindle some lost imagination or purpose for an aspect of your tools that you had lost or forgotten.

Everyone should have a voice

This is the important one. If you ignore everything else here, this is the one to take away. One of the biggest mistakes with kids is to treat them like kids, give them very little credit and to deny them a voice, a say so in their own life.

Yes, we're not talking about giving a three year old a nail gun and telling them 'it's time you learned how to put up a fence'. Instead, we're talking about letting them share their thoughts and opinions on things that they're involved in, matters that affect them.

Same with development teams (or any teams for that matter). I've seen it before in some of the more toxic places I've encountered where junior or less experienced devs have their ideas steamrollered, voices drowned out by the old guard, stalwart gatekeepers or even well-meaning types who just forget that inexperience does not mean not insightful.

So take the time to listen to all members of the team (even some outside of the team), gather and hear their suggestions because you never know what you might uncover when you do.

What have you learned from your experiences (with or without a child)? How have they made you better at your job? Share your tips in the comments.