Good Developers Code. Great Developers Do Much more.

Kumusta! That means “hello” in Tagalog, one of my native languages. I’m proud to say it to you as Cisco DevNet’s newest Senior Developer Advocate!

I’ve been a software developer for a decade, and I’ve seen a few things. I’ve worked at small startups, and medium and large enterprises. I’ve worked in industries including higher education, healthcare, e-commerce, and finance. Most importantly, I’ve worked with a lot of different developers. The most effective developers that I enjoyed working with the most, and those I learned from the most, had a few things in common. These are the things that made these developers stand out, and which continue to be guiding principles in my career:

Documentation is our friend

We hear about the merits of documentation all the time. We know we need it, are frustrated when it’s bad or non-existent, are thankful when it’s good, and yet rarely write it ourselves. Whether that’s due to the self-deception that our code is “self-documenting” or that we don’t have the time, documentation is absolutely the first measure that sets great developers apart. Documentation is key to writing great software and being disciplined enough to do it is always beneficial. Adrienne Moherek has a great, 5-minute lightning talk that discusses this and I encourage you to check it out.

The greatest developers I know can easily reference a workflow or point out an important detail in a function. Is this because they have impeccable memory? Maybe, but the main reason is because they are consistent in documenting their code! Once I started to see documentation as a required task that becomes an asset, rather than a “nice to have” but annoying chore, I knew I had progressed in my career.

Code reviews the nice way

Another key part of software development is the code review. As we continue to make changes to our codebase, the code review offers a way to make sure we don’t break production! This is usually done by our peers; fellow software developers comb through our code to make sure there are no glaring (or hidden) mistakes.

Unfortunately, this process sometimes becomes a battleground of egos. You may have experienced this yourself: you’ve opened a pull request to be reviewed and returned to find nitpicks or things based on preference. Or overly critical comments that may not show awareness of the full context of what you were working on. Still other comments give unsolicited suggestions without any reasoning behind them. This kind of code review — the type that makes your co-workers tense, feel unintelligent, and despise the process altogether —  is what great developers avoid at all costs.

I used to believe all code reviews were this way; that the process was supposed to be uncomfortable. It was only halfway through my career that I met a developer who completely changed that viewpoint. Code reviews can be done in a much more efficient and considerate way!

With a few basic rules that the entire software development team agreed upon, code reviews could focus on the code and not the person writing or reviewing it. In a nutshell, great developers encourage objective, automated, and considerate code reviews! If you happen to meet me at a Cisco Live event, don’t hesitate to ask me more! 

Humor and fun have a place in learning

My favorite guiding principle is that of infusing humor and fun into learning. We’re software developers; we know how fast languages, frameworks, and all other kinds of tech change. This means we are constantly learning, constantly growing, and constantly looking for good learning resources.

What’s a good learning resource? One that’s clear, concise, and that effectively teaches the topic being discussed. For me, that means content that’s structured, learning materials that let you get your hands in the code, and the use of fun or humorous examples. Especially when it comes to more complex or very dry technical content; the more creative the examples, the better.

Think about this example: would you rather learn about durable function patterns through several dense technical paragraphs and complicated diagrams? Or would you rather learn that same information via analogies to making lumpia (complete with visual aids)? The latter would certainly keep my attention longer (which is the hardest part of learning something new). It likely also helps me grasp the fundamentals of what durable functions are and how the patterns work. With the fundamentals understood, those dense technical paragraphs become more approachable and those complicated diagrams discernable! If I started the other way around, I’m more likely to get lost, frustrated, and give up learning about durable function patterns altogether.

As someone that now creates all kinds of learning resources for other developers, I take this guiding principle to heart. I always try to creatively teach something and distill it into the fundamentals. There will always be more advanced resources to continue learning, but they will be of no use if starting out on a rocky foundation. So, if you find yourself mentoring a junior, explaining something to your peers, or even finding a learning resource yourself, never underestimate the value of adding a bit of fun into those tasks.

I hope these guiding principles tell you more about who I am as a developer and what I hope to bring to Cisco’s DevNet team. I’m looking forward to sharing much more with you, at conferences and events, in new videos and in blog posts I have yet to write.

Follow me on LinkedIn, on Github, my blog. and give me a shout on Twitter!

And be sure to check out the progress my new Cisco teammates are making on some great API tools: 

• API Clarity: Open source for API traffic visibility in K8s clusters (see also: demo; interview) 
• APIx Manager: Open-source tool to help developers improve API quality and security

 

---

We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!

LinkedIn | Twitter @CiscoDevNet | Facebook | YouTube Channel