What I've Learned So Far as a Programmer
copygrammer.com
copygrammer.com
> THE BIGGEST LESSON I LEARNED TODAY
> Don’t forget to turn on your caching plugin and CDN. I submitted this blog post to Hacker News and this website can’t be accessed.
> And I HOPE it won’t crash right after I wrote this. I hope! Haha.
Haa... nice.
Complicated things break. Simple things also break, but a lot less often.
Complex is OK, complicated is wrong.
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.
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.
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.
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.
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!
Think what you will of Zed Shaw, but he actually has a pretty good piece on how indirection and abstraction get mixed up:
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.
This is also what I learnt as a programmer.
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.
Most likely causes: The website has a programming error."
Thanks IE, you really know how to make me laugh.
- 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.
You make a static website. HTML, CSS, maybe some JavaScript.
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.