Seems like a lot of fluff. I think the key is to deliver value to customers. Do something you know. Don't be arrogant and enter a random business you know nothing about.
Trying to get a startup off the ground is basically 2 things: pushing code and talking to customers. Set a metric like how much users are using the app (proxy for usefulness). If you create something that's valuable, it'll probably work out.
There are a few exceptions which they touch on a bit. Movie pass model where you sell $10 for $5 obviously doesn't work. Or if you take investors and scale up too fast also screws you. You could be perfectly profitable and have fit but if some VC throws money at you and convinces you to hire dozens of people, then it could sink your product despite fit. An investor doesn't necessarily have your best interests in mind. They may prefer a 10% chance of $100m co where as you prefer a 50% chance of a $20m company in that time frame.
> Do something you know. Don't be arrogant and enter a random business you know nothing about.
Within reason. I think there is a path to success in partnering with customers in the market you want to serve. Following Seth Godin's advice- "Don't find customers for your products, find products for your customers." As devs we have the capacity to join ranks with our customers and learn and build to solve their problems.
Redis drops data semi randomly when under memory pressure.
If you use Redis for queue tasks (this is popular in Rails and Django/Python web services), that means that during an incident where your queue jobs are getting added faster than they’re removed, you’re going to lose jobs if the incident goes on long enough.
That depends on how the `maxmemory-policy` is configured, and queue systems based on Redis will tell you not to allow eviction. https://github.com/sidekiq/sidekiq/wiki/Using-Redis#memory (it even logs a warnings if it detects your Redis is misconfigured IIRC).
Well, of course! Redis is not (and has never been) a database, it's a data structure server, at best described as a cache. If jobs are added faster than they're removed, this is straight queueing theory 101 -- ideally you'd reject jobs at add-time, but otherwise you have to drop them.
Right. I think Redis hitting the disk would be a terrible tradeoff compared to making a new backend call. it probably wouldn't save you much time and I imagine it would lead to very strange and unpredictable behavior on the front end or trying to debug latency or data issues downstream
Since Redis is an in-memory cache, and already doesn't guarantee the data, would it make sense to set PRAGMA SYNCHRONOUS on nalgeon to OFF to boost performance to something closer to standard Redis?
The use case is caching 20 million API responses that almost never change, each about 20kb of JSON, for a high traffic site.
Yes, I can pay for a 400Gb RAM instance of Redis, but it's expensive.
I can also cache it on disk, but then I need to think about cache expiration myself.
Or I can use something appropriate like a document database, but then I need additional code & additional configuration because we otherwise don't need that piece of infrastructure in our stack.
It would be a lot easier if I could just store it in Redis with the other (more reasonably sized) things that I need to cache.
In other abuses of SQLite, I wrote a tool [0] that exposes blobs in SQLite via an Amazon S3 API. It doesn't do expiry (but that would be easy enough to add if S3 does it).
We were using it to manage a millions of images for machine learning as many tools support S3 and the ability to add custom metadata to objects is useful (harder with files). It is one SQLite database per bucket but at the bucket level it is transactional.
Redis Data Tiering - Redis Enterprise and AWS Elasticache for Redis support data tiering (using SSD for 80% of the dataset and moving things in and out). On AWS, a cache.r6gd.4xlarge with 100GB of memory can handle 500GB of data.
Local Files
> I can also cache it on disk, but then I need to think about cache expiration myself.
Is the challenge that you need it shared among many machines? On a single machine you can put 20 million files in a directory hierarchy and let the fs cache keep things hot in memory as needed. Or use SQLite which will only load the pages needed for each query and also rely on the fs cache.
S3 - An interesting solution is one of the SQLite S3 VFS's. Those will query S3 fairly efficiently for specific data in a large dataset.
You could try using Amazon S3 Express, a low-latency alternative for S3 buckets [0]. I imagine cache invalidation would be relatively simple to implement using lifecycle policies.
Or shard it - divide your objects up based on some criteria (hash the name of the object, use the first N digits of the hash to assign to a shard), and distribute them across multiple redis instances. Yes, you then need to maintain some client code to pick the right redis instance to fetch from, but you can now pick the most $/memory efficient instance types to run redis, and you don't have to worry about introducing disk read latency and the edge cases that brings with it.
Edit: looks like redis has some built-in support for data sharding when used as a cluster (https://redis.io/docs/latest/commands/cluster-shards/) - I haven't used that, so not sure how easy it is to apply, and exactly what you'd have to change.
You're trying to get redis to be what it isn't. Use a thing that has the properties you want: a document or relational database. If you insist on this then running a system that allows a ton of swap onto a reasonably fast disk might work, but is still gonna perform worse than a system that's designed for concurrently serving queries of wildly differing latencies.
Have you looked at varnish for caching api responses? Varnish let's you back it with disk and relies on page cache to keep more accessed items in memory.
If the reverse proxy thing doesn't work I think memcached has two level storage like that now iirc
Having WFH for the past 3 years, Im not sure I would start my own WFH company. Maybe Im in a company that doesnt have the culture to support it very well, but the amount of inefficiency I see on the engineering level would make me prefer a hybrid solution for my own company.
At work there tend to be other inefficiencies. A lot of "spontaneous collaboration" that people claim happens in the office is people talking to pretty/handsome people in other departments, without necessarily adding to the bottom line.
In person collaboration is definitely worth it, but this needs to be planned. It doesn't happen automagically if you are being forced to sit at a desk.
I can see why middle management's hates it thought. You can no longer tap on someone shoulder and pester them in prioritising your work above others. You need to make a business case rather than bullying a poor Engineer.
WFH just amplifies management incompetence, it’s not a problem per se. If it doesn’t work, it’s better to look deeper to understand the root cause of inefficiency.
WHF amplifies all incompetence, especially around comms. Managers are particularly bad at that but in my experience everyone is at least a little bad at it...
It's not just comms, many live in a digitalized world FORMALLY, they formally works on desktop computers, but their mind work on paper and they seems to be unable to works on computer other then mimicking their works on paper.
Aside managers like people in the office because they are more tied to the company, change employer often means having to move elsewhere and the worker might be in couple and his/her partner might have issues moving, they might have kids suffering from loosing friends and change schools etc, this means workers more keen to accept bad condition at work at a certain point in time. A remote worker can potentially change employer just changing some login screens.
The comms thing is a bit of a bug bear for me too. I like to respond quickly to messages/emails because I believe the person at the other end appreciates having their questions answered quickly so they can get one with their day. When I have to wait an hour (or whatever timeframe feels disproportionate) for a reply to my message it grates. Still, I can live with it if I don't have work in a noisy shared space.
About the remote work comms there is a widespread attitude that irks me: People texting "can we talk?" or simply "hello".
No! tell me straight away what you need so I can judge how and when to respond.
When people state what they need, most of the time the response is immediate and it's the thing they need or some ok followup.
"can-we-talkers" I'm starting to let stew for a few minutes, because I suspect they do that on purpose to "skip my queue".
I agree. Having worked on the shop floor I don't like my time being wasted and I'm careful to add detail for my colleagues so that they are engaged from the outset with my query. All I ask is 'give me half an hour' or some similar response so I can manage other people's expectations.
This is why so many orgs find remote working hard. Everyone has to be willing to compromise on how they communicate to find a middle ground, or the company has to hire for people who work the same way as everyone else. When you have a team made up of people who communicate with different expectations, and they're not willing to accept that other people will think differently about what's reasonable, remote working starts to break down.
Maybe that's why so many companies push for people to return to the office. In-person working where someone can just walk up and interrupt someone else is equally awful for everyone.
I'm all about the compromise. I don't mind waiting for an answer but I'm often hassled for a response in my role and then I need an update from another member of the team. If that response is not forthcoming guess who gets the follow up? Now I'm badgering people who are probably busy but have neglected to tell me and I'm now the block in the pipe to those above me. I don't mind a pat response that they're busy but someone somewhere always needs a status update.
Urgent ad-hoc status update requested by someone above is in most cases a communication anti-pattern. Why would someone need it outside of regular reporting structure (DSM, weeklies etc)? Even in case of disaster recovery, when updates need to be more frequent than daily, it’s better to agree in advance on how communication proceeds and plan the work correspondingly.
When WFH(A) is a real alternative, office work means hiring a mediocre team to achieve mediocre results. It is not better value for money, because poor management is not just about inability to organize remote work. Toxic environment will result in higher churn and missed opportunity costs, poorly designed processes will inevitably decrease quality and increase time to market etc.
I own equity in a fully remote company worth billions of dollars and highly profitable, and I would buy more if I could. There is (edit: at least) roughly $120B in enterprise value in fully remote and remote first orgs.
Feelings and anecdotes aside, the data shows the model to be effective imho.
> There is (edit: at least) roughly $120B in enterprise value in fully remote and remote first orgs.
There aren't any North American private companies that have an enterprise value of over $120B right now so the company is public, why not just name it?
Figure presented is an aggregate if that was not clear, not a single enterprise. Open to suggestions how I could’ve improved that sentence in that regard.
I am lazy and time poor, not a liar. No need to troll if you [1], for whatever reason, take issue with the concept of remote work. You’re free to the opinion. I believe in the model based on a preponderance of the data (enterprise financial success and metrics, worker quality of life, environmental impact, etc). Probably a bit of “talking my book” [2] too if you will.
I’ll make time to have the Google Sheet cleaned up and shared here as a post.
How much more would you be willing to spend to get these employees to work in your office? Or put another way, at a fixed salary budget, how much smaller a talent pool would you accept to recruit from?
Recruiting only from the pool of "people who accept to work 100% in an office" is a massive handicap, at least in some regions and positions.
+1. I tell any recruiter not offering WFH to pound sand. It’s not the 1920s. I don’t need to commute to sit in front of a pc. I can do that just fine at home.
I've worked for two types of WFH company - the kind where everybody is kind of just left to their own devices and the highly collaborative kind.
I think a lot of people really like the former but I don't think it works very well. There's a marked tendency of many people to drift apart and communication breaks down within and across teams and the fallout it quite ugly - a lot of people individually doing their jobs (and perhaps doing them well), but nothing really fits together very well. I personally found working in this environment to be torture because my work felt performative and meaningless.
I find that the highly collaborative kind works about as well as working in person - possibly better. However, I think it's only really possible with a lot of camera-on video calls which many people find quite draining.
Things “fitting together” is generally on management though. Can’t speak for other industries but if you leave this up to engineers then they settle down into something like design by contract, or you write my tests I’ll write yours, etc. management often actively resists that with or without wfh because they don’t get to run fiefdoms on the strengths of their network and charisma, look important by forcing meetings, etc.
So effectively you have middle management failing to be fulfilled at an emotional level as well as failing at a professional level to do management, and their plan to deal with this is to first blame others, then try to convince leadership to kill wfh for line workers before anyone notices the real problem.
Nothing against any individuals out there, just seen these things play out a lot and have been having the wfh discussions since long before Covid.
Technical alignment is easy in a sense because it’s clear when two ends of a bridge don’t meet in the middle. Product people or department heads have a harder time of things, but if I were a ceo, I don’t want to buy office space for 2500 when 25 will do.
It’s kind of evil to advocate for back-to-office if you know it’s good for you, but bad for both the company and your coworkers, and I expect many of the most vocal advocates know these things in their secret hearts
> I find that the highly collaborative kind works about as well as working in person - possibly better. However, I think it's only really possible with a lot of camera-on video calls which many people find quite draining.
I think it's something else. It's providing space for employees to interact spontaneously. In software there's a huge push to have everything public and recorded, which makes me very cautious about how I present myself. When I switch to private messages, I get much higher sense of connection with the other person, because I don't need to stay that formal.
It's all down to the approach. I work for a company which has been remote right from the start (10 years ago) and if it's done right then it's great. A lot of it comes down to treating your employees as adults and trusting that they are doing their jobs. A good company culture is key to making it work.
That kind of thing is called an "unlimited company", which exists, but is rare and puts off investments (but apparently makes borrowing easier?): https://en.wikipedia.org/wiki/Unlimited_company
Random "unsophisticated investors" (e.g. me) are supposed to get some degree of protection from catastrophic mistakes we can't be expected to recognise heading our way, in order to encourage us to participate in the stock market without having to worry we might inadvertently be taking on some fractional responsibility for a debt exceeding our net worth.
Likewise, governments don't like it when pension funds are bankrupted because of what they invested in.
Limited liability and other contraptions are just tools capital and feudalists use to avoid liability. In fact these should be reveresed. In fact most of these should be tried as RICO cases
Feudalists avoid liability by conscripting peasants and ordering them to fight their creditors' peasants, or handing out literal piracy (privateer) licenses, or steal money from monasteries after denouncing the Pope or accusing the specific holy order in question of practicing witchcraft.
RICO came after 159 years of US experience with all the benefits of limited liability and in the midst of the Cold War where the US was fighting for the freedom to keep government out of the way of business, so selecting that as your magic legal phrase is about as sensible as trying to fight Covid lockdown restrictions by putting a printout of Magna Carta in a shop window.
The people benefiting from any behavior ranging from deceptive to criminal should be at least partially held liable (at minimum to not receive any profit whatsoever from those misdeeds).
Will this change investor behavior and industry culture? Yes, and that is not only a net good but absolutely necessary.
If you want capitalism as a financial system then holding the capitalists liable for wrongdoing that benefits them is the only way you avoid turning the planet into a hellscape.
You need to be very careful with how you phrase that and what exactly you mean — as (for example) 3M and Boeing pay taxes and make stuff broadly useful across society, the set of people benefiting from misbehaviour which these companies are deemed responsible for is… basically everyone.
Even in a more narrow case with no complications (even narrower than SBF, because he distributed money to good causes who can't pay it back), you're including the defence lawyers.
I'm (caveat: not a lawyer) more in favour of specifically criminal behaviour being handled by "piercing the corporate veil", putting the penalty directly on the humans who actually did the crime without letting them hide behind corporate personhood: https://en.wikipedia.org/wiki/Piercing_the_corporate_veil
But of course, it can be hard to prove who knew what, so sometimes "follow the money" is easier. And yes, I also agree with you that there are misaligned incentives in capitalism that lead to bad outcomes and we should work to improve that — just don't throw out the baby with the bathwater.
To clarify, I am only talking about direct financial benefit (capitalist ownership). But it has to be backdated to the owners at the time range when wrongdoing occurred. That way you can go after people who sold (for profit) their stock before the wrongdoing was discovered.
Financially punish the capitalists who benefit from crimes and the executives that are currently getting away with crimes won't continue to get away with anything. (Laws and regulations will change rapidly when money is on the line)
Punishing only the people responsible for the crimes is a losing strategy. You have to eliminate the demand for that behavior. Because there an endless supply of morally corruptible people to take the fall so that capitalists can gain.
Source on this? Been living in Spain for 8 years now, and my wifes family have a number of empty of apartments here. AFAIK, they do not pay tax on any of them for being empty.
IMO that is one of things they can do to address the housing issue we have but I have seen no mention of this policy anywhere.
My wife grandfather bought them as an investment and after he died, the grandmother inherited them. She couldn’t care less about them as investments, but I guess my in laws are waiting to inherit them and then sell them off.
What is the benefit to buying a car from a company very few people have heard of? I don't know the price point of this vehicle (imagine not cheap), but regardless, personally I would never buy a car from a company without a reputation built up before for sales, reliability, and post-sales service.
Well, the company is about to go under so the cars are now at fire sale prices.
My guess is that Fisker and others thought that the market would be much larger, Tesla wouldn't be able to ramp up their production that quickly, and battery prices would have dropped faster. Fisker gets a little bit of a pass since it's from a CEO who tried to sell EVs back in 2009, and may be living in that same mindset.
I didn't realize they had dropped the price by almost half, most of them are going for well under $40K now.
On the one hand, Fisker had already tried it once and failed, why did they think they could succeed the second time? On the other hand, there are lots of success stories out there that make it seem like the time is ripe (Tesla of course, Rivian, Lucid, Bddy, Li, I'm still optimistic about Canoo...)
Well, I have some Li stock and it's been up this past year, so that's a good indicator. I'm not sure about Rivian, it's stock has been pretty flat the last year. Lucid by a similar measure is definitely bleeding. Hasn't been a good year for Tesla either, but I wonder how much of that is Musk being silly.
Canoo has been interesting, over the last 2 years up to a few months ago it had dropped 98% in stock price. Over the last two months it's grown quite steadily. It has what looks like a great vehicle, a good story for it, strong interest and orders (including fleet interest from Wal Mart and USPS and others). But, it's hanging on by a thread.
>What is the benefit to buying a car from a company very few people have heard of?
Status? Once everyone old money and new money already has a Tesla how else can you stand out and start a conversation, but by buying more niche but equally expensive EV brands that look cool and nobody ever heard of.
Henrik Fisker has been building and designing cars since the 80s. He's a known quantity in the industry, but yeah, on his car company specifically, very much buying a startup mvp, so I presume it's for people who are interested in cars and have disposable income?
How else would you start a car company? At some point in every business's life, few people will have heard of it, but they still need sales in order to grow.
> At least 7 years of backend engineering experience, at least 3-4 of which were spent building products using LLMs.
Seeing as the largest, most popular LLM only came out <2 years ago and penetrated the consciousness of the tech sector, what kind of candidate are you actually looking for?
Our CTO said he ideally wants to hire someone who has been working with LLMs since before they blew up 2 years ago; i.e. someone who has been working in the space since around GPT-2.
I honestly don't know, I am just a mid-level who wanted to post the job application here to make sure it is seen by the Hacker News crowd. If it were up to me, a salary range would be included in the job posting.
It works fine in Italy. ChatGPT just had to comply with local privacy regulations (EU's GDPR) and for a few weeks it was off. They were interested in doing this because other countries could have made a case against them, it's just that Italy was the first to move.
Ha! Just got rejected from a process in the EU (not desperately looking) cause of a super nit picky coding challenge project. The project worked exactly to spec, I just overlooked the use of a third party package on a (Django) DB model to replace the "created_at" field.
Oh well! My 4 hours of coding was not totally a waste.
I have been feeling cynical about the "blameless" culture seeping into entire organizations recently. At the end of some quarters where my team has fallen behind, I run away from the question of "who was really at fault here?". I probably should not do that...
The blameless postmortem comes from air crash investigation, where it works extremely well.
If people know there is a risk of blame, it changes their behavior. It creates incentives to destroy evidence, or avoid creating it in the first place. It creates incentives to stay inside your organizational and political boundaries rather than reach out to solve problems. Whereas if you have a successful blameless culture it is much easier to find out what actually happened.
The first of those is the aviation safety reporting system, which provides explicitly for immunity from sanction for inadvertent violations of FAA regulations (with certain limitations).
The second of those is basically the first aviation law clause for flight crews (after 91.1 which is the "this is what this section of law applies to" and 91.2 which doesn't exist) and gives broad discretion to deviate from any rule [in this part of federal law] as needed to address an emergency.
ASRS is directly and strongly supportive of the overall blameless culture in aviation. 91.3 is moderately supportive of it.
To me, "blameless organisation" is about raising the bar for blaming people. It makes you try _really hard_ to blame the process that allowed this to happen: if you really can't... _Then_ we're within the realm of professional negligence/misconduct or performance
Blameless culture doesn't mean "we seek to not understand who was involved or played a part in the bad outcome", but rather "we seek to not punish them for their involvement, while seeking to understand who, what, why, when, and how in order that we can design a more robust overall system".
Blame-oriented cultures result in people hiding problems, which makes them worse in the long run.
That doesn’t mean people aren’t accountable for their actions in “blameless” cultures, but problems are first assumed to be the result of systemic issues, deserving to be fixed, rather than individual issues, deserving to be punished.
The first one would refresh all the cached information after a marketing database update. The second would stop all the webservers.
Guy's first day; I'm showing him the ropes; we push the marketing data update and set about regenerating all the cache files by manually picking the correct file from the folder of all possible files. I'm sure we can all guess what happened to make this a story remotely worth telling...
Complete site outage. Completely unnecessary. Completely human error.
Should we blame the guy who clicked on the file that was directly adjacent to the one he intended? Should we blame me as the guy overseeing the training? Or should we change the system so that files that we use multiple times everyday and are safe/innocuous are't right next to an E-stop/EPO button? Or maybe we should change the system so that pushing marketing data refreshes the caches files automatically?
Blameless culture favors the latter actions over the former and tends to make your operation stronger and more resilient over time. The experts (and the novices) who made the mistake can speak freely about what happened and how we might prevent it, without fearing reprisal.
If someone repeatedly kills the site by mistake time after time, despite reasonable safeguards being in place, they should face disciplinary action. But when they make an honest mistake because we left an idling chainsaw laying around on the workbench, it makes no sense to blame them for grabbing it by mistake.
You are conflating criminal acts with engineering problems.
As stated earlier, blameless postmortems are for RCA of a particular incident. If you shoot every engineer who causes a incident you will succeed in having no incidents because no one will bring them up or making any changes for fear of getting shot.
You might want to, but whether you should do it is a separate question of its own.
If you promise people that there will be no blame, no punishment, no nothing, then they may speak more forthrightly. Do you want that honesty or do you prefer to retain the option of punishment?
because in the end the powers at work will make sure that the blame goes to some person turning a wrench instead of finding the real reason and the real source of the blame, most likely a process or inadequacy of redundancy/checks-and-balances would have been the real fix. Pointing at Max over in Wrenching because he left a wrench in the motor because he's been working double shifts for months on end does not fix future issues, and Hank the Replacement will likely make a similar mistake at some point in the future
Blameless culture is not about dodging responsibility. It’s about that when a process wrongly allowed a human to do X, the process is the issue to fix.
Of course you can go deeper and ask why was this process not done correctly etc but at the end of the day, it’s about actionable changes that ensure mistakes don’t get repeated.
Blaming process for everything is a symptom of this mindset. Not everything is a process issue. Process is the only thing you can blame with this mindset, but it will only fix process issues.
> Unless you just call everything a process: "His childhood was difficult and that's why he fouls people. Let's call his childhood a process."
Well... attempting to prevent stuff like bullying or domestic violence is a worthwhile goal in itself.
For the example of the soccer player, one might also question other incentives (e.g. bonuses tied to winning games no-matter-what), or why a player with a known history was hired in the first place.
I disagree - if 'everything can be a process' we wouldn't need human judgement anywhere - and clearly we clearly still do need humans in the loop - and the reality is the judgement of humans is not all created equal. Some are better than others.
I mean in theory, you're absolutely right but so rarely does it ever actually shake out that way. It seems like corporations continue to make the same mistakes while simultaneously being held less and less accountable.
Literally hundreds of people have died due to Boeing's negligence recently and the prevailing opinion seems to be that no one is ultimately going to be held accountable. (at least not meaningfully)
Ideals are great and all but if it results in zero accountability when hundreds of people die, maybe its time for us to re-evaluate.
Perhaps you haven't worked enough in a habitually blaming organization. The problem is that blaming is both easy and often spurious. So in the end you still often run into the same problem: a bunch of people pointing fingers at each other and no one owning anything. If anyone takes a fall because of it that's often more a measure of their political power rather than their actual culpability. It also fails to address dysfunctional organizational processes that make individual errors more likely, because everyone is more concerned with finding a single scapegoat or small group of them.
Maybe we need a new way of expressing "blameless" that still expresses that personal responsibilty for quality work should be expected, but that punitive blame politics are simply a very ineffective way of encouraging that or finding the truth when problems inevitably occur.
The blameless culture is about the benefits of not blaming the reports I think. If you manage a team you should see yourself at fault in a sense if something goes wrong just by implication. But you should try not to make it a big deal for respective team member and your higher-ups should try the same for you...
Making it clear who did it does not mean firing that person or making them feel like shit internally, it's a learning process, but the higher up you go the more you should feel bad (presumably you went through the learning process and earning big bucks as a result, so wtf)
> The blameless culture is about the benefits of not blaming the reports I think.
That may have been the case, but their are entire company values that insist on the blameless culture. This certainly sends a message organization wide to all levels that blame is not tolerated.
You are conflating "blameless culture" and blameless retrospectives culture.
You can 100% blame people for doing bad things. But in an engineering incident you want to find the RCA.
In SDE you may find the single git commit that took down everything, it has a author. Fine, there is blame. But why was there no review, no unit tests, no functional tests, QA, etc....
So you fire the engineer but make no other changes and it happens again, how is that helpful?
Same here, never understood the march towards 'blameless' culture - if someone is to blame, they should be blamed; if there is a pattern of mistakes they should be shown the door as quickly as possible.
Because if there is someone who is at fault, their reaction will be to throw someone else under the bus. So you may end up with a situation where the person being blamed isn't actually the person responsible for the accident.
I have worked in companies where the focus was finding who is responsible for failures. The result was that minor incidents were covered up to save bonuses and the problems (in the Problem Management context) that led to them were invisible to the management. When problems are invisible there is a tendency to push into safety margins to cut costs (known as normalisation of deviance) which ultimately leads to uncontrolled incidents.
In my current role I promote a blameless culture and the result is my team proactively raise incidents. We have more incidents than other teams but the incidents are generally controlled and problems are visible, prioritised and closed off. Coincidentally, my teams have record high Mean Times Between Failures and I'm now working with the other teams to fix their safety culture.
The lack of thinking about safety culture in this way is one of the reason that I don't believe most "Software Engineers" should be considered engineers.
