The Blank Page

André Eriksson, January 11, 20203 min read

To the novice programmer, the biggest fear is the very starting point of any program. The Blank Page. As we gain experience we learn to overcome this fear, but what remains is the remarkable unhelpfulness of our programming environment. This unhelpfulness is not limited to the blank page but extends to all facets of software development.

While user interfaces in general have improved radically in the last 20 years, our IDEs have if anything regressed. They have grown features but the majority of them only grow the memory usage, never getting the opportunity to provide actual value. And even the useful ones are only helping us by automating mechanical tasks. Is renaming a function the height of usefulness?

Software Engineering is hard. Renaming a function is not. We need tools that come to our aid in the hard parts of our craft. Reading and understanding code. Writing code. Understanding how larger systems fit together. Tools that come to our aid when there’s a production outage, or when there’s a particularly tricky bug to track down.

Software Engineering is slow. Not because Software Engineers are slow but because shipping new functionality requires so much from us. Mountains of boilerplate separate our five lines of pure business logic from the customer that wants it. We need tools that let us write the code that matters and free us from writing that which does not.

Software Engineering is collaborative. Or rather, it should be. We send pull requests and review code and pair program now and then, which are all immensely useful activities for improving quality. But developing a new feature seldom touches only one component. We would be much more productive if we could collaborate across components, with multiple engineers working together from several angles on the same thing. If sharing your work in progress was as easy as sharing your screen.

The root cause

I believe these problems stem from two things. First and foremost, our programming languages are (by design) so incredibly general. Secondly, they operate at a fairly low abstraction level.

Because our programming languages are so general, our tooling has evolved to be equally general. This means that no assumptions can be made about the way the software is written, or even what its purpose is. This is how the killer feature of our IDEs is still renaming a function.

We need to move to programming environments with higher level concepts like defining an API endpoint, calling a backend service, or querying a database are all first class citizens. It’s then easy to build a much more powerful developer experience, to aid in the process of actually writing code (and not just re-writing). For example, when we make an RPC request to another backend service it should look like a regular function call in code.

A solution?

We are working on something to solve these problems. We’re calling it Encore and we’re finishing up the last few things for an initial public release and will have more to show in the next few weeks. Sign up here to be notified!

We’re building something new

This blog post comes directly from our experiences building Encore.

We kept feeling that backend development took much longer than we liked, and that we had to spend so much time configuring build systems, managing Kubernetes yaml files, provisioning databases and more. We built Encore to solve all of these problems.

With Encore you can focus on the API itself. We take care of the rest, from setting up build and deployment systems to auto-scaling Kubernetes clusters and provisioning databases. That way you can focus on what makes your application unique, and create value for your users much faster than ever before.

If you're interested in trying it out, sign up for Encore and let us know what you think!

Subscribe to our Engineering Blog

The latest ideas to help you build better software.

You can unsubscribe at any time.

© 2020 Encore. All rights reserved.