23. Code style: Follow it

If your project have a defined code style, you must follow it. Sometimes it may not be clear ("this struct/class should be singular or plural"?), but do your best to follow it.

23.1. ... unless that code style is the Google Code style

(Totally personal opinion, feel free to disagree) Every freaking time Google comes with their own coding style, it's a garbage fire. The community came with a better style way before and Google seem to come with a style with high contrasting parts just to call it theirs.

23.2. There is only one coding style for C/C++: K&R

(Totally personal opinion again) Every other coding style is _WRONG_. :)

24. Pay attention on how people react to you

I have a "angry man resting face" kind of face.

Sometimes I'll ask things and people will move a bit back -- like I'm telling them their solution is wrong.

That's when I have to add "I'm not saying it's wrong, I'm just confused".

That _may_ help you to not get in trouble.

25. Explicit is better than implicit

You know what's one of the worst function names ever? `sleep()`.

Sleep for how long? It is seconds or milliseconds?

Be explicit with what you use; `sleepForSecs` and `sleepForMs` are not perfect, but are better than `sleep`.

(Think about this when you're writing your app command line interface or its config file.)

26. Hero Projects: You'll have to do it someday

An "hero project" is a project that you personally think will solve a large group of problems at once. It could be a different architecture, a new framework or even a new language.

That means you'll spent your free time to write something that is already being worked/exists just to prove a point.

Sometimes it proves you where wrong.

(But you got something from it, nonetheless.)

Follow

26.1. Don't confuse "hero project" with "hero syndrome"

I have seen this at least two times: Someone claims things don't work when they are around or that they don't need help.

This is "hero syndrome", the idea that that person is the only one capable of solving all the problems.

Don't be that person.

27. Always use a Version Control System

"This is my stupid application that I just want to learn something" is not even a good excuse to not use a version control system.

If you start using a VCS right from the start, it will be easier to roll back when you do something stupid.

27.1. One commit per change

I've seen people writing commit messages like "Fixes issues #1, #2 and #3". Unless all those issues are duplicates -- in which two of those should be already closed -- they should be 3 commits, not one.

Try to keep a change in a single commit (and by change I don't mean "one file change"; if a change requires changes in three files, you should commit those three files together. Think "if I revert this back, what must go away?")

27.2. "git add -p" is your friend when you overchange

(Git topic only) Git allows merging a file partially with "-p". This allows you to pick only the related changes and leave the other behind -- probably for a new commit.

(Damn, this is waaaaaay over 50 minutes for a presentation... :( )

28. Paper notes are actually helpful

I tried to become "paperless" many times. At some point, I did keep the papers away, but in the very end, it really do help to have a small notebook and a pen right next to you write that damn URL you need to send the data.

28.1. Trello is cool and all, but Postits are nicer

Nothing says "I'm really busy, but organized" like having a bunch of post its on your desk.

On top of that, they help you keep small notes or things you need to do.

(I have the slight feeling that, at this point, I may start pushing nonsense, like "The best music style to code is synthwave" or "Foxes are the best canines, fight me")

29. Blogging about your stupid solution is still better than being quiet

You may feel "I'm not start enough to talk about this" or "This must be so stupid I shouldn't talk about it".

Create a blog. Post about your stupid solutions. They are still smarter than someone else's solution.

Also, come back later and fight your own solutions with better ones.

Show your growth.

29.1. Post your stupid solution online

Don't keep a Github only for those "cool, almost perfect" projects. You're free to show that, at some point, you were a beginner.

You can always come back and improve your code.

(Or don't: I still have a public repo of my first Python project that looks like I just translated Java into Python, without the Pythonic part.)

30. Resist the temptation of "easy"

Sure that IDE will help you with a ton of autocomplete stuff and let you easily build your project, but do you understand what's going on?

Do you understand how your build system works? If you had to run it without the IDE, would you know how?

Can you remember your function names without autocomplete? Isn't there a way to break/rename things to make them easier to understand?

Be curious about what goes behind the curtains.

30.1. Start stupid

One way to get away from the IDE is to "start stupid": Just get the compiler and get an editor (ANY editor) with code highlight and do your thing: Code, build it, run it.

No, it's not easy. But when you jump into some IDE, you'll think of buttons of simply "Yeah, it runs that" (which is exactly what IDEs do, by the way.)

31. The config file is friend

Imagine you wrote a function that you have to pass a value for it to start processing (say, a twitter user account id). But then you have to do that with two values and you just call the function again with the other value.

It makes more sense to use a config file and just run the application twice with two different config files.

31.1. Command line options are weird, but helpful

If you move things to config files, you could also help your users by adding an option to select the config file and expose it.

There are libraries to handling command line options for every language today, which will help you into building a good command line and giving your users a standard interface for everything.

32. Not just function composition, but application composition

Unix came with the idea of "applications that do one thing and do it well".

Now, I said you could use one application with two config files, but what if you need the result of both applications?

That's when you can write an application that reads the results of the first one with both config files) and turn into a single result.

32.1. Even for app composition, start stupid

Application composition may lead to microservices -- which is good -- but microservices require some ideas about how applications "talk" between them over the wire (protocols and such).

You don't need to start with that. Both applications can write and read from files, which is way easier.

Worry about talking over the wire later, when you understand how networks work.

(Wondering if I'm starting to repeat myself. At some point, I realized what I was about to say about "starting stupid" I already said on "using logs"...)

33. Learn to recognize toxic people; stay away from them

You'll find people that, even if they don't small talk you, they will bad mouth everything else -- even some other people -- openly.

Stay away from those people.

You have no idea how that kind of attitude will drive you down.

33.1. Beware of micro-aggressions

"Micro-aggressions" are aggressive comments in small doses. Like someone that keeps calling you "_that_ person" or seemingly innocuous comments about your position in some policy.

Those are hard to fight, 'cause PR won't listen to you saying that they are attacking you.

Better just stay away and avoid contact as possible.

33.2. No, I don't think they are "fixable"

(Personal opinion) Someone could say "Hey, maybe if you spoke to that person, they would stop".

Personally, I don't think they would. This kind of stuff is going for so long to them that it feels natural and, most of the time, you're the wrong one (for not seeing that they are joking, for example, in true "Schrödinger's asshole" style.)

33.3. Toxic/migro-aggressors are only fixable if they are _YOU_

Unless it's you realizing you're acting like a toxic person or micro-attacking someone, and realize that you're actually doing more harm than good being that way, there is no way to fix those traits (again, personal opinion).

...mostly 'cause hearing from someone else may feel "_they_ are the ones against me!" to them.

34. Keep a record of "stupid errors that took me more than 1 hour to solve"

I tried but never managed to create a list of stupid errors I kept finding that took more than 1 hour to solve it, which were simply "forgot to add dependency" or "add annotation".

But you should try to keep a list of stupid errors that took you 1 hour to solve, 'cause later you can use it to not stay more than 1 hour to solve some stupid error.

35. Keep a list of "Things I Don't Know"

Richard Feymann, famous physicist, kept a notebook with the title "Things I Don't Know".

When you find something that seems cool and you'd like to know more, create a file/note/whatever with it in the title. Then make notes about what you find/figure out.

Show more

@juliobiason make sure that your important passwords are on different postits. Even if they are the same password.

@juliobiason I have tried this. It requires a lot of discipline. Got a lot of changes to make? Do one at a time, test, commit, move on.

@xj9 Damn, there is a typo in there (my fault):

"Someone claims things don't work when they AREN'T around"

Sign in to participate in the conversation
Functional Café

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