On Saturday I mentored at the Ladies Learning Code workshop for National Learn to Code Day. As usual it was a great experience, although pretty draining for an introvert like me, but what I want to talk about is the single phrase I used most often with my learners: let’s try it and see what happens.
Now, I’ll freely admit that a good portion of the times I said that were because I didn’t have a lot of experience with the language we were using (python, if you’re curious) and just didn’t know what would happen :) But the bigger part was that I wanted to show the learners that it’s okay to not know what’s going to happen and to mess around and try stuff.
It’s normal to be worried that you’ll look stupid or completely break your program, but the only way you can learn a new programming language (or any language, for that matter), is by trying things and making mistakes. The great thing about programming languages is that failure is just about consequence free. If you get an error message, so what? It’s not even a waste of time, you learned something that doesn’t work. That gives you one less thing you need to try next time.
Even if you’re an experienced developer, you need to keep that willingness to try things and see what happens. Analysis paralysis is what happens when you’re afraid to try something. If you’re working on a large project it’s true that you need to plan it out carefully and run your idea past other developers, but sooner or later you’ve got to start building something even if you’re not absolutely sure it’ll work. The sooner you try it, the sooner you can figure out whether or not it’ll work and the sooner you can try something else. Thinking things through is great but you can’t let it stop you from doing something.
Sometimes no amount of planning can tell you more than a few hours of trying. This is especially true when you’re just starting out, but it doesn’t stop being true just because you’ve got a solid handle on how loops work. And honestly, even the most experienced developers get off by one errors sometimes :)
When you’ve been a developer for long enough, sometimes you lose track of what it was like to be a beginner. We start assuming that we should know exactly what will happen before we even write a line of code even though that’s not even slightly how it works. I feel like I’m raining on new devs parades here, but the uncertainty never goes away. You just work on a different scale when you’re more experienced. Instead of “what happens when I change this == to a >=?” it’s “what happens when I try to use this new library?” or “what happens when we try to make our system talk to this other system?”
The next time you catch yourself slipping into analysis paralysis (and I do all the time), just try something and see what happens.