top of page

Learning Through Failure

If I don’t fail every day, I’m probably not doing it right.


The other alternative is that I’m amazing at what I do, which is just not possible since I haven’t even started my first job in the field.


I’m talking about coding of course.  (Who isn’t?)


As a senior, I’m currently finishing up a degree in Computer Science / Systems with a completed minor in Math.  (Don’t get me started about how much you have to fail in a Math degree.)


Coding is all about solving problems, but most of the work happens before you touch the keyboard.  Once you’ve taken the time to understand the problem, you have to mentally walk through how you would solve it without code.  That way when you actually sit down to code it, all you have to worry about is the vocabulary and grammar of the code, not the content.


At least, that’s what you’re supposed to do -- turns out I’m more of a hands-on learner.  I usually end up spending 80% of my time writing and erasing code, just to figure out how to solve the problem.  I’m told that this is bad, but that’s usually because the person telling me is the professor who wrote the problem and knows the correct answer.


In the “real world” of professional programming, no one knows the right answer.  If they did, they wouldn’t have a job because there would be no problems to solve.  Software engineers get paid to fail – they figure out what doesn’t work, over and over again, eventually arriving at what does work.  Even if they happen to have the right solution in mind before ever touching the code, the trick is still figuring out how to get there, and that’s bound to involve failure.


Code never works the first time.  It’s super easy to make mistakes and miss small details, causing little defects in the code, aka bugs.  (If you’ve ever wondered where this term came from, one of the first computers ever built partially malfunctioned due to an actual bug leaving its exoskeleton inside the hardware.)  Humans are really good at seeing the big picture.  Computers aren’t – they just do exactly what you tell them to do.  This means that a human software engineer will usually instruct the computer to do something that doesn’t work, but the computer will faithfully carry it out to the letter.  Every time.  Fail after fail after fail.


I’ve had my fair share of failure during my short Computer Science career.  As a software engineer intern this past summer, I accidentally wrote some code that repeated the same instructions over and over again (this is called an “infinite loop”).  Because the code executed forever without terminating, one of our servers ran out of space and the team lost 2-3 days worth of work.


First of all, that should never happen.  Secondly, although I certainly learned my lesson, my own failure exposed another defect in the system that needed to be fixed for the team to succeed.  It never would have been discovered otherwise.  Failure needs to happen in order to learn.


This is constantly happening in the tech industry.  Technology is always changing, and what was formerly known as the right answer will become the wrong answer after a few years.  Tech companies have to stay on top of this in order to continually succeed.  This culminates into a giant game of “King of the Hill,” as companies constantly vie for position as “America’s #1 Technology Solution” (I made that up).


Even if my former team continues on to put together a perfect solution for their client, it probably won’t stay perfect for very long.  The whole purpose of the project is to update the previous version of the software according to newer technology, a multi-year process that might result in software that is once again outdated.  But at least they’ll have learned something, right?


When people ask me how long a typical Computer Science project will take, I usually say “somewhere between 4 hours and 40.”  It all depends on how much time it takes for me to get it working – in other words, how many times I have to fail before succeeding.  I wouldn’t learn how to do it otherwise.


I’m sure my professors would agree with me, but they probably would prefer that I spend more time planning out my solution beforehand.  Oh well.  You learn through failure I guess.  I’m not even going to mention what Thomas Edison and Michael Jordan would have to say on the matter.


Kendall Miyakawa

Comments


bottom of page