
First Rule of Programming Is Don't Program - cyman
While us programmers tend to say "I'll just program it myself" it is actually much faster to:<p>- Buy an off the shelf program and take 3 hours to read their proprietary API for extra functionality.<p>- Use an existing library and read the documentation rather than building your own code.<p>- Use VB.NET or Delphi for the front-end user interface.<p>- Buy a properly documented royalty-free library for under $1000 rather than spend months integrating open source code.<p>- Use Python or VB.NET even tho it just feels right to use Java/C. (Ok, I said it. Now if I can only get this VB.NET flame shield program to finish loading.)<p>Unfortunately, us programmers tend not to do this. "Oh, we need a queue class? I'll just build it myself, takes like 30 minutes tops."<p>As coders, we need to think like an engineer who is building a car. No engineer building a car will make the engine or windshield themselves. But us coders do this all the time.<p>There are 2 parts to every program:
[1]: The new scientific code/algorithm you are writing. Which is typically quite small. (5%) [2] Everything else. (95%)<p>How many times have I got that urge.. "I don't want to do the research. I want to jump right in.. I bet I can finish this tonight.."
90% of the code out there is already written. It is more about adding the glue. And of course, finding it and <i>reading</i> the docs.
======
viraptor
That looks like the manager's (or any other person spending money, not writing
code) point of view... In reality you missed a couple of things:

\- Buy an off the shelf program and take 3 hours to read their proprietary API
for extra functionality. Then learn that you cannot integrate it into the
current system (because of licensing, data format, missing features). Since
you cannot make changes to the off the shelf program, you have to rewrite most
of the existing code, just to satisfy the programs expectation. Or spend a
month writing software that does a two-way sync between the proprietary API
and the current data. Then learn that the API documentation is not
complete/correct, then that new versions come out once a year - whether you
need a bugfix or not.

I agree with the rest though... if there is a library, use it. Pay for it if
you really need it. Just make sure you can modify it when needed and that you
can do what the api/docs says you can - otherwise the software you bought is
worth nothing as soon as you hit a problem, or you spend more money working
around the problems than rewriting the software from scratch would cost.

~~~
jaddison
I'd say that if you're buying an off the shelf program, it's likely because
implementing it would take FAR longer than the (example) 3 hours to
investigate their proprietary API.

I think there is still a valid trade-off in purchasing - it just has to make
sense, is all. If the problem is _big_ enough that it's unwieldy enough (ie.
take too long to develop and TEST internally), then it definitely makes sense
to investigate 3rd party options.

That said, developing internally is sometimes the only answer: when you don't
get a good feeling from the 3rd party options (based on research), when the
3rd party cost is too high, etc.

Of course... it's usually more fun to develop internally. :)

------
bad_user
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 with no clue of what
they are choosing, just to spend countless resources and important amounts of
money ... later to realize that it doesn't fix their problem. But they use it
anyway, adapting the problem to the software, just to get a return of
investment ... which is the most idiotic thing one can do. But it happens
quite often, especially in big companies that get lured by salesmen with
promises of greatness.

Another thing that happens is that quite often I've seen situations where
inventing the wheel is faster than using something prebuilt. That's because
software development is not like lego-building. Many times you'll find a
module that's close to what you want, but it's not good enough. So you start
fixing that, and then you realize that the mismatch is greater than what you
thought, and you lost more time than doing it from scratch and keeping it
simple.

And more to the topic ... the first rule of programming is there are no rules.
What works for one project, doesn't necessarily work for another.

Also, developers that consciously and constantly try to "keep it simple" and
"not to repeat themselves" are doing a pretty good job at not reinventing the
wheel anyway.

~~~
alttab
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 because I understood why the design decisions were made because I
had similar problems when doing it myself.

I've written my own PHP framework. Why? Same freaking reason. I can look at
similar frameworks, CakePHP/Django and quite literally see what it was they
were doing under the covers without looking at the source because I've solved
the same problem myself.

In the event that there isn't a third party library out there that does what
you want, the programmer who is accustomed to look for those first will be
screwed. They've never had to make a large system by themselves and they don't
understand ahead of time what types of problems they'll run into because
they've used other frameworks that have prevented them from making those
mistakes.

tl;dr; Using a framework just because its there is similar to a parent
coddling a child. When its time to enter the real world they simply won't be
ready.

The anecdote here, I believe, is knowing when doing it yourself is a great
learning experience, vs a COMPLETE waste of time. Always doing it yourself is
stupid, but never doing it yourself is the easy way out.

~~~
jrockway
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.

~~~
alttab
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.

~~~
jrockway
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?

~~~
japherwocky
deploying is one of those cornerstones that you need to get right once, right
at the beginning. #twitter

~~~
jrockway
You are not Twitter.

------
jaddison
I'd say it can be simplified even further:

THINK before you SOLVE.

A natural tendency for programmers/developers is to move towards a knee-jerk
reaction of "I'll just start coding this". It's not that good solutions don't
come up from that line of thinking; it's more that - as cyman states - there
are faster ways to accomplish results if you simply think about how you're
going to solve the real problem(s).

Once a problem is analysed and broken down into it's appropriate
tasks/needs/requirements, sometimes a credit card solves the problem faster
(and better).

Oh, and when you _purchase_ solutions, you typically can investigate APIs and
system requirements beforehand. Even after purchase, most reliable solution
vendors offer support/money back guarantees.

~~~
ErrantX
I believe this is actually a much better rule.

There is the other knee jerk (and a dangerous one) to do the reverse and just
use off the shelf kit for large swathes of functionality.

We have one contractor who did just this and it currently the project is 3
months overdue as he is reworking large portions and sections so that it can
do the things we originally asked of the program ;)

Formulate your approach _then_ decide what can use pre-built packages and what
needs to be hand coded.

"Dont program" can be as dangerous as "knee jerk" programming.

~~~
JoeAltmaier
Agreed. I tell my partner "We can write that easy!" and he always replies "We
CAN do ANYTHING, Joe. What SHOULD we do?"

------
nostrademons
This is one of those mantras that I lived by when I got out of college, and
then found that the reality was far more complicated than I initially
believed.

There're costs and benefits both to implementing something yourself and to
using an off-the-shelf solution. It's a given that if you do something
yourself, it will take 3 times as long as you expect, and you will be finding,
tracking down, and fixing bugs long after you thought you'd be "done". And
then if you bring in other people to help you, they'll all have to go through
the same process.

But using off-the-shelf solutions has hidden costs too. Abstractions leak;
that 3rd-party library never completely shields you from the complexity it
purportedly solves. There may not _be_ docs, or they may be incompletely
specified. You'll probably have to spend some time customizing it, and your
customization code may often end up more convoluted than just reimplementing
from scratch. You'll probably run into incompatibilities between different
libraries. The libraries may themselves have bugs that you have to dig in and
fix.

Worse, reliance on off-the-shelf solutions often warps your product so that it
fits the solutions you have available. ("When all you have is a hammer,
everything looks like a nail.") As much as people _say_ that they'll figure
out the problem first and then pick solutions to solve it, the choice of
solution then feeds back into the types of _additional_ features you can add.
If you decided to use an RDBMS early in development and then find you want to
add, say, clustering of related items where "related" is defined by a fuzzy
matching function, you'll likely say "This is too hard" and fall back using an
exact match, one that can easily be stored in a relational table. Users
suffer.

Obviously, a blanket rule of DON'T PROGRAM is wrong, because many successful
websites throw away all the off-the-shelf solutions and write their own.
Google's probably the most obvious one. I'd amend it to "Carefully consider
the infrastructure you'll be using, and only reach for the third-party
solutions when they save you significant time and complexity over doing it
yourself."

~~~
nrr
I think another point to emphasize is that using a third-party solution
shouldn't in all cases be a long-term solution.

Consider keeping such a chunk of code around only long enough to get the
product shipped and paying for itself. At that point, make an attempt to
justify keeping it around, especially after seeing how it fits into the big
picture of your product.

------
jrockway
I would never _buy_ a library, but I've never had that option either. Every
tool I use is open source, and I build small proprietary applications around
the open source stuff. (Making web pages and parsing CSV files is not my
business domain, so I let the community handle those.)

I will say this -- the first step to not writing too much code is to reuse
your own "internal" code. It's simple; instead of cut-n-paste-n-modify, make
it a library, and make the per-app "modification" some different parameters
you pass to the library. Now a bug that affects all the possibilities can be
fixed everywhere at once. And, if someone understands one app's usage of this
library, they will understand the other app's usage, as well. Less to think
about, less code to maintain, and nothing to buy.

The next step is letting other people fix your bugs for you. My last job was
for a company that routinely factored out part of their apps into community
libraries. If you use Perl, you probably use Moose -- that was a piece of an
internal app at one point. Releasing that bit of code changed the entire Perl
community, and it made maintaining our software even easier. There are plenty
of times I've hit a Moose bug only to have it fixed in 30 minutes by Someone
Else. (To be fair, I've fixed other people's Moose bugs too.)

So anyway, the word "reuse" is thrown around a lot, but it is really an
important concept. I have reused every piece of code I've written in the last
few years -- once in my application, and once in the test suite.

If you're not reusing your code at least once, you're doing it totally wrong.
If you're not reusing your code more than once, you're missing out on a lot of
good things.

~~~
JoeAltmaier
Bought libraries are static; you can't get them changed. Open source may be
architected wrong; not componetized the way you need; have bugs; build on the
wrong platform...BUT you can fix all that. There is probably something in
there you need, that has already been debugged, and that's why I consider Open
Source first.

------
makecheck
Even if it were "much faster", this isn't really the goal, because code
writing is usually the quickest step; at least, it is if your employees are
competent. What matters more is how maintainable your project is, and how easy
it is to deploy.

I may use several libraries, but I lean heavily on platforms; for instance, I
have no problem using what's in /usr/lib from a typical Linux distribution, or
the Python standard library. This keeps deployment pretty simple, and I can
rely on well-tested components that are widely used and unlikely to go away.
The platform libraries are also usually free. And I can ask or hire anyone who
knows something about them.

While I don't rule out incorporating another library, this is _definitely not_
a rule of programming. A 3rd party library has to do _a lot_ to justify its
added deployment complexity. After all, maintainers will have to read through
API documentation just to figure out what something does, and this shouldn't
take more time than it would take to read through my own implementation of the
functions.

------
blue1
#1 Rule or programming is: programmers start counting from 0, not from 1.

~~~
ardit33
unless you are programing in Lua or Ada. Counting from 1 makes sense.

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

------
silvio
Most people fall for the songs of the unwritten-code. When confronted with
existing code, they can see all of the unevenness of the terrain, the special
cases that needed to be shoe-horned because the original architecture didn't
allow for them. It is at this time when the unwritten-code starts luring them
inside their heads, a sweet, seductive melody. They (who am I kidding, we)
think of a perfect generic architecture which will take into account all
cases. This architecture will be so extensible that when new requirements
arrive, it will take care of them without mutating the design. And performance
will be equal or better.

It's all good, if it wasn't for one little problem. Unwritten-code is non-
functional. Until we sit down and spend weeks --yes, weeks-- working on it,
it's absolutely useless. What is worse, once we start getting better clarity
on the domain, we start to understand what those architectural bumps were on
the original codebase. At best, our new architecture will be better than what
existed before, but our codebase is yet to be tested on the wild.

Oh, the wild, the proverbial real world where code is tortured in ways that we
failed to imagine. If your code runs on a server, you may be lucky. Given the
continuous feedback, you can patch it and evolve it, effectively reacting to
the environment where your program runs. But if you pack it in a released form
and part with it, then you're in for a ride.

There's a few rules to heed when rewriting something that's readily available,
they are:

1- You are an expert in the domain of what you're rewriting. You're only an
expert iff you've written the previous codebase and maintained it for years or
you're an user of the codebase and worked with it for years. Yes, years.

2- You have the time and disposition to claim ownership (design,
implementation, unit testing, functional testing, maintenance) of this code.
It's like having a baby, you have to see it through College.

So, what to do? Write new functionality using existing parts. The value is on
the new parts, and since they're new, there are few or no experts, and anyone
can go ahead and explore that vast unknown.

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

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

~~~
apotheon
tl;dr version:

Write code to solve the core problem. Don't write code for the rest unless
it's _really needed_.

~~~
gcb
he could have used that concept for the post text :)

------
edw519
I wonder what OP has seen to reach these conclusions because this is not my
experience. Not even close.

What I have experienced in commercial environments:

\- Software make/buy decisions are rarely made by programmers, but are made
strategically with programmer input.

\- "Everything else (95%)" can be many things. Sometimes you can plug in
standard stuff (utilities, human resources, accounting), often you _must_
write original code to handle your company's proprietary processes.

\- In theory, existing libraries and frameworks are great. In practice,
sometimes they make sense, but just as often they force you into a dead end.
It may be tough to code at a low level, but the advantage is that you can
almost always do what's needed.

\- Having source code and being able to do something with it if often a _huge_
competitive advantage. I forget how many times I've witnessed M & A scenarios
where the acquirer bought the acquired because the former was able to change
their business software on the fly and the latter had an unchangeable package.

------
cromulent
I think "Don't solve the same problem twice" might be a good way to say the
same thing.

If someone else has solved the same problem, use their code. If your problem
is different enough, solve it yourself.

Knowing the difference is the hard part.

Also, sometimes the problem actually is "Purchasing a complementary solution
will take 6 months of managerial approvals". The solution is to build it
yourself.

------
jacquesm
There seems to be some tension in your argument regarding the use of code.

If everybody would reason the way you did then we'd be stuck at version 1.0 of
just about everything because nobody would get off their asses to do something
new every now and then.

So it's a treshold problem. At some point the tension between that which is
available and that which has to be done becomes so large that someone will
stand up and says 'let's fix that, once and for all'. This person will then
put in an enormous amount of time on top of what it would probably have taken
to fix just the original problem.

And that's exactly how progress is made in the software world.

So, the premise you make is an idealistic one, in an ideal world, such
libraries and bits and pieces should be available, for sale, well documented
and 100% applicable.

In reality that is definitely not the case.

You are right that many people will fall for the 'let me do that' temptation
when in fact they would be better served by using something off the shelf.

To keep your engineering analogy alive: If an engineer working on a car even
_could_ go and make his own bolts then that would be the road to total
madness. There is lots of standardization and materials knowledge available to
'hard' engineers that is simply not there for 'soft' engineers, and because
the price of the tooling is essentially zero the threshold for re-
implementation (hopefully in a novel and better way) is very low.

Maybe it's too low, but that's a policy decision, not a technical one.

And if you are not under a deadline and simple trying to get the hang of stuff
nothing will teach you better than to re-implement some of the better
understood algorithms, especially queues, lists stacks and so on.

These are the staple of many larger structures and to understand them well
(and how tricky they are to get right) is essential knowledge.

------
rythie
Virtually everyone I meet nowadays tells me they are using some high level
framework like Rails, CakePHP, Django with jQuery/Prototype etc. or building
on top of Wordpress. Even .net is pretty high level.

So, I'm not sure people are doing what you are saying.

------
techiferous
Agreed. I would broaden the #1 Rule of Programming to be:

SOLVE PROBLEMS.

Sometimes you do this by programming it yourself, sometimes by doing it off-
the-shelf, but if at the end of the day you've solved someone else's problem,
they will give you money.

~~~
v4us
Yup, you are right. But solve problem your best and as fast as you can :-)

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

~~~
barrkel
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.

------
warp
I always try to find a library which does what I need before writing one
myself. However, I rarely consider proprietary libraries.

With open source or free software libraries I can quickly get some idea of how
well-written the library is, and how well it can be extended in the directions
I need it it to.

In rare cases I might pick a propietary library for a project at work, but
even then I only pick those for which I get the source code. When a client
calls with some issue which needs an immediate fix, I can actually dive in and
fix things.

------
jcromartie
Also: 9 times out of 10 you can do something faster by hand even if you think
that a shell script, regex/sed command, or custom emacs extension would do the
job better.

------
growt
#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.

~~~
bk

        "Talk is cheap. Show me the code."
        - Linus Torvalds

~~~
jrockway
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.)

~~~
bk
Regardless of its originator, to me the quote just serves as a reminder that
my true productivity and progress are based on the quality and speed with
which I can write (or integrate other people's) code (as opposed to talking
about features, dreaming of all the way things could be done, etc.).

It's easy for me to outline how a great piece of software X is supposed to
function, but I'm still surprised every time how much more work ends up going
into the actual implementation compared to the conceptual simplicity of the
design. So, similar to "writing is thinking" I believe that "coding is
thinking" as well.

------
Intrawebs
This is a balance one has to make when working for someone else. Often, all of
your suggestions you made end up with more limitations than freedoms.

You need freedoms within apps that are going to be around for the long haul.

Example... Do I build an app in MOSS 2007 or simply use asp.net. Ya, then
comes MOSS 2010 and you need to do a rewrite, if you used asp.net then there
is no rewrite needed.

------
v4us
Of course, "Don't PROGRAM" is a greate rule. If you can use libriry of
algorithms or something else that is made by really professional programers
and fulfit all your requerements it's good. To buy this library will save your
time (=money).

But there are many cases when the best solution is to program. For example: Hi
performance software development, sequrity issues and etc.

~~~
nrr
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 case of "someone
else's problem." If you purchase a component, I'd say you have a lot of
leverage to complain that a particular piece of software isn't performant or
secure. If it's open source, write patches and, if politics becomes a problem,
step on someone's toes.

~~~
v4us
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

~~~
nrr
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. ;)

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

~~~
nrr
Fortunately, academic pursuits only require compromises in terms of politics.
;)

------
alexkearns
If you ever want to create something better than what's out there, you'll have
to program itself, and if you want to get to the situation where you can
create something better than what's out there, you're going to have to do a
helluva lot of programming, not just read documentation and try to fit
together other's people's software with the minimum effort.

------
japherwocky
bleghhh, maybe you are underestimating the joy/morale of writing what you
_want_ to write.

Prototype a cog in an afternoon; you'll have a much deeper understanding of
how that cog should work, and you'll be a better judge of the available cogs.

FrankenCode is a perfectly viable strategy, but it's gross and boring.

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

~~~
v4us
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.

~~~
visitor4rmindia
Ok - I program in a software product company. Our business depends on getting
out the best solution - not the fastest solution. It's definitely not a
"hobby".

Some businesses may requires "fast" solutions, but I would argue that most
businesses would be better off with "the best" solutions. And, in any case,
requirements of a certain segment of businesses shouldn't really qualify as
"The No #1 Rule Of Programming".

------
ErrantX
I kind of agree: however I think if you only spend 3 hours learning the
proprietary API and reviewing the code in the package your going to end up in
almost as bad a place.

I'd factor it at anything from 8-24 hours _at least_.

------
elptacek
"Everything that can be invented has been invented." Attributed to Charles H.
Duell, Commissioner of the U.S. patent office, circa 1899

~~~
apotheon
I wish the patent office had taken that to heart and stopped issuing patents.

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

~~~
v4us
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

~~~
barrkel
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.

~~~
v4us
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

------
cesare
Great advice. Otherwise, you might learn something. By doing. Which is so
passé.

Why is this site called ' _Hacker_ News' anyway?

------
pmorici
"Use VB.NET or Delphi for the front-end user interface."

Or, you could use something that's cross platform like Python.

~~~
jodrellblank
Using which Pythonic stable, tested, documented drag-n-drop GUI/RAD toolkit?

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

------
omarish
I'd be interested to hear what some of the successful founders in YC have to
say about this one.

------
scotty79
I'd say first rule of programming is KISS. It kinda includes your rule.

------
mcotton
There is something to be said for writing code you can be proud of. I'm always
working on finishing projects faster and not introduce bugs in the name of
speed.

I can't see a furniture craftsman recommend that you just buy a chair at IKEA.

This philosophy leads to becoming the IKEA of software.

~~~
pretzel
>This philosophy leads to becoming the IKEA of software.

As in the most succesful?

~~~
mcotton
If that is what you are going for, then yes. There is nothing wrong with that
strategy. I haven't found anything remarkable at IKEA (except for price).

~~~
xcombinator
I have. My office leather chair was bought in IKEA more than ten years ago. It
was cheaper than alternatives, I bought the alternative because I wanted
something good that last. It lasted 6 months of use, I had used a lot of
chairs in my life,and all broke fast(I'm tall, maybe that's it) I think my
IKEA is way way better in terms of quality, not only price.

I have lived in places with old mahogany furniture(from Congo), strong,
beautiful, heavy wood, I prefer IKEA furniture for living, I don't need to
care if I broke it, is lightweight, and I don't feel bad about the
environment.

Having someone do something using his own hands doesn't mean is better, in
fact, it uses to be worse, compare a Toyota manufactured with robots to a
handmade car and tell me.

------
fjabre
Would mint.com be a good example of this philosophy..?

------
olliesaunders
I prefer: No code is better than no code.

Or: Programming takes eons.

------
ulf
#1 Rule of Programming Is..There is no Rule #1

~~~
castis
sure there is. mine is: automatically assume that every user is out to
hack/deface/fuck with your app.

------
sli
Well what's rule #34 of programming, then?

~~~
nostrademons
[http://bogdan.org.ua/2009/01/05/unix-sex-linux-command-
refer...](http://bogdan.org.ua/2009/01/05/unix-sex-linux-command-
reference.html)

------
rick_2047
I would like to take a poke at the automobile engineer analogy. I think the
reason they don't build there own parts is because of one of the two: [1]They
don't know how to build it.These parts are sometimes too advanced for a single
engineer to build.This is because there field of engineering has advanced to a
level to which,I think, software engineering has just not reached.

[2]They don't have the experience points (Money) to buy the material needed to
build those parts. And that's not just limited to material, sometimes even the
tools are too expensive to buy.Not to mention the transport charges.This is
because they are...umm...physical. The parts cost them
materials,chemicals,casting/forging devices etc...etc.

Now on the other hand for a software engineer, [1]If you are worth your salt
its fairly easy to learn anything in programming in time.And I put an
emphasize on "in time".

[2]The cost of material is quite nominal (and transport charges free).And this
is because mostly programming material or tools are not...umm...physical.They
can be easily downloaded from the internet or from any other 'net you are on.

So in my opinion the analogy is just not fair.

PS: For the umm...physical part, I am not satisfied with the word "physical"
to distinguish between programming and automobile tools. So please someone
give me a better word.

~~~
cromulent
How about "hard"?

As in hardware vs software?

I'm just going down to the hardware store to buy a spanner and some raw
materials.

------
ilyak
In Java, you usually do not invent the wheel but rather take an existing open-
source jar.

Even those of them that aren't very good, sadly. But most are.

