Out of the blue, I thought another presentation I can make for people starting UNI:

"Things I Learnt the Hard Way in 30 Years of Software Development"

1. Monitoring.

After writing a lot of metrics for a project in a previous life, not adding any support for Prometheus makes me feel nervous of deploying my code in production.

Show thread

2. Tests are good, integration tests are gooder.

I'm currently writing tests for a single module only (e.g., only tests for the "view" layer). It gives me some idea of what is right and what is wrong, but in no way I feel those tests say my code is doing what it should do.

Show thread

3. Tests make better APIs

We build stuff in layers. Tests allow use to see how the API of a layer behaves and we can make better APIs by just checking our struggles writing tests.

Show thread

4. Future thinking is future trashing

Solve the problem at hand. Don't think "We can do this in a more general way and, in the future, it will be easier to add more". Adding more will never come and you'll have to deal with a pile of trash.

Solve one problem, then solve the next. A patter of problem will emerge -- or not.

Show thread

5. Code reviews are for architecture, not style

Do not complain about a misplaced semi-colon or a "missing space before parenthesis" in a code review. That's not the forum for this -- unless you found an architectural problem, then you can point both.

Show thread

5 1/2. Code formatting tools are ok, but are no silver bullet

Computers are very flexible into reading code, but humans are not.

(I may even say that, if the tool is moving a lot of your code, there may be a real architecture problem with your code.)

Show thread

6. Documentation is a love letter to your future self

Yeah, it's tiring to write the damn documentation on every freaking function, but your future self will thank you for letting the code explained on what it's doing.

Show thread

6 1/3 The documentation of a function is its contract

The documentation should reflect the code; if it doesn't, you have a problem with your code, not your documentation.

Show thread

6 2/3. Documentation with an "and" means you're doing it wrong

A function should do one thing and one thing only. If you have to add an "and" to its description, it probably means the function is doing two things and you should break it apart.

Show thread

6 3/3. Good languages come with integrated documentation

If the language comes with its own way of documenting functions/classes/modules/whatever and it comes with even the simplest doc generator, you can be sure all the language things and libraries will have a good documentation.

But languages with no integrated documentation will most of the time have bad documentation.

Show thread

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.

Show thread

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.

Show thread

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.

Show thread

(Addendum: Most of the time, people against CoCs are the ones that want to break it in the first place.)

Show thread

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.

Show thread

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.

Show thread

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."

Show thread

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

Show thread

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.

Show thread

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.

Show thread

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.

Show thread

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.

Show thread

16. Types say what you data means

Memory is just a sequence of bytes; bytes are just numbers from 0 to 255; what those numbers mean is described on the language type system.

For example, in C, a `char` type of value 65 is most probably the letter "A", which an `int` of value is 65 is the number 65.

Remember this when dealing with your data.

Show thread

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?"

Show thread

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.

Show thread

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.

Show thread

19. Spec first, then code

If you don't what you're trying to solve, you don't know what to code.

Write something specifying how the application works before writing any code.

"Without requirements or design, programming is the art of adding bugs to an empty text file." -- Louis Srygley

Show thread

(Addendum to "Spec first": The times I stood longer looking at my own code wondering what to do next were when we didn't have the next step defined. It is a good sign that it's time to stop and discuss it with your coworkers -- or maybe rethink the solution.)

Sign in to participate in the conversation
Functional Café

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!