Hacker News Reader

> Sorry if offensive or presumptuous, I assume you are max. 30 years old?

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.

Not OP, but I think there is a reason for it, although I do agree it might have been better phased.

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.

Yes, I might have phrased it better, but the intention was that at a younger age, you perhaps didn't yet have to upgrade a legacy projects with semi-obscure tooling where the original developers have long left; or have had to hack your code in a dirty way because the team leader might have read about e.g. an experimental frontend framework and a DB system that is in alpha status, but still orders the team to use it (to show the company that he/she is using cutting edge tech), so 80% of the time you're just figuring out how to get the system running instead of actually creating value for the project.

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".

Yes. In the Parcel and WebPack threads I was reminded shiny new things often have edge cases that are unknown, not well known or known with no solution ( yet ). And I simply dont have the time and energy to deal with those, much better to wait for it to mature before jumping in.

If someone has worked on 20 projects, they have encountered edge cases, undocumented behavior, or incomplete implementation few enough times to believe 'it's just this framework / library / language.'

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!)

> Yes, I might have phrased it better, but the intention was that at a younger age, you perhaps didn't yet have to upgrade a legacy projects with semi-obscure tooling where the original developers have long left; or have had to hack your code in a dirty way because the team leader might have read about e.g. an experimental frontend framework and a DB system that is in alpha status, but still orders the team to use it (to show the company that he/she is using cutting edge tech), so 80% of the time you're just figuring out how to get the system running instead of actually creating value for the project.

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 simply ignored the first line and appreciated the rest of the response because it had good actionable information. I wish I had older mentors in engineering and CS when I was 20-35yrs to tell me their war stories and point me to promising areas of work.

This constant outrage at every perceived slight is a recent phenomenon of the Facebook/Twitter decade and it is suffocating.

> This constant outrage at every perceived slight is a recent phenomenon of the Facebook/Twitter decade and it is suffocating.

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.

Lol —— CANCEL THEM ALL!

#RickyGervais2020

Not at all, what the "30 year" commenter did is even mentioned in the HN guidelines. See the section In comments:

> 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."

https://news.ycombinator.com/newsguidelines.html

Assume good faith, and try to get the point.

"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.

Or, perhaps, because you enjoy playing with “hot new tech”.

I thought it was valuable. Sure, it could have been worded differently, but it was also fine as is.

I really enjoy Flask too.

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.

[0]: https://buildasaasappwithflask.com/

Really loved your course! Your Docker introduction inside that course was wonderful! Kudos!

Thanks a lot for the kind words, I really appreciate it. I'm looking forward to posting even more free updates this year.

Awesome! Will look forward to it!

Looks like a nice course. Any plans for updating it with an SPA option (say, Vue-based)?

Hi,

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..

Hi, there! Understood, thank you for the clarification. I guess, I've somehow missed mention of that bonus section. Two more suggestions for more comprehensiveness: consider updating this course with a content addressing 1) using alternative approaches to authentication (open source projects, like Keycloak & Gluu, and commercial services, like Auth0 & Okta) and 2) multi-tenancy options and aspects. Hope this helps.

Thanks.

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.

My pleasure.

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 can be incredibly fun to learn new tech for those of us who aren't purely trying to maximize output.

I have always enjoyed learning new technologies and often it has nothing to do with work. I just like the process of learning and adding new tools to my software engineering "batman belt".

I'm in the same boat. And sometimes one of those new "tools" gave me a new way of solving a problem with an old tool.

It's just good fun though, but it's not everyone's idea of fun. XD

What a condescending response.

Yes, this person is a student. No reason to act like this.

I don't agree the response is condescending. FOMO is a thing, as well as buzzword-driven development and CV-driven development, and it's pervasiveness generates this false sense of urgency regarding learning new frameworks or technologies, and even creates this false notion that this rat race is a basic requirement to have a career as a software developer.

If anything, this sort of comment is not repeated enough.

Cant upvote this enough. Especially in Web Development, how many Front end framework hype cycle has there been now, 10?

But then again I have to admit CV Driven Development is quite important for Careers development.

> 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?

There are plenty of reasons to learn new languages and frameworks. Dismissing them because of 'new and shiny' is not a good reason.

Sure, but this is the objection to the substance of the response, not the way it is delivered (which is what the parent comment is unhappy about).

The only reason to learn most of these frameworks is if your line of work has a high chance you’d inherit, need to support, and/or build new features on top of such a code base.

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.

One good reason is to learn different ways of doing things. I think the best way to understand why something is the way it is is to look at different ways it could be done and what are the pro/cons of it.

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.

> Dismissing them because of 'new and shiny' is not a good reason.

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.

There is a way to write a comment about what is great about tried and true tech without assuming peoples age or talking down about new tech as a whole.

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.

Regardless of age or career, I think most of us are lifelong students of one kind or another.

How is it condescending? It's obvious OP is inexperienced and the reply is sharing their experience.

Actually Django and Bootstrap are my bread and butter too! I stick to them for anything mildly serious.

Cool :-). I use Symfony for bigger projects (because I have a deeper understanding of it by now and the ecosystem is large) and Python / Flask for smaller projects because I feel there's less stuff pre-configured.

Maybe someday I will use Django more, once I'm deeper into Python or perhaps I can find a freelance Django project.

Same here; even throwaways get built on Django. It's just so quick and easy to test something out. And if you're lucky and it does need to scale… Django can scale just fine for the vast majority of things.

It Just Works™ and the Django group is not trying to steer Django into something that it's not. Same with Flask.

Why Django over something like rails? If you going to go for batteries included go for a Tesla battery pack and not a set of double a Duracells.

I like using flask but django always felt half baked to me vs rails.

Django if you are already extremely comfortable with python would be my guess.

Exactly!

I don't know Rails. I know Django. Should I learn Rails in 2020 ? Or something else?

Rails is like Django, it's boring because it's predictable, well documented, safe and stable. All of which, for me, is a huge plus. Version 6 was released recently, it's always being updated and it's stunningly easy to use.

Yes, it's totally worth learning in 2020.

It's a bit strange to me that you use profitability as your metric of success for a _side 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.

I have plenty of other things to do with my free time that don’t involve computers. If I’m going to spend time on a side project, it’s only going to either be to make money from the project or learn something that someone will pay me for.

It's one of the metrics, but having kids and thus less time for hobby projects, the more profitable a side project, the more time I can dedicate to it (and reduce my freelance work). And thus I can use it more long-term.

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.

The irony of this post is saying you don't want to learn new and then saying you used parcel.

There really is nothing to learn with Parcel, that is the thing. It just works

The problem with such tools is well known: as soon as you get outside the anticipated usage patterns, you're pretty much fokd in the arse.

I didn't say to not learn new tech, but just don't go deep-diving into it because some people think it's cool.

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.

I second this. I believe in stable and mature codebase/system even if I may have to sacrifice some new tiny hyped techstack or trend.

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.

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.

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.

> There is no “long term” in technology.

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.

Spot on! Very often throwing frameworks at a problem only makes it worse.

Even if I agree in theory - and that’s the reason I have avoided front end development - whether using a framework is “better” or not is irrelevant if you need a paycheck. If the market demands knowing AngularReactWASMJs and you’re a front end developer, you have to have it on your resume.

I’ve been working for 20+ years, dozens of successful interviews and the last time I had anything approaching knowing “algorithms and computer concepts” is over 20 years ago writing low level cross platform C.

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.

Your experience is not all experiences. Plenty of us have never written a crud app and never will. Sounds boring, and it’s not like it pays better than working on systems or algorithms.

I’m not saying it “pays better”. What I am saying is that statistically that’s where most of the jobs are.

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.

I'd estimate that 90% of developers are working on CRUD apps, if you work on algorithms in your day job you are definitely in the minority.

It depends on what you're going for. There's some risk with projects, but also more reward.

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.

Is there really more risk adjusted reward? If you’re young, smart and unencumbered, you could easily move to the west coast, work for BigTech for a few years and make more money guaranteed than you could as an entrepreneur unless you get really lucky.

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).

> There is no “long term” in technology.

C.

I did C for the first part of my career - 12 years. There weren’t that many decent paying C jobs in most of the US compared to more “enterprisey languages”.

There's quite a long term. POSIX and Unix knowledge? Decades. Win32 API? Also decades at this point. SQL databases and relational modelling. Expressing things in procedural programming, in functional programming, in logic programming. Concurrent programming. Most of that stuff applies in whatever syntax the language of the day has overlaid. At this point when I had to pick up Ruby I basically went "so it's a single dispatch, class based imperative language and the surface syntax for the things I need is blah. Right, we're good." And C and variants of Pascal have been around for decades, too.

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.

Anyone can pick up the syntax of the language. The ecosystem surrounding the language is a different story. I might be able to pick up Swift in as little as two weeks that doesn’t mean I could be a competent iOS or Mac developer. The same applies to Java and Java + iOS.

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?

> The ecosystem surrounding the language is a different story.

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.

Ecosystem as in knowing Java and Android. Knowing C# and Entity Framework/ASP.Net. Knowing Swift and iOS.

You say breaking compatibility between major versions is a reason to avoid something (eg Laravel), but also say you choose PHP and Python despite those languages doing the same thing. Maybe breaking between majors isn't the reason why you don't like Laravel, it just feels like that's the reason.

Breaking changes are a pain and you have to calculate the risk when using it. Laravel was my first framework (I jumped in at version 4.1) and maybe if was still moving fast at the time.

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.

AFIK, Dave Thomas is over 50 and is still regularly digging into new languages. Ditto for many if not most of the people at Prag Prog and it seems to have worked well for them.

This is the classic question of how set your explore vs exploit algorithm. You need a mix of both, but what is that mix?