I was talking to my friend Abhay recently, and he brought up a very interesting idea. He works at a software startup that’s still relatively small, which means that there’s a certain amount of pressure to make quick progress and produce results. This requires having to churn out functioning code on a regular basis. Unfortunately, it’s often easy to write code by pattern-matching or copying from other sources – but an entirely different thing to fully understand, and internalize what you’re doing. In the long term, only the latter will stick with you, making you a better engineer. Obviously, there has to be a healthy balance between the two. The problem though is that companies are typically paying you to do the former, while not always incentivizing the latter. This is what he said about his job

I'm not here to get things done. I'm here to learn. Things will get done as a side-effect of what I learn.

I strongly believe that it’s largely your responsibility to ensure that you’re learning, and not succumbing to the pressure to show progress. The reason I liked his point of view was because it’s a good attitude to have, and helps to set expectations. In my own work, I have certainly written code I didn’t fully understand, had it compile and pass all tests. It’s easy to feel accomplished doing that, but important to remember it’s not the end goal.

- nRT