4 ms·

In all fields there is a minority who are not very good at what they do. I think, though, that in programming that minority might actually be a majority. The th

by cjfd 7y ago

In all fields there is a minority who are not very good at what they do. I think, though, that in programming that minority might actually be a majority. The thing is, if you are a poor plumber who causes floods in peoples houses you are not going to be in business for a very long time. In programming there seems no such discipline because it actually takes somebody good at programming to perceive the difference between good and bad programming. And if the programming project is a disaster right now the cause of this might be bad decisions made 5 years ago and the people who made them are already gone thereby shielding themselves from the consequences of their actions. In a healthy programming department there should certainly be a small influx of new people and new ideas but also the stability of people who see the project as their personal responsibility.

MisterTea 7y ago
> The thing is, if you are a poor plumber who causes floods in peoples houses you are not going to be in business for a very long time. That might be true if the pipes leak after repair or installation. But what if the job holds up long enough to allow the plumber to avoid responsibility? Same with software. It has to just work well enough to appear functional and for long enough to allow the developer to quickly shed responsibility and put distance between them and the customer. Then blame them for the error and force them to pay for support. Dealt with an ERP system like that. Didn't matter how fragile or crappy their system was, you had to pay tech support to fix their bugs (windows 7 updates broke it frequently ...) Twice it nuked its own DB and had to restore from backups. We had to pay tech support to tell us that. They're still in business. Once they got you on the hook and their system becomes the companies lifeblood then you tend to eat the crap sandwich and pay up. Then if you leave a bad review they sue you for defamation.
pmichaud 7y ago
Programming is more like trades than you think. A bad plumber might occasionally cause a flood, just like a bad programmer might occasionally cause a hard crash during an important sales presentation, but actually bad plumbers use sub par material, and install them incorrectly, and you don't know until 5 years later when your first floor is flooding because a pipe joint inside the wall finally burst after the 1000th time water hammer slammed it. And, like programming, sometimes you'd find someone who actually just didn't know what they were doing because they were inexperienced, and sometimes you'd find someone who was rushed and underfunded, but in either case they are generally long gone, and the cause of the ultimate failure isn't perfectly clear, so the world turns and everyone keeps plumbing, for better or worse. I can tell a similar story for almost all trades.
- cosmodisk 7y ago
  Used to work in plumbing. One morning coming to work and see a waterfall coming from the 3rd floor..The apartments were complete with kitchen furniture installed. Turns out one idiot didn't solder an elbow,while other didn't test it properly and the third signed it off and gave green light to turn the water for the entire block.. It took many people and a lot of time to undo this. Not much of a difference when things go wrong in code.
techslave 7y ago
> it actually takes somebody good at programming to perceive the difference between good and bad programming. sorry that’s not true. there are plenty of products (let’s limit ourselves to digital products) where consumers can differentiate between good and bad programming. they may not realize it’s the programming that’s the problem, but they can tell the difference. for products where the user can’t tell the difference, does the difference matter? good enough is literally good enough.
- cjfd 7y ago
  The customer can and will perceive bugs. E.g., I used to own an MP3 player that would crash regularly. Everybody can notice that a crashing MP3 player is lacking in quality. What is more difficult is knowing who in the team contributed to a good or to a bad result and who of the programmers was a dead weight on the team. One really needs to know a lot about programming to say anything useful about that. I agree that what the user can tell is the most important attribute of quality. There is is another important matter, though. This is how easy it is to modify the software. Good code can relatively easily be extended to incorporate new features and bad code makes this as difficult as possible.
dfraser992 7y ago
One of the best clients I had told me something once (she knew IT pretty well and was a very good manager). (paraphrasing) In her experience, only 10-15% of people in IT actually knew what they were doing and were good at it. The next 20%-25% had something of an idea and could get stuff done, but you had to pay attention to them. The bottom 65-60% were basically useless.... I think it does take a certain <something> to really grasp this field at a deep level, but as most jobs are CRUD type ones, that level of skill is not essential - and as always, the money / business side of things always trumps the engineering.

by cjfd 7y ago

MisterTea 7y ago

> The thing is, if you are a poor plumber who causes floods in peoples houses you are not going to be in business for a very long time. That might be true if the pipes leak after repair or installation. But what if the job holds up long enough to allow the plumber to avoid responsibility? Same with software. It has to just work well enough to appear functional and for long enough to allow the developer to quickly shed responsibility and put distance between them and the customer. Then blame them for the error and force them to pay for support. Dealt with an ERP system like that. Didn't matter how fragile or crappy their system was, you had to pay tech support to fix their bugs (windows 7 updates broke it frequently ...) Twice it nuked its own DB and had to restore from backups. We had to pay tech support to tell us that. They're still in business. Once they got you on the hook and their system becomes the companies lifeblood then you tend to eat the crap sandwich and pay up. Then if you leave a bad review they sue you for defamation.

pmichaud 7y ago

Programming is more like trades than you think. A bad plumber might occasionally cause a flood, just like a bad programmer might occasionally cause a hard crash during an important sales presentation, but actually bad plumbers use sub par material, and install them incorrectly, and you don't know until 5 years later when your first floor is flooding because a pipe joint inside the wall finally burst after the 1000th time water hammer slammed it. And, like programming, sometimes you'd find someone who actually just didn't know what they were doing because they were inexperienced, and sometimes you'd find someone who was rushed and underfunded, but in either case they are generally long gone, and the cause of the ultimate failure isn't perfectly clear, so the world turns and everyone keeps plumbing, for better or worse. I can tell a similar story for almost all trades.

cosmodisk 7y ago
Used to work in plumbing. One morning coming to work and see a waterfall coming from the 3rd floor..The apartments were complete with kitchen furniture installed. Turns out one idiot didn't solder an elbow,while other didn't test it properly and the third signed it off and gave green light to turn the water for the entire block.. It took many people and a lot of time to undo this. Not much of a difference when things go wrong in code.

techslave 7y ago

> it actually takes somebody good at programming to perceive the difference between good and bad programming. sorry that’s not true. there are plenty of products (let’s limit ourselves to digital products) where consumers can differentiate between good and bad programming. they may not realize it’s the programming that’s the problem, but they can tell the difference. for products where the user can’t tell the difference, does the difference matter? good enough is literally good enough.

cjfd 7y ago
The customer can and will perceive bugs. E.g., I used to own an MP3 player that would crash regularly. Everybody can notice that a crashing MP3 player is lacking in quality. What is more difficult is knowing who in the team contributed to a good or to a bad result and who of the programmers was a dead weight on the team. One really needs to know a lot about programming to say anything useful about that. I agree that what the user can tell is the most important attribute of quality. There is is another important matter, though. This is how easy it is to modify the software. Good code can relatively easily be extended to incorporate new features and bad code makes this as difficult as possible.

dfraser992 7y ago

One of the best clients I had told me something once (she knew IT pretty well and was a very good manager). (paraphrasing) In her experience, only 10-15% of people in IT actually knew what they were doing and were good at it. The next 20%-25% had something of an idea and could get stuff done, but you had to pay attention to them. The bottom 65-60% were basically useless.... I think it does take a certain <something> to really grasp this field at a deep level, but as most jobs are CRUD type ones, that level of skill is not essential - and as always, the money / business side of things always trumps the engineering.