Getting hired for a tech job is not the easiest thing to do. Although there's undoubtedly a significant shortage of tech specialists in America, it doesn't make the playing field less competitive. That's why you need to play your cards right and go for those skills that will be highly in-demand in the next couple of years. Here we've compiled a list of the most sought-after skills in the industry based on multiple online reports including Indeed Hiring Lab.

Machine Learning

Machine learning, which falls under the artificial intelligence umbrella, is a powerful skill that is expected to change several industries including drug development and the stock market. This technology involves programming a computer to learn by itself without human intervention. Through different programming practices, a machine learning engineer can make a machine identify objects, patterns, and anomalies in datasets.

Since there's no designated bachelor's degree for machine learning, people who want to become machine learning engineers need to opt for a computer science degree, bootcamps, or self-learning. However, don’t worry, because there are some great machine learning bootcamps out there, such as the ones offered by Galvanize. At the school, you'll learn the fundamentals of mathematics and statistics, as well as programming languages like Python, among others.

Data Science

Data science is the ability to study data to get meaningful insights to solve problems, identify phenomenons or errors. Data scientists are some of the leading tech professionals today, and this trend will only continue to grow. Companies that don't have the help of a data scientist are at risk of falling behind in their marketing strategies and business decisions. So this could give you an idea of how essential this skill is for every company.

Now, if you'd like to become a data scientist, you'll need to have some mathematical knowledge, as well as statistical and analytical thinking. There are some outstanding schools out there that can help you become a certified data scientist. Springboard's data science program, for instance, will introduce you to the most crucial aspects of machine learning, such as data filtering, data analysis, and even data visualization, among other relevant subjects.

Software Engineering

Software engineering is another fundamental tool for companies to optimize their operations. When there are repetitive and redundant tasks, a software engineer could create a solution that helps smoothen and quicken the process. On top of that, they are responsible for creating, maintaining, and updating software. That's why a software engineer is usually a long-term position.

Bill Gates and other experts like Elon Musk have let people know the importance of learning how to code because, in the future, they believe that this will be a necessary skill for working—just like reading in today’s world. If you want to go for the path of software engineering, there are two routes you can opt for which are Bachelor's Degree in Computer Science or study online through a coding bootcamp. Flatiron School has one of the most immersive courses where you can learn software engineering. You'll learn about JavaScript, Python, and Java, among others.

Cloud Engineering

With the evolution of big data, the need for cloud engineers has also grown. Companies no longer rely on large rooms to hide and save their databases; they're using cloud systems that are more secure and accessible. Cloud engineers are the ones responsible for building and maintaining these systems to ensure they remain efficient and safe from potential threats.

To become a cloud engineer, you need to understand platforms such as Microsoft Azure or Amazon Web Services (AWS). In order to pursue this career, you need to get a certification that validates your proficiency in any of these platforms. Some of the best AWS bootcamps** **out there are the ones from Coding Dojo or Code Fellows. Both schools provide students with flexible payment methods and schedules.

SQL

This is the era of data; almost everything relies on it. Therefore, digital products and platforms must be created in a way that they're able to have efficient data systems. SQL is the coding language that is used to create and maintain database programs. This skill is especially important for data scientists or other professionals who work with databases and data-driven systems. If you want to get some examples of real-life situations when you use SQL-driven platforms, just think about technology or devices that depend entirely on their data systems like news platforms and Amazon’s virtual assistant, Alexa.

SQL is a programming language, so there are some basic courses where you can learn this skill. such as General Assembly's beginners SQL bootcamp. In this course, you'll learn everything you need to know to master this skill in a short period of time.

Cybersecurity

As mentioned, data is everything these days, so it's no surprise to hear that companies want to keep it as safe as possible. If fallen into wrong hands, datasets that contain a lot of sensitive information could jeopardize the actual safety of the masses and put businesses in a bad financial state. Therefore, it has become imperative for most organizations to hire cybersecurity engineers to keep their data safe. After all, a criminal cyberattack could become a company's worst nightmare. A cybersecurity engineer is a professional who creates policies and systems to protect data.

Flatiron School's cybersecurity bootcamp could help you understand all the processes involved in the creation of cybersecurity policies and systems. In this course, you'll be trained by cybersecurity veterans and you'll have one of the best labs in America for your practices.

Python

Python is a very in-demand tech skill these days and will continue to be so in the next couple of years. It is a programming language used by data scientists and machine learning engineers, among others. If you're new to tech terminology and know nothing about coding, Python can be the best first language you learn because it is easy and straightforward to use. The syntax is simple and some even say it's similar to writing in English.

If you want to dive into this skill, you can take a look at some of the best Python bootcamps out there, such as the ones from Coding Dojo or Code Fellows.

The past few months, my side hustle and technical interview course AlgoDaily hit $3k USD MRR. It's a small amount compared to my software engineering position at a large tech company, but it covers rent and gave me something to work on during COVID. While running this project, I learned a ton of stuff that's been really useful for both the business, as well as for at work. Here's a small sampling.

Engineering Quality Does Not Matter

This statement is of course being facetious, but not to a tremendous extent. Many outsiders will think that in a software project, engineering should roughly consume 50% of your time, and marketing/sales/biz dev the other half.

This is great in theory, but it turns out that marketing/sales brings in 100% of the money-- shocking, right? The old adage rings true: you can literally have the best product in the world, but if no one knows about it, it won't really matter. Likewise, when people are on your site or app, they just care that the button works when it's clicked. Only fellow developers will find it cool that you're using turbolinks or react-dom-router.

For the first year and a half of running AlgoDaily, I spent nearly all the time improving the product, and refining it technically. I built a daily coding newsletter and wrote hundreds of long-form, quality solutions. Then added an editor and runtime to the site so folks could execute solutions. Then I hired a team to add solutions in other languages. Then I worked with a team to create hundreds of beautiful visualizations and diagrams. None of these things improved sales dramatically.

You know what did work? Telling people about it! Sharing my work with communities (shout out Hacker News and dev.to), asking email subscribers to check out the premium course, getting and sharing testimonials, and spreading the word via social media/youtube/meetups-- getting people's attention was by far the most crucial thing for the sustainability of a small business.

Are You a Content or a Platform Play?

One huge mistake I made in the very beginning was mistaking content plays with platform plays. It's too easy for a software product to just be labeled "software", and for its founder/maker to start listening to generalized advice that may not apply.

For example-- "it needs to be 10x better". Not if you're a content business! An online course, newsletter, or Youtube channel only needs to be marginally better to have users make the switch. Think about it-- if I have the option to watch Selling Sunset or Million Dollar Beachhouse, I'm picking Selling Sunset every time even though it's just a minor improvement in quality.

Another one-- "build an MVP first and iterate". If you're trying to offer articles, tutorials, videos, or podcasts-- an MVP is just episode one. You won't learn much until episode 100 or so!

Side Hustles Need Help Too

AlgoDaily really started to take off when I got burned out after the first year for several months. I then started hiring people to help with nearly everything, and only then did it start seeing traction. If you're a solo maker, don't hesitate to hire!

The term "indie hacker" is kind of bull, largely because there's no such thing as a pure one-person business. Yes, one person may oversee or run things, but the second you need vendors (hosting, forms, newsletter, graphics, design), you've started to build a team. It may be a low-touch team, but if any part of your business depends on a third-party solution, you're no longer on your own.

Less Reading, More Experimenting

I think the majority of entrepeneurial advice/content is largely useless in the moment that it's being consumed. I now strongly believe in favoring just in time advice versus just in case advice.

What's the difference? Just-in-case advice is when you peruse indiehackers.com or pick up a business book for entertainment. You'll read a case study to get motivated, or to get inspired, but it's probably not useful to you at that moment. There's nothing wrong with this-- in fact, I'm having a great time reading Reed Hasting's new book on Netflix-- but I know that it's infotainment.

Just-in-time advice, on the other hand, is when you don't know how to do something and look up a tutorial. It's when you feel chronic fatigue and see a doctor, or have a specific legal question and seek out a lawyer. I've found business advice to be much more useful here, because it's specific to the problem at hand.

It's cool to read up on how an ivy league grad launched a multi-billion dollar startup when she was 21, but almost none of what they did or said will ever apply to someone creating a small online course while trying to start a family. Learning about morning routines and what founders read is dope, but what will actually help your hustle is to try everything and learn from failures.

Customer Quality Really Does Vary By Price

99.9% of AlgoDaily users are lovely. I've corresponded with hundreds, if not thousands of you at this point, and for the most part you're all great! I've made several mistakes along the way, and the AD community has been extremely forgiving and encouraging even during big mishaps.

However-- there really is a correlation between willingness to pay and customer quality. The nastiest emails I've ever gotten have been from folks who've bought a subscription during a sale, paid for a month (the absolute minimum), and then demanded a refund while deriding myself and the product. On the other hand, the folks who pay for the most expensive packages upfront, or stay subscribed for many years, never complain and are usually the first to give testimonials and praise in public.

I'm not sure what to make of this. I price AlgoDaily at a ridiculously low price. You get a daily coding email, hundreds of illustrations, and video solutions for what amounts to $5-6/month if you pay annually. I do this to try to help folks and give back to the dev community, obviously while also learning some things about running a business-- but why people will be rude and mean while getting so much value (and often completely free content) will never make sense to me. What a fascinating phenomenon.

---

As every thought leader now says, hope this brought you some value. If you're preparing for technical interviews, consider the best and most accessible course available.

There is perhaps no aspect of the field of software engineering that is more disliked than algorithmic whiteboard interviews. You know what I'm talking about-- sometimes they're called "algorithms and data structures", other times "leetcode-style" questions.

People dislike, and I mean, really dislike these interviews. Here's a sampling of quotes I randomly pulled from Hacker News. First, there's concerns about their effectiveness on a per-interview basis.

Most interviewers don't ask enough technical questions to have any idea what a candidate knows or doesn't know. If their one or two questions happen to be something the candidate knows well, they'll call them a genius. If they happen to not know, they'll label them an idiot.

We've already covered why companies use such interview questions. The problem is that they may be hit-or-miss for each person, but they're incredibly useful when hiring at scale. Other comments lament the interviewers themselves:

I find most interviewers unprepared to evaluate the person for the role, and instead exercise their own biases, stroke their egos, etc. It's largely a voodoo practice that we'll look back and laugh at as a civilization at some point.

Completely Unrelated to Work?

This next one is what we'll be discussing. I've heard over and over again that studying algorithms and data structures isn't really applicable in day to day life.

There are companies that will pay near FANG levels (maybe 10-15% haircut) without subjecting yourself to onerous completion of hundreds of LeetCode problems. There are other options, and we should be aware of them. You'll still need to prove you can code, but the questions we ask have practical application to our codebases: we use recursion and trees, for example, so we ask questions about those.

The above commentor seems to be arguing that the top companies focus more on algorithms and data structures that don't appear frequently in real-life. He talks about recursion and trees are examples of "more applicable" concepts in day-to-day software engineering. This is true to an extent.

No, I have never had to implement a linked list at work. (For some reason, people always point to this as the classic example.)

No, I've never encountered a red-black tree in my career thus far, and I hope I never will.

Yes, I've tended to lean on some pre-built abstraction (database, library, framework, or other) to get my work done, without implementing fundamental algorithms.

However, has studying for them, and knowing these problem-solving patterns, made me a better engineer? I would wager an astounding yes. Here are some ways:

Better Naming Of Things

With these kinds of interviews, you're often nervous and coding in front of a stranger. When this happens, it's really easy to lose track of where you are in a problem.

The thing that helped the most with keeping the problem's "state" in my head, whether on game day or practicing these problems at home, is improved variable and function naming. There are two important constraints in this unique situation:

1. The names can't be too long, or you'll take a white to write them out on a whiteboard (or you'll run out space)
2. The naming needs to be extremely specific to the problem at hand.

The reason for #2 is because you'll often have multiple pointers, nodes, or counters to keep track of.

Names like pointer1 and pointer2 don't really work when they do completely different things, or are conceptually moving in different directions. You eventually realize startingPtr and endingPtr help you remember their purpose, and eventually graduate to start and end-- or parent and child.

Management of Complexity

The pragmatic David Heinemeier Hansson once gave a keynote about Conceptual Compression. It's basically the idea of embracing abstractions-- where increasingly, a developer doesn't need to know the often messy or complex details of some particular technology to be effective with it. Studying algorithms and data structures for interviews actually taught me to see the light on this.

New developers tend to think that solving algorithmic challenges is all about holding all the details in your head. In the beginning, when you haven't learned any patterns, that's the whole point. You haven't yet learned the tools of the trade.

These patterns and "tricks" are abstractions that, once understood, let you concentrate on solving the problem. When you know how sliding window, BFS and DFS, or backtracking works, you suddenly have a filter through the various solutions. You're a level up, that is-- your focus can now be on how to use BFS in this problem, rather than figuring out the exact steps to get to the shortest path.

It is true that, without knowledge of these patterns, it becomes more difficult to solve these kinds of challenges. However, the majority of companies that employ this style of interview are upfront about the expectation that you do study them. People derail this notion, because outside interviews, we never use these abstractions though, right?

Using the Knowledge At Work

Nope, these patterns actually come up all the time! Don't believe me? Here's a few examples.

Sets to Dedupe

I was working with a massive dataset of payments for a company spanning decades. My team had written an ETL process that would pull records in chunks of 100,000 rows and transform them based on attributes of the payment. When the ETL was shipped to production, I noticed the process was taking days instead of the hours we had expected.

Upon inspection, one of the methods in the ETL was doing some de-duping. The way it was de-duping was by performing this routine:

1. Take the chunk of 100k rows as an array
2. Iterate through each row a. On each row, do a lookup in the original 100k to see if there was another one. b. If there was, delete it from the original array

Besides the issues with mutating the original array, the lookup time was just killing our efficiency. The great thing about tech is that most engineering cultures are blameless, so we as a team quickly changed it to this:

1. Throw the chunk of 100k rows in a set

There was a literal 10x speed increase from this change.

Some readers might laugh and say that code like that would never make its way to production. Those people have never been under pressure to ship a feature, while having to work with a team of varying experience levels and managing PRs that regularly span hundreds or thousands of lines.

Knowing to use sets is certainly something that could be picked up just by reading code and gaining more experience. But a concerted effort to learn more of these "tricks" can save you when there's a pickle in production.

Hash the Lookups

I've certainly used hash maps professionally quite a bit, even on this site. On AlgoDaily, we have the concept of Challenges. Each time users finish a problem, we add a Completion record with that Challenge's ID referenced. Now, also note that Challenges are also tagged on multiple Categorys through a join table Taggings.

When I was building out the dashboard, I wanted to display how many Completions each user had completed per Category. This was surprisingly difficult to make efficient with the built-in ORM. Even with eager loading, ActiveRecord would make several n+1 calls to properly group each Completion by Challenge, Category, and user.

The fastest solution ended up outside of any framework. I simply made a solo database call to get all Completionss for a given user by joining them to Challenges. Then, server side, I used a good old hash map to group the Completions by Category and used it to look up counts when rendering the UI.

In this case, knowing that multiple network calls would be significantly slower than performing in-memory operations reduced the load time of the dashboard by over 70%.

Graphs and Trees in CRUD

People always say that 90% of software engineering nowadays is just data-in, data-out-- in other words, CRUD apps. That may be the start, but what happens when you want to do things and analyze the data? Or debug it?

Modeling things is one aspect, but operating on what you've modeled is usually the next step. As an example, a friend of mine was recently working on a directory of company employees. Nothing fancy, most companies have something like this.

The difference with this one was that it would just display an employee profile, and let you click to see their manager's page. Then when you went to the manager's profile, you could navigate to his manager-- an on, and on, up the chain. Nearly every company has an org chart/directory like that.

Of course, for those who've studied data structures, this is clearly a tree, or graph, in the making. And it was implemented as such. Each employee record in the database had a manager_id column that pointed to another employee.

This "shape" was incredibly helpful when doing renderings/visualizations of org charts, and when shaping the payload to populate the HTML (which itself is a tree!). Knowledge of these data structures was especially handy when the team needed to audit the departments, their headcounts, and the reporting structure.

Wait, But!

You may read these examples and assume that all of these are things that come with experience. Yet that is precisely my point. Those who've heavily studied Big O notation, Data Structures, Algorithms, and Systems Design will always have efficiency in the back of their minds.

These will always be fundamentals that have been painstakingly uncovered over decades, and are incredibly useful even in day to day work!

A friendly reminder that we’re running our 50% off summer sale. If you like the AlgoDaily emails and tutorials, you'll love lifetime access to a growing course for half off. We plan to add about several new challenges, lessons, and video tutorials each week for the next few months, so don't miss out!

Code Mode

It's been a wild week. You and your team have been engaged in an all-out war with the codebase for the past two sprints. There's this new integration with a partner that's close to being shipped, and it promises bountiful revenue and voluminous web traffic. And you've been working on the part of it that'll seal the deal and let your squad deploy, come Monday morning.

You find yourself on the Friday night before launch, 6pm, absolutely fried at your desk. Everyone else on your team already left to attend the company happy hour, or has gone home seeking sanity from work. For the past several hours, you've been tracking down a nasty, horrendous bug that could prevent the feature from shipping next week.

But you introduced it.

Caught late in the game, with the marketing team eager to deploy, there were no other options. Thankfully, you're close to patching things up. Your thoughts have been a web of abstractions all night, looking something like this:

• I've looked at SuperClass, but the stack trace is from ChildClass.
• Alright, so ChildClass imports the function from HelperModule...
• HelperModule uses a bunch of functions from CrazyLibrary. Let's do a search. Great, CrazyLibrary has no documentation.
• Wait, did I check out the latest master yet?
• Oh wait, the error wasn't actually on the server. Let's look at the client.
• HugeReactComponent is making the call. Maybe the type is wrong?
• Oh man, it uses DatabaseModernClientApi... I don't know DatabaseModernClientApi.
• Wait no, it's in MiddlewareClientServer...

At 7:30pm, you're sure you've nailed it. It was a silly conditional that got in the way. Boom, problem solved. After merging a PR that switched the broken ternary statement around, off to the happy hour you go.

Beaming with pride from merging the bug fix, you walk in, and notice your team chatting with folks from a sister team. You recognize some members of the sister team, but not everyone. You go and try to introduce yourself.

"Hey y'all, what's happening?!"

Both your team and the sister team sheepishly smile at you. "Hey man", one of them says, "long day?" You look around, and suddenly notice that some people have startled looks on their faces. Then you realize they had been having a low-key conversation, and that you'd jumped into the conversation at quite the high decibel.

"Yeah, haha", you play it off, "Oh boy, working on the PartnerIntegrationProject this week was awful! Whoever wrote SuperClass created a complete mess. Must've taken 10 hours away from my life."

Everyone in the circle stops smiling. Eric, who wrote that class, nervously chuckles. "Yeah, I guess it could be better, huh?" Oops. Bad move. You feel the energy drain out of the conversation they were having.

You stay silent for the next half hour or so, and everyone keeps chatting, but it feels weird. You keep noticing people's expressions and body language. There's some more forced conversation before a few folks excuse themselves. Then everyone disperses.

And for the rest of the evening, you can't shake off the feeling that everyone's thinking something about you. That you did something wrong. You get a sense that the energy was off, and blame yourself.

But you're not to blame! Everything was probably fine, and no one was judging you. You were just in code mode.

What Happens In Your Brain When You Program?

Ask any developer, and "code mode" is a real thing. We seem to be so drawn into our innermost thoughts of classes, modules, syntax, and systems-- that we lose track of how to mentally function the rest of the time. Some call it "monkey mind" or restlessness, but we all recognize it. It's the brain on hyperdrive, going 200 miles per hour when the speed limit's about 50.

It's the thinking, or rather, the overthinking, that is almost always unnecessary. And for reasons unbeknownst, this always tends to happen when we need to deal with other people.

Now, that doesn't seem problematic, right? Being stuck in code mode is harmless. So you overthink the occasional small talk session, and can't really pay attention to long films, but is it really harmful?

No, not really. But understanding why it happens helps us understand how to make the gear switch a little bit smoother, which is behind my upcoming pitch for meditation. If you're able to leave the programmatic thought patterns behind anytime you'd like, you have greater control over your life.

Of course, we want to be sure of our assumptions. After all, the argument for meditation requires a somewhat well-formed paradigm of what's happening when we read and write code. It's important to take into account exactly which thought patterns we "execute" while in code mode.

What's Going On Up There?

There was a push in recent years to allow programming to replace the study of a foreign language. Around that time, Norman Peitek, Janet Siegmund, and a team of researchers conducted a study that observed 17 participants in an fMRI scanner while they were comprehending short source-code snippets. Their key finding was that despite the stereotype of math and logic being the major concern in programming, the brains of the participants showed greater activation of its language centers than expected.

Now, this may be confusing to you, as it seemingly contradicts the idea of code mode. After all, if the language centers are activated, shouldn't we, as social beings who communicate through the use of language, not be affected by these lingering cognitive thought patterns?

This could be so. But if we dig deeper into the results of the sudy, we actually find that the programmer mind is activated more traditionally than the above finding would suggest:

In essence, we found five relevant activation clusters, all in the left hemisphere.

The function of the left hemisphere is thought to be for control of the right side of the body, and "is the more academic and logical side of the brain". The right hemisphere is associated with creativity, visual/spatial perception, and emotional management and expression.

Because this has been disputed recently, I took a look at what naysayers of the "left-brain, right-brain myth" were saying. It turns out, most of the rejection of this "myth" stems from the fact that people are not usually left-brain or right-brain dominant. However, the fact of the matter is, the left hemisphere is still associated with logical operations and analytical functions, and the right with more "emotional" or "creative" activities.

In fact, a 2013 University of Utah study on brain lateralization examined the brains of more than 1,000 people and found no evidence for people having a dominant side of the brain. Even though each side of the brain does more work for certain functions, such as language being localized on the left and attention on the right, this doesn’t vary by person. All of the study participants, whether they were engineers or musicians, used their entire brain equally, debunking the left-brain right-brain myth.

In addition to programming being left hemisphere dominant, there's also a lot going on. The earlier study referenced found that the activated regions while coding found were:

1. Middle frontal gyrus (division of attention, silent word reading, verbal/numeric problem solving)
2. Middle temporal gyrus (categorization)
3. Inferior parietal lobule (verbal/numeric problem solving)
4. Inferior frontal gyrus (verbal/numeric)
5. Inferior frontal gyrus (silent word reading, problem solving)

If this sounds like a surprisingly high amount of brain activity merely for understanding source code, I would agree. And if it sounds like you'd be surprised if all this happened when trying to sleep or talking to a friend, you'd probably be right. Thus, I'd argue that one should choose to believe that quite a bit is going in mentally when we program, and mostly in the left hemisphere.

But Isn't It Fun?

An interesting note to add is that this kind of intensive brain activity sounds painful in a challenging way, but is actually desirable. Many call it the "flow" state. Courtland Allen and Vincent Woo talked about it in their interview on IndieHackers:

Courtland says:

That's funny because it reminds me of the first two years after I moved to San Francisco. I started a startup and I basically just coded for sixteen hours a day, every day for two years, and the problem is that if you're in flow for that long and you don't vary your activities... you don't make new memories, everything just blurs together, so I have a two year block of time in my life where there were zero memories, and I swore that I would never do that again.

To which Vincent replies:

That's kind of what I suspected happened to that sixty year old plus guy at Amazon, I think he just sat down to code one day and then he woke up, and he was sixty. I don't know, I think flow is both really seductive and also kind of boring in it's own way.

A fascinating take-away of the above conversation is the conflation of two different ideas: flow state and code mode. From our good friend, Wikipedia:

In positive psychology, a flow state, also known colloquially as being in the zone, is the mental state in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity.

Here, I argue this point, and I want to be succint: flow and code mode appear to be two sides of the same coin. That specific coin is neurotransmitter-fueled activity, causing us to hone in one problem (or consecutive problems) for an indefinite period of time. However, we generally use the term flow to refer to the good parts of it, and I'm using code mode as the detrimental aspect.

I think we'd all agree that 16 hours spent on something is not good for your health, mentally or physically. Especially the art of programming-- your back aches, your eyes burn, and you leave the coding session feeling unsatisfied. This is what we want to avoid, and the mental fatigue this imparts on you will carry over to other parts of life.

In fact, here's a follow-up passage from the above Wikipedia article on flow state:

The flow state shares many characteristics with hyperfocus. However, hyperfocus is not always described in a positive light. Some examples include spending "too much" time playing video games or watching television and getting side-tracked and pleasurably absorbed by one aspect of an assignment or task to the detriment of the overall assignment. In some cases, hyperfocus can "capture" a person, perhaps causing them to appear unfocused or to start several projects, but complete few.

But you may be wondering, does this state really carry over to later activities? Can't we "easily turn off" this abstractions level sort of thinking after we're done with it?

Shouldn't the code mode end, and lead to-- say, "happy hour mode"?

Turns out, it's not that easy.

The Stickiness of Code Mode

Patterns of thought stick around. Ever switched schools or jobs, and found yourself en route to the old place?

In Source Code and Cross-Domain Authorship Attribution, the concept of stylometry is discussed. Stylometry is a marker of author identity through writing style, and can be used in source code to identify the author of a program. When I first read this paper, it blew my mind, especially this snippet:

Programmers can obfuscate their variable or function names, but not the structures they subconsciously prefer to use or their favorite increment operators. Following this intuition, we create a new feature set that reflects coding style from properties derived from abstract syntax trees. We reach 99% accuracy in attributing 36 authors each with ten files.

So essentially you have a "handwriting" in crafting software. Your placement of if statements versus ternary statements, your naming conventions, the complexity of your calls, etc.-- they're never pulled from thin air. Rather, you cultivate and inhabit these patterns over time, which is why we recommend studying problem-solving patterns for technical interviews. The patterns also appear to linger in later work.

But of course, we cannot assume causation from this. How you think while programming certainly carries over to other times you write code, but we still haven't substantiated concrete evidence that it's sticky in the rest of life. Why does this pattern of thinking remain when we go to happy hour?

Unfortunately, there doesn't appear to be research on this exact claim, but the mere existence of articles like 7 Tips On Turning Off Work Mode When You’re Not At Work and Your Company (Not to Mention Your Family) Needs You to Stop Taking Work Home shows it's a problem that people deal with. Software engineers are not excluded:

I just really started my life in the professional world. I am a very active, 24 year-old. I am used to lifting/running 3-5 times a week, maintaining a blog on the weekends, and going out 1-2 nights per week. Since I started the new job, I am coming home DESTROYED. I can't motivate myself to workout, clean my room, or anything. The job itself isn't very stressful, though I am sitting down for long periods of time. Any ideas on whats going on or how to get out of this funk would be most helpful!

I won't continue to belabor the point. Clearly, your work as a software engineer has sticky, lingering effects on the rest of your life, especially with regards to patterns of thought-- and how much you think. Those patterns, be they negative or positive, will lead to other thoughts of the same nature and magnitude. Learning to control this mechanism, and not letting it master us will prevent overthinking and the overuse of programmatic paradigms outside of writing code.

“The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities,” said Edsger Dijkstra, of Dijkstra's Algorithm “It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.”

The awkward social interaction presented at the beginning is merely one manifestation of this. The necessary amount of thinking and abstraction-handling to correctly fix a bug is overkill for other situations. Knowing when to, quite literally, get out of our heads, can be tricky. Luckily, there's a tool everyone knows about but probably doesn't practice.

The Mindful Programmer

What’s happening in the brain when meditating?

I can't speak for other techniques, but when you practice mindfulness, you're doing one of two things:

1. Simply noticing feelings and thoughts as they come, and more importantly, go away.
2. You're coming back and re-focusing on being aware of the present moment.

Originally an ancient Buddhist meditation technique, in recent years mindfulness has evolved into a range of secular therapies and tools for the restless mind. And the term"restless" doesn't need to be chronic-- in fact, challenging software engineering leads to this type of mental chatter, for the mental dialogue we turn on helps us solve hard problems.

The purpose of meditation is to help one see the world more clearly. Programming, I would argue, is the opposite-- there are quite literally abstractions (that is, layers of models) that take us away from real life.

How I've Benefitted From Meditation

As a programmer, I noticed I used to live the beginning scenario all too often. Between work and side projects, I was constantly sucked into a screen, practicing the act of holding onto a million things in my head and ignoring everything in search of that hit of dopamine. I stayed in the mode for hours, even after logging off, overthinking every interaction and situation. I found I had a serious inability to just enjoy the present moment, and let go.

Now, if I find myself in that mental position, I meditate, even if just for a few minutes. It's like a release valve that waves goodbye to the day's work, and moves me onto the next activity. The simple act of focusing on my breath, noticing my environment, and feeling my body appears to release the body's problem-solving tightness.

It lets me move beyond the code, the internet, and the world of screens.

Because when all is said and done, you might be like Vincent Woo.

I can't do it anymore, I can't program for eight hours anymore, like I tried, I just can't do it anymore.

Sources:

• https://www.psychologytoday.com/us/blog/brain-wise/201904/the-science-habits
• https://www.huffpost.com/entry/scientists-begin-looking-_b_4829981#:~:text=A%20new%20study%20provides%20new,brain%20devoted%20to%20mathematical%20thinking.
• https://pdf.sciencedirectassets.com/280203/1-s2.0-S1877050916X00130/1-s2.0-S1877050916311164/main.pdf
• https://www.nccih.nih.gov/health/meditation-in-depth#:~:text=However%2C%20in%20a%20second%202013,brain%20areas%20associated%20with%20craving.

What are their secrets?

I've recently had the opportunity to spend a considerable amount of time with some friends who are thriving. These individuals are "successful" in both the traditional financial sense, as well as in the way of all being top performers who truly enjoy what they do.

Because they were people I wanted to be like, I naturally took some mental notes about their habits and quirks. I have a possibly unhealthy, but hopefully all too human, tendency to try to find patterns in people who inspire me. This stems from the idea that, if I could just find that one additional commonality that's shared amongst them - whether it's meditating, reading, working out, taking nootropics - I could do the same and emulate their results.

Big Wins versus Distractions

Ramit Sethi has written about this idea of Big Wins vs. Distractions before. Big Wins are the important items to tend to. Distractions are aptly named as such. As an example, a personal finance big win could be setting up automatic investing into a target-date fund. The counterpoint distraction would be to "agonize over 13 different money apps".

You can find examples of this in any field of interest. For students preparing for a standardized test, the big win could be taking practice tests and reviewing them. Distractions in that scenario include being choosy about the brand of their study materials, or spending time figuring out which section is an experimental one.

Another way to describe this phenomena is as an expression of the power law. Here's a great description: it implies a small amount of occurrences is common, while larger occurrences are rare. For example, where the distribution of income is concerned, there are very few billionaires; the bulk of the population holds very modest nest eggs. I've learned that this readily extends to one's career and professional life.

(Image Credit to EdgePerspectives)

Sound familiar? This is also the basis of the famous 80-20 principle.

Does the Slight Edge Exist?

Every time I make mental notes about what breeds success, I quickly realize this: for every person who does one thing, you'll find someone in their same standing who does the polar opposite.

For example, I went to a conference recently with a buddy who's had an impressive track record in the open source development community. He made Staff Engineer at an early age, and had been featured in several media outlets for his work.

One thing I noticed about him was his tendency to always be learning. This isn't an exaggeration - it seemed like he was constantly absorbing knowledge. We shared a room, and I observed that in any free time that he had, outside of the main conference events, he was learning.

I'd wake up, and see that he was on his phone, checking Twitter for updates from those he followed, mostly developers themselves, who had a habit of teaching quick software tips or thoughts in 280 characters.

Whenever we were waiting for the first talk of the day to begin, he'd review the videos and blog articles of many of the speakers of the day. He was particularly fond of dipping his toes into subjects or areas he wasn't familiar with. When we would get back, he'd start reading a book he had brought on the trip, on something completely different from his line of work.

I thought, oh wow, I'm on to something. Perhaps his results stem from the fact that he keeps up with learning. Learning is the secret to success. I'm going to learn something every day!

(Image Credit to BrainPickings)

Then I had the great fortune of immediately spending a weekend with another wunderkind in tech. Like my first friend, he had speedily risen through the corporate ranks and had achieved a reputation of getting things done in his sector. Yet shockingly, his behavior was the exact opposite of the other's.

At any free moment, he was on social media or gaming on his phone.

He was up all hours of the night watching sporting clips.

I asked him what books he'd been reading, and he said he didn't really read books.

I thought, wait, I thought learning was how you propel yourself to greater heights. But this second friend doesn't seem to care and he's doing so well. What gives?

Too often we miss the forest for the trees in our careers. We focus on how our social media profiles look, or prioritize keeping up with the latest New York Times bestsellers. We let the distractions drag our focus away from the big wins we could be making. We forget about the power law.

Commonalities

In the case of these two friends, their overlapping behaviors were concentrated in one place. The only shared quality between the two friends was an intense interest in their work. Notice I didn't say passion - it was just pure excitement to approach the tasks at hand.

Both talked about their upcoming work to anyone who would listen, and were constantly thinking with others about pushing the boundaries of their work. Both were pulled into meetings while we hung out, and both were actually excited to have the discussions with people they enjoyed working with. Both had bet their careers on products that they really intrinsically liked.

Back to Boring

As boring as it is to say that doing good work is the secret sauce to professional success, it bears repeating. In an age of too many thought leaders lacking substance, let this serve as a reminder to refocus on where the true value is. You can try to decipher what your role models do outside of their craft, whether it's what books they read or how they wear their hair, but don't neglect the thousands of hours spent on the craft itself. All the meditation in the world wouldn't have made Ray Dalio a billionaire had he not competed in the financial realm and only read books about prominent financiers.

It's certainly important to be aware of the influences of others, and to know when to step in and out of a situation. However, there is an inherent power law when it comes to careers, and most of what you're looking for derives from a very small number of inputs. Keep on honing your craft, going deep and mastering what you can, and the results will surprise you.