The more specific the better
Ask HN: How do you go from good to great Programmer?
1–10 of 45 posts
Re: Ask HN: How do you go from good to great Programmer?
#2Re: Ask HN: How do you go from good to great Programmer?
#3What does this mean?
Don’t just do: write, share, give others credit, coach, etc
Re: Ask HN: How do you go from good to great Programmer?
#4Re: Ask HN: How do you go from good to great Programmer?
#5Re: Ask HN: How do you go from good to great Programmer?
#6Re: Ask HN: How do you go from good to great Programmer?
#7In order to become great at that, you have to make enough mistakes that affect other people until you understand what helps and what hinders them. You have to realize that your code isn't just implementation but is human-oriented communication, and tools are part of the puzzle.
The more your work hinders others, and the more you are forced to deal with the consequences of it, the more you will learn what helps and facilitates others.
You can also learn some of this by using and suffering from other people's bad work, as long as you don't allow it to make you complacent.
Finally, you need to have humility. Nobody who thinks they're great is going to be truly great. You need to recognize how you suck and how to suck less. "Take the log out of your own eye so that you can see clearly to take the speck of dust out of your brother's eye."
Re: Ask HN: How do you go from good to great Programmer?
#8I've discovered that the usual buckets used to categorize tests (unit, integration, etc) can mislead people into writing tests that make refactors painful/impossible. If you test each "unit" in isolation, then you limit your ability to change how the units interact (even if the user-facing behavior isn't changing at all.) You end up needing to change/rewrite the tests for each "unit".
Instead of units, I think about supported interfaces and tricky dependencies. Ideally, I'd test using the user-facing interface. That way, the test only changes if the user-facing (supported) behavior changes. Then I swap out any tricky dependencies (mainly slow/nondeterministic operations) for fakes/stubs/mocks. In the end, the tests look like "integration" tests, but they fit into your CI pipeline in the same place unit tests would.
This testing strategy makes me much faster and more effective. I can start writing tests before I've worked out how I'll organize the components. And if I change my mind halfway through, I don't need to rewrite any tests. If done right, those tests can survive years of refactoring with little maintenance.
There's more to good testing and being a great programmer than this, of course. But this is the lesson that has had the biggest impact on my "greatness" at programming.
Re: Ask HN: How do you go from good to great Programmer?
#9By getting good at testing. I worked on a project with a 100% coverage requirement for a few years, and it forced me to learn how to test things that I normally wouldn't bother with. It also forced me to deal with the consequences of maintaining my tests. I've discovered that the usual buckets used to categorize tests (unit, integration, etc) can mislead people into writing tests that make refactors painful/impossibl…