Home

One Year Since Reborn as Programmer

After 5 years of experience in a software company, I quit and went to do my Masters. Finally after completing 2 years of my higher studies, I started fresh – clean slate. Its been now one year since I re-entered software field. This was a new beginning, and I did not want to commit the same mistakes I had done previously (what were the mistakes done?). During this one year as a fresh software development engineer, I learned a lot. This post is all about those learning. I hope this helps anyone who is joining new as a Software Development Engineer.

Initially when you join the team, two things happen. First, because you are a fresher and new to the team, team would give you light work. There is the feeling of ‘Oh! you have just joined, enjoy as time lasts!’. Second, everything is new, every word spoken by the team members seem alien to you as if team is talking in an highly cryptic language. Every meeting is like a new page in a dictionary – loads of new words/acronyms/terms and you try hard to put a calm face as if you know those things but inside your mind – ‘you are killing your confidence – I don’t know anything’. The second thing was especially bad to me due to the fact that I had previous work experience. Even though I am starting everything fresh, still I had that ego saying ‘I know things! I should have known all this!’. These two things – take it easy & what the hell is going on – will set a unique composition of destruction. It will make you lazy & things look daunting. As things are daunting you loose interest, loose self confidence. As you lost your confidence & interest you become more lazy and as you are more lazy you do not want to take up more tasks rather barely survive. First thing first, from the day one its your job, your career, your team and your product. The reason initially you are given small work is not that they think you are incapable or they think you ought to end your work early daily, go out and enjoy outside but rather it is for you to learn. Learn about the code written by your team, learn about your products environment. This is the precious time where you get to read the products code, get to know the nuts and bolts of your product. I know just by reading you will not know everything but knowing code is big confidence booster. Believe me this is the only period in your career where time is given for you to read about the code, as you become experienced you will be flooded with work. So, utilise these initial days in the team to know about your product well and read the code.

During initial days in the team, you are trying to understand the team – How do they work, what does the team generally appreciates, what does a big no in terms of attitude. So during this time, we tend to become very defensive as in we try to shield our work thinking “Oh! what will the team think , when they see my work”. We do not want to project as fools or inexperienced or not knowing image of ours to the team. Usually this can be seen when we hesitate a lot to send our code for reviews or in-fact any kind of reviews like even design. We keep thinking, is this the perfect code I have written? By seeing this what does the other genius developers (rest of the team except me) in my team think off me. There are two things in play here – first, our self confidence is low because we are new to the team and I have less knowledge of the team as a whole. Second, we are afraid of the criticism. Remember this – by delaying your reviews you are basically not helping yourself. If there was a flaw in our code and it is not apparent to you, then by not reviewing it with others you will not catch that flaw early. So you keep developing on top of that. This practically is making the flaw bigger and bigger. Then, when you finally review it with others, this flaw will be discovered and whole thing blows out. So, you did not improved your image rather you tarnished it by doing it. So, best thing to do is iterate quickly. Do something small, get feedback, update it, add new stuff and repeat this. Criticism != Evil. Criticism is a chance for you to learn something. Its not a big deal that you got criticised for your work. These criticisms are a chance for you to fix the flaws which may not turn into a problem in future.

Just reading the code or understanding the concept will not help, you should be ready to question. Ask what you are not understanding, ask what is not clear to you, ask if what you are thinking is the right direction. When you ask, that means you are thinking on it or atleast just to ask that question you thought of it. But we fear, we might ask a dumb question. What might others feel when I ask this question or what will others think about me when I ask this question. Remember this and repeat it yourself – “There are no bad questions“. Even they might not have thought about what you are asking so you are kind of helping them also. Its okay to be vulnerable. For me this was very tough, I tend to just listen and never question on it. Always the fear was they might think I am unintelligent if I ask this question. It’s not the case and you will be surprised how many others had the same question and they just kept it inside them. We tend to put others in pantheon of Gods or Genius and try our best not to tarnish our image infront of them by asking stupid question. But when you talk to them and ask questions to them, you will understand that they are as human as you are. They know many things and also don’t know many things.

You should remove the idea of developer as a one who just writes code or programs. You should also delete this notion that manager, developer, tester, architect and requirement analyst all are different roles performed by different persons.We always want someone else to tell us what to do or how to do or when to do. We want our manager to manage us, our testers to keep check on our quality of code. What is our work? – Just write code. We indirectly want to be machine that takes x as input and give code as output. We need to change this mentality. We need to manage ourselves, we need to be our own quality control. Don’t expect things to be spoon fed. As a developer you collect requirements, as a developer you design your module, as a developer you write code for your requirements, as a developer you test your written code, as a developer you review your peers code and get your code reviewed, as a developer you write wikis& document your work, as a developer you build, deliver your modules and finally as a developer you are going to manage your time & resources.

Mistakes, problems and failures – all of them are good. Embrace them and learn from them. You wrote a code, tested it, went through review and it got deployed. Then one fine day out of nowhere an issue has happened in production due to your code. Don’t panic – this is part and parcel of life. Rather learn from it. There was something we missed due to which this occurred. Fix the immediate problem, learn lessons and finally adapt it so that next time this wont happen. When the problem comes all we want to do is get out of this problem. Its a good thought but we tend to opt for quick fixes. Once that problem appears to have gone, we totally forget about this. Quick fix never works. We just delayed the issue and it is going to come back in even bigger way. To avoid it, do deep analysis – go to the core of the problem, understand it and then fix it. This is difficult to come by. It takes practice, again and again thinking on it. We always tend to pass the ball and once ball is out of our hand we forget about the ball. This attitude must change. Take any issue – whether work or personal , small or big – understand it and go over it, think on it.

I feel, especially nowadays, it is foolish to think that you will be working from day one till you retire (can you retire from your passion?) in a single language, example only Java, or a single framework. Its a continuously evolving field – new languages, new frameworks, new methodologies keeps popping up. So here change is inevitable. As your product and requirements demand, you need to use different languages, frameworks. Within this one year I worked in python, Java, Ruby, javascripts and varying set of frameworks. So be ready to embrace the change. You may be a big fan of C but be open minded about Java. You may be an expert in Java but be ready to learn and write code in shell script. When you learn different languages and framework, the knowledge of one can be transferred to another. Something cool you discover in x framework of language xyz and you try to implement the same in language abc. So don’t judge. Shun the attachments. Then keep updating and changing. One of the things which help me is personal projects. Apart from the work, at home I usually spend sufficient amount of time on these projects. They usually form the experiment grounds for learning new programming languages, frameworks, concepts and designs.

As we start learning about the product and gain that confidence, there is one evil lurks in the dark. That is ego. It feeds on your success. We start thinking we are great, I know in and out of my product. We think we are Genius. There are two things to it – we get offended by small questions or criticisms, we stop learning. Be aware of it. Every time somebody questions you or criticises you, immediately you start defending yourself because how can a genius go wrong?! We don’t even think if the criticism is valid or not. I am genius – the all knowing, whats there to learn anything else apart from this product? Once the stagnation sets in, its the perfect ground for rotting. We tend to stop learning further. We don’t update or don’t acquire new knowledge. So basically we are moving towards deprecation or replaced. This is because industry itself is evolving constantly and old things gets replaced with new things. So, be a small fish, learn and update constantly. There is a learning from everything and every person. Be humble. Rama & Krishna, even though they are Gods, they had teachers from whom they learn about life. Adi Shankaracharya learns the most important lesson from a Chandala(Kind of begger). So always keep a watch on ego and be open to learning from all.

Finally, here are are some one liners which are taken from this amazing must watch video The myth of genius programmer. This forms the basis of my post and kind of guiding points to every programmer out there.

  • Lose the EGO
  • Criticism is not evil
  • Embrace failure and learn from it
  • Change is inevitable. Keep updating.
  • Be vulnerable
  • Iterate quickly
  • Do deep analysis
  • Quick fix never works
  • There are no bad questions
  • Don’t try to be a Genius
  • Be a small fish
  • Shun the attachments
  • Don’t judge
  • Collaborate early and often