Note: If a programmer only writes programs for her own use, "competency", as defined above, is all but irrelevent. Whatever works.
Controversial, but true.
Note: If a programmer only writes programs for her own use, "competency", as defined above, is all but irrelevent. Whatever works.
Controversial, but true.
Very, very few non-trivial pieces of code are completely bug-free, and building anything interesting under normal time constraints is really difficult and expensive to prove 100% correct.
So, I guess that point is true, but ultimately not very useful.
The same is true about most software people write--it is also cheap and disposable. Often, having something that works well enough now is better than having something that works well tomorrow. I'm not even talking about being impervious to skilled hackers; even breaking under normal use is not necessarily bad.
Sure, if your software would kill people or destroy things, you have an issue. If your software is very critical and usually above suspicion (like a compiler, say) this would also be a problem. But if you're just writing a web app to share cat pictures or some internal tools or really most any other type of software? It's most often better to be cheap and fragile than good and solid.
My laptop is probably my single most important possession. (Yeah, I'm a student so I don't really have much else :P.) Do I have a Tough Book which is nigh unbreakable? Nope. I have a laptop which is actually fairly easy to mess up. And it is in every practical sense the better choice.
This is, coincidentally, why I think the cynical view of "planned obsolescence" is somewhat shortsighted. Sure, in a sense it's bad that electronic gadgets fall apart after a couple of years. But there's no cynical force behind all this: the simple fact that you wouldn't pay twice as much for a phone which is only more sturdy--but not more capable--is what drives the markets. If you were really worried about it, you would have bought a purpose-built device that would hold up better; instead you bought something cheaper which will break sooner. And this is a perfectly reasonable compromise to make!
I take the opposite view. I like durable software. And that's how I build my systems. If they get trashed, they can be restored in minutes. I'd rather spend my effort preparing simple durable systems that can be restored easily than building complex, fragile systems that would be difficult to reconstruct if something goes wrong. I've heard that sometimes things can go wrong.
Finding bugs in Knuth's or NASA's code might be beyond "a reasonably skilled hacker". To find bugs in that code you would likely have to be "highly skilled", above average.
Everyone makes mistakes. Even professionals who are licensed. The idea is to minimise them to achieve a reasonable, expected level of "correctness". Competent does not mean "perfect". It means no stupid mistakes.
In my biased opinion, there's a high tolerance for stupid mistakes in software.
Off the top of my head: seL4, a correct microkernel...pretty nontrivial!
source: http://ertos.nicta.com.au/research/l4.verified/numbers.pml
IMHO, these guys are heros merely for undertaking the task, let alone completing it.
They don't want to admit their mistakes or that someone else might understand things they don't. They actually think they are being smart when they are really being stupid.
Certainly not looking for "votes" with this one. Although I did get an upvote immediately, then a downvote from, who would have guessed, a closed source developer.
I'm not a fan of StackOverflow. There is a lot of stupidity and herd mentality there. It's not where I would look for "competent programmers". Like finding a needle in a haystack.