Carlo G. Romero

Recently I gave a talk to a group of young and aspiring engineers at Pursuit about getting their first job in technology. One of the questions they asked me was: “If someone for whom you cared deeply was one of the students and you could advise him or her only once, what would that key advice be?” Here is my answer.

If someone I cared about deeply were in the program and was aspiring to a career as a software engineer, I wouldn’t give him or her just one piece of advice.  What my loved one would need to know and learn is far too complex to be reduced to just one pithy sentence.  It would be a disservice to that person and a serious display of apathy if all I did was say one thing. No one thing anyone can say is so profound that it will change everything.

That said, let me try and reduce what I think would help you in your question to a few items.  

Write a lot of code.  And I mean a lot.  You are in this program for just under a year or so.  Write thousands of lines in the year you are part of the program and thousands more when you get out, whether professionally or for yourself.  The code you write for the program counts, of course, but write more than that.  Solve problems on HackerRank or LeetCode.  Find an open source project.  Come up with your own project.  It doesn’t really matter why you write it, it just matters that you do.  

The foundation of the ability I have today was the thousands upon thousands of lines of C and C++ I wrote when I was an undergraduate, either as part of my coursework (hundreds of lines) or a job (thousands) or just pursuing my own curiosity (thousands more).  

There are no short cuts around this and there is no book, no web page, nor YouTube video that will absolve you of the need to churn out lines and lines of code.  You just have to do it.

Production is what the marketplace rewards.  Nothing less, nothing more.  Never forget that someone is paying you to produce software.  If someone is going to pay you, it’s because they want a product in return.  Your success in any career will be always be a function of how much product you can deliver and at what quality.  In your case, your product is software since you are aspiring to be software engineers.  You have to deliver as much software as possible and at as high a quality as possible. This is why you need to start writing a lot of code.  Now.

Your ability to produce is a function of your skill.  “Skill” here means how well you know the programming language you were asked to use, how quickly you understand the problem you have been asked to solve, and how well you apply the language you know to the problem at hand.  When you advance, “skill” will mean how well you design the solution in anticipation of problems because problems will become more general and vague and you will have to solve problems you have yet to experience.  Later on, “skill” will mean choosing which language to use in the first place, which technologies to use and how to put them all together to build systems.  As you advance in your career, you will produce larger and larger pieces of software.

Learn how to learn.  The volume of information in the field of computer science is massive and continually growing.  In my own career I’ve learned and used Python, Scala, Java, C++, C, Perl, Pascal, FORTRAN, BASIC.  There’s Object-Oriented Design and Programming, Procedural Programming.  Now with the popularity of massively parallel systems, there’s Functional Programming.  Processes gave way to threads, single cores to multiple cores.  Unix bred Linux, Windows actually became viable, NeXT became iOS.  Waterfall moved on to Agile (supposedly).

You are going to have to learn a lot and in a very short period of time.  This means you shouldn’t just be memorizing things.  You need to get to the underlying principles beneath all that you are leaning—you need to get to first principles.  

By the way, there is no such thing as a “preferred learning style”—the idea that some people are visual learners, some are auditory, some learn best by doing, some learn best listening.  There is no scientific evidence for this.

There is the best way to learn given the domain, i.e., sometimes it’s best to read, sometimes it’s best to do, sometimes it’s best to watch and sometimes it’s best to listen.  It depends on the subject, not the learner.

Embrace the frustration.  The best sign that you are learning is that you are frustrated.  If anything you are learning is too easy, you are not learning enough and you are not trying hard enough.  If you find writing code easy, you are not challenging yourself enough.  Embrace the suck.

Protect your most valuable asset for your career.  Your most valuable asset an engineer is your brain.  Take care of it.  Train it to focus.  Push it then let it get rest.  Feed its hunger for knowledge through reading and other forms of intellectual exploration.  Don’t let it get distracted by trifles. Sleep.

Learn how to build relationships!  Engineers are notoriously bad at this but relationships are one of the foundations of your success—not to mention your overall happiness.  This is nothing less and and nothing more than learning how to develop friendships with the people you will encounter in your career.  

The quality of your relationships in your career as an engineer will dictate how much you learn, what opportunities you will see and what path you will take.  Bill Gates needed Paul Allen.  Steve Jobs needed Steve Wozniak.  Larry Page needed Sergey Brin.  All of them needed networks of people who believed in them and trusted them.  

Building relationships is not the same as “networking”.  I despise that word. It is utilitarian, insincere and not only is it useless, it is actually destructive.

You will need help from someone who has something you don’t in order to succeed—whether it is knowledge or access to opportunity—and if that person senses that you are “networking” with them, i.e., you are only trying to connect with them because they have something you need, it’s over—that person who has something you need will shut you down.
Networking is transactional—taking.  Relationships are built on trust and generosity—sharing.

Have fun.  There are few actions in life that bring as much joy to human beings as the act of creation.  Ask any artist or author, movie director or screenwriter, mother or father.  When you bring something new into this world it is deeply pleasurable.  Writing code is an act of creation.  A software engineer at his or her best is an artist, no less so than Picasso or Da Vinci.  Yes, you must follow mathematically constrained rules, but that shouldn’t limit you, it should free you.  The rules are the rules of logic and they are simply the canvas of your creation.

You’ll be frustrated and you’ll be infuriated but, in the end, if you are doing it right, you should be having fun.

On this first Friday of Lent, when I have to abstain from eating meat–as a billion other Catholics do–not only am I pondering the meaning of this (very) minor sacrifice but also the slightly less minor sacrifice we have to choose for this forty day period.

First of all, I am hungry and I love meat.  And now I have to wait at least twelve hours or so before I can take in food products derived from land animals.  Second of all, I have chosen two actions for this Lenten period that make me want ponder the point of sacrificing at all.

The first action I’ve chosen for this season is to pray The Examen every night during this season.  St. Ignatius, founder of the Jesuit order, created the Examen as a method of reflecting and reviewing the day.  Jesuits end their days with this prayer.  For you more secular minded folks, think of The Examen as a way of doing a review with your boss, except that your boss just happens to be The Boss of the Entire Universe–and He just happens to be very wise and forgiving.

The second action I’ve chosen is to continue the project I began two years ago for Lent.  Back then, I interviewed homeless people in order to understand.  Two years later, I have thought about the general principles of problem solving in order to be able to teach my students how to approach an problem.  Given the amount of thought I’ve given to problem solving and given the unfinished project from two years ago, my second action for this season is to apply the problem solving rubric I’ve written about for the last two months to a seemingly intractable challenge: the problem of poverty. That’s right, I said that.  I want to see how the problem of poverty can be solved.

I know.  Good luck with that and so on.

It occurs to me today that the whole point of these minor sacrifices Catholics are enjoined to undertake are really meant to educate us.  We are asked to sacrifice for the sake of understanding.  And what we ultimately need to understand is why we need to care, what we need to care about and what we need to do about it.

My sacrifices–such as they are–are less than minor.  In the end, I’m just sacrificing time.  And, frankly, I expect to come away with something greater, so it’s not even going to end up being a sacrifice at all.  I expect to understand at the end of 40 days.  Certainly not everything, but just a bit more of what I need to do in this life.  

So given that I have this primitive problem solving rubric, it’s time for the first step, getting my mind right.  Why care about poverty and why solve it? I’ll start there.  We can discuss the impossibility of the problem later.  First, let’s consider why we even need to care.  And–surprise–I am asserting that we do. 

The last step in problem solving is not necessarily the most important—they’re all important—it’s the one that I think is the most overlooked: you need to test your solution.  Another way to put this is to “check your work.”

Solving a problem, especially a challenging one, is exhilarating.  It’s a sense of accomplishment and we naturally want to pat ourselves on the back.  But the rude but necessary question is this: how do you know you’re right?

Sometimes my students get so excited that they were able to apply some newly acquired knowledge to a lengthy problem that they skip this step, missing a critical element of the question or forgetting a minus sign, ultimately getting the question wrong.  On a more serious level, imagine what would happen if a new medicine arrived on the market with claims of treating a grave illness–cancer, say–but without any evidence of testing for its efficacy.  Not only would that medication likely be useless, it may actually be dangerous.

When you think you’ve solved a problem, don’t be too certain.  Check your work.  Test your solution.

How to Solve Any Problem:
Step 1: Get Your Mind Right 
Step 2: Identify and Clarify the Problem 
Step 3: Break It Down    
Step 4: Identify and Gather Your Resources
Step 5: Send in the Wolf
Step 6: Test Your Solution

You’ve put yourself in the correct mental and emotional state.   You’ve identified and clarified the actual problem.  You’ve broken it down into smaller and easier to handle pieces.  You’ve gathered the necessary tools and resources and you’ve consulted your storehouse of previous solutions.  The next (and almost final) step is to send in the Wolf, just as Marsellus Wallace (Ving Rhames) did in Pulp Fiction in order to help Jules (Samuel L. Jackson). In other words, it’s to find the solution to the problem.  You have enough information at this point, it’s time to act.  That’s all I’ll have to say–for now. 

How to Solve Any Problem:
Step 1: Get Your Mind Right 
Step 2: Identify and Clarify the Problem 
Step 3: Break It Down    
Step 4: Identify and Gather Your Resources
Step 5: Send in the Wolf

• 

It is President’s Day in the United States, the day that Americans celebrate the birthdays of two of the greatest presidents in American history: George Washington, born February 22, 1732, the father of the nation and Abraham Lincoln, born February 12, 1809, the Great Emancipator and Rail Splitter.

There are many reasons each one has been deemed by history to be the two greatest (depending on the list, they often trade first and second place) but surely the scale of the problem each one faced contributed to these assessments.  Washington had to bring forth a nation and a type of government that hadn’t existed on earth for nearly two thousand years. Lincoln had to keep that nation intact in the face of massive armed opposition.  In other words, each President faced existential level threats.  

Given the massive scale of he problems each one faced, what is of interest to me is how each man solved it.  Entire volumes have been written about their respective solutions, of course (see The Glorious Cause and Battle Cry of Freedom).   But for the sake of my study of problem solving a key step each man engaged is what interests me today on President’s Day: identifying and gathering your resources.

It should go without saying that neither man solved their respective existential level problems by themselves.  Washington had to raise an army, train it, arm it and clothe it.  Lincoln had so supply his army, identify how much of his army even remained after his inauguration, unify his allies, and gain support for the fundamental changes to the country and government his predecessor, Washington, had birthed.  In other words, each man had to identify what resources he had available, gather them together, and bring them to bear.

On a much smaller scale, this is often the step we all tend to forget when we are faced with a crisis or a problem.  In a moment of panic we might actually forget what we know.  We might not remember what we actually have or who is actually on our side because we are so wrapped up in the scale of the problem instead in the promise of the opportunity.  Hell, that just happened to me today.  And it tends to happen to my students when faced when a seemingly inscrutable problem on a test.  They forget how much they know.  They forget just how smart and how talented they actually are, just as you (and I) often do when under pressure and confronted with a threat.

So that’s the next step in problem solving: Identify and Gather Your Resources.

How to Solve Any Problem:
Step 1: Get Your Mind Right
Step 2: Identify and Clarify the Problem
Step 3: Break It Down   
Step 4: Identify and Gather Your Resources

Barely four months into his presidency, the youngest elected president in American history gave a speech to a special joint session of congress exhorting the United States to send a man safely to the moon and bring him home, all before the end of the decade of the sixties.  The audacity of this challenge needs to be put into perspective.  At that point in history, May 25, 1961, the United States hadn’t even put a man in orbit—though the Soviets had.  American Alan Shepherd had only reached a mere 116 miles from the surface of the earth.  Now John F. Kennedy was challenging the country to send a man on a trip of over 450,000 miles.  This was an enormous problem to solve.  How did they do it?

They didn’t.  In 1961 it was an impossible task to send a man to the moon. Instead, James Webb and the rest of NASA broke down the problem into a series of steps.  Build a powerful rocket.  Get a man into orbit (John Glenn). Build a more powerful rocket.  Put two men into orbit.  Get a man to walk in space (Ed White).  Execute a rendezvous of two different spacecraft (Gemini VI and Gemini VII ).  Build a command craft and a landing craft.  Put three men into space.  Build the most powerful rocket ever known to humanity (Saturn V).  Orbit the moon (Apollo 8). Land on July 20, 1969, before the decade ends, fulfilling the promise of the young president.

Once my students encounter the sixty or so words in a math problem, they have fifty seconds to find the correct answer.  After getting their minds right and clarifying the problem, they will to need break down the big problem into its constituent parts, solve each of those parts and then put it all back together to find the answer.

How to Solve Any Problem
Step 1: Get Your Mind Right
Step 2: Identify and Clarify the Problem
Step 3: Break It Down   

And, now, we’re back to problem solving…

The NASA spaceship Odyssey was 205,000 miles away from earth when astronauts Jim Lovell, Fred Haise and Jack Swigert heard what they described as a “pretty large bang”.  This was accompanied by electrical fluctuations onboard and the momentary loss of communication with Earth.  Their second oxygen tank reading was zero.  When they looked out the window, they saw that the Odyssey was venting gas.  Clearly, they had a problem—but what?  They didn’t even know if what they heard was an explosion or the impact of a meteorite.  And if it were an explosion, what caused it and which parts of the Odyssey did it affect?  The specific answers to all these questions marked the difference between the success and failure of the mission, with “success” meaning that Lovell and Haise would land on the moon in the Aquarius and then plant the flag.

In the latter parts of the math section of the SAT the questions get harder. The questions have fifty words or so and the student has less than fifty seconds to read it and solve it.  If they get past their intimidation—which they often do—as they read the question they will recognize many elements, realize that they know all the necessary math, start executing the steps they know and then get an answer.   

Only later on do they find out they got wrong answer because they solved the wrong problem.  They hadn’t read all the way to the end of the question so they didn’t actually know what the real problem was.  Or they simply misunderstood the question because the excitement of recognition drew them away from complete understanding and, therefore, the correct solution.

After the accident on the Odyssey, it wasn’t immediately obvious that the astronauts’ survival was at stake. After all, they were still breathing and they were still moving towards their original target—the moon.  Only after an examination of the all the monitors on the Odyssey and a long series of physics calculations run by the NASA engineers on earth did the gravity of the situation become clear.  Only then did they understand the true nature of the problem.   Not only were Lovell and Haise not going to be able to take the Lunar Module and land on the moon, it wasn’t even clear that they were necessarily going to survive.  The problem to be solved wasn’t a lunar landing.  It was whether they were going to live and land back on earth. Their supply of breathable oxygen was now severely limited and they were hurtling away at thousands of miles per hour from the nearest known source of oxygen in the universe—talk about time pressure!

You know how this movie ends, of course.  Lovell, Haise and Swigert returned home, their mission hailed as a “successful failure.”  The movie Apollo 13 was largely accurate, down to the lines in the script taken directly from actual NASA communication transcripts (a bit of trivia: unlike Tom Hanks in the movie, what Jim Lovell actually said was, “Houston, we’ve had a problem”, not, “Houston, we have a problem”.  Impress someone with that at your next party).  But for all the excitement in the movie of solving the problem, most of the movie was really spent trying to understand the problem in the first place.  Most of the movie was spent problem identifying instead of problem solving: identifying the real problem (survival) and clarifying the problem (the constraints imposed by a limited supply of oxygen and Newton’s Laws of Motion).

So this is step two of solving any problem, what my students have to do in less than fifty seconds.

How to Solve Any Problem

Step 1: Get your mind right

Step 2: Identify and clarify the problem

Imagine having the ability to dispatch forty armed assailants with your bare hands.  Or the agility to dodge heavy machine gun fire unscathed.  Or the strength and speed to take on  interstellar opponents.  Of course, our friendly neighborhood Spider-Man can do these things because he has the proportionate strength and speed of a spider.  

But the foundation of all of his amazing ability is his “spidey sense”, his extra sensory perception that warns him of all forms of danger.  When his spidey sense “tingles”, he knows he’s about to be punched, or that an energy burst from a blaster is coming, or someone is about to drop a bucket of paint on his head.  And since he knows what’s about to happen, he can handle it appropriately: punch back, get out of the way or simply do nothing.

Wouldn’t you love it if you had a spidey sense?  I would!  If you could just peer a little bit into the future to see what harm may befall you, imagine how prepared and ready you would be to handle what life has to throw at you.

Actually, you already have this superpower.  Mother Nature is no fool.  We call this superpower “fear” and it does for us what Spidey’s sense does for him.  Fear warns us of danger.  Fear tells us when to fight, when to flee and when to stand our ground and do nothing at all.

It is possible to be truly fearless, i.e., feel no fear at all, but this is a very bad state to be in.  To be truly fearless, you would have to be cut off from your amygdala—essentially the reptilian part of your brain.  There are such people running around, who by genetic circumstance or brain injury cannot feel fear at all.  They tend to walk right into the middle traffic. When a punch is thrown, they don’t know why they should get out of the way.  In the face of a predator, they feel no need to run.  Without outside protection, they are not likely to make it into the next round of life.
You need the gift of fear.  Evolution gave it to you for a reason.  Evolution wants you alive and ready to procreate.

The problem is not fear but an excessive attachment to it.  This is what happens to my students when they see a problem they don’t understand. Their anxiety goes through the roof and understandably so.  They’ve been told over and over that their future is on the line.  And it is. 

So what to do with the gift of fear at that exact moment?  When the amygdala starts blaring, all mental processing is taken away from the neocortex—the part that’s brilliant at math—and drawn to their reptilian brain—the part that knows about—among other things—digestion.  How to get the focus back on their brilliant neocortex?

You can try to ignore the fear, but that won’t work since any ignored emotion will simply return more intensified.  You can challenge the fear but—like ignoring it—it will simply make it stronger.  Why not do what Spidey does when his spider sense tingles?  He pays attention to it.  Then he decides what to do, whether it be fight or flee.  Note that he does not do what his spider sense tells him to do.  He listens to it, evaluates its warning then he decides and acts.

Fear is not designed to tell you what to do.  It tells you that there’s a threat and you might need to do something, but the decision is left entirely up to you.  But how can you make a good decision when your fear is at its most intense and you amygdala is demanding all of your attention?

You can breathe.  Deeply, evenly and consciously.

This sounds simple but the decision to breathe deeply and consciously actually sets off a complex series of neurological events.  This decision to focus wrests control of your brain from your primitive amygdala to your far more intelligent and advanced neocortex.  

You don’t need to take my word for it.  Take it from the experts in fear management: the United States Military.  This is the breathing technique the US Navy teaches to prepare for extreme situations (“extreme” meaning the probability of a life terminating event is high, aka death): Combat Tactical Breathing

Relax yourself by taking 3 to 5 breaths as described below. Visualize each number as you count.
Breathe in counting 1, 2, 3, 4
Stop and hold your breath counting 1, 2, 3, 4
Exhale counting 1, 2, 3, 4
Repeat the breathing
Breath in counting 1, 2, 3, 4
Pause and hold your breathe counting 1, 2, 3, 4
Exhale counting 1, 2, 3, 4

Navy SEALs use it.  First responders use it.  Professional athletes use it.

Try it.  I will!  I will teach it to my kids.  Let me know how it goes.  Maybe instead of fear being a master, we can turn fear into a very good and wise friend.