21–30 of 32 posts
This doesn't work for all applications, but a good number.
With that said, don't let the passion for fun and interesting projects die! Small, start-to-finish projects are exactly what hobby, side project, and open source is for.
On your own or in small companies, you get requirements and you go build something. Most of your time is spent creating.
In large companies, you have to do a lot of exploration which could involve reading existing code or talking to other employees to figure out what to change. Most of your time will be spent researching and communicating, not purely creating.
This is true with most work. Whether it’s programming or landscape design or what have you, there is a shed load of work to do that no one is really excited about. This is why the whole “do what you love” is dangerous.
From my own experience, I find the best way to scratch this itch is to find a passion project and spend time on that as you can. This has the added advantage of getting you more time with code. You’ll pick up tips and tricks and tools.
Finally, don’t lose your optimism. Many of us work on projects that are fulfilling outside of work for just this reason.
Some tips for your current situation:
1. Accept the slowness and irreducible complexity that comes with large codebases. There is no quick fix. Don’t beat yourself up. Even people who wrote a codebase find it frustrating to come back later and make changes to it.
2. Understand the data model and the core data flows of the codebase from a business point of view. Make diagrams and notes to capture this, but do it for your own reference and not to share it with others.
3. Understand the technical architecture of the project to a sufficient extent that you’re not getting bogged down in technical questions when trying to follow the logic. This is one of the reasons that simple languages like Java or Go are preferred over more complex languages. Understand what flavor of OO or any other paradigm applies in the codebase.
4. Create a fork or branch of the codebase where you can annotate the code and add any documentation. This doesn’t need to be kept in sync with the main code as long as it’s substantially the same.
5. When you’re working on a piece, look up git blame and commit messages to see how that piece came about.
All these steps will yield results, but slowly. My feeling is that there tends be an inflection point when all the various bits of knowledge start to add up. Until then it will be slow going.
Earlier quoted context omitted.
Donate to them 20 gifted hours of your time. I’ll bet whatever passion project you make in those hours they will love and want to fund for real.
Honestly not a bad idea. If I can find something I'm passionate enough about I think I'll do this. I'd be making something in my free time anyway - might as well make it something that could potentially make my time on the clock better. Thank you!
Secondly, and I don't mean to disrespect you in any way, but if you're self-taught, and your prior experience is one man jobs working on small sites then I wouldn't expect the quality of your code to be great. I would be wondering how much time it would take to ensure whatever you build is really readable, documented, fully tested, maintainable, in line with the company's current tech stack, performant and scalable.
The benefits of working at a large company is that they have products that run on massive code bases that are, for the most part, REALLY STABLE. They move slowly, but they also move surely. New code won't be scrappy and volatile. Old code can stagnate, but it's because it hasn't broken in years. All of these things are learning opportunities you can take with you even if you strike out to start/work at a startup.