Very relatable article! Personally I would like to join a software company of a substantial size is because of the opportunity to learn from more experienced developers and understand better software development practices.
I know how you feel really well. I think it is a dilemma many developers have :/ Some people love to work in a small team or even alone, but there is currently no great way for them to learn from experienced developers. I hope this to change in the future tho!
I'm a small business programmer. I love solving tough problems with Python and PHP. If you like what you're seeing, you should probably follow me here on dev.to and then checkout my blog.
You may not be able to learn from experienced developers directly if you are working alone, but there are plenty of indirect ways to learn from great developers:
books (Steve McConnell, Martin Fowler, Robert C Martin, Michael Feathers, etc.)
thousands of hours of YouTube videos
online courses
and hundreds of millions (or possibly billions) of lines of code just sitting there in open source projects waiting for you to "git clone" them
I'm not saying this is the easy or preferred way of becoming an experienced developer but it can be done--this is how I leveled up.
Finally, just keep practicing. Review your own code a few days after you wrote it. Our go look at something you wrote 6 months ago and see if you can find a way to improve it.
If you have the time, try to contribute to open source projects. Pick ones from big corps with known high quality standards (Google, Facebook, Square). This is definitely how I learned the most: gtk+, libxml, GWT, Dagger, etc.
Reading code reviews from those projects can be a good first step too (I'd encourage reading all issue and PR comments as they happen in select projects)
Yes I am planning to do so😄. However, I do have this irrational fear that high quality standard repos are too big/complex for me to understand enough without guidance.
Anyway, I do currently have a project that I intend to get on soon, making baby steps towards a better self...
The best projects to pick are the ones you leverage in your projects. And even if you don't understand the code sometimes, reading the review comments is still valuable (chances are you'll also learn about how the code works 😉)
Hi Thomas,
Would you mind elaborating on how you tackle a fresh open source project? I am quite clueless as to where to begin when faced with the repo. Is the process of getting to understand what is going on by simply...reading every single line of code or every single issues from start to finish? Is there a strategy that you employ when starting out with a fresh project?
In most cases, I had started with an issue I had with the project, trying to find my way in the code and understand how things are supposed to work. So starting from an error message I got, or an output file I thought should be generated by was missing, an option that I thought would match my use case but didn't work the way I thought it would, etc. git grep is one of my best friends in those cases (for a statically-typed language, grepping the type's name to navigate to its declaration or use sites; for JS or Python grepping the import paths).
Or if you wonder how one feature works under the hood, go explore that part.
For issues and PRs, look for "good first issues" you could possibly pick up at fixing, and read select PRs that pique your curiosity.
Then watch the project to get notified of every new issue/PR and comment.
That's how I generally do it (I learn by reading, not necessarily practicing), but YMMV 🤷
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Very relatable article! Personally I would like to join a software company of a substantial size is because of the opportunity to learn from more experienced developers and understand better software development practices.
I know how you feel really well. I think it is a dilemma many developers have :/ Some people love to work in a small team or even alone, but there is currently no great way for them to learn from experienced developers. I hope this to change in the future tho!
You may not be able to learn from experienced developers directly if you are working alone, but there are plenty of indirect ways to learn from great developers:
I'm not saying this is the easy or preferred way of becoming an experienced developer but it can be done--this is how I leveled up.
Finally, just keep practicing. Review your own code a few days after you wrote it. Our go look at something you wrote 6 months ago and see if you can find a way to improve it.
If you have the time, try to contribute to open source projects. Pick ones from big corps with known high quality standards (Google, Facebook, Square). This is definitely how I learned the most: gtk+, libxml, GWT, Dagger, etc.
Reading code reviews from those projects can be a good first step too (I'd encourage reading all issue and PR comments as they happen in select projects)
Yes I am planning to do so😄. However, I do have this irrational fear that high quality standard repos are too big/complex for me to understand enough without guidance.
Anyway, I do currently have a project that I intend to get on soon, making baby steps towards a better self...
The best projects to pick are the ones you leverage in your projects. And even if you don't understand the code sometimes, reading the review comments is still valuable (chances are you'll also learn about how the code works 😉)
Hi Thomas,
Would you mind elaborating on how you tackle a fresh open source project? I am quite clueless as to where to begin when faced with the repo. Is the process of getting to understand what is going on by simply...reading every single line of code or every single issues from start to finish? Is there a strategy that you employ when starting out with a fresh project?
In most cases, I had started with an issue I had with the project, trying to find my way in the code and understand how things are supposed to work. So starting from an error message I got, or an output file I thought should be generated by was missing, an option that I thought would match my use case but didn't work the way I thought it would, etc.
git grepis one of my best friends in those cases (for a statically-typed language, grepping the type's name to navigate to its declaration or use sites; for JS or Python grepping the import paths).Or if you wonder how one feature works under the hood, go explore that part.
For issues and PRs, look for "good first issues" you could possibly pick up at fixing, and read select PRs that pique your curiosity.
Then watch the project to get notified of every new issue/PR and comment.
That's how I generally do it (I learn by reading, not necessarily practicing), but YMMV 🤷