This is my opinion, and I know it won't be popular, so give me some slack for admitting that and posting it anyway.
You can tell a startup is focusing on the wrong thing when: They're using the 'newest', most obscure, programming language or frameworks available because it's the 'best' for some unscientific reason.
Instantly I hear the argument "Yah, but if we need to scale, we don't want to re-write." Ok, you're going to rewrite anyway. Right now your problem is producing quality code that additional people can onboard themselves with. Chances are you can produce something very practical using plain GET/POST operations and gradually add more interactivity on the client side if you prove your product out.
The stem of my rant is this: Recently I was thinking about picking up some side work for extra $. The company I was interviewing with described their front end team as struggling to keep pace and needed some temporary help. The product is under NDA, so let's just say it's a shared calendar. Their stack was insane: 18 different javascript frameworks, required a certain version of Node.js to "compile" to ES6, then another to run it in your browser, and the stylesheets were written in some other obscure language. In the second interview, I told the product manager I think he's been had: the reason your front end team is struggling is because they're not being practical, they're busy with shiny toys. He said he had a feeling, but given his situation he didn't have much of a choice but to continue. He thanked me for being honest and said he understood if I wasn't interested anymore.
Anyway, there's a lot of really "cool" stuff to get distracted by as developers. I think a lot of us need to sober up and really meditate on the phrase "do the simplest thing that could possibly work".
>This is my opinion, and I know it won't be popular, [...] a startup is focusing on the wrong thing when: They're using the 'newest', most obscure, programming language or frameworks
I'm not sure where you get that idea that boring technology is a minority opinion. Your conservative approach favoring mature technology is a sentiment expressed by the majority and brought up repeatedly on HN as a highly upvoted point of pride. Examples:
I have seen zero articles upvoted to the front page that make a case for using the latest whizbang tech stack for an "unscientific best reasons". (E.g. Rust is new ... but the front page articles on it are usually tutorials, proof-of-concept comparisons to C++, or something about DropBox using it in limited spots where Golang's memory footprint was unacceptable. I haven't seen any frontpage article proselytizing its use as a tech strategy to help a startup succeed or scale out.)
Of course there's no blog post about how you should use a new piece of tech at your company because you saw a toy example of using it and like it - because when you put it that way it sounds ridiculous. Instead you have people posting toy examples of code that isn't used in production or is used in production for very specific reasons that usually don't apply, and other people thinking "hey that looks neat" and deciding to use it in production without doing actual analysis. See: the sharp rise of NoSQL and chase of "big (not actually big) data" starting ~7 years ago.
If this wasn't a phenomena then the posts you linked seem kinda pointless.
>, and other people thinking "hey that looks neat" and deciding to use it in production
That may actually happen but it's not relevant to my point.
I'm pointing out that exabrial presented his opinion about choosing "uncool" tech as if he was a lone voice crying out in the wilderness. He's not a lone voice.
Even though exabrial ran into a project apparently enamored by shiny new toys, that doesn't take away from the fact that the overwhelming popular opinion is to just use the older stuff.
For example, every time a thread about "Javascript fatigue" comes up, the HN commenters pile on complaining about the speed of change in the ecosystem and the flavor-of-the-week framework. No thread about new tech ever has "I'm going to use this brand new week-old framework in production!" as the top voted comment -- nor is there ever an article recommending such a strategy upvoted to the front page.
>If this wasn't a phenomena then the posts you linked seem kinda pointless.
They're not pointless but they may have been triggered by a sample size of one (Dan M. writing about regrets at Etsy) or zero projects (Jason Kester writing about what he hypothetically would do). Both those blog posts can be written for audience contemplation ... but ... simultaneously not an indicator about most of us being restless programmers trying to deploy shiny toys into production.
Based on those 2 blog posts (and many others like them), and the followup comments in HN threads overwhelmingly expressing the same conservatism, I'd say exabrial doesn't realize the majority actually agree with him.
I agree with your major point but not with your example. That just sounds like:
* "18..." -> JS Libraries?
* "certain version..." -> TypeScript / Babel?
* "another to run" -> CommonJS / SystemJS?
* "stylesheets were written" -> SASS / SCSS?
Bleeding edge syndrome is definitely a problem in technology but the opposite can be too. Not leveraging technologies that increase productivity and performance can be just as impactful. I'm not implying that you're doing that.
> You see the Node.js philosophy is to take the worst fucking language ever designed and put it on the server.
Had to laugh at that!
In the recent Westworld episode (S01E05), the lab tech was trying to program the bird's AI and his file was called "New Script.wws", where .wws is apparently "west world script".
Immediately, the thought crossed my mind, "Must be fucking JavaScript! No wonder the AI will soon start killing the humans" :-)
In my faux outrage, I went into theoretical scenarios of how exactly JS caused SkyNet. To be fair, once my flash of righteousness passed, I took a closer look and .wws looks nothing like JS. Also, there seems to be C or C++ on the LHS.
I still bet WWS is some kind of duck-typed shite that relies on the cult of TDD to keep the robots' behaviour safe.
checkNoKillMode(str). "Look, all my tests pass. We have 100% coverage".
Yeah, except when str == '', in which case it evals to false. Of course, there's no test case for that.
"You see the Node.js philosophy is to take the worst fucking language ever designed and put it on the server."
My theory is that there are many front-end designers that only know html, javascript, and css, and suggested javascript on the back-end, because they don't know any other language.
I've been a part of many of the javascript framework communities like Ember.js over the years and it's filled with designers, not developers.
But it also depends on your optimizations. If you are a small company, you want to focus on having a small footprint because server space costs more to you.
Large companies don't care about server space costs, because it's negligible compared to the cost of a developer salary and benefits. So, they would rather use a large and bloated framework that helps with productivity because less lines of code need to be written.
I've worked at a few large corporations that didn't get that much traffic. They all used enterprisey, inefficient, and bloated frameworks. Nobody really noticed because they could just throw some more hardware at it and the traffic to the site was fairly low.
I think this is a result of all of the tooling and automated building that's "necessary" to cludge everything together.
ES6 features and TypeScript are great, for many reasons, but they don't work immediately in the browser. You need precompiling and something like CommonJS or SystemJS to handle importing libraries not defined in HTML. SASS/SCSS really improves stylesheets, tremendously improves them, but you need to...precompile. Finally, JS heavy apps turn into a hodgepodge of JS, CSS, and HTML that just doesn't really...sit well, so most people will use tooling to establish some sense of ordering.
That last step is both a boon and a curse. Automating the process makes development very easy and saves a lot of time. That tooling is also inherently complicated to an outsider and is a large, ugly barrier to entry.
Frankly speaking, if you invest some time in learning these tools it's not really that bad. Once the project's toolchain is setup properly one can be productive for a long time without worrying much.
One of the major problem front end development seems hacky is the browser quirks and developer's wish to get more out of browsers for which they were not designed for.
I've seen too many examples of this... but its not limited to start-ups. Had a term for it - RDD, resume driven development, where the teams focus is developing their resume as opposed to a product.
I don't blame them. They want to get paid well, and having experience with 'stuff that hasn't even been invented yet' makes them look innovative. And, generally, looking innovative means a big pay increase.
What's funny to me is that I've had a track record of leading and building core parts of successful applications used by millions of people. Yet, when I go to interviews, often they don't seem to care about my successes. And, to them, my methods look ancient. And, they express disbelief when I ask for $200k (a paltry sum compared to how much time and money that they'll spend).
Yes mostly due to Resume Driven Recruitment. All the soft skills and technical acumen become worthless to many companies if you can't hit those language and stack bullet points.
or the managers don't have the right incentive. I manage a team of devs at a startup, and beside some promise of "do well, get liquidation event" I have no incentive to make a good product other than personal pride.
>You can tell a startup is focusing on the wrong thing when: They're using the 'newest', most obscure, programming language or frameworks available because it's the 'best' for some unscientific reason.
I don't think he was talking about technical details, he was merely trying to emphasis on the importance of ignoring trivial things that might not mean (at an early stage esp.,) as much as one might think... And I'd agree..
At an early stage one should have google like garage office and just stay focused... focused.
twitter isn't facing problems due to less revenue.. but due to abundance of the expenses.... just gave a very broad example to make the point.
Exactly. Nothing in this article even talked about technology specific startups at all. It could apply to a craft beer company as much as a new SaaS product.
Or they are using $(Obscure new Functional Programming thing) which makes Haskell look like VB in ease of use and only two people on the team know how to use it (kind of)
Or using (invented here thing that could be replaced by regular DB/other existing system) but since it was one of the founders that did it nobody is allowed to touch it or fix bugs
I had a gig once where my predecessor was a Haskell guy and had written Haskell-in-Javascript :( The comments were things like "this is a simple functor that produces a monad that, when curried to a function, will return a lambda that will do what we need".
Needless to say, I wrote zero lines of code during those two weeks, and the company shut down shortly after that.
To some people, jQuery and bootstrap are overkill (motherfuckingwebsite.com, etc).
The rule of thumb is if someone is using a more complicated stack than me then they're foolishly overengineering their app and if they're using a simpler stack than me then they're unsophisticated novices.
I don't like the obsession with the newest, most shiny stuff myself, but to me it looks different from a business perspective.
Let's say that I'm a startup CEO and don't have a lot of money, but want to hire great engineers. I'm competing with giants with a lot of money, so I'm trying to offer everything I can - and all I really have is creative freedom. And if engineers choose to use it to learn new frameworks and in general, get a little crazy, it's fine by me, as long as it keeps them happy and not looking for greener pastures.
"keeps them happy and not looking for greener pastures"
These types of developers are always looking for greener pastures. No fault of their own. They should be. If all you "really have is creative freedom" you can't compete with the bigger guys who provide that + higher pay + equity + perks.
It would be better to choose a tech stack that is best for your company and attract talent that actually wants to work on what your startup is doing vs playing with the latest shiny thing.
Suppose you have a fairly interesting business but your tech needs are 'boring' -- you might have a few unique problems but nothing really interesting enough for a talented engineer that's mostly driven by problem solving. What can you do to attract that kind of engineering talent?
You could offer them money, or equity, or perks, but the kinds of people you really want would happily take a QoL and pay cut for more stimulating work -- the kind of work that puts them at the forefront of their field -- the kind of work they could write blog posts and give conference lectures about. So you offer them creative freedom, let them pick their own stack, let them use the new trendy framework, let them set up a fancy build and deployment pipeline even though you're a small shop, let them use their favorite language that they never get to use outside of personal projects. Let them solve your boring problems in fancy, clever, maybe a little over-engineered, but fun ways that also make you, the business, look like you're up to date, modern, and ahead of your competition.
Fair points but at some point you have to ask yourself at what cost to the business, especially if you are a small shop. Implementing all new trendy frameworks & over-engineered setup comes at a cost.
I am not at all opposed to using new and shiny. I use new frameworks, etc. in my business often but there is a balance. I generally stick to boring and proven for business crucial stuff (especially back-end) and new/shiny for not so crucial. OR sometimes a new framework is the best decision for the business. In that case, that framework wins.
I guess I feel as a business owner, I have a responsibility to do what is right for the business and our customers. If a developer doesn't want to work on what is right for the business or our customers, I don't want that developer.
I value more no crazy schedules, ability to work remotely, cool office atmosphere, interesting product, getting to do stuff together after work... than shiny toys.
This debate isn't simple. I'll try to distill it as best I can.
Sure, some people only want to work with new things because they are novel. That's human nature.
However, that's not all of it. Many people strive for new tools not simply because they are new, but because they are better in some way. Of course, I understand that some people over-estimate how much better the "new" technology is, in practice. Transitions take time.
A side note: most "new" things are often based on combinations of "old" things. One of the big problems with some "new" tools isn't simply that they are "new" -- it has to do with their maturity. Applied person-hours, working on representative problems, helps shake out problems or edge cases with various technologies.
Take Clojure, for example. I reject the notion that calling it "new" or "old" is particularly useful. When it was released, it was based on many iterations of Lisp and the JVM. Clojure has been very stable.
Some people underestimate the importance of tooling and the ecosystem. Or they may underestimate integration; e.g. in the case of a new language, does it have a solid C or Java native interface?
Until one found the code failed on some version on browsers, or worst - mobile browsers...
Then you need to debugger your code, compiled code, sourcemap files, compiler, compiler options, the layer and layers of configuration JSON scripts and mobile browser.
I've been working with es6 for two years now and never even heard of this happening to someone. Given the huge number of people who use babeljs, if there were to be a bug in it, it'd be reported and fixed rather quickly.
Yes, transpiling es6 -> es5 is adding another layer of complexity to your codebase, another thing that could potentially go wrong, but the reality is that the development gains we get from being able to use es6 are far more important than a small chance of a problem. It works well enough that you don't even think about it after leaving webpack in watch mode.
Block scoping (using const/let instead of var which is scoped to the function) alone is really nice, but I also make heavy use of destructuring, arrow functions, template literals, export/import syntax and promises. Es6 makes javascript more pleasant to code with, and can greatly improve readability.
es6 has become pretty well supported by modern browsers, so maybe after a year or so, we'll just be calling it "javascript" and running it without babel. I expect everyone to continue to transpile, though, to get newer features as they come, as the plan for ES is to release new language updates on a yearly basis.
It adds some extra nice language features to JS. It really is a good productivity improvement, especially with JSX which enables HTML literals: pretty much essential when working with a complex React front-end in my opinion.
My team has been using it for most of this year now and we've had no problems so far.
> Then you need to debugger your code, compiled code, sourcemap files, compiler, compiler options, the layer and layers of configuration JSON scripts and mobile browser.
This seems like you're deliberately trying to make things sound way more complicated than they actually are. If there is a bug in the code on a certain platform, you examine the bug on that platform and add the appropriate feature detection code to fix it. There is no need to debug the compiler and every other tool in your stack, it all compiles to javascript at the end of the day and assuming you're not running a minifier in development, 99% of platform specific bugs are readily apparent and almost certainly the developer's fault (i.e. not the tool's fault)
After with, do your team do automated regressive tests the oauth support and all other functionalities on all the regular browsers and mobile browsers?
+ Older version browsers?
+ Older browsers in older version of Linux, Mac, Windows?
+ Browsers with plugins such umatix, unblock origin, noscript that blocks scripts from your own domains + other domains?
I'm not really sure what your point is. If OAuth integration is a requirement for your project then its your responsibility to test it across the platforms you intend to support and that's a universal truth no matter what development stack you're working with.
Dealing with sourcemaps absolutely causes extra trouble. Transpiler errors and bugs can also pop up at the worst times. Any time you add more steps to your compilation and deployment process, you're adding risk and potential trouble. That's just a fact of life. I'm not saying not to use es6 because I do and it's awesome, but I am not under the illusion that it's all sunshine and rainbows.
Maybe its a good recruiting tool though? If you're not a famous or wealthy company it can be a way to recruit good people if you use leading (not bleeding) edge technology. It didn't attract you but lots of people seem to like shiny things.
this. we are a small team but really wanted a person that we liked to work with (he was a long time friend) but he had some language prefs. Its not without a major cost since generally the rest of us dont touch the software stack as much anymore (we are a hardware startup with a lot of EE/Mech and FW) but right now I'm not sure thats a bad thing as we can focus on our respective parts. Rolling with a modern language and framework set was a small price to pay for a great hire. We did stipulate that the backend framework had to by things we were fluent with though.
Sounds odd to me that you'd accept his actions that feel like a price to pay (which I take as a loss of business value) in order to get a great hire.
But If they are doing things that are destroying value then are they so great? Or maybe they are great but not a good fit for you. I.e. they need a Google not a Crud Inc.
We didn't 'accept his actions' but instead he told us upfront that he was partial to working in certain languages and frameworks. We mulled it over before agreeing and coulnd't be happier. He is great because he is great to work with, highly productive, self motivated, and brilliant. Sure, I could have hired a dev that only did the exact same things as me, but I might be tempted to get into the weeds more than I probably should. You defining 'his actions' as destroying business value is a poor mischaracterization as he has created enormous amounts of business value. Couldn't be happier with our decision on this.
I have been in similar situations and agree 100% with you on the technical side. But they may not have been actively engaging in self-harm. If a dev isn't very experienced in front-end, it's easy these days to fall into the trap of creating an SPA without realizing what you're doing, just because that's what libraries expect you to do by default. For example, any library that supports client-side routing without discussing the alternative.
You might have been able to turn things around for the company with your experienced view.
There is, however, some value in letting engineers choose which tools and platforms they want to build upon as long as the consequences to the business and hiring are understood and agreed upon.
You can tell a startup is focusing on the wrong thing when: They're using the 'newest', most obscure, programming language or frameworks available because it's the 'best' for some unscientific reason.
Instantly I hear the argument "Yah, but if we need to scale, we don't want to re-write." Ok, you're going to rewrite anyway. Right now your problem is producing quality code that additional people can onboard themselves with. Chances are you can produce something very practical using plain GET/POST operations and gradually add more interactivity on the client side if you prove your product out.
The stem of my rant is this: Recently I was thinking about picking up some side work for extra $. The company I was interviewing with described their front end team as struggling to keep pace and needed some temporary help. The product is under NDA, so let's just say it's a shared calendar. Their stack was insane: 18 different javascript frameworks, required a certain version of Node.js to "compile" to ES6, then another to run it in your browser, and the stylesheets were written in some other obscure language. In the second interview, I told the product manager I think he's been had: the reason your front end team is struggling is because they're not being practical, they're busy with shiny toys. He said he had a feeling, but given his situation he didn't have much of a choice but to continue. He thanked me for being honest and said he understood if I wasn't interested anymore.
Anyway, there's a lot of really "cool" stuff to get distracted by as developers. I think a lot of us need to sober up and really meditate on the phrase "do the simplest thing that could possibly work".