Search for a command to run...
A Practical Guide for Developers to Efficiently Understand and Contribute to New Projects
Full stack aficionado, passionate about making tech simpler, faster, and enjoyable. Sharing the love with open source and spreading the knowledge ! 🎉🚀🌐📚
No comments yet. Be the first to comment.
Google Auth in Wasp with TypeScript
What is Zed? Zed is a new kid on the block in the IDE business but seems to be causing some people to talk about it. https://twitter.com/adamwathan/status/1648867721944104960?s=20 From the first look, it appears to be focusing on blazing speed (jus...
“Because he's the hero Gotham deserves, but not the one it needs right now." - Jonathan Nolan, The Dark Knight
What is Wasp? Imagine modern monorepos. If you are not using typesafe solutions like tRPC , chances are - you know the pain of synchronizing your types between the backend and front end. More than that - you are probably also aware that creating new ...
If you are new to the programming world, you might have been there - you are finally starting to work on a real world, production project, that actually has users. You grinded your skills with YouTube videos and putting together a bunch of bootcamp projects, but this one is a bit different. It's not a project you wrote from ground up, it has its own history, tools (that might not be the same as you are used to) and purpose.
I remember my first project was a bit daunting in this regard. I was completely lost and was afraid to look unprepared or too incompetent to ask questions.
So, to help you overcome this here is my list of things I usually do when I start on a new project / codebase.
Regardless of what you are working on, frontend, backend, devops etc in a project you will always have specific file / folder structure. Specific tools being in use to format, lint validate, build, deploy, preview the code etc. There will be specific naming and organisation conventions (or a lack of them).
More often than not, you can study this right at the doorstep of the project. Take a good look at the project's main file containing dependencies (for JS users - package.json for example). Surf through the files and direcotries to understand how features are broke down.
Regardless if it's a website, a server, plugin or a driver - if you plan to work on it, you will most likely need to build it locally. So, do this then.
Now that you have an idea what kind of tools are being used in the project, second order of the business is to try to run the project locally. It might be as simple as running npm run dev (or alternative command), or might be something more complicated, with different dependencies for different operating systems, installing additional software etc (which you should be aware of from the first step - if not, you will inevitably get hints in forms of errors on what is lacking on your machine).
One thing I find common between different projects - lack of documentation around different environment variables. More often than not you will different environment variables containing some configurations, secrets etc. Sometimes they are not properly documented and the consequences of missing them out when starting the project can sometimes be not very obvious. Keep it in mind.
You have a good idea what tools are being used. You launched the project. You feel like nothing can stop you now. Wait. Do not try to conquer the world... just yet.
Start small - take a small request to change (pick an issue, or, if you are in a professional environment, one will be assigned to you most likely) and dig from there.
Here is a very concrete example, you need to change that alert notification text and how much it is displayed on the main page.
Identify potentially static parts of this alert (something that does not change based on X scenario and always remains the same), like a text. Try to find this text inside the project by searching globally over the project. Find the responsible component or a feature that produces this text. Most likely, you will have some logic around it - some timing, some constructors, translations etc.
Even if you cannot find the specific text, take a neighbour text, something that lives pretty close to what you need to change, and search for it. Most likely, you will find them residing side by side.
Pay good attention at why you found this text where you found, how the file is called, why is it being there. What does it interact with and what relies on it. I call it - context scanning. You have a chance to scan the context around something and see how things are working, even if it is just a text and a button.
This step can be done outside of the order of these advices as it is more of a "keep your head above the water" advice. It is good to know what your teammates are doing, how do people leave review (identify who is the most mean person in the wild west and get reviews only from them), what kind of features are being prepared and what kind of files are being modified for it to work.
More often than not, you will have someone to help you and to answer your questions. Sometimes very available person, sometimes not at all or almost not.
In any case, be ready to ask questions. Asking questions about the project, structure, where to start or what might be potentially affected is never a stupid idea. In fact, it is considered as a good thing - you don't want to mess things up. Just make sure you tried to steps above, tried to find the answers yourself. If you feel like it is specific to the project and does not have an obvious and straight forward answer -ask away.
I got those steps by starting on many new projects and it kind of became a habit that I use now on every new project I start on.
Hoping this helps and bon courage!