Lately I’ve been thinking a lot about thinking. There are a couple of reasons for this.
First, doing it well is a prerequisite to developing any dependable expertise in any kind of computer science or engineering discipline. With the right mental toolset, you can bootstrap any of the subject matter knowledge you could possibly need.
Second, in my experience, it is the aspect of computer science and engineering that gets the least amount of attention. There is a veritable deluge of training resources online. But most of them cut right to the nuts and bolts of gaining basic competency with the software tooling to qualify someone for a job. This is understandable to a point. If you’ve never programmed before, the skill you immediately feel yourself lacking is the use of a programming language. It’s only natural, then, to attack that head-on.
But while it’s not as exciting as rolling up your sleeves and saying “hello” to that world, taking the time to learn how to learn, and how to solve problems that can’t be solved by coding harder, will pay off in the long run.
What follows will outline what I have found to be the most essential cognitive skills that contribute to engineering success.
Your Harshest Critic Should Be Your Thinking
The primacy of critical thinking is such a worn-out aphorism that most people whom I prompt to scrutinize it are inured to it. That shouldn’t lead anyone to mistakenly believe it isn’t indispensable, though.
Part of the problem is that it’s easy for those who advocate critical thinking to assume their audience knows what it is and how to do it. Ironically, that assumption itself could benefit from undergoing some critical thought.
So, let’s go back to basics.
Wikipedia defines critical thinking as “the analysis of available facts, evidence, observations, and arguments to form a judgment.” What do the most load-bearing words here mean? “Facts,” “evidence,” and “observations” are related, as they all endeavor in their own ways to establish what we reasonably believe to be true.
“Facts” are generally proven prior by (usually) others whose discernment we trust. “Evidence” is made up of specific measured outcomes cataloged by you or other trustworthy individuals. “Observations” implies those that the critical thinker themselves has made. If these, too, were phenomena that others (and not the thinker) witnessed, then how would this meaningfully differ from “evidence?”
“Arguments” is the odd one out here, but for good reason. This is where “thinking” (specifically reasoning) really starts its heavy lifting. “Arguments” describes how the thinker makes rational determinations that point to additional knowledge based on how the facts, evidence, and observations interact.
The most important word of the definition is “judgment.” Critical thinking does not concern itself necessarily with trying to prove new truths. All that critical thinking requires is that the consideration of all the foregoing yields some overall estimation of whatever is under consideration.
These judgments don’t have to be absolute but may be probabilistic. As long as the result is that the entity being considered has been “judged,” and the judgment accounts for all available information (not just that which leads to a desired conclusion), then the critical thinking exercise is complete.
Vetting Process
I have my doubts if all that is what most people mean when they say “critical thinking.” What really matters, though, is whether you yourself practice critical thinking. Funny enough, the way to evaluate whether you think critically … is to think critically about it. Meta, I know, but you have to go there.
In fact, what we’ve just done in posing these questions is do a kind of critical thinking. I have my own heuristic for critical thinking, which is to ask, “why is x the way it is?” What elements acted, or would have had to act on x for it to be as I perceive it, and do those elements that I suspect to be present manifest or produce effects in other ways? This is helpful because it acknowledges that nothing exists in a vacuum, which helps to make sure that you account for all available facts, not just the obvious ones.
With a working understanding of the practice of critical thinking, get in the habit of using it to sieve reasonably validated reality out of perceived reality. Try not to take something as true until you’ve vetted it via this process. Does a given statement align with the other facts you have on the matter? Is it consistent with what is reasonable? Does it make sense given the context?
I shouldn’t have to tell you how valuable this is to working with computers. I shouldn’t because you’re now (if not before) able to figure that out for yourself.
Try Before You Cry
This is something that has shown up in other pieces of mine, but which merits reiterating here in the interest of completeness.
We all need help sometimes, but your colleagues will expect you to have tried to solve the problem yourself first. Time is a scarce resource, so they want to know they are spending theirs wisely. Giving you the same answer found a Google search away probably isn’t that. Moreover, if you’ve tried to solve it yourself, the person helping you can start out where you left off. This lets them rule out many potential causes that take time to test.
You also never know whether your fellow engineers will be available or knowledgeable enough to help when you need it. What if you’re the only one who knows anything about the project you’re working on? Or what if you’re on such a tight deadline that you can’t afford to wait for a response? Develop dependable problem-solving habits, because ultimately those are all you’ve got.
What this really means is to have a troubleshooting procedure. Write step-by-step basic diagnostics for the major types of problems you’ll encounter. Then run whichever diagnostics apply.
Assemble a list of reliable reference materials and consult them before asking questions. For each incident that sends you to the user manual, keep track of where you looked, and what was and wasn’t there. Then, when it’s time to ask for help, compile the outcomes of your diagnostics and the excerpts from the reference materials, and present it all to whomever you ask. They’ll appreciate that you did.
Learn Skills, Not Factoids
Just like with every field, there are certainly facts that you should memorize. For instance, your life as a developer will be easier if you remember the syntax for conditional statement blocks in your go-to language.
Yet this is not as important as acquiring skill sets. For instance, if you memorize the syntax for your routine programming languages, you can get decently far. But what happens if you need to learn a module or an entirely new language that formats things differently? If instead you know how to look up what you need from credible sources, it may take longer sometimes, but you’ll get the right answer no matter what software or language you are using.
The iterative and incremental design paradigm for software development is an example of a skill.
Here, “incremental” relates to modularity. It prompts the developer to break the overall project into the smallest possible pieces, with each piece only doing one thing and operating as independently as possible (ideally not at all). The developer’s task is then simply to build each piece one at a time.
The “iterative” element means to keep building, editing, and testing whatever component the developer works on cyclically until it can function on its own. There’s no moving on until then. This not only works for whatever language one uses or application one builds, but even beyond the realm of computers entirely.
This design philosophy is just one example of how a skill serves engineers better than a rote process, but many others exist. Figure out the ones your discipline needs and get comfortable with using them.
Stop by the Bakery, You’ll Need Breadcrumbs
Write everything down. Since writing notes is cheaper than it has ever been, there’s nothing stopping you. If you like digital, it’s basically free to write however much you want. Open a word processor and see for yourself. If notebooks are more your thing, a few bucks at an office supply store and you’re set.
Reading notes is also cheaper in terms of spent time than trying to find something repeatedly on the web. There is no reason for you to look something up twice unless it has changed since the last time. It’s tempting to assume you’ll remember something or won’t need it again. Don’t. If you do, you’ll eventually be wrong, and it will needlessly take time to rediscover.
Your notes are also the only place in which you can tailor what you learned to your needs. The web has no shortage of answers, but they may not be exactly the ones you need. If you take notes, you can reformulate the information to your use case before recording it.
The real trick with notes is to have an organizational system. The only way writing things down fails you is if you can’t find them again. Regardless of whether you are an avid note-taker, try a few note-taking techniques until you find one you like.
Step Up to the Starting Block
When running a race, you set yourself up for victory or defeat in your training. If you didn’t train diligently, trying extra hard when the competition starts won’t make the difference. That said, you still have to put it into practice on the track.
The cognitive skills I’ve discussed aren’t even the training, but your coach’s fitness regimen. Mine is certainly no Olympic coach, but it beats none at all. The training is in your hands now.
