Stop Learning Frameworks | Hacker News Reader

Stop Learning Frameworks

sizovs.net

515 pointsingve294 comments

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

I assume you use React but which webframe do you use? Rails or Asp.net core?

Depends on the team and the project. I've used Express, Loopback, Golang+Chi, Rails, and Flask for API development; Rails, ASP.NET MVC, and Elixir for web. Not all of those were frameworks that I chose to learn, some were already chosen or already in use when I started.

If you've a choice, what framework would you chose for backend api of react app.

Not the op. But I tend to favor minimizing friction... to me, if I can use the same language on the front end and the backend, that will be my preference. These days I mostly use JS because in general the friction is so low, and I can modularize my code with very little effort.

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

Depends on what I'm building. Rails is fast to iterate on, a cobbled-together Go service is great for specific niches, JavaScript and TypeScript plus an ORM are good all-rounders that can help your team work across different parts of the stack and have interesting possibilities when it comes to sharing logic, and I'd probably build a toy project in Rust because Diesel is pretty interesting.

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

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.

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

I have a similar mindset: I had no idea how to approach Responsive Web Design. I learned Bootstrap. I now understand Responsive Web Design along with Grid Systems.

You mean you know how to code responsive design or you know how to use bootstrap to achieve it?

Both. I prefer using Bootstrap because I know the shortcuts, but if I need to duck down into some @media(max-width) I can. I also have a much better idea of the concept (it’s not just a lack of a fixed width; it’s changing font and element sizes and floats as you go up and down).

There are good and bad frameworks.

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.

Yep

Now you have 2 problems

Is the cliche

But now it’s Dart instead of GWT

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.

> but it's all common sense stuff that you learn in the first couple of months on the job.

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.

Yes, a lot of comments suggest most people appear to work with these paragons of programming. I have seen methods with a cyclomatic complexity of over 200 (the tool actually gave up at that point so I don't know the real number), so maybe I have an affinity to companies where "don't use global variables" is still strange advice.

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

“But it’s not global! I put it in this object [that is global]”

Heard at least twice, and at different jobs.

Similarly to static variables (globals), threading and race conditions, and/or using really ineffective structures as a caching layer.

Out of curiosity, how do you know a person has been shadowbanned?

In your account page (https://news.ycombinator.com/user?id=bobwaycott) you have the "showdead" option, which lets you see dead comments. You can then look a user's comment history by clicking on their nickname and on "comments". Shadowbanned users are those for whom all comments are automatically dead.

Ah, gotcha. Thanks!

I had to create a new account since I lost password of my last one, but I had noticed in my last account that my submissions (not comments, but link submissions or Ask HN submission) would be shadowbanned right from the start? And this was on a fresh account that I had. Does HN shadowban by IP?

Email the mods via the Contact link in the footer and they can definitively determine why the account is shadow banned.

ye, I got into a rather angry argument with another user about Hellenistic Antiquity. I was told back then. What impact does being shadowbanned have? Have I been shouting into the void these past few months?

Yes, a lot of people won't see your comments since the default is NOT to show the dead ones, and I have to "vouch" for your comments to be able to reply.

Oh I see. That would explain a lot. I thought I was just getting out of touch and nobody liked me anymore! :D

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

Replying to "icantdrive55"

I agree - I find the whole mess, with flag / dead / shadowbanned, to be extremely cowardly. It reminds me of Hettinga [1], who would quietly delete comments he disagreed with from his blog. In both cases it was an issue of "private property so they can do what they want" but I still dislike it.

[1] https://en.wikipedia.org/wiki/Robert_Hettinga

If someone is that far into writing bad code, computer science textbooks are the last thing they need. Algorithmic awareness does not result in readable code, and cyclomatic complexity has only a very loose relationship with computational complexity. In fact, code written by computer science professors is routinely some of the messiest, gnarliest stuff I encounter.

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.

My suggestions would be Programming Pearls 2nd Ed and The Practice of Programming. Classics, for sure, but so much good in them it'll make any programmer better for having read them.

I agree that learning algorithms is underrated & helps you out with many aspects in life. I can't tell you how often I'm sorting something with someone (like Christmas ornaments) and want to explain the fastest route to sorting them.

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 can't tell you how often I'm sorting something with someone (like Christmas ornaments) and want to explain the fastest route to sorting them.

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

Given that the constant factors are so much larger and the number of items relatively small, we're unlikely to start really hitting the theoretical asymptotic complexities of sorting algorithms in these scenarios. But for what it's worth, like much real-world data, this sounds like a good fit for Timsort: https://en.wikipedia.org/wiki/Timsort It probably benefits from having a lot more sequential access than random access; the physical world is even more punishing than a processor cache.

Timsort is interesting. I had first read about it some years ago, maybe in the Python Cookbook, 2nd Edition (recommended, BTW, as is Edition 3). It's a hybrid and adaptive sort.

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

My favorite solution like this I saw was from grading an Algorithms class.

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.

> I can't tell you how often I'm sorting something with someone (like Christmas ornaments)

Do Christmas ornaments have a natural ordering?

I just put them in a heap.

I assume they’re sorted in ascending order of merriment.

I can't recall the last time I've ever had to sort christmas ornaments.

And if you did, I imagine you could perform the task just fine without advanced knowledge of sorting algorithms.

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

It makes me wonder what the most practical sorting algorithm for sorting things by hand is- like, if someone tossed a 1000-page hand-written (but numbered) manuscript in the air, which algorithm would be fastest to sort them by hand? Card sorters used radix sort, but if you don't have a card sorting machine, maybe mergesort.

According to Algorithms To Live By (great book), libraries use a sort of merge sort.

Someone on HN mentioned the 'magic of ____ arrays' or something like that where search, insertion, merge, etc. were all constant time operations...

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

The correct sort for that situation is a most-significant-digit-first variant of a radix sort. Arrange the documents into 10 piles based on hundreds digit. Pile up all of them except the zeroes, then sort the zeroes recursively. Then pull the next segment out of the pile, and sort it recursively. And so on.

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.

Some of my friends are postal workers and have described their mail sorting to be roughly this. It's not a general algorithm though, there is knowledge of their route weaved in. So the most significant bit would be the street name, but they'd remember houses 42+ are earlier in the route and direct them to a different bucket. For this reason the person delivering the mail also sorts it.

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?

Can’t tell if OP was being sarcastic or not

Ah, you and your fancy non-OCD brain.

I can't remember the last time I've sorted anything with an algorithm written by me. Last time I did that in AI class in College. :\

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

I have a set of ornaments of the twelve days of Christmas. Last year I sorted them into order so that I could easily make sure that they were in ascending order on the tree. I'm going to do the same thing in two days time when we put our tree up again. I'll admit that I did it by eye, putting 1 and 12 at opposite ends of a table and then slotting the others into what seemed like the right places.

> If you want to learn something with long lasting value, learn actual computer science.

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.

> ... and 3% computer science

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

Bizarre isn't it.

Easiest way to not get an offer is to be an ass in the soft skills interview.

That's the remaining 10%...

This unfortunately runs counter to common sense and the OP.

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?

> Real world software engineering [is] 70% managing emergent complexity, 20% people

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.

I've noticed a lot of these "soft skills" seem obvious when stated out loud, but are rarely followed.

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

Because most soft skills are to be applied in a very tailored way. Not prescriptive, per se.

Quite. Skilled engineers are making the right decisions 90%, 95% of the time when it comes to these soft-skills of design and architecture. But it's that 5% error-rate that builds the technical debt that the project inevitably has to pay down. And if too many contributors have too-high an error rate, the wheels come off, design intent is abandoned, and mystical approaches become de rigeur (a la "This code doesn't do anything but it crashes if we remove it!")

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.

Could you clarify what you mean by "soft-skill"?

I assume they mean things like

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

etc.

Yeah, all those things that are unimportant until you have to work with other human beings.

CPR is important, but I don't want to read about that when I'm taking a course on hiking and camping.

More high-level skills like "people" skills, "conversation" skills, and things like that. They're not specific to individuals or individual languages but are general and more about concepts rather than specific examples.

People skills and conversation skills are also what I typically associate with "soft skills", but it doesn't seem to make sense when applied to (maybe half of) those books?

Yes, the poster is using "soft skills" in an idiosyncratic way.

That's a great way of saying "incorrect"

It's also a good example of "soft skills".

Agreed to a point. But please give AOCP a try. It is much more readable than it is given credit for. So is SICP.

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

I don't need a book to learn Vue but learning React, Rails, Aspdotnet core needs a book.

Timeline of features is usually lost when reading about them online.

A book can present better timeline and overview of what all things are available in a framework.

Online guides were entirely sufficient when I learned Rails and ASP.NET a while ago. There's no special property of dead trees and ink that makes it more suited to delivering information.

May be ebook or .pdf or some online. The point of a book is to dig deeper.

I read pdf sir, never waste a tree when u can!

There are experienced people writing books and people are even paying for them. Surely, they do have smth worth mentioning in a book.

Have you considered that during those 10 years you might not have learned much?

Not as much as the extremists but a decent amount. 10 years ago being first introduction to programming some time in K-12 to now: besides what you learn in a CS degree, I've made significant contributions to Unity3D games including networking code on the one that's an MMO, wrote emulators, wrote a graphical IDE with a custom assembler for NES games, made some HTML5 games like a recreation of the Windows 95 maze with Three.js, and now in the professional world I've learned a lot about a certain CMS and taken a decent amount of online courses provided at work for professional advancement, such as one on R. I'm personally satisfied with the breadth and depth of what I've learned, especially given I have other hobbies.

Don't need to own them, check your local library. Books delve deeper than blog posts or even series of them, without distraction.

+1 for without distraction

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?

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.

And this how we get “expert beginners”.

Are you accusing me of being an "expert beginner" based on preferring web resources over books?

The parent post quoted these books:

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

These aren't "programming books" for the most part.

There is a huge difference between "programming" and "software engineering".

The parent post also said those books were boring fluff that didn't tell you anything you didn't learn on your own in the first month of a job. They recommend actual computer science and math instead, which is more the route I took. I'd say ProjectEuler is a good resource for practicing algorithmic optimization and math. I enjoyed the classes in college that went deeper into CS concepts like Language Processing and I did take extra math classes, but I'm not sure what resources I'd recommend on them. Probably some good textbooks available digitally. I'm not opposed to the concept of the format of a book, I'm just saying it's easily possible to be successful in "programming" and "software engineering" without having these books on your shelf, which the parent post said nobody reads anyway.

Yes plenty of people do read them.

And very few people do algorithms and math on their jobs.

You also don't learn most of what the books teach you on your job.

Knowing how to do algorithms and math is rarely what's needed to deliver software.

Yes. scarface74 is trying to tell you that the parent post is wrong. For the record, I'm on scarface74's side of this one. Those books are not soft skills. They're about the difference between being able to code up an algorithm and actual software engineering.

We've got too many people employed as software engineers when all they know is computer science. They cause a lot of problems without even knowing it. When others complain, they respond that their algorithms are perfect - as if that were where the problem was.

> This means algorithms...

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

CLRS is solid.

What does that acronym stand for?

Author names: https://en.wikipedia.org/wiki/Introduction_to_Algorithms

Our use of acronyms is getting out of hand.

"Introduction to Algorithms" is a pretty common title, so CLRS seems to be how it's universally known. It's (for me) the top hit on Google and Duck Duck Go. I haven't read it yet myself, though I've probably seen it recommended 100+ times.

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

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.

Most developers work on projects where the success or failure of the project is determined by stakeholder interactions.

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.

Well, the way i am interviewed it always made me feel as if success of the company depends on my blackboard data structure and algorithm skill.

Yeah, you said yourself that’s “in a interview only”. I agree that many modern interview techniques are stupid. Perhaps they think the leaders know how-to communicate well already or perhaps because soft-skills are notoriously hard to assess. But in my experience, algorithms and data structures questions can only reveal very little about the potential of the candidate. A lot of truly important skills can only assess through interaction with experienced human evaluators.

Isn't that really selection bias though? Projects with bad management simply don't make it. Those with bad algorithms make it but with lots of accrued technical debt.

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.

It depends... a given software application that only has a handful of users on a dedicated server can totally survive a less than perfect implementation. Right now I'm working on an application that will be deployed to multiple independent customer sites. That same application will never likely see more than 1k users on it at the same time (mostly about 20).

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

Again, bad software project management can over engineer as much as they can under engineer.

Soft skills aren't as obvious as they seem. That's why we need books about them.

This is moving the goalposts.

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

I don't know how old you are, but I'm in my 50s, so I have some perspective on this. I don't worry about becoming irrelevant at all. But that is as much due to the "soft skills" that you dismiss as the hard skills, maybe even more so. I've been through enough projects, from tremendous successes to total disasters, that I can see large-scale patterns. And those are never about tiny algorithmic details. They're only sometimes about technology.

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

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

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

That's the sound of me having learned it the hard way...

Thank you for passing on the knowledge - I hope you are well off now!

Hi, this is a great post, thank you for sharing your experience. I have a colleague who is in that company focused rut. He is a great bug fixer and such, but his confidence has been shattered because he knows he is in this rut and isn't sure how to get out of it.

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.

Best thing? Find another job. Pick up some currently-useful skills (AWS certification is great if you aren't currently working with it).

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

Thanks for taking the time to reply, I really appreciate it! I was thinking about graphql and strengthening my mathematics. This AWS stuff looks interesting though, Ill check it out.

Is there a tech community you can be involved in? There can be many good reasons to stay with one company, especially if you have medical, or other reasons to stay with that company. Or, need to build up confidence before interviewing somewhere.

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

Those are all really good points, it definitely gives me a few ideas. That is certainly a pro tip you got there, to ask about helping to organize, pretty brilliant way to break the ice and such. I really appreciate your response!

> Part of it is that they no longer have practical interview skills, or even understand the current trends in recruiting and hiring.

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

when i left my previous job, one of my complaints was that, even though they claimed i'd be working with FOSS technologies, the libraries were buried under three layers of abstractions, so that i never actually got to touch them and everything i learned was very specific to the companies custom code.

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.

One would assume someone in their forties would have a lot of experienced with the fundamentals the article talks about, and more time to discover modern tools, libraries and frameworks.

Aside, I'm 43.

I've read The Pragmatic Programmer on a 10 hour flight and I fell asleep 2 or 3 times, because it was freaking boring.

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.

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

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

An excellent point. To corroborate it, there was a challenge issued by Jon Bentley to Don Knuth to write a program that Doug McIlroy would then critique. The program was to parse a file and count the frequencies of words, outputting a list of the frequencies sorted highest to lowest.

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

I've seen a lot of failed IT projects.

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

I would like to agree with you from the opposite direction. I work with a team of basically all PhDs and write several patents a year. We have a regular scientific paper reading list. (I work developing commercial software, not in research.) My job requires some understanding of at least some graduate-level math.

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

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.

Can't upvote you enough for singing the praises of the liberal arts. I majored in them myself and had to listen to a lot of people, both my peers and certain mentors, question its usefulness and basically wonder why I was wasting my time. In spite of that I have worked at two massive tech companies that the vast majority of people have heard of (one in the enterprise space, one in the consumer space) since graduating and am doing well.

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 agree with everything you said.

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

Most cities you can get a job working on interesting problems as an barely competent undergrad student through the trifecta of showing up, accepting minimum wage and not requiring your office to let you have a nerf gun. Or you know, the same work conditions as 90% of people in other disciplines. It's just we're kind of spoiled as younger devs when it comes to work conditions and often pick an incremental improvement in salary or free breakfast over challenging work.

I would upvote you a billion times if I could. I’ve seen so many good ideas getting lost because of overcomplicated approaches to the implementation, and so many “boringly simple” systems delivering immense value. I am guilty of this too. It’s a variation on Knuth’s famous “premature optimization” mantra, and is still as actual as ever.

Back when I was doing lead coder and tech PM work, I'd see these ads online for contracts for projects that were just getting started.

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.

Amen a billion times to that. And then some.

My enthusiasm isn't curbed either, but this stuff doesn't stick for everyone, especially if the wrong behavior is rewarded. The use of the term "soft skills" to cover a swathe of topics that technical people want to avoid is a real problem that I observe regularly. In a way usage has become derisory rather than a just bucket for a range of topics like leadership, strategy, empathy, marketing etc.

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.

You're using the word "soft-skill" incorrectly.

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.

I saw many software engineers, with several different study paths, not knowing anything about how a computer and a network work. Apparently this doesn't affect significantly their efficiency at work but it's kind of stunning.

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.

That's like saying being a mathematician involves how well you can sell yourself, therefore marketing and networking are core skills in math. Marketing and networking are core skills of life no matter where you are.

It's not like that at all.

Software ENGINEERING skills are important for software engineers. Period.

Nope, as the OP said, you are misunderstanding that these books aren't teaching "soft skills", they aren't about networking or marketing, they are about how you collaborate in a work environment and build maintainable software that meets deadlines. If you haven't give some of them a shot, I find them a refreshing break from algorithms heavy books and get a lot of value from them.

Code are messages written for other coders so writing clean and readable code is a soft skill. Things like picking good variable names, designing the structure so things are easy to find, designing the architecture so the intent of the writer is apparent etc are all definitely soft skills.

Continuous delivery isn't a "soft skill". Neither is Domain-driven design.

You can't see the forest for the trees.

> POSIX for example is still with us

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.

The Pragmatic Programmer may be soft skills and generally "common sense" advice, but it's very practical and the analogies stick with you. The two that have stuck with me are the boy scout principle (leaving an area of code cleaner than you found it) and tracer bullets (getting software in front of end users as early as possible). Both of these are simple things that everyone would agree to, but in my experience having the analogy on hand helps teams actually follow and enforce the principles more consistently.

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

I have a confession to make: I haven't read any of those books, and I'm not really planning to.

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 picked up Pragmatic Programmer just a few days ago and am loving it. While many of the lessons I have figured out already on my own, the book helps qualify and solidify them, giving you a place to reference if you want to teach someone else about them or push for something on your team.

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

> really hard to follow (Art of Computer Programming),

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

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

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

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

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.

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.

I think it's a balance that each person has to set to the "right" level for them based on the stage of their career, and the trajectory they would like it to take. What's "right" for someone who wants to become a project manager is different than what will be "right" for someone who wants to be an architect or strike out and found their own company.

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

> these are soft-skill books.

Clean Code is not a soft-skill book.

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

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.

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.

> You don't have to memorize a framework any more than you have to memorize the STDLIB

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.

> A library is something you call from your code. A framework is something that calls your code.

Libraries and frameworks do both of those things. A library is something you can call from your code, but is it not calling your code if it uses callbacks? If you're not calling built in functions of a framework then you probably have no need for it.

I think the main difference between libraries and frameworks is that libraries interact with the language, whereas frameworks generally exist in their own little world, attached to but not embedded with the language itself.

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.

You guys are overcomplicating things. Frameworks generally force you to structure your code a certain way. Both frameworks and libraries provided added functionality so you don't have to code it. A library will not force you to structure your code a certain way.

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.

Reading the entire article he states to spend 20% of time on frameworks, libraries, and tools and 80% on "fundamentals". So he isn't against learning frameworks just don't make that the focus of your learning outside of your job because you'll learn the frameworks while trying to do your job.

I don't know about this author's day-to-day, but mine is not in the fundamentals of a language, it's in a framework.

Granted, a JS dev spends her day juggling libraries, but a Ruby dev (a Rails dev?), an iOS dev, an Android dev, etc, spends her entire day writing code for a framework, not a language.

I would even argue that software is 80% libs and frameworks and 20% fundamentals, but I digress.

I build some rather complicated things using Flask. Maybe 5% of total programming time in the last 6+ years has been spent writing code for a framework.

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.

I don't disagree that you might spend 5% in flask, but you also have auth, you have a data abstraction layer, you have session management, data persistence, tooling, and sec. All those libraries together is called a framework.

I know what a framework is, having been building with a handful of them for more than a decade. That a framework is used to deliver a web-based frontend has no bearing on intentionally designing and building a framework-agnostic backend.

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.

> Frameworks are there so you don't have to repeat the work of others... ... but never stop learning about new frameworks.

I hope you see the irony of this.

You might be limiting your point to web frameworks in a single language. Rails gave rise to CakePHP after all...

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.

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

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

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

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.

> Frameworks are there because [...] people want to avoid writing boiler-plate

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.

I've taken a look and found https://edicl.github.io/hunchentoot/#easy-handlers

Yes, to be fair: hunchentoot is a webserver in CL, the "easy handler framework" is one option how to use it and I have never seen it in production - it is a convenient way to get started.

And in LISPs you'd call a framework maybe protocol or driver. Same difference. A high-level "web request dispatching and handling" library will take just as much control over your code no matter how you call it... (See weblocks, clack etc in CL - they all very much limit your code)

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/

What are some examples of that trivia?

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

Thankyou for this.

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

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

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.

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

“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

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.

4. Being the SME gives you influence over the direction of the project (whether you deserve it or not).

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.

Whether it’s rational or not to chase the newest frameworks doesn’t matter. It’s what keeps you employable.

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

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

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.

I feel you :-) I could very well be that interviewer, reaching for a framework to do something that can be easily done in vanilla JS, but feeling that the framework will make it even simpler. (E.g. after using a framework that will handle syncing my state with my UI I find that I don't want to do the same with plain JS). But I've had my share of arguments that made me appreciate the opposite viewpoint as well.

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.

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

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.

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

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.

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

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.

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

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.

Notice how the community has been trying to move away from the centralized Redux though? Trying to co-locate inside single components presentation logic and the data needed to render this component? I am not saying it's necessarily a good thing, but it is... interesting.

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.

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

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.

I intended my code to work ;-)

Frameworks are most valuable in 2 situations:

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.

I agree. Frameworks tend to codify a set of design patterns and fundamentals into a nice package, they offer you training wheels to a broader set of concepts. If the author said that frameworks are great to learn for your first 10 years, then spend time after focusing on more abstract fundamentals I would agree with him. But as it stands I think he's making a blanket statement that is misleading to newcomers.

    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

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.

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

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.

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?

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.

This hasn't really matched my experience with the industry.

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.

I agree with you on hiring people that know what they are doing instead of people that just know how to use the flavor of the month.

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.

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.

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

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

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.

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.

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.

They are supported by all modern browsers afaik.

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

This seems like a good example of what the OP is preaching:

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

I don't think I ever worked at a place where people would mind if an engineer is reading an engineering book. As someone who has managed software projects I know it has never bothered me.

I can't tell if this is serious or not. That's how sad some situations really are, I guess.

Well, I'm exaggerating (a little).

Me: Thanks boss, but you don't pay me enough to work with assholes like you. See ya. Good luck with your $0.10/day offshore devs, call me when the project fails, if I'm free I'll consider bailing you out at my emergency overtime rate.

You: meet the new boss, same as the old boss.

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.

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.

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.

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

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

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?

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

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.

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

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.

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

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

A piece of technology that requires me to learn so much about it that I understand intimately what's going on under the hood such that I could re-implement it myself?

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

It takes roughly the same amount of time.

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.

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

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.

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.

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

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.

I worked with a guy who had a master's in CS. I'm self-taught and he was definitely more knowledgeable than I am...like way more. But the guy couldn't deliver. I want to learn CS stuff, and I even pick up some here and there, but ultimately I'm just too busy solving problems and delivering features, and I get paid pretty well to do it.

That’s just the opposite of what my experience is. Too many comp sci majors are “architect astronaughts” who are more than willing to spend time doing everything else besides shipping code.

Yes I have a comp. sci. degree.

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.

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

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.

> The goal is to get paid

Not all programmers work for other people

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.

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.

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

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.

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.

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.

I agree to this .. I have around 8 years of experience now and have built teams and products .. In one application I was sent a list of 4/5 frameworks and actually have to reply with yes/no in front of each .. based on which they will 'decide' further ..

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

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.

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

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 BTW, this lib is a mere 200 lines. Add this 500-line 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.

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.

You’ve never programmed in C....

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.

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.

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.

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.

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

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.

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

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.

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.

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?

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

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.

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…

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.

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

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

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.

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.

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?

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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

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

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.

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.

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.

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.

> start learning to embrace concepts and different paradigms.

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

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

    'How' ages faster than 'why'.

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.

/r/javascript on this was good https://www.reddit.com/r/javascript/comments/a70qwf/stop_lea...

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

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

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.

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.

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

This is cost-effective.

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

Reply on news.ycombinator.com