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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Aside, I'm 43.

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

Computer SCIENCE does not teach you much about software engineering.

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

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

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

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

Software ENGINEERING skills are important for software engineers. Period.

Amen to that.

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

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

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

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

My enthusiasm is not curbed.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This means algorithms and math.

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

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

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

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

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

tr A-Z a-z |

sort |

uniq -c |

sort -rn |

sed ${1}q

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

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

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

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

Correct.

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

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

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

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

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

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

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

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

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

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

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

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

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

Heard at least twice, and at different jobs.

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

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

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

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

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

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

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

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

From the parent's Wikipedia link:

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

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

From the above Wikipedia link:

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

Do Christmas ornaments have a natural ordering?

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

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

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

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

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

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

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

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

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

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

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

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

The hard part is doing the trickier exercises.

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

You can't see the forest for the trees.

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

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

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

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

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

There is a huge difference between "programming" and "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.

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.

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.

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

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

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

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

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

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

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

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

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

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

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

Clean Code is not a soft-skill book.

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

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

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

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

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

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

I am so sick of the attitude your comment represents.