Book Review: Whatever you think, think the opposite
Review
Title: Whatever you think, think the opposite
Author: Paul Arden
Continuation of It's Not How Good You Are. It's How Good You Want To Be, this book is precisely more of the same: More ideas and tips to be different, to take risks, to start doing more what you like and what you think you should be doing and less what others (or society, or anybody) tells you to do. Some sentences are still very radical as in the first book, but this time at least have some explanation, like "don't go to university unless the subject of your learning is close to your heart."
The section about bad (and good) ideas is great, and it has some fun anecdotes. Again a short read (~130 pages), I felt this one is a more generic book about letting yourself go and become free to do what you really want to do, not only about unleashing creativity.
Notes
Just a few highlights I liked and wanted to keep:
Getting what you want means making the decisions you need to make to get what you want. Not the decisions those around you think you should make.
Everything we do we choose. [...] You are the person you chose to be.
The effort of coming to terms with things you do not understand makes them all the more valuable to you when you do grasp them.
Ideas have to be applied before they are recognized as good ideas. Even a bad idea executed is better than a good idea undone.
Solving the problem is the exciting part, not knowing the answer.
Simply change your life: The world is what you think of it. So think of it differently and your life will change.
Meetings are for those with not enough to do.
Book Review: It's Not How Good You Are. It's How Good You Want To Be
Review
Title: It's Not How Good You Are. It's How Good You Want To Be
Author: Paul Arden
Quick read (~120 pages) of provocative advices, mostly oriented to business people. Some of them are good, radical, different, challenging... but some to me feel either stupid or wrongly exposed: Getting fired because you have radical ideas might not be bad, but exalting you've been fired 5 times? Or the wrong wording "not getting good grades at school is ok" (instead of saying something like "school grades are not everything")? Some of the messages give the impression of being a survivorship bias: "this is what took me to success so you don't need anything else" and forget that it takes some time to be in a position where your school grades, or your "raw CV" doesn't matter as much as your past successes and mistakes.
That said, not a bad read, especially the creativity part is great and the general tone of "you can do it" is good as self-help and can open your mind.
Notes
I had this book forgotten and decided to read it before gifting it out. I don't even remember why I bought it, but definitely I didn't read it was more oriented to raw business than a generic creativity book.
I also found I have the second part ("Whatever you think, think the opposite") so another review will follow very soon.
Course Review: The Complete Splunk Beginner Course (Udemy)
I sometimes have to use Splunk at work and the truth is that, excepting some basic queries I had no clue how it works, so after a colleague mentioned he was going to go through Udemy's The Complete Splunk Beginner Course I also decided to give it a try.
The results are not bad: It covers all fundamentals and basic pillars like setting it up, querying and visualizing data, so you get to know how it gathers the data, why maybe some field is not being displayed correctly, and other informational bits that can come handy. My main focus was on searching, reporting and visualizing and, while some examples are gone through so quickly I had to watch them twice or pause the video to properly read the search query or terms used, it covers much of the options, from pipelining queries into commands, generating tables or charts, and specific examples of dealing with time series (one of the most common use cases).
The examples are not bad, although I'd have preferred to see a sample of ingesting and parsing an Nginx log than Windows security audit logs, which yes, include some relevant fields but also huge by default useless XML chunks, but on the other side the author provides a "homework dataset" of useful CSV sample data to ingest and play with.
It is a complete course, a bit short (3 hours), but clearly stated with the "beginner" word on the title and covering quite some ground, so a good intro to learn this monitoring tool.
Course Review: Perfect English Pronunciation: British English (Udemy)
I was searching for a course about improving pronunciation, when I found that the Perfect English Pronunciation: British English course has been added to the Udemy for Business catalog, so I took it and recently completed it.
It is exactly what I wanted: around four hours of examples, with minimal pairs or trios of similar sounding words that you should learn how to speak differently and correctly. For once, I'll show a screenshot of one pair so you can judge by yourself:
The pairs/trios are also grouped by two big categories, vowel sounds and consonant sounds. You get plenty of examples, precise instructions on how to vocalize the sounds (including mouth close-ups), and a few repetitions of each.
Totally recommended.
When to Feature Flag new code
A few days ago a colleague asked me the question of "when I consider that new code/logic should go behind a feature flag". I gave a short answer but truth is that using feature flags, or feature toggles is very common these days and taken for granted you know how to use them, but it is not always explained when to use them.
What follows is my humble opinion and experience, feel free to ignore it.
The single, most important fact that is usually forgotten and perverted is that feature flags are meant to be temporal, they should always be removed once fully rolled out (or replaced by a system switch, more on this later).
When to use Feature Flags
- New features. It is a fact that online complex systems will always have bugs, so having a flip switch to quickly "rollback" your new feature is a must. Also most non/trivial feature flag systems allow for gradual roll-outs, canary releases, role-based, entity-id based and other conditions.
- Experimental features. To me, the same scenario as previous point.
- Breaking changes. Many times should actually be something like a parallel change
- Code that changes storage data (format or manipulation). Data corruption can be so dangerous that I'd consider it almost like a breaking change scenario.
- Code that modifies input/output. Except if new I/O parameters/fields/things are optional.
- Code that raises new potentially unhandled exceptions. Extending your validation logic with new scenarios? Cover with a FF the new validation until all upper layers/callers have been revised and handle the new errors.
- Complex refactors or rewrites. If you have a really high code coverage might not need it, but we all know what usually happens with code coverage as codebases grow.
- Untested or poorly tested code. Your change might look tiny, but tiny changes in complex systems can wreak havoc in unfortunate situations.
- Code changes that might have potential performance hits. From adding a new data manipulation library to modifying an apparently innocuous ORM query, monitoring will alert you of performance degradations but if you can easily switch back to the old version while you ensure everything is fine, the better.
- Simple A/B testing. As in "one control group and one experiment group".
When NOT to use Feature Flags
- To disable system components. While the mechanics are the same, those uses are for System Switches, Ops Toggles or whatever you want to call them, but do not mix with feature flags, because it sends the wrong message of a feature flag being long term, when they shouldn't be.
- For permanent versioned features. Example: If you have versioned API endpoints, the Feature flag should disappear as soon as the new version is stable and you should have routing-based versioning (or user-based or any other solution except a feature flag).
- Complex A/B testing. There are better solutions than feature flag systems for A/B testing so use one instead.
Miscellaneous closing tips
Feature Flags are to be used by developers and product, while System Switches are for Systems, DevOps, SREs and the like.
When coding the feature flag check and forking logic, there are two accepted paths: The first one allows to just delete the lines in the future without any further changes:
if not feature_flags.enabled(feature_flags.constants.NEW_SHINY_FEATURE):
# old path (don't forget to return to avoid executing also new logic!)
# new logic
And the more commonly found, which just needs code re-indentation when removing the flag:
if feature_flags.enabled(feature_flags.constants.NEW_SHINY_FEATURE):
# new logic
else:
# old logic
If you want to know more about what are Feature Flags, this article is quite detailed.
Previous entries