
Coding is Over - loorinm
https://medium.com/@loorinm/coding-is-over-6d653abe8da8#.ixfq42smv
======
khedoros
> But is [coding] the most intuitive and productive approach?

Intuitive: no. Productive: Well, we haven't found anything better for building
software. What would you like to compare it to?

> I used to make electronic music with a program called Reason. I loved it
> because it let you drag and drop wires between different machines, showing
> you exactly how everything was connected.

Ever seen a call graph of a non-trivial piece of software? It shows you how
everything is connected, but it isn't usually useful on an intuitive level.

> But most of what we do is not engineering. Being an engineer is about
> solving new problems, and about deep thinking. It’s intellectual work.

Who's "we"? I write software when I can't find something suitable that's
already been written. I design it, work out use-cases, come up with a set of
requirements, and build it.

> Real engineers code, they say, and coding is what makes you a great
> engineer.

"Real engineers" do a lot of things. "Code" is somewhere in the middle of the
list, after a whole lot of analysis and design, and before a support cycle.
Not all people that are called engineers are engineers.

> These are just a few examples of how engineers waste time duplicating the
> same basic features over and over.

...but as meaningfully different implementations. Unless the author would like
to adapt some C code. The stone wheel is heavy and hard to carve. The wood
wheel is easier, but flimsier. The metal wheel is easier, stronger, and
lighter, but it's still "reinventing the wheel". Doesn't mean that it isn't
sometimes worthwhile.

> Software engineers are grossly overpaid

Define "overpaid". I'm paid roughly what the market will support in my area.
If the market's broken, then it's ready for disruption, and you're in a
position to become very rich when you figure out how to take advantage of it.

The author bounces around all over the place. I like the core idea of the
article (which I take to be simplifying work where possible and avoiding
duplicate effort), but there's so much slop and fluff around it that a
basically good idea is just buried.

------
ctvo
This was painful to read.

Yes, writing code is inefficient. It's unfortunate it's the best way yet to
create computer systems.

Yes, a lot of work in programming is line of business applications with slight
customization and implementing specific business rules.

Yes, it'd be amazing if we achieved something smart enough that a set of data,
business rules and requirements in human language could be used to generate an
application. That would be amazing. So would flying cars and living on the
moon.

Feels like the author has no context on how difficult their suggestions are to
implement, and the point about how we're already there because of GraphQL (?!)
and Algolia support it.

------
echlebek
Coding is not over. I too once thought as you did.

In a previous job, I worked extensively with LabView[1]. Like Reason, you hook
up wires to little boxes. This enables graphical dataflow programming.

LabView enables a person with no knowledge of syntax to write a program. It's
great! Until your program grows in size. Then, you have a very large and very
difficult to understand system of boxes and wires. Debugging becomes
increasingly difficult. Users can abstract the wires and boxes away into more
boxes, but after more than a few layers of turtles, you start wondering why
you're even using a system like this.

Later on I discovered that LabView was an instance of a "4GL" and that such
things had been around for decades. Although some have been successful in
certain niches, to my knowledge no 4GL has ever succeeded as a general purpose
programming language.

Why is this? It's because textual programming languages are far more general
and expressive. Programs written in text are far easier to change, version
control, and understand. There is no silver bullet[2].

[1] [http://www.ni.com/labview/](http://www.ni.com/labview/) [2]
[https://en.wikipedia.org/wiki/No_Silver_Bullet](https://en.wikipedia.org/wiki/No_Silver_Bullet)

------
dh8
The author's twitter says that they just graduated from a coding bootcamp. I
am not trying to silence anyone- but maybe its too soon to be making such
claims.

------
leonatan
Unfortunately, I've had several idiot project managers like that, who just do
not understand the "point" of coding, and don't understand why project
development takes as much as it does, why there are bugs, etc.

These people are not fit to be project managers. You cannot manage what you
don't have a basic understanding of and appreciate.

------
camgunz
I love this post. I think that when most apps look the same, you start to
wonder why we can't just fill in some data and regenerate the UI again. A lot
of UI builders work this way anyway: you drag and drop stuff, hook up events
to functions, etc.

Why are we still building CRUD apps in 2016? Building that with any tech is
just boring, whether it's COBOL, Java, Ruby, or node.

This is the way tool building works. You sharpen a rock so you can work with
wood, you work with wood so you can build a trebuchet, you build a trebuchet
so you can go to the moon.

I've said it before and I'll say it again. The next breakout programming
platform probably won't be terminals and editors. It'll be something that
sparks creativity, like the author's Reason example. Mobile apps allllllmost
got there; can you imagine if even 1/1000th of Snapchat users had an easy way
to program their phones?

Don't be so quick to dismiss someone based on their writing style or their
"lack of" education. This is an optimistic, creative article, and it contains
a lot of sophisticated insights like this:

> More than that, it allows for infinite “creativity”, also knows as code
> smells. Most code is pretty rank. Engineers spend countless hours dealing
> with syntax, typos, indentation, linting, errors, arguing over style and
> best practices, and making shortcuts to try to coax some of the code to type
> itself. It’s absurd. And it’s a waste of time.

That's all 100% true.

~~~
loorinm
thanks camgunz. Like I said in my post, I knew this would be very unsettling
for many people who have built their lives and identities on coding.

------
ookblah
yeah okay... i feel like the author is way too simplistic in her thinking.
"coding is over" is akin to house building is over. we know to build every
part of a house so why re-invent the wheel? why not have some magical machine
that just builds whatever we can dream of?? there are a lot of nuances and
things to think about depending on what you're trying to accomplish.

i do think we need to be optimistic about a world where coding is something
magical where you can build anything you imagine like some lego set, but there
is a huge leap between making some example todo list or implementing a basic
user auth system and a full fledged web app and i think she fails to
understand that.

at it's core ever app is CRUD, just like a house is walls and a door or a car
is wheels and whatever.

------
lsiebert
Why can't we just throw data into a database and have it optimize it?

Well I suppose we could. We could probably build a set of tools that optimized
a database of separate tables with connections between them. That's not a
horrible idea, I'm reasonably sure we do some of that, though we can still
reason about things better than algorithms can, much the same way that hand
coded assembly can be more efficient for an embedded device then a JVM and
byte code.

But the reason we can't just have such a server, graphql and the browser is
because not everyone on the internet needs access to everything on a server.
Users should have access to their data, not everyones. You need business
logic.

I think they are right that rebuilding the same parts of crud apps is a waste
of time, but often the parts we rebuild over and over are abstracted into
libraries, modules, classes, packages, gems, etc. And you need to build a few
crud apps before you see the commonalities that can be abstracted.

We aren't handcoding bytes on a wire with a telegraph key, we aren't writing a
web app in assembly, and that's because we build tools and frameworks and
languages. But those tools, etc. still need to get built, and are still being
improved, and that means the crud app you built in 1990 with perl and CGI and
apache running on slackware, while perfectly servicable, isn't as responsive
or useful as the app you build today. And even that 1990 app had CPAN... and
CPAN was an innovation. And even perl is still used today, in stuff I use
everyday, like git on the command line.

I guess what I'm trying to say is that we stand on the rickety shoulders of
giants, and being an engineer means both having the beautiful abstraction to
build grander visions and see great vistas before us, as well as to cover over
the framework with dry wall CRUD and make it look smooth, and also to climb
down and into that framework, and write compilers, parsers, databases, machine
learning code, virtualization software and software to manage concurrency
between network nodes, to create all of the pieces that we create to make
those heights scalable.

That said, I'm appreciative of them for sharing their vision, and think they
deserve better than to be insulted ad hominem, instead of having what they
wrote critiqued.

------
minimaxir
To provide some actual constructive criticism (seriously, everyone?), yes,
there is overlap in apps made today. As a result, if tech companies want to
stand out when everyone has access to the same tools, they have to code, and
code the best.

Game theory is fun like that.

------
Findeton
I'm sorry but the quality of this article is just too low for my taste.

------
calgoo
While the basic idea behind the article is very nice, its not really ready
yet. People try all the time, and you end up with stuff like SAP (which still
needs coding). I think the only way you can remove the coding (apart from
basic: click button -> do: XY) is to advance AI to a point where you can just
request an application with basic specs and its made. However, that looks like
its still a few years away.

------
Tiksi
So the future of software is basically PLC programming[1], which has been
dying out and slowly getting replaced with cheap ICs or arm chips.

[1]
[https://i.ytimg.com/vi/xfKXeLj84wY/maxresdefault.jpg](https://i.ytimg.com/vi/xfKXeLj84wY/maxresdefault.jpg)

Also some dbs already have a REST interface out of the box like Riak, though I
dont see the far more popular databases going anywhere in the near future.

------
dragonwriter
Some good points buried in here (especially about the over-glorification of
coding), but lots of wrong or irrelevant points:

> Have you ever wondered why we need a server acting as a middleman between
> the client and the database?

Well, not recently; without it you have a two-tier architecture instead of
three-tier. Two-tier architectures have been used a lot, are well-understood,
and are suitable for some applications. Using them doesn't eliminate coding,
though.

> Algolia makes a pile of data searchable. I’m not sure how they do it. But
> what I do know is, a computer is cheaper and better at optimizing structured
> data than a human is.

I'm going to make a wild guess that there's some coding going on to achieve
that.

> We should be throwing data into a pile and databases should organize and
> optimize themselves using machine learning and other buzzwords.

Building systems that use "machine learning and other buzzwords" to acheive,
well, anything often requires a non-trivial amount of coding. So, really, this
isn't just talking about a preference for a different locus of coding. Which
isn't entirely invalid (though it seems to involve a lot of attribution of
magic to tech that the author isn't familiar with the implementation of), but
is a long shot from coding being dead.

> People should not be writing database schemas, because we inevitably get it
> wrong. Database design is an optimization algorithm, not an area of
> engineering.

To a certain extent, its an optimization problem. That doesn't take it out of
the domain of engineering. And, yes, there may be tools that can be coded to
take some of the gruntwork out of doing that. And, in fact, plenty that have:
but mostly those end up being productivity multipliers for coders on specific
applications, rather than eliminating coding for specific applications.

> Product Managers should be able to just make the app do what it’s supposed
> to do, without knowing how to code at all.

And everyone should have a pony.

> The only thing a company should be creating are the things that make their
> product unique.

Unfortunately, everyone that's been there first hasn't necessarily released
all their work as open source, so if you want "like X but with unique Y", you
often need to build X and Y. Once the company that built X first -- when it
was unique -- spent the effort, they may not want to give it away.

> My current undertaking is to build an easy-to-use drag-and-drop interface,
> where anyone and everyone can construct fully-featured, full-stack apps,
> with no coding.

Coding using a visual rather than textual language is still coding. And tools
that replace some coding with visual drag-and-drop diagram manipulation have
been used in lots of places, for ages. They definitely have their place, but
they generally fail to succeed at being anything more than adjuncts to textual
programming for most serious work.

------
WalterSear
To put it mildly, I don't get the feeling that the author is much of a coder,
and is suffering from Dunning Kruger.

------
justinzollars
This author is crazy.

~~~
leonatan
Not crazy, just stupid in software development.

------
ratfacemcgee
here we go again

