[HN Gopher] Software engineering books
___________________________________________________________________
Software engineering books
Author : colin-dumitru
Score : 246 points
Date : 2022-08-01 13:57 UTC (9 hours ago)
(HTM) web link (software-engineering-books.com)
(TXT) w3m dump (software-engineering-books.com)
| lutarezj wrote:
| Great list but missing dave farley's books on continuous delivery
| and modern software development.
|
| Is see clean code but references about hexagonal architecture
| could be way more impactful, IMHO
| fabianholzer wrote:
| Cormen et.al. is a great algorithms textbook, but I'm wondering
| in what world does it pass as a _quick_ reference?
| commandlinefan wrote:
| What I hated about that book is that it's full of exercises
| (good!) but no answers are provided (bad!). I really don't
| understand the mentality behind providing such good exercises
| with no way to check your answers - and they're not the kind of
| problems that you can verify your answer to, either.
| wheelinsupial wrote:
| They have started providing some answers: https://mitp-
| content-server.mit.edu/books/content/sectbyfn/b...
|
| There are other sources on the web with answers. For example,
| https://sites.math.rutgers.edu/~ajl213/CLRS/CLRS.html
|
| Often you can find some solutions to problem sets on course
| pages that use the book.
|
| I agree that it would be better to provide solutions, but not
| all textbooks are written to be used in self-study. I don't
| know enough about CS to offer up any concrete
| recommendations, but there are math books that come with
| worked problems (e.g., https://www.springer.com/series/3423)
| and other math books that don't have worked problems
| (https://www.springer.com/series/666).
| jjice wrote:
| Lots of stuff on here that I've been meaning to read. A few more
| I'd recommend are A Philosophy of Software Design, SQL
| Performance Explained, Mastering Regular Expressions, and Design
| Patterns (GOF). All for different reasons, but I feel like
| they're all great books to help explore various ideas, from more
| implementation level to high level overviews of software design.
|
| Clean Code is solid. A bit radical in my opinion, but there's
| some good stuff in there.
|
| Pragmatic Programmer was surprisingly good. I came into it
| thinking it would be very shallow since it tried to be wide
| reaching, but it was actually a lot of good general ideas to be
| refreshed every now and then. Works well as an audio book.
|
| Designing Data-Intensive Applications was very good. Some stuff
| is hard to apply when you work on smaller scale software, but
| there's a lot of great content in there. The visualizations are
| huge for helping understand a lot of this
| siddontang wrote:
| I also recommend A Philosophy of Software Design, the book
| taught me a lot about how to manage complexity in programming.
| mtlynch wrote:
| I see Amazon affiliate links but zero disclosure that the author
| is earning a commission from these recommendations.
|
| Affiliate links aren't a problem in themselves, but it's
| misleading and unethical to recommend a product without
| disclosing your financial incentives to the reader.
|
| If you're in the US, this is a violation of the FTC Act.[0]
| Outside the US, Amazon still requires you to disclose that
| they're sponsoring your reviews. [1]
|
| [0] https://www.ftc.gov/business-guidance/resources/ftcs-
| endorse...
|
| [1] https://affiliate-
| program.amazon.com/help/node/topic/GHQNZAU...
| user00012-ab wrote:
| Also, amazon sells lots of counterfeit books now, so the author
| of the site makes money off these books but the people that
| actually write the books probably don't:
|
| - https://news.ycombinator.com/item?id=32210256
|
| - https://news.ycombinator.com/item?id=32287936
|
| - and just reading the reviews on the books of everyone saying
| they are getting counterfeit books.
|
| The author could link to a book seller that actually sells the
| real book, but then I guess they wouldn't get their kickback.
|
| (updated post to appease people that would rather get next day
| shipping than support the authors of the books.)
| gergi wrote:
| > amazon only sells counterfeit books anymore
|
| This statement is (obviously) false as 99.9+% of all books
| sold on Amazon are authentic. Yes, Amazon should do even more
| to combat counterfeit _everything_ but inflammatory, false
| comments are not productive.
| user00012-ab wrote:
| Every Tech book I've looked at in the past few month has
| reviews of people showing their counterfeit books they have
| received. I'm not sure why you are defending Amazon's
| practice of letting this go on.
|
| The first book on that list has comments showing off the
| counterfeit book that the people have gotten!
|
| Reviews on Clean code: This books is a fake. Don't buy it.
| Look at the images I posted.
|
| Reviews On Mythical Man: ordered new book, got something
| that was used and marked up and Great book, terrible
| terrible print and binding quality (which I assume is just
| a counterfeit)
|
| Reviews On Algorithms: Beware of counterfeits; do not buy
| from Amazon!
|
| I'm not going through the entire list, but most of the tech
| books are all fakes.
| Hermitian909 wrote:
| I've bought several tech books in the past month such as
| Purely Functional Data Structures by Chris Okasak, none
| were fake. I think you'd get less push back if your
| rephrased the original post as more of a warning that
| books ordered _may_ be fake.
| thibauts wrote:
| It's time we fork a << software design >> category from the
| software engineering catchall.
|
| Yet many great suggestions on this topic but one is missing,
| which in my opinion sums up a lot of the software design classics
| : << The Design of Everyday Things >> by Don Norman.
| azhenley wrote:
| I made a list a few years ago, "Books I recommend to my software
| engineering students".
|
| https://austinhenley.com/blog/booksformystudents.html
| graynk wrote:
| Sorry, but I can't take seriously any list that starts off with
| Clean Code.
| dimgl wrote:
| Clean Code is one of the best books I've ever read. I don't
| even code in Java.
| krater23 wrote:
| Maybee thats the reason ;P
| dcu wrote:
| Clean Code is not bad in itself. The problem is that some
| people made it a bible, like the absolute truth (I guess it is
| written in that way), and that's where it fails.
| kube-system wrote:
| Why? I have heard it recommended but I haven't read much of it.
| layer8 wrote:
| The book contains some really bad advice (like using instance
| variables for temporary state instead of passing values via
| method parameters, with the rationale that parameter-less
| method calls are easier to read), and you need to already be
| quite experienced to tell the good from the bad.
| commandlinefan wrote:
| A lot of people just don't like the author, so viscerally
| react negatively to the book itself. As a book in and of
| itself, it's a bit opinionated and maybe a little outdated,
| but no more so than The Pragmatic Programmer, The Mythical
| Man-Month, Code Complete, Patterns of Enterprise
| Architecture, Refactoring and Code (I haven't read the other
| two books in OP's Software Engineering section, so can't
| speak to them). It's entertaining to read and something you
| could finish on a long plane ride - there's good advice in
| there, but you won't really _learn_ anything like you would
| if you read, say, Knuth.
| vasergen wrote:
| any recommendation for data structure / algoritms?
| commandlinefan wrote:
| Cormen et al (Introduction to Algorithms, first in OP's quick
| reference books) is a decent book on data structures and
| algorithms, although I'm always irritated that it doesn't
| include answers to the exercises. I read Sedgewick's
| "Algorithms" in college and I remember it being pretty good.
| Knuth (The Art of Computer Programming) is amazing, but be
| prepared to invest a _lot_ of time into it (them).
| kenoyer130 wrote:
| I really enjoyed Common-Sense-Guide-Structures-Algorithms
| https://www.amazon.com/Common-Sense-Guide-Structures-Algorit...
|
| Since it was more pragmatic and less math driven.
| throwaway093433 wrote:
| SICP, K&R C, and TAOCP are the holy trinity.
|
| * https://mitpress.mit.edu/sites/default/files/sicp/index.html
|
| * https://kremlin.cc/k&r.pdf
|
| * https://www-cs-faculty.stanford.edu/~knuth/taocp.html
| InitialLastName wrote:
| Instead of (or possibly in addition to) "The Toyota Way", which
| seems to be listicle-fied, read "The Machine that Changed the
| World" by James Womack, Daniel Jones and Daniel Roos. It goes
| into deep detail and analysis of the way that the Toyota
| management principles infuse across the entire business.
| a_c wrote:
| A lot of tech books focus on a steady state. Use this for that
| job, have 8 engineers per team and put two on calls every week,
| micro service and kubernetes everything, do DevOps, automate
| every bit of CI/CD etc. The thing is, it really depends on what
| stage you are in. Evolve your organisation accordingly, there is
| no one size fit all solutions. How did a river form? Don't
| blindly build a river. Otherwise you become the fish that swims
| within never realising how you come there in the first place.
|
| Notable exception is mythical man month. It describes transitions
| rather than steady states which put a lot of things into
| perspective imo.
|
| Having said that, engineering books do provide a map of reality.
| A map is a map. That goes a long way
| greatgib wrote:
| A crap list. Why is there "Essential Scrum"?
| albertop wrote:
| Honest question: what is wrong with Essential Scrum?
| swagtricker wrote:
| You can skip the tar pit of the Scrum Industrial complex
| (e.g. "here! you MUST take our certificate program!") and the
| drag setting pointless sprint boundaries and focus on just
| repeatedly, successfully, ship high quality software. The
| Accelerate book is a very good starting point -
| https://www.amazon.com/Accelerate-Software-Performing-
| Techno...
| jbigelow76 wrote:
| That site is throwing off strong "affiliate link niche site"
| vibes.
| swagtricker wrote:
| Not only why is there a garbage book like "Essential Scrum",
| why is there no mention of any unit testing or TDD books? If
| the author is seriously going to plug Martin Fowler's
| Refactoring book but make no effort to call out any books to
| help guide in writing good quality tests, I'm starting to have
| serious doubts about the nature of those "10 years of
| experience". I don't care if you "buy into" TDD or not -
| refactoring without test coverage is flat-out "Cowboy coding":
| reckless & irresponsible.
| apocolyps6 wrote:
| > refactoring without test coverage is flat-out "Cowboy
| coding": reckless & irresponsible.
|
| This is basically what Fowler says in his refactoring book.
| Actually, he says it's by definition not refactoring. I'm
| curious why you don't think it's worth reading.
| Jtsummers wrote:
| I suspect GP's complaint is not with Fowler, but with the
| list not including books that complement it. Like Beck's
| _Test-Driven Development_ or Feathers ' _Working
| Effectively with Legacy Code_ or some others.
| swagtricker wrote:
| Yes! This is exactly my point. Having included something
| as fluff as "Essential Scrum" on TOP of skipping Beck's
| "TDD by Example" or Feathers' "Working Effectively with
| Legacy Code" is very regrettable.
| mindless_solips wrote:
| Kent Beck's Test Driven Development by Example and Xtreme
| Programming Explained are delightful books that deserve a place
| on this list.
| acutis_fan wrote:
| This is perhaps off-topic. I once found the table of contents of
| what seemed to be a very good and thorough book on operating
| systems, maybe associated with MIT. Unfortunately I lost the
| link. I know this isn't much to go off, but is anyone here aware
| of something like this, or does anyone have recommendations for a
| good textbook?
|
| Thanks.
| Jtsummers wrote:
| https://pdos.csail.mit.edu/6.828/2018/xv6/book-rev11.pdf,
| possibly?
| poushkar wrote:
| Nice list! I love that the Code by Charles Petzold is on it!
|
| I created something similar out of my list of books which I used
| to navigate the transition to a Tech Lead role:
| https://techleadcompass.com/. I see that some of the books
| presented on the OP's list overlap with my list.
| yla92 wrote:
| These are helpful. Thanks for sharing them!
| yakshaving_jgt wrote:
| You're better off skipping Clean Code, for reasons detailed
| here[0].
|
| [0]: https://qntm.org/clean
| krater23 wrote:
| Thank you very much! Really! Since some years I puzzle to find
| out why the most Java programmers write code that is as shitty
| as it is. With tons of methods that are just doing more ore
| less nothing and you need to jump through 42 classes to find
| out what the code is really doing. It's a mess of code overhead
| that leads to nothing than more code overhead. Now I know, it's
| because the existance of this book and most Java programmers
| think thats the clean way to code. Unbelievebal.
| shepherdjerred wrote:
| I disagree. It has plenty of useful information, but you have
| to take it all with a grain of salt. I'd much rather work with
| someone who has read and tries to apply Clean Code than someone
| who writes a 1000 line function.
| yakshaving_jgt wrote:
| > I'd much rather work with someone who has read and tries to
| apply Clean Code than someone who writes a 1000 line
| function.
|
| Surely you recognise this is totally a false dichotomy?
| wiseowise wrote:
| I'd rather work with well structured 1000 line function than
| dozen useless functions from Clean Code.
| krater23 wrote:
| I know exactly what you mean. I'm so happy that he only
| wrote about Java. Hardly imaginable how many damage this
| book would cause if it's written about C++.
| yCombLinks wrote:
| Some of his points are good, some are bad. I think Clean Code
| should be read, but not considered the Bible. It's a good work
| with some flaws.
| sdevonoes wrote:
| As someone who has read perhaps 75% of the books listed there,
| the outcome I got is: you need to learn the rules only to be able
| to discard them. Plenty of the "principles", "patterns", "laws",
| "good practices" that abound in these books are not only
| irrelevant but dangerous in plenty of real-world scenarios. From
| introducing an hierarchy of abstractions soon in the project, to
| apply blindly Brook's law, to using Scrum all the time... The
| real deal is to be able to say: "I know that most of you guys
| will say 'Let's apply Pattern X to this problem!', and while M.
| Fowler would also agree, based on similar projects we have done
| in the past, we definitely should not use Pattern X".
|
| There is nothing more dangerous than an engineer that after
| having read all these books, is incapable of accept that
| sometimes following M. Fowler is the wrong path to solve that
| little problem we have at hand.
| clumsysmurf wrote:
| > There is nothing more dangerous than an engineer that after
| having read all these books
|
| I disagree to some extend. We learn the rules, so we know when
| to break them. This is called improvisation. I think its worse
| to break the rules without even knowing why they are there in
| the first place.
|
| I have read many of these books, and don't think its much of a
| concern because they often don't even agree with each other,
| and anyone paying the slightest attention to what they are
| reading will wrestle with the tension.
|
| Sometimes they don't strictly disagree, but are different
| enough you must synthesize an even better idea!
|
| For example, in "Philosophy of Software Design", Ousterhout
| recommends X, and then says Uncle Bob's advice is to do Y
| instead. When the experts don't agree, that should make you
| think "hmm, maybe this isn't settled."
|
| In "Clean Architecture", Uncle Bob had a separate chapter (34
| The Missing Chapter) written by Simon Brown which somewhat
| conflicts with the rest of the book.
| Hermitian909 wrote:
| > I have read many of these books, and don't think its much
| of a concern because they often don't even agree with each
| other, and anyone paying the slightest attention to what they
| are reading will wrestle with the tension.
|
| I'm not sure you're the norm, at the very least a _large_
| number of engineers I 've interacted with or mentored have
| come away from these books with either an explicit belief in
| these hard rules or an implicit one.
|
| I've found Uncle Bob's work tends to be particularly bad in
| getting engineers into this mind set (though maybe I over-
| indexed because I think so much of his advice is bad).
| serial_dev wrote:
| In my experience, Uncle Bob's followers tend to be very
| dogmatic and somehow they think that only Uncle Bob's books
| are worth reading, so when you point out that maybe there
| is another valid perspective on the issue and not only
| Uncle Bob's, they look at you like you are crazy.
|
| If you admit that you think that some of his books are
| pretty dated, or if you point out the examples he used to
| justify certain patterns are so contrived to make the other
| alternative look ridiculously stupid, or if you say that
| maybe our CRUD mobile app that only fetches data from the
| backend and displays it 1-1 doesn't need the 20 layers of
| clean architecture cargo culting, then they get angry and
| will label you as someone who "doesn't care and know about
| software architecture".
|
| I'm not even sure why Uncle Bob is special in this regard,
| I have never met a Sandi Metz/Martin Fowler/John Ousterhout
| fan who could not comprehend that there are other valid
| points of view on a situation.
| Ma8ee wrote:
| The danger is all the cargo-culting that is rampant among
| software "engineers". They know all the patterns and repeat all
| the acronyms and phrases, while they have very little idea
| about the whys.
| jjice wrote:
| Absolutely. No book should be taken as word of law for software
| development. I like to think of books as a collection of ideas
| to expand my mind and then I can use judgement to choose to
| apply them as appropriate.
| bsamuels wrote:
| Hasn't been mentioned in the thread yet, but the Phoenix Project
| is also excellent for senior engineers/managers.
|
| I read it once when I was a junior engineer and didn't get much
| out of it, then again 6 years later and it was _excellent_.
| Jtsummers wrote:
| I recommend _The Goal_ as another reading, I think it does a
| better job on covering the Theory of Constraints aspects
| compared to _TPP_ , but _TPP_ does a good job of connecting
| that idea to IT work and software development.
|
| Goldratt's sequels to _The Goal_ are worth a read, too, but
| _The Goal_ covers the more critical parts (IMO).
| 0x54MUR41 wrote:
| Thank you for sharing this.
|
| I would also to recommend these books [0]. They are books that
| may help you on programming journey. The site owner listed books
| in order from beginner to master.
|
| [0]: https://www.programmingbooks.dev
| craigching wrote:
| Shame these books didn't make the list:
|
| Structure and Interpretation of Computer Programs:
| https://mitpress.mit.edu/sites/default/files/sicp/index.html
|
| Concepts, Techniques and Models of Computer Programming
| https://www.info.ucl.ac.be/~pvr/book.html
|
| The former is probably mentioned and well known enough, but it's
| surprising to me how few people know about the latter, or at
| least I rarely see it mentioned in "best computer books"
| PTOB wrote:
| Thank you for introducing me to something new.
| ivank wrote:
| https://qntm.org/clean
| kenoyer130 wrote:
| Read Code Complete first then read Clean Code with a healthy
| dash of skepticism and do not follow it blindly. I still think
| Clean Code is a great book but does fall into "the one true
| way" and dogmatism.
|
| This is the advice I give junior developers. I explain that
| Clean Code turns everything up to 11 and can make the code less
| readable then more if followed without thought.
| Jtsummers wrote:
| _Clean Code_ includes this near the start:
|
| > Consider this book a description of the Object Mentor
| School of Clean Code. The techniques and teachings within are
| the way that we practice our art. We are willing to claim
| that if you follow these teachings, you will enjoy the
| benefits that we have enjoyed, and you will learn to write
| code that is clean and professional. But don't make the
| mistake of thinking that we are somehow "right" in any
| absolute sense. There are other schools and other masters
| that have just as much claim to professionalism as we. It
| would behoove you to learn from them as well.
|
| > Indeed, many of the recommendations in this book are
| controversial. You will probably not agree with all of them.
| You might violently disagree with some of them. That's fine.
| We can't claim final authority. On the other hand, the
| recommendations in this book are things that we have thought
| long and hard about. We have learned them through decades of
| experience and repeated trial and error. So whether you agree
| or disagree, it would be a shame if you did not see, and
| respect, our point of view.
|
| Dogmatic texts generally don't tell you to go find other
| places to learn from.
| dimgl wrote:
| But Clean Code BAD. Don't you know?
|
| Chances are these commenters haven't even opened the book.
| Apocryphon wrote:
| Perhaps, but this is far from the only time that book has
| been criticized on these forums. Here's a comment from
| the past month alone that goes into why _Clean Code_ has
| not aged well.
|
| https://news.ycombinator.com/item?id=31978877
|
| It's from a thread discussing a 2017 article critiquing
| the book. https://news.ycombinator.com/item?id=31978465
| black_puppydog wrote:
| During my undergrad I semi-randomly picked out "Beautiful Code"
| [0] from our university library. Not sure why it never features
| in such lists but I thoroughly enjoyed it. :)
|
| [0]: https://www.amazon.com/Beautiful-Code-Leading-Programmers-
| Pr...
| anupj wrote:
| +1 I really enjoyed these books. I wish there were more books
| in this series
| dongecko wrote:
| I really love this book. Beautiful data and beautiful
| visualizations are also nice reads, but beautiful code has a
| special place in my heart.
| ChrisRR wrote:
| Do we need yet another site that recommends the same 10 books? I
| think practically every search for the best dev books will list
| Code Complete and The Mythical Man Month at this point
| xiande04 wrote:
| There are a lot more than 10 books on that list.
| Apocryphon wrote:
| Because contrary to the site's name, a bunch of those books
| aren't even about software engineering.
| gashmol wrote:
| I would skip Uncle Bob and Marting Fowler's books and just read
| Code Complete. It has everything you might want to know about
| coding and then some.
| itsdrewmiller wrote:
| It doesn't really cover enterprise patterns or refactoring in
| any depth, so I'm not sure why you'd replace Fowler. I agree
| skipping uncle bob is probably healthy for everyone though.
| gashmol wrote:
| It has one chapter that sumarizes refactorings. Enterprise
| patterns or design patterns in general are about software
| design. IMHO design patters are the worst way to learn about
| design in software.
| itsdrewmiller wrote:
| The fowler book on design patterns isn't really like gang
| of four or whatever - it's more descriptive of the
| different approaches you will really find in enterprise
| software vs. a bunch of fancy OO madness that turns junior
| engineers into architecture astronauts.
| ironmagma wrote:
| Almost everything. I was scouring it a few weeks ago for some
| ideas on naming things according to analogies, for examples of
| analogies to draw from. Sadly it lacks this, and I still
| haven't found a good source for inspiration in that department.
| But yes, it's definitely like an encyclopedia of software
| construction.
| Ologn wrote:
| In terms of a dry 960 page reference book, with references to
| studies, Code Complete is good and I refer to it and tell
| others to refer to it. Uncle Bob's Clean Code covers the same
| ground, but the book has a narrative drive, gives examples, and
| is stylistically well written (although people may or may not
| agree with certain ideas).
|
| I think both books are good but I usually recommend people read
| Clean Code first. It is an easier read, and it is also half the
| size so they're more likely to finish it.
| beckingz wrote:
| Solid recommendations.
|
| Mythical Man Month and Peopleware have been the best books I've
| ever purchased from a financial return on investment perspective.
| Required reading for any technology professionals.
| elevaet wrote:
| What did you get out of these books?
| Benjammer wrote:
| I apply the concepts from MMM in professional contexts
| probably more than all other books combined. So many absolute
| timeless gems.
|
| * No silver bullet
|
| * 2nd system effect
|
| * Mythical man month (adding people to a late project makes
| it later)
|
| * "Question: How does a large software project get to be one
| year late? Answer: One day at a time!"
|
| * Separate architecture and implementation
|
| * "The Surgical Team" about technical team structure
| buescher wrote:
| Also an important takeaway from TMMM: people were having
| the same problems and trying the same approaches to solve
| them _over 50 years ago_.
| beckingz wrote:
| A much better understanding of what it means to manage
| software engineering projects and work within a software
| engineering organization.
|
| These understandings are valuable as an individual
| contributor: you are more self managing, which increases your
| perceived value (in healthy orgs), and are able to understand
| the machinations of a software org, which is good for your
| sanity and effectiveness.
| loloquwowndueo wrote:
| mythical man month : "adding resources to a late software
| project only makes it later", and gives you an authoritative
| reference to throw at everyone who hasn't read it and thinks
| that "hey if I give you double the headcount can you finish
| the project in half the time?" It happens a lot in real life
| :/
| Minor49er wrote:
| Tom DeMarco is a fantastic author. His book "Slack: Getting
| Past Burnout, Busywork, and the Myth of Total Efficiency" is
| incredibly helpful if you're on a team that faces anything
| listed in that subtitle
| CharlieDigital wrote:
| Code Complete has some of my favorite quotes on programming.
| "The visual and intellectual enjoyment of well-formatted code is
| a pleasure that few nonprogrammers can appreciate. But
| programmers who take pride in their work derive great artistic
| satisfaction from polishing the visual structure of their code."
| "...there is a psychological basis for writing programs in a
| conventional manner: programmers have strong expectations that
| other programmers will follow these discourse rules. If the
| rules are violated, then the utility afforded by the expectations
| that programmers have built up over time is effectively
| nullified." "The smaller part of the job of
| programming is writing a program so that the computer can read
| it; the larger part is writing it so that other humans can read
| it." "The information contained in a program is denser
| than the information contained in most books. Whereas you might
| read and understand a page of a book in a minute or two, most
| programmers can't read and understand a naked program listing at
| anything close to that rate. A program should give more
| organizational clues than a book, not fewer."
| j1elo wrote:
| I always liked the feeling of looking at a well-formatted piece
| of code. But discussions about formatting always ensued with
| coworkers.
|
| Lately, I've been deriving immense satisfaction from pressing
| Ctrl+Shift+I inside VSCode, and having Prettier format
| absolutely everything, with its sensible default settings and
| no leeway for discussion. It feels _good_.
| neves wrote:
| I'm in love of Black formatter for python code: it leaves
| almost no option for formatting preferences. Format on save
| and you are done. It clears mental cycles for the important
| problems and make formatting discussions a thing of the past.
| digdugdirk wrote:
| Excellent quotes, and certainly inspired me to put Code
| Complete on the reading list.
|
| Out of curiosity - how did these quotes come to mind/hand so
| quickly? What's your notetaking process look like? How do you
| keep it all organized?
| CharlieDigital wrote:
| I freely highlight and take notes in my books, but also, I
| keep a blog and a Medium :)
| renox wrote:
| Given that I know have to use clang-format, the 'intellectual
| enjoyment of well-formated code' is a thing of the past.
|
| This isn't a criticism of clang-format, just that as it is now
| a tool which does the formatting, I focus on other things..
| amelius wrote:
| > "The visual and intellectual enjoyment of well-formatted code
| is a pleasure that few nonprogrammers can appreciate. But
| programmers who take pride in their work derive great artistic
| satisfaction from polishing the visual structure of their
| code."
|
| Except those who code in Whitespace.
|
| https://en.wikipedia.org/wiki/Whitespace_(programming_langua...
___________________________________________________________________
(page generated 2022-08-01 23:01 UTC)