Debugging Abstractions: The Benefits of Mindfulness for Software Engineers

By Jake from AlgoDaily on 2020-07-02 12:27:28 UTC

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.


The Power Law and Your Career

By Jake from AlgoDaily on 2020-01-01 09:55:48 UTC

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.

Power Law
(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.


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.

What Programmers Can Learn From Rappers

By Jake from AlgoDaily on 2019-07-12 14:18:13 UTC

I was fortunate enough to grow up in Queens, New York, which contains many of the literal most diverse zip codes in the world.

This meant that growing up, I was exposed to a lot. Obviously I experienced Chinese language, culture, and cooking at home-- but I also went to school, church, and played basketball with the local Irish, Filipino, and Puerto Rican kids. Then I went to Bronx Science and saw the dichotomy between its adolescent culture and what the rest of the neighboring Bronx schools had to offer, before attending CUNY and Fordham and seeing two completely different socioeconomic levels.

All that's to say, my background is pretty eye opening for most people around the world, though it's pretty common to New Yorkers. These experiences were also what introduced me to perhaps two of my favorite loves in the world-- computer programming and rap music.

Though they seem completely unrelated at first, they do share some commonalities. Otherwise this video of Nipsey Hussle investing in cryptocurrency wouldn't be as captivating as it is. And of course, you wouldn't have Ben Horowitz quoting rap legends in the beginning of every chapter of his book.

What could they possibly share in common then? It's firstly the endgame: programmers and rappers want the same things:

  • A sense of "making it", from either getting signed to a deal or joining a public software company
  • Status, from either Platinum albums or Twitter/Github mentions
  • Influence in their small circles (e.g. BET Hip Hop Awards, MET GALA, etc. versus tech conferences )

And what's the most interesting commonality?

Both professions are writers, simply using different mediums to express their thoughts.

Computer programming and software development is literally taking the knowledge and solution in one's head, and expressing it in symbols that a machine can understand.

Rhymes and bars are poetic memoirs of one's current state of mind.

They also share a need for a flow state. When Kendrick Lamar wrote "Bitch Don't Kill My Vibe", he was talking about being in a frame of mind where he could innovate, create, and harness his mental powers without distraction. If you're a developer, you know exactly what I'm talking about here.

Since most of you reading this will be programmers (hello to the few rappers reading this blog), I think it would be interesting to explore some things that software engineers can learn from hip hop artists.

Requirements, Winning, Copycats

You gon' have to pay the price if you get wishy-washy / This a Tallageda Night, I think I'm Ricky Bobby / My advice quit the music, get the different hobby / All you ***** sound the same, just a different copy - Joyner Lucas, Broke and Stupid

These bars are underrated as hell, bro. So many gems here.

Without clear requirements, "wishy washy" asks are going to lead to failures of projects. They are also, indeed, usually very costly-- so make sure that you know exactly what you're trying to build before starting to code.

Secondly, Ricky Bobby in Tallageda Nights was all about winning initially. However, winning (and trying to be the "rockstar developer") got him in a world of hurt and trouble. You ultimately have to realize software is a team sport, and that ninjas/rockstars/superstars hurt morale instead of boosting it.

The last two lines are especially true for developers who identify as IndieHackers. You don't want to be a copycat. AlgoDaily is not like any other interviewing site-- it is meant to be the ultimate remix, and serve as a career coach, habit tracker, and community combined into one simple platform. If you "sound the same" as a rapper or developer, go find yourself a niche that you can excel in.

Career Advice From Kendrick

I was born like this, since one like this, immaculate conception / I transform like this, perform like this, was Yeshua's new weapon / I don't contemplate, I meditate, then off your fucking head / This that put-the-kids-to-bed, this that / I got, I got, I got, I got / Realness, I just kill shit  / 'Cause it's in my DNA - Kendrick Lamar, DNA

Kendrick drops a lot of hidden gems in his bars, but this is one of my favorite. What he's saying here is for top performance, you need to be at 0 or 100, but never in the middle.

That is, you either need to be meditating, or kicking ass. You need to be putting kids to bed, or killing shit.

This is because software engineering is not just a mental game, but a physical one-- long hours slouched in front of a screen wreck your body. If you want to really attain peak performance at all times, you need to be willing to be an absolute bum sometimes.

Yishan Wong, former CEO of Reddit, has written about this before:

Exceptional focus does not mean that you are able to work during all your waking hours. During your "downtime" (time when you are not being productive but also not sleeping), don't try to work on lower-priority projects. Instead, make sure you are goofing off. The most focused people maintain focus over long periods of time (months, years) rather than working obsessively on something over entire days (which is likely to lead to burnout), so make sure your daily schedule involves breaks where you deliberately don't do anything productive. The idea here is to not fatigue your mind with focus, but to continually "re-attract" it back to the thing you want to focus on.

This is why AlgoDaily advocates just one problem a day. Not two, or five, but ONE. One a day gives you the rest of the day to do whatever you want.

You know this'll never be a tie, just look at they laces / You know careers take off, just gotta be patient.

These words came from Kendrick Lamar.

Yep, that Kendrick Lamar. The man behind HiiiPoWeR, Swimming Pools, Humble, and many more huge hits. If there's one guy who can lay a claim to king of the rap game, it's him.

But did you know he started rapping and making music at just 8 years old? It was when he witnessed Tupac and Dr. Dre film California Love. From then on, he knew exactly what he wanted to do.

He didn't achieve commercial success, however, until Section.80 came out in 2011-- meaning he had to hone his craft for 16 years before blowing up.

Careers take time, but don't worry. Your competition is rarely as prepared as you, provided you do just a little bit each day-- because ultimately, the average person does zilch to improve upon their standing in life.

New Developers Are Trying Their best

I'm just a man of the people, not above but equal / And for the greater good I walk amongst the evil / Don't cry, Mama, this the life I choose myself / Just pray along the way that I don't lose myself / This is for the ***** that said that Hip-Hop was dead / I went to Hell to resurrect it / How could you fail to respect it? - J. Cole, Let Nas Down

Look, Javascript was my first programming language, and it doesn't feel great when older developers trash the Javascript ecosystem.

Yes, there are some libraries written that aren't up to par for production use, and it seems like there's a new framework every few days-- but to new developers, as J. Cole says, "for the greater good I walk amongst the evil".

This is the environment that new developers are coming into-- the world where programming mostly happens in, or for, browsers. As a result, the average "not above but equal" developer is coming into a terribly chaotic world and trying to make sense, and their dent, in it. It's not easy.

So give the new wave of developers some respect. They are coming into a web full of unlimited possiblities, but very little guidance (many are now self taught through sites like this), to make things. That is difficult, and bad works will happen, but great things are coming out of it too. And that's progress.

$60k to Learn to Code, And Why I Built a Leaderboard for AlgoDaily

By Jake from AlgoDaily on 2019-07-06 01:43:43 UTC

When you hear the term "peer pressure", what immediately comes to mind?

Many people will quickly think of associations with bullying, bad decisions, and building anxiety. The immediate reaction to "peer pressure" is usually a negative one, and generally folks would agree that decisions made without influence from members of one's peer group are better than ones with.

That's definitely a fair assessment. After all, many bad acts throughout history have often been a result of someone being forced to do things they wouldn't have individually done. There is a significant amount of evidence that social influence is an effective and strong force in motivating people to abuse substances, commit criminal acts, or make otherwise poor life choices.

Peer Pressure For Good

On the other hand, Seth Godin makes an intriguing point in his article, Digital Peer Pressure, saying that peer pressure can used for good:

But the digital peer pressure that pushes us to use social media a certain way can also have more positive effects. It can challenge us to understand the details in that Do lecture or to edit a Wikipedia article to make it better. Digital peer pressure can push us to level up.

Thousands To Learn to Code

Though Godin is talking about peer pressure online, it applies to real life as well.

I've used this insight in the past-- believe it or not, social influence was the only thing that allowed me to learn to code. As I wrote about in The Best Way to Learn to Code, I initially tried to teach myself, but could never keep up a practice. I'd do a tutorial here and there, and perhaps skim a programming book, but would fall off the wagon for weeks afterwards.

However, the second I enrolled in a university program, it was mentally a different ballgame. The first class I took as part of the prerequisites, Introduction to Computer Programming in C++, was significantly harder than the most challenging resources I had previously used to teach myself. However, by the end of the class, for the first time ever, I could code a working program alone. Why's this?

The social pressure. I didn't want my family and friends know that I dropped out of the first class. I didn't want to be the only student in my cohort who didn't turn in their assignment. And I certainly didn't want my brilliant professors to think poorly of me.

Regardless of whether I should have cared about others' opinions, the subconscious desire to look good worked in my favor, and ultimately launched a new and fulfilling career for me.

So with that said-- I'm proud to announce that AlgoDaily has a new feature: the leaderboard. It's meant to be just a bit of peer pressure to challenge and inspire you to do the daily practice of solving a problem.

Today, it tracks just two metrics: number of challenges completed, and days in a row that a user has done a problem-- but we'll be sure to expand this. Can you get on it? If so, where do you fall on it?

What's the Leaderboard For?

The same way that The 4-Hour Chef was a guide to rapid learning that had been masked as a cookbook, AlgoDaily's purpose goes beyond passing a technical interview.

Instead, it's about having a system, any system, that incrementally moves you toward your goal regardless of the direction luck sways.

It's about cultivating daily habits that ensure you're at least a little bit better than yesterday in any area of life.

It's about having a community and peers on the same path that motivate you to get better, slowly but surely.

This is also why we have the AlgoDaily community. After every question, you'll see a link that says "Having trouble with this question? Click here to ask the community for help"-- which will bring you to helpful discussions like this one.

I'm hoping that this message gets people thinking of ways social pressure could be used as a force for good. Until then, can you get on the leaderboard?

P.S. - I am in the works on open sourcing the entire AlgoDaily curriculum-- more to come soon. The goal is to improve upon the quantity of questions, build more test cases, and write the solutions in other languages. If you've benefitted from AlgoDaily, and would like to help me prepare the curriculum to be open sourced, please comment or shoot me an email at Together, let's create the largest open sourced repository of technical interview challenges so that any developer can be economically empowered.

Forget Thought Leaders, Seek Out People Who've Actually Done Shit

By Jake from AlgoDaily on 2019-07-03 14:25:33 UTC

In recent years, due to the abundance of communication methods both electronic and analog, the concept of the influencer has been brought to center stage.

We're talking about "thought leaders". These men and women are supposedly deemed experts in their field, knowledgeable about the world in ways the common person cannot comprehend, and are impeccably mimicked by their followers in every way.

With their huge social media, blog, or mailing list followings, their ideas command the absolute attention of their listener or reader's minds, and often subtly-- very humble-braggingly, implant this notion that they know best, and they know better than you.

This idea can be devastating. We humans are social animals, and will thus have a tendency to seek out wisdom and advice externally. This is how we as a society have improved upon shared knowledge over thousands of years, and there's nothing wrong with this habit-- the key is to be discriminatory in your absorption of such information.

I'm here to to remind you of this quote by Steve Jobs, who himself idolized, and was idolized by, so many:

Life can be so much broader, once you discover one simple fact, and that is that everything around you that you call 'life' was made up by people who were no smarter than you. And you can change it, you can influence it, you can build your own things that other people can use.

I would argue that we should especially emphasize the "no smarter than you" aspect.

Look, the internet has given a voice to many brilliant people with wonderful ideas to share. This has led to incredible gains in education, science and technology, enabling meritocracies, and economic growth.

It has also birthed a movement of folks who don't have anything to say, but say it anyway. You can sense the lack of substance-- they are the self help gurus whose only value is rehashing the experience, the teenager sharing career and branding advice on social media, the wantrepreneurs who critique the works of others while never producing themselves.

They are a loud group that pervades your feeds. When it's so easy to influence widely (the barrier to entry being a simple internet connection) it can be hard to tell what advice is good, and what is not.

I want to stress, in a similar vein that Jobs did, that these "thought leaders" are not leading any different thoughts than you are. Yes, kudos to them for putting out content, even if most is void of value, but they are just creators until their work has certified their proficiency.

And what of the perception of expertise, of knowing something you don't? Well, they may know just a bit more than you in some small areas, and there might be some value derived. This aspect of our modern information overload could obviously be helpful, but the key is to use your judgment and not blindingly accept an influencer's gospel. And even more importantly-- do not put them on a pedestal.

They do not have all the answers to life, and can sometimes be very open about this.

Here's what Tim Ferriss has to say:

Though I’ve occasionally done profiles like A Day In The Life with Morgan Spurlock’s crew, I rarely let journalists follow me for a “normal” day. Why? I’m no superhero. I’m not even a consistent “normal.”

Think for yourself and be discriminatory in the advice that you seek. I have a general litmus test for authors and writers of non-fiction in particular:

Is this person undoubtedly experienced in what they are teaching?

In programming, this is easy: if they're walking you through how to build a Vue app, they by definition must have done it before. It might not be clean code, nor the "right way" to do it-- but it's hard to falsify getting an app up and running. If the divs load, and the content renders, and it looks the way you want-- then you've gotten the result you want.

We don't do this enough for non-technical knowledge, and that's a shame, as it's now more important than ever to parse through all the advice and knowledge for what will actually be helpful to you. But it's actually really easy to do. Just focus on asking the following two questions:

  1. What am I trying to learn to do or be?
  2. Has the teacher done this thing? Or have they demonstrably embodied this principle?

With that said, I'd like to leave off with some of my favorite books by people who've actually done shit. Heads up that these are affiliate links that help support the costs of running AlgoDaily:

Get Free Daily Interview Problems

We'll send you over 100 of the most common coding interview questions, once a day with visual explanations. Join over 16,323 users who are doubling their salaries in 30 minutes a day. All subscribers get a free 86-page preview PDF with a week of study material.

Latest Posts

Ready for your dream job?

Welcome to the most accessible guide to technical interviews. AlgoDaily was created to be a gentle, visual introduction to patterns around solving data structures and algorithms challenges.

We believe that technical interviews are a matter of practicing well. We've referenced hundreds of resources on habit change, education design, and algorithms to design the best and most streamlined learning experience.

Start the course now

Subscribe to newsletter