Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

First Rule of Programming Is Don't Program

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 90 posts

Re: First Rule of Programming Is Don't Program

#11

Post by barrkel »

tybris wrote: post #5

Not programming is hard work. You will spend about 90% of your programming time integrating other software whether you like or not. By the way, the nr 1 rule is: context is everything. The nr 2 rule is: keep it simple.

Often - actually, almost always - third-party code is too general for the task at hand. If the job you're doing is simple, it can cost less in cognitive complexity to implement it directly, particularly if it's a problem domain you're expert in.

But when integrating, I do prefer to wrap the integrated thing within a simple layer or wrapper, if feasible, that only exposes what I need. That buys me several things: it makes the interface very simple; I can create tests that verify my expectations; I can replace it later without having to clone someone else's API; and the API of the wrapper is almost a bullet-point list for what I'm expecting the third-party code to provide, and as I dispatch from the wrapper to the third-party code, I can verify that it's going to meet my requirements, before having to readjust architecture etc. if I find out it doesn't fit further down the road.

Re: First Rule of Programming Is Don't Program

#12

Post by visitor4rmindia »

Ok - this is a cute post but I'm going to play devil's advocate.

So what if it is faster to do X? I program because I like to. I find it much better than trawling through the net, evaluating a half-dozen alternatives and then cursing as I try to force fit their API into my requirements.

Re: First Rule of Programming Is Don't Program

#13

Post by barrkel »

v4us wrote: post #10
barrkel wrote: post #9

As an odd corollary, in matters of system administration, the exact opposite is usually apposite: AUTOMATE EVERYTHING.

It's kind of the same rule. AUTOMATE EVERETHING == Let something or someone todo your work == Use work of another people == use library == DON'T PROGRAM

Usually the process of automating is writing high-level glue code. So it is a kind of combination; it's using third-party code, but it's also very much programming.

Re: First Rule of Programming Is Don't Program

#14

Post by v4us »

visitor4rmindia wrote: post #12

Ok - this is a cute post but I'm going to play devil's advocate. So what if it is faster to do X? I program because I like to. I find it much better than trawling through the net, evaluating a half-dozen alternatives and then cursing as I try to force fit their API into my requirements.

If you like you may programm but it will be your HOBBY. IF you need something special or it is fater to program yourself DO IT. But Biz needs fast and quility solution.

however i'm in Academia and need to program a lot of by myself, cause i should use some non free library ( cause other people wil lnotbe able to modefy this code and etc.

Re: First Rule of Programming Is Don't Program

#15

Post by nrr »

v4us wrote: post #8
nrr wrote: post #7

Earlier quoted context omitted.

I'm not sure your definition of high-performance software development and mine coincide here, in any sense imaginable. In the programmer-performance sense, just snagging an off-the-shelf component and shoehorning it into your product will let you ship something far sooner than otherwise. Who cares if the code looks nice right now? Just ship the damn thing! In the runtime-performance sense, the whole mess becomes a ca…

I ment runtime-performance. Off-the-shelf components will make you to code fatster and prolly much more flexible. Don't programm is really greate rule. Don't programm and keep your code as simple as possible

You subscribe to the rose-colored glasses version. :) I'm sensing a trust issue or two w/r code written by others, but that's okay.

In reality, while you'd like to keep your code as simple as possible, it's often impossible even to keep the simplest things simple because you have numerous bad designs from the past to use as a foundation for whatever it is you're building.

UNIX? Sucks. X11? Sucks. Windows NT? Sucks. Win32? Sucks. .NET? Sucks. PHP? Sucks. Perl? Sucks. Ruby? Sucks. Everything? Sucks.

Any one of these will pose a decent enough challenge somewhere down the line. What really becomes a problem, though, is gluing a good chunk of that mess together somehow.

Get your product out now and then worry about runtime performance.

If that ends up being a big concern early on anyway, I suppose you could pull a Google and just hype the hell out of your product while letting in a small amount of early adopters. ;)

Re: First Rule of Programming Is Don't Program

#16

Post by v4us »

barrkel wrote: post #13
v4us wrote: post #10

Earlier quoted context omitted.

It's kind of the same rule. AUTOMATE EVERETHING == Let something or someone todo your work == Use work of another people == use library == DON'T PROGRAM

Usually the process of automating is writing high-level glue code. So it is a kind of combination; it's using third-party code, but it's also very much programming.

Yup it is. You know the main idea of all this advices is Try to save your time and power. For administrators: Write code thatwill do your job. For programmers: find someone who have done this work with needed quolity

Re: First Rule of Programming Is Don't Program

#17

Post by jimfl »

Each line of code is a liability. Even tests.

Eventually, something will happen to render that line of code incorrect; either another line of code, changes to other code, changes in the tech stack or 3rd party libraries, and even the domain may change out from under your code.

Re: First Rule of Programming Is Don't Program

#18

Post by v4us »

v4us wrote: post #8
nrr wrote: post #7

Earlier quoted context omitted.

I'm not sure your definition of high-performance software development and mine coincide here, in any sense imaginable. In the programmer-performance sense, just snagging an off-the-shelf component and shoehorning it into your product will let you ship something far sooner than otherwise. Who cares if the code looks nice right now? Just ship the damn thing! In the runtime-performance sense, the whole mess becomes a ca…

I ment runtime-performance. Off-the-shelf components will make you to code fatster and prolly much more flexible. Don't programm is really greate rule. Don't programm and keep your code as simple as possible

Yup it is mix. You know, Life has alot of compromizes

Re: First Rule of Programming Is Don't Program

#19

Post by v4us »

nrr wrote: post #15
v4us wrote: post #8

Earlier quoted context omitted.

I ment runtime-performance. Off-the-shelf components will make you to code fatster and prolly much more flexible. Don't programm is really greate rule. Don't programm and keep your code as simple as possible

You subscribe to the rose-colored glasses version. :) I'm sensing a trust issue or two w/r code written by others, but that's okay. In reality, while you'd like to keep your code as simple as possible, it's often impossible even to keep the simplest things simple because you have numerous bad designs from the past to use as a foundation for whatever it is you're building. UNIX? Sucks. X11? Sucks. Windows NT? Sucks. W…

Yup it is mix. You know, Life has alot of compromizes
Post reply on HN