nullEDGE – Being a good ServiceNow dev with Ekta Sharma

ServiceNow / By /

What’s a “good developer”?
What’s “good”? What’s a “developer”?

That’s the kind of thing humans have been arguing about since ancient Greek philosophers.

In this session, Ekta Sharma shares her views on what makes a good ServiceNow developer.

Key takeways

Some advice resonates a lot:

  • Know the platform in its different dimensions: by product (ITSM, CSM, HR…) and by common capabilities (UI Builder, Virtual Agent, Workspaces…).
  • Leverage the community and documentation, there’s plenty of it out there. [Sometimes I miss the old wiki days!]
  • Understand what’s standard and what’s coming in the next releases.
  • Know the “Why?”, get the context, understand the bigger picture.

Questions are the answers you might need

On these and other aspects, my perspective has changed a lot over the years, and now I have more questions than certainties.

“Good” for whom?

Your employer, your customer, ServiceNow, your CV, your mental health?

Is a “developer” the same as a “technical consultant”?

What about seniority?

Do you have a clear list of responsibilities or plans to move to a different role?

For extra fun, ask a CTA/CMA cohort what an “architect” is and you’ll get 60 different replies.

Incentives also matter

Does your company / project lead / boss value curiosity and quality?

Or is velocity the only thing that you are evaluated for?

Will becoming the best developer on Earth lock you into a position that makes a promotion impossible?

And opportunity cost

Understanding the industry of your customer and their processes is great, but every minute you dedicate to that is a minute not spent learning technical stuff.

There’s no free lunch!

Beware of the magical solution on the next release

Sometimes a feature needs a couple of versions to deliver the promised value, and can cause a lot of headaches in the meantime.

It might be reasonable to write a couple of lines of code, document it well and plan to revert it to OOTB later.

Closing remarks

Anyway, back to Ekta’s session! (See what happens when you ask a developer to question things?)

Her closing summary remarks:

  • Don’t default to code.
  • Understand ServiceNow.
  • Question “why”.
  • Own your code.
  • Don’t create technical debt.

Sorry, I’m not done yet!

I need to expand on that last point!

You will always create technical debt, even when you follow all the best practices.

Standards change, new features make old stuff obsolete, or you figure out the perfect solutions two years after the go-live.

So, the only advice I feel comfortable giving for developers is: be kind to the developer who wrote the legacy code you are reviewing (sometimes that developer was even you!). And if you don’t feel a tiny bit embarrassed when you read what you wrote a few years ago, you are probably not learning fast enough… which is OK too!

References

Related Posts