Follow JRNY on LinkedInFollow JRNY on MediumFollow JRNY on Twitter

We Software Engineers (aka Developers) speak the language of code. We solve complex problems by designing, creating and improving information systems, and code is how we tell the system what to do.

The basics of being a Software Engineer are quite simple. When someone needs a new feature, you create that feature and then push the finished product to a server so clients can use it.

But, it's never quite that easy...

A New Feature is Born

Once we receive a request for a new feature, it then becomes our job to figure out if it’s even possible!

Sometimes those conversations go something like this - Client: “I need a button that gives me a user’s email address so I can send them marketing emails”; Dev: “That’s illegal, sorry no”.

If it is possible though, we then need to figure out what we need to use to get it done. For example, a database or third party service.

The more senior developers in the room also need to check the reason why this feature has been requested - often the why is more important than the feature requested. Sometimes we can offer a better solution than what was originally requested!

There’s always niggles and we work through those, for instance - the third party service won’t support what we need or we want to be able to do something in a different way.

We Can’t Do That Because It Would Break Something Else

Think of code like a maze - everything is linked and shortcuts can bite you in the arse. The code needs to be written to a certain standard so that every sub feature works in unison. One letter wrong and the whole thing can break.

It’s Done, Let’s Get It In Front Of People

Once we’ve built the structure, we need to test the feature and then put it live on servers.

So the engineer needs to create a bunch of servers to handle the task. To throw some lingo into the mix this includes needing to understand how to create a database server, web server and any extra stuff like load-balancers.

If the process isn’t automated we're in trouble - the more human steps required, the more errors with broken servers. If the process is automated, the engineer still needs to be able to see what’s going on in case of a failure somewhere.

But The Bad Internet Man Wants To Hurt Us

Once we’ve set up the servers, they can’t just land on the web. They need to be locked down to reduce any attacks.

Only servers that need to be accessed by the web should be seen, everything else should be hidden. Our applications need to be carefully written so they can’t be attacked (more lingo: injection, CSRF). Our websites need to be over https, so there’s a bunch of certificate stuff to do.

...And It Broke

Just when you think it’s ready to go, it can break. Every system will have bugs.

Even if it doesn’t have bugs, the hardware it runs probably does.

Even if the hardware doesn’t have bugs, it will break.

It’s inevitable.

Even if the hardware doesn’t break a solar flare could emit a small piece of radiation that changes a 0 to a 1 in memory and cause havoc (that’s an actual thing).

We then need to be able to look over all the information we can gather (including logs, error messages) to find the code that caused the problem and fix the problem (without causing more issues) so that we can get it in front of people again.

Sharing is caring
FacebookLinkedInTwitter

What's next?

Ready to
start the JRNY?