• Should have been more aggressive in the start while I was being onboarded to my first job. Took more than a month to get the whole picture of the internal tooling and abstractions. Should have found out someone who was willing to help me understand the internals of the company.
  • Was not comfortable asking people for help as I was afraid of getting no from them. But it turns out to be a bad assumption to make in the first place. People are willing to help, you just need to find out a good time.
  • Should have set out personal 1-1’s with all my teammates in the beginning itself.
  • Should have been more proactive with the follow-ups w.r.t to an Issue or an MR.
  • Context is everything. There were some instances where the effort I put in without realizing the context had gone futile. Could have saved a ton of unnecessary work.
  • Became lazy with documentation after a while. Initially, I was very enthusiastic about documentation, but I lost interest after a while. Big mistake on my part. Documentation is the most important skill that can reduce the repeated effort, lubricate and delegate communication in an effective manner.
  • Was unsure about the priorities of many tasks. I am getting better at managing tasks with differing priorities.
  • Didn’t time box my day-to-day tasks. Huge mistake. Everytime task has to be time boxed, you can’t keep dragging it till you can.
  • Didn’t think reading existing code was a good idea. Again a huge mistake. Code and Tests are the best documentation of the codebase. Getting comfortable reading code is paramount to debugging.
  • Learning is exponential when you’re on Support. The kinda of skills that get acquired when you’re on Support helps you to be more than a programmer. Communication, Delegation, Prioritization, Debugging, How-not-to-write-code and what not.
  • Was not a good code-reviewer at the beginning. Was thinking too much about design patterns and other idealistic shit. Instead, could have focussed on common-sense and instincts. Any code should meet basic readability and making-sense aspects.
  • Should have googled more about any unknowns I was encountering on day-to-day basis. Basic googling infuses much more context than anything will.
  • Didn’t respect the human aspects that arise from code. I didn’t care much about the backward compatibility and constraints of various surrounding systems. Used to propose audacious things which have 0 percent of materialization. One word, was not realistic enough.
  • Didn’t experiment enough and didn’t invest enough time in mastering the fundamental tech. Having code samples which can help you to play with things and mastering CLI tools can massively come to your aide when the situation arises. Gotta work on this more. Hands on experience beats everything.
  • Didn’t pay much heed to my curiosities. Again a big mistake. Whether it is making small POCs and understand how they work or reading some good’ol research papers, you have to follow your curiosities.