Hacker News Reader

Comment by bad_user | Hacker News Reader

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.

View on HN

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.

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.

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

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.

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

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

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

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.

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.

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.

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

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

You can't see the forest for the trees.

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.

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.

    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.

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

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

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

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

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

> these are soft-skill books.

Clean Code is not a soft-skill book.

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.

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

Reply on news.ycombinator.com