Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What does it take to be a good programmer?

dimitrov2k.wordpress.com

Post reply on HN
Print view View original

31–40 of 116 posts

Re: What does it take to be a good programmer?

#31

Post by nickff »

AnimalMuppet wrote: post #28
nickff wrote: post #22

Earlier quoted context omitted.

abc_lisper specifically said: "every problem you do can be broken down into smaller problems, which can be worked independently and tested independently". Unless you delete or ignore "and tested" from that post, abc_lisper 's approach definitely involves tests.

I stand corrected; what abc_lisper said definitely involves tests. That's not necessarily TDD, though; see my post at https://news.ycombinator.com/item?id=13465459 for the difference.

I agree that abc_lisper did not 'exactly' describe test driven development, which is why I said he 'essentially' described test driven development. I am a believer in test driven development, yet I often write a bit of application code before I write the tests; I acknowledge that probably makes me a pariah, but I still keep tests (and TDD) in mind.

Re: What does it take to be a good programmer?

#32

Post by AnimalMuppet »

nickff wrote: post #31
AnimalMuppet wrote: post #28

Earlier quoted context omitted.

I stand corrected; what abc_lisper said definitely involves tests. That's not necessarily TDD, though; see my post at https://news.ycombinator.com/item?id=13465459 for the difference.

I agree that abc_lisper did not 'exactly' describe test driven development, which is why I said he 'essentially' described test driven development. I am a believer in test driven development, yet I often write a bit of application code before I write the tests; I acknowledge that probably makes me a pariah, but I still keep tests (and TDD) in mind.

Meh, I think TDD has value, but I don't think a methodology should become a religion. Write a bit of application before your tests, write most of the tests before the code, you're good to call it TDD in my book. (Of course, being non-religious about methodology may make me a pariah, and not just on TDD; but I can't work up the energy to care...)

Re: What does it take to be a good programmer?

#33

Post by TeMPOraL »

AnimalMuppet wrote: post #26
TeMPOraL wrote: post #18

Earlier quoted context omitted.

TDD is like object-oriented programming. Nobody can agree how precisely it should work in real world , but "you'll know it when you'll see it". And you're 50% likely to embrace it, and 50% likely to decide it's utter crap.

TDD is more than having unit tests. TDD means that the first thing you write are the tests . Why does that matter? It means that you're writing a user of your class before you write the class. That means that the interface of the class gets designed from the mindset of a user, not an implementor. More: The interface gets designed by someone who wants to be able to test all the externally-visible behavior of the class…

You see, I'm in that 50% of people who don't particularly like TDD. Even though I tried it, honest to god, several times.

> That means that the interface of the class gets designed from the mindset of a user, not an implementor.

From my experience, something entirely different happens. The class gets designed from the mindset of a third party - the tester. Which is, I believe, a mindset different from the user. If all you're testing is the externally-visible behaviour, fine. You're pretty much treating the class like a library. But if you start injecting stuff into the class to test if some other dependent services got called properly, etc. - and especially if you start designing the interface around such testability, then I believe it'll lead to bad, unreadable code. In particular, I believe adding complexity to the class for the sole purpose of making it easier to test is a code stink.

TDD taken to the extreme prescribes that you should only ever write dumbest possible code that makes current tests pass. If you need more complicated behaviour, you first have to write tests for it. But this gets quickly out of hand if your project is meant to do anything more complicated than being a simple CRUD layer, because test complexity rises in lockstep with production code complexity. I've seen cases when people blindly following the test->code->refactor cycle created tests that themselves were isomorphic to the algorithm they were implementing, which makes one ask where did they have the code that tested if tests themselves are implemented correctly?

So personally, while I like tests (particularly regression tests), I just can't make myself follow TDD.

Re: What does it take to be a good programmer?

#35

Post by windlessstorm »

TeMPOraL wrote: post #17

My personal advice would be to follow the Ira Glass quote: > Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still kil…

Big smile on face after reading this.

Re: What does it take to be a good programmer?

#36

Post by sanderjd »

halis wrote: post #7

It helps to be obsessive. Program in your spare time. Don't be one of these people that just learns what they need to know to do their job and then stops learning. I've been programming professionally for 6 years and I'm learning as much today as when I started.

You don't need to be obsessive or program in your spare time to be a good programmer. It's great to continue to learn indefinitely. It's also great to leave work at work and build a life rich with a diversity of interest and activity. You can do both.

Re: What does it take to be a good programmer?

#37

Post by AnimalMuppet »

TeMPOraL wrote: post #33
AnimalMuppet wrote: post #26

Earlier quoted context omitted.

TDD is more than having unit tests. TDD means that the first thing you write are the tests . Why does that matter? It means that you're writing a user of your class before you write the class. That means that the interface of the class gets designed from the mindset of a user, not an implementor. More: The interface gets designed by someone who wants to be able to test all the externally-visible behavior of the class…

You see, I'm in that 50% of people who don't particularly like TDD. Even though I tried it, honest to god, several times. > That means that the interface of the class gets designed from the mindset of a user, not an implementor. From my experience, something entirely different happens. The class gets designed from the mindset of a third party - the tester. Which is, I believe, a mindset different from the user. If al…

Well, when I did it, I was the tester, and the user, and the coder, and I switched back and forth frequently - maybe in five minute increments. But I thought differently when wearing each of those hats. I could see the difference between ways of thinking in the design of the code.

> But this gets quickly out of hand if your project is meant to do anything more complicated than being a simple CRUD layer...

I've done things a lot more complicated than a simple CRUD layer. TDD held up just fine.

> I've seen cases when people blindly following the test->code->refactor cycle created tests that themselves were isomorphic to the algorithm they were implementing...

Well, blindly following any methodology is likely to get you in trouble, one way or another. The problem is blindly following, not that they're following TDD.

That said, I did TDD, and now I don't. It worked well for me, I loved the kind of code that came out of it, and I still don't do it any more.

Re: What does it take to be a good programmer?

#38

Post by optimuspaul »

TeMPOraL wrote: post #17

My personal advice would be to follow the Ira Glass quote: > Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still kil…

This nails it in my opinion. Too often I see people assume that programming/coding is somehow science based. It's not really, it's an art and you need to be a creative person to be good at it. The science comes later (sometimes never for some).

Re: What does it take to be a good programmer?

#39

Post by A_Crazy_Idea »

tertius wrote: post #9
awfgylbcxhrey wrote: post #3

In my opinion, "be humble" isn't a winning strategy. Don't be so arrogant that you stop improving or fail to understand mistakes, but by all means don't be humble. Be proud of who you are and the work you've done. You work in an industry where 90% of people don't understand what you do. Chances are your own boss won't understand the actual value you're providing. So don't be humble. "There's always someone better tha…

Being proud of your work and being humble are not mutually exclusive.

Bad advice and anonymous posts on forums are not mutually exclusive.

Re: What does it take to be a good programmer?

#40

Post by keithnz »

Well, I've been programming 30+ years.....

I think one of the main things that makes a good programmer is someone who cares about the final product. Ironically this doesn't necessarily mean you have to be super good at writing code. I have seen people with what seems basic coding capability very methodically build some really nice software. This is because they are very focused on the "end" not the "means". You see the thoughtfulness of what has been designed in. Sometimes, in the quest of writing "good code" it interferes with writing good software because the emphasis becomes getting good at the means to an end above the end itself.

Not to say improving your coding capability isn't of value, but it's done so you can create even more fantastic things.

Post reply on HN