Today I completed the first month of my first job. It happened all too quickly and everything looks on fire when you are not in college anymore because in the real world there are too many variables you can’t control. Nevertheless, for me this has been a good month for personal and professional development. Here are the things I learnt in my first month -

  1. Meticulously brainstorm the path that you are planning to go on while building a project. It happened with me many times that I was given a small project to do. It was quite simple and I got excited that I will be able to complete it in a day, but this excitement led me astray. I didn’t brainstorm my plans and as I progressed I got stuck in many stupid problems that I would have easily avoided had I meticulously planned the way forward beforehand. So step back a little, foresee the project and how you want it, consider it from the perspective of the end user and then proceed. You’ll not face stupid issues this way.

  2. Start with a small skeleton code. My CTO gave me this advise. When planning to go forward with a large project, just get the basic skeleton of the project running and then progress forward. This way you make sure that all your models, views, environment, database, etc are setup correctly and hence you will not have to deal with these basic configuration later on because they get frustrating at that stage as your codebase expands.

  3. Effective naming of variable. I can’t stress this enough. Follow the naming conventions that your team is following or if you are just starting then adopt a good styling guide (like Pep8 for Python) and then be consistent throughout. But don’t compromise in length when it comes to naming variables. Half of the time, the logic of your code will be more clear if the name of your variables reflects their purpose.

  4. Overestimate the time to do the task so that you can easily finish the job within the timeline. When someone asks you how much time you need to finish something, give a exaggerated time line and then complete it before the time ends. This way you make sure that you have some time cushion in case some unprecedented problems comes up (which will because it is coding). Also, you will create a reputation as someone who gets shit done in time. Trust me, it creates a good impression.

  5. Make comprehensive notes. When in meeting or when given a task or when you have to get shit done, just write it down. This way you can create a clear chain of thoughts and you can easily organise your time and work.

  6. Don’t lose your mind when things aren’t going as you planned. It happened with me. First week of the job and the things weren’t as I had supposed them to be. I got depressed that I am stuck at this job and stuff, but it turned out I was only overthinking. So give it a time. It will be alright.

  7. Read about the library or framework or tech you are going to use before starting. Read as much as you can - blog, docs, etc. This helps to create a general idea about the things that you are going to use.

  8. Make comprehensive logs of the code. This way when the code gets deployed to prod, you know when and where the error came up. This seriously makes debugging way too easy and provides a morale boost on seeing the logs when everything is working fine.

  9. Keep your working environment clean. When I first started I used to make new directories everytime I had to do some major changes in the code and then I would end up with 5-6 directories of the same project and later it would get confusing which one is the useful one. So learn version control (like git) and then maintain your project nicely.

  10. Networking is essential. Don’t think of yourself as a nerd engineer who just sits, drinks coffee and code. You won’t get far and the office politics will kill you sooner or later. So go out, network with others and just enjoy your life in general. This also helps in getting new job offers and you get to learn new things from fellow engineers. Remember, software engineering is not about writing code. It’s about taking a business problem, finding a solution to it and then transforming it into code.

  11. Make comprehensive docs and follow Test Driven Development (TDD). I can’t stress this enough. Writing documentation and tests is a habit I picked up while making open source contributions. It not only makes sure that your code is fully tested but also helps other developers understand it.