On Confidence and Experience

I learn by doing.  My family bought a Nintendo Entertainment System when I was maybe 4 or 5 years old.  I didn’t care to read the instructions.  I just plugged it in and started playing, bumping into everything and testing everything until something happened.  I recall Who Framed Roger Rabbit being particularly challenging.  That same methodology has been with me ever since.

NES-Console-Set

This is both good and bad.  I was validated last week by my Microprocessor Apps professor.  A student asked him a “what if” question regarding a program in assembly.  He took it as an opportunity to show a few different approaches.  Of course, we found limitations in the platform this way.  We were bumping into everything.  Then, finally, after re-writing the code several times, we found a method that worked.  He then told us, “this is the process of engineering.”  You cannot be afraid of the many, many failures you will have.  You just have to keep pressing until you figure out what works.  In this way, my methodology is good.

Now, let me finish the rest of my original story.  I never finish a video game, except for a few.  This is because I get bored after I’ve bumped into the things and tested the buttons.  I don’t really care about the story.  I don’t marvel at the graphics.  (Let it be known, my favorite game of all time has 16-bit graphics.)  I just lose interest.  This is the bad part of my methodology.  Whether successful or not, when a project is nearing its logical end, I begin to loathe it.  I want to move on to something new.

Sometimes, though, I enjoy something so much that I’m inspired to improve upon it, or recreate it in my own way.  So, I started learning to program in Visual Basic around the age of 10.  Of course, my interest waned when I bumped into the limitations of my abilities and creativity.  At one point I managed to install Linux.  That forced me to purchase “C++ for Dummies”.  A few years later, Macromedia Flash was blowing up on the internet.  I picked it up and started learning the integrated scripting language ActionScript.  But, I spent most of that time animating instead of programming.  Toward the end of high school, I had the opportunity to take programming classes.  I honestly don’t remember all of the languages I studied.  I know there were at least three, but I only recall Visual Basic and Pascal.  (The reason I remember them is because the classes ended before lunch and most of us stayed in the room and played Quake 1 on the school’s LAN.)  Through all of this, I tried and tried to recreate my favorite video games using various languages.  Very few were successful.

I wasn’t until I was much older and much less busy that I finally programmed and published a full, working game.  Unfortunately, it was a Flash game.  Therefore, it enjoyed very limited success and very limited exposure.  It was also kind-of awful.  Still, I made money from it.  For the first time in my life, I had earned money for programming.  I immediately began working on an improved version.

Unfortunately, life got in the way.  My wife and I moved to a different city.  I started commuting long distances.  She lost her job.  We went into debt.  She regained a job.  We paid off the debt.  We coasted.  Then we both lost jobs.  Then we both got new jobs.  My commuting was greatly reduced.  Then, I picked up the game making again.

Unfortunately, at this time, Flash was going through transition.  Adobe had bought Macromedia and was redesigning ActionScript to be much more like java, in an attempt to make it more powerful.  This was a problem for me, because I didn’t have time to learn a new language.  (ActionScript 3.0 used an entirely new syntax.)  So, I used the older syntax that I was familiar with.  It was slower and less capable, so I had to learn how to optimize my code.  The scope of the new game was ridiculously complex relative to the scope of the first one.  I did it anyway.  I spent a few weeks making my own path-finding algorithm.  It wasn’t great, but it sort-of worked.  Then I spent a day implementing A* path-finding.  Both experiences taught me a great deal.  Then, school began to get tough.  So, the programming slowed to a crawl.

In short, I invested a lot of time and energy into a scripting language that ultimately failed.  (I know that Flash is still widely used, but it is rapidly being replaced by mobile apps and HTML5.)  Still, I learned a lot about programming during this time.  Beside algorithms and optimization, I learned that you can make money even if your product sucks.

Still, none of this gave me the confidence to take a job as a programmer.  Knowing the syntax of several languages doesn’t give you confidence.  Knowing the limitations doesn’t give you confidence.  Tiny “successes” don’t give you confidence.  What gives you confidence is experience.  What gives you experience is work.  There are only two kinds of people who can give you work:  Those willing to take a chance on you, and yourself.

I have been fortunate in life.  Several people have been willing to take a chance on me.  I expressed interest in doing what they do, and they wanted to teach me.  But, they didn’t want to sit me in a lecture hall and profess the why and what-for of what they did.  They just wanted me to do it and learn as I went.  The first big opportunity like this that I snatched was at a defense contractor.  I had been working as an electromechanical assembler for about a year.  I had been put on hot projects that were halfway between development and launch.  Therefore, I had a lot of interaction with the engineers.  This interaction convinced me that I wanted to be an engineer.  I expressed interest to the right person at the right time, and was given an entry-level position.  I had only an Associates degree.

So, then I was part of manufacturing engineering.  If you’re unfamiliar with the various engineering fields, manufacturing engineers take design engineers’ drawings and turn them into real things.  Manufacturing engineers are tooling and process developers.  They procure and/or develop the tools for the job, they design manufacturing processes, and they train staff to actually perform the processes.  My entry-level job was essentially a support position for those engineers.  They let me play with all the new equipment.  Sometimes they let me develop tools.  A lot of the time they let me write procedures.  I wasn’t always successful.  Not everything I did was wonderful or exceptional.  Still, all of this experience gave me confidence that I could figure out most of the problems placed in front of me.  I was also fortunate to have a great mentor.  He seemed to know that I learned things the hard way, and wasn’t afraid to let me do it.  Of course, he offered guidance and support when needed.  It was invaluable.

Defense contracting began declining during the Great Recession. (See page 26)  There were massive layoffs.  I was caught in them, because my position was not an essential part of the process.  I wasn’t mad.  In all honesty, I was relieved.  I had been commuting for 2 hours every day.  This was an opportunity to get a job much closer to home and have more time for other things.

The confidence I had gained at that job lead me to the next one.  I actually interviewed for a manufacturing engineering position, but asked for too much money.  They told me that during the interview.  Fortunately for me, my resume was passed around to other departments.  It landed on the Director of R&D’s desk, and he called me in.  He wanted me as an intern, to do CAD and a little bit of design work.  Again, I was fortunate that someone wanted to take a chance on me.  I had no CAD experience, but I had read and interpreted dozens of drawings.  I was computer savvy.  I was studying engineering at a local university.  But, I asked for too much money again.  Maybe my confidence was a little too high?

It worked anyway.  I’ve now been there for nearly three years.  I went from the CAD internship to full-on product design.  Like I said, I’ve been fortunate.  Other than my direct manager, other people at the company have been willing to take a chance on me.  They’ve given me many opportunities to learn and grow.  It has been amazing.  I feel super-confident in my CAD abilities, which I learned entirely at this job under the supervision of several great mentors.

So, what’s the point?  Wasn’t I talking about programming earlier?  Yes.  I was.  Take note:  Both of those jobs required 40 hours per week.  I’ve been employed in these types of positions for a total of 6 years, now.  That’s roughly 12,000 hours of combined manufacturing/design experience.  Meanwhile, I’ve been programming on-and-off in various languages over a much longer period, but with far less consistency.  That self-teaching experience hasn’t given me the same confidence as my work experience.  That is in spite of the fact that I’ve been self-teaching for much longer.  But, in self-teaching, there is no consequence for absolute failure.  There is nothing to deliver.  There are no deadlines.  These are the reasons that self-teaching is bad.  However, self-teaching is also good because it allows you to explore and experiment.  You don’t fear failure, because the only failure in self-teaching is failing to learn something new.  You’re not afraid to take risks when self-teaching.

So, what’s next?  I’m studying Computer Engineering.  I want to design embedded systems.  I want to be an entrepreneur.  I want to know enough about the technical side of things that I can reasonably identify and ally myself with really talented, intelligent people in those fields.  I want to solve a problem that a lot of people need solved.  I want to tell them that I can solve it for them.  And, that brings me to the next big hurdle, after Computer Engineering: Communication.

Communication has always been a struggle for me.  I think it’s a struggle for a lot of people, actually.  By that, I mean that some people are really terrible communicators even though they speak often.  Still, some people are really terrible communicators because they speak so little.  That’s because communication is an art.  It requires practice (experience) to gain confidence.  I’ve had several opportunities in my career to communicate ideas and concepts to small groups of people.  If my programming and design experience is a plate of enchiladas, then my communication experience is a tiny dollop of sour cream.

Since my work doesn’t often require that I speak to groups, I have to self-teach.  This is good, because I can take risks, I set my own deadlines, and I explore a lot of different ideas.  Hence, I’m writing this blog.  This is how I’m building confidence in communicating.  I learn by doing.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s