1. Read the docs 2. Write tests - unit testing with jest and vitest - e2e with cypress and playwright - integration testing, api testing - test containers 3. Learn to write documentation 4. Collabrate with other devs 5. use Debuggers 6. understand CORS
Another thing is really important is to start asking yourself the question Why? Instead of just doing what is trending or what most people tell you to do.
My answer is that, because I’m a Muslim, many other jobs make me compromise on my religion. 1. Medical - too much time, time which I would like to learn and teach Islam. Also don’t want to interact with women who are strangers. 2. Engineering - women. Islam prohibits unnecessarily interacting with women. Even though it might be valid as it is a need, frankly, I have a strong desire for women, and I’m afraid being near them could cause me to form relationships against my religion. 3. Anything to do with banks - interest. Interest is completely forbidden in Islam. 4. Cooking - women. 5. Teaching - women. Etc you get my point. But CS is one of the only professions where I can limit the negative aspects of other careers. Also I can move to a Muslim country while working remote on my job.
I think these are great indicators of quality experience. There's a lot of developers that build years of experience and yet do not have the depth of these skills. I have seen many developers say things like "I don't like documentation" but they have never written much documentation to begin with. Similarly, they say things like "we need test 100% coverage" when they have never actually written that much test at all or don't know what it takes to get there and why. The more you try difficult things in real life, you run into challenges and limitations you never knew before, and or become more convinced by the values and benefits these practices bring, which leads to having more nuanced and "deeper" level of skills.
This is goldeeeeeen! Found your channel few hours ago and this video alone is far better than most channels with millions of subscribers. Thanks for transparent information!
Solid advice! I enjoy documenting, it's like the finishing touches to the code and helps me to check in if I really understand what I'm doing. If you can't teach it to others, you haven't really learned it.
You are the bigbrother everyone wants in their life. Always guiding & giving genuine advice. Everytime i come to your channel i learn something new, it has shaped me to become a better dev in my community. Thank you
Another bonus one I would suggest if you are looking to go down the senior path is presenting to a group. So becoming a subject matter expert on something higher level and not company specific and then having deep enough knowledge to talk about it to a group. Some examples of the top of my head, messaging, event driven architecture, my current favourite topic - code quality. Obviously it really helps if you have a genuine interest in the subject and if the company dismiss it as not being relevant to them then maybe that’s a sign the company isn’t a great fit
Thanks. Altought having 3 years of experience in this field I still feel amateur compared to you guys. Appreciated for this type of guideline. This will help me greately in my next couple of months of improvement. I mean learning is forever but I will be learning some of the things in this to improve myself and more later on.
Outstanding advice. I wish I had watched this video 9 years ago when I started learning to code. It would have saved me A LOT of headaches. You people starting your dev career recently pay attention to this and put it into practice.
I often find that reading the source docs / tutorial makes a lot more sense after struggling through YT tutorials first, lol. Often the docs show 1 implementation and expect the dev to be able to do other permutations of it (which is fair), so i like to see a few different ways thigns are done, then i go back through and read them again.
Wow listening to this makes me feel very grateful that I am on a team that has enforced a lot of these daily practices on me over the past 2 years. My brother has been a dev for 10 years and has never written a test. At my job I cannot get a PR approved without full test coverage on any code I write. I’ve learned to really enjoy testing.
An important thing I learned, especially with my hobby projects, is to take a break and return later with a fresh pair of eyes. Sometimes, that may result in “sleeping it off.” You already know the answer, but you can’t get to it. Coming back after a lunch break or TH-cam break and having the solution instantly come to mind is refreshing!
Experimented with the pomodoro technique and that really boosted my clarity and productivity and also made me enjoy solving problems even more. So 25min work, 5 min break, 25min work 5 min break. Great stuff
When I code , i like to keep an outline of what I am doing and why and highlight only one task at a time.The reason is that this prevents me going down rabbit holes, it also lets me pick up right where I left off because I have my thought process written down in an outline format. Also, I will in the future think of something and know that I have thought of this before, so this lets me search through my thought process from the past. It takes a little bit more time, but it's worth it and saves me time in the long run.
extra tips that helps me a lot. -read the source code of open source software/lib that you use. try to understand it. -read the issue pr on those projects. you'll learn the reason why they choose that approach. -try reinvent the wheel. make a clone of open source software that you use. then compare the code. -try to code one abstraction lower. if you code react, try to code fe with vanilla js. try to bundle on your own. if you code backend, try to not use framework. try to make your own http server.
You missed I would say one of the base ones which is KNOW how to be a master at version control. GIT is incredibly important, and one of the key tools that you need to know. You can't imagine how many developers are just completely clueless about how to properly use it
Great content u always got, you are one of the realiest developer not the "content creator developer" type. I believe beginners should learn this before even start to learn coding. After entering the real programmng world it felt like I was always only learning how to type.
A quick way to learn is understanding the concept first, then implement it. Then repeat the same with another technology and do your analysis, or read up why certain technology is preferred for which situation
The collaborative part is my weak point. I can sit down, enter the zone, and be extremely productive in the absence of the distractions of another person. I value collaboration more in the early stages during brainstorming sessions when we're figuring out the best architecture and stack to use.
About to graduate and super glad that in the points mentioned, I've done with my mentor in my internship terms thus far. Started with a refactor for DI, then writing tests, given a week to read on specific docs, then implement collaboratively. I like it and I learned alot from it!
I would also recommend learning multiple programming languages if you’re only familiar with one. Even if you never end up using that language professionally each language is good at solving specific problems in specific ways, letting you see problems in different lights. You can take that new view when you go back to the language you’re working in professionally.
there is also another thing , Do not underestimate yourself, sometimes i see some people with great skills , and somehow they are affraid of even taking a junior level interview, i am sure a lot of those who saw the video already know all of these things, and yet they think they are bad 2 things you forgot : 1 - do the actual thing , CODE , this is how you will be better, you will be able to code without reffering to many docs or google searchs 2 - learn version control and have good habits on commit messages and branch naming
I think just being curious can get you to be way above average. Oh you are curious about testing? Just go and experiment with it. Oh you are curious how other people do architecture? Find an open source project and go and look at it. Many developers say "yeah I really like programming, I like learning new things", but they never actually do try new things or even just read about them.
@aaronsanders6162 it's not about being fixated on a single thing. It's about being curious about programming in general. Being curious and genuinely interested in programming advanced my career the most I would say. If you are trying to be a programmer for the money and just want to do your 9-5 and not think about it anymore, you will most likely be average, if you even manage to get into the field. Of course, exceptions to the rule exist.
I agree, some of the most talent devs are the ones I know who always ask why and try to figure out how stuff works instead of just fixing it and moving on. It’s a trade off though because those types of developers can often waste days being too curious while the client is wondering why that feature you just demoed isn’t done yet. Knowing when to move on and revisit later is an important learned smiles
Great topics to improve in your career ! I would emphasis even more the need to be able to "share knowledge". It does enter in few of your points but i truly believe that you are getting proficient with a tool only once you are able to explain it. Also being able/being acustomed to talking to people/ group of people is one of the best softskill to have !
'share knowledge' is so important, many devs have the view that if they share, then their importance is reduced:( Wherever I worked, created a knowledge base that anyone in the team - present and future - can refer. The way we have solved a problem in one project comes in handy for something else too.
Hello cody, Im having some doubt pls ellaborate Currently i have done todos,imdbclone,blog website with crud feature and some static site in web using next js react react query tailwind css node js and express js And i am currently learning / making blog site in app using expo react native i also completed imdbClone in react native. The main thing is that sometimes i get stuck inbetween in js.so im currently learning js from scratch its like im reading eloquent js book after that should i start applying for job? (Ps:Blog site in web is my biggest project that i have done there is implementation of auth and many more feature like user signin signup forget password etc etc so give me some puece of advice )
It doesn’t hurt to just try applying now, but if your biggest app is a blog site you need to work on something larger. Integrate with stripe, add authentication, have a database, send out emails, etc
Hey Cody could you make a video on how to use Debugger? in Node or Frontend?? i know how to add debuggers when a code gives error and i can move to that specific line in sources but need more clarity on how backend does it? or if any way to add breakpoint on FE
Since the title says "99% of developers", I'm going to assume you aren't just talking about web developers. These are mostly good points but they are not going to get you ahead of 99% developers. Maybe you could argue 90%, but even that is too big of percentage in my opinion. I would say these are mostly basic skills, except maybe mastering debugging . Debugging and profiling of a complex system, like for example Linux kernel or a 3D graphics engine, can sometimes be really hard.
I agree none of this will get you ahead of 99% of developers, with enough experience every dev will eventually work through these points, no real advantages here
Great topic. I think what should be added could be learn to share your knowledge that will help solidify it (as you’re doing it). It can be writing it in blogs, doing in person tutorials or online etc
As a beginner what i find bothersome with documentations is that it feels like unless you're already very experienced, you understand nothing from it. For example it will say to integrate our feature X you need to do Y. Problem is that many of us don't even know how to do Y to begin with, yet alone implement X after.
Thanks for the helpful video! Regarding the "Learn to write documentation" point, I don't have a lot of experience with writing documentation, but I really want to learn how to do it. Do you have any advice on how to become better at this? I often struggle to know where to begin, what to include, and how to make it detailed but not too overwhelming. I would appreciate any guidance or your thoughts on this. Thanks!
It's not really how to get ahead of 99% of developers It's how to just be a professional and actually bringing value Everything you said is what we do everyday That's supposed to be normal
A lot of us log debuggers have used debuggers then turned back, especially watching people using debuggers repeating runs so much I've found log debugging does two things better, you don't need to rerun the same thing as much because you can look back at previous runs' logs, it encourages you to add more information to logs so they're actually useful for when you have prod issues or complaints (I've seen so many logs that just say an event happened with no context information at all and its often nearly free to add all of the potentially useful context information even just as a text dump) That said I still use a debugger but usually only for investigating issues with a library I've imported that I might be misusing or that might have a bug itself and doesn't have enough logging available for me to dig deeper otherwise.
"If you don't provide test/you don't know how to talk about testing, we probably aren't going to hire you" This is an interesting point for me, is a developers understanding of tests really that good of an indicator as to if they're a good hire? Like if someone was a great dev, gave all the other signals you were looking for, you really wouldn't be down to just teach them about writing tests? Just seems a bit weird to me since we don't test at my current job(startup-esq), so it would seem weird to me to not get hired for a job I was an otherwise great fit for if testing was the one gap in my knowledge(obviously I have plenty of gaps in my knowledge, I'm speaking hypothetically here)
You should at least know how to talk about testing. I just interviewed a senior engineer with over 10 years of experience; they didn’t know how to explain testing at all
In the ideal world, this all would be awesome. Unfortunately a lot of companies prefer the quick and dirty approach. Obviously a PITA for us developers, but we need to get with the flow most of the time. That sucks. 😢
I watched Melky's video and he raised some valid criticism of TH-cam content creators. My take is that if the answer to this particular question gains popularity then it's not the right answer. One has to go to extreme lengths in order to achieve what the vast majority couldn't. For me, I would expect that specialization is a prerequisite for mastery. I appreciate your perspective though. The current job market for developers requires a wide array of skills. And so being a generalist could pay off in one way or another.
About step 2. Whenever I bring up these kind of questions, I always feel weird because most of the answers I get "Yeah, this is a good question, what do you think about it?". I just gave up. At this point I always consider worst case scenario when I write code. Always add layers of data abstraction.
The most important thing is to understand the stakeholders' requirements and build the feature in time. Again, this is a broad area but if you can do it then that means that you are a great problem thinker, can know how to fix bugs and use debuggers, work in a team and lead them (if that is the case), and overall talk, deliver updates to the stakeholders. This is a crucial skill for software developers.
11:31 To be fair, null reference error messages are terrible. The compiler could actually help and say which variable or chain of variables is null and specify the method or member that is being called on that variable/chain.
I totally agree with testing. There are only dump examples on TH-cam (testing add function). But testing can get so hard and I really struggle a lot with it (mocking, stubbing etc.). Maybe u can provide a good useful insights how u handle it with real examples? Would be great!
You can actually get an ahead of I would say 100% of the devs out there. If you learn to put the product you’re working on first and have a product based mind. Next.js and your bubble sort algorithms are worthless if you can’t understand the product your building. Learn to know the product better than your product owner and you will go very very far in a company
I cannot explain the level of DUH BRO and yes this is absolutely true and gold. I have 5+ years exp and went 0-60 real quick started from the bottom now we here. 😁Theres no short cut for doing this stuff other than having processes in place that consistently yield similar results.
Funnily, most people I know like to neither read or write documents. I don't think most of those who don't like reading are to blame by any stretch of the imagination. It is very much conceivably arduous and frustrating to go through a wall of dull texts even for the most avid readers. Adding a literary spin is essential to making one's doc fun and easy to comprehend, and exquisite writing keeps yourself engaged to the fullest as a doc writer too.
Yeah it's hard to keep docs detailed, but still engaging. From my personal experience, per project docs are way overrated. Yes, having simple onboarding docs to be able to set up the project is great and does make sense, but anything beyond that can be a huge waste of time. I've seen it many times that people complain that something doesn't exist in the docs when it does exist and I've seen it that even if super detailed docs do exist, people still go to Slack/Teams and ask devs directly instead of trying to search in docs first. I've been a huge proponent of writing docs in the past, but after seeing docs just get ignored by many on many occasions, I'm a proponent for not documenting project intricacies and just having onboarding docs. And also, keeping docs in sync with code/architecture is just super tedious. If you are building a library/framework, that's a totally separate topic and those do require detailed docs in order to be more usable.
I tried to learn a framework by reading its documentation, and I found it extremely challenging because most of the time, the documentation lacks good examples. I feel lost and unsure of how to apply an object or class in the code.
To add to point 2: "Ask dumb questions". Like why are we even doing this for.. will this do what it's supposed to?.. is this feature even necessary?(cost saving tsk. tsk.). To point 4: Comment your code. Even when you're learning through do-along tutorials, if you dont understand how to comment that particular line of code for a total newbie to understand, you aren't learning anything in the first place. To point 5: Practice planning your project with charts. Collaborate with your project buddies, build conceptual designs aka napkin design. Then later build upon it towards the real physical architecture and then start actually working on the project with a clear goal, budget, timelines, etc.
easy learn a system level programming language, learn assembly, C, Zig, Rust, implement your own memory allocators, your own top descent parser/compiler, build a kernel, a fuzzy finder. Learning a framework, or stupid fluff like design patterns won't get you far. Learning communication, stress, expectation and time management and all the soft skills necessary is really important too, learning DTS, building useful stuff.
Eh I don’t find them useful outside of interviews. I’ve never solved a dynamic programming problem at work, and I’ve only had to recursively traverse a tree once or twice in my career
Great. Is frustrating when you're a collaborating with some devs and they provide poor documentation of their projects and don't understand how to make a code review, open a PR, etc.
Testing is important but tbh i hate to write test , sometimes it felt like god no. if it is working perfectly on manual testing then why to write , just hate testing stuff.
Do you want to maybe make some videos about some real examples of testing? I still don't have a clear understanding of what to test and when to test so I just go ahead and test on the running application every time instead of thinking about writing tests.
Pair programming is not what it seems. Apart from being very exhausting, Its only purpose is to sequeeze more work out of you and to optimize the slave work in a team. Imagine coding and being in a meeting at the same time 8 hours a day
It’s not for everyone, but I find it actually helps you code higher quality software and work through bugs faster. It can be exhausting to some, so 8 hours a day might be extreme, but letting devs just work on their own stuff in isolation is also a recipe for disaster. It leads to people spending a full 5 days trying to solve issues that someone else could maybe help fix in 30 minutes
It invigorates me, it help's teach junior and mid developers useful technical and problem solving skills and it's 2 sets of eyes to find bugs. I just wish I could do it more often than 2 hours per week on average. I need to find a new job.
@@WebDevCody Although its proven to work in the right teams, it mostly doesn't and the worst part is that a lot of companies try to force it - which is the worst idea possible. So while it can be a good skill to have, i don't think it will make you that much better as a programmer compared to the pother points you made. Also i think if a programmer spends 5 days trying to solve a problem without telling anyone or asking for help thats a bigger issue that might not be solved with pair programming :) I personally code since about 15 years and did quite a few pair programming sessions but i can't name a single one that was super productive compared to a seperate meeting with the person and a good agenda for that and then splitting the work to be done.
@@TheRealWurstCase idk I’ve had some good pair programming sessions. When the feature involves complex business logic it’s often much easier to have multiple devs who share knowledge of the system being in the same zoom. I’ve seen pairing reduces the back and forth between thinking we did the story correct and then getting it sent back because we missed something. It’s nice having multiple eyes reviewing the work as it’s done vs reviewing a pull request at the end of the feature and needing to review 100 file changes.
I'm obsessed with this content. I had the pleasure of reading something similar, and I was completely obsessed. "Mastering AWS: A Software Engineers Guide" by Nathan Vale
8 hours of pair programming a day? Am I missing something or does this effectively half productivity (two devs become one)? Is this always followed up with code review in pull requests? I treat pull requests as async pair programming.
Pair coding removes the need to do thorough code reviews. My biggest argument in support to pair coding is “have you ever been stuck on a bug for hours just to have one person help you solve it in 5 minute? That’s what pair programming provides, but the entire time you code”
this is great but I have issues reading many docs. They give you information for a more advance user so what I read makes no sense. So I need to understand it all but I don't even know enough to understand what the doc is telling me a lot
The clickbait thumbnail had me thinking: the ones creating videos like this are the 1% and the people watching are the soydevs. Creating this video made you learn new content, how to edit videos, how to narrate and talk and most importantly how to document (in video form). This video acts as an asset, boosting your income and reputation. Those of us watching basically learn very few things compared to the creator and watching this does not boost our income nor reputation. So keep on creating, whatever it may be. Keep your times of consumption short and your creative times long.
100% this channel has always benefited me a lot more than anyone watching imo. The amount of clout and skills I’m learning with every video continuously increases my net worth. At least a few say they are learning new stuff
Didn’t watch the video but the way you get ahead of 99% of developers is by reading books. Books about programming concepts. Books about design methodologies. Read books guys. Learning JavaScript from internet and from a book is totally separate thing. You can traverse so much ahead of others if you read books
Reading the docs has actually been more helpful in most cases than following any code along or tutorial on TH-cam… something I wish I knew before wasting so much time on pointless videos
If you are a software engineer who has actually worked on a decently complex project, everything mentioned in this video should be implicit when you're hired. There is no longer room for people who can just code. Everything here should be expected, not reminded
"we work on government stuff that might be around for 5-10 years" i think double to tripple that and the number might be more accurate as a minimum lol
this helped me reach my clickbait title quota for the year, sorry
Taking the bait was worth it though.
How To Get Ahead of 99% Of TH-cam Coders :D
😂
@jonasjonaitis8571 😂 I know a lot of people who don’t read the docs. The bar is low
"Click-bait" or not, it's useful to hear various people's views on the important things to know. Happy New Year!
1. Read the docs
2. Write tests
- unit testing with jest and vitest
- e2e with cypress and playwright
- integration testing, api testing
- test containers
3. Learn to write documentation
4. Collabrate with other devs
5. use Debuggers
6. understand CORS
No, not understand cors, understand why bugs are happening and learn from those mistakes. I probably shouldn’t have mentioned cors at all 😆
@@WebDevCody This was actually a funny one as CORS is a nightmare for a lot of developers lmao, thanks for the vid, good tips for a short one !
5. use Debuggers LMAO
this.
Cringe. Can you compute in-place fft? No? You're code monkey then, not a developer.
Another thing is really important is to start asking yourself the question Why? Instead of just doing what is trending or what most people tell you to do.
Totally agree on this one!
Why use Java If I am comfortable with C#
exactly, always ask what the purpose of a thing is, if the answer is just "it's a trendy tech" might as well skip it.
My answer is that, because I’m a Muslim, many other jobs make me compromise on my religion.
1. Medical - too much time, time which I would like to learn and teach Islam. Also don’t want to interact with women who are strangers.
2. Engineering - women. Islam prohibits unnecessarily interacting with women. Even though it might be valid as it is a need, frankly, I have a strong desire for women, and I’m afraid being near them could cause me to form relationships against my religion.
3. Anything to do with banks - interest. Interest is completely forbidden in Islam.
4. Cooking - women.
5. Teaching - women.
Etc you get my point. But CS is one of the only professions where I can limit the negative aspects of other careers. Also I can move to a Muslim country while working remote on my job.
@izakbhere8079 you won't last long if that's the only thing that drives you
I think these are great indicators of quality experience. There's a lot of developers that build years of experience and yet do not have the depth of these skills. I have seen many developers say things like "I don't like documentation" but they have never written much documentation to begin with. Similarly, they say things like "we need test 100% coverage" when they have never actually written that much test at all or don't know what it takes to get there and why. The more you try difficult things in real life, you run into challenges and limitations you never knew before, and or become more convinced by the values and benefits these practices bring, which leads to having more nuanced and "deeper" level of skills.
This is goldeeeeeen! Found your channel few hours ago and this video alone is far better than most channels with millions of subscribers. Thanks for transparent information!
Solid advice! I enjoy documenting, it's like the finishing touches to the code and helps me to check in if I really understand what I'm doing. If you can't teach it to others, you haven't really learned it.
In my internship I was surprised how little people documented. If I ran into a problem that I thought others would face, I will documentation on it.
You are the bigbrother everyone wants in their life. Always guiding & giving genuine advice.
Everytime i come to your channel i learn something new, it has shaped me to become a better dev in my community. Thank you
Thanks man I appreciate that!
Another bonus one I would suggest if you are looking to go down the senior path is presenting to a group. So becoming a subject matter expert on something higher level and not company specific and then having deep enough knowledge to talk about it to a group. Some examples of the top of my head, messaging, event driven architecture, my current favourite topic - code quality. Obviously it really helps if you have a genuine interest in the subject and if the company dismiss it as not being relevant to them then maybe that’s a sign the company isn’t a great fit
Thanks. Altought having 3 years of experience in this field I still feel amateur compared to you guys. Appreciated for this type of guideline. This will help me greately in my next couple of months of improvement. I mean learning is forever but I will be learning some of the things in this to improve myself and more later on.
Outstanding advice. I wish I had watched this video 9 years ago when I started learning to code. It would have saved me A LOT of headaches. You people starting your dev career recently pay attention to this and put it into practice.
Learn to Collaborate is #1, because a senior dev can tell you about all the others and show you how and when to use them.
I often find that reading the source docs / tutorial makes a lot more sense after struggling through YT tutorials first, lol. Often the docs show 1 implementation and expect the dev to be able to do other permutations of it (which is fair), so i like to see a few different ways thigns are done, then i go back through and read them again.
Wow listening to this makes me feel very grateful that I am on a team that has enforced a lot of these daily practices on me over the past 2 years. My brother has been a dev for 10 years and has never written a test. At my job I cannot get a PR approved without full test coverage on any code I write. I’ve learned to really enjoy testing.
An important thing I learned, especially with my hobby projects, is to take a break and return later with a fresh pair of eyes.
Sometimes, that may result in “sleeping it off.”
You already know the answer, but you can’t get to it. Coming back after a lunch break or TH-cam break and having the solution instantly come to mind is refreshing!
Experimented with the pomodoro technique and that really boosted my clarity and productivity and also made me enjoy solving problems even more. So 25min work, 5 min break, 25min work 5 min break. Great stuff
4:10
- unit testing with jest and vitest
- e2e with cypress and playwright
- integration testing, api testing
- test containers
The cors error got me thinking 😂😂
Thank you for this video.
Really appreciated m
When I code , i like to keep an outline of what I am doing and why and highlight only one task at a time.The reason is that this prevents me going down rabbit holes, it also lets me pick up right where I left off because I have my thought process written down in an outline format. Also, I will in the future think of something and know that I have thought of this before, so this lets me search through my thought process from the past. It takes a little bit more time, but it's worth it and saves me time in the long run.
Good suggestion!
I'm forced to do so recently. I'm amazed by how much time it saved.
extra tips that helps me a lot.
-read the source code of open source software/lib that you use. try to understand it.
-read the issue pr on those projects. you'll learn the reason why they choose that approach.
-try reinvent the wheel. make a clone of open source software that you use. then compare the code.
-try to code one abstraction lower. if you code react, try to code fe with vanilla js. try to bundle on your own.
if you code backend, try to not use framework. try to make your own http server.
Reading other code is definitely helpful!
You missed I would say one of the base ones which is KNOW how to be a master at version control.
GIT is incredibly important, and one of the key tools that you need to know. You can't imagine how many developers are just completely clueless about how to properly use it
Great content u always got, you are one of the realiest developer not the "content creator developer" type. I believe beginners should learn this before even start to learn coding. After entering the real programmng world it felt like I was always only learning how to type.
A quick way to learn is understanding the concept first, then implement it.
Then repeat the same with another technology and do your analysis, or read up why certain technology is preferred for which situation
The collaborative part is my weak point. I can sit down, enter the zone, and be extremely productive in the absence of the distractions of another person. I value collaboration more in the early stages during brainstorming sessions when we're figuring out the best architecture and stack to use.
About to graduate and super glad that in the points mentioned, I've done with my mentor in my internship terms thus far. Started with a refactor for DI, then writing tests, given a week to read on specific docs, then implement collaboratively. I like it and I learned alot from it!
Hi Cody, this is the perfect video for new year as a developer. Thank you! Much appreciated!
These are great indicators of a good dev, not sure about 99% ahead but I am sure, will be far ahead than many devs out there.
Great video as always. Thank you for doing it
I would also recommend learning multiple programming languages if you’re only familiar with one. Even if you never end up using that language professionally each language is good at solving specific problems in specific ways, letting you see problems in different lights. You can take that new view when you go back to the language you’re working in professionally.
Thanks for sharing the valuable content.
there is also another thing , Do not underestimate yourself, sometimes i see some people with great skills , and somehow they are affraid of even taking a junior level interview,
i am sure a lot of those who saw the video already know all of these things, and yet they think they are bad
2 things you forgot :
1 - do the actual thing , CODE , this is how you will be better, you will be able to code without reffering to many docs or google searchs
2 - learn version control and have good habits on commit messages and branch naming
I think just being curious can get you to be way above average. Oh you are curious about testing? Just go and experiment with it. Oh you are curious how other people do architecture? Find an open source project and go and look at it. Many developers say "yeah I really like programming, I like learning new things", but they never actually do try new things or even just read about them.
@aaronsanders6162 it's not about being fixated on a single thing. It's about being curious about programming in general. Being curious and genuinely interested in programming advanced my career the most I would say.
If you are trying to be a programmer for the money and just want to do your 9-5 and not think about it anymore, you will most likely be average, if you even manage to get into the field. Of course, exceptions to the rule exist.
I agree, some of the most talent devs are the ones I know who always ask why and try to figure out how stuff works instead of just fixing it and moving on. It’s a trade off though because those types of developers can often waste days being too curious while the client is wondering why that feature you just demoed isn’t done yet. Knowing when to move on and revisit later is an important learned smiles
@@WebDevCody yes, absolutely true! Knowing when to stop doing something is also a skill.
Great topics to improve in your career ! I would emphasis even more the need to be able to "share knowledge". It does enter in few of your points but i truly believe that you are getting proficient with a tool only once you are able to explain it.
Also being able/being acustomed to talking to people/ group of people is one of the best softskill to have !
'share knowledge' is so important, many devs have the view that if they share, then their importance is reduced:( Wherever I worked, created a knowledge base that anyone in the team - present and future - can refer. The way we have solved a problem in one project comes in handy for something else too.
Hello cody,
Im having some doubt pls ellaborate
Currently i have done todos,imdbclone,blog website with crud feature and some static site in web using next js react react query tailwind css node js and express js
And i am currently learning / making blog site in app using expo react native i also completed imdbClone in react native. The main thing is that sometimes i get stuck inbetween in js.so im currently learning js from scratch its like im reading eloquent js book after that should i start applying for job?
(Ps:Blog site in web is my biggest project that i have done there is implementation of auth and many more feature like user signin signup forget password etc etc so give me some puece of advice )
It doesn’t hurt to just try applying now, but if your biggest app is a blog site you need to work on something larger. Integrate with stripe, add authentication, have a database, send out emails, etc
@@WebDevCody okay sire
Hey Cody could you make a video on how to use Debugger? in Node or Frontend?? i know how to add debuggers when a code gives error and i can move to that specific line in sources but need more clarity on how backend does it? or if any way to add breakpoint on FE
Since the title says "99% of developers", I'm going to assume you aren't just talking about web developers. These are mostly good points but they are not going to get you ahead of 99% developers. Maybe you could argue 90%, but even that is too big of percentage in my opinion. I would say these are mostly basic skills, except maybe mastering debugging . Debugging and profiling of a complex system, like for example Linux kernel or a 3D graphics engine, can sometimes be really hard.
I agree none of this will get you ahead of 99% of developers, with enough experience every dev will eventually work through these points, no real advantages here
Great topic. I think what should be added could be learn to share your knowledge that will help solidify it (as you’re doing it). It can be writing it in blogs, doing in person tutorials or online etc
As a beginner what i find bothersome with documentations is that it feels like unless you're already very experienced, you understand nothing from it. For example it will say to integrate our feature X you need to do Y. Problem is that many of us don't even know how to do Y to begin with, yet alone implement X after.
Thanks for the helpful video!
Regarding the "Learn to write documentation" point, I don't have a lot of experience with writing documentation, but I really want to learn how to do it.
Do you have any advice on how to become better at this?
I often struggle to know where to begin, what to include, and how to make it detailed but not too overwhelming. I would appreciate any guidance or your thoughts on this. Thanks!
always useful content from senore cody
Correctly logging and parsing logs is also very important
Great video again.
I really appreciate what you are doing.
I am totally agree with all those points.
Thanks for this type of content.
It's not really how to get ahead of 99% of developers
It's how to just be a professional and actually bringing value
Everything you said is what we do everyday
That's supposed to be normal
WOWW the CORS call out. I'll learn CORS when the stack overflow directions stop working for me!
😂
A lot of us log debuggers have used debuggers then turned back, especially watching people using debuggers repeating runs so much I've found log debugging does two things better, you don't need to rerun the same thing as much because you can look back at previous runs' logs, it encourages you to add more information to logs so they're actually useful for when you have prod issues or complaints (I've seen so many logs that just say an event happened with no context information at all and its often nearly free to add all of the potentially useful context information even just as a text dump)
That said I still use a debugger but usually only for investigating issues with a library I've imported that I might be misusing or that might have a bug itself and doesn't have enough logging available for me to dig deeper otherwise.
"If you don't provide test/you don't know how to talk about testing, we probably aren't going to hire you" This is an interesting point for me, is a developers understanding of tests really that good of an indicator as to if they're a good hire? Like if someone was a great dev, gave all the other signals you were looking for, you really wouldn't be down to just teach them about writing tests?
Just seems a bit weird to me since we don't test at my current job(startup-esq), so it would seem weird to me to not get hired for a job I was an otherwise great fit for if testing was the one gap in my knowledge(obviously I have plenty of gaps in my knowledge, I'm speaking hypothetically here)
You should at least know how to talk about testing. I just interviewed a senior engineer with over 10 years of experience; they didn’t know how to explain testing at all
Great content man, keep it up
I’d like to see you and Theo have a debate about unit testing
In the ideal world, this all would be awesome. Unfortunately a lot of companies prefer the quick and dirty approach. Obviously a PITA for us developers, but we need to get with the flow most of the time. That sucks. 😢
I watched Melky's video and he raised some valid criticism of TH-cam content creators. My take is that if the answer to this particular question gains popularity then it's not the right answer. One has to go to extreme lengths in order to achieve what the vast majority couldn't. For me, I would expect that specialization is a prerequisite for mastery. I appreciate your perspective though. The current job market for developers requires a wide array of skills. And so being a generalist could pay off in one way or another.
The truth is there isn’t a right answer. It’s honestly just a click bait title which gets views
All titles are click bait in some sense. @@WebDevCody
About step 2.
Whenever I bring up these kind of questions, I always feel weird because most of the answers I get "Yeah, this is a good question, what do you think about it?". I just gave up. At this point I always consider worst case scenario when I write code. Always add layers of data abstraction.
great tips! it'll be cool if you went in depth in each of these sections, especially testing and debugging
What's your thoughts on pair programming?
Hey Cody I am struggling to implement real time cursor with sockets can you please make something related to this it would too much helpful.
"Learn to write unit tests"
I cheer
".... and documentation"
my nemesis
But for real, excellent information.
The most important thing is to understand the stakeholders' requirements and build the feature in time. Again, this is a broad area but if you can do it then that means that you are a great problem thinker, can know how to fix bugs and use debuggers, work in a team and lead them (if that is the case), and overall talk, deliver updates to the stakeholders. This is a crucial skill for software developers.
11:31 To be fair, null reference error messages are terrible. The compiler could actually help and say which variable or chain of variables is null and specify the method or member that is being called on that variable/chain.
I totally agree with testing. There are only dump examples on TH-cam (testing add function). But testing can get so hard and I really struggle a lot with it (mocking, stubbing etc.).
Maybe u can provide a good useful insights how u handle it with real examples?
Would be great!
You can actually get an ahead of I would say 100% of the devs out there. If you learn to put the product you’re working on first and have a product based mind. Next.js and your bubble sort algorithms are worthless if you can’t understand the product your building. Learn to know the product better than your product owner and you will go very very far in a company
Do we test every applications including crud and web apps that consume api?
I cannot explain the level of DUH BRO and yes this is absolutely true and gold. I have 5+ years exp and went 0-60 real quick started from the bottom now we here. 😁Theres no short cut for doing this stuff other than having processes in place that consistently yield similar results.
Funnily, most people I know like to neither read or write documents. I don't think most of those who don't like reading are to blame by any stretch of the imagination. It is very much conceivably arduous and frustrating to go through a wall of dull texts even for the most avid readers. Adding a literary spin is essential to making one's doc fun and easy to comprehend, and exquisite writing keeps yourself engaged to the fullest as a doc writer too.
Yeah it's hard to keep docs detailed, but still engaging. From my personal experience, per project docs are way overrated. Yes, having simple onboarding docs to be able to set up the project is great and does make sense, but anything beyond that can be a huge waste of time.
I've seen it many times that people complain that something doesn't exist in the docs when it does exist and I've seen it that even if super detailed docs do exist, people still go to Slack/Teams and ask devs directly instead of trying to search in docs first. I've been a huge proponent of writing docs in the past, but after seeing docs just get ignored by many on many occasions, I'm a proponent for not documenting project intricacies and just having onboarding docs. And also, keeping docs in sync with code/architecture is just super tedious.
If you are building a library/framework, that's a totally separate topic and those do require detailed docs in order to be more usable.
I forgot about Cors errors but you just had to remind me.
I tried to learn a framework by reading its documentation, and I found it extremely challenging because most of the time, the documentation lacks good examples. I feel lost and unsure of how to apply an object or class in the code.
I don't like react even if it's easy, I'll just use Svelte or something similar plus my other programming languages and some of the frameworks I like.
Ive never worked anywhere where testing is optional.
No code gets in main without a unit and integration test
To add to point 2: "Ask dumb questions". Like why are we even doing this for.. will this do what it's supposed to?.. is this feature even necessary?(cost saving tsk. tsk.).
To point 4:
Comment your code.
Even when you're learning through do-along tutorials, if you dont understand how to comment that particular line of code for a total newbie to understand, you aren't learning anything in the first place.
To point 5:
Practice planning your project with charts.
Collaborate with your project buddies, build conceptual designs aka napkin design. Then later build upon it towards the real physical architecture and then start actually working on the project with a clear goal, budget, timelines, etc.
easy learn a system level programming language, learn assembly, C, Zig, Rust, implement your own memory allocators, your own top descent parser/compiler, build a kernel, a fuzzy finder. Learning a framework, or stupid fluff like design patterns won't get you far. Learning communication, stress, expectation and time management and all the soft skills necessary is really important too, learning DTS, building useful stuff.
What about algorithms and data structures?
Eh I don’t find them useful outside of interviews. I’ve never solved a dynamic programming problem at work, and I’ve only had to recursively traverse a tree once or twice in my career
Great. Is frustrating when you're a collaborating with some devs and they provide poor documentation of their projects and don't understand how to make a code review, open a PR, etc.
this was very useful to me. thanks
If everyone is top 1%, math is broken
Great video!
excellent vid!
Love your videos.
how can you do pair programming remotely and both of you use an ide?
There is tooling to allow screen control, zoom has one built in, we also use one called pop which allows screen control
I would add practice and build things.
Testing is important but tbh i hate to write test , sometimes it felt like god no. if it is working perfectly on manual testing then why to write , just hate testing stuff.
Do you want to maybe make some videos about some real examples of testing? I still don't have a clear understanding of what to test and when to test so I just go ahead and test on the running application every time instead of thinking about writing tests.
Pair programming is not what it seems. Apart from being very exhausting, Its only purpose is to sequeeze more work out of you and to optimize the slave work in a team. Imagine coding and being in a meeting at the same time 8 hours a day
It’s not for everyone, but I find it actually helps you code higher quality software and work through bugs faster. It can be exhausting to some, so 8 hours a day might be extreme, but letting devs just work on their own stuff in isolation is also a recipe for disaster. It leads to people spending a full 5 days trying to solve issues that someone else could maybe help fix in 30 minutes
It invigorates me, it help's teach junior and mid developers useful technical and problem solving skills and it's 2 sets of eyes to find bugs. I just wish I could do it more often than 2 hours per week on average. I need to find a new job.
@@WebDevCody Although its proven to work in the right teams, it mostly doesn't and the worst part is that a lot of companies try to force it - which is the worst idea possible. So while it can be a good skill to have, i don't think it will make you that much better as a programmer compared to the pother points you made. Also i think if a programmer spends 5 days trying to solve a problem without telling anyone or asking for help thats a bigger issue that might not be solved with pair programming :)
I personally code since about 15 years and did quite a few pair programming sessions but i can't name a single one that was super productive compared to a seperate meeting with the person and a good agenda for that and then splitting the work to be done.
@@TheRealWurstCase idk I’ve had some good pair programming sessions. When the feature involves complex business logic it’s often much easier to have multiple devs who share knowledge of the system being in the same zoom. I’ve seen pairing reduces the back and forth between thinking we did the story correct and then getting it sent back because we missed something. It’s nice having multiple eyes reviewing the work as it’s done vs reviewing a pull request at the end of the feature and needing to review 100 file changes.
Great video ❤
Your videos are always enlightening specially for a beginner like me.
Appreciate the effort and sincerity you put in them.
I'm obsessed with this content. I had the pleasure of reading something similar, and I was completely obsessed. "Mastering AWS: A Software Engineers Guide" by Nathan Vale
8 hours of pair programming a day? Am I missing something or does this effectively half productivity (two devs become one)? Is this always followed up with code review in pull requests?
I treat pull requests as async pair programming.
Pair coding removes the need to do thorough code reviews. My biggest argument in support to pair coding is “have you ever been stuck on a bug for hours just to have one person help you solve it in 5 minute? That’s what pair programming provides, but the entire time you code”
You missed a big one and that is to build projects. It's especially useful for new developers and unemployed developers.
but other youtubers say that this vid is more for the stuff that goes under the radar
SRS also contributes a lot
Thnaks
Learning to collaborate is going to be the thing I'll focus on from now. It's very difficult for me.
If you open a bug or issue as a developer without even stepping one line? You have no business opening that issue. Number 5 should be number 1.
Lol number 6.
Thanks for info. Just letting u know yt chapter generator and ur website link is not working.
Yeah I broke it all on accident. I’ll work on fixing it again
I 100% agree!
i don't want to work at a place that tests tbh.
how do you manage writing code in multiple language without getting confused in using methods .. 😁👨🏽💻
arr.length, arr.Length, len(arr), count($arr)
this is great but I have issues reading many docs. They give you information for a more advance user so what I read makes no sense. So I need to understand it all but I don't even know enough to understand what the doc is telling me a lot
do you have a few videos on testing because I don't understand that at all. Like when I think of test I think of actually using it
I have a few, but not that many. maybe I'll make more
I do most of these practice daily 😎. But thanks i was not aware....
The clickbait thumbnail had me thinking: the ones creating videos like this are the 1% and the people watching are the soydevs.
Creating this video made you learn new content, how to edit videos, how to narrate and talk and most importantly how to document (in video form). This video acts as an asset, boosting your income and reputation. Those of us watching basically learn very few things compared to the creator and watching this does not boost our income nor reputation. So keep on creating, whatever it may be. Keep your times of consumption short and your creative times long.
100% this channel has always benefited me a lot more than anyone watching imo. The amount of clout and skills I’m learning with every video continuously increases my net worth. At least a few say they are learning new stuff
Didn’t watch the video but the way you get ahead of 99% of developers is by reading books. Books about programming concepts. Books about design methodologies. Read books guys. Learning JavaScript from internet and from a book is totally separate thing. You can traverse so much ahead of others if you read books
Reading the docs has actually been more helpful in most cases than following any code along or tutorial on TH-cam… something I wish I knew before wasting so much time on pointless videos
If you are a software engineer who has actually worked on a decently complex project, everything mentioned in this video should be implicit when you're hired.
There is no longer room for people who can just code. Everything here should be expected, not reminded
what browser do u use ????
Chrome
@@WebDevCody but isn't that privacy invaiding ? i use brave with duck duck go
"we work on government stuff that might be around for 5-10 years"
i think double to tripple that and the number might be more accurate as a minimum lol
😂 I could see that as being accurate
why do I feel like he is talking abt one of his juniors developers 🤣
If the shoe fits 👀
The clickbait title was unnecessary. Should've been "how to be a programmer" because all of this is the bare minimum for a productive programmer.