Things I Learnt The Hard Way (in 30 Years of Software Development)
(Now in blog format!)
36.1. "The right tool" is more obvious than you think
Maybe you're in a project that needs to process some text. Maybe you're tempted to say "Let's use Perl" 'cause you know that Perl is very strong in processing text.
What you're missing: You're working on a C shop. Everybody knows C, not Perl.
Sure, if it is a small, "on the corner" kind of project, it's fine to be in Perl; if it is important for the company, it's better that if it is a C project.
PS: Your hero project may fail due this.
36. "Right tool for the job" is just to push an agenda
"Right tool for the job" should be an expression that meant that there is a right and a wrong tool to do something -- e.g., using a certain language/framework instead of the current language/framework.
But every time I heard someone mention it, they were trying to push their favourite language/framework instead of, say, the right language/framework.
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.
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.
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.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.
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.
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.
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.
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.
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.)
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.
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.)
functional.cafe is an instance for people interested in functional programming and languages.