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

21–30 of 116 posts

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

#21

Post by bluecat »

_m8fo wrote: post #13

Shocking to me that there are so many articles on this. The strategy to becoming a good programmer is the same strategy to become good at anything else. 1. Identify what it means to be good 2. Work endlessly towards that aim 3. Deliberately practice 4. Decide to refine strengths or squash weaknesses. Do this as frequently as possible. Make sure you have an accurate assessment of what your strengths and weaknesses are…

Step five is, in my experience, one of the fastest ways to get better. Very solid list of steps.

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

#22

Post by nickff »

AnimalMuppet wrote: post #20
nickff wrote: post #4

Earlier quoted context omitted.

You are essentially describing 'test driven development', and many of us have either been taught the methodology, or stumbled on to it.[1] [1] https://en.wikipedia.org/wiki/Test-driven_development

No, abc_lisper is describing decomposition of the problem. That may or may not be implemented in a TDD environment; it may not even involve tests at all.

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.

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

#23

Post by dullroar »

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…

That's a great quote. Thanks for that.

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

#24

Post by AnimalMuppet »

Radle wrote: post #11

"Write unit tests, they could prove to be invaluable, especially when you introduce changes to your codebase." I always read this... What exactly is a unit test? What parts of my software should be tested? What are some examples of good unit tests and the code that is tested?

A unit test is something that calls the code you wrote, and makes sure that the responses are what they should be. It's often (though not always) written using a testing framework, like jUnit or CxxTest. These frameworks handle some of the tedium of writing the tests, but not all of it - testing is tedious to do, and there's not much way around it.

What parts should be tested? Everything that can be conveniently tested, and some distance past that. The goal is "every externally visible behavior of a class"; that is, everything that matters to a caller. For example, let's suppose I have a "sorted container" class. I'd want to test that it returns stuff in sorted order, maybe with two or three items, and with lots (hundreds or thousands). I'd want to test that it handled duplicates correctly. I'd want to test that it worked correctly with only one item, and with zero. I would not want to test whether it was internally implemented with a vector - that's not something that the caller cares about. So if the sorted container is changed from a vector to a tree, the unit tests should run unchanged.

Just last week, I was breaking apart a singleton into three related singletons. "Related" means that they each need a reference (or pointer) to at least some of the others. Turns out I coded a recursive constructor loop. A unit test pointed that out to me.

I've seen unit tests catch race conditions. Catch that I was calling a pure virtual method in a base class destructor. Plus of course all a whole bunch of the usual regular bugs.

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

#25

Post by TeMPOraL »

_m8fo wrote: post #8
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…

Failing to be humble eventually leads to arrogance. This advice is counterproductive. The part regarding being proud of who you are is completely tangential. I also highly doubt that "90% of people" in the tech industry don't understand what a "good programmer" does. The best advice is just to become as best as you can by trying as much as you can: 1. Deliberately working 2. Learning from people you perceive to be be…

> 5. A razor sharp focus on what really matters -- value in the context of the business/domain.

This is a tricky part, and you have to ask yourself explicitly - what do you want to work on? Becoming a better programmer, or a better employee/entrepreneur? Because business does not optimize just for good, quality work. It optimizes for earning money. Which involves things like:

- doing good, quality work which can be sold

- doing good enough work, minding the essential tradeoff between quality and business realities

- doing shitty, half-assed work and having a good sales team sell it anyway

- doing useless shiny things that don't really help the intended audience, but help your business to get their money

If the needs of your business are from the latter two groups, being a good programmer goes directly against your career success in that place. Unfortunately, it is my belief that most of the jobs in our industry fall into those two groups. From the POV of everyone else but programmers, the code is only means to an end.

I want to emphasize it, because a lot of advice for programmers tells you about the "razor sharp focus on what really matters -- value in the context of the business/domain", and I found that for some reason, it never resonated with me. It took me a while to understand why - it's because this advice comes from a business mindset, where making money is the goal and the means to it are tangential. I have the opposite mindset - for me, it's the product that matters, not how to make more money off it. Realizing that those are two different worldviews has helped me stop feeling inadequate just because I couldn't bring myself to enjoy the business value. It also helped me understand the POV of management and what they expect from me.

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

#26

Post by AnimalMuppet »

TeMPOraL wrote: post #18
Radle wrote: post #11

"Write unit tests, they could prove to be invaluable, especially when you introduce changes to your codebase." I always read this... What exactly is a unit test? What parts of my software should be tested? What are some examples of good unit tests and the code that is tested?

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. If you can't test it, you have to think about re-designing the class interface - often by breaking it up into smaller classes. I've seen this in practice; the net effect of this is better class design (plus thorough tests).

That said, I'm considerably stronger of a proponent of tests than I am of TDD. If you don't like the TDD approach, still write tests. Write lots of them. They'll often save you when you make subtle mistakes in your next set of changes. (Nothing like fixing a bug, running the tests, and getting informed of all the implications of your change that you forgot about.)

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

#27

Post by FLUX-YOU »

_m8fo wrote: post #13

Shocking to me that there are so many articles on this. The strategy to becoming a good programmer is the same strategy to become good at anything else. 1. Identify what it means to be good 2. Work endlessly towards that aim 3. Deliberately practice 4. Decide to refine strengths or squash weaknesses. Do this as frequently as possible. Make sure you have an accurate assessment of what your strengths and weaknesses are…

>1. Identify what it means to be good

You'll never get a solid definition for a good programmer, and that's the problem. If we knew that, we would have a list of things to learn and teach and we could easily make that a standard interview test before giving people a job. And no one would need to write any more "10 things you need to know as a programmer" articles.

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

#28

Post by AnimalMuppet »

nickff wrote: post #22
AnimalMuppet wrote: post #20

Earlier quoted context omitted.

No, abc_lisper is describing decomposition of the problem. That may or may not be implemented in a TDD environment; it may not even involve tests at all.

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.

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

#29

Post by kornish »

dullroar wrote: post #23
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…

That's a great quote. Thanks for that.

A great quote, and a great interpretation at the bottom.

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

#30

Post by marcosdumay »

Radle wrote: post #11

"Write unit tests, they could prove to be invaluable, especially when you introduce changes to your codebase." I always read this... What exactly is a unit test? What parts of my software should be tested? What are some examples of good unit tests and the code that is tested?

I'm recently completely disagreeing with that wisdom.

You should have thoughtful integration tests. Unit tests are only useful when you have an obvious independent "unit" with semantics that are completely independent from the rest of your code. If so, you test those.

Post reply on HN