What I Learned About Making Software From My 3 Year Old Daughter

It's amazing how much you learn about people and about yourself once you have a kid. You can see below some of the lessons I’ve learned from my 3 year old daughter and which I believe are also applicable in building software products. First Try it Yourself to See if You can Figure it Out First of all, let me tell you that my daughter is driving us crazy with this one. We have a hard time showing her how something works. She always wants to figure it out by herself. That part is great, the challenge is that even when she is not able to do it, she still doesn’t want us to help her :) I’m not recommending that you don’t ask for help, but I see a lot of value in trying to figure it out yourself first. I can see how my daughter has developed skills overtime to figure out how things work and the satisfaction in her eyes when she manages to do it alone is incomparable to that when she receives help. When there are things which are quite similar to what she has done before, she is a master. If you want to try a new framework, tool or language; first, try to figure out how it works and then ask for help, when you are stuck. If You Keep Doing the Same Thing Over and Over You Will Get Better at it My daughter’s progress with drawing was so interesting. Now at 3 years old she is able to draw faces and objects whereas she started with something which looked like scribbles and doodles. She was so frustrated at the beginning because she couldn’t draw like we did. That’s when we realized that we should make our drawings worse so that we don’t discourage her and also encourage her progress. If you take a technical practice and do it every day, you will get better and better, even if at the beginning it is painful, you get frustrated and maybe you want to quit. For example when you try out TDD. I can see how that creates frustration and makes you feel that you are too slow in producing shippable code. In order to master TDD you need to practice a lot. Repairing Things with Glue Might Not Make Them Last Longer My daughter saw that when a toy of hers gets broken, we tend to use glue to repair it. Every time a toy gets broken she goes around the house looking for glue in order to repair it. What she has observed after a while is that although we can repair it with glue, the toy is not new anymore. No matter how well you’ve fixed it, you can always spot the glue and you’ll need to pay more attention when using it because it doesn’t have the same resistance. Another lesson is: if you repair the toy with glue in the same place twice, it is probably time to buy a new one. If you patch the same are of code multiple times, it's probably time to refactor it. When you patch things in your code, they might not last long and they are not like the new ones. Quick fixes in code might solve your problem temporarily. Long term, you might need to invest time in order to refactor it properly. Some Things Cannot be Repaired with Glue and Need to be Replaced My daughter believed that if we can repair some toys with glue, then we can repair any broken one with glue. That is not the case. Sometimes we just need to completely replace a broken toy. It's the same with code, sometimes we try to fix it too much, to patch our code rather than completely replace or rewrite that part or functionality. Look Closely You Might Discover Patterns Which you Might Miss Otherwise. , When she was 2 years old and we were walking outside she was able to spot patterns everywhere. For example there was one week when she enjoyed looking for a heart pattern at windows, doors and fences. We even created a game “who could spot more heart patterns” and of course my wife and I lost. Why she was able to win? Because she was paying attention, she wasn’t distracted, she was extremely focused. When you write code, if you pay attention and you are focused you might discover patterns and principles you could apply which you otherwise would have missed. When You Try Something and You Don’t Figure it out, Don’t give up My daughter tried to learn to ride a bike. Her first attempts were close to failures. For a while she stopped trying to use the bike. The surprise came when one day, we were in the kitchen and she was riding the bike in the hallway, alone (yes, we kept the bike inside our apartment). You probably remember the times you tried something and although you’ve explored different options, you still weren’t able to figure it out. Rather than giving up, what seems like a good solution sometimes is to take a break and try again later. What are some lessons you learned from kids which you can also apply in building software?