coolsunglasses - Why did Datomic seem slow to you? Can you describe the problems you had in detail? I'm not from Cognitect, just someone who is developing some prouducts that currently use Datomic among a few other databases.
Would love to hear some honest feedback. Maybe your struggles were because of the tech, earlier versions, bad hardware config, or mis-applied use case?
I agree with you mostly. Although you are right that most people who steal phones probably would not to do this, thieves and others are becoming more aware. Thieves have friends too and some are even technical, especially people who specifically target phones. Also consider how many people forget they actually have certain accounts. It's not hard to use these accounts as the keys to more things or to use as social engineering tools.
As for the frequency of lost phones, I think it happens more than people know. Ask a friend who works at a restaurant, hotel, store, etc. how many times people accidentally leave or drop phones. With all the things like payments, passwords, personal information, etc. tied to phones, these are becoming treasure troves for people who have any idea of what they are doing. On the plus side, people who don't know what they are doing and spend time online on a stolen phone might be caught easier if the thieves have an idea.
While I agree with you, at least in part a few problems here as mentioned by the previous replies.
As far as N0tch, I think that's a bad person to compare yourself against. While I can respect what he achieved and envy his good luck, he is hardly what many would call a good programmer. My standards may be different than others. He may code fast compared to some people (and slower than others), but code speed/output != productivity. Judging by the state of Minecraft and bug counts of what he's done, one could do the same by shifting emphasis or priorities on getting something usable vs. bug free. It is more correct as you imply that other things are just as valuable or perhaps more. It all depends on context. N0tch might be a great prototype programmer, but a terrible programmer for writing banking software and sending things into space. We still don't have many good ways to judge people, which is why dumb managers look at things like lines of code or total hours.
Indeed we know that many factors influence productivity - familiarity with the task and technologies involved, language choice, library choice, deadlines, environment, external influences, and so on. This sick culture of work will make you free is not a good one. I do believe though that many good developers who can work together in a group (very important) are better than having 100x as many people who are bad coders. It really depends how big or small a team is, how it is managed or not, and so on. Having a team of only the best coders isn't enough and can actually seal the doom of a project.
3. No, judging on stars is ridiculous. A good library is a good library. Perhaps stars may catch people's attention, but honestly anyone professional I've ever known doesn't even remember to look at stars in the UI. Better to look at other things like the actual code and commit frequency and contributions to see if it's still alive.
4. This is not at all true. If you send me a link to code to look at and it sucks, I won't hire you. Perhaps my perspective is skewed since I rarely ever hire people who I have to teach computer science 101 to, rather I take only people who show promise, have the tools, and simply need to put in the time. Your work is completely reflective of you, so please just don't throw random bad code and call attention to it. This is terrible advice.
Anyway, I think you missed the point of my next list. The point is that you give these things long and hard thought. You do them one day if you get there, and you mess around for a few weekends. What you don't do is dedicate years on these projects unless you treat it like a video game in terms of fun level.
1. This is why you take a class in writing an OS and screw around for a few days. This is different from writing an actual OS.
2. Same as #1.
3. New databases are often being written and they are bad. A lot of the new databases are simply layers on others, not true databases. As for this issue, again, it's something that requires careful thought and experience. You better be solving a problem and be solving it well. The fact that things are written is not justification to write them. Notice how so many of these are written and not really used. Notice all the problems created, abandoned projects, and catastrophic design flaws that creep in later in the projects because of lack of planning, thinking, and ability. I've contributed code to some of the biggest databases out there and I don't feel qualified to write one myself. Sorry, but this is another skill beyond most people. If you've ever worked with someone who really gets this type of programming, you realize they were born to do this. You may be a better programmer than them in everything else, but DB, OS, programming language people who are good are super rare.
My lists are not narrow-minded. You can philosophize about how little Johnny can do anything. I speak more in terms of actual experience and reality. It is better to tell it like it is. You can write whatever code, whenever you want, just be reasonable. Build things you and other people want to use. Do not build hacky, half-baked things that waste time and repeat history. Following this advice would probably eliminate a good majority of the bad projects out there. If you can't see that, I am not sure where you've been working all these years. I've worked with some brilliant people, and especially the ones who did these things would tell you the same.
No, making more languages is not a solution. If your language solves a problem that others cannot do as easily, great. The point is that even if you succeed on one level, you can create messes. One of the largest problems we have today in computer science is all the mess of poorly constructed languages. Just because something is widely used does not make it good, rather there are other realities like popularity contests, luck, press, etc. at work.
If you read my comment, you'd see that I didn't write no one should do it, just that there are only a few people that should. You can create your own language or DSL like thing in your spare time. Just don't spend thousands of hours on it and push it into the public. Without naming names, there are quite a few languages that we would be better off in many ways if they did not exist. Some of the authors of these languages have admitted as much and I am pretty sure they know better than both of us.
There's a difference between academic messing around vs. putting out something there with the presumption of knowledge. Making languages is a very hard thing. If you don't understand why this is true, you are probably one of these people that should not make a language. Sorry, but it does more harm than good 99% of the time. At best, the language gets ignored, at worst, it becomes popular enough in a half-baked state.
Let me also add some more specifics for your case:
1. Program whatever you want. Don't go for popularity. If you don't do what you want, then you won't finish.
2. Corollary to the first item, finish what you start.
3. Anyone who judges on stars as an idiot. I will use the sweeping brush. In the same way it's hard to make a hugely successful startup, being good and being popular are two different things. Without naming languages, frameworks, etc., I personally find a lot of the most popular stuff to be among the worst tech wise.
4. Consider making some of your projects private if you are really that worried. Github is for open source, public collaboration. Although it provides private accounts for pay, I am not sure it's always the best deal financially. If something needs to be private, then hosting on a public service may not be the best idea anyway. Either self host, or at least comparison shop. More generally, don't put things out there you don't want people to see. I'd even add people need to stop putting things out there that are not worth seeing as it just makes it harder and harder to find what is a toy vs. a real project.
5. For Github profiles, mainly I look at what I mentioned in my other post. Code quality over quantity, good behavior, and claims match reality.
Finally, I will add that you should not take on things that are too ambitious. While it is good to challenge yourself and you learn, it is much better to take on projects you can finish. This is a hard thing because it requires motivation and the related skill of picking something that is challenging enough to keep it interesting, but still feasible. I say this as the author of multiple past game engines that I never fully finished and released for instance.
I often tell colleagues the following rules about projects in general (again, challenge yourself within reason and for mental exercise, but consider below general statements about programmers):
1. Don't make a programming language. You probably aren't the guy to do it. There is most likely exactly two people in this world in every generation qualified to do this well and you probably are not one of them. Unfortunately, many people have made programming languages who should not have without naming names.
2. Don't make an operating system. This is hard. Really hard. Same points about #1 hold, only you probably also need an army of people helping you to do this right. Obviously this may not apply for some small scales and it's find to experiment, but your OS isn't going to change the world. No one will care about it and realize that the software usually makes the OS, rarely the other way around. There are a lot of abandoned/nearly abandoned OS code-bases that are much better than anything we use, but they didn't have developers, weren't cost effective, etc. Console wars have shown the same thing in the past.
3. Don't make a database. You probably will do it wrong. Your database will be fast and fix all kinds of problems the past ones had, but when you start adding in the real features, things change. Soon you will realize that your database now has similar problems to the ones you wanted to fix because as you had to do things like transactions, clustering, backup, logging, and so-on, your optimizations could not work anymore. A lot smarter people than you worked on these problems a lot longer. If they could have magically fixed many of these problems, they would have. While it's true legacy code and corporate politics get in the way here often, that doesn't mean that the same won't happen to you. If you do need to make a #1, 2, or 3, please sit on it for a few years first and talk to people smarter than you before you start. And don't neglect security either.
4. Pay attention to the past. Someone probably made what you made many times before. The first or second time was probably the best, but everything since has just been worse with the benefit of faster hardware. Instead, just simply dig up the past if you must and do what they did in a modern context, giving acknowledgement and credit where it is due. Learn from the mistakes of others as well.
5. Whatever you built is insecure. Ask a security expert or 50 to review it, and then get some coffee because you probably have twice as much work to do to fix it as when you first built it. Better you ask these people before you even write a line of code or at least very early in the process, or hell will descend about you quickly.
Well honestly, that part about Github was a bit of a joke grounded in some real-world experiences. Mainly I was just referring to people who act mighty about something that is in essence, nothing. Further, I am referring to people who obviously are struggling over basics, but are not humble enough to recognize it. Amazingly, people love to brag about things they are actually not skilled in at all.
As for public facing programming-related artifacts and sites, I don't think it's a good idea in general to judge people on things like Stackoverflow, Github, etc. It's not that I don't at all and not that my colleagues don't, but rather we place appropriate weight. Mainly when we asks for things like this, we just want to see what your writing and code looks like to get an idea. If a candidate said to me, I don't have a Github account or I have better code I can send to you, then that's fine. There are so many arguments why judging people this way is bad that I would end up writing a book in reply.
This is why sometimes we'll do a coding test regardless because then we can at least have greater confidence that the person actually wrote the code we are looking at and that they are capable of executing the type work we are interested in doing. Even for coding tests, we mainly put weight on the explanation the candidate gives rather than the code. You learn a lot about how someone understands problem solving by asking them to explain their code and walk you through it. Moreover, it helps weed out the cheaters, pretenders, and liars, of which there are many.
Regarding your case, I would never really penalize someone that harshly based on their commit history, at least in isolation. As you explained, there are many factors at work. If a candidate explained why there were so many commits and 3 months ago, he did x and then now he's doing y, I wouldn't care. I would actually just look at the explanation itself, rather than the commits.
Be wary of any employer that cares too much about your Github. Although one should be humble in interviews, you also to a small degree are seeing if the company and people are a good fit for you. If the interviewer is placing too much stress on things you feel are irrelevant, it may or may not be indicative of other future problems with them. I have noticed for instance that people that I have co-interviewed someone with sometimes become very antagonistic when they feel threatened by the person they are interviewing. That is, their ego gets in the way of doing a constructive interview.
If I had to pick specific things I look at when viewing anyone's work including Github:
1. Clean code with a consistent style. This is rather subjective, but I think that most of us develop a feeling for the things we want to see. A good developer searching for other good developers should recognize that good is not simply coding very similar to yourself, but rather that the code has easily identifiable merits, even if you disagree on some choices. Simple things like namespaces and following the standards of the language are easily identifiable and hardly debatable.
2. Understands the material. In the case of Github and your commits, part of that might be understanding how to use git. Things like rebase vs. merge come to mind, cleaning commit history and branches, and so on. We all make mistakes and do stupid things like use git to move things between machines to get something done fast. It's fine, just keep things tidy and use the tool properly most of the time (preferably all the time obviously). If it's a programming language, don't write Lisp like C++, don't write JavaScript like Java, and so on.
3. Recognizable that it is actually the person's work and not plagiarism. Bigger problem than you may think.
4. Obvious that something of value has been created. I've seen a lot of node.js projects linked to me by candidates that are in essence doing nothing but wrapping something else, then outputting it to a pretty UI that came from someone else, i.e. Bootstrap. A lot of this can be fine, but there better be a point to the project and the description given by the candidate should match reality. If it doesn't, it just feels like bs or a lie. It's OK to use tools like Bootstrap, but just don't take credit for those parts as if you did it all yourself, from scratch in assembly or something.
5. Good behavior. This can mean a lot of things. For example, how does the candidate interact with issue submitters? Is the documentation broken? Do they seem to post a lot of crazy, false, ridiculous stuff everywhere (your language sucks type stuff, sweeping false generalizations, etc).
Regarding hackathons, I've felt much the same as you. I let many of my team members go to these events to keep them happy, motivated, and to network. I have met many people from these events, brought them in for interview, tried to find people to start a start-up with, and so on.
Full disclosure - I've only gone to hackathons to accompany co-workers to provide advice and to network, I don't have any desire to actually participate.
Anyway, my general view on hackathons are they are a waste of time. If you want to learn something, learn by doing a real task, not a contrived one for a hackathon. If you are taking a more practical idea into a hackathon, sit on it, use that time to think it through, and build it on your own time, rather than in a noisy room. I get that people want to network, that they need motivated, and that constraints/goals/focus can inspire them, but I really feel that in software development, that's just people looking for an excuse. If you want to build something, build it. If you want a constraint, write it on a piece of paper yourself and follow it. If you lack the creativity to make something without the help of a hackathon, you are probably a lost cause anyway.
You can experiment with that new technology yourself. You don't need the group to tell you what you are doing is right or cool. The group is often wrong or misguided. History is full of bad group think. The way I see it is that if you are really a computer scientist, look at your computer and the world around you for a few minutes. You should easily see thousands of problems that need to be solved or can be solved better. It doesn't matter if it is polishing an old tech or a crazy new idea that throws out everything we learned before. I have more problems to solve than I can handle in a lifetime and I cannot imagine wasting that time at a hackathon in that kind of ridiculous environment.
You mentioned that there is definitely a bro/framework/money culture and I agree. Look at all the "schwag" and advertisements at most bigger hackathons. People want you to buy things and to use their stuff. Putting time constraints on people doesn't make them automatically more creative, often it just forces them into using whatever framework because of the nature of the hackathon so they can get something complete. This is constraining creativity usually, not encouraging it. This is not some romatic story about a lab deep in the bowles of MIT where the next great clean energy will save the universe, it is a gathering of guys trying to out muscle each other's egos. The bros will dominate because of this and will always be there in some form.
Check the experience level. Notice that a lot of great programmers don't go to these events. Why? They are working and don't really care, and nor should they. If you want to have some fun with people, start asking your colleagues and friends why they are going to XYZ events, hackathon, whatever. Strangely enough, most people I have asked can't explain and give reasons like free pizza, chance to win an ipad, or to hear a presentation about ABC technology. Is it worth losing a day of work or the weekend for that? Can you not read things in more depth at home or even just watch the video later? What is the point?
The point is perhaps to just participate in more group activities and feel part of something. There are similar reasons why people go to religious services, join fraternities and clubs, and post on message boards. People like meeting like-minded people. When a dominant sub-group emerges within a group, it becomes the group and usually drives out the fringes. I remember older and smaller versions of hackathons and meetups at people's houses, garages, etc. in decades past. It was really the same thing where bad actors eventually dominated, and perhaps for awhile there was a period where it felt fun, then stopped. Very little has changed, only scale and the way the same personality types manifest themselves in the context of the time.
Don't get discouraged by these people. They are everywhere, in every sub-culture. If they want to call themselves stupid terms like "hackers" instead of software developers, so be it. If companies want to be idiots and put up job ads calling for "rockstar programmers," just ignore them and take it as early notice that working there would probably suck. If someone wants to shove their glued frameworks in your face and claim they are awesome, just point out exactly what they have done and how simple, or better yet, just do something better yourself. You be the example, and you be the good guy.
But yes, you are right, I hate these people and I too feel they are unethical with stupid ideas that advance nothing. I think this shameful bubble of valuations of companies that don't really produce anything including actual revenue based on something real (ads don't count, sorry, if advertising would die and take 98% of the internet with it, so be it) need to die a quick death.
It is very mature that you want perspectives and I appreciate people who are not afraid to say what they mean. You touch on a lot of hot topics here including agism, hackathons, "hacker" culture, brogrammers, and so on. I'll try to write a few replies to address your concerns.
I am one of these "older engineers" as you describe. Mostly I am well-respected by anyone who works with me because I tend to intimidate, but also be very helpful and mentor people. I do feel a lot of disrespect from younger people I meet in the industry. I actually look extremely young for my age, but I can hardly pass as a 22-year old.
Anyway, I'll start by discussing your generation stereotypically. I've been hiring people from universities for a few decades now and I am increasingly disappointed as time passes. Maybe I am just becoming a grouchy aging developer, my patience is wearing thin, or perhaps what I see is just reality. When I hire someone, especially out of school, I never expect them to know much about XYZ technology we use, ABC framework, or anything else I am using at the time. Simply, I look for smart people who I think my team can get along with in the workplace, are at least a tiny bit motivated to work, and are honest in every sense of the word. I learned the hard way it's better to hire someone who is a good, honest, hard worker than someone full of great ideas that can't execute or pisses everyone off each day. Unfortunately, I find myself disgusted by the type people who show up for interview and that I have to deal with from other companies. I do not ask for much.
Perhaps in the words of William S Burroughs, a few "words of advice for young people" are needed:
Do not turn on your cell phone during an interview, show up on time, do some basic research about us before you arrive, understand at least bullet item we wrote on the job description, etc. I'm not your dad and most definitely not your bro. Do not show up to the interview in your free give-away Angular.js t-shirt you got. That technology or framework you are named dropping and then trying to use to feign knowledge about? Well, you aren't fooling me, I probably used it or read about it, tried it, and realized that my instinct that it was garbage was true. I use more new technologies than you do because I am doing actual work as I have done for decades. Just because I am older than you doesn't mean I don't understand Ruby. Just because I don't seem impressed by your node.js github project doesn't mean I don't get it. More likely I am not impressed because your code is terrible and I am shocked that it took you so many weeks and commits to do what you would be expected to finish in 1 day at our office.
Remember that class where you decided the professor was as a-hole and that it was just too early in the morning to go to anyway? Was it called data structures 101? Well, it's going to bite you one day when you interview with me and you can't tell me when you would use a hash table and when you would use a list. Remember when you interviewed with me and you didn't get the job which you thought it was because I just didn't like JavaScript? Well, you are wrong, you did not get the job because you could not explain basics in JavaScript, your favorite language. Go ahead and criticize us for using Foo technology, because even though it's rock solid stable, works great in real-world production, and is making us millions, we were waiting for you to tell us to rip it out and replace it with Bar, which your buddy just put up on Github yesterday. But that's OK, because we're a lame company, and everything is our fault. We just need you to turn the ship around, so by all means, act like an idiot because there is no way we can live without your genius.
Do you want to impress me? Tell me what you know. Explain to me what will make you happy and motivated you. When you do not know something, admit it instead of trying to bs me. I hear enough bs from sales guys, marketing people, and VPs of the department of nothing to recognize bs before it leaves your lips. When you do not know something, do not give up. Tell me how you would do it differently or how you would go about finding the solution. If I give you hints or part of the solution, use it or even ask me for another hint. I am trying to help you because I am tired of interviewing people just like you. I want to hire you so I can get back to coding. I have already seen ten of you today, and I am currently considering offering a 5 million bounty for the next person who can sit in that chair and have even 20% of what we need to do the job.
You can be relaxed, just not too much. Most developers who have been at it for awhile really need to stay relaxed and do not take everything too seriously. You can have fun with us and talk to us. That does not give you a license to fool around, act unprofessional, or like an idiot. This is a job, and it takes very little else but hard work like any other job. Things are done by doing, not talking. People worth impressing are impressed by actions, not words.
I build whole systems, and have had specialized jobs ranging from 3D game programming to Machine Learning to Rapid Web App Dev. I've observed many the opposite. I would agree that interfaces have lots of moving parts, but part of what you try to do there is to reduce the complexity because it often means you are passing on too much to the user. I suppose there's a bit of Apple philossphy there.
Just cron jobs and REST APIs? Regarding cron jobs, we generally try to avoid them because communicating with them, getting good information, maintaining, and so on sucks. While I've written tons of cron jobs and still do, it's probably 1% of what I've observed happening in the back-end and usually a sign of a duct-taped system. This excludes baked-in unix tools that are actually supposed to work that way of course, rather I am talking things directly involving apps I build. As for REST API, not everything needs to be or should be REST. It introduces all kinds of extra layers of auth, slowdown, caching issues, and so on. For some domains, REST is a bad idea. Of course we use it where it makes sense, but it's not just some magic thing that is and should be used everywhere and anywhere to be representative of the bulk of back-end. Most REST services are built very quickly, it's rather the logic behind them that takes a long time.
As for concrete things I've encountered that are actually complex and happen in traditionally the back-end, I'd say none of these are straight-forward:
1. Caching - As it goes, other than naming, this is one of the most difficult things in computer science and happens everywhere in a good application, front, back, let, right, data, service, whatever.
2. Machine Learning, Sentiment Analysis, Analytics, OLAP, etc. - People forget that a big part of building a system is getting information back out of it.
3. Orchestration - this is hugely complicated. So much so, Microsoft created a very complicated and misunderstood product for it (BizTalk). Doing orchestration is still something no one gets. It happens in millions of forms and related manifestations.
4. Deployment - Versioning, machine provisioning, cluster management, and so on are all very complicated. There are tons of these things that fall under what many people call Dev Ops now too as well. I have yet to see magic here in any app. I challenge you to deploy a running system that is accepting live data transactions, then seamlessly roll it back without data loss, down time, corruption, weird states, unforseen bugs, and so on. No one has done this in full which is why this area is becoming increasingly full of solutions and start-ups. Whether it's Google App Engine, Azure, Heroku, your in-house AWS scripts, Chef, anything, I am telling you no one really does this 100% right. Supporting a real app is just as important as the app itself, and often the two have to communicate and be written in ways to make this work.
5. Streaming - Building streaming related back-ends is anything but simple and plug-and-play. No, I am not talking about streaming Tweets.
6. Data Migrations/Updates/Changes/Flow - Very important part of dev, and usually one of the top 5 time sinks. Complete nightmare and again products and libraries that help, but no magic bullets to be found here other than doing the work and putting in the time. As for simple cases, almost everyone deals with getting data in X form, transforming it to Y, and having it change form again after getting a reply from Z service. A huge part of people's time is simply manipulating data structures, at any place in the system and a reason why I tend to favor Clojure for web apps that don't need to be speed demons. As for migrations, ask someone to do one, then double or quadruple their estimate, sit back, and watch.
7. Authentication/Authorization - The world runs on more than just OAuth and Social Auth. Try dealing with people that have secure systems or many other systems that you need to communicate with, especially across network boundaries.
8. Legacy Integration - Happens all the time. Especially when you build a shiny new app very fast, then have to roll out v2 that actually scales. Beyond that, try any business that has been around 5+ years and actually makes money to see just how horrid this can be.
9. Data modeling - If the scenario of ABC person created XYZ app which now struggles to do Foo new thing without huge pains, you haven't worked on apps long enough. Data modeling mistakes and limitations are one of the single biggest problems and time sinks. More obvious examples include simple facts like having to dupe or dump data into other places to consume it the ways people actually want. While your shiny normalized tables with a REST service might work well for returning a simple list of customers, as that list scales and you realize you now have a new place where you need 2 fields from here, 8 from there, and so on and it needs to happen in 100ms or less in total back to the user, then you are in for a treat.
10. Logging - in big systems, the code here can be non-trivial. Often this means more than writing to a log file, but rather providing visibility into parts of the system in real-time or close to it.
11. Scaling - Everyone thinks they are doing this right until they don't do it right. This can involve anything from servers to message transport format to compression to memory management to clustering.
We could do this all day, but hopefully this makes a point.
Not trying to pick a fight, but again your team comes off as naive and essentially gives the middle-finger to probably the majority of the software developer community with comments like these. It seems like you guys simply have not worked on an actual complex system of any significant size or over-value the complexity of front-ends. I personally respect all facets that go into making software.
Anyway, I would argue there's no easy part and dividing things into monoliths at a conceptual-level is a mistake. Putting that aside, whatever part is comparatively (key-word) easier is highly dependent on the implementer. For instance if I build a system that just needs 1 input field, but then performs some sort of machine-learning or triggers some complex background dispatching, then that system is arguably much more complex on the "back-end." I think making big distinctions is a source of trouble to begin with and regardless I do about equal amounts of front and back-end work on my current start-up.
As for the special sauce, in many apps the special sauce is actually the back-end. I would agree everyone hates with dealing with 3rd party libs and so on, but the ways you deal with that information is important. I think the way Treeline is described in your website, this article, and video makes weird distinctions and conflations between what is front and back-end work and what are actual problems programmers actually have. I totally get the parts about plugging into another API and not having to write the fetch code, but honestly with a library or two or even implementing integrations with many libraries, the work is minimal. Adding the correct libraries is often an important choice.
To give you a concrete example, I do most of my current work in Clojure followed by Haskell, Java, and C. The choice of library authors doing things like using non-standard data structures that I then have to transform or directly consume, using/not using things like async channels, and so on from the ends of their APIs is a huge deal. It's not normally a problem to find a library that works with how you want to do things, but rather important that you pick the right one from the list of choices. If a Clojure library forces me to consume a core.async channel, I might not do it because I want to use something more general like a transducer to abstract that away.
Sometimes also the ways that I consume someone else's library are very unique to my app and provide a crucial difference aka special sauce. Consider for example that for years I had a client that had a huge advantage due to code my team created against some public APIs because we were able to stream, batch, and thread our interactions with this particular API in ways most people had not thought of or implemented. The fact that our integrations were based on self-calculated heuristics provided dramatic speed-ups over everyone else meant it looked like we could do things that would cause the client's competitors to think we had some special deal or wonder how it all worked. This is not unique to us, rather it is simply illustrative of the importance of optimizing your business activities in the back-end. Consider that most of wall-street high frequency trading as another example is based on this notion. While I am not claiming that everyone needs to do this, your generalization is the issue here.
It is funny because maybe our definitions of "back-end" are the issue. I tend to notice that the wheels on the front-end are invented time and again. How many different UI frameworks, patterns, controls, etc are there that get implemented from scratch? How many people end up composing their apps out of little more than paging, showing pictures, textboxes/checkboxes/pickers, form validation, css positioning, animation, and so on. I'd argue these are the actual repetitive bits that are tedious to write.
I am reminded of criticisms of forum software by the authors of discourse. They pointed out a lot of the special sauce things that were wrong with forums, but ended up pissing off a lot of potential users who thought at least the versions in the past few years were essentially a lower functionality version of the same things with fancier loading and scrolling using JavaScript and JS templating. And the critics were at least in part right because not much new was brought to the table beyond looking and feeling slightly better on some basic elements, but the nature of forums software as we know it was hardly shattered so far.
It seems to me what you've noticed is that a very particular segment of node.js users who used sails or were involved in the node.js ecosystem were reinventing the wheel or didn't understand the wheel. This is fine as you clearly are trying to address this problem, but you are also making blanket statements about software development. Everyone I have worked with who I consider to be far smarter than me would agree that a common mistake a lot of people make is they think any part of software development can just be replaced by a magic wand wave and that xyz part of the system is just stupid, tedious, and simple. It's like that time before you reach the point in programming where you realize it is not that your code is awesome, it is merely that it sucks slightly less than the next guy's code due to your experience.
You guys really need to focus on the concrete things the product does not on philosophical nonsense of magic software development. Presently it just seems like you've made it easier to wrap some node.js APIs, call them in an opinionated way quickly, and slap a visual front-end that includes some canned forms and an impractical editor on top.
I really also have to question the attitude of the founders. I found a lot of the quotes out there about this product insulting. "Building the backend, however, is like stacking wine glasses: it’s not that hard, but if you make a mistake it’s a bigger issue to deal with." If building a back-end is not hard, then why do I need your product? It should just be easy as long as I test it and do a lot of checking to make sure the wine glasses don't fall. What makes me think that the founders of all people are the ones I should trust to make these decisions when the pitch for the product is insulting the people who actually build solid back-ends? I've built a lot of back-ends that people actually use and not once has it been an easy task. Even the jobs that took me less than a day I would never say were easy; perhaps I simply discovered humility and actually lived long enough to see what happens to systems 10+ years after they are used by real people.
I would also apply the above to front-ends - they are never just "easy." But front-ends you can mess up and fix them without too much catastrophe beyond perhaps annoyed/lost users/etc. When back-ends fail or are designed badly, we lose data, ability to gain insight into our business, can't satisfy company/client requirements, and so on. These are much more serious consequences than your app not being responsive or shiny, or looking like it came from a wannabe Craigslist fan. Both are important to success, but let's not pretend that our apps could be the next Google if we could only sweep away that pesky back-end. It seems on some level the founders agree here that back-ends going wrong are really a problem, but why does this start-up suddenly guarantee success here? Just the fact of using node.js + <insert db> does not make a back-end good. Using things the community generates also does not make something good. Back-ends are anything but one size fits all, or even one size fits more than a few people.
Producing a good back-end is actually very hard for anything beyond a prototype and an often misunderstood art form. I don't get this notion I see a lot that xyz programmer is a "front-end" developer and abc programmer is a "back-end" developer. You are not a developer at all if you can't learn anything you put the time and effort into I would argue. At best, you are a beginning programmer who knows a few libraries that are focused on one or more aspects of a system. In practice, you don't always get to work in jobs in all roles, but you still have to know about all of them to be an effective developer. I would never hire someone for my team beyond a junior-level that was not strong in all areas. There are of course specialists as well, but these are more for things like crypto/security, embedded programming, and so-on rather than your general application code. Simply put, if you can't learn front or back-end development to meet the requirements of your development tasks, you have no business doing them. As a corollary, it is important to know your strengths and hand-off to people who might be more artistic or more familiar with a language, but it does not absolve you of learning about the other parts of your system. So I also ask, what part of this protects a programmer who is inexperienced, clueless, or otherwise too busy to care about the back-end to not structure or combine otherwise solid parts (for the sake of argument) of this tool from creating a back-end that is a complete disaster because of the sum of its parts?
I think this app discounts the close relationship of a system as a whole between the front and back-end. A few things were mentioned already like syncing data offline, but I have additional concerns. Note for example that caching, data modeling, and asynchronous programming for example are all very closely related to both databases/working with data and building user interfaces. I cannot tell you how many times I have had to build little tricks to makeup for technology or real-world issues that involved doing things like encoding some bits of information in a database key, field, whatever to make something more cacheable, O(1) lookup, or whatever to ensure the front-end experience was better, or even just deal with deficiencies from other parts of the code. I think the notion of all parts of the system needing to work with a consistent approach, philosophy, and quality is highly demonstrated by the current approaches in Clojure using ClojureScript, React, and Datomic for example where the notion of using immutable data makes it both easier to cache information nearly indefinitely, and to create UI that renders quickly due to the ability to use deltas and caching as bi-products of immutable data. There are many other systems and frameworks that share this view of "turtles all the way down."
Another problem with the product here is I don't see a good story of how someone can legitimately develop a solid back-end with this tool. The problem is not necessarily the tooling, but the customer that presumably uses this already lacks the skills to create a back-end. What about the product being visual suddenly mitigates this? It seems from the literature available that the implication is that a lot of back-ends are super simple and require merely basic CRUD operations. In my experience, this is anything but for most people. Business users for better or worse like to throw tons of rules, conditionals, corner cases, and so-on when developing a system. It is your responsibility if you are a developer to stop this, but I hardly think the customer here is one of those people who knows enough to do this correctly or at all. The tool looks like it can give you the ability to add all these rules to be something more than super simple CRUD, but the problem is not the rules working or not, but the fact that adding them and using them usually causes countless bugs and severe consequences without someone who knows what they are doing actually checking with proper thought. Assuming you are building a CRUD app with none of the aforementioned complexity, I hardly see why someone would not just use something that is either stupidly simple or closely matches their domain to do this like Salesforce, Sugar CRM, Excel, whatever. This product seems to give no immediate value proposition over a naive CRUD app over existing tools, and takes away just enough power to not make it something that can compete with a more complicated solution like existing web or app frameworks.
Additionally, I have encountered the truth is that there are few things in an application that matter more than data. One could argue the end-user functionality is king and while this is often true, you can still get away with not the greatest user experience and product but be successful. Judging the front-end is very subjective at times, but the back-end is rarely anything but subjective. I have seen countless front-ends that made millions for companies based on nothing more than Access, Excel, FoxPro, VB, Salesforce, Drupal, Wordpress, whatever. One thing they would all tell you though is their data (and even logic) was super important to them. Another reality is a lot of these people already have the data in abc form and need to transform it to xyz form(s) to take the next step. This solution does not seem to have any obvious story here. That seems to discount a lot of people with existing businesses and products. Doing ETL or any sort of transformations is exceedingly complex, and the person using this tool would hardly be the person to do it. I just can't imagine everyone else doing the heavy lifting of getting existing data into a form to use with this tool, then stop the heavy lifting to use an unknown quantity in an online visual builder.
I have many more concerns and arguments here, but to cut a long rant slightly shorter, putting everything else I said aside, what about the tree structure itself? Trees in web browsers seem like an awful fit. They are even a particularly awful fit in desktop UI beyond a few levels. Programming "back-ends" is notorious for deeply nested logic and complicated flows. I don't see how modeling this in a tree is a good fit. A DAG is a bit better, but my real issue here is that it is so visually literal. I can already imagine being driven crazy with identation. Undoubtedly I am sure there is some work-around, solution, whatever just like in normal programming of hiding the nesting complexity by naming sub-trees, collapsing things, etc in the way we collapse things into files, classes, objects, namespaces, etc. This though seems to work a lot better in a text editor with some visual capabilities rather than in a purely visual editor. I've seen structural editors with Lisp that try to do fun things here too, but that's another topic. Anyway, my point is that the UI itself seems like it won't scale well and introduce complexity in groking the code it is supposed to simplify.
Generally, the problem with this product and most in the same space is that as you take away control from what someone can do here, you get diminishing returns. The reason some things work with bad back-ends is because they are super simple. This looks anything but simple and I have no nice way of saying this, but it seems targeted at an odd group. Are you going after high school - early 20 year olds beginning programming? If so, did it occur to you that these people are often fickle with spending money in this area, and often don't have the money anyway? Who is your real customer beyond what is mentioned in the article. Sorry, but I don't see a future for this tool and I can't see why any logical person would invest the time and money to couple themselves to it. Shame on YC for investing in this one as well, you've been duped I think.
I don't normally comment here, but I'll bite on this one. ;tldr - I find the goal and customers here confusing, questionable, and not well thought-out. Additionally I find the founders insulting and naive in the article.
I still don't get who is the current and future customer even after reading the other posts here and other available material. I fail to see line of business users writing anything in this as it is too complicated for them and too close to programming. I cannot see an experienced dev introducing this in a stack and investing the time in learning the tool/libraries, building a system visually (super slow), and tying themselves to a 3rd party unknown start-up this tightly. As for the indie developers mentioned in the article who cannot build a scalable back-end, who are these people? Why are they developing apps? Maybe I am a grouching aging developer, but I really don't understand who these people are - "Indie developers comfortable building the user-facing side of an app themselves, but who would need assistance to build out a scalable backend."
I would argue that if you believe you are a person who builds apps, you should be capable of actually building the app you are building. Beyond that, you are just another person with an idea, which in our world means absolutely nothing. While I can see how people can build a prototype not knowing exactly what they are doing and become successful, the keyword here is prototype. A prototype doesn't usually need to be scalable. If you want and need scalability, you need to build something carefully which matches your app's use cases and real-world usage. This is a difficult problem and not one that can be solved by plugging in anything and waiving a wand.
Listen, I've worked as a developer since the late 80s, consultant since the 90s, spent many years at Microsoft, and worked for a few startups. I suppose I am one of those weird people who doesn't care about the tools, language, whatever, just give me the task and I will find the best tools to do it, and learn them in hours if I must to get the job done so I am open to anything to help, but this app makes me feel like I live in the Twilight Zone. I have seen this exact product in some shape or form so many times whether it was Visual XXX or ABC Builder or even some layer on a product like SharePoint, Dynamics CRM, Wordpress, whatever. The closest tools that have had at least practical success I've seen have been Excel and Hypercard. My hats off to you if you can make it work, but really I have my doubts. There is nothing written so far that is convincing me or more importantly, that would convince any of my previous customers (including private, government, and start-ups) to use this. And I assure you that my past customers would like nothing more than to take shortcuts, not pay for my hours, and/or find some way to in-house many development tasks. There are just so many things wrong here I don't know where to start. I'm not saying this to be mean, but rather I am genuinely curious who would use this and why. On top of this, you have tons of related competition, and hype around everything from Wolfram Language to Eden in this space if we broaden the scope to visual builders in general.
I think it's a bit telling that one of the first comments is, "Treeline is different." I am pretty sure everyone who builds a product like this says exactly this, including my former colleagues who built real, very large, and even well-selling products. I have never seen any product genuinely succeed in its goal here, at best these products just sold the sucker's line and did not retain their customers long-term. Alternatively, these products succeeded in something else, but failed in the "app" or "back-end" builder category.
Would love to hear some honest feedback. Maybe your struggles were because of the tech, earlier versions, bad hardware config, or mis-applied use case?