lbriner (u/lbriner) - Readit News

lbriner commented on Welcome to hell; please drive carefully 2earth.github.io/website/... · Posted by u/2earth

lbriner · 4 months ago

In my experience, the Puffin crossings are setup correctly precisely 0% of the time.

If you are going to pay presumably a lot more money for all of the extra detectors and electronics then they need to deliver 2 things as mentioned by OP: 1) They make sure that anyone on the crossing has time to cross rather than stopping traffic for a fixed amount of time (useful outside schools) and 2) If there aren't any people crossing, the traffic should be stopped for a short amount of time no worse than if they were just a normal Pelican crossing.

However.

Even when no-one is crossing or in some case someone crossed and is about 50 metres up the road, the crossings are still usually on red for a total of often 20 seconds, which is way longer than most Pelican crossings that are on red for usually 5 to 10 seconds max.

I don't know if no-one notices or cares but it is really annoying!

lbriner commented on Marissa Mayer will close her old AI startup, sell assets to her new AI startup techcrunch.com/2025/09/29... · Posted by u/bookofjoe

lbriner · 5 months ago

A lot of misunderstanding here about "why would you invest in someone who has failed?"

An investor is a gambler. Not just on past success, although I'm sure Marissa has had some successes even if people don't know them.

They gamble on: 1) Has this person got the experience (good or bad) to run a business. A failed business leader is a better gamble than someone with no experience. 2) Does this person have a strong network so they can realistically pull in some really good people? 3) Has this person raised capital before? 4) Do they have a convincing narrative about why they have failed and what they might do differently? 5) Is the potential ROI high? 6) Do I have anything else I could invest in instead with better odds?

If I think as an Investor and not as an Engineer, I am not surprised that she has succeeded and I wish her all the best.

lbriner commented on What is “good taste” in software engineering? seangoedecke.com/taste/... · Posted by u/olayiwoladekoya

lbriner · 5 months ago

I find a lot of these articles conflate two issues, which I have seen mentioned in some of the other comments.

1) There are objectively bad decisions that you can make regardless of "taste" or principles. If you search a list in O(n) for an items key, it is objectively worse than using a dictionary with O(1) search in most cases. It is not about taste or readability, there is a right way and a wrong way (or multiple right ways and multiple wrong ones).

2) Everything else is a matter of trade-offs. Map reduce or a loop? It depends entirely on performance requirements, what reads better in a specific scenario, maybe browser compatability or whatever but as long as the trade-offs are considered, I won't get bitchy to another Dev who decides that one is better than the other although I might disagree.

If something is wrong or the trade-offs haven't been considered though, that is a question of maintenance: do we care enough, is the performance bad enough, is the code visited enough to change it? In a lot of cases, the app will be deleted before it becomes a problem but it is still a question of trade-offs.

As someone said below, as long as someone has considered the "why" then its all fair game. I'm not sure that any of this is "taste" though.

lbriner commented on I know when you're vibe coding alexkondov.com/i-know-whe... · Posted by u/thunderbong

godelski · 7 months ago

I think you're missing the author's thesis

  > Is speed the greatest virtue?

If speed is the greatest virtue then yeah, all that stuff will happen. But if it isn't, then that stuff will happen at a much lower frequency. Because, all the stuff mentioned is just tech debt. Debt doesn't go away, it accrues interest.

If speed is all that matters then you need exponential output, as your output needs to offset the debt. If speed is a factor but isn't the only factor, then you need to weigh it against the other things. Take on debt wisely and pay it off when you can. But it does seem like there's a trend to just take on as much debt and hope for the best. Last I checked, most people aren't really good at handling debt.

lbriner · 7 months ago

I think you are misusing the phrase "tech debt" like many people do.

Not everything that is not perfect is Tech Debt, some of it is just pragmatism. If you end up with two methods doing the same thing, who cares? As long as they are both correct, they cost nothing, might never need any maintenance attention and will never be paid down before the codebase is replaced in 10 years time.

Same with people writing code in a different style to others. If it is unreadable, that isn't tech debt either, it's just a lack of process or lack of someone following the process. Shouldn't be merged = no tech debt.

Adding some code to check edge cases that are already handled elsewhere. Again, who cares? If the code make it unreadable, delete it if you know it isn't needed, it only took 10 seconds to generate. If it stays in place and is understandable, it's not tech debt. Again, not going to pay it down, it doesn't cost anything and worse case is you change one validation and not the other and a test fails, shouldn't take long to find the problem.

Tech debt is specifically borrowing against the right way to do something in order to speed up delivery but knowing that either the code will need updating later to cope with future requirements or that it is definitely not done in a reliable/performant/safe way and almost certainly will need visiting again.

lbriner commented on A short post on short trains shakeddown.substack.com/p... · Posted by u/surprisetalk

lbriner · 7 months ago

I feel like this is one of those articles that claims some clever idea on paper but without experience of how this would actually work IRL but IDK if the OP has more experience than me so I will assume the best.

Others have already pointed out some of the practical things that would limit what you can achieve with shorter trains like minimum headway between trains and the congestion that would occur after a delay where you would expect people to wait for maybe 10 short trains to arrive and depart before you could get on.

There are other problems. The cost of the smaller trains means if e.g. 2 carriages each, then every other car is a driving vehicle with motors and control equipment. On longer trains, this could be 1 in 3 or 1 in 4. Each of these not only requires regular maintenance (so that's doubled the maintenance requirements) but also creates massive congestion issues in maintenance yards. Commonly, 1 or 2 full trains fit in each siding so getting most trains out if e.g. one is broken down is usually easy enough. Imagine having to move 3 or 4 separate smaller trains out of the way, they are not automated in the yards.

Most people would be very unhappy knowing that they might be alone on a train, which is a main reason why operators are not quick to get rid of all staff. But currently, a single driver and conductor is close by for, maybe, 8 carriages. This would double if you needed a single attendent on each 2 carriage train.

The signalling is very heavily designed around traditional trains with its delay after passing a signal. 4 x 2 carriage trains would utilise more signalling capacity/time than 1 x 8 carriage train. If these were all coming from the same location and needed to return, that would also need a lot more platforms so that the following trains don't block the first trains in terminal platforms. This is already a major problem at most UK terminal stations so that is largely unsurmoutable.

I also heavily question the idea that station cost is largely dependent on platform length. On most surface stations, platforms are relatively easy to construct and whether they are 4 carriages or 12 carriages long still require a station building or 2, some ticket machines and CCTV etc. For elevated railways that is more likely to be true maybe.

So yeah, like someone else said, we are unlikely to come up with ideas that 1000 other engineers haven't already asked, the easier problems to solve are around planning, design, legal rights for infrastructure projects etc. since these tend to eat up sometimes decades and billions of dollars.

lbriner commented on Ross Ulbricht granted a full pardon twitter.com/Free_Ross/sta... · Posted by u/Ozarkian

lbriner · a year ago

Someone might have already pointed it out but for me, the sentence of RA is not the main issue, the issue is allowing a single person to stamp through an entire legal system and undermine all of the time and money that is invested in it, even if that person is a president.

I suspect that the idea originally was to give some safety valve but if it is used more than a few times by a President, it makes a mockery of it and it should be removed as a power. How can a President ever decide that the entire legal process is flawed and their opinion is right? If the sentence was too long then change the sentencing guidelines.

lbriner commented on Kenya's EV bus adoption stalled by supply shortages, import tariffs restofworld.org/2024/keny... · Posted by u/surprisetalk

lbriner · a year ago

It would be interesting to know why the Kenyan Government proactively levied a tax on EV imports. Usually this would be to protect local production but if the local production cannot supply, it is self-defeating.

I guess the real problem is that Governments are not agile enough to change this things as needed e.g. lets remove tariffs for 6 months and then revisit. If the locals can produce what we need, great, if not, we allow imports again.

lbriner commented on · Posted by u/elsewhen

lbriner · a year ago

If only BeyondTrust was called LeastTrust, it might not have used a global key to gain access to a load of very high-value targets.

To be fair though, most of what we use in these companies is a stack of containers of stuff that we just assume works properly, securely etc. and we don't really know if we use e.g. Citrix or VMWare or BeyondTrust or whatever, whether the software works as designed and whether it was only as secure as the people who wrote the code.

lbriner commented on Faster CI with Selective Testing mill-build.org/blog/3-sel... · Posted by u/lihaoyi

lbriner · a year ago

Like others, I think this is a solution describing an idealised problem but it very quickly breaks down.

Firstly, if we could accurately know the dependencies that potentially affected a top-level test, we are not like to have a problem in the first place. Our code base is not particularly complex and is probably around 15 libraries and a web app + api in a single solution. A change to something in a library potentially affects about 50 places (but might not affect any of these) and most of the time there is no direct/easy visibility of what calls what to call what to call what. There is also no correlation between folders and top-level tests. Most code is shared, how would that work?

Secondly, we use some front-end code (like many on HN), where a simple change could break every single other front-end page. Might be bad architecture but that is what it is and so any front-end change would need to run every UI change. The breaks might be subtle like a specific button now disappears behind a sidebar. Not noticeable on the other pages but will definitely break a test.

Thirdly, you have to run all of your tests before deploying to production anyway so the fact you might get some fast feedback early on is nice but most likely you won't notice the bad stuff until the 45 minutes test suite has run at which point, you have blocked production and will have to prove that you have fixed it before waiting another 45 minutes.

Fourthly, a big problem for us (maybe 50% of the failures) are flaky tests (maybe caused by flaky code, timing issues, database state issue or just hardware problems) and running selective tests doesn't deal with this.

And lastly, we already run tests somewhat selectively - we run unit tests on branch uilds before building main, we have a number of test projects in parallel but still with less than perfect Developers, less than perfect Architecture, less than perfect CI tools and environments, I think we are just left to try and incrementally improve things by identifying parallelisation opportunities, not over-testing functionality that is not on the main paths etc.

lbriner commented on Database mocks are not worth it shayon.dev/post/2024/365/... · Posted by u/shayonj

senex · a year ago

Does anyone have experience making tests against real databases fast?

I resonate with the sentiment of this article, but have struggled to find an alternative that’s fast enough as the test suite grows, isn’t flakey in CI, and is able to share the production schema definition for relevant relations.

I’d love to hear more from anyone that’s solved for some of these constraints!

lbriner · a year ago

A real database should not be slow. Even with our tests running against a hosted SQL Server on a separate server, the database is never the slow part. For other tests, we run with the same database in a local Docker container with Docker Compose and it is fast and isolated/resettable.

Most tests should be unit tests, which are super fast. Integration and UI tests that might use the database should be fewer and if the database is slow, it might be related to your specific application or unoptimized database queries, our database calls are usually < 10ms