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.

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.

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.

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.

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.

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

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.

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.

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.

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.

Follow

(Addendum to the "integrated documentation": The same can be said to languages with integrated testing frameworks: They come with good tests.)

Sign in to participate in the conversation
Functional Café

functional.cafe is an instance for people interested in functional programming and languages.