Live data from Hacker News

First Rule of Programming Is Don't Program

news.ycombinator.com

71–80 of 90 posts

Re: First Rule of Programming Is Don't Program

#71
post #55

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…

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.

Re: First Rule of Programming Is Don't Program

#72
post #69
post #62

#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

The second line is a great counter-argument.

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

#74
The 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 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

#75
Nah.

Top 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

#76
post #74

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

tl;dr version:

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

#78
post #55

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

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.

Re: First Rule of Programming Is Don't Program

#79
post #36

"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?

There are a lot. the built-in TK library has worked well for me in the past. It supports some drag and drop.

Re: First Rule of Programming Is Don't Program

#80
post #78

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

But unless you're a web host or something, you are not being paid to write web servers. In the limited amount of time you have to solve your business's actual problem, do you want to learn the ins and outs of HTTP, or do you want to learn the ins and outs of the actual problem you are trying to solve?
Post reply on HN