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

I have very bad experience with the GWT mentioned in the original article. When I tried GWT when it was originally released, it only worked for demo code/pages.

Anything more complex required me to understand Java, Javascripts and the code/system/process they use to convert the Java code to the "generated JS" code. It was O(n^3) complexity for my limited brain.

Maybe it has been changed, I see there was still a release in 2017.

The Python as a language/framework is extremely good in my opinions - very easy to learn, debug, create complex system and dig very deep as needed.

Now you have 2 problems

Is the cliche

But now it’s Dart instead of GWT

The best answer is usually "whatever your company is already using", and unless there was a compelling reason I'd start with that.

JS is emphatically NOT the best language for anything... but it's good enough for almost everything.

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

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.

There is at least an order of magnitude difference between the number of products that have failed because someone didn't use the right algorithm versus didn't set expectations appropriately, or built the wrong software.

Communication matters, a lot, so books about communication and structure also matter a lot.

Reading a soft skills book is like taking mandatory anti-corruption training at work. It is boring because its obvious, but unfortunately some people still need it.

How much effort should be made towards optimization, or custom data stores? Or just use {insert favorite sql dbms}?

Due to rampant ageism, most people in this field are afraid of becoming irrelevant in their forties due to the rapid evolution of the industry, therefore staying relevant is of concern.

But if we are going to talk about what drives the success and failure of projects, the "stakeholder interactions" are only one part of the problem.

I've worked with 3 startups already and have heard stories from many others ...

For startups that die, usually the blame lies with not finding the "product/market fit" however the reality is that startups only have a small window of time in which they can present their product and win customers and if your MVP has bugs or is underfeatured, it can kill your business, irregardless of how well connected you are to your stakeholders and your clients.

Going further than startups, in software companies developers do have to talk with stakeholders in order to understand the requirements.

Asking the right questions however is a matter of technical skill and no discipline will teach you how to better dissect a problem in smaller problems than math and a scientist will always be better at asking questions than non-technical folks ;-)

The people my age that suffer career losses and anxiety usually do so because they stayed in one place too long. Getting laid off or fired after 10-15 years (or longer) in one place can be disastrous. Part of it is that they no longer have practical interview skills, or even understand the current trends in recruiting and hiring. But a lot of it is because their skill set becomes company-specific, deeply tied to the business of their long-time employer. They might be (and often are) fine programmers or analysts, but their resume doesn't reflect that.

As for startups... if you think an initial product (MVP) having bugs or lacking features is the reason startups die, you're not paying much attention. I would go far in the other direction! A company that doesn't release a buggy, incomplete product will die. That's because startups are a race against the clock. They need to show results (usually measured in sales) quickly enough to not run out of money, or at least get them to another round of investment to keep them going. The longer the time to market, the harder that is. And customer feedback is the best way to find the shortcomings in your product.

The reason anyone buys from a startup is desperation. That startup needs to be offering something that cannot be obtained from an existing, stable market player. This is especially true in B2B, where businesses are actually risking something by committing to a startup, other than their free time. A startup needs to find such a big pain point, such a big market gap, that customers will put up with a buggy, incomplete app, and pay for the privilege. That is the secret to a successful startup - certainly not polishing the turd til it glows. (Read Crossing the Chasm for great depth on this, if you don't mind a bunch of boring soft-skill reading.)

I'm in my 40s, and this is _precisely_ why I mentor peers to interview occasionally with other companies after a couple of years at their gig, even if they have no intention of leaving. It's not just keeping up with the technology, it's keeping up with the soft skills, the trends in recruiting, etc.

What if they fit the gig they're interviewing for and get an offer? I could think of worse problems someone interested in keeping up and going through this exercise could have.

And especially for hiring managers, occasional interviewing is even _more_ helpful for finding better, more efficient methods for interviewing in your own company. Or finding out your own process is better run.

You might not want to do this in a small town where you're going to exhaust your options rapidly, but in major cities, if you're methodical about the roles and industries, it's an unbelievable wealth of information (and competitive analysis, to be fair).

I am rapidly approaching my 40's, and lately I am fearful of ending up in the same position. I was wondering, if I could ask you, what can I do to make sure I don't end up like that? I'm a full stack programmer with a great job, but we are very vendor locked.

I feel like I already made one step in the right direction, where I don't focus too much on frameworks, but more on the soft skills. For instance, instead of reading a book about d3.js, I started with a book about the underlying fundamentals of data visualization (Grammar of Graphics). Instead of focusing on tsql, I focus on database architecture and indexing fundamentals. Is there anything more I can do, though? I guess I should really explore finding another job.

If you go to a dev meetup reach out the organizers about how you can help them. This often gets you introductions to people you may not usually interact with. I have personally experienced this pattern:

* Go to meetup I like. * Find I'm intimidated by the topic and personalities. The groups knows each other and there are what looks like a clique of speakers. * Meetup ends and after some very brief smalltalk I go home. Opportunity missed.

I certainly learned a few things from the talks, but I missed out on opportunities to network. Many times it turns out there are some dynamics happening, and I only learned this from hearing a bit more from the organizer side:

* Group started out as a bunch of friends with an interest. * Same people are giving talks over and over. Feedback from membership is that they want more variation, or beginner talks. * The people who started the group were intermediate before they started the group, so for various reasons don't do beginner talks, or do them well. * Organizers want other folks to step up and improve the beginner experience, but struggle to find people who actually understand it. I probably had a few stories to tell the group, but didn't.

There are many more things going on, but if you get in touch with the organizers they can likely help find something for you to contribute towards which isn't necessarily speaking.

You'll get into a circle of people you wouldn't normally be in, where you can initially lurk. You can pick something that will get you visibility with other group members (potentially hiring) or recruiters (if they allow them). Most importantly you'll develop some leadership skills which will be valuable to employers. Employers also like to have organizers on their staff because then they can host events and showcase their company (just be careful with how that comes off.)

My rule of thumb is to not stay more than five years anywhere, if you want to make sure you can move when needed.

Thank you! That is one more encouragement to get my prototype started and think about how to do my marketing.

My experience from leading both engineering and product teams is that this is mostly wrong.

If it's product/market fit you're worried about, then the problem of asking the right questions is not a hard-skills problem. It's domain expertise and communication skill. Knowing what an S-expression is or POSIX internals won't make you better at any of those things. Working on your soft skills will.

Aside, I'm 43.

None of those books are about soft-skills. They are about software ENGINEERING: about software quality, software design, software testing, deployment, software life cycle etc.

Computer SCIENCE does not teach you much about software engineering.

As an engineer you rarely need computer science, you need engineering skills.

On the other side, I started from logic gates, registries, network packets and ended up with their same skills, with some 20 extra years at my disposal (I couldn't learn React before it came into existence but I know JavaScript since day 1.)

An exam on the second year of CS required us to write a simulator for a toy CPU, with the microcode to implement some simple machine code instructions. I remember the curses interface on a VT100 and the professor testing the program.

I wonder if I could have studied my books and those other books before I was 25. Why not? But I think that it's much harder to "know" software quality, software design, software testing, deployment, software life cycle than it is to learn the fundamentals. Anything that somewhat deals with people is messier and more difficult than something that deals only with machines.

Software ENGINEERING skills are important for software engineers. Period.

Amen to that.

I bought a house, married, had kids, visited four continents and never had to worry about money just because at some point I decided "hmm, guess I'll learn really well how Linux works".

I see all new languages, frameworks, methodologies and fads woosh past on their way from explosive hype to early retirement. And I still make my money out of knowing what those few syscalls actually do.

% of projects that failed due to some "soft skill" issues such as covered in these books: 100%

% of projects that failed because of some bit of CS somebody was missing: 0%

My enthusiasm is not curbed.

I think the funniest part of this comment is the fact that it's this exact attitude that makes people crash their projects: it's not tough enough. Surely there's some magic sauce we can add on top to make it tougher, right? Maybe the project is only keeping track of the 50k books and 10k patrons at the local library, but we'll certainly need a messaging system capable of huge amounts of realtime transactions, right? And what kind of cloud infrastructure is that going to take? Probably something complicated, I'm sure.

As a newly-minted instrument pilot, I was lucky enough to sit in the jump seat of a local commuter as it made its way home to my local airport. We were shooting an IMC approach down to minimums. I kept my mouth shut and paid attention to the two pilots working.

It was like watching a clock. Everything was dull, double-checked and cross-checked. When we finally landed, I told them "That was pretty boring"

I'll never forget the pilot's reply, "That's how it's supposed to be"

The vast majority of tech work is not intellectually-challenging. Even when it fails, it usually fails for these "soft" reasons.

Plenty of folks are not happy with this state of affairs. Those are the people you need to keep away from the keyboards.

The greatest skill you need to know as any kind of professional is the skill of dialing it back to only what's required by the client -- not what might be the most fun or interesting thing you'd like to do. That can be really, really tough.

Every year since my first year, I wrote on my self-evaluation form "I really need to learn more about (GPU computing/differential geometry/hyperparameter optimization)". And every year, I got told "be nicer to people, show your work, thoroughly explain your algorithms, double-check". (Well, different things every year, but all in that list.)

The fact is, intellectually challenging work doesn't exempt people from, well, doing work. Keeping records, using processes, talking to people. There's no market for heroes who only want to pull the sword from the rock but not get any blood on their shirt.

I think the key fact of my landing-the-plane story was that there was a hell of a lot of technical knowledge used in landing the plane. They just didn't do barrel rolls on the way in.

It's not the lack of technical skill. The broader and deeper your range of skills, the generally more-useful you can be to people. It's putting the problem first instead of your own (perhaps) boredom.

Putting the problem first is what's creating all those "soft skills" books the OP mentions. When we put the problem first, suddenly we realize that we're bad at code standards, or negotiation, or interviewing, or any of a dozen or two other skills that we may never have wanted to learn.

That sucks, but that's life. That's the job for most of us. When you truly put the problem first, it dictates to you what skills or knowledge you might need. You are no longer taking an active role, choosing from a big closet of cool-looking weapons to go do battle. Instead, you're taking a reactionary role, carefully looking at both the people-systems and the technical-systems to feel your way through an engagement that will deliver the maximum value for the least amount of work, ie, putting your client's interests ahead of yours.

We don't teach people to think that way, so you'll see a lot of this soft skill stuff out in the industry that's an effort to correct the training they should have gotten in school.

But yes, absolutely, pick up more CS skills. I love that stuff. Starting in on Category Theory myself next year, probably Haskell too. I plan on having a blast.

But my fun or enthusiasm is not at all important to consider when I'm trying to help folks. Then I put their needs ahead of my own.

I'd also add that it's not just soft skills and deeper CS skills. A good liberal arts education pays off every day. I think tech folks look at these books and think there's nothing there -- then go off and make the same freaking mistakes over and over again. For those folks, trust me, there's something there. You missed it.

The disparagement aimed at the liberal arts these days (at least in American education) is really quite saddening. The prevailing notion seems to be that the purpose of an education is to produce good STEMs, not good human beings.

I'd just like to add that the world is full of fascinating (yes, even tech/math/cs heavy) problems. If you find your problem (as distinct from the tech stack or whatever) boring, you could always find a different, cutting edge, problem to work on the next few years (or decades)

You might have to get a PhD/demonstrate extreme dev skills/build cutting edge software etc to get paid to work on such problems, but them's the breaks.

You don't have to 'settle' for boring domains/problems if you don't want to, but you do have to put yourself in a position to get paid to work on them, and some "soft skills" might come in handy (though I doubt the value of some books in that list. 'clean code'? bleh) .

They were just getting started -- yet there was this ton of technical frameworks they just knew they needed.

For the ones I knew, I went ahead and applied, of course. Even got a few of them. But it always amused me that they could be so sure of all the frameworks and tools -- and not have a clue as far as to what the code was going to do.

This is just a nerd version of "we've formed a club and are looking for other cool kids to join"

Fine enough, I guess. Sure were a lot of those projects that failed, though.

These are clearly hard skills for the individuals that complain the most, or suggest they aren't important. It's much more comforting to work on technical skills which you believe can be measured objectively, but at some point you need to focus on the human side which is messier.

I attempt to be more specific with resources I point people to if they ask for help, or I need to steer someone in a particular direction. Just telling people to read a soft skills book can be chore and they won't necessarily identify the right lessons to learn. People also need to understand that you aren't trying to turn them into a manager, or one of the people they don't admire. It sometimes help to point out that the role models obvious technical skills aren't the ones that got them to that point.

Either you already knew that the things it recommended were good ideas and were doing them, or you haven't yet learned why the things it recommended were good ideas. I know "soft skills" is a euphemism for a bunch of stuff that I'd rather not unpack here, but personally I do think learning good practices around how to write maintainable, testable code are actually, y'know, important and useful, even if they get communicated with icky horrible soft words instead of burly awesome hard math symbols.

This means algorithms and math.

If you say so. But the niche for heroic god-tier 100000000000000000000x rockstar wizard ninja gurus who roll their eyes at tiny puny baby-child beginners while channeling the heartbeat of the universe to derive the Perfect Algorithm™ is... pretty small, and getting smaller ever year. Working programmers don't -- or maybe shouldn't, but oops, that's a "soft skill"! -- actually re-invent all of CS from first principles on a daily basis. And there's really no level of programming you can run to anymore to escape. It's frameworks and libraries and gluing stuff together all the way down, even into the "bare" metal (which isn't so bare anymore, and is a rich programming environment in its own right).

I mean, maybe you work someplace that routinely has to invent entire new fields of theoretical math just to describe the stuff you're building. But I've worked at a household-name place, and known plenty of other people who worked for other household-name places, and in my experience and their anecdotes that kind of stuff is vanishingly rare.

Also, I'd be willing to bet almost anything that you didn't start out as a programmer by reading Turing's "On Computable Numbers" and going from there. You probably started out with an already-built, friendly programming environment in which you could slap things together to see what happened, and only later -- possibly years later -- started to dive into all these "fundamentals" that you now insist everyone learn up-front instead.

Knuth wrote -everything- from first principles, custom file reading, parsing, the whole nine yards. At the end he had a 10 page WEB literate programming document that solved the problem. McIlroy, in his critique, wrote a six line shell script to do the same thing

tr -cs A-Za-z '\n' |

tr A-Z a-z |

sort |

uniq -c |

sort -rn |

sed ${1}q

McIlroy pointed out that by using generalized abstractions over small tasks, file reading, parsing, sorting, etc. you can write software that can be re-used and solve the business need in a reasonable timeframe. If we did everything from first principles then nothing would get done.

The merits of McIlroys argument in the context of Bentley's challenge are another matter, but I believe that his point is a good one in the general case, we are hired to build software that meets business needs, and most of the time that does -not- mean hand-crafting purpose-built data structures and algorithms.

For more on the Knuth, McIlroy story: https://franklinchen.com/blog/2011/12/08/revisiting-knuth-an...

+ a lot. Even TensorFlow is driven by a Python API.

Correct.

And if you want to advance your career, learn soft skill books. Real world software engineering, the kind that pays solid money, is 70% managing emergent complexity, 20% navigating human relationships, 7% coding, and 3% computer science.

Unless you can be a unicorn[1]. Then always be a unicorn.

[1] right now a unicorn is someone who can develop bleeding edge self-driving and other AI-ish algorithms. That's 70% computer science and 30% human stuff to be able to put yourself in a position where someone realizes you are the unicorn they want.

Gosh I think I will put this on my cube wall. I haven't really heard it put better.

Its all plumbing and the tough questions are "Does replacing these pipes with this pipe make the system less/more extensible/complex". The rest is people.

But getting a job is 90% CS based on all the LeetCode interviews companies give.

I think the OP is trying to encourage a broad and deep understanding of CS, even if they don't see the value in "soft skills". The culture of programming interviews seems to encourage a lot of folks to ignore soft skills and focus on CS only to point where it helps getting past an interview. That doesn't help anyone, but how will we ever change the industry?

The code I have had to deal with suggests that almost nobody learned "its just a view" during the decades of WinForm development.

Its all very well that you're clever and the book low-balled you but don't overestimate the average developer.

> This means algorithms and math. It also means exposure to paradigms like functional programming, or logic programming.

Ah, your religion. I forgot how often we do algos in our day job. We glue just as much if not more and while its nice to be able to the rock the maths and algos you're not offering better advice here than the OP IMO.

Also, it seems that you've been shadowbanned for about four months. Apparently you annoyed someone here.

Books like Domain Driven Design are helpful for people who don't know how to program cleanly, but the most important thing is really mentorship from a good programmer. People need code reviews that are firm and guide them in the right direction.

Heard at least twice, and at different jobs.

Well maybe i'm still pretty unlikable but not _that_ unlikeable. Thanks for the clarification.

I don't believe those books are all common sense though. They capture excellent ideas on working with your team, managing projects & writing your code in a way that is easy for people to understand months & years later. Those skills make up the majority of a lot of developers days. They're also not that common.

-Edit - I can't recall any of those books discussing patterns, which the post author mentions a few times are worth learning. I would highly agree in the value of learning patterns. One of the many patterns books for sure should be mentioned.

I'm imagining you using quicksort to sort ornaments, but then I started thinking that sorting algorithms aren't as helpful in real life as they are with computers because your brain can comprehend "the big picture" and do precision swaps or innovative transformations that a computer wouldn't know to do.

For example, say you need to slide some wooden blocks into a long slender box. The blocks have letters of the alphabet on them, and you want to load them such that z is in the very bottom and a it at the very top. You arrive at the table and you see the blocks are sorted - but in the reverse order. You could use a sorting algorithm to optimally correct this, or you could just flip the box over and load from the other side...

The assignment was "turn this min-heap implementation into a max-heap implementation". The correct solution was to flip the tests correctly.

The solution I liked the best just negated all the values as they came in, and negated them again as they came out, so as long as you were inserting numeric values, everything worked out! It was a) delightful and b) totally missing the point of the assignment, so I felt bad about marking it down, but the point was to demonstrate knowledge of heaps, and the proposed solution would have worked whether the internals were a heap or not.

From the parent's Wikipedia link:

[ Timsort has been Python's standard sorting algorithm since version 2.3. It is also used to sort arrays of non-primitive type in Java SE 7,[4] on the Android platform,[5] and in GNU Octave.[6] ]

https://en.wikipedia.org/wiki/Tim_Peters_(software_engineer)

From the above Wikipedia link:

[ Peters also wrote the Zen of Python, intended as a statement of Python's design philosophy, which was incorporated into the official Python literature as Python Enhancement Proposal 20 and in the Python interpreter as an easter egg.[8] He contributed the chapter on algorithms to the Python Cookbook[9]. From 2001 to 2014 he was active as a member of the Python Software Foundation's board of directors. Peters was an influential contributor to Python mailing lists.[10] He is also a highly-ranked contributor to Stack Overflow, mostly for answers relating to Python.[11][7] ]

Do Christmas ornaments have a natural ordering?

I find the idea that the OP’s computer science background was a “help” hilarious. I’m sure those he was helping sort Christmas decorations with are all wondering how they ever managed to do it in the past, alone, without the Christmas miracle of sorting algorithms...

Ah! Clojure's persistent vectors: https://hypirion.com/musings/understanding-persistent-vector...

I would use stacks to sort. The book was about 1000 pages? I'll do about 10 stacks. Then figuring out which stack to put a given page in is fast. (Abstract this and you wind up with a binary tree, which is what made me think of the persistent vectors above.)

This is often the most efficient way to sort physical items when you have a constrained range and working space, without custom equipment.

And yes, it really helps to know about variants like the American Flag Sort to realize that you can mix and match algorithm properties. AFS is an in-place sort, which is horribly inefficient for physical objects, but the observation that you can do a radix sort in MSD order is a refreshing additional observation vs "radix sort is always LSD first" the way card sorters work.

Computer science isn't directly applicable because we generally deal with general purpose algorithms, but I wonder how often their work is applicable to us, how often could we see huge improvements by using a specialized for the purpose sorting algorithm?

I just don't see a reason to spend excessive time optimizing, unless performance becomes an issue.

Most developers writing yet another software as a service CRUD app or a line of business app will never need to implement computers science algorithms from scratch.

Every developer will need to know how to translate business requirements to software.

The developers who don’t have the soft skills and all they can do is “Cracking the code” leetCode style programming will rapidly find their career stagnate.

Most developers will never need to know how the CPU works or about the Posix standard.

No it’s not. Knuth is a very clear writer.

The hard part is doing the trickier exercises.

Of course, it’s also a very long book. Most people only read particular sections and generally use it as a reference..

You can't see the forest for the trees.

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?

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.

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

I have read some other broad-spectrum programming books (Mythical Man-Month, Code Complete, Design Patterns, Peopleware, some lesser known ones). I've read a summary of DDD. I've read many blog posts linked to from HN relating aspects of those books. But I've never read that specific set of books.

I wonder if I'm really missing out much by not having read them, but I'm not motivated enough to find out by reading them, because there's other books I have on my reading list first (e.g. currently re-reading DDIA, after that I have Tufte lined up). Also, I never get signals from my surroundings that there are gaps in my skill set that those books would fill. Besides, having read some books is already a leg up, since many (most?) programmers don't read books.

I think the biggest thing is that they are rather easy reads, it is nothing like diving into TAoCP.

This topic is of some interest to me - I am co-authoring a book called "evergreen skills for software developers" https://evergreenskills.com/ and delivered a talk at a local developer conference on it about a year ago https://jcooney.net/post/2018/10/evergreen.html

  * Thinking like a programmer
  * Planning projects
  * Working with others
  * Time and project management
  * Setting up your environment

Common Lisp is also ideal, it effectively supports paradigms other then functional, and has been or at least was the lingua franca for artificial intelligence for decades.

Uh, huh. It does, because that's how you get past interviews.

After that, though: how useful are they really, your algorithms and math?

I'm curious what people consider the best books and/or online resources on computer algorithms are?

Clean Code is not a soft-skill book.

The technical skills are important too, but we engineers tend to get lost in the weeds.

Crucially, decreasing that error-rate has a disproportionate benefit on how sustainable the things you build are. The rock-solid tech lead isn't going to shock you with her choices. In fact, she'll probably bore you by erring on the readable and easy-to-understand side of things.

Eking out that 1% improvement really does take reading these books, thinking about them, thoughtfully trying to engage with them in your own work. So much effort for such a small improvement -- but this small improvement in one's own skills pays off exponentially in the work.

In absolutely no way is this true, and if this is your view, you need to take a hard look at your future as a software engineer, which to be honest I'm not even sure you've ever been paid to write software with other people if you think what's in Pragmatic Programmer is common knowledge.

Your comment reeks of the classic attitude that comes with getting a CS degree (or some other STEM degree) and never actually working an hour of programming professionally. The fact is, programming jobs don't involve solving hard problems, for the most part, they involve perfectly executing on an already-solved problem, and in order to do that you need to ace a bunch of "soft skills". Not just understand, but ace.

Software engineering is not computer science, for the most part. Two entirely different groups of people do those things, and use two entirely different skill sets to do them. Your advice is not for the audience or author of this article.

I am so sick of the attitude your comment represents.

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.

While that's a valid opinion, it also misses the point. A framework is the opposite of a library. A library is something you call from your code. A framework is something that calls your code. (Fill-in-the-blanks coding, if you will.). Those are different skills and different use cases. For the former you can consult the man page for a specific API, but the latter requires some domain knowledge.

That is, frameworks have an ecosystem associated with it, whereas libraries are the ecosystem.

And then the issue becomes that the ecosystem is fragmented between frameworks and the language, and things become a lot less general (suddenly you need interop code to switch between the framework’s world and a language library, akin to ffi), and you start getting locked into the framework’s world view, which tends to be quite limiting. Particularly in that when what you want, and what the framework wants, conflicts, everything goes to hell.

I think in general frameworks should be avoided when it can be composed out of libraries, in the same fashion that libraries should be avoided when it can be composed out of simple handwritten code (eg avoid 10-line libraries, perhaps accept 1k, definitely consider 5k, assuming you’re actually making use of most of it).

Its only when the benefits are significant should you reluctantly accept a framework. But most go the other way — they start with frameworks and reluctantly leave it, not realizing there are distinct and heavy constraints that make the framework so convenient in the first place.

I also have no idea why I was downvoted, what I previously said is correct. The Werkzeug python library works as a wrapper. Without you declaring a __call__ function it's not going to work. It needs to call your code to wrap it. Any framework ORM's are an example of code you're calling.

I hope you see the irony of this.

Even the web frameworks in a single language (e.g. Cake and Symphony) approach web dev in a sightly different way. Reading each is a great way to learn more about the language and how to approach the same problem using strategies.

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.

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.

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

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.

This really depends on how the framework was designed.

Some frameworks are really good at getting out of the way, and focus primarily on providing a library-like syntax (e.g. Flask for Python) with very little bundling of libraries. You can use a Flask instance inside of a desktop app as a library rather than piping to it Apache requests if you so need.

Larger, more structured frameworks exist for the developer to focus on the business logic and not worry about the context (networking, auth, sec, data store, etc.). They bring together multiple standard libraries that everyone agrees on and bundle them in a context instance the developer can confidently rely on. This, too, is a great tool.

Now, Flask is a microframework, sure. But I see this in other work I do. Perhaps it’s the way I intentionally architect/design to have as little coupling of application with framework, but it’s an exceedingly rare event where I have to bother even thinking about the framework. At most, with a web project, it’s maybe when accessing a request or a session. Otherwise, I don’t write for a framework. I write applications that get a framework-powered web frontend, but all the work is in framework-agnostic code where it belongs.

For instance, auth happens via a library that is not Flask. Same for database models and persistence (that’s SQLAlchemy for the models, and a mix of ORM and straight SQL queries for db operations—again, not Flask/framework). This is starting to feel like splitting hairs, though. One of the great benefits of a microframework like Flask is that you get the freedom to design and write application code that ignores the fact that there’s a framework handling the request lifecycle. It makes for better code.

For an example of a non-microframework example, Phoenix takes this approach as well—that Phoenix isn’t your application, it’s just a web layer, and your application should be independent.

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/

I've often thought of learning in terms of "learning trivia" vs. "understanding concepts", but had never applied the word "trivia" to learning programming facts.

I'm a hobbyist, rather than a professional, so I learn what I want, while aiming for comprehensive knowledge. Over time, I have become bored with learning frameworks and libraries, and have become much more interested in learning standards.

The phrase I have ringing in my head is "don't learn APIs", which is rather like your "don't learn trivia", but I think "trivia" captures the essence of it better. To be a little more nuanced about it, I think the thing to avoid is learning APIs for things that are not either standards, or defacto standards of long-standing.

Of course, learning APIs is necessary, but everytime I find myself wading through API documentation, I stop and ask myself whether it will still be relevant in a few years time; often the API will change, or even worse (I'm thinking of React here), the whole ecosystem will probably have disappeared in 5 years time.

This talk[1] makes a similar case.

Obviously, if someone wanted to pay me to learn and use React, that would be a different matter.

[1]https://www.youtube.com/watch?v=k7n2xnOiWI8

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

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

Chasing the Shiny and New in Software

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

Sigh.

To paraphrase Warren Buffett - “the job market can stay irrational longer than you can stay solvent.”

Some of the wizbang people are clearly benefitting from keeping everybody else off balance. You see this most strongly in places where the people wrote their own framework instead of using an existing one. Great way to keep out new ideas, because everyone you hire is an idiot for a year instead of just a couple of months.

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.

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.

Write your application logic in easily testable vanilla JavaScript and use React for rendering application state into DOM.

Note that the React docs won’t teach you this. They’ll tell you about Enzyme but they won’t tell you how to make React more of an implementation detail and less of a “framework” that your entire application is tightly coupled too.

The question is, should the logic be in the central core of the application, or should it be spread around among the components?

The concentric structure of a cleanly architected app will suggest that the app logic should be centralized, while the framework should just be an implementation detail. However, centralizing and abstracting away the logic makes for code that is 1) harder to delete; 2) harder to code-split.

There are probably many such questions and at this point we’re trying to solve a problem that may not exist in an application we know nothing about. However, with test coverage (and maybe also type annotations) you can delete or move that code around with greater confidence, which means your decision doesn’t have to be as hard or permanent.

This is the point of React. It's why it was released hand-in-hand with Flux and later Redux. If you're not doing this, you're architecting your code poorly and no framework can save you.

1. You are going to be using this framework in multiple different projects, so the time investment will yield time savings returns over the course of multiple projects as well as ease of maintenance of each project over time. This accelerates further with popular frameworks that have common bolt-on functionality.

2. You need multiple people to work on the same code base under a specific set of standards. Your options there are to either, select a framework for which those rules already exist OR to create your own framework of rules and then teach them to other people. People generally want to invest in portable knowledge and are much less likely to want to invest in your framework than they are in a framework they can use either at home or in other jobs.

Neither of these apply in situations where the code surface is very small or isolated, so be wary of increasing the size of the code base with a framework where it isn't necessary or valuable.

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.

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.

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

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.

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.

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?

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.

Honestly, most of the hires I've made that have done exceptionally well are the folks who have a very solid grasp of the fundamentals.

I prefer them over a subject matter expert in a framework all week long.

If you can't pick up a framework as part of the job, you're a really mediocre developer.

Does it require slightly more on-boarding time? Sure, but that's a pretty cheap price to pay for a solid long-term employee.

I've had the same experience on the other side of the table as an interviewee. I'll flat out tell them I've never touched their framework of choice. Or used their language of choice. It really doesn't matter as long as you can talk competently about the concepts behind them, and have a good track record.

Sadly, my experience, at least as a candidate, is the opposite of yours. But I'm in a country where most work is off-shored work, and I guess this do play its part.

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.

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

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.

Learn the box model[0], and you won't have to 'fiddle' anymore, you'll know why your elements are arranged the way they are.

Or, you could keep ploughing through permutations of bootstrap magic until you stumble at the correct implementation.

[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Box_Mod...

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.

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

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.

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

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

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?

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.

That sounds lovely, but honestly when that happens I regard it as a failure. That means its abstraction is so porous that I'm constantly having to think about what it's actually doing.

I think about the frameworks and libs where I know every iota of them... and it's not the good ones. It's the crappy ones where I'm constantly having to debug the sharp edges. "Why the heck does it do this? Ohhhhh, that's why."

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.

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

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

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.

Yes I have a comp. sci. degree.

Not all programmers work for other people

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.

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

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.

I would rephrase the message as 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.

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.

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

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.

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.

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