Congrats! I remember seeing posts from you now and then about how you were learning programming. (IIRC, your first contact with programming was for the demo to get your track jacket?) It's great that you kept at it.
My first task was to add a dismiss button on a Javascript popup. I thought the task would be easy, but each page actually has dozens of files of code fitting together to make a page work– style sheets, controllers, distributed all around the code base. (…) Instead of being off-put by how long it took, or being overly sympathetic, he just said, “Yup. That’s what development is. It’s very frustrating until it works.”
I'm currently in a similar situation, working on a project with a guy who uses libraries and frameworks I know very little about and it honestly frustrates me. I've had other things to do on the project so far, so I've postponed digging into it.
But it makes me wonder if that's how things should be. Often you're fine once you're beyond the breaking waves of setting up your environment and getting a grasp on the codebase, but before that, it can be very frustrating… especially, when you want to implement something, that you theoretically know exactly what you want and what you need, and you get slowed down by some problem with library incompatibilities or what not.
I think the lecture is broader here. Frustration is really at the core of programming. And whenever you're frustrated, thats a wonderful lession ahead of you in understanding what makes the systems tick that you take for granted.
I've recently had the pleasure to drill down (from C) to single machine instructions in my quest to understand why a conditional branch was seemingly having no effect, on an architecture that I couldn't debug on. As it turns out, the compiler would sometimes use a memory addressing scheme that wasn't supported on this particular architecture. I had to work around this bug by writing assembly that correctly accesses the memory.
It's incredibly frustrating when you end up at a point where the only abstraction (and seemingly faulty) layer below you is nanometer-sized transistors. And all the more rewarding when you reveal the actual problem and get to extend your knowledge.
(Of course, this doesn't really apply to all the ridiculous pain points that annoy us by design. Things like browser compatibility come to mind.)
I can certainly enjoy figuring out what's wrong sometimes (and unravel the whole string of events: "oh now that makes sense: this was happening which made this and that behave that way") and I the satisfaction you're referring to; but other times, it's just so far removed from the real task at hand that it's not even funny.
A recent example would be when I was trying to set up my local environment with virtualenv, whose whole purpose is to make that easy. Everything seems fine but pip (Python package manager) was throwing errors. The culprit was that virtualenv creates Python scripts in the local directory with a hashbang for a local version of Python. The thing, it turned out, is that hashbangs don't work when there's a space in the path. And there was a space in my path because I wanted to use Box's sync folder which (stupidly I must say) is called "Box Documents". Now I know.
Long story short, the point is that I wasn't trying to debug virtualenv but had to dig deeper than I wanted into it just to get started on the problems I created. :)
Though you're right: just recalling this, I have a feeling of victory over the problem.
I think the biggest lesson for me was that in programming things aren't necessarily there for a reason. Method and class names are arbitrary and part of the "creative" side of development. One of the best skills to learn is to read arbitrary code and be able to pull out the concepts and ignore the "design" on top.
My first task was to add a dismiss button on a Javascript popup. I thought the task would be easy, but each page actually has dozens of files of code fitting together to make a page work– style sheets, controllers, distributed all around the code base. (…) Instead of being off-put by how long it took, or being overly sympathetic, he just said, “Yup. That’s what development is. It’s very frustrating until it works.”
I'm currently in a similar situation, working on a project with a guy who uses libraries and frameworks I know very little about and it honestly frustrates me. I've had other things to do on the project so far, so I've postponed digging into it.
But it makes me wonder if that's how things should be. Often you're fine once you're beyond the breaking waves of setting up your environment and getting a grasp on the codebase, but before that, it can be very frustrating… especially, when you want to implement something, that you theoretically know exactly what you want and what you need, and you get slowed down by some problem with library incompatibilities or what not.