Essential Programming Mantras for Beginners

Photo credit: S Migaj, Unsplash

During my initial time learning the fundamentals of software engineering, it became readily apparent that programming is powerful. Not only does code of any language have the capacity to create and manipulate intangible worlds borne from the depths of our mind, but also to provide oneself inspiration, satisfaction, and understanding along the way. Conversely, coding for beginners can (and typically does) tend to leave you in a state of frustration, disappointment, and confusion.

Throughout my career, I’ve leaned on the mantras, credos, and quotes of others to help me make sense of certain situations, assuage myself of unnecessary concerns, and recalibrate when the going gets tough.

When I need to remind myself that feedback doesn’t have to be critical or taken personally:

…and when I need a reminder to keep daring greatly instead of panicking when trying something new(like, say, a 15-week software engineering bootcamp):

I’ll be real with you; there have been plenty of up’s and down’s while learning to code for the first time, and rest assured, the high’s definitely outweigh the lows…but that isn’t to say I don’t get lost in the swamp of “Why is everything breaking, I can’t do this, this isn’t for me.” time and time again. Naturally, I’ve already started developing a rolodex of helpful reminders that help me take stock of situations where I’m finding myself lost or in over my head in programming.

Words to l̶i̶v̶e̶ code by

“Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid.” — Albert Einstein

Before deciding to take the plunge and pivot my career toward software engineering, I was full of doubt as to whether or not I could actually carry my success as a non-technical professional in tech to the technical side of things. My inner saboteur would constantly compare myself to technical individuals I knew or worked with and say, ‘You can’t do that! You just can’t, you’re not smart enough to be an engineer.’ But, as Albert Einstein brilliantly reminds us, if your benchmark for success is something that doesn’t play to your current skillset, you’ll feel like a failure.

This holds true even in the early weeks of learning to code. Every time I’d feel like I had a handle on a new concept, a simple dive into Stack Overflow or documentation would remind me how little I still knew in the grand scheme of things. It’s an important reminder to maintain throughout the process of developing a skill, that your best point of reference for your own capabilities is yourself: past, present, and future, be proud of how far you’ve come in learning how to climb a tree, and excited to hone your climbing skills down the road.

“A computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match.” — Bill Bryson, I’m a Stranger Here Myself

One concept that Flatiron School hammered in during the initial lectures of the program was this notion that computers, despite their capacity to do incredible things, are inherently stupid. At first, this felt perplexing, until truly understanding that computers are rather…directionless without computer programmers to provide direction. This chiasmus by Bill Bryson beautifully encapsulates this dynamic, that WE as humans and as programmers are what make computers smart. Computer programming isn’t purely about hardware and specs and left-brain thinking; it’s about communication, creativity, and our capacity to bestow brilliance upon machines that can do things a lot faster than we can.

“Failure is not the opposite of success; it’s part of success.” — Arianna Huffington

When traditional academia is structured in a manner that makes us believe life is a game of pass or fail, it instills in us a fear of failure. Personally, I still get caught up in feeling that failing is a direct reflection of my own capability, but that’s simply not the case!

In software engineering, this is paramount. The best programmers are those that fail and fail and fail and fail and finally succeed, but with plenty of lessons along the way. A fear of failure obstructs the ability to succeed, and at times it can be easy to think experienced coders you meet are like Simone Biles; sure, we revere the perfect landing, but never had the chance to see the hundreds, likely thousands, of falls and tumbles that were part of her journey. To pull from another wise individual, Master Yoda, “No! Try not! Do or do not, there is no try.” And an unwillingness to fail is an unwillingness to try, and inevitably a limitation to do and succeed.

In theory, theory and practice are the same. In practice, they are not.

While learning JavaScript and React, I can’t count how many times I would listen to a lecture or read learning materials and really feel like everything was making perfect sense, only to then attempt a coding lab and completely flounder. This reality, that theory and practice are distinct, helped me come to the understanding that failing to succeed when putting a theory into practice is not indicative of your understanding. In reality, applying theory takes practice, and lots of it! Sometimes, I can be quick to say “All right, I got the gist of how iterators work, I’ll be fine without doing a couple of reps on it”, yet reps upon reps upon reps is the best way to develop one’s unconscious competence.

“When action grows unprofitable, gather information; when information grows unprofitable, sleep.” — Ursula K. Le Guin, The Left Hand of Darkness

This quote is within the introductory chapter of Marijn Haverbeke’s Eloquent JavaScript, and hit me HARD during the early weeks of learning JavaScript. I certainly know one thing about myself: I’m a completionist and can’t put a problem down until I’ve fully solved this. You can imagine this initially led to late nights of working on the same coding problem and eventually spiraling when nothing I tried bore fruit.

Ursula Le Guin, despite never programming in her life (…probably), hits home with the above sentiment. Sometimes the best thing you can do is step away from a problem, give yourself the grace to walk away without considering yourself a failure, and come back to the challenge with a fresh set of eyes. The structure is brilliant, and put simply:

  • Do things. Do the things you know you can do until you’re out of ideas on what you can do. Sometimes it can be easy to go straight to the interwebs first before actually trying things that are buried within the recesses of your mind.
  • Research things. See if you can find new methods, functions, or approaches you might not know about that, thankfully in the age of information, is only a well-structured Google search away. There’s a reason that our bootcamp heavily stressed that the best coders aren’t the ones who have memorized every syntax out there, but instead know how to articulate and search for the answer.
  • Stop. Just…stop, take a walk, sleep, call it for the day, rather than sinking yourself deeper into the pit of despair. To reference an earlier mantra, don’t spend so much time feeling like you’re failing to the point where you can no longer see your successes.

Don’t boil the ocean.

I have an awful habit of looking at an entire code challenge and attempting to solve all the things in one fell swoop. This, I quickly learned, is a disastrous way to approach programming. If you try to solve everything at once, it becomes paralyzing when figuring out exactly where to start, and unfruitful when you finally run a spec against your code and have no idea where the error lies within the code you spent the last two hours putting out.

The phrase “code a little, test a lot” has now been instilled in me. Tackling a coding challenge and trying to solve everything is like trying to boil the ocean: a hopeless endeavor. It’s essential to chunk out problems, solve them one at a time, and move on accordingly. It seems logical that, if your code is working and, fifteen minutes of coding later, something’s broken, you created the problem in the last 15 minutes. Yet, our lizard brain tells us to win the war instead of focusing on winning the battles.

“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” — Abraham Lincoln

Planning is essential, no matter the discipline. Every third week of a Phase at Flatiron School is a project week, devoted to pairing up with another student and applying everything you’ve learned up to that point on JavaScript, React, Ruby, or Ruby on Rails.

On day one of project week, it’s incredibly tempting to come up with an idea and start diving into the code straight away. In fact, it sort of feels that you’re falling behind if you don’t have something tangible by the end of the first day. As you may suspect, however, poor planning from the offset inevitably leads to chaos and disorganization for the rest of the week.

When starting a project, sharpen the axe by building a project plan, a single source of truth you and your partner can continue to refer back to, adjust, and update as the project plays out. Eventually, as you finally start building out your application, you’ll find yourself less error-prone and more organized, having to backtrack less and less thanks to your project plan acting as your northstar throughout.

I can’t stress enough how crucial planning like this is, especially when working with others. As humans, inference is a great tool we have for associative understanding, but assumption can be the bane of thinking your vision was the same as someone else’s, only to discover halfway through building your application that you’re taking two distinct and incompatible approaches. So before one person cuts the tree with an axe horizontally and the other uses a chainsaw vertically…plan and align, you’ll be just fine.

Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.

Five days into a React application project, I reflect back on our first day endearingly as my partner and I dreamed up the many things we thought we could accomplish in a single week. “Oh yeah! By Tuesday, we’ll have our file structure complete and API fetching correctly, by Wednesday, our functionality will be working perfectly, we’ll refactor Thursday and hopefully squeeze in a few more features, and present on Friday.”

Fast-forward to Thursday night, where MVP functionality is still our focus and those lofty ambitions finally met reality.

Hofstadter’s Law is a great reminder that things will always take longer than expected. If you’re driving across town, maybe leave a bit earlier to account for potential traffic. In the same capacity, programming can sometimes take a fraction of the time that you expect, but more often than not will take more time than you anticipate. In product management, a two-week sprint doesn’t expect all involved engineers to produce ten business days worth of code. In that sprint, there’s padding to “expect the unexpected” so that you don’t “expect to fall short of the goal.”

The Three Great Virtues of a Programmer

Something I found funny when listening to lecturers and reading docs was how often developers called themselves lazy, or framed laziness as a positive attribute. This took a while to wrap my head around…in the right context, is laziness a good thing?

Larry Wall, the original author of the Perl programming language, stated that there are three great virtues of a programmer, stated below, and I absolutely love the lens of how we as engineers can turn vices of character into virtues of our craft:

  • Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don’t have to answer so many questions about it.
  • Impatience: The anger you feel when the computer is being lazy. This makes you write programs that don’t just react to your needs, but actually anticipate them. Or at least pretend to.
  • Hubris: The quality that makes you write (and maintain) programs that other people won’t want to say bad things about.

Tying it all together

Finally, I leave you with one final takeaway. I won’t write too much on my personal interpretation of the credo below, but find myself coming back to it whenever I reflect on why I decided to become a software engineer in the first place, feel frustrated at how I initially oversimplified an undertaking, or feel in over my head while developing my skillset.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store