Yipit Django Blog: Why You Need a Git Pre-Commit Hook - <AUTHOR> http://tech.yipit.com/2011/11/16/183772396/

<comment><USER2> This is what I use with django+south to prevent forgetting to commit migrations:

      MIGRATIONS_DIRECTORIES="$(find -type d -iname migrations)"
      UNTRACKED_MIGRATIONS="$(git ls-files --exclude-standard --others -- $MIGRATIONS_DIRECTORIES | egrep '(.*)[.]py$')"

      if test -z "$UNTRACKED_MIGRATIONS"; then
          # If there are no untracked .py files in the migrations directory, do nothing, allow commit.
          true;
      else
          # If there are untracked files in the migrations directory print a warning message.
          echo "Warning -- Untracked files in the migrations directory"
          echo 'The commit may be forced with "git commit --no-verify"'
          echo
          echo "$UNTRACKED_MIGRATIONS"
          exit 1
      fi

</comment><comment><USER3> I can't get behind pre-commit hooks.

1) Sometimes (usually the worst times) you just need to check something in, maybe it doesn't pass pep8 but when service is down nobody gives a shit.

2) Instead of promoting thinking and caution it promotes attitude of "hey check it in and see if it sticks".

Post commit hooks that report broken tests, poor code, etc preferable to whole team are far superior. After first couple of times being shamed people will actually look over their code, run tests, run pep8, etc to verify the commit isn't bogus.

<comment><USER4> `(Note: A pre-commit hook can be bypassed by passing the --no-verify argument.)`

<comment><USER3> neat(ish) that definitely solves the one critical issue.

Tool I use doesn't have that AFAIK. My comment was focused on universal concept "pre-commit hook" not a particular tool.

</comment></comment></comment><comment><USER5> This is my pre-commit hook for Django projects: <https://gist.github.com/858223>

It just runs pyflakes and does some sanity checking. Best of all, it doesn't go around stashing files or otherwise messing with your working directory or repository. It just uses some git plumbing commands to copy the current index (what you're about to commit) to a temporary directory.

I can't remember where I copied it from but it works perfectly, only copying whatever I'm about to commit:

         git diff --cached --name-only --diff-filter=ACMR | xargs git checkout-index --prefix=$TMPDIR/ --

I can't say how many times this saved me from leaving a pdb.set_trace() in a view somewhere...

<comment><USER6> Cool. We had looked at doing it that way, but decided that we wanted to have the flexibility of accessing the entire repo so that we can run things like "./manage.py validate" and quick unit tests.

A leftover pdb.set_trace() that snuck into production is the exact reason we first added this :)

<comment><USER7> So wouldn't:

git checkout-index --prefix=../temp/ --all

work?

<comment><USER6> Absolutely. Stashing seemed like the cleaner choice to me, but either would work.

</comment></comment></comment></comment><comment><USER8> Personally, I find pre-commit hooks to be a throw-back to older RCSes. For modern systems like Git I would prefer to have a pre- _merge_ hook. That is to say, commit any old crap you want to your local branch but you're not merging with the main development branch until your code is proven to pass the test suite. And only code that is in the mainline dev branch can be merged to main, etc.

</comment><comment><USER9> Here's my bash pre-commit hook to check for PHP syntax errors and accidentally committed merge conflicts: [https://github.com/dave1010/scripts/blob/master/git- hooks/pr...](https://github.com/dave1010/scripts/blob/master/git-hooks/pre- commit)

</comment><comment><USER10> I think it's a bit overkill to say any pre-commit hook that doesn't stash before running is 'wrong'. If nobody thought to stash before checking the files, maybe nobody else has a workflow that would require it. For me, staging and committing happen in immediate succession, so there wouldn't be any edits that aren't staged. If you work in a way that requires it then go right ahead, but what's the deal lately with calling everyone else 'wrong'?

</comment><comment><USER11> Here is mine:

[https://github.com/lbolla/dotfiles/blob/master/githooks/pre-...](https://github.com/lbolla/dotfiles/blob/master/githooks/pre- commit)

It PEP8-fies and pyflakes .py files and gjslint-ifies .js files. Other actions can be easily added!</comment>


Medical error in hospitals is the third leading cause of death in the U.S. - <AUTHOR> http://www.kurzweilai.net/warning-your-hospital-may-kill-you-and-they-wont-report-it <comment><USER2> Thankfully I haven't had many reasons to enter a U.S. hospital, but the few interactions I had were extremely worrisome.

For example, when my grandmother fell ill, my family spent a lot of time visiting her. My mother, in particular, spent many days and nights there, and her biggest complaint was the complete lack of communication between shifts.

Every few hours, someone new would come into the room, read my grandmother's charts, wake my grandmother up, and ultimately misinterpret several important details. Thankfully my mother was often there to correct them and fill them in on what previous nurses/doctors had already done, but the net result was that my grandmother barely got any rest (being constantly woken for no apparent reason) and, had my mother not been there, a nurse or doctor could easily have made a critical mistake when continuing her treatment.

Another example, still the same grandmother. Even though her original condition improved (after having been rushed to a different hospital), she ended up going home with an entirely new infection which resulted in several more weeks of sickness and eventual recovery. The infection (C. Diff) is one of the leading Hospital-acquired infections and is in many cases totally preventable. It's hard to believe how many people die each year due to infections they pick up in hospitals.

<comment><USER3> > her biggest complaint was the complete lack of communication between shifts.

Hmm seems weird and easily addressable to me, I had to spend some time in a hospital in Paris (France) and the staff had a meeting between every shift to discuss how patients were going. To the point that people complained they weren't available at that time... But yeah no experience with US hospitals so YMMV.

<comment><USER4> Most human errors are easily preventable.

</comment></comment></comment><comment><USER5> Note the paper's definition of medical error: "Medical error has been defined as an unintended act (either of omission or commission) or one that does not achieve its intended outcome,3 the failure of a planned action to be completed as intended (an error of execution), the use of a wrong plan to achieve an aim (an error of planning),4 or a deviation from the process of care that may or may not cause harm to the patient."

That's quite broad

<comment><USER6> Is it? Those all seem like pretty reasonable types of error. Ultimately they have to have contributed to the death of a patient to be included. If one of those things contributed to someone's death, I don't think i'd hesitate to call that a 'medical error'.

<comment><USER7> > one that does not achieve its intended outcome

I struggle to see how there are any deaths inside a hospital that don't fall into this category. E.g. a cancer patient on chemo therapy who doesn't make it would seem to qualify.

Realistically I assume this means that they count whatever they want as medical error, with no good rules.

<comment><USER8> I don't think your example would qualify unless a real error was made e.g. the chemo killed them so there was a planning error in putting them on chemo. The truth is that many people with cancer will not survive. In those cases, chemo is not about saving their lives, just extending them.

<comment><USER9> You're saying what it _should_ be but the parent comments are talking about what it actually says. Specifically, "one that does not achieve its intended outcome".

<comment><USER8> I'm arguing that the "intended outcome" isn't always complete recovery. If a patient with terminal cancer dies, that doesn't necessarily mean that the chemo didn't achieve its intended outcome.

</comment></comment></comment></comment></comment></comment><comment><USER10> A thoughtful point-by-point response to the underlying medical journal publication:

"Are medical errors really the third most common cause of death in the U.S.?"

[https://www.sciencebasedmedicine.org/are-medical-errors- real...](https://www.sciencebasedmedicine.org/are-medical-errors-really-the- third-most-common-cause-of-death-in-the-u-s/)

Simply put, the headline of the article kindly submitted here surely exaggerates the actual problem. What's undoubtedly a problem is that we don't yet have good data-gathering about when patients die unavoidably and when they die when they could have been saved by standard-of-care medical treatment.

<comment><USER11> Why is this being downvoted?

<comment><USER12> Maybe because the first paragraph is a non sequitur swipe at the business of alternative medicine and two people in particular. Or maybe because there's apparently an online campaign against the article author.

The first paragraph may not be so random in the blog's context, I expect a blog called Science Based Medicine would spend a lot of time doing battle with alternative medicine adherents, but it detracts from this specific article which does a good job deflating this medical errors headline.

</comment></comment></comment><comment><USER13> The original study's authors suggest adding a field to death certificates where the hospital personnel would put additional information about the cause of death:

 _... death certificates could contain an extra field asking whether a preventable complication stemming from the patient's medical care contributed to the death._

How could they do this and, at the same time, shield themselves from lawsuits which use that "extra field" as evidence against them?

<comment><USER14> > How could they do this and, at the same time, shield themselves from > lawsuits

Why is that a desirable goal?

<comment><USER15> Hospitals are a mix of stakeholders, all of whom have different agendas. There's something to be said for a blame-free environment where you can actually get honest post-mortem assessments.

</comment></comment></comment><comment><USER16> Disappointing, sad, and scary, but not unexpected. You can't expect matters of life and death that effect liability, public relations, and profitability to be properly investigated and resolved by the entities directly involved. When an airplane crashes, the airlines, manufacturers, and pilots union don't get to run the investigation and choose the results. Sure they are involved and try to influence the outcome, but an external agency heads the investigation.

Medicine needs some sort of non-punitive external investigative agency. With the scope so much larger than aviation and death often being a normal outcome, how to structure such an agency would be challenging, but I still think it's the only way to really address the problem. The same applies for law enforcement and the use of deadly force. While many of the people involved have the best intentions, the pressures of the organization put undue bias on any internal investigation.

It looks like an agency along these lines may have been formed [1], but the 'At the invitation of healthcare providers' isn't good enough. A quick google search found others pushing along these lines [3], and it's interesting that they are talking about error being the 'third leading cause of death' in 2014.

While critics point out that the study may have an overly broad definition of error, it still seems that there is an issue here from anecdotal experience, and that error shouldn't even be in the top 10.

[1] [http://www.prnewswire.com/news-releases/pso-services- group-l...](http://www.prnewswire.com/news-releases/pso-services-group- launches-national-medical-safety-board---nmsb-165958516.html) [2] [http://www.ntsb.gov/Pages/default.aspx](http://www.ntsb.gov/Pages/default.aspx) [3] [http://safepatientproject.org/press_release/patient- safety-a...](http://safepatientproject.org/press_release/patient-safety- advocates-urge-the-creation-of-a-national-patient-safety-board-to-fight- medical-errors)

</comment><comment><USER17> I wonder how many of those deaths were in public healthcare and in private healthcare?

Speaking as a swede I am fed up with seeing how the government undermines public health care at every turn and promoting privatized health care. Health care workers aren't stupid, they're mass migrating from public to private sector. Leaving the public sector in very bad shape with no backup from the government to keep it running.

If you like me believe that your health should not be measured by your wealth then it's down right disgusting.

</comment><comment><USER18> I am ROUTINELY prescribed medication that I am not supposed to take.

I have a drug allergy, and one other simple condition that both preclude certain medications being prescribed to me. These conditions do not change over time, and have been in my medical history for 20+ years and yet multiple providers have prescribed medication I can't take to me. I cross check all new prescriptions myself as a matter of course now.

</comment><comment><USER4> I can't say I'm surprised. I had a surgery once at a supposedly well-respected regional hospital, and they made several careless mistakes with me. Everything turned out fine, but there was considerable opportunity for easily preventable things to have gone wrong if it weren't for dumb luck.

</comment><comment><USER19> nothing to do with death, but how hospitals don't know what they are doing sometimes.

when I was really young I jammed my finger. went to the hospital to get it checked. they were putting a wrist splint on me. I asked how that helped my finger. he quickly took it off.

If I was older I would have just tapped it up.

</comment><comment><USER20> We had a discussion on this topic a week ago: [https://news.ycombinator.com/item?id=11627213](https://news.ycombinator.com/item?id=11627213)

</comment><comment><USER21> The book "Black Box Thinking" by Matthew Syed has good insight on this issue, especially the differences between how the airline and medical industries handle errors.

</comment><comment><USER22> In many arguments about socializing medical care, the "fact" that the US has "the best medical care in the world" is cited as a reason to keep the status quo. instead it appears we are paying through the nose for a system that doesn't manage quality very well at all.

<comment><USER23> It's certainly debatable which countries get the best medical care for the dollar, or which countries distribute it to people in the most fair way, or make it most accessible to the poor. But I don't really think there's debate that the US gives the best medical care if money is no object. My understanding is that, with very few exceptions, the wealthy all over the world come to the US if they have a serious medical condition.

<comment><USER24> It is highly dubious that this is some feature of the expense of medical care in the US. For example, it's generally recommended that for surgery, you actually want to see a doctor who works in the public system (in Australia, my country) because for routine procedures the guy who does them everyday, all the time, is probably a lot better at it then the guy who can choose his cases.

The US has a _giant_ population with first-world levels of funding from the government - it's fairly likely that care quality is simply the intersection of population and experience. But you pay more from the government per person, and get less. Your system and outcomes should be _so much better_ and you all should be angry about that. It's just at some level of size and overall budget, you get a lot despite being inefficient.

<comment><USER25> > . For example, it's generally recommended that for surgery, you actually > want to see a doctor who works in the public system (in Australia, my > country) because for routine procedures the guy who does them everyday, all > the time, is probably a lot better at it then the guy who can choose his > cases.

While I agree that this is the case, the people who are willing to travel for medical care are likely not traveling for routine cases; they are going to see specialists for complex cases. The quality of care varies substantially across the US, and I do think the top tier facilities in the US are some of the best (if not the best) in the world. That says nothing about the average level of care across the country however, and it is typically difficult to get access to these premiere hospitals unless you know someone with connections in medicine or have money.

<comment><USER26> Be careful even in non-routine cases. The specialist in question may select his patients based on qualifiers that are in his interest. One of them is the likelihood of recovery - high likelihood improves their track record and thus their standing as a specialist.

<comment><USER25> This is fair point, but at a hospital-level in the US you do tend to see higher mortality levels at prestigious hospitals due to the increase in average case complexity. People are willing to take on the tougher cases.</comment></comment></comment></comment></comment></comment>


Stop Don't blindly take that coding challenge - <AUTHOR> https://dev.to/theobendixson/stop-dont-blindly-take-that-coding-challenge-1903 <comment><USER2> I charge 100$ an hour to do coding challenges. Recruiters guffaw when I tell them (of course they do), but I don't do the ol' jazz hands routine with the money makers for free. Really, the positions they're seeking to fill pay > 100k. What's a few hundred to a candidate if you really want them to demonstrate a skill? Pay that and I don't care if I'm actually closing a real ticket for you as part of the interview process.

Once I wavered on that for a data science position. They had me do some predictive analytics on a dataset. I've built a pipeline for problems like that so I figured I'd spend the 20 minutes spinning it up... I ended up spending an hour creating a rather detailed writeup about methods used and my analysis. The stake holder got back to me asking for changes to minor format things with my output data. (headings, serialization of booleans.. minor shit like that) I came to the cynical conclusion they were getting free data science work and the position was an illusion. I asked if that was the case and never got a response.

Learned my lesson I guess.

<comment><USER3> So how many potential employers have agreed to pay you the $100 an hour?

<comment><USER2> Quite a few. I've been a full time self employed consultant for 3 years now. Yes, I'm being cute -- but the distinction between customers and recruiters who trick me into answering the phone by spoofing my area code is irrelevant to where I draw my lines. I like the internal consistency in my handling of either situation.

</comment></comment></comment><comment><USER4> > Employers already have most of the power in this relationship

I feel like it's the exact opposite.

I once was at a team where a coworker left. He was one of two developers working on a subsystem. The subsystem was highly valued by the company because it would result in faster payments and less labor in processing payments. Even though they replaced him with another developer the project still took 1.75x longer to complete compared to the previous pace.

When a developer replaces a company they continue to pay the same green money. When a company replaces a developer it can take months or years to retrain him with institutional knowledge. The asymmetry gives developers more power in the relationship.

<comment><USER5> Employees may have more power than employers, but employers have more power than candidates.

<comment><USER4> Right, I was thinking about the wrong relationship.

</comment></comment></comment><comment><USER6> I am moving in this direction after having taken a few coding challenges and not heard anything back from the company. If I am going to spend time on a coding challenge, I am expecting at least an acknowledgment that I am no longer being considered for the position. Coding challenges are a time commitment and if a company can't even be bothered to commit to at least being polite about it, then it's a clear indication of how they view employees.

</comment><comment><USER7> We sometimes hire mid/jr-level FE developers, which means we get _lots_ of bootcamp applicants.

It feels like the main goal of the bootcamp is to produce portfolios/resumes that make you indistinguishable on paper from developers that learned any other way.

Not necessarily bad, but the quality difference among bootcamp grads (from the same program!) is crazy. Some people understand the fundamentals of what they learned and continue to learn and expand their skills, but some are just copy/pasting code and debugging by typing random character combinations until something works. Both got through the bootcamp with identical group-project portfolios and class assignment personal websites and resumes.

We've recently started sending an at-home coding challenge to all jr. FE applicants, just to cut down on amount of time wasted if we bring them in and they don't know anything. This has worked okay so far.

I'm generally very cognizant of wasting peoples time, so I don't want to do this as a general rule for more experienced candidates. But for junior/first- job candidates, I'm not sure it should be as offensive. Do any of y'all see a reasonable distinction here?

<comment><USER8> Is a bootcamp grad much different than a university grad?

While in school, I read blogs claiming that the majority of CS grads can't code. I got the hint this may be true in one of my 3rd-year classes where we had to work in groups of 2 or 3 over the course of the semester to write a program that was essentially like an alpha version of SimCity. At the last day of class, we had to present our work. Half the groups didn't complete the project, and one group only had a blank window with a Help button that presented a wall of text. Then, during my senior project, in my group of six, two of them admitted to not knowing how to code, with one of them saying they didn't even want to code, they just became a CS major because they heard CS majors have low unemployment and good salaries.

I've digressed a bit, but...

When I finished my degree, I didn't have a software engineering internship under my belt, so I made sure to list personal projects on my resume. I think the presence of projects done on my own time for my own enjoyment and learning was a key factor in landing my first job.

So no, I don't think there's anything offensive about rejecting a candidate if a bootcamp is all they have to show.

<comment><USER9> I've worked with people who have MBAs but aren't really developers or even devops types.

It's interesting to see them get frustrated so easily and have a hard time plowing through problem after problem making small changes until they finally get to something that works.

Someone who has only done a boot camp hasn't demonstrated that they can work on problems for weeks or months before they can see real progress.

Someone who has an actual degree from a legit university or college, has at least proven that they can spend months or even years working on something until they get their reward. They won't necessarily be able to program their way out of a wet paper bag, but they have at least one advantage on people who only have the boot camp certificate.

</comment></comment></comment><comment><USER10> TBH, for the positions I applied to, a coding challenge came _after_ a face- to-face interview. From what I later learned, I have been mostly given low- priority tasks built upon the actual codebase, but I was expecting that much at that point in the process (why bother spinning up a googol+1st blog implementation?).

</comment><comment><USER11> Having just been through the interview process, i ended up having to go through a few coding challenges. Luckily for me, i never got "ghosted" after sending one back.

The important thing to me is that the coding challenges have a reasonable scope. I really appreciated two of the companies that gave me an already set up project (it was not their actual codebase) and then required me to build an addition to it. That feels like an accurate way to test someone's skills.

As someone who doesnt excel at some of the "leetcode" interview questions as much. I have found challenges to be a welcome alternative when done right.

I did experience some companies who would give a project that was wayyy too complex and they estimated it would only take one hour. Those are the places i would reject without doing it. With the market as competitive as it is, you need to have some limits with these things.

</comment><comment><USER12> Agreed.

Also, why is no one willing to look at code I have already written?

<comment><USER13> As an interviewer, I try to ask a consistent question in a consistent way, so that I can calibrate my feedback against all of the people I've interviewed before. It's nice that you claim to have some previous code, but most of my candidates aren't able to share their code, and some hopefully small number of my candidates are going to submit someone else's code and claim it as their own. I have worked with and interviewed people that can discuss all the things, and run through other people's code as if it's their own, but are unable to write their own code.

That said, exceptional candidates are exceptions and maybe should be handled outside the normal process.

</comment></comment><comment><USER14> Asking to speak to an engineer isn't going to change much. If you really mean business insist they pay a nominal fee for your time. Not an hourly contract rate, more like the hourly salary rate of a mid-level dev. It's peanuts to them so if they won't pay they don't value your input so it's game over.

<comment><USER15> I agree, but it's probably no a thing the recruiter can do without going through the boss of the boss and hassle with accounting department. Until a big body of of candidates require it, nothing will happen, and if too many require it, the employer will probably just quit giving home work.

This concept of whiteboard interviews and assignments is quite alien to me. I've got three different software jobs since graduation and not one did any sorts of test they just trusted that I would not apply if I couldn't code. Never heard of any colleagues or former class mates that done any either.

</comment></comment><comment><USER16> sorry but this is as absurd as saying don't let line cutters into traffic. yes, "we" should band together to end the practice, but the fact that "everyone else" is going to do it means it will continue.

rather than address the call to action to candidates, how about asking folks to refuse to give a coding test?</comment>


"Don't worry about people stealing your ideas.  If your ideas are any good, you'll have to ram them down people's throats." (Howard Aiken) Is this true? - <AUTHOR>

<comment><USER2> I think it's more the vision than just the idea that matters. Superficially understanding an idea and really "getting it" is different. In the end you're protected from most people by their own lack of knowledge, skepticism, small thinking, etc.

The people who are smart enough to steal your idea, in a way that would be competitive, probably have their own ideas or would be willing to work together.

</comment><comment><USER3> If your idea is so obvious and easily understood that you have to worry about it being stolen, then you gotta wonder why someone hasn't already done it.

Also, talk is cheap. And ideas are just talk.

</comment><comment><USER4> While it might not be entirely true, it certainly gives you an attitude that affects your behavior for the better, especially at early stages. From my limited experience, talking about your ideas to both laypeople and technical people can only help you.

Talking to laypeople helps you solidify and lets you practice pitching what it is that you're doing. When you're working at a company, you don't have to explain yourself very much. But when you say you're doing a startup, I've found that most people will demand more of an explanation. However, most people don't have the patience in everyday settings to listen to more than 2 or 3 minutes of it. This helps you whittle out the core of what it is that you're trying to build. Call it a functional spec cleaning, if you want.

Talking about your ideas with technical people might give you insight into different areas you're not as familiar with. The more that I read, the more I realized everything is inter-related. But it's hard to have that kind of breadth in this day and age of specialization--there's just way too much to know. Talking to technical people will often times help you make connections and leads to other technical fields that will help you get a feel for where else you can dig or if you're digging in the right place.

That said, most people won't steal your ideas for the same reasons mentioned before by others. Doubts and eagerness to point out how it might not work. Lack of vision, breadth and depth to understand the problem and implications. Lack of technical ability. Lack of time. Lack of motivation.

And after reading and talking to people, it seems like ideas end up changing. It's only when you're a bit bigger that you'd have to worry about secrets.

</comment><comment><USER5> It's certainly true for my startup. I've been advertising my ideas for years, hoping someone else would do all the work, but in desperation I'm now building a company to produce the software I was hoping someone else would make.

Look at Google -- they tried to sell their algorithm so they could stay in school, but no one was interested, so they had to put up or shut up. If a bunch of people already thought your idea was a good idea, it'd effectively be a mature space.

<comment><USER6> '... if a bunch of people already thought your idea was a good idea, it'd effectively be a mature space. ...'

I'd modify that slightly...

'people already thought your idea was a good (MONEY SPINNER) idea , it'd effectively be a mature space. ...'

New ideas maybe easy to come up with but translation into a product is not easy. If you can see a new idea implemented & copy it you piggy back on the innovation of others thinking & implementing.

Compare for instance Flickr to say Zoomer. The later was developed post flickr & probably quicker. The point being Flickr came up with the wonderful clean url design, api design and concepts such as 'favourites'. It also showed there was a market. Zoomer copied lots of Flickr ideas without having to think, tinker & hack.

</comment></comment><comment><USER7> This entry asks a yes/no question, when there is no yes/no answer. If you read the TechCrunch comments on FreeBase, there are a couple of people who say they had the exact same idea -- one even reserved "ifreebase.com." The idea is definitely not new. Facebook wasn't entirely novel either. There are a lot of factors that can make a good idea unprofitable, or a so-so idea a big hit (who knew what AJAX was before it was called "AJAX"?). So, yes, your idea may be stolen if it's good. If your idea is obvious, there is a chance that people are just too lazy to implement it. The only way to win in either case, is to work damn hard on your idea until fruitition.

</comment><comment><USER8> I'm halfway through Founders at Work and the conclusion I am getting is an overwhelming yes. The chapter on Hotmail is pretty illuminating -- nobody else they talked to thought web-based e-mail was remotely a good idea.

</comment><comment><USER9> Almost everyone I meet(there are exceptions) is pessimistic of all my ideas. Which is lots of fun because you can tell they don't quite get the "whole thing" as you have in your mind no matter how well you explain to them.

Co-incidentally I wrote a post titled "Mere ideas have never been this useless" just earlier today. You can read it here: http://www.zaid360.com/?p=63

\--Zaid

</comment><comment><USER10> The best ideas are innovative and edgy. Any competitors will be behind the curve once they realize what you already know.

If your idea is good in a duh-obvious sense, then you can be damned sure someone else is already doing it or has done it. The way to succeed in this aspect is by doing it better where others have been lazy.

<comment><USER11> I think I've read it in one of PG's essays, who sais always choose the harder solution because you thought the easy one because you are being lazy?

</comment></comment><comment><USER12> Applying to YC is a bet that this statement is not true in general. Or that they invest in great teams with ideas that they do not fully appreciate.

</comment><comment><USER13> And yet not all ideas are good ones: http://www.advogato.org/person/apenwarr/diary.html?start=258

</comment><comment><USER14> ideas floating in air? true. ideas implemented in a prototype? untrue</comment>


Titles are Dangerous - <AUTHOR> http://techentrepreneurship.com/2011/02/07/start-up-titles-are-dangerous/

<comment><USER2> I am always fascinated by why people get so caught up in titles or no-titles. The reality is if it is a good team titles are not going to go to their head, they know it is just a title. Further titles help when dealing with third parties that are concerned with titles. I can't tell you how many times I have seen a consultant or a third party provider talk past the "tech guy" to the CEO because the "tech guy" does not have a title. Worse yet I have seen them undermine their authority, because they perceive them as having no power. I swear we do it to ourselves in this industry, when everybody has no title then the cool guys will all be giving themselves titles and titles will be all the rage. If you are the guy that calls the shots you are the CEO plain and simple, having that title simplifies things and brings clarity. If you run the technology you are the CTO again this is simple and brings clarity. It does not matter if you are two guys starting out or a 5000 person company, titles help simplify understanding. If someone is so pretentious that a title changes how they work, then you don't want them around, it does not matter if there title is CEO or secretary.</comment>


This is how an engineer feels when he's surrounded by idiots - <AUTHOR> http://www.cnet.com/news/this-is-how-an-engineer-feels-when-hes-surrounded-by-idiots/ <comment><USER2> I have been in a lot of meetings where business-types suggest all sorts of ideas. I used to get really frustrated and would take the easy way out, i.e. think to myself that these guys are clueless, why am I even in this business, and just go in a really shitty place mentally.

Then something changed. About the tens of sales books I read, a nugget from one of them struck me. The idea was to re-focus / re-frame any conversation to "what are the business objectives we are trying to achieve here?". Instead of having them propose solutions, have them dig deep into the problem and where they are trying to get as a final destination. An easy way to do this is look them in the eye, smile like John Wayne and say "I have seen this many times, it's not a problem, in fact, there are hundreds of ways we can slice this, let me ask you, what are the key business objectives here? How will we be measuring the success and failure of the project from a business point of view?" Then they really go into what their problem is, and where they are trying to go. The idea is to not propose any solutions on the spot (guess what, they don't like to hear your smarty-pants / clever solutions anyway), they would like 1) for you to play therapist in the meeting and hear every last problem, 2) come back to them at a later day and tell them that every one of their problems will be solved and the cost will be low, 3) be prepared to explain how it would work (keep high level and leave the clever bits out, but don't forget to address the impact on other resources like marketing / legal / etc.) and 4) present to them a timeline of execution mixed with approvals needed at each stage.

I have fucked up 100 times, and gotten it right about 3, thats how I know. Hope it helps some wise guy (like I was) out there.

<comment><USER3> This is great advice that took me quite a bit of time to learn as well.

Most of our meetings are held in a room with a whiteboard, and it has become standard to start by writing "GOAL: {{goal}}".

It prevents tangents, encourages us to use the scratching space so we can diagram the high-level components involved, and helps educate the folk who aren't up to speed (technical or business).

</comment></comment><comment><USER4> As far as I can tell everything requested can (theoretically) be done.

As many commenters noted in the original discussion ([https://news.ycombinator.com/item?id=7513182](https://news.ycombinator.com/item?id=7513182)) if you increase the number of dimensions you can increase the number of lines that can be perpendicular to one another. How a person would "draw" in such a space is merely a question of semantics.

You can certainly draw a kitten with a line. Just not a straight line. This definitely complicates the perpendicularity requirement, but I suppose that if every line is identical (they all draw kittens), then it can be done.

Finally, color is just a question of lighting. You can draw red lines with green ink. Just draw the lines in one color setting (where the ink is green) and display the lines to the client with different lighting where the lines are red. The fact that the lines must be drawn with red, green, and transparent ink complicates the lighting setup, but it can be done.

The inflation of the red balloon should be trivial but could be delegated to a less technical member of his staff if necessary.

I certainly don't envy him the task, but Anderson should quit with the excuses and get to it.

<comment><USER5> Lines, by definition, are straight. Otherwise it's a curve.

<comment><USER6> Lines also, by definition, have no beginning or end. They're defined by a simple equation like y = mx + b. Good luck drawing one of those with _any_ ink.

<comment><USER7> _" Good luck drawing one of those with any ink."_

No trouble, since they also have zero width...

</comment></comment></comment></comment><comment><USER8> "What exactly is stopping us from doing this?"

"...geometry."

I've had too many conversations like this, where I pause to think "where do I begin to fill the vast gaps of ignorance such that they will even begin to be properly equipped to understand the absurdity of their question?"

<comment><USER9> Just to add to your response, I think absurd questions are totally OK. It's a fact of a life that non-experts will need to talk to experts, and when that inevitably happens it's best if (a) the non-experts aren't scared of asking potentially absurd questions and (b) the experts can translate their thinking into non-expert language. Both (a) and (b) are necessary for great communication.

<comment><USER8> Generally speaking, I have no problem with absurd questions. Ask away. But if you're sitting on the other side of the table just waiting to hear what you want to hear, ignoring all else, and continuing to ask the same questions, then you're not doing your part on the "great communication" thing. That's my take on what the video is trying to get across. Too bad cnet editorialized the title, and incorrectly so, IMO.

</comment></comment></comment><comment><USER10> Junior sales will say yes to whatever the client says they want; Junior engineer will try to implement whatever the client says they want, say no if it's impossible.

Senior sales will try to figure out the real reason of a client's request, and sell them a solution that solves their real problem; Senior engineer will try to figure out the real reason of a client's request, and propose a solution that solves their real problem.

A sales person and an engineer may start from opposite directions, but really good ones think the same.

<comment><USER11> That really depends on your definition of "good" in this context. I've worked in more than one place where a "good" salesperson is one that brings in the most revenue, damn the torpedoes, feature creep, impossible requirements, etc.

Sales and engineering have fundamentally different objectives: Sales needs to generate revenue, engineering needs to create a project that satisfies a specification (ideally). There is very obviously overlap and hopefully interplay there, but I don't agree that people who are good at those largely disparate things necessarily think in any particular way, and certainly not the same way.

<comment><USER10> When the type of sales person you mentioned gets promoted and valued, it's a failure of management, and will eventually lead to failure of the business (it can take a long time for the damages to surface, however).

In most, if not all industries, reputation of a company matters a lot. That's how you get repeat and referral business, the lifeblood of a mature business.

</comment></comment></comment><comment><USER12> This was posted yesterday under a different URL and I penalized it. This time, I'm going to bury it as a dupe.

Because it is designed to elicit controversy (and views) rather than insight, it is not good material for HN.

We can have a discussion about communication between engineers and others. I'd have a lot to say about that myself. But priming everyone for indignation ("surrounded by idiots") is exactly the wrong way to start it.

Pandering to engineers who think they are "surrounded by idiots" is not seeking to get at the truth. It's an appeal to pre-existing opinion, i.e. prejudice. Worse, it's a sneaky way to promote tribalism while pretending to promote the opposite (tolerance). HN stands for the opposite of all these things.

(Side note: when I say "bury", I'm using a technical term from our code. It means applying a rank penalty, but leaving the item open rather than killing it, so anyone who wants to can continue the discussion.)

<comment><USER2> It's a common problem among external facing engineers. A source of great stress also. I think it is critical for engineers to discuss this topic and re-shape our view of working with the external world. We don't operate on an island and we cannot keep going for long with a condescending view of the business types without developing issues. Figuring out a mutually beneficial / acceptable operating procedure is key. The default is too negative and helps no one. With some skill, we can leverage our position, really solve big problems, and have a better working relationship. Just my 2 cents coming from b2b where my projects have 100% external impact (i.e. if we fuck up, they will have egg all over their faces - brings out the control freak in the business types).

<comment><USER12> Sure. That's why it should be discussed in the context of, say, a thoughtful article, rather than a baity video. If you'd care to post such an article, or an Ask HN, that would be much better.

Edit: None of what I said applies to your comment, though. How about this? Post it as an Ask HN with a good title. I'll put the link in my comment at the top of this page, we can ask rogerbinns and hurtmykneee to migrate their replies over, and have a substantive discussion.

<comment><USER2> Thanks for offering an alternative, Dan. Not sure if it's worth the hassle. I do appreciate your effort.

I would like to point out that the baity video is satirized commentary on many enterprise cultures. Though the presentation layer is light, the content is heavy; thus spawning discourse.

</comment></comment></comment></comment><comment><USER13> Original short story is in Russian and was written in 2011. [http://alex-aka- jj.livejournal.com/66984.html](http://alex-aka-jj.livejournal.com/66984.html)

Thought that you copyright lovers ought to know this.

</comment><comment><USER14> The moment the client's request is determined to be impossible, the only problem can be communication and the engineer's assumptions must be challenged. Instead of feeling that he is an "expert," he should try to understand what the client actually wants. Instead of asking questions to point out how the client's request is wrong, he could have asked questions about how to clarify the problem -- "what purpose do the red lines serve?" "why did you choose green ink?" etc.

<comment><USER15> But he asked "Can you describe, what the end result should look like?"

<comment><USER16> That's actually completely different though.

I'm always trying to get my internal stakeholders to NOT describe what they think the end result should look like, but to describe WHY they want it, what they want to accomplish, and let me help figure out what the end result should look like to accomplish that.

I'm not saying it's easy.

</comment></comment></comment><comment><USER17> Not necessarily idiots. Just those who don't know what they don't know. Knowing what you don't know (and therefore not overstepping one's bounds when making judgements) is an important thing.

<comment><USER18> I think the point is not so much about the fact that they do not have a firm understanding of the field, but that they are just blatantly ignoring the viewpoint of the Expert, who is supposed to be the authority with regards to feasibility.

</comment></comment><comment><USER17> It also reminds me this: [http://dilbert.com/strips/comic/1995-11-17/](http://dilbert.com/strips/comic/1995-11-17/)

</comment><comment><USER19> I'm pretty sure most of the other comments are pointing to what I'm going to say too, but I have to put this out of my mind.

This video, while hilarious, puts the 'expert' not in a good light. It is in fact true that the 'customer' is talking completely nonsense, but it's not her fault. Most time you'll be dealing with something which 1) has been put there or 2) has a focus on something else and you're are the only 'tool' to accomplish her goal.

The question is: what's __our __goal? Engineering for the engineering's sake? This is a goal that IMHO __must be present __in every engineer, this makes us mutate from tools to artists (personally I think that if something happens for its own sake, then that's art) But this must (IMHO) not be the only one. What we really need as a goal is something anthropocentric: make someone else happy (happier).

The real problem here is not in the customer, but in the 'expert'. If you really want to have that 'expert hat' what you really need to do is __understand __the very person you have in front, and her needs. Only then you can start talking about 'technologies'.

The problem with this video is that the customer is asking for something __to be done __, and the 'expert /sales-men' team responds with "hows", this moves the conversation in the wrong direction.

\- "We need you [...] to draw 7 perpendicular lines" \- "Could you please explain better what was the process that brought you here?"

If the sales-man stops you because this kind of questions is 'out of scope' of the meeting, ask him out, and destroy him to the very last piece of him: he must let you do your job (understand the customer's needs and take them from want-space to real-space), his job is ensuring that from a sales and customer relation point of view you're not ruining your own company strategic plans. Is he also the project manager? Then try to make him reason. He doesn't? Quit. Now.

wooosh. I had to say it. sorry.

<comment><USER11> This is really, really idealistic. Most people _do not_ have the flexibility to just up and quit, and most people in this situation _do not_ have the influence to "destroy" a salesperson without getting fired or at least censured.

It sounds like either you've never been in a situation like this or you should back up a bit and take it in at a higher level; you're missing the forest for the trees. You're assuming the client contact you have even _knows_ "the process that brought [them] here," which they often don't, and that they are going to be interested in discussing it with you, which they often aren't, among other things.

This conversation is also more often, in my experience, one step removed: Rarely have I seen this actually happen with a technical implementation person in the room. More typically it's a salesperson and a project manager, and you just get marching orders after the fact, which may or may not make sense depending on the PM's ability and willingness to make sense of the client's requirements.

</comment></comment><comment><USER20> Extensive discussion: [https://news.ycombinator.com/item?id=7513182](https://news.ycombinator.com/item?id=7513182)

</comment><comment><USER21> "That's a triangle."

Shut up, you fool, _it 's what the client's asking for._ Get them to add a few more lines and then order coffee.

</comment><comment><USER22> I had a version of this happen to me at my first job a few months out of school. I was supposed to write code to read IMU data from a flying sensor. The sensor was giving me a stream of pitch, roll, and yaw numbers, and I had to use this information to convert sensor measurements into absolute coordinates in lat, lon, and altitude. As is so often the case, there was no documentation on the data format coming from the IMU unit. I had no idea whether the numbers were in radians, degrees, gradians, or some other weird format. I also didn't know what order the pitch, roll, and yaw transformations should be applied in.

So in a team meeting I asked about the transformation order. Now, pitch, roll, and yaw transformations are not commutative. For the small angles that you're likely to see in typical flight, they're _almost_ commutative, but of course we were trying to do better than "almost". But when I asked about the transformation order, someone answered that it didn't matter. These were actually some technical people who answered, so it wasn't even management talking ignorantly. I politely said that it's a mathematical fact that order does matter when applying pitch, roll, and yaw transformations. The guy responds, "Oh no, the IMU measurements represent a snapshot in time." I responded that in that case, the numbers carry with them an implied transformation order, and that I need to know what it is in order to write my software correctly. "No, I'm pretty sure it doesn't matter," he said. Now I'm getting desperate, so I bust out with the hand demonstrations. "Start here, pitch up 90 degrees, then yaw right 90 degrees. Now compare that to yaw right 90 degrees, then pitch up 90 degrees. See? We started from the same orientation, but we get different results." These guys weren't having any of it. They insisted that it didn't matter, so I dropped the issue. Later I brought it up again at another meeting and a PhD who wasn't in the first meeting says, "Oh, I know what you're talking about." Ahhhh, finally, vindication.

That didn't even help me all that much though, because nobody seemed to have information about the actual ordering. I think in the end I had to reverse engineer it by brute forcing every possible combination of units and orderings until I found one that made the data look right. And oh by the way, the units weren't in degrees, radians, OR gradians. They were in units of semicircles, where 1 = 180 degrees.

</comment><comment><USER23> On the other side of the coin, I am not really an engineer and have worked mostly in project management or marketing, working with engineers. And I have to say, this type of thought is why everyone tended to avoid dealing with engineers as much as possible.

There is quite often this mindset of superiority amongst the engineering community and it only serves to isolate them further. Engineers aren't all knowing, and everyone else aren't brainless morons. While engineers might know engineering, the marketers know marketing, the salesman know sales, the financiers know financing and so on. It takes great collaboration among everyone to make a truly great product and to have it really make an impact.

So, please, if you can, avoid this "surrounded by idiots" type of thinking. Everyone is working towards a common goal, and the sooner we realize that we aren't better than anyone else, the sooner we can achieve our goals.

</comment><comment><USER24> As an engineer i tire of engineer worship. Any engineer not too full off themselves should finish the video with too conclusions perhaps unintuitive to much of the HN mass:

1\. I could actually fulfil the letter of the request provided I can use 2 red lines, 2 green lines and 2 transparent lines. Or I could modify the request slightly in various ways to also provide much of the requirements.

2\. damn if it was not for the stupid sales people I probably would not have even thought of these solutions.

Non-techs are there to force you to think outside of your own damn box. Too many engineers assume that people talking to them should understand why something wont work, before they take the time to see how it could work differently then even they would have initially thought. Even fewer have the wits to give credit to the collaborative process that brings these less that intuitive solutions to light.

Go find and read the circa 1700 essay [https://en.wikipedia.org/wiki/Heinrich_von_Kleist#On_the_Gra...](https://en.wikipedia.org/wiki/Heinrich_von_Kleist#On_the_Gradual_Production_of_Thoughts_Whilst_Speaking)

</comment><comment><USER25> This reminds me of trying to explain how left handed scissors function.

Give 'em a piece of paper with a straight line down the middle and a pair of right handed scissors, then instruct them to cut accurately along the line using their left hand. Afterwards ask them why they are holding the scissors on the right hand side of their body.

</comment><comment><USER26> 7 parallel lines can be achieved by creating an 8-dimensional Riemann space (R8) and then drawing in it. The bill for the particle accelerator to do so is on the order of $1,250B. We'll just assume that you're OK with this and add that to the project budget -- invisible Red and Blue ink, easy. Phosphor dyed UV ink. No problem. It will perfectly meet your specification.

If you want the visualization and detailed description of the solution, we can engage Rand Corp for a nice slick to show you how this will work. It'll be about 1250 pages, and we can add this to the budget for a little over $400M.

\--

If there's any lesson to take from this... When confronted by people who don't understand the scope of the problem -- don't communicate the problems OF the problem. Communicate the actual scope of the solution. It will tend to focus the dicscussion rather rapidly.

</comment><comment><USER27> This seems like self-serving drivel. Engineers are not Gods and non-engineers are not single-digit-IQ morons.

The tasks set is of course impossible by definition - which is not the case in the real world where most projects are doomed by human factors, lack of trust and will rarely if ever be rescued by one guy standing up and saying "No you are all wrong now listen to me and I will tell you why this cannot happen".

Humans work emotionally and love stories - if we want to succeed and still fulfill out inner Maker then instead of No you can't do it, please try "Instead of red lines why don't we sell pencils to enable our customers to draw their own lines. What's the best ad campaign we can imagine for a pencil case aimed at the blue collar market?"

Everyone else is not an idiot, is probably the best and most useful thing to take away from this.

<comment><USER28> While a little of this clip suggest idiocy - The per... per... dick... dick...

This video is actually more about the human factors in communication. The "you do know what translucent means" is an example of speech that is VERY absolute and inflammatory. The sales and PM are very agreeable to the client and distrusting of the engineer - very often putting the burden of his "being the expert" against him in the conversation.

</comment></comment><comment><USER29> I idenitified so strongly with that video that I had to check for hidden cameras.

</comment><comment><USER30> Videos like this make me feel so much better because: (a) I know that I'm not alone in my frustrations (b) I realize that things could be much worse, and I should consider myself lucky they're not.

</comment><comment><USER31> This may appear spammy, but I found Kepner Trego training[1] to really help prevent this kind of stuff from happening. The strategy is more effective when everybody in the room has had the training, which limits its usefulness with external clients, but I'll still recommend it anyway.

1\. [http://www.kepner- tregoe.com/pdfs/pubworkbro/psdmbroch06-07....](http://www.kepner- tregoe.com/pdfs/pubworkbro/psdmbroch06-07.pdf)

</comment><comment><USER32> Granted, the video was funny because it rang true.

I've also been in meetings where the expert was wrong.

Still, I suspect it's not just engineers. The same thing can happen to any expert in a subject where things can be true or false. For instance, it could be a legal or financial expert being asked to approve something that's illegal.

</comment><comment><USER33> This reminds me of how software engineers have a tendency to see their viewpoint as the only correct viewpoint.

Source: Veteran software engineer.

</comment><comment><USER34> Idiots is pretty harsh. They could just be focused on other things and not know the right words to communicate what they want.

<comment><USER35> Yea, that's fair. They could want something impossible, or they could want something possible but are describing it so imprecisely that what they end up asking for is impossible. They may not be able to tell the difference between the possible and the impossible, the tech guy can help there.

</comment></comment><comment><USER36> It's helpful to remember that the role of idiot might be swapped depending on the topic.

<comment> mkr-hn As a writer, I get to watch engineers humble themselves in advice forums when they need to write something important. It reminds me that even the mortal deities of our little civilization have shortcomings.

</comment></comment><comment><USER37> I have never worked with business people who were this stupid.

</comment><comment><USER38> This hits far too close to home...

</comment><comment><USER39> or just draw the lines on a globe (like longitudinal ones). and use infrared ink

</comment><comment><USER40> the solution is to idiotized the engineer!

<comment><USER41> ... My brain is now trying to combined the songs "London Bridge Is Falling Down" and "Ring Around The Rosy".

</comment></comment><comment><USER42> I think that as a metaphor, this video somewhat describes what it's like to work with somebody who is far beneath your expertise level in the same field. The obvious bikeshedding aside ("It's just 7 lines, anyone can draw that Anderson, you're an EXPERT"), working with people who haven't had the same exposure or experience to problems within your domain before might make you feel the same way Anderson's character did when he tried to explain why the task was not (in the most direct sense) possible.

I assume this probably goes both ways. In the eyes of an expert, they'll probably have difficulties or at the very least get frustrated that people are making judgment calls when they're obviously wrong. On the other end, non- experts might actually feel frustrated feeling that the expert doesn't know what they're talking about, when task X is so obviously a possibility and they're just viewing the world inside their own tiny box. From both sides, they lack/forget/have lost the context to see the other sides' perspective. It's not so much that haughty managers and salespeople are too quick to say 'yes' all the time, but rather that what's obvious to you is clearly not 'obvious' or may not even register within their perception of the world. Ultimately, the root cause of the problem here is that there are unspoken assumptions, and neither party is willing to communicate what those are.

Take for example, the assumption that "you're an expert." In reality, you may be the best in your field, or at the very least you might be well-versed in it, but an expert in astrophysics isn't going to fare well in a discussion about civil engineering. In the same way, there are people who make the assumption that there is no distinction between engineers, and that electrical engineers are the same as geomatics engineers are the same as chemical engineers. While the specific field of engineering may be different, small assumptions that go un-communicated like this are how these sorts of problems start.

That said, even communicating these assumptions to others may not solve the problem. In my own experience, I've had problems getting team members up to speed, if only because there's no hard and fast way to do so. As an example, when working on a Javascript project with a partner once, my team member kept complaining that they didn't "get" how to write code in Javascript, despite having gone through the same education (same degree/program) that I did. Certainly I had more experience with the language than they had, but I was confused as to why they would find the language hard. To give some context as to why I couldn't understand why my team member was suffering, we take courses in programming with C++ / MATLAB in our first few years within our degree. Furthermore, I had sent multiple links to courses such as CodeAcademy, and many others, which I had assumed would have given my partner the information necessary to transfer their skills to the constructs of the new language.

Unfortunately, it didn't work out as I had expected. They continued to struggle with Javascript, for reasons beyond my understanding. The intent to learn was there, but for some reason there was no way to explain the language in a commutable way to them. And here's where I noticed the problem of being an "expert" who's "surrounded by idiots": I couldn't get figure out why someone who had the same basic training/purported skills as me couldn't manage something as simple as learning a new programming language. At the end of the day, there was definitely a communication barrier, but the "unspoken assumptions" I spoke of before didn't even help alleviate that once they were revealed. I guess in this case, once I had set that barrier, it wasn't coming undone. The attitude that "this is too hard" or "I can't do this" had already set in, so there was little left I could do about it. Even attempting to help teach after the fact was only met with disdain and harsh attitudes.

If anyone else has some tips for dealing with this sort of behaviour / attitude / whatever in the workplace, I'd love to hear them. Too often am I approached by a colleague who tries to convince me of the impossibility (or possibility, in the case of the video) of some task that is not such. What do you do when you're the expert and you can't get people to work up to the level you're on, and what do you do when you're the non-expert and feel like the level you need to work up to is impossible?

</comment><comment><USER43> I was thinking god this video is boring, talking about colors and lines, how is relevant to tech, then the monstrosity of it all hits me, this is what I've been doing many many times.</comment>


Taleb Is Wrong: Killing Millions Is Risky - <AUTHOR> http://curi.us/2242-taleb-is-wrong-killing-millions-actually-is-risky <comment><USER2> Basics we've had for generations--like tractors, and the haber process--have made food production so easy that the biggest problem in agriculture isn't fragile crops, but how to keep the farmers from bankrupting themselves through overproduction.

We have "solved" this problem through things like protectionism, quotas, subsidies, and dumping any remaining surplus on the developing world--thus destroying their own local farm economies.

The Guardian article he links to is an obvious astroturf. Long before GMOs, Americans had no problem feeding themselves. To this day, the Amish manage to do the same, and most do so without GMOs, tractors, pesticides, etc, etc. To pin malnutrition in the developing world on GMO restrictions is bogus, and the title is the sleaziest thing I have ever seen on this site.

edit: And whatever you think of Taleb, the man is a friggin' hero for standing up to Monsanto.</comment>


Why Is the Federal Government Afraid of Fat? - <AUTHOR> http://www.nytimes.com/2015/07/09/opinion/why-is-the-federal-government-afraid-of-fat.html <comment><USER2> Because _they can 't change their recommendations without admitting they were wrong_, and governments generally _can 't do that_. Or, at least, the speed with which they can change their recommendations is sharply bounded by ensuring they never quite have to admit fault. Admitting you were wrong is basically begging to have your funding cut, your reputation trashed, your influence removed, your job cut. The closest thing a government can do to admitting being wrong is if they can say a _previous_ government was wrong, but now we're right. But for these administrative posts there's never a clear turnover for that to occur.

Public policy adds the additional problem that if they admit they were wrong about what was possibly the single clearest message the government has sent the US public in the last 50 years, "Fat is bad for you!", the public will very likely and entirely rationally start asking very pointy questions about how such _volume_ could be combined with such error, and what else being communicated with such volume and confidence today may also be wrong.

The government has a ton of moral capital tied up in fat being bad for you, so it _has_ to be bad for you. It _has_ to be bad. _It just has to_.

As an individual, you may find it profitable to consider whether this is the sort of incentive structure that produces an authority you want to bet your life on. Considering whether there are similar issues where the government may have gotten stuck on a particular answer and now can not change its mind pretty much regardless of what facts come in left as an exercise for the reader.

<comment><USER3> The 3 hardest words to string together: _I was wrong_

(see also: the War on Drugs)

<comment><USER4> (see also: Extreme Global Warming predictions)

</comment></comment></comment><comment><USER5> A large part of the issue is that in the traditional American diet, a significant portion of fat intake is in the form of saturated fat. There is a decent amount of research showing saturated fat has inflammatory effects in the body and directly causes insulin resistance. For a long time doctors have had success encouraging patients to eat diets excluding America's primary sources of saturated fat (red meat, bacon/lard and butter).

In addition, dietary fat intake does influence triglycerides, LDL and VLDL; fairly good correlations exist between these levels and heart disease. It is only recently we have discovered that sub-types of these particles exist, and not all of them have the same impact on health. Additionally, the knowledge that excess carbohydrate intake can actually have a larger impact on these levels is somewhat more recent.

The bias against mono- and poly- unsaturated fats given all the research that exists on their beneficial health effects is still bat-shit crazy, though.

<comment><USER6> That is curious, considering our rates of heart disease and diabetes were a fraction of what they were today when people ate more saturated fats (e.g butter). And when switching to a diet where saturated fat is the primary energy source, people tend to lose weight and see an increase in insulin sensitivity.

<comment><USER7> Off-topic, but every time I see the phrase "a fraction of what it was" I get a bit miffed. 99/100 is a fraction. 101/100 is a fraction. Every thing that gets measured in time intervals is always going to be a fraction of what it was before, bigger or smaller.

<comment><USER8> "A fraction of what it was" is a common idiom, which uses fraction in the ordinary sense.

"Fraction" is related to words like "fracture" and "fragment". When you fraction something into pieces, they are always smaller than the whole (barring strange spatial partitionings: Banach-Tarski paradox and all that).

Maybe you were playing hooky in grade 3 when the teacher explained that 101/100 is an _improper_ fraction, which can be rewritten as 1 1/100: the whole number 1, combined with a proper fraction. See? "Improper!" Mathematics recognizes a special status for fractions where the numerator has greater magnitude.

Also, ever heard of the "integral" and "fractional" parts of a floating-point number? See the ISO C99 function modf, for instance.

<comment><USER7> An improper comment is still a comment. An improper fraction is still a fraction. What exactly is your point? I'm not sure why you felt the need to be snarky.

</comment></comment></comment></comment></comment><comment><USER9> >Based on years of low-fat messaging, most Americans still actively avoid dietary fat, while eating far too much refined carbohydrates.

This is the crux of the problem; years of social programming is hard to reverse. Try to explain to someone that fat is good and carbs are bad. It shouldn't be hard to convince someone, but even the basic premise is tantamount to heresy to most Americans. Fat gives you clogged arteries! Fat makes you fat!

Carbs and sugar are the American Way™.

</comment><comment><USER10> Because whenever they set dietary guidelines last the common way of thinking was that "fat is bad" and since it's the government progress is ridiculously slow and also because resetting dietary guidelines is probably way down on the list of "Things that we should really fund this year"?

I've seen comments here and elsewhere pop up across the entire internet in response to this article saying that obviously it's a government conspiracy and a lobbying issue and they're all trying to keep us fat and stupid but that's some serious tin foil hat lines of thinking.

Also: _But rather than focusing on total fat or other numbers on the back of the package, the emphasis should be on eating more minimally processed fruits, nuts, vegetables, beans, fish, yogurt, vegetable oils and whole grains in place of refined grains, white potatoes, added sugars and processed meats._

Which seems to be saying "hey, if you don't eat processed stuff and instead eat more whole foods from a variety of sources and strive for lots of variety in your diet then you're probably going to be healthier and less likely to gain a bunch of weight" which seems to be pretty ridiculously obvious nutrition science.

</comment><comment><USER11> We know shockingly little about nutrition, but this paper is a great summary of what we do know from both association studies and randomized trials: [http://circ.ahajournals.org/content/123/24/2870.full](http://circ.ahajournals.org/content/123/24/2870.full)

In particular, table 2 summarizes what we know about each type of food (sodium, saturated fat, trans fat, carbs, sugar, ...) and what type of study we know it from (e.g., randomized trial or association study?): [http://circ.ahajournals.org/content/123/24/2870/T2.expansion...](http://circ.ahajournals.org/content/123/24/2870/T2.expansion.html))

The best type of evidence you could have is a randomized trial of clinical end points--divide people randomly into (say) low fat and low carb diets, run the study for a few years, and measure what percentage of people have a heart attack. That's column 4, and it's nearly empty. The only things we seem to know are that total fat seems to be neutral, and substituting polyunsaturated fat for saturated fat reduces heart attacks.

In the absence of that gold standard evidence, we're relying on weaker but more convenient types of study designs -- randomized trials that measure surrogate metrics (e.g., blood cholesterol and blood pressure), or various types of association studies.

As of now, those seem to be telling us that alcohol, dietary fiber, and unsaturated fats help our risk factors for a heart attack, and trans fats, sodium, carbs, and cholesterol make our risk factors worse. But those conclusions can easily change since they're based on a surrogate, and indeed, we've already seen the recommendation against eating cholesterol reversed: [http://well.blogs.nytimes.com/2015/02/19/nutrition-panel- cal...](http://well.blogs.nytimes.com/2015/02/19/nutrition-panel-calls-for- less-sugar-and-eases-cholesterol-and-fat-restrictions/)

</comment><comment> saiya-jin one thing i don't get with all these sways of opinions... everybody is so obsessed with what they eat and how much, nitpicking contents of this and that, instead of trying to match their intake with amount if activity per day. I know it's hard, i know you have to produce that nasty thing called sweat to actually achieve anything, but for christ sake... just do some activities! ideally daily, with some variability. But even half an hour early morning run every day will make huge difference in life.

it will make your life longer, and more interesting in the process, in practically every aspect (yes, including sex). We are all unique, so find whatever makes you sweat and feels like fun & challenge. Heck, after not consuming processed sugars for few weeks, eating something with them is rather disgusting experience, same goes for overly fatty foods. Taste for anything natural improves HUGELY.

of course, ideal scenario is good food + healthy activities. but the more you do work out, the less importance there is on quality of food to make you stay & feel healthy (this one is more complex topic, so let's say keep eating healthy).

what i would propose is similar to tobacco treatment - anything clearly unhealthy, add a tax that will go directly to health system treating all those heart attacks, diabetes and other conditions that people bring upon themselves by being weak and/or stupid. i know it's not that simple, but at least that's a move into some direction...

<comment><USER12> > add a tax that will go directly to health system treating all those

Maybe I'm being a bit cynical, but I'm not sure we have any tax that that goes directly into any direct remedial use for any type of issue.

I can't think of one, anyway. If tobacco tax does, then color me impressed (and surprised).

</comment></comment><comment><USER13> Fat is calorie dense. There's ~380 calories per 100g of sugar but _880_ calories per 100g of olive oil.

70% of the US population is overweight. Being overweight is bad for you.

If your diet contains a lot of fat, you're consuming more calories than if you substituted the fat with something else (e.g. by avoiding deep fried foods, and eating leaner meat).

If you are not overweight, then feel free to eat as much fat as you like, but know you are unusual.

<comment><USER14> Fatty foods are often more satiating than carbs, meaning you eat less overall.

All things being equal calorie-wise fat is better for weight loss than carbs are.

<comment><USER15> This is simply not true. You are oversimplifying the issue. As an example, I'd like you to go take a shot of olive oil and tell me you feel fuller than having a cup of steel cut oatmeal with a cup of blueberries. In fact, in 1 shot of olive oil, that's 3 tbsp, which is roughly 360 calories, whereas the oatmeal and berries clocks in around 250 calories. "All things being equal", I just put fat against carbs and the oatmeal just won because 3 tbsp of olive oil will not satiate the way 2 cups of carbs will.

<comment><USER16> The experiments that measure satiety generally have the subjects eat a measured amount of a certain food, wait a specified period of time, then eat from a buffet wherein subjects may eat pre-measured portions of whatever they like.

In such experiments, certain foods do have a significant impact upon the calories later consumed from that buffet. Some foods are more filling than others. I forget the exact results, other than the one that was surprising to me: whole boiled potatoes were the grand champion of fullness, and 3 times as filling as a calorie-equivalent portion of french fries.

So do your experiment for real, with some volunteers. You will need to make some oatmeal, and pour some oil shots, and have a buffet ready. And you will have to continue the experiment for multiple days, so you can get same-person comparisons for different foods.

Please actually do the experiment before you declare your hypothesis confirmed. For what it's worth, I think it probably would be, _but there is always the possibility that we will be surprised by the results_.

Naturally, to avoid accusations that your experiment cherry-picked specific foods that are not representative of their fat/carb classes, you would also have to test other foods, like coconut oil, glazed doughnuts, rendered beef suet, dry white toast, butter, and bananas.

But wait. That's still oversimplifying the issue. Boiled white potatoes are three times as filling as plain white bread. If some carbs are more filling than other carbs, how can you meaningfully compare all carbs against all fats?

I guess you can't. The experiment would have to serve isolated food components. Rather than olive oil, serve a shot of caprylic acid, or stearic acid, or DHA. Rather than oatmeal, serve pure starch, or pure glucose syrup, or fructose. Maybe also test the effects of added MSG, aspartame, or table salt.

 _Everyone_ is oversimplifying the issue.

</comment></comment></comment></comment><comment><USER17> Because fat has 9 calories / gram, carbohydrates have 5 and water has zero. So while a tint of olive oil in your salad might have some theoretical health benefits if you are skinny, replacing those deep fried chips with baked chips has immediate benefits if you are overweight - you will probably eat the same quantity anyway but half the calories.

Fat makes you fat without a proportional decrease in your appetite, it's as simple as that.

<comment><USER18> Right, because carbs do wonders for satiety and fat doesn't do anything...

</comment></comment><comment><USER19> The article talks about some dietary ideas that turned out to be wrong while at the same time saying stuff like "... the emphasis should be on eating more minimally processed fruits, nuts, vegetables, beans, fish, yogurt, vegetable oils and whole grains in place of refined grains, white potatoes, added sugars and processed meats.".

A wrong thing in no way makes other stuff right.

</comment><comment><USER20> The federal government isn't afraid of fat, but carbs, most extensively from corn and corn syrup, are a huge industry in the US, and the agriculture industry is a massive lobby. Politicians aren't going to tell you to eat fats not sugars when your sugar addiction is keeping them in office.

[http://www.theguardian.com/business/2012/jun/11/why-our- food...](http://www.theguardian.com/business/2012/jun/11/why-our-food-is- making-us-fat)

<comment><USER21> This doesn't make sense. Corn is used much more heavily as feed stock for animals than as a sweetener or dietary carb for humans. Corn growers thus have more invested in encouraging high-fat diets than low-fat diets.

About 4.2 billion bushels of U.S. corn per year are used to feed livestock (dairy, beef, hogs, poultry). About 1.4 billion bushels go toward uses including sweeteners like HFCS, as well as toward cereals (and booze).

This per: [https://en.wikipedia.org/wiki/Corn_production_in_the_United_...](https://en.wikipedia.org/wiki/Corn_production_in_the_United_States#Production)

</comment></comment><comment><USER22> Heh. I switched to a high fat, moderate protein, almost zero carbohydrate diet back in April and lost 40 lbs so far.

<comment><USER23> And yet when I say that the government doesn't like fat because it makes people healthy (less dependent on the government) and faster thinkers (less likely to blindly trust the government) people downvote me.

Impact of obesity on the brain, memory and intelligence:

[https://www.sciencenews.org/article/obesity-messes- brain](https://www.sciencenews.org/article/obesity-messes-brain)

"Obesity has been associated with a reduced total brain volume and diminished gray matter density."

[http://www.mpg.de/4280661/obesity_brain_structure](http://www.mpg.de/4280661/obesity_brain_structure)

"But as scientists are learning more about the critical role white matter plays in cognition, new research suggests that obesity may target white matter integrity, leading to a decline in human cognitive performance."

[http://www.dana.org/News/Obesity_Linked_to_Changes_in_Brain_...](http://www.dana.org/News/Obesity_Linked_to_Changes_in_Brain_s_White_Matter_Structure%E2%80%94and_Cognition/#sthash.nYWxFdXP.dpuf)

EDIT: downvoting is one way to cope with cognitive dissonance but it does not help motivate those that are trying to lose weight.

<comment><USER22> It's no secret that there are a lot of terrible people on HN with over 500 karma, but usually it doesn't help to complain about them. You just give them a chance to downvote you again.

</comment></comment></comment><comment><USER15> We don't know much about our bodies. I feel like every time a major news publication publishes an op-ed or a study, they're contradicting themselves[1]. One week eggs are bad, the next they're good. Same with dairy, carbs, and red meat. Then you mix in the whole "diet" complexity: Atkins? Paleo? Keto? Vegan? How do I choose?

When you study the longest-living peoples of the world, you also find extremely varied diets: the carbohydrate-rich Greeks rely heavily on fruits, veggies and whole grains. They also love goat's milk and wine. While natives of costa rica are primarily relying on "evil" white rice and beans, and heavy on pork and chicken. The people of Japan are also heavy on white rice, and virtually no fat in their diet, since their diet is primarily plant-based[2].

The truth is that everyone's needs are different. As an anecdotal example, I was convinced that keto was the right way, and that carbohydrates were not going to help me. Did I lose fat? Yes. Did I feel great? Sure. It turns out that even with great HDL and Triglycerides, my LDL and fasting glucose were still high. And I'm not alone in this problem from keto either [3].

After switching to a broader, less-restrictive diet, which now includes whole grains (quinoa, oatmeal, and wild rice), beans, and fermented vegetables (kimchi, sauerkraut), lots of fruits and vegetables (including starchy carbs like sweet potatoes and squash), I've lowered my LDL and fasting glucose (yes, now that carbs are back in my diet). Different things work for different people because everyone has a different metabolism. It seems that, if you study the longest-living people, the trends are as follows:

* Don't overeat.

* Eat mostly plant-based, whole or minimally-processed/refined foods.

* Leave 10-20% of your diet for indulgences. Virtually all of the longest-living peoples drink alcohol or coffee on the regular. And even then, by allowing yourself that affordance, you don't risk binge eating or rebounding for days/weeks/months on end.

* Ignore fad diets. Stick with the whole foods that you like to eat, get in some variety, but don't be dogmatic about dietary approaches, because not only will you likely not adhere to such restrictions, but you'll probably find yourself being contradicted by another study in the next 3-10 years.

[1] [http://www.nytimes.com/2014/02/09/opinion/sunday/why- nutriti...](http://www.nytimes.com/2014/02/09/opinion/sunday/why-nutrition-is- so-confusing.html)

[2] [http://www.nsca.com/uploadedfiles/nsca/inactive_content/prog...](http://www.nsca.com/uploadedfiles/nsca/inactive_content/program_books/ptc_2013_program_book/aragon.pdf)

[3] [https://www.google.com/webhp?#safe=off&q=keto+fasting+glucos...](https://www.google.com/webhp?#safe=off&q=keto+fasting+glucose)

<comment><USER24> When I visit Greece, I find it very surprising how little my relatives eat per meal.

I think at the end of the day, we're just going to find that calorie in, calorie out is what's really going on here. Sure, heavy eaters binge on carbs or fats or whatever, but that's not the root problem here. Its our portions and snacking culture that might be the real culprits.

</comment></comment><comment><USER25> Armchair dieticians in post an this thread. Not all carbs or fats are the same. Good ones of both are part of a healthy diet. But hey, making it simply black and white is appealing for the uneducated masses.

<comment><USER26> From the article: "Dariush Mozaffarian is dean of the Friedman School of Nutrition Science and Policy at Tufts University. David S. Ludwig is the director of the Obesity Prevention Center at Boston Children's Hospital and the author of the forthcoming book "Always Hungry? Conquer Cravings, Retrain Your Fat Cells, and Lose Weight Permanently.""

Armchair dieticians?

</comment></comment><comment><USER23> Because fat is good for the brain and for the body (it makes you slim and a fast thinker) whereas carbs are the opposite - obese people have 8% less brain tissue.

The government wants dumb unhealthy people that depend on it so it can perpetuate its existence.</comment>


My post got to the front page of Digg yesterday, here's how much money I made - <AUTHOR> http://www.geek-juice.net/2010/07/my-post-got-to-front-page-of-digg.html

<comment><USER2> I think the best way to make money blogging NOW is to get a lot of readers and become an expert around a specific topic. Then go around and get paid for speaking engagements.</comment>


H-1B Restrictions Driving Company Outsourcing, Offshoring - <AUTHOR> https://insights.dice.com/2019/10/07/h-1b-restrictions-outsourcing-offshoring/ <comment><USER2> There is a bill called s386 recently caught some attention and eyeballs.

The data says, 75% H1B visas all went to one country, India, while a larger country like China, took a normal percentage 9% over the years.

Reason? India's outsourcing companies made quite a lot frauds and while they moved some of their offices to USA, they still hired mostly Indias by H1B visa, from outsourcing to insourcing, the employees are the same: those from India.

As an IT guy for years the problem I saw is that, India manager is notoriously nepotism, mean they prefer hiring Indians _greatly_ to other races, it's not uncommon after an Indian becomes a manager, in a short period of time, all his/her team will be full of Indians. This is scary and unhealthy, and Americans has been turned on their blind eyes for this abuse for years.</comment>


How do you learn new, unfamiliar code base? - <AUTHOR> What is your thought process? Which questions you ask yourself? <comment><USER2> In this order, I personally:

* Run a `tree` and a `tree -d` to figure out the global structure of the project and try to understand how it's organized. Read most file names and try to look inside some files

* If one or more authors of the code are available to guide you, ask them (reading through the project structure first really helps to understand what they'll tell you about)

* If there are tests, read them, they're a very useful resource to understand what the code actually does

* If there are docs (particularly diagrams, but anything can help), read them

* If there is an entry point to the program, try to follow it and draw sequence diagrams (-ish, no need to be thorough if it's for you, but keep in mind it can be used by someone else (maybe even future-you) later so try to keep it clean and digitalized). For this you can also use a debugger and place some breakpoints wherever you want

* Read the code, modify it to see what happens, and _add comments_ to what you manage to understand

Obviously take notes of everything you learn.

</comment><comment><USER3> Usually I'm doing one of two things:

* Trying to completely learn how an application works * Trying to figure out a specific issue or bit of behavior.

For case #1, you generally look for an entry point and spread out from there. For case #2, you're mostly concerned with a specific chunk of code, probably related to an error message you're interested in, so you do some quick searching or digging to jump straight down to the relevant spot.

This article is a great example of that sort of behavior and thought process: [http://www.lihaoyi.com/post/DivingIntoOtherPeoplesCode.html](http://www.lihaoyi.com/post/DivingIntoOtherPeoplesCode.html)

</comment><comment><USER4> Second step, I find the main() function so I can start following references.

First step, I find the project's issue tracker to get a sense of what state it's in. Is it under active development? Is it half-finished, maintained? Are there giant problems unaddressed?

</comment><comment><USER5> Read code and debug.

Ask questions about configuration and architecture.

Learn how to reproduce peer successes.

The actual purpose of the code base is important for a good answer: elaborate "code base".</comment>


Companies, Don't Discriminate Front-End Developers - <AUTHOR> https://medium.com/@sadiqevani/companies-don-t-discriminate-front-end-developers-6b824c49de49 <comment><USER2> The actual title is "Companies! Don't discriminate Front-end Developers!", which changes the headline meaning in my opinion[1].

As it is, "Companies Don't Discriminate Front-End Developers", sounds like the crux of the Medium post is "Companies do not discriminate against front-end developers", whereas, the post headline and content reads as, "Companies, stop discriminating against front-end developers."

While its more of a rant, it would be nice to have more specifics on that complexity vs UX and other generalized subjects.

I say this, because being submitted to HN it is probably targeting a technical audience, vs, this reads more to "business" folks who may not understand the back end vs front-end.

[1] Maybe HN removes ! marks, so I would edit in a , if possible after "Companies".

<comment><AUTHOR> Updated. Thank you for your suggestion</comment></comment>


Technology Radar May 2013 - <AUTHOR> http://www.thoughtworks.com/radar <comment><USER2> I'd like to read what specifically lead them to categorize Backbone.js under "hold". They wrote about the various technologies that are recommended but don't provide much of a narrative for any of the "holds".

<comment><USER3> If you dig back to the last tech radar ([http://thoughtworks.fileburst.com/assets/technology-radar- oc...](http://thoughtworks.fileburst.com/assets/technology-radar- october-2012.pdf)) you'll find the narrative for why Backbone.js was moved to the 'hold' category.

<comment><USER4> Thanks! Here's the specific section on backbone from page 11:

Backbone.js is a great example of an abstraction pushed too far. While we initially liked the ease of wire-up, in practice it suffers from the same issues as all such databound frameworks from WebForms to client/server tools. We find that it blurs the framework and model too much, forcing either bad architectural decisions or elaborate framework hackery in order to preserve sanity.

<comment><USER5> They go on to say:

 _As the industry shifted from desktop GUI development to the web, it seemed natural to port the most successful patterns and designs to the new paradigm. After 15 years of trying, we feel that there are still no component-based frameworks that have successfully achieved this. We recommend not attempting to make web development into something that it fundamentally is not. It is time to accept the page and request-based nature of the web, and focus on the frameworks that support - rather than work against - these concepts._

This seems reasonable, but single page apps don't have a page and request- based nature, and Backbone seems a good fit for this case.

</comment></comment></comment></comment><comment><USER6> Is it just me or are a large number of their recommendations have no commentary at all?

For example what is "Aggregates as documents" and why is it top?

<comment><USER7> It is a bit terse. There is a very easy to miss show/hide details link in each section, but it does seem to omit mention of this technique. I think it is talking about using aggregations of data as documents in NoSQL databases. See <http://martinfowler.com/bliki/DDD_Aggregate.html> and <http://martinfowler.com/bliki/AggregateOrientedDatabase.html>

</comment></comment><comment><USER8> Always a great read. Strong recommendation for Clojure but just an Assess for Clojurescript. I would have liked to see some specific recommendations for Clojure tooling and frameworks.

Also interesting to see a strong recommendation for Sinatra but no mention at all for Rails. I agree with Sinatra's awesomeness, but was surprised to see noting on Rails.

<comment><USER9> Because we have so many blips we fade old ones or items that we feel are no longer worth highlighting. We like Rails but most of our readers know that and so we no longer include it on the Radar.

</comment></comment><comment><USER10> Go is not on their radar yet!

<comment><USER11> but that would conflict with their own continuous integration system... <http://www.thoughtworks-studios.com/go-continuous-delivery>

</comment></comment><comment><USER12> Just a quick reminder: if you only use the popular tools you might miss the perfect weapon for your use case.

Finding the right tools isn't an arranged marriage, it's a continuously evolving affair with twists and turns like a good novel.

Thanks for puttin this together. Always interesting to read what others think is "hot".

</comment><comment><USER13> Adopt MongoDB? I thought people were starting to realize that it's not so "web scale" after all.

<comment><USER14> What people are now realizing is that MongoDB is not a one-size-fits-all technology.

<comment><USER9> When we put something into "Adopt" we feel that its usage patterns and general "fit" are well known. We feel that's the case for Mongo -- it doesn't fit in all cases, but when appropriate it's absolutely a solid go-to platform. More industry awareness around when Mongo is the wrong choice actually makes it _easier_ to adopt.

</comment></comment></comment><comment><USER6> PostgreSQL for NoSQL

Hell yes, trialling here soon!</comment>