In the previous diary entry, I had mentioned that I was neck deep in research papers. Soon after that, things started picking up some pace. After having looked at how the world was attempting to solve this problem, we decided to do some soul searching. We looked at any and all relevant features that exist in SAP systems, and how we could improve them. We also brainstormed and created our ideal solution to the problem. And then, we rolled up our sleeves, sat down at our desks, and started work.
The work involved reading up product documentation, understanding feature roadmaps, cloning a few GBs of source code, building a server and, last but not the least, debugging the said server. I learnt a few things along the way:
- Know your tools well: If you aren’t crazy about your text editor, haven’t struggled with your version control system or do not know how to correctly administer your system, you are going to spend a lot of time (and other resources) reinventing the wheel. And, on top of this, you are looking at a new code base which makes you feel like you’ve landed up on Jabba the Hutt’s planet. Knowing your tools ensures that you don’t kill your grey cells in doing basic tasks like cloning the source code, editing it, building it and debugging it.
- Keep your intuition of systems sharp: It is not always possible to know every detail of how the networking stack works, how a system handles jobs, differences between forking and threading or how requests are parsed and processed. But, if you have built a good intuition about these concepts, then merely looking at the logs and the basic directory structure of the repository tells you the right place to start digging further.
- Interest v/s Stake: By it’s very nature, a lot of problems that IT tries to solve are interesting. Hence, what you work on will interest a hundred people. It feels great to talk to them about your problem, and try to find out ideas and solutions. But, there is also every possibility that some of those hundred people might make you bark up the wrong tree, intentionally or unintentionally. On the other hand, stake holders in your problem are the most awesome people. There will be about ten of them, and they will do loads for you, provided that you communicate exactly what you need from them, and what you can give them in return.
- Getting data sets is tough: No, just making a database table from a CSV that was generated by sequences in Excel or Google Docs is not sufficient. All customers are extremely protective about their data. And, even if they are interested in providing datasets, the hardware might just be so heavily loaded that they cannot turn on that extra tracing parameter for you. So, start working on collecting a dataset as soon as the problem statement is understood.
- Code is the Law: Do spend some time to read architecture documents, and customer manuals. Don’t be fooled by it though. Unless you see classes/methods that actually implement that feature, and you can hit that method while debugging, the feature is not present.
- Rinse, repeat: Learn how to build, rinse and repeat, and become Yoda. Inevitably, you will land up in a situation where you will have to start from scratch all over again, even though you know the tools. You are new to the system, and you will mess up either the data or the build while debugging or editing respectively. And, this will happen often in the first few days.
- Know when to stop: Rinse and repeat is a good thing. You learn loads. But, the process reaches a stage where nothing new can be gained. Learn to recognise that you are up against a wall, and go take a water break or ask someone who knows better than you. You will save yourself from the heartburn, and time and money for whoever employs you.
If you’ve been around in the industry for some time, this may seem pretty obvious. But, for someone like me who is still learning the ropes, it took some time and effort to realise this.