I actually think the reverse of this is the biggest problem in our industry. From my experience most programmers I've worked with don't understand the underlying mechanism that make their tools work. And when they hit a bug or a problem their tools weren't designed for, the shit hits the fan. And I've seen the reverse of what you're talking about quite a lot ... developers or managers choosing off-the-shelf software…
I also think that the "use a third party library" mentality can, but not always, cripple programmers. I've almost always written something that has less features/worse code/more bugs than a library that would have been a perfect fit. And I did it intentionally. Why? Because I learned something new. I've written my own C++ DirectX game library... then went out and used HGE/Goblin 2D. It made me a better programmer bec…
First Rule of Programming Is Don't Program
71–80 of 90 posts
Re: First Rule of Programming Is Don't Program
#72#1 Rule of programming ist. Don't talk about programming. #2 Rule of programming ist. Don't talk about programming. Was intendet to be funny, but I just realised it makes a lot of sense.
"Talk is cheap. Show me the code." - Linus Torvalds
In reality, this clever quip is just Linus' way of telling people to go away. He certainly talks a lot about code he has no intention of writing. (He does write a lot of code, too.)
Re: First Rule of Programming Is Don't Program
#73Re: First Rule of Programming Is Don't Program
#74Here's a typical example, one I just ran into today. For a course, I need to enter some data into some system that stores grades. It doesn't just store grades, though, it tries to calculate grades--by various rules and heuristics, which you are likely to misunderstand. They have written a lot of code for the import process, to, you know, take the burden off the poor teacher, by calculating the grades.
Of course, it's such a pain, and so error-prone, the much easier solution would be to just make a spreadsheet containing the grades and upload it, and have the program do nothing but display the results or whatever actually needs to be done. That would remove 95% of the code written for this thing. And make it work better.
Another one, which I ran into a few weeks ago. I needed to add a class. The professor needed to approve it. The software was so confusing, the prof couldn't figure it out (he is a world-renowned professor of computer science, BTW). After a couple weeks of this, I finally got a sheet of paper and had him sign it. I brought that sheet to the expert in operating the mysterious System, and that finally got the job done.
Some software does obviously help the university run better. Every line of code after that makes it run worse.
Re: First Rule of Programming Is Don't Program
#75Top Three Rules:
1. Before you start writing something, make sure it'll actually reduce workload in the future. (laziness)
2. Borrow liberally from others -- especially open source code -- because that's the quickest way to success. Why waste time rewriting stuff that others have written, when that'll take three times as long and require lots of testing? (impatience)
3. Eventually write your own version anyway, because you can do better than the other guy. (hubris)
The first is what ensures you're writing software that should be written.
The second is what ensures that you write robust software with reasonable efficiency, and what protects you from getting a reputation as someone who badly implements a lot of cruft that someone else has already done better.
The third is what ensures that you improve as a programmer, rather than just getting into the tired rut of playing Legos with other people's libraries and never learning anything new.
Re: First Rule of Programming Is Don't Program
#76The first rule of programming is indeed "don't program". But that's not because buying off-the-shelf code makes you more productive than writing code yourself. It's because software solutions are usually worse than manual solutions. Here's a typical example, one I just ran into today. For a course, I need to enter some data into some system that stores grades. It doesn't just store grades, though, it tries to calcula…
Write code to solve the core problem. Don't write code for the rest unless it's really needed.
Re: First Rule of Programming Is Don't Program
#77"Everything that can be invented has been invented." Attributed to Charles H. Duell, Commissioner of the U.S. patent office, circa 1899
Re: First Rule of Programming Is Don't Program
#78Earlier quoted context omitted.
I also think that the "use a third party library" mentality can, but not always, cripple programmers. I've almost always written something that has less features/worse code/more bugs than a library that would have been a perfect fit. And I did it intentionally. Why? Because I learned something new. I've written my own C++ DirectX game library... then went out and used HGE/Goblin 2D. It made me a better programmer bec…
It's worth noting that your learning experiences and experiments don't need to become production applications, though. This is what gets many people into trouble.
Merely my $0.02.
Re: First Rule of Programming Is Don't Program
#79"Use VB.NET or Delphi for the front-end user interface." Or, you could use something that's cross platform like Python.
Using which Pythonic stable, tested, documented drag-n-drop GUI/RAD toolkit?
Re: First Rule of Programming Is Don't Program
#80Earlier quoted context omitted.
It's worth noting that your learning experiences and experiments don't need to become production applications, though. This is what gets many people into trouble.
Not being able to write your own code to deploy into a production environment won't get you very far as a software developer. Merely my $0.02.