This is pretty relevant for things like claude-code, which has a fairly rudimentary way of dealing with permissions with block-lists and allow-lists.
I once accidentally gave my claude "powershell" permissions in one session, and after that any time it found it was blocked from using a tool, e.g. git, it would write a powershell script that did the same thing and execute the script to work around the blocked permission.
Obviously no sane system would have "powershell" in a generic allow-list, but you could imagine some discrepancy in allowed levels between tools which can be worked around with the techniques on this page.
Power Shell or Python scripts to work around restrictions are the go to for LLMs.
And it doesn't stop there.
Yesterday I was trying to figure out some icons issue in KDE plasma (I know nothing about KDE). Both Claude and Codex would run complex bus and debug queries and write and execute QML scripts with more and more tools thrown into the mix.
There's no way to properly block them with just allow- and block lists
> There's no way to properly block them with just allow- and block lists
Especially not when some harnesses rely on the reliability of the LLM to determine what's allowed or not, pretty much "You shouldn't do thing X" and then asking the LLM to itself evaluate if it should be able to do it or not when it comes up. Bananas.
Only right and productive way to run an agent on your computer is by isolating it properly somehow then running it with "--sandbox danger-full-access --dangerously-bypass-approvals-and-sandbox" or whatever, I myself use docker containers, but there are lots of solutions out there.
You have to be extremely careful when you set up a dev container, lock down file access, do not give the agent the power to start other containers or "docker compose up", restrict network access to an allow-list etc. Just running the agent in a container does little to protect you. (Maybe you know this, but a lot of people don't!)
Most of those things are what happens by default. Sure, be careful, but by default it's secure enough to prevent most potential issues. No need to lock down file access for example, by default it only has access to files inside the container, and of course by default containers don't have access to start other containers, and so on.
Good word of caution though, make sure you actually isolate when you set out to isolate something :)
As mentioned, "podman/docker run -it $my-image codex" also actually has the requisite isolation by default, no need for special software. Biggest risk is accidental deletion of stuff, easily solved without running an entire VM, which "smol" machines seems to be. No doubt VMs have their uses too, but for simple isolation like this I personally rather use already existing tooling.
Ok, YMMV, but a smolvm provides macOS-native, per-workload isolation -- vs trad container depending on a daemon and relying on namespaces (w/ a shared kernel). Easy "packing" into single-file executables, and a nice SDK, make it ~ideal for my needs; great balance of security:convenience.
Cool ad bro, but stop claiming container won't get you "per workload isolation" just because they share kernels, in the context of this discussion it hardly matters, containers isolates enough for this.
I imagine someone probably wrote very specifically about it in the training data that underwent lossy compression, and the LLM is decompressing that how-to.
So I'd say it's more like "surfacing" or "retrieving" than "re-discovering".
They scraped everything on Stackoverflow, likely IRC logs from Freenode, and every book written in the modern era courtesy of Sci-Hub / Library Genesis / Anna's Archive / Z Library.
RIP Aaron Swartz, they're generating trillions in shareholder value from the spiritual successors to the work they were going to imprison you for.
For the LLM it's a probabilistic set of strings that achieves the outcome, the highest probability set didn't work, try the next one until success or threshold met. A human sees the implicit difference between the obvious thing not working indicating someone doesn't want you to do it, but an LLM unless guided doesn't seen that sub-text.
So chmod +x file didn't work, now try python -c "import os; os.chmod('file',744)"
Humans and LLMs both only see that when given the right context. A tool not working in a corporate environment may be anything from oversight, malfunction all the way to security block. Knowing which one it is takes a lot of implicit knowledge. Most people fail to provide this level of context to their LLMs and then wonder why they act so generic. But they are trained to act in the most generic way unless given context that would deviate from it.
Trello does not work in Russia. You cannot install it on your server in the company's closed loop. There is no task number, there are no subtasks, you cannot see the progress of subtasks on the parent's board. There is no analytics. There is no page where you can view all the tasks that can be taken on. The service does not claim the laurels of solving all problems, but it is unique in its own way.
That's exactly what claude-code does these days. If you AFK for ~5 minutes it also produces a summary of where you are, which is useful if you're juggling multiple windows.
Azure-dev ops explicitly has an "Approve with suggestions", I suspect it was designed for when there are multiple acceptances required, but I sometimes use it anyway.
Whether those comments get read once approved, I don't know.
I found the same, it was super careful handling the environment variable until it hit an API error, and I caught in it's thinking "Let me check the token is actually set correctly" and it just echoed the token out.
( This was low-stakes test creds anyway which I was testing with thankfully. )
I never pass creds via env or anything else it can access now.
My approach now is to get it to write me linqpad scripts, which has a utility function to get creds out of a user-encrypted share, or prompts if it's not in the store.
This works well, but requires me to run the scripts and guide it.
Ultimately, fully autotonous isn't compatible with secrets. Otherwise, if it really wanted to inspect it, then it could just redirect the request to an echo service.
The only real way is to deal with it the same way we deal with insider threat.
A proxy layer / secondary auth, which injects the real credentials. Then give claude it's own user within that auth system, so it owns those creds. Now responsibilty can be delegated to it without exposing the original credentials.
That's a lot of work when you're just exploring an API or DB or similar.
When they decide to touch something as they go, they often don't improve it. Not what I would call "refactoring" but rather a yank of the slot machine's arm.
> In practice, it was seldom done, and here we have LLMs actually doing it, and we're realising the drawbacks.
I spent some time dealing with this today. The real issue for me, though, was that the refactors the agent did were bad. I only wanted it to stop making those changes so I could give it more explicit changes on what to fix and how.
>The idea being that if you're working in an area, you should refactor and tidy it up and clean up "tech debt" while there.
This is horrible practice, and very typical junior behavior that needs to be corrected against. Unless you wrote it, Chesterton's Fence applies; you need to think deeply for a long time about why that code exists as it does, and that's not part of your current task. Nothing worse than dealing with a 1000 line PR opened for a small UI fix because the code needed to be "cleaned up".
That is the flip side of what you're arguing against, and is also very typical junior behaviour that needs to be corrected against.
Tech debt needs to be dealt with when it makes sense. Many times it will be right there and then as you're approaching the code to do something else. Other times it should be tackled later with more thought. The latter case is frequently a symptom of the absence of the former.
In Extreme Programming, that's called the Boy Scouting Rule.
The Boy Scout "leave it better than you found it" is a good rule to follow. All code has its breaking points, so when you're adding a new feature and find that the existing code doesn't support it without hacks, it probably needs a refactor.
This is a real pain, I notice over-editing a lot when using AI coding tools locally and also re-inventing the wheel (e.g not using external libraries or reimplementing something over and over again). The Boy Scouting Rule is a good framing, but the tricky part is deciding when we apply it and what's actually a 'minimal' change. Maybe smt like 10% of the PR should be refactor max, and if is more open a new PR?
Indeed there's a distinction that needs to be made here between "not refactoring this code means I'll need to add hacks" and "Oh I'll just clean that up while I'm in here." The former can be necessary, but the latter is something you learn with experience to avoid.
> the latter is something you learn with experience to avoid.
The latter is something you learn to judge the right time to tackle. Sometimes a small improvement that's not required will mean you're not pressed to make the refactor to avoid hacks. The earliest you can tackle problems, the cheaper they are to solve.
Before, not after: when the code makes it hard to implement a new feature (the definition of technical debt: code that is properly designed but only for previous features), first refactor the code to make the feature easy to implement, then implement the feature.
So I think theres some more nuance than that.
A lot of the times, the abstraction is solid enough for you to work with that code area, ie tracking down some bug or extending a functionality.
But sometimes you find yourself at a crossroad - which is either hacking around the existing implementation, or rethink it. With LLMs, how do you even rethink it? Does it even matter to rethink it? And on any who, those decisions are hidden away from you.
Really? I've never heard it's considered wise to put refactoring and new features (or bugfixes) in the same commit. Everyone I know from every place I've seen consider it bad. From harmful to a straight rejection in code review.
"Refactor-as-you-go" means to refactor right after you add features / fix bugs, not like what the agent does in this article.
Notice how they didn't say to put it in the same commit. The real issue, and why refactor as you go isn't done as much, is the overhead of splitting changes that touch the same code into different commits without disrupting your workflow. It's not as easy as it should be to support this strategy.
I think you're talking about a different topic unrelated to the linked article. In the linked article the LLM doesn't split it into several commits. If LLM had a button to split the bug fix and the overall refactoring, the author wouldn't complain and we wouldn't see this article.
That's a real question, maybe the changes are useful, though I think I'd like to see some examples. I do not trust cognitive complexity metrics, but it is a little interesting that the changes seem to reliably increase cognitive complexity.
The problem is that there is not enough infrastructure for EVs. If you can't charge at home (e.g. you live in a flat), it is hard to live with an EV and it's much more expensive than the ICE.
I had a rental EV while I was there for 6 weeks last summer, it was a pretty low spec jeep model and I stayed at mates places all over England none of which had parking or charging, to tell the truth charging was a bit spotty in town, but if I was just going around the local area the battery was good for a week or more. My take away was I would definitely rent an EV again, but a lot of the older charging infrastructure still sucks, under-provisioned at peak times, and cost 2-3 times what a similar charge would cost here in NZ. I ended up doing most of my charging at the Tesla superchargers on the motorways and at supermarkets in town. I did 2900 miles total and it was about the same cost as petrol in the end, but worth it as the EV was cheaper to rent and was automatic (which renters charge a premium in UK)
Not sure fast charging all the time is good for battery life though. 99% of my driving in NZ is on a normal 10A overnight charge
Local government can quickly change that, if they get their act together. Here in the Hague, there's literally thousands of public chargers available on the city's residential streets. Coupled with the fact that the charging-price is city-mandated at a fixed rate (currently around 35ct/kwh), this gives a perfectly fine solution for most people. (I can charge at home, for 20ct/kwh currently, so that's even nicer)
Not in the UK. Local governments (councils) are going bankrupt and are saddled with an overwhelming burden to pay for adult and child social care. There's no money for much else
What is actually the realistic cost. Covering infra, the charger and the maintenance of everything involved. Power and transfer included, with transfer including any standing charges. And after that you probably want decent margin to well run the business.
I don't expect 10 thousands of the fast chargers in my town.
I'd love to have slow chargers built into the street lights. Not everyone owns a house, and the public charging usually meets or exceeds the petrol price per mile.
If you're referring to DC charging it's going to be pretty expensive. The construction and power electronics for a DC station is going to be in the millions.
For AC the rectifier is inside the car and the L2 chargers is just a fancy plug. Price should just be the base electricity cost.
Governments would do better to try to fix the bureaucracy around installing L2 chargers in shared living spaces. It's a problem they created and it should be on them to fix. But it guess that's harder than impossible mandates and high EV taxes.
If a significant percentage of cars start to become EVs then spaces where people regularly park overnight will get chargers because it will allow whoever is operating them to make a bit of money selling electricity. You don't have to be making a huge profit margin to make it worth your while to have people passively buying ~200kWh/month of electricity from you.
The same applies to workplaces, especially if solar causes electricity to cost less during daylight hours, and then it becomes convenient to get an EV if there is a charger where you park at night or where you park during the day.
that would depend on the infrastucture cost to install such charging and to maintain it? This is kerbside slow charging presumably overnight. Note that spaces in these residental areas are typically not even marked spaces; the worst outcome might be losing more footpath space to charging infra for road users.
Non-fast chargers aren't very big. They can be installed in lampposts, or in lampost-diameter boxes sunk into the pavement (with the socket sticking out at the top)
About 65% of homes are owned (either outright or via mortgage), but I can't estimate how many of them have garage or off street/driveway parking they can charge their car on.
There's usually very little of the garage space available.
Electricity is expensive in the UK (~25p/kWh) But not gas car expensive. It is £1.57/L (£5.94/gallon).
The EV infrastructure is also pretty dang far along, especially compared to the US. Remember that everything in the UK is a lot smaller and closer together than it is in the US. Further, the UK has a functional train system for long distance travel. You can go from the top of Dunnet Head to Lizard Point in a 15 hour drive.
People downvoting me, Look up chargers in plugshare to see just how many there are in the UK, it's a lot. And also correct my math if it's wrong. An 80kWh car costs £20 to fill up. A 55L car, which has about the same range, costs £85 to fill up.
Also if you are able to charge at home you can subscribe to a smart tariff that gives you electricity for 4p/kWh overnight. That’s £3.20 to fill an 80kWh battery that on a modern car will take you up to 320 miles.
It's cheaper to purchase new bike/used car, tax and insure it, service and fuel, than to use train to ride to work.
Annual train ticket form my small town (25 miles from the Zone 1 of London) is over £5,500. Five GRAND. For the pleasure of standing every time and a much higher risk of getting mugged.
£15k will give you REALLY nice bike or pretty new car. After third year you're saving thousands. Of course if you decided to buy something old and used, you're saving from the second quarter of the first year on.
It's only functional because not everyone can afford another car to work.
It can be, depends on a lot of factors. Obviously flying ryanair will often be the cheapest way to go, but if you do any sort of other regular airline trains will quickly start to win out.
And it's not as if you can fly everywhere in england. As soon as you start looking at more oddball flights (for example, london to birmingham) ryanair goes away as an option and all the flights end up super expensive.
Trains, on the other hand, remain cheap for pretty much the entire nation. You can basically go anywhere by train for under £60. A lot cheaper if you book in advance.
That is because of the cost structure of trains vs planes. Trains require a huge amount of infrastructure, and have higher labour costs because they are slower (so the same journey means people work for longer).
Another problem is that fuel taxes are a reasonably equitable means of paying for the roads, and EVs don't have that -- the closest would be vehicle miles * weight or some such.
Equivalents of fuel taxes for EVs have been announced recently - charging directly on a per mile basis.
> The rate of tax will be 3 pence per mile for fully electric cars; this is around half of the 6 pence per mile the average petrol or diesel driver pays in fuel duty.
In my state they decided to tax EVs punitively through our annual registration fee. I already pay an additional $200 for my EV registration, which is $50 more than the average ICE driver pays is gas taxes. I drive considerably less than the average TN driver. Next year it will be $274.
At least in the US, EVs are not heavier than the average driver's vehicle, though they are heavier than other vehicles in their class. And practically all consumer vehicles are nothing compared to semi trucks.
that is absolutely not the problem. We have more than enough li, subject to cost of extraction. New chemistries dont even need it. you need to update your talking points.
This won't happen unless they outright ban non-EV vehicles which is unlikely considering how many people are still using old cars and cannot afford new cars, how many car enthusiasts are there, and not to mention potential lobbying from big oil.
So 20 years from now, all the old gas regular people cars have aged out. You’re left with what, 1 or 2% of enthusiasts cars? Seems like success to me, and fairly inevitable
There will undoubtedly be a death spiral of sorts when it comes to gas stations, refineries, etc. where they become fewer and farther between as less people buy fuel. And that makes it more expensive and inconvenient, so more people buy EVs, which in turn...
Death spiral to gas stations? why? EV cars need to charge somewhere (and on long trip it can’t be at home) and people need to take a break and grab a coffee sometime too. They will change, sure, but certainly not die.
Refineries will be fewer but we do need another products from them also.
Presumably a lot of people will charge at home which significantly cuts down the number of stations needed or the traffic to those stations.
For example, I have 2 gas stations within a mile of my home. They stay pretty busy because people around me constantly need to fill up. I, on the other hand, basically never visit either of those stations since I switched to an EV. I charge at home.
If everyone around me switched to EVs, those stations could not stay in business. There's a grocery store in the same area which makes anything those stations offer obsolete.
Those are the majority of gas stations that die with a mass switch over to EVs. There's a gas station for my hometown without an attached convenience store with 300 people there. There's no way that station stays in service if a significant portion of the community switches to EVs. It already struggles to be profitable as is (I know the owner).
That might be the case in places where most people live in single-family homes with dedicated garage.
Where I live (Spain) that's not the case at all - our towns are very dense. People in big cities tend to live mostly in flats (Europe's highest elevators-per-capita). Even people in the countryside, where it's more common to have a 1-family homes, often don't have a dedicated garage.
Chargers can be anywhere. They are at grocery stores, parking lots, restaurants, I can see the need for a dedicated re fuel station to disappear when charging is ubiquitous.
This is what people don’t get. Charging just means parking. The idea of dedicated charging stations where you stand around doing nothing, maybe buying a candy bar, really only make sense in the context of a fuel which is not literally already everywhere.
I've seen this on the Autobahns: what were just parking spots with unattended bathrooms are becoming little charging stations. Since I don't have an EV yet, I've not stopped at one to see how high-speed the chargers are, but at the very least, I assume that 10-15 minutes would be enough to get you somewhere more efficient/pleasant to wait for a full charge.
Charging stations will only need to be on highways if cities are sensible and build slow charging infrastructure (aka normal wall sockets) in parking spaces. Urban gas stations will be a thing of the past.
A place where you can take a break and grab a coffee is called a cafe, not a gas station.
Also, with Chinese manufacturers increasingly pushing out batteries capable of 1000+ km, you'll be able to charge fully at home for increasingly long road trips.
In 2045 petrol stations will be well on the way the being about as rare as places selling paraffin or special racing car fuel today.
I don't see how this is an interesting bet. No new petrol car will have been sold for 10 years. Places selling fuel for large lorries etc will last a bit longer, but these are already a fraction of the total.
Does anyone have reliable data on the number locations selling avgas in say, the U.S. compared to the number of locations selling automobile grade gasoline?
This has already happened in Norway, where 96% of new cars sold are EVs. They didn’t ban combustion but they did support adoption with subsidies and other incentives
The problem is a 50kWh battery in a car is worth more as a battery than a typical £1500 car.
The lowest end of the market won’t have electric cars unless the batteries are shagged (early Leafs)
And given how insanely cheap petrol is (15p a mile, so £450 for a low mileage runaround) the savings even if electric was free and they weren’t introducing a 3p/mile charge isn’t there.
A £1500 car is £1500 because it's expected you'll need to replace the engine or transmission pretty soon. That can be up to a £4000 job (£2500 on the low end).
And, as it turns out, a brand new 50kWh battery costs around £4000 to manufacture. Used will be cheaper.
With most modern ICE cars everything but the transmission and the engine will fail before those two go out.
Also: I don't think that's the usual case. Plenty of sub 2k cars that will happily keep driving for years (I've had 3 such cars). ~700 mark is where you start seeing 300k mile "finish-them-off"-type cars.
Plenty of EVs will drive for years as well (so long as they have a good thermal system for the battery). So I'm not sure what point is being made.
Saying "It costs a lot of money to replace the battery" doesn't mean much as the battery, even if it has 70% of it's original capacity, is still perfectly functional. Very much the same as the engine which also costs a lot of money to replace.
I just thought the parent comment was unfair to ICE cars to make the EV proposition sound better. I'm a fan of EVs but they are still more expensive to buy.
That said, very cheap ICE cars have a sweet spot where any damage to engine / transmission / clutch+flywheel often means replacing the entire car since the repair cost exceeds the market value of the car.
>A £1500 car is £1500 because it's expected you'll need to replace the engine or transmission pretty soon.
Really not true at all. Care to share your sources for this claim? Anecdotally, I've (plus friend and family) owned plenty of beater cars in that ballpark price, and none had failures needing to replace engine or transmission. Most of their faults came in the electronics (sensors, actuators, fuse box, wire harness) plus suspension, body rust, etc basically the same parts EVs also have.
Meanwhile, if you look up 'EV clinic' postings online, you'll see they find plenty of design failures with European and Korean EVs that are basically ticking timebombs(sometimes literally, hello Stellantis) where electric motors, inverters or battery packs are guarantee to fail in a short timeframe due to various design faults that were entirely preventable. Most common faults with poor EV designs I saw, seem to be the seal of the electric motor stator cooling which fails quickly leading coolant to flood the motor rotor killing it, needing a rebuild.
From what I gather from their analysis', the crux of this issue seems to be that some modern EVs, especially those less premium ones, are cost cut to the extreme in a race to the bottom to maintain shareholder value, both at manufacturing but also at design phase, leading to cut corners everywhere and such issues being a common occurrence and manifesting en-masse after their warranty runs out. From their analysis, IIRC Tesla's powertrains seem to be some of the most reliable and well designed, with the likes of Audi, VW, BMW, Mercedes being less so and Stellantis being trash tier.
Meanwhile, plenty of older ICEs are largely immune form such massive reliability faults, because they benefited from decades of industrial design and development experience done in a past era where race to the bottom cost cutting and planned obsolescence weren't yet a thing. So I wouldn't be surprised when an older 1500$ ICE car will last longer than a 1500$ EV.
Battery prices are still falling though, it's just demand is enormous. But I works fully expect China to start having "compatible replacement packs" being built once the volume is there to support it.
A logical future market is battery-refurbished EVs, just a question of where the crossover point is.
"Gas" prices are hiking up here - its about £1.90 per litre of diesel at the moment and petrol isn't much less.
In contrast, my cheaper 'leccy rate is now about 25% less at 5.2p per kWh than it was. Electricity is weird in the UK - its pinned to the price of gas and is currently (lol) rather expensive "on peak" at 27.87p per kWh and there is a day standing charge of 47.71p. That's from Octopus.
We also have a petrol car - an elderly Renault Clio. It does just run and run and is pretty economic for a pretty shagged out ICE.
My EV is cheaper to run, by far. However, its unlikely the battery will last 20 odd years. I haven't yet sat down and done some whole life costs for ICE vs EV yet.
My Saic MG4 can do 300+ miles on a 100% charge of its 78kWh battery. After two years, it still manages to exceed its WLTP (with care, when required) and I quite like the ridiculous 0-30 acceleration etc.
It sounds like ICE buyers are subsidizing EV buyers. The math starts to get ugly as EVs become a larger percentage of the mix. ICEs will be priced out of the market, but there won't be anyone left to subsidize the EVs. In short, it sounds like buying a car is about to get a lot more expensive in the UK.
In Germany for example(and other EU countries) you get money back from the government on your tax return for your daily commutes to work, if you live far away enough from work to qualify for commuter subsidies. Those subsidies you get no matter which transportation you use, bicycle, train, car, etc. And plenty of people commute by car when their work/home is far away and remote enough for cycle/public transportation to not be very useful or convenient.
Funny how their solution was to subsidize burning fossil fuels for car commutes to the office instead of, oh I don't know, MANDATING WFH!, given Germans are such staunched green environmentalists. Sure, let's turn off nuclear and ban plastic straws, but let's also subsidize the generation of diesel, brake pad and tire fine dust particles we breathe in, for commuting by car to work. We can't forget our car industry lobbyists.
I am guessing its a deduction in calculating your taxable income. You also say it applies to all forms of transport. That is not a subsidy. It is not different from allowing a factory that uses a fuel to deduct the cost of that fuel in calculating their taxable profits.
Some countries literally subsidize gasoline, but even if your country does not it probably supports oil companies with tax breaks ('creating jobs'). There also are lots of untaxed externalities like global warming and exhaust pollution.
They are not so different: it's the same private/public money dynamic but money flowing in different ways. For consumers it doesn't really matter if it's a tax or 'mandatory levy'. For instance: in the EU it's mandatory to pay for disposal of consumer goods, which is priced in with every purchase. That's as close as a 'disposal tax' as you can get.
In the US, at least, we directly subsidize fossil fuels to the tune of billions of dollars a year -- just counting the above-board, direct subsidies through legislation. If you count indirect subsidies, the figures are staggering.
But put a $7500 point-of-sale rebate on an electric car and people go nuts. So the solution is either make the EV subsidy less obvious, like we do for fossil fuels, or try to educate people on where their tax dollars actually go. The former is more feasible, certainly, in the modern political environment where ideology rules over facts.
That is the aim. Its not a bad idea to reduce the number of cars (at least in cities) but the problem is that the British government wants to drastically reduce the number cars without spending on providing more public transport.
But you know what's also frustrating? Code bases which involve multi-step manual steps to build.
You should be able to get a working local environment with a single command.
You should be able to get a working local build with a single build command.
If you have depedent projects, they should either be in a monorepo, or delivered through a packaging system so they are not depend on the specific local naming of other repos.
Having a repo depend on a different repo being in a specific place on the file system is bad, having multiple of them is terrible.
Stick what's needed in an onboarding script, and make sure it works before onboarding someone.
Ideally that script should be kept to a minimum, if it grows too large that's a sign you've split things artificially instead of finding natural splits.
I agree, and there are other fun gotchas that even more frustrating and convoluted. But everything is thoroughly documented and I even explicitly pointed out those potential issues before I gave them the assignment. When the errors first occurred, I pointed out the fix, which was ignored, multiple times. Should it be that difficult to rename a couple folders? The compiler errors were fairly easy to understand: can't find repo2. Is that too much to expect from someone?
In an ideal world and in retrospect, you are right. But the build process is very old, created by someone long gone, of which multiple projects depend upon, each with minor tweaks and always reliant on the same hard-coded paths which IMO isn't that bad and can easily be rectified - it's really not worth the time or energy to allow dynamically named folders, not to mention dangerous since it's a critical production system that's worked forever. Nobody wants to break a running system, nor has the time to clean things up properly, especially since there are tons of build scripts that all rely on these paths, and trying to fix all of them would be a huge amount of work, spread across multiple projects, all requiring sign-off from higher-ups who will never be able to justify the cost to fix something that already works.
I hear you, but I still feel for the coworker, and if I newly joined a company and learned on my first day that they are failing the Joel Test[1] here in 2026, I would get that sinking feeling in my stomach that I made a huge mistake. There is no longer a valid excuse for having a build like that. "It's documented..." and "Nobody wants to touch..." "Not worth it to..." "Can't justify..." are all huge red flags.
Nice list, somehow I missed that one. I love Joel's wisdom.
The full build literally works in one step but the main prerequisite is to perform a few git clone commands which can be copy/pasted from the readme. Can't help it if they want to manually do git clone and let it name folders incorrectly and then subsequently ignore compiler errors and my advice to rename. Changing our antiquated workflow would have required changing a lot of other sensitive dependencies. What ever happened to the old adage "never change a running system" ? ;)
And people here are concentrating on our build system, which I will be the first to admit isn't perfect, but this isn't the only instance of me telling this person how to do things, them not listening to me and doing something else, letting me debug only to realize they didn't listen, telling them how to fix, only to be ignored _again_, rinse and repeat. It's unfortunately a recurring theme. I initially thought it was a communication error on my part, but I've heard similar complaints from several other colleagues as well.
See, you are probably right about that new hire. But the way you say things here, you do come across (at least to me) as "that guy". You know? "That guy" that says "we've always done it this way and that is why it's good and why we still do it that way".
What happened to "never change a running system" is that if the system is barely running at all, you better do change that system.
If I'm the new guy and you tell me how to do things and those things seem bad and there's no explanation for why they need to be that way, I'll also ignore you, coz I know how I want to do things and how things can be done better. Don't tell me to do things X way. Many roads lead to Rome and some are better than others. See my other reply. At my very first job I was also told how things work and how to do things. But things sucked and so I made them better anyhow.
Now, in the other part of the thread you also did mention how they just sent you error logs without reading and thinking about them themselves and such. That definitely is a red flag and the kind of thing that will make me fail someone's probation period. Definitely. But just because someone doesn't think that "the way we've always done things" is a good reason to keep doing something bonkers is where I'm no longer with you. And again, probably just your wording/what you disclose in various parts of these threads but it explains why "we concentrate on certain things only" ;)
> "That guy" that says "we've always done it this way
I most definitely am not, and constantly push back for changing processes, and do make changes when I am allowed, even when it's not budgeted for or even officially allowed, because we have legacy systems that need to be maintained and some things are truly outdated and need some love. In fact, as a new hire in another life, I used to get scolded for changing _too much_ because I like to constantly improve things. The problem is, in order to ship code at our company and within our budget constraints, you don't have time to constantly refactor, unfortunately.
> is that if the system is barely running at all
Our system is and has been running just fine for many years, thank you very much :)
> there's no explanation for why they need to be that way
There is an explanation: There is no shell script because there is no root for all the repos, and some repos are shared across multiple projects.
I hate reiterating this yet again but is it really that hard to copy/paste a couple git commands? The readme is quite short, and once you've done it one time, it's fairly easy and straightforward to understand.
With you on this one - I worked with a hopeless tester years ago - gave him a detailed test plan with a nice sequence of steps to follow to set up the scenario. I have no idea why but he decided to do the steps out of order, then wondered why my patch didn't do what it was meant to.
at the very least there's no excuse for not having a shell script to check everything out in the right places! I've been the new person in teams with this sort of fragile setup and it's no fun whatsoever.
See, I would probably have been the guy that ignores the dest part. On purpose. Just to see whether this pile of poo shits itself and how much.
I would also recognize what happened when I see the error messages though and then silent quit until I've been with you guys for long enough my resume doesn't take a hit just because your interview process duped me into starting at your place.
Yes this sounds harsh. I know. Nothing against you personally. But I've been at too many such places. One can do things better.
haha I would totally empathize with you. But see, you would realize immediately that it doesn't work and why, but you are smart enough to realize it and would just rename the folder (as mentioned in the readme as the very first thing to do), hit build and voila, everything works as expected, instead of sending me log files, letting me debug your errors, ignoring my repeated instructions, waste my time helping you debug, back and forth until finally you just rename and move on. I had to say it 4x before it finally stuck. This guy seemingly wanted to get an initial build done so he could move on to actually fixing bugs. Maybe it's intentional to waste everyone's time so that he can book hours in the system and get paid for futzing around? :shrug:
and btw the system doesn't shit itself that much: the compiler errors are fairly straight-forward: this folder doesn't exist.
Of course everyone can always do better, but it's a legacy inherited system, and works fine, as long as things are named correctly. The readme is actually very short - literally the git commands are there to copy/paste and will create the correct directory names. There are plenty of other things to get hung up on, but naming folders correctly should IMO not be one of them.
Hehehe, definitely been there and dealt with that guy that I definitely didn't let pass his probation period. I see we do understand each other.
And I might not silent quit right away and try to actually improve things and see how it goes/how you "let me".
This does actually remind me of my very first job actually. It's been many, many, many years now. I found a stinking pile of disparate shell and perl scripts that made up the "backend" of the application I was hired into working on. Grown histerically for almost 15 years prior to me being hired fresh out of university. I started extracting common library code out of every single one of these every time that I was tasked with adjusting one of those scripts. I introduced a proper deployment from source control to production the second time I "broke" something, because someone had previously fixed a bug directly in production and forgot to check the fix into source control (and no, I didn't believe that it was not the guy that was working on the project w/ me for one second after seeing how they coded and how they defended everything that was bad about that pile of poo and how "it's too complicated to do X".
Well guess what, this new grad did all of that anyway. Without AI and without IDE refactoring support (I mentioned Perl and shell scripts, did I?) and without a single QA person in sight. And yes, every single one of the readers here very probably has bought a product that was "touched" by that software, without knowing, since it was an in-house administration tool.
I agree but it's probably more common than you think. I had a job where the setup involved running one setup command twice because the first time always failed. But that was called out in the documentation so it was fine. The reason it wasn't fixed is because the project was well on the way to being end of lifed so it wasn't worth it at all to fix the crappy set-up process.
> If you have depedent projects, they should either be in a monorepo, or delivered through a packaging system so they are not depend on the specific local naming of other repos.
Our git master actually considered this, but it would have caused other issues that I can't recall right now, so we got stuck with lots of repos. The readme literally has all the git commands, all they had to do was copy/paste them into the terminal.
I once accidentally gave my claude "powershell" permissions in one session, and after that any time it found it was blocked from using a tool, e.g. git, it would write a powershell script that did the same thing and execute the script to work around the blocked permission.
Obviously no sane system would have "powershell" in a generic allow-list, but you could imagine some discrepancy in allowed levels between tools which can be worked around with the techniques on this page.
reply