It means we have a new prototyping tool. Cool. Don't worry, your skills aren't going to become obsolete :) Just keep learning and building stuff, and you'll always be very employable.
I once worked with a guy who embodied the "grumpy old man" (we were both just out of college btw) attitude for every new, cool thing I brought to his attention. I kept telling him that in order to stay relevant as a programmer in the foreseeable future he would have to stay on top of technology and keep his chops up outside of the very mundane engineering work that we did at that company. He would flatly refuse out of hand and say things like "Someone who only knows COBOL for 40 years will still have a job". It frustrated the hell out of me at the time, but he's probably right. Not saying you're guaranteed a great job or be making google-level salaries, but you have to try pretty hard to become completely irrelevant in technology. There's a huge long tail of boring business coding that happens every day, and that world as an aggregate whole doesn't change very much.
If you have even enough interest to be on this website and explore things like App Maker and question things like this, you're going to be just fine :)
I have a colleague, a graphic designer who is nearing retirement age. Every time Adobe announces a new software tool, she's partly excited, mostly terrified. Adobe likes to show how newbie-friendly these tools are. One click here, another there, and...project is done. She pays money to visit these demonstrations at conferences. Then she watches on, imagining her billable hours being redirected to an intern, the client's nephew or someone like that.
Usually the terror gets a sort of beachhead in her mind, and for a while my colleague bears the cognitive cost of this "well there's no need for me anymore" anxiety. It's really sad to watch.
> There's a huge long tail of boring business coding that happens every day, and that world as an aggregate whole doesn't change very much.
This is so true. I wish everyone fearing for their career due to new tech could understand it. Braided into a broader whole of business process you've got huge loads of necessary mental capital too, like the ability to deliver on multiple deadlines, the ability to set healthy boundaries, set proper budgets, and communicate well with others. My colleague has all these things; if only she could see new technology is only a small part, and overall a very forgiving part that needs humans like her more than we might think.
I think that people in the tech world underestimate how foreign this all is to a lot of people. We've had "form builders" in various incarnations for a long long time. Most people don't have the first clue what to do with them, and don't even want to try.
The new low-code solutions are still used by developers, just allows get to develop much faster without having to worry about UI and cross-platform compatibility and other time consuming things that take up time when building a custom app.
I'm afraid that the new generation of low code solutions are not just "form" builders or prototyping tools. We've built a full operational system and client facing portal using a low code solution.
Point out to her that her (and your) customers are not the people who are getting Adobe products and doing their own design work. The people who will take advantage of the new tools that freak her out are mostly people who are already doing it, they're just not doing it as well.
Her customers are the people who want someone to "make this work" and who don't want to mess with it themselves any more than they want to buy a big chest of tools and do their own vehicle maintenance.
Her customers are not the skilled amateurs now getting better tools. Her customers are the business people who already have too many things to do and aren't looking for ANOTHER project to add to their plates.
> It means we have a new prototyping tool. Cool. Don't worry, your skills aren't going to become obsolete
Not at all actually. There is a ton of demand for light code app builders (waves hand) for simple CRUD stuff in most businesses. These apps are usually cost prohibitive to build and maintain, so things App Maker make a ton of sense.
What happens when the business outgrows what AppBuilder can do? I would assume that's a ground up rewrite. Seems like it's kicking the issue down the road and accumulating technical debt along the way.
You see this same situation with large and small legacy systems that have reached end of life and need to be replaced. In some since the app or system can serve as the requirement for the replacement, but no one ever sees it that way. Why is the rewrite late? Still waiting for requirements! That running system over there is your requirement! Wait, that old crap? Yes that old crap.
What happens when the business outgrows what AppBuilder can do?
They use AppBuilder 2.
The flaw in your argument is that you're assuming the business grows while AppBuilder remains the same, or even just grows less quickly. There's no reason to think that would be the case. Scaling is a problem that Google and Amazon have really worked hard at solving. Plus for every business that outgrows AppBuilder there'll be 100 that don't, which still represents a huge contraction in the need for developers.
Automated code generators are coming, and they're going to be really good at writing code. If your job is writing code, learn to do other things as well.
I mean grow in complexity, not scalability. The crux of the issue, and why all of these type things fail to gain enough coverage to concern me, is business grow in complexity. Each. Individual. Business. Cumulatively it's exponential complexity. These type solutions are general solutions designed as one size fits all. In reality, that usually covers small businesses and for a short period of time. All businesses are niche.
Wordpress, Wix, Access, Oracle Applications, etc. were all thought to solve the problem of development expense and they have all failed. I mean they get some coverage, but once a business grows in complexity, they quickly become obsolete, or in the case of larger apps, configuration is more complex and error prone than developing the application.
They probably don't pivot very well either. Maybe Google will figure it out, but I don't think they will.
I don't think that for instance MS Access has failed. It was and still is a very good solution when it comes to creating line of business apps (within days) that have forms, reports and database access (for teams with up to ten members). These teams don't need anything that is more complex than that.
I don't know better solutions for developing RAD (rapid app development) apps for companies who are running on the Microsoft stack and who don't have dedicated dev teams.
Now for them Google App Maker is a very interesting solution.
Actually Google addresses these kind of users explicitly in their early access application form.
I don't think that this platform was intended to replace Frontend Development, React, Angular, etc
It is, and if you compare the resources needed to build software 30 years ago to the resources we need now it's pretty obvious we've made some incredible advances that will continue to make it possible to build software with even less.
I work in a huge company. Being consumed with what might be tomorrow is taken to an extreme. Given what I hear from other companies, this is very common. Sad part is, it never works. Designs don't ever match up with real world requirements (they match up very well to stated requirements). Anticipated changes never happen, but other changes do, and ... then of course a rewrite is needed, after attempting to get 2-3 unanticipated changes built into the "agile" design. "Technical debt", is the explanation, often without any further clarification.
We have inventory control systems that have their own database server (including disk format, their own indexing system, ...), own query language (because, ... euhm ... needless to say, someone wrote a script that dumps their own database into a mysql, and deletes and rebuilds the mysql every 2 hours, and everyone uses that to query the data. These days, even including the team that built the product). Impressive code (or I should say, impressive that it doesn't burn down our data more often). The point of doing/having done this ? It makes everyone's life more complicated, which seems to mean more reason to promote the participants.
Of course, failure of designs and over complicated designs is always seen as a reason to do more design (every postmortem, every time), with more anticipated future evolution, instead of less. Better and more accurate product managers, better and more accurate requirements (that are never going to come). I shudder to think what happens after rewriting databases from scratch has become the norm. More product managers to collect better requirements from people who don't know their own requirements. And of course, none of them ever see any need whatsoever to understand the problem they're solving.
The scary part is, rewriting database engines starting from a basic key-value store ("nosql") does in fact seem to be the norm now, even on hacker news. App-specific query languages are everywhere. People are I'm not kidding proud of doing this. Nobody seems to realize that this just isn't worth it.
Cynicals say that this is simply "CV-first engineering". Of course the database system for your company ticketing system needs to scale to 50000 employees, and 1 billion customers, never mind that you have 10 at the moment. When you go and interview at Google/Facebook/Amazon, and they ask you "what have you built", are you going to answer "a system that works really well for our 100-person 500-customers company" which runs really well on a single cloud server. They'll laugh you out of the room. (of course reality is that no, they won't laugh you out of the room)
A very interesting answer. I could very much identify with what your saying.
> Designs don't ever match up with real world requirements (they match up very well to stated requirements).
Perhaps the most important discipline in computing isn't anything related to technology, but is instead "requirements analysis". What does your company generally use to communicate and record requirements - use cases/stories/other? Are we just still struggling with the same old problem - data can be modeled easily, but not complex behavior?
> More product managers to collect better requirements from people who don't know their own requirements. And of course, none of them ever see any need whatsoever to understand the problem they're solving.
Do you think these people don't know their own requirements because: aspects of the complex underlying real-world problem or system are difficult or unknown to them; they are trying to describe something new in their imagination; the mechanism for writing the requirement is vague meaning it inevitably needs to be further decomposed; something else?
> The scary part is, rewriting database engines starting from a basic key-value store ("nosql") does in fact seem to be the norm now, even on hacker news. App-specific query languages are everywhere. People are I'm not kidding proud of doing this. Nobody seems to realize that this just isn't worth it.
How do proponents of these "custom" database engines justify them if they are not really needed? Is management clueless?
Because it's harder to read code than to write it, most freelancers/contractors a small business would get will insist on a rewrite anyway.
Sometimes this is truly justified (especially when the code comes from a $2.50/hr "coder" off Upwork), but more often it's just people wanting to do things their own way and not deal with the cruft of another thing.
I'd say COBOL is a bad example. I personally know someone hit by that so bad he became homeless and ended up spray painting street numbers on curbs for money.
I've never understood how that could be possible. What makes COBOL programming so different from work in any other language as to make it impossible to pick up, say, C? I've heard numerous similar anecdotes, but never from programmers who struggled to transition from any language but COBOL. I'm sympathetic, but never having worked in COBOL myself, I can't help but be curious what makes it so distinct.
I spent many years working with COBOL & CICS on AS/400 and mainframe and PC.
COBOL is such an excellent high-level abstraction from the computer hardware that it's almost pseudo-code and one can translate business requirements very easily, but therefore working in nothing but COBOL isolates a developer from underlying technology and trends.
I wrote a few algorithms in COBOL, basic sorts and trees, which was really awkward and whilst it can be forced to do other tricks such as data compression and encryption[0] it's really not conducive to such tasks. As a result it's easy to sit in a COBOL-bubble writing IF...ELSE business code all day long and not do anything computer-sciency until the memory and skills fade.
Thankfully my COBOL programs called down to C programs to do nitty-gritty work otherwise I'd probably have been pigeonholed both in skills and career; many companies seem to ignore COBOL experience as 'not proper programming', for the reasons above. However being one of the few people dealing with the old COBOL code gave me huge experience in working with the business clients.
[0] we had one vendor offer us AES-in-COBOL for scary amounts of money.
CObol is the epitome of a walled garden. Everything from accessing data to ui is done the cobol way. Simple things like arbitrary length string and dynamic memory allocation aren't in standard cobol.
Many companies used to run cobol bootcamps to hire developers. As recently as 2004, one local company was still doing them here. Very few of their developers studied cs in school. The boot campers studied who knows, and those who studied computers often majored in cis or mis.
So you can see how those people are really starting off at zero when it comes to switching to more modern dev stacks. I've personally seen very few make the transition.
My first paid dev job was at such a place, doing mainframe cobol, but I'd been doing hobby programming since I was 12, and writing games in c++, so I wasn't typical. I completed a bs in cs at night and moved on.
> you have to try pretty hard to become completely irrelevant in technology
Agreed. I don't know how it is in other countries, but most currency exchange offices I have seen in Romania use FoxPro software running on an MS-DOS equivalent. I haven't used FoxPro in the last 20 years, but some people still make a living with it.
[Now that I think about it... I have actually written a small program in Visual FoxPro last year to interface with a .NET application... huh.]
>Just keep learning and building stuff, and you'll always be very employable.
This is true, but there are a few caveats.
The one that I've been running up against most recently is that a lot of this new-fangled stuff does not really have a strong value proposition, and I personally do not want to waste time on it.
This has become especially true since "cloud" hit critical mass. Junk seems to get generated 20 times faster than it used to and see much wider adoption. GitHub profiles are now status symbols and everyone feels a need to have a bundle of their own showpieces to display.
A lot of the fads are totally perplexing, from the perspective of an engineer who is more interested in building a robust system than padding his resume. JavaScript on the backend (or, even more horrifying, the desktop)? Single-page app frameworks like Angular for everything, including very simple pages? Why?
Yet, it's hard to find a web-oriented position that isn't asking for a background with some SPA and some Node.js. Maybe it's a fad, but it's still going to impact your job prospects.
The takeaway: stay on top of fads and new tech, even if you resent it and think it's really dumb.
I had the same experience with Rails; I hated so much about it and put off getting serious experience with it for 4 years or so. Turns out I still hate it after years of usage, but it was much easier to find work, both as an employee and a consultant, when I had significant experience in the fad.
Didn't matter that I was learning all kinds of new tech that I thought was interesting. As much as one may hate it, it's usually best to bite the bullet and ride the market's waves.
The most frustrating one today is Kubernetes and Docker. Ansible was so beautiful. I hate Docker with a seething passion (not necessarily other container systems), and I see Kubernetes as a very rough toolkit for people who have Google-scale problems that no one should be trying to make for themselves.
Other caveats:
* sometimes techs DO go extinct. Though COBOL is not quite extinct yet, I've known COBOL coders who have gone years unemployed (that doesn't happen to anyone who knows a language/stack still in wide circulation). A small niche has pros and cons, and one of the cons is that the supply:demand ratio is fickle, and may not always be in your favor.
* It is very rare that your technical qualifications will be so unique that they will take precedence over your personal and political qualifications. This is something most developers try to dance around, but the fact is that tech is ultimately run by people, and they want to be comfortable more than they care about that loop's runtime. If you're looking for something that will confer huge career benefits, the odds are that improving your people skills will be more valuable than improving your technical skills. This is almost universally true. It's especially true if you think it's not.
I'm like you; I looked at Chef and thought "WTF??". I looked at Puppet and thought "WTF???". I looked at Ansible and thought "ahh, yes! they get it!"
Most of the application stacks I see that are popular I think of as being invented by people who didn't bother to look around at what had already been tried and rejected by the previous generation.
Caveat I don't build apps that need to scale to millions of users.
Yeah ui frameworks. has anyone else noticed that yahuda Katz seems to have been completely unfamiliar with any other ui framework for the past 20 years? For example the superfluous stuff removed from 2.0? Sure the browser has unique requirements, but sheesh.
I tend to agree that a lot of the new-fangled stuff (aka. hipster shit stacks) are generational/cyclic re-hashes of previous techniques, but unlike previous generation don't even attempt to adhere to standards or otherwise appeal to ideas such as separation of interface/implementation and interchangeability in general. Supposedly, that's pre-generation POSIX or Java-ish greybeard stuff and we're living in a post-standards era after all.
But I think you should re-consider Node.js. JavaScript is based on an ECMA-specified (ISO-adopted even) language with at least three major implementations, plus smaller (yet still highly regarded) ones. The Node.js API is (loosely) based on CommonJS which is as good as it gets in terms of a community API standard for JavaScript.
Genuine question. I'm not a fan of it either, after working with it for two years, but I can't quite explain why. Maybe it's the "magic" aspect of it, since so much is convention, DSL, and hidden away.
Yes, "the magic" is usually the way it's summarized. Everything is expected to be done exactly their way. Your code is interpreted and modified by Rails to fit its pre-conceptions and assumptions about your program. Neither the framework itself nor the support structure around it are forgiving if you deviate, no matter how justified the rationale.
One of the most prominent examples I remember is developing a form and explicitly setting the form's method in the Rails code, of course precisely according to the documentation because we know how picky it is. However, because of some minor detail in the content of the form (which I unfortunately don't remember specifically), I found that the Rails JavaScript was overriding me and dynamically changing the form's method when the form was submitted. I had to hack in the middle there to subvert that event.
It took forever to track that down, something that should've been so basic and simple. This is exactly the kind of anti-feature that developers resent: it's supposedly there to make things "easy" by assuming you meant something, when you've taken pains to say that you did not in fact mean that because you assume it's going to assume you meant that. When you complain, the Rails community blames you for not believing in magic hard enough.
That's emblematic of the entire Rails experience; it's just one example among many. We all know that any moderately-complex program is going to have unique requirements and want to do things that are a little out of the ordinary; if it didn't, you'd just be using something pre-built like Wordpress.
When you get to that point, you're going to be tearing your hair out and fighting Rails the whole way, as it insists that no, you didn't mean that when you explicitly defined it in the place the docs say to explicitly define it; you clearly meant the thing that Rails says you meant.
It'd be one thing if this type of behavior was acknowledged and respected as a bug, but it's not. The response you get is usually along the lines of "Well, why were you trying to disobey Daddy Rails? You are a very naughty coder. DHH could surely beat you in a street race, and you probably haven't even read REWORK." The Rails community is a cargo cult.
Rails is not to be introspected or customized. It is only to be appreciated and praised. After all, you are not as successful as 37Signals, are you?
And don't you like magic? Are you not entertained? Magic won't work if you change all the stuff. Don't ruin the magic! The great visionary DHH has come down with the visions of what web applications should be. Do not defy him.
They try to cover all of this up by saying that they believe in "convention over configuration". This means that if you question Rails, for any reason, you will be punished for your insolence. They truly despise heretics.
That's not how frameworks are supposed to work! I sometimes don't even like calling Rails a framework because it's so rigid. Frameworks are supposed to give users the tools and flexibility they need and then get out of the way.
If I feel like I'm writing Ruby (or whatever the base language is) and the framework is just helping me get that code onto the web (or provide whatever the framework's function is), then I'm happy. If I feel like I have to write in a special framework-specific dialect, then it's not a framework; it's a platform, and I'm writing a plugin for it.
I think this revulsion from big-magic black box "frameworks" like Rails and CakePHP led to the rise of "microframeworks", or "semi-reasonable ways to put code behind a web site", as normal people call them. ;)
I once worked with a guy who embodied the "grumpy old man" (we were both just out of college btw) attitude for every new, cool thing I brought to his attention. I kept telling him that in order to stay relevant as a programmer in the foreseeable future he would have to stay on top of technology and keep his chops up outside of the very mundane engineering work that we did at that company. He would flatly refuse out of hand and say things like "Someone who only knows COBOL for 40 years will still have a job". It frustrated the hell out of me at the time, but he's probably right. Not saying you're guaranteed a great job or be making google-level salaries, but you have to try pretty hard to become completely irrelevant in technology. There's a huge long tail of boring business coding that happens every day, and that world as an aggregate whole doesn't change very much.
If you have even enough interest to be on this website and explore things like App Maker and question things like this, you're going to be just fine :)