7 ms·

My default response to any "good programmer, bad programmer" post: A smart accountant once told me that the answer to "How much money did you make?" is always,

by edw519 14y ago

My default response to any "good programmer, bad programmer" post: A smart accountant once told me that the answer to "How much money did you make?" is always, "Who wants to know?" If it's an investor, the answer is "A lot." If it's a customer, the answer is "A little." If it's the IRS, the answer is "None." Same thing here. The answer to "Who is a good programmer?" is always, "Who wants to know?" To a project manager, the programmer who hits every deadline (regardless of quality) is a good programmer. To a customer, the programmer who solves their problem quickest is a good programmer. To a business owner, the programmer who makes them the most money is a good programmer. To a PHB, the programmer who makes them look the best is a good programmer. To a journalist, the programmer who tells the best stories is a good programmer. To a junior programmer, the best mentor is the good programmer. To another programmer, the programmer they are most likely to want to go into battle with is a good programmer. To a blogger, the programmer who best fits the profile of the point he is trying to make is a good programmer.

batgaijin 14y ago
Hey edw519, I've read a lot of your posts and I was wondering if you could point me at a repo of some of your code; I'd love to read it.
- mcknz 14y ago
  http://edweissman.com/53640595 http://edweissman.com/53640595 -- or check his profile.
  - mcknz 14y ago
    sorry, you asked for code and i sent you to the ebook. :P
- Evbn 14y ago
  Do you want to see Scott Adams's project status reports too? Just enjoy the stories.
- swah 14y ago
  "I never publish my code. Ever. Users get to give me feedback, but I don't give a shit what other programmers think. Sure, I learn from them, but never in the context of reviewing the code I wrote. I learn from the code of others and apply those lessons to my own work" (from here: http://news.ycombinator.com/item?id=2096007 http://news.ycombinator.com/item?id=2096007)
  - batgaijin 14y ago
    So, he gets to comment on other people who publish their work, but he is forever safe from the same sort of feedback? That sounds more like fear than pragmatism.
why-el 14y ago
I agree with you here. That project manager you mentioned is a lot of things to a lot of people. But I think as programmers we might want to agree on a set of standards that identify the good and the bad. I am one year or so older than Dan, and it would help my career to know that more experienced programs could identify who is the best among them.
- pavanky 14y ago
  This again depends on the domain and programming language you will be working on. But almost always the following line holds good. Make your code readable.
  - snogglethorpe 14y ago
    I've had the fortune / misfortune of working with some very smart programmers, who could quickly come up with amazing and correct algorithms to solve difficult problems... but I found much of their code very hard to read; it wasn't "horror code" by any means, but it was often terse and tricky, and pretty comment-light. My theory was that because these guys were so smart, in many cases they overestimated the ability of others to comprehend what was clear to them, and as a result simply made their code too clever and omitted comments that might help clarify it. It was a definitely a valuable experience, though; besides the natural pleasure of working with very smart people, it really drove home the importance of actively pursuing clear and well-commented code! :]
    - mercurial 14y ago
      Make no mistake. Clever code is not necessarily good code. I'm not in favour of littering the code with a pile of comments which will most likely become obsolete in three months, but it's very important to do whenever you are: - implementing a non-trivial algorithm - doing something surprising (maybe to fix something on a specific architecture or whatever) - implementing a complex business rule
    - Flow 14y ago
      But their code could also be hard to understand because you don't understand the problem good enough.
deleted 14y ago
[deleted]
hnriot 14y ago
You're making the point that being competent at programming is in some way relative to the perspective of the asker, but that's just not the case. Competence is absolute. There are traits of a good programmer that are immediately evident to any experienced programmer.
- siganakis 14y ago
  If competence is absolute, then there should be some way that you can objectively measure it (otherwise how do you know its absolute?). What are the ways to objectively measure the competence of a programmer? If that was the case, then it would be much, much easier to hire and fairly compensate programmers than it is in reality.
  - nadam 14y ago
    In my opinion programmer competence is not absolute, but a little bit more absolute than what ed's post suggest. :) A very rough measurement of programmer competence: The programmer is given a product specification. He creates the program in T time using S size of code. 1/(T * S * S) is a very good approximation of how good the developer is. (small size is more important than the taken time, that's why I've taken S square. We can tweak the formula of course. Maybe 1/(T * S * S * S) is even better in some cases.) TL;DR: the most common thing amongst good programmers in my opinion is that they are masters of the DRY principle, but they do not overabstract; in essence they write smaller code to problems (usually even faster) than not so good programmers. The bigger the system is, the more and more architectural/design skill is needed to keep the code base small.
    - EwanToo 14y ago
      I have to disagree sorry. If a piece of software is needed by the date of a major launch, and a programmer doesn't ship, all because he wants to reduce the amount of code involved, then he's an awful programmer as far as the business is concerned. Running over time can cost millions of $ of investment in other areas of the business: - Press organised - Advertising purchased - 1000s of hours of staff training underway - Suppliers informed of increased demand / new supplies purchased - Customers told to expect delivery by date Any one of these areas can cost 10x or more of the cost of developing the code. If you're not writing code which would be affected by that kind of criteria then cool, go for whatever metric you want to define. Time taken is almost always the number one criteria of any business requirement, or to put it another way, small size of code means almost nothing to anyone except the original developers.
Ubiquite 14y ago
To a maintainer programmer, the programmer who makes the simplest code.
- just2n 14y ago
  To an HR person, the programmer with the most number of years of experience. Here's to the technical interviewers out there who know all too well that there is no correlation between number of years of employment as a "software engineer" and the quality of the engineer.
anthonyb 14y ago
> To a project manager, the programmer who hits every deadline (regardless of quality) is a good programmer. > To a customer, the programmer who solves their problem quickest is a good programmer. Up until the codebase is such unbelievably appalling shit that you can no longer add new features, solve problems or reliably hit deadlines. I have worked on too many of these projects to be able to easily count them. Typically, I'll be the one fixing up something after the previous developer has run away or has been sacked. There's often a culture shock when the manager/customer/project manager who is used to calling the shots suddenly finds that their latest idea needs to take a back seat while deeper (often 'invisible') problems get fixed. Perhaps another take is that a "good programmer" is one who is still around and still adding features after a couple of years.
- prostoalex 14y ago
  In the real world (or at least the world of garage sales and Antiques Roadshow), one man's junk is another man's treasure. In the programming world, one man's treasure is inevitably another man's unreadable spaghetti dependency-ridden junk.
  - flyinRyan 14y ago
    No, in the programming world there are projects that met the revolving door of mediocre programmers that no one is proud of, no one understands how it works or wants to, everyone just finds a place they think will have the effect their being driven to make and takes a shot.
  - anthonyb 14y ago
    Yeah, the code you're working on is really treasure in disguise. Whatever gets you through the day...
    - ShawnBird 14y ago
      If you are doing it for an employer it is at least worth what they are paying you for it. I would argue that qualifies as treasure.
crncosta 14y ago
Thank you for so enlightening comment.
gadders 14y ago
> To a project manager, the programmer who hits every deadline (regardless of quality) is a good programmer. Obviously not true, unless your project manager is a complete idiot.
- Shorel 14y ago
  The average manager is dumber than you think.
- dkrich 14y ago
  Not sure how you define idiot, but more often than not pm's have no formal programming experience which makes it difficult (though not impossible) to understand the value of well-engineered code. The only language they speak is dates, which unfortunately is usually accompanied by loads of unnecessary documentation.
  - gadders 14y ago
    Presumably, though, a competent programmer would include the effort required to produce well-engineered code within his original estimate.
    - dkrich 14y ago
      Yeah, but in my experience, the PM's response to that will be "can we get it done sooner?" If the estimated time aligns with what they want, then you're fine. But that's rarely the case and when things slip the code cleanup is pushed to the back burner.
    - vadman 14y ago
      Code that was well-engineered 3 months ago may suddenly become lacking in light of a client having a brilliant new idea/requirement. And a programmer is not always in charge of his estimates. He may have to arrive at it together with his team lead who is under pressure from 2-3 project managers, thus only the minimal reasonable time will be allocated, without concern for architecture changes or refactoring.

by edw519 14y ago

batgaijin 14y ago

Hey edw519, I've read a lot of your posts and I was wondering if you could point me at a repo of some of your code; I'd love to read it.

mcknz 14y ago
http://edweissman.com/53640595 http://edweissman.com/53640595 -- or check his profile.
- mcknz 14y ago
  sorry, you asked for code and i sent you to the ebook. :P
Evbn 14y ago
Do you want to see Scott Adams's project status reports too? Just enjoy the stories.
swah 14y ago
"I never publish my code. Ever. Users get to give me feedback, but I don't give a shit what other programmers think. Sure, I learn from them, but never in the context of reviewing the code I wrote. I learn from the code of others and apply those lessons to my own work" (from here: http://news.ycombinator.com/item?id=2096007 http://news.ycombinator.com/item?id=2096007)
- batgaijin 14y ago
  So, he gets to comment on other people who publish their work, but he is forever safe from the same sort of feedback? That sounds more like fear than pragmatism.

why-el 14y ago

I agree with you here. That project manager you mentioned is a lot of things to a lot of people. But I think as programmers we might want to agree on a set of standards that identify the good and the bad. I am one year or so older than Dan, and it would help my career to know that more experienced programs could identify who is the best among them.

pavanky 14y ago
This again depends on the domain and programming language you will be working on. But almost always the following line holds good. Make your code readable.
- snogglethorpe 14y ago
  I've had the fortune / misfortune of working with some very smart programmers, who could quickly come up with amazing and correct algorithms to solve difficult problems... but I found much of their code very hard to read; it wasn't "horror code" by any means, but it was often terse and tricky, and pretty comment-light. My theory was that because these guys were so smart, in many cases they overestimated the ability of others to comprehend what was clear to them, and as a result simply made their code too clever and omitted comments that might help clarify it. It was a definitely a valuable experience, though; besides the natural pleasure of working with very smart people, it really drove home the importance of actively pursuing clear and well-commented code! :]
  - mercurial 14y ago
    Make no mistake. Clever code is not necessarily good code. I'm not in favour of littering the code with a pile of comments which will most likely become obsolete in three months, but it's very important to do whenever you are: - implementing a non-trivial algorithm - doing something surprising (maybe to fix something on a specific architecture or whatever) - implementing a complex business rule
  - Flow 14y ago
    But their code could also be hard to understand because you don't understand the problem good enough.

deleted 14y ago

[deleted]

hnriot 14y ago

You're making the point that being competent at programming is in some way relative to the perspective of the asker, but that's just not the case. Competence is absolute. There are traits of a good programmer that are immediately evident to any experienced programmer.

siganakis 14y ago
If competence is absolute, then there should be some way that you can objectively measure it (otherwise how do you know its absolute?). What are the ways to objectively measure the competence of a programmer? If that was the case, then it would be much, much easier to hire and fairly compensate programmers than it is in reality.
- nadam 14y ago
  In my opinion programmer competence is not absolute, but a little bit more absolute than what ed's post suggest. :) A very rough measurement of programmer competence: The programmer is given a product specification. He creates the program in T time using S size of code. 1/(T * S * S) is a very good approximation of how good the developer is. (small size is more important than the taken time, that's why I've taken S square. We can tweak the formula of course. Maybe 1/(T * S * S * S) is even better in some cases.) TL;DR: the most common thing amongst good programmers in my opinion is that they are masters of the DRY principle, but they do not overabstract; in essence they write smaller code to problems (usually even faster) than not so good programmers. The bigger the system is, the more and more architectural/design skill is needed to keep the code base small.
  - EwanToo 14y ago
    I have to disagree sorry. If a piece of software is needed by the date of a major launch, and a programmer doesn't ship, all because he wants to reduce the amount of code involved, then he's an awful programmer as far as the business is concerned. Running over time can cost millions of $ of investment in other areas of the business: - Press organised - Advertising purchased - 1000s of hours of staff training underway - Suppliers informed of increased demand / new supplies purchased - Customers told to expect delivery by date Any one of these areas can cost 10x or more of the cost of developing the code. If you're not writing code which would be affected by that kind of criteria then cool, go for whatever metric you want to define. Time taken is almost always the number one criteria of any business requirement, or to put it another way, small size of code means almost nothing to anyone except the original developers.

Ubiquite 14y ago

To a maintainer programmer, the programmer who makes the simplest code.

just2n 14y ago
To an HR person, the programmer with the most number of years of experience. Here's to the technical interviewers out there who know all too well that there is no correlation between number of years of employment as a "software engineer" and the quality of the engineer.

anthonyb 14y ago

> To a project manager, the programmer who hits every deadline (regardless of quality) is a good programmer. > To a customer, the programmer who solves their problem quickest is a good programmer. Up until the codebase is such unbelievably appalling shit that you can no longer add new features, solve problems or reliably hit deadlines. I have worked on too many of these projects to be able to easily count them. Typically, I'll be the one fixing up something after the previous developer has run away or has been sacked. There's often a culture shock when the manager/customer/project manager who is used to calling the shots suddenly finds that their latest idea needs to take a back seat while deeper (often 'invisible') problems get fixed. Perhaps another take is that a "good programmer" is one who is still around and still adding features after a couple of years.

prostoalex 14y ago
In the real world (or at least the world of garage sales and Antiques Roadshow), one man's junk is another man's treasure. In the programming world, one man's treasure is inevitably another man's unreadable spaghetti dependency-ridden junk.
- flyinRyan 14y ago
  No, in the programming world there are projects that met the revolving door of mediocre programmers that no one is proud of, no one understands how it works or wants to, everyone just finds a place they think will have the effect their being driven to make and takes a shot.
- anthonyb 14y ago
  Yeah, the code you're working on is really treasure in disguise. Whatever gets you through the day...
  - ShawnBird 14y ago
    If you are doing it for an employer it is at least worth what they are paying you for it. I would argue that qualifies as treasure.

crncosta 14y ago

Thank you for so enlightening comment.

gadders 14y ago

> To a project manager, the programmer who hits every deadline (regardless of quality) is a good programmer. Obviously not true, unless your project manager is a complete idiot.

Shorel 14y ago
The average manager is dumber than you think.
dkrich 14y ago
Not sure how you define idiot, but more often than not pm's have no formal programming experience which makes it difficult (though not impossible) to understand the value of well-engineered code. The only language they speak is dates, which unfortunately is usually accompanied by loads of unnecessary documentation.
- gadders 14y ago
  Presumably, though, a competent programmer would include the effort required to produce well-engineered code within his original estimate.
  - dkrich 14y ago
    Yeah, but in my experience, the PM's response to that will be "can we get it done sooner?" If the estimated time aligns with what they want, then you're fine. But that's rarely the case and when things slip the code cleanup is pushed to the back burner.
  - vadman 14y ago
    Code that was well-engineered 3 months ago may suddenly become lacking in light of a client having a brilliant new idea/requirement. And a programmer is not always in charge of his estimates. He may have to arrive at it together with his team lead who is under pressure from 2-3 project managers, thus only the minimal reasonable time will be allocated, without concern for architecture changes or refactoring.