5 ms·

> Look I'm not even complaining. But it feels like I'm stuck in a Franz Kafka novel. We just keep changing and changing the same things again and again because

> Look I'm not even complaining. But it feels like I'm stuck in a Franz Kafka novel. We just keep changing and changing the same things again and again because that's the new way to do. Big distraction. Destroys your workflow. Forget about all the util scripts you wrote last 6 months being useless. Here's how I stay sane -- I focus on the changes. For the technologies that you noted, here are some good questions that come to mind to set them in my brain: - What's the difference between CGI scripts and Serverless? - What's the difference between Terraform and Ansible? - What's the difference between a Bash script and a Makefile ? Is one more general than the other? Does one have a considerably better interface than the other? All the solutions look the same, but the distinctions between them (even at a relatively surface level) are what help to actually tell things apart and stop the feeling of endless churn. I think of it this way -- unlike other fields because the fruits of our research are immediately usable and almost zero-cost, we're given a front seat to the frontier of experimentation. It's a water hose, and you have to determine which streams are worth turning on/off, bottling for later.

noduerme 3y ago
I have this impulse to constantly experiment with everything too. And I think it's healthy for your brain to always be learning new ways and testing your preconceived notions of how you do things. A lot of times it leads to incremental advances, either in the next iteration of my existing code or the way I approach my next project. But a lot of it, I can admit, boils down to sheep shaving. When you start figuring out how you'd implement codebase 2009 in stack 2023, and then actually doing it, that's golf. It's all good, it's educational, but it's downright immoral to sell that to a client and drag them through it.
- hardwaresofton 3y ago
  > But a lot of it, I can admit, boils down to sheep shaving. AKA Yak shaving[0], which I am... unashamedly fond of doing >> There are yaks to shave all over the stack, and I go where the yaks are. (quote is from my github readme) > When you start figuring out how you'd implement codebase 2009 in stack 2023, and then actually doing it, that's golf. It's all good, it's educational, but it's downright immoral to sell that to a client and drag them through it. I definitely agree that selling this to a client when you've told them you'll do the minimum to update the codebase is immoral, but if there is value in updating, then you should expose them that value. For example -- moving a client to AWS might not make sense, but if they're maintaining on-prem infra and paying tons of money for an application that would actually cost less as a single ECS service (or App Runner, these days)... Then maybe you should upgrade their stack a little bit. In the end it's your job as a consultant or an employee (if you're high level enough) to introduce change that will make the company better, if you see an opportunity. Tech stacks crumble underneath their own weight, and if they're bad enough, become business risks. If it's humming along, easy to maintain, and isn't riddled with security holes, then great! [0]: https://en.wikipedia.org/wiki/Yak_shaving https://en.wikipedia.org/wiki/Yak_shaving
  - noduerme 3y ago
    My idea of a major overhaul for a client is upgrading from Mysql 5.7 to 8 with no downtime and then slowly, over a year, finding queries that could be sped up with lateral subqueries or window functions. That's about the pace, and it's effective at keeping resource use in check. The wilder things I experiment with on the side are once in awhile actually useful for a new app or service... I basically agree with you, if the cost of building the code will be easily outweighed by the savings to the client and I also think the platform will hold them for the next 10 years, I'll pitch it [e.g. I've moved many early clients from my servers over to AWS services when it made sense, and still maintain them]. But it's easy to see too how if I were trying to constantly drum up more work, it would be seductive to pitch them on new hyped up technologies they don't need, just to remain relevant and keep the checks flowing. I think that's the animating force behind all of this platform churn, not excited developers who just want to sheep or yak-shave (thanks. I always forget which ruminant I'm shaving ;)
re-thc 3y ago
> - What's the difference between CGI scripts and Serverless? > - What's the difference between Terraform and Ansible? Marketing and VCs
andrewflnr 3y ago
I would phrase almost the same idea from the opposite angle: focus on the fundamentals that never change, and view the trends in terms of how they relate to those fundamentals. But also, those are some pretty odd comparisons. For sure Ansible and Terraform aren't directly comparable. If anything they're complementary. Terraform provisions machines (and also infra, etc), and Ansible configures provisioned machines.
- kitd 3y ago
  Lord, teach me to accept the things I cannot change, And use version control for the things I can ...
- hardwaresofton 3y ago
  > I would phrase almost the same idea from the opposite angle: focus on the fundamentals that never change, and view the trends in terms of how they relate to those fundamentals. Definitely -- I'd say that these questions force the understanding of the fundamentals, because that's what you get down to ("fundamental"/irreconcilable differences). The problem is that fundamentals can be similar, and sometimes the difference is elsewhere (UX/DX/perf for example). > But also, those are some pretty odd comparisons. So they are odd comparisons, in some sense -- but the point was to reflect the kind of questions someone who didn't know the answer would ask. Ansible and Terraform (and Salt/Puppet/Chef) are often presented in similar context and they're often confusing precisely because they are so close but different. The other example (CGI vs Serverless) is situation that's somewhat more targeted towards the age discussion -- did we churn over the years for churnings' sake? > For sure Ansible and Terraform aren't directly comparable. If anything they're complementary. Terraform provisions machines (and also infra, etc), and Ansible configures provisioned machines. What you've said is the usual rebuttal (and it's mostly right!), but did you know that Ansible did/does provisioning?[0] The lines aren't drawn as neatly as they seem to be. You can build a Terraform-like experience out of Ansible, if you wanted to, and it's important to know that and why you choose a tool like Terraform instead of traveling deep into Ansible land. All that said, if you prefer, replace "Ansible" with "Pulumi" (Full Disclosure: I'm firmly on the Pulumi side in the Terraform vs Pulumi debate). [0]: https://docs.ansible.com/ansible/latest/collections/index_module.html https://docs.ansible.com/ansible/latest/collections/index_mo...
agumonkey 3y ago
I believe there's a spiraling pattern, where the same ideas reappear every N years but with slight internal or ecosystem changes. I'm not sure if we're running or circle of if there's a real slow progress.
- hutzlibu 3y ago
  I think it is mostly just adopting. To new hardware, new demands, new plattforms. There is maybe some progress on a academic level, but I don't think we progress fast on the fundamental level, on how to write better code. There are slight improvements here and there, but it is mostly just different. And more complex. Or rather new tools are needed because everything gets more complicated (some say bloated). That being said, the new thing that I am learning is general purpose GPU compute. That is quite new and useful (but hard). But it is an improvement.
  - agumonkey 3y ago
    Yes, that is indeed part of it. Everything changes, the ideas have to swim on top of that moving soil. And at times some integration occurs where a lot of ideas suddenly merge into a new cleaner brick.
- hardwaresofton 3y ago
  I think it's real slow progress, and sometimes even, quite fast. It's the same ideas, but I will assure you that most of the large things that people get crotchety about are legitimate moves forward. People were complaining about "docker" (i.e. cgroups + namespaces + some CLI UX) not too long ago and now you'd be dumb to try and deploy most applications without at least having that there. How many people are wrangling their own cgroups and namespaces (not counting systemd, which is another thing people fought, tooth and nail)? Should we all be doing 1 user per workload like the good 'ol days? Or maybe 1 machine/VM per workload like the 'ol 'ol days?

noduerme 3y ago

I have this impulse to constantly experiment with everything too. And I think it's healthy for your brain to always be learning new ways and testing your preconceived notions of how you do things. A lot of times it leads to incremental advances, either in the next iteration of my existing code or the way I approach my next project. But a lot of it, I can admit, boils down to sheep shaving. When you start figuring out how you'd implement codebase 2009 in stack 2023, and then actually doing it, that's golf. It's all good, it's educational, but it's downright immoral to sell that to a client and drag them through it.

hardwaresofton 3y ago
> But a lot of it, I can admit, boils down to sheep shaving. AKA Yak shaving[0], which I am... unashamedly fond of doing >> There are yaks to shave all over the stack, and I go where the yaks are. (quote is from my github readme) > When you start figuring out how you'd implement codebase 2009 in stack 2023, and then actually doing it, that's golf. It's all good, it's educational, but it's downright immoral to sell that to a client and drag them through it. I definitely agree that selling this to a client when you've told them you'll do the minimum to update the codebase is immoral, but if there is value in updating, then you should expose them that value. For example -- moving a client to AWS might not make sense, but if they're maintaining on-prem infra and paying tons of money for an application that would actually cost less as a single ECS service (or App Runner, these days)... Then maybe you should upgrade their stack a little bit. In the end it's your job as a consultant or an employee (if you're high level enough) to introduce change that will make the company better, if you see an opportunity. Tech stacks crumble underneath their own weight, and if they're bad enough, become business risks. If it's humming along, easy to maintain, and isn't riddled with security holes, then great! [0]: https://en.wikipedia.org/wiki/Yak_shaving https://en.wikipedia.org/wiki/Yak_shaving
- noduerme 3y ago
  My idea of a major overhaul for a client is upgrading from Mysql 5.7 to 8 with no downtime and then slowly, over a year, finding queries that could be sped up with lateral subqueries or window functions. That's about the pace, and it's effective at keeping resource use in check. The wilder things I experiment with on the side are once in awhile actually useful for a new app or service... I basically agree with you, if the cost of building the code will be easily outweighed by the savings to the client and I also think the platform will hold them for the next 10 years, I'll pitch it [e.g. I've moved many early clients from my servers over to AWS services when it made sense, and still maintain them]. But it's easy to see too how if I were trying to constantly drum up more work, it would be seductive to pitch them on new hyped up technologies they don't need, just to remain relevant and keep the checks flowing. I think that's the animating force behind all of this platform churn, not excited developers who just want to sheep or yak-shave (thanks. I always forget which ruminant I'm shaving ;)

re-thc 3y ago

> - What's the difference between CGI scripts and Serverless? > - What's the difference between Terraform and Ansible? Marketing and VCs

andrewflnr 3y ago

I would phrase almost the same idea from the opposite angle: focus on the fundamentals that never change, and view the trends in terms of how they relate to those fundamentals. But also, those are some pretty odd comparisons. For sure Ansible and Terraform aren't directly comparable. If anything they're complementary. Terraform provisions machines (and also infra, etc), and Ansible configures provisioned machines.

kitd 3y ago
Lord, teach me to accept the things I cannot change, And use version control for the things I can ...
hardwaresofton 3y ago
> I would phrase almost the same idea from the opposite angle: focus on the fundamentals that never change, and view the trends in terms of how they relate to those fundamentals. Definitely -- I'd say that these questions force the understanding of the fundamentals, because that's what you get down to ("fundamental"/irreconcilable differences). The problem is that fundamentals can be similar, and sometimes the difference is elsewhere (UX/DX/perf for example). > But also, those are some pretty odd comparisons. So they are odd comparisons, in some sense -- but the point was to reflect the kind of questions someone who didn't know the answer would ask. Ansible and Terraform (and Salt/Puppet/Chef) are often presented in similar context and they're often confusing precisely because they are so close but different. The other example (CGI vs Serverless) is situation that's somewhat more targeted towards the age discussion -- did we churn over the years for churnings' sake? > For sure Ansible and Terraform aren't directly comparable. If anything they're complementary. Terraform provisions machines (and also infra, etc), and Ansible configures provisioned machines. What you've said is the usual rebuttal (and it's mostly right!), but did you know that Ansible did/does provisioning?[0] The lines aren't drawn as neatly as they seem to be. You can build a Terraform-like experience out of Ansible, if you wanted to, and it's important to know that and why you choose a tool like Terraform instead of traveling deep into Ansible land. All that said, if you prefer, replace "Ansible" with "Pulumi" (Full Disclosure: I'm firmly on the Pulumi side in the Terraform vs Pulumi debate). [0]: https://docs.ansible.com/ansible/latest/collections/index_module.html https://docs.ansible.com/ansible/latest/collections/index_mo...

agumonkey 3y ago

I believe there's a spiraling pattern, where the same ideas reappear every N years but with slight internal or ecosystem changes. I'm not sure if we're running or circle of if there's a real slow progress.

hutzlibu 3y ago
I think it is mostly just adopting. To new hardware, new demands, new plattforms. There is maybe some progress on a academic level, but I don't think we progress fast on the fundamental level, on how to write better code. There are slight improvements here and there, but it is mostly just different. And more complex. Or rather new tools are needed because everything gets more complicated (some say bloated). That being said, the new thing that I am learning is general purpose GPU compute. That is quite new and useful (but hard). But it is an improvement.
- agumonkey 3y ago
  Yes, that is indeed part of it. Everything changes, the ideas have to swim on top of that moving soil. And at times some integration occurs where a lot of ideas suddenly merge into a new cleaner brick.
hardwaresofton 3y ago
I think it's real slow progress, and sometimes even, quite fast. It's the same ideas, but I will assure you that most of the large things that people get crotchety about are legitimate moves forward. People were complaining about "docker" (i.e. cgroups + namespaces + some CLI UX) not too long ago and now you'd be dumb to try and deploy most applications without at least having that there. How many people are wrangling their own cgroups and namespaces (not counting systemd, which is another thing people fought, tooth and nail)? Should we all be doing 1 user per workload like the good 'ol days? Or maybe 1 machine/VM per workload like the 'ol 'ol days?