Live data from Hacker News

What does it take to be a good programmer?

dimitrov2k.wordpress.com

71–80 of 116 posts

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

#71

Earlier quoted context omitted.

I think that's crossing the wires of humility and confidence. You can be confident but humble. Confidence is your ability to come up with solutions and feel like they are the right solutions, and that they are good or excellent solutions. Humility is your ability to come up with solutions and realize that (1) they might not be the _absolute best_ solutions, (2) some solutions that look like they're better are actuall…

You can be confident but humble. I agree with you in principle, but again, I don't think that's a winning strategy. A humble, competent woodworker creates a piece that's beautiful, visually rich, has a solid, study feel to it, and can be appreciated by most . The software engineer, who checks in a fix on the back-end service that pre-empts several bugs that had yet to be discovered, goes relatively unappreciated. So…

While “pride” is often used as the opposite of “humility”---which I think is maybe what you're getting at here---I don't think pride is always the opposite of humility. In particular, I think the word can mean many things, and the meaning you're using isn't the one that's often used as the opposite of humility.

Fundamentally, I agree that you should be proud of what you've done, even if 10X awesome dude at Google could have done better. For one thing, 10X awesome dude at Google is surrounded by other Google folks, and by 15+ years of Google technology. There's being aware that there are better possibilities out there---indeed, being interested in them and even thirsty to learn more about them---and there's being embarrassed about what you've done. You can be interested in the crazy things some people do and want to learn more about those things while still working at a smaller, more limited scope and being proud of what you achieve with what you've got. The latter is how you get confidence, the former is how you get humility.

In short, I think we're probably saying the same thing. When you build a thing, you should be proud of that thing---unless you deliberately cut corners for some other tradeoff, in which case you should be cognizant of why you did it and satisfied with the tradeoffs you made. But that doesn't mean you have to think there's no better way, nor even that you have to avoid looking into those better ways. Often, I think these things (thinking there's no better way, not looking for improvements) are what people mean when they refer to folks who aren't humble. Certainly, that's what I mean.

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

#72
post #64

I'm reminded of something Splosky wrote: >The difference between a tolerable programmer and a great programmer is not how many programming languages they know, and it’s not whether they prefer Python or Java. It’s whether they can communicate their ideas. By persuading other people, they get leverage. By writing clear comments and technical specs, they let other programmers understand their code, which means other pr…

This boils down to: write code for your peers, not for yourself. I always try to remember that, and write code that will be easily understood by others, rather than the cleverest possible way.

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

#73
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.

Yes.

If you want to make sure your functions work, write unit tests.

If you want to make sure your application works, write integration tests.

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

#74

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).

More of a craft than an art. Sometimes it's more like woodworking, sometimes it's more like plumbing, but it's rarely anything like painting.

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

#75
post #40

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 t…

I have also been programming for over 30 years. I agree with you when the problem is small but all the rules change when it is bigger. If you are not up to it then it does not matter how much you care, and I do want people who care working on stuff, but at scale if it is not really good then the chances of failure are much higher.

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

#76
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?

"Unit" is not well-defined. However, it usually means a function/method. Being a unit test also implies some explicit setup for when that function is used.

The easiest examples of unit tests are math functions, since they're so well-behaved.

Here is a square root function in Javascript:

    function sqrt(n) {
      guess = n/2;
      while(Math.abs(guess*guess - n) 
There is nothing to set up because this code doesn't depend on a database, or an HTML input field, or the phase of the moon.

The call to assert_equals there is a unit test. (Also, keep in mind that assert_equals is a glorified if statement)

"well, what isn't a unit test??"

Since we can call anything we want a unit, the answer is "whenever we say we aren't doing a unit test". But a more practical answer is: whenever you're testing the interaction between two or more units (where a unit is a function/method).

If you're making a video game, you might have enemies who can jump, and guns that can fire. It would be a unit test to check if enemies jump correctly, and it would be a unit test to see if guns fire correctly. It wouldn't be a unit test to see if guns fire correctly from a jumping enemy, since this is the combination of two pieces.

Another way to (sort of) define a unit test is to say "how does this behave assuming that the rest of the system is correct"? That is, we aim to check the behavior of our code in isolation from the rest of the system.

This is important when something is wrong, because if we know what is behaving correctly, we don't have to waste time checking if it's the cause.

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

#77
Here's my take:

- You need to think a certain way. You need to be able to see how to translate a problem into something a machine can execute. You need to be able to switch from the macro to the micro smoothly.

- You need a certain level of proficiency with the tools you're using. Those can be programming languages/OSes/libraries/other software.

- You need experience. Having seen different approaches to solving various problems. Which ones worked. Which didn't. Having tried a few different approaches, different languages.

- You need domain knowledge. If you're working in a certain field you need to know the state of the art. You need to be able to read papers in the field. You need to be able to apply whatever techniques are required for the domain.

- You need to be a problem solver.

These are sort of basic table stakes for being a good "programmer".

In most real world settings you need to have some more on top of that:

- You'll need to be a good communicator. You will need to interact effectively with many different people, e.g. your boss, a product manager, junior developers. It's a team effort.

- You need to understand users/customers. You need to be able to gather requirements, ask the right questions, and deliver something useful.

- You need to understand the life-cycle of software. How long will it be in use? What sort of maintenance work will it need. How will it evolve?

- You need to have some business understanding. Is what you're doing creating business value?

- You need to appreciate the right trade-offs. Sometimes a crappy solution sooner wins over a perfect solution too late. And sometimes you should wait and have a perfect solution. That's just one example of a trade-off but our job is full of them.

- You need perseverance. Sometimes things take longer than you think. Some bugs take a lot of work to chase down.

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

#78

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…

> Nobody tells this to people who are beginners, I wish someone told me..

Henri Cartier-Bresson summed up Ira Glass' advice in 1 sentence.

> “Your first 10,000 photographs are your worst.”

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

#79
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

https://dimitrov2k.wordpress.com/2017/01/22/what-does-it-tak...

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

#80
I wish everyone were forced to program everything on a machine with the resources of a Pentium I-class processor and say 64MB RAM.

Learn to conserve your resources, learn to eschew that which is not needed, and for crying out loud learn to not write bloated stuff. Even today, most programs I use on Windows 7 were written back in the days of Windows 95/98 and they still work faster than any current modern implementation you can find, and they're smaller.

Post reply on HN