What my kids taught me about writing code…and living life in general.
Two months ago, my 18 month old decided it was time she knew how to put on her own socks. This came without provocation from myself or my wife, but we encouraged her ambition. For half an hour, she would try her hardest to get her socks put on her little feet, which taught me a lesson I didn’t expect to learn from this simple little act. As she tried again and again, her socks would ultimately get caught — between her toes, on the ball of her foot, or at her heel — she couldn’t quite get them on. She would wiggle her little feet, pull harder, grunt, and cry in frustration until my wife or I intervened and got her straightened out so she could continue. Half. An. Hour. THIRTY MINUTES! From a little girl who loses interest in almost anything after a few minutes. (Baby Shark excluded, of course.) It didn’t take her over an hour to finally get them on; once she finally got them on her feet, she would clap twice with the biggest smile, celebrating her own success and looking for us to share in it, then she’d rip her socks off and start all over.
I’m not sure if it’s the overwhelming sense of absence or gaining on 32 or just the way my mind has always worked and a new awareness of those inner workings, but it struck me as a poignant lesson. I’ll break it down after laying out another experience — this one from my 4 year old.
He wanted to get the lego pieces on his latest vehicle masterpiece centered, and rather than asking for help, (they’ve both got SOLID independent streaks going) he held the legos in his lap and counted from the outside in “1…1, 2…2, 3…3, …” until he reached the center of the lego platform he was building on. According to my adult brain, it wasn’t the most efficient way to do things, but it was sure effective. It’s become another simple truth I try to live by as I continue to pursue mastery in software development.
The simple truths are as follows:
Tackle big problems.
My daughter clearly doesn’t need to know how to put her own socks on just yet, but she got it in her head and she went for it. Her dexterity and understanding of physics and its applications is not quite where it needs to be to accomplish this on her own, but nobody told her that. Get passionate about something and get after it.
Grind out on your own.
You can learn some amazing things by diving into the thick of it and experimenting with what you find. Before asking for help, try to work a few things out on your own. The things you figure out will stick with you better if it’s something you had to work for. The lessons are brutal, but in my experience, nothing teaches quite as well as the School of Hard Knocks.
Ask for help.
On the heels of diving in and being a go-getter, recognize that sometimes you need help. And there’s nothing wrong with that. Somewhere between throwing your laptop out the window and reading the ticket you need to address, there comes a point where you need external input. Consult the All-Source (Google it), ask a peer, rubber duck it, or use another effective resource as needed. You know what works for you (and if you don’t, you should probably work that out anyway). There’s a reason so much emphasis is placed on collaborative effort. It works.
Celebrate your successes, but then dive back in!
This was the biggest one for me. I have a problem in that I’ve taken a cautionary approach to coding. Consequently, when I get a function or feature performing as it should, I mimic Robert Redford in Sneakers and back away slowly so as not to disturb the heathen Ruby/Rails/JS gods. No celebration, no sharing my accomplishment, just ease out of the room before my code notices I’m gone. This is, in my opinion, a fundamental flaw in my approach to learning how to code. My daughter wasn’t satisfied with successfully putting on her socks once. She was elated with her success, and then tried to replicate it. I definitely need to start doing the same.
Seek simple solutions.
The final lesson was to take away the clever approach and test the most basic solution that will accomplish the task at hand. There’s nothing wrong with using .each; there are cleaner ways to solve certain problems, but finding a functional solution first is the highest priority. You can always refactor code to improve logic or design, but it should be working properly first.
I suppose there is a meta lesson to pull out of all of this. Simple daily experiences can be powerful teachers if you take a moment to reflect on them. Take some time for yourself and figure out what you’ve been missing. Then jump in with both feet!
