Coding is Over
medium.com
medium.com
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.
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.
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/ [2] https://en.wikipedia.org/wiki/No_Silver_Bullet
These people are not fit to be project managers. You cannot manage what you don't have a basic understanding of and appreciate.
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.
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.
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.
Game theory is fun like that.
[1] 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.
> 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.