Ask HN: How do you stop feeling overwhelmed when programming? | Hacker News Reader

Ask HN: How do you stop feeling overwhelmed when programming?

1 pointdiminium7 comments

The same could be said for business but for this question, how do you stop feeling overwhelmed when programming for the big picture?

Programming one piece is pretty simple (usually). It's when I start adding more and more and more and more that I'm starting to feel overwhelmed by the machine. I know how each part works if I think about each part individually. I also know how I want the big picture to look. It's the middle that causes me to "feel" overwhelmed even if I take a few deep breaths, I can explain how it works.

The most overwhelming feeling is when parts of the program are decoupled from one another because it's the best solution to decouple them. The feeling I get from checking the couplings to see if it matches the big picture makes my stomach churn. One obvious example of this is going from JavaScript to HTML to Server Code to SQL. Is this actually going to produce what I want too see?

So, how do you stop feeling overwhelmed?

It's hard to give you any specific advice without knowing a lot more about your level of experience, your understanding of different programming paradigms, best practices, etc.

Having said that I remember feeling like you're feeling on my first one or two software projects (before I had actually considered becoming a programmer). I remember reaching a point in those projects where the complexity had reached a level that my brain sort of "gave up" and I found I couldn't progress on them anymore. I think I was living under that fallacy that I had to understand the whole project at any given time.

Fast forward many years and many shipped products and I certainly don't feel that way. In the broadest sense I think I've learned to embrace ignorance in software development. Developing reusable code is a formalization of that. If you're writing software to be reusable and easy to use (not easy to understand internally) you don't have to have a sense of the big picture, or the whole picture.

If it is the case that you're new to programming, I would suggest limited scope as much as possible. The "simplest" project is always more complicated than you (or I) would imagine. Try creating a very, very small project but take that project to completion.

Alternatively, if you're hitting the complexity wall with what sounds like it could be a fairly straightforward web project, you're probably not leveraging the available tools as much as you should be. If you think that applies pick up a book on RoR or Django, download either of those, and try to build your project (or a simpler version of it) with those tools.

You should also consider picking up a book or two on programming best practices. The problem you're attacking with your software may be unique, but writing big (and small) software projects is a solved problem. There's lots of good advice out there on how to structure a big project, how to write reusable code, how to do basic testing, etc -- all of the techniques people have figured out for making large projects manageable.

"Fast forward many years and many shipped products and I certainly don't feel that way. In the broadest sense I think I've learned to embrace ignorance in software development"

So embrace ignorance? I could always go back to that but I'm wondering at what point do we grow? Things were much easier when I was ignorant of stuff and just pushed forward.

I did that for quite a long time. It created products but none of them were superior or great with most of them ended up being average.

I'm trying to climb that wall from just creating average things into creating something greater. I'm not sure how without being overwhelmed.

Wow, missed this one. I no way did I equate "embrace ignorance" with "embrace mediocrity". You misunderstand me. What I mean is that you have to write code in such as way that you don't have to understand previously created parts. They should be designed in a way that they just work -- they are easy to use and use without error.

"They should be designed in a way that they just work -- they are easy to use and use without error."

But how do you learn how to do that? For example, making an API. API's, once released into the wild, should never be changed (unless your hugely popular like Facebook). Public changes breaks code.

I look at some of the most popular API's. They look easy but I don't know how they got to that point. They had an infinite amount of choices yet they choose that particular way of doing it.

Very few, if any people can keep every detail of a system as complex as a modern piece of software in their head at once. As developers we just have to accept that. Understanding the big picture, and how all the parts of a picture fit together is still important so rather than trying to load everything into our brains at once, we can focus on a part at a time and develop a good test suite that will point out the effects of any changes so you don't have to try to anticipate them and can focus your energy on he problem at hand.

Expanding on that, having a good set of automated tests gives you confidence that all the pieces of the system fit together properly. With good tests in place, you can focus on changing a small part of the code without having to understand how it relates to every other part of the project. If the small change affects anywhere else you'll see this in failing tests.

If you aren't already, start writing unit and integration tests for your code. It can feel like unnecessary overhead at first but you quickly reach a liberating point where you can lean on the tests to tell you how any changes affect the bigger picture.

"so rather than trying to load everything into our brains at once, we can focus on a part at a time and develop a good test suite that will point out the effects of any changes so you don't have to try to anticipate them and can focus your energy on he problem at hand."

Hmm.. Let me ask you something. There's a ton of lectures and blogs written about TDD and what not. Do you consider them mostly valuable or do you consider most of them to be junk?

Testing.

Reply on news.ycombinator.com