Live data from Hacker News

What I've Learned So Far as a Programmer

copygrammer.com

51–60 of 62 posts

Re: What I've Learned So Far as a Programmer

#51
post #42
post #38

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

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

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

Re: What I've Learned So Far as a Programmer

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

Re: What I've Learned So Far as a Programmer

#53

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.

Managing complexity is our main responsibility.

Re: What I've Learned So Far as a Programmer

#54
post #36
post #35

" 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 algori…

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…

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.

Re: What I've Learned So Far as a Programmer

#55

"Error establishing a database connection" The greatest knowledge by experience for all for us in devops.

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

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.

Re: What I've Learned So Far as a Programmer

#56

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.

For me it was rather:

Complex is OK, complicated is wrong.

Re: What I've Learned So Far as a Programmer

#57

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.

Simple things are easier to fix when they do break.

Re: What I've Learned So Far as a Programmer

#58
post #42

Earlier quoted context omitted.

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

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

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/

Re: What I've Learned So Far as a Programmer

#59
post #30

Earlier quoted context omitted.

No, for a blog you don't. You make a static website. HTML, CSS, maybe some JavaScript.

I suppose the millions of wordpress blogs disagree with that statement. Some people like to format their content in a wysiwyg environment.

> I suppose the millions of wordpress blogs disagree with that statement

And crumble under the weight of real traffic.

> Some people like to format their content in a wysiwyg environment.

Those exist for HTML and are just fine for writing a blog, assuming markdown is too hard. We're talking about a programmer's blog here, however.

Re: What I've Learned So Far as a Programmer

#60

Earlier quoted context omitted.

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

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

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.

Post reply on HN