Live data from Hacker News

Programming Innocence

projectb14ck.org

11–20 of 25 posts

Re: Programming Innocence

#11
post #6

I have always been a "fearless" programmer, but never realized it until reading this post. Here's how: Fear of not knowing the best way to do things (best practices). The sooner you realize that there is never a best way of doing anything, the sooner you can release this silly fear. Some ways are better that others, but any way is better than no way . Just get the thing done. Later, when you refactor, you'll have the…

I don't give a shit what other programmers think. Sure, I learn from them, but never in the context of reviewing the code I wrote.

Can you elaborate on this a little? On the surface, it sounds like ego getting in the way of learning and closing your mind to good mentors. On the other hand, you might also have had a helping hand in inventing Lisp or something, and I am your young whippersnapper that you won't be listening to because you have already written my algorithms better before I learned to crawl. The context helps, since I am far from convinced this is a good attitude for programmers (especially my coworkers) to adopt.

Re: Programming Innocence

#12

At first, I though "Man, this sounds like a recipe for technical debt" but then I realized I'm guilty of exactly what you're talking about. In fact, I was browsing hacker news as a break from googling the best way to implement a feature that I could do in 10 minutes if I weren't concerned about having it perfect from the get-go. I recently realized that I code slower than I used to. I assumed this was because I stopp…

Be careful. Sometimes the reason you code slower is that you are thinking from an architectural level and are making sure your code is a reasonable fit. Sometimes you are taking the time to shape the code in a way that is maintainable.

I have felt this loss of what the author calls "programming innocence", but when I dig down deeply, I think it is more that I am doing MORE work than less. When I was young and stupid, I thought I was implementing features, and I whipped things out quickly. Lord do I remember also spending a lot of time debugging those things, and if I came back to the project a few months later, I would find it hard to read, figured I knew better, and would rewrite the whole thing with my newfangled enlightenment. Today, I spend a lot less time debugging and rewriting, and my projects are more feature-complete. It may feel like I am programming slower, but I am still whipping things out, and unlike my young days where I was my own customer, my requirements are constantly changing: I write code that can evolve.

Re: Programming Innocence

#13
post #11
post #6

I have always been a "fearless" programmer, but never realized it until reading this post. Here's how: Fear of not knowing the best way to do things (best practices). The sooner you realize that there is never a best way of doing anything, the sooner you can release this silly fear. Some ways are better that others, but any way is better than no way . Just get the thing done. Later, when you refactor, you'll have the…

I don't give a shit what other programmers think. Sure, I learn from them, but never in the context of reviewing the code I wrote. Can you elaborate on this a little? On the surface, it sounds like ego getting in the way of learning and closing your mind to good mentors. On the other hand, you might also have had a helping hand in inventing Lisp or something, and I am your young whippersnapper that you won't be liste…

Can you elaborate on this a little?

Let me put it this way...

If you gave me a page of your code and asked for feedback, I would return it with 50 red marks on it.

If you gave it to me a second time, there would still be 50 red marks, but most of them would have you changing it back to the way it was in the first place.

The point is that any programmer can give endless feedback to any other programmer based on a sample of code. In my experience, 90% of that feedback was flat out wrong, and the other 10% was a waste of time.

I prefer learning new things the way I have for years now. When I see something cool, either as a user or by looking at the code, I figure out what was done and how I'd like to do it (rarely keeping 100% of it), and then incorporate that into my own style.

Having others look at my code has never delivered much value. This may seem like ego, but it's not. It's just a matter of what works best.

Re: Programming Innocence

#14
post #13
post #11

Earlier quoted context omitted.

I don't give a shit what other programmers think. Sure, I learn from them, but never in the context of reviewing the code I wrote. Can you elaborate on this a little? On the surface, it sounds like ego getting in the way of learning and closing your mind to good mentors. On the other hand, you might also have had a helping hand in inventing Lisp or something, and I am your young whippersnapper that you won't be liste…

Can you elaborate on this a little? Let me put it this way... If you gave me a page of your code and asked for feedback, I would return it with 50 red marks on it. If you gave it to me a second time, there would still be 50 red marks, but most of them would have you changing it back to the way it was in the first place . The point is that any programmer can give endless feedback to any other programmer based on a sam…

Having others look at my code has never delivered much value.

Maybe not much value for you, but after enjoying your many insightful comments on this site, I suspect that I would learn a lot by looking at your code. :-)

Re: Programming Innocence

#16
post #14
post #13

Earlier quoted context omitted.

Can you elaborate on this a little? Let me put it this way... If you gave me a page of your code and asked for feedback, I would return it with 50 red marks on it. If you gave it to me a second time, there would still be 50 red marks, but most of them would have you changing it back to the way it was in the first place . The point is that any programmer can give endless feedback to any other programmer based on a sam…

Having others look at my code has never delivered much value. Maybe not much value for you, but after enjoying your many insightful comments on this site, I suspect that I would learn a lot by looking at your code. :-)

EDIT: (Ignore this. It's wrong, and I should have been more polite anyway. I'm leaving it to teach myself a lesson about being hasty...)

If you understood his point, you wouldn't say that.

Not that I agree with Ed on this, 95% of my code is published. But still.

Re: Programming Innocence

#17
post #2

That's phase 2. Phase 3 is the middle way: be clever about balancing all those forces. Use the new library, but only if your gut feeling tells you that it's also the right choice for the future. Change the code without hesitation, but do hesitate if you think that it may cause more problems than it resolves. Etc. Experience is a bitch. There are no blacks and whites, only a grey mess.

Hm. What about "There are neither blacks nor whites, only a lot of black and blue?"

Re: Programming Innocence

#18
post #13
post #11

Earlier quoted context omitted.

I don't give a shit what other programmers think. Sure, I learn from them, but never in the context of reviewing the code I wrote. Can you elaborate on this a little? On the surface, it sounds like ego getting in the way of learning and closing your mind to good mentors. On the other hand, you might also have had a helping hand in inventing Lisp or something, and I am your young whippersnapper that you won't be liste…

Can you elaborate on this a little? Let me put it this way... If you gave me a page of your code and asked for feedback, I would return it with 50 red marks on it. If you gave it to me a second time, there would still be 50 red marks, but most of them would have you changing it back to the way it was in the first place . The point is that any programmer can give endless feedback to any other programmer based on a sam…

Interesting. In my experience, the feedback

(1) introduces me to new concepts or utilities I had not considered using -- may or may not incorporate

(2) shows me what patterns other developers are accustomed to seeing -- if I chose a pattern for subjective reasons and I am outnumbered, incorporate and adapt

(3) sometimes uncovers bugs or places where I am not fitting into the architecture well enough (or someone else's new development) -- extra eyes, extra attention, all nice

(4) allows me to turn around and show my "reviewers" approaches in #1 and #2 -- educates and changes local culture

(5) introduces other developers to parts of the code they did not write

In short, the code review is not just about me. Although your two code reviews may give me red marks going back and forth, it is ultimately up to me to decide which way to go, and I may benefit from seeing both sides if I have not already seen those. There is a pretty small percentage that I would say is actually completely useless to me. I suppose it depends on how one conducts reviews, and it may also depend on whether your project source is shared with and maintained by others.

Re: Programming Innocence

#19
But what if my favorite way of hacking, what makes me feel amazing is something more like Rich Hickey's Hammock Driven Development (clojure.blip.tv/file/4457042/)?

Of course I don't get a chance to do this as much as I'd like at my day job. Still, some of my most satisfying programming experience has been when I've spent days researching and thinking about a problem, had a moment of enlightenment, and wrote 200 lines of beautifully simple code that strikes at the heart of the problem. That makes me feel like a programming god.

And I'd argue the result is somewhat better than "innocently" hammering out reams of code without taking time to really consider it.

Re: Programming Innocence

#20
post #18
post #13

Earlier quoted context omitted.

Can you elaborate on this a little? Let me put it this way... If you gave me a page of your code and asked for feedback, I would return it with 50 red marks on it. If you gave it to me a second time, there would still be 50 red marks, but most of them would have you changing it back to the way it was in the first place . The point is that any programmer can give endless feedback to any other programmer based on a sam…

Interesting. In my experience, the feedback (1) introduces me to new concepts or utilities I had not considered using -- may or may not incorporate (2) shows me what patterns other developers are accustomed to seeing -- if I chose a pattern for subjective reasons and I am outnumbered, incorporate and adapt (3) sometimes uncovers bugs or places where I am not fitting into the architecture well enough (or someone else'…

When coding fast, nobody knows your code like you do. Reviews are then either a) too late to do any good, or b) shallow. Both are nearly useless.

If you have a mentor and are new, then the mentor's review can help. But in that case, the mentor probably could have written your code faster than you did. The review may be useful to you, but the project would have in fact gone faster had you not been there.

If you code fast, outrun the others around you, are any good at all, then code review is at best annoying.

Post reply on HN