Stop Learning Frameworks - <AUTHOR> https://sizovs.net/2018/12/17/stop-learning-frameworks/ <comment><USER2> One benefit of learning a framework is that you can internalise the mindset of the authors, and another is that you can see abstract patterns and ideas in their native habitat.

Learning Rails taught me about metaprogramming, reversible database migrations, ACID, and the pros and cons of ORMs. Learning how to build XAML apps with C# taught me about two-way data binding, MVVM, DSLs, and socket communications. Learning React and Redux taught me about cooperative threading, functional programming, transactional state management, and testing front end features without using selenium and webdriver.

Now, I already "knew" most of these things, but I hadn't applied them in the real world before. Getting to experience them as implemented in well-designed frameworks taught me a lot about their practical use, building on top of the theoretical knowledge I'd already acquired.

EDIT: cooperative threading, not cooperative multitasking

<comment><USER3> A downside of that approach is that sometimes authors implement bastardized versions of basic concepts and thus learning frameworks ends up warping the developer's mental model. Case in point: Qt's take on the MVC design pattern.

<comment><USER4> Is your issue that Qt "lacks" a controller, or that it only supports homogeneous column-row models with natively numbered (not named) columns, bound onto homogeneous table-like views (not widget sets)?

</comment></comment></comment><comment><USER5> The author says he bought these books:

        The Pragmatic Programmer
        Clean Code
        The Clean Coder
        Domain-Driven Design
        Growing Object-Oriented Software, Guided by Tests
        Continuous Delivery

Not to curb anybody's enthusiasm, however these are soft-skill books.

I've read The Pragmatic Programmer on a 10 hour flight and I fell asleep 2 or 3 times, because it was freaking boring. Beginners might get some value out of it, but it's all common sense stuff that you learn in the first couple of months on the job.

Everybody has some of these books in their bookshelf, including other classics such as the Art of Computer Programming. What I find interesting is that few people read these books, either because they are boring (the soft-skill ones) or because they are really hard to follow (AOCP), but keeping such books in your bookshelf is like a rite of passage. You can't call yourself a programmer if you don't have a couple of programming books in your bookshelf that you've never read :-)

To switch from framework learning to soft-skill books doesn't feel like much of an upgrade. If you want to learn something with long lasting value, learn actual _computer science_.

This means algorithms and math.

It also means exposure to paradigms like functional programming, or logic programming. I recommend Haskell, not because you need to learn yet another language, but because the knowledge ceiling in its ecosystem is really high and it's the current lingua franca for papers on functional programming.

Also some technologies are longer lasting than others. POSIX for example is still with us. The architecture of CPUs has evolved, but the basics of how a CPU processes instructions and accesses memory are the same. Frameworks and libraries come and go, but the fundamentals of concurrency, parallelism, asynchrony remain the same. Etc.

<comment><USER6> I've never owned a single physical programming book and I've been doing this around 10 years. The internet is more than sufficient.

<comment><USER7> Often times the best resources for learning something in programming is a book. I don't buy or believe in physical books, but the digital editions are very much worth reading.

It's not about the physicality of a book, it's that guides are typically of lower quality and less in-depth than a book is.

Rarely, you get a "guide" so good it's a book (for JavaScript: Mozilla Developer Network). For many languages and tools, something like this does not exist.

What C++ guide online is going to teach me as well as The C++ Programming Language, 4th Edition? What Rust guide online is going to teach me as well as The Rust Programming Language?

<comment><USER8> I agree with your view that book is the best resource for learning.

I have read so many tutorials that were just bad, that reinvented the wheel, mixed patterns in MVC, had business rules in javascript without server side validation and so on. Books usually will touch on why something is done a certain way and you can trust an author that is well regarded in the field. I guess it may take a bit more effort.

</comment></comment></comment></comment><comment><USER9> Please don't stop learning frameworks. Frameworks are there so you don't have to repeat the work of others.

Frameworks are like languages: some come and go, others remain for a long time (Rails, Django come to mind). We've replaced domain languages with generic languages that work on multiple platforms (hello, JS!). It's no longer just the language that matters, but the framework as well.

You don't have to memorize a framework any more than you have to memorize the STDLIB of a language, but never stop learning about new frameworks.

<comment><USER10> > Frameworks are there so you don't have to repeat the work of others

You know what else is there so we don't have to repeat the work? Libraries. And they don't take the control of how my code is called from me.

Frameworks are there because except for Lisps language provide little mechanisms to reduce boiler plate so people want to avoid writing boiler-plate to pipe libraries together. However that doesn't have to be the case, take a look at Hunchentoot.

<comment><USER11> > You know what else is there so we don't have to repeat the work? Libraries. > And they don't take the control of how my code is called from me.

Of course they do. Libraries want you to give data in one way, and they return data in another strictly formatted way.

Put a bunch of libraries together, that all know how to talk to each other via convention, and you have a framework.

<comment><USER12> >Put a bunch of libraries together, that all know how to talk to each other via convention, and you have a framework.

And if that language of communication is the programming language... you have a programming language! (Eg using stdlib types/objects/whatever)

<comment><USER11> Sure, but if I pass you a struct, having standard naming conventions for those struct elements is really nice. Having a standard way to do callbacks on observables is really nice. If a bunch of components are configured at run time using JSON or XML, having those components all use a similarly formatted markup language is nice.

Looking at web server frameworks, a lot of them boil down to "put things in these directories, use these naming conventions, and if you do the convenience functions we've thrown in will work nicely".

End result, instead of writing my own auth code for every endpoint, I throw some middleware in there and the auth happens for me. It all works because everyone agreed on how a bunch of library components are going to communicate with each other.

Are there some frameworks that are way too opinionated and heavy weight? Sure. When someone tries to make a meta-framework that can be configured to solve all problems (see: The Java ecosystem), horrible nightmares end up being written.

But the rise of small lightweight frameworks that are just an agreed upon glue for how components should work together? Eh, no big complaint.

</comment></comment></comment></comment></comment><comment><USER13> The core idea of the article is valid, but the wording is off. It's not about frameworks.

There are two types of knowledge you can get in IT. Fundamental knowledge that transfers across domains and trivia.

Problems with trivia: \- Just like the article pointed out, it often gets outdated. \- If the system you work with is well-designed, you don't _need_ to know much trivia about it. \- Fundamental knowledge allows you to derive more knowledge. Trivia is gained through rote learning and doesn't allow you to derive anything. \- Trivia hinders interoperability and innovation.

Unfortunately, most IT people _love_ their trivia. They brag about knowing trivia. They separate in-group from the out-group by trivia and use that as hiring criteria. Finally, they proudly design systems that require you to learn new trivia.

It's a giant waste of society's resources, but it also creates job security and allows some people get much larger salaries that they would otherwise.

As far as I'm concerned, eliminating the need for knowing trivia about their systems is one of the primary responsibilities of a good software engineer, regardless of specifics of what they do.

"Stop designing frameworks" is my advice.

PS: Design patterns are also trivia. Peter Norvig gad a great set of slides on that. [http://www.norvig.com/design-patterns/](http://www.norvig.com/design- patterns/)

<comment><USER14> What are some examples of that trivia?

<comment><USER13> "To concatenate a Stream of Strings, call .collect(Collectors.joining())"

"References to missing variables will be sent to the output stream, unless you use quiet reference notation"

"You need jetty-web.xml and web.xml files in your JAR to register a servlet with the server"

Language/file syntax of any sort. Names of things (classes, methods, functions, commands, parameters, magic variables, magic files). Steps you need to take to get something running.

Isn't it ridiculous that some people are considered "experts" simply because they memorized a bunch of poorly documented names for a piece of software?

</comment></comment></comment><comment><USER15> the older i get, the less insightful these types of posts sound. It's advice that sounds good because it takes the burden of "keeping up" off, and makes those that do seem like they're chasing their own tail. On the flip side, I've worked with old timers that stopped looking at new shiny things and wrote their code the way they did 10-20 years ago. and guess what it was pure shit (2000+ line long stored procedures with business code that makes sense only to creator) and i am sure they're still coding that way.

the truth?

learning to code is like pulling on a yarn. whatever makes you continue to be curious and go deeper will ultimately make you better. sometimes that means learning new frameworks just to point out good/bad parts about them. sometimes it means learning the "bare metal" technologies that are more boring (they're not, it's all how you look at it). simply saying "don't learn frameworks" is lazy, not insightful or helpful. Frameworks an abstraction that are there for a reason. Those who truly understand those reasons will be best positioned to get most value out of using said frameworks. at the very least you'll learn about another "opinion" on how code should look/work, and be free to agree or disagree with it

<comment><USER16> I think that's great insight. People are motivated differently. One person may be energized by learning the latest framework while another is more interested in fundamental design patterns. I think there is room for these different types in the world and both can contribute effectively.

</comment></comment><comment><USER17> I think every cohort of software engineers learns this in their own way. I wrote this three years ago.

Chasing the Shiny and New in Software

[https://www.nemil.com/musings/shinyandnew.html](https://www.nemil.com/musings/shinyandnew.html)

"I worry that some programmers (and their employers) have this attitude, namely a focus on transitioning stacks to the newest. They pick companies primarily based on the framework, aiming for the latest instead of the best tool for the job. They spend their time playing with new libraries and frameworks, instead of improving their core technical skills. Let's call them stack chasers - those pushing for new technologies (or their own favorite technologies) in a startup's stack, with limited advantages for key outputs (software capabilities that users value, development team productivity)."

I find three key underlying factors:

1\. Using marketing (including Hacker News posts), to make tech choices

2\. Not having the historical context to realize how ephemeral so many current tools are

3\. Software training programs stress DSLs and frameworks because they help you get jobs the fastest (same with job posts)

For practical advice, I always loved Dan McKinley's concept of a fixed budget of innovation tokens:

Choose Boring Technology [http://mcfunley.com/choose-boring- technology](http://mcfunley.com/choose-boring-technology)

<comment><USER18> Dilemma: I want to make (use of) technology a lot more boring, but in order to do that I need some fairly sophisticated and counter-intuitive technology under-the-hood.

Sigh.

</comment></comment><comment><USER19> > Keeping up to date with Angular, React, Vue, Riot, Ember, Knockout is fun.

Since the author himself raised the issue of _JavaScript_ frameworks...

Imagine you did not learn frameworks. You completely ignored what's going on the the JavaScript world. You stuck to the basics. JavaScript the good parts, design patterns, clean architecture... Object-oriented software, for good measure.

Then suppose you get a job that requires you to write React.

I know that React itself is very simple (although I think it did take me a couple of days to learn the basics of it), but not having studied it, how would you know what your options are? How would you know which way of writing React will be less painful, or what questions you need to ask yourself regarding the architecture of your app? Without keeping track of what's going on in the community, how will you make informed decisions.

Besides, the evergreen books that the author mentions mostly come from the same school of thought — it's object-oriented programming. Will they prepare you for thinking in React? Remember, seasoned programmers, no doubt accustomed to the best practices of their times, denounced React for its lack of "separation of concerns", i.e. for how it mixed layout, logic, and perhaps even styles. It took a while to realise that thinking in terms of components may have its merits, and may even be superior that thinking in terms of technologies (markup/styles/logic). This is one of the paradigmatic shifts that was brought about by React, a humble framework.

<comment><USER20> _Then suppose you get a job that requires you to write React._

I had a job interview where the interviewer asked, "What framework would you install to accomplish _x_?"

My response was along the lines of, "I wouldn't use a framework. It's a simple problem, so you just _write_ a function to do it. You don't need to throw yet another framework on the fire."

We had a brief discussion where he couldn't wrap his brain around the concept of just programming something, and not loading a bunch of frameworks to accomplish each task.

I didn't get the job. Later, I found out more about the company and realized that was a good thing.

<comment><USER21> Had the same deal with a guy running a startup factory. I'm pretty sure he couldn't program his way out of a paper bag without frameworks, which is why the alternative wasn't even on his radar. With people like that running the show, it's really no wonder we're going downhill fast.

</comment></comment></comment><comment><USER22> From one standpoint he's right. Frameworks come and go, and what you use in 5 years, will most likely not be the same today. I think he misses something key though. Learning a framework is not just about understanding you call method X to do Y. It's about understanding why people who created it designed it that way. He touches on this briefly, and he mentions some books that everyone in SD should read, but they don't really show how in depth application of how things can be put together. Learning about a framework shows you concrete examples of how things can (and sometimes cannot) function together. IF learning a framework is just about learning the names of methods and results, you've missed the key point to learning it.

<comment><USER23> > why people who created it designed it that way

Yep, exactly. Once I understand the problem that a framework was designed to solve (which is nearly always the hardest part of the framework to uncover), the details are almost obvious.

<comment><USER24> I have been seeing a real issue with tech people, code comments, datasheets, SDKs, git readme, framework descriptions, stackexchange posts, and generally all spoken words around computer science that people seem to forget or just for some reason aren't mentioning _intent_.

Tell me how you INTENDED this code to run ('why' comments, not 'what'), tell me how you INTENDED this micro's peripheral buffer and registers to work, tell me how you INTENDED this framework to solve this problem - and I'll see if what you intended works for me or not.

The drastic alternative is not seeing a better solution because you only ever implement something the way someone else told you to - but specifically for this discussion, that's what a framework is anyhow.

<comment><USER25> I intended my code to work ;-)

</comment></comment></comment></comment><comment><USER26>
        The Pragmatic Programmer
        Clean Code
        The Clean Coder
        Domain-Driven Design
        Growing Object-Oriented Software, Guided by Tests
        Continuous Delivery

is good list of books. I'm still trying to go through the Art of Computer Programming by Knuth, and The Architecture of Open Source Applications, which is free online. [http://aosabook.org/en/index.html](http://aosabook.org/en/index.html)

Frameworks are fine, but very job specific. I'm currently learning Angular as well. Frankly, there is just too little time to learn everything... Sometimes I wish to be mind-uploaded like in the Bobiverse sci-fi series. Make many clones of me and get overclocked.

<comment><USER27> Happy to see a Bob reference on HN. Fantastic series of books.

</comment></comment><comment><USER28> It sounds good...in theory. In reality if you are not up to the latest or so, you wont get a job unless you have a contact with a lot to say in the hiring process or you are an expert in some rare domain.

The author's conclusion is a conclusion programmers get to after a couple of technology waves, when they have to face the fact that they have spent precious living hours learning something whose value has become marginal in less than a decade.

But there is no escape to this. Thinking that you will get by because you are an expert in the fundamentals is just wishful thinking.

<comment><USER29> _or you are an expert in some rare domain_

Being what the OP advocates, i.e. good at seeing patterns and applying common sane practices etc, i.e. basically the good old being wise instead of knowing a lot (useless things usually) isn't that rare of a domain. And even if it were you could still be hired by any _proper_ hiring process which looks beyond the 'how many frameworks do you know' and values your general skills, thereby recognising you could learn whatever framework you want if needed.

Not saying knowledge has no use, there are indeed expert skills which require somehwat more knowlegde than general programming, but if that 'book-knowledge' isn't combined with knowing how to properly apply it in a way your app has a sane architecture on all fronts you're still nowhere.

 _Thinking that you will get by because you are an expert in the fundamentals is just wishful thinking._

Is it really? Learning my first programming languages in depth took maybe years. But after I got the hang of it a new language, even when syntax is rather different, rather takes weeks now. Apart from me knowing fundamental stuff by now, what else would contribute to that?

<comment><USER28> I don't disagree with you about the fundamentals, but my experience does not match yours.

i.e: I'm good at the fundamentals and have more than 20 years of experience, but I was hopeless job wise until I found an employer that needed an experienced fireman to save his project on fire.

Now that I have all the modern tech buzzwords in my CV, I get job offers to work with the latest fads all the time.

Before I was looking to change jobs, I thought that I was going to get good positions because of my broad knowledge and experience. Reality proved me wrong.

</comment></comment></comment><comment><USER30> My team gave up on hip frameworks when angularJS became angular 2.0, and went back to jinja and a little JavaScript here and there.

It increased our productivity by quite a bit, and everyone got less stressed from not having to constantly stay up to date on X.

I think most of us has done a lot of X'es for fun. I did some graphql personally, but nothing that ever ended up in production.

The funny thing is, we seem to have not really missed out on anything. The article is completely on point, frameworks come and go (rapidly these days), and when we needed to build a few VUE.JS widgets, we frankly could. It took a little time to learn VUE and especially the Axios package which was also needed. Probably more time than it would have if we had kept up-to-date on JS frameworks, but we had a lot of time to spare from not having kept up-to-date on popular JS frameworks since AngularJS.

</comment><comment><USER23> Boss: "Ed, what are you doing?"

Me (proud): "I am reading a book about building modern Java apps with GWT."

Boss: "What the hell are you doing wasting time reading on company time? Bob knows GWT, ask him if you have any questions, we have a deadline to meet! I don't pay you to learn, I pay you to know! If you don't know, I'll replace you with somebody else who does, there are a million people in India who will do your job for 10 cents a day, so you'd better get in line right now and start already knowing everything, you worthless lazy programmer!"

<comment><USER31> Are you implying that developers sit around reading books at their job? Usually books are reserved for their free time.

<comment><USER25> IT requires constantly learning new things. If we are learning and reading at home, then we are really _working without pay_ , for good or bad.

It's true one can learn a lot from mostly using trial and error, but often it's best to read about the general rhyme and reason for the framework. Trial and error learning can be quite time-consuming.

For example, I've spent days trying to get Bootstrap (UI) to do otherwise simple things right, and am frustrated by the amount of fiddling needed to get things to work in multiple browser brands. I have to manually use a genetic algorithm of sorts to breed a working version. If there were a book that explained the Grand Theory behind it (assuming there is one), maybe I could have skipped all this wasteful fiddling.

UI frameworks are a huge time-sink which seems like _should_ be a solved problem: GUI's are 30+ years old. I don't get it. Our (non) standards suck rotting eggs and nobody wants to overhaul them. Is there a mathematical proof that we must live with suckage to gain some so far unstated benefit? Is this _really_ the best we can do in web UI land? I'd like to see fans of the existing standards justify we are really close to optimum. Or, are we just stuck in QWERTY Syndrome: nobody can replace the bad standard until enough replace the bad standard.

<comment><USER32> People use Bootstrap mainly for layouts.

But today, this problem is solved using CSS grid (2 dimensional) and Flexbox (one dimensional)

Once you learn these two, you don't need Bootstrap.

<comment><USER25> Not enough browsers support CSS grid well, last I checked. Hopefully over time they will, but I'm sure they'll have limits, kinks, and vender differences also.

<comment><USER32> They are supported by all modern browsers afaik.

<comment><USER25> "Support" is on a continuum (non-Boolean), and not every user has a recent version installed.

</comment></comment></comment></comment></comment></comment></comment><comment><USER33> This all sounds good in theory, but the fact is you'll have trouble landing a job offer, say if you want to be a frontend or full stack web dev and you don't yet know React.

True, the FAANGs will take you in as long as you pass the general CS algorithm tests. Most startups don't hire that way -- they want to see that you have some working knowledge of React.

And yes, like the author said, learning at the job is the best option -- you learn how to practically use the framework, and you're forced to learn quickly. That is, provided that you get a job offer at all first.

Aside from all that, I would also argue against the premise of the article at all:

> Keeping up to date with Angular, React, Vue, Riot, Ember, Knockout is fun.

I don't know about most people? But if at least a minority percentage of developers are like me -- learning these frameworks is the least fun part of the job. Building products is fun. If I had a choice (like in my hobby projects), I would build all the frontend of my projects in jQuery and HTML. It's just that the world has moved on and uses React now.

<comment><USER34> The author is a little disingenuous with the post's title. As stated further within the post, he didn't stop learning frameworks. He just stopped learning frameworks that he considers new and uses stuff like Spring. His rationale makes sense.

> The Lindy effect: The future life expectancy of technology is proportional > to its current age. Every extra period of survival implies a longer > remaining life expectancy.

I don't fully disagree with him that there's a strong chance of wasting time learning a bleeding edge framework that fades into the background after 2-4 years. Tapestry was a good example. However, where I disagree with the author is what he defines as a "new" framework. I don't feel that either React or Angular are new frameworks. Both are pretty established at this point. imo Rails and Django, as well as any framework based on express are probably pretty solid as well.

The obvious danger of waiting too long to at least experiment with new technology is the risk of being left behind and being dumbfounded when new concepts become mainstream. This leads to not getting interviews as well. Why? It's more efficient for companies to vet people on standardized industry knowledge such as a framework.

That said, Eduards Sizovs still has a point to keep in mind.

</comment></comment><comment><USER35> IMO the best way to become a better coder is to maintain an open source project.

Even if you never get a single Github star (just don't mind the stars, really), you will try to keep to current standards, and you will learn SO much about the traits of good software.

This will also enhance your self confidence, rid you of the backseat coder mentality, and gain recognition by co-workers/clients.

</comment><comment><USER36> Functional Programming provides a great solution to this problem. You learn what a Functor, Applicative Functor, and Monad are, and then the concepts remain useful for the rest of your life.

Below is an amazing blog entry on how to apply functional programming abstractions to build a UI without regard to the underlying implementation underneath (react, vue, dom, etc). [https://medium.com/fuzzy-sharp/building-a- type-safe-embedded...](https://medium.com/fuzzy-sharp/building-a-type-safe- embedded-dsl-for-form-components-with-validation-e7ffaaf537e4)

For those interested, I've begun implementing these ideas in a more developed sense in typescript and purescript in this repo: [https://github.com/dwhitney/intro-to- fp/tree/master/demo](https://github.com/dwhitney/intro-to-fp/tree/master/demo)

</comment><comment> jf- This is mostly shallow advice masquerading as deep advice by disparaging "shallow" frameworks. The main thrust of the article seems to be "learn design patterns" plus a list of books. That's a fairly thin amount of information for an entire article.

My own input to the debate is this: learn frameworks. Do not learn bleeding edge new frameworks, only those that are proven and have significant market share, or unless your job requires them, or you have a personal interest in them. Expect that these will change every few years and that you will need to pick up new ones, but hang on to the ones you already know until they're effectively deprecated. On top of this, know good practises ala clean code etc. and design patterns.

I really don't know how I could spend 80% of my time learning the fundamentals and 20% learning frameworks. Am I just supposed to keep reading the same basics again and again instead of learning technology that is actually new?

<comment><USER16> I felt the same way. Maybe I am weird, I come from a physics background so not the standard CS training?

</comment></comment><comment><USER37> I really hate this meme because it misunderstands how learning takes place.

If you are learning basketball and only did the fundamentals you would be practicing drills your whole life. Drills are important but don't teach you everything you need to know. You need to practice the fundamentals in the context of a game or you will not get good.

Learning frameworks can definitely be detrimental too but for a beginner, a framework is often a real world example of how some fundamentals work. Einstein said "Learning is an experience. Everything else is just information." Learning fundamentals is just information. Practicing them in a real life situation is learning.

So I like to learn new frameworks to figure out how principals I've never used before work. Sometimes I'll continue using the framework and sometimes I don't. I think it is definitely prudent to limit how many frameworks you learn but it is wrong to throw them out totally.

</comment><comment><USER38> Those who don't learn frameworks will be damned to write them.

<comment><USER39> I think a good rule of thumb is that if you learn and use framework you should understand it well enough to write it yourself. That doesn't mean you should actually write one.

<comment><USER40> Have been working on multiple project, always ended up with our own framework.

<comment><USER39> I think that's pretty common. Often it's a framework that's sort of a subset of a bigger framework.

</comment></comment></comment></comment><comment><USER18> I learned this in the late 90s. Up until that time, I was convinced that frameworks were where all the true value was, and that, for example, languages were completely unimportant.

Then I started to work for a company making a content management system. One that actually worked, which at that time absolutely was a USP. Anyway, we were on various Unixes, mostly SunOS/Solaris, but also AIX and others. The code base was "object-oriented C" and workable, but puh.

I got approval to try to get us on Objective-C + a Foundation (first GNUstep, later libFoundation) and it not only worked, but worked out spectacularly well for us.

Of course there were essentially no frameworks, no Enterprise Objects Framework, no WebObjects, just the Foundation (and we had to contribute to those as well). This turned out to be much less of a problem than I had feared, and in fact. In fact, I would say it worked spectacularly well.

That made me realise that frameworks were not nearly as important as I had thought, that a lot of technology problems are easier than we think and that we overcomplicate the solutions, particularly with huge libraries and frameworks.

I still think that frameworks can be extremely helpful, when applied well, but we are not very good at applying them well. I recently saw someone describe this as _abstraction_ vs. _indirection_. We often aim for (and claim!) abstraction, but in most cases we just achieve indirection.

Real abstraction is wonderful, but rare. Indirection, on the other hand, is fairly easy, usually quite detrimental and very common.

So: if there is an actual domain you can _abstract_ usefully, there is potential for a framework (though there are architectural issues). Your framework may require some indirection, but only if it allow more directness in expressing your solution.

</comment><comment><USER41> Another way of looking at this:

I used to think if I learned how to write in Perl or PHP or Ruby, I was programmer.

But it turned out that was like thinking that now that I can write in English, I'm a writer.

Then I thought if I learned the right tools and frameworks, THAT made me a programmer.

But that was like learning how to use Google Docs and calling myself a writer.

It turns out that the only thing that makes me a programmer is what makes a writer a writer: the quality of our output.

And the only way to improve the quality of our output is to learn the concepts as best as possible, and produce a lot of work.

I suspect most writers don't know how to use 90% of the features of their word processors. (Ex: GRRM still writes in a DOS app from the 80s.)

I also know a lot of programmers who have a long list of frameworks on their resumes, but I'd never make the mistake of ranking them as better programmers than the guys and gals who write exclusively in C (for example).

<comment><USER42> As a former C programmer for a decade, I can tell you that I've delivered far more business value to a company by knowing higher level abstractions than I ever did as a C programmer and my salary has gone up with the increased contributions.

</comment></comment><comment><USER43> This is basically why studying CS is a better idea than going to a bootcamp yo learn javascript. If you know the abstraction, you can learn the concrete.

<comment><USER17> I actually think both programs have benefits and downsides.

A friend (a founder of a dev tool company used by most Silicon Valley companies) and I were just laughing the other day about the issues with CS grads.

His main concern with the smartest CompSci people was their bias to write code and reinvent tools, as everyting else was boring. Graduates are over focused on algorithms, and CS programs rarely teach engineering.

Just a counterpoint to "bootcamps are bad."

<comment><USER44> There's really two ways to go, if software really is eating the world.

Either we accept that most companies are writing the same software and further agree that this is a stupid waste of resources. If that were to happen then we have too many programmers so everybody has enough.

Or, we bifurcate into tool users and tool makers. The users need to understand ergonomics and glue and appreciate complexity. But the tool writers have to _really_ know this stuff, and algorithms analysis too. This is probably okay, many industries work this way.

</comment></comment></comment><comment><USER45> This is bad advice. After you deeply learn a handful of MVC/UX frameworks, you can learn the next one in a few days. So learn and study them, you'll get faster and become more aware by doing so. It won't be a waste of time.

<comment><USER46> So you're saying learn the patterns (e.g. MVC, ORM, etc) which is essentially what the author was saying.

</comment></comment><comment><USER47> I can't fully agree with this. The goal is to get paid. Angular and React pay the bills. Where I am in agreement is not just understanding the framework but understanding how the stack of tools which make up your framework works. Joel (that dude from egghead) wrote about it and it resonated with me. So don't stop learning frameworks, but don't stop at just learning the framework. Learn it from top to bottom.

<comment><USER48> > The goal is to get paid

Not all programmers work for other people

<comment><USER42> Everybody has a boss who codes to pay bills. That boss may be the customer but you still need to be able to work efficiently.

</comment></comment></comment><comment><USER49> The issue isn't "learning frameworks", it's don't waste your time learning how to _use_ frameworks _only_. Learning how different frameworks are _implemented_ , their goals, etc, is pretty valuable.

I would say the same thing about databases. Don't just learn how to use PostgreSQL, or Kafka, or Dynamo. Try to understand how they're implemented.

I've found that sometimes, you do need help. Getting some nice user documentation will get your feet wet. But I've found that the best books tend to be more general topics, like "Designing Data Intensive Applications" for databases. (Note: I haven't found anything like that for frameworks - would be a great topic though.) These tend to cover not only "patterns" but give you a nice survey of the theory - so you can dive further into details yourself.

</comment><comment><USER50> While I was in general agreement with the article, I think the examples are extreme; the author has swung from wanting to learn every Java GUI framework to reading books about softtware design. There is a middle ground, which is what I was expecting the author to describe. Here is my (utterly incomplete and non-comprehensive) list of books to read:

\- The C Programming Language \- Computer Networking: Principles, Protocols and Practice \- The Art of Unix Programming \- An Introduction to Beginning Linux Programming \- Sams Teach Yourself SQL in 24 Hours \- The Python Data Science Handbook \- Python Programming with OpenCV \- Speaking Javascript \- Scalable and Modular Architecture for CSS

Wade through that lot and you will have learned about C, UNIX/Linux, networking, HTML CSS, Javascript, data science/machine learning, text processing, and computer vision. I reckon that covers 90% of what gets posted on here.

While some of this seems quite specific, all of these books teach either principles such as machine learning, or teach actual __standards __such as POSIX, HTML etc. None of these are going out of fashion anytime soon, unlike the latest GUI framework or virtual DOM library.

The last book in my list actually speaks to the broader issue of framework use. The core takeaway of the book can be summarised as this: HTML is a tree data structure, and clean CSS relies on namespacing CSS rules so that _they only apply to a specific branch of the tree_ , so no `.menu` classes or the like, which will probably end up applying to all sorts of branches. I think if every front-end dev understood this, libraries like React would have had far less appeal, as everyone would have been too busy writing lean, fast HTMl and CSS sites to have the time to learn how to make complicated React-powered static blogs with loading spinners. (As an aside, I think there would have been less of a backlash with motherfuckingwebsites and brutalist design, as only a little CSS can make a site much more usable, with almost no impact on load time, but I think people have been scared off it by bad experiences).

</comment><comment><USER48> A programmer who has a plan and knows what he wants to do needs not waste time selecting the "absolutely most appropriate tool for the job", but work with what is at hand like a good artist. You could do web development in C, and as long as you stay focused in your plan the end result would be good, code wise. But we don't live in this world, people optimize for jobs instead of projects and projects are not plans but random stuff being thrown at the proverbial wall to see if it sticks.

</comment><comment><USER51> More accurately, "Stop Obsessing Over Frameworks".

Learning frameworks is fine, especially if you have to/want to use one. But to think that all programming revolves around a framework? That's the real mistake.

Rails, for example, taught me a lot about how to make good web applications. I've transferred that knowledge to other disciplines and found some success simply by regurgitating some of the concepts Rails taught me into other paradigms, like Go, Elixir, and JavaScript.

</comment><comment><USER52> The core message is solid, that knowing how to build systems without frameworks is must have. However you must know popular frameworks or you won't pass interviews. I had some absurd experiences due to not having Angular experience (false), I couldn't even reach the technical interview, since HR somehow decided I'm unqualified :)

I would rephrase the message as _Stop relying on frameworks for your careers sake_.

<comment><USER53> > _Stop relying on frameworks for your careers sake._

Or _Stop relying on HR people for your careers sake_

Hint: there are technically better ways to get into company. In my last six jobs/gigs I talked to target team/management guys first. HR was only there to complete the paperwork.

</comment></comment><comment><USER54> Agree with the article, but instead of Docker vs continuous delivery, I'd say learn about managing UNIX/Linux environments and reproducing these environments in other systems. Reproducing environments can be for CI, but also for dev, production, self-hosting, etc.

It can be with Docker, but also with lxc, chroot, virtual machines, scripts, etc. Generally, a common set of UNIX tools will stay useful in all contexts.

<comment><USER55> The biggest failure I see with Docker is people not using the signal system in POSIX. Want to stop a container running a java application? You hit ctrl-c and send sigterm to the bash shell...not the java process.

Or the default settings in Docker, you have a long running job in your java appliction, and you execute docker stop, which sends the correct sigterm, but after just 10 seconds it sends the sigkill signal. _sigh_

</comment></comment><comment><USER56> You do need frameworks, but you don't need big fat frameworks that completely change the programming model and require you to learn its own incantations, rituals and ceremony. React is one such beast. React is only useful if you need to incrementally update complex screens, because simple screens can be re-rendered completely and no one will know the difference. Very few applications need to incrementally update complex screens. If your application doesn't have this need you can use simpler technologies that don't have the same "Care and feed" requirements of React, such as UIBuilder: [https://github.com/wisercoder/uibuilder](https://github.com/wisercoder/uibuilder) BTW, this lib is a mere 200 lines. Add this 500-line router: [https://github.com/edman3d/mvc-router](https://github.com/edman3d/mvc-router) Now you have a usable "framework" that is 700 lines long, super productive, and no incantations, rituals or ceremony.

</comment><comment><USER57> And, the corollary:

Any technology that forces you to constantly navigate its sharp edges and learn hyper-specific workflows to use it is worse-than-useless and should be kept far away from your tech stack.

I am _offended_ when I pick up a library and find out I'm going to spend the next day or two learning how to use it, and the next weeks working around non- obvious surprises it presents me.

<comment><USER42> You've never programmed in C....

<comment><USER57> I have. At least C provides _benefits_ to its sharpness - low-level hardware access, speed, and the lessons of 40 years of history.

I'm more thinking about various libraries I've used that aim to "simplify" things and end up making them worse than not being used at all.

</comment></comment></comment><comment><USER58> The main take-away I got from the article was:

"Invest 80% of your learning time in fundamentals. Leave 20% for frameworks, libraries and tools."

The article's title sounds like it's an all-or-nothing choice, but the actual advice is reasonable and based on experience. A better title might have been, "Learn the fundamentals, not only frameworks".

Frameworks offer benefits: save time and effort, hide complexity, and provide a consistent/canonical way of doing things (in teams, large organizations or across the ecosystem). There can be downsides: they churn, they bloat, sometimes force you to use anti-patterns like work-arounds or "bad" choices (wrong tool for the job) inherent in the framework. One of the biggest risks I see is that using a framework creates a tight dependency, often critical to everything built on top of it.

I don't agree so much with grouping frameworks along with libraries and tools. The latter are modular by nature, and ideally replaceable.

</comment><comment><USER59> It is apparent to me that learning frameworks is an excuse for JavaScript developers to never learn what the corresponding technologies are.

For example many web developers have no idea what the DOM is. They have no idea why they should learn it, what it means to their work, or why things work in a certain way. It is important to understand that the DOM is the standard and there are no choices or alternatives. There is only the one standard interface and every corresponding abstraction compiles to this standard.

Performance is one benefit to understanding what this technology is. You can literally improve execution speed of your application at least more than a thousand times faster and in some cases up to 16 billion times faster. This is not an exaggeration. I have seen these numbers myself from testing using perf tools. I have seen developers twist themselves into knots to justify why their favorite abstraction is more important than such performance gains, even when gifted the evidence thereof.

Another benefit is that you can do things, very easily, that many abstractions will not allow you to do. There is a capability called _walking the DOM_ where from any point on a DOM tree you can relatively navigate to another other point and account for all manners of variability in between.

A really big benefit is employment. Knowing how these technologies actually work has always put me at the top of employment preference. When I applied for the last job I was the number one hiring choice out of 72 interviewers (possibly hundreds of resumes). Before that job I have also been at or very near the number one consideration out of a pool of several dozen candidates for each of the past several jobs. There is something unarguable about actually knowing some minimal level of competency around the technologies that comprise your platform. On the other hand, avoiding frameworks has never prevented me from attaining employment or cost me a job opportunity.

</comment><comment><USER60> Frameworks don't solve problems, developers solve problems.

I agree that it's more important to understand the core patterns used to solve problems. I also agree that a lot of technologies come and go, so it's a poor use of time to just learn something new.

What is important, though, is to be familiar with the languages, frameworks, and patterns of the career you're targeting. When hiring, I always prefer someone who doesn't need to learn everything from scratch on day one. That doesn't mean I don't expect a learning cure; but what it does mean is that I look for some serious overlap based on the maturity of tools.

New tool / framework / language: I don't expect much experience.

Established tool / framework / language: I prefer candidates with experience.

</comment><comment><USER23> Nice thought, but I've never started learning a framework because I wanted to use it, I started learning it because everybody else in my organization was using it, and I had to learn it to keep up. Stop learning frameworks means stop using frameworks - which really just means write your own custom framework to do what the frameworks do. I mean, the author is absolutely right - you have to learn the fundamentals, but you have to learn the specifics too. And, in my experience, you have to do all of that on your own time, because there are JIRA tickets to close this "sprint".

</comment><comment><USER61> I'm going through ReactNative now and holy christ it's framework Inception.

Literally, EVERYTHING is a framework. You need a framework to build your framework. You don't just learn React, which is a framework, you need to learn all the various navigation frameworks or other sub-UI frameworks, or the networking framework etc.

Wtf is going on. I don't want to learn a framework just to render a button.

"But then how will the button know when data has been updated" or "how will component X know thing has change etc." seems to be the running theme of most frameworks.

</comment><comment><USER62> The author listed a bunch of software ENGINEERING books. I could list a couple important books more, but I think there is one fairly good summary and it's this:

The SWEBOK: The Software Engineering Body of Knowledge

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

It's both a good summary and a good reference. Includes stuff about software engineering, computer science, processes etc.

Highly recommended.

I don't think it mentions any frameworks.

</comment><comment><USER63> This is concrete advice.

Learning frameworks are like learning fully specified tools, and be done with it. You need to learn driving a car, and related technics for racing/driving, not driving an F1 car, unless that you need to race in the F1 race.

So learning driving and general driving/racing technics is a better investment. You are going to use - mostly the same technics - even if you are racing in F1 or in Nascar, or even driving on the road commuting to work.

And you know what? You would be commuting to work, or training more than you are in an actual race.

</comment><comment><USER64> That is why I invested in studying in Software Engineering. I am very glad for doing that and very lucky to receive a very good piece of advice, at the very beginning of my career, to do this of an Apache MyFaces contributor from Germany (Matthias Weßendorf, I am grateful and I will never forget his name).

We need to study more on things that don't change too much, that we will use for the long run.

I have homework with the books listed in the article, does anyone knows if there is a compiled list with these must-learn fundamental subjects?

</comment><comment><USER16> I'm not really someone who spends time studying programming. I generally learn by building things. I do research to figure out what seems like the best tool for the job. I didn't read a book on ruby on rails or react but I learned them. I'm not sure if I'm weird or what but this article doesn't resonate with me at all. I would say that if I were to read a technical book it would be on some fundamental of CS or data science. It seems extremely boring to read a book on ReactJS. :)

<comment><USER65> Completely agree. I think it would be okay to pick up a book on React or whatever, but only after I've had some real-world experience with it so I can actually appreciate the concepts.

</comment></comment><comment><USER66> This is pretty bad advice. 1/ Frameworks are valuable. 2/ By learning a framework you don't learn only a framework. You'll learn about paradigms, concepts, software design, testing, good practices, etc.¹ 3/ Learning a framework is not exclusive, right? You can read a book about CS or software engineering on the side.

¹ For instance, learning React can introduce someone to functional programming and concepts like first-class citizen, high-order function, function composition…

</comment><comment><USER67> Frameworks can save you a lot of time. Especially drop-in frameworks like Vuejs that have very little learning curve yet they can cut the development time by a huge factor (I'd say if I were to write a small app in Vuejs vs vanilla Js, I'd be saving over 80% effort and lot of headaches though ymmv).

IMO frameworks are not that bad and there is a reason why so many people use it and learn it. Not using it for the reasons listed in the article isn't very good advice.

</comment><comment><USER68> The mistake is not to learn about frameworks but to spend too much time with the details of one framework. Reading a 500 pages book about a specific framework is most likely a waste of time.

But getting an overview about the framework landscape is crucial.

Using the wrong tool can lead to a dramatically slower dev speed. Choosing React over Angular for an app with complex interactive views leads to an enormous increase in dev speed. (Angular is hell for complex views.)

</comment><comment><USER69> I'm going to blow the lid off this one and share a very "out there" opinion.

Read both. Soft skills books won't help you navigate the insane economy of web technologies and current framework books won't help you develop your fundamental, transferrable skills.

Any time someone tells you a choice is 'one or the other" they're probably lying and the correct answer is 'a little bit of both".

</comment><comment><USER70> You can't stop learning frameworks in order to be successful in your job. However, not all frameworks are equally "frameworky". It's possible to prefer ones that organize themselves around concepts, over ones that are bags of magical incantations. That way, when the framework inevitably fades to irrelevance, you're left with some concepts you can apply elsewhere.

</comment><comment><USER71> One thing I kept trying to reinforce when I was teaching Rails/Ruby, was that _everything_ in Rails is just Ruby code. Not everything in Ruby is Ruby (some of it's C), but I haven't come across anything in Rails itself that isn't Ruby.

There is no "Rails code", it's just a lot of Ruby that someone else already wrote.

</comment><comment><USER72> I don't believe that _learning_ is the same as "I am reading a book about building modern Java apps with GWT." or "It's a 500-page-long Apache Tapestry book. Tapestry was a thing."

I agree that the "fundamentals" are important, but if you don't apply knowledge to something practical it's really worth?

</comment><comment> em-bee in 2012 i had a project where i realized that frontend frameworks would be the right approach. i analyzed what was there (knockout, ember, angular and a few others), and picked angular as the most agreeable. that was before angular was popular.

then i stuck with it until angular 1 was essentially no longer kept current.

i evaluated again at that point, and this time picked aurelia. i'll stick with that until i run into a problem that aurelia can't help me with and then i'll start looking for alternatives.

same goes for backend frameworks, or platforms. i am still working with the same one that i discovered in 2004. not going to change until i run into a problem where this platform doesn't fit.

in the meantime i am learning more exotic things like common lisp and smalltalk (rather the opposite of shiny and new), to get a different perspective on programming, but not to help me solve todays problems (except for fun).

</comment><comment><USER73> Now if only he would learn that most of the books left on his bookshelf are likewise window-dressing in front of fundamentals:

* The Pragmatic Programmer * Clean Code * The Clean Coder * Domain-Driven Design * Growing Object-Oriented Software, Guided by Tests

All of these books take the simple maxim:

"Be organized, and stay organized"

and spend thousands of pages expanding on that.

</comment><comment><USER74> Each new framework is a reset or reboot. We should be _building_ on previous efforts, not throwing them away! Imagine how much more productive we could all be if React allowed you to use Angular libraries, which in turn was backward compatible with JQuery plugins.

Too much re-inventing the wheel, not enough extending the wheel.

</comment><comment><USER75> This is trite. Stop learning frameworks with your personal time, let someone pay you to learn them on the job. Then wonder why you are underpaid.

The more you know, the more valuable you are. That includes frameworks and libraries. Using your personal time to become more valuable is a great way to earn a lot more at your next job.

<comment><USER76> The most effective programmers don't learn libraries. They look them up. A good library has embarrassingly greppable documentation, and has a regular enough design that it's easy to predict when it should have a built-in facility to help with whatever you're doing at the moment.

The most effective programmers _do_ spend time learning design and architectural patterns, data structures and algorithms, stuff like that. Because you need to be familiar with those sorts of things ahead of time in order to know when to use them, and also when _not_ to use them.

<comment> em-bee right, "framework" in this context is an architectural pattern. i am happy to learn one or two to know how frameworks function, and how to apply them. which framework i end up using doesn't matter. once the pattern is understood, they are mostly interchangeable (in a conceptual way) and it's more a matter of applying any chosen framework to the problem.

</comment></comment></comment><comment><USER77> Thank god I have a specialization that allows me to not have to follow the framework crap. I could care less about staying up to date with some dude's opinionated way of doing things. It has not affected me getting a job, because when I go to get a job I work in an industry where my domain expertise is valued much higher than the fact I like framework X or happen to have used it or forced myself to read some book on it.

I feel sorry for people who all they have is that going for them, it's a rough like constantly keeping up and re-learning the same MVC or UI lipstick every year. If you call yourself a React programmer, you're the next PHP Symfony Programmer or "Rails Developer". It's a completely different kind of engineer, kind of like the difference between someone who does IT but can't code. I cringe and immediately avoid any companies who advertise for "React Engineers" and the like.

I realize that some developers couldn't care less about what they are actually working, the product behind the code but I'm not one of them.

<comment><USER78> I think that's a little pessimistic (and a shade condescending?).

You can easily call yourself a React Engineer today, for one interview, and be a frontend specialist for the next.

If your company is using a stack, why wouldn't you hire people that actually like to work with it and know its quirks?

As someone who mostly does Java infrastructure work, sure anyone can learn Java. It's the easiest. But there's plenty of room to bring value with experience and specialization if you want.

I just hope no one feels forced into it because of market forces.

</comment></comment><comment><USER79> _Don 't pick the right tool for the job, pick the right framework which secures you extra work for being a tool._ \- @iamdevloper

... via [http://github.com/globalcitizen/taoup](http://github.com/globalcitizen/taoup)

</comment><comment><USER80> If you're a front end web programmer, I would tend to agree with this advice because web frameworks are a little insane right now.

Apart from that this is another spin on "don't learn X learn one level deeper." A few years ago I read something on HN telling everyone not to learn C but x86.

</comment><comment><USER81> I agree with this as I have seen frameworks come and go, but knowing something like a programming language and the frameworks that comes with it in depth really helps in order to write really fast, efficient, debuggable and maintainable code.

</comment><comment><USER82> I think the key takeaway from this article is to keep the "framework" and "technology" terms substantially differentiable. For example, "React Engineer" as a job title is quite infuriating, if you ask me.

</comment><comment><USER83> > Looks at web developer job postings > Notices almost all postings want some > proficiency in some framework (usually React/Angular)

Will React and Vue survive? Has knowing Jquery been absorbed into knowing vanilla JS? All these questions...

</comment><comment><USER84> Best part about this was the list of foundational books. Good choices!

</comment><comment><USER85> Makes sense, however the practical application might help you gasp the theoretical concepts...

"Experience without theory is blind, but theory without experience is mere intellectual play."

</comment><comment><USER86> STOP HAVING UNNUANCED OPINIONS about programming, they don't work and waste everybody's time.

Now be mindful of the work you're doing, and be careful about the tradeoffs of your tools.

</comment><comment><USER87> If people really want to stop learning framework, just stop learning ! Because framework is the highest level of code abstraction after many man hours of copy & pasting.

</comment><comment><USER88> He kind of overstates his thesis in the title in a click-baity kind of way. The TLDR is basically "don't spend a majority of your learning time on frameworks". But he makes a separate error as well, stating _" Don't rush to learn new technology – it has a high probability of dying"_

Under that line of thinking, no one would ever bother learning new technologies until they're established, but no new technology would ever get that far because no one was learning it. In fact his advise only seems to apply to people working predominantly within the more conservative Enterprise sector. Otherwise, the fact is that if you want to innovate and be on the front lines of creating new and exciting things, you need to either be learning new technologies or creating them yourself.

</comment><comment><USER89> Yes. Stop learning frameworks and start learning to embrace concepts and different paradigms.

If all you have is a hammer, everything looks like a software project.

<comment><USER90> > start learning to embrace concepts and different paradigms.

Frameworks can do help you achieve this, especially if you learn more than one.

</comment></comment><comment><USER44> A phrase I met last year that I've stolen, especially for interview loops:

        'How' ages faster than 'why'.

</comment><comment><USER91> somehow this post reminds me of Joel's post on Fire and Motion. Joel wrote about the fact that Microsoft would come out with more and more APIs to slow down developers in the industry from developing more apps on the windows platform. He compared this to the military tactic of Fire and motion: to advance on your target by firing bullets.

</comment><comment><USER92> /r/javascript on this was good [https://www.reddit.com/r/javascript/comments/a70qwf/stop_lea...](https://www.reddit.com/r/javascript/comments/a70qwf/stop_learning_frameworks)

<comment><USER93> If a Javascript developer isn't learning frameworks, what are they actually doing?

It seems like being a Javascript developer is learning a new framework every time it's Tuesday.

You know, that and installing packages to handle IsOdd and IsEven....

</comment></comment><comment><USER94> Or, take some time to learn the internals on each one you use.

</comment><comment><USER95> I think that advise is a bit misplaced. You should really not learn, or at least learn extensively, frameworks which you aren't using.

You should definitely learn frameworks that you ARE using. Or know that you will use very soon.

</comment><comment><USER96> All his "fundamental books" are on OOP. It's sad that this stuff is now considered "fundamental"

What is OOP but a framework for structuring your programs?

I guess if a framework is pervasive, and nobody thinks of it as a framework. Then you should probably learn it.

</comment><comment><USER97> The frame is used when needed, thrown away when not needed,

This is cost-effective.

</comment><comment><USER98> just another clickbaity blog post with no substance for the sake of self marketing.. I really don't understand why HN of all communities still falls for such baits</comment>


Chinese security guards use smart glasses to find people with coronavirus - <AUTHOR> https://thenextweb.com/neural/2020/03/26/ai-powered-smart-glasses-are-finding-people-with-coronavirus-in-china/ <comment><USER2> [Original article here is better]([https://www.scmp.com/tech/gear/article/3077122/hangzhou- park...](https://www.scmp.com/tech/gear/article/3077122/hangzhou-park- security-uses-ai-powered-smart-glasses-detect-people-fever))</comment>


The ghosts of technology in today's language (2018) - <AUTHOR> https://medium.com/@mwichary/the-ghost-tech-in-todays-language-c3becc9ae30b <comment><USER2> One not included in the article: "balls-out", meaning "extreme" or "as fast as possible". It's thought to originate (although I haven't seen any authoritative sources for this) with centrifugal governors, which used spinning balls to regulate the speed of mechanical devices:

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

<comment><USER3> By the way, forcibly moderating the speed by grasping the governor was referred to in Victorian times (not making this up) as "cupping the governor's balls" which was one of those "plausible deniability" phrases (it was literally true so if someone objected _they_ were the ones with the dirty mind).

<comment><USER4> But those people _knew_ that they were being risque, right?

<comment><USER3> I'm sure, yes.

</comment></comment></comment></comment><comment><USER5> How uncanny. I was thinking about this in one of my lectures today after seeing that my lecturer spelt "online" as "on line" in one of his presentation slides. It turns out that the origin of the term "on line" dates back all the way to the telegraph industry!

</comment><comment><USER6> If y'all don't follow Marcin Wichary on Twitter you're missing out on a lot of great content. He's consistently highlighting interesting intersections of history, technology, and how humans live within it all.

Twitter can often times be an unpleasant place and he's always a bright spot in the noise: [https://twitter.com/mwichary](https://twitter.com/mwichary)

<comment><USER6> Here is one of my favorite threads by Marcin: [https://twitter.com/mwichary/status/996056615928266752](https://twitter.com/mwichary/status/996056615928266752)

</comment></comment><comment><USER7> "Album" meaning "blank tablet" in Latin is interesting because it seems to have the word "white" in it, same as in albumen (egg whites) and Albion (home of the White Cliffs).

<comment><USER8> Albion comes from early Celtic rather than Latin. Originally naming all of Britain it changed at some point to refer to just Scotland, and gave the modern Scots Gaelic of Alba for Scotland.

<comment><USER9> Does Albion really mean Scotland in English? It means England in French.

<comment><USER10> There's no real common modern usage of "Albion" except in the name of football teams (West Bromwich Albion, Albion Rovers, Stirling Albion) - so it doesn't really mean one more than the other in _English_. Some people might say it comes from an old celtic word and therefore refers to Scotland, others might say it's from Latin and refers to England or the whole island of Britain. I've no idea which is "right" but the word just doesn't come up in everyday English.

</comment></comment></comment></comment><comment><USER11> > _what would be the oldest extant word based on technology no longer in use_

Hard to beat "calculate", which is about finding numerical answers by moving pebbles around a counting board.

<comment><USER12> Many of these technologies are really old, burning the midnight oil refers to oil lamps that date back at lest, 15,000 years ago. Various sailing references date back a minimum of 7,500 years old but could easily be much older technology.

Computing via moving pebbles could easily be a surprisingly recent idea ~500 BCE, but again it's very difficult to date this stuff.

<comment><USER11> > _Computing via moving pebbles could easily be a surprisingly recent idea > ~500 BCE_

By the 5th century BCE, Herodotus was writing about how Egyptians and Hellenes used their counting boards in different ways; by that point the technology was apparently widespread and taken for granted.

It's hard to judge when a counting board with an explicit place-value system (where the tokens could represent different quantities depending on position) first arose, but I'd guess no later than like 2000 BCE, and possibly much earlier.

If you allow "pebbles" to also include little clay counters, and counting with them to include piling them up and changing units by trading one type of counter for another, then we have physical examples from 7500 BCE.

We have much older evidence still of counting via tally marks, because as archaeological evidence those are relatively easy to interpret. If people longer ago were counting with pebbles there's almost no way we'd know it.

* * *

> _burning the midnight oil refers to oil lamps that date back at lest, 15,000 > years ago_

I take this phrase to mean doing some kind of scholarly work (reading/writing) late into the night. Apparently comes from Quarles (1635), _Emblemes_ : "Wee spend our mid-day sweat, or mid-night oyle; Wee tyre the night in thought; the day in toyle." So while burning stuff to make light is an old technology, this is not too old a metaphor.

Can you think of sailing metaphors which etymologically arose thousands of years ago, in forms still used? Obviously literal words like "ship", "mast", "row", "sheet", "wind", "knot", etc. are very old.

Also, sailing is a technology still in use. :-)

<comment><USER12> > If you allow "pebbles" to also include little clay counters, and counting > with them to include piling them up and changing units by trading one type > of counter for another, then we have physical examples from 7500 BCE.

What's your source on that? I would be really interested in checking it out.

<comment><USER11> Check out Denise Schmandt-Besserat's work, [http://sites.utexas.edu/dsb/tokens/](http://sites.utexas.edu/dsb/tokens/)

</comment></comment></comment></comment></comment><comment><USER13> Electric cars still have a gas pedal :-)

<comment><USER14> No they don't. You just use the wrong word. Try accelerator.

<comment><USER15> But the steering wheel is an accelerator too…

<comment><USER14> So is gravity when your going down hill, somethings can have the same name, so what?

<comment><USER15> Gravity isn't a control in your car.

</comment></comment></comment></comment></comment><comment><USER16> One of my favorites is from VLSI. Finishing a chip is still called "Tape out" even though we quit using magtape for sending the design files to fab years ago.

<comment><USER2> Didn't that refer to the adhesive tape used for hand-drawing optical masks?

<comment><USER16> Perhaps, but I don't remember it in that context. Maybe someone older than me might remember.

I do remember it from back when we used to mail reel-to-reel magtapes around.

</comment></comment></comment><comment><USER17> Cassette. That was a household word, right? Both for video and music cassettes. I haven't heard that word in many years, now.

<comment><USER18> bicycles have a cassette of gears

<comment><USER17> I didn't know that was called a cassette. I always assumed cassettes were a type of cartridge with reeled tape.

<comment><USER19> The etymology of English "cassette" appears to come from the French word for "little box", which makes sense for tape cassettes but not for bicycle gearing. Considering that bicycle cassettes were invented in the 70s whereas tape cassettes are from the 60s, I'd be curious to know the reason for the name.

[https://www.etymonline.com/word/cassette](https://www.etymonline.com/word/cassette)

<comment><USER8> Little box to hold a removable piece or mechanism, so seems a bit of a stretch unless cassette gears pop out for replacement? There were far earlier uses. The box that held the glass plates in early plate cameras was called a cassette.

</comment></comment></comment></comment></comment><comment><USER20> Round our way if something is rubbish, it's often referred to as "bobbins":

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

</comment><comment><USER21> Checks and balances refers to James Watt era machinery. IIRC, couldn't google.

Kubernetes/Cyber/Gubernotorial/Governor means rudder.

</comment><comment><USER22> They should have also mentioned the word "modem", which is actually an abbreviation but not many people know that.

<comment><USER11> Nobody uses the word "modem" anymore; it isn't a metaphor that worked its way into general speech.

It's just a dead word for a dead technology.

<comment><USER23> The heck? Modulator/demodulator is still used. In fact, I generally have great success in using it to illustrate the demarcation between LAN and WAN for non techie users.

Your LAN ends at your router. Your WAN begins at your modem. Your modem is the thing the ISP gives that gives you access to the Internet.

While it doesn't do the heavy lifting of converting digital traffic to/from analog signals anymore, it makes a very good nominative identifier for the particular purpose of identifying the piece of hardware that still fulfills the role of enabling connectivity with the world at large.

<comment><USER11> Yes, but people used to know that "modem" = "those funny noises on your phone line".

Now laypeople don't have a "modem", they just have "that internet box the ISP technician plugged in when I signed up".

The word modem went out of popular currency too fast for it to ever spawn the kinds of more general metaphors we are talking about in this discussion.

<comment><USER24> We still have cable-modems in some parts of the world.

</comment></comment></comment></comment></comment><comment><USER25> A couple of years ago, I gave a TEDx talk on "how our body understands the digital world", which also picks up the topic of language/tech metaphors:

[https://youtube.com/watch?v=oXWyfFyWACI](https://youtube.com/watch?v=oXWyfFyWACI)

</comment><comment><USER26> thanks for technology language easy to help [https://www.alltopinterviewquestions.com](https://www.alltopinterviewquestions.com)</comment>


Tim Wu: A TikTok Ban Is Overdue - <AUTHOR> https://www.nytimes.com/2020/08/18/opinion/tiktok-wechat-ban-trump.html <comment><USER2> So because China bans American apps, we should stoop to their level? I thought the point was that America is better than China because America is free, is anyone really going to believe that if America starts censoring its Internet (even more than it already does)?</comment>


The agile samurai - <AUTHOR> http://www.pragprog.com/titles/jtrap/the-agile-samurai

<comment><AUTHOR> I guess things are going to have to get worse before they get better.

</comment><comment><USER2> Does going agile mean following processes/practices mentioned in a book/blog?

I thought it was about not following any set practices and about following the simple guidelines mentioned in the agile manifesto (<http://agilemanifesto.org/>). No matter what process you follow to achieve it.

<comment><USER3> Agile doesn't mean blindly feeling around until you figure it out for yourself. It means using the best practices you find or invent to achieve the manifesto. If this book has some good insights, it's a worthwhile read.

Does it, though? I dunno. I didn't read it. When I see a book with words like 'ninja' and 'samurai' and it doesn't involve martial arts, I generally just ignore it because it seems childish.

<comment><USER2> Agree! As per my experience it is good to understand the best practices but it's foolish to assume that they'll work for you just because they worked for someone else... As long as the team is willing to modify and evolve the process for good (as they gain experience)... it works well...</comment></comment></comment>


RIAA spends 58mi on lawyer fees, gets about 2% back. - <AUTHOR> http://www.pastemagazine.com/articles/2010/07/riaa-spends-58m-on-lawyer-fees-gets-about-2-percen.html

<comment><USER3> "It recovered $1,362,572, for a 2.3 percent return rate, according to Beta News. We're not math majors, but that's bad, right?"

Well, I was a math major, and the answer is "Not necessarily." (Not that you need any math to understand why)

Is money recouped through legal avenues the only way the RIAA stands to benefit by launching a massive legal assault? No, of course not. It also gets to scare the bejeesus out of people who might have thought about downloading or uploading pirated music, and choose not to, because of the thought of a lawsuit threatening their financial future. So, in theory, there's the possibility that the RIAA has also gained by reducing the loss of earnings due to piracy.

I'm not saying this _has_ been a success for the RIAA, or even that it has been effective at all. Obviously piracy and legitimate sales are not zero-sum. But it's not quite as simple as this article (and the various others making the same point) makes out.

</comment><comment><USER4> This is irrelevant. First, the record companies don't have to justify what they do to anyone, as long as they aren't violating anyone else's rights. The RIAA initiated these lawsuits because the rights of the companies they represent are being violated by people who are stealing their music.

This Beta News recovery statistic is short-sighted. If the recording industry doesn't defend itself against piracy through these lawsuits, they will lose a lot more than $57 million. I view their actions as $57 million well-spent on self-defense. I also think it's a shame that people have such low respect for intellectual property that this is necessary.

If you don't believe in intellectual property, ask yourself: how would your startup would fare without IP? If you create something new, no one else has a right to it. They should only have it on terms that you choose, because without you, it wouldn't exist.

Certainly, there is a great deal of benefit to collaborating with others. But without rights as defined above, collaboration on mutually beneficial terms is impossible (e.g., both immoral because someone gets ripped off - <USER2> impractical because innovation ceases).

</comment><comment><USER5> Minor title nit: I was momentarily confused as to how the RIAA spent 58 _miles_ on lawyer fees. :) The usual way to write this would be "$58m" and not "58mi".

<comment><USER6> You can spend frequent flyer miles on more than just free flights these days.

</comment></comment><comment><USER7> Scaring thousand if not millions of potential music thieves straight: priceless

<comment><USER8> It will just serve to make the p2p world devise ways to hide their actions from the plaintiffs (like peer blocking), or make them use the myriad alternatives that don't record ip addresses or removes the p2p aspect entirely (which is much lower "heat") such as youtube audio rippers, megaupload/rapidshare, usenet, or straight up http download services like beemp3.

If the mainstream "pirates" can't figure the above out (and, really if they can't, then how did they figure out bittorrent?), legit services like last.fm, pandora, spotify, or streaming stations from shoutcast and the like provide free music tailored to genres and user preferences.

Finally, perhaps people will just buy the damn things from itunes or amazon. I guess they'd "win" then.</comment></comment>


How to Buy Drugs - <AUTHOR> https://www.lrb.co.uk/v41/n21/misha-glenny/how-to-buy-drugs <comment><USER2> Prescription drugs? Because I need some and it takes months and time off work and repeated Dr and specialist and procedure trips just to get an antibiotic called Rifaximin that can cure certain types of IBS. Last time it took six months, a thousand dollars, four or five days off work, and a colonoscopy before I could get a prescription. But they don't prescribe enough to actually cure it. Is there a black market for this? I'm asking for a friend.

<comment><USER3> Alibaba...

A few years back, I was prescribed a anti cancer, prescription drug that costs $4k per box. (5mg per day, 28day day supply).

I went on Ali, and ordered 5lbs of the drug for $100 usd including shipping.

<comment><USER4> Honest question, how do you know you're actually getting the correct drug and that it isn't contaminated or cut with something else?

<comment><USER5> You can test it yourself, but many times the same manufacturer in the USA is the same abroad.

I would say India for Drugs is not a bad idea - if you're worried it's "from" China.

<comment><USER6> I have not the remotest idea how I would test a cancer drug for myself to see if it was pure. I suppose I could hire a chemical laboratory, if I could figure out what kind of one would do that kind of work...

<comment><USER7> > I have not the remotest idea how I would test a cancer drug for myself

As someone with only a high school level of chemistry training I would check the melting temperature.

Although seriously get it professionally tested. The delta between USA prices and India/China prices is so high a lab test will barely change the margins.

</comment></comment></comment></comment></comment></comment><comment><USER8> This writer is brilliant. Never have done (and really never was that interested in) drugs, but the air of mystery and cat & mouse that he wrote in was just fantastic.

A very serious subject with very real consequences but what a ride that story was. Well written and well played.

<comment><USER9> Yeah, agreed---the end is particularly well done. The reveal about the police strategy with the DDOS!

<comment><USER10> Spoiler alert!

</comment></comment></comment><comment><USER11> > full-service dealers advertise their wares is through Snapchat or WhatsApp:

Oh dear, just because a snap disappears doesn't mean a record doesn't exist.

While Snapchat (I don't know about WhatsApp) says that they "typically" don't retain your expired story data, you only need one of your friends/followers to be using a third-party app that does capture and retain data for your record to persist.

I'm guessing that the moment an account is of interest to law enforcement, a social network organization is obligated to start persisting and reporting account data.

<comment><USER12> Most snapchat/whatsapp dealers are 100% fake. Engage with them and see how fast it turns into the same scam language someone on Craigslist trying to buy your item from another state is.

<comment><USER13> > Most snapchat/whatsapp dealers are 100% fake

You'd be surprised how dumb some dealers can be. (This also depends on the location). I may or may not know of people who used to operate on Facebook Messenger, Instagram, but Snapchat is surprisingly popular.

Most dealers who have half a brain use Wickr (it being closed source; I still don't approve, but it's better than Snapchat).

</comment></comment></comment><comment><USER14> " As a consequence, the drugs available to the informed buyer are of a higher quality than ever before. They are also safer."

If only we could say the same about the people exploited along the chain of production of these drugs

<comment><USER15> I'd buy fair trade drugs if I could

<comment><USER14> Hell I would too! So long as I could go to sleep at night knowing my money didnt help finance violence and corruption.

Thats why I really hope we legalize recreational drugs. Tackling supply and the demand just doesnt work, people want them.

</comment></comment></comment><comment><USER16> Fascinating. What sort of legal liability would someone take on by publishing 'secure darkweb marketplace software' as open source?

Asking for a friend interested in civil liberties and civil disobedience.

<comment><USER17> Well you might want to familiarize yourself with this story first: [https://en.wikipedia.org/wiki/Ross_Ulbricht](https://en.wikipedia.org/wiki/Ross_Ulbricht)

<comment><USER18> Writing open source software designed for the .onion network is different than running a drug platform over the darknet.

Writing software doesn't get you in trouble. Choosing to stock ads for products like guns/drugs might.

<comment><USER19> > Writing software doesn't get you in trouble

[https://www.wired.com/story/wannacry-malwaretech- arrest/](https://www.wired.com/story/wannacry-malwaretech-arrest/)

</comment></comment></comment></comment><comment><USER20> The idea the police prevented access to a well protected site to move traffic to a site they had control of is fairly clever.

<comment><USER21> A few years ago the police did something similar by running a honeypot site called Hansa [0]; they gained control of the site, but rather than shutting it down immediately, they quietly ran the site for a few months, making changes to it in the background. Then, they siezed the big darknet market at the time, Alphabay [1], which drove everyone on the site, dealers and users alike, onto Hansa.

Before the influx of users, they had modified the site to record a lot of data that a normal darknet market wouldn't. For example, instead of discarding photo metadata, it would extract it for law-enforcement use. They changed built-in PGP encryption software on the site, so that when people used it, it would first record the information entered before creating the message and sending it to the other user, which allowed them to get information like mailing addresses. Instead of hashing and salting passwords, they recorded them in plaintext, which allowed them to capture accounts on other markets when users had recycled usernames and passwords.

The operation, called Operation Bayonet [2], was complex enough that several different law enforcement agencies from Europe and the US were involved. The Dutch police, Interpol, the FBI and DEA etc. It was quite an interesting case.

[0] [https://en.wikipedia.org/wiki/Hansa_(market)](https://en.wikipedia.org/wiki/Hansa_\(market\))

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

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

<comment><USER22> You can protect against these attacks and maintain your privacy by doing the following:

1\. After you take a picture, open that image on your computer and take a screenshot of that image and crop as needed. This removes all camera metadata.

2\. Use a program for PGP encryption. Type out your message on Notepad or whatever, encrypt it _locally_ , then paste the encrypted message into the website's message box.

3\. Use a randomly generated username and password. Generate a different username _and_ password for each site.

Don't break the law, kids!

<comment><USER21> Yeah, this vector was avoidable by individuals who had good operational security, but the operation still got addresses for 10K+ individuals: they recorded around 27K transactions, so that means over a third of users relied on the built-in PGP tool!

</comment></comment></comment></comment><comment><USER23> I completely agree that legalization and education is the only rational solution. In many countries people are already too confident in the legal system to make life choices for them, and they tell with a straight face that anything "is good for health because else why would it not be made illegal already?".

<comment><USER23> Okay I am going to contradict myself a little bit now... actually, today the state is also healing people when they are sick, using tax money for that. So, just letting people make themselves sick and then suck up tax money to get back on their feet is very counterproductive... which is why "prevention" is so important, and why so many substances are regulated or forbidden.

<comment><USER22> The state is not a business and does not have to make decisions based on the cost/benefit analysis from a monetary or tax collecting perspective. In the US for example, LSD and psilocybin are illegal even though there is zero chance for chemical addiction or dependence. In Canada and the US you can get a prescription for Klonopin, which sounds roughly as addictive as cocaine. People have gone to rehab for Klonopin addiction--for a prescription anti- anxiolytic!

<comment><USER23> But it has to be somewhere in the lawmaking process. Imagine there is a perfect but very costly cure for Alzheimer, imagine the price to cure one person is equivalent to the GDP of the whole country.

On the other hand, you cannot let people harm themselves and then do everything to save them. What is the cost to repair somebody who went out of his way to cut his hand in a very dirty way, such that it would take hundred of hours of surgery?

<comment><USER22> In democratic countries the politicians care about how the expenditure looks to the public. People think that 5 billion dollars in welfare is a lot of money, so it's hard to spend more welfare. People do not think that 5 trillion dollars on "defense" is a lot of money, so it's easy to spend more money on defense even though it has at best dubious return on investment.

</comment></comment></comment></comment></comment><comment><USER24> [http://archive.is/wwOyk](http://archive.is/wwOyk)

<comment><USER25> or [https://outline.com/C4gf4U](https://outline.com/C4gf4U)

<comment><USER26> Nah, at least I can view archive.is links without JS enabled.

<comment><USER25> aye, tried opening the outline url via w3m (text browser) and all i got was a blank page :(

</comment></comment></comment></comment><comment><USER27> Agora was another market who made sailed off in to the sea keeping true to their words. Everyone got their money from escrow, no one was scammed and was always under DDoS.

One of the true market legends of the time.

</comment><comment><USER28> Haha here in CDMX I live a few blocks from Tepito and you can't walk in on a busy day without someone trying to sell you weed or coke.

I personally stick to my drug of choice: pambazos. I don't even want to quit.

<comment><USER29> When I went on vacation to Europe, that was one of the most noticeable differences from the United States. In Prague in particular, people were aggressively selling drugs.

And I look like a complete Square.

</comment></comment><comment><USER30> The last paragraph claims police DDoS attacked a site. Is this legal?

<comment><USER31> Who will sue the police? Who will investigate the police?

LEA and intelligence agencies operate in legally grey areas because the know they can get away with it and the politicians are happy that results can be shown.

Parallel construction is often used, involving private sector 3rd parties.

<comment><USER32> CO cops just won on appeal for demolishing a home to catch a thief who made off with a shirt and belt from Wal-Mart. It's doubtful they could be held accountable for pigging up a computer network.

</comment></comment></comment><comment><USER33> tl;dr:

A dark web drug marketplace was well-secured, but a competitor was not. Frustrated law enforcement is rumored to have DOSed the well-protected site to drive buyers to the less-well-protected site, which was promptly seized by LEOs.

</comment><comment> ur-whale [http://archive.is/wwOyk](http://archive.is/wwOyk)

</comment><comment><USER34> Medicines: Schedule a free consult with the doctor in your healthcare area. Obtain a stamped and signed recipe based in his/her professional opinion. Ask for the product in the next pharmacy and exchange your recipe for the product. Pay a small amount or nothing at all. Say thanks and have a good day. Finish.

Illegal drugs: Are you fishing? Good try.

</comment><comment><USER35> Just decriminalize it already. Tax it, inspect for quality and offer tax-free mandated psychiatric and clinical checkups every six to eighteen months (paid for by taxes and imports) and start busting dealers and suppliers for tax evasion; not possession or intent to distribute. 50% to 90% user rate drop, far less overdoses and overall huge tax increases.

<comment><USER36> While I can see the argument for decriminalisation of most drugs, I can't believe something like fentanyl should ever be. Just like you can't legally buy cyanide without a permit - it's just too dangerous to allow free market distribution.

<comment><USER37> The rise of fentanyl trafficking is largely a result of prohibition. Imagine you are a drug smuggler. Now would you rather have truck load worth $100k or a briefcase worth $100k?

<comment><USER38> Doesn't the same logic apply if you're a legitimate provider?

<comment><USER39> You'd rather have a truck load of legal goods than a briefcase full of illegal goods. Illegality is a big cost.

<comment><USER40> Not if the equivalent value was the same. The briefcase is easier and less conspicuous to transport.

<comment><USER41> Transporting a truck of legal goods across a whole continent and multiple countries is much cheaper and easier than a briefcase of illegal drugs.

The total cost of risk-free (i.e. fully insured) delivery of a truckful of goods is trivial compared to even quite cheap products; while that briefcase would pretty much have to double in value after that long trip to make the transport profitable.

<comment><USER40> That briefcase will increase in value ten fold over the journey. So my point stands, easier to transport the briefcase and the returns are better. The risk is higher but that is why the returns are higher.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER42> Is there a non paywalled version of this article anywhere?

<comment><USER43> i have a question: would it be illegal for me or anyone else to access it, copy and paste it somewhere else? this sucks

<comment><USER44> Its copyright infringement but as usual, nothing will happen if you did copy and paste it.

</comment></comment></comment><comment><USER45> I'd rather not know that an article exist than being told "you have 1 free article this month".</comment>


Google Issues Warning for 2B Chrome Users - <AUTHOR> https://www.forbes.com/sites/gordonkelly/2020/04/18/google-chrome-81-critical-security-exploit-upgrade-warning-update-chrome-browser <comment><USER2> Wow, this writeup tries really hard to pad out what is a relatively routine security advisory.

The title should be something like "use after free vulnerability in Google Chrome, with possible remote code execution"

In any event, any insight into whether this is exploitable without allowing the permission? Seems like the auditing effort should be focused heavily on code that runs without any particular permission.</comment>


Welcome to Bypass Paywalls Clean for Chrome/Firefox - <AUTHOR> https://bitbucket.org/magnolia1234/bypass-paywalls-chrome-clean/issues/36/welcome-to-bypass-paywalls-clean <comment><AUTHOR> Refactored Bypass Paywalls Clean extension (no google analytics)/add-on with lots of new sites (200+ sites + all (custom domains of) Medium), bug-fixes, option to add custom sites and update-notification. [https://bitbucket.org/magnolia1234/bypass-paywalls-chrome- cl...](https://bitbucket.org/magnolia1234/bypass-paywalls-chrome-clean)

[https://bitbucket.org/magnolia1234/bypass-paywalls- firefox-c...](https://bitbucket.org/magnolia1234/bypass-paywalls-firefox- clean)</comment>


RIP Red Burns, "mother of the hacker artist community in NYC" - <AUTHOR> http://inagist.com/all/371035108872290304/%20

<comment><AUTHOR> NYTimes obit: [http://www.nytimes.com/2013/08/27/nyregion/red-burns- godmoth...](http://www.nytimes.com/2013/08/27/nyregion/red-burns-godmother-of- silicon-alley-dies-at-88.html?_r=0)

</comment><comment><USER2> Wow, I was a grad student ITP under Red. She was a pure genius and visionary. Sad day.

</comment><comment><AUTHOR> New York's Secret Tech Weapon: ITP. [http://www.forbes.com/sites/stevenrosenbaum/2013/08/26/1095/](http://www.forbes.com/sites/stevenrosenbaum/2013/08/26/1095/)</comment>


Lyft pulls electric bike fleet from San Francisco streets after some catch fire - <AUTHOR> https://www.theverge.com/2019/7/31/20749396/lyft-electric-bikes-pulled-san-francisco-battery-fires-motivate-bay-wheels <comment><AUTHOR> This after they were already pulled once this year for faulty brakes that sent multiple people to the hospital: [https://www.theverge.com/2019/4/15/18311243/lyft-electric- ci...](https://www.theverge.com/2019/4/15/18311243/lyft-electric-citi-bike- bikeshare-nyc-sf-dc-braking-malfunction)</comment>