Vadivel's blog

Even while looking for members with specific technical skills, I generally look for these in any candidate:  1. Lots of people can raise issues and surface problems. But the best people identify the problem, propose a real solution to it, and help do the work to implement it. Those people are incredibly rare and incredibly valuable. Does this candidate look like one among them?   2. Generally, most companies don't need superstars. They need people who are curious and disciplined, and that can come from anywhere. Is this candidate curious enough? 3. Enterprise company: this is a great plan. Let's make sure we get these four other teams on board to get this done.  Startup: great plan! Is it live yet? What are the results?  Does this candidate have a startup mindset while approaching a task?   4. No one person leaving a good company kills it, but sometimes one person staying can. Similarly, the absence of a feature may not kill a good product, but the presence of a...

Have listed down few Lessons learned on the field which I found useful over a period of time. 1: Always execute every line of your code After developing a feature one needs to obviously test it. Make sure every line of your code has been executed at least once. Many times see bugs on a certain line of code which had never been run by the developer. Kind of a condition within your code where the control never reaches during the normal flow. The code might look decent enough while reviewing, but unless you had made sure control comes to that part of your code and test it nothing is guaranteed to work. Sounds obvious, doesn't it? Think how many times you would have faced this scenario by having used some test data which never takes you to an "else" part of the code (or) "case" of a switch statement etc., 2: Logging, Error Handling to be part of the code from the very beginning. While developing a new feature/module/project add logging and error handlin...

Mostly this mantra is followed by most development teams (in particular startups) & it certainly makes sense as long as it gets understood completely. In my nearly two decades of experience, I have seen teams strive tirelessly to "Make it work" and deliver a minimum viable product. But are indirectly forced to skip the "Make it better" part due to lack of time/lousy estimation. Why?  Because once the minimal viable product is delivered, people start pulling resources out of that, start assigning the next module so that they can "Make it work". The assumption was we can work on refactoring the code tomorrow or the day after, which in reality never happens. Ultimately the development folks don't find time to "refactor" their initial code to "Make it better". "The problem with waiting until tomorrow is that when it finally arrives, it is called today." - Jim Rohn So what? It is already working anyway!  ...

During my days as an MVP (Microsoft Most Valuable Professional), I used to mentor few juniors from the community. One of them used to be very low on confidence and fear of failure was hurting him more than anything. Recently while cleaning up my mailbox found few of the old emails which I have sent him - cleaned it up a bit and just compiled all those into this  article .

Over the past two years, I acquired many life lessons from cycling. However, after careful thought, I have decided to share the most significant life lessons I have learned in this article