Day in the Life: ServiceNow Developer (Modern Perspective)

[alexalejandro]

A few years ago, I responded to a community post with a quick breakdown of what a ServiceNow System Administrator does on a day to day basis.

That simple reply ended up sticking with me.

This continues that same idea, just focused on the ServiceNow Developer role and what it actually looks like day to day.

Like before, this is not meant to be a perfect definition of the role. Every environment is different. This is just a reflection of what you may run into based on real experience.

🎯 What Success Looks Like

A good ServiceNow developer is not measured by how much code they write. It is more about what they leave behind.

• Solutions that are easy to maintain
• Things that survive upgrades without breaking
• Clean logic that someone else can understand later
• Solving the right problem, not just closing the task

Over time, you realize the goal is not to build fast. It is to build something that will still work months from now.

☕ Morning

Most days do not start with writing code.

They start with figuring out what you are actually being asked to build.

• Reviewing user stories or requirements
• Talking through unclear requirements with admins or consultants
• Catching gaps before anything gets built
• Thinking through impact before touching the platform

A lot of problems get solved here before any development even starts.

⚙️ Midday

This is where the actual building happens.

• Creating flows and automations
• Writing scripts like Business Rules or Script Includes
• Working in App Engine or Studio
• Setting up integrations when needed

One thing you learn quickly is that not everything should be code.

A lot of the time the better solution is simpler and closer to configuration than customization.

🤝 Working with others

Development is not done in a vacuum.

A typical day includes working with:

• Admins who understand the platform operations
• Architects who care about long term design
• Consultants who are translating business needs
• Stakeholders who just want something that works

The real work is making all of that line up.

🔧 Afternoon

This is usually where things get tested or fixed.

• Debugging scripts that are not behaving as expected
• Looking at logs to see what actually happened
• Fixing edge cases that were not obvious at first
• Testing to make sure nothing else broke

Honestly, this part can take as much time as building the solution itself.

🔗 Integrations

Most environments are not standalone.

• APIs break
• Data does not always come in clean
• Timing issues happen

A lot of development work ends up being about making sure systems actually talk to each other the way they are supposed to.

📊 What you start thinking about over time

At some point your mindset changes.

You stop asking: “What do I need to build?”

You start asking:

• Will this break on upgrade?
• Is there a simpler way to do this?
• Who is going to maintain this later?

That shift is what really separates junior work from more experienced work.

🔐 In regulated environments

This becomes even more important.

• Access matters
• Data matters
• Decisions need to be explainable

You are not just building features. You are building something that might need to stand up to scrutiny later.

🔄 Continuous improvement

A lot of the job ends up being going back and cleaning things up.

• Refactoring older logic
• Simplifying things that got too complex
• Reducing technical debt over time

Eventually, you realize the best code is often the code you did not need to write.

⚠️ Where things go wrong

Some common ones:

• Overcomplicating simple requirements
• Writing scripts when configuration would work
• Not thinking about upgrades
• Not documenting anything
• Building without understanding the bigger picture

💡 If I could go back

A few things I would tell myself early on:

• Learn the platform before trying to out-code it
• Simpler usually wins
• Ask more questions before building
• Work with admins and architects early
• Not every problem needs a script

💬 Discussion

For those working as developers today:

What is something you thought development would be, but turned out completely different?

And what is one lesson that changed how you approach building on the platform?