-
Notifications
You must be signed in to change notification settings - Fork 1
Talk About Your Code
Talking activates different neural pathways than typing... or even hand-writing, for that matter... and it's valuable to engage as many of those different pathways as possible towards solving a difficult problem. Neuroscience aside, there are also some very practical and social reasons to talk about your code with others, even non-technical family or friends.
Some of the most common and easiest mistakes to make while programming -- not just while learning programming -- are typographic: mispelled wrods, missing or un-necessary mark's of punctuation or (mis)use of indentation
or other whitespace. Some technologies on the web -- HTML and CSS -- are forgiving enough to overlook your typos, while JavaScript, bedeviled tongue that it is, will noisily report its protest and go no further.
Unfortunately, writing functioning code requires precision, i.e. if your code has a typo, it either won't work or might not work as expected. Furthermore, it's easier to see the mistakes of others than your own, because you have a tendency to assume what you typed was right or you wouldn't have typed it. Your excellent pattern-matching brain that fills in the gaps in your flawed perception glosses right over that missing "s" in "accessories", the hyphen that should have been an underscore, and so on.
Fixing another person's typo makes you feel useful, while having your own typo fixed -- whether you fix it yourself or someone else finds it -- can be disheartening and a little embarrassing. Therefore it's a good idea to ask someone else to read over your code if you suspect it might be broken because of a typo. It's easier for the other person to find it, and it'll make them feel useful.
To add insult to injury, consider also the embarrassment you feel from showing others your "messy code", your work-in-progress, full of typos and poor indentation choices. Sometimes just cleaning up your code well enough for someone to look at it will organize your thoughts enough for you to have your own epiphany. Then again, sometimes you're so acquainted with the mess that changing anything about it leaves you as helplessly ignorant of what it was doing as anyone else.
Regardless, don't be afraid of showing off your messes and answering questions about the decisions that you've made. Why is that block indented like that? What does that variable contain? Why did you name it x again? Wait, didn't you rename that somewhere? Having another set of eyes help you sort through your messy code can bring you to a realization about your code that wasn't obvious in its current state.
Just like talking, writing, and typing, different parts of the brain are involved in hearing about, reading about, and solely thinking about a problem. Since hearing about a problem activates different parts of your brain than reading or thinking about it would, listening to someone else's problem can help you solve some problems that you couldn't solve by merely reading or thinking about them.
Talking to yourself, a non-technical friend, pet, or even an inanimate object is a time-honored problem solving strategy, occasionally referred to as "rubber ducking". Just like Ernie explained his problems to his rubber ducky, talking to another developer can work the same way. Therefore, talk to someone else about your problems. Hearing yourself describe the problem can lead to a solution even if the other person offers no input.
So, writing functioning code requires precision, but merely thinking about a problem does NOT. That beautiful pattern-matching brain of yours abstracts, ignores, and just forgets entire aspects of the problem while you ponder it. And then the dog barks and wakes up the baby, shattering the whole glorious picture anyway.
Putting your thoughts about a problem into words requires more precision than just thinking but less than actually coding. Talking about a coding problem with another person can help lead you towards a solution by forcing you to be precise enough about your thoughts to put them into words. If your words are unclear to the other person, it's a sign that your thoughts might not be clear enough to be turned into code. Yet. Talking out the details, even with someone who doesn't fully understand the problem, can help that pattern-matching organ of yours wander around to a solution.
Writing functioning code requires you to know things. It may come as a surprise to you, but other people know things. Therefore, talking about a coding problem with another person and listening to their thoughts can give that person the opportunity to teach you something you can use to solve your problem. Even if they don't know anything about the solution -- the code -- that you're trying to derive, what you're attempting to do with your code is analogous to the real world. The experience and wisdom of real world problems can be translated to intelligence and insight into your code. Talk, hear, listen, and learn.