Thought it seemed like a great idea but I never tried it. In a startup it seemed like an unnecessary source of risk and in an enterprise too much hassle to convince stakeholders to switch from existing IaC products.
In my last company, we _did_ pay for Google Cloud support and when BigQuery jobs started to fail randomly, causing huge trouble producing critical reports, the response was essentially "we are investigating", "we have identified the issue", and "please wait for it to be fixed". Hardly what I would call support. They couldn't care less.
The post is light on details. I'd guess the author ended up hammering the API and they decided it was abuse.
I expect more reports like this. LLM providers are already selling tokens at a loss. If everyone starts to use tmux or orchestrate multiple agents then their loss on each plan is going to get much larger.
Author here, thanks for reading. Yes, naming is tricky. By mono-environment, I mean that there is one _long-lived_ environment to which we deploy software.
I'm constantly surprised by developers who like LLMs because "it's great for boiler plate". Why on earth were you wasting your time writing boiler plate before? These people are supposed to be programmers. Write code to generate the boiler plate or get abstract it away.
I suppose the path of least resistance is to ignore the complexity, let the LLM deal with it, instead of stepping back and questioning why the complexity is even there.
> Write code to generate the boiler plate or get abstract it away.
That doesn’t make any sense. I want to consider what you’re saying here but I can’t relate to this idea at all. Every project has boilerplate. It gets written once. I don’t know what code you’d write to generate that boilerplate that would be less effort than writing the boilerplate itself…
>Every project has boilerplate. It gets written once.
Agree with you - I think when my colleagues have talked about boilerplate they really mean two kinds of boilerplate: code written once for project setup, like you describe, and then repetitive code. And in the context of LLMs, they talking about repetitive code.
Interesting. I don't recall this happening during my studies. You didn't have the time in my exams to cheat, leaving for the toilet was strongly discouraged and if you did leave, you would have an invigilator standing behind you at the urinal or outside the cubicle.
The article is about accountancy. Accountancy is not academia.
>In the end of the day academia in general should stop relying on exams based on memorization of random facts and start using real world examples of what kind of work student would be working with as an employee.
I have an undergraduate degree and PhD in chemistry and I don't really think "blind memorisation" had much to do with my success. It will only get you so far.
I think there is also substantial within academia about the purpose of academia. I think a lot of academics might disagree that it is about preparing people to be employees.
Statistically, how many people will become private employees and how many people will stay in academia to do science? Disagreement is just denying reality.
I absolutely loathe when someone is looking over my shoulder. Additionally, the software for pairing is so good and being able to be help and annotate while the main "driver" can focus on solving the problem is immensely fruitful and I would argue objectively more engaging and helpful if you can highlight and demonstrate directly what it is you're communicating.
I work remote and wouldn't have it any other way, but I'll admit there are culture things I miss since I really love my team. As an employee? My employer gets way more value from me without the bullshit of going to an office.
I dislike it in general, I want to work on my own terms and I have to interrupt my way of thinking constantly because now I have to communicate my ideas to some other person.
Sometimes I like to work in the middle of the night, sometimes early in the morning. Having another person to code with me is just a blockade.
In my opinion, the openings to pair are harder to find when remote.
In person, it's usually easy to see when a junior is struggling, and pull up a chair. That same junior, in a remote environment, might not proactively ask for help. And me sending a slack message to them asking how they're doing might get a "all good" even when they are not. And sending a huddle request to them because I suspect they're struggling is just a VERY different thing than looking over at them to read their body language, or swinging my their desk to check in.
Maybe some would say that it's on that junior to know they need to ask for help. Sure, great. That does nothing to resolve the reality of this very real situation. Of course part of coaching this junior (in person or remote) would be encouraging them to be more proactive about asking for help, but if you have fewer opportunities to offer help and coaching in the first place, their growth is slower. Significantly slower in my opinion.
This is a hard difference to convey to someone who has never experienced a good in-person culture. But I know I would not be where I am if I had spent the first decade of my career working remotely.
What is your setup when pairing remotely? (Full disclosure I am building an OSS app for this purpose and just want to learn what is working for people)
Our team uses IntelliJ so we use Code with Me with Slack for AV. Specifically on Slack we have channels called pairing-room-1, pairing-room-2, etc. Allows colleagues to drop in and out.
I would try Tuple but to be honest we are fine on Code with Me.
Indeed Tuple is a great product. The goal is to match their quality and make it the OSS alternative, it's still early though, and I am trying to get some feedback.
Thought it seemed like a great idea but I never tried it. In a startup it seemed like an unnecessary source of risk and in an enterprise too much hassle to convince stakeholders to switch from existing IaC products.
I admired their commitment to open source.
reply