Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Sadly just an outline but I didn't mind that. Good read.

I'd add a few things I've noticed over the years. Great developers like to pair program on tricky stuff, because they always learn something. They will try 2 different implementations if they're not sure which is best, and then the right one will then be obvious. They back their arguments with real world proofs. They try most fringe/new technology, even if it's not right for the current project. They hold large amount of domain knowledge in their heads. They admit when something is twisting their brains, draw it on paper, talk about it and then bang it out. They fantasize about what-ifs, in a perfect world, scenarios. And they love to share knowledge.



> They try most fringe/new technology

I have actually found the opposite. The best programmers I have known are often the most reluctant to try new technologies. At least until the technology appears to have reached some sort of critical mass and it has been shown to be virtually guaranteed to increase their already very high levels of productivity. Partly this is just an experience thing. After you see enough shiny new things wrapped up in spin and hype the task of peeling that stuff away to get an honest assessment becomes unappealing.


I'm definitely in this camp. I read enough programming related news that I know what new technologies are emerging and what problems they attempt to solve. But these days I wait until things have gained enough momentum that I think they'll stick around for at least a few years before I'll even consider adopting them for real work.

That said it's good to keep learning new things just for the sake of learning so I will still sometimes pick up something new just because it looks different enough from things I'm already familiar with.


You should hesitate to introduce fringe technologies into production systems while they remain fringe. But you should absolutely evaluate them, figure out which ones you want to keep an eye on, and learn ideas from them that you could apply elsewhere.


I've seen both, so I'm guessing there are multiple things that make a productive programmer.


I would say "try" fits very good but "use" often comes later.


I do tend to try things when they solve a problem that I have. I may be missing on problems that I don't know that I have. On the other hand, I frequently see people using tools to solve problems that they don't really have.


From what I've seen, they are eager to try new technologies but not necessarily new implementations. Just enough to get an idea of where this tool fits in their toolbox should they ever need it.


I am in the same camp. I'd prefer to know an older technology (and it's underpinnings) completely than scratch the surfaces on a bunch of short lived new ones. Most of the new stuff I see is pretty high level. I invest my free time in getting as close to the metal as I can.

If there's something new with a feature I like, I'm a lot more likely to try to replicate their feature in something I know than make a switch.


Exactly. I have not seen a new thing in many years. All the so called "new" things are simply rebranded decades old ideas.


Isn't everything?


Even your statement isn't new! 2200 years ago King Solomon wrote, "There is nothing new under the sun." We just keep finding different ways to rehash the same core concepts.


> They try most fringe/new technology, ...

I would have thought that in area like IT where everything gets reinvented every decade (or less) a master programmer wouldn't have to look at the details to assess a "new" technology.


Agreed; too much commitment.

I hate 'trying everything' because I never feel good at anything, and more often than not "new technologies" in this scene are just someone else's old ideas, rehashed and made more complicated. Mastery requires focus.


I'm no master, but I am middle aged. I like to learn at least one new technology a year; I always learn something from working hands on that I might not have understood just from ideating about it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: