19.1. Write steps as comments
If you have no idea how to start, describe the flow of the application in high level, pure English/your language first. Then fill the spaces between comments with the code.
Better yet: think of every comment as a function, then write the function that does exactly that.
18. Shortcuts are nice, but only in the short run
A lot of languages/libraries/frameworks add a way to make things shorter, reducing the number of things you need to type.
But, later, that will bite you and you'll have to remove the shortcut and do the long things.
So learn what the shortcut does before using it.
17 1/2. The Magical Number Seven, Plus or Minus Two
"The magical number" is a psychology article about the number of things one can keep in their mind at the same time.
If you have a function, that calls a function, that calls a function, that calls a function, that calls a function, that calls function, you may be sure it will be a hell to read later.
Think more about: I'll get the result of this function, then pass it to the second function, get its result, pass to the third an so on.
17. Cognitive Dissonance is the readability killer
"Cognitive dissonance" is a fancy way of saying "I need to remember two (or more) different things at the same time to understand this."
For example, adding booleans to count the number of True values is a mild cognitive dissonance 'cause one can think "What do you mean True plus True equals 2?"
15 1/2. The best secure way to deal with user data is not to capture it
You can be sure that, at some point, the data will leak, either by some security flaw or human interference.
If you don't capture any user data -- or store it in anonymized way -- you won't have any problems.
15. Think of the users
Think how the data you're collecting from your users will be used -- this is more prevalent on these days, where "privacy" is a premium.
If you capture any used data, remember to protect it against unauthorized use.
(Holy cow, I'm _really_ enjoying this. And I think I have more than 50 minutes of presentation going on here.)
14 1/2. Design patterns are used to describe solutions, not to find them
(Again, personal opinion) Most of the time I saw design patterns being applied, they were applied as a way to find a solution, so you end up twisting a solution -- and, sometimes, the problem it self -- to fit the pattern.
First, solve your problem; find a good solution; then you can check the patterns to know how you name that solution.
14. Data flows beat patterns
(This is personal opinion) When you understand how the data must flow in your code, you'll end up with better code than if you applied a bunch of design patterns.
13. Companies look for specialists but keep generalists longer
If you know a lot about one single language, it may make it easier to get a job, but in the long run, language usage dies and you'll need to find something else. Knowing a bit about a lot of other languages helps in the long run, not to mention that may help you think of better solutions.
"A language that doesn't affect the way you think about programming, is not worth knowing." -- Alan Perlis
12. Understand and stay way of cargo cult
"Cargo cult" is the idea that, if someone else did, so can we. Most of the time, cargo cult is simply an "easy way out" of a problem: Why would we think about how to properly store our users if X did that?
"If BigCompany stores data like this, so can we".
"If BigCompany is behind this, this is good."
11. You're responsible for the use of your code
This is hard. Very very hard. It's the difference between "freedom" and "responsibility".
There is nothing wrong in writing, for example, a software to capture people's faces and detect their ethnicity, but you have to think about what that will be used on.
10. Learn to say no
Sometimes, you'll have to say no: No, I can't do it; no, it can't be made in this time; no, I don't feel capable of doing this; no, I don't feel comfortable writing this.
(Addendum: Most of the time, people against CoCs are the ones that want to break it in the first place.)
9. Code of conduct protect _you_, not _them_
When you're beginning with any language/library/framework, check their CoC; they will protect _you_ from being harassed for not immediately getting what is going on instead of blocking you from telling them what you think.
8. A language is much more than a language
A programming language is that thing that you write and make things "go". But it has much more beyond special words: It has a build system, it has a dependency control system, it has a way of making tools/libraries/frameworks interact, it has a community, it has a way of dealing with people.
Don't pick languages just 'cause they easier to use.
7. When it is time to stop, it is time to stop
Learn when you can't code anymore. Learn when you can't process things anymore. Don't push beyond it, it will just make things worse in the future.
European-based husband, father, programmer and coffee-nerd.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!