Cracking The Code Of Developer Creativity

February 23, 2022

There are a lot of stereotypes about developers: We sleep during the day, coding only by the light of the moon. We’re brilliant but anti-social technology geeks. We’re robot-like code drones, devoid of creativity. While I concede there may be a kernel of truth to the first two, I take serious umbrage with the third.

Coding is creating—and developers are, at their core, amazingly creative problem solvers. That is, we can be amazingly creative problem solvers under the right circumstances.

Unfortunately, there are times when the very nature of what we do gets in the way. For example, we’re often called upon to deliver the same routine functionality—say, an information intake form—for use in different applications. This is a necessary element of what we do, but think of it like this: If you were a writer, would you want to write the same story over and over again? Probably not. Because where’s the creativity in that?

It’s the same for us developers: Coding the same basic components keeps us from doing what we really want to do, which is to find new ways to solve people’s problems.

A quick primer on low-code

For those who don’t know, low-code development makes it possible for pretty much anyone to build an application. Using graphically based, drag-and-drop technology, people can assemble an app using pre-coded components.

Are these citizen developers suddenly coders? No. Can they create enterprise-wide business apps that work across multiple functions? No—at least not without the support of IT. But can they create simple apps that solve their problems using pre-coded functionality found in most business applications? Yes. Absolutely. And there’s no reason low-code can’t be used to help developers spend less time reinventing the wheel, and more time creating cool stuff.

Less-than-perfect process

Let’s start by looking at the typical, less-than-perfect process of how a business application gets made:

An IT department uses a shared email address to intake app requests and then tracks those requests, their approvals, and fulfillment through a shared spreadsheet. Already, there’s a lack of visibility on the part of the requester and other stakeholders, coupled with a high-touch, time-consuming fulfillment process.

Then someone needs to manually identify the people responsible for approvals and send approval emails to those contacts. They then need to collect the approval information, update the spreadsheet, and perform whatever work is required to fulfill the request.

Then, work is done in an entirely different software platform that has an API that can be consumed. Finally, an update is sent to the requester via email when the work is completed.

The process—spanning multiple people and platforms—is already clunky. And we haven’t even made it to development yet. Once a developer comes into the picture, they would have to:

Create a database to store requests and metadata, such as who approves which type of request and which groups each request needs to be routed to.

Add security to this database, so the appropriate people have the appropriate level of access.

Create an intake form hosted on a portal somewhere, which a requester would fill out and create a record in the request table.

Create automation that notifies the requester that their request has been received, handles the approval process, and assigns the request to the correct fulfillment group.

Create an integration that consumes the third-party API and sends the data.

As a developer, I’m most interested in the higher-complexity piece of this project—the integration. But I’m going to have to slog through the first four steps to get there. This means going back and forth with the stakeholders or business analysts on what the forms need to look like and the wording of emails, amongst other things.

This streamlines the entire process, freeing the developer to focus on the more complex integration, which is what we’re more interested in anyway.

Enter citizen development

In organizations with functional citizen developer programs, a non-IT employee can use a low-code platform to take care of the steps that are important, but better suited for someone closer to the business requirements of the project. Low-code would allow that person to create the data model with security, build an intake form, and deploy it to the correct portal. They can then use an automation tool to automate email sending, approvals, and request routing.

This streamlines the entire process, freeing the developer to focus on the more complex integration, which is what we’re more interested in anyway.

When developers can focus on one thing—knowing they won’t need to worry about going back and forth around form design or notification wording—they can be more creative in solving that one complex problem.

By removing the rote and mundane aspects of the project, developers are free to dig their teeth into the more creative aspects of our jobs. Not only does this unlock creativity, it lets developers focus on high-value technical challenges, rather than repetitive tasks that can be offloaded to citizen developers.

People get the apps they want. Developers get to create cool things. And problems get solved quickly with less stress all around. To sum it all up: low-code is the development solution we’ve all been waiting for.

https://smartstreamhd.blogspot.com/

https://infonewsviewers.blogspot.com/

https://media-streamit.blogspot.com/

https://mockbusterlive.blogspot.com/

https://monthjulymovi.blogspot.com/

https://gumaceng21.blogspot.com/