
Stop Learning Frameworks - ingve
https://sizovs.net/2018/12/17/stop-learning-frameworks/
======
strken
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

~~~
geezerjay
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.

~~~
jimbo1qaz
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)?

------
bad_user
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.

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

~~~
Kaveren
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?

~~~
avgDev
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.

------
ppeetteerr
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.

~~~
PuercoPop
> 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.

~~~
com2kid
> 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.

~~~
setr
>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)

~~~
com2kid
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.

------
gambler
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/)

~~~
WhompingWindows
What are some examples of that trivia?

~~~
gambler
"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?

------
SonicSoul
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

~~~
wuliwong
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.

------
nemild
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)

~~~
mpweiher
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.

------
azangru
> 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.

~~~
reaperducer
_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.

~~~
sifoobar
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.

------
kemiller2002
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.

~~~
commandlinefan
> 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.

~~~
SlowRobotAhead
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.

~~~
tabtab
I intended my code to work ;-)

------
ConfusedDog

        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.

~~~
siquick
Happy to see a Bob reference on HN. Fantastic series of books.

------
gfs78
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.

~~~
stinos
_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?

~~~
gfs78
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.

------
jaabe
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.

------
godot
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.

~~~
chaostheory
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.

------
manmal
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.

------
dwhitney
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)

------
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?

~~~
wuliwong
I felt the same way. Maybe I am weird, I come from a physics background so not
the standard CS training?

------
cyberpanther
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.

------
commandlinefan
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!"

~~~
fouc
Are you implying that developers sit around reading books at their job?
Usually books are reserved for their free time.

~~~
tabtab
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.

~~~
InGodsName
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.

~~~
tabtab
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.

~~~
InGodsName
They are supported by all modern browsers afaik.

~~~
tabtab
"Support" is on a continuum (non-Boolean), and not every user has a recent
version installed.

------
mpweiher
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.

------
billman
Those who don't learn frameworks will be damned to write them.

~~~
maxxxxx
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.

~~~
GrumpyNl
Have been working on multiple project, always ended up with our own framework.

~~~
maxxxxx
I think that's pretty common. Often it's a framework that's sort of a subset
of a bigger framework.

------
nickelcitymario
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).

~~~
scarface74
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.

------
gnulinux
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.

~~~
nemild
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.”

~~~
hinkley
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.

------
wellpast
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.

~~~
ams6110
So you're saying learn the patterns (e.g. MVC, ORM, etc) which is essentially
what the author was saying.

------
gkilmain
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.

~~~
buboard
> The goal is to get paid

Not all programmers work for other people

~~~
scarface74
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.

------
mr_tristan
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.

------
bellweather49
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).

------
buboard
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.

------
tomphoolery
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.

------
kowdermeister
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_.

~~~
imhoguy
> _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.

------
antoineMoPa
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.

~~~
olavgg
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_

------
petilon
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.

------
Pxtl
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.

~~~
scarface74
You’ve never programmed in C....

~~~
Pxtl
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.

------
lioeters
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.

------
austincheney
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.

------
gwbas1c
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.

------
commandlinefan
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".

------
debt
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.

------
kyberias
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.

------
fsniper
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.

------
edpichler
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?

------
wuliwong
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. :)

~~~
jchoca
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.

------
ggregoire
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…

------
superasn
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.

------
brillout
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.)

------
DFXLuna
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".

------
_greim_
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.

------
tibbon
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.

------
hyfgfh
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?

------
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).

------
andrewprock
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.

------
mLuby
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.

------
hashkb
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.

~~~
bunderbunder
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.

~~~
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.

------
iamleppert
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.

~~~
kjeetgill
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.

------
contingencies
_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)

------
madrox
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.

------
z3t4
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.

------
kahlonel
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.

------
Nickersf
> 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...

------
nickthemagicman
Best part about this was the list of foundational books. Good choices!

------
lucaspottersky
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."

------
valw
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.

------
revskill
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.

------
ineedasername
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.

------
m34
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.

~~~
sosborn
> start learning to embrace concepts and different paradigms.

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

------
hinkley
A phrase I met last year that I've stolen, especially for interview loops:

    
    
        'How' ages faster than 'why'.

------
megaman8
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.

------
KaoruAoiShiho
/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)

~~~
LandR
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....

------
crimsonalucard
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.

------
juddlyon
Or, take some time to learn the internals on each one you use.

------
Illniyar
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.

------
lincpa
The frame is used when needed, thrown away when not needed,

This is cost-effective.

------
the_other_guy
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

