HN user

arctangent

1,319 karma
Posts0
Comments512
View on HN
No posts found.

Julian Jaynes' book is of course relevant. [1]

Further to that, I've read on several occasions about lone survivors of disasters who report encountering a person who wasn't there who helped them to survive.

The most common I've encountered is the stereotypical tale of "mountain madness" [2] where an injured or lost climber receives help or guidance from an imaginary being (who presumably seemed quite real to them during their escape from peril).

Literature, fiction and cinema are all full of similar tales (not all in mountain scenarios) and so I expect that this "ability" is part of being human.

There would be an evolutionary advantage to be had if the brain was able to access some "hidden partition" containing recovery instructions during times of extreme stress.

[1] https://en.wikipedia.org/wiki/Bicameralism_(psychology)

[2] https://consumer.healthday.com/fitness-information-14/climbi...

Edit: better [2]: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6088769/

So we need to be on call continuously, 24/7, meaning we can't ever be off the grid or unavailable?

The well-established solution to 24/7 availability is to operate a shift pattern.

Fred Brooks said [1] that there are two types of complexity, accidental and essential. While accidental complexity can be reduced the theory is that the essential complexity cannot.

"Accidental complexity relates to problems which engineers create and can fix; for example, the details of writing and optimizing assembly code or the delays caused by batch processing. Essential complexity is caused by the problem to be solved, and nothing can remove it; if users want a program to do 30 different things, then those 30 things are essential and the program must do those 30 different things."

[1] https://en.wikipedia.org/wiki/No_Silver_Bullet

While OODA is an interesting and increasingly popular concept, it is really only useful when applied to very short intervals of time. You can and should expect that an opponent with "a reasonable amount" of time will make the correct response. In business that timeframe is much longer than the few minutes or seconds a modern aerial duel might be concluded in.

The general idea of OODA is that if you can "play fast" you can beat someone who can otherwise "play better". Think about how blitz chess differs from traditional multi-hour games, even though the rules of play are the same: for example it is often possible to exert time pressure by playing "confusing moves". This concept of "fast play" translates into the business timeframe more as the concept of "agility" (to be contrasted with large-company "inertia"), whereas businesses only try to confuse one another on television or by accident :-)

Concepts similar to OODA but more applicable to a business context and timeframe would include PDCA [1] and DMAIC [2].

PDCA a.k.a. the "Deming cycle" stands for "Plan, Do, Check, Adjust" and is closely related to the concept of "kaizen" [3] (or "continuous improvement"). PDCA happens in timeframes that can best be described as a "short project" (or a "kaizen event").

DMAIC ("Define, Measure, Analyse, Improve, Control") on the other hand is a framework commonly used for larger business interventions where the stakes are higher, more project members are needed, more structure is required and so on. It is a key feature of the Six Sigma [4] approach as well as Lean Six Sigma [5].

Note: I'm sure there are other valid approaches too. I'm just mentioning the ones I am familiar with in case anyone else is interested in methods to help businesses improve and respond to change.

[1] https://en.wikipedia.org/wiki/PDCA

[2] https://en.wikipedia.org/wiki/DMAIC

[3] https://en.wikipedia.org/wiki/Kaizen

[4] https://en.wikipedia.org/wiki/Six_Sigma

[5] https://en.wikipedia.org/wiki/Lean_Six_Sigma

While I recognise the valid points made elsewhere in this discussion about this guy’s luck and/or cheating, I can’t help wonder about how we would react differently to an AI “oracle” that gave useful solutions to problems we can’t /couldn’t solve. Where is the boundary between experiential evidence and statistical “proof”?

NHS.UK frontend 8 years ago

This is a very difficult question to answer comprehensively because our "website" does a lot more than just present information to people! Most of the content you can see on www.nhs.uk is Python/Django/Wagtail plus a whole heap of infrastructure. But there are aspects of our service written in C# or JS for example.

NHS.UK frontend 8 years ago

I'm the tech lead for the NHS website (www.nhs.uk) and I oversee the team who are building this frontend library.

With respect, I think you fail to appreciate the importance of effective communication of health and care information to members of the public.

The NHS is under incredible financial strain due to an ageing population and one of the UK government's key strategic goals is to reduce demand on GPs and hospitals through channel shift, i.e. providing much better information online so that citizens can prevent illness and also find better avenues for care (e.g. their pharmacist).

This is much more difficult than you might think. For example, a very large number of people seeking health and care advice in the UK are "old" and not used to using the internet. At NHS Digital we have had to carry out extensive research into how best to communicate advice in a way that is suitable for all audiences.

NHS Digital has a key role in the UK health and care system and our goal is to share (and perhaps mandate) our technical solutions to these communication problems. Through this we aim to save the NHS money and promote better citizen health and care.

NHS.UK frontend 8 years ago

I'm the tech lead for the NHS website (www.nhs.uk) and I oversee the team who are building this frontend library.

Your comment is a good explanation of how things work.

My employer, NHS Digital, is working on this frontend library as a way to spread good practice throughout the federated health and care system you describe.

In short, we spend money doing the research on how best to provide information to users/patients and then we promote the uptake of the technology we develop to best satisfy them - with the overall goal of improving self-care and reducing the need for costly GP appointments and hospital visits.

NHS.UK frontend 8 years ago

I'm the tech lead for the NHS website (www.nhs.uk) and I oversee the team who are building this frontend library.

I largely agree with what you have written above, however things work very differently now in NHS Digital.

Every piece of work we embark upon is based on strict requirements from a commissioning body (typically NHS England or Public Health England) and is managed tightly according to budget and demonstrated realised benefits.

We have a highly capable layer of delivery managers who help translate and interpret these "business goals" into things which our agile teams of developers can work towards.

It's not perfect, but we're improving all the time. If we fail then the money taps get turned off quickly, and we move onto something else.

NHS.UK frontend 8 years ago

I'm the tech lead for the NHS website (www.nhs.uk) and I oversee the team who are building this frontend library.

I'll be making sure we remove our jQuery dependency when I can. For now the team is simply aiming to get to an MVP that we can iterate on :-)

NHS.UK frontend 8 years ago

I'm the tech lead for the NHS website (www.nhs.uk) and I oversee the team who are building this frontend library.

I will pass on your comments about RSS to our architect (who gets to decide these things).

We do syndicate all of our content via a service which requires registration. Maybe you could try this as a workaround?

https://developer.api.nhs.uk/

NHS.UK frontend 8 years ago

I'm the tech lead for the NHS website (www.nhs.uk) and I oversee the team who are building this frontend library.

I'll be making sure we remove our jQuery dependency when I can. For now the team is simply aiming to get to an MVP that we can iterate on :-)

NHS.UK frontend 8 years ago

I'm the tech lead for the NHS website (www.nhs.uk) and I oversee the team who are building this frontend library.

NHS Digital are working on a "Standards Library" encompassing how to go about building healthcare websites and services (as opposed to generic government services) which encompasses not only the design of a website but also the whole lifecycle of the service.

We still have work to do, but I think 2019 will see the release and adoption of our ideas across the UK!

NHS.UK frontend 8 years ago

I'm the tech lead for the NHS website (www.nhs.uk) and I oversee the team who are building this frontend library.

We have a full-time and fully-staffed team comprising developers, designers, user researchers, product/project managers etc. focussed purely on this piece of work.

In our role working to deliver health content to the general public we take very seriously the need for our content to be accessible to users and we invest accordingly. This frontend library is something we hope to push to other healthcare providers as part of a wider drive towards standards adoption.

None of this work has come cheap, but in the public sector we work to very strict budgets (and some would say lower pay) and I would say the public are getting very good value for money here. (We are judged by and required to provide proof of "benefits realisation".)

Spotify Form F-1 8 years ago

This happened to me too, so I'm in the process of switching back to Apple Music.

I scrobble to last.fm so I can still get decent recommendations over there.

A good rule of thumb is that a Django "app" should be (1) standalone and (2) reusable.

If you were to write a Django project to automate some complicated internal process at your particular company, it's likely that you'd break up the code into separate Python modules to help give it an easy to understand structure. But it's unlikely that any other company would necessarily benefit from any of those separate modules by themselves.

However, let's say you come up with a clever idea about how to log errors in your project. Now, that's the sort of thing that other people might want to use in their own projects. If you were to restructure your code a bit and make it a bit more abstract then you could create a separate "app" that could be dropped into other Django projects.

You've caught a lot of flak for your statement.

With the knowledge I have now it would easy for me to say "and rightly so", but I think I can understand where you're coming from.

Django didn't always have schema migrations built in. I think they appeared in version 1.7 about 2 and a bit years ago. Before then there were separate add-on apps that could do migrations for you.

When Django added built-in support for migrations I still didn't use them for a while because at the time I was primarily a solo developer and wanted to have full control over what happened in the DB. And because I was a solo developer it didn't matter. So in that sense you're comment is in some ways correct.

However, in recent times I've started to work as part of a team. And that's where migrations really start to shine, because there might be several different people making app changes that result in DB schema changes. Django stores migration files with information about which other migrations each one is dependent upon.

Without that kind of migrations system it would simply be impossible for developers working on combinations of different branches of a development tree to build a working version of the code.

So much hate in this thread!

@Perihelion: Allow me to be the one who says "thanks for your efforts" and "keep up the good work".

My team are using GitLab to manage development and we're happy with how it's going so far.