How 'DevOps' Is Killing The Developer - <AUTHOR> http://jeffknupp.com/blog/2014/04/15/how-devops-is-killing-the-developer/ <comment><USER3> DevOps isn't amount making Developers be Ops guys. It's about the fact that automation eats everything, and a significant part of 'ops' is now coding.

A DevOps person isn't someone who develops, and who does Ops. It's someone who does only Ops, but through Development.

It's not about start ups vs Enterprise, it's about 1 person writing programs or 5 people doing things by hand.

<comment><USER4> Was (Unix) ops ever not coding? I honestly don't know, I haven't been around that long. But all the old guys I know were "perl is unix duct tape" ops guys.

The older, more foundational problems were getting automated back then. Now that they're solved problems, and combined with more and more people running large and/or virtual infrastructure, a new problem domain exists around spinning up machines and deployment.

The current coding investment is infrastructure because it's the current pain point. In a decade (or whenever permanent solutions exists for infrastructure) the current way will be considered "by hand" and operations coding efforts will just move onto whatever problem is only visible now that infrastructure is no longer a time sink.

You can say that some ops is just admins running already existing software and operating everything by hand, but there will be admins doing exactly that in a decade too.

<comment><USER5> Yeah, I was never aware of a sysadmin who couldn't code.

Generally, a sysadmin has slightly different skills from a developer - <USER2> might code in a highly imperative style and always keeping the actual machine/system being targeted in mind, but I've never known a half-decent sysadmin who cannot write code.

<comment><USER6> The last time I looked for a senior sysadmin -- less than a year ago -- I didn't get anyone who was comfortable programming in Perl/Python/Ruby until I started using the term DevOps.

If that's the term the market wants to use, fine. As far as I'm concerned, a senior sysadmin who can't write in a couple of scripting languages isn't senior.

<comment><USER7> I consider myself a developer (though I call myself software engineer, due to the incompetence of other "developers" I work with).

I know a reasonable amount of sysadmin (all my computers run Linux primarily, I only keep Windows on for checking hardware issues, and a couple of specific apps I need to run once or twice a year).

I wouldn't apply for sysadmin jobs, because I wouldn't feel my knowledge is enough. I have however seen devops jobs that seem to match my skillset - developer with a bit more. I hadn't really heard of the term until I saw the job ad.

</comment></comment></comment></comment></comment><comment><USER8> The market is maturing. Take a look at a market that is similarly structured. Look at construction.

You have general contractors and then you have subs that work under them. A general contractor is a jack of all trades, master of none. Exactly what a full stack developer is.

This isn't the end of specialization. It's the beginning of project management steered by developers who intimately understand all of the work involved, even if they aren't as competent as the specialists.

Having a team consist of all full-stack developers is just stupid. Having a full-stack developer as the head on a project, with specialists on the team, is a great idea.

<comment><USER9> The joke is that what web guys call "full stack" is actually a small niche of software development.

<comment><USER10> Yup, the article also leaves out networking, where developers 'who can do the job of others' are usually the most blatantly incapable of not being able to do just that.

</comment></comment></comment><comment><USER11> Pure developers are a problem because they will the information do their job well.

I go back a few years, to an old, waterfall-like job. I was handed work by an analyst, that was handed a task to analyze by an engagement lead, who might at some point talk to someone using the application. The work was always handed out on time, but the product often failed, not because it was buggy, but because nobody actually had much of an idea of what we were really trying to solve.

So us developers got much work done, but the work didn't actually solve real problems: The force is applied to the wrong vector. Then the product fails, and the blame game begins: Changes are too expensive, because the developers didn't know what the real invariants are. Queries are slow, because the database architect wasn't told about the questions that the database had to answer. The business analysis just wrote documents. It was all a big catastrophe.

That company moved to Scrum, the terrible way: Here, have this self organizing team full of specialists that don't know anything outside of their domain. They are still failing to this day, but now they blame each other in retrospectives.

So I'd much rather be stuck coding less, but then being aware that my code is actually solving a problem for someone, than just writing castles in the sky, because everything I've been told about what my userbase needs comes from a game of telephone.

</comment><comment><USER12> You can't really draw a hard line between administration and development, in the end you are just building a system and the more you know about it from all angles the better design decisions you can make and the easier it is to fix issues.

I diagnosed a few problems over the years that arose as apparent issues with a web application but that I gradually narrowed down to things like network issues, or kernel bugs, or system misconfiguration, or database issues etc. Modern stacks are very complicated and the interactions can get really messy, it is close impossible for someone who doesn't understand the whole thing to find issues that aren't neatly isolated. I perfectly know that I do not have the full qualifications of a sys-admin proper, and would not like to do a sys- admin job full time, but in those particular cases a pure sys-admin would not (and often actually could not) find those issues. As an example, I can remember many situations where the application showed different behaviour depending on which application server you hit, and typically both "pure" developers and "pure" sys-admins were having a hard time finding the issue.

Good sys-admins anyway have to learn, at least, C programming, shell scripting, and network protocols and programming, so it's should not be a big deal to add some Rails/Django/Node to their skillset. Good developers anyway have to know things about hardware, networks, protocols and so forth. You do want to have people that are specialized in one or the other area and focus on it on a day to day basis, but you also do want to have people that can understand a particular aspect of the system top to bottom when such a need occurs, and it does happen quite often.

<comment><USER13> I don't know - I need to know the kernel, the shell, the hardware, networking, programming, all of the services that are in prod and automation tools and how to manage a code base. Now I need to learn how to write production quality code in Node?

I'm all for a tighter integration between Ops and Devs, and infrastructure-as- code can help bridge that gap, but I don't know that doing each others jobs is the solution.

<comment><USER14> Well, if the servers you are administrating run Node, you you do. Maybe not production quality, but you should at minimum know enough to read it and create a simple project.

At the plus side, you have quite a big deal of control over most of those variables.

</comment></comment></comment><comment><USER15> I think the idea is not necessarily to have developers run production systems, but they still should know what production looks like and at least have basic knowledge on how to configure all of the moving parts of the system.

Having developers be 'full stack' imho reduces the amount of "works on my machine". How would a developer test the software he/she is developing on if she can't at least get close to a production environment.

Automated provisioning is just one of the usual 'devops' things that I can't imagine how a proper software engineering process would work without.

I would say that at least 20% of the people I graduated with can create software that works mostly ok when they hit the little green "run" icon in Eclipse. They were however incapable of figuring out why their jar file doesn't work in tomcat on a linux server somewhere.

Usually it was because they're using a local database with root credentials instead of a remote Database with multiple users, they have some file stashed away somewhere in their classpath, they have some binary installed in $PATH that makes the whole thing work.

I think just wanting to be a developer and not know about the stack that your application runs on is like being a painter but refusing to buy paint because you can't see what going to the store has to do with painting.

<comment><USER16> It's more like wanting to be a painter without knowing how paint brushes are created. Ideally I don't need to know how a system is configured (to an extent, of course), I just write the code.

<comment><USER17> That, right there, is the attitude that leads to unmaintainable software. If you want the position of general contractor, then you'd better know how to interface with zoning authorities, draw architecture, and perform maintenance on your creation over time, or at least work _very_ closely with the people who do know and do care about that stuff. You are not above any of those things. Ever.

All too often I see feature developers say "well, I have an operations team, I'll let them figure it out," and they (a) never leverage said operations team for advice during development, (b) don't consider operational concerns such as sharding, deployment, logging, and monitoring at all during development, (c) file a ticket against operations with three weeks to go until their deadline to perform all of those things, and (d) call for rolling operational heads when their service does not perform to their expectations (using the author's "totem pole" as their rationale). As an operations engineer, I can count way too many fucking times I've been on the other end of that from developers with attitudes like yours. It is the absolute worst part of my job.

</comment></comment></comment><comment><USER18> As someone who has been doing DevOps for 20 years, since long before it was called "DevOps"...

First, DevOps has degenerated into a meaningless buzzword to rival "Agile", despite the good ideas and good intentions. Every day, I have recruiters looking for "DevOps". A couple of years ago, they'd never heard the word.

Second, DevOps is actually getting strongly biased toward Ops, often to the exclusion of Dev. In the eyes of recruiters and much of the industry, it's become synonymous with "Chef/Puppet/Ansible automation", a set of automation tools. That's stupid.

Third, and this is what matters to me... DevOps is (or was meant to be/should be) more about organizational structure than skills. As the author points out here, specialization is good and necessary. But specialization comes with bureaucratic compartmentalization that makes working across org boundaries very difficult. When you have to climb four or five (or more) layers up the org chart to find common management for both the dev and ops sides of a project, then the dev team has no authority over and very little way to communicate with ops, and vice versa. For most large organizations, the dev/ops separation is necessary - developers get locked out of production systems to keep them from legal exposure to customer data (HIPAA, PII, etc), and to keep them from accidentally or intentionally altering production in a way that it might break.

Read Gene Kim's excellent quasi-fiction book, _The Phoenix Project_. It covers a lot of the issues of DevOps as fixing communication patterns in large organizations. You'll see how little of it is about tooling or "full-stack", and how much is about clearing bureaucratic obstacles to effective communication.

</comment><comment><USER19> I found it very interesting that Facebook apparently hired programmers for all its roles in the early days - even e.g. the receptionist. I think the point that this article misses is that a 'devops' person - that is to say, someone with both sysadmin and development skills, whichever side of the fence they originated on - _can do the job better_ than someone who is "just a sysadmin" and incapable of programming. When you look at modern ops infrastructure like Puppet, you're looking at programs, written in programming languages, and it's foolish to pretend otherwise. So like it or not, you need to hire someone who can program to manage it. If you imagine you can get a cheaper non-technical ops person to handle this and save money, you're going to get inferior results.

I think this is going to happen to more and more careers. Already a profession like surgery or piloting a modern airliner is starting to require some of the skills we think of as programming. Software is eating the world - that doesn't make domain expertise irrelevant, but it means you need people with domain expertise _and_ programming skills. That applies to non-programming roles in the software industry just as it applies to other industries.

</comment><comment><USER20> "All too common a question now, can you imagine interviewing a chef and asking him what portion of the day he actually devotes to cooking?"

Yes. Chefs also do shopping, menu planning, prep, hiring, firing, marketing, and schmoozing with patrons. Source: I know a chef.

<comment><USER21> Exactly.

You have to ask whether you're talking about a senior executive ("Chef de Cuisine", "Head Chef", "Executive Chef"), a subject matter expert or mid-level professional ("Saucier", "Pastry Chef", "Line Cook"), a junior person ("Prep Chef"), or a low man on the totem pole ("Busboy", "Dishwasher").

"Chef" is a very vague term when applied to large restaurants. Obviously, in a little family owned place, a lot of these roles would collapse.

<comment><USER18> We could replace the chefs with puppets...

</comment></comment></comment><comment><USER22> This article is pretty ignorant.

I don't think most developers have the capability to be sysadmins or QA. Vice versa, too, quite often. Joe developer ain't _that_ special.

Devops is about taking moving the infrastructure into its own configuration- managed artifact, taking lessons from programming and computer science, and coming out with its own engineering rigor.

If you want your devs to operate builds/infrastructure/etc/etc, that's fine, but devops that ain't. That's called "many hats".

<comment><USER23> >I don't think most developers have the capability to be sysadmins or QA.

No, but they tend to think they can.

<comment><USER24> And/or they're pushed to do so.

</comment></comment></comment><comment><USER25> The author couldn't be more off-base is his understanding of how devops came to be, and his attitude is exactly the kind of cost-ineffective developer behavior that led to the partial unification of development and operations to begin with.

It has nothing to do with limited startup resources, and everything to do with _managing externalities_.

Specifically, developers have an enormous amount of control over the stability and deployability of their software: technical decisions made at almost all levels of the stack _directly_ and _significantly_ impact the costs of QA and Operations.

The people best suited to automating deployment and ensuring code quality are the people writing the code.

If you entirely externalize the costs of those two things , natural human laziness takes over, and developers punt bugs and deployment costs to the external QA and operations teams, ballooning the overall cost to the company.

</comment><comment><USER26> This is an interesting rant. I had never seen DevOps as being "for" developers. My impression has always been that it is sysadmins quest for a high degree of automation and streamlining that allows them to manage hundreds of systems without waking up in the middle of the night sweating. And when you're looking for a sophisticated tool to control something, you inevitably find yourself writing software.

</comment><comment><USER27> Because of an abnormal learning style, severely dyslexic, I have never fit in to corporate environments. Looking past the egregious spelling errors, being a slow learner isn't a winning talent in a job interview. As a result, I've fallen in to the trap of full stack (jack of all trades) developer consultant for a little over a decade now. I never got very good at anything in particular. Thus, I have battled with burn out for many years now, and am passively seeking another careers outside of Internet technologies. Point of the article is close to home.

The burnout aside, there is a plus to someone being proficient at many related tasks; having a somewhat in-depth knowledge of how all these technologies come together. The point is not all jobs require the best, most expert techniques. As in the case of the jack-of-all-trades carpenter, as long as he knows when to call the specialist, he is still getting the jobs, as am I.

</comment><comment><USER28> The author is missing the fact that good developers can actually _automate away_ a lot of those "lower on the totem pole" roles, or at least reduce the amount of repetitive stuff down to the point where the remaining work is quite abstract and basically just more programming.

This isn't counter to specialization -- in a big organization, people are certainly still going to specialize. But the "DBA" equivalent people are just programmers who have fresh expertise on the storage layer, and the "QA" people are just programmers who have expertise on the automated build and test systems.

The dentist analogy doesn't hold in software. A dentist handling secretarial work is just an expensive waste of time, due to comparative advantage. But a programmer _replacing_ secretarial work with automation often reaps big long- term dividends.

</comment><comment><USER29> The OP makes a relatively uncontroversial point (that people will be specialized, and better, at a finite set of skills)...so I think "killing the developer" is a little dramatic.

However, I think as with most things that involve computational thinking and automation, this is not a zero-sum game. A developer who can apply deterministic, testable processes to server-ops may be able to reap an adequate amount of benefit for significantly lower cost than a specialized sysadmin. In addition, the developer is augmenting his/her own skills in the process. Yes, that dev was not able to focus all of their time on...whatever part of the stack they are meant to specialize in...on the other hand, the time spent studying dev ops is not necessarily a sunk cost.

For my own part, I've tried to stay away from sys-admin as much as possible...but when I've been pushed into it, I've gotten something out of it beyond just getting the damn server up. For example, better familiarity with UNIX tools and the importance of "text-as-an-interface"...which does apply to high-level web development...nevermind the efficiency you gain by being able to stay in the shell when most appropriate (rather than, say, figure out how to wrangle server commands in a brittle capistrano script).

But hell, even the end product itself, just being able to deploy a server with some confidence...is kind of empowering. For me, it opens up new ways to run scripts and jobs...It sounds dumb and maybe it's just the way my brain poorly functions, but the concepts of server-oriented architecture become so much clearer when you can spin up different machines to play with and experiment with delegation.

</comment><comment><USER30> I don't really think a good developer can replace a good sysadmin. The reverse is true too, this is not a flamebait! :P

I don't see "DevOps" as a way to replace some roles - but as a way to make everyone work better together. Instead of living each in their own bubble (and in my - pretty limited I admit - experience it always) everyone has to know, at least a little, what someone else does. It really helps everyone at the end of the day. And the developer can keep coding without me screaming at him because he placed the database connection string in a configuration file that sits inside a .jar that sits inside a .war and so on.

<comment><USER31> It really helpful to have developers know at least a little systems administration, and vice versa. When doing web development at least there's a fair number of problems that you should just let a web server, caching server, database server or even the operation system handle for you. If developers no nothing about systems administration they sometimes solve non-problems.

I'm just a guilty as anyone else in try to write code to fix a problem that's better handled by existing infrastructure and servers. I worked on a project to deliver invoices to customers in downloadable form. In the end pretty much very thing was thrown out and I just need to write the authentication part, because the sys admins pointed out that the existing StringRay boxes could handle everything else ([http://www.riverbed.com/products- solutions/products/applicat...](http://www.riverbed.com/products- solutions/products/application-delivery-stingray/)).

It's not that it doesn't make sense to have dedicated developers and systems administrators, as the developer you just need to know enough to be able to talk to and understand the admins position and thoughts.

<comment><USER32> this is pretty much spot on. when you have strict separation of dev & "ops", you get what I would argue is bad service+stack design and wasted resources.

"devops" is having developers sitting with, understanding, architecting, and in the end programming solutions to what were traditionally ops/sysadmin problems. and operators sitting with, understanding and participating in service architecture, teaching about livesite realities, coding where possible, and appropriately buffering devs from noise on the livesite.

the unfortunate thing is that many companies swing the pendulum too far one way or the other. neither all devs nor traditional dev + IT/ops orgs are the best way to build a great product and run a world class service.

</comment></comment></comment><comment><USER33> In my own experience I don't think developers were ever pushed to become devops (as the article asserts).

Instead, about 40% what was called 'sys admins' were pushed to become devops. The 'sys admin who knew cfengine' became a 'devops person who knew ansible'. Deploys and cloud APIs just became another thing to automate.

The bottom 60% - the shit ones who got paid 120,000GBP to copy paste commands they didn't understand from word documents into Solaris 8 boxes in 2010 because they couldn't actually automate anything - left the industry.

<comment><USER34> from what I've seen, the term 'devops' is generally used to pay a developer less than you would otherwise while getting more from them. I'm not sure how the math of that works out, but based on what I've seen, that's what happens.

<comment><USER35> My average "devops" engineer is paid the same as the senior-level engineers within my company.

<comment><USER33> Ditto. DevOps is charged out at the same comparative rate Sys Admin was 10 years a ago. Which makes sense - it's boring work and not as many people want to do it.

<comment><USER35> Boring is in the eye of the beholder. The biggest challenge I've found is that very few engineers have the depth to even attempt the job competently.

Most engineers simply don't have a meaningful understanding of the internals of large-scale environments.

</comment></comment></comment></comment></comment><comment><USER36> I'm a terrible system administrator. Everything I've learned about it has come from necessity because _startups_. I don't want to be a system administrator and have no desire to be good at it. So I learn the minimum I need in order to get it to do what I need to do and hope that I've done it right.

I might only be slightly better than someone who's new to system administration only because I've written system-level code and understand operating systems and things of that nature.

However a good system administrator understands the entire architecture from a holistic point of view. They know the compiler switches to use, the run-time switches to tweak, the security implications of various configurations and all of the other details it takes to keep a cluster secure.

I often work well with a good system administrator to debug and optimize workloads due to the overlap in our skills. I find this to be the optimal relationship.

Learning and practicing system administration takes away from my ability to learn and be a better programmer (and the opposite is true as well). I don't know about most people but I find I can't be good at both. And I know which one I'd rather be better at (programming).

I don't think the author has hit the nail on the head but I agree that effective teams can't expect one person to manage an entire application from code to managing a secure deployment.

</comment><comment><USER37> DevOps is a rather overloaded term at the moment. I've seen it refer to any of the following:

\- Encouraging collaboration between your Dev, Ops, and QA teams, with some cross-training so they can work together better

\- Merging those teams under the same manager to try to improve that collaboration

\- Making your developers responsible for all those roles, and never hiring a dedicated sysadmin or QA engineer

I personally think any of those is _fine_. Startups will err toward having fewer people and all of them be developers, while in a larger company it probably makes sense to specialize more and make "DevOps" mean close collaboration between those teams.

Of course, I've also seen "DevOps" as a job title for what would have previously been a "system administrator" or "site reliability engineer", and I have much less patience for that. :) Occasionally I see a job posting for a role that is actually dev + ops, but most often a "DevOps" posting means "we need a sysadmin, but we don't think sysadmins are cool enough to work here."

</comment><comment><USER38> I work at a large enterprise company and for a while I was part of the DevOps team as a software engineer.

Some of our goals included:

       - Building the continuous integration/delivery pipeline

       - Moving codebases from one source control system to another

       - Creating programs/systems to automate tagging of builds

       - Automating the deployment processes of multiple applications onto non-production servers

       - Implementing and maintaining the functional testing frameworks and server grids

The more I look at these goals, the more I realize that the developers who work on feature delivery should not worry about these anyway. So I disagree that DevOps is killing the developer. In fact, DevOps is helping the developers focus on what's important.

</comment><comment><USER39> It's definitely more complicated than the post implies, and it most definitely is NOT only for startups. Soon after I started out - at a mature company already making plenty of money - I was a full-stack engineer. There were a number of reasons:

\- New development happened sporadically; day-to-day work was a mixture of maintenance development and admin work

\- Culture. They started with a small team, and never grew it. Having more people didn't fit with the way the company saw itself.

\- Difficulty hiring specialists. Various reasons for it, but still valid.

At another company I worked, there was a lot of "integration development", where your time was spent connecting various internal and external systems together, software-wise, developing tools that support systems work (i.e., tools for sysadmins), and developing other tools that are for end-users, but have a heavy systems component (management software for DNS, for example.) That meant understanding each part of the stack from both a development _and_ system perspective. Another is interest level. A few of us were full-stack developers because we were studied more than just development in our free time, and we took that with us to work. This wound up benefiting everyone. This also led to us being the go-to people (that is, the top level of internal support) for both more specialist internal developers _and_ sysadmins, as we had deep knowledge of the internal systems from the bottom to the top the stack, and the knowledge and experience to explain and troubleshoot problems to people in those other roles.

The author is correct in that this may be more /common/ at startups (the previous startup I worked at did in fact operate as the post describes), and is sometimes done out of necessity. It is by no means limited to those environments, however.

Edit: I'd also separate DevOps from full-stack engineer. They sound like the same thing, and if you squint from far enough away, they look like the same thing. The terminology may be fluid, but I think (as some other comments state), that DevOps is more centered around "coding for systems automation", whereas "full-stack engineering" is a much more general term which can encompass a variety of different types of tasks in different environments with _varying_ levels of knowledge/experience in the different parts of the stack/tools.

</comment><comment><USER40> I'm not so sure your usage of the term "full-stack engineer" is accurate here. I consider myself full-stack, but I don't know half the stuff about Chef that our DevOps guy does and I'm ok with that. To me, a full-stack engineer means that I'm capable of coding both things that make magic happen in the browser and things that make magic happen on the server side of the application. It doesn't mean I'm a jack of all trades.

That said, I don't think that the increased prevalence of DevOps is bad. And I don't think it means "everyone is doing everything" either. It's a new role that is borrowing elements from both development and operations. Not one person doing both roles.

</comment><comment><USER41> I think DevOps is very much a web-application thing (where web-application includes intranets, ... basically anything that speaks tcp). I seriously see the need there. I still remember the days when developers would build an application that worked on their system and then handed it off to Ops, hoping to never hear back from it. I interviewed developers that could not tell me which webserver or application server their company was running in production, even though capabilities and performance characteristics differ wildly. The DevOps role is trying to bridge the gap, it's the jack of all trades, that knows enough of every piece of the system to debug issues that happen at those boundaries. Is this DB problem a machine issue, do we just need new hardware? Is it an application problem (n+1 queries) and where could those be? How can I structure my stack in a way to hand of tasks to the place where they can be solved efficiently. The implementation of those solutions can be handled by domain experts, but someone needs to keep all those pieces from breaking apart at the seams. In the web world, that's the DevOps.

</comment><comment><USER42> I personally think DevOps is terribly misunderstood. I think the best way to describe DevOps to that it broke down the traditional Ops/QA/Developer roles into different roles, namely SRE, Platform Engineer, and Developer.

Developers take on the new responsibilities of being able to independently deploy their code, instrument and monitor stability and own test/QA.

Platform Engineering is about building a robust infrastructure and the tooling needed for Developers to handle the new responsibilities. This includes packaging, monitoring, deployment, AB testing, etc.

Site Reliability Engineering is about dealing with fires outside of the codebase. Hardware failures, network connectivity issues, etc.

I don't think any of these roles becomes a "Jack of all trades, master at none" situation. It does, however, cut out some of the more typical engineering roles. While developers just took on additional responsibilities, QA engineers and traditional Ops are forced to repurpose their skill set.

</comment><comment><USER43> "The underlying cause of my pain? This fact: not every company is a start-up, though it appears that every company must act as though they were."

DevOps is not about startups, DevOps is about avoiding the pitfalls of big companies who completely fail and leave all of their employees jobless by focusing on all of the wrong decisions and initiatives.

It's about outlawing cowboy coding and other bad habits that people pick up as hobbyists, and intertwining business and technical objectives reasonably.

Why is a full-stack developer important? Why is eroding the difference in responsibility between Dev, Ops, and QA important? Because traditionally along these boundaries have been opportunities for individuals to absolve themselves of responsibility. More than anything, DevOps is about not living in that world anymore.

Some people won't survive outside that world. Those who want to will read "The Phoenix Project" by Gene Kim.

</comment><comment><USER44> As someone who is moving into more of a devops role from a pure development role. Here is my learning list so far.

1\. The TCP/IP Guide: A Comprehensive, Illustrated Internet Protocols Reference. [http://www.amazon.com/The-TCP-Guide-Comprehensive- Illustrate...](http://www.amazon.com/The-TCP-Guide-Comprehensive- Illustrated/dp/159327047X/)

2\. Advanced Programming in the UNIX Environment [http://www.amazon.com/Programming-Environment-Addison- Wesley...](http://www.amazon.com/Programming-Environment-Addison-Wesley- Professional-Computing/dp/0321637739/)

3\. A systems programming language- I choose golang.

4\. GDB/makefiles

5\. SSH, The Secure Shell: The Definitive Guide: The Definitive Guide [http://www.amazon.com/SSH-Secure-Shell-Definitive-Guide- eboo...](http://www.amazon.com/SSH-Secure-Shell-Definitive-Guide- ebook/dp/B006H4GA0M/)

<comment><USER45> If you like the Stevens, his TCP/IP Illustrated is kind of a 'bible'.

Also, not sure what you're getting into but usually for sysadmin for scripting you need to know one of: Bash|python|Perl|Ruby

</comment></comment><comment><USER46> From my point of view, this is due to lack of tech education. There just are not enough people graduating/learning the technical skills necessary for medium to large size software companies to employ.

I am a manager/developer/architect at a relatively large software company, and we have to task our developers with devops-type tasks constantly. Not because we want our developers spending time outside of coding, but because for lack of ability to hire the competency needed.

As you stated, good developers can generally perform these tasks so when you have nobody lower to perform them they become a weight on the developers' shoulders.

No it isn't necessarily fair, and yes, I believe in the future specialization will come back as the education system starts to realize there are many jobs in tech, not just a Comp Sci degree jobs.

<comment> at-fates-hands >>> Not because we want our developers spending time outside of coding, but because for lack of ability to hire the competency needed.

This is known as the "odd man out" syndrome. I currently work in a medium sized company who are doing a huge ERP switch over. I'm a front-end developer by trade, but know .Net as well. One part of the contract stated our company needed to have X amount of company resources (people) to have on the project.

Guess who the "odd man out" was? Yup, that's me. The last three months, I think I've written 10 lines of javascript, a dozen or so .Net classes and spent the remainder learning JDE development on the fly. Now you have to ask yourself, is there something beneficial to me learning JDE? Nope, not even close. It's on the complete other end of the spectrum in terms of skills. The only reason I'm doing what I'm doing is because of what you said - the company had neither the desire or want to hire a JDE Developer. They just thought they'd throw me in the mix since I have "developer" in my job title.

The downside is I hate my job now and am actively looking to get out of here. They told me recently after the release, I'll be one of the ongoing "resources" to help manage post-release defects.

So I agree on your last point as well. It's not fair and unfortunately, it's a no win situation for the developers. If I do a shitty job as a JDE developer, they get pissed and might evenutally fire me. If I do a good job, then I get tasked with all kinds of stuff I have neither the want or desire to do.

Six months in and I hate working in JDE but all the contractors think after two weeks I should be a pro with it since I'm a "developer".

</comment></comment><comment><USER47> DevOps, at least imo, is not about technology. It is about culture, and applying practices to speed up the various loops across organizational groups (marketing, sales, developers, ops). Of course there will always be trade- offs, if you don't have the budget to hire both an expert in the technologies that, say for example, speed up configuration management, and prevent snowflake servers AND someone to develop the code for the product, the person you do hire, will have to either pull double duty, or the org will have to plan for the fact that it is probably going to be doing "stuff" slower.

</comment><comment><USER48> "If you are a developer of moderately sized software, you need a deployment system in place. Quick, what are the benefits and drawbacks of the following such systems: Puppet, Chef, Salt, Ansible, Vagrant, Docker. Now implement your deployment solution! Did you even realize which systems had no business being in that list?"

I'm not understanding this, you can deploy with Puppet, Chef, Salt, Ansible, Vagrant and Docker. With Vagrant you can deploy a bare image and use Chef (or one of the others) or you can just deploy a fully setup box file (like with Docker).

<comment><USER49> I hope I'm not actually expected to know what any of those is.

<comment><USER50> If you're a developer and want to stay relevant I suggest you read up.

With distributed systems becoming the norm rather than the exception, developers will need to understand how and where their code runs in production (and how it gets there) to be able to debug issues or write better behaving code.

<comment><USER51> This may be a simple oversight and I hope I don't sound too pedantic but you may need to broaden your definition of developer a bit. Developers who work on OS, games, embarked systems or professional applications (think CAD) are not very likely to need these anytime soon. More knowledge is always good so I'll check some out anyway!

<comment><USER50> You're right, I should've narrowed the scope to client-server or perhaps "the web" (although the exact lines are blurry).

</comment></comment></comment></comment></comment><comment><USER52> Are any other companies besides (well funded) startups actually hiring people as "full stack developers"? I mean, yeah, it's normal to look for candidates with _full stack experience_ , but not to hire them in an actual _job position that requires them to do full-stack work_... it's a big difference.

(sorry if the q is off topic, I don't really understand what OP is ranting about with the devops problems, so I'm referring to the only part of the article that makes any sense to me, that about the full-stack devs...)

</comment><comment><USER53> It's not so much that DevOps is killing the developer as it's the expectation that you can have your regular general purpose developers do your DevOps on the side.

I can relate to the downsides pretty well - I'm the only developer in my group and my job is mostly to develop web apps, but the IT side doesn't have much knowledge of modern tools - they live in the era 'just use Drupal and Apache' so I'm often the one who ends up having to figure out the deployment of the applications I work on (and also help with random problems from their OTB apps) and such.

To be honest, I don't mind when it's DB stuff because I'm pretty comfortable with it and have plenty of background with various SQL DBs, and it's not a time black hole, but when it comes to configuring servers and deployment I hate having to deal with the DevOps because there are so many pieces I never have the time to really become comfortable with them all and I feel very inefficient. Accomplishing something doesn't always take long itself, but it can require spending a day of reading wikis and documentation to accomplish something simple when you've got a lot of moving parts. And the worst part is that you have to deal with the DevOps bits so infrequently it's like you have to relearn them each time.

</comment><comment><USER54> +1 I don't agree, but an interesting article anyways.

I have worked with DBAs who had PhDs and could have still done development, but they moved past that to concentrate on schema development, scaling, etc. Toss into the mix modern programs of master data development inside organizations and people who are characterized as DBAs have a very sophisticated role.

Also, for small projects, devops makes all the sense in the world to me. Deeply understanding how an entire system works is valuable.

</comment><comment><USER55> Full-stack doesn't mean being a 'god of all things', except that it does in fact mean exactly that.

It means that no part of the stack goes not understood, or .. all parts of the stack should be understood and controllable by the developer.

Guess what - this doesn't produce 'worse developers' .. it produces better stacks. The fact is that the fracture and delineation between the _cultures_ of code, rather than the actual code itself, is the true danger. Getting 'the db guy' to talk to 'the front-end guy' is a posers game. Get rid of it.

Instead, get your guys to move across the tree of responsibility that a full- stack approach requires. In truly professional development, there is always going to be new things to learn and new things to use to manipulate the machines - this is turned to an advantage in the full-stack approach since it requires an adherence to a real policy: you just don't care about 'the culture of the tech', you read the docs, you write the code, you read a hell of a lot of code, and you don't really put limits on what you can and cannot understand; those limits are instead expressed in working code, at any layer of the stack. The 'cultural excuses' for why things are borked 'over there' are no longer relevant in this approach; if you're a real full-stack guy, you'll get along - source or no source, but hopefully: mostly always with the source.

It is a political approach, but it works - especially in industry. There are a few other principle-based disciplines in the world where an 'all-embracing' privilege exists, in this case we are lucky that computers, as grand engines of word and significance, are a form of literature. Study well, and study all .. to the end!

</comment><comment><USER56> > ...the old "waterfall" develop-test-release cycle is seen as broken.

Waterfall is not just _seen_ as broken, it was always broken.

<comment><USER57> Agreed. The concept of "waterfall model" was given form by Winston Royce as a strawman for an argument he was making in an article, and it's disingenuous to say that it was ever a promoted model on its own merits.

I prefer to think of it as the consequence of software development being tacked onto most other existing processes, without regards for the practical needs of software development.

<comment><USER58> You're talking about the original waterfall model. But waterfall as a way of developing software in phases that tended to be long and were not amenable to changing requirements was in fact practiced in most enterprises for many years. And, while not the most efficient process, it certainly did deliver good, working software. Just not efficiently. Phone switches, manned space flight, most businesses all ran on software developed this way.

</comment></comment></comment><comment><USER59> Overspecialization is the source of a organizational smells in a lot of medium-sized engineering companies - a lot of times it's better to have generalist engineers with some specializations in what you need to do than a bunch of specialists for a bunch of reasons, among them:

\- (pure) Specialists often don't understand how their decisions affect other systems (and middle management or communication isn't always a solution)

\- (pure) Specialists tie you to a particular technology when in reality you may need to evolve to use other technologies.

\- If you need a bunch of different specialists to get something simple done (perhaps something you don't do all the time so don't have a process in place), just because they are siloed, it's a lot more complex and usually ends up badly designed (because it's harder to be iterative across teams). Generalists can get simple things done that require different skill sets to accomplish.

<comment><USER60> I will disagree with you on your first point. One of the characteristics of specialists is that they know in practice how the software in which they specialize interacts with other software, where a generalist might not. For example, most specialists in any performance-critical software are pretty intimately familiar with the behavior of the Linux kernel when it comes to things like I/O scheduling and cache eviction, because of how it affects their program of choice. Generalists, on the contrary, rarely know any part of the system in enough depth to be able to quickly diagnose such problems. Often companies without suitable onsite expertise will reach out to specialists in these situations to resolve such problems.

I'll agree with your second point, to some extent. Generalists are rarely tied to any one technology and therefore can be very good at getting your organization to use the right tool (avoiding the common "hammer-nail" problem). However, just as frequently, I see generalists picking the _wrong_ tool for the job, because they again aren't intimately familiar enough with the tools already at their disposal to understand all their capabilities or be able to make an informed decision about whether the gains of the new tool are worth the added complexity of introducing another layer to their stack. And, of course, nobody feels the pain of adding extra layers to the stack quite like DevOps do.

I'm not sure what to make of your third point. Isolated processes talking to each other is just a different strategy from a monolithic design. There are advantages and disadvantages to each. It's unclear to me that monolithic means "better designed," and in fact there are good security arguments to the contrary. But maybe I'm misreading what you're saying.

</comment></comment><comment><USER61> It seems like the OP is advocating the surgical team [0] approach to software development. This seems very consistent with DevOps. Have a group of specialists that are good at automating operations surround the key developers.

[0] [http://c2.com/cgi/wiki?SurgicalTeam](http://c2.com/cgi/wiki?SurgicalTeam)

</comment><comment><USER62> I think there is a lot miss understanding here, to me DevOps is not just automation (we've had that for a long time, Perl, cron, cfengine etc).

It's much about applying the same processes you would apply in development to Ops. For example committing changes into version control and only using that, not live patching things, much like you wouldn't live edit a website.

Also being able to spin up new servers based on a config and not requiring manual config to get it going. Automation alone does not get rid of 'snowflake servers' [http://martinfowler.com/bliki/SnowflakeServer.html](http://martinfowler.com/bliki/SnowflakeServer.html)

Also, it can be about letting developers get the exact same environment for development/testing at no additional time cost - which in turn makes it more like that code changes can go live without problems or delays.

</comment><comment><USER63> IMO, Amazon gets 'DevOps' right. It's mostly just called 'ownership' over in Amazon. (source: I used to work in Amazon as a systems engineer)

You still have specializations - SDE's, systems engineers, DBA's, etc. However, if you write code and it ends up in production, you are responsible for the proper function of that code in production. As a friend of mine put it in terms of developers who don't want to be on-call: 'what, you don't trust the quality of your code?'

DevOps is simply a nicer way of just saying, "own your damn code." The corollary to this is that the organization must help you in getting to that state where you can effectively own your code - this means collaboration (so that you build maintainable systems) and building tools that enable fairly frictionless code ownership.

<comment><USER64> I've worked among devs who don't want to own their code in production, they'd rather just code and then throw new code over the wall for the sys admins to deploy.

The anti-DevOps developers don't understand how databases work so they want an ORM to make it easy for them, and they don't know how to configure a web server so they want PaaS solutions to let them do 1-click deploys, and system command prompts are scary to them. Frankly such developers just plain suck. They don't like DevOps because they don't have the skills to be DevOps.

</comment></comment><comment><USER65> I disagree with the central thesis of his argument that being generalized is a detriment and that operations and other factors should remain siloed at your average large company. I've worked at both large companies (10k+ employees) and small companies and many things in between.

In general a Full Stack DevOps oriented approach always tends to be more efficient. You have less monolithic hard to maintain applications because you force the teams to be small and agile. People will have their specialties (operations, backend, frontend, etc.) but still remain generalized enough to have an idea of the big picture. If your application has issues where the frontend developer doesn't know the general idea of how Varnish and Nginx in your stack are setup then perhaps your application is too big and complex.

</comment><comment><USER66> The description of DevOps from the article describes what I do at a large multinational software company really well. In our project we have 5-7 developers who test each others code and functionality and one DevOps who does build/test environment, databases, release management, change management, impact analysis with regression testing, and fixes bugs, but rarely develops new features. It's being done not because of the startup culture, which we do not have. It's done for efficiency. Every request to the DB team, even minor, will take at least three days to process. We do not have so much time to waste, so we have to do everything ourselves, unless it's something that requires an actual expert in the particular topic to accomplish.

</comment><comment><USER67> I couldn't disagree more about his portrayal of DevOps. There are companies misusing any and all paradigms of development. Google "cowboy coding agile" to see what I mean.

When I think of DevOps, I don't think of having everyone know everything. Ops staff have to know enough code to write deployment automation scripts and dev staff need to know enough system administration to step up and help when the monitoring or deployment automation breaks.

It's meant to be a partnership to maintain a system rather than the old practice of throwing code over the wall. It really harms morale to have the developers all enjoying wonderful weekends while ops is on red alert because app changes they don't understand broke everything in production.

</comment><comment><USER68> This article pretty much resonates with my experience, except that my employer (a 4 person established company) can't afford to hire a QA and sysadmin alongside my role as developer.

The bad side is that doing this DevOps role across multiple projects at the same time can lead to burnout, and I think I came close to that in the last few months.

The good side is that I've learnt a great deal about how to architect and deploy distributed web systems, how to do end-to-end testing, and how to effectively run the ops side of the business.

It's a mixed bag, and the burnout is the worst aspect of it, as well as the case where people are forced into situations where they are way in over their head.

<comment><USER69> Nothing wrong with burnout. You'll go get yourself a better job once you wake up from it. Established mom/pop shops are the best way to break into an industry but a terrible dead end for your career.

</comment></comment><comment><USER70> Related: I'm curious if 'full-stack' devs find themselves making more money than 'half-stack' devs. After all, you're doing more as part of your job, and you're a chimera.

If not, then aren't you being taken advantage of?

<comment><USER71> I'd slay a chimera before I'd pay a chimera.

I'm curious to know how specialists negotiate for pay or write a resume if that isn't their specialty.

</comment></comment><comment><USER72> I love this article and couldn't agree with it's central premise more. I can think of no other industry that demands an individual wear as many brain intensive hats as that of the developer today. These jobs which used to be distributed are quickly becoming the baseline for how an individual applicant is judged. I for one believe that if we focus, we can become a true master of skill AND compile that with understanding of the "whole stack" but never being forced to maintain more than our fair share of that stack.

</comment><comment><USER73> In the same way that being able to cook dinner doesn't make me a chef, while it's true that a developer can be a sysadmin, QA or DBA, they won't do a very good job.

To suggest otherwise shows a complete lack of understanding of the nuance of those roles.

As for suggesting that "DevOps" is killing the developer - the only thing "DevOps" is doing is polluting our common language with a term that doesn't actually mean anything concrete. It's perfect consultant speak.

</comment><comment><USER74> As a developer of course it's tempting to agree with the author's hierarchy. Masters of the IT world! But really it's over-simplified. As a dev with many years of experience there's no part of the stack I can't work in and figure out what I need to do. But that doesn't replace actual operational experience and oversight. You make do in startup or small team because you have to, so I guess ultimately I agree with the piece.

</comment><comment><USER75> Before you start to complain, I am a fan of collaboration but Devops might just be the best joke ever! The truth is it means something different to every person. For years I have defined Devops as Engineers trying get Ops out of the way and pushing forward with out those pesky sys admins. Your think I am over blowing it? I have been in the Silicon Valley for the boom of Devops and I hear it all the time "We dont need ops, we can just have a developer do it". The number of new startups who use AWS thus allowing them to forgo a system administrator never ceases to amaze me. My biggest problem with this is your cutting the legs out from yourself, but your assuring me job security so maybe I should keep my mouth shut. I have been a a operations engineer for over ten years now, and honestly developers and ops engineers have different ways of functioning. To me a good software engineer has long term focus, can get deep into a project and crunch on the same code for extended durations. Give a good coder a project that will take weeks or even months and they will put there head down and solve your problem. As a generalization these people do not handle interrupt driven work well, they also often do not handle high pressure situations well. Operations people on the other hand do the majority of their work under massive interruption and constant pressure. Tell a operations engineer the site is down and they will not focus on what the origin of the problem is, they will focus on getting the product back online and come back to fully understand why. This does not mean they do not troubleshoot but they are trying to identify the immediate cause not the who or root. One might argue this is short sited but when your stuck waiting for someone to figure out why the web severs where started your killing your customer experience. I would argue restart the web pool get the product back online and then start to look at root cause once you have identified the customer impact problem and completed the shortest path solution. When you start off by having your engineers run operations you never allow new ops people to start from ground up and develop their skills, learning the pain points as the system grows thus ensuring when you grow to the point that you need a operations engineer the is a shortage of trained people available. One might argue that some of the developers that started the company by running operations will become your operations engineers and will cover this but to me thats like using a vice grips to remove a bolt.

</comment><comment><USER76> This is a really badly written article but I know the point he's trying to make.

DevOps is stupid because it fractures expertise and makes it more difficult to get work done. By splitting up roles you get more domain-specific knowledge, have more time to work on a single problem, and provide support for your co- workers who also have different specific roles. I would much prefer to work with specialists than generalists.

</comment><comment><USER77> While I get the need for page views, I really wish problematic aspects of any tech movement could be discussed in a way that actually improves things rather than tears them down.

You hate _xyz_? OK, but apparently _xyz_ has enough merit to get the attention of quite a few people, so let's identify the problem areas and make _xyz_ better rather than resorting to hyperbole and melodrama.

</comment><comment><USER78> The role of DevOps is to help developers work more efficiently, not give developers more work to do. An example of this could be a TFS administrator who works on TFS build template changes and configuration to make the build and deploy process as automated as possible. Nothing to do with being a startup, or trying to get more work done with fewer people.

</comment><comment><USER79> The problem with DevOps is that it's a meaningless term. Look at all the comments here, all starting off with what "DevOps is," or "Devops isn't." Instances of people arguing past each other based on different interpretations.

You can't have a fruitful discussion when everybody uses it differently.

</comment><comment><USER80> Every place I've seen DevOps, seems that developers bear the brunt of the work - learning the infrastructure and understanding deployments and such. I've never seen Ops people learning the codebase or even the software architecture / data structures.

Maybe that wasn't true "DevOps"?

</comment><comment><USER81> _> Large companies love this, as it means they can hire far fewer people to do the same amount of work._

But they cost much more as well. Following that logic, it would be in the interest of hospitals to make "full-stack-doctors" clean toilets.

</comment><comment><USER82> "As a sysadmin, I would like developers to pay any damn attention to what happens in live before deploy without me having to cattle-prod them into doing so after deploy, so I don't have due cause to set them on fire."

</comment><comment><USER83> Interesting. I always thought of "Full-stack" developers from a web perspective being capable of coding from the client to the server. Never thought of them being devs that do ops also.

<comment><USER40> I think the definition of full-stack in this article is fundamentally wrong. I say that as a full-stack engineer. heh.

</comment></comment><comment><USER84> What non-startups are trying to hire jack of all trade generalist devs?

</comment><comment><USER45> I'm glad to see that most people here are replying objecting that the writer's view or definition of a DevOps is not what seems to be the most accepted/popular view.

</comment><comment><USER85> It's interesting to see how the term devops is stretched to mean anything you want. This term should die because it confuses many.

</comment><comment><USER86> Show me a developer who can do anything in Operations and I'll show you someone who gets the DevOps philosophy.

</comment><comment><USER87> I love the dentist example. Imagine if dentists were treated like developers. It'd be hilarious!

</comment><comment><USER88> Similar title: How Buzzwords Are Killing The Developer

... because DevOps is just a buzzword at this point.

</comment><comment><USER89> The author needs to read or reread The Mythical Man Month. Even in a large organization there are important benefits to having fewer people on a team. Even if this means that someone is sometimes doing work that they are overqualified for.

He makes some good points but he misses the value of needing fewer people to accomplish the same thing.

</comment><comment><USER90> Most coders I see would be useless as sysadmins...

</comment><comment><USER91> Hmm. Let's just ask the guy that took the Penny Arcade DevOps job.

</comment><comment><USER92> To much scepticism.

<comment><USER93> I doubt it.

</comment></comment><comment><USER94> The guys is missing the point by 10000 miles. DevOps is about getting together with devs and focus on best practices from day one. Keep in mind that you need to deploy your software in a timely, reliable manner, that is going to run on a network of computers, where part of your system might be down or showing elevated latency. I could not believe how non-trivial were these things until I have seen it with my own eyes that most of the software out there still has the following assumptions: zero latency network with unlimited bandwidth, uptime for servers is 100%, memory and CPU is something you can keep adding to computers. My experience is that when people are talking about DevOps what they really mean is site reliability or systems engineers, people who understand networks and operating systems in depth and can read and write code yet they primary focus is not deliver customer facing services, more like develop tools which can improve deployments, automate error prone processes and optimize/tune operating systems for better performance. In my humble opinion is that developers should be aware of the architecture of the system they are writing software for, but it seems we need another breed of engineers who are more focused on that as of today. Lets call them DevOps... :)

</comment><comment><USER95> It seems to me that the OP's real objection isn't to "DevOps" but with the reality of the software industry. He's upset that developers often are asked to do "lower" work. I find that a bit simplistic on his part. If anything, DevOps at its best is about elevating the ops work (by recognizing automation possibilities).

The issue is that employers are horribly inconsistent. They demand specialism in hiring, but refuse to respect specialties once they've pulled people in. Thus, you end up having to interview like a real computer scientist, only to find that most of the work is mind-numbing for a serious programmer, but that there's no one around at-level for it because "we only hire A players".

DevOps didn't do this. The problem is the industry, not one concept.

</comment><comment><USER96> tl;dr: there's a problem here in software, and I don't know what it is, lets fix it by acknowledging its existence and then going back to what we normally do.

</comment><comment><USER97> There is no content here. Why are people explaining themselves and upvoting this nonsense?

<comment><USER96> YCombinator is like a reverse link aggregation for businesses. Instead of readers coming to this site for information, people troll with their latest business bullshit and expect free solutions in the comments.</comment></comment>


Ask HN: Do you want to talk someone who is very different than you? - <AUTHOR> Do you want to talk someone who is very different than you?
If yes, please share here or via https://goo.gl/forms/X7QeGn3BuT4Is2pt2:
- a bit about yourself
- roughly who you'd like to talk to
- if/how much you'd be willing to compensate the person for their time
- preferred medium (online chat, phone, video)
- contact info for me to get in touch with you off-thread
I'll recruit folks online and play matchmaker for this little private-AMA experiment. I'll make sure to confirm with you before making any intros.
The motivation is that many of us rarely talk to people who are very different than ourselves and this leads to lots of misunderstandings, alienation, and destructive tribal behavior on both sides. Obvious h/t to @sama's post about the election https://news.ycombinator.com/item?id=12728249.
Personally, I worked in social services for the last few years so had the great opportunity to peak outside my personal bubble. And not just politically...for example, about HALF of all Americans can't come up with $400 in an emergency without going into debt[1] and in my day-to-day life this ubiquitous experience is basically invisible to me.
Thanks all and looking forward to hearing what you think.
[1] https://www.federalreserve.gov/econresdata/2014-report-economic-well-being-us-households-201505.pdf <comment><USER2> This is a neat idea. Some thoughts:

Maybe there are already other projects like this?

Maybe it could use some kind of taxonomy of whom you might get to talk to?

Maybe it could use some kind of ground rules about confidentiality? (or am I being too paranoid?)

Maybe it could use some kind of advice for people's ensuing conversations? (or am I being too pessimistic?)

<comment><AUTHOR> Thanks, @schoen.

Good points and I agree all around - just wanted to keep it as lightweight as possible to start.

I did a bit of searching first and didn't find much. Something like chatroulette.com has similar features but doesn't quite hit the mark of a respectful, private-AMA. Let me know if you see anything else.

</comment></comment><comment><USER3> this is a great idea, congrats. reminds me of a project where people intending to learn English could speak to elders and seniors living in a retirement house. Will follow up. Thanks, M Matos

<comment><AUTHOR> thanks - yes I've heard of that one! Great example of the internet promoting human connection...

Hope I can find you an interesting conversation :)

</comment></comment><comment><USER4> No thanks! I talk all the day to marketing people. That's more than enough for me.

</comment><comment><USER5> awesome idea, is the compensation required to be money? or it could be an exchange of knowledge?

<comment><AUTHOR> No need for cash compensation, though since I'm just doing this for a few people I probably won't be able to match based on specific learning/teaching areas. If it's a matter of logistics I'm happy to accept paypal/venmo and just send the other person an Amazon gift code on your behalf.</comment></comment>


Knuth: Programs to Read  - <AUTHOR> http://web.archive.org/web/20080123223429/www-cs-faculty.stanford.edu/~uno/programs.html

<comment><USER2> Why the archived version?

See the recent one:

<http://www-cs-faculty.stanford.edu/~knuth/programs.html>

By the way, Donald Knuth uses Emacs to write TeX :-)

<comment><USER3> There is an interview where he explains what he likes about Emacs:

 _I have special Emacs modes to help me classify all the tens of thousands of papers and notes in my files, and special Emacs keyboard shortcuts that make bookwriting a little bit like playing an organ._

Probably one of the few rational vi/emacs arguments I've seen. And it also is a good reason why I like vi, given that I can barely hit two keys on a piano at the same time.

(Link to interview: <http://www.informit.com/articles/article.aspx?p=1193856>)

<comment><USER4> _...and special Emacs keyboard shortcuts that make bookwriting a little bit like playing an organ._

A bit of trivia: Knuth has actually studied the organ--in fact, he has a pipe organ at his home:

<http://www-cs-faculty.stanford.edu/~knuth/organ.html>

</comment></comment></comment><comment><USER5> Too bad all the links on that page are dead.

<comment><USER6> Untrue.

<comment><USER5> Well, I must admit I didn't try _every_ link so perhaps one of them might be valid but lets see what happens when we try the first few:

      cweb - The requested URL /~uno/cweb.html was not found on this server.
      Axioms and Hulls - The requested URL /~uno/aah.html was not found on this server.
      Computer Musings - The requested URL /~uno/musings.html was not found on this server.

Don't waste your time with this page, use the one dimitar posted instead: <http://www-cs-faculty.stanford.edu/~knuth/programs.html></comment></comment></comment>


NEAR Protocol – The global computing platform for the Open Web - <AUTHOR> https://near.org <comment><AUTHOR> [https://github.com/nearprotocol/nearcore](https://github.com/nearprotocol/nearcore)

> NEAR's purpose is to enable community-driven innovation to benefit people > around the world.

> To achieve this purpose, NEAR provides a developer platform where developers > and entrepreneurs can create apps that put users back in control of their > data and assets, which is the foundation of "Open Web" movement.[1]

> One of the components of NEAR is NEAR Protocol, an infrastructure for > server-less applications and smart contracts powered by blockchain. NEAR > Protocol is built to deliver usability and scalability of modern PaaS like > Firebase at fraction of prices that blockchains like Ethereum charge.

Nightshade: Near Protocol Sharding Design (July 2019)

Alex Skidanov @AlexSkidanov firstname.lastname@example.com

Illia Polosukhin @ilblackdragon firstname.lastname@example.com

[https://near.org/downloads/Nightshade.pdf](https://near.org/downloads/Nightshade.pdf)

[1] [https://techcrunch.com/2016/04/10/1301496/](https://techcrunch.com/2016/04/10/1301496/)</comment>


Ask HN: Google Chrome heuristic warnings pose threat to our business - <AUTHOR> Many businesses use our Enterprise File Sharing Product called FileCloud (http://www.tonido.com/filecloud). Think of it as a self-hosted alternative to Dropbox.  With the latest Chrome update, the browser is showing phishing warning (http://patch.codelathe.com/foruser/phish_1.jpg) with our installations.  The warning is not based on the domain and it appears in our different customer installations. It has to be heuristic based because it generates warning even on a debug/local webpage. The chrome browser heuristically decides our login page as a phishing page and gives the wrong warning. We are trying to find if there are any published "guidelines" as to legitimate web pages should NOT be doing to trigger these? Either there should be clear methods to resolve these warnings or Chrome should avoid doing this blanket-so-called-protection racket. Because of Google's missteps, our reputation as well as customer reputation got a hit. We have spent countless hours in our resources to see what is going on and all thing points to heuristic decision making by Chrome browser.  There is no way to contact Google Chrome team to resolve this issue. We have lost few large deals. Now all our support team is pretty much focused on this issue and fielding queries from our customers. Since our UI code (Developed in GWT) is common between our Enterprise and Consumer product (Tonido), if we this error start appearing in our consumer version (half a million users) it is an EXISTENTIAL RISK to our company that we have built over 5 years. We have 2 questions. 1.	How to get in touch with Chrome team and solve the issue? 2.	Are there any legal avenues or precedence to force Google to take action and claim compensation for lost business? Please provide us with your suggestions. P.S:  It is happening to our software today. It may happen to your products tomorrow. <comment><USER2> I just ran into this with some pages in our product as well. If you run Chrome with '\--enable-logging --v=2' the chrome_debug.log will contain messages from the phishing classifier (search for 'phishing_classifier'). I was able to tweak the wording on the page to drop the score below 0.5, but there are other features that may be causing your problem.

You may need to restart the browser between edits, as it seems to cache the classifier results by URL. It also skips classification for hosts with private IPs, I had to jump through some hoops to test.

<comment><USER3> Very nice! This will actually be very helpful in tracking this. Thank you.

<comment><USER3> Here is the output snippet. Basically some "algorithm" thinks it has found phishyness with some score above 0.5 and flags it. No clue as to what caused it (We know that it can be triggered by simply changing the name of the "Login" button to "Connexion"!!

Must be nice to dream up some "algorithm" and push it out.. sigh

[5570:1799:0701/133949:VERBOSE1:client_side_detection_host.cc(221)] Instruct renderer to start phishing detection for URL: [http://dev1.codelathe.com/ui/core/index.html](http://dev1.codelathe.com/ui/core/index.html) [5579:1799:0701/133949:VERBOSE2:phishing_classifier_delegate.cc(238)] Not starting classification, no Scorer created. [5579:1799:0701/133950:VERBOSE2:phishing_classifier_delegate.cc(238)] Not starting classification, no Scorer created. [5570:1799:0701/133954:VERBOSE2:client_side_detection_service.cc(255)] Sending phishing model to RenderProcessHost @0x7aa18a00 [5570:1799:0701/133954:VERBOSE2:client_side_detection_service.cc(255)] Sending phishing model to RenderProcessHost @0x8043d620 [5579:1799:0701/133954:VERBOSE2:phishing_classifier_delegate.cc(283)] Starting classification for [http://dev1.codelathe.com/ui/core/index.html](http://dev1.codelathe.com/ui/core/index.html) [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: UrlTld=com = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageImgOtherDomainFreq = 0 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: UrlOtherHostToken=dev1 = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: UrlPathToken=html = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageLinkDomain=tonido.com = 1 [5574:1799:0701/133954:VERBOSE2:phishing_classifier_delegate.cc(275)] Not starting classification, last url from browser is , last finished load is chrome-extension://jpjpnpmbddbjkfaccnmhnkdgjideieim/background.html [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: UrlPathToken=core = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageTerm=password = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageHasTextInputs = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageExternalLinksFreq = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageHasPswdInputs = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageSecureLinksFreq = 0 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageTerm=connexion = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: UrlDomain=codelathe = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: UrlPathToken=index = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageTerm=account = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageHasForms = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageNumScriptTags>1 = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier.cc(192)] Feature: PageNumScriptTags>6 = 1 [5579:1799:0701/133954:VERBOSE2:phishing_classifier_delegate.cc(211)] Phishy verdict = 1 score = 0.548927 [5570:1799:0701/133954:VERBOSE2:client_side_detection_host.cc(447)] Feature extraction done (success:1) for URL: [http://dev1.codelathe.com/ui/core/index.html](http://dev1.codelathe.com/ui/core/index.html). Start sending client phishing request. [5570:1799:0701/133954:VERBOSE2:client_side_detection_host.cc(415)] Received server phishing verdict for URL:[http://dev1.codelathe.com/ui/core/index.html](http://dev1.codelathe.com/ui/core/index.html) is_phishing:1 [5570:1799:0701/133954:VERBOSE2:client_side_detection_service.cc(255)] Sending phishing model to RenderProcessHost @0x802b7ff0 [5580:1799:0701/133954:VERBOSE2:phishing_classifier_delegate.cc(259)] Toplevel URL is unchanged, not starting classification.

<comment><USER4> Thanks for the really useful tip to look into Chrome's debug log.

First of all we see that this so called phishing detection filter's code is found at [http://src.chromium.org/svn/trunk/src/chrome/renderer/safe_b...](http://src.chromium.org/svn/trunk/src/chrome/renderer/safe_browsing/)

Second, this code and the logic it employs is really bull __ __.

The world wide web is not a kiddie playground especially for a browser, and especially for a plugin whose's job is to detect phishing. The way Chrome's anti-phishing works is to use several foolish measures that mean nothing in the real world and then 'punish' and push websites into oblivion when someone crosses these arbitrary sets of rules.

The way the plugin appears to work is to look at various things * The type of URL (IP vs domainname, number of subdomains, size of the subdomain names, the strings in the Path URL) * Whether the page contains form data * Whether the page contains password input box * Whether the page contains checkboxes/radio boxes * Whether the page text contains some terms (in this case 'connexion') * Whether page has links/images to other domains

and so on.

None of these are _ANY_ indication of phishing behavior and if this set of quackery based logic is what we see from Google Chrome, where else can we go to really feel safe and protected?

<comment><USER5> As much as I can understand you being upset that Chrome shows a warning for your site, I don't think that the approach they are using is unreasonable.

I'd take bets that those criteria show a correlation to phishy sites. Especially if you combine those metrics together.

Is it perfect? No. Does it produce false positives? Yes. Is it beneficial on average? I think so.

PS: Since you have found the relevant file in the open source project (or 'kiddie playground' \- as you like to call it), why don't you supply a superior implementation with less "foolish" measures?

<comment><AUTHOR> You are trivializing the underlying issue here. If the same thing happened in a physical world it will be a high profile public defamation case.

Browser is the window through people sees the world. That's the reality we live in. In our target market, Google chrome holds 40% market share. Because of its stupid categorization, in one stroke Google harmed our reputation and the reputation of companies we serve. It is not a simple browser compatibility issue. Google chrome is telling the world our software is phishing software while we are not. What is the recourse here?

We don't care what Chrome's algorithms are. But the results are not factual and it harms our business. "One cannot escape saying hey that is our algorithm. We don't do evil…" Remember.

<comment><USER5> Believe me, I am empathetic to the pain this is causing you. I can understand the anger you are feeling.

But I don't think that I am trivializing things. The fact is, that phishing sites are causing a real pain (as in millions of dollars lost by the victims, hundreds of thousands of computers becoming zombies, etc). All major browsers are trying to mitigate these risks by implementing phishing & malware filters. None of these implementations are perfect (you probably know a bit or two about bugs in software development).

But on average these filters have a positive ROI - especially for the target market (which is Joe WebUser and sadly NOT your company - or mine for that matter). The costs of a false positive ("I'll go & find that information on another site") far outweigh the costs of a false negative ("I put my login+password into this legitimate looking website and now I can no longer access PayPal").

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Hey there, I actually worked for a "competitor" of yours at one time in my career. We had a very similar problem, turned out that one of our users shared(probably unknowingly) a file containing malware and probably posted it to their twitter or facebook(we had that feature built-in at the time). This URL was caught by a very popular anti-virus company, which posted it on their site. I guess the software phones-home to get all copies out there in sync. So for awhile, anyone with this anti-virus software would get blocked on our site's homepage for malware and/or phishing attempt. My somewhat-educated guess would be that a costumer of yours has hosted something that Google(or whatever Google uses to get its info) considers shady. Our solution was first to contact the company to get delisted, then I think we ended up changing domains for the sharing stuff. Similar to dropbox's dl.dropbox.com for any sharing stuff. Or maybe we did some kind of URL-shortener. But somehow, a change to the URL's domain of anything that hosted user-generated content was the solution to the problem, AFAIK.

<comment><AUTHOR> Hi,

Our software is little different. It is a self-hosted software. It is hosted by our customers under different domain names in their infrastructure. So it is not the same domain or URL.

For Example:

Customer 1: fileshare.abcplumbing.com

Customer 2: dataanywhere.peterlawfirm.com

Thats the real problem here. It affects our customer installations under different domains. To some extent, we are fine if google is blocking one domain because somebody in the domain is sharing malware. The issue here is different.

<comment><USER6> Ah, we did have a feature sorta-kinda like that too... if you had your own domain you login on our webUI, enter in your own domain and if no other user had it, you'd get it. Then, you add a CNAME record pointing to us and we'd do certain things when we received the request depending on settings the customer provided during the domain-name setup. I think we used the Referrer in the request-headers. So I could point portal.mypersonaldomain.com -> CNAME -> whateverIchoose.yourcompetitor.com and get a custom page, kinda. If we had a customer use a domain that CNAME pointed to us and had a history of questionable content, I wonder if Google would follow the CNAME direct to see where it's going and incorrectly(or correctly?!) decided bad stuff is happening, thus marking the CNAME target as bad. Just my random'ish guess. Hope you find the issue soon.

<comment><AUTHOR> We are not a SaaS or PaaS business. The software itself is hosted by the end customer in thier infrastructure.

The warning appears even in local IP/debug page.

<comment> grey-area Have you tried deleting things from your page till you work out what causes the warning? Just start with a static copy of you page, and gradually delete elements till you find the culprit. It shouldn't take long to go through through the elements of the page and work it out if this is some sort of heuristic triggered by some element on your page and not based on the domain.

Another thing it could be is if you fetch any assets at all from your domain, and the domain is blacklisted, that causes the warning regardless of the page where it is hosted.

<comment><AUTHOR> Yeap. we are doing exactly as you said. Hopefully we can find out.

</comment></comment></comment></comment></comment></comment><comment><USER7> Report an incorrect phishing warning at [http://www.google.com/safebrowsing/report_error/](http://www.google.com/safebrowsing/report_error/) .

      If you received a phishing warning but believe that this is
      actually a legitimate page, please complete the form below
      to report the error to Google. Information about your
      report will be maintained in accordance with Google's
      privacy policy.

Try posting a thread on the Google forums and decribe the false positive in neutral terms: [http://productforums.google.com/forum/#!forum/chrome](http://productforums.google.com/forum/#!forum/chrome)

Use Google Webmaster Tools for your product site and check for issues: [https://www.google.com/webmasters/tools/home?hl=en](https://www.google.com/webmasters/tools/home?hl=en)

Try to come up with a reason why this may not be a false positive. Perhaps you have trademark issues? etc.

More info:

[http://blog.chromium.org/2008/11/understanding-phishing- and-...](http://blog.chromium.org/2008/11/understanding-phishing-and- malware.html) This includes the URL of the website you are visiting, as well as the URL of any included resources (such as included JavaScript or Adobe Flash movies)

[https://support.google.com/chrome/answer/99020](https://support.google.com/chrome/answer/99020)

[https://www.usenix.org/legacy/event/hotbots07/tech/full_pape...](https://www.usenix.org/legacy/event/hotbots07/tech/full_papers/provos/provos.pdf) [pdf] The Ghost In The Browser. Analysis of Web-based Malware (a paper to make this post interesting to others)

<comment><AUTHOR> Unfortunately we have done all that. It is not a domain issue or safe browsing issue. The best analogy here is let us say lot of customers run a default drupal or joomla site under their domain and Google chrome show these sites as phishing site.

<comment><USER7> Please host the HTML source of a page that throws a warning somewhere. And mention the version of Chrome that gave the warning ( chrome://chrome/ ). Also can you post the thread on the Google forums with a proper bug report? I can't find it.

<comment><USER3> Try [http://dev1.codelathe.com](http://dev1.codelathe.com)

Shows up now with Chrome v27.0.1453.116

<comment><USER8> Same version, no warning. Edit: Oops, had yet to read that it's now temporarily whitelisted by google.

</comment></comment></comment></comment></comment><comment><USER9> I work at Google but not on this product.. so I escalated your issue to the team that works on the anti-phishing classifier. They're looking into it now, and put you on a temporary whitelist in the mean time (should take effect within 30 mins).

<comment><AUTHOR> Just one more thing. Since our product is self-hosted by our customers under their own domain, white listing just our development domain is unlikely to help our cause.

<comment><USER10> In fact, whitelisting would tend to hurt your debugging efforts.

<comment><USER3> The whitelisting already active for this domain now.

Trace showing server overriding the "Phishyness" verdict of the client

[5760:1799:0701/150256:VERBOSE2:phishing_classifier_delegate.cc(211)] Phishy verdict = 1 score = 0.548927

[5751:1799:0701/150256:VERBOSE2:client_side_detection_host.cc(447)] Feature extraction done (success:1) for URL: [http://dev1.codelathe.com/ui/core/index.html](http://dev1.codelathe.com/ui/core/index.html). Start sending client phishing request.

[5751:1799:0701/150256:VERBOSE2:client_side_detection_host.cc(415)] Received server phishing verdict for URL:[http://dev1.codelathe.com/ui/core/index.html](http://dev1.codelathe.com/ui/core/index.html) is_phishing:0

</comment></comment></comment></comment><comment><USER11> Have you tried to produce a minimal version of the software to show the problem? If not do it now and post it on the Google Chrome Bug tracker: [http://code.google.com/p/chromium/issues/list](http://code.google.com/p/chromium/issues/list)

Other contact forms: Mailing Lists: [http://www.chromium.org/developers/discussion- groups](http://www.chromium.org/developers/discussion-groups) IRC Channel: [http://dev.chromium.org/developers/irc](http://dev.chromium.org/developers/irc)

<comment><USER12> That failing, get money for them blocking a competitor.

before downvoting, take the time to explain how this would be different from old good Google suing Microsoft just for not making their product use Google easier than it already allowed.

<comment><USER13> this is HN, you can't get downvoted:)

<comment><USER14> I'm assuming some people are downvoting you to help disprove your point, but to be clear, once you've reached a karma threshold you can downvote.

</comment></comment></comment></comment><comment><USER15> Hmm that sucks. All I can suggest is you systematically remove content from the page until the error stops - this way perhaps you can identify the offending content (or combination of content which aggregates to an "offence")

<comment><AUTHOR> There is no offending content here. We are not a SaaS company and we dont host content. We provide shrink ware software to other companies which they use to host content.

<comment><USER16> The person you are responding to is not talking about user-uploaded content.

</comment></comment></comment><comment><USER17> External dependencies on that page? Anything being pulled from a domain that might have made the list? It might not be specific to your page, it might be on a JS library you are including.

<comment><USER18> This was precisely my thought. If it's happening even on a local staging server, it's highly likely that this is being caused by a third-party dependency somewhere in your site. I'd start by looking at any JS libraries you're loading.

</comment></comment><comment><USER19> I opened [http://dev1.codelathe.com/ui/core/index.html](http://dev1.codelathe.com/ui/core/index.html) (URL in your screenshot) in Chrome (latest) but I'm not getting any phishing warning.

<comment><USER20> Same here. I'm in Chrome 28 beta.

<comment><AUTHOR> The issue is much more complex. It appears in the latest live production version. if any of you are part of Google chrome team we can show you.

</comment></comment></comment><comment><USER21> i'm not seeing the phishing warning when visiting the url from the screenshot using chrome v29.0.1547.0 dev-m.

maybe you caught a malware on your computer. did you try from different machines?

<comment><AUTHOR> We have checked with one of the latest beta builds. In that build it didn't show the warning. It happens with the live chrome version. The issue is much more complex.

<comment><USER22> On a Mac with current Chrome (Version 27.0.1453.116) hitting your sample dev URL, I don't get any errors at all...

<comment><USER3> It shows up now on Version 27.0.1453.116

</comment></comment></comment></comment><comment><USER3> While I think chrome having strong anti fraud protection built in is nice, the fact that there is no way to understand what constitutes "correct behavior" and no clear way to get clarification is appalling.

It is essentially engineering how things should be developed, which still could be tolerable if there are guidelines.

If an average user sees a red page indicating risk to a page, then that site/page is essentially killed.

</comment><comment> grey-area Do you have an example page where this happens, like a demo login page? If so it'd be a good idea to post it as at the moment there's no way for us to see what you see and no way for people to help you work out what is wrong.

</comment><comment><USER23> If you are lucky, Matt Cutts ([https://news.ycombinator.com/user?id=Matt_Cutts](https://news.ycombinator.com/user?id=Matt_Cutts)) will read this and investigate with the Chrome team.

</comment><comment><USER24> You may also be interested in this article: [https://medium.com/surveillance- state/32ba2b38c219](https://medium.com/surveillance-state/32ba2b38c219)

<comment><AUTHOR> Yeap. That summarizes our issue.

The next step for us is to hire PR and go public. We are spending 1500$ per month on google adwords now.

May be use that money to get some legal help. In a physical world it is a clear public defamation case.

<comment><USER25> Get a lawyer. Send a demand letter to Google's corporate counsel that they stop falsely identifying your software as dangerous. Fax, FedEx, and email it. If they don't respond in 24 hours, have your lawyer file an emergency injunction in federal court.

Google's failure to respond to issues like this is appalling, and it's probably going to take a lawsuit and public embarrassment to get them to stop being evil.

</comment></comment></comment><comment><AUTHOR> A request to YC mods. It seems like this post is getting flagged. This issue is really a big risk for our startup and we will appreciate if you allow the post to get the visibility it deserves.</comment>


Russia bans all GMO food production - <AUTHOR> http://www.rt.com/politics/315844-government-decides-to-ban-gmo/ <comment><AUTHOR> [http://www.nejm.org/doi/full/10.1056/NEJMp1505660](http://www.nejm.org/doi/full/10.1056/NEJMp1505660)

New England Journal of Medicine, Aug 2015

GMOs, Herbicides, and Public Health

"...unlike regulatory bodies in 64 other countries, the Food and Drug Administration (FDA) does not require labeling of GM foods.

... determination by the IARC in 2015 that glyphosate is a "probable human carcinogen"1 and 2,4-D a "possible human carcinogen."

...These developments suggest that GM foods and the herbicides applied to them may pose hazards to human health that were not examined in previous assessments. We believe that the time has therefore come to thoroughly reconsider all aspects of the safety of plant biotechnology. The National Academy of Sciences has convened a new committee to reassess the social, economic, environmental, and human health effects of GM crops.

...we believe the time has come to revisit the United States' reluctance to label GM foods."

<comment><USER2> This article is not really a scientific work. It's an opinion piece from some researchers who are closely aligned with an industry that stands to gain from anti-GMO scare tactics, and it has a LOT of problems.

Its primary problem -- a problem so fundamental (and sadly common) that it's usually safe to disregard the scientific opinions of people who do this -- is the authors' implicit assumption that herbicide resistance is the only application of genetic modification. This 'single-issue campaigning' isn't really productive because it sidelines all the other incredibly important applications of genetic modification.

Also, pretending that glyphosate is only used on GMO crops is ... disingenuous at best.

Please also note that "probable human carcinogen" classification is grouped the same as "being a hairdresser" and "heating your house with wood." It's still up in the air as to whether 2,4-D is even remotely a candidate to be listed as a carcinogen.

I find it _profoundly_ troubling that the authors chose to name-drop Agent Orange as a scare tactic, since 2,4-D had nothing to do with the deleterious effects of Agent Orange on humans. That's bordering on irresponsible.

</comment></comment><comment><USER3> For those mocking Russia for this, note that they are joining Germany and France in enacting these laws[0]. While I believe in democracy and freedom, I also think that anti-Russian sentiment is being stirred up for the wrong reasons, by people who see Russia as an enemy of the US.

[0] [https://en.wikipedia.org/wiki/Regulation_of_genetically_modi...](https://en.wikipedia.org/wiki/Regulation_of_genetically_modified_organisms_in_the_European_Union)

</comment><comment><USER4> Boy, the Cold War vibes are getting stronger and stronger; will this be followed by a string of "bad harvests"?

(Actually, returning that level of Stalinist stupidity is unlikely, but given the low price of oil they need maximum productivity everywhere else possible.)

</comment><comment><USER5> Mmm, pseudoscience

<comment><USER4> You might say they were pioneers in this particular domain: [https://en.wikipedia.org/wiki/Lysenkoism](https://en.wikipedia.org/wiki/Lysenkoism)

And how's this for the last sentence in the intro:

 _Lysenkoism is used metaphorically to describe the manipulation or distortion of the scientific process as a way to reach a predetermined conclusion as dictated by an ideological bias, often related to social or political objectives._</comment></comment>


Elon Musk declares Juneteenth holiday, but employees must use PTO day - <AUTHOR> https://www.buzzfeednews.com/ryanmac/tesla-musk-juneteenth-holiday-unpaid-spacex <comment><USER2> Elon Musk is short for Elongated Muskrat.</comment>


YC Demo Day Session 2: Midnox, 42Floors, Sonalight, Your Mechanic - <AUTHOR> http://techcrunch.com/2012/03/27/yc-demo-day-session-2-midnox-42floors-sonalight-your-mechanic/ <comment><USER2> YourMechanic should provide some idea off the bat as to where they are providing service at this time, and perhaps a timeline as to when they expect to expand.

A simple, YourMechanic is currently providing service to the San Francisco Bay Area, or something.

After going through several steps in their chain:

Select Service -> Service Details -> Provide Name, Address, Email, Phone

The Mechanic Bids step failed with

errno: erange "Sorry, we currently do not serve this location right now."

<comment><USER3> Hey Jerry - (Art from YM).. sorry about this. You are right. The reality is that our site is not supposed to be public yet, but I guess it was too easy to find out the internal pages! When we launch this, we will make sure it is super clear the areas we are serving.

</comment></comment><comment><USER4> I think YourMechanic is an excellent idea.

<comment><USER5> In general, I think any "get service provider X to come to you" is great. But, from the article: "Your Mechanic has had 90,000 transactions and recorded $20,000 in billings per month, saving each user an average of $200 per transaction." Saving an _average_ of $200? I have a really hard time believing that. Not saying it's impossible (I haven't seen their presentation, product, anything), but either their numbers are wonky or their users had been getting gouged at their mechanics' shops.

<comment><USER3> Hey Charlie - Art from YourMechanic. It was supposed to be $90,000 in transaction, billing $20k per month now. I will request TC to fix this error. I wouldn't mind getting 90k transactions though :).

<comment><USER5> Hey, Art. Thanks for the comment. Even $90K in transactions is great, and $20K/mo is excellent.

Not the first time TC's borked numbers. :)

Good luck with everything. It sounds like a good product, and I hope things go great for you and your team.

</comment></comment></comment></comment><comment><USER6> I can't wait until YourMechanic is available in the Berkeley area! That's definitely a service I will use.</comment>