Show HN: The Autoprotocol Language Standard for Biology - <AUTHOR> http://www.autoprotocol.org

<comment><USER2> So, this is cool and it's nice to have an open standard with got traction from an active company.

When setting up lab automation, instrument communication is the biggest headache. There's lots of variability in how instruments communicate (serial, gpib, analog voltage, ftp/email from a contractor,...) and in how easily accessible their protocols are (published by manufacturer, closed, too old to know). Moreover, really old equipment is still in use and new equipment isn't likely to be 'designed for autoprotocol' for a while. How do you think managing instrument communication is going to work?

What are previous similar works like? I imagine stuff like this was made, way long ago, for doing combichem and hts... did it all remain in-house?

Support for extra parameters, like constant current vs constant voltage for gels, or that kind of thing? Or will this be in the name, like "op": "gel_separate_constant_I"

Support for timing, e.g. thaw out reagentB in time to mix it with reagentA which is being centrifuged, etc?

Reagents-- Any standardization for names/concentrations, or integration with inventory management?

Any planned integration with lab notebook/management software?

Any plans for 'preventing catastrophe' or 'forbidden operations' like centrifuging asymmetrically, or mixing stuff that precipitates+clogs (vs. intentional precipitation of, e.g., dna)? Not that we should need this, but increasing abstraction makes it easier to break stuff.

Looking forward to using this and contributing, etc.

<comment><AUTHOR> > Moreover, really old equipment is still in use and new equipment isn't > likely to be 'designed for autoprotocol' for a while. How do you think > managing instrument communication is going to work?

This is obviously a big issue; it's what we spend most of our time on at Transcriptic. (That, and building new hardware when it makes sense.) Only a few devices are designed for being controlled by 3rd party software and even fewer are designed for real automation like motorized lids for sample loading. Internally we have a layer that handles all of the device communication, but we haven't open sourced that and it wouldn't make sense without the rest of our infrastructure anyway: not something easy to just pick up on part of.

This is kind of outside the scope of Autoprotocol. I think that in reality there will be three big uses of it right now:

\- generating eg a PDF to take into the lab \- using it for more semantic information about the methods being used in conjunction with analysis of data you get from running stuff in lab \- running experiments on Transcriptic

In terms of automating communication and data capture in your own lab, I think Riffyn's doing the most interesting work here and it will be interesting to see what they come out with.

</comment></comment><comment><USER3> Hey all, I've been working on Autoprotocol for the last couple of months and can answer any questions!

</comment><comment><USER4> What is the overall process when using autoprotocol? I presume there are standardized robotic workstations with the capability to - 'do biology'. My experience of microbiology is limited to high school biology experiments 20 years ago -sequencing DNA and culturing bacteria on a petri dish. What is it exactly like to do biology in a modern research setting? (rough high-level description/example appreciated :) )

<comment><USER3> At Transcriptic we perform experiments using what we call a workcell - a set of devices like liquid handlers (automated pipettors), PCR machines, and plate readers all linked together via a common interface and a robotic arm that moves containers between devices. That interface understands Autoprotocol and executes the instructions accordingly. Autoprotocol itself was designed to be an agreed upon standard for different types of laboratory automation (not just ours) to execute protocols.

An example of an experiment someone could run through our cloud laboratory interface would be to monitor the growth rate of bacteria expressing different genes. This would be done using a protocol that contains some pipetting steps to dilute the bacteria and then alternates between incubating the plate at 37 degrees and reading OD600 of its wells using a plate reader at a specified interval for a certain number of repetitions.

</comment></comment><comment><USER5> This is a really neat idea. I wrote test-scripts for cell culture machines a few years back. Great fun moving giant robotic arms around!

If you can indeed encode all the primitives needed to more formally describe an experiment this would be great.

Are you worried the language will endlessly grow in complexity as you find edge cases it doesn't support?

</comment><comment> oodles-n-moles I'm a molecular engineer working on a well-funded, stealth biotech project. We're building the world's first biological server farm. It's going to be a massive, fully automated research facility that manipulates, moves, mixes, and analyzes millions of batches of cells and molecules everyday.

It'll have the effective throughput capacity of taking everyone on earth, giving them a pipette, and having them do molecular biology by hand. But it'll be accessible from the comfort of a laptop. Biology will become a programming discipline.

We have an IMMEDIATE need for talented Python coders for short-term, on-site contract work. If the mission inspires you and you'd like to hear more, please email Kent Kemmish biokemmishtree at gmail.

<comment><USER6> > on-site

In the general area of...?

<comment> oodles-n-moles The general area of San Francisco Bay.

</comment></comment></comment><comment><USER7> _Both the volume and duration are measures, which are strings of the format "value:unit"._

FYI, ISO 31-0 [0] already defines a single space as the separator between the value and the unit. Granted, most people (and even some scientists) don't know about this rule.

[0] [http://en.wikipedia.org/wiki/ISO_31-0#Expressions](http://en.wikipedia.org/wiki/ISO_31-0#Expressions)

</comment><comment><USER8> Another of the devs here along with @therzka, happy to answer questions :)

<comment><USER9> This is neat, but you guys have failed on the basic human motivation. A python file isn't something I can take into the lab with me to reproduce an experiment. Does this spit out a useful human readable set of instruction?

Is there a sample output spec, compared with the norm of human readable input? As is, this seems like a solution for computers, not folks in the lab.

<comment><USER3> _Does this spit out a useful human readable set of instruction?_

At its core, Autoprotocol is just a way to agree on how to capture all of the information about an experimental method, which in itself turns out to be deceptively complex (though looks a little obvious afterwards when you see it). That description is just JSON: it can be generated by scripts, UIs, or written by hand (and we at Transcriptic + customers do all three) and it can be consumed by lots of different things. If you have a lab of your own, we'll release our to-english converter soon! You can also post the protocol JSON to Transcriptic to run it in our cloud lab environment, which produces a preview of the instructions that looks like this: [http://imgur.com/EOBfZfW](http://imgur.com/EOBfZfW)

<comment><USER6> If it's a subset of JSON... Is there a mechanism to add in comments for humans to read?

I know the main use-case may be inter-device, but someday you might want to embed a short hint or explanation along with a particularly arcane set of instructions or parameters.

</comment></comment></comment></comment><comment><USER10> Hmm I have a microfluidics SVG library that I have been cooking, I think I will write a converter.

</comment><comment><USER11> What's the 3rd party hardware/software support for this like?

<comment><USER8> Software-wise, there are a couple of unannounced things from our partners coming down the line that work with Autoprotocol, and several of our customers have been building on top of the autoprotocol-python[1] and autoprotocol- core[2] libraries. Hardware-wise, Autoprotocol is a description language, it could even be executed on a sufficiently meticulous "human" device. (We have a project in the works that transforms Autoprotocol into human-readable instructions suitable for inclusion in a publication.) Transcriptic is the only fully automated system today that accepts Autoprotocol, but we're working with other groups building low-cost hardware systems (in particular, OpenTrons) who want to build on top of the Autoprotocol standard.

[1]: [https://github.com/autoprotocol/autoprotocol- python](https://github.com/autoprotocol/autoprotocol-python) [2]: [https://github.com/autoprotocol/autoprotocol- core](https://github.com/autoprotocol/autoprotocol-core)</comment></comment>


Where do individual contributors go once they peak? - <AUTHOR> https://tannerchristensen.com/blog/2019/12/23/where-ic-designers-go-once-they-peak <comment><USER2> Be careful that you are at a company or, even better, in an industry that isn't rife with ageism and where there is a clear and well defined path for more senior ICs to continue to develop an age appropriate resume (increasingly strategic contributions while remaining current with latest industry tools and practices) that will serve them well if/when they are looking for work at 55.

In software this is very often not the case. A 55 year old still fluent in hot tech and a lot of strategic work as an architect, interventionist, mentor to younger devs, etc and who can demonstrate all that in their resume will probably do ok. A 55 year old who is "just" a coder will often have a rough time (vs 28 year olds getting actively recruited 5x/week).

In other industries, like EE where I also worked for several years, this is much much less true. Very senior ICs are highly valued and it is common for teams to be a blend of engineers from fresh grads upto near-retirees.

<comment><USER3> Not an easy problem to solve. And this is why, given the odds, a career in tech is probably a bad decision.

To avoid ageism while being an IC you need to find a job in a niche where the domain is CS and/or ENG based (as in embedded, aerospace, or even relational database engines) and these jobs are far and in between.

Beware: jobs like Facebook seem to be CS based but they aren´t (that´s why their programmer average age is 27). The CS problems they have are due to arbitrary complexity and they are short term. Companies like these are media companies.

<comment><USER4> None of your conclusions follow from your premise.

I could just as easily claim that coders who refuse to develop new skills and keep up with a changing environment will eventually find themselves sidelined, due to their inability to adapt to changing needs. Since most of those middle aged people started programming 30 years ago now, they then move into environments where the technologies also haven't evolved in 20-30 years: embedded, aerospace, and dated DB work.

This doesn't preclude people who can evolve from keeping up as mostly-just- coders in a changing world. Calling the complexity inherent in something like facebook "arbitrary" as opposed to the complexity in embedded work as innate just implies that you don't understand the "CS" problems that Facebook (or similar) deal with, and I can imagine that a company like Facebook might not want to hire someone who, for whatever reason, is unable to accurately analyze the complexity of their problem space, especially at a more senior level.

<comment><USER3> I find the wording of your last paragraph a little insulting.

Please answer: do you think aerospace, embedded and relational DB engines is dated work that has not evolved?

<comment><USER4> > I find the wording of your last paragraph a little insulting.

And calling modern app development's probelms " due to arbitrary complexity and they are short term" isn't?

I do think that much of the aerospace technology industry uses dated methods. Same with much of the embedded field. There are certainly places that, for example apply modern best practices to embedded work, but most of those places are the exact same things that you're writing off: Google, Facebook, etc. Have embedded projects that follow best practices.

Focusing on aerospace specifically, I know of plenty of people who work in aerospace and don't use version control. That's plainly unacceptable. And I'd argue that the problems encountered there are much more self-imposed than at a Facebook.

Db engines again depend. There's a number of really cool modern relational database work, but the places where it happens (postgres, Google, cockroach labs) aren't places where someone who isn't interested in self growth are going to succeed.

The tl;dr here is that the impression I get from your comment is that you're describing a developer who let their skills stagnate because they learning things one way and don't want to keep up with changing processes. The fields you mentioned are fields that have such a stigma attached to them, and not unjustly. It doesn't apply to every person or project in those fields, but the people it doesn't apply to would succeed anywhere anyway.

</comment></comment></comment></comment></comment><comment><USER5> If one _wants_ more responsibility, one has to move to leadership. This is true in almost every company and work type, not just in software development.

There is a flip side to this, as some (many? most?) excellent ICs either become poor managers, or hate the job of dealing with humans, or (frequently) both. This is well known and many companies actually want and support top ICs who want to stay ICs with significant freedom to choose projects, generous (time, travel and $$) conference budgets and other perks.

Thus at least some ICs do not go anywhere after they peak (hopefully plateau), which can be a good place to be. But sooner or later they will likely be working under one of their team members whom they did not think much about (who may just be better with people than with technology). This is not a reason to lose any sleep; just something to keep in mind. My 2c.

<comment><USER6> Responsibility vs. accountability. If one wants more _accountability_ , then you must move to management. Responsibility can and should scale with IC levels.

What's the difference? Think about when a project fails. "Bad things" happen for the person accountable, whereas the person responsible can move on to the next project. The buck stops at the accountable individual _not_ the responsible one.

In practice, every project has a manager that's accountable and a lead that's responsible. As ICs move up the ladder, they're able to lead larger and larger projects _and_ offer expertise and guidance across multiple projects. Think: providing feedback, from hard-fought past experience, on a design doc that'll save a team 3 months worth of effort; architecture review, etc. Essentially ensuring and instilling engineering excellence across the organization.

One thing to note, moving up into a senior engineering role may mean you'll be coding or designing less. And that's to be expected. Senior engineers understand that coding/designing is one portion of a larger picture that includes communication, eliciting buyin, documentation, architecture, software quality attributes, and many more responsibilities.

In theory, this provides equal management and IC tracks that are fulfilling to all. In practice, very few companies work this way, but there are some out there. And when you find them, you won't want to leave because it's such a pleasant experience.

<comment><USER7> I'm sure it's a pleasant experience for the high level IC, but from the rest of the organization's perspective it you're describing architecture astronauts.

* They descend on random design docs to demand changes, based on vague pattern matching to a problem they faced 5 years ago.

* They don't have to do any of the work to implement those changes, of course. My team has to, and we have to defer to their opinion that changes are needed.

* If the changes they demand end up being really dumb, and hurt or kill my project, they can't be held accountable. Not even when it's a recurring pattern, since every corporate metric will show that the project team are the ones who messed up.

Maybe our disagreement is less severe than I'm thinking, since I also wouldn't agree the IC model at e.g. Google works like you're describing. But separating accountability and responsibility is in my experience an unmitigated disaster.

<comment><USER8> You describe a bad implementation of top level IC. They same way, it can be someone from the top management who has no clue about individual teams, makes dump decisions that hurt your team.

Top ICs work together with ICs that represent their teams, so that they can make informed decisions. They are up to date with technologies (this must be an obligatory requirement), code regularly, so they are much better then managers to make efficient company wide technical decisions, own the architecture of the whole system or large parts, organise and overlook large and expensive engineering initiatives, drive prototypes and research projects. They must me accountable for being up to date, understanding the consequences of their decisions, getting feedback from managers and engineers - not turn into "astronauts" in some years.

I think ICs should go in parallel with engineering management in the reporting chain: the top IC reports to CTO, next level reports to directors, etc. This ensures that IC's scope of responsibilities is expanding and they have better visibility and power.

<comment><USER9> > I think ICs should go in parallel with engineering management in the > reporting chain: the top IC reports to CTO, next level reports to directors, > etc. This ensures that IC's scope of responsibilities is expanding and they > have better visibility and power.

That's how it works at IBM. I'm the "responsible" party and technical leader for a couple of teams working on related projects. I report to a program director who reports to a VP. My peers are line managers and other senior tech leaders. Part of what's great about the team that I'm in is that we ha e clear talent pipelines that show how you can matriculate upward in design, engineering, or management, and that a "band 10" of engineering is equivalent in scope, comp, influence, and autonomy to his or her manager equivalent or design equivalent. That extends into the executive ranks as well though it's more common to find people who hold dual roles of VP and Fellow or Director and Distinguished Engineer or Distinguished Designer.

<comment><USER8> Exactly, it is similar to my position at some previous company: as a tech lead I reported to a Director of Engineering who also managed a few engineering managers. The top IC tech guy - "Chief Architect" reported to CTO.

</comment></comment></comment></comment></comment></comment><comment><USER10> They keep on doing what they love.

At some point, I simply cut and pasted the paragraphs of my performance self- reviews and actions for growth from one year to the next and told my manager: "WYSIWYG, you know what you can expect from me, you know I'll learn anything that's needed for the job, and more. What more needs to be said?"

And that was the end of self reviews and we all lived happily ever after.

<comment><USER11> You seem to assume someone has to "love" what they do to be effective. I'm a senior engineer, and I don't hate what I do, but I wouldn't be doing it at all if I were financially independent. I'd be doing something I love instead.

<comment><USER10> Not assuming, just anecdotally telling what works for me.

</comment></comment></comment><comment><USER12> I think this phenomenon is evidence of the value ceiling of IC work. What is the point of diminishing returns on paying an IC more money to do what they already do well vs hiring an additional younger and less expensive person to do the same thing, though not as well? Of course, an experienced IC can transition to mentorship, and different companies value this differently, but that may have a value ceiling as well.

Personally, I don't think it's necessarily a bad thing when IC's who max out their value writing code transition to other things. I agree not everyone makes the transition successfully, but it's a great opportunity for personal growth, and the potential for upside is high, since an organization can gain a leader with very nuanced and deep insights into product + market.

<comment><USER13> This is not my experience. It might depend on the field. Unless there is a "peak IC" doing stuff development stagnate and no matter how much time or resources is put into something the great results never comes. Things turn out good, yes, but not great.

It might be that I see this from an engineering perspective and that "the market" and stockholders wont notice in the short term until the brand gets a quality reputation in 10-20 years from user hearsay.

Managers on the other hand seems to mostly have the duty of fighting fires and putting out fires - with the most important quality of not litting fires themselves. There is no way a great engineer working as a manager have time to deal with deep proactive technical issues where I have worked.

</comment></comment><comment><USER14> The original article's title is: "Where do IC _designers_ go once they peak?" (not sure why it was changed on HN), and it focuses mainly on the career path for design.

For engineers, at least in larger tech companies, there's often a tech career ladder that runs parallel to the management ladder where you can have salary and responsibility growth as an IC without managing people. These ladders usually top out at a "distinguished engineer" or "fellow" level that's roughly equivalent to being a VP.

EDIT: added clarification about company size

<comment><USER15> Based on my experience, it doesn't seem that many companies outside of the FAANG companies have those kind of tracks. At a small company that builds a single product, what would a "fellow" actually do that is different than a senior engineer?

<comment><USER14> You're right, the company needs to be of a certain size before this makes sense. But it's not just FAANG -- for example, IBM, Microsoft, Twitter, Lyft and many others have similar tracks.

<comment><USER16> People are so stuck on the acronym that think of MS as less of a tech company than Netflix? Microsoft is much larger than Netflix no matter how you measure it.

<comment><USER17> So true. The reply is like "by these other huge famous companies have them too".

Ok. That's great. How about the small product companies that have like 20 or 200 engineers as opposed to 2,000 or 20,000?

</comment></comment></comment></comment></comment><comment><USER18> Managers control the purse strings. ICs don't. There will never be equal status, and it starts with other ICs that won't lift a finger unless it pleases someone with a fat purse. You can leverage IC star power a little, but it won't get you too far without a purse.

<comment><USER19> Very true. Whoever owns the cost center number has the power.

</comment></comment><comment><USER20> I am a senior IC transitions to management. I think these articles leave out a very significant part of the equation and that is compensation and career mobility. Generally the management track at higher levels has more openings. If you stay in the IC track, there are going to be much fewer openings at that level with appropriate compensation. This is particularly true the more specialized your knowledge is. Moving to management track provides more opportunity at the same/similar or greater compensation. The exception to this are the FAANG companies but in my experience it's way easier to get in through the leadership ladder than through the senior IC ladder. At least that was my experience in the 2 I've worked for. In one of the FAANG I worked for, I joined as a senior IC but was given a very non-senior manager and was effectively treated as a junior engineer during the 1st year.

<comment><USER11> More openings at higher levels? That's just at odd with how organizational structure works. For engineers, at least, you need about 1 manager per 8 ICs. Going up the ladder, you probably need about the same number per level, so: 8 managers of managers per first level manager, and so on. If you have team managers, directors, and VPs, you should need:

1 VP per

8 directors per

64 team managers.

So, how are there more openings at higher levels?

<comment><USER20> There are more openings for managers at higher levels with the same or higher compensation than for high ICs simply because there are fewer problems that have the scope for such a senior engineer. A FAANG I worked at might have a need in an org for a few director level ICs. These ICs in my experience are few and far between. ICs at this level make same money as management track. In my experience not many teams within an org have scope for an IC at that level Making it more difficult to transfer within the organization. Yet at the same time there are many director level managers because there are many teams and lower level managers to manage within those orgs. Additionally, a director level manager is considered somewhat generic and has an easier time moving around in the company with things that are tangential to their domain. My current company is not a FAANG but I can tell you that I see the same thing there.

</comment></comment></comment><comment><USER21> Many of you are thinking about this wrong.

In places that allow senior non-manager ICs, those ICs are determining what to do. The managers are figuring out who and when to do it, the ICs are going to figure out the details, tech ordering, research, etc.

Usually the way it works is I'll identify a large scale problem, work to quantify it, cost it out, work to find the manager who is most appropriate for it. Work with that management chain to further quantify cost and benefit of fixing the problem. We'll get high level resourcing and prioritization for the work. I'll get going on deeper research, role needs, design docs and v0 implementation. Manager will get going on hiring. At some point I'll swap from driving everything to doing, and just lob prioritized tasks to the managers. Essentially I'm working as a Product Manager and IC coder at this point, eg I'm saying what we should be doing (PM) and doing the work. However at this point the manager is actually setting sprint task level priorities for me. So weirdly the work goes PM (me) -> SDM (mgr) -> IC (Me). At this point the SDM will usually have hired some other devs or a PM and we just fit them into the flow. At a certain point I'm really just a Lead on the team while we groom up a permanent lead. Or if it's a longer project I'll stay in the Lead role for a year. The manager, PM and I are all working together. I don't have to manage anyone but I do a ton of mentoring and product work and communication.

They asked me a while back if I wanted to manage people (manager came from where everyone here seems to be coming from). But when we discussed it they didn't want to lose 30% of my time to management duties.

A highly effective manager will be able to delegate large parts of their perceived responsibility to others, which is how they get to 100% productivity. Same can happen for managers.

Some call it managing up.

<comment><USER22> Since I do the same process described here (at a FAANG), I'd like to elaborate on one more thing: responsibility. Upper management trusts me to do a good job along the entire pipeline, _particularly_ at the hand-off to the maintenance/independent-development phase.

Not every company actually defines a role like this (mine doesn't), but it is a role every healthy large-scale company needs.

<comment><USER21> Very good call-out. Trust is inherent here. Amazon would call it earns trust and ownership. The role there is Principal Engineer (or really senior sde3).

</comment></comment></comment><comment><USER23> Value is all about impact and companies are incentivized to reward and promote impact. It's valuable to a company to have a really great IC, it's even more valuable to have a manager that can grow their team into really great ICs - presumably like the manager was at one point.

If you are an amazing IC, but can't/won't help others grow to that level, you are only so valuable to the company - hence the IC ceiling.

<comment><USER24> ICs reach a local maximum at some point. Most companies aren't solving problems that are hard enough to warrant executive-level equivalent engineering roles (except organizational ie. management of said engineers).

</comment></comment><comment><USER19> Most companies have no use for very senior ICs. They don't have much difficult work and a lot of managers want to involve themselves in technical decisions so once you have reached a certain level there is no room to grow. Either go into management or stagnate.

<comment><USER25> > They don't have much difficult work

They usually have enormous technical debt that elite engineers could disentangle.

<comment><USER26> Technical debt is like real debt. You do it because you want to grow the business, and you can delay it as long as you can. Paying the debt down doesnt make the business grow.

<comment><USER27> After owning a house, I feel like technical debt is much more closely related to building homes and doing remodels.

You can always cheap out and get it done slightly faster and slightly cheaper. And you might not have to suffer the consequences. But someone down the line likely will.

E.g. we recently had to install a cleanout for the sewer mainline in our house. Apparently when they built the house, they did everything but install the final above-ground cleanout - instead they just capped it off below ground. The other work, except for the above ground part, all had to be done for testing purposes anyways. But by not installing the above ground part they managed to save something like $10 for each house they built. But now, instead, I had to pay a company $1,200 in labor (they spent all day digging) to install a $20 part when our sewer backed up.

I work in a codebase full of bad, willful technical debt like this. "Let's just do it the easy way" \- despite the "hard" way not being harder, just more different than they were used to at the time. Or hard coding things despite being able to derive it from other information - "we can do it later" \- good luck, differences creep in and you will spend weeks or even months figuring out all these minor differences and whether they are on accident or on purpose.

6 months down the line, that easy way is completely fucking us up. Certain changes that would have taken an hour take days. And it was completely predictable at the time.

<comment><USER26> This is true, but i doubt it was just 10$ piece - they did many of these shortcuts that probably didn't matter. They probably didn't use the _best_ material on your kitchen countertop, because the marginal value over good enough is not there.

In a similar analogy to yours, most of these systems tend to cause outage somewhere, which are then usually patched on the fly. Depending on a project, shipping fast is usually more valuable than not shipping it for a year. From my pov, i used to be in advertising, and not releasing a billion dollar feature for a year would, by definition, cost a billion dollars a year. If it explodes after releasing, you are still better of by a huge marging because outage would cost much less. Once you have the business going, you can spend money and manpower on the problem, too.

I think this is key: "Hard way not being harder". This depends. Engineers like to overengineer, and without proper supervision they tend to favor technical excellence over business usecase - it needs to be a balance.

On the house example, i bet the value of your house still increased, and the 1500$ you paid is irrelevant in the grand scheme of things. Just like business & rewrite.

Overall, don't get me wrong, I like to use my best skills and put a shiny design out, but i don't do it because I favor doing "good enough".

</comment></comment></comment></comment></comment><comment><USER28> The problem with growth as an IC is that one person only has so many hours in a day. The only real way to multiply your impact is to transition from using your own hours to produce work towards directing the hours others use to produce work. Simple math shows that your own productivity scales only up to 24 hrs/day while you can easily direct a team of 4 towards 32 hours a day of productivity and actually get some sleep.

<comment><USER27> This just isn't true. A friend of mine is an IC and regularly ends up making original tools that solve his problems that everyone else at his company ends up adopting. The company recognizes this and awards him in kind. He makes around 1 million in regular salary.

He has way more impact than any individual manager. If you want to have a huge impact at your company as an IC, solve the higher level problems that both you and your fellow developers are having.

<comment><USER29> It is simpler to manage a company without arrangements like this. It makes ICs and Level 1 managers more interchangeable. If you moved the 1M employee over to another group it would blow up that manager's budget. The more interchangeable employees are the better for some people in upper management who don't actually care about maximizing cost efficiency and productivity. They are maximizing other metrics.

<comment><USER30> > They are maximizing other metrics.

Can not be customer satisfaction (by quality) or employee happiness or retention.

I wonder what those other metrics are.

<comment><USER31> _I wonder what those other metrics are._

A big one is that managers are _de facto_ judged by the size of their team (and, for more senior ones, the size of the tree underneath them, too). It seems to be really, really hard to have middle management in an organisation without "maximise headcount" becoming an unofficial goal.

 _Edit:_ Employee happiness is an interesting one here. It's quite believable to me that being seen to cut down a few tall poppies might have a positive impact on (mean) employee happiness in some cases.

<comment><USER30> I was not expecting such a Machiavelic answer, but yes, your explanation looks quite possible. Indeed, it is possible that the expertise ceiling that goes on a lot of companies is due to misaligned incentives (plus some dishonesty) for management. That seems worth taking a better look.

> It's quite believable to me that being seen to cut down a few tall poppies > might have a positive impact on (mean) employee happiness in some cases.

This again... I dread to imagine going through the day around people that think like this. But people that think like this exist, and I imagine they concentrate somewhere. If some place makes them happy (and everybody else unhappy as a consequence), you'll probably find them there. This is really believable.

</comment></comment></comment></comment></comment></comment><comment><USER32> There are many ways to be an IC. You could just write code all day with minimal interaction with the rest of the team. But you can also mentor your teammates or be a technical lead for a component or entire project, even without becoming a manager with direct reports.

In general I don't think there is anything wrong with "peaking" at a point in your career where you feel fulfilled without feeling pressured to always take on more responsibility and stress. If you want to lead projects or manage people, go ahead. If you just want to write code, that's fine too. Of course depending on the company your compensation might top out after a certain point, which you may or may not be happy with. But at least in the bigger FAANG-type companies, you can go pretty far as a "tech lead" style of IC, without directly managing people.

<comment><USER24> > In general I don't think there is anything wrong with "peaking" at a point > in your career where you feel fulfilled without feeling pressured to always > take on more responsibility and stress.

So true. Especially after having a kid, I'm dreading any further promotions above the usual Senior. I'm happy at the level I am for the last 5 years and don't see why I would suddenly want to spend more hours in meetings and be held responsible for more things?

</comment></comment><comment><USER33> Why do we feel the need to "progress" anywhere? I mean, why not enjoy the mastery of the field, knowing your job so well you can do it blindfolded. Somehow a welder or a plumber doesn't need to "progress" to "welding architect" or "distinguished plumber". Yet most of us in tech willingly participate in a stupid rat race that eventually causes a lot of us to burn out. You can't make all the money in the world. On my deathbed I'm pretty sure I won't be thinking of how much more money I could have made. In fact I won't be thinking about work at all.

</comment><comment><USER16> Devil's Advocate Question: What's wrong with peaking? I'm 45. I spent 10 years in "Expert Beginner" mode and then spent 7 years moving between 3 companies and for the last 3 or 4 going back and forth between a dev lead, back to an IC to get some hand on experience in some areas I was weak at and now back to an "architect" or a Single Responsible Individual with maybe a team of dotted line reports.

I make "enough" now to meet my short and long term goals and have a great work life balance. Why shouldn't I just focus on keeping my network current, my resume up to date with in demand technologies, and within the next two or three years when I reach my ceiling, be happy with cost of living raises?

I'm looking at the next level. Management doesn't interest me. I'm really not interested in the travel requirements of consulting and we are good. I could easily see myself doing the same thing I'm doing now using whatever technologies are trending then at my current company or an equivalent.

But, on the other hand. I might get bored out of my mind and move to consulting just for new challenges and the extra money would be nice but not necessary. A regular old Enterprise Developer in Atlanta can live a good life - especially with dual incomes

</comment><comment><USER8> It is unfortunate that the industry seems to stick to only "coder or manager" framework. There are technical topics and decision spanning across a few teams or the whole organization: CI/CD, data pipelines, languages / frameworks, consistency, reusable components, best practices, mentoring, integrations.

Can coders who are limited to a single team, without exposure to a big picture, not experienced in business communications, specialists not generalists do it?

Can a director of engineering, who is busy with people management, meetings, plannings, work allocations, who can barely keep up with latest technologies, forgot when they coded last time do it properly? Do you want VP to decide what language or platform to use across the organization?

It is just my opinion and some experience, but I think there is a proper set of responsibilities in many tech companies for such leadership roles without people management, like tech leads on steroids, they can be called architects, principal engineers.

Roughly, 20-30 percent coding, the rest on communications, coordination, designing, mentoring, researching, solving tricky problems, with career progression in the scope: single team -> department, area -> whole organization.

</comment><comment><USER34> I find the whole concept strange. Why are technically skilled folks boxed into being "individual" contributors? There are many ways (hats) in which technical skill can be leveraged to help other people or teams: the person who can troubleshoot surprises with relentless digging (beaver), the person who provides technical feedback to colleague (reviewer), the person who has a broad understanding and can quickly get someone up to speed in a new area or suggest exactly what to look for (consultant), the person who understands the system well enough to onboard a new member quickly (teacher), finding new directions for the org (researcher), etc. All of those are multipliers on the performance of people and teams, and don't befit the "individual" moniker.

Working on complex problems requires collaborative effort, which can be immensely gratifying not just intellectually but also emotionally (humans are social beings). It is strange to see a warped restriction of the concept of collaboration down to each "individual contributor" doing what they're assigned, and ignoring the other "hats". That formulation never allows/imagines a chance for the whole to be better than the sum of its parts.

<comment><USER35> because thats the meaning that we've assigned to the phrase "individual contributor", its as simple as that. If you don't have people reporting to you for you to direct in accomplishing the goals of the organization you're an individual contributor, if you do have them you're a manager.

</comment></comment><comment><USER36> And what about individual contributors with a communication handicap? Where do they go once they peak?

<comment><USER37> That's a great question, and of course depends on the handicap. If it's hearing/speaking, probably a lot of jobs can be done via "chat", with little or no phone or in-person hearing required. For limited sight, we fortunately live in an era of huge monitors. Certainly being blind would suck, of course, perhaps even more than 20 years ago given the "advances" in UI.

</comment></comment><comment><USER38> It sounds like career path for designers has some similarities with software engineers. I think software engineering can potentially offer a much wider and deeper set of opportunities.

Still, in practice, these growth opportunities can seem far less common than yet another senior full-stack dev position. If you want to work with scale, there's Google, Amazon, etc., but most companies don't really need to engineer for scalability and high availability. They just need to ship some CRUD features yesterday.

At some point, it's worth considering whether it's worth the costs to keep pushing up in career for more interesting work, more money, more status, whatever.

</comment><comment><USER39> "Then, a few years into the [manager] job, they realize that they don't have the natural talent to develop other people. Not only is this a waste of their time, but chances are, they could have increased their contribution even more if they had stayed in the [developer] role - a role in which they naturally excelled. Yet if we want additional income, status or responsibility, most organizational hierarchies force us into a very different role - instead of allowing for an entire career of progression within a specific role that fits our talents."

StrengthsFinder 2.0 from Gallup

</comment><comment><USER40> And then there's me, desperate to get into management. Has hussled for 10 years to make it happen, with no luck. I'm currently sending out hundreds of CVs trying to get a business analyst role. No interest. Do you know how many engineers I've seen promoted in 15 years in the industry? 0. None. Had I done a business degree I'd be well away. I'm so old now that even doing an MBA wouldn't help me. I'm currently considering getting a super market job because the thought of going back to programming makes me feel physically ill.

</comment><comment><USER41> I have been an IC for 17 years now (MS/Amzn/Snap) - let's hope I haven't peaked yet :)

But over time I have seen my role change in many ways though: I started as the stereotypical IC, slinging code and did that for a long time. Almost at every level though, sooner or later I ended up with almost full ownership of whatever I was working on. That meant I kept growing in levels and I am where I am right now (Uber tech lead for all data analytics infrastructure at snap).

My current role essentially takes up 10-15% time for company level arch/design reviews, 10% time on interviews, 40% time on preset meetings (scrums/team design reviews/planning/post mortems), 20% time on operations and about 15% time for coding. So pretty much all coding I do is in that tiny sliver or outside office.

I am pretty much a part of all meetings my manager peers are a part of - except for their people commitments. The main differentiation I see between the IC role and managerial is that I don't have people reporting to me. I also don't have to be in ALL the status reporting meetings / managing up etc.

There are definitely times I want to put my head down and get some problems solved, but it usually comes at a cost. So I find some or other engineer to task it on and watch it done most of the times. Rest of the times I don't sleep :)

It is breadth heavy because snap is still a small company in terms of # of engineers. My equivalent role in AWS was a lot more on the building side (50-75% went into building stuff and rest for ops/interviews etc.) because it was a depth position. I did choose this after 13 years of depth roles, it has been quite interesting so far! The biggest advantage I bring is that I can pretty much fix anything in the system and make changes in any component, assuming the dev is not available. I also keep the full stack in my head, so serve as the initial litmus test for new proposals.

I see a bit of misconceptions about pay (I do get paid in the same band as my level to next level give or take bonuses/stocks etc), ownership (My ass is very much on the line for our data quality), responsibility (my managers share the responsibility in a different way - they will get a team member on things that need done and refocus. I will jump in myself if that doesn't work) etc.

I like the freedom. I do like the fact that I can be socially aloof (I am usually friendly, but my friends are outside work) and still get things done. I prefer not to worry about others personal lives (from what I see, this becomes inevitable for managers). I definitely like not having to deliver reviews (I am still a part of the process).

Feel free to ask me any questions.

<comment><USER42> > let's hope I haven't peaked yet

Hear hear! There's still so much to learn - I've been coding for nearly 30 years, and there are entire domains I've hardly scratched the surface of. And now I'm actually getting a chance to apply AI techniques to my day-to-day work!

</comment></comment><comment><USER43> What a dumb article, the whole thing is the title.

Here's my measure for "meaning density" in article. "How many sentences did it have" divided by "How many distinct points did it make"

this is one of these "lightning rod" articles, where nobody upvotes it because the article itself is good, but rather because it talks about something they are angry about and agree with and want to debate.

</comment><comment><USER44> There's nobody making you choose to stop being an IC. If you want (and you stay up-to-date with the latest trends) you can continue doing it indefinitely. You just can't do that _and_ also demand that you be paid the salary of someone who is leading a team.

You are paid to produce value. If you continue to focus on producing value as an _individual_ , you have to reasonably expect that your compensation will eventually reach a limit.

<comment><USER45> Microsoft pays employees based on level. My manager does make more than I do, but that's because they're a higher level, not because they're a manager.

<comment><USER46> Facebook is the same. Transition to management, make the same pay per level. It's less about moving for money and more about moving to what skillset you prefer to use, which I really like.

<comment><USER26> Ish. There is a ceiling to an ic. Sr dr ic level(distinguished) is probably it, while an em can go up to svp level.

Let's not kid ourselves, the ladders are never equal, and a senior ic level doesnt translate well to another company. After l7 and above, the skillset is only mostly recognized within the company.

</comment></comment></comment></comment><comment><USER3> Where do they go?

A-Management.

B-Consulting.

C-Stagnation.

D-Endure a string of jobs where they are mobbed because they are seen as a threat until they retire from the industry.

<comment><USER47> E - Teaching? A few of my absolute best adjunct professors were retired from industry and took jobs in education because they loved the field and wanted to give back.

</comment></comment><comment><USER48> they become PMs and begin the inexorable long decline.</comment>


Turing and Wittgenstein on Logic and Mathematics [pdf] - <AUTHOR> https://www.britishwittgensteinsociety.org/wp-content/uploads/documents/lectures/Turing-and-Wittgenstein-on-Logic-and-Mathematics.pdf <comment><USER2> Like all great philosophers Wittgenstein had a knack for pointing out the nuances in the things we take for granted--I think this is what he's driving at with his emphasis on analysis over proof, and indeed, he was brave enough to claim there are certain things in life we _can 't say_\--things we can't master, things that may never be captured by our epistemological games-- unknowables.

If nothing else, reading Wittgenstein always induces thinking, which is something I think it's easy to take for granted. Reading other philosophers or intellectuals, I think it's easy to agree or disagree with their propositions, Wittgenstein, at least for me, mastered the peculiar art of pushing his reader _beyond_ agreement or disagreement into the realm of active thought--whenever I read his aphorisms, I don't find myself going "yes!" or "no!" as I do with some other writers, but rather being gently pushed into a reflective mode, into an active consideration.

Thank you for sharing!

</comment><comment><USER3> This lecture was by Ray Monk, who wrote a fantastic and very accessible biography of Wittgenstein: [https://www.goodreads.com/book/show/12079.Ludwig_Wittgenstei...](https://www.goodreads.com/book/show/12079.Ludwig_Wittgenstein)

Wittgenstein's work can be pretty difficult to wrap your head around, but Monk does a great job of getting its main thrust while covering his life too.

<comment><USER4> Monk's biography is fantastic. But I have to disagree, it gives an intimate picture his life, relationships and general outlook, but only glancing snippets of his philosophy. If you are interested in his thought, you would do far better just reading Wittgenstein himself, or reading one of the many fantastic overviews of his work - I would recommend Hans Sluga's book, the Routledge introduction to the Philosophical Investigations, and the Cambridge Companion to Wittgenstein.

<comment><USER3> I think we're probably talking about different audiences. If you're an undergrad studying a philosophy minor then sure, go to the source. But if you've read a couple of Virginia Woolf novels and are interested in the Bloomsbury set, it gives you enough of a flavour. I studied both early and late Wittengstein at university and I certainly wouldn't recommend the Tractatus to anyone except as a novelty, and although the Philsophical Investigations are more approachable, they quickly become tiring for someone not motivated to invest some time in reading them slowly and thoroughly. (I know this from the time when I was reading the Investigations and badgered other people to read them because I thought they were so fantastic!)

</comment></comment></comment><comment><USER5> From the Cambridge seminars:

        WITTGENSTEIN: I won't say anything which anyone can dispute. Or if anyone does dispute it, I will let that point drop and pass on to say something else.

        TURING: I understand but I don't agree that it is simply a question of giving new meanings to words.

        WITTGENSTEIN: Turing doesn't object to anything I say. He agrees with every word.

        TURING: I see your point.

        WITTGENSTEIN: I don't have a point.

<comment><USER6> I don't get it.

<comment><USER7> It didn't really happen so there's nothing to get. Those are seperate quotes taken from different lectures and strung together as though they are a dialogue with a sort of Zen character. See one of the sibling comments by dfaubulich for the actual origin of each of those lines.

</comment></comment></comment><comment><USER8> The crux of Wittgenstein can be summed up thus (and I am totally stealing this from Jean-Yves Girard).

It's not about the rules of logic, it's about the logic of rules [1]

The axioms and deductive rules of ALL formal languages are invented/designed by humans, not discovered, so it begs the question: Who invents the rules and why?

Logic (when seen as a formal language itself) is a subset of Programming Language Theory [2]

1\. [https://doi.org/10.1017/S096012950100336X](https://doi.org/10.1017/S096012950100336X)

2\. [https://en.wikipedia.org/wiki/Programming_language_theory](https://en.wikipedia.org/wiki/Programming_language_theory)

<comment><USER9> The remark from Girard may not be so far from some things Wittgenstein said at this or that point. But it's not clear that Girard's remark means anything like that "logic is invented/designed by humans". For example, it might also mean something like what Wittgenstein wrote in the Tractatus:

We have said that some things are arbitrary in the symbols that we use and that some things are not. In logic it is only the latter that express: but that means that logic is not a field in which we express what we wish with the help of signs, but rather one in which the nature of the absolutely necessary signs speaks for itself.

<comment><USER8> If you trawl Girard's papers you will find him saying at least these two things:

Logic is subjective.

Logic is implicit - will never be explicit.

"The symbol speaks for itself" is the notion of denotational semantics mathematicians use. I am in the camp of "symbols mean whatever you interpret them to mean".

</comment></comment></comment><comment><USER10> To whom is interested in history - "A Mind at Play: How Claude Shannon Invented the Information Age" \- [https://www.goodreads.com/book/show/32919530-a-mind-at- play](https://www.goodreads.com/book/show/32919530-a-mind-at-play) is an excellent book. A good companion to this is The Idea Factory: Bell Labs and the Great Age of American Innovation [https://www.goodreads.com/book/show/11797471-the-idea- factor...](https://www.goodreads.com/book/show/11797471-the-idea-factory)

</comment><comment><USER11> Something that sticks in my head about Wittgenstein (someone correct me if I'm getting this wrong) was that during World War 2, Wittgenstein felt that being a professor of philosophy at Cambridge was 'intolerable' and went to work as a hospital porter instead, incognito.

Also, favourite quote:

"A philosopher who is not taking part in discussions is like a boxer who never goes into the ring."

<comment><USER12> He also volunteered for military service in world war 1, and when he reached the front line volunteered for the extremely dangerous assignment of crawling into no-man's land alone to make observations of the enemy. He said it seemed absurd to be a volunteer among draftees and not take on the most dangerous missions.

<comment><USER13> His World War I journal portrays him has an very egoistical man, with a violent contempt to everyone, including his comrades. He wrote: "It is almost impossible to find a trace of humanity in them [the men of his unit]" and, about marines, "I often cannot discern the human being in a man". As an extremely wealthy and high-class officer, he despised the low ranked soldiers ("stupid", "malicious", "pigs"...), but also the other officers ("pigs", "utterly limited"). He volunteered for the army of Austro-Hungarian empire and expected others to follow; he failed to understand that the e.g. Serbian soldiers whose people was oppressed by the empire did not share his views.

I don't care about his personal life, but since this thread was turning into an hagiography, I just wanted to draw a more complex portray.

<comment><USER12> He was a self-critical upper class twit who continued to evolve and transform his view of the world and himself over the course of his entire life.

</comment></comment></comment></comment><comment><USER14> Maybe someone here can explain: I've come across more than a few philosophers, of the PhD/academic flavor, who are dismissive of Wittgenstein's work. I have a gist-level understanding of his work, and a hobbyist's knowledge of the history of Western thought up through, say, Foucault.

Am I seeing a biased sample or is LW out of fashion these days? If so, why?

<comment><USER15> Here's my take on it. Academic philosophy in the US is highly focused on making completely clear claims with a rigor approaching that of mathematical logic. It is more or less pursuing the program Wittgenstein sketched in his first book, the Tractatus, creating a collection of concepts and network of relationships among them in which apparent philosophical paradoxes vanish. This is the analytical tradition. It is nice because it is indeed rigorous, but it can be limiting because it severely constrains the topics you can talk about. Something as big and multifarious as, say, Heidegger's notion of Dasein does not fit into this mold. And certainly nothing written as poetically as Nietzsche would pass muster.

In his second book, Philosophical Investigations, Wittgenstein completely rejected this approach, and his earlier work. He claimed that....well, no one's really sure what he claimed, or that he really claimed anything, and that's exactly the problem academic philosophers have with him. To a first approximation, he claimed that the whole idea of language as a formal system was either wrong or a waste of time, and that language is better thought of as some kind of game.

The thinking, then, is that later Wittgenstein was not making a clear point, was not interested in making a clear point, and possibly was not even serious at all. Philosophical Investigations is an enigma, and modern academic philosophy doesn't deal in such things.

<comment><USER8> Somebody should tell Philosophers about the Curry-Howard-Lambek isomorphism.

Because that's all there is to the Mathematical notion of "rigorous proof".

And the 'next step' in scaling up this process is the mission undertaken by the NuPRL project [1] well on our road towards internalising systems theory as the mode of scientific discourse [2]:

      Starting with the slogan "proofs-as-programs," we now talk about "theories-as-systems."

1\. [http://nuprl.org/Intro/intro.html](http://nuprl.org/Intro/intro.html)

2\. [https://en.wikipedia.org/wiki/Systems_theory](https://en.wikipedia.org/wiki/Systems_theory)

<comment><USER16> What makes you think that philosophers haven't heard of it? Here's the Stanford Encyclopedia of Philosophy entry on it: [https://plato.stanford.edu/entries/type-theory- intuitionisti...](https://plato.stanford.edu/entries/type-theory- intuitionistic/)

</comment></comment></comment></comment><comment><USER17> Seeing that facsimile of "Mind" reminds me of Wittgenstein's quotes:

"If I read your mags I often wonder how anyone can read 'Mind' with all its impotence & bankruptcy when they could read Street & Smyth mags. Well everyone to his taste."

"How people can read Mind if they could read Street & Smith beats me. If philosophy has anything to do with wisdom there's certainly not a grain of that in Mind & quite often a grain in the detective stories."

</comment><comment><USER18> I wonder whether Wittgenstein would be satisfied with how things have turned out. We now know that what he considered "useless language-games" are in fact the building blocks of the universe, or as close as we're going to get to building blocks while still being human. We also know that every logic is either formal or trivially useless. Formalism ended up being the only path forward.

It's fun to see part of the origins of what we'd now call constructive logic in the question of whether a bridge might fall down if built from double- negation and classical logic. The idea that the bridge proves its sturdiness by holding itself up under its own weight is exactly the same sort of constructive-deconstructive idea.

I can't help but compare Wittgenstein to Confucius in their insistence on the meanings of words and their usage. Confucius wanted people to play fewer language-games and use simpler language because it was part of his legalist philosophy; by being direct and plain, a government could be more transparent and its people could find more harmony in their social interactions. But Wittgenstein was concerned with human ability to perceive truth, logic, and abstracta, and his desire for simpler language was so that people could see the world as it really is, with a simpler map for a more intuitive territory.

</comment><comment><USER19> Wittgenstein tried to describe an (emotional + logical) universe with logical rules. That stuff don't work!

</comment><comment><USER20> Too heavy for me, just curious.

Wittgenstein had read Godel, right?

<comment><USER15> He rejected Gödel's arguments.

<comment><USER21> I would say he rejected the Gödel's interpretation of his theorem but not the theorem itself.

<comment><USER22> Wittgenstein wrote about the _incorrectness_ of Godel's famous 1931 argument for incompleteness of Russell's Principia Mathematica because Wittgenstein showed that the [Godel 1931] proposition _I 'mUnprovable_ leads to inconsistency in mathematics.

For more information, please see the following: [https://papers.ssrn.com/abstract=3603021](https://papers.ssrn.com/abstract=3603021)

</comment></comment></comment></comment><comment><USER22> Wittgenstein was one of the first to realize incorrectness of Gödel's famous 1931 article on the inferential undecidability (incompleteness) of Russell's system Principia Mathematica. For more information please see the following: [https://papers.ssrn.com/abstract=3603021](https://papers.ssrn.com/abstract=3603021)

Professionals (including Gödel) ridiculed Wittgenstein's work on logic and ignored his correct important argument against [Gödel 1931].

<comment><USER23> Can you elaborate a little more on how Wittgenstein showed the incorrectness of incompleteness theorem?

<comment><USER22> Wittgenstein was one of the first to argue that adding the [Gödel 1931] proposition _I'mUnprovable_ results in contradiction by providing the following correct but somewhat convoluted argument [Wittgenstein 1937-1944] which has been explained by adding explanations of steps in brackets:

        "Let us suppose [Gödel 1931 was correct and therefore] I prove the unprovability (in Russell's system) of [Gödel's proposition] P [that is, ⊢⊬P where P⇔⊬P]; then by this proof I have proved P [⊢P because P⇔⊬P]. Now if this proof were one in Russell's system [⊢⊢P] — I should in this case have proved at once that it belonged [⊢P] and did not belong [⊢¬P because ¬P⇔⊢P] to Russell's system. But there is a contradiction here! [⊢P as well as ⊢¬P]
      …[This] is what comes of making up such propositions."

However, Wittgenstein did _not_ point out that the [Gödel 1931] proposition _I'mUnprovable_ is not allowed by the rules of Russell's system because of restrictions on orders of propositions.

Nothing of practical importance depends on the existence of Gödel's proposition _I'mUnprovable_. As discussed in [https://papers.ssrn.com/abstract=3603021](https://papers.ssrn.com/abstract=3603021) , the important property of inferential undecidability (incompleteness) of Russell's system can be proved in a different way without using _I'mUnprovable_. Furthermore, having Gödel's monster proposition _I'mUnprovable_ comes at the heavy cost of introducing another monster, namely, "A powerful theory cannot prove its own consistency" as discussed here: [https://papers.ssrn.com/abstract=3603021](https://papers.ssrn.com/abstract=3603021)</comment></comment></comment>


Draft California DMV Policy on Autonomous Vehicles - <AUTHOR> https://www.dmv.ca.gov/portal/wcm/connect/211897ae-c58a-4f28-a2b7-03cbe213e51d/avexpressterms_93016.pdf?MOD=AJPERES <comment><AUTHOR> Interesting statement on the term "auto-pilot":

227.90. Statements About Autonomous Technology

(a) No vehicle shall be advertised as an autonomous vehicle unless it meets all of the following requirements:

(1) The vehicle meets the definition of an autonomous vehicle specified in Vehicle Code section 38750 and section 227.02(d) of this Article.

(2) The vehicle was manufactured by a manufacturer licensed pursuant to Vehicle Code section 11701 also holding a valid autonomous vehicle manufacturer's permit issued pursuant to this Article at the time of the vehicle's manufacture.

(b) Terms such as "self-driving", "automated", "auto-pilot", or other statements made that are likely to induce a reasonably prudent person to believe a vehicle is autonomous, as defined, constitute an advertisement that the vehicle is autonomous for the purposes of this section and Vehicle Code section 11713.

</comment><comment><USER2> _" The manufacturer shall be responsible for the safe operation of the vehicle, including compliance with all traffic laws, when the autonomous vehicle is operating in autonomous mode within its approved operational design domain."_

The California DMV has it right. Self-driving cars are allowed, but if a manufacturer screws up, they have to pay all damages and may forfeit their $5 million bond. If they screw up badly, DMV can pull their license to sell or test self-driving cars.

There's practical stuff in there, such as coordinating with the California Highway Patrol with a plan for moving a stalled autonomous vehicle. (How to turn it off. How to get it to release the brakes for towing. Can it be pushed? Stuff like that.)

<comment><USER3> This answers a key question about autonomous driving: Can I ask my car to go above speed limit (because I casually do, and I want to project that on my car, rather than admitting I am reckless)? Answer is a clear No.

<comment><USER4> And if you need to accelerate out of danger for 20/30 seconds?

I am thinking of taking avoiding action on a motorway.

<comment><USER5> What makes that hypothetical interesting is that that kind of situation will almost always be the other driver's liability. So an autonomous driving manufacturer has no legal _liability_ reason to handle it. But when morality comes into the picture it gets a lot more cloudy (what if it accelerates over the speed limit to avoid an accident, if only to crash into another car and make the accident worse?)

<comment><USER4> mm so it wont break the law even if it risks your life - not going to go down well with drivers

</comment></comment></comment></comment></comment><comment><USER6> Here's part of the relevant section that other news outlets are trumpeting:

 _§227.54. Manufacturer's Permit to Test Autonomous Vehicles that do not Require a Driver.

A manufacturer desiring to conduct testing of autonomous vehicles capable of operating without the presence of a driver inside the vehicle on public roads in California shall submit an application for a permit to conduct driverless testing to the department on Autonomous Vehicle Tester (AVT) Program Application for a Manufacturer's Testing Permit- Driverless Vehicles, form OL 318 (New 9/2016), which is hereby incorporated by reference. Notwithstanding the requirements of sections 227.04, 227.18, 227.20, 227.22, 227.32, 227.34 (a) through (d), and 227.40 (a)(2) and (a)(3), and 227.46 a manufacturer may conduct testing of autonomous vehicles capable of operating without the presence of a driver inside the vehicle on public roads in California if all of the following requirements are met: _

And then follows a long list of requirements that __must __be met before a manufacturer can test those vehicles without a driver.

<comment><USER3> Based on those, how soon should we expect empty cars being summoned from the parking lot?

<comment><USER6> This is only during the testing phase.

</comment></comment></comment><comment><USER7> Can individual towns / municipalities issue rules on top of state regulations?

I assume a private community with private roads (and private maintenance not state funded ) can forbid vehicles from their roads (via a gate,guard or regulation) as they do now.</comment>


Xiaomi looking to invest in some Indian startups - <AUTHOR> http://pixr8.com/xiaomi-looking-invest-indian-startups/

<comment><USER2> Good job Pixr8.com, I am subscribing!!</comment>


The Most Detailed Simulation of the Cosmos Ever Made - <AUTHOR> https://futurism.com/illustris-cosmos-simulation/ <comment><AUTHOR> I this this is possibly the most interesting paragraph:

 _If the program's verifiable predictions about dark matter, galaxy formation, and magnetic fields continue to prove accurate, we'll be able to put greater stock in the insights it provides about processes we haven't been able to observe with even the most advanced telescopes ... With the simulation, we can track all the properties for all these galaxies. And not just how the galaxy looks now, but its entire formation history._</comment>


White People Love Hiking. Minorities Don't. Here's Why. - <AUTHOR> http://www.newrepublic.com/article/114621/national-parks-popular-white-people-not-minorities-why

<comment><USER2> As a minority, and especially as a minority that hikes, I hate these kinds of articles because I feel like their intent is to perpetuate White Guilt. Inequality and racism is bad, but you shouldn't feel guilty about not being poor. (These kinds of articles also conveniently love to forget about poor Whites and instead assume everyone who is White is affluent)

Like most articles, they fail to mention Asians. Once again, it's always Blacks and Latinos… Asians make up 4.8% of the US population, yet make up 8% of hikers. If you're Asian, you're nearly twice as likely to go hiking!

Blacks make up 12.6% of US population and 11% of hiking population. Latinos make up 16.4% of general population, but only 7% of hikers. Lastly, Whites are 63.7% and 70% respectively.

I don't know about you, but these numbers seem to follow general demographic percentages. So why was this article even written?

Every time I use a public city/county park, I always see giant groups of Hispanics and Asians. In fact, I always comment on how it seems like only first generation minorities like to take advantage of these services. (Which is a shame because local parks are awesome) I suspect that second generation minorities are enjoying their large house and fancy grill in the suburbs instead.

</comment><comment><USER3> Shouldn't they be normalizing the percentages? i.e.,they should be looking at percentage of non-whites who camp (denominator total number of non-whites) as opposed to percentage of people who camp who happened to be non-white.

If a minority represents only 0.01% of the entire population, odds of finding them camping is going to be very low unless that said activity is something very, very common amongst that ethnic group.

Having said that, I somehow do not see a lot of African Americans when I hike/camp.

<comment><USER4> While this article is just a rewrite of a similar one from today's NYT ([http://www.nytimes.com/2013/09/06/us/national-parks-try- to-a...](http://www.nytimes.com/2013/09/06/us/national-parks-try-to-appeal-to- minorities.html)), I appreciate that it contains some additional data, even though it doesn't relate specifically to National Park visits.

The NYT article only states that "about one in five visitors to a national park site is nonwhite... and only about 1 in 10 is Hispanic", which definitely points to Hispanics being underrepresented, since they make up 16.3% of the general population. But they don't include any more specifics, which makes me think the discrepancy couldn't be _that_ big.

<comment><USER5> Keeping in mind that non-Hispanic/Latino whites are about 60% of the US population, when this article notes that "the Outdoor Industry Association [...] own nonprofit organization, [the] Outdoor Foundation, shows underwhelming diversity. Its 2013 outdoor participation report notes that last year, 70 percent of participants were white.", it's hard for me to take the rest of this article seriously.</comment></comment></comment>


How to Create a Chatbot with Python - <AUTHOR> https://towardsdatascience.com/how-to-create-a-chatbot-with-python-deep-learning-in-less-than-an-hour-56a063bdfc44 <comment><USER2> Engati's Bot answers roughly 55% of all questions Look at how customer Support chatbots can improve your service experience and two case studies of self- service bots that will inspire you to create your own before they make it to a human. Build your bot using these templates from the best chatbot platform [http://s.engati.com/1qk](http://s.engati.com/1qk)</comment>


Ask HN: Beginning Consulting - <AUTHOR>

I'm a Canadian iPhone developer who started learning early 2011 and got a job with a seeded startup in the Fall of 2012.  I'm under NDA so I can't talk about the product at all.  I want to start contracting on the side, how much of a portfolio do you think I'll need to build up before finding clients won't be a struggle?<p>Also, how much should I charge as a Canadian. I've heard numbers as low as $30 and as high as $100. I like to think I'm competent, but am not sure if Toronto's market has a much lower ceiling than NYC or SF. <comment><USER2> As a benchmark, I know that University of Waterloo Computer Science and Computer Engineering Co-ops are making $60/hour for similar work. That's a good starting point. If you have any kind of portfolio, you should be able to leverage that into a higher hourly rate. In finding clients, its important not only to build a portfolio, but also to build a network that can help you find new work with interesting clients. So if you have a portfolio of two or three apps, along with a few people who are willing to serve as a reference for you, then you should be on your way.

<comment><AUTHOR> The issue I'm having with building a portfolio is I'm unsure how significant an app needs to be before its worth including. I don't have any ideas for apps that could be a commercial success (and I don't have much desire to be a developer for myself as opposed to being a freelancer). I could just rehash the same to-do list app that seems to be vogue but it seems too simple.

Am I overengineering or should I try to make a technically non-trivial app?</comment></comment>


Switching from software development in banks to product-oriented tech firms - <AUTHOR> I'm a upcoming new grad, and I'm debating whether accept an offer as a software developer position in a bank or still apply for product-focused tech firms. Eventually, I would want to move towards product-focused tech firms, or start my own down the road.<p>Anything is appreciated, thanks! <comment><USER2> Software development in banks is _far different_ than in tech firms.

In banks, you have a working legacy system that's existed for 15-30 years, written in whatever the languages and frameworks popular that were popular then (J2EE, etc), and the guys who have written it are long since gone. Your goal is to make sure the system doesn't break.

In product-focused tech companies, you have an in-progress system that you're in the process of building. It was written 18 months before by the guy who sits next to you, and was written in a framework / language that is much more modern (Python, RoR, Node), and your goal is to build new features on top of it.

You're at a fork in the road. Please, keep interviewing.</comment>


Ask HN: Has anyone here saved a failing software project? - <AUTHOR>

If so, how did you do it?  Was the old team still there or did it need new people? <comment><USER2> Saved might be a strong word, but I've helped some projects get delivered over time and over budget, when four previous teams had failed to deliver at all.

That really is a significant warning sign. If you are dealing with an organization that is currently failing at something it can mean almost anything. They don't have the skills? They trusted a 3rd party supplier? They have one bad leader?

If you are dealing with an organization that has failed repeatedly on the same task, then you are dealing with entrenched issues that you are not going to easily change. If they've decided in the past that this project can be done by 10 people in 3 months with continuously increasing scope then there's a good chance that's how it will run this time too.

As far as I can tell the key is to learn to be diplomatic but emphatic about saying no.

You can only be an asshole to coworkers occasionally, and you need to recharge your karma in the meantime, so being the guy who always says "no, that's too hard. It would take too long" will just mean you'll get sidelined and routed around.

You need to be the guy who says "Yes! That feature sounds awesome! Our customers will love it! Which feature can we cut to make time for it?"

Pretending that design and scope will stay the same for 6 months is fantasy, but as it changes you need to maintain a non-negotiable climate of people working regular hours and not getting bullied into making impossible promises.

Give somebody a goal 10% out of his comfort zone and he will work harder to meet it. Give somebody a goal 50% out of his comfort zone and he will make jokes about the whooshing sound that deadlines make as they fly past.

</comment><comment><USER3> I used to run a consulting practice where all we did was technical project rescues. I can say it is never really fun, almost always sucks and is never easy (which was the draw for me). The range of issues is huge, from entrenched teams unwilling to adapt, to horrible leadership to just a general lack of experience.

The recipe is almost always the same though, identify the gaps, increase communication, organize the project, reduce the initial scope, set some realistic deadlines, get some easy/quick wins and get both sides (IT and business) to the table to discuss reality regularly.

Also, quickly get rid of negativity, if you find someone that pulls the team down and out, try to pull them aside and get to the root of it. If they can't be influenced to help positively get them off the project or out of the company quickly, like ripping the band-aid off. No one likes to talk about firing people, but reality is what it is, one bad apple on a team can destroy a project by killing morale and feeding FUD. And frankly, you aren't doing that person any favors by letting them stay and be miserable either.

My 2 cents, projects need to be rescued because of weak leadership and decisions that went without being made for too long. A bad decision is almost always better than no decision, at least you have something to work with. No decision is almost always a mistake and guarantees nothing changes.

</comment><comment><USER4> Yeah, sometimes. It's challenging. When I've been successful, it's usually been a mixture of ingredients: a majority of capable team members who want to succeed; some level of management support for the changes you need to make; introducing (or improving) build and test automation; and planning and tracking work iteratively, chunking work into small end-to-end slices whenever possible. I know "agile" methods often get a bad rap (and often rightly so), but if you have a project in trouble, you need to be able to understand how much work you have left, and how you're progressing towards getting that work done.

</comment><comment><USER5> Meta: Make sure you get paid and credited for it. (And note the order in which I listed those.)

The world is full of discarded heros.</comment>


Using Python to Pull Data from the Meetup API - <AUTHOR> http://www.acheronanalytics.com/acheron-blog/using-python-to-scrape-the-meet-up-api <comment><USER2> Meetup2xibo also uses Python to pull event data from the Meetup API. Meetup2xibo loads the events into a Xibo digital signage dataset for display in sign layouts such as agendas, calendars, room activity signs, and maps.

[https://github.com/jshprentz/meetup2xibo](https://github.com/jshprentz/meetup2xibo)</comment>


How to tell a raven from a crow (2012) - <AUTHOR> https://www.audubon.org/news/how-tell-raven-crow <comment><USER2> Have you ever exchanged a look with a stranger and their expression was such that you immediately got a deep impression of their inner life, of their humanity, and felt a connection? That happened to me with a raven, while we were both enjoying a stunning view of a sunset at Petrified Forest National Park. It was a large, old, rumpled, wise seeming creature.

Surely that environment primed me for the experience. The mostly likely explanation is that I had a kind of moral hallucination. But it's changed the way I've seen ravens since. I attribute self awareness to them. When they caw what I hear is laughing ... at a ground bound inferior like me.

Reading _Mind_of_the_Raven_ only reinforced this feeling.

[https://www.goodreads.com/book/show/254704.Mind_of_the_Raven](https://www.goodreads.com/book/show/254704.Mind_of_the_Raven)

<comment><USER3> Scott Alexander has a good post on bird intelligence here: [https://slatestarcodex.com/2019/03/25/neurons-and- intelligen...](https://slatestarcodex.com/2019/03/25/neurons-and-intelligence- a-birdbrained-perspective/)

Though they have much smaller brains, there is evidence to suggest that their brains are 10x more computationally dense.

<comment><USER4> Birds are on a better process.

<comment><USER5> Maybe cooling is also a factor, so we are constrained by our brain's surface area.

</comment></comment></comment></comment><comment><USER6> Crazy to see this posted today. Last night my wife and I were on a reservation in Arizona and watching the birds. She googled this very topic. Then when I looked at HN today, here it is!

I showed it to her and the first thing out of her mouth was, "Is Facebook listening to me?"

Then I had to explain that HN is human-powered and the chances of Big G and Facebook and HN sharing data is pretty close to zero.

<comment><USER7> Similar spooky things happen to me with online adverts. I happened to mention to a friend that I want to adopt a dog. Lo and behold, for the next 5 days, all I see is dog adoption/dog food adverts. It's happened twice to me, and both times, the ads have been so out of the ordinary from my usual ads, that I actually took time to notice them!

I'm fairly certain Google is listening in to conversations for ad targeting. I think your case is serendipity!

<comment><USER8> I hear this kind of thing all the time. "Your case is serendipity, but they were listening to me!"

Do you know why you thought about adopting a dog randomly? Are you confusing cause and effect? Perhaps you were really being shown dog ads for six (or sixty) days and only noticed it for five.

I say this not to dismiss the fear of recording, but to raise that recording is kind of a lazy rationalization that tech companies probably favor over the other, more realistic explanation.

The idea that the ads have changed your behavior without you realizing is far more creepy. They don't have to listen to what you say because they influenced you to say it.

<comment><USER7> Yes, I do know why I thought about adopting a dog. It's because I love dogs, and have wanted one since I was a kid, and a really cool dog happened to walk past my window at the time while I was at talking to my friend.

I never Google dog photos or anything dog related really. I have no real reason to. Also, all the ads are see are usually either finance related or tech related. The huge influx of dog adoption adverts was most certainly an anomaly. I dismissed it the first time, but the second time, it was harder to put it down to chance.

I could be wrong, and maybe they aren't listening in, however at this point, I can't say with certainty that they're not. My suspicion is officially raised!

</comment></comment></comment></comment><comment><USER9> I'd always heard it was a matter of a pinion... (supposedly the pinion feather is longer in Ravens)

</comment><comment><USER10> I think the entire corvid family is fascinating. They are extremely intelligent. Some of them not only use tools but actually _make_ tools:

[https://en.wikipedia.org/wiki/Corvidae#Intelligence](https://en.wikipedia.org/wiki/Corvidae#Intelligence)

<comment><USER11> Corvids don't just have the capacity for making and using tools but also metatool use, i.e., using one tool on another [0]. In this respect their cognition apparently exceeds many species of primates.

[0] [https://www.sciencedirect.com/science/article/pii/S096098220...](https://www.sciencedirect.com/science/article/pii/S0960982207017708)

<comment><USER12> Interesting to note there that initially trying to use the short stick to directly retrieve the reward is considered a mistake; I wonder how many humans would give that a try, though.

<comment><USER11> I think it's largely dependent on the parameters of the problem. The researchers noted the significance of the distance between the reward, the first tool, and the second tool.

My guess is most humans run two quick analyses: 1) what is the cost of seeing if the short tool can be made to work and 2) what is the cost of retrieving the more distant long tool using the short tool. Human/primate efforts would seem to begin with tool use before escalating to metatool use.

All seven of the New Caledonian crows in the experiment engaged in metatool use on their first attempt; only some of them successfully retrieved the second tool but none of them trialed simple tool use.

</comment></comment></comment></comment><comment><USER13> Researchers for the Massachusetts Turnpike Authority found over 200 dead crows near greater Boston recently, and there was concern that they may have died from Avian Flu. A Bird Pathologist examined the remains of all the crows, and, to everyone's relief, confirmed the problem was definitely NOT Avian Flu. The cause of death appeared to be vehicular impacts.

However, during the detailed analysis it was noted that varying colors of paints appeared on the bird's beaks and claws. By analyzing these paint residues it was determined that 98% of the crows had been killed by impact with trucks, while only 2% were killed by an impact with a car.

MTA then hired an Ornithological Behaviorist to determine if there was a cause for the disproportionate percentages of truck kills versus car kills.

The Ornithological Behaviorist very quickly concluded the cause: when crows eat road kill, they always have a look-out crow in a nearby tree to warn of impending danger.

The scientific conclusion was that while all the lookout crows could say "Cah", none could say "Truck."

</comment><comment><USER14> Birds are so awesome. They make me feel so happy. They are also so much more elegant than anything people made that can fly, I think. I absolutely love them.

<comment><USER15> I think you'd like this: [https://www.youtube.com/watch?v=pI63Rbxml5U](https://www.youtube.com/watch?v=pI63Rbxml5U)

4K POV of an eagle soaring through the Alps

<comment> bjelkeman-again Thanks. Now I need to look at this on a big screen.

</comment></comment></comment><comment><USER16> Ravens are huge and they make a sound that to me sounds hilariously like a person doing a bad imitation of a crow.

<comment><USER17> In Swedish, the names are Korp and Kråka. The birds obviously know this and take every chance to introduce themselves.

<comment><USER18> > In Swedish, the names are Korp and Kråka.

Strange. I would have guessed Huginn and Muninn.

<comment><USER17> Hugin and Munin means Thought and Memory. I can't imagine how that would be onomatopoeia :)

</comment></comment></comment></comment><comment><USER19> Taxonomically, ravens and crows are not distinct clades. That is to say, not all the species we label "crows" are more closely related to each other than they are to all of the species we label "ravens," and vice versa.

<comment><USER20> Yeah. The article seems to be a pretty dry list of traits that distinguish the common raven and american crow, which are specific species, so it makes sense in isolaiton. But it seems to be embracing a frame (echoed in a lot of comments here) that "crows and ravens look similar but are very different birds", which is basically wrong.

</comment></comment><comment><USER21> Here's a very cool Google Creative Labs experiment that used tSNE to organize thousands of bird chirps/songs/calls. The result is an interactive map that groups similar bird sounds (click/tap to play any of the sounds):

[https://experiments.withgoogle.com/ai/bird- sounds/view/](https://experiments.withgoogle.com/ai/bird-sounds/view/)

source code:

[https://github.com/googlecreativelab/aiexperiments-bird- soun...](https://github.com/googlecreativelab/aiexperiments-bird-sounds)

<comment><USER22> I feel like these kind of cool tech demos paired with a highly motivated and technically savvy phd student would lead to some interesting models in research papers with accompanying demos.

<comment><USER23> On a related note, there's an app that will identify bird species based on photos that you upload ([http://merlin.allaboutbirds.org/photo- id/](http://merlin.allaboutbirds.org/photo-id/)), and it's powered by "Visipedia", a collaboration between a Caltech and Cornell research group ([https://vision.cornell.edu/se3/projects/visipedia/?__hstc=75...](https://vision.cornell.edu/se3/projects/visipedia/?__hstc=75100365.1faf22dbc501863eea5790689e4fb775.1478881109453.1480518577615.1480622596812.13&__hssc=75100365.1.1480622596812&__hsfp=2912946381)).

I remember how nascent the tech was when they first started releasing it in 2011ish and it's _incredible_ how good it is now. Really awesome stuff.

</comment></comment></comment><comment><USER24> Many will have heard the collective noun for crows via the Simpsons episode reference or otherwise (a "murder of crows"), but ravens get one of my absolute favorites: an "unkindness of ravens".

<comment><USER25> What's the real story of these supposedly normative collective nouns? They don't seem to stem from natural development of the english language, rather seem to have been poetically constructed at some point — is that true?

<comment><USER26> [https://en.wikipedia.org/wiki/Collective_noun#Terms_of_vener...](https://en.wikipedia.org/wiki/Collective_noun#Terms_of_venery)

> intended as a mark of erudition of the gentlemen able to use them correctly > rather than for practical communication

<comment><USER27> Here's the relevant page in Archive's scan of The Book of Saint Albans: [https://archive.org/details/cu31924031031184/page/n111](https://archive.org/details/cu31924031031184/page/n111)

</comment></comment></comment></comment><comment><USER28> In Northern Europe, the subspecies Corvus cornix, hooded crow, is easy to tell apart from the raven due to its grey body parts. For this reason there is never any doubt what you see, but this also has imprinted the other body differences in my mind. I don't think it is hard to tell the black Corvus corone from raven due to this.

<comment><USER29> They are beautiful and it almost looks like silver. I loved seeing them when I was in Finland.

</comment></comment><comment><USER30> I've found this YouTube video:

[https://youtu.be/k9-wTnqIidY](https://youtu.be/k9-wTnqIidY)

more helpful, as it spends more time showing you both (and obviously you can hear the sounds).

<comment><USER31> I like how he pitches his wine video in the beginning.

</comment></comment><comment><USER32> An old English farmer with a strong Dorset accent once explained the difference to me:

"If you see a raven, and there's only one of them, that's a crow that is. If you see a crow and there's lots of them, that's a raven, that is".

Simple!

<comment><USER33> Shouldn't that be the other way round then, according to the article?

<comment><USER34> That's the joke.

<comment><USER35> I'm not getting it

</comment></comment></comment></comment><comment><USER36> There are also grackles, some of them mostly black, that are mistaken for crows.

Easier to tell the difference if you can gauge the size. This picture with a 1 foot ruler is helpful:

[https://www.dshs.state.tx.us/uploadedImages/Content/Preventi...](https://www.dshs.state.tx.us/uploadedImages/Content/Prevention_and_Preparedness/idcu/disease/arboviral/westnile/samples/grackle/blackbirds.jpg)

</comment><comment><USER37> Crows sound like "caw" or "ca-caw" and ravens sound like "nevermore"

<comment><USER38> Not "the N word!"

[https://wiki.lspace.org/mediawiki/Quoth](https://wiki.lspace.org/mediawiki/Quoth)

</comment></comment><comment><USER39> At the Grand Canyon National Park they told us that ravens are the only animal allowed at wolf kills; this is because they train wolf pups while the parents are off hunting so theyre recognized.

<comment><USER40> what do you mean by train wolf pups?

<comment><USER11> My guess would be that the ravens demonstrate effective scavenging behavior to the wolf pups. Interestingly, both wolves and ravens engage in observational learning of food acquisition behaviors [0].

I think most of us would assume that wolf pups have an innate scavenging ability; this is probably wrong.

[0] [https://pdfs.semanticscholar.org/aff0/dca479ca58868890d903cd...](https://pdfs.semanticscholar.org/aff0/dca479ca58868890d903cd8b1a25421cb4e4.pdf)

</comment></comment></comment><comment><USER41> A bigger challenge is to differentiate a Northwestern Crow from an American Crow.

> It is smaller than the American Crow and has a more nasal call, but it is so > similar that the two may in fact be the same species.

[https://www.allaboutbirds.org/guide/Northwestern_Crow/overvi...](https://www.allaboutbirds.org/guide/Northwestern_Crow/overview#)

I didn't even realize that my area had an apparently different crow than everywhere until I bought a birding book.

<comment><USER23> Actually, recent research indicates that these two species _began_ differentiating themselves a long time ago, but their lineages have since converged: they now interbreed freely and there's no reliable way to tell the two species apart: [https://twitter.com/dlslager/status/1072353359041085440](https://twitter.com/dlslager/status/1072353359041085440)

It's been really interesting to talk to birders I trust about this. The rough consensus is, most people think they're the same species and will get merged back together soon, but some are very attached to the distinction between the two, haha.

Birds are so cool! I think it's fascinating that we're still learning new things about this stuff all the time.

<comment><USER41> Hm the story from the posted tweet makes sense to me. Damn that is really cool.

</comment></comment></comment><comment><USER42> Sounds timely now that Games of Thrones starts again

</comment><comment><USER43> Wish I'd known this when I was randomly attacked by raven or crow in BC, then I'd only dislike one of them.

<comment><USER29> Just because you don't understand its reasons doesn't make it a random occurance. I'm guessing you were near a nest or a fledgling, but that's just my non-educated guess.

Another possibility is that you looked like a former 'enemy' of crows. Crows can remember people who mess with them for up to two years and seem to be able to communicate that information among their peers. There is an excellent documentary about that behavior and it may have even been about scientists in the BC area.

They wore masks to test whether the information could be passed down from generation to generation. They found one crow offspring that still recognized the mask its parents had been trained on.

I believe it was called "The Intelligent World of Crows". It was excellent.

</comment></comment><comment><USER44> French crows are bigger than English crows, and behave rather differently. An English crow on a pavement will hop out of the way of an approaching pedestrian, a French crow will stand there and look at you, as if to say "Yeah, do you want some?"

</comment><comment><USER45> This article pertains to North America. In Australia there is less distinction between crows and ravens. Australian crows/ravens are infamous for their loud and obnoxious call precisely timed to interrupt your afternoon nap!

</comment><comment><USER46> "Listen closely to the birds' calls. Crows give a cawing sound. But ravens produce a lower croaking sound."

Also, the raven is the only one that repeats "Nevermore!'

</comment><comment><USER47> Aren't ravens the birds with the Spy-vs-Spy behaviors?

</comment><comment><USER48> If on some midnight dreary there is suddenly a tapping, as of someone rapping, at your chamber door...

It's probably a raven.

Nevermore.

</comment><comment><USER49> I thought I could easily tell the difference till I read this article...

</comment><comment><USER50> I want to tell a raven from a writing desk.

</comment><comment><USER51> Ctrl-F jackdaw

...Here's the thing...

</comment><comment><USER52> that is the best comment section I've ever seen.

</comment><comment><USER53> Their website has Javascript which causes every single page to spend 3 seconds stuck at a white screen before showing content. Disabling JS makes content appear nearly instantly.

<comment><USER54> It seems to be just you.</comment></comment>