As a community of self improvers we are constantly seeking advice from wherever we can find it.
But not all advice is good advice, here’s my hit-list to miss:
Avoid broad sweeping declarations to avoid X over Y.
In case you hadn't realized, we are not at war. You are not some Capulet servant who has sworn fidelity. No one is going to call you to arms to fight PHP in the streets, it's simply not going to happen. So you don't need to start carving NodeJS into your arm and denouncing anyone you know using PHP.
You also don't become good at something by only learning bits of it. You can shortcut your way to a single achievement but you can't shortcut your way to knowledge and understanding.
Now the internet is overflowing with these sort of articles, heck just search 'web components' here on Dev.to. My rule of thumb is: If people are discussing it on the internet than it's still valid to learn. The only thing NOT worth learning are they things no one talks about any more, remember assembler language?
A good dev understands good practice. To understand good practice you need to know what makes up bad practice. You need that holistic view, I'd even go as far as to recommend you learn the "bad" language first to help put into context why the "good" language is superior.
Most of the time when you are on a mission to learn something it's not just for shits and giggles. If you are learning in hopes of landing a job in that space you can't afford to not learn certain things. Just because BLAH language is best practice now over GLEH, doesn't mean that plenty of hiring companies aren't using GLEH. Companies and their technology stacks are often old and tend to be wedded to decisions they made five years ago. Knowing the language of 2019 isn't going to help you get a job supporting a system from 2015.
I see this commonly in the data space. People wanting to get into data blindly googling and landing on article after article saying 'don't learn SQL, instead learn Python, NoSQL, or R' and yet in reality this advice couldn't be more misleading. For one, most companies just have a simple sql-based data warehouse and knowing anything but SQL wouldn't be supported. Not to mention python just passes SQL commands, so you still need to know SQL to know how to extract data in Python.
Take more advice from the faceless and nameless.
The internet is a game, look no further than LinkedIn to understand what I mean. You are either trying to build your brand or you don't give a fuck.
Brand builders will do everything and anything to legitimize themselves in your eyes. The thing is, its super duper easy because their is no accountability. I can write that I know JavaScript on my Dev.to, CV, and LinkedIn. There is no test to prove that I know it. Brand Builders know how to play the game. Large follower counts, high quality posting, constant activity, brand deals, it all looks good but it means nothing. It's all over stated by at least 30% and it's a race... to the bottom.
Liquid error: internal
I once came across one of those 'ten people you should follow in data.' All but two of them sent me an automated twitter message looking forward to interacting with me. After two weeks of my timeline being inundated with massive amounts of retweets and cross promotion that contained at least 6 hashtags and four named tags I un-followed them all.
The best advice comes from the people who don't give a fuck about their online brand. Faceless and nameless they just answer the question or give their two cent's worth and then move on.
This is often why the best advice comes from the comments, but not Youtube - never read Youtube comments. Comments on Dev.to / Twitter / Stack are moderated by their environment. Someone says something dumb and you can instantly see the discourse around it. Someone says some good and likewise the up-votes and comments tell you it's a good thing. When a Brand Builder posts utter shite, their is no moderation, as the comments saying 'uh this is wrong' are buried under all the bots and brand builders hoping for a lick of that sweet sweet anus.
A great person may not be able to give great advice
Teaching Is hard. The human predisposition to forget things often leads people to forget the struggles and road blocks they faced on their learning journey.
How many times have you asked for help and the first thing out of their mouth is ‘Oh it’s easy” and then you proceed to stare at them blankly for ten minutes because you don’t get it and your afraid to own up to not knowing something ‘easy’?
When people say ‘oh its easy’ what they mean is “to me, with my experience and knowledge...this as easy.” It’s a dick move but it’s not deliberately malicious. People suck at remembering how hard things where.
People also may not know how they got where they are now. Some people achieve greatness through luck and timing, some get their because they themselves are naturally the top 10%. In neither of those scenarios, will they be able to give you tangible advice.
You are also a different person, with different learning styles and personality. Taking advice from just one person may not be what’s right for you. In all scenarios crowd source your advice.
Ronsoak 🏳️🌈🇳🇿@ronsoakWho am I? 🌈. Senior Data Analyst for Xero. Blogger dev.to/ronsoak - medium.com/@ronsoak . I draw sometimes instagram.com/ronsoak_art/ and I write Sci-Fi that no-one has seen yet. My tweets do not represent my company. 💬 Be Good and Be Good At it !00:30 AM - 02 Jun 2019
Top comments (4)
Great article. I especially like the second point. It's where most of my advice has come from. Honestly, out of the 1000s of people whose answers I've read on Stackoverflow, I don't think I've ever once looked at a name.
As regards great people - there are two kinds - those who are great at what they do and can share how they do it, and those who can't. Sometimes with the first kind you can just figure it out by observation. Anyone who says "Oh it's easy" has forgotten how to hold context in their mind.
I fully agree about the part that teaching is hard, this year I had to mentor two girls for Technovation with Thunkable (which I've concluded that is way to green for what these girls wanted!) and there were a lot of things that left me thinking about how to explain it to them. I picked up a book called Girls Who Code one day at a museum, bought it and read it to understand how they were explaining things to young girls and that helped a lot (it's a good book too, I recommend it!).
And I had to mentor these girls mostly because their main mentor, a developer as well, didn't know how to teach programming to them! I was just a substitute mentor lol. Either way, it made me realize that I truly need to find more ways to up my teaching game since who knows if one day I'll get to mentor again :3
Also,"This is often why the best advice comes from the comments, but not Youtube - never read Youtube comments." made my day! :D
What technology you choose should be based on your intended outcomes. Your reasoning doesn't even have to be performance or technical based to be valid. For example, I'm learning Ruby/Rails now to be able to look over Dev's site repo and a coworker's project. Having a meaningful reason to use/learn a technology is ultimately more important than what the 'best' choice is.
This was such a great read, resonated with me on so many levels and gave me a lot to think about too - kudos!