In the US, for some reason, if you are a danger to the President's friends, you can be fired/your department can just be shutdown executively and this isn't just about Trump, it is about a serious weakness in the systems of governance.

* Support really poor, raised a ticket last week and have heard nothing back at all * Separation of claude.ai accounts and console accounts is super confusing * Couldn't log into the platform since I had an old org in the process of deletion even though I was invited to a new one (had to wait 7 days!) * Payments for more API credits were broken for about a week * Claude chat has really gone to s*t unless it always was. Just getting back terrible answers to simple questions. * The desktop app is a web app pretending to be a desktop app that doesn't always know it is a desktop app so you get things like, "this will only work in the desktop app". Yes I know, this is the desktop app! "Oh sorry about that but you need to use the desktop app". * mcp integration and debugging is dreadful, just a combination of generic "an error ocurred" and sometimes nothing at all * MCP only supports OAuth for shared connectors but auth key doesn't work even with "local" servers that are not necessarily local, just the config is local.

You can put those on the health status!

I think new founders are sometimes intimidated by customers, especially well-known brands, we don't want to upset or annoy them instead of being open about not being able to afford to run loads of pre-sales technical work. We also see the dollar signs for one large customer when we should be seeing smaller dollar signs for many customers.

For the customers, to be fair, they are partly trying to derisk the purchasing decision by making sure everyone and their dog has seen the demo, shown that it definitely does exactly what they want with their data and processes etc. and they have no skin in the game at this point, so why not?

Believe in the product you have built already and as the OP says, be certain of product market fit and ABC (always be closing).

They even have the cheek to link to a 15 year old guide on email best-practices, it is in equal parts awkward, annoying and incredibly shameful for a large organisation like MS. The fact that SNDS shows all greens seems to mean nothing and clearly they have been instructed not to engage in any conversation about why it is happening and the fact these are servers that are linked to a well-known business with static IPs that have been in use for over 3 years.

The best I can work out is the use of heuristic mail filters that detect anomolies for whatever reason they feel like. Too much email, not enough email, email sending rates that are too erratic, basically what 99.9% of email servers in the world are doing and they decide to block you. I could live with "rate limited" and I could live with "temporary" because I would disable the servers once they got blocked but nope. Just more "we don't give a shit" attitude from Microsoft.

Sadly, I had to accept the inevitable which I had avoided for many years and migrate all of our email sending to Amazon SES because life is too short to send emails to Microsoft.

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!

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.

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.

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.

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.

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.

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.

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.

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.

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

It's weird that with the sort of numbers that could lift some countries out of poverty, we can't even write something down in a spreadsheet.

The one basic tool that does seem lacking, however, is just basic network segmentation. I could understand a single system being hacked, especially an old system that is massively complex to replace but having to shutdown multiple systems including WiFi and office networks just smells like lazy "just connect all the wires together to make my IT life slightly easier". Having air gaps with separate computers, separate networks (even vlans) etc. is probably the most cost effective way to reduce your attack surface.

It's like buying the new 5G cell phone because it is X times faster than 4G even though 1) My 4G phone never actually ran at the full 4G speed and 2) The problem with any connection is almost never due to the line speed of my internet connection but a misbehaving DNS server/target website/connection Mux at my broadband provider. "But it's 5G"

Same thing cracks me up when people advertise "fibre broadband" for internet by showing people watching the TV like the wind is blowing in their hair, because that's how it works (not!). I used to stream on my 8Mb connection so 300Mb might be good for some things but I doubt I would notice much difference.

In a startup, there is some natural way to choose the 1 right person for the job, say, the Developer. They probably wouldn't be chosen unless they have a high level of ability, communication skills (hopefully) and a lot of productivity and proactivity. This could be directly related to the potential rewards of equity etc. but maybe not, maybe they are happy to be free to work at high and low level and to make educated decisions on everything. I did this job for the same money as my older job without much expectation of a large payout (never got one!)

But as soon as you hire 1 other person, things immediately change. It isn't just about their ability, although we often talk about that both in terms of testing it during interview but also measuring it using some KPI but a person is much more than ability. You can have ability and be lazy or lack ability but are a quick learner. You might be really easy to get on with but your stuff is slightly above average, or a complete a-hole but produce rock-solid code. You might be reliable, you might not, you might be motivated all the time, some of the time or none of the time. As much as we like to think we can have regular performance reviews, you can't put numbers on those things but you can put process. I can arrange a daily standup and weekly progress reviews to get slightly better at making sure you are on-track. I can try and count things like tasks completed or LoC or Stories completed or bugs in production etc. but these are also a rich tapestry and after-all, do you compare them to the 10x coder that you are?

Some people need to be told to do something properly, they need process, others will do it properly without being asked, they have passion. How can you tell? Mostly gut feel, and maybe a checklist! I think there is also a myth that if we only had tonnes of cash, we could be much more picky with hires and only get the best, that would remove a lot of bureaucracy but look at FANNG companies, they have this problem in buckets. People can fake their ability and passion to a point, they have 1000s of applications to process and they still have tonnes of meetings. Even if you hire someone with the same passion and ability as you, they will be still be different. They will be insistent on VueJS instead of C#, TDD instead of DDD, Unit Tests for everything or UI tests for some things. Each of those is OK but you still then create that Architect position to ensure consistency between teams, the Project Leader to ensure delivery times are balanced with technical perfection.

Personally, I have never believed that a company with more than, say 200 employees can ever be efficient. They can be rich but eventually they will buckle under their own red-tape or at the next culling that takes place under the "new trendy CEO who had successes at previous companies".