01/11/20

The Blank Page

Better tools for developing software

3 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!

Encore

This blog is presented by Encore, the development platform for building robust type-safe distributed systems with declarative infrastructure.

Like this article?
Get future ones straight to your mailbox.

You can unsubscribe at any time.