[Video] How To Get Ahead of 99% Of Developers RIGHT NOW
One of the goodies I recently found on YouTube was this video of Melkey discussing another video by Web Dev Cody. As the title says, it’s about how to get ahead of 99% of developers and, personally, I don’t think that number is a hyperbole. Given the huge amount of people getting into coding, being smart about how to learn and how to gain experience might as well put you in the 1% that know what they’re doing.
So, let’s take a look at their takes, and I may throw in some of my own.
Read the Docs
“6 hours of debugging can save you 5 minutes of reading documentation”
Melkey said that many engineers (especially beginners) do not take the time to read the docs. That checks out when you see all the programming jokes about Googling, copying from StackOverflow or, most recently, ChatGPT-ing being what programmers do for a living. And it’s not that I don’t use those myself. It’s just that they are not alternatives to the official docs. They should be used when the docs aren’t helping very much.
Also, Cody has a great point here, which is that reading the docs will help you better understand the library/product you’re using and its limitations and edge cases, which in turn gives you foresight to write your code with those limitations and edge cases in mind. Otherwise, you’re more likely to write sub-optimal code and run into problems.
I may add here that people who don’t read the docs might think that tutorials do help them understand the library. Based on my experience, I think that’s not true. Most tutorials gloss over how things work and why they work that way. Instead, the mostly do nothing except write some code and ask you to follow along. This is an inherent problem with tutorials because, just by design, no article or video will explain each file, type, function, and return value being written.
Ask the Right Questions
By “asking the right questions,” Cody meant that during planning of a new feature, you should try to predict edge cases that might come up later. Melkey further clarifies the point by saying that this comes with experience. He still encourages people to ask questions. Even “beginner questions” will still get you to learn better until you get to know the right questions to ask.
This is only the technical part of asking the right questions, but there is also a non-technical part of that, which happens when you are a freelancer or in a small team. In those settings, you deal with non-technical clients or managers. These people may think they want something out of your software, but if you try to go beyond that direct request and try to ask the right questions, you may get a better idea about your users and how to deliver better software to them. That will be a much better scenario than simply saying “yes” or “no” to whatever they ask.
Learn to Write Documentation
Beside the general advice to be sure to document any new feature or script, Cody mentions adding diagrams to better explain the code, and Melkey mentions that this is especially great for explaining software to non-technical people. He even argues it might be better than being great at the technical aspect alone.
Among all the advice given so far in the video, adding diagrams to documentation was the most actionable for me. While I try my best to document my code, especially packages and CLIs that can be potentially used by others, I never thought of making a diagram. So, I will keep that in mind going forward. Also, any visual aspect like screenshots and demo GIFs will serve as documentation that is both informative and appealing. (Let’s be honest: visual appeal matters, especially in portfolio projects.)
Master Debugging
The first point here is that debugging usually takes longer time than writing a new feature and, by extension, debugging is a more valuable skill than merely writing code. Cody recommends learning how to use a debugger, but I’m not sure if I agree. In the context of web development, I’ve been able to solve all bugs I encountered by simple print-debugging. ThePrimeagen is also pro-print-debugging and thinks it’s sufficient for web apps.
Another point related to debugging is reading the error message. I believe lots of people think error messages are less informative than they actually are. I don’t know if this is a beginner-dev thing or it generalizes to professional ones, but I’ve seen lots of beginners treating errors like such a cryptic thing without taking the time to parse it and find the meaning in it.
Conclusion
“Just get good!”
This was a relatively short video, but it was fun and had a lot of insightful content that I am glad to have reviewed here. Thanks for reading and good luck on your journey!