Jeff Atwood is wrong about performance • Hacker News Board

Re: Jeff Atwood is wrong about performance

#21

Post by j_baker » Sun, Jul 05, 2009, 7:11 PM UTC

ankp wrote: post #18

patio11 wrote: post #3

If you have upgraded all your servers without consolidating, year after year, you will notice that your electricity bill is going through the roof. I don't know, you can buy an awful lot of electricity for an hour of my time, and I'm cheap ... I think the largest deployment my day job supports probably causes an electricity bill in the hundreds a year range. If you had a meeting between one PL and two engineers to di…

It's not cheap, and you don't have to be Google for it to matter. Most of the time, the costs are just non-obvious to engineering. Here are some rough numbers. Power for a single 48U rack usually runs $200-$300/month for two 20amp circuits (possibly +2 for redundancy). A modern 1U server draws anywhere from (roughly) 1.66 to 2.5 amps, and you can only use 80% of a circuit's maximum supported load due to safety regula…

You're still talking about a minimum of 12-19 servers though. I'd imagine that the average website doesn't use even that. I think that SO in particular is at 3 servers. Maybe if SO explodes, this will become an issue, but an optimization would likely have to make a difference of a few racks before it it's even worth considering making an optimization based soley on power concerns.

Re: Jeff Atwood is wrong about performance

#22

Post by dexen » Sun, Jul 05, 2009, 7:11 PM UTC

marcusbooster wrote: post #15

edw519 wrote: post #11

Earlier quoted context omitted.

"Very few people have such a good eye for talent." That's OK because it's not necessary. Management doesn't need an eye for talent. It needs an eye for demonstrated performance. If Programmer A consistently delivers excellent software in x% of the time of Programmers B thru G, the users/customers love it, and the maintenance costs are a small % (if they have a way of measuring this), then what the f*&#%@ else does ma…

Demonstrated performance on what? A padded resume? A minimal contribution to a well known large project? Or is your ideal company one that hires 100 programmers to perform the same task and then fire the bottom 95% after a code review? You're assuming the company has already hired all-star talent (accidentally?) and just needs to pay off their demands. What happens when this all-star leaves to balloon across the worl…

This is why projects with large teams contributing to one system or application make it exceptionally hard to pick and reward good programmers. Their contributions just wont stand out functionally in the mass of mediocre performing system.

Moreover, their code may be considered unreadable or even dangerous by less experienced team members, leading to situations when he is considered less capable by the management than actually is.

It seems to me developing systems with loosely coupled components rather than tight, rigid interfaces, and keeping overall size small is the only way for assessing performance of products of individuals. Not an easy way, for sure.

Re: Jeff Atwood is wrong about performance

#23

Post by j_baker » Sun, Jul 05, 2009, 7:15 PM UTC

edw519 wrote: post #9

vaksel wrote: post #5

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

> never writes in 150 lines that which could be written in 100 lines

I'd disagree on this one. Oftentimes the 100 lines of code is an unintelligible mess while the 150 lines isn't.

Re: Jeff Atwood is wrong about performance

#24

Post by azanar » Sun, Jul 05, 2009, 7:38 PM UTC

edw519 wrote: post #9

vaksel wrote: post #5

Earlier 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 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 longer than a bad programmer, and might spend time futzing around with different implementations, moving code around, creating various data structures, etc.

Depending on the task, I would argue that can be a good thing. The good programmer is attempting to understand and present a clear conceptual model of the problem and solution in his code; the mediocre programmer might just create a litany of special cases for the cases specified right now just so they can get that particular program behind them.

Although the mediocre programmer might produce code faster, I would argue the good programmer is still 10x more productive, because he has done that much more thinking than the mediocre programmer. Perhaps when you refer to futzing, you mean changing the code just for the sake of another commit to show management, where nothing is learned and nothing is improved.

Also, a good programmer might come back two months from now, with the knowledge he gained from some other project, and make a change to the program that tangibly improves it for the better. The mediocre programmer will have put all that behind them; it is not on their list of projects and requirements, therefore they won't bother, nor will they bother even mention it to anyone.

But, I suspect this sort of comparison of timespans varies with size, and with the difficulty of the problem space.

And yeah, N^2 different answers. :-)

Re: Jeff Atwood is wrong about performance

#25

Post by lightcrest » Sun, Jul 05, 2009, 7:57 PM UTC

ankp wrote: post #18

patio11 wrote: post #3

If you have upgraded all your servers without consolidating, year after year, you will notice that your electricity bill is going through the roof. I don't know, you can buy an awful lot of electricity for an hour of my time, and I'm cheap ... I think the largest deployment my day job supports probably causes an electricity bill in the hundreds a year range. If you had a meeting between one PL and two engineers to di…

It's not cheap, and you don't have to be Google for it to matter. Most of the time, the costs are just non-obvious to engineering. Here are some rough numbers. Power for a single 48U rack usually runs $200-$300/month for two 20amp circuits (possibly +2 for redundancy). A modern 1U server draws anywhere from (roughly) 1.66 to 2.5 amps, and you can only use 80% of a circuit's maximum supported load due to safety regula…

You forgot to mention bandwidth as part of the fundamental datacenter cost structure. Some datacenter operators are charging up to $200/month to drop dark fiber into your cage/rack/cabinet. It is then up to you to negotiate a primary and secondary connectivity provider. At non-bulk rates (meaning around 10-100Mbps) this can be up to $50/megabit. Bulk rates look better - but only because if you're pushing that much traffic, you must be rich.

This is part of the reason cloud computing should be taken with a grain of salt. There can be fantastic economies of scale when applied correctly (say, on a properly built CDN solution) - but be wary whenever "cheap" and "computing" are mentioned in the same sentence. Someone has to be paying for all of that power, space, and bandwidth.

Re: Jeff Atwood is wrong about performance

#26

Post by bjelkeman-again » Sun, Jul 05, 2009, 8:11 PM UTC

edw519 wrote: post #9

vaksel wrote: post #5

Earlier 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 get the idea. However, I would be severely challenged to actually measure any of that. To me that means that "only a good programmer knows another good programmer", which is a hard situation to start from when you are trying to reward good programmers.

Re: Jeff Atwood is wrong about performance

#27

Post by moe » Sun, Jul 05, 2009, 8:49 PM UTC

azanar wrote: post #24

edw519 wrote: post #9

Earlier quoted context omitted.

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

Re: Jeff Atwood is wrong about performance

#28

Post by Periodic » Sun, Jul 05, 2009, 11:30 PM UTC

lionhearted wrote: post #10

edw519 wrote: post #4

"Hardware is cheap, programmers are expensive." Mediocre programmers are expensive. Good programmers are the bargain of the century. If companies would just wise up enough to pay a good programmer 3 times as much as a mediocre programmer to do 10 times the work, do it right, and do it so that it can be maintained reasonably, Jeff Atwood's tradeoff would become moot. But companies generally don't do this, which is pro…

100% agreement, yet: > If companies would just wise up enough to pay a good programmer 3 times as much as a mediocre programmer to do 10 times the work... Very few people have such a good eye for talent. It's really, really hard to do. Jack Welch, one of the better HR people of all time, said his hiring success rate was only 2 out of 3 hires working out even towards the end of his tenure. It's really hard to identify…

They also can mistake business for productivity. For example, there's the classic joke (at least in the sys admin world) about breaking something about a month before reviews, then stay over the weekend to fix it. You will be the savior of the company and be rewarded in kind.

Really good work is hard to see sometimes because it doesn't look like work. If you had two teams, one just delivered on time on and on budget and the other spent a heroic month overdue fixing bugs and finally shipping over budget it might appear that the people on the second team are better. They work more and worked harder than the first team. You might even decide that the first team was given too large a budget and too much time, when in reality they paced themselves and had talented people who could give good estimates and were able to deliver on their promises.

YOU might not make that mistake, but I can guarantee that many managers would give greater rewards the team working overtime to fix (their own) bugs than the one that consistently delivers on time and on budget.

I think it has more to due with the culture believing that software is buggy and impossible to schedule, and rewarding people when faced with those things.

Re: Jeff Atwood is wrong about performance

#29

Post by ankp » Sun, Jul 05, 2009, 11:43 PM UTC

j_baker wrote: post #21

ankp wrote: post #18

Earlier quoted context omitted.

It's not cheap, and you don't have to be Google for it to matter. Most of the time, the costs are just non-obvious to engineering. Here are some rough numbers. Power for a single 48U rack usually runs $200-$300/month for two 20amp circuits (possibly +2 for redundancy). A modern 1U server draws anywhere from (roughly) 1.66 to 2.5 amps, and you can only use 80% of a circuit's maximum supported load due to safety regula…

You're still talking about a minimum of 12-19 servers though. I'd imagine that the average website doesn't use even that. I think that SO in particular is at 3 servers. Maybe if SO explodes, this will become an issue, but an optimization would likely have to make a difference of a few racks before it it's even worth considering making an optimization based soley on power concerns.

Whether an optimization is worth pursuing depends on the business requirements, how much the it costs to implement, and whether there are any additional gains beyond avoiding power, space, and personnel costs.

Simply picking an efficient (both for the developer, and in terms of implementation) language/platform can be enough to start with, and will help you avoid being boxed in later.

Re: Jeff Atwood is wrong about performance

#30

Post by jhawk28 » Mon, Jul 06, 2009, 12:03 AM UTC

Its a short term vs long term analysis. If you focus on the long term, programmers are cheaper. Short term, it is easier to throw more hardware at the problem. The part that makes it difficult to measure is estimating how fast it will run on the new hardware. Usually if you use good algorithms and data structures with an architecture that matches the problem, adding hardware will scale the performance. Mediocre programmers rarely can get this right unless they are lucky.