Programming: Doing it more vs. doing it better

> Three years later, I am still very much the apprentice.

Well, three years is really not a lot when it comes to developing an intuition. Just enough to grasp some basics.

> a writer is someone for whom writing is more difficult than it is for other people

Yeah, I seem to recall Douglas Adams saying that the easier it is to read a text, the harder it was to write it.

At the beginning of my career I was constantly being praised for how fast I work. Well, I did stuff that worked, the effects were quickly visible, everyone was happy.

Even though there were code reviews to weed out the ugliest stuff, I wouldn't want to go back and maintain that software today :P

For me the best analogy is a carpenter tightening screws. When you start out solving a particular problem part of the scope and required functionality is always not 100% clear. So you start out with an implementation which favors flexibility over things such as DRY or performant. As you learn more about the problem you start to optimize.

One of the biggest mistakes (the biggest one is probably not writing tests) I see junior engineers make is trying to optimize before fully understanding the required functionality.

Part of me feels like bootcamps are effective for some because you will inevitably start getting it when you do it for 15+ hours a day every day for an extended period of time (which is more than you’d likely do on the job or in a more theoretical CS degree)

Someone who's been programming for three years is still a beginner, even though based on what he wrote here, Kevin is almost certainly a lot better than I was when I'd been programming for only three years.

I do find that a lot of programming stuff that used to be hard is easier for me now that I've been progrmaming for 38 years. But that doesn't mean I spend all my time doing things I can do without thinking, and it certainly doesn't mean I write code that doesn't need refactoring. Maybe my designs are better than they used to be — I think so — but often that's because I developed the design more incrementally through refactoring, rather than less incrementally by planning.

I do avoid a lot of errors by thinking through the consequences of a choice before taking action, in a way that I couldn't always do. But often that choice is specifically the choice to plan out a big design at the start of a project.

Also, though, what counts as "big" has changed for me. What I can hack together in an afternoon now might have taken me a week ten or fifteen years ago. So I can explore alternatives with less risk, in a way.

The author describes a lot of anxiety and guilt about doing things imperfectly. I think that's a big obstacle to improvement — other people can pick up on that and will be reluctant to give you feedback, and feedback from other people is a really fast way to improve. Also, it tends to shunt you into tasks that don't challenge you enough — it pushes you to avoid risk, and pushes other people to not ask you to do things that are at the limit of your abilities. This is precisely the dynamic Atwood was trying to combat by telling his story.