This line added absolutely no value to your comment (try reading your comment without the opening line and tell me it's any different) and resulted in a lot of distraction from the rest of the conversation. It's curious to me that you decided to include it even though, as indicated by the disclaimer you provide at the beginning, you knew its potential to be considered both offensive and presumptuous.
This constant outrage at every perceived slight is a recent phenomenon of the Facebook/Twitter decade and it is suffocating.
> Be kind. Don't be snarky. [...] When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."
"That is a question that a junior developer would ask" is not on the same level as "that is idiotic".
If you're asking after "hot new tech" it's probably because you haven't been around long enough to see how tragically wasteful the "hot new tech" treadmill is. The "30 year" comment manages to communicate that very directly.
Frankly, the OP said something rude. It's not a "perceived slight". It was unnecessary, offensive, and presumptuous. Why shouldn't they be called out on their behavior? Congratulations on your ability to ignore the first sentence, but that doesn't excuse OP.
#RickyGervais2020
Assuming Good intention, ( Which I think OP is ) sometimes it is a little hard for people under certain age to understand certain things. It is simply a reflect on our stupidity that when we were young, we too were also singing, praising and hyping all the shiny tech. And we were burnt by it.
So it was more like a suggestion to those under 30, here is what I did, I was stupid. and if you are under 30, please consider my follow experience as some sort of guidelines.
The first time it happened, I was like "it's fine, we can just rewrite modules A and B". As the years go by, I see it more and more. And now being a freelancer and having been in about about 15 projects, 1/3 greenfield and 2/3 legacy, I see a pattern.
Use the most appropriate tool for the task (taking into account not just the tech itself, but also the market, the maturity, possibility to find developers, etc), not the "hot tool of the day".
When you've worked on 100+ projects (and accumulated a few pathologically obtuse, worst-case horror stories), you realize it wasn't bad luck, but those landmines inevitably lurk in every younger stack.
Maybe you get lucky and don't step on one. But that doesn't change the overall risk based on their existence.
As Torvalds said in the spinlock back-and-forth: it looks simple, until you're looking back over two decades of patching edge cases that you never saw coming without the benefit of hindsight.
And having that experience makes you look forward very differently.
(At least where production, must-work code is concerned. Go nuts with toy / personal / experiment projects!)
You're conflating age with experience. Yes, somebody that's younger is likely to have less experience, but the two words are not interchangeable. Their link is definitely not strong enough to begin guessing peoples' ages based on their level of expertise.
I remember back when I updated my Build a SAAS App with Flask course[0] for Python 3.7.x when it was originally coded to support Python 2.7.x and 3.4.x, and it took like 15 minutes.
Also updating Flask to 1.1 from 0.9.x took around 2 hours but that also involved updating ~20 top level package dependencies at the same time, so most of it had nothing to do with Flask specifically. It was more about updating the whole app (which is a large SAAS app with payments, etc.).
I really like knowing that if I don't update my packages for ~3-6 months then the upgrade process will still be super painless.
A few weeks ago I also added Webpack into the app (and course) and even that, along with updating to Bootstrap v4 from v3 only took a little over 1 full day's of work, and that was starting from scratch and rewriting all of the CSS to SCSS and JS to ES6 JS. It's just so nice when your web framework gets out of your way and lets you use native tools whenever possible. It makes it SO much easier to follow that tool's documentation and online examples.
There is already a separate 3+ hour bonus section where we build a RESTful API driven app (a 2nd app from the main course).
It doesn't use Vue -- instead it uses jquery + jsrender but you could totally replace the front-end to use Vue without needing to modify the back-end.
That app covers all sorts of things like API design, token based auth, websockets, etc..
I'm very much against using services like auth0 to manage your auth. Not because I personally don't like auth0, it's just I dislike the idea of offloading such a critical aspect of your site to a third party service.
Multi-tenancy is tricky because it's super dependent on the app in question. There is no general solution. Using postgres schemas is ok sometimes but sometimes not. The implementation details between using multiple servers, multiple databases and multiple schemas is quite different too.
Re: commercial AuthN/AuthZ services - I definitely understand your rationale (though I've seen some passionate opinions of the opposite nature; not only Auth-related, but generally, in the vein of "outsource as much as possible of your infra to external services" (BTW, I strongly disagree with this stance for most cases). Returning to Auth, I guess, the right answer is "it depends".
Re: multi-tenancy - Yes, there are certainly various approaches, but most, if not all, represent those three that you mentioned. I thought that it would be nice to have your course expanded with demonstration of how relevant multi-tenancy design decisions (ideally, with all three options) affect other parts of the codebase and integrate with them. Perhaps, I want a perfect course, but since the focus here is on SaaS, multi-tenancy coverage IMO makes perfect sense.
It's just good fun though, but it's not everyone's idea of fun. XD
Yes, this person is a student. No reason to act like this.
Not the author of the parent comment; but with bristling replies like this, aren’t you dismissing the experience of those who, through years of experience, have become weary, and disillusioned, and a bit cynical? Isn't it also a valuable perspective (don't go for the new and shiny; stick with the tried and true), delivered in exactly the same way many older craftsmen have historically shared their knowledge with the younger and more enthusiastic ones?
Otherwise, we don’t need 10 different tools for building—what is at the end of the day—a simple website or CRUD application.
Complexity isn’t a good thing. Creating complexity is the first sign of inexperienced coders.
I've seen many times that trying and understanding a new framework leads to me implementing something in a better way in a framework I was already using.
How about putting a pin on technologies that are unproven and immature? Because many projects (and careers) have died a painful death because an overeager developer decided to bet the farm on a shiny flavor of the month because it was trending.
I'm in mostly the same camp as the parent in that I prefer solutions that are proven over years instead of the latest shiny thing, but new tech also brings a lot of interesting ideas to implement in a "proven over time" stack.
If anything, this sort of comment is not repeated enough.
But then again I have to admit CV Driven Development is quite important for Careers development.
It Just Works™ and the Django group is not trying to steer Django into something that it's not. Same with Flask.
I like using flask but django always felt half baked to me vs rails.
Yes, it's totally worth learning in 2020.
Maybe someday I will use Django more, once I'm deeper into Python or perhaps I can find a freelance Django project.
Most of the shiny tech that has severe breaking changes is Javascript - there are plenty of other technologies to have fun with.
The older I get the less I care about the technology choice and the more I care about the content of the project.
With non-breaking tech, I can focus more on features and monetization instead of updates and debugging.
I still give some space for experimentation (re: frontend I'm interested in learning more about Mithril.js and Svelte), but I don't go all in and risk long-term profitability.
Parcel was something small and minimal and got the job done for me. I'm not dismissing all shiny new tech. After it was released, I waited a year until I felt I should use it in a project.
I liked it because it was easy to use, fast, covers 99% of my use cases, and in case it got abandoned, it should be easy to replace.
If your product is stable and usable by use, they dont give a damn about its internals. It should good enough for test case. I use vanilla php and posgresql/mysql mostly. They are well matured, stable and have known issues. The website I made for a small college in 2008 is still live and working seamlessly, only changes I detected in last few years on it, were related to styling and formatting content.
There is no “long term” in technology. The best way on average to stay competitive is by keeping up with what the market wants. Sure it’s possible to start a project that is profitable or that you can get someone to acquire but statistically that’s like buying lottery tickets as a retirement plan.
Yes there is, computer science concepts like algorithms, pointers, ... exist for a very long time. General programming language principles and paradigms are reusable in other languages and libraries. Database principles and languages like SQL exist for a very long time. HTTP exists for a very long time. etc...
If you know enough of those long standing principles, you can use "framework of the week" in its week without much big deal, or ignore framework of the week and use/create whatever will solve your problem the most efficiently now.
Most software developers are “dark matter developers” doing “enterprise applications” that will never see the light of day outside of the company or yet another SASS CRUD app.
Most of those hiring managers could care less if you know anything about pointers and algorithms.
I don’t go to work not to be bored. After dealing with computers for over 30 years there is nothing that excites me about computers. It’s a way to fund my lifestyle and to pay for outside interests.
Being marketable requires staying up to date, but it's a hamster wheel: You stay fit, but you aren't moving.
With projects, you can always pivot. Nothing is truly wasted unless you throw in the towel on being an entrepreneur.
For me, I started a system integration platform 5 years ago. It's made 5 figures over the years. Nothing spectacular, and I'm 30 now, so even if it does take off, I'm not going to be the early success story many people like. But it's taught me lessons that are priceless. I have hands-on experience with sales, development, and marketing. I have sales contacts. I have code that can be repurposed into new products.
If it doesn't reach $x within y months, I may start a new business with a new model. But that's the beauty of it: You can do that. You don't have that option with lottery tickets.
Heck, I am none of those - young, unencumbered or willing to move to the west coast and I’m looking to work for one of the big three cloud providers (well two, I would never hitch my horse to GCP) as a consultant since they hire from any major city as long as you are willing to travel (I’m not right now).
It's very easy to pick up details that aren't longterm skills, but with a little care you can make much of your skillset last a long time.
The number of shops that still care about native desktop software has been dwindling weekly.
Why would someone hire a developer who has no history of the ecosystem that the company is targeting over one that has the same experience and knows the ecosystem?
Is it? If you're being hired to worked in a particular setting, the choices from that ecosystem have probably been made. If there are really new abstractions that's one thing, but that's rarely the case. If you're being asked to make choices in a new ecosystem, that's different. But I think you also over estimate the depth of these ecosystems.
> Why would someone hire a developer who has no history of the ecosystem that the company is targeting over one that has the same experience and knows the ecosystem?
Lots of reasons. Social/emotional intelligence? Salary requirements? Proximity? And that's all assuming that you can find someone with the same experience that knows the ecosystem.
C.
For a while I used Laravel and Symfony side by side, but after a while I jumped ship and decided to focus more on Symfony, because I felt it suited my needs better. Plus the update cycle was more predictable (Laravel changed it to a time-based versioning at version 5, then to semver at version 6, v6.0 was released in September 2019 and 3 months later was already v6.8, it's a bit too unstable for me to use in long-term projects).
Doesn't mean I will never use tools with breaking changes, but I will use them cautiosly, fully knowing that I will need to allocate time to updating the system in general.
PHP as a language has been VERY backward-compatible in my opinion, though. And Python 3 was released in 2008.
This is the classic question of how set your explore vs exploit algorithm. You need a mix of both, but what is that mix?
Being a freelancer the last 5 years (previously doing webdev part-time for 15 years) and having a couple of long-term side projects, I've been "burnt" enough that I've gotten tired of chasing shiny tech, just for it to become abandoned (e.g. bower, grunt, AngularJS) or introduce big breaking changes (e.g. some upgrade paths in PHP's Laravel or Symfony).
Using Python with Flask was a breath of fresh air (ironically because it's "boring") and trying to keep setup / infrastructure overhead low in the frontend (e.g. using good old Bootstrap, combined with Parcel.js) has reduced debugging significantly so I can focus on developing features. Instead of shiny new tech, I can actually present shiny new features.
It's important to know of the new tech, but I think diving deep into new tech just because it might seem cool now can be frustrating and inefficient long-term.
Of course it depends on what you want in your developer career. I have one profitable side project and 2 more that I hope to make profitable this year. Yes, it took 7 years and they use boring-ish tech (PHP / Symfony and Python / Flask, both using PostgreSQL, and none of them a SPA) but that's ok. I have colleagues who have started 15 side projects in the past 5 years, each using a different stack, but none profitable and none maintained over 6 months.