This post is an attempt to answer a question I get quite often – “How do I improve my technical skills?”. I won’t say there is the recipe for it. But I have seen these being followed by the good technical fellows that I have seen or known.
1. Broaden your horizons. Research.
Why: This technical knowledge would help you a lot in the day-to-day. It gives you new insights and tools that you didn’t know about. It makes you a better problem solver who uses the right tool for the right job.
2. Invest time in Reading. Make time.
Read books, articles, presentations, whatever. Too often people feel they don’t get enough time to read because they are busy. But in the fast-moving tech world, you are either moving ahead or you risk becoming obsolete. So make time and cultivate an interest in reading. You will find as you read and learn new and even totally unrelated things, you get better an understanding of things you knew. You can do things faster and make time for your reading now. It sets a virtuous cycle. The best tech guys read hard-core tech articles as a hobby / past time. Think of it like reading newspaper except that instead of feeding your mind use-less tidbits, you get better and learn something you can use.
Why: Its the only way you will learn really new tech and best practices for existing tech. If you are reading the right things (not tech-crunch), it exercises your mind, keeps you up-to-date, gives you new tools and ideas.
3. Find problems. Refactor.
Within the simplest of software systems lurks many small time-bombs. They are ready to blow anytime. So, find where your system is shaky. If you can’t find them, take help from your leads/seniors. Usually, the problem areas have bad performances, no-one wants to touch them, are un-tested and only one person ever works on it. Once you find these, refactor and make them better the next time you touch them. Refactoring is about making small changes in the system to leave it in a better state, without adding or removing functionality. It’s about fixing broken windows.
Why: If you don’t find these problems, they will find you unawares. You want to run ahead of them. Also, this helps you learn what was wrong in the system, fix it and gives the experience necessary to design better systems when you get a chance.
4. Share Ideas and Solutions. Write.
A big part of the job description for a tech fellow is being able to communicate technical designs and ideas and convince people of their importance. Writing coherent and compelling emails is a must. Typically these emails would have a succinct not-so-technical description of the problem, a few possible solutions, a recommendation with supporting arguments and a call for feedback or comments. These emails are like call-to-arms. e.g. Nobody likes refactoring. It means extra work and risk, without any new features. So the onus is on the tech fellow to convince that the refactoring or other good technical ideas are necessary and can be executed without too big a risk and will be more efficient in the long run.
Why: Having a great technical idea is not enough. Its also your job to cajole some, convince others, sometimes fight through resistance and make sure that ideas are implemented, all that while meeting business goals and without creating big fail risks. Explaining the need is the only way to get that done.
5. Do Code Reviews. Be great at it.
Read code – yours, others and everyones. When learning a new technology or language, you can pick a popular and well done open source project in it and read through its code. Also, go back and read your code a few months later and you will find out what things you should have done differently. Have your peers review your code. Make it a point to explain how and why you did something and have them provide feedback. Do the same and reviews other’s people code. Understand the big picture and why something exists where it does. But also look at the finer details, code conventions and best practices. When you give comments, make it a point to be as detailed as possible and with examples. The reviewed code should be better quality than what you would have written. That is a promise you make when you review code and say that its good for production without any objections.
Why: Fastest way to learn is from getting feedback from your mistakes and from other’s mistakes. Getting to see how other people do things would give. Giving review feedback is an exercise in getting your ideas heard and accepted (see 4).
6. Cut to the Chase. But be Respectful.
Say exactly what you feel and believe. You don’t have to beat around the bush. It wastes your time and for the readers. Tech fellows always have 15 other interesting things to work on and so time waste is a crime. Be to the point. But criticize the ideas, never the person. Its okay to say “This is code looks smelly” but not “This code looks like it was written by a drunken monkey”. On the other hand, when receiving feedback, never take it personally. Take pride in your work, but never get “attached” to it. It affects your rationality and ability to take honest feedback. The critique is always at your work, not you. And you are already better as you take the feedback.
Why: You and your colleagues don’t have enough time, so, be to-the-point with feedback or critique. You don’t want to make the discussion personal i.e. my idea vs his idea and argue on the merit of the idea itself. Hence, avoid personal remarks. And learn to take feedback without getting personal.