
What I've Learned So Far as a Programmer - peace01
http://copygrammer.com/learned-far-programmer/
======
devwastaken
"Error establishing a database connection" The greatest knowledge by
experience for all for us in devops.

~~~
blojayble
Has anyone measured how much traffic can being on the front page of HN
generate?

~~~
jsjohnst
It's not as bad as you'd think in total volume, it's just you get a lot of
bursty concurrent traffic. Something as simple as a hundred requests in
roughly the same second crash many blogs sadly.

------
Sir_Cmpwn
The most important lesson I've learned is _simplify_. Simplify everything.
Simplify your problem. Simpilfy your approach. Simplify your architecture.
Simpilfy your data model. Simplify your build process. Simplify your release
process.

Complicated things break. Simple things also break, but a lot less often.

~~~
olegkikin
The problem is "simplify" means different things to different people. For some
it's write everything in vanilla JS. For others it's install libraries for
everything, write the least code.

------
mcguire
" _It doesnâ€™t matter if you donâ€™t know algorithmsâ€¦ But it doesnâ€™t hurt
to learn about it (because it might help you in the future). This is
important. Usually you donâ€™t use algorithm in programming a system but if
itâ€™s something that will scale fast, your understanding of algorithm might
be useful._ "

Sigh. I'm really tired of this misunderstanding.

Literally everything you type in to an editor is an algorithm. "Learning
algorithms" isn't about memorizing known facts, it's about learning how to
think about programming.

~~~
Xorlev
Those that don't study algorithms are doomed to reinvent them, often poorly.

Totally agreed. A knowledge of "conventional" algorithms influences how you
write code. Sometimes it manifests as knowing which algorithm to choose,
sometimes it manifests as intuition into the performance (or lack thereof) of
something you're writing.

It's not required by any means, but don't turn down cheap knowledge on how to
gain an edge.

~~~
khedoros1
Some basic algorithmic knowledge is definitely essential. I remember the first
time that I found a need for sorting. I designed my own algorithm, and I
learned years later that I'd basically recreated bubble sort. It worked fine
in my little QBasic program, but would've made anything serious fall flat on
its face.

------
sk5t
Without judging the author, I think it's fair to say there's nothing to be
learned from this article by 90% of regular HN readers.

~~~
knieveltech
I think that statement might have been true years ago.

------
k__
Some stuff I learned:

Don't write/use abstractions you won't understand later. Often you start with
2-3 copies, try to merge them and end up using it at a place were it doesn't
fit 100% anymore.

Keep nesting low. Often it's faster to scroll over one big okay-ish structured
function than to find all the clean tiny things around the the project. Same
goes with Objects/Classes/Components etc.

Stop using abbreviations and try to write code more readable and not as short
as possible. IDEs help with autocompletion and code gets read more than
written anyway.

~~~
ethbro
_> Keep nesting low._

This so much. One of the bigger differences between academic and professional
coding is software system longevity.

Premature refactoring is incredibly harmful to readability.

1\. You have no idea what the future will require. You will always know more
about the requirements in the future.

2\. You have no idea how the current use and system will need to evolve. You
will always learn more about this in the future.

3\. You have no idea how long the current system will be used. Could be 20
years; could be a week (if it's an executive's pet project).

4\. Time to MVP > perfect code in almost all instances.

Writing code with clean, documented _potential_ refactoring points, but
stopping short of actually pulling all those things apart has served me far
better than the alternative.

If you have one function that may not be applicable to a future use case, and
you refactor it into two, now you have two functions that may not be
applicable to a future use case.

Develop a feel for what's "reasonable" in an initial write, and don't code
yourself into an inflexible corner, but defer actual refactoring until it's
necessary. Because then you'll have the benefit of knowing _far_ more about
the new needs and how the system is used.

~~~
nhteou79snt
> Premature refactoring is incredibly harmful to readability.

Is that a thing? If it is, I've never run into it. I always run into the
opposite - never refactoring and everything turning into a god object. It
never occurred to me that premature factoring would be bad because I can't
recall ever running into it!

~~~
cstrahan
I've seen plenty of this. The most common offenders are junior to mid-level
developers who, in the pursuit of attaining the trappings of sophistication,
cargo cult various patterns without understanding the original rationale
behind those patterns, nor when they should be applied. What they fail to
realize is that needless indirection is not the same as useful abstraction.

Think what you will of Zed Shaw, but he actually has a pretty good piece on
how indirection and abstraction get mixed up:

[https://zedshaw.com/archive/indirection-is-not-
abstraction/](https://zedshaw.com/archive/indirection-is-not-abstraction/)

~~~
k__
Haha, interesting.

I always assumed abstraction was only a special case of in direction.
Indirection on a meta level.

Like loops are abstractions for jumps, but this means that you "indirectly"
use jumps when using loops.

------
theossuary
While Hacker News hugs the site to death:
[http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://copygrammer.com/learned-
far-programmer/)

~~~
jerrylives
I think there's more wisdom to be found in the error page than the original
article

------
alexfi
"Error establishing a database connection"

This is also what I learnt as a programmer.

------
mattkenefick
This is one of the funniest headlines I've read considering the site seemingly
crashed. I'm hoping the punchline was actually "Error establishing a database
connection" but I doubt it.

------
velebak
Always build scalable web presences.

~~~
majewsky
I hope to once make the frontpage on HN. Not for the fame or anything, just to
check how scalable my blog really is. :)

~~~
sunnyam
Do you know of any way of testing your website to see how many concurrent
users it can handle?

~~~
shakna
Siege [0], is my go-to. Easy to add to CI, because its on most platforms, and
has decent output configs. You can vary headers and pages to hit, and how long
connections get held open, or just reject them. And of course, it has great
concurrency.

It can bring down most servers that aren't configured to prevent DOS attacks,
like naive nginx or Apache configs. Usually somewhere between 5-10mins.

[0] [https://www.joedog.org/siege-home/](https://www.joedog.org/siege-home/)

------
fareesh
Yet to be learned - caching?

~~~
philbarr
"Identify exactly what you're weak at" and "learn quickly" are two of his
notes so...

------
Adamantcheese
"HTTP 500 Internal Server Error

Most likely causes: The website has a programming error."

Thanks IE, you really know how to make me laugh.

~~~
mezuzi
Needs to dispatch a team of highly skilled monkeys.

------
faragon
My two cents:

\- Time don't make you [much] smarter in the "brute force" sense, however it
allows you doing less errors, avoiding unnecessary stuff, and in general
making you more productive. Also, it allows you to enable others to be more
productive, e.g. giving some hint to a coworker so he/she can simplify his
work.

\- Focus is all: understand the problem, do a good planning, and stick to the
plan.

\- For critical projects trust people you _really_ know (their capabilities,
potential, character, etc.). And DON'T trust people you don't know, in the
sense of: tracking, ensuring people know what they are doing and that they're
capable, etc.

\- The wrong people can ruin any project, no matter how smart you think you
are, so: do risk analysis, always.

------
s_dev
Mirror:
[http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://copygrammer.com/learned-
far-programmer/)

------
jayeola
curl --head [http://copygrammer.com/learned-far-
programmer/](http://copygrammer.com/learned-far-programmer/) HTTP/1.1 500
Internal Server Error Date: Tue, 01 Aug 2017 15:02:57 GMT

------
kutkloon7
What I Didn't Learn So Far as a Programmer: \- How to properly encode text

------
flavio81
Lesson learned: _Always make sure to establish a database connection._

------
fouc
"Learn to learn quickly" _cringe_

------
Kenji
Everyone is so smug here, wow. If you have a little web presence with 5 visits
per day, of which 3 are bots, you don't cache, you don't use AWS or any of the
big services, you just spin up a tiny Linux machine with a LAMP stack and
that's it.

~~~
yoz-y
Is there a good (preferably free) service to load test ones own website? I
imagine that something like this is quite hard to test for a beginner and I
admit I have never tried to do it on my site either.

~~~
siliconwrath
I've had a good experience using [https://loader.io/](https://loader.io/)

