Today’s challenge: spend 20 minutes reading the docs for something you’d like to know a little better.
Ideally, this should be something that’s already in your dev toolchain or used by your app. That’ll let you apply what you learn right away.
You might want to investigate the docs for one of these:
Your text editor. Vim users: type :h , search for “Editing Effectively” or “Tuning Vim”, read one of the docs in that section.
Your database. Any unused features you might leverage?.
A library or framework you use frequently. Have recent releases added anything useful?
Your shell. Can you optimize your workflows? Refactor a shell script? Improve your prompt?
Your programming language. Anything new or unexplored there?
If you discover something new, try to use it right away. If you can’t, maybe jot it down on a sheet of paper next to your keyboard so you remember to try it later. I do this often to teach myself new Vim commands. Once the new stuff is in my muscle memory, I throw the sheet away.
decided to read about some gems that can be included. For example, we need xls export for some tables that can be easily integrated and add value to the product.
Good. Finally I learnt how to use :bufdo in (n)vim to set :diffthis in both windows at once: :bufdo diffthis
This I wanted to know for quite some time.
Anyway, I have strange habit of reading documentation upfront any development. It might come from the time I was at university (1988), when there was real shortage of any documentation for anything (pascal, AutoCAD, whatever) and anyone having some had big advantage.
Later on in Holland I learned, that simply reading a manual makes me an expert - while designers facing strange MS DOS message called “an expert”, I used to pick the manual, find it in the index and by reading the information I became the expert myself.
My boss was once surprised - I got clipper handbook for three days and read it through. My boss thought, there is no way to store “arbitrary long data” (that time) in database field because he employed two programmers for two years to do some clipper coding. I told him about memo field type and could see in his eyes, how much extra costs his programmers generated simply by skipping the manual.
I finally read up on how to use multiple .gitconfig files so that different user names and email addresses can get used (as there are client specific ones we have to use sometimes) depending in which sub directory I’m working in.
This is so that I don’t have to update the config on a per-repository basis anymore after cloning.
For whom interested, per client I have a subdirectory like
~/projects/client-a/
~/projects/client-b/
In each of these can be multiple repositories.
With the addition of these settings into my global .gitconfig:
Today I’ve read about React Native Core components and native components from official documentation. It’s good to return sometimes intentionally to basics.
Today I’ve been reading a lot about zeitwerk for a rails upgrade that I’m performing in my job, we are upgrading from rails 5.2 to rails 6.0.3 bin/rails zeitwerk:check is your friend
I read through the manual of one of the gems we’re using. I also took the time to read through some of the release notes so that we can work our way through some upgrades.
I saw a colleague with a nifty plugin for terminal that sped up his folder switching, like teleporting.
I took the time to investigate and set it up nicely with oh-my-zsh
