What struck me the most is going with the old and tried tools (PHP+MySQL). Nowadays everyone - myself included - is trying to have an excuse to try the sexiest JS framework of the day and most of us fail miserably to deliver anything useful - because of lack of experience or just reinventing the wheel altogether.
It's not so much old vs new, or cool vs boring, but rather the thing you are most experienced with. If the goal is to just build the damn thing, go with a stack you would be most productive in.
Exactly. I'm making 25k month with a SaaS that was built on boring ASP.NET+SQL Server+Angular 1 because that's what I knew.
I host it on Windows because I know how to make it fast and secure.
I'm happy I focused all my time on building the features that clients were asking for, instead of learning the latest frameworks or fighting an OS I'm not familiar with.
Ah, silly me :) I'm not that familiar with the history of Fortran so I thought maybe some cool Fortran reincarnation (hence II) was released a few years ago.
At the time I started the project, there seemed to be a new article on top of HN every week telling me how Angular is bad and why I should learn React. Since I had been using Angular for a while on my day job, yes, Angular was the boring choice.
Actually, I wonder if the creator of WWWBoard/FormMail/etc achieved that. It certainly would've been well earned. His stuff was everywhere (I used them a lot too).
Doesn't it make sense to be specific with the currency you are talking about on an international forum? I realise the US is the worlds most powerful country with a very important currency, but it doesn't follow that we should always just assume that any currency spoken about is USD.
It does make sense to be specific, but I find the only people who aren't specific are usually Americans so we can assume these figures are USD.
While this forum does have people from all over the world (I'm living in London), it also is a forum headquarted by a seed accelerator based in the US.
When I’ve seen people set out to learn something and build something, they tend to accomplish neither—but if they focus on just one of those, the other is often a happy side effect.
The golden rule in my experience is that you can have both, if being careful in the proportions. Usually I limit new things to 1-2 concepts/tools a time, and use well tried ones for others. This way I usually manage to get stuff done and avoid getting stuck in my comfort zone.
Note: I have some hobby projects with minimal progress, where I ignore the golden rule and try new stuff all the time :)
As a counterpoint, I recently built something in a framework (Rails) that was relatively new to me because the framework had large amounts of functionality available as open source components (info in profile).
I reviewed other options, including technologies that I was more familiar with, but the risk of slower development while I came up to speed was outweighed by the increase in speed to market.
I did just that about a year ago. I moved over from a an MS stack to a Linux/Node/Postgres stack. And while I finally got the damn product shipped - it was a terrible idea to change my tooling/environment so dramatcially. Everything took way longer. And honestly, the quality of the end product is worse.
What motivated the change? Were Linux/Node/Postgres technologies you were familiar with in comparison to the MS stack you were using? This can be problematic regardless of the technologies involved.
This can definitely depend on the technology and the use case. For instance, I'm building a .NET desktop application and started using WinForms since I have several years experience with it. I scrapped that and started using XAML for the first time and I am already more productive in XAML than I am with Winforms. I have a cleaner UI and an easier time with the architecture due to the data binding.
My point is that there are technologies that if you are using a technology that is a pain in the ass (Winforms) but that is all you know moving to a newer technology that has been designed to be easier to use can not only benefit what you are building but even save you time in the long run.
Or you know, many set out to neither learn nor build, mostly to avoid chores and homework, and somehow end up having learnt and built and ended up with a good technology job.
> It's not so much old vs new, or cool vs boring, but rather the thing you are most experienced with. If the goal is to just build the damn thing, go with a stack you would be most productive in.
This exactly. Customers do not care what the product was written in, as long as it solves their problem. I find this is a hard thing for programmers as we are generally curious and want to be learning. It is important to remember the goal. If the goal is the learn, then go learn. If it's to ship some software to start a business, then use the tools you know and ship something.
One of the hardest things for programmers to learn (including myself) is that success is almost entirely determined by how well your solution solves the problem you're aiming at, and how well you market it. The tools you use to create your solution matter to almost nobody.
It's true that if the company really grows, scalability, code manageability for teams etc. might become an issue if your backend is very poorly engineered, but that's the exception to the rule. As long as it works, it's good enough to launch with.
> It's true that if the company really grows, scalability, code manageability for teams etc. might become an issue if your backend is very poorly engineered, but that's the exception to the rule. As long as it works, it's good enough to launch with.
I think concentrating on the main features and launch quickly is good. You can start getting feedback and doing what customers or potential ones want.
I don't completely agree. To follow your analogy, I don't think the languages themselves are "theorems". Rather they are notation. Some notation is shorthand. Some is quite verbose.
But in the end it is not the notation that makes or break a theorem. However, a theorem may be more or less clear depending on the notation.
Imagine your in the cleaning business and you focus all your efforts into making the most light weight durable broom in the world and one day you wake up and realise the guy with the wooden broom has all the actual business.
In this case some developers actual go further down the tool rabbit hole and start building tools that build tools..and they wonder why they fail.
> Nowadays everyone - myself included - is trying to have an excuse to try the sexiest JS framework of the day and most of us fail miserably to deliver anything useful - because of lack of experience or just reinventing the wheel altogether.
I don't think PHP has anything to do with that. Probably more experienced coders (i.e. older, hence PHP), just cranking out great code. Language/stack has nothing to do with it.
For example, my day job I work with Android all day long. But as a side project, I wanted to make a small mobile game as a invitation for my wedding. So I loaded up Phaser.io and wrote some really easy Javascript. I had a working, playable game that night. To be fair, it's a really great framework. But I think choosing a framework that fits your needs at hand is much more crucial than which language or database you use.
For me the biggest issue is motivation, rather than old and boring vs. new and shiny. More than what I know, it's about what makes me happy. I'm sure people build awesome things in one Javascript du jour framework or another every day, but I'm just not one of them. I know Javascript and Node.js fairly well, but I don't find any joy in programming in them. Whenever I make the effort, my motivation always dies off and I either abandon the project, or rewrite it in something else. Anything else.
On the other hand, technologies like Elixir, Erlang, Elm, and Riak, for instance, are immensely enjoyable to me, so they keep my motivation alive. In my opinion, whatever makes you happy and motivated is the best.
We ship $2+ million/year through WooCommerce/Wordpress and a PHP/MySQL backend on Digital Ocean servers. It's enjoyable to come on Hacker News and read the thrashing about new technologies and the like.
There's something to be said for working with the tools you're familiar with but I am also quite happy to have put my PHP development in the rear-view long ago.
I would posit that it is not old vs new but the vision you have of what you are building. If he had used ClojureScript this would still be just as good. If someone uses PHP and jQuery on an uninspired vision it will not be very good.
At work, we've been using a new JS framework paired with server-less infrastructure for the past 9 months. It's barely production stable, so it's been painful, but hey look at our fancy new framework.
When I started a new side project, I wanted to get an MVP out as quickly as possible. I opted for PHP/MySQL, and development time felt like lightning. It was so refreshing.
I plan on rebuilding the code base, now that the side project is making money, and perhaps I can use newer tech for that, but quite happy sticking with PHP for MVPs.
I have a similar story I recently set out to build a SaaS product and wanted to use/learn elixir. I enjoyed using elixir but a lot of the fairly complex things I wanted to do requires quite a bit of learning and custom solutions. I wound up scraping that version after 2 months and rewriting it in Ruby/Rails in about a week. And adding new features.
I did the exact opposite: I have ~8years of professional ruby/rails experience and I was building a little SaaS. At some point, after 100 hours, I got bored/stuck with only 20% of the planned features to reach a MVP. I decided to switch to elixir/phoenix, where I had few confidence and there was apparently a growing ecosystem not always ready or complete. After 100 hours I completed the MVP and launched it. Using elixir was refreshing and right now I'm using it for almost all my side projects/prototypes.
Who cares if it's old and boring? Making money is what you need to do as an entrepreneur (by improving your product and delivering more value), not playing around with various "sexy" technologies. I would write something in COBOL if it made sense to do (i.e. faster, more efficient, w/e)
Personally I don't really enjoy the development work on the "for profit" projects I build. I love seeing a finished product, though. Use the sexy untested tech for a "fun project", not a commercial one.
That was the first thing I thought when I hit the URL.
Here's the thing, I'm guilty as charged. But, analyzing my own behavior, trying the sexiest (JS or otherwise) framework is just an excuse to play/learn it. My subconscious mind never had the intention of actually following through with a product...
I hope we can recognize (and avoid) the pattern in the future and use whatever we are more comfortable with to rush the product out of the door.
I noticed the same thing. Was previously working on a startup using PHP/MySQL/Backbone. We just kept churning out releases out of management's ever changing specs.
After a while with the chatbot hype, in comes this external contractor, and started dismissing people left and right that either did not code in javascript or wanted to use his simplistic challenge/response chatbot (we coded a decision tree based system). In any case, at that stage the startup was failing, I ended up leaving, kept working with same cooling in my own startup and have been happy ever since.
So for me, the moral of the story is, work for somebody that is focused on the product instead of trying to win a hipster contest. First time I saw that was when .NET was in beta mode and our tech lead decided to switch everything over to an undocumented/buggy system back then.
Old and boring is still sometimes the best.