It's laughable that new programmers are encouraged to contribute to long running existing projects like this. It's almost embarrassing to think that some people would try this. The whole "code education complex" is so detached from the reality of how things actually work, it's encouraging people to go in & potentially destroy projects that half the web relies on now.
What a ridiculous statement. Name one project that was destroyed by this. Just one. Contributions are not automatically merged and released to thousands of people and companies. They are rigorously reviewed by the maintainers, and even then, there's often a transitional period for larger features-even for the code contributed by core developers.
I don't agree with the destruction part but the first part is really true. Those internals are just like the video says, you're most likely not prepared.
The only time I've ever been able to contribute to open source is when 1. I already knew the language used the project. 2. I was using some esoteric software a bunch of people don't use. 3. I found a bug. 4. I could reproduce the bug on my local machine after I downloaded the code. That's why I was thinking "what the fuck are these assholes talking about when they say I should contribute to open source?" when I started developing.
i tried to contribute to a php framework similar to express. i ended up rewriting it myself from scratch, left an issue on on it, and the dev never got around to it. my functional solution worked better and was cleaner than their OOP code anyway. but composer and the psr-4 autoloading is probably the reason why php people love classbased php even tho functions are just as performant if not more so.
It's my opinion that the whole idea around "open source" just doesn't work in the real world. Yes, technically, everyone can "jump in" and contribute, but in practicality it's impossible. It's just too many lines of code, too many systems running in parallel for you to ever be able to actually contribute to it in a meaningful way. So I absolutely agree with this video. So to all the beginners in programming out there: Don't waste your time trying to get a PR accepted on any big open source project. Have fun building your own stuff instead. At least there you can get some actual value for your time.
yeah or contribute to one of your friends project that is either on the same level as you or is willing to hold your hand through the process. IMO you should only contribute if you have a vested interest in the actual projects outcome and not because you think itll elevate your coder "cred."
So true, my first gig was solo in a start up so I wrote literally everything and felt more confident, now I'm in a team re-writing an old monolith and finding it very difficult to wrap my head around everything, and by the time I get more comfortable the team will move onto the next microservice!!
Hit the nail in the head. I'm at a fintech startup for 3 months now and the codebase is so convoluted I can barely contribute or add any value to the company. This being the standard nowadays makes it hard to work somewhere new as a developer
i think most companies understand it takes awhile for you to understand the codebase, it will take you time to understand and be valuable without breaking it. but also if it takes that long, for new peopel to get on boarded unless that fintech has a absurd amount of money they are doomed XD
As a programmer who's self taught, has worked in industry and worked in education. I completely agree with you, we have a similar timeline, I started in 2010 professionally but I was a fluke getting recognized from my programming skills by a small local team who wanted me. I can confirm after programming websites for 15 years that there's a lot of false truths getting sold to beginners. Self taught is not easy, in fact a lot of the things I excel at now it too me 5 years on and off to really get a grip on. This is a scary field with a lot of potential for growth but if you're just a normal human it's not gonna be a walk in the park. That's why I like your honest no hype approach. I taught at a boot camp for 3 years, but I never sold my students on things they couldn't grasp/achieve without an intense drive. I'm glad somebody in a public forum is sharing the same sentiment. Programming is an amazing field to get into but not an easy one, the information is also just as accessible, but can you really learn it to get job in a year? Just like you said maybe, but the majority of people have lives and want to learn at their own pace will need to self regulate and look for sources of information that don't BS them. Also I started with Rails and they wanted me to work in Django which I ended up teaching later on. So I'm the scripting language sage of my friends at this point haha.
I remember when I first started learning, a lot of courses and tutorials I found suggested contributing to open source projects. I thought it was crazy. I ended up contributing a HTML quirk I learned from CSS tricks to the Bootstrap 4 docs. I think it's much more useful to create something new, rather than contribute to an existing massive open source project. The risk vs reward simply isn't there unless you already know what you're doing.
So true. You have to recreate the project, I mean rewriting the code while looking at the final product to really understand what is happening, I've tried that. No body, no body, has time for that.
I remember when I first tried to learn C (I’m still really bad but I could hack something together with enough time) I was like “Yeah I can C, let’s look at the Linux kernel.” Needless to say I left very quickly lol.
@@realchrishawkes Yup, most of the RUclipsrs, even the recognized "good" ones, are not actually that good. They are mostly self-taught, not trained and make mistakes quite often. Also, IMHO, they are usually lousy teachers. I'm not pointing my finger at anyone in particular, just my observation, in general, that's all.
ive only made one open source contribution and it was for a bug that was breaking my project. that gave me a reason to trace through the source code and figure out what was going on. luckily it was a simple one line fix and the maintainer accepted my PR. was cool to help out. but ya, just going in with the mindset of contributing from the start is basically impossible unless u actually need to fix something uve encountered or u have an intimate understanding of the project already.
Functional components have been around for years now, yet the official docs haven't been updated. Some people claim that's because there's so few people actually working on React, as alluded to in your video. Quite amazing really when you consider Meta has around $100bn in cash.
And even if you do somehow understand a non-trivial opensource project, much of the time the low-hanging fruit was already picked -- the easier problems were already solved and the easier features were already implemented. So to really contribute anything, you would likely need a grad school level understanding of mathematics and computer science to even be remotely qualified to even make a suggestion as to how they could improve the existing algorithms or solve a problem they couldn't solve yet. So contributing to open source while you're still relatively new and learning is mostly impossible. But just because you most likely won't contribute, doesn't mean these non-trivial opensource projects are of no use to your learning -- reading the code, examining the architecture, naming, and algorithms, understanding the thought, planning, and decisions that went into it is very helpful for your growth.
It's the 80/20 rule or pareto principle or whatever you want to call it. The majority of the contributions come from just a few people the same way that the top 5 richest people have as much money as the bottom 3 billion or whatever the stat is
I do agree, it's impossible for these large scale super essential projects, but you can still contribute to something smaller or at least poke around the code just to try and comprehend how it all fits together. It's great to get inspired or just learn how others do things, although grasping React codebase as a junior is probably impossible. One other thing I don't like about this push for juniors to contribute is that it leads to bunch of low quality PRs. I've seen it during events like Hacktoberfest where repos would get bombed with pointless PRs that just create noise and mess and waste maintainer's time in the end. It's good to encourage people to contribute to open source to keep it healthy, but it cannot just be done by saying "yeah, just go and contribute to open source, it's easy". But then again, people also should have some kind of self awareness and control and not just go and randomly try to contribute pointless stuff and waste everyones time. I don't know, it's complicated.
This wasn't my experience at all. Lamenting that these codebases are simply too large for mere humans to understand misses the point entirely. As Dijkstra said, "The art of programming is the art of organizing complexity". You do not need to understand an entire well-organized codebase to meaningfully contribute to it. It is possible for the average programmer to see a bug in an open source project, read and understand the directly relevant sections of the codebase, and submit a patch. I have done this and I have seen it done by many others. For example, consider Linux. No one, in the entire world, has a complete, off the top of their head understanding of all kernel internals. It is simply too much information. Yet it remains well-maintained, and new developers come on every day. These developers choose a specific section to focus on. Ext4 support for the linux kernel was written by experts on file systems, and I'd bet money that they would struggle to explain the intricacies of the process scheduler. To me, contributing to open source does not mean "over the weekend, I think I'm going to add server-side rendering to react". It means anything from "my blog engine has issues if I don't add dates to my posts. I can fix that" to "oops, looks like a typo in the readme, I'll just submit a quick patch", to even "I will submit a bug report for this issue I found". It bothered me when you highlighted that the majority of contributors don't have large amounts of code committed to projects, as if this was a failing. A good community projects benefits from both developers who dedicate serious time to established projects, as well as developers who just submit tiny PRs for issues. I would argue that you *are* a contributor to flask. Sure, it was a tiny commit, maybe it was even just docs, but your work will benefit countless people. Complaining about the distribution of work of the developers feels weak when the project is in fact well-maintained. The ubiquity of open source throughout the modern global infrastructure exists as a testament to the thousands who did what you plainly call impossible. I think the complaint "these projects are so large, it's difficult to make a meaningful impact" is a reasonable one, but it's flaw is that it undersells the importance of small changes and support. It is absolutely okay to tell developers that if they want to create a project from the ground up, and exercise that type of control, that they should make their own project. I would agree! But I don't think it's reasonable or fair to say that this is somehow a failing of open source. I firmly believe that there are open source projects for each developer that they could benefit by contributing.
Couldn’t agree with this more. This is something that almost everyone who has ever tried to contribute to open source has yet barely anyone talked about it.
Very true ! The right approach to open source contribution is to offer help after identifying bugs or missing feature when actually using the open source project. These make meaningful contributions. Contributing for the sake of contributing, to fill your github timeline with green squares is just silly. I see some guys do that though. They do pull requests to add a missing letter in a word, or missing comma, in the documentation. That's dumb, and it may backfire as an employer would identify you as a cheater.
As a beginner programmer programming extensibility projects inside a big ERP software with hundreds of classes and interfaces with minimal documentation... Thank you.
I am just on the beggining of the 3 month of my internship and my boss is angry because i could not add a feature to this giant CRM project. I explained my prior knowledge to him, and he knows my progress by now. I dont know what to do. Should i tell him to fuck off and leave or what do i do.
Very true. I started contributing to an open source game about a month ago and the only reason I can do this is because one of the main developers is holding my hand, explaining stuff to me and even writing parts of the code that I need to show me how its supposed to be done.
That's why making your own projects works out a lot better for your job prospects. So many people think contributing to the Linux Kernel is some right of passage when in reality, you could make your own hacky version that's much simpler and not for general consumption until it gets support to be refined and improved upon. More choice is better and so is living the best version of your own story that's worth telling instead of changing the story or telling someone else's story.
I was given the same advice after giving an interview, i realised i need to learn so much before i could even understand what and where to contribute to.
oh man. Carlton and Vincent are always encouraging contributions for Django haha even for people who are new. it's a dream of mind to contribute like it is for most.
Have to agree, I always hated jumping into someone else's code because of how ridiculously complex things can get, not even mentioning open source projects. Still I find it very rewarding, kinda when Godot came out I started digging into the code and it was fairly easy to understand (despite being written in c++) mostly for my own personal use, getting PRs merged was just a bonus. Some projects are super difficult to get into, if it's some obscure language you can barely read or if it's some sophisticated Scala code with Cats library and a bunch of implicits everywhere, still managing to add a few features despite all that complexity is nice.
Thanks Chris. I have spent 2 years now learning programming and I love and enjoy doing it. I have spent hours and days to solve some DS and AL questions without looking for online solutions. I think figuring out solutions fo problems without looking at provided solutions is becoming a habit for me. Also, I love trying to build things from scratch without using frameworks though I get faustrated, it's a normal thing. As an experience developer, do you think still continuing in this path is worth it at 19 rather than jumping to frameworks? Maybe I can switch to using frameworks later when am really good at the naked language.
So very very true. I just experienced this because I joined a small dev team and release is in like a month. So everything is almost done, and looking at my ticket and trying to figure out how everything works so I can contribute basically seems impossible.
Yeah a lot of open source is mostly just like an "unofficial team with the occasional guest". Actually it's probably more accurate to say it's "an unofficial team, who fixes bugs the guests find." Lots of big packages are like this. Even when they're sponsored by massive corporations they still usually only have a few key members. Hell even bitcoin. Look at their contributers. Top 10 or so people basically hold the vast majority of commits, and you quickly drop off to people with low double digit commits or people who haven't touched the codebase in years. Not really feasible for someone, ESPECIALLY A NOOB, to become an "active contributor" to any of these projects. Sure, some do, but it's the norm not to.
Most of the contributions I have made that actually got merged were either for documentation fixes or for small enhancements to the extensions of these larger libraries / frameworks. It's never a good idea to go looking for this stuff. Real world scenarios will make you decide if it's a good idea to make a contribution
I think to the falling out over Actix Web: basically somebody removed a bunch of unsafe rust, maintainer explained that this was all internal stuff that devs using it shouldn't have to mess with in the first place and was a performance boost (for context, actix Web is one of the fastest out there), ultimately didn't merge the PR. However, maintainer chose to have this convo in the most abrasive way possible and subsequently vacated the open source community. But *as it turns out* the maintainer was just burnt the fuck out. Even if pulls aren't merged, it can be an irritating ordeal for everyone and that free labour can ultimately backfire. This all reminds me I badly need to start putting stuff on my github again, but there's a reason I do so sparingly and with projects I genuinely care about.
Yeah, I used to think I was supposed to be able to jump right in, this is why we have so many bug reports, but nobody knows how to actually fix it in source. Mostly, because they don't have the time and training.
I think that is the reality of open source projects, most of the people contribute to marginal things, and the core is dictate by a handful of people ... today, people add a new line to a open-source project documentation and put it on their resume ...
Nowadays, because I have seen more high-end codebases, I start producing right away. Takes me around two weeks to be 100%. Of course, assuming the code base is exactly what I'm expecting
Nobody got time for that. If you do, you'll only be involved in 1 or 2 projects. Definitely hard to do with a full time job and or life outside of code.
Well! That applies to everything in life. Nothing is evenly distributed. There will always be a tiny group of people who have contributed a whole lot to almost any field. Pareto principle applies to almost every scenario in life!
I guess I would be in the minority here. Sure you can’t just “jump in” to any code base and contribute meaningfully (outside of a one line bug fix). But if you really want to contribute and don’t have good documentation and/or institutional knowledge to lean on then the strategy is first to learn all the tooling around the project, frameworks, compilers, OS, etc. And then I like to work my way from points of contact, command lines using the projects, entry points, etc. It’s exhausting, expensive, and tedious but it’s all you have sometimes. I’ve inherited quite a few 10 - 15 year old applications written by contractors who are gone or employees that have retired.
Can confirm, you will burn out. In my case, I don't sleep until I have a solution / plan for a technical issue. Baring chronic fatigue, or blackout drunk. And that is not sustainable. And not employable if you're unable to maintain an 8 to 5 business casual schedule. While giving up half your weekends for conversions and on call phone trees. Never-mind that 8 to 5 is the absolute worse time to travel / drive to work. It's definitely hard to jump into an existing code base. Just the naming conventions, on some languages that keep non-reserved words to 8 characters with mixed case, and other notation trends. Many of which may have little to do with a meaningful name. It's purpose and current implementation could be wildly different from it's name. Think short, int, long, double and variable names that no longer match it's definition, due to the evolution of processors and languages over time. And other "." versus "END" for languages like COBOL. And some things have shorthand for common groupings / complexities of things. Which might only be defined in the latest book, or forum on a given language. And quirky things like "on overflow" that can behave differently depending on compiler versions. And may be or may NOT be roughly the same as greater than. I tend to avoid advance language features, because I know someone has to come in behind me and maintain something. But others seem to ONLY do advanced language features. It's still pretty much the wild wild west and your programming language tomorrow is not the same language you're coding today. JAVA handled that by deprecating language features. To the point that my JAVA game programming book wont even compile on versions since the millennium. Ever see a current job ad for J++?
actually what needed is someone who knows these on a project should put up some tutorial on basic sturctrues and ins and outs of project, otherwise it is nearly impossible to get into any project... eg: Niccolo vi, kde project
I approach contributing as some sort of side quests. For example, lets say I use a Toast library for mobile dev and find a bug in it or something that does not work like it should. Here's a side quest for me. I could go on and try to fix it or continue with my life. Either choice are good. I just need to make sure that it stays as a side quest, and if its too hard for me well I'll just open an Issue and leave the side quest for someone else :)
Goodday Sir, am working on developing my css am taking one of your courses. My question is, when do I learn a css preprocessor like sass less. After bootstrap or after JavaScript
Contributions are not limited to only code. They can be a variety of things, everything from docs, bug fixing, feedback, ideas and proposals. The whole point of having core contributors is they can determine the quality of those contributions and whether they fit the direction. On top of this, the React repository is a monorepo. It contains multiple packages within its project, not limited to the core library itself. Contributions happens across the entire repo. Graphs and commit count is not an indicator of anything, especially considering that this is people who are working on it full time, and have done so for years, since the early days of React. The core developers of React doesn't have intimate knowledge of every single feature and code path of React. They know a few areas really well, and others at a high level, which anyone can learn by simply reading the docs. And that's enough. It's not realistic that you have to keep all this in your head, whether you write open source or work for a company. To anyone who are new to either programming, or looking to start contributing to open source projects; don't listen to any of the advice presented in this video. Just start small, contribute to the docs, get to know the project and its people, push yourself more and more. You don't need to know every detail of a project to start contributing. Don't let people tell you what you can and can't do because of your supposed experience. Dan Abramov and Andrew Clark are great examples of outside people who contributed to React and got hired to work on it full-time. Their influence has reached the wider audience because of his active pursuit of fostering a community. That doesn't mean you should only contribute to get a job, but it's still a path that many take to work on open source full time. Starting from nothing.
Are people seriously telling juniors to go contribute to open source projects? Like you said, they have no idea on the architectural level of what is going on nor do they know the actual product. Even if they did learn those two things you still have to solve an actual issue that is requested. That is way too much to demand for a junior.
Literally every programming tutorial channel (with some obvious exceptions ;) ) has one video that describes how to get good at programming and on that list will be "contribute to an open source project". So the idea is definitely out there.
@@realchrishawkes Exactly - even as a relatively seasoned developer (or perhaps because), I look at these projects and realize there will be a huge investment in time in just getting up to speed so that I could contribute. I recently took on a new staff member who is relatively junior, and he is working hard to make contributions to our project. But it is taking him a few months of full time effort to understand how things hang together in the code base. So there are a lot of false starts.
This is true especially for large projects. There is also a culture of anti-documentation in software development that is toxic. Their logic is that documentation isn't good because it'll need to be maintained when the code changes, so they just write nothing, no comments, no diagrams, etc. That thinking is stupid. There is always a way to document without over explaining things where you can easily update it later and it will save hundreds of hours of people banging their heads against the wall if someone just wrote a sentence explaining one quirky thing. It even helps out the most experienced people on the project because people forget things very easily.
I've just seen his level of genius, I don't have that same degree of comprehension. Maybe if I tried real hard, I don't see myself naturally being that good.
Everything I've seen, heard, read and experienced tells me that being a programmer is a sad way to spend your professional life. From the hassle of getting a job to the politics of the office, managerial fads and community/program tribalism, it all just sounds like endless misery.
@@illegalsmirf Well, I would say that the most fun thing is that you are learning and at the same time creating something with your own hands. It's like a sandbox or Lego. It's true that when you have to experience failure, it's not as fun anymore, but that's part of the learning.
If you can write well I don't know what project wouldn't take extra help with documentation. No, it's not code, but oh lordy will you understand whatever functionality you document...
This is why I will never stop listening to you Chris. You are so original and the things you talk about are so true but no one talks about this too. I had a beginner programmer I was mentoring who wanted to "contribute" to the Godot game engine source code, just after 3 weeks of learning python. When I laughed at him so hard, he changed his mind. I did not even know what else to tell him.
You have no business mentoring anyone if you're just going to "laugh so hard" at them. Obviously a beginner isn't going to grasp the scope of something like a game engine. You don't laugh at them like a pompous jackass. And don't come back and make excuses for your behaviour either, it was wrong.
@@intoTheEther1 You missed my point and focused on an attack when you know nothing about me. I have no time for nobodies on the internet. I would not even meet people like you in real life, so jug on!
"You wanna be a programmer, go contribute to an open source project..." i actually nevery heard that or that anybody told that you need to contribute to anything.
React contributors are only 0.015% of all users. If we take top 6-7 contributors that is 0.00005% of all users. For a new developer to contribute something meaningful is beyond astronomically low chance. Also once I worked in a company with big established codebase and it was really difficult to grasp what, where, how code worked. I got very little training or explanations and it was rather unpleasant experience to say the least.
Some of us like it, though. Some continue to do it even after they have enough money to never have to work again. It isn’t for everyone is what I hear you saying, and I agree.
Are you guys all bots? Every video this guy makes he’s just shitting on some fictional problem that doesn’t exist and everyone is kissing his ass in the comments which he obviously hearts all of your comments. Maybe give some useful information about how people should get started rather then spend all your time telling people how not to get started
@@Meleeman011 Start waking up early, eat healthy, hit the gym, get yourself a hobby you love (especially one with a group course), read books, watch movies, meet with strangers. One day at a time. No need to rush. Go slowly but consistently.
@@berakoc8556 having a hobby makes a world of difference, that I can attest to. I've currently been self learning for a year now and preparing leet code recently, my efficiency increases and I think better after I go out or play an hour of table tennis.
@@Meleeman011 Infinte amount will not be enough because you will also need to make her a physical body and for that you will probably need to get acquainted with 3D printing and CNC machining, Also you will need to buy some electronics components for controlling some hardware stuff, And only now you can move to the coding part to link up / operate the whole stuff in a comprehensive manner and be done. And you will have you very own GF with your very own design which is pretty cool haha
These people are everywhere. They even tell these beginners to then put their open source contributions onto their resume... as a way to increase their odds of getting their first job... LOL
@@tjalferes I mean if they actually contributed, putting it on the resume is nice, but eh... Imagine doing that after you pushed a PR titled "fix typo" xd
@@realchrishawkes great observations in this video. A lot of people get in the impostor syndrome mindset without understanding that 90% of the work in any project is done by something like the square root of the total amount of contributors. Not to mention that often its even less contributors than that
It's laughable that new programmers are encouraged to contribute to long running existing projects like this. It's almost embarrassing to think that some people would try this. The whole "code education complex" is so detached from the reality of how things actually work, it's encouraging people to go in & potentially destroy projects that half the web relies on now.
Yeah the cargo culting needs to stop
What a ridiculous statement. Name one project that was destroyed by this. Just one. Contributions are not automatically merged and released to thousands of people and companies. They are rigorously reviewed by the maintainers, and even then, there's often a transitional period for larger features-even for the code contributed by core developers.
I don't agree with the destruction part but the first part is really true. Those internals are just like the video says, you're most likely not prepared.
oh you want a frontent job? well today you are going to do a python algorithm test, it's going to be 5 hours long
@@joshk2181 even worse, here's a logic problem you need to solve on a whiteboard with cryptic hints based on analogy. You should know it right?
The only time I've ever been able to contribute to open source is when
1. I already knew the language used the project.
2. I was using some esoteric software a bunch of people don't use.
3. I found a bug.
4. I could reproduce the bug on my local machine after I downloaded the code.
That's why I was thinking "what the fuck are these assholes talking about when they say I should contribute to open source?" when I started developing.
i tried to contribute to a php framework similar to express. i ended up rewriting it myself from scratch, left an issue on on it, and the dev never got around to it. my functional solution worked better and was cleaner than their OOP code anyway. but composer and the psr-4 autoloading is probably the reason why php people love classbased php even tho functions are just as performant if not more so.
It's my opinion that the whole idea around "open source" just doesn't work in the real world. Yes, technically, everyone can "jump in" and contribute, but in practicality it's impossible. It's just too many lines of code, too many systems running in parallel for you to ever be able to actually contribute to it in a meaningful way. So I absolutely agree with this video.
So to all the beginners in programming out there: Don't waste your time trying to get a PR accepted on any big open source project. Have fun building your own stuff instead. At least there you can get some actual value for your time.
yeah or contribute to one of your friends project that is either on the same level as you or is willing to hold your hand through the process. IMO you should only contribute if you have a vested interest in the actual projects outcome and not because you think itll elevate your coder "cred."
So true, my first gig was solo in a start up so I wrote literally everything and felt more confident, now I'm in a team re-writing an old monolith and finding it very difficult to wrap my head around everything, and by the time I get more comfortable the team will move onto the next microservice!!
These kinds of discussions would be great for a podcast Chris! I love your no bs approach
Hit the nail in the head. I'm at a fintech startup for 3 months now and the codebase is so convoluted I can barely contribute or add any value to the company. This being the standard nowadays makes it hard to work somewhere new as a developer
But thats not a big problem for you or is it?
Like they are going to tell bye bye just for that?
i think most companies understand it takes awhile for you to understand the codebase, it will take you time to understand and be valuable without breaking it. but also if it takes that long, for new peopel to get on boarded unless that fintech has a absurd amount of money they are doomed XD
It’s been this way for a long time
@@Soulis98 that happens All the time
@@ChrisAthanas It looks kinda scary for new dev tbh.
"If it's not your code base, it's spaghetti." -- me.
Or my own 6 months later.
As a programmer who's self taught, has worked in industry and worked in education. I completely agree with you, we have a similar timeline, I started in 2010 professionally but I was a fluke getting recognized from my programming skills by a small local team who wanted me.
I can confirm after programming websites for 15 years that there's a lot of false truths getting sold to beginners. Self taught is not easy, in fact a lot of the things I excel at now it too me 5 years on and off to really get a grip on.
This is a scary field with a lot of potential for growth but if you're just a normal human it's not gonna be a walk in the park. That's why I like your honest no hype approach.
I taught at a boot camp for 3 years, but I never sold my students on things they couldn't grasp/achieve without an intense drive. I'm glad somebody in a public forum is sharing the same sentiment.
Programming is an amazing field to get into but not an easy one, the information is also just as accessible, but can you really learn it to get job in a year? Just like you said maybe, but the majority of people have lives and want to learn at their own pace will need to self regulate and look for sources of information that don't BS them.
Also I started with Rails and they wanted me to work in Django which I ended up teaching later on. So I'm the scripting language sage of my friends at this point haha.
I remember when I first started learning, a lot of courses and tutorials I found suggested contributing to open source projects. I thought it was crazy. I ended up contributing a HTML quirk I learned from CSS tricks to the Bootstrap 4 docs. I think it's much more useful to create something new, rather than contribute to an existing massive open source project. The risk vs reward simply isn't there unless you already know what you're doing.
Indeed. Better start something new.
I 100% agree. We are always "experts" in training, no matter your experience.
So true. You have to recreate the project, I mean rewriting the code while looking at the final product to really understand what is happening, I've tried that. No body, no body, has time for that.
I remember when I first tried to learn C (I’m still really bad but I could hack something together with enough time) I was like “Yeah I can C, let’s look at the Linux kernel.” Needless to say I left very quickly lol.
🤣🤣🤣🤣 Same
I feel that.
It's SO much more than just the language. You can either spread the butter, sculpt the Statue of Liberty or stab someone with the same tool
Agree. Trying to blindly jump in the middle of a codebase can be impossible to effectively contribute.
This is a good topic. I've never heard anyone say this and I agree.
It's real life. The truth, most big RUclipsr programmers aren't in the real game.
@@realchrishawkes Yup, most of the RUclipsrs, even the recognized "good" ones, are not actually that good. They are mostly self-taught, not trained and make mistakes quite often. Also, IMHO, they are usually lousy teachers. I'm not pointing my finger at anyone in particular, just my observation, in general, that's all.
Agreed! If you don't understand the code base, YOU WILL GET LOST!
It's all about context.
ive only made one open source contribution and it was for a bug that was breaking my project. that gave me a reason to trace through the source code and figure out what was going on. luckily it was a simple one line fix and the maintainer accepted my PR. was cool to help out. but ya, just going in with the mindset of contributing from the start is basically impossible unless u actually need to fix something uve encountered or u have an intimate understanding of the project already.
Functional components have been around for years now, yet the official docs haven't been updated. Some people claim that's because there's so few people actually working on React, as alluded to in your video. Quite amazing really when you consider Meta has around $100bn in cash.
And even if you do somehow understand a non-trivial opensource project, much of the time the low-hanging fruit was already picked -- the easier problems were already solved and the easier features were already implemented. So to really contribute anything, you would likely need a grad school level understanding of mathematics and computer science to even be remotely qualified to even make a suggestion as to how they could improve the existing algorithms or solve a problem they couldn't solve yet. So contributing to open source while you're still relatively new and learning is mostly impossible. But just because you most likely won't contribute, doesn't mean these non-trivial opensource projects are of no use to your learning -- reading the code, examining the architecture, naming, and algorithms, understanding the thought, planning, and decisions that went into it is very helpful for your growth.
It's the 80/20 rule or pareto principle or whatever you want to call it. The majority of the contributions come from just a few people the same way that the top 5 richest people have as much money as the bottom 3 billion or whatever the stat is
I do agree, it's impossible for these large scale super essential projects, but you can still contribute to something smaller or at least poke around the code just to try and comprehend how it all fits together. It's great to get inspired or just learn how others do things, although grasping React codebase as a junior is probably impossible.
One other thing I don't like about this push for juniors to contribute is that it leads to bunch of low quality PRs. I've seen it during events like Hacktoberfest where repos would get bombed with pointless PRs that just create noise and mess and waste maintainer's time in the end. It's good to encourage people to contribute to open source to keep it healthy, but it cannot just be done by saying "yeah, just go and contribute to open source, it's easy".
But then again, people also should have some kind of self awareness and control and not just go and randomly try to contribute pointless stuff and waste everyones time. I don't know, it's complicated.
This wasn't my experience at all. Lamenting that these codebases are simply too large for mere humans to understand misses the point entirely. As Dijkstra said, "The art of programming is the art of organizing complexity". You do not need to understand an entire well-organized codebase to meaningfully contribute to it. It is possible for the average programmer to see a bug in an open source project, read and understand the directly relevant sections of the codebase, and submit a patch. I have done this and I have seen it done by many others.
For example, consider Linux. No one, in the entire world, has a complete, off the top of their head understanding of all kernel internals. It is simply too much information. Yet it remains well-maintained, and new developers come on every day. These developers choose a specific section to focus on. Ext4 support for the linux kernel was written by experts on file systems, and I'd bet money that they would struggle to explain the intricacies of the process scheduler.
To me, contributing to open source does not mean "over the weekend, I think I'm going to add server-side rendering to react". It means anything from "my blog engine has issues if I don't add dates to my posts. I can fix that" to "oops, looks like a typo in the readme, I'll just submit a quick patch", to even "I will submit a bug report for this issue I found". It bothered me when you highlighted that the majority of contributors don't have large amounts of code committed to projects, as if this was a failing. A good community projects benefits from both developers who dedicate serious time to established projects, as well as developers who just submit tiny PRs for issues. I would argue that you *are* a contributor to flask. Sure, it was a tiny commit, maybe it was even just docs, but your work will benefit countless people. Complaining about the distribution of work of the developers feels weak when the project is in fact well-maintained.
The ubiquity of open source throughout the modern global infrastructure exists as a testament to the thousands who did what you plainly call impossible. I think the complaint "these projects are so large, it's difficult to make a meaningful impact" is a reasonable one, but it's flaw is that it undersells the importance of small changes and support. It is absolutely okay to tell developers that if they want to create a project from the ground up, and exercise that type of control, that they should make their own project. I would agree! But I don't think it's reasonable or fair to say that this is somehow a failing of open source. I firmly believe that there are open source projects for each developer that they could benefit by contributing.
Couldn’t agree with this more. This is something that almost everyone who has ever tried to contribute to open source has yet barely anyone talked about it.
Very true ! The right approach to open source contribution is to offer help after identifying bugs or missing feature when actually using the open source project. These make meaningful contributions. Contributing for the sake of contributing, to fill your github timeline with green squares is just silly.
I see some guys do that though. They do pull requests to add a missing letter in a word, or missing comma, in the documentation. That's dumb, and it may backfire as an employer would identify you as a cheater.
As a beginner programmer programming extensibility projects inside a big ERP software with hundreds of classes and interfaces with minimal documentation... Thank you.
I am just on the beggining of the 3 month of my internship and my boss is angry because i could not add a feature to this giant CRM project. I explained my prior knowledge to him, and he knows my progress by now. I dont know what to do. Should i tell him to fuck off and leave or what do i do.
This is really just a consequence of code being harder to read than to write, which is the opposite of normal textual writing.
True.
Very true. I started contributing to an open source game about a month ago and the only reason I can do this is because one of the main developers is holding my hand, explaining stuff to me and even writing parts of the code that I need to show me how its supposed to be done.
That's why making your own projects works out a lot better for your job prospects. So many people think contributing to the Linux Kernel is some right of passage when in reality, you could make your own hacky version that's much simpler and not for general consumption until it gets support to be refined and improved upon. More choice is better and so is living the best version of your own story that's worth telling instead of changing the story or telling someone else's story.
This Is the content I subbed for
I was given the same advice after giving an interview, i realised i need to learn so much before i could even understand what and where to contribute to.
Thank you for the advice Chris, I am very new to programming would love to have you as a mentor!
this is so true, everyone be like, go contribute to a project, but they never talk about this.
oh man. Carlton and Vincent are always encouraging contributions for Django haha even for people who are new. it's a dream of mind to contribute like it is for most.
Have to agree, I always hated jumping into someone else's code because of how ridiculously complex things can get, not even mentioning open source projects. Still I find it very rewarding, kinda when Godot came out I started digging into the code and it was fairly easy to understand (despite being written in c++) mostly for my own personal use, getting PRs merged was just a bonus. Some projects are super difficult to get into, if it's some obscure language you can barely read or if it's some sophisticated Scala code with Cats library and a bunch of implicits everywhere, still managing to add a few features despite all that complexity is nice.
Thanks Chris. I have spent 2 years now learning programming and I love and enjoy doing it. I have spent hours and days to solve some DS and AL questions without looking for online solutions. I think figuring out solutions fo problems without looking at provided solutions is becoming a habit for me. Also, I love trying to build things from scratch without using frameworks though I get faustrated, it's a normal thing. As an experience developer, do you think still continuing in this path is worth it at 19 rather than jumping to frameworks?
Maybe I can switch to using frameworks later when am really good at the naked language.
You'll learn more that way.
Denial of service attack simply from the sheer volume of pull requests is possible! xD
THank you for vocalizing the bug that has been circling in my brain... like scratching an latent itch
So very very true. I just experienced this because I joined a small dev team and release is in like a month. So everything is almost done, and looking at my ticket and trying to figure out how everything works so I can contribute basically seems impossible.
Yeah a lot of open source is mostly just like an "unofficial team with the occasional guest". Actually it's probably more accurate to say it's "an unofficial team, who fixes bugs the guests find."
Lots of big packages are like this. Even when they're sponsored by massive corporations they still usually only have a few key members. Hell even bitcoin. Look at their contributers. Top 10 or so people basically hold the vast majority of commits, and you quickly drop off to people with low double digit commits or people who haven't touched the codebase in years.
Not really feasible for someone, ESPECIALLY A NOOB, to become an "active contributor" to any of these projects. Sure, some do, but it's the norm not to.
Yep
Most of the contributions I have made that actually got merged were either for documentation fixes or for small enhancements to the extensions of these larger libraries / frameworks. It's never a good idea to go looking for this stuff. Real world scenarios will make you decide if it's a good idea to make a contribution
I think to the falling out over Actix Web: basically somebody removed a bunch of unsafe rust, maintainer explained that this was all internal stuff that devs using it shouldn't have to mess with in the first place and was a performance boost (for context, actix Web is one of the fastest out there), ultimately didn't merge the PR.
However, maintainer chose to have this convo in the most abrasive way possible and subsequently vacated the open source community.
But *as it turns out* the maintainer was just burnt the fuck out. Even if pulls aren't merged, it can be an irritating ordeal for everyone and that free labour can ultimately backfire.
This all reminds me I badly need to start putting stuff on my github again, but there's a reason I do so sparingly and with projects I genuinely care about.
Thank you been wondering about this for awhile
Yeah, I used to think I was supposed to be able to jump right in, this is why we have so many bug reports, but nobody knows how to actually fix it in source. Mostly, because they don't have the time and training.
good reality-check
I think that is the reality of open source projects, most of the people contribute to marginal things, and the core is dictate by a handful of people ... today, people add a new line to a open-source project documentation and put it on their resume ...
Nowadays, because I have seen more high-end codebases, I start producing right away. Takes me around two weeks to be 100%. Of course, assuming the code base is exactly what I'm expecting
I'm usually somewhat similar. Maybe I'm just in a funk.
This is the thoughts I really needed to hear. 😊 I thought I don’t know how to code cos I can’t jump into open source!!
Nobody got time for that. If you do, you'll only be involved in 1 or 2 projects. Definitely hard to do with a full time job and or life outside of code.
huh? of course you can't dumbo, thats like doing brain surgery without study human anatomy lol
Arthur Schopenhauer's lectures on contribution to open source.😂😂
Well! That applies to everything in life. Nothing is evenly distributed. There will always be a tiny group of people who have contributed a whole lot to almost any field. Pareto principle applies to almost every scenario in life!
Probably right.
I guess I would be in the minority here. Sure you can’t just “jump in” to any code base and contribute meaningfully (outside of a one line bug fix). But if you really want to contribute and don’t have good documentation and/or institutional knowledge to lean on then the strategy is first to learn all the tooling around the project, frameworks, compilers, OS, etc. And then I like to work my way from points of contact, command lines using the projects, entry points, etc. It’s exhausting, expensive, and tedious but it’s all you have sometimes.
I’ve inherited quite a few 10 - 15 year old applications written by contractors who are gone or employees that have retired.
"It’s exhausting, expensive, and tedious but it’s all you have sometimes." well said. All of it. Especially that.
first time hearing you saying some sense holy
The most work being done by only a few is not surprising...the pareto principle.
Can confirm, you will burn out. In my case, I don't sleep until I have a solution / plan for a technical issue. Baring chronic fatigue, or blackout drunk. And that is not sustainable. And not employable if you're unable to maintain an 8 to 5 business casual schedule. While giving up half your weekends for conversions and on call phone trees. Never-mind that 8 to 5 is the absolute worse time to travel / drive to work.
It's definitely hard to jump into an existing code base. Just the naming conventions, on some languages that keep non-reserved words to 8 characters with mixed case, and other notation trends. Many of which may have little to do with a meaningful name. It's purpose and current implementation could be wildly different from it's name. Think short, int, long, double and variable names that no longer match it's definition, due to the evolution of processors and languages over time. And other "." versus "END" for languages like COBOL. And some things have shorthand for common groupings / complexities of things. Which might only be defined in the latest book, or forum on a given language. And quirky things like "on overflow" that can behave differently depending on compiler versions. And may be or may NOT be roughly the same as greater than. I tend to avoid advance language features, because I know someone has to come in behind me and maintain something. But others seem to ONLY do advanced language features. It's still pretty much the wild wild west and your programming language tomorrow is not the same language you're coding today. JAVA handled that by deprecating language features. To the point that my JAVA game programming book wont even compile on versions since the millennium. Ever see a current job ad for J++?
interesting topic, i see myself while u were explaning 👍
actually what needed is someone who knows these on a project should put up some tutorial on basic sturctrues and ins and outs of project,
otherwise it is nearly impossible to get into any project...
eg: Niccolo vi, kde project
I approach contributing as some sort of side quests.
For example, lets say I use a Toast library for mobile dev and find a bug in it or something that does not work like it should. Here's a side quest for me. I could go on and try to fix it or continue with my life. Either choice are good. I just need to make sure that it stays as a side quest, and if its too hard for me well I'll just open an Issue and leave the side quest for someone else :)
okay? and how that benefit you? a waste of time
@@pepi8433 bruh its a challenge... learn new things. Work with code thats not mine nor my coworkers code
Goodday Sir, am working on developing my css am taking one of your courses. My question is, when do I learn a css preprocessor like sass less. After bootstrap or after JavaScript
Contributions are not limited to only code. They can be a variety of things, everything from docs, bug fixing, feedback, ideas and proposals. The whole point of having core contributors is they can determine the quality of those contributions and whether they fit the direction.
On top of this, the React repository is a monorepo. It contains multiple packages within its project, not limited to the core library itself. Contributions happens across the entire repo. Graphs and commit count is not an indicator of anything, especially considering that this is people who are working on it full time, and have done so for years, since the early days of React.
The core developers of React doesn't have intimate knowledge of every single feature and code path of React. They know a few areas really well, and others at a high level, which anyone can learn by simply reading the docs. And that's enough. It's not realistic that you have to keep all this in your head, whether you write open source or work for a company.
To anyone who are new to either programming, or looking to start contributing to open source projects; don't listen to any of the advice presented in this video. Just start small, contribute to the docs, get to know the project and its people, push yourself more and more. You don't need to know every detail of a project to start contributing. Don't let people tell you what you can and can't do because of your supposed experience.
Dan Abramov and Andrew Clark are great examples of outside people who contributed to React and got hired to work on it full-time. Their influence has reached the wider audience because of his active pursuit of fostering a community.
That doesn't mean you should only contribute to get a job, but it's still a path that many take to work on open source full time. Starting from nothing.
Same here. I know the concepts but I cannot connect the dots. It's frustrating.
Are people seriously telling juniors to go contribute to open source projects?
Like you said, they have no idea on the architectural level of what is going on nor do they know the actual product.
Even if they did learn those two things you still have to solve an actual issue that is requested. That is way too much to demand for a junior.
Literally every programming tutorial channel (with some obvious exceptions ;) ) has one video that describes how to get good at programming and on that list will be "contribute to an open source project". So the idea is definitely out there.
Most of them being out of the game and contributing to nothing themselves.
@@realchrishawkes Exactly - even as a relatively seasoned developer (or perhaps because), I look at these projects and realize there will be a huge investment in time in just getting up to speed so that I could contribute.
I recently took on a new staff member who is relatively junior, and he is working hard to make contributions to our project. But it is taking him a few months of full time effort to understand how things hang together in the code base. So there are a lot of false starts.
I've been coding and just been until Hello World apps for 12 yrs now. :P
this dude speaks the truth
This is true especially for large projects. There is also a culture of anti-documentation in software development that is toxic. Their logic is that documentation isn't good because it'll need to be maintained when the code changes, so they just write nothing, no comments, no diagrams, etc. That thinking is stupid. There is always a way to document without over explaining things where you can easily update it later and it will save hundreds of hours of people banging their heads against the wall if someone just wrote a sentence explaining one quirky thing. It even helps out the most experienced people on the project because people forget things very easily.
no passion i guess is just for money, or peer pressure, cuz their friends, or family did it
good video and well explained
This might be a silly question, but what do you mean by "brains I can't even compete with" ..... what is that guy capable of that is so special?
I've just seen his level of genius, I don't have that same degree of comprehension. Maybe if I tried real hard, I don't see myself naturally being that good.
Everything I've seen, heard, read and experienced tells me that being a programmer is a sad way to spend your professional life. From the hassle of getting a job to the politics of the office, managerial fads and community/program tribalism, it all just sounds like endless misery.
yeah but all of that will end at some point............when you die .
Well, yes, but it's fun
@@alex-lar What's fun about it? Most programmers I meet are quite unhappy people.
@@illegalsmirf Well, I would say that the most fun thing is that you are learning and at the same time creating something with your own hands. It's like a sandbox or Lego. It's true that when you have to experience failure, it's not as fun anymore, but that's part of the learning.
@@alex-lar playing with Lego is fine till you get to your 40s or 50s when it stops being fun and real life gets in the way lol !
If you can write well I don't know what project wouldn't take extra help with documentation. No, it's not code, but oh lordy will you understand whatever functionality you document...
This is why I will never stop listening to you Chris. You are so original and the things you talk about are so true but no one talks about this too. I had a beginner programmer I was mentoring who wanted to "contribute" to the Godot game engine source code, just after 3 weeks of learning python. When I laughed at him so hard, he changed his mind. I did not even know what else to tell him.
You have no business mentoring anyone if you're just going to "laugh so hard" at them. Obviously a beginner isn't going to grasp the scope of something like a game engine. You don't laugh at them like a pompous jackass. And don't come back and make excuses for your behaviour either, it was wrong.
@@intoTheEther1 You missed my point and focused on an attack when you know nothing about me. I have no time for nobodies on the internet. I would not even meet people like you in real life, so jug on!
How are these facts that no one told me if you just told me them?
Till now... :)
Totally agree.
"You wanna be a programmer, go contribute to an open source project..." i actually nevery heard that or that anybody told that you need to contribute to anything.
It's a fairly common line among some YT programmers when greenhorns are trying to get out of tutorial hell, or avoid it proactively.
Spoken mostly by RUclipsrs who are not actual software devs for a company.
@@realchrishawkes ic, be specific next time.
What are your thoughts on outsourcing?
confusing coding with programming???
React contributors are only 0.015% of all users. If we take top 6-7 contributors that is 0.00005% of all users. For a new developer to contribute something meaningful is beyond astronomically low chance. Also once I worked in a company with big established codebase and it was really difficult to grasp what, where, how code worked. I got very little training or explanations and it was rather unpleasant experience to say the least.
My advice after what I went through as zero to developer in 7 years:
If you can - don't become a software engineer.
Damn, that's not a good sign.
Some of us like it, though. Some continue to do it even after they have enough money to never have to work again. It isn’t for everyone is what I hear you saying, and I agree.
Programming Face Everyone Will Tell You: Using Github light theme is a crime punishable by death
Programmers are into petty politics more than writing code, that's why.
Features is not the only thing you can contribute.
- Bugs fixes,
- Tests,
- Docs
These are sometimes easier than new features.
Honest 👍
Nice
Thanks
I had to say this to someone on reddit once. a noob isn't gonna start contributing to open source. Just not gonna happrn
Are you guys all bots? Every video this guy makes he’s just shitting on some fictional problem that doesn’t exist and everyone is kissing his ass in the comments which he obviously hearts all of your comments. Maybe give some useful information about how people should get started rather then spend all your time telling people how not to get started
i have no life outside of code tbh.
@@realchrishawkes how many if statements does it take to write myself a new GF?
@@Meleeman011 Start waking up early, eat healthy, hit the gym, get yourself a hobby you love (especially one with a group course), read books, watch movies, meet with strangers. One day at a time. No need to rush. Go slowly but consistently.
@@berakoc8556 having a hobby makes a world of difference, that I can attest to.
I've currently been self learning for a year now and preparing leet code recently, my efficiency increases and I think better after I go out or play an hour of table tennis.
@@Meleeman011 Infinte amount will not be enough because you will also need to make her a physical body and for that you will probably need to get acquainted with 3D printing and CNC machining, Also you will need to buy some electronics components for controlling some hardware stuff, And only now you can move to the coding part to link up / operate the whole stuff in a comprehensive manner and be done. And you will have you very own GF with your very own design which is pretty cool haha
What this implies is that you're often better of rewriting the application that you're assigned to, rather than trying to improve on it.
waste of time of contributing into a project that is not yours...
I've never seen anyone recommend beginner developers to contribute to big open source projects...
These people are everywhere. They even tell these beginners to then put their open source contributions onto their resume... as a way to increase their odds of getting their first job... LOL
@@tjalferes I mean if they actually contributed, putting it on the resume is nice, but eh... Imagine doing that after you pushed a PR titled "fix typo" xd
They do.
First
second!
@@realchrishawkes great observations in this video. A lot of people get in the impostor syndrome mindset without understanding that 90% of the work in any project is done by something like the square root of the total amount of contributors. Not to mention that often its even less contributors than that