In software, a stack overflow occurs if the call stack pointer exceeds the stack bound.
Wikipedia
A stack overflow is, in short, bad. It means that more information has been crammed into memory that can fit and there’s nowhere for new information to go.
Stack Overflow, with a capital O, is the overwhelmingly popular website for finding answers to specific problems programmers have stumbled across. It has saved my butt more times than I can count when facing particularly obscure issues.
I once worked with a guy who used Stack Overflow as his primary tool of solving problems. Today, he might be the one who always has a ChatGPT window open while coding. By combining Google Search and Stack Overflow, he seemed to let the web do all his critical thinking for him. Rather than thinking through a problem or learning about syntax, he would search for answers and copy them from the internet.
I didn’t think anything of it because it was early in my career. While I did (and still do) use Google and Stack Overflow, I was doing something in parallel that he wasn’t doing.
I read the C# Programming Yellow Book, The Pragmatic Programmer, Programming .NET 3.5, HTML and CSS: Design and Build Websites, JavaScript and JQuery: Interactive Front-End Web Development, and more. I read everything I could get my hands on because I was hungry for knowledge.
Leverage my ten years of software engineering experience to find a tech job that matters, get hired, and get paid what you deserve.
It’s all in my book, Handshake Protocol – the step-by-step guide to getting hired as a software engineer.
I built side projects to prove to myself I was learning, my best creation by far being a website for vampires to help them calculate the overall interest they would pay on 100-, 500-, and 1,000-year mortgages.
After six months or so, I noticed I relied less on Google and Stack Overflow. It was painful to see my co-worker Googling simple syntax errors or logical conundrums and copying solutions into his code, only to see it fail. He was learning one tiny piece of the programming puzzle at a time, reactively, while I was proactively following a trail of curiosity in an attempt to understand the whole puzzle. I wanted to understand what the picture on the box was and what each piece did.
Industry standard lessons learned about how to architect programs, organize code, what technology to choose and why given certain circumstances, these all were aspects of programming I was learning from books and applying in projects. They were not learnings that showed up in Google searches for how to connect to a database inside a loop.
Years later, I read Limitless Mind by Jo Boaler. In it, I discovered that there is empirical evidence that supports the theory that there are no limits to what we can learn. The concept of a growth mindset is referenced within it quite a bit. Although that term is bandied about in corporate culture to the point of meaninglessness, the underlying neuroscience indicates that we can leverage our brain’s ability to forge connections between neurons in a virtually limitless way. If we become curious life-long learners, there is no summit. Find your curiosity and learn the fundamentals.
Not to worry, at no point in time will too much information be crammed into our minds. At no point will there be nowhere for new information to go.
