
What are some things that only someone who has been programming 20 years knows? - mcguire
https://www.quora.com/What-are-some-things-that-only-someone-who-has-been-programming-20-50-years-would-know/answer/John-Byrd-2?share=1
======
cynoclast
He saved the best line for last and knew it:

>Sooner or later, you will meet some older man who has been around for a
while. At some point, this man will lecture you about the Laws of Programming.
Ignore this man entirely.

That said, like everyone else I'm going to add my most salient bits:

1\. Keep It Simple, Stupid

2\. Programming is a lifelong study of the difference between what you said
and what you meant to say.

3\. Reflect reality in your modelling.

4\. If you have to get creative, you might be doing it wrong.

5\. Build tests first when you can.

6\. You're coding for two audiences: The computer and the future programmer.
Favor the latter, because the computer doesn't need help understanding your
code.

7\. There are two hard problems in programming: naming things, cache
invalidation, and off by one errors.

~~~
TeMPOraL
> _2\. Programming is a lifelong study of the difference between what you said
> and what you meant to say._

This week I finished reading "Startide Rising", a 1983 (!) novel. There was
this gem hidden in it:

"You don’t have conversations with microprocessors. You tell them what to do,
then helplessly watch the disaster when they take you literally."

~~~
simtel20
Such an amazing book. I hope you are inspired to read the rest of Brin's work.

~~~
TeMPOraL
I binged "Sundiver" and "Startide Rising" over the last two weeks, and
currently I'm well into "The Uplift War", and planning to continue on with the
remaining three books. I love the universe so far.

Fun fact, in "The Uplift War" (1987!) I found what looks like a reference to
cryptocurrencies:

"The money inside was GalCoin, untraceable and unquestionable throughout war
and turmoil, for it was backed by the contents of the Great Library itself."

------
andyidsinga
three things resonated with me (as a person in the long time programmer camp)

1\. > You’re going to forget what your code does in a few months. Make it
ridiculously easy to read. Sometimes, all you need is a one-liner in sed.

2\. > No matter how many managers are screaming at you, the first step is to
reliably replicate the bug

3\. > Sooner or later, you will meet some older man who has been around for a
while. At some point, this man will lecture you about the Laws of Programming.
Ignore this man entirely.

The first has to do with knowing yourself and having years of experience with
a diversity of tools. (lessons: be reflective and work on a diverse toolbox)

The second has to do with experiencing and learning from team/org dynamics and
to some degree how to operate under pressure.

The third is tricky - key red flag to watch for "the laws of programming" or
"you don't have enough education" or similar put downs. But the older
programmer who is always rolling up his/her sleeves to jump into the bug
fixing process and and help - follow this person around like a puppy and watch
everything - these guys are epic.

edit: one more thought on my note about the third item: look for these people
across the org - technical or business - look for the people who jump into to
constructively help when its needed. (very Mr Rogers)

~~~
mcphage
> The third is tricky - key red flag to watch for "the laws of programming" or
> "you don't have enough education" or similar put downs.

I think the third was an attempt at some humorous self-deprecation.

~~~
andyidsinga
oh geeze - of course :)

problem is -- I've literally had that conversation (when I was the young guy
.. never walked away feeling good).

------
combatentropy
> Good programmers write good code. Great programmers write no code. Zen
> programmers delete code.

I guess then I have been a Zen programmer from the beginning. Maybe it was
because first I was into writing, and my favorite book is the Elements of
Style. I relish deleting code, but you have got to understand I'm not deleting
features, security, or anything.

It is really hard to explain how it's possible to someone who has not known it
first hand, how you can subtract things yet lose nothing --- or even gain
something. The simplest example of how you can delete code and not affect
features is deleting code that was commented out by the last hooligan,
commented out because he did not use version control and was trying different
ways to solve the problem. The next most obvious example is code that is never
run: functions that are defined but never called or, trickier, branch
conditions that will never be true. But most of all I guess I have just worked
with a lot of people who subscribed to the copy-and-paste method of code re-
use. It's easy to pull out the repetition into functions.

One of my favorite examples of less-is-more is outside the field of
programming, in the field of sports cars. The Lotus Elise weighed 1,600
pounds, so even though its engine had just 118 horsepower, it could go 0 to 60
in 6 seconds. In constrast to heavier sports cars, who solved the speed
problem with the more obvious solution of dropping in a bigger engine, the
Lotus also had these advantages: more miles per gallon, faster braking,
nimbler cornering. As the founder, Colin Chapman, said, "Adding power makes
you faster on the straights. Subtracting weight makes you faster everywhere."

How do you shave weight while retaining rigidity? Through another minimalist
technique: reducing pieces. The chassis was of one piece, a "monocoque." Since
things break at joints, instead of reinforcing the joints, you just do away
with them. Steve Jobs, another minimalist, used the same technique in
MacBooks. By cutting them out of one piece of aluminum, the frame can be
thinner and lighter yet still stronger than competitors.

~~~
eddieh
The best code to delete is when someone was cargo cult programming and put
code in that doesn’t do anything or is completely unnecessary in some way.

~~~
pureliquidhw
Just be careful before ripping out too much!

[https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence](https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence)

~~~
eddieh
Yup, that is a risk. I had an issue once where the person transcribed the
wrong bug ID in a comment above a piece of code that appeared as though it was
meaningless. I was able to catch the error and put the correct bug ID in and a
more assertive comment describing why the code was needed.

Long story short, always comment weird shit and use the correct bug ID.

------
njharman
I'm 47. Following is trueabout many things not just programming.

That things happen in cycles. Little is fundamentally new. The time your in
now, your wxperiences, are not all that different than previous peoples.

That young people (definition expands as you get older) really are clueless.
BUT, that is really really important. Without naive optimism and youthful
exurberance (God young people have so much energy, don't squander that) very
little "progress" would be made.

Developement related.

Process matters, a lot. Naming matters. Writing code is not about getting
computer to do something. It's about getting that future developer to
understand what this code is suppose to be doing. Optimization of software
almost never matters. Optimization of developement often does.

~~~
damagednoob
> Naming matters.

Meh. I've gotten to the point where as long as variables are not named 'a',
'obj', 'thingie', e.t.c I'm good. I've gotten into enough arguments about
naming that have turned into bikeshedding that I just don't care. I'll do my
best effort at good names but I will go with whatever your review notes say.
If I need to understand code later I'll rename as I go, do the code change and
then revert them.

I've generally worked on legacy systems and on any reasonable sized system
there will be multiple names for the same business concept embedded all over
the place. You just have to roll with it or be perpetually frustrated.

~~~
mercer
I do agree that in practice proper naming is often absent and too much
frustration over this isn't helpful.

But that doesn't mean it's unimportant! I've found that when I struggle with
properly naming things (outside of anonymous functions), it usually means I
need to stop and properly think about what I'm doing. I've found this to be
the case for both naming functions/methods and naming 'data' (which is why
I've warmed a bit to the idea of explicit typing).

------
Animats
Hard to find bugs often come from violation of an invariant between two
distant parts. Somewhere, part A assumed that part B would do X. If this is
neither machine checked nor well documented, and the program has a long life,
at some point someone will change B and break something. Or A and B will
become unchangeable for fear of breaking something.

This is one of the primary mechanisms by which software ages. It is also the
real justification for comments and internal documentation.

~~~
damagednoob
If you're talking about code comments to me that's a prime example of what
you're talking about in the first paragraph.

------
superasn
My own three things:

1\. It's much easier to figure out something by looking at code samples, other
people's code than reading documentation.

2\. Clever one line code doesn't look very clever 3 to 6 months down the line
and often leads to what was i thinking moments.

3\. Perfectionism including premature optimisation is the progremer's biggest
enemy.

Bonus: programming doesn't make you money, marketing it does.

~~~
TeMPOraL
> _Bonus: programming doesn 't make you money, marketing it does._

This one I find the hardest to accept out of pretty much any advice I've ever
read on HN. All rational evidence points towards this being true, and yet all
my being, all the ethics I have, scream loudly that _it ought not to be so_.

~~~
kristjansson
If it helps, I don’t think that’s a statement of the relative value of
programmers and marketers, but a statement of necessary conditions - a great
marketer without a product is pretty pointless, and beautiful code sitting
unused is pretty worthless.

~~~
TeMPOraL
My point is: just look at the Ask HN thread of yesterday -
[https://news.ycombinator.com/item?id=18047553](https://news.ycombinator.com/item?id=18047553).
Look at the marketing tips. Half of them make me feel dirty just from even
considering them.

------
MrTonyD
I was writing production code over 30 years ago (C, OS, database). It is much
worse to be a software developer now. It used to be a very high autonomy job -
where you were trusted to figure out your work process and usually given lots
of freedom to dynamically define many of your deliverables (within reason). I
remember when I first read about Agile - I looked at the practices and thought
"I've done most of those." But when our nightly builds broke it was no big
deal, we would just fix them when we got around to it (as opposed to managers
now assigning blame and calling in people on weekends to "fix" it). And if
things weren't going well then we might have daily brief meetings for a couple
of weeks. But now there are managers who insist on daily standups irregardless
of their actual business necessity. I could go on and on. There is a reason
why I'm not a practicing programmer anymore - even though I love to code.

~~~
maxxxxx
I agree. I started 25 years ago. My first projects were pretty much "Here is
the problem. You guys figure it out.". And off we went for months without much
reporting back to management. Now everything is very "professional" and
process driven and you barely get space to breathe and think about something.
God forbid to do any experiments.

I don't envy young people who get into the business now. A lot of them will
probably never get the chance to work on something uninterrupted for a long
time. Instead they are being micromanaged daily, have to justify every little
thing they do and don't get much opportunity to make mistakes and learn from
them.

I guess most industries get boring once they mature. Working on cars between
1900 and 1950 was probably much more fun than working on modern cars in a
modern car dealership.

~~~
toomuchtodo
Tech is like being a football player or an exotic dancer: you have a shelf
life. Some people can make it a life long career, I haven't seen that to be
the case though. Get in, make as much as you can, get out into a sane
industry. Plumbers, carpenters, electricians, electrical linemen, welders,
lots of trades make similar to what you'd make in tech, the jobs can't be
outsourced, and you deal with a lot less day to day bullshit (and you usually
have a union protecting your wages and benefits, as well as no such thing as
unpaid overtime).

~~~
technofiend
>Some people can make it a life long career, I haven't seen that to be the
case though

So, what, you've literally never met anyone over the age of 40? 50? 60? in IT?
I'll bet if you think about it for a moment you probably have. But if you
haven't you need to look no farther than Pike and Thompson working at Google
for two examples of older people working on interesting problems at a top tier
company.

Regardleas I don't share in the cynicism and burn out that some have shared in
this thread.

Even if I see some ideas recycled from 20-30 years ago I'd argue the
implementations are novel. Frankly the fact that IT keeps changing is what
makes it fun for me.

~~~
maxxxxx
"I'll bet if you think about it for a moment you probably have. But if you
haven't you need to look no farther than Pike and Thompson working at Google
for two examples of older people working on interesting problems at a top tier
company."

I don't think most of us can follow the example of some superstars.

~~~
nineteen999
On a more mundane level, IBM was full of older techies and programmers. Until
more recently, anyway. In my mid-thirties there I felt like a youngster.

------
notacoward
Code does not exist in a vacuum. There are two flavors of this. Many get the
first part well before twenty years: all code exists to serve someone else's
need. It might be another programmer at the next layer in the stack, all the
way up to making a profit, furthering scientific discovery, or serving
national security. You can _not_ write good code without understanding why
that code exists in the first place. But, as I said, most people get that
before twenty years.

The other way code doesn't live in a vacuum, which I've seen too many people
fail to understand for far too long, is that code is the _tip_ of your
personal pyramid. The foundations of that are your mental health, your
physical health, your family and friends, your professional connections, your
civic connections, etc. If you don't look after those things, it will affect
what code you write and how efficiently you write it, or possibly whether you
can keep coding at all. Think about what it means to be doing this for 20+
years, from young adulthood through having a family and even to the empty-nest
period. Don't burn your bridges or burn yourself out in five years. Learn to
do what you do _sustainably_ over the long haul.

~~~
yesenadam
_all code exists to serve someone else 's need_

I've been programming since the 80s, it all existed & exists to 'serve my
needs' alone. (Well, I have written a few things to help other people.) So
obviously that doesn't seem right to me. Maybe you meant
'commercial/professional code' or something. I wonder what % of the LOC ever
written were to serve the programmer and no-one else.

------
CodeArtisan
>Everything in software development has already been invented. People just
keep rediscovering it and pretending they invented it. Whatever you think is
so cool and new, was copied from Smalltalk, or HAKMEM, or Ivan Sutherland, or
Douglas Engelbart, or early IBM, or maybe Bell Labs.

That's like saying programming language theory stopped 20 years ago and all
the conferences and papers on the subject since then are fraud.

[http://www.sigplan.org/Conferences/](http://www.sigplan.org/Conferences/)

~~~
nindalf
Dismissively claiming "meh, all of this is old hat" makes OP sound wise, but
it doesn't stand up to closer scrutiny. Of course all new languages owe a
great deal of debt to what came before, and that's exactly what you'd expect.
The vast majority of ideas that humans come up with owe a great deal to
previous ideas. We copy, remix, extract the essence, infuse with some
inspiration and voila, new idea!

Take Rust for example. It has several cool features, many of which are copied
from other languages. Only an idiot would sit on the sidelines and say "oh
what's so great about a package manager like cargo, Ruby has had that for a
decade". A smarter person would realise that this is exactly how great ideas
spread, and what's important is the combination of ideas and features that the
language chooses. For Rust it's zero-cost abstractions, a good package
manager, no data races, generics and sum types. Maybe this is the exact
combination that's perfect for your use case.

I'm no Rust fanboy either, I just chose it because it's the newest one I could
think of. I'm sure I could make a similarly strong case for many other popular
languages.

~~~
mercer
While it's hyperbole, I think the more charitable interpretation is that a lot
of 'new stuff' is really just rediscovering 'old stuff', and this should be a
impetus to study the old stuff to find some pearls.

Obviously there's plenty of new stuff that is properly new, especially in a
field as young as CS. But there's also a ton of stuff that just keeps being
rediscovered. Looking back instead of stumbling upon the same idea eventually
can give a programmer a huge advantage.

------
pjmlp
Some things from my point of view.

The most important one is that team is more relevant than whatever company one
works for, and promises they might deliver.

Work friendships carry on whenever one goes, companies are all about profit,
even when they state otherwise, things do change when bad times arrive. Too
many times there.

Soft skills are quite relevant, it is not always about cool technologies and
what not. Specially useful when working on UI/UX or getting to know what is
actually happening at the company.

Always be curious to learn about new technologies and programming paradigms,
but when time comes to launch products that are supposed to be around for
years to come, stick with the vendor tooling of the target platforms.

New shiny thing might be a box of surprises when requirements start changing
all the time and it is time to go live.

Picking on the last one, use whatever technology is appropriate for the
problem, as what matters is delivering a working solution that solves a client
issue, not to expose source code on the Louvre.

------
InclinedPlane
Almost all software dev. advice is contextual. There's such a huge diversity
in the software development field and yet somehow people like to pretend that
diversity doesn't exist, and like to give blanket advice that is allegedly
universally applicable. You see this especially in the advice that is most
relevant to small to mid sized silicon valley startups, somehow people working
in that world think it is _the_ world (of software dev) and can't imagine that
any other worlds exist. Software dev. spans more orders of magnitude of
difficulty, complexity, scale, etc. The advice that applies to building the
operating software for a nuclear reactor, an airplane, a financial system that
has to handle thousands of each individually critical transactions a second
around the globe, that advice is going to often not be applicable to someone
developing a mobile ad-based flashlight or fart app (and vice versa).

~~~
abraae
And the correct answer to every software dev. question starts with:

"It depends"

~~~
BatFastard
just like every martial artist

------
taneq
The hardest part of programming is figuring out exactly what you're trying to
achieve.

The (well, _a_ ) key to good program structure is reducing coupling between
components.

Comments should say what the code is intended to do, not how it does it.

------
dabei
> Good programmers write good code. Great programmers write no code. Zen
> programmers delete code.

Good luck to the great and zen programmers in creating anything or finding a
job.

It might make more sense to say we have good moments where we write good code,
great moments where we unlock key insights without writing code, and zen
moments where we make things better by just deleting code. Hopefully as we
practice over the years, the great and zen moments happen more often. But most
of the time we have to be content with merely the good.

~~~
dilyevsky
Thank you! This weird meme that programming is hard so lets just half ass
things with some saas products glued together with some bird shit and bash
(“bash is not code amirite?”) needs to die already.

------
hodgesrm
Production errors in business critical systems can be the most stressful event
in your life when you write successful products. You'll simultaneously have to
calm down a highly agitated customer as well as your own colleagues while
dealing with your own guilt about screwing up, possibly at a spiritually low
time like 2am.

Whenever I write software I try to picture those future conversations and what
we need to do to avoid them. Having a few mildly unpleasant conversations
about resources, quality, or time needed early on saves on far more unpleasant
ones later. It's hard to do this with conviction unless you have actually been
there.

~~~
mercer
The converse of this is analysis paralysis. More than once I've agonized over
what could go wrong in production, and trying to prevent these scenarios, only
to realize in hindsight that even the entire system going down for a day
would've not been noticed by or problematic for the particular client.

------
blihp
Overall a good post... except for that first line 'Everything in software
development has already been invented' Really... everything? I don't buy that
but do agree with the sentiment expressed in the rest of the paragraph that
people keep rediscovering/reinventing things. Computing is a field with very
little long term memory.

~~~
tobiasSoftware
That and "We don’t need any more computer languages." I admit I'm biased
though as I'm writing a new computer language. But I believe I have found
several interesting innovations.

I would agree with both of these as rules of thumb though, chances are a new
programming language is a dumb idea and that your idea has already been done
in some library. But new innovations still do exist, they are just rare.

------
raverbashing
\- good solutions are abandoned by no reason other than lack of
momentum/popularity

\- there's a sweet spot between "new, cool but unproven" and "boring but
works" and it is different each time

\- find the right level of abstraction to work with. Too high and you'll lose
flexibly, too low and you're doing work you shouldn't.

\- cut the crap and don't waste time with what you don't need. Focus on the
product and on shipping the product. Your customers don't care about the
latest js lib unless your product is _significantly_ better than the
competition for using it.

~~~
TeMPOraL
> _find the right level of abstraction to work with. Too high and you 'll lose
> flexibly, too low and you're doing work you shouldn't._

That's a very good point that took me a long time to fully comprehend. The
concept of code abstraction is usually introduced with a promise of it
_increasing_ flexibility. But the truth is, abstractions increase flexibility
along one dimension, by severely constraining you in many others[0]. As long
as you only need to move around along the abstraction-favoured dimension,
things are fine, but if you find yourself needing flexibility elsewhere, it
turns out that rewriting dumber/less abstract code is _much_ easier and faster
than digging yourself out of a wrong abstraction.

\--

[0] - I sometimes feel there is a "law of conservation" kind of thing hiding
in there. That abstractions are merely moving complexity around, not
destroying it. Someone must have explored this idea before; anyone here knows
of such attempts?

~~~
s_m_t
Its just compression and information theory.

~~~
gugagore
That's a bit too reductionist, right? Or perhaps you could elaborate? As it
stands it sounds like "it's all just atoms" when someone asks "how does a
neuron fire? Someone must have studied that."

~~~
s_m_t
In information theory you can't come up with an encoding that will give you
more than a bit of information per bit of source on average. Of course, the
information we usually care about is usually highly structured, so we use
encodings that compress the highly structured parts we care about and dont
care if in that same encoding it would take many bits more to encode some
other part. Ever used some sort of library or framework where in the beginning
you get a ton of progress made in a small amount of time but when it comes to
getting it to do _exactly_ what you want you find your code balooning around
the corner cases? Same idea in my opinion.

------
watwut
Testers are great.

Crunch is a choice, failure of management and irrational. Organization and
process matters.

Staying long is not being hero. It is being a sucker. It makes little
difference in result. It amounts to vitrue signal.

Never cease learning. (Youngsters know that too, but it is important.)

~~~
your-nanny
staying long?

~~~
watwut
Long into the evening multople days while you are increasingly sleep deprived.

As staying long in one company - imo depends on company.

------
tchaffee
The most important thing I have used constantly in my decades of programming:
learn the skill of negotiating and specifically get good at saying "no". You
will be a far happier programmer and the people you work with will be happier.

------
snorkel
All programming languages are fads, except for C.

~~~
astura
At this point you can add Java to non-fad list, right? It's been around for 23
years and it's the most popular language used in industry. I'm currently
supporting Java code that's old enough to vote.

~~~
marcosdumay
I'm just glad we are at a point when the GP didn't need to say "Fortran".
That's evolution.

~~~
ryl00
I work with a lot of numerical code. Fortran's not going away any time soon.

~~~
tormeh
All programming concepts are fads, except for legacy.

~~~
slededit
Stay in one place long enough to see a few cycles and you’ll get nice and
jaded. Today’s old and shitty was yesterday’s “proper way”. It can change in
only a year or two. “Global” refractors always end unfinished and the code
worse for the wear.

Local refractors in code your touching anyways tend to work great though.
Since your changing it you’ve built enough understanding to refactor it
correctly.

------
the_arun
Few from my own journey line :)

1\. Your code is temporary, but your attitude towards programming is not.

2\. There is no such thing as perfect solution - a solution can be implemented
by multiple ways, so no need to criticize one solution over another.

3\. One size doesn't fit all

4\. Learn to appreciate the creativity of youngsters and nurture them.

5\. Brilliant programmers drive a product & culture, not a specific program.

As someone mentioned earlier, these tips just don't apply for programmers -
but any profession.

------
randomsearch
Make it simple, make it work, then add complexity.

~~~
taneq
Make it work. Make it right. Only then, make it fast.

~~~
tomohawk
Only works if making it fast is not precluded by the design from the get-go.
If performance and scale are a consideration, then they must be considered at
the start.

~~~
taneq
In that case it's not working right unless it's working fast. ;) But yeah,
this saying refers more to micro-optimisations than proper algorithm
selection.

------
zoomablemind
Burn-out is real.

Maybe it's not necessarily tied to 20yrs in programming, but to stay long in
this field, one needs to develop an ability to sustain or recognize burn-out.
Personal and on team level.

Especially while young and seemingly having limitless energy, attention, and
desire to succeed.

------
patrickdavey
>Wait for the point-one release of development tools before installing them.
Let other people be guinea pigs.

Hell yes. I was bitten by this 2 months ago. Updated the server to Ubuntu
18.04.0 and had a week of hard disk crashes (randomly). I just could not work
out what the issue was. Midway through the week 18.04.1 was released with two
filesystem bugs fixed. Made all the crashes disappear. Never making that
mistake again!

------
thewoolleyman
Most things that are Good in the world of computing can be boiled down to:

Loose Coupling and High Cohesion

At all levels, macro and micro. It applies at the function level and to global
distributed systems.

For example, each of the letters in the "SOLID" Object Oriented patterns boils
down to one or both of these principles.

Whenever I'm looking for ways to improve something, I start by thinking of it
in these terms.

------
jonesdow
>> What are some things that only someone who has been programming 20 years
knows?

Those in positions of power (the managers) have never been those who
programmed 20 years. Either never programmed at all, or were early successes
either trough luck or more often than not, connections.

As a result they don't know and don't care about the things known by those who
programmed 20 years, it's not their problem.

~~~
neathack
That's simply not true! I'm 43, and there hasn't been a day without coding
since I got my first computer 32 years ago. I'm also managing teams for the
last 20 odd years; small teams, large teams, in startups and large
corporations. And I know many others like me.

~~~
tluyben2
The same here; 43, daily coding since I got my first computer beginning of the
80s and managed companies and teams for well over 20 years.

------
jerrysievert
move slow and make things.

------
gaius
My take: all the progress in the last 30 years has been in hardware. Software
is going in circles.

------
amriksohata
That younger people often are wide eyed and enthusiastic but lack experience
in production systems

------
michaelchisari
Nothing matters more than budget, time and labor constraints.

Every technical decision is trivial in comparison.

~~~
dplgk
You can waste a substantial amount of budget and time by making the wrong
"trivial" technical decision.

------
8bitsrule
1 Resist that gnawing urge to add just _one little new feature_. Instead, go
rewrite that secret little mess you know is there but are afraid to look at
again.

2 If your _little new feature_ causes you to consider modifying the database,
GOTO 1.

------
kennu
Don’t solve imaginary future problems. Solve actual problems at hand. Most of
the unnecessary complexity in programming can be avoided by keeping this in
mind.

------
floatingatoll
“Why does the site think it’s the year 19118?”

------
throwaway5250
Complexity kills.

That's not so hard to see. The hard part is figuring out what simplicity is.

------
anonlastname
Terry A. Davis's streams were full of good salty old programmer quotes...

------
teddyh
> _If you know you will do a fixed sequence of steps more than ten times,
> automate it._

More detailed answer: [https://xkcd.com/1205/](https://xkcd.com/1205/)

~~~
nemo1618
This chart doesn't take into account the possibility of errors, though (unless
you equate an error to wasted time, which is dubious). Even if you only need
to run a command once a year, and it only involves a few short steps, it's
worthwhile to automate the task if fat-fingering one of the commands could
have disastrous consequences.

~~~
teddyh
> _This chart doesn 't take into account the possibility of errors, though_

This one does: [https://xkcd.com/1319/](https://xkcd.com/1319/)

~~~
delecti
Amusingly that actually does the opposite, and takes into account the
possibility of errors in your automation, but not in doing it manually.

------
rurcliped
New hires have trouble understanding that, occasionally, we have a valid
business reason that a piece of code simply must EXIST. Yes, almost always, we
want the code to exist and also be correct, or maintainable, or have other
desirable properties. But not always. Sometimes the customer, or our own upper
management, is completely fixated on the distinction between THINGS THAT EXIST
and THINGS THAT DON'T EXIST. The worst possible day is when I hear back from
the programmer about their perceived "progress" in which they have "evaluated
design alternatives" or "better understood the problem."

