Alacart

This is how I've explained programming to friends and family. It's like I got my letter to Hogwarts and I've been learning magic ever since. I get to make something real out of nothing, just by spending time learning how things work and working on the craft of using that knowledge. That's magic to both 11 year old me and and 32 year old me.

Agreed, though most people just call/pronounce it "post gress". Wish it had a better name though.

Is it more likely that Nature suddenly lost it's integrity or that people on HN might be jumping to conclusions about what the study actually says and how it was run?

I don't see anything in the study that claims anything other than the truth? It's not like it's saying "Microdosing will make you happy".

The title is literally "Adults who microdose psychedelics report health related motivations and lower levels of anxiety and depression compared to non-microdosers"

It then tells you how the research was done, and what the statistics were. This isn't a random news website saying "Chocolate prevents cancers" or something.

Yeah, self-reported data should be taken with a grain of salt. On a large enough scale though, that data says something though. It might not be the original insight you're looking for, but it's still data.

There are also plenty of tests and measurements that can be given over an app that don't rely solely on subjective self reporting too though. For instance: reflexive tapping tests, wearable health telemetry, memory tests, etc., etc.

I'm excited to see researchers taking advantage of tech to speed up studies and make research more feasible in general. More research means more insights and advancements in the long run for all of us.

> You say that "millions" of participants should be useful, almost automatically.

I don't disagree that there are issues with self-reported data, but I do disagree with saying that a large set of self-reported data is worthless.

I also didn't say millions, I said massive. Which in the case of research like this could be the difference of 40k participants (through an app) and 100 participants (clinically). While the size of the data set isn't everything, it does matter. With 40k participants you could aggressively invalidate 30k of them and still have 100 times as many data points for statistical validity as that clinical study. The clinical study would also cost more and take much more time to implement.

> How many self-report surveys would it take to match an actual double-blinded study with double digit participants? What if the answer is "hundreds"?

I don't know, but how many more can be easily done now if technology is used like it was here? What if doing 100s in the same amount of time is now feasible? What if it takes far fewer than your arbitrary assumption of 100s of studies? What if it only takes 1 study with 100x the participants?

No one here is advocating for stopping double-blinded studies. Why not both?

> If you're off by an order of magnitude somewhere in your stack of assumptions, the data could be noisy enough that you need to be sample from a population of a hundred billion.

Why would you assume that it would be off by an order of magnitude? That seems about as likely as the data being perfectly accurate (that is, very unlikely).

And why 100 billion? It seems like you're just throwing out arbitrarily large numbers here.

> Should we wait a century for all these surveys to be done before even attempting data analysis?

This study took less than a year, and because it was automated, could likely be run concurrently with others. Why would it take a century?

> surveying the same set of people over and over won't give you additional data. You need to wait for some of the survey respondents to die.

Why would they survey the same set of people for the same study? There's a lot of people in the world.

I know you've decided for some reason that it would take 100 billion people, and that 100s of studies would need to be done to compare to even one clinical study. I know that for some reason you think that would take a century instead of in parallel.

Consider for a second that if you're wrong on any of those magically large and arbitrary numbers, this might actually have some value to the world instead of dismissing it out of hand.

Again, no one is suggesting any fewer clinical, double blinded, etc. studies. Doing studies this way has some potentially very large upside, and it can be easily used in tandem with those other studies to speed up research and gain much larger data sets.

Yes it has trade-offs. We can be aware of those without throwing out the whole idea.

I replied something similar elsewhere, but I think the real story here is about using tech to administer large scale studies and what that could mean for future research.

A lot of people here are discounting the fact that this study would typically be very hard (or impossible) to administer at such a large scale, especially in such a short amount of time.

In my mind, the important questions here are:

Are the benefits of massive scale studies worth the trade-offs of self-reporting?

What can we do to reduce or eliminate those trade-offs?

Imagine the scientific value of having easily created, easily administered, massive studies be easily accessible to any research group. If the research data can be made even a little bit more reliable (direct mobile health-kit measurements for example), that's hugely valuable.

> We already know from plenty of surveys that people will self-report a lot of benefits; and we also already know that adding in randomization, longitudinal tracking, or blinding makes most or all of the effects go away.

Do we know this or do we "know" this?

Having another study, even a self reported one like this, doesn't degrade the scientific body of knowledge, it adds to it. The fact that there have been other studies doesn't make doing another worthless.

I also think a lot of people here are discounting the fact that this study would typically be very hard (or impossible) to administer at such a large scale, especially in such a short amount of time.

In my mind, the important questions here are:

Are the benefits of massive scale studies worth the trade-offs of self-reporting?

What can we do to reduce or eliminate those trade-offs?

Imagine the scientific value of having easily created, easily administered, massive studies be easily accessible to any research group. If the research data can be made even a little bit more reliable, that's hugely valuable.

I also recommend sponsoring Matt Holt for his work on Caddy and several other very useful and high quality open source repos. He's very under sponsored for having built a server that a lot of companies use.

https://github.com/sponsors/mholt

Absolutely. my reply was aimed more at the unseen other readers looking to use your comment to confirm their bias that regular people can't do this without a huge audience and dismiss it altogether.

I think this gets overblown in the sense that followers often do no equal customers, especially when it's a subscription. obviously yes, having an audience is helpful, but it can also give you false confidence too. They'll tell you your product is amazing, sign up for an early access waitlist, and then often very few of them actually buy because what brought them there was a desire to emotionally support you, not a need for your product. It does help you get the word out though.

I'm absolutely pissed about it. I couldn't believe it when I saw it and I spent 20 minutes trying to find the setting that I thought must be there somewhere. It's such a seemingly small thing but in. lot of ways it's the equivalent of waking up in the morning and finding that someone came into your house in the night and stuck a flyer to your fridge.

The parent comment is saying that the economic success of China should be encouraging America to step it's game up, not that it should become a single party system.

Whoever allowed that decision to be made should be ashamed of themselves and embarrassed. Safari really is the new IE.

I run my own git server with Gogs, which is written in go. I set that up 2 or 3 years ago on a 5 dollar DOdroplet and have never had downtime and I haven't SSH'd into it since the initial setup. I use it all day every day for many projects and have had up to about 5 devs regularly committing to it as well. Zero problems, ever.

There's also Gitea which is a fork of Gogs after some contributors became concerned with the bus factor, very slow feature development, and occasional disappearance of the maintainer of Gogs. I haven't use it but that's probably what I'd try first now.

I think you could argue up front and ongoing costs for either scenario.

The duplication of an app for each install is technically very low cost (although you could say that the app store taking 30% is a cost there), that doesn't mean there weren't large up front costs and ongoing ones as well.

What about maintenance, support, infrastructure like servers/services/bandwidth. For anything of a decent size you probably have to do these things, which means you probably need staff, which means you probably need an office, benefits, insurance, all the usual business costs. That's not even bringing up the constant updates, new features, and supporting the ever changing platform or environment it runs on, which is all completely expected by users.

Apps are as much of a regular business as anything else, not some magic special case.

Pattern matching is awesome and we should make use of it whenever appropriate, but not every situation is appropriate. For instance, if your formatted_hour functions were larger, or shared some amount of code between them, then cond might be a great option instead. Or case, or even the dreaded if statement. As a community, sometimes we overuse our cool special features just because we have them! Personally, I like the case statement as a middle ground for lots of scenarios. You still get pattern matching and it's pretty readable.

Your first argument is true, but I would argue that if you already know what you're doing, you can write some demo portfolio code specifically to show off your skills in very little time. Make that code pleasant to read, free of legal constraints, and be ready and able to talk about it. You probably will spend at least 40 hours a week at your job and it will dramatically affect your life. That's worth spending a few days, maybe even a few weeks preparing for so that you can get one you like.

For your second argument, I know what you mean, but that's also totally subjective, dictated by chance, and would apply equally across the board for all candidates. Even if that happens, it sort of naturally levels itself out competition-wise.

Also, remember that you're evaluating the employer too - do you want to work for someone who chooses employees that way? Would you want to work with someone who has a closed mind and an axe to grind about certain concepts? I wouldn't trust people like that to make good decisions that will make the company succeed, thereby keeping me employed - let alone providing opportunities to advance. Plus they sound like they'd be a pain in the ass to work with.

You're right, maybe not the right thread for this.

I was commenting less on the article and more on the general disdain for bootcamp grads that seems to crop up in every article or thread about them. It always devolves into whether people with this education or that education are any good, and it's just completely irrelevant.

Who gives a shit where or how you learned to code. What a stupid and indirect way to filter candidates.

Just show me what you've done. Send me repo links, production code, or even just the end result with some sort of proof that you actually built it. That's the best part about any craft - practicing or building something creates tangible results. If you don't already have a portfolio, get to work on that before you start applying.

The problem, I think, is that they are hiring younger for what are economic decisions, rather than decisions based around protected status. That is, they're more likely hiring young because they can get a better deal out of it (they assume), not because of age in and of itself.

I don't want to see older tech workers out of work, but I also don't think it's a group that deserves anything more than any other group.

A few, more concrete, ideas about how you might reduce emotional Bing coding:

Experiment with coffee. Most commonly I see bingers drinking a LOT of coffee, that's what fuels and in part causes the binge. If that's the case, try going to zero coffee and then every other day, try increasing your coffee intake just a little, with a rest day of no coffee in between, until you find out what actually works best for your productivity. You're looking for optimally consistent, not max output in one sitting. It's got to be consistently repeatable.

Try meditating. I recommend the app headspace if you've never done it. Basically a large part of meditation is deliberate awareness of your thoughts and emotions, the goal being to better understand yourself and what makes you tick. If done consistently, it seems to help people guide their thoughts and emotions in a positive way, which can really help with something like programming.

Exercise. We all know the benefits, a zillion studies have shown it helps you feel motivated, relaxed, improves mood, and think clearly. Seems helpful to me.

Decide to take the pressure off of each work session, regardless of what's going on. Even if it's crunch time and the sky is falling, tell yourself this is not the be-all end-all, that you won't remember this in 5 years let alone 20, and to relax. Choose to be calm, and just focus on making the project a little bit better than when you started.

Go for walks. I separated this out from exercise, because the best benefit of walking is that it takes very little thought, freeing up your brain and giving it space to run around. Sometimes I just let it go bananas, the equivalent of a dog zooming around a back yard. Other times, I'm just washing out everything else by listening to a podcast or an audio book. Or, just putting on music and letting myself feel more and think less. All of these are like a pressure release valve for your mind.

Make a list. Follow that list strictly. Nothing is less emotional than a cold hard list. Not something I recommend all of the time, it can make your thinking rigid, but a very simple and effective tool when that's what you need.

One of my main complaints about cs in university is that they didn't teach how to put their effort and energy into their projects in a healthy and sustainable way. Many students ended up learning the 'magic binge' approach you're talking about.

It depended on that seemingly random lightning bolt of inspiration combined with almost manic mental energy to work crazy hours to get it done. If you've ever worked through the night, met someone who _expects_ future crunch times (aka. binges), or put off working on something important because you just weren't feeling it right now, then you know what I'm talking about.

The closest analogy I've found is writing. Experienced professional authors most commonly give out the advice to work on it consistently, every day, whether you're feeling it or not. I feel like that heavily applies to programming too. If you care about a project, for work or for your self, you've got to make it part of a routine. Pick your days and time that you're going to work on it, then sit down and work whether you're super excited and have 'flow' or not. I think that after a short amount of time each session, you'll find you are creating the inspiration rather than waiting for it to find you.

Ok, here's a strange analogy, but hear me out. Think of a company as a hostel rather than a family or a sports team.

For example:

The owner is trying to make a profit (rather than a hard salary) and it's probably best if they're fairly detached or things go haywire, but a good hostel owner wants the hostel to be beneficial and enjoyable for the guests (regular employees) because it benefits everyone.

The hostel staff are management. They are much more involved with everyone, but still try to remain detached somewhat, since they might have to kick a guest out for bad behavior. Often they were previous guests, and those people often make the best staff (managers) because they know all sides of it. They get direct orders from the owners and try to make that work.

Guests are the equivalent of a company's employees. They are all there for different reasons and get all different kinds of things out of it. Some want to spend most of their day hanging out with other guests and staff. They're not in a hurry to leave and they get a lot of their satisfaction from the comfort of the hostel and the people they're with. Seeing the area is sort of tangential to them. Others are trying to see everything they can, they don't care about making friends, they have a plan and goals. On the extreme end, they might do something like cut in line to make sure they make the list for the next tour. In fact if they can't, they're probably going to another hostel.

Anyways it's a loose analogy, but everyone is there for different reasons that overlap at different points. They're not really all working towards the same goal, but again, their goals likely overlap. Nobody bats an eye that the goal of a guest isn't to make the owner the most profit, or vice versa. You can reasonably expect that most people are going to move on sooner or later. People may or may not become really socially involved, depending on what they want. Some hostels are large and less sociable, others are tightly knit and cozy. I can draw parallels for days.

I mean, obviously a hostel _is_ a type of company, but I still think it works as a helpful analogy. Most of the things I roll my eyes at or that people don't like about companies, you could try to apply to the hostel analogy and it will break the illusion of that thing being good. If people thought of their work more in that context, there might be a little less company koolaid being pushed around these days and a little more satisfaction for everyone.

Depends on what you're interested in.

For programming:

-Software engineering daily & the other less frequent version

-the changelog

-shoptalk (mainly frontend)

-twenty percent time (mainly Laravel?)

-syntax (new show)

-full stack radio

-does not compute

(Would love some recommendations for more!)

Startups/Bootstrapping/Business:

-Indie hackers

-Tim Ferris (some episodes)

-Startups for the rest of us

-Mixergy Startup Stories

-The pitch

-DFJ ETL (Stanford entrepreneurship podcast)

- How I built this

For life and interesting topics:

- Tim Ferris

- Freakonomics

- Planet Money

- 99% invisible (haven't listened to much, but hear it's very good)

- Between World's (haven't listened to it much yet)

For entertainment:

- How did this get made? (hilarious reviews of bad movies by a group of comedians with various guest comedians)

- Bill Burr (Like having a chat with your funniest friend that you go way back with)

No, usually that lessens my enjoyment actually. The point for me is to get outside and just enjoy being there, and being a little bit active, not to pack another objective onto my to do list. I'll often make a small coffee and sip that while I listen to a podcast, which could be a business or programming podcast, something like freakonomics, or just entertainment like 'How did this get made?'. On the way back I might stop and pick up a few groceries or something though.

I can see how my way do the opposite for some people though, where the mental pressure valve for them is released by getting something else on their to do list done.

No, as I mentioned, I'm a freelancer. Intellectual property for any project is strictly defined in the contract for that project. I'm also operating on my own equipment, as a separate entity, on my own property. Not to mention that clients are actually not allowed to get to specific with when or how I do my work exactly, without breaking some Canadian (and I suspect American), rules related to distinguishing contractors from employees.

I work as a freelancer from home, so my answer might be less interesting to people at an office, but I've found that at home I'm mostly just doing the things I wanted to do at the office when I worked in one, but felt uncomfortable doing there. These include:

Taking short (15 - 30 mins max) naps if and when I need them, which pretty dramatically helps me creatively problem solve.

Going for a long-ish walk outside. This is by far the absolute best thing I've added to my days. I feel more energized after, I mentally and emotionally am much happier, and physically it made me slightly fitter. Plus it helps relieve some of the problems I know I'm developing sitting all day.

Podcasts. This one I only do when I'm taking a break, I can't focus and get into a flow listening to other people talk about interesting topics. Awesome for those walks though.

Chat with other developers and friends on slack or some other messenger. Usually at some point during the day I'll have a 15 minute flurry of messages with a developer friend about some side project or something we think is cool.

And finally, this one is half work half fun, but I'll research something I think is cool or would be useful. Might be a service, framework, product, methodology, anything at all. I probably spend an hour or so of my work day, every other day, on researching something that's not an absolute necessity to the work, but might benefit it. In some cases it's paid off big time. Mostly though it just keeps me happy, interested, and hopefully a little sharper.

> If you want client persistence, you have localStorage, sessionStorage and IndexedDB.

I really wish that we had a persistent, non-ephemeral web api for local storage. One that has to be manually deleted by the user, searchable by domain, just like a mobile app. It should ask you to allow it just like notifications or webcam usage, and allow you to set a maximum size with a reasonable fallback default. Until we have that, and full support for service worker features, mobile apps will be a necessity for many developers unfortunately.

Interview idea: Honestly and bluntly tell the potential employee the worst things about working for your company, _then_ ask them why they want to work there. I bet you would get some really telling information out of their answer, and if you haven't scared them off maybe they'll be more likely to stick around.

In my anecdotal experience, selling something, especially to businesses, typically comes down to 4 things (in descending order of what's easiest to sell):

Will it make them more money?

Will it save them money?

Will it make their (the decision maker's) life significantly easier?

Will it make their (the decision maker's) life feel dramatically better?

Notice how they get more subjective as the list goes down. Its hard to convince people of, or prove, subjective things. That last one is so hard that I'm not sure I've ever seen someone successfully sell something that way in person. But the first one needs almost no convincing at all.

Now, does your search engine do one or more of those things for people? If the added performance doesn't fulfill one of those desires, sorry but they probably won't be interested enough to go through the pain of switching and taking the risk of failure with a new and largely unproven system.

But if you can show that it will demonstrably fulfill one of those needs, say by cutting down the number of servers required, less down time, or better search results that also result in more sales or engagement, then you've got a product you can sell.