How NoSQL forced the evolution of a scalable relational database - <AUTHOR> http://blog.memsql.com/nosql/ <comment><USER2> Everyone seems to want to compare against MongoDB, but when I think NoSQL I think about Google Cloud Datastore and Amazon DynamoDB. Databases which are fully hosted, infinitely scalable, zero-maintenance, transactional, reliable, and - at least with Google's offering - scales down to a free tier. They aren't perfect or applicable in every situation, but they're cheap and easy enough to allow a one- or two-programmer team to achieve massive scale without hiring devops.

MemSQL is so expensive you have to call for a quote.

If it's just "the ability to scale" then sure, SQL is back on the menu. MemSQL, Spanner, CockroachDB are leading the charge and that's great! But you have to pay a pretty penny for it (in TCO). There's still a lot of value in a cheap fire-and-forget scalable database, and there are not currently any SQL options there.

Regarding schemaless: I think this is a divide between people who work in dynamic languages vs people who work in statically typed languages. Schemaless databases are just fine in languages like Java; your classes define the schema with enough rigidity to keep you out of trouble. They wouldn't be my choice for Javascript though, that's for sure.

<comment><USER3> I don't understand the "call to get a quote" sales cycle. I bet memsql has a sales time the size of their engineering team trying to get those fat Enterprise deals but in the grand scheme of things why should I care?

It doesn't have a free tier, I can't use it easily and just seems like a lot of hype without any 3rd party to back up their claims. Its the kind of things mongodb used to say to gain mindshare.

Most popular databases like MySQL and Postgres gained its mindshare because they were open source and anyone could verify they did what they said. Only a couple closed source databases have won it big. Behind them were huge monoliths like Microsoft and Oracle with armies of sales teams.

I'm not saying MemSQL will die. They are probably quite profitable. I work for an analytics company with a custom database. It's just the average joe doesn't get much from it. The cloud based dbs gets the average joe very far.

<comment><USER4> They're focusing on customers that can afford it, so it's not about you caring but you not being their primary customer.

You can download the developer edition and it does everything except cross- region replication if you want to test it.

It's a great product and the real deal, we used it before (as a startup too) and it did the job and is one of the most polished databases out there.

<comment><USER5> Nick, your account is shadow-banned. Email hn admins to revert the ban.

<comment><USER5> Aaand it's back to normal. Welcome to the club.

</comment></comment></comment></comment></comment><comment><USER6> I think NoSql, especially things like Mongo, got popular because it is super easy to program with javascript. While scaling is one of the advantages, I'd be super surprised if many people actually need scaling capabilities ( other than because their design is super inefficient ).

Recently I've been inspired to play around with kicking out as many layers between a relational db and a REST Api, largely because I've been watching [https://www.twitch.tv/nybblesio](https://www.twitch.tv/nybblesio) ( who I first came across here on HN on a thread about live coding via twitch streaming ). One of his projects he works on is a SASS product which is largely done in postgresql leveraging [https://github.com/PostgREST/postgrest](https://github.com/PostgREST/postgrest) . Seems pretty good, going to be interesting to see how it turns out ( though I haven't seen him work on it lately )

I tend to like SQL Server, ASP.NET Core and found [https://blogs.msdn.microsoft.com/sqlserverstorageengine/2018...](https://blogs.msdn.microsoft.com/sqlserverstorageengine/2018/01/29/simplify- rest-api-development-modern-single-page-apps-sql-server/) and I've been playing around with this kind of idea and using a lightweight mapper when needed ( [https://github.com/StackExchange/Dapper](https://github.com/StackExchange/Dapper) which the stackoverflow people created )

I gotta say, I kind of like it

One of the problems of many stacks is that the frameworks wrap general purpose languages over SQL, which, is not really a good idea, SQL is a vastly more capable language for dealing with relational data and layers built over the top often dumb down the database.

The REAL problem SQL wrappers need to solve is that most languages don't have a good interface with SQL. So most often SQL is handled in strings and manipulated with string manipulation and there is no type safe way transitioning data from the DB to a general purpose language.

Microsoft at one stage had Linq to SQL which was quite good..... but they killed it :)

<comment><USER7> >I think NoSql, especially things like Mongo, got popular because it is super easy to program with javascript.

I chose Mongo for a project recently. I have many years experience with SQL databases, and I think SQL will become more of a niche in the future.

Here are the reasons:

Everybody uses an ORM with a SQL database. You can pretend they don't and everyone is writing raw sql, but they aren't. This is basically a big, complicated, and slow piece of software that tries to make a SQL database into something else. A NoSQL database is like a native version of that. It starts off with you being able to define collections and schemas in code and so on.

SQL is a shit way to query a database. I used to write massive queries that took an hour or so to write just so that the non-programming people could put them into analytics software that didn't support any other methods of input. While I was writing these queries, I was just thinking to myself "I can write this in code in a few minutes instead of an hour or more". The fact is that programming languages are much better at querying databases than SQL.

Joins are slow and complicated, and ORMs are slow and complicated, so you can never actually use any of these things in a high-traffic environment. As you say, not many people will reach these levels of traffic, but it is still a factor.

Most of the comments about "I moved from mongo to postgres" lately are first- time programmers who didn't know any of the basic concepts of databases. They then discovered patterns that the SQL database forced on them and declared that mongo sucks when in reality, they just didn't know what they were doing.

>One of the problems of many stacks is that the frameworks wrap general purpose languages over SQL, which, is not really a good idea, SQL is a vastly more capable language for dealing with relational data and layers built over the top often dumb down the database.

This is not true at all. Programming languages are vastly superior at querying a database. Just go write a complex query and compare it to the one in linq or whatever you use.

>Microsoft at one stage had Linq to SQL which was quite good..... but they killed it :)

They have entity framework, which uses linq and is the same thing. It is very slow though.

<comment><USER8> > Everybody uses an ORM with a SQL database.

I'm ripping ORMs out of any backend code and using things like jOOQ.

> I was just thinking to myself "I can write this in code in a few minutes > instead of an hour or more".... > Joins are slow and complicated

You know what's really slow? Creating joins in code.

> This is not true at all. Programming languages are vastly superior at > querying a database. Just go write a complex query and compare it to the one > in linq or whatever you use.

It makes zero sense to pull a bunch of records back from the db using multiple network calls to join and then filter. Let the db do its job.

<comment><USER9> > It makes zero sense to pull a bunch of records back from the db using > multiple network calls to join and then filter. Let the db do its job.

But then it wouldn't be distributed processing! :)

Seriously, though, consider it for a moment.. this pattern has similar features to something like Hadoop. The data comes from storage nodes (database server and, hopefully, their read replicas) and goes to processing nodes (app server) to have the work done and is then new data is written back out over the network to storage nodes and replicated across the network (to the replica/slave database servers).

If the data volume is particularly low or the compute load (CPU and/or RAM) is particularly high, the distributed method would make intuitive sense. I haven't seen it yet, however.

<comment><USER10> Doing distributed joins correctly requires an architectural/technical capability that most distributed database engines don't have: decentralized parallel orchestration. If you have this, you can do joins even with very high data volumes efficiently given good parallel scheduling algorithms. Most databases are designed such that there is a single point of control that declaratively schedules all data flows required to execute the query; this scales poorly for operations like joins, never mind recursive joins, which is why you don't see it.

Letting individual database nodes dynamically schedule and orchestrate their own data flows with each other, essentially allowing each node in the parallel system construct its own execution plan in relation to other nodes as it goes along, does not fit within the "giant distributed file system" paradigm that most distributed systems are based on. People who design codes for supercomputers are often familiar with parallel orchestration idioms that work at extremely large scales but it hasn't crossed over into ordinary distributed database engines. (This is also a good litmus test for what makes a database "parallel" as distinct from "distributed".)

Most distributed database architectures are much more centralized than they need to be, particularly around control of execution planning, and this limits their expressiveness. It is quite difficult to hack together a distributed join that performs better than a centralized one without good support for parallel orchestration.

<comment><USER11> Could you point out any open source supercomputing / data products that get this right (ie have decentralized data flows?).

<comment><USER9> I'm obviously not the parent commenter and have no inside knowledge of the HPC world, but my guess is the main open source supercompting projects would be from NASA, the US national labs, and CERN.

You might search HN for the recent announcements about new clusters, especially top500, and look for the comments discussing using MPI (versus something custom, I think?), as my recollection is that those topics would yield further pointers to the actual examples you're looking for.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> Redis is not mentioned here at all so maybe the author is thinking mostly of other NoSQL software here, but well, in the case of Redis the whole point was not just the in-memory performance part, but the data model as well. My claim is that you can't really exploit the advantage of using memory if you perpetuate in using the memory to represent the same data model that you were using with relational databases. For instance think at Redis sorted sets in the use case of leaderboards in popular games (the same pattern is used in a number of applications that have nothing to do with games). To use SQL, even an in memory one, in such use case is not going to work. So in the case of Redis the point was to remove the interface between the user and the way the data is actually fetched from data structures, to make the user do the choices in a very direct way. Thus this article does not apply to Redis in my opinion. I've the feeling that many other NoSQL products could argument like that, but in other areas of their research and difference. For instance I've issues to see how modern SQL systems can replace CRDTs based stores.

<comment><USER13> This is the problem with people that use the term NoSQL.

Do you mean Cassandra (BigTable), MongoDB (Document), Riak (Key/Value), Redis (Mix), Kafka (Log Structured) ? There are dozens of fundamentally different systems many of which are closer to an RDBMS than their NoSQL peers. And many of them have rigid schemas so it definitely isn't that either.

<comment><USER14> You can also add Neo4j (graph) as part of the NoSQL family, right?

<comment><USER15> Yeah in general it seems like NoSQL is used to proxy "MongoDB and other key- value stores."

Graph databases arguably handle relational data better than SQL, and I'd argue they're much nicer to work with.

<comment><USER16> And MS SQL Server now supports graph databases; it doesn't have to be either- or.

</comment></comment></comment></comment></comment><comment><USER17> Well, this is exactly why competition is good, in every domain. That's why PostgreSQL got its column mode and JSON type, because there was a clear use case for performance for the former and schema-less data for the latter. EAV pattern is a plague and I'm glad documents are replacing it.

<comment><USER18> Postgres has had hstore for schema-less data since 2003.

<comment><USER19> This is a very blunt statement and overvalues hstore. Keys AND values in hstore are and can only be text strings.

<comment><USER20> With arrays and composite type the potential for semi-structured schema was there for decades. The concept just got more mainstream with NoSQL, more easy to maintain and more efficient with indexables type such as JSONB.

</comment></comment></comment></comment><comment><USER21> What concernes me is that the article is strongly biased in the sense, that modern developments of non-relational databases just get ignored while ranting on their state from a few years ago. Schemaless databases do support full ACID transactions (MongoDB, ArangoDB), with some you can also enforce a schema and not everybody loves SQL. So having competition even on the query language- side, can only improve the status quo.

Yes, thinking about your data model will for sure increase your understanding of what you are actually doing... and every professional developer is doing this as well when choosing a non-relational database. Anythings else would be stupid.

For me the article rather shows that the modern developments in non-relational databases do affect vendors on the relational side of the spectrum. Otherwise, it would not make sense to invest so much time in writing such a long article.

</comment><comment><AUTHOR> My name is Rick Negrin. I run the Product Management team at MemSQL, a scalable relational database. I recently wrote a blog on my thoughts regarding NoSQL vs. Relational Databases and I'd love to hear the community's thoughts on this.

<comment><USER22> Hi Rick, I've been following Memsql for a few years now, are there any plans to release "community" edition? Last time I checked about 1.5 years ago json support was very basic and EE pricing (dont remember exact #s) was rather high. Thanks

<comment><USER23> What are you looking for in a "community" edition?

<comment><USER24> Something that you can use on production based on what your db advertises as it's advantages (high availability + sharding).

<comment><USER23> I was asking because I am the creator of RediSQL[1] -- SQL steroids for Redis -- which is a less sophisticated product than MemSQL but still has its own use cases.

And maybe for parent was enough, or if not it would be very interesting to know what is missing.

[1]: [http://redbeardlab.tech/rediSQL/](http://redbeardlab.tech/rediSQL/)

<comment><USER24> The same answer applies to your product.

<comment><USER23> Honestly, I believe that for small workload you can definitely use RediSQL in production, it will happily contain your cache or it will be a great SQL database.

However, I need a way to cut it between people just using the free product and people actually supporting the project, so provide as paying feature something that the big company will require it seemed to me the only way to go.

Unfortunately, I don't have the capital nor the bandwidth to go with fully open source product and selling just support, which I don't believe is anyway a good business model.

If you were in my shoes, you would do something different?

<comment><USER24> To be honest, I fail to see what I could use your product for so I'm out of the target audience.

Assuming nosql is for something very efficient or very scalable, I need some space to use it before I have to shell $$. There are many products where I have to pay before going on production.

<comment><USER23> It really depends on what you are building.

If I were building a fast prototype I would not use a postgres box anymore but just a redis one.

If you need to cache data in a way more complex than just key->value you don't have too many alternatives at the moment.

If you want an easy and fast way to have an SQL engine in memory, again is not going to be simple.

If you need a separated database for every of your user there are no many alternatives that I am aware of.

It is definitely not a revolutionary product, but it has it's niche, any of the problems that I mentioned can be solved in a different way, but those different ways are quite complex.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER25> NoSQL is an excellent technology for rapid R&D, but once a domain "settles", data should be modeled and data stores should be switched to relational or graph backends.

If a system already has a well-defined domain, NoSQL adds little value.

Of course you could leverage AWS DynamoDB and reduce cost, but you still have downstream implications for things like reporting, which requires a known schema with relational paradigms.

<comment><USER26> I don't see how NoSQL could be better for rapid dev when something like Postgres can migrate its schema and data at once while enforcing constraints. That's clearly better precisely when your schema is changing.

<comment><USER25> In R&D scenarios, NoSQL wins hands down because devs are jamming schema changes hourly. That level of frequency in a relational model is a massive drag on time and it's wasted.

If it's a redevelopment of a well-known domain, depending on reporting requirements, I'd slightly side with relational.

But AWS DynamoDB can be a huge cost savings, so as any good architect will say, "It depends."

</comment></comment></comment><comment><USER27> I feel like this topic was covered better by Stonebraker :p [https://homes.cs.washington.edu/~billhowe/mapreduce_a_major_...](https://homes.cs.washington.edu/~billhowe/mapreduce_a_major_step_backwards.html)

In the late 90s/early 00s Eric Brewer also wrote a bunch of papers about his experiences scaling stateful systems at Inktomi. The most famous one is probably the one that introduced/codified the CAP theorem: [https://pdfs.semanticscholar.org/5015/8bc1a8a67295ab7bce0550...](https://pdfs.semanticscholar.org/5015/8bc1a8a67295ab7bce0550886a9859000dc2.pdf)

</comment><comment><USER28> Someone please help me understand. I use relational databases everyday for my projects (db, api, frontend). I'm well-versed in SQL and general best practices, and my projects scale well (admittedly I'm not in the petabytes level of scale). Does the desire to use NoSQL databases come from a disdain for having to think in terms of declarative programming instead of imperative? Is it desirable to have dynamically typed fields in a database? I've always thought that the biggest motivation to use NoSQL is simply due to high-level language programmers' unfamiliarity with relational database logic and SQL syntax. Once I grasped the concepts, the relational model has proven indispensable for me.

I will say, though, that it is important to get your schema correct at the beginning. I've also always worked full-stack, so I don't know what it's like not to have the ability to manipulate the database.

<comment><USER29> > what it's like not to have the ability to manipulate the database.

In general "not wanting to understand, depend on, or work with other systems/teams" (often cause of dysfunctional eng/pm organizations) has, over 20years experience, been the number one reason devs (esp front end devs cause they tend to move the fastest (faster than traditional backend teams are prepared for) and have least experience in back end systems) go for something new, something they can control, something they can spin up fast and quick. NoSQL, cloud, anything they can do themselves.

</comment></comment><comment><USER30> My own experience chimes with this somewhat, having used MongoDB on my last project - quite often application data storage requirements are relatively trivial - and it is a boon to do away with the ORM layer and be able to vary any given object schema without touching the database (although in practice a .js data migration script may be involved, so this is moot). As a sidenote local cultural issue, the fact that we can operate the MongoDB servers ourselves, whereas RDBMS instances are with a central team and buried under a layer of bureaucracy was also probably an operational consideration.

When it comes to joins, these have lately been added to MongoDB, as has SQL - although the functionality is still rudimentary compared to a mature RDBMS.

But where we experienced pain was when the business decided they wanted to do live reporting. We ended up piping the data into a SQL Server instance and using SSRS.

<comment><USER31> The fact that you could operate the mongo instance, but not the DB is definitely a cultural issue, or more likely a managerial issue. Definitely NOT a DB issue. I've worked at places where we could manage the DB ourselves, and other places where we couldn't eve talk to the DBAs without beuraucracy. It's all about the management in those scenarios. And the company results were as you would expect.

<comment><USER30> Sure - I'm not claiming that as a database issue at all. It's just a side addendum to note that sometimes technical decisions can have a political aspect.

</comment></comment></comment><comment><USER32> How are people running migrations in these distributed SQL environments? Especially with something like Kubernetes that has canary / rollback functionality. Do people run their migrations as a manual step, is integrated into the CI/CD system?

I can't find anybody talking about how they handle it in a scalable way. Not having a good DB migration story for dev/prod environments with automatic rollout / rollback makes using a SQL DB a non-starter for me.

Most Docker / Kubernetes documentation and their ecosystem assumes the app is fully developed and development doesn't exist. Real world companies develop products and have to perform DB migrations on the production database on a regular basis with each release.

What am I missing?

</comment><comment><USER33> I keep looking at Tarantool longingly, but I can't figure out when I would need it.

<comment><USER34> I have the same feeling. If you ever figure this out, let me know. It looks very interesting, but I don't think my clients will let me remake their production with it and it is difficult to evaluate databases without data or a workload.

</comment></comment><comment><USER35> It's hard to understand the point of this article. First of all this is a good example of a completely biased ranting.

Secondly after that it's bashing NoSQL through many chapters later it is using those same features that NoSQL was capable of in the first place as a selling point for MemSQL... Seriously? This is a really biased marketing opinion piece at best.

Not to mention that it talks about new types of analytics but it completely ignores (or at least it doesn't mention any of) the category of low latency streaming analytics applications like Apache Storm, Apache Spark, Apache Kakfka et al.

> "To do this requires a new breed of analytics systems that can scale to > hundreds of concurrent queries, deliver fast queries without pre- > aggregation, and ingest data as it is created. On top of that, they want to > expose data to customers and partners, requiring an operational SLA, > security capabilities, performance, and scale not possible with current data > stores"

Guess what! This is what streaming analytics was invented for.

</comment><comment><USER35> > "To give an analogy, imagine libraries saying they are doing away with the > Dewey Decimal System and just throwing the books into a big hole in the > ground and declaring it a better system because it is way less work for the > librarians"

No, to give an analogy imagine a library where the librarian only accepts books which are below a given size, have a specific color and weight, and he rejects any books which have even a cm bigger size, a different color or it's just a gram heavier. Also from time to time (let's say each month) the librarians are sitting together to decide what other books shall they accept (sometimes extending (and by that inherently limiting) the acceptable ranges to other properties like title or smell). Also to give a good analogy the librarians also reject those books which are returned without their softcover. That's RDBMS for you. It works, but not everyone is satisfied with such a service.

</comment><comment><USER36> Can't you have ACID with write on ram first, write on disk second, delay the commit by committing after writing on disk, and have some tolerance for the time between write on ram and write on disk? How probable is it that a crash happens in that window? The data loss would seem very minimal and rare.

And is ACID always so important for most databases? I don't think most databases in the world are related to banks or require that much guarantees and safety. Better hardware often achieves that level of safety.

Other side note, I wish there would be alternative to the SQL "english sentence" flavor of the language, so that one could give more precise parameters for querying data, instead of building a sentence query which doesn't always make a lot of sense when compared to a non-sentence programming language.

</comment><comment><USER37> If you want a scalable database that holds JSON and lets you query it with SQL, you should check out Couchbase

</comment><comment><USER38> > the need to retrain people

Last I checked, we stopped doing that back in the early 90's - learning new things is your problem and you better know all of them by next Tuesday, or we'll replace you with somebody who does.

</comment><comment><USER39> I'm surprised how many people still conflate NoSQL with "document database" and only think of MongoDB or CouchDB. I'd love to hear how MemSQL addresses graph data, for example.

<comment><USER40> Because when the fox has been in the henhouse this long, it's a fox house, not a henhouse.

</comment></comment><comment><USER41> > NoSQL came into existence because the databases at the time couldn't handle > the scale required.

Arguably the first "NoSQL" database was a DIT, generally accessed via the LDAP protocol. OpenLDAP is one of the better known open source instances, but Novell eDirectory was there in the early part of this century, as was MS AD.

In the case of Directory Services, it's a completely different approach to both SQL and the common "Document Store" approach of modern "NoSQL" options. Unless you go cowboy-mode, you're still adhering to schemas (albeit with the option to combine schemas), you still use indexed attributes to conduct searches, but you have a literal tree of objects with a more flexible layout (e.g. multi-value attributes without needing to use a JSON column) than with a regular SQL RDBMS.

The rise in popularity of 'modern' NoSQL options (most commonly document stores) is IMO driven by a combination of lazy developers and too much Kool- aid consumption.

<comment><USER42> I would say the the rise of nosql options is driven by the need for scalability by a few large companies that desperately need it, and cargo- culting by developers that don't actually need it, but want to be like google and don't want to take the time to properly learn and optimize sql.

There's a genuine need for good scalable options, and with stuff like google spanner, those don't necessarily need to be "eventually consistent" or nosql. The simpler datamodels were probably easier to create and solved the problem, now I think there'll be a rise of scalable and consistent databases, best of both worlds.

<comment><USER7> >don't want to take the time to properly learn and optimize sql.

This sounds like an old-wives tail at this point.

<comment><USER8> > This sounds like an old-wives tail at this point.

Except it's not. I've seen it in person, over and over. I've gone into systems where people were complaining about the 'database is slow', but there were no indexes. I've seen systems pull back 100s of thousands of records and then sort on app server and take the first 50. I've seen what would have been a simple join with exists clause turned into many round trips to the db with loops and app code complexities where a query would have 100x easier to reason about.

It's not even about _optimization_ yet, but taking the time to learn even the surface capabilities of the tool.

</comment></comment></comment></comment><comment><USER43> Perfect! We at Shippable moved from NoSQL MongoDB to PostgreSQL for several reasons. Here is a small story,

It started with small problems...

Even though we had the ability to add features at a lightening pace, we started seeing occasional downtimes which always seemed to come down to MongoDB. For instance:

> We were very happy to have 24x7 availability with primary and secondary > instances of MongoDB. However, our perf suddenly deteriorated one day and > retrieval started taking more than a second per document. We tried using > many tools and profilers, but could not figure out what was happening. > Finally, we rebuilt a new server, switched that over as primary, and rebuilt > our secondary. Retrieval times dropped to 150ms again. This is still an > unsolved mystery! > Our Mongo instance reached 4TB and we were proud of our > growing adoption. Due to the lack of tooling around managing large DBs, we > relied on indexes to keep the search times low. When NoSQL DBs first became > popular, there was no way to create uniqueness, so these features were built > as an afterthought. Some of the bloating of our MongoDB was actually due to > indexes, but rebuilding them was primitive and the entire DB would lock > down. > At one point, we needed to reboot our DB server and it took MongoDB > 4 hours to come back online. This led to an extended downtime for our > service, and we had very little visibility into the MongoDB process or > status.

And then came the knockout punch! The biggest advantage, and disadvantage, of MongoDB is that it has a flexible schema. This means that documents in the same collection (aka table in the old world) do not need to have the same set of fields or structure, and common fields in a collection's documents may hold different types of data. In a nutshell, there are no strict schema rules and this opens it up to a lot of cowboy tinkering. While many developers love the flexibility, it also puts a very high degree of responsibility on their shoulders to get things right.

The whole experience we have written on our blog [http://blog.shippable.com/why-we-moved-from-nosql-mongodb- to...](http://blog.shippable.com/why-we-moved-from-nosql-mongodb-to- postgressql)

<comment><USER3> Almost everything has a schema. Whether you explicitly write it down or have it in someone's head.

If you really want schemaless then use JSON type in a relational DB.

Also with huge memory and risk machines, one could go multi terabytes with a 3 machine cluster on a relational database.</comment></comment>


Don't add your 2 cents - <AUTHOR> http://sivers.org/2c <comment><USER3> I can't agree with this article at all. From my experience on contributing to FOSS projects, I feel much better when somebody senior makes adjustments to my code rather than leaving it as-is.

Not only does it tell me that they actually read my code and spot errors (the added bug safety net makes it much less stressful for me to write new code), but it also makes me feel like I'm learning something new that I wouldn't otherwise have. Finally, it inadvertently means that the rest of my code passed their "high" standards for quality, which is gratifying - <USER2> for large commits in which I only need to change little.

I guess the key difference between my experience and this article, though, is that the article seems to be mostly focused in a non-technical boss commenting on benign/arbitrary opinions (like shades of color), rather than a technically skilled superior commenting on his area of expertise. That might explain why I have such a 180° reversal from this article's stance.

<comment><USER4> _I guess the key difference between my experience and this article, though, is that the article seems to be mostly focused in a non-technical boss commenting on benign /arbitrary opinions (like shades of color), rather than a technically skilled superior commenting on his area of expertise._

The article is referring to things that are ostensibly subjective changes that don't make a tangible, measurable difference. The suggestions in question are often the boss putting their mark on something so demonstrate that they've made an impact.

Even if the suggestion actually improves the product, suggesting something that deflates team morale more than it brings to the design means the change isn't worth it. As a boss that's quite a hard lesson to learn because logic says you should be doing whatever you can to ship the best possible product. In reality, especially in the long term, the product is going to be better if you temper your suggestions in favour of the team.

<comment><USER5> I think the employee-boss relationship is a factor as well. Generally speaking, superiors should be able to make constructive criticisms to their subordinates without it impacting morale in a negative manner. That makes criticism a two way street.

Bosses must make sure that they're not all critic with no praise. No one wants to be critiqued all the time without kudos for the good portions and hard work. Tone, body languages, and timing all play into how an effective leader communicates positively or negatively to a team member.

On the flip side, staff need to be able to separate their personal worth from the work that they do. This can be especially tough in some fields and with some personality types such as art, design, and programming. When your work is highly subjective, when you're starting your career, or when their are a million methods to achieve the same goal (with some methods being better without obvious reason as to why), it can feel like critiques are attacking the person instead improving the work.

An anecdote from my personal life: I worked as a paralegal for a while. I started off mediocre at the job, but after a management change, my new boss had manuals that gave standardized instructions on how to do nearly everything. That's when I started to excel. There were many specific times when I would give my boss documents, but he _never_ let them slide. Ever. He would say, "The language and structure of this document is perfect, but you know I can't let anything slide without having _something_ to change." He'd mark something subjective such as substituting a synonym with the same meaning and tone or moving a sentence that didn't affect the language of the paragraph. It never bothered me, but I can see how that would definitely grate on others. In spite of this, he was always full of praise with nothing but positive remarks.

<comment><USER6> One-word redline => 10 minutes of billable hours.

::Shakes fist:: lawyers! ;-)

<comment><USER5> Because of the line of work, we were contracted with up front costs. We didn't have billable hours, but hot damn - those little corrections would have added up quickly.

</comment></comment></comment></comment></comment><comment><USER7> I think it's good to note, as Derek does, the distinction between "2 cents' worth" and larger changes that do require senior input - otherwise you're just being the manager that the team create ducks for [1].

This is where coaching skills as a manager can prove useful. If you feel there are some minor changes that could be an improvement, but don't want to impose your will/opinion, coaching ('ask') can be a better response than managing ('tell').

For example, you might ask "If you had to improve anything, what would you change?" It's an open-ended question that will encourage your team member to think. They can reply "Nothing" if they're confident in the final solution, or they may propose some tweaks they weren't fully happy with - "I'm not sure if that's the right shade of blue" or "I think that's the right call to action, but maybe we could get another opinion". If those are reasonable improvements, empower them to implement the additional change; if you disagree with the extras they raise, tell them you consider the version they proposed to be superior, which empowers their original decision.

Just don't be the manager who expects a detailed response and change every time ... then you're right back to where you started.

[1] See point 5 [https://blog.codinghorror.com/new-programming- jargon/](https://blog.codinghorror.com/new-programming-jargon/)

<comment><USER8> The open question does not always work. I'd say it never works, even.

If I take "coaching" attitude, I will take attitude of sports coach - observe, measure and explain why corrective action is needed. The action itself is a choice, mostly, but manager and coach should present a basis for it.

Continuing my my rant, I emphasize that manager and coach are external to the team, they view performance from outside (and often prohibited to look under the hood). This is the reason why open questions do not work - difference in view points creates difference in the context.

<comment><USER9> I thinks _specific_ questions would work well. To use the bad boss example:

> _I like it! Really good. Maybe just a darker shade of blue there, and change > the word 'giant' to 'huge'. Other than that, it's great!_

Let's change this to:

> _I like it! Really good. Can you briefly work me through the design process > behind it? I 'm particularly interested in how you settled on the colours > over there, and your ideas behind the word 'giant'._

(This honestly still needs a bit of work, but is getting there)

In this phrasing we show interest in the designer's work, respect their choices and don't assume our ideas are better than theirs. Instead we assume they know what they are doing and give them the space to convince us and also tell us what parts of the design do and do not matter to them, before engaging in giving proper feedback.

The big issue with the cited bad example is that the boss doesn't say _why_ the design needs a darker shade of blue, or why the word 'giant' has to change to 'huge'. It doesn't give any other feedback than "this is wrong, this is the fix". It's not open for debate.

<comment><USER10> >> I like it! Really good. Maybe just a darker shade of blue there, and change the word 'giant' to 'huge'. Other than that, it's great! >Let's change this to: >> I like it! Really good. Can you briefly work me through the design process behind it? I'm particularly interested in how you settled on the colours over there, and your ideas behind the word 'giant'.

Take note, all ye entrepreneurs! This advice is just as applicable for software engineers as for designers, extremely so. So many issues could be avoided with people I do contracts for if they just approached issues in this way.

Usually, it's "change this, do that". So I have to reply with "OK, well, we _could_ do that but it'll take 20 days and cost $3000 dollars". The entrepreneur, displeased yet unwilling to pay that much or give up that much time: "hrmph. well...".

Automatically, something that _could_ have been a collaborative process has been turned into a confrontation. If he/she had instead approached the problem in the way you recommended, I perhaps could have found out what was driving the desire for change, and recommended a cheaper/faster solution to the problem. Usually, I'll end up in that place eventually, but by that time what could have been a collaborative process has turned confrontational, with my client thinking "ugh, programmers" and me thinking "ugh, idea guys".

That said, this has given me some ideas about how to respond in this types of situations. Perhaps with something like, "can I walk you through the reasons why I did/chose this?". Might be worth trying.

<comment><USER9> > _That said, this has given me some ideas about how to respond in this types > of situations. Perhaps with something like, "can I walk you through the > reasons why I did/chose this?". Might be worth trying._

Right, there's no reason the designer/software engineer shouldn't take the initiative

</comment></comment></comment></comment></comment><comment><USER11> As a manager, I tend to frame my feedback/opinions as 'Have you considered <something>?' or 'Can you explain your thinking behind this <feature/function/design>?'

Doing it this way, I get an understanding of their rationale and if I still think my idea is good, I can debate the worthiness of it against my employees reasoning. I feel this approach fosters a 'best idea wins' rather than a 'manager opinion trumps all'.

I agree with Derek's implied point that 'manager opinion trumps all is bad', but think it's a discredit to his staff if he doesn't challenge their ideas if he thinks he has something more worthwhile.

<comment> torrent-of-ions This post is much better than the article. The manner in which you deliver criticism is very important. When criticising somebody on their method I find it is much nicer to say "I like to do it like this..." They will then be encouraged to try your method and they might like it. You are not attacking their method.

I find it unfortunate that most people take criticism as an attack, but they do and choice of language and delivery can soften the blow and bypass their defences.

<comment><USER12> > "I like to do it like this..." They will then be encouraged to try your > method and they might like it

The danger here is that this will often be interpreted as "my boss wants me to do it like this", and they will do it not because the idea stands on its own merits, but because it was the boss's idea.

</comment></comment></comment><comment><USER13> I find the advice highly condescending.

> Because of that small change, that person no longer feels full ownership of > their project.

What kind of person is that who 1) thinks the ownership is 100% theirs when working in a team? 2) can't handle a little nitpicking? 3) feels it's less their work just because of a little change? 4) can't defend their work and resist those 2c?

This is advice for managing 2 year olds. As a manager, just be your _reasonable_ self. The truth is key for a functioning team. Giving people feedback and letting them know where they stand helps build trust.

> It's perfect. Great work! Let's ship it.

Ditto!

<comment><USER14> >This is advice for managing 2 year olds.

That's exactly the vibe I got from reading this article. I immediately thought of someone trying to manage super-fragile millennials who wilt and pout without constant encouragement and affirmation. If I submit I project for scrutiny, I _want_ constructive criticism and advice. The goal should to make the project as good as it can be, not manage the feelings of emotionally challenged workers.

<comment><USER15> Perhaps it's like SEO, where all the low-hanging fruit is obvious and sensible, but where further optimization beyond that point is stuff that looks really odd and counter-intuitive, or like it "couldn't possibly" have any impact.

Maybe people put out a 1.0 units of effort when you're just a reasonable person, but put out e.g. 1.1 units when you baby them, and so babying them is a "win" in some sense?

<comment><USER14> >Maybe people put out a 1.0 units of effort when you're just a reasonable person, but put out e.g. 1.1 units when you baby them, and so babying them is a "win" in some sense?

I'd contend that any worker that you have to "baby" in a business environment to get their best effort is a worker you are better off without.

<comment><USER15> Note that I'm talking about _results_ , not _effort_. Someone could be giving their _best effort_ already, resulting in 1.0 units of output. But babying them might be the emotional equivalent of blood-doping in a marathon, a psychological stimulus that actually partially restores or extends the willpower-resource that is spent internally to accomplish work.

I'm also not talking about a specific kind of person who "needs" babying. I'm proposing instead that your average neurotypical human brain might have this effect built in, such that it applies to anyone and everyone. It would just be an effect that most of the time goes untapped.

<comment><USER13> I think a truer kind of relationship is the most significant factor still. It's the common denominator that will take people to great results for a wider "audience" (a team here).

But I agree that fine-tuning your feedback and style per individual needs, even if counterintuitive, may also be productive, as long as it's not contradictory and leads to situations where one team member feels another is being babied around more.

</comment></comment></comment></comment></comment></comment><comment><USER16> I think the suggested comment _It's perfect. Great work! Let's ship it._ has its own set of issues.

Firstly, while the conversation started with "I'm looking for input", the manager has suddenly moved it into a push for delivery.

 _If_ the design was ready to ship, then that won't be an issue, but if all you're looking at is a mockup, or a slapped together stylesheet, etc, then what was an attempt an encouragement has just lumped more pressure on.

Also, the comment assumes that the designer thinks it's "done". The request for input could mean "this is the direction I'm going in, does that look right". Telling them that you think it's "ready to ship" still takes ownership from them. You've just moved from being the boss who provides 2 cents on everything to the boss that wants everything to be done right now without taking the time to do it right.

Much better to say "I think it's fantastic. Great work! Is it ready to ship, or do you have more to do on it?"

<comment><USER17> I think your subtle focus on the semantics of the reply highlight a common block to agile feedback loops, small batches and generally getting things done. Sorry if that's harsh but you either missed the point of the article entirely or just overlooked it, the latter possibly being worse.

The primary point IMO is "don't squash ownership" because the cost of doing so is often not fully realised. The secondary point is "don't sweat the details". You've kinda proven you don't get this yet.

<comment><USER18> > I think your subtle focus on the semantics of the reply highlight a common > block to agile feedback loops, small batches and generally getting things > done. The primary point IMO is "don't squash ownership" because the cost of > doing so is often not fully realised.

^^^ Here's your comment without the pointless condescending remarks. Notice the difference?

</comment></comment></comment><comment><USER19> I like the way Joel Spolsky describes managers taking this even further at Microsoft back in the day.

They wanted to make sure the engineers knew that they were the ones designing the software, to the point where they would refuse to even step in and resolve a conflict between two engineers about the design. Even when those two engineers came up and asked for help resolving said conflict.

 _Now you 've got three people in the room: a designer, a developer, and a manager. Who's the person who knows least about the problem?_

Solve it yourself, guys. Perfect.

[http://www.joelonsoftware.com/articles/fog0000000072.html](http://www.joelonsoftware.com/articles/fog0000000072.html)

<comment><USER20> Right, but you have the engineer saying that is not important, and the designer saying this is the most important part of the software and we might as well not do it at all.

This is where you need a decision from someone else.

<comment><USER15> I don't know if you need arbitration, there, so much as a willingness to allow each party to "pull in" others to help make their point. Like expert witnesses in a trial, but just for the sake of convincing.

</comment></comment></comment><comment><USER21> Something a very smart person advised me was to "Tell people what you want, not what to do"

It sounds so simple yet is surprisingly hard to practice. It really puts the onus on you to think carefully about outcomes you desire and explain it clearly.

<comment><USER22> Or as Neil Gaiman put it from the opposite perspective:"When people tell it's wrong, they're almost always right. When they tell you how to fix it they're almost never right."

</comment></comment><comment><USER23> What this article misses is that genuine feedback helps us grow, and being open to it is as important as being able to deliver it in a way that doesn't take something away from the recipient. Getting others' input and adapting to it (or learning when to accept but not heed it) is crucial for getting better at whatever endeavor one is engaged in.

If you have a suitable level of trust and respect between you and the person requesting approval or feedback, then your input can be valuable without it being undermining of their ownership of their creation. In fact, the opposite; by soliciting feedback (preferably early, not just at the end of a project), you can help build a sense of ownership from the person giving feedback.

<comment><USER24> I thought that was the point of the article—give people only genuine feedback that helps, not hassle them with minutia. Giving unsolicited advice to people you manage can undermine the "suitable level of trust" that you would otherwise have, if you're not careful.

There is a big difference, after all, between requesting feedback from someone you respect and getting approval from a superior in a hierarchical power structure.

What the article is touching on is the tendency for some managers to give feedback on everything just because they can. Other people in the organization won't have that privilege, and giving feedback on everything reinforces the fact that the other people in the organization are subordinates and don't have that privilege.

<comment><USER25> Exactly. If this article annoys you, read it again carefully, it does _not_ argue against feedback in general.

</comment></comment></comment><comment><USER26> This seems a bit condescending to me. I can take suggestions and feedback without losing sight of my own accomplishments. Because I'm an adult.

</comment><comment><USER27> I sometimes convince my boss that he is wrong. I think it's a sign of a healthy team.

</comment><comment><USER28> Related: Parkinson's Law of Triviality, and the Queen's pet duck in Battle Chess (when developers become aware of management's need to unnecessarily "finishing touch" all work and begin making slightly-inefficient choices intentionally to give the work a "shear point" where the management can feel like they're contributing by removing something obviously incorrect).

[https://en.wikipedia.org/wiki/Law_of_triviality](https://en.wikipedia.org/wiki/Law_of_triviality)

Similar processes have been used for decades by movie and television creatives to move the Overton window on media censorship---early cuts of a project will have something _obviously_ grotesque and culturally repugnant, so the censors lock onto that and miss the risqué thing the creator wanted to get to their audience.

</comment><comment><USER29> Love the suggestion. So many times have minor suggestions from managers killed the enthusiasm for a project because it feels like the manager can't think about or appreciate the bigger picture. In fact, it looks like he is only trying to own the success of the project by picking on non-important stuff.

</comment><comment><USER30> Some factors in motivation at work are the level of autonomy, mastery and purpose in your job.

A coworker giving minor feedback is only contributing to your mastery. A boss giving you the same minor feedback is cutting in to your autonomy. The exception is when the purpose is great and sweating every detail is necessary or when the boss is a recognised master of your craft and their feedback is almost always correct and regularly helps you improve.

An example of the first case might be engineering at SpaceX and the second could be Steve Jobs giving engineers and designers product feedback. What I think a lot of people are missing in this thread is that in most situations the purpose is relatively uninspiring and the boss is significantly less skilled than the person she is giving advice to.

</comment><comment><USER31> I am reminded of the story about the duck!

[https://rachelbythebay.com/w/2013/06/05/duck/](https://rachelbythebay.com/w/2013/06/05/duck/)

</comment><comment><USER32> I think the article/blog post is missing a key point in that the employee came to the manager asking what he thought.

This is a critical role that the manager plays that the article decides to come up with a unreferenced social psychology manipulation solution when there is a greater problem at hand.... the employee is nervous about shipping the product and wants approval.

The reason why this is because a great manager is supposed to protect and shield employees from the outside so that they can feel at ease with making decisions and working with out fear of making some mistake that costs there job (unlike the article I can site like 5 or so Harvard Business Review articles written by experts that show this is often the reason why employees come to ask questions like that.. yes I'm being snide but I think "What got you here want get you there" is basically on overrated Dale Carnegie rewritten).

Not getting any input sends a message of "I don't really care about your work". And if you really wanted to coach and you really believe this arm chair psychology then why not send a link of the article to the employee asking the advice and say "I would like to give some input but I want to assure you that I think you own this project... etc etc...".

Education is a powerful thing... manipulation is not.

</comment><comment><USER33> The way I've always tried to approach this is by pointing out problems, rather than offering solutions, especially where I'm in a position that I'm giving feedback to someone who is more of an expert in the activity than I am. Expressing things as problems automatically eliminates a lot of the minutiae about wording, color, etc. (since those are just subjective opinions and not reflective of a problem), and it lets people still feel like they're owning the work and not making changes they disagree with because they're forced to.

Example:

Providing solutions: "Move the 'widgets' menu to the top. And make it bold"

Expressing a problem: "So, when I'm using the app, one of the first things I usually want to do is look at my widgets. It took me a few minutes to find out how to do that."

The solution to this problem might be looking into whether accessing widgets is a common use case, or finding different ways of educating users about how to find widgets, or yes, even moving it to the top. But no matter which solution is chosen, everyone is going to come out of it with more information than if they blindly implemented the manager's uninformed opinion.

</comment><comment><USER34> My experience with work is that everything can be slightly improved all the time. You have to stop at a certain point and I think the author has found the nicest place to stop, at least for employee happiness.

On the other side, if you have been working on something alone, I think it is a clever idea to accept the feedback of your boss just to have another perspective.

</comment><comment><USER35> Dale Carnegie Rule #1: Never condemn, criticize or complain. In general, we're all not actually looking for input so much as support.

Human nature is such that even when we readily acknowledge someone better at something, we quietly indulge and seek out advantages we have in other areas.

We engineers like to think we're more rational and accepting of input. Working as a coder and manager for the last 20 years has shown me there's nothing further from the truth.

</comment><comment><USER36> Man! I wish my boss had read it 5 years ago. I could never understand why I was not motivated in my job at all even though my boss was really brilliant. It basically reduced to this. No matter what I did the boss always had 2 cents that had little impact on anything but made be less interesting in doing the work. But for my next job the boss was much better, instead of saying change this and change that he would often ask me why I made certain choices and what inspired me. He would then say "ship it" but the questions he raised made me wonder how I could make things better.

But the advice is something everyone must learn.

</comment><comment><USER37> Tread carefully between being fake and being sincere. People will stop asking you if you give a fake answer like the article.

<comment><USER24> People who can't sincerely ignore trivial matters probably should stay out of management.

<comment><USER25> I assume GP was refering to the "great work" part, but even then it's just matter of style; the point was only to show approval without nitpicking, not emphatic congratulations.

<comment><USER24> Ah yes, it's too easy to think that a comment is addressing one point when it is addressing another.

</comment></comment></comment></comment><comment> torrent-of-ions Ugh. This reeks of "safe space" nonsense.

Part of working in a team is receiving comments and criticism from others. If you take these negatively and as attacks to you, rather than collective construction towards the final goal, then you have a problem and need to consider changing job.

I find that when I design something I become accustomed to early design choices and then eventually become blind to them. I need someone to come along with a fresh pair of eyes, see the whole thing and nitpick it. It's absurd to suggest that it's either perfect or needs to scrapped entirely.

<comment><USER38> Well, I was going to downvote, but figured it's better to comment.

> Ugh. This reeks of "safe space" nonsense.

What? I have very little idea what you are talking about, so I looked it up on wikipedia: "In educational institutions, safe-space (or safe space), safer- space, and positive space originally were terms used to indicate that a teacher, educational institution or student body does not tolerate anti-LGBT violence, harassment or hate speech, thereby creating a safe place for all lesbian, gay, bisexual, and transgender students."

Which frankly sounds like a good idea, but doesn't seem like it has much to do with this blog post about managing members of your team.

> Part of working in a team is receiving comments and criticism from others. > If you take these negatively and as attacks to you, rather than collective > construction towards the final goal, then you have a problem and need to > consider changing job.

Yes, except the point of the blog post is that managers should be aware that comments and criticism they would have been happy to offer as co-workers suddenly start to look a lot more like commands when they are coming from a boss. It's a good idea for new managers to be aware of this changed dynamic.

<comment> torrent-of-ions > > Ugh. This reeks of "safe space" nonsense.

> What? I have very little idea what you are talking about, so I looked it up > on wikipedia: "In educational institutions, safe-space (or safe space), > safer-space, and positive space originally were terms used to indicate that > a teacher, educational institution or student body does not tolerate anti- > LGBT violence, harassment or hate speech, thereby creating a safe place for > all lesbian, gay, bisexual, and transgender students."

It was originally something like that but "safe spaces" just turned into echo chambers where everyone is only allowed to agree and encourage people and dissenting opinions are considered "unsafe".

</comment></comment></comment><comment><USER39> A better way to approach this situation: "That's great! Love it! Out of curiosity, what inspired you to choose those colors and fonts?" Then, they still have ownership, but they also are given the chance to justify their choice and it starts a conversation that could lead to improvements, if necessary.

<comment><USER40> Unless you're genuinely curious, that would likely come across as passive- aggressive undermining.

<comment><USER41> Even if you are genuinely curious, such inquiries from a boss/"authority figure" can easily come off as threatening, so tread very carefully with advice like that.

<comment><USER42> Indeed - it only takes two or three easy questions like that to become a pattern, at which point every question is code for "guess what you did wrong", which is toxic.

</comment></comment></comment></comment><comment><USER43> Is it not possible to make it clear that your 2 cents is just a suggestion? This just seems like bad communication, and regardless of whose fault that is, the boss might as well try to solve it.

<comment><USER24> It's a "suggestion" from a direct superior in a hierarchical power structure. A little bit of communication isn't going to change the context.

So no, it is not something simple like "bad communication".

I think one of the main problems here is that people in power often feel like they have to justify themselves by giving technical feedback, even when it's not appropriate.

<comment><USER44> But there are ways of eliciting critical thought about the choices made and even about alternatives that the person in power has.

It is "bad communication" in that the person in power is communicating their desire in a way that is perceived, even if just a little bit, as being a command. And I do believe there are effective ways to mitigate this.

<comment><USER24> This conversation is a great example of bad communication, if you want a reference.

Communication is not just about how you communicate, but when. Good communicators know how and when to listen, and they keep their mouth shut when it's appropriate. That's the lesson of this article. If that's not a problem for you—if you know when to speak and when to listen—then maybe this article won't help you, personally.

And if my manager was always trying to elicit critical thought about trivial and mundane matters like font choice and colors on internal tools, then I'd want them to just shut up for a moment. I'd be glad to hear what your effective mitigation strategies are for giving unnecessary advice.

<comment><USER44> I think the issue I have is that the author is taking an all or nothing approach. Either something is all wrong and a larger discussion must be had or nothing is worth noting. There is a huge range of things in between there, many of which may be small opinions.

After reading the article a few more times and the comments here, I'm getting the impression the author meant "don't add pointless opinions or suggestions to things." The use of the phrase "my two cents" beguiles the author's intent, as in many cases that phrase is not used when one has a pointless opinion.

<comment><USER24> Yes, I've heard the "my two cents" phrase used with important or strongly-held convictions, but that's just an ironic use of the phrase to mean the opposite of what it usually means, no?

It may also be a dialect issue, like the old "let's table this" problem.

I was definitely not reading "all or nothing" from the article, more of "if you only have something trivial to say, don't bother." Hence, don't give your two cents, but put a dollar in when it matters.

</comment></comment></comment></comment></comment></comment><comment><USER45> Oh how I wish I had a downvote ability on this post. The first thing wrong with this is the fact that the post is nothing more than the author's 2 cents. The author doesn't know what they hey they're talking about and is just pontificating.

As someone who does a lot of creative work, I _hate_ it when people just give useless positive encouragement and withhold actual constructive feedback, small or large. Only hypersensitive people feel worried about their loss of ownership because they accepted someone's suggestion.

A situation where a boss having a color preference means that a designer feels unable to reject the suggestion is a dysfunctional workplace. When the manager has that type of feedback, they are not being a manager. A good manager makes it clear that if they have color feedback, that's just their suggestions and not them acting in capacity as a manager.

<comment><USER46> I have to agree with a lot of what you say, but just as the article I think you haven't completely thought through what you are writing.

For instance, let's add two points that in real life can't be circumvented: a) most places that pay you will be dysfunctional work places, and b) you don't always have a choice of work since you need to pay bills.

And what are your standards for downvoting? I downvote when I think a comment/link is hurtful for the discussion or people involved. And yes, while it is not a very well finished article from Derek, it leads to a healthy discussion and in itself is not a bad/hurtful opinion to have.

<comment><USER47> > _most places that pay you will be dysfunctional work places_

This article is aimed at _managers_. It is advice on how to create a functioning work place. To the extent it fails to do so, it is entirely appropriate to say "Hey, this is bad advice for reason X."

It is not interesting to rebut this by saying "Yeah, but reason X isn't valid if the manager is terrible." The whole point is that the manager shouldn't be terrible. This isn't advice for non managers and it isn't advice for managers who aren't trying to be good managers. Managers who don't care about creating a functioning work environment aren't reading and discussing this anyway.

</comment></comment></comment><comment><USER48> Reminds me of the designers pricelist.

[http://www.creativebloq.com/career/graphic-designers- price-l...](http://www.creativebloq.com/career/graphic-designers-price-list- priceless-91516736)

</comment><comment><USER49> This doesn't necessarily invalidate the advice, but Steve Jobs clearly did not abide but it (would critique icons at the pixel level, etc.), so it is demonstrably not universal advice for building successful companies.

<comment><USER50> I would argue that sj only critiqued things that he genuinely felt needed to be changed. Though he was also demonstrably the worst manager one could have so I wouldn't draw too many conclusions from him.

<comment><USER49> _> sj only critiqued things that he genuinely felt needed to be changed_

Which included incredibly detailed nuances like pixel-level critiques of icons and UIs, which is literally what the author defines as "your 2 cents".

 _> demonstrably the worst manager one could have so I wouldn't draw too many conclusions from him_

Except how to build one of the most valuable companies in the world? Seems like a fair criterion for good management.

<comment><USER51> Why did Steve Jobs think the iPhone shouldn't be able to copy and paste?

</comment></comment></comment></comment><comment><USER52> As an independent contributor I don't want my manager weighing in on my choices. I see them as out of the loop on the more technical aspects of my job and they should leave those decisions to me.

If I come to a more technically senior member of the team who is more knowledgeable, it is to _precisely_ ask for their opinion.

So in my mind: if you're a manager, don't bother; if you're a more senior IC, do, with the explanation of why your approach is better. You're more of a mentor at that point than a manager.

Oh, and if your approach isn't really better, just different, keep it to yourself.

<comment><USER53> > Oh, and if your approach isn't really better, just different, keep it to > yourself.

This really is the heart of the problem, not giving feedback when it is solicited (unless it is really soliciting for approval rather than feedback).

There usually are many ways to do something, all of them roughly equal and it doesn't matter who gets to chart the road to take, as long as _a_ road gets taken and you can move on to the next issue. Way too often the discussion will center around who gets to claim that their road was taken, which is more often than not utterly irrelevant.

Office politics is the silent killer of teams, projects, products and whole companies and this is one of the more immediately destructive manifestations.

</comment></comment><comment><USER54> This is an excellent mini-rule for habitual micromanagers. Like me :)

<comment><USER53> Maybe you could use 'good' instead of excellent and a ;) instead of a :)?

</comment></comment><comment><USER55> This is a total straw man. There's something in between bikeshedding and blindly approving work you feel is less than perfect. What if the boss responded with, "Why did you choose this color of blue?" This indicates respect for an intentional choice, lets the employee provide a rationale and be heard, and still moves towards a better final product. There's a false dichotomy presented in the article, and it's crap.

</comment><comment><USER56> Honest question - is this idea of individual ownership conducive to team morale, enough to protect ownership like this? I've seen a lot of examples of how "ownership" backfires when people are protective of their turf or disregard others' valid input. Ownership seems to be commonly used to get people to take personal responsibility as a proxy for motivation, it does help some people set better examples, but does it motivate a team and make it more cohesive on the whole?

I have seen 2-cents backfire a lot a well, but I think it's most often strong personal opinion not backed by good reasons, like evidence or unseen constraints or dependencies, etc.

This article started by the boss asking for " _non-obvious_ advice", and then provided an example of advice that was pure opinion without any reason, and stated as a veiled command rather than offering an alternative option. It can be important to share actually non-obvious insights, even if it's just 2 cents worth, so I won't be asking my team to avoid sharing their 2 cents as a blanket rule, I will ask them to share any important insights they may have, and encourage them to have a good reason.

</comment><comment><USER57> As somebody who is working himself up the food chain and has a tendency to give his two cents, this is some real food for though. Thanks for sharing!

</comment><comment><USER58> Huh... approaching this from the opposite side, when my boss has suggestions I always take it as an opportunity to let them feel some ownership of the work, even on occasions where the suggestions don't turn out to be that useful in practice ("I implemented your suggestion of X, which led me to come up with Y").

 _Trying to game professional relationships goes both ways I guess :)_

</comment><comment><USER59> It's tough to be prescriptive about this sort of thing in a general way. Every situation is different. It really depends on who you're working with, sort sort of context you're working in, what sort of expectations you're working with, etc.

I would say, "make sure you set expectations in advance about how feedback is to be interpreted and acted upon". My boss gives me his 2 cents all the time, and I enjoy it. And vice versa. Sometimes I preface my suggestion with "you don't have to do change anything, but FYI...", and sometimes I say "I feel quite strongly about this: XYZ" – and even then we have an understanding about whether or not something should or should not be changed. It works the other way too. I've shipped things without incorporating feedback, and all was well.

So I think it boils down to culture. Everyone's understanding of what the norms are, what is expected, etc. (Just for fun: Can you imagine telling Elon Musk or Steve Jobs not to add their 2 cents?)

</comment><comment><USER60> This would need to happen 10 times before I would think I don't own the project. If I can't take input, I should not have a job.

</comment><comment><USER61> > because it's not just one person's opinion anymore — it's a command!

Spot on. Exactly the reason for quitting my last job. Boss(manager) comes and adds his 'suggestion' to every task.Even though, I tried to stick to my way to going about the task. He continued to insist that I should give this view a trail run first. After a week or so, When thing go wrong, I'll go back original method and finish the task.

Later, he will complain about I'm being slow to respond to task. When I point out the unnecessary time-wasted due to his suggestion. Now he will backtrack & put it as 'I was only giving suggestions, it was your baby anyway'. It happened 3 or 4 times & I had enough.

Funny thing - During my last day, I took this issue to CEO. To my surprise, he said, 'Yeah, employee has to take my suggestion, since I'm their boss'!

[to those bosses if you are reading this:] - I don't have any issue with trying out your ideas - but when thing go wrong, take the responsibility for your _stupid_ idea.

</comment><comment><USER62> While I'm normally a fan of Derek's musings, this one is too pithy for me. He is painting with too broad of a brush. There are all kinds of reasons why you might tell an employee to make small changes: maybe one small change will have a big impact; maybe many small changes in aggregate will have a big impact; maybe the employee doesn't want to take ownership; maybe the employee is too junior to take ownership; maybe the employee wants to learn the nuances of the profession in greater detail; maybe the employee is an underperformer; I could go on like this indefinitely as could many other experienced managers.

Now maybe if you're employing a bunch of independent-thinking artistic, creative and intelligent types this generalization makes sense. But I'm sure the global workforce has substantially more than 1 billion members who don't fit this definition. In that light it seems a little irresponsible to put this thought out there like it's a zen koan.

</comment><comment><USER63> If your team cannot take your feedback just like taking feedback from their colleagues, cannot argue with you or veto your idea easily with a legitimate response, take everything you said as a "command" then you have failed as a manager anyway.

I assume Derek's advice makes sense for Korean culture where manager and team dynamics are different.

<comment><USER12> I've seen this happen over and over again in American culture. One of my most common pieces of feedback to managers centers on this, in fact. Time and time again I see managers who _think_ they are able to give feedback as "one of the team" and that they aren't "the boss" or giving people orders... but when you speak to their reports, they are interpreting it as orders from the boss. Even if you produce documents declaring your workplace to have a "flat" structure, people tend to treat any feedback from the person who signs off on their paycheques as commands.

<comment><USER63> 2 things:

* It's about how make the suggestion. "How about making this blue darker?" vs. "Do you think making this blue darker would give us more engagement? Are there any studies, or have we done A/B testing on this? I think it fits on our branding better because..." etc. Derek's example is really bad one though. Why would a manager (unless an experienced designer) would make such a pointless suggestion?

* If everything you say is just done without any sort of questioning then it's obvious there is a problem.

So I think any decent manager would notice it.

</comment></comment></comment><comment><USER64> Maybe rather than avoiding giving helpful feedback, they should work on fostering better employer - employee relationships

<comment><USER24> I think it's a common delusion for managers to think that this kind of feedback is helpful, which is the kind of misconception this article addresses.

"They should work on fostering better employer - employee relationships" is non-advice, it's just a goal statement. Kind of like telling a runner that they should try going faster.

</comment></comment><comment><USER65> This reminds me this story [https://rachelbythebay.com/w/2013/06/05/duck/](https://rachelbythebay.com/w/2013/06/05/duck/) (Project managers, ducks, and dogs marking territory)

</comment><comment><USER66> I have a similar tip to provide:

When a designer or developer shows you a version that is not nearly done, don't provide any _specific_ feedback. If you mention specifically that a button should be red instead of blue, for example, then you are communicating that they are almost done, and they simply need to make the minor changes you mention for you to be happy. If the work isn't nearly finished, it's better to instead say, "Great work so far. I don't want to rush you. I think you should spend some more time refining the UX. Do a few trial runs as a user and do the best job you can to make the most perfect UX possible."

As soon as you mention specific things, they mentally move on.

<comment><USER67> Absolutely terrific advice.

As soon as I read "_specific_ feedback", my eyes lit up.

Another issue with specific feedback is that "...should be red instead of blue" type feedback can derail a designers whole thought process, a thought process which usually doesn't end at the delivery of a draft, which is merely an optional stop along the way in the mind of the designer.

A designer might have ideas for how to address certain kinds of objections to a draft. For example, if boss says, "It doesn't match our brand well enough.", the designer might have some specific ideas that he/she came up with, in case that was a perceived issue. If, instead, the boss says, "It doesn't match our brand well enough, so add more blue.", then the designer's route can no longer be used, and an entirely new route has to be determined.

I use the railway analogy, because I think it actually maps exactly: Imagine you, as a train passenger, told the conductor (the person you've hired to be your railway professional) exactly where to go, and there wasn't a predefined switch for getting there OR the switch for getting to that exact location has already been passed. The only way to achieve this new route is to backtrack or build a new switch track, both of which are more expensive than continuing on the existing route to a location that also solves the passenger's problems.

</comment></comment><comment><USER68> As a follow up to this article, I need about 40 examples that illustrate the difference between manager opinions that are worth two cents, and useful manager feedback. Or about 10 years of experience, but I'm hopeful that someone will offer examples.

</comment><comment><USER69> Sorry, but this is just lame. A manager has a job to do, too, and whether or not they do it well, it is within their prerogative to add comments or suggestions, even if small, if they think it will improve a product.

Put yourself in the manager's position (which ironically this article seems to attempt to do). Go further, suppose it is your company, not just your department. Are you going to let a product ship when something minor could be improved to make it even better? A sloppy manager might. Or one who doesn't care. This article almost seems to suggest that managers should care less.

Attention to detail is what often separates good from excellent.

<comment><USER70> I think the point is to avoid getting lost in the forest because you want to climb every tree.

As part of a leadership training program I once did, we had a Q&A with an executive where we could ask him anything. One of the questions was "What was the most surprising thing about going from an individual contributor to a manager to an executive?" His answer was, "I learned that as you get higher up in the organization, oftentimes you need to seek _a good_ solution rather than _the best_ solution."

Yes, this means that the product will be less excellent than it could be. Anyone who has used a big company's product can tell you that this is what actually happens. And yes, this leaves openings for big companies to get replaced by hungry little startups. But the alternative is for the big company to function like a startup that has a few thousand uncommitted people wandering around drawing a salary while providing input. Imagine working under those conditions as a founder; you won't get very much done, and people who work under those conditions in a big company don't get much done either.

If you want the product to be excellent, go quit and make an excellent (if minimal) product. If you want to work with a lot of other people, then let them do their jobs.

</comment></comment><comment><USER71> Maybe "Don't add your 2 cents" is not the best way to frame this, but he is correct that being the boss means _your opinion is dangerous._ More accurately, casually tossing out half-baked ideas is dangerous for anyone with real power or even social influence. When your words carry enormous weight merely because you said them, you need to be more careful about the things you say because it will have consequences. If it really is just a casual opinion, and not something you have really thought about, it is better to err on the side of not expressing it in such a situation.

</comment><comment><USER72> Feeling ownership doesn't have to mean managers can't contribute at all, that's absurd.

Creative labor is unqiue - Depending on the employee, I know I have X changes I can suggest/propose per project before they start to get annoyed with me, for some it's more than others. Unsurprisingly when its promo time the guys who are easier to work with get brought up (even if the difficult divas work is marginally better) The big thing is trust and respect - earning that early on is key and once you do things are much easier going forward.

</comment><comment><USER73> Your boss' opinion might not be better... but it often does have more authority.

In my case, I work directly for the president of the company. He owns the place, he founded it, he built it, it is his. Whether or not his opinion is better, it does hold complete authority, and it is his right to have his company run his way.

Now, if you are a low/mid-level manager, the advice from the article may be more applicable to your situation. But your own corporate structure and culture will have an impact on the validity of that advice.

<comment><USER74> Speaking as someone who has been "the technical guy" for 20-odd years, if the president of the company wants to pick nits like variable names and coding style, he's perfectly within his rights to do so. But he can do it without me.

<comment><USER75> I've worked for those "I'm the CEO, do it my way" guys. They hire you for your brain but end up only wanting to use your fingers.

<comment><USER73> There is probably a balance to be struck. Because I've also worked for milquetoasts whose teams walk all over them, doing whatever they want. The product suffers, the team suffers, and the company suffers.

</comment></comment></comment></comment><comment><USER76> This reminds me of that story about the bikeshed[1] colour: "This is a metaphor indicating that you need not argue about every little feature just because you know enough to do so. Some people have commented that the amount of noise generated by a change is inversely proportional to the complexity of the change."

[1]: [http://bikeshed.com/](http://bikeshed.com/)

</comment><comment><USER77> Wow, what a bad example. That is called constructive criticism and is a very valuable tool in a company's toolbox of culture.

What I observed to be actually harmful is criticism of how an employee works: Tools, practices and habits. If your boss tells you that the build tool of your choice sucks without naming a better alternative or any constructive advice, that feels really bad and destroys motivation for the job.

<comment><USER78> No it isn't. The example presented is the manager throwing in his two cents worth because they feel they _ought_ to contribute something, which is what the article is arguing against.

</comment></comment><comment><USER79> My two cents: rather than tell someone to change a word here, a colour shade there, what you should do is give your reasons for WHY. Why is this shade of blue better than the one I chose? Why is a given call to action better than another? That way, your opinion becomes, if not data driven, at least reason or anecdote driven. And that shouldn't demoralize anyone, I should think.

</comment><comment><USER80> The boss should not say, "it's perfect!", if the boss feels it is not....which is literally what this article is advocating.

In the hypothetical situation described, I get the impression that the boss didn't even look closely at the two weeks worth of work. To then get immediate flattery feels very disingenuous to me.

</comment><comment><USER81> If your manager asks you to change a color or font or whatever that has 0 relevance to the actual task, you know then that your manager is an idiot and you should probably start searching for another job or a way to move up over him.

I had number of such situations. You are almost always better off without that in your life.

</comment><comment><USER82> Emperor Joseph II from Amadaeus: "My dear, young man, don't take it too hard. Your work is ingenious. It's quality work. And there are simply too many notes, that's all. Cut a few and it will be perfect!"

</comment><comment><USER83> The problem is the initial question, not the manager input. There's a significant difference between delivering something with facts than delivering something and asking for approval.

</comment><comment><USER84> I like to get feedback from as many people as possible, and take action on MOST of the [actionable] feedback. In my experience, this always leads to a better final product.

<comment><USER48> You have obviously worked with more competent people than me.

</comment></comment><comment><USER85> I always feel not to add those extra two cent when i'm responsible to something. You just my words here. Thanks

</comment><comment><USER86> So as a leader, she/he does not need to get into details and just simply _ignore insignificant details?_

</comment><comment><USER87> Yes, bosses should always say "Perfect work!" so the developer feels full ownership of the project.

</comment><comment><USER88> I think this is more-so a critique of toxic manager-developer relations, but that's just my 2 cents.

</comment><comment><USER89> The correct management approach is to test 41 different shades of blue, collect $219M.

</comment><comment><USER90> > "It's perfect. Great work!"

I cringed. It's not perfect, it's at best _excellent_.

</comment><comment><USER91> So if I have an honest opinion about something my coworker or employee asks me, I should not tell him, so that I won't hurt his feelings?

Is this kindergarten or grown-up life?

Especially in creative areas it pays to let other people look at your stuff and get feedback. It is simply too easy to just get stuck on a path.

<comment><USER12> The article draws an explicit line between giving feedback as a coworker and as a manager. If you didn't get that, rather than reproducing the arguments here I humbly suggest you re-read it.

</comment></comment><comment><USER92> Great advice. Now how to subtly get the boss to read this...

</comment><comment><USER93> This makes so much sense yet didn't cross my mind.

</comment><comment><USER94> Excellent. So simple advice, so obvious, so true.

Works with kids, too.

</comment><comment><USER95> Huge Sivers fan! With that said, I'd take this advice way further.

> The boss's opinion is no better than anyone else's.

All opinions are no better. Does not matter who. Throw out opinions altogether. In America we are obsessed with "our right to our opinion" and somehow have confabulated this to equal our individuality, our exceptionalism, and our success. We're unique to begin with, exceptional is only a hard earned reputation, and success is just a feeling. Case in point, unique is effortless because it takes effort to be identical to other people; no one has ever been exceptional without doing exceptional work; define success conveniently, and we're all successful.

> your opinion is dangerous

All opinions are dangerous. A doctor doesn't operate based on opinion. Engineers don't build rockets based on opinion. Programmers don't program based on opinion. Reality is fact based, not opinion based.

Don't add your 2 cents. Add something that's actually worth something. Faster, lighter, stronger, cheaper, smoother, more efficient, more succinct, more obvious, more fun... Better is measurable. If you need progress, you need facts. And if you start comparing "opinions" and find one is better, you're already seeking facts. Opinions about opinions is demonstratively far worse.

Of course, this is all professionally speaking. When consequences don't matter, we're free to indulge in our opinions because we all have them. They're automatic. But just because you thought something, it doesn't mean squat. If anything, opinions are funny. Off the clock, do and say whatever you want. But whenever you need to be real, share what you know, not what you think. The more you know the better. Never confuse this with the more you talk or the louder you voice your opinion. Bosses that authoritatively enforce their opinion are the worst.

And most importantly, know when you know. Because only then can you or anyone go gather facts before making that important decision. Talking and thinking is not gathering facts! Googling is.

If you're still wondering why Donald Trump is doing so well, it's because so many of us still live in an opinion based reality. He is the feel good candidate for his supporters. Hasan Minhaj just did an awesome piece on the Daily Show [0]. His supporters don't care what he says, and their opinions are hilarious. Not to mention they are all wonderful people. If not for politics, we'd all be holding hands in a circle.

For better or worse, democracy treats facts and opinions equally. But a good boss won't. They are not equal, and only one leads to true progress.

\----

[0] [http://www.cc.com/video-clips/ukn1y5/the-daily-show-with- tre...](http://www.cc.com/video-clips/ukn1y5/the-daily-show-with-trevor-noah- muslims-prepare-for-a-donald-trump-presidency)

<comment><USER96> In terms of design, everything is an opinion. You can't prove one design is better than the other... unless you ask for multiple people's opinion. It boils down to opinion in the end.

<comment><USER97> You can't prove a design is better than another but you can measure it. You can use beta releases or focus group and other methods. Abstract things like feelings and intuition tell you one design is better than another. Relying on intuition might be what works best if you are alone. But there are also concrete signs: user feedback, churn rate, etc. Although we can agree that the best design is not always the most successful. In the long run good design lasts.

<comment><USER95> Having good taste is the empirical skill for judging the aesthetics or experience of anything. If you have good taste, you know you can rely on your intuitions. If you don't, you need someone who has good taste.

> You can't prove a design is better than another but you can measure it.

If you can measure it, you can prove it. The missing key is priority. If you prioritize what your design needs to be better at, then you have a concrete reference for scientifically measuring one design against another.

A common conflict is having multiple priorities. If you want a page to look good, but also want to maximize your ad revenue, well, no matter what you do, you've lost freedom in both. But if someone accuses you for building an ugly page, you can show them the numbers, and their opinion will not matter. It will matter as little as yours. I mean, you probably agree with them.

</comment></comment></comment></comment><comment><USER98> Great advice, short but precise!</comment>


Reverse Engineering the GoPro Cineform Codec - <AUTHOR> https://medium.com/@kierank_/reverse-engineering-the-gopro-cineform-codec-7411312bfe1c <comment><USER2> Pretty cool, I like these kinds of articles.

> An interesting feature where coefficients were pre-aligned to mod-8 widths > to presumably allow for SIMD optimisations

I have seen protocols implemented in such a way that when described on paper, they look convoluted, especially how they specify alginment "this will have this much padding, this one will be aligned on this boundary. Little endian encoding for integer values...".

However I quickly realized they basically picked a particular memory layout in a C struct generated on x86-64 architecture, by a particular compler (gcc 4), and particular OS (Linux). I imagine at some point someone implemented it like that, then they went back and wrote into a standard. It would have been nice to at least mention that in the docs footnote ("Encode these as C structs on this combination of arch/compiler/os and cast binary blobs to the struct to serialize/deserialize data in this format)

<comment><USER3> > I imagine at some point someone implemented it like that, then they went > back and wrote into a standard. It would have been nice to at least mention > that in the docs footnote ("Encode these as C structs on this combination of > arch/compiler/os and cast binary blobs to the struct to > serialize/deserialize data in this format)

That footnote could cause multiple problems. Someone might just use that C struct and expect the layout to match, which would introduce portability problems (such as if using a different target OS, as Windows and Linux have different struct layout rules). Or, conversely, someone might see that line in a proposed standard and reject it as non-portable, whereas a precise description of memory layout would not come across as such. (In particular, the memory layout of structs by GCC on x86-64 Linux matches the memory layout of structs by any compatible compiler targeting several different 64-bit architectures on several POSIXy platforms.)

<comment><USER2> > Or, conversely, someone might see that line in a proposed standard and > reject it as non-portable, whereas a precise description of memory layout > would not come across as such.

Yap that makes sense, I din't think of it that way first but that probably explains it.

</comment></comment></comment><comment><USER4> > However, real-world files didn't seem to match a lot of the document which > was odd. All of this was buried in the small-print of course: "the core > technology behind the GoPro CineForm Codec has been standardized [sic]". So > in reality existing files were not decodable by a VC-5 decoder.

This is why open source is often so much better than open standards (though the latter the was used to help create the former, in this case).

Huge kudos to the author for doing this work, as well as explaining the process.

<comment><USER5> Not sure what open source would accomplish here - without a standards paper you can't get multiple conformant players for a format, because the company can just constantly move goalposts around as much as they will.

The best way to implement video standards until now has (as pretty much everywhere else) been a good tight specification coupled with a several conforming decoders without any monopolizing the market. It keeps the vendors honest.

</comment></comment><comment> c-slice Fascinating post. I wonder if anyone has tried to decode the Audible audiobook format - ".aa"?

<comment><USER6> Spotify's ".file" has been a tough one to crack.

<comment><USER7> The only work I've seen on breaking Spotify DRM encryption was this[1], back in 2014 and discussed on HN here[2].

[1]: [http://moyix.blogspot.com/2014/07/breaking-spotify-drm- with-...](http://moyix.blogspot.com/2014/07/breaking-spotify-drm-with- panda.html) [2]:

<comment><USER6> That is...genius!

</comment></comment></comment></comment><comment><USER8> Wavelet image compression is itself interesting and quite intuitively simple (if looked at in the right way):

[http://www.iquilezles.org/www/articles/wavelet/wavelet.htm](http://www.iquilezles.org/www/articles/wavelet/wavelet.htm)

</comment><comment><USER9> FEC stands for forward error correction

<comment><USER10> You can edit and delete your comments, no reason to spam one-liners, especially not without connection.

</comment></comment><comment><USER9> Http://rphlo.github.com/ there is a go pro repo

</comment><comment><USER9> Interlaced stream of RTP h.264, audio stream, and FEC channel

</comment><comment><USER9> [https://github.com/rphlo/GoProLiveProxy](https://github.com/rphlo/GoProLiveProxy)

</comment><comment><USER9> [https://tools.ietf.org/html/rfc6184](https://tools.ietf.org/html/rfc6184)</comment>


The person(s) behind the mirror - <AUTHOR> https://www.josephkirwin.com/2015/09/16/person_behind_the_mirror/ <comment><USER2> "When we published some simple byte matching detection, it appeared that an "automated system" on that attacker's side would modify the previous version by doing some simple code manipulation that didn't change the functionality of the malware, but broke our detection signature."

The major flaw of some AV in one sentence.

<comment><USER3> That's an inherent problem in all AVs. Signatures based systems can be bypassed easily. If you're not using signatures, then the AV is running/analyzing the code which leads to the halting problem.</comment></comment>