This is an adaptation of a talk that I’ve done at various events now, and I’d be more than happy to do it again (just sayin’… get @ me 👀).
I’ve been doing ‘web things’ for about 15 years now; it’s become an integral part of how I define and present myself. “What do you do?” – “I make websites”. “What’s your role?” – “Front-end developer”. “Do you internet?” – “Yes I do”. These things used to roll off the tongue as a matter of course in all sorts of daily conversations and I’ve been comfortable with that. The last few years however, have conspired in such a way that I’ve been forced to assume another guise – one which has largely superseded the ‘web dude’ one…
I’m now a Dad. In fact, I have been for over 4 years, but it still feels odd writing it down.
Becoming a parent initially in late 2012, then doubling down last year, has changed my life in all sorts of ways that I neither have the time nor the aptitude to fully articulate. But one way I feel particularly strong about, is how it’s helped me to be a better developer.
There’s a quote from Umberto Eco that I’ve always liked:
I believe that what we become depends on what our fathers teach us at odd moments, when they aren’t trying to teach us. We are formed by little scraps of wisdom.
There’s rarely a big dramatic reveal when it comes to being who you are; it’s a culmination of small things – small changes – that alter you gradually until you’re noticeably different.
I’ve had loads of those changes since being a dad, to the point where I’m almost unrecognisable from who I was in 2012. More than the grey hairs and bags under my eyes, those changes have fundamentally altered my approach to life and consequently to work, and I’d like to share some of those things. 10 of them, in fact, because listicles are a thing.
You don’t have to have your own children to benefit from techniques to parenting, and you don’t have to write code to appreciate how raising a person is akin to development.
In case you’re doubting the parallels between parenthood and programming, briefly consider this tweet from Julia Evans:
If you swap out ‘programmer’ for ‘child’ – there’s no difference to the steps that come after. Particularly the ‘ask questions’ thing! Kids become amazing adults the same way that code-types become ‘wizard programmers’, so why shouldn’t we learn from the experience of being a child / guiding children to adulthood(?). (We should. So let’s.)
1. You Don’t Have to Get Things Perfect
As a parent, it’s so easy to obsess over making sure you’re doing the right thing. There’s no pressure quite like the pressure of looking after an actual human being who needs you for literally everything. It’s natural to worry about whether they’ll turn out OK, that the choices you’ve made for them are the correct ones. Not only have you got your own crippling doubt, but a plethora of contradictory opinions from anybody else that’s ever had a child, or has ever even seen a child.
(https://twitter.com/McElaney/status/736659052428681216)
Some things just work and you go with them even though you know they’re not ‘right’. But it soon becomes clear that there really isn’t a right or wrong way – there’s just whatever gets you through. If it does the job and doesn’t hurt anyone, then that’s probably enough.
For the most part, other people wont notice there’s anything wrong. What matters is the result, not the technique you used to get there. Often, you don’t even have to release a fully polished thing; Minimum Viable Product isn’t a new concept, but it’s something my daughter is definitely on board with, to the point where I have a newfound appreciation for it.
MVP is the smallest thing you can build to deliver the value of your solution to your customers, or in child terms, it’s the big circle with a few lines coming out of it that is clearly a dinosaur.
Putting something out there (getting something done and showing it), demonstrates that you’re getting somewhere.
Waiting for perfect is never as smart as making progress.
– Seth Godin *
My daughter didn’t wait until she knew how to run before she started walking, and she didn’t perfect her gait before she started toddling around. It’s a process. Granted, during that process she fell over a lot, and you might fall too, but…
2. Don’t Be Afraid of Making Mistakes
All through school, I was taught that mistakes are inherently wrong. The very etymology of the word comes from ‘taken in error’. They’re bad! But really, they’re not. You should try to see them as evidence of exploring an avenue that turned out not to be the one you wanted.
Kids embrace mistakes. They practically live mistakes! It’s an inevitable consequence of learning new things. Obviously you don’t want to make too many mistakes as that’s not a great use of your time, and there are things you can do to mitigate the effect of any errors, like ensuring you’re in an appropriate environment.
Start with a development environment where you can do pretty much whatever you want without fear of any serious repercussions.
When you’re ready, move into testing (get QA involved if that’s what you do). That’s still local and private, but with some of the safety net removed.
Next is user acceptance… i.e. sort of public, out in the open where people can see, but if things go wrong there’s enough padding so that you can try again.
Then when you’re confident, go to production and let the world see the fruits of your labour. By this point, you’ll probably have ironed out all the creases.
This workflow probably isn’t new to you, but it’s good to remember that there are plenty of places where ‘failure’ is OK. My daughter is into the testing environment for most things in life, though she’s verging on UAT by now, whereas my son is transitioning from dev to QA. Cushions everywhere.
Every stage you go through is a learning opportunity, and as long as you’re not making the same mistake over and over, you’re doing fine.
learn ? experiment ? fail ?
learn ? experiment ? fail ?
learn ? experiment ? win! ?
3. It’s Good to Play
A by-product of establishing safe areas to experiment and fail without fear is that you’ve got room to play. It’s crucial to grant time and space where playing is allowed – and encouraged.
When you’re at school, lessons are broken up a couple of times a day by playtime / recess (whatever you want to call it) and it’s often seen as a break from learning. But that’s unfair, because ‘playing’ shouldn’t ever be viewed as an alternative to ‘learning’.
An ideal office
For my kids, it’s where they practice and hone skills that will help them in their adult lives. Socialising, imagination, physical fitness; there are so many reasons why it’s important. How else would my daughter refine her dinosaur tracking skills, if not during play time? I mean, it’s hard to teach that in a lesson format.
With your code, there are plenty of places to play: in the dev environment, places like codepen, your personal projects… Sometimes you might get lucky and your play turns into work, or sometimes you’ll get lucky and it’ll stay fun. The point is: experimenting, trying new things for fun, and stretching your legs a little is important, regardless of where it leads to. It is, in and of itself, worthwhile.
That said, it can be useful to set some boundaries on that playtime. The amount of time it takes, for one, but also it can help to define a structure. If you let your kids out in the playground with no guidelines at all, it can descend into chaos fairly quickly.
Playworks, a US company that organises play in schools reckon that “without structure, there are fewer opportunities for kids to be successful in directing their own play” and that it’s better to introduce some rules to frame the playtime. An example could be as simple as giving the child a couple of bean bags and a hoop, then letting them use those as props in their playtime. For devs, that could be defining a topic, or a framework to use, then encouraging free reign to use it however you like.
4. Use What You Know
There’s a lot to be said for acquiring new skills and I’m in no way trying to say that’s not important. But I know that when my daughter wants to do something, she doesn’t worry about what she might need to get it done, she’ll use whatever she’s already got and make it work. Want to have a cape to look like Queen Elsa? Grab a tea-towel and a peg. Building a castle to stop your little brother stealing your jewels? Lay the sofa cushions around the pile of buttons you’ve got. Need to colour in an apple but don’t have a red pen? Get the purple pen, now it’s a plum which is fine because it’s still a fruit.
A lack of time leads to less creativity, but a lack of resources leads to creative thinking. If you don’t know about Vue or React or node or whatever, there’s absolutely nothing wrong with using jQuery if it means you’ll get the job done (there’s also nothing wrong with using jQuery in general, but that’s a different discussion).
It’s not a case of always sticking to the stuff you know (word to High School Musical) – it’s merely that what you know is usually quicker to work with, and is probably absolutely fine.
Picking up new skills comes with time and often out of necessity, but too often it creates a self-imposed barrier to just getting on with it.
You’ve probably heard the word ‘disruptive’ thrown about in relation to technology before. It’s always cool to be disruptive. Disrupt stuff! Yeah! Tech! 🤘 Smartphones disrupted the PC market, Netflix disrupted video rentals, Uber disrupted the taxi business, etc etc… but to remind you of the original definition, outlined by Clayton M. Christensen, in his 1995 article Disruptive Technologies: Catching the Wave,
disruptive innovations [are] technologically straightforward, consisting of off-the-shelf components …often simpler than prior approaches.
i.e. using what you know, but to a better effect.
5. If You Encounter Something New, Document It
With my children, we’ve tried to maintain a log of big things they’ve done. First words, first steps, funny moments; they’re documented with a date and description in a notepad.
Looking back through the list, it’s great to be reminded of the good times, and it also helps to inform future decisions. Knowing exactly when my daughter had her first swimming lesson for instance, meant we could aim to start my sons’ lessons at around the same age.
On a more serious level, there’s the red book that every child in the UK is given at birth, which is used to track medical things like height and weight, or the dates of vaccinations. Having a record of those is obviously useful.
When it comes to code, the same principle applies. If you’ve learnt something, or written something, document it. It’s been said that Hell is other people’s code, but Hell is also your own code from 3 years ago. Either way, if it’s not been documented, it can be harder to decipher than Rongorongo. Properly commented code should point you in the right direction and help you understand what the thinking was at the time.
Same goes for commit messages: ‘did a code update, merged a feature’ is not a sufficient message. Be specific, be helpful!
This particularly applies if you do something successful, because it’s very easy to caught up in the moment and forget it later. Write things down so that you and other people can build on what you’ve done in the future. Even if your commit message consists of ‘refactored js to get the carousel working on every device’, that’s fine, because it’s good to…
6. Celebrate Your Successes
It’s really important to talk about stuff you’ve done well. Milestones deserve celebration, no matter how big or small. First steps, first day at nursery without crying, first time using a spoon – those all got a cheer and an acknowledgement of how proud I was of their achievement. A little positive affirmation goes a long way, and it’s perfectly valid to give them to yourself.
Take the tree falling in the forest thought experiment… does it make a sound? I.e. does something exist unless it’s actually perceived? (It’s why Brad should never have looked in the box at the end of Se7en). To put that into a work context: if you produce quality work but no-one knows about it, was that effort futile? If nobody saw it happen, did it really happen?
For a lot of people, the idea of blowing your own trumpet is embarrassing and potentially awkward, and that’s understandable. It’d be strange if you went around extolling every git commit as if it were solving world hunger, but that’s not what I mean. If ‘celebrate your success’ is anathema to you, then let’s call it ‘communicate your efforts‘.
Sharing your process is good. I love hearing ‘Daddy, look!’ for every individual pen mark on a page – it lets me see how things are coming together – what’s going right or wrong – and it makes all the more special when the final drawing is unveiled. It’s not like every doodle needs to get put up on the fridge, but it’s nice to see (and acknowledge) progress.
Oprah puts it quite pleasantly when she says that people should celebrate:
- Concrete steps we have taken towards larger goals.
- Successes of value to us personally, but not necessarily to others.
- Your difficulties, failures AND mistakes.
(I can’t remember where I found that list, but it still sounds like something Oprah would say).
7. When You Get, Give. When You Learn, Teach.
This is sort of related to point 5 above, but more than that, it’s about sharing your findings with the wider world. The quote is from Maya Angelou, but the concept is something I’ve tried to instil in my kids from day one.
If they have a surplus of toys, they should share with their sibling. If my daughter has learnt something new that day, then I want her to tell me about it. In the best case scenario, I’ll learn something new too – but at the very least, the act of sharing that learning helps to enrich her own understanding of it.
Einstein apparently once said “if you can’t explain it simply, you don’t understand it well enough“, and there’s nothing quite like being tasked with ‘teaching’ a topic to get you researching it more.
I’m guilty of not doing this in my professional life enough. It can sometimes feel like there’s no appropriate outlet, or imposter syndrome kicks in and you question if anyone would gain anything from hearing your viewpoint, but there are plenty of ways to do this at a micro level. Blog posts, conference talks, volunteering at things like Code Club or codebar. Or answering stackoverflow questions, contributing to public projects, even replying to #webdev queries on twitter. More than likely, you know something that someone else doesn’t. Or at the very least, you have a different take on something. Either way, sharing is caring.
8. Don’t Get Attached to Your Ideas
An unavoidable consequence of sharing your views is that people will question them. As soon as you start giving back, you should be prepared for feedback. And that’s a good thing – great, in fact! Sharing your own knowledge is all well and good, but it’s only your perspective. Allowing yourself to be open to alternate (sometimes conflicting) views can only be a good thing; having that dialogue will either reshape or reaffirm your own view.
Realising that ideas and plans are flexible is one of the most important things that having children has made me do. I used to plan excursions to the nth degree – timings and activities mapped out long in advance. Trying that with 2 kids in tow is beyond laughable. Not only do things take longer, but they’ve both got their own ideas as to what a ‘fun’ day entails and it wouldn’t be fair to say mine is the right way. The whole thing works best when it’s an interchange of ideas where (hopefully) everyone ends up having fun.
The crucial thing when you’re trying to be open to other ideas is to actually take on board other peoples viewpoints. Actively listen: remove any distractions, hear what they’re saying, and give feedback that you’ve understood. My daughter rightfully gets upset if she’s telling me something and I’m clearly not paying attention. It gives the impression that I don’t value what she’s saying, and it means that I don’t really hear her viewpoint, so no-one wins.
It might help to remember that listen is an anagram of silent. Mind blowing, right(?) There’s no excuse now.
One way of getting on board with this is by peer review. Encouraging critical thinking within your team is a perfect way to open yourself up to new ideas. It shouldn’t ever be a case of judging or being judged, as it’s not about being right or wrong. Be like Cicero:
i criticise by creation,
not by finding fault
9. More ‘Yes, And’, Less ‘No, But’
It’s easy to default to ‘no’ when something isn’t exactly how you would’ve wanted it. The amount of times per day I find myself saying ‘no we can’t’ or ‘no, stop doing that’ is embarrassing. It’s (by definition) a negative word, and all it does it shut down the other persons viewpoint. Saying ‘no’ is the best way to dim a relationship, and if it’s a relationship you’re trying to nurture (e.g. parent/child) then that’s a horrible thing to realise.
It’s a basic step, but starting with ‘yes’ and framing your response as a positive is much better for everyone. It immediately validates and accepts the other person, rather than rejecting them. Following up with ‘and’ augments their opinion, rather than ‘but’ with dismisses it.
By saying ‘yes, and’, you give an idea a chance to be acted upon. The problem with using ‘no’ as a starting place is that it polarizes, prompts defensiveness, and shuts down connection and collaboration. No-one wants to hear ‘no’ about something they suggest – there’s a basic human need for pride, and that takes a big knock if you shrug off their viewpoint.
All this isn’t to say there isn’t a role for ‘no’. It’s definitely appropriate sometimes, just know when to use it. If you don’t resort to it all of the time, it’ll have more impact when you do. ‘No! Don’t touch the BBQ!’ is a good time to save ‘no’ for.
10. Take a Look Around
Finally, if you’re struggling with something that no-one in your immediate surroundings can help with, go external. Remember: it takes a village to raise a child; same applies to raising a developer.
It’s insanely rare that you’ll find yourself in an entirely unique predicament. There are people who have done it all before. Not sure how to start potty training? Ask other parents. Need a different approach to baby-led weaning? See what the grandparents did. The key is to learn from them, use them for help if you need to, but ultimately forge your own path as what worked for them probably wont exactly work for you.
Other developers you work with are usually the first port of call, but if you don’t have access to people irl, that’s what the internet is for. So so so so many places to look for help and advice, whatever your problem is. I like to think that for every mumsnet post, there’s a direct stackoverflow equivalent.
You can try podcasts, books (remember books?), local meet ups, conferences, medium posts… whatever wherever. You’re not alone.
11. Under Promise & Over Deliver
See what I did there(?) You thought there’d be 10 items, and now there’s an extra one. How happy are you right now?! This approach works incredibly well with children. It’s much better to say you’ll try to bring home a toy and then come back with armfuls of plastic animals, than it is to promise you’ll get something only to find the shops are out of stock and nowhere else is open.
A study at the University of Columbia by Patricia Brosseau-Liard, Tracy Cassels, and Susan Birch found that
By age 5, children were less trusting of someone who sounded confident but had been wrong before, than someone who was tentative but had been right.
The same will apply to your colleagues (or clients).
The planning fallacy means that you’re very likely over optimistic about how long it’ll take you to do something, despite any past evidence to the contrary. If you’re aware of it when planning work, you can at least negate some of the effects. Be the person that unexpectedly comes through with the goods quicker than expected, instead of failing to do what you said you’d do.
Finally
Having children is by far the most amazing thing that’s happened to me. Meeting my wife is up there too, but for the purposes of this – learning how to code was also a pretty big deal. They’re the things that define me, so it’s only sensible for me to see where the two roles overlap and can support each other. They’re both full of responsibilities and hidden bugs. They can be the best thing one day and incredibly stressful another.
Being a parent or being a developer is a very lucky position to be in; we create things that go off into the world and which will ideally have a positive impact on it. There’s no one true way of handling either situation, but there are ways of making things easier and more enjoyable while you’re doing it. Hopefully, you’ve picked up a couple here. Come back in a decade for ’Little Scraps of Wisdom: The Teenage Years’ 😬
