Ask HN: Books that'll make you grok software engineering? | Hacker News Reader

Ask HN: Books that'll make you grok software engineering?

14 pointsyura8 comments

There are some technology books that are almost unanimously agreed to be of the very highest quality: common traits are the use of concise and clear language, good code style, correct and relevant information and overall superb treatment of the topic at hand. For CS, there's "The Art of Computer Science" series, "Structure and Interpretation of Computer Programs", CLRS's "Introduction to Algorithms". For programming languages: "The C Programming Language", "The Go Programming Language" are a few examples. For system administration, a book comes to mind (for *nix): "Unix and Linux System Administration Handbook".

What the equivalent of those books, but for software engineering? I've researched this before, and the names that come up are "Clean Code", "Code Complete" and "The Pragmatic Programmer". But "Clean Code" in not without criticism: it has been criticized for advocating stutter-y functions (4 lines or less), overly descriptive names (isLeastRelevantMultipleOfNextLargerPrimeFactor) as opposed to comments and it's debatable whether the refactored code samples (illustrations of the so-called clean code) are actually good and legible code. "Code Complete" and "The Pragmatic Programmer" appear to be universally praised, except for the fact that these two books have been so influential that most of their content is common knowledge nowadays, and reading those books may not be as enlightening today as when they were first released.

I'm wondering if there are books of the same caliber for software engineering, which are not so entry-level and are more up-to-date with current trends (the rise of scripting languages, cloud computing, and OOP not being "the one true paradigm" as it once was).

> But "Clean Code" in not without criticism

It's true - the worst and most dangerous programmer I've worked with quoted that book like the bible. Their code was completely unreadable, unmaintainable and lead to some horrible performance because of the knots they tied themselves in.

I'll list some books I know of that tackle larger projects and can be good for working through different patterns and why to do things in a certain way. Since they tackle larger scope, there's less pro/conning of alternatives, but they're good springboarding for your own research:

Cosmic Python: https://www.cosmicpython.com/

Implementing DDD, CQRS, and Event Sourcing: https://leanpub.com/implementing-ddd-cqrs-and-event-sourcing

SaaS Handbook: https://builderbook.org/book

I would say that, unless you're just starting your career, books like Clean Code, The Pragmatic Programmer and the like are not real "revelations".

Software engineering has more to do with people than with software. Have you checked Peopleware? Also, perhaps The Phoenix Project could help as well.

>I would say that, unless you're just starting your career, books like Clean Code, The Pragmatic Programmer and the like are not real "revelations".

I agree, that's why I'm asking this question. I think these particular books are mostly helpful to the junior engineer.

But it's hard to believe that from here on out the only thing that's left is to learn how to deal with people. Surely there's more to the software side of software engineering than what TPP and Code Complete have covered. Surely very experienced engineers have written books on software engineering that cover something more than entry-level knowledge. (Clearly, since I haven't found such books yet, there's a chance they haven't been written. But I find that hard to believe, considering the broad audience of software engineers that are interested in that knowledge.)

One thing that I really think a lot of SE teams should do is to include a full time BA with them, to fend off irrelevant requirements, mine real requirements and write requirement docs on Confluence. I'm currently in that position, but sadly I'm in a business team, not in SE team, which makes my work only half relevant.

The perfect BA should be someone directly from a SE team but with more people skills and are willing to take the burden of that position. He should be expected to increase the efficiency of the WHOLE team by say 20%.

My two last position were in team where all members have a technical background. Like, we just assume you can code or query whatever. Devs are not magical creature. Coding happen to be their main focus.

- A bunch of devs. - A BA exactly like you described. Usually 50% on one team. - QA lead, able to pull from the set of devs at will. Must have deep automation and QA skills. - A scrum person ( 20% on the team ) - a tech lead.

I've found "Understanding Software" by Max Kanat-Alexander very helpful in improving the quality of my code.

I heard Domain Driven Design is good.

Reply on news.ycombinator.com