In my experience, rewrites are most of the time motivated by switching to the latest hyped stack than anything else.
Nobody rewrites anything in the same stack/technology.
1,678 karma · joined November 29, 2016
Nobody rewrites anything in the same stack/technology.
Where you think a long call should be allowed somebody else will think it should be split.
Pick a code formatter, and fuck opinions, we'll do whatever the formatter says we have to do. Done. It is not that important if you put semicolons here or there as long as it is consistent.
You don't. The same JavaScript is not 20 year's ago JavaScript, PHP is not 20 year's ago PHP, etc, etc.
Not doing an SPA doesn't mean form POSTs for a like button reloading the whole page or doing jQuery spaghetti. MVC and server side templates rendering has come a long way too.
Some technologies that would make your reservation system trivial to implement with this approach:
- Hotwire (Rails). See https://hotwired.dev/.
- Livewire (Laravel). See https://tallstack.dev/.
- Unpoly (fw agnostic). See https://unpoly.com/
and there are many others.
The caveat here is that you need an open minded engineering team that are happy with using programming languages as tools to build something and not js/python/elixir fanatics which can't touch anything which is not js/python/elixir/etc.
Can see how 1 year from now it is a totally different thing impossible to update without rewriting everything because they've got a new idea.
All of these things are pretty easy to do with Rails and Laravel. I don't see how Flask or express or the home made framework on top of those could make anything of this easier. Other than writing the code yourself and not needing to read documentation (which will be a problem for future maintainers) I don't see any advantage for anyone except the one writing it for the fun of it.
Not my experience at all. The "new requirements" you mention are always about business, not technical. Frameworks like Rails, Django and Laravel solve a pretty good bunch of the technical challenges which, in my experience, are common to the 90% of everything we build in most web based companies.
I've seen this argument of let's use flask/sinatra/express/fastapi because I need the flexibility/it is just a simple service too many times. And every single one ended up in a frankestein mix and match of 10s of other libraries that some developer ( now gone, of course) decided at the time was the best thing in the world until he got bored.
Also, you're not forced to use everything in these frameworks. If you think your application just needs routing, you can also use them and call it a day. If it happens 3 years down the line that you need an ORM, then you have it right there waiting for you.
As I said many times over here: If you have a terrible manager/lead, if you are drowned in useless time consuming scrum rituals and can't get work done, if you are asked to work more hours you're paid for, if you're not happy with your salary or anything similar to this and you can't see this changing in the short term, just find a new job. If you already have a job as a developer it will take you almost no time to find something else.
Right, your next company might have some of these problems as well. F*ck them too and keep searching until you find something you like. There are a LOT of great companies to work for out there, but it takes time and research effort to find them.
I've left companies just after 2 months because I've given crappy laptops and forced to use tools (such as local editors as crazy as "Scite") because the CTO was a fanboi of it.
I've left companies after 2 or 3 months because they were scrumb-by-the-book extremist who didn't had a clue what they were doing but scrum was good because the book the PM read said so.
I've left companies because after 2 years was earning almost the same salary than when I joined while my market value was a lot higher (now I'm earning about 2.5X).
So are you in a crappy company? They don't want to change their bad ways? Good luck to them, I'm not working there.
The amount of effort wasted is just not worth it in 90% of the cases.
In fact, this is what you usually do with "worker" nodes that do background jobs.
And you can always have feature flags/environment variables to disable everything you don't need in a given cluster.
Of course they can do that too. But this is clearly screwing up people, as it is not easy to change a lifetime email address.
If they say I cannot store my photos anymore, that's fine. I can move them. Changing an email address is not an easy thing to do. Or losing all your Google play purchases.
But yeah, at the end of the day nobody is forced to do anything for free (despite nothing google offers being free, as they sell ads with my data) but this shows just how you cannot trust anything from Google.
Personally my solution to this will be to pay for iCloud and move everything over there. I had planned moving to iPhone for privacy reasons anyway, so this is just another nail on the coffin for using any Google service ever again.
Transfer your custom domain to Google Domains (you have to pay for your domain registration as usual), as they allow to set up free email forwarding to your free gmail account.
This only works if you just want to not lose your email address (as me). Of course this is not a solution if you also rely on calendar, docs, etc...
- https://www.yammer.com/ (is this still a thing? used it like 10 years ago)
- etc...
We also used slack (or equivalent... also used hipchat, and even jabber before that) for ephemeral, one off, non important stuff. And then a lot happens also in READMEs, Merge/Pull Requests, Gitlab issues, helpdesk tickets, etc. Not much use of emails other than for notifications.
At the end of the day everything has a link and things can reference each other.
I think what most companies are missing is a way for employees to "post" and "subscribe" to updates that are interesting for them.
Salaries might at some point stabilize I suppose, as people will prefer to relocate to cheap places and overall there will be more offer of developers charging less money.
Overall I think this is a win-win for everyone (except middle managers that like micromanagement, those are the ones worried right now).
In my experience, either the entire team is in a single place or all of them are remote. Now having teams some teams in the office and some others 100% remote, that could work, but I'm skeptical too.
There is no enough money in this world to make me go back to 2~3 hours a day commute in a crowded bus.
The last two companies I've worked for where 100% remote, in both of these places engineering was a lot more productive. I personally invested less total time in work (about 7 or 8 hours total) and got a lot more done.
Both of these companies had a culture of writing things down, so everything was documented, an all important conversations where posted in the open for anyone to see. Everything is searchable.
For the kind of work I do (web development) in-person interactions are only good for middle managers that enjoy micro managing as a way to justify their job.
What does not work is to try to keep doing the same things you did in the office in a remote way. You need to adapt to the new context.
If your company went remote and suddenly you have 5 video calls a day, you're doing it wrong. Of course it will be worse and less productive.
Over Django: - Because if not doing SPAs, it provides infinitely better tools for the frontend, such as an integrated assets pipeline, a good template language with componetisation support - Because it is faster - Because during development every change is not a restart - Because it has an integrated queue system - Because you have popular frontend solutions such as Livewire
The only better thing I've found in Django is the admin.
Over Rails: - Because it is faster - Because PHP is far, far, far more popular tan Ruby - Because it has integrated authentication - Because it is easier to hire for
just some reasons from the top of my mind. I don't have a ton of experience with Rails and I think it is still great, but IMHO Laravel is better. I have worked with Django for about 10 years, and other than the Admin, I don't miss anything when working with Laravel. Language wise PHP vs Python is just syntax, I don't care as both ecosystems are pretty healthy.
This is like saying "React is bad because once I had a problem I don't remember".