My Love-Hate Relationship with Stack Overflow

Introduction

As developers, we probably couldn’t live without Stack Overflow. When you get stuck on a problem, you Google it, and the first hit you get is a post on Stack Overflow, usually with a line (or lines) of code that solves the issue you’re facing.

Don’t get me wrong. I love Stack Overflow, and it’s not that specific site I’m addressing here. Rather I’m more so describing the mindset you fall into when you’re searching for answers on there or on similar Google results.

More and more, I’ve started to realize that, when you’re trying to solve a problem, finding an answer that works shouldn’t be the end of your search. Very often in my early days as a developer, I would skim through a guide or article just to get the code samples I needed to finish my task. While this gets you from point A to point B in your work, it limits your ability to solve a trickier variation of that problem you might encounter down the road.

We all dream of getting to a point where typing out your code becomes second nature, but I’ve begun to distrust that feeling. As soon as a procedure becomes muscle memory (boilerplate, as we call it), I wonder if I’ve stopped thinking about why I’m doing what I’m doing.

More specifically, what does this mean?

I’ll give an example in iOS because that’s what I do. But whether you’re a mobile developer or not, I think this experience applies to anyone in this field.

In the world of iOS development, there are many ways to build a screen. Whether it’s UIKit or SwiftUI, even each option has its own different approaches.

In programmatic UIKit (i.e. writing Swift code instead of dragging and dropping elements onto the Storyboard), it’s an essential step to set the translatesAutoresizingMaskIntoConstraints flag to false for any view in your code. If you don’t, the system ignores any constraint you set on your subviews, and none of the UI elements on your screen will align correctly. We don’t have to write this if we were creating views from Storyboard, so you might miss it out if you were doing programmatic UI for the first time.

Now, this is such a simple implementation. Once you figure it out, most of your programmatic constraints will work as expected. Especially because this translatesAutoresizingMaskIntoConstraints property is such a mouthful, it’s easy to ignore what it actually means instead of asking what it actually does. You just sort of do it according to the Stack Overflow post.

However, we would miss a lot of important questions that shed light on what we just wrote.

• What if this value were true? What does making it true actually mean?
• What is an autoresizing mask, and what does it do?
• Why didn’t I have to do this in Storyboard?

These questions lead you deeper past the post you found. They lead you to official docs like this and this. So you read through the discussion points and you kind of recognize some words. Then you start to ask more questions based on those words, and all of a sudden, you’re reading through a guide on understanding the ins and outs of Auto Layout.

I won’t dive into the details because this isn’t an iOS article, but you get the idea. From this very long variable name, there’s a lot of information to dissect, and the more questions you ask, the more details you find on the Internet.

As an aside, I especially find that digging through the open source code for your language or framework provides you with the most insight. When you do, you get to step through and see first-hand what this specific method or property actually does under the hood.

In Summary

My point here isn’t that we should aim to know every nitty-gritty detail about the language or framework we’re using. My point is that following this line of thinking when we’re developing helps us grow to become more curious. It trains us to figure out what type of questions to ask, which in turn, deepens our capabilities as a developer.

Maybe diving into a framework’s source code or documentation helps you, or maybe you’ll never actually use any of that information again. But I’m confident in the mindset of digging deep into the internals of the tools we use. It’s the key to finding our way out of those spaghetti bugs we encounter 1% of the time but spend days and days slogging through.