Lessons I learned during my first SWE position

There is a world of difference when we go from coding on our own, starting to learn, and when we start our first real experience as a software engineer. Whether it is working in an open-source project, or taking a job, things are not the same when we integrate an existing team which has existing projects. Here are the raw notes of some lessons I wrote for myself during my first experience as a software engineer:

• Decompose problems into smaller problems: Solve a problem by decomposing it into the smallest bits of solvable problems. i.e: Divide and conquer.
• Focus on one thing at the time: When solving a bit of a problem, focus on it and don’t try to solve other things at the same time, in the end you will probably end being slower by trying to multitask. And some tasks need all the active memory of your brain, context switching is not efficient. Your brain is not multithreaded.
• Note everything you will need in >1 minutes: every remark you want to do, every task you need to accomplish, every idea that comes to your mind… We are overconfident in our memory, but we’re quick to forget something, especially if your attention is caught by something else. You need to be able to be 100% focus on your current task without trying to keep in mind a bit of information for later.
• Don’t be afraid to look stupid: You cannot understand every concept the first time, you cannot always grasp every question without any uncertainty, you cannot know everything, especially since you are here to learn in the first place. Don’t be afraid to ask for help, to ask to repeat or to reexplain. The only stupid thing would be to keep ignorant about what you’re trying to figure out. n.b: this doesn’t mean you shouldn’t try to figure out things by yourself in the first place. You have to find the right balance between figuring out by yourself, then eventually asking if needed.
• When getting lost/loosing sight of the initial goal for a task, come back to the initial requirements, as if you were starting over.
• Have a plan before tackling a problem and keep track of everything, even the tough process: Creating an issue that follow a template can be a way to lay down every step, the requirements, the advancements, etc… But to each they own way of formalizing the written knowledge for a problem. Some people need close to nothing written down, others will benefit for transparency with others, themselves, but also to decompose the issue, lay down the context, the goal, the steps, the progress, etc…