Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?

TLDR: you have to find the underlying context of the advice; when is it good for what. when you have your own reasons to adopt, then you'll also know when to let go (not wait for someone else to disband the party)

Don't just blindly follow the advice of "experts", take it with a grain of salt.

is prudent advice regarding following advice... but not enough; it's just varying the level of trust. Instead of only adjusting trust % level on what people tell you, try it out. for real or thought experiment on your past projects.

e.g. coming from years of writing Ruby to writing Go, i was accustomed to plucking the values out from os.Getenv wherever I needed it; there's a certain "plug and play" to doing things this way. chuyeow's PR reviews kept pointing out that cli flags are preferred and that it's ok to pass them in through function arguments to where I needed to use them. Though I didn't agree with the practice, nor could I see why it would be good in Go context, I went with it to see how things will pan out. Regarding this and other advice along the way, whenever the benefits borne out or downsides felt, I do make it an effort to revisit the contention and get back to him "yes i now think this is good because..." or "this problem we face now is because... wdyt?". I recall he wondered why I'm "keeping scores" but it's not personal win/lose score keeping; I'd just wanted to share my learnings so i can remember the reasons myself.

I forgot whether i pointed you to https://www.joelonsoftware.com/2002/05/06/five-worlds/ before. the content is rather dated, but the underlying point is very relevant: advice usually has an unspoken context, and if your situation is similar it could work but in another context the advice could be irrelevant or even wrong.

When i was in the J2EE world, i was trying to catch up to learning "best practices" (and there's a LOT of that in Java-land). only when i was exposed to "a different OOP" from Ruby, then it was shown to me that "could some of those best practices be just workarounds for the flaws of Java?" i.e. "when writing java code you should..." instead of "when writing software you should....". that might have been my first experience of what joelonsoftware was talking about.

For example, a lot of people formed the opinion that "hey, you should check out Robert C. Martin's book, Clean Code" and then there would be someone out there stating that his book isn't good.

I have not read the book. I did come across SOLID principles occasionally, but they didn't stick. Whenever I do google the principles, I'll find myself asking "is this a good thing all the time?".

also, they could be a bit too OOP specific. and if like me you start losing faith in OOP, then these best practices start to look like they are built on top of sand...

NEVERTHELESS, you could sell me on some stuff from the book, and i'll let you know my take and any context that I spot?

I see that you were able to have opinions on whether GraphQL or Elm was worth to invest time it.

i park "GraphQL" and "TDD" under the same category of "if based solely on what I read about them, i'm not particularly interested". so yea, I was also in your shoes of "wa so many people i respect seem to be talking about [thing] being so good", i think i might have somewhat adopted the opinion that they are good also -- except that wasn't enough for me to start practicing tdd or using graphql.

it wasn't until i chanced upon https://speakerdeck.com/choonkeat/tdd-for-people-who-dont-need-it?slide=31 that it clicked -- relevant to me and my experience -- and now i have my own opinions of it. this is better since based on your own reasons, you are better able to see "when is this good, when is this meh".

i forgot what got me off my lazy ass to try graphql on a side project, but whatever clicked -- relevant to me and my experience -- wasn't whatever people were praising about. it's not even what graphql was invented for: to reduce http calls and over fetching (good good... but whatevs). what i liked was having the very human-friendly schema (not verbose xml) that i can easily use compilers to ensure i didn't make a mistake (typo?) implementing (stale?) apis on both front and backends.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment