"Jeff Atwood is wrong on the Internet", film at 11. Why is this news?
Jeff Atwood is wrong about performance
31–33 of 33 posts
Re: Jeff Atwood is wrong about performance
#32Earlier quoted context omitted.
I agree with a vast majority of this, except for the qualification of time. There are many brands of mediocre programmer, some of which would claim a finished product well before the good programmer. But, the code will prove a nigh-unmaintainable disaster that will required all sorts of time later when a new feature is requested or bugs start creeping out. There are times when a good programmer will take considerably…
There's a rather simple metric actually: A good programmers stuff works. You don't have to go back and fix it, you don't have to rewrite large parts of it to extend it. One day I want to write a VCS history analyzer to quantify these things. Svn blame ($yourtool annotate) works to an extend, but there's a lot of untapped potential in that data.
good luck with that ;)
Re: Jeff Atwood is wrong about performance
#33Earlier quoted context omitted.
what separates a good programmer from a mediocre one?
Great question. Ask it to n programmers and get n^2 responses. This could easily be the subject for another post or even a book. Just off the top of my head in no particular order: - understands the problem at hand before writing any code - uses the right tool for the right job - follows accepted standards and protocols without sacrificing creativity - names variables & functions what they actually are for the next p…
I would like to add:
- does not over-engineer
A good programmer abstracts and generalizes as much as reasonably necessary and no further. A mediocre programmer will over-abstract the system for pointless 'extensibility' that will never be used. A bad programmer just outright doesn't do anything.
A mediocre programmer always codes with the "kitchen sink" mentality, targeting specifications that do not exist, but in their own minds do.