Takeaways from my first job at Oracle
This post originally appeared on medium.com/@kannarkk before I consolidated my writing here.
June 30 was my last day at Oracle. I joined Oracle PeopleSoft in June 2014, right after completing my undergraduate study. My two years were illuminating and these are the few things off the top of my head that I learnt about coding, or are of the most value to me.
Breakneck speed causes only failure
As I gained more understanding of the product, I recognized my tendency to rush into coding. Though this didn’t happen in the first few months for obvious reasons, I found this dangerous tendency somewhere in the middle of the learning curve, where the learning is incomplete. They don’t say “incomplete knowledge is dangerous” for fun. With tidbits of every learning every day, my knowledge of the product wasn’t perfect, and rushing through things only caused more mistakes — incorrect place to put the right code, wrong code, wrong commits, incomplete commits etc.
Development required me to move at a steady pace; breakneck speed was the easiest way to fuck things up.
Ask for help when stuck
As a beginner, I was afraid of asking silly questions. If I were stuck somewhere, I had a lingering thought that it was a too obvious thing I shouldn’t trouble the team leads or senior engineers with. This isn’t necessarily limited to the programmer folklore which goes on the lines of:
Stage 1: Why isn’t this working?
Stage 2: I am doomed. Urgghh!
Stage 3: I am hopeless!
Stage 4: I left a semicolon. Never mind. It’s working now.
Everyone has heard one of the many versions of the above story, and it kind of sucks you into a loop of not asking for help when stuck. You think there’s a stage 4 of the problem which you aren’t seeing, but you should be seeing. However this isn’t always true. You could be stuck for various other reasons like a lack of context or understanding of the product. This is especially true in the initial days when you are still ramping up.
So a stage 4 doesn’t necessarily exist which means you are going to be stuck in stage 3 self loop forever expecting a stage 4 to happen. I always found clarity when I talked to people around me. If they had a better understanding of the product, it helped. If their third eye could catch a stage 4 problem, it helped. There isn’t a silly question. A question is a question. So ask for help when stuck, with the caveat that do your research first.
People are better resources than documentation
As a undergrad, I always felt that documentation was the key to everything. It was the Bible, the Gita or the Quran to understanding the product. It is; it is not.
With an ERP product like PeopleSoft, the code base is humongous and documentation isn’t always there. With several people working on the same code base, having one documentation that fits all wouldn’t work either. A lack of documentation almost always means you are left to debug from scratch and piece together the root cause of a bug. While this helped me ramp up my knowledge of the product, I found my learning ramp up faster by talking to people.
People who wrote the Bible, the Gita, the Quran and the code are better knowledge points than the creation itself.
They could speak more about why the code exists, what the code does and does not do, what implementations use the functionality, what’s the logic behind using a specific logic over another. Documentation hardly covers most of this; if it did, it would be verbose.
Brown bags delivered by key people like architects or product leads provided a broad understanding of the product components, exactly the opposite of what a documentation serves to do. People provide the context, documentation serves to confirm.
One to one sessions with my manager provided clarity, sense of direction, along with necessary help and guidance. My mentor provided required context, key tidbits required to code, develop and work. If there are two people I am indebted to, it is my manager and my mentor, who were not just encyclopedias of information, but also had the perspectives to understand the requirements, aligned to the organizational goals. In communicating them to me with respect to the context of my work, they were more valuable to me than an organizational keynote article that outlined the same (again verbose, complex and broad).
Divide, Prototype and Conquer
Any task can be divided into smaller sub-tasks, which can be conquered easily now that they have been outlined clearly. This has been stressed enough, however I found an intermediary step of prototyping to be cardinal to faster development.
A prototype doesn’t need to have all functionalities built. It’s a smaller version showcasing a proof of concept, or a preliminary version from which other forms including the final form is developed. Therefore it showcases the bare structure.
I found rapid prototyping to be helpful for two reasons:
- It was crucial in delineating the basic structure from the actual implementation. If I had to implement a processing loading indicator for example, it is pretty simple to do it for static pages. For dynamic pages loaded through multiple code flows, one needs extensive unit testing. The first step is building the loading indicator logic itself, and not the calls from these code flows. Prototyping helps solidify the basic backbone essential to all implementation.
- Prototyping along with modularity speeds up development.
101 of coding: don’t check-in bad code
Code optimization is key. I may have got through college projects with inefficient lines of code that worked at that scale. However, I could not have, at work. If I did not deallocate a few objects in those small scale projects, it was acceptable. But it wasn’t acceptable in this humongous code base working at such huge scale; memory leaks that looked inconsequential hogged up the RAM easily and quickly. If it was HTML, multiple keyboard callbacks like onkeydown, onkeyup and onkeypress aren’t necessary most of the time and just one of them would suffice.
Code versioning systems can quickly create nightmares
I am not talking about CVS version control, rather about code versioning (CV) itself. Yes, it’s awesome. But it’s a nightmare too. Though I believe a CV nightmare is a part of a developer’s formative process, just thinking of them evokes painful memories. Suffice to say merge conflicts are the least of the concerns.
In summary,
- Breakneck speed causes only failure
- Ask for help when stuck
- People are better resources than documentation
- Divide, prototype and conquer.
- 101 of coding: don’t check-in bad code.
- Code versioning systems can quickly create nightmare.
I will be taking back these valuable aspects of my Oracle chapter as I head back to academia for my master’s degree.