Java Champion and Oracle Groundbreaker Ambassador Nikhil Nanivadekar knows a thing or two about efficient coding. Whether on the job at the Bank of New York Mellon, speaking at conferences such as Code One, demonstrating robots for kids, or contributing to Eclipse Collections, Nanivadekar has had his head in code for nearly a decade.

Like most developers, Nanivadekar enjoys the feeling of being absorbed in the process of programming, famously described by psychologist Mihaly Csikszentmihalyi in Flow: The Psychology of Optimal Experience (Harper & Row, 1990). He has boiled his productivity as a Java developer down to three key measures: “One, the amount of good or bug-free code that I write,” he says. “Two, the amount of code that I can delete. And three, the amount of help I give to fellow developers, be it on Twitter or GitHub or with my teammates while we are pair-programming.”

Here are five key lessons Nanivadekar has learned for measuring efficiency, maintaining team presence, and getting recognized as a leader in your organization.

Lesson #1: Notice How Much You Delete

According to Nanivadekar, understanding how you work can help you find flow as a coder.

“I develop something in one pass,” he says, citing his personal “rule of three” as a way of sharpening that formative, naïve version of his code. A second review optimizes the code, removing unnecessary “garbage” that appeared in the draft version. With a third pass, Nanivadekar says he “decorates” his code to improve readability and assist with future enhancements.

“Code should not only work as expected but it should also look and feel nice,” he says. “Writing readable code helps us maintain and enhance it, so I am productive in the long run as well when I revisit the code.”

As he becomes more productive, the amount of code he has to delete shrinks, because he’s writing only necessary code to begin with. “I can actually see those metrics, because I’m committing against the same issue or the same functionality. When I delete 25 lines of code, that means I wrote 25 lines that were completely unnecessary.”

Lesson #2: Measure Your Mentorship

Becoming a great software developer is a process of give and take. For Nanivadekar, teaching and mentorship fuel his own productivity—so he measures that too. While you can always count how many lines of code you’ve written, GitHub commits you’ve collected, or issues you’ve tracked in JIRA, how do you measure the effectiveness of your mentorship?

Start with looking at frequently asked questions, Nanivadekar suggests, and simply document those that come to you more than once so you can “just point to it.” Then, “I refine my delivery or information channel so that the same question, if asked again, gets answered on the first attempt,” Nanivadekar says. He also tracks how often the same person asks the same questions in order to evaluate the effectiveness of his mentorship. “That’s not a criticism of the person asking; it’s a criticism of me, because I have not done a good job of explaining the answer to them.”

When helping junior developers, he first teaches the concept and then lets them take the driver’s seat. “That’s because when you do something once, you understand it; when you do it twice, you start getting it into muscle memory; after three or four times, it becomes second nature. So, I try to walk through it with them at least once, twice, thrice.”

Lesson #3: Check Your Story Point Estimates

Agile methodologies emphasize chunking work into manageable sprints by estimating “story points,” which are elements of functionality to be coded. But it’s equally important to verify the accuracy of those estimations after the fact. “I’m very particular about tracking how much time I spend on a particular functionality,” Nanivadekar says. “That is something that I have done for the last seven years, so it’s second nature and a self-reflection to know that, hey, I really did spend 13 hours on this, so the next time we are doing this, we have a baseline.”

Lesson #4: Collaborate by Pair Programming

Also key to Agile is the idea of face-to-face interaction, with pair programming being a critical practice. Whether you are in the office with your team, working from home, or working while traveling, pair programming requires some discipline. And if you’re not in front of people in a shared office, it’s easy to forget, Nanivadekar says. To mitigate that, his team has a few protocols, such as being reachable for urgent calls and issues.

Beyond that, Nanivadekar spends up to seven hours a day doing long-distance pair programming. “There’s always someone on the other side of the phone who is collaborating with me.” In pair programming, there’s a driver and a navigator. If Nanivadekar is the driver, “I’m typing the code, and I’m explaining what will happen. And the navigator keeps checking, saying, ‘Hey, does what we’re doing here make sense?’”

Lesson #5: Get Recognized

Maintaining team presence ultimately can help you be recognized as a leader in your organization, Nanivadekar believes. One of his first managers advised Nanivadekar to update his résumé every January 1. “If in the last 365 days, I haven’t gained even one new technology or skill to add to my résumé, then the year was not productive for me. And I will then end up trying to make it up in the next quarter or add it as a goal or checkpoint with my manager.”

“When you get promoted, it’s because you’re already doing that job, right? People will often ask, ‘What do I need to do to become a VP?’ Rather than that, I ask, ‘What am I doing that is holding me back from being a VP? What am I not doing?’”

Learn More

Photograph: Martin Vargas/Getty Images for Oracle