After doing it for years, I've realized that clean code isn't really a good end goal, so I'm not sure if it "steps up your game"
That said, The Pragmatic Programmer is my favorite resource for it. https://refactoring.guru/ is also a nice reference point, in an easy problem-solution format.
It's not just algorithms. Creating maintainable code and building good habits matter too.
For that, I'd recommend The Pragmatic Programmer, A.Hunt, D.Thomas.
Once you get over the syntax and basics of writing a program, I would recommend learning about writing maintainable software.
Kent Beck's 4 rules of simple design is great. You can find the rules online.
Some great books are Clean Code, Pragmatic Programmer, Working Effectively with Legacy Code
Chapter 3 of "The Mythical Man Month" is titled "The Surgical Team" and describes just this. If you enjoyed the Pragmatic Programmer, I recommend The Mythical Man Month as well.
The Pragmatic Programmer from Andrew Hunt. Very informative book. It is a book filled with opinions/tips from experienced programmers, some of which apply and some don't. The ones that do are invaluable.
The Pragmatic Programmer. I'm on mobile, so just Google for it.
This book is amazing and still holds up today, for the most part.
A copy of
The Pragmatic Programmer...
I think a toy robot would be great
two books I would recommend anyone wanting to become a great programmer to read:
- the pragmatic programmer
- clean code
I'm not sure I believe articles like this, but myself and colleagues have found these books to greatly improve our coding.
The Mythical Man-Month and The Pragmatic Programmer are two of my favorite classics. Fairly easy reading and valuable insights.
The Pragmatic Programmer is one of my favorite books ever. I recommend it to every programmer. At whatever point I'll have employees of my own, it will be required reading.
I noticed that the Pragmatic Programmers books are made with LaTeX, so I was curious to know what kind of toolchain they use. In this video Steve Peter shows their toolchain.
Are there any one of those books that you would especially recommend? I have considered the Pragmatic Programmer - but is there more to it than what is implied in the title?
> A lot of what you say about
The Pragmatic Programmer, applies to the book Code Complete too
Agreed, that's why I listed that book in my linked comment:)
I am certain there are words of wisdom in The Pragmatic Programmer book that correlate to this post. I'll update my comment if I find it, but I'm sure someone here will remember it before me.
Seeing as your title managed to land under the same publishing umbrella as (one of my own favorite programming books as well) The Pragmatic Programmer, do you have insight as to whether your title will also be made available on the O'Reilly platform?
Peopleware by Demarco and Lister is one of my all-time favorites. The Pragmatic Programmer is also great.
"The Pragmatic Programmer" is much more detailed.
Joined :)
Well, the first book recommended is The Pragmatic Programmer, we can all get behind that one :)
Sign your code.
Doing this attaches your reputation to your code. Anybody reading it knows to expect a certain level of quality given it is written by you, and you get the much needed motivation to write good code.
Amazing piece of advice I picked from the Pragmatic Programmer.
I like the concept, but it would be nice to see a better selection of books about the craft of building software, rather than language guides. For example, books along the lines of "Code Complete", "The Pragmatic Programmer", etc.
Practice, learn from others. Don't spend more time reading than coding, but a couple of books with good tips include "
The Pragmatic Programmer" and "Apprenticeship Patterns"
Also going to dojos and doing katas.
The books listed in this article are great. Code Complete, Pragmatic Programmer, Head First Design Patterns, all great.
"The Pragmatic Programmer" is one of the best books on programming I've read. When it first came out I read it and then went out and bought a copy for every member of my team. It's fabulous.
The Pragmatic Programmer. It feels like a textbook introduction to the software engineering field. Not the code part, but more the engineering parts.
There's a 2019 edition of The Pragmatic Programmer. I haven't read enough to compare it to the original.
I own Code Complete, but I felt I got better value out of the Clean Code book combined with
the Pragmatic Programmer.
I did find some value in Code Complete, but it is a little too long for my tastes. The naming and abstract data structure sections were probably my favorite parts of that book.
-
The Pragmatic Programmer (Hunt/Thomas)
- Computer Architecture - A Quantitative Approach (Hennessy/Patterson)
- Expert C Programming - Deep C Secrets (van der Linden)
I woud call the Pragmatic Programmer though by far the most influential.
'The Pragmatic Programmer' is a fantastic language-agnostic manual that still applies heavily today.
Absolutely learn it now. I suggest reading "Pragmatic Version Control Using Git" (Subversion & CVS editions also available), from The Pragmatic Programmers. Excellent book. Short & straightforward.
Finally bought
Pragmatic Programmer and Code Complete so I'm perusing through those in between my school work/reading.
Also got Rapid Development for 5 dollars, but haven't started on that. Haven't really read any software engineering books like these before, but enjoying them so far.
Starting Strength - because this time I actually started lifting instead of just reading it :)
The Pragmatic Programmer - It has been recommended to me by a good developer that is self-taught like me. So far so good. Some things are a bit dated though.
"
The Pragmatic Programmer" by Andrew Hunt and Dave Thomas.
It reads a bit like "the 7 habits for effectice developers", except that it contains about a 150 "habits". I have wished many, many times that I could force colleagues to read this.
http://www.pragprog.com/titles/tpp/the-pragmatic-programmer
I fully recommend The Pragmatic Programmer. Its a book that I feel will ease transition from spoon fed grad to experienced coder such that you can pick up new languages and technologies as and when they fit the problem faced.
I'll second 'The Pragmatic Programmer' as a wonderful career enhancer.
I'm reading 'Growing Object-Oriented Software guided By Tests', Pryce, Freeman right now, and think it's really worthwhile.
Check out Leo Brodie's "Thinking Forth"
I read both The Pragmatic Programmer and Code Complete (2ed) before Thinking Forth. The latter provides a wonderful software engineering foundation (in clearer, more concise language too).
I have not read it but "The Pragmatic Programmer" remains the best development book for me. Interesting how the "Apprenticeship Patterns" compares to it?
Yeah, I saw this approach in a book called "The Pragmatic Programmer", which I highly recommend. Agreed 100%
*
The Pragmatic Programmer (Read this once every 6 months until it's obvious)
* Head first design patterns
* Agile Web Development with Rails
It's not obvious, but the rails book is a great introduction to test-driven development in general.
Thank you, it does look good. I still want one with an animal on the cover!
Or, more seriously, I think an O'Reilly book on common Lisp would go a long way toward promoting the language. As would one from the Pragmatic Programmers.
I've recently read The Pragmatic Programmer and its still quite relevant
I've also read the pragmatic programmer. They had the right idea, eh?
> Traditional publishers take something like 90%
The Pragmatic Programmers offer their authors 50% of the net. I was lucky enough to publish one book with them, and despite that book's anemic sales I made out pretty well. Cant recommend them enough to prospective authors.
My favourites are more about the general craft of software development than specifics e.g.
The Pragmatic Programmer: Hunt and Thomas
The Mythical Man Month: Frederick Brooks
I really like:
- Code Complete by Steve McConnell
- The Effective Engineer by Edmond Lau
- The Pragmatic Programmer by Andrew Hunt and David Thomas
A lot of what you say about The Pragmatic Programmer, applies to the book Code Complete too, particularly your last paragraph, however, it has so many "good practices" points, that it is worth reviewing now and then, even for experienced programmers, IMO.
I now I am late on reading this one, but
Pragmatic Programmer.
Then there was The Kite Runner
Also, Zen and the Art of Motorcycle Maintanence
Then Becoming a Technical Leader by Gerald
I wish I had read more.
Thanks a lot. I'm sure I read the book a few years ago ... will have closer look to make sure I'm not confusing it with "The Pragmatic Programmer".
No, not Code Complete. It is an obsolete book, made with sloppy research, that leads to shallow or incorrect conclusions (10x more productive programmers, code of uncertainty, etc).
Pragmatic Programmer is a much better book.
The software-related books I've given most often are Gerald Weinberg's 'Becoming a Technical Leader', Brook's 'Mythical Man Month', Demarco and Lister's 'Peopleware', Hunt and Thomas 'The Pragmatic Programmer', and Mconnell's 'Code Complete'.
One thing I pay for and I don't think anyone mentioned is "O'Reilly Safari Bookstore". US$ 22,00 month (I think?) and quite some nice books: the Javascript Rhino book, Obie's the Rails way, the Ruby way, the Pragmatic Programmer, the Cathedral and the Bazaar, and Hackers & Painters, to name a few.
Working with other great developers.
Learning to keep it simple & methods for avoiding code duplication. I tend to find when learning a new language that avoiding duplication teaches me how to use the language properly.
And the book, The Pragmatic Programmer helped me to communicate better.
This is great news.
I've finished reading the fist draft of the Pragmatic Programmers new book on Clojure and I can't wait until they release another draft. The first draft only contains about half the chapters.
Best "learn a language" book I've read was the first edition of Joe Armstrong's Programming Erlang book.
For a Software Engineering book, it's hard to beat The Pragmatic Programmer.
A good working-with-other-people book is Extreme Programming Explained 2nd ed.
Pragmatic Programmer and Code Complete are usually mentioned as classic programmer text books. I own both and have probably read 10 pages between the 2 books.
I'd suggest "The Pragmatic Programmer" by Hunt and Thomas. It's a compendium of advice on being an effective programmer compiled from experience. Also, take look at "The Practice of Programming" by Kernighan and Pike. It's a bit more narrowly-focused, but Kernighan and Pike are models for clarity in programming and in writing.
I'll add my current three,
1) "How to Win Friends and Influence People"
2) "The War of Art"
3) "The Pragmatic Programmer"
Have you read Smalltalk Best Practice Patterns by Kent Beck? I'd throw it in that mix if you haven't. It and the Pragmatic Programmer are my two favorites. Code Complete is too verbose imho.
Even if it substitutes for a CS degree, it won't make you a remotely decent programmer. Without books like Code Complete, The Pragmatic Programmer, The Mythical Man Month, etc., your code will suck.
The Pragmatic Programmer might be useful from an angle of what not to do, and has a good amount of wisdom with regards to refactoring. It's also quite pleasant to read, less technical, more on general patterns to learn from.
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 kinda wonder, after all these years, if there would ever be a new edition of the Pragmatic Programmer; or even a discussion from the authors on how their thinking has evolved over time.
Have you considered reading some software engineering classics as well?
Code Complete, Rapid Development, The Mythical Man-Month, The Pragmatic Programmer, Peopleware and A Discipline for Software Engineering? (The last one is controversial).
"The Pragmatic Programmer" may be useful to you. It's dated but still relevant, and it was recently revised.
Wow, I can't believe The Pragmatic Programmer dates back to 1999 — seems like I read it just yesterday!
I'm surprised that The Pragmatic Programmer isn't on there. Am I that much out of date that this book is no longer recommended? It completely changed the way I thought of development at the time.
I highly recommend the Pragmatic Programmer's book on Clojure. For me, the concepts are new and interesting and may even be applicable to what I'm working on today, and will most certainly be applicable in the multi-core future.
I think the book « The Pragmatic Programmer » advises to do refactorings twice: First refactor to see what it’s hitting, then rollback. Once you know what you’re hitting, format it and clear it up, commit, then perform the big refactor, and you have much better chances of going smoothly.
If it isn't clear it's not easy to change, making it "bad code."
Do what needs to be done to make the intent of a block of code super clear, in plain English. Comments don't count, as illustrated clearly in The Pragmatic Programmer, for instance.
Pragmatic Programmer, Art of Unix Programming, and Code Complete (in that order because of page count) are the books that I recommend these days to junior devs
* Alan Turing: The Enigma of Intelligence by Andrew Hodges. The definitive biography, with lots of detailed explanations of his work.
* Making Software, edited by Oram & Wilson. A bunch of papers about evidence-based software engineering.
* Beautiful Code, also edited by Oram & Wilson. A bunch of papers about especially elegant pieces of software.
* Eiffel, by Bertrand Meyer. What Java should have been.
* The Devil's DP Dictionary, by Stan Kelly Bootle. A satirical look at the computer industry circa 1980.
* The Jargon File. (http://www.catb.org/jargon/html/). The language of the Elder Days.
* Facts and Fallacies of Software Engineering by Robert Glass.
* The Pragmatic Programmer by Hunt & Thomas.
If you haven't read them yet, Design Patterns, The Pragmatic Programmer, and Code Complete, will all help you.
What do I recommend for a teen programmer? Unit testing.
Best resources and books? There are just so many good books. Last one I enjoyed was The Pragmatic Programmer. Next I'm going to try reading Clean Code.
Keep learning. Keep reading. Keep writing.
1)
The Pragmatic Programmer by Hunt and Thomas will always be a classic.
2) The Decision Maker by Dennis Bakke. This one pairs well with the more thorough Reinventing Organizations which has been mentioned in another comment.
Which is to say you haven't read The Pragmatic Programmer? I highly, highly recommend it. I bought my first copy about 8 years ago, and pull it off the shelf once a year or so to freshen up. I always learn something new every time I do.
The Pragmatic Programmer (book) -
New office chair -
Candy/Chocolate/Wine/other goodies
The wife and I bought a new car this Christmas season, so I think that counts. We already have it though. '06 Volvo S60.
I'd recommend edx's CS50x, "Learn Python the Hard Way", "The Pragmatic Programmer" and "Code Complete".
According to the site:
The coupon is valid for the entire contents of an order
(excluding books we do not publish such as The Pragmatic
Programmer and a handful of other titles) but does not
affect shipping costs.
I know DHH divides opinion here on HN, but this book is a real Gem (not to be confused with RubyGems).
This and "The Pragmatic Programmer" are my top two books, relating to Software Development and Running a small business.
Computer Systems: A Programmer's Perspective and NAND2Tetris: Elements of Computing Systems are the best books to learn the internals of computer hardware and solidify your understanding of how a computer works.
The Pragmatic Programmer - My all time favorite. Awesome book to learn best practices of various aspects in programming.
The Code Book: The Evolution Of Secrecy From Mary, Queen Of Scots To Quantum Cryptography, if you have a thing for cryptography.
One of the niceties of CoffeeScript generated code is that it's totally readable and idiomatic Javascript with a dose of JSLint on top.
To misquote the "Pragmatic Programmer" book... don't use wizard code you don't understand. The opposite applies in my opinion.
> Dave Thomas, the author of
Pragmatic Programmer and Programming Ruby (arguably the book that helped Ruby grow pre-Rails), has written a great book titled "Programming Elixir"
I bought this ebook when it was first released. The level of care Dave has given to it is astounding. I believe he's released at least 10 significant updates to it as the language has evolved.
Maybe he said somewhere on the book's marketing page that he was going to be doing that, but if he did, I missed it. Extremely pleasant surprise.
I picked up
the Pragmatic Programmer some time ago and among the great lessons it had, the one that sticks with me every day at the code editor is: You spend far more time reading your code than you will writing it.
With that in mind, it makes it easy to write tests and more comprehensible variable names (still thinking and re-thinking how to best do documentation...was checking out github's Ruby guide and Tomdoc yesterday http://tomdoc.org/)
I am interested in reading books about software development and best practices like Clean Code and
The Pragmatic Programmer [0]. I have coded for about eight years, but I would like to do it better. I would like to know your opinion about [0], since Clean Code has been significantly criticized.
[0] https://pragprog.com/titles/tpp20/the-pragmatic-programmer-2...
The Pragmatic Programmer was a good broad spectrum intro 20 years ago, I don't know how well it's aged, but they have just released a 20th anniversary update so maybe check out reviews for that.
"I'd suggest reading
the pragmatic programmer before looking into a new backend stack."
Thanks for the suggestions, I'll give it a listen on Audible.
> I read
the Pragmatic Programmer last year, and it was .. very boring. Most of the tips were like "doh, of course".
Context: it was published in 1999.
I came across Stone Soup Story while reading
The Pragmatic Programmer - By Andy Hunt and Dave Thomas And I think super power - a chrome extension that empowers developing static websites directly from the browser was also a stone soup. Read more about it here-
https://medium.com/@ananyaagrawal125/stone-soup-and-super-po...Software Developer
1. Code Complete by Steve McConnell
2. Refactoring by Martin Fowler
3. The Pragmatic Programmer by Andrew Hunt and Dave Thomas
What I saw on the first two pages of Customers who bought.... list was:
Database Internals,
Snowden book,
Algorithms book,
BPF Performance tools,
Your Linux Toolbox,
The Go Programming Language,
The Pragmatic Programmer,
Quantum Computing,
A Programmer's Introduction to Mathematics,
An Elegant Puzzle
I had to go up to page 14 of the items list to find all of the items you listed and to find the wire-type soldering iron tip cleaner.
Edit: Took out unneeded snark. It seems I fell prey to Amazon algorithms.
That reminds me, I'm due a re-read of The Pragmatic Programmer. I re-read it about once a year, and every time seem to get something new from it.
A senior developer told me early on that all software is compromise. Thinking back to that has often saved me when I realize that I'm trying to find a perfect solution. There is no perfect solution. Also, read books, especially The Pragmatic Programmer. I finally read it this year as a Sr. Developer and there were some great nuggets of wisdom.
Andy Hunt and Dave Thomas wrote the seminal software development book,
The Pragmatic Programmer. Together they founded
The Pragmatic Programmers and are well known as founders of the agile movement and authors of the Agile Manifesto. They founded the Pragmatic Bookshelf publishing business in 2003.
The Pragmatic Bookshelf published it's most important book, in my opinion, in 2017 with the first pytest book available from any publisher.
Topics:
The Pragmatic Programmer, the book
The Manifesto for Agile Software Development
Agile methodologies and lightweight methods
Some issues with "Agile" as it is now.
The GROWS Method
Pragmatic Bookshelf, the publishing company
How Pragmatic Bookshelf is different, and what it's like to be an author with them.
Reading and writing sci-fi novels, including Conglommora, Andy's novels.
Playing music.
One of the first rules from the book The Pragmatic Programmer is "SELECT isn't broken". (It might even be the first rule.)
I've heard (but can't verify) that
the Pragmatic Programmers have their own tool chain, and that it's quite good. It will, for example, check that code snippets are syntactically correct.
I have a few of their books, and they're pretty good. Their store is also very straightforward and friendly.
Does anybody have experience writing for them?
Reading
The Pragmatic Programmer helped me a lot with the problem-approaching aspect of things, but then I didn't pick it up until I was moderately comfortable with PHP. (I'm not a FT programmer so my learning process tends to be s-l-o-w w/o many opportunities for practice.)
I'd definitely be interested to see two different programmers write up their approach to a given problem. Something like this would be an excellent monthly blog post.
> I helped port the full back catalog of books from
The Pragmatic Programmers over to Medium
People feed the beast and then wonder why it's come back for more.
I learned to program with a book called Learn to Program from the great publisher
Pragmatic Programmers around 2011 All I knew was just like you: some HTML/CSS, and unziping and embedding jquery plugins. Here's a link to the book
https://www.amazon.com/Learn-Program-Second-Facets-Ruby/dp/1...I'd go for that and some JS on the side but if you got an iPad, I'd definitely try Swift with the Playgrounds app.
Clojure. Without a doubt. It's by far the easiest and most productive Lisp around right now. You get a modern core library with great support for concurrency, and you can use Java libraries with ease. The new Clojure book published by the Pragmatic Programmer guys a pretty good read, and it gets into the important aspects of functional and concurrent programming. I've been having a blast so far.
If you're just starting out in your career, reading Code Complete is like gaining experience by osmosis. Then once you know what you're doing, Pragmatic Programmer is like a light refresher that you read once every few years.
I recently read
The Pragmatic Programmers book
SQL Antipatterns: Avoiding the Pitfalls of Database Programming (
http://pragprog.com/book/bksqla/sql-antipatterns) and chapter 6 talks specifically about this kind of DB design (entity-attribute-value) and the benefits/pitfalls. It's a great read and I highly recommend it.
As a recent graduate, I cannot recommend
Pragmatic Programmer and Code Complete highly enough.
Pragmatic Programmer fills in the gaps you need to succeed as a professional programmer.
Code Complete is a field guide to managing software complexity.
They're not all writers, some just invented things like the Wiki. The original wiki, the portland pattern repository, was a hotbed of discussion among those programmers about the practices that eventually became known as agile. It was an amazing place to hang out and debate patterns, languages, and architecture with other passionate developers. There's been nothing like it since.
But from the writers:
* Refactoring
* Patterns of Enterprise Application Architecture
* Smalltalk Best Practice Patterns
* Agile Software Development, Principles, Patterns, and Practices
* Domain-Driven Design
* Structure and Interpretation of Computer Programs
* The Pragmatic Programmer
* Design Patterns
* Analysis Patterns
* Implementation Patterns
Fowler is the most prolific writer of the bunch, but he was largely documenting and naming what he saw all of them doing.
> [...] the original “Don’t repeat yourself” was nothing to do with code, it was to do with knowledge
> The trouble with DRY is it has no reference to the knowledge bit, which is arguably the most important part!
Okay. Now what does this mean? Is this article effectively a tantalizing recommendation to read The Pragmatic Programmer?
The Pragmatic Programmer (Andy Hunt and Dave Thomas) is the other one that springs to mind for me.
-
Pragmatic Programmer, From Journeyman To Master
- Code Complete 2nd Ed.
- Quality Software Management Vol 1-4, by Gerald M. Weinberg
I'd also throw in: Code Reading - The Open Source Perspective
There is so much to love about Elm. It is a typed language, so it eliminates typing issues, like 1 + "1" = "11". Its compiler is great. The compiler catches almost everything and offers easy-to-read suggestions to fix your code when there is a problem. Elm's compiler virtually eliminates runtime errors; at least I've never had a runtime error with Elm.
I also like the debugger. It allows you to easily capture your steps as you click around your application, save those steps into a file, and send that file to other developers, which allows them to run through your steps on their own machine; seeing Elm's output at each stage. It works like a "steps to reproduce" bug report, only automated, which makes finding and fixing difficult bugs easy.
There is a lot of good documentation for Elm as well. Elm's documentation itself is good. Manning and Pragmatic Programmers both have good books on Elm (both are still early access versions though). Pragmatic Studio also has an excellent video course on Elm for about $60 (https://pragmaticstudio.com/courses/elm), if you're interested in learning it.
My top priority books:
Software Requirements - Karl Wiegers
Programming TypeScript - Boris Cherny
Associate Cloud Engineer Study - Dan Sullivan
Design Patterns - Gang of Four
Refactoring - Kent Beck, Martin Fowler
Programming Pearls - Jon Bentley
Patterns of Enterprise Application Architecture - Martin Fowler
The Pragmatic Programmer - David Thomas, Andrew Hunt
CSS: The Definitive Guide - Eric A. Meyer, Estelle Weyl
Working Effectively with Legacy Code - Michael Feathers
Head First Design Patterns - Eric Freeman, Bert Bates
Code Complete - Steve McConnell
Peopleware - Tim Lister, Tom DeMarco
Clean Code - Robert C. Martin
The Clean Coder - Robert C. Martin
Clean Architecture - Robert C. Martin
Don't Make Me Think - Steve Krug
Functional Design Patterns for Express.js - Jonathan Lee Martin
The Surrender Experiment - Michael A. Singer
The best books I've ever read:
Principles - Ray Dalio
The Power of Now - Eckhart Tolle
The Effective Executive - Peter F. Drucker
Think and Grow Rich - Napoleon Hill
Extreme Ownership - Jocko Willink, Leif Babin
Influence - Robert B. Cialdini
The Startup Way - Eric Ries
The Lean Startup - Eric Ries
12 Rules for Life - Jordan B. Peterson
Measure What Matters - John Doerr, Larry Page
The Fish That Ate the Whale - Rich Cohen
The E-Myth Revisited - Michael E. Gerber
The Score Takes Care of Itself - Bill Walsh, Steve Jamison, Craig Walsh
Management - Peter F. Drucker
Thinking in Systems - Donella H. Meadows
Blue Ocean Strategy - W. Chan Kim, Renee Mauborgne
This is usually true of language or framework-specific books, but not of more general books like The Pragmatic Programmer.
If you're looking to write books that will be read years from now, you need to focus on wider or more fundamental issues. The caveat here is that primers for long-lived languages like C++ have remained relevant for decades.
Definitely learn to use version control of some sort (I'm still stuck on Subversion) as early as you possibly can. Indeed, it'll be great to track your progress as you build up code on more complex stuff. Also, you'll definitely be great in a team environment and it'll foster a somewhat safer team environment, too. Teaching a developer now at my job (who was in place before I was) how to use SVN because now we're officially a team and I stay nervous about accidentally hosing anything he does or vice versa.
And yes, being able to rollback bugs or things your users don't like in a systematic, traceable way is absolutely the best. Undo only works up to a point lol.
Check out The Pragmatic Programmer for more nice ideas about being a developer. http://www.pragprog.com/the-pragmatic-programmer
There were different book that impacted different stages of my career:
As a programmer :
1. The C++ Programming Language by Bjarne Stroustrup.
2. Operating System Concepts by Silberschatz
3. Compilers by Aho
As an agile software developer:
1. eXtreme Programming by Kent Beck
2. Pragmatic Programmer by Hunt and Thomas
3. Continuous Delivery by Jez Humble
As an architect:
1. Domain Driven Design by Evans
2. Pattern-Oriented Software Architecture by Buschmann
3. Envisioning Information by Edward Tufte
As a CEO:
1. Good To Great by Collins
2. Lean Startup by Eric Ries
3. Beyond Budgeting by Pfläging
Hmmm... my own list of memorable programming books would look like (in no specific order):
1. The Mythical Man Month, Brooks
2. Peopleware, DeMarco and Lister
3. Paradigms of Artificial Intelligence Programming, Norvig
4. The C Programming Language, Kernighan and Ritchie
5. The Ruby Way, Fulton
I had a hard time deciding whether or not to include
the Pragmatic Programmer, in the end I decided to go with The Ruby Way because it was an unusually enjoyable read for a language book.
I know the original list was supposed to be more esoteric books, not classics, but I'm anticipating this becoming a thread of everyone's favorites. : ))
Hi Jacques,
Thank you for your comment, I thoroughly enjoyed it. Thank you also for summarizing the many forseeable possible discussions upfront so that we could have avoided them here.
The books were chosen by a group of five, half of us with 10-15 years of experience, so no, they aren't the latest books the author by a chance happend to read.
I admit that, as others have complained, the title might be percieved as misleading. The reason is that these are books that our company recommends to its developers and we want the developers to be something more than coders (= what most people understand under 'developer'). Though it's important to write great code, it's even more important, IMHO, that it is the right code that gets written, i.e. that the resources available are used to produce the maximal business value possible (and we believe that this cannot be planned but must be discovered based on feedback from reality - that's why lean/agile). Going quickly (great coding skills) in the wrong direction isn't progress.
Some of us have read Code Complete or The Pragmatic Programmer but it hasn't made it into the list. More of us will read it now and we will reevaluate the list afterwards. I hope it's good with you :-)
My favorites so far:
- Pragmatic Thinking & Learning by Andy Hunt
- The Design of Everyday Things by Don Norman
-
The Effective Engineer* by Edmond Lau
- The Pragmatic Programmer by Andy Hunt and Dave Thomas
- SQL Performance Explained by Markus Winand
And http://teachyourselfcs.com curriculum is pretty good as well.
As a side note, there's so much we can learn from game programmers and OS/database/compiler engineers.
Since you said web design, I am assuming you want to build a website.
So, Ruby on Rails.
Rails is a stack that has:
Ruby - a very simple developer friendly language. This is responsible for putting together
JavaScript - this lang is responsible for all the fancy stuff you see on websites. The animations and all.
HTML, CSS - this is the stuff that websites are made of. Ruby and JavaScript are used to generate this the way you want.
I used to be an accountant and started coding in Nov 2014. I have many rails apps ever since as prototypes and maintain one app that is in production (meaning people use it).
I used this Rails Tutorial by Michael Hart (https://www.railstutorial.org/book) significantly. You will end up with a cool website at no cost at the end of the book.
I also highly recommend Codecademy courses on HTML, CSS, JavaScript and Ruby.
If you are really serious about this stuff, which is great news, you might want to read more about making software. Start with the Pragmatic Programmer. It is a great book to read in your formative years.
And finally (this is important), try to solve a problem (like building a website for yourself or a friend etc) with programming. Learning just to know doesn't stick for long in my experience and probably is true for others.
In the book "
The Pragmatic Programmer" they refer to this as "rubber ducking". The origin of the term was from a particular programmer who kept a rubber duck sitting near his computer (I believe on his monitor, I don't have the book handy right now). When questioned about why the duck was there, he said that when he got stuck on a problem, he would explain the problem to the rubber duck (full well knowing that the duck was not going to respond :-D ). The purpose of having the duck was just to have a target to explain the problem to, knowing that the act of explaining the problem would often lead him to the solution.
There's a wiki article about it here:
http://www.c2.com/cgi/wiki?RubberDucking
The Pragmatic Programmer, which was recently published its 20th Anniversary Edition, talk about these tips in whole book, from The Basic Tools to Pragmatic Starter Kit.
The Pragmatic Programmers have a book on learning called "Pragmatic Thinking and Learning". I own it and would highly recommend it, one of the more underrated books. It covers the Dreyfus learning model which was mentioned in the article.
The examples and language tend to be programming related (for example one chapter is titled "Debugging your Brain" iirc) because that's the intended audience but I'd also recomend it for non-programmers.
Very good blend of theory (Dreyfus model, r-/l-mode) and practical advice on how to improve your learning and generally use your brain better.
http://pragprog.com/book/ahptl/pragmatic-thinking-and-learni...
Hi everyone,
Last year, I was lucky enough to sign a book deal with The Pragmatic Bookshelf to write an intermediate level book on Python. (The Pragmatic Bookshelf is the publishing company founded by the authors of one of my favorite programming books: The Pragmatic Programmer.)
Having written Python most of my professional career, I wanted a resource that I could give to engineers who might have deeper experience in some language that wasn't necessarily Python. I wanted to help teammates newer to Python quickly discover its virtues (and limitations). I think there are tremendous Python resources available online, but wanted to capture another perspective to help teammates level up their skills.
The book ("Intuitive Python: Productive Development for Projects that Last") went through a beta release this spring, and was officially released this month.
It's available (including a few free sections) here: https://pragprog.com/titles/dmpython/intuitive-python/
In case anyone is thinking of becoming an author with the The Pragmatic Bookshelf, I'd be happy to share my thoughts about the publishing experience there (spoiler: I had a positive experience).
I'm proud to have released this book, and excited to share it here.
Thanks!
-David
I would not read it if you called it a "productivity book". But maybe I misunderstand. Books with "tips, tricks, and techniques for more productive development" could include The Pragmatic Programmer, SICP, Hackers Delight, The Mythical Man Month, Programmers at Work, Unix Power Tools, Expert C Progamming, Release It!, Gang of Four, Art of Unix Programming, etc. I've read those and would read others like them. Probably the most like a "productivity book" I've read was Time Management for System Administrators. That was excellent, but I don't want to read more books on how to be organized, how to stay motivated, how to manage my TODO list, etc. That's what I think of when I hear "productivity book". Whichever your meaning, I would ask yourself what you have to contribute that hasn't been said already. It's hard to find new interesting things to say, but if you have something, best of luck to you!
I've enjoyed having an O'Reilly Safari subscription for random access to books. In particular,
the Pragmatic Programmer and Designing Data-Intensive Applications.
I've also had good experiences with SCPD courses from Stanford, if your budget would cover those (they are at the other end of the price spectrum).
"Mazes are everywhere. From psychology experiments where mice scamper in search of cheese, to robotics demonstrations, to movies (Labyrinth, anyone?) and video games (Pac-Man? The Legend of Zelda? Doom?), to books and books of puzzles to be traced by finger or pencil, you’ve almost certainly encountered them at some point in your life.
What you’re reading now is not a collection of mazes for you to solve. No, this is something much more exciting. This is a collection of ideas to inspire you.
You’re about to learn how to generate your own mazes. Random mazes, unique, each one different than the one before. It’s a voyage of discovery where you never know quite what you’ll find when you crest the next hill."
Mazes for Programmers by Jamis Buck — Pragmatic Programmers (3 / 121)
Read more: https://medium.com/pragmatic-programmers/introduction-f7e108...
Sure you do, but let's say a small publisher like
the Pragmatic Programmers managed to roll out a $8.99 iPad e-book on a new technology (let's say Clojure) and O'Reilly's was selling for $14.99.. well, the choice would be more difficult, no? In many niches, books
are interchangeable.. at least until the reviews come out ;-)
Luckily with many tech and non-fiction books, the author isn't quite as important as when you're buying fiction or high profile books from the likes of Seth Godin or Malcolm Gladwell. Those guys will always be able to charge the premium rates :-)
Excellent question btw. Language-agnostic books don't get out-dated that fast and I'd give them higher priority.
Personally:
- Code complete
- Pragmatic programmer
- Design patterns
- Programming pearls
- If you're going for hardcore programming: the dragon book, something on modern hardware and something on OS internals.
A few years ago I started an annual tradition, where around the new year I'll re-read the Pragmatic Programmer. This year will be the third year, and I expect I'll continue to gain new insights from future rereadings.
Oh, nice catch! I'm reading
The Pragmatic Programmer right now and I find myself wishing for an updated edition. I'm a little reluctant to buy a $40 patch of a book, but it almost seems worth it.
According to the preface, "As a result, this book is something of a Ship of Theseus. Roughly one-third of the topics in the book are brand new. Of the rest, the majority have been rewritten, either partially or totally. Our intent was to make things clearer, more relevant, and hopefully somewhat timeless."
It looks like it did get a substantial update.
I would have thought she'd mention Introduction to Algorithms (Rivest et al). The Pierce book is great but hardly something that I'd include in an every-programmer-must-learn-this list.
Code Complete is fantastic. I haven't re-read the Pragmatic Programmer in probably a decade but I remember that giving me a very good handle on approaching code as a young developer.
A lot of Googling, most of which concentrated on StackOverflow discussions. Redis and ØMQ both have
fantastic documentation, so it's easy to get started there; LXC was really a matter of trial and error. As for the more abstract concepts (networking/distributed computing), I would start on a Wikipedia article (
http://en.wikipedia.org/wiki/Distributed_computing for instance) and click links and jump from article to article for hours.
Books are great, but I prefer using solely online resources to learn; I find it to be a more efficient use of my time. Though there are notable exceptions: The Pragmatic Programmer (http://pragprog.com/the-pragmatic-programmer) and Getting Real (http://gettingreal.37signals.com/) come to mind.
Noble goals. And now that you said that I don't understand how I could have overlooked that in the first place.
Maybe it would be a good idea to put a bit more stress on the "no" in "no sacred cows", that's an important point beyond just K&R. Nothing should be sacred, including "Learning C The Hard Way" - and a "question everything and everyone" mindset is generally a good thing to have as a programmer [I think I read that in "The Pragmatic Programmer" ;-)]. But other than that I now think that chapter is fine. I do apologize for the somewhat passive-aggressive form of my question.
Thanks a lot!
I agree with that 100%. I am a voracious reader, I love software engineering and productivity and fiction and Syfy and nonfiction and... You get the idea.
I have a previous comment on this site about reading. That is actually what I look for, intellectual curiosity and a desire to continue learning and growing.
I'll just quote myself:
"""
What I look for in a developer: READS BOOKS. ( Audio books count )
That's the only thing. I'm sorry, if you are not reading and studying to keep up, you are getting left behind. There are so many brilliant people writing amazing books on a huge array of subjects. If I could get every one of my developers to read ONE book on software design[0] a year, I would die happy and the entire industry would be 10 years ahead.
They don't even have to be technical books. I just want to see intellectual curiosity and a commitment to self improvement.
- 0: In the vein of Clean Architecture, The Pragmatic Programmer, The Mythical Man Month, Designing Data-Intensive Applications, The Google SRE book, etc
"""
i suppose the author recently read
The Pragmatic Programmer?as with the same argument presented in that book, i have a little trouble with this since i've been under the impression the broken windows hypothesis was discredited...
What a great piece of writing. This could do so well as a preface to my all time favourite "programming" book: "
The Pragmatic Programmer" written by Hunt & Thomas.
Also, IMO, the worst of such "considered harmful" essays were those that advised against the use of stored procedures and programmatic constructs directly on relational databases in favour of the shiny new hive-mind created ORMs.
The funny thing is, just as the best ORM technologies are beginning to sort their shyte out, we are seeing essays that they are now considered harmful. Reboot.
The Pragmatic Programmer is pretty zealous about DRY. For instance, the authors describe how they inserted sample code snippets into the book using specialized scripts developed for that purpose. A simple copy paste wasn't good enough (see p. 100-101). Granted, they had wanted to make sure the code snippets were tested and updated as needed, but repeating code anywhere seems to be a bad practice according this definition.
> prevents people from reading content after a few times without either paying or logging in is beyond me.
I don't think this is fair or accurate.
Authors are choosing to put their articles behind Medium's paywall because they want to get paid. So when you see a paywall that's the author's choice. It's not any different than a Substack newsletter other than scale. So to say Medium is preventing people from reading... it's really that Medium is home for a lot of writers who want to get paid for their work and probably wouldn't even have written the piece you are trying to read without that incentive.
Then this Skymall article isn't even behind the paywall and doesn't have any sort of block on it or login wall. Or am I seeing something different than you? I tested it while not logged in.
FWIW, there is a ton of great writing on Medium even if there is also a lot of trash. For example, I helped port the full back catalog of books from The Pragmatic Programmers over to Medium. Those are great and it's great to have easy access to all of them.
I really liked
The Pragmatic Programmer, although some might think it's not a very technically challenging work.
I also like most of O'Reilly's Perl books.
Also, Jonathan Rockway's book on Catalyst was very helpful for me, although there were some issues with typos in the first edition (which is to be expected.)
Also, Philip Greenspun has published a good free collection of computer-science and web-development related texts on his website.
(Sure, he's a little arrogant and some people find his writing style to be somewhat abrasive or even borderline nonsensical, but I certainly liked most of his work. And I believe I learned quite a bit from it, as well, though I'm sure that is debatable.)
Judging by the "The Pragmatic Programmer" book on subversion alone, this series of books has got to be absolutely horrible because they literally half-copied the svn redbook and dumbed it down so you pay good money for so very little information which you could all very easily find by spending 10 minutes with the svn redbook.
> One of the first rules in the marvelous book
The Pragmatic Programmer is "Select() isn't broken". Yeah, but sometimes it is. And if a junior programmer came to me today reporting a bug in OS memory management, my first response would be "What's wrong with your code, really?"
In my years of software development I had the fun but unfortunate experience of coming across not one, but two compiler bugs. The program would segfault on a seemingly innocuous line, but after looking a the assembly, it was clear the compiler was doing something screwy. These types of bugs are exceedingly rare, and they can be maddening to debug, but when you catch them you get a nice sense of satisfaction.
Thanks for the input, we began a reading plan with The Pragmatic Programmer ans then we will move on to Don't Make Me think
Pragmatic Programmer is still a good book, not as revealing as before but still has lots of good advice.
Code Complete is a problematic book. It has some good ideas but also has some very bad ones (cone of uncertainty, 10 times productivity in good programmers, etc).
Design Patterns is mostly obsolete. Functional programming techniques made a lot of Object Oriented techniques irrelevant (e.g.: observer pattern vs callbacks with lambdas).
Art of Computer Programming is the book everyone mentions but no one reads. A classic that people actually read is Structure and Interpretation of Computer Programs.
My recommendations: "Code" by Charles Petzold,"Don't make me think" by Steve Krug, Working Effectivelly with Legacy Code, by Robert Feathers, Clean Code by uncle Bob,..
It's interesting to note that this presentation strongly contradicts the advice of "
The Pragmatic Programmer" and "Clean Code", which are highly respected by many. Does this mean that those books are wrong, or does it mean that Facebook will eventually come to regret their philosophy? Or maybe writing this kind of code is somehow fundamentally different, so the usual wisdom and rules of thumb don't apply.
I really don't know the answer, but find it fascinating and can't wait to see what Facebook is doing in 10 years time.
> - Code Complete by Steve McConnell
It has good parts. But it has some very bad parts too, when it reinforces myths that, IMO, are very wrong (e.g.: cone of uncertainty, X times better programmer, etc).
I'd recommend to read it with care.
> - The Pragmatic Programmer by Andrew Hunt and David Thomas
After many years I still read parts of it, again and again. And I still like it.
Now if only he would learn that most of the books left on his bookshelf are likewise window-dressing in front of fundamentals:
* The Pragmatic Programmer
* Clean Code
* The Clean Coder
* Domain-Driven Design
* Growing Object-Oriented Software, Guided by Tests
All of these books take the simple maxim:
"Be organized, and stay organized"
and spend thousands of pages expanding on that.
Not the OP, but my advice would be:
Read the "classics" - Code Complete, Pragmatic Programmer, Clean Code etc. Google "best books about programming" and you'll find plenty.
When you're reading think about the why. You're job is dealing in complexity and there is no one true way. Understand as many of the different ways as possible.
If you think an idea is weak, try and figure out a question that exposes the weakness (how does this handle a date before 1970?). Expect that sometimes this question will reveal the idea isn't as weak as you initially expected.
Remember you only need to solve the problem that's in front of you. If that problem doesn't seem easy try to break it up into smaller problems.
Complicated solutions are often bad solutions.
Complicated solutions can be good solutions.
Write your code for people to understand.
Advice on good writing is often very applicable to code... See Orwell(1), particularly "Break any of these rules sooner than say anything outright barbarous"
1.https://www.writingclasses.com/toolbox/tips-masters/george-o...
I'm still not exactly sure what the author means by Don't Repeat KnowledgeI think they're assuming that everyone has read The Pragmatic Programmer. To quote the original DRY principle from there:
Every piece of knowledge must have a single, unambiguous, authoritative representation within the system
Note that this has only an accidental relationship with code duplication, and in some cases could increase the latter.
Hey, I have your book! "
The Pragmatic Programmers: HTML5 and CSS3" right? :)
You were lucky because you consistently had the entire page width. For mine, because the book's formatting was pre-defined, the column width was variable depending on content type. I could have anywhere between 20 to 65 chars for code. The only place I had control was in the screenshots of code in Vim, but even Production decided to scale those down to make it fit.
WORD!
Generally, programmers who are afraid of the command line aren't very good at putting textual commands into a program text file, either.
They will cling for dear life to code generators and other such facilities in an IDE. (but not the good kind of code generators that define an original source DSL to be expanded into otherwise unseen code by the build process itself, always the IDE based code generators that generate mountains of crap code that now must be read and saved in source control)
They will cling to rigid, bloated, frameworks that require that they fill in parameters in an XML file, and write (many, scattered) tiny pieces of code to fill in the blanks for that framework, but which allow little variation from the application style which the framework mandates.
Beware the illiterate, programmer, grunting at cave paintings on the wall (clicking pictures on the screen, only).
See also: Pragmatic Programmers - power of text/shells sections; Neil Stephenson - "In the Beginning was the Command Line" essay.
This essay is far from perfect. That said, when I first read this I was a Windows user and primarily a Windows desktop application developer, but I'd started to explore what was outside the Microsoft ecosystem by playing with things like Perl and Linux. Reading this document, along with the (far, far better) book
The Pragmatic Programmer, helped open my eyes to the world beyond Microsoft.
All this to say: despite the negative comments here, this is worth your time to read.
The Pragmatic Programmer, Refactoring (I'm rereading it after many years with the 2018 edition, opinion not totally formed on this one), Working Effectively With Legacy Code, A Philosophy of Software Design. It's been a long time since I've read Clean Code, I don't quite get the hate from the other thread here today so I'm rereading it now. I figure it'll take me a couple days and worst case I'll agree with the criticism and stop recommending it.
I can't really decide, but here are a few of my favorites.
* Song of Ice and Fire series. I never really liked fantasy but this series is wonderful. The TV-series (Game of Thrones) is okay but a far cry from the books.
* The Pragmatic Programmer. The best programming book I've seen. A must read for programmers I'd say.
* Introduction to Algorithms. Haven't really gone through it but so far it's been great.
On a related note (sorry for hijacking)
Should you invest time in learning for interviews or your own personal growth once you are 2-3 years in the industry ?
I understand that both sets are not mutually exclusive, but where should you put your time on ?
Investing time specifically to give interviews: Leetcode, Cracking the Coding Interview, TopCoder, etc., may increase the chances of getting a better job then your current one (and will make you a better programmer too).
On the other hand reading books like 'the pragmatic programmer' and other classics, won't necessarily put you in a better position to get a better job (in most companies), but will surely make you perform better in the current one.
So, is it ok to put it this way:
* If you are happy with your job and you can see that you can stay 5+ years at the company (basically FAANG ?): Invest time in learning for personal growth (Design Patterns, Refactoring, etc)
* If you plan to switch / want a better salary / company sucks / <every_other_reason> : Invest time towards preparing for interviews specifically ?
Well, this brings up another problem. And that is that software development is not applied computer science. There are plenty of books which will teach you skills on dealing with real-world code (Refactoring and Working Effectively With Legacy Code being two of the biggies) and there are books that will teach you about other important aspects of development processes (such as Code Complete, Rapid Development, Design Patterns, The Pragmatic Programmer, etc. although those books are showing their age a bit these days) but none of those would be considered computer science textbooks.
Precious Little Sleep - New baby in the house. Seems to be good advice.
We are legion (We are Bob) - Finally broke down and listened to all the praise. It wasn't misspent. What fun!
The Emotional Craft of Fiction - Can never have enough writing advice
The Pragmatic Programmer (20th anniversary) - Again, relenting to the pressure to read classics
I'm away from my books right now, but here are the ones that come to mind:
Norvig, Paradigms of Artificial Intelligence Programming (I agree with plinkplonk and am quoted on Norvig's web site saying as much; a good book about all of {AI, Lisp, programming}).
Hunt and Thomas, The Pragmatic Programmer (no big surprises but lots of little insights and very little I disagree with; nicely written).
Bentley, Programming Pearls (absolutely superb for the sort of low-level algorithm-heavy stuff that, er, hardly anyone does any more).
Cormen/Leiserson/Rivest/Stein, Introduction to algorithms (best single-volume algorithms text I've seen, but not for the faint-hearted; might be well supplemented with Skiena's The algorithm design manual, a very different sort of book).
The individualists turn into hard bargainers as they carefully probe their own market value and frequently re-negotiate relationships. They carefully invest in keeping their skill-base current and avoiding being shunted into the sunset end of the ecosystem for as long as possible. This sort of developer likes to hedge bets, stay invested in multiple projects and keep one foot in the open source world at all times. They position themselves for massive upsides when that is a possibility, and the ability to walk away from failures with their own reputations intact where there is real risk.Full agreement on this point. Once I started looking at my own career from this perspective I couldn't stop. Books like The Passionate Programmer and The Pragmatic Programmer as well as heaps of prose from pg, patio11, edw519, and tptacek guide my continuing quest for increased leverage.
> It's also possible that purely language/framework books
That has been my experience. The best book club discussions (we do probably 10 different groups a year for 5+ years at this point) have been for books like The Pragmatic Programmer, Rework, Lean Startup, etc -- ones that focus more on a methodology or have room for discussion about trade-offs. Framework/language specific books tend towards the reference material side of things and don't have much room for discussion. One exception is the Seven Languages in Seven Weeks book -- we would work the exercises on our own and then meet together to discuss and share our solutions.
Glad to hear I'm not the only one with a copy of
The Pragmatic Programmer on its way to tatters as a result of chronic re-reading; I'd begun to think I wasn't getting out of it what I should be. I likewise recommend it to other programmers, new or otherwise.
I avoided The Passionate Programmer when it was called My Job Went To India, deterred by the title and lack of reader recommendation. Maybe I'll give it a look now. Somewhat related, I found Land The Tech Job You Love to be a comprehensive and insightful resource.
As beobab said, code, debug, feedback, rinse and repeat
Other resources that were helpful for me as well
Books:
- SICP (http://mitpress.mit.edu/sicp/full-text/book/book.html)
- The Pragmatic Programmer: From Journeyman to Master
Courses:
- Almost all udacity CS classes
- SaaS courses at edx.org
- Scala course and most CS courses in coursera
Open source:
- browse most popular OS projects on GH, and try to contribute
- create your own open source project, and get feedback / pull requests
Q&A sites:
- Stackoverflow
- http://codereview.stackexchange.com
and of course most coding related articles here on HN
edit: SICP has an online course at MIT OCW:
http://ocw.mit.edu/courses/electrical-engineering-and-comput...
it might cover a lot of things you know, but I think it's a must have for every developer out there.
1. Head First Design Patterns - Didn't learn patterns in school. This book made a lot of difference in communication with more experienced programmers.
2. Pragmatic Programmer - A classic, learned many practical tips for day to day programming job.
3. Founders at Work - Motivated me to work on my side projects and be constantly learning.
Most of their language books are pretty good -- Programming Erlang and Programming Clojure are both worth reading, if you're interested in either language.
It's disappointing that they don't discount The Pragmatic Programmer, as that's a book I wholeheartedly recommend to every working developer. I think that's still owned by Addison Wesley.
Solid list for any CS theory-thirsty minds :)
My mentoring CS professor's recommendations included these 5 books as well as the following:
* Pragmatic Programmer
* Gödel, Escher, Bach.
* Programmer Pearls
He also had a great deal of Computer Vision expertise/recommendations (his specialization / side job was as doing R&D for RED Cameras). Great professor, even better guy.
Current OMSCS student here. It's been a challenging, eye-opening experience, and I'm grateful to be a part of the program.
However, computer science and software development are not the same thing. If your primary goal is to up your game as a software developer, you might get more out of well-regarded software development books like "The Pragmatic Programmer," "Working Effectively with Legacy Code", or "Design Patterns."
Hope this helps.
My favourite quote from
The Pragmatic Programmer is this one.
"Text manipulation languages are to programming what routers are to woodworking. They are noisy , messy, and somewhat brute force. Make mistakes with them, and entire pieces can be ruined. Some people swear they have no place in the toolbox. But in the right hands, both routers and text manipulation languages can be incredibly powerful and versatile. You can quickly trim something into shape, make joints, and carve. Used properly, these tools have surprising finesse and subtlety. But they take time to master. "
Quoted from https://flylib.com/books/en/1.315.1.37/1/
This is a project management problem, not a problem with too smart developers.
The problematic activities described here, overgeneralization and solving imaginary problems (aka Coding for A Rainy Day), are simply typical newbie mistakes.
Otherwise highly competent developers almost always fall into this trap early in their careers, so the important thing is to have someone experienced in charge of the project who can veto their weirder ideas until they mature.
I think every software company should hand out a copy of "The Pragmatic Programmer" to all new hires. It gives much good advice on how to not overcomplicate things.
For the language and the framework the official tutorial/documentation are pretty good.
Also Pragmatic Programmers has very good books on both, written by the creators.
I love Phoenix but I will disagree with the OP in 2 points.
Yes probably Elixir/Phoenix will manage better thousands of concurrent connections, but if you are doing personal projects or are a start-up that condition is irrelevant in the meantime. So that only lefts us with the big established applications. That does not mean Phoenix is not good, it only means you will not notice a difference with Rails for most of your projects.
The second thing, that OP failed to mention is that the Rails ecosystem is at least an order of magnitude larger. From the gems available, job opportunities,developers available, instructional material, SOP for many tasks and so on.That is boring, but valuable.
Hmm. My picks would be very different, aside from '
The Pragmatic Programmer', which is worth reading early in your career.
Leo Brodie, 'Thinking Forth'
Roland, 'Program Construction'
Ullman, 'Elements of ML Programming'
De Marco, 'The Deadline'
Brooks, 'The Mythical Man-Month'
Skiena, 'The Algorithm Design Manual'
Hunt, 'The Pragmatic Programmer'
Stevens, 'Advanced Programming in the Unix Environment'
Stevens, 'TCP/IP Illustrated, Vol. 1'
Ross Anderson, 'Security Engineering'
Also, the Phoenix Project is a ripoff of Goldratt's 'The Goal.' I suggest reading Goldratt instead, and then think very carefully about what transfers from manufacturing to software.
Look up
The Pragmatic Programmer and Clean Code - they're decent books and I'm sure other people on HN have even better recommendations.
Also, you don't necessarily need to cover something completely in order to get started. And these will be useful mostly if your work is in some way part of a software product instead of being some "offline" analysis, model build or forecast. Just learning to use version control, to collaborate with other developers and to run tests goes a long way.
There's several good Clojure books. I'd start with Rich Hickey's video "Simple made Easy":
http://www.infoq.com/presentations/Simple-Made-Easy
The "Joy of Clojure" is the best book on understanding the mid and high level constructs and design of Clojure (and FP). It's not a beginner book though - for that the books from the Pragmatic Programmers or Oreilly are excellent.
That depends a lot on your current level and field. I myself am a junior frontend developer. I started from scratch through freeCodeCamp.org and I passionately recommend it to anyone to starting to learn to code.
If you passed that stage, I recommend the book The Pragmatic Programmer as a very good book on how to become a good software developer. The book Clean Code is a good starting point too.
Other than it depends on your circumstances. A good heuristic (particularly in frontend world) is to study the language, not frameworks.
I've been reading the Pragmatic Programmer and the copy I have is in black and white, and I've noticed the exact same thing.
That's sounds like example of someone with math skills applying them to make an awesome bit of code.
But I've also heard about math PhDs write the sloppiest code code imaginable: functions 1000+ lines long, copying and pasting functions to add a parameter... (in production code for a software company, not a research project).
So like you said, math helps but I'd like to extend that thought and say that you can make bigger gains elsewhere. For example, if you're a sloppy coder and don't know math, go out and get a book like "Code Complete," "The Pragmatic Programmer" or "Clean Code" first.
These three books helped me tremendously:
1. The Pragmatic Programmer by Andy Hunt and Dave Thomas
2. The Clean Coder by Robert Martin
3. Design Patterns: Elements of Reusable Object-Oriented Software (the "Gang of Four" book)
The first two contain a range of advice pertaining to working as a professional software engineer. The third one, although very dated, is still a great resource for understanding many of the design patterns used in OOP.
I'm a huge believer in going back to primary texts, and understanding where ideas came from. If you've liked a book, read the books it references (repeat). I also feel like book recommendations often oversample recent writings, which are probably great, but it's easy to forget about the generations of books that have come before that may be just as relevant today (The Mythical Man Month is a ready example). I approach the reading I do for fun the same way, Google a list of "classics" and check for things I haven't read.
My go to recommendations:
http://www.amazon.com/Structure-Scientific-Revolutions-50th-... - The Structure of Scientific Revolutions, Thomas Kuhn, (1996)
http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master... - The Pragmatic Programmer, Andrew Hunt and David Thomas (1999)
Things I've liked in the last 6 months:
http://www.amazon.com/How-Measure-Anything-Intangibles-Busin... - How to Measure Anything, Douglas Hubbard (2007)
http://www.amazon.com/Mythical-Man-Month-Software-Engineerin... - Mythical Man Month: Essays in Software Engineering, Frederick Brooks Jr. (1975, but get the 1995 version)
http://www.amazon.com/Good-Great-Some-Companies-Others/dp/00... - Good To Great, Jim Collins (2001)
Next on my reading list (and I'm really excited about it):
http://www.amazon.com/Best-Interface-No-brilliant-technology... - The Best Interface is No Interface, Golden Krishna (2015)
I am a huge fan of this book.
The Pragmatic Programmer and this book are the two that I recommend most.
When I first read Refactoring, IntelliJ wasn't released yet and refactorings still needed to be done by hand. Automated refactorings are so incredibly useful when it comes to improving code quality over time that I don't know what it was we did without them.
I'm also hoping to prune my reading list of redundancy.
Right now I've got:
- Design Patterns by the Gang of Four
- The DevOps Handbook by Gene Kim
- The Phoenix Project by Gene Kim
- Designing Data-intensive Applications - Martin Kleppmann
- Peopleware - Tom DeMarco
- Code Complete - Steve McConnell
- The Mythical Man Month - Frederick P Brooks Jr
- Growing Object-Oriented Software - Steve Freeman
- Domain Driven Design - Eric Evans
- The Clean Coder: A code of conduct - Robert C martin
- The Pragmatic Programmer - Andrew Hunt
- Building Evolutionary Architectures - Neal Ford
- The Design of Everyday Things - Don Norman
- Don't Make me think - Steve Krug
The funny thing is that it's nearly impossible to evaluate where you stand before you've reached the next level or even the level after that. You think your solution is clever? Wait 6 months and you think it stinks. You think you have a nice abstraction? Wait until you need to do something you didn't think of and you find it's useless/too complex/unnecessary and so on.
I find that the best way to evaluate yourself is to look at your code all the time and think critically. Be careful not to overdo it though, maybe take a closer look in between projects or in some interval is fine.
What should you work on? What do you find interesting? I think you're a lot better off working on something you find interesting than forcing you into something that you don't find thrilling. As always you should do stuff you're not comfortable with: do some low/high level stuff, try a new framework or do something you think is hard.
I wouldn't obsess too much on how good you are compared to others, there's always someone better, period.
Instead focus on your relative improvement. If you read your old code (which you should) you should think "this is awful, I could write something better" or at least "this is ok... but if I did it this way it would be much better".
And finally read code, read books about code, try to code with other people and try to make something useful.
Some book tips:
The Pragmatic Programmer:
Read this!
Introduction to Algorithms:
If you don't know algorithms, here's a nice book for it
Effective Java, Effective C++, More Effective C++:
Just good practices
I haven't found a good starting point. The two main contenders I've read in non sequential order:
1. Micheal Heartl's Rails Tutorial.
2. Pragmatic Programmers Bookshelf - Agile Rails 3.2 (4th Edition)
Both are a good start but delve far too much into unit testing with the horrific RSpec. When you're learning something new, you don't want to muddle with learning a DSL on top of things.
If a book on software is truly obsolete anytime shortly after publication, then the tech itself isn't truly stable.
Read "The C Programming Language", by Kernighan and and Ritchie. Written decades ago, still accurate and relevant today. "The Mythical Man-Month", "The Pragmatic Programmer", "Design Patterns"... books like this will always be relevant.
Maybe a good rule is to stick to CS books that have been in continuous print for at least ten years.
The Structure and Interperetation of Computer Programs will teach you to think more clearly about the fundamentals of computation and programming. A free PDF is here:
http://web.mit.edu/alexmv/6.S184/sicp.pdfIt is foundational though: you won't likely write lisp in real life.
Good books to read about practical software engineering are sold here:
https://pragprog.com/
I'd start with The Pragmatic Programmer.
By copy-pasting things, you've gotten yourself into a habit of just banging things until they work. Now, you should approach things from a scientific prospective: try to understand why they work, then write something to test that understanding. Build coherent and clear mental models.
I actually think that books which cover software engineering practices, rather than language specific books, have helped me the most. This is due to the fact that the concepts and principles you learn can be applied to many languages.
Two I've enjoyed are:
"The Pragmatic Programmer" by Andy Hunt and Dave Thomas
"Clean Architecture" by Robert C Martin
That being said, no harm in deep diving individual languages. Secrets of a JavaScript Ninja by John Resig was an excellent introduction to JavaScript!
1. "The Power of Habit" by Charles Duhigg. Gave me a better perspective on how to tackle my bad habits like endless watching YouTube after work, drinking too much coffee etc.
2. "The Power of Your Subconscious Mind" by Joseph Murphy. Sold me on the idea of positive thinking, but generally I found the book crappy.
3. "To Kill a Mockingbird" by Harper Lee. The only nover on the list. Definitely a good read.
4. "The Pragmatic Programmer". I fell in love with the idea of "the network" of views and controllers.
5. "The Software Craftsman" by Sandro Mancuso. Great one. Made me recosinder a few (quite a few!) things in my workflow and project.
6. "Deep Work" by Cal Newport. Amazing one. Can't wait for Monday to implement some at work. I even ordered 3 more copies for my team.
See also "The Power of Plain Text" in "The Pragmatic Programmer." Why people think binary formats are the be-all-end-all (or even the correct solution for the majority of problems) continues to confound me. But then again, I don't get NIH syndrome either, and many who insist that binary is better usually want to invent their own binary format.
You have quite overlap between some stuff. I would recommend "Clean Code", but then skip the rest from the same author, at least for a while. While "Code Complete" is good, it's loooong and also a lot of the same stuff.
For patterns, "Head First" is a bit childish maybe, but the content is fine for someone learning to recognize patterns. "Patterns of Enterprise..." is also good, but more dry. I'd stick with one of those two. And then skip the one by GoF, unless you want to read the "original" for some reason.
"The Pragmatic Programmer" is probably the book that has shaped my work the most.
1) Read (a lot) and absorb quality writing on software development. For example
Pragmatic Programmer, Code Complete, Designing Hard Software, SICP...
2) Create software (for about 10 years at least) for fun and profit. Assume others must read and understand your code. Write it for them. Also love the code you write. Find the beauty in solving problems elegantly and simply. You'll learn a lot.
3) Teach others how to create high-quality software, most especially focusing on "why". This keeps you thinking about what you're doing and leads to you finding ways to improve.
4) Listen and evaluate honestly when others criticize your choices. Maybe you did do it wrong or you don't have the whole picture. Have strong opinions, weakly held.
5) Repeat.
These aren't qualifications so much as guidelines for when people ask me how I got "so good." My title has been "Software Architect" for the last twelve years.
There's a lot more to it, naturally. Your biggest job as an architect is to extend the reach of the entire development team. Be it by writing libraries and frameworks for the project, mentoring developers, or creating designs and guidelines for developers to work within. Like a building architect, you are responsible for crafting and engineering the space in which people will live and work. For a software architect those people are the users, the developers, and the stakeholders. Your job is to strike the right balance between the three groups.
The reason you see so many posts in this thread deriding software architects is that as an industry we have largely forgotten what software architecture is. B-School and CIO Magazine have been selling executives on out-sourcing so that they don't have to "worry" about that kind of thing (and we're just now recovering from this). Capital "A" Agile came along and sold them another bill-of-goods that doing Scrum would fix all the issues.
For these and other reasons, the title basically came to mean "really good programmer" and was handed out as a simple promotion. But the real software architects are never just that. When doing their job properly, they become the foundation for excellent software development teams, and for excellent software.
Here are my three:
"Unwritten Laws of Engineering" https://www.amazon.com/dp/0791801624
Originally meant for mechanical engineers, it provides specific and general non-technical career advice. It focuses on what we call “soft” skills today. This field puts so much weight into technical prowess that we often think of these “soft” skills as somehow beneath the “hard” skills. Nothing could be further from the truth. If you don’t spend time on learning how to navigate your career, you’ll be as well off as a dragster on the backroads: you’ll get nowhere fast. I only wish I could have read this book sooner; it would’ve saved me a lot of trouble early on.
"Becoming a Technical Leader" https://www.amazon.com/dp/0932633021
Don’t let the title fool you: this is not just for people planning on becoming a “Tech Lead.” It’s for anyone in the tech field, period. If you pickup this book you must work through the exercises to get the full effect. It will be worth it. It’ll be like having your own therapist, life coach, and mentor, except that it’s just you and a notebook answering very important questions.
"The Pragmatic Programmer" https://www.amazon.com/dp/020161622X
I consider this book 10x better than Clean Code and Code Complete combined! (Though that may just be because I read PragProg first?) As the name suggests, this book provides more tactics advice but also gives great career advice too. The most famous is to “learn a new language each year.” This kind of advice seems a bit much, but over my career I’ve had to write in over a dozen different languages, even though 90% of the code I’ve written has been in just one language, the ability to pickup new languages quickly and easily is a solid skill to have. And that’s just one particular tip from this book.
(These are excerpts from my suggested reads blog post: https://valbaca.com/posts/my-suggested-reads-3cie)
For me, there have been more than one. I'll list them in the order I read them. I have them all in an eBook form to read in my Kindle App on my Nexus 7.
1) Clean Code
2)
Pragmatic Programmer3) Patterns for Enterprise Application Architecture
There's some overlap in contents, but I feel they complement each other very well.
As I was reading the post, I kept thinking that the nihilist sounds like they're following the recommendations set in "
The Pragmatic Programmer."
If you make decisions reversible or abstract away the interface from the implementation, you may be doing it for nihilistic reasons, but still a decent idea.
Also, "good enough" is underrated.
>>> One of the first rules in the marvelous book
The Pragmatic Programmer is "Select() isn't broken". Yeah, but sometimes it is.
How come you give this example just now? This can't be a coincidence. select() just caused us a major production outage.
FYI: select() is broken on pretty much all Linux kernels up to very recent ones. Doesn't work when there are more than 1024 opened file descriptors, not a lot for a server app. Side effects include crashing the application.
Foolishly, I don't really. I made the connection in some other thread on HN, and it's stuck with me. My advice is perhaps terrible: find yourself an old engineer and just do whatever it takes to be their friend and follow 'em like a puppy. It's sorta weird how effective it is to just be around people like that (and I think some PE licenses actually require apprenticeships for that reason).
But I do have two formative things:
Feynman's lecture on Cargo Cult Science is excellent, with this gem:
"The first principle is that you must not fool yourself--and you are the easiest person to fool. So you have to be very careful about that. After you've not fooled yourself, it's easy not to fool other scientists. You just have to be honest in a conventional way after that... I'm talking about a specific, extra type of integrity that is not lying, but bending over backwards to show how you're maybe wrong, that you ought to have when acting as a scientist. And this is our responsibility as scientists, certainly to other scientists, and I think to laymen." - Feynman [0]
I can't tell you how many times this has saved me in the field. Replace the word 'scientist' with '<YOUR DISCIPLINE HERE>' as needed. (And I think moreso for engineers than scientists, since safety absolutely requires this mentality.)
And I really like the ideas in The Pragmatic Programmer [1]. More than anything specific, the idea of not being married to any particular concept or solution, but rather to pragmatically chose what is correct then for that circumstance helps a lot. The book is opinionated, but reasonable, and copying that pleasant tone is a fast way to make allies when solving problems in a group. And it's a pretty good book to boot.
[0] http://neurotheory.columbia.edu/~ken/cargo_cult.html (and is an HN favorite, to be sure)
[1] https://pragprog.com/the-pragmatic-programmer (another HN favorite, though not always brought up in terms of engineering)
>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.)
Coincidently, I just started reading the "
The Pragmatic Programmer, 20th Anniversary Edition, 2nd Edition" on O'Reilly [1]. I read the original book many years ago and the second edition is completely updated and just as good. For those not familiar with the original, it's a refreshing take on programming as a craft as opposed to just "coding."
[1] https://learning.oreilly.com/library/view/the-pragmatic-prog...
For anyone seeing this, I tried to help Medium solve this coming from the other direction, which is to make it an over the top good value for HN readers to not only log in but also pay for the $5 subscription.
That's really what Medium aspires to be--a place worthy of a five dollar subscription.
Many people here probably end up on Medium repeatedly via Google search and yeah, the results are mixed. But also, it's worth noting that a lot of those results wouldn't exist at all without Medium paying and encouraging writers and editors.
What I hoped would start to take Medium over the top though was the addition of all of The Pragmatic Programmer books. That was paid for by other tech people who had already subscribed. (And I played a role in bringing them on board).
There's more coming. But overall, this is 100% Medium's direction and belief that a soft paywall is a better business and a bigger win for all parties than free & ad supported. So this paywall isn't going away, and it's really on them to do more to justify it.
Have you read the
Pragmatic Programmer? They talk about how to handle a situation like this. From what I remember it said to build a pocket of excellence in your dev workspace first, and then expose everyone else to it.
Set up the CI/build server on your machine, have it email everyone when the build fails. They will see the use of the tool then, and when the team accepts it they will hopefully get an official server to host it on.
Write tests for your code, and when other devs work with you on issues, or break things, write tests and send to them "Hey, i wrote this test that shows the code you wrote is failing, can you make it pass?" Also ask others to make unit tests. You will have to write the bulk of tests. You probably know which others on the team are open to writing tests and working with you on the pocket of excellence. Get them involved first, and then the idea will spread. A good idea would be buy them copies of Pragmatic Programmer too.
No, you aren't process oriented. A software team that doesn't at least like the idea of automated builds, and tests is crazy. As far as if it's a good place to work and improve one's skills? That depends. In some teams you might never get them to adopt the pocket of excellence. If you are working in a place like that, then it's probably not a good place to work. But if you have a shot at converting them by just doing it on your own first, then it would be a great opportunity to get experience with setting up these aspects of a software shop. And you can put that on your resume, blog about it, etc. In that case it would be a great experience.
Clean Code and The Pragmatic Programmer are both great books, but really your team needs to be doing code review on every line of code that is going to make it to production. It doesn't have to be /you/ reviewing all of it. As a bonus, having your team review each other's code builds more familiarity with the app(s) you are working on and allows all your team to learn from each other.
Another list (mine):
1-4: Books on computer organization, operating systems, networks and distributed systems (I like the ones by Tanenbaum, but there are many).
5: Another about compilers/languages (the dragon book is a classic, but there are many others).
6: Something about Lispy-languages (e.g. SICP, but the Little/Seasoned Schemer is another favorite).
7: A book about algorithms. I have Knuth, but something less thorough covering a wider area may be preferable.
8: A book about the practice of programming. My favorite is The Pragmatic Programmer.
9: A book about software engineering as a profession (I recommend Peopleware.)
Calm down. You are absolutely fine. It is not like you are a schoolteacher one month, a carpenter next and then a programmer the third month. You are exposing yourself to a breadth of knowledge within your field/domain, that is only fine, especially in the beginning. It is very common advice to do so, mentioned in the Pragmatic Programmer for instance.
If you don't consider yourself talented, but you make it a profession, you can make it work and become successful, but if you have the talent, and you aren't a professional, then there's nothing you can do and everything will end in failure.
I've learned that lesson the hard way I think. I read the Pragmatic Programmer early in my career but I don't think I understood it very well.
These are not specifically about structuring projects, but I would recommend two books for "thinking like a programmer".
The Pragmatic Programmer, by Dave Thomas and Andy Hunt, is a fairly slim book that aims to cover the unwritten knowledge that experienced programmers have. It came out a long time ago, but it's one of those timeless classics. If you can read this book and everything in it seems obvious, you are probably the equivalent of an intermediate-level software developer.
Similarly, Code Complete, by Steve McConnell, explains how to think like a project lead. In contrast to The Pragmatic Programmer, this is a large book: it aims to cover many concerns. Again, the less that you know, the more value that you will get from it: if you are starting with no training in programming, this book could be immensely valuable.
I'm not particularly sensitive to it, it has to be fairly pronounced before I'd even notice. This is.
It's one thing to say, I'd do it different. I'd have this book, or that book, or my list would have more this focus or that focus. It's a whole different beast to claim this list is "poor." And it is stupid to do so without countering with a list of exactly 5 books. Yes stupid.
I have read all 5 books. All 5 are excellent books. All 5 are very highly regarded in the field of programming and computer science. The descriptions that are attached to the list in TFA are accurate and useful to anyone reading the list. If there's a book on that list you haven't read, I'd say read it. This list simply isn't in the same postcode as "poor" and the descriptions of it as poor can't back it up in a meaningful way. Maybe there's another reason why the general mood of this thread is hypercritical? Smells a bit though, don't it? Do you really think if Guttag submitted that list the tone here would be the same or would the whole "this book is better" comments be rather more respectful of the original list and author? I've stated my opinion and why. You may of course, disagree.
Here's mine, Petzold "Code", Kernighan and Pike's "Practise of Programming", "The Pragmatic Programmer", Abelson and Sussman "Structure and Interpretation of Computer Programs" (with video lectures on youtube), Richard Stevens "Unix Network Programming" or maybe "Advanced Programming in the Unix Environment" - Which betray my OS accent. I'm not sure it's better than Ana Bell's. You can decide for yourself on that point.
The Pragmatic Programmer is one that I re-read every few years.
>One example, sometimes DRY'ing up things that just happen to use the same logic now, but don't existentially/necessarily use the same logic. When they stop using the same logic, you add extra 'magic flags', or you've got to undo the architecture.
The DRY principle was created by the authors of The Pragmatic Programmer, and as they formulated it, your example is not DRY.
DRY is about requirements, not code or logic. The specification of a requirement should exist in only one place in the code. It aims to reduce instances of "The requirement changed, and I thought I fixed all the places in the code, but I forgot one and it became a bug." If two pieces of code have very similar logic/code structure, but are tied to different features, then the DRY principle absolutely does not suggest you should refactor to make that logic appear in only one place.
Pretty much every time I've seen people complaining about DRY, they're complaining about something unrelated to the original DRY principle.
There's a whole bunch of technical skills that Universities didn't teach when I was there. I would recommend reading
The Pragmatic Programmers by David Thomas and Andrew Hunt to help with that.
Equally important are your soft skills. I would recommend reading The Hard Truth About Soft Skills: Workplace Lessons Smart People Wish They'd Learned Sooner by Peggy Klaus.
For software development - I favor books that are about good practices generally rather than books about particular languages which work well as references.
I usually recommend:
* Code Complete (Steve McConnell)
* The Pragmatic Programmer (Andrew Hunt and Dave Thomas)
* Clean Code and The Clean Coder (Robert Martin)
* The Mythical Man-Month (Fred Brooks)
* Test-Driven Development By Example (Kent Beck)
I also recommend blogs for more bite-sized knowledge. Jeff Atwood's blog at https://blog.codinghorror.com and Joel Spolsky's at https://www.joelonsoftware.com in particular have been helpful to me.
There has been plenty said about the topic. Have you read Clean Code? The Wikipedia page?
The Pragmatic Programmer? The depth on the subject has been expanded far more than just “single responsibility”.
Here is Bob responding to OPs link: http://blog.cleancoder.com/uncle-bob/2020/10/18/Solid-Releva...
Stating:
“SRP) The Single Responsibility Principle.
Gather together the things that change for the same reasons. Separate things that change for different reasons.”
That’s a pretty clear delineation IMO.
Yes, but if you pay the up-front cost of learning the interface (which, far from being arcane, is actually designed the way it is because it's ergonomic), then you can focus even more on creating than the person using the IDE. While they are stuck debugging some autocomplete error in Eclipse, you've already finished your code project, wrote a letter to your mom, dabbled in an interactive R sessions to teach yourself R, and played Tetris, all without touching the mouse.
IDEs exist for the same reason 7/11 exists. Convenience. You pay a higher price (lost productivity) to experience certain comforts (clicking a button instead of issuing a keystroke command).
My experience has universally been that IDEs only get in the way of focusing on creating. They might be necessary when you are literally just beginning with software and you need a lot of scaffolding to help you -- and I don't think anyone would begrudge university students using IDEs.
But not using a power editor once you are an experienced programmer is hard to understand. I mean, it's so important that it was even included as a whole chapter in The Pragmatic Programmer.
Paying the up-front costs of proficient editor usage is like paying the up-front costs of wearing braces so you can have straight teeth or wearing correcting shoes so you can walk properly. Of course it's more convenient in an absolute sense to simply not wear braces or corrective shoes. But that's not the point. The point is that the value you get from the outcome (e.g. straight teeth, proper walking, or dramatically increased productivity when developing) is far greater than the cost.
In other words, I think you're using a hyperbolic discount function. You are placing such a high value on absolutely immediate "focus on creating" that you incorrectly discount how much more focus on creating you would be able to do with the power of a real editor framework.
Fowler's writing is what makes the books so good: PoEAA is much more approachable than the GoF books. It's more approachable than his early books (Analysis Patterns).
I'm surprised that you didn't mention The Pragmatic Programmer..
I think that a lot of the people here (and who read your blog) could do worse than to check out "Team Geek". It's about people, not programming, but the impact it has had on me is equal to PoEAA..
I agree. I have been programming for many years, working in the industry for four years, and have always been interested in improving with clean code, testing and whatnot.
I read the Pragmatic Programmer last year, and it was .. very boring. Most of the tips were like "doh, of course". It's a beginner's book, not for someone who have been trying to improve their code (and processes around it) already for some years.
1. Learn to be criticised and to gain as much knowledge from that, as possible.
2. Learn to fail and feel good with that. And as above, to gain as much knowledge from that, as possible.
3. Learn to be confident enough to defend your solution.
4. Read as many non stricly technical books related to programming as possible. Ie. "The Pragmatic Programmer", "Rework", "Clean code", etc.
5. Don't take your job too serious. If you worry about your code after hours, stop! And if you can't, change your employer.
6. Everyone makes mistakes. Just try to not repeat them.
The WET criticism relates to not following the maxim of
https://en.wikipedia.org/wiki/Don%27t_repeat_yourselfThere have been some long threads here about other people's evolution as programmers and what kinds of things they felt helped them improve. I don't have one in mind right now, but maybe you could find one.
You could also try reading a couple of software engineering books that talk about some of these concepts. Wikipedia mentions The Pragmatic Programmer, and there's also Code Complete and others. (I haven't read either of those.)
Here's a list of the best "software engineering" books, although the focus of these is incredibly varied and some probably wouldn't be relevant to you.
http://noop.nl/2008/06/top-100-best-software-engineering-boo...
There was a nice approach described in the
Pragmatic Programmer book if I'm not mistaken.
The idea was to construct development teams in a way similar to the surgery teams - one lead developer, one assistant developer (these two "adult" and very good), and a 3-4 other people who
's job is to make the life easier for the main devs - someone to manage documentation, someone else to do detailed testing, one average dev to do the simple and boring stuff, and so on.
That way, in a company of a 100 devs, you'd need 15-30 super-smart developers (who don't need methodologies and scaffoldings), and the remaining 75 just junior/average specialists doing specific tasks and fitting into the structures provided by seniors.
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 looks like somebody has taken yet another stab at re-writing '
The Pragmatic Programmer' :-)
i don't think you've really leveled up until you get past using phrases like 'Level Up'. You're not a 14th level Ranger with a potion of strength and +4 leather armor. You're supposed to be an engineer ( or software developer or pick your favorite name ) helping real people solve real problems.
I heard about the
Pragmatic Programmer book. I guess it is now time to read it.
About CI server, it is on its way but only for production release. No continuous build for now mainly because there is no unit test infrastructure setup.
About writing test, well, no one uses unit-test for the reason above. It maybe a good time to introduce that and get to show them the light :)
"In some teams you might never get them to adopt the pocket of excellence. ". I am a bit afraid of that. Why ? I have spent some time trying to change things and yet I see little or no effort from others.
What are you thoughts on documenting things ?
Read "Code Complete". Read "Mythical Man Month." Maybe read "
The Pragmatic Programmer." If you're interested in learning more about testing, read "How Google Test Software." If you work on a lot of other people's code, read "Working Effectively with Legacy Code"
Good unit tests are absolutely crucial to any kind of future refactoring effort. They are helpful at finding regressions and give you some confidence that you do not break the paths that are tested. If you work in a team larger than one, code reviews are a must. Code reviews allow both participating parties the opportunity to learn, improve the overall codebase, and catch bugs. I also think writing code comments and documentation is absolutely important. Mostly so the "next guy" understands why the code is doing what it is doing. Most of the time the "next guy" ends up being you.
"Whenever I catch myself wondering whether this function I’m writing is going to crash or not, I remind myself to just run the tests or the app."
One lesson that often comes later in one's programming journey is that there are surprisingly, shockingly, many bugs that won't be found by just running the code. Like you're debugging one thing, and you find this other thing that has been in the shipped code for a year, intermittently causing crashes, but no one was the wiser. The "how could this possibly be working?" moment.
So, I fully embrace the idea of of incremental ground-up development, but running the code just to see if it crashes is too low a bar. Beginner versus craftsperson. I would suggest a high-value compromise is to single-step through any function that you just wrote. This has revealed a huge number of logic errors to me, even without writing additional tests. It's super low-hanging fruit that a lot of people don't even pick. I think that suggestion came from Code Complete, which although old, is still a great resource for beginning programmers. I also recommend The Pragmatic Programmer.
EDIT> Liked the article. Am also interested in standup. Also just recently had a very productive couple of evenings kit-bashing together some wood scraps where the tactile nature of holding a battery here, there, trying to orient it etc. seems to have been vastly more productive than sitting down with Solidworks or overthinking the early design.
Question to fellow coders:
Can anyone comment how, if at all, these books are different from classics in the field, such as The Practice of Programming, The Elements of Programming Style, The Pragmatic Programmer, or Complete Complete?
I can't think of anything new that another book on writing good code could say, that hasn't been said already.
That's why I haven't looked at these books yet. It feels to me these books are like another book about Newtonian mechanics, there just can't be anything new.
Thoughts?
You're starting at a tricky time. Rails 2.3 is still a great, stable platform and should be sticking around for quite some time.
Rails 3 does have many improvements, but it's still a "beta" in every sense of the word as many of the plugins don't work yet, or require many modifications to work.
I still think just about the best book/introduction to Rails is the Pragmatic Programmer book: http://pragprog.com/titles/rails3/agile-web-development-with... - They don't yet cover Rails 3 yet, but in the meantime you could fill in the gaps with weblog posts and the like. If you get a solid grip on 2.3, you should have no problem adjusting to 3.0 once it becomes final.
Too many =P But seriously, there are certain volumes I would never part with. For example:
The Pragmatic Programmer, SICP, Design Patterns, The C Programming Language. Tomes which are definitive and timeless.
I also have a few for purely nostalgic value, representative of key moments in my past. Notably: the OpenGL Red Book and C++ The Complete Reference.
In the past, students read the books in the college library, as it was the best way to find information about the topics they studied. Having their own copy was prohibitively expensive for anything more than the textbooks and maybe one or two books of required reading (this may be an experience in countries with free education, when you're borrowing several thousand a semester, another thousand for textbooks is probably less significant, but it was true in Ireland), and the only other source of information was the college's journal archive which was definitely not aimed at beginners.
Nowadays, most students have a library of pirated PDFs, meaning they have the information on hand where they need it and with no need to return it or find it already borrowed in the college library. Most colleges will give you access to online databases of journals, so they aren't a draw either.
The other problem encountered was that of QC. At least in my institution more substantial books were always in short supply, as they'd never have more than 5-6 copies of a single book, so you'd arrive at the computing section and find... "Java 2 for Dummies". Or "Teach yourself C++ in 24 hours". Books that might have been fine to self-learners (when they were not significantly outdated), but nothing that wouldn't be covered in a textbook and nothing more substantial.
Probably this is a disconnect between the people running the library and the lecturers, but the attitude of the library was "Yes, we have software development books. What do you mean 15 years is out of date? The psychology books have been there since the 70s. And our figures show that more students have taken out 'Java 2 for Dummies' than 'Design Patterns' or 'The Pragmatic Programmer', so we don't need more copies."
But those two factors, the greater accessibility of pirated PDFs and blogs (and for some of the slightly more recent students, Stack Overflow), and the lacking quality of what was probably available on the shelves at any given point you chose to look meant that the library was definitely way more useful as a study space than for the contents of the shelves for the other students and myself during my degree.
I recommend the book:
The pragmatic programmer. There's a section there explaining orthogonality by explaining a system that is not: a helicopter.
That example sticks with me.
Pragmatic Programmer is pretty good, but even better are Steve McConnell's books from the late 90's, "Rapid Development" and "Code Complete".
They're both big and both published by Microsoft. Two strikes, yes, but don't be fooled. These books have so many nuggets that I've gone back to again and again as a programmer. "Code Complete", in particular.
Neither book is a cover-to-cover read. They're both books you dip into for a tip, a skill, some perspective. But they've held up amazingly well, and for my money and time, they're both a step up from the Pragmatic Programmer. If you like what you found in "Pragmatic", you'll love "Code Complete".
I just wish it wasn't from MS, at the peak of MS evil in the 90's.
Does anyone know a good time in one's career to take time out and spend it on going through SICP and videos lectures with it?
I have a STEM (non-CS) degree but very recently, started working as a programmer. Doing my first internship at a 'techy' corporate company. One of the things I'd be doing on the side is to go through https://mitpress.mit.edu/books/elements-computing-systems. The video introduction to it just gives me goosebumps to this day. I don't know why. It's fascinating.
Than there is other paradigm books such as "pragmatic programmer", "Thinking Like A Programmer", "Design Patterns: Elements of Reusable Object-Oriented Software", etc.
So far, I've done plenty of reading on Algorithm & Design Structure and leetcode here and there. In the past, I didn't qualify for internship at Google, Amazon or M$ as a software developer/engineer. I feel the reason why I didn't was because I didn't have a "computer science" keyword mentioned anywhere on my resume. Hence, my hope is after getting through "Element of Computing System" & Design Pattern, I'll be able to shove in "computer science" keyword one way or another on my resume.
This has a own section in the book
The Pragmatic Programmer.
Chapter 3, Debugging, Rubber Ducking.
However, even if I agree with the great use I really use it more for code reviews than for actual hardcore debugging. (This could be my fault because I use distributed async processes in my work)
I think the rubber ducking has more advantage if you use a high level dynamic type language to code in (rather than more low-level C with pointers).
Thirding Code Complete (another top-level recommended it). I read that book very early on, and I credit it with my current ability to write clean code.
Another good one is The Pragmatic Programmer.
Lastly, this wiki is a gold mine of wisdom from hardened devs: http://wiki.c2.com/?StartingPoints
I really recommend you read lots and lots of those pages.
RE: Picking your axe
Your wish list is all over the place. It would help to pick one of the goals listed (i.e. Ruby, or Node, or Python) and hone in on that. Once you figure out what language you want to learn, devour everything on the topic from these sources:
* Peepcode tutorials
* Slideshare slideshows
* Youtube videos or other longform tutorials
Get a Hello World example running in your new language, and then see if you can get it wired up to a database. Congrats, now you're up and running...
It's not sexy or new, but the book the Pragmatic Programmer is the bible on how to become a good programmer and not just a hack.
RE: How to build a web app - read Getting Real by 37signals, this will give you a nice high level approach. This is also a great introduction to agile development principles.
"but I never really have an itch to scratch" sounds like you're not brainstorming hard enough. Even in your post there's the seeds of many different itches. Find the most basic thing you trip over every day, and write a tiny tiny software tool to fix that problem.
Last but not least, sounds like you could use some more experience with front-end concepts. I recommend Bulletproof Web Design by Dan Cederholm as a great overview.
Technology moves too fast for anybody to keep up, just do your best and always keep learning! Good luck
Highly recommend starting with "
The Pragmatic Programmer". I found "Clean Code" to be much more narrow in its applicability (and I did not enjoy Martin's writing, but that's highly subjective).
The Pragmatic Programmer serves as inspiration for me every time I read it. I know everything in it, but somehow I always come away with at least one "I could totally be solving my current problem with this!" insight from a re-reading.
I would say that the advice in
The Pragmatic Programmer is timeless, much like
The Mythical Man Month. A lot of the ideas presented there were later formalized into agile principles and practices, and are still quite relevant today.
Code Complete, on the other hand, is a little more hit-or-miss. Some parts of it are still very relevant, like how to write clear, readable code. But other parts have been supplanted by better practices. The book tends to lean more towards waterfall development approaches.
Find a problem that he is interested in fixing.
Use programming adjacent tools that he is familiar with or wants to play with. Excel, html, no code solutions. This should be a low time investment but will either get him hooked or deter him.
Read some core books like "The Pragmatic Programmer" about general skills.
Pick up a friendly book like https://www.railstutorial.org/ for web development. I'm sure there are other similar books for other types of development.
Slightly off topic but I love Adrian Coyler’s blog. Since I never pursued graduate studies in CS I never really got into reading research papers but would love to start reading some on my commute to work.
Does anyone have any recommendations for finding interesting papers? Do I need to buy subscriptions? Is there a list of “recommended” papers to read like we have with programming literature e.g. The Pragmatic Programmer?
One of the authors of "The Pragmatic Programmer" was also a woodworker.
I thing the big difference is that software is gradually becoming more declarative. It's less about coding how it does things, more about coding what it is doing. This has been the flow for many decades, but it's more common now than 5 years ago.
Something like React is the norm now. It's not necessarily any simpler or faster, but it's more efficient past N hours, which is the case for many larger companies.
It's also why functional programming has regained popularity, or at least writing functions the way you would for functional (immutable, output of one is the input of another).
However, we're still using a lot of old techniques. The best book on Design Patterns was written in 1997. Pragmatic Programmer was written in 1999 (though revisited a few years ago). The best TDD book is still from 2002; a lot of modern takes on TDD gets the philosophy completely wrong. TDD was meant to reduce fear, not improve test coverage.
> 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.
You don’t think the Pragmatic Programmer books are valuable?
I don't know, but some of the people I consider to be really good software developers seem to reference "
The Pragmatic Programmer" (perhaps even more than I realize do since I never read the book but have heard of "rubber duck debugging" & "DRY").
Generally, good software would have to be first defined and there's no universal definition. In most projects, I require it to have the following properties:
* New developers find it easy to ramp up on
* A handle on the defect rate (usually through adoption of best-practices like unit tests, fuzzers, automated tools, CI/CD, reproducible builds, etc).
* "Fires" infrequently enough relative to team size that it's manageable to accomplish your business goals.
* No "surprises" in adding new features/fix bugs where you didn't expect them.
* Meets business requirements today & can meet them tomorrow.
However, in other cases, like prototyping, "good software" means, "explores the problem space as quickly & cheaply as possible without worrying about any of those other things". Some of those other things can be useful in accomplishing this, especially if you plan to pivot from prototyping to the above definition. If you don't use them effectively then throw away your prototype before productionizing & start from scratch.
Ditto for both books, though I prefer The Effective Engineer to The Pragmatic Programmer. I found that quite a bit of the tactical advice in TPP is already standard practice (e.g. "always use source control"). Comparatively, TEE has more of an emphasis on project planning and team/company health, and I found that more useful for my work.
I read "
The Pragmatic Programmer" about two years back and back then I felt inspired and excited about all the wonderful ideas shown in the book. Fast forward to today, it seems that stuff was kinda obvious - automate things, read, take responsibility, care for the craft, be patient and the other forty tips.
I kind of believe that, have I not read the book, I would have stumbled upon the ideas later anyhow, by reading blogs, tinkering, and making mistakes. Albeit, it is wrong to expect any magical words that can shift your direction completely, but still I am not sure how much value do printed ideas provide vs learning them by experience. I am not implying that books like it are futile but I don't buy that they are "career-changing".
Same goes for reading about Design Patterns. I believe it is better to learn "Design Patterns" by building and reading code and finding a certain code organization better for your use-case, rather than enforcing a kung-fu-singleton-ninja pattern where it might be simply an over-engineering.
I didn't see any mention of in a quick look through the linked website, but the book "
The Pragmatic Programmer" is one of the best resources you'll find for making the most out of text-based tools. PP goes a little beyond that, too, it's not the book's sole focus, but it's a major one, and the book is a classic:
https://www.amazon.com/Pragmatic-Programmer-journey-mastery-...I read through Code Complete 2 cover to cover my first year and I agree with parent it's more useful early on than later. There's a lot of discussion around best practices; I think there's an entire chapter on strategic whitespace. All the stuff in there makes sense, but it cements
why it's important.
Definitely check out "The Pragmatic Programmer"! There's definitely some good nuggets in there that helped me. Distinguishing full-blown prototypes vs. prototypical kernels that can be productionized, a.k.a. tracer bullet prototyping, is one.
How so? I don't think anyone needs to get permission from Amazon. There are a few formats that are compatible with the Kindle. I've bought a few books from The Pragmatic Programmers and they offer a .mobi version that works on the Kindle.
Thanks everyone, the comments are much appreciated. Here's a list of books and other media resources recommended so far in the thread:
Robert C. Martin, Clean code: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...
Vaughn Vernon, various: https://vaughnvernon.co/?page_id=168
Steve McConnell, Code Complete: https://www.amazon.com/Code-Complete-Practical-Handbook-Cons... 2
Clean coder: https://cleancoders.com/ videos
Hunt and Thomas, The Pragmatic Programmer: https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...
Hitchhiker's Guide to Python: https://docs.python-guide.org/
Dustin Boswell The Art of Readable Code: https://www.amazon.com/Art-Readable-Code-Practical-Technique...
John Ousterhout, A Philosophy of Software Design: https://www.amazon.com/Philosophy-Software-Design-John-Ouste... This one looks particularly interesting, thanks AlexCoventry!
Kent Beck, Test Driven Development: https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...
Dan Bader, Python Tricks: The Book: https://dbader.org/
Ian Sommerville, Software Engineering: https://www.amazon.com/Software-Engineering-10th-Ian-Sommerv...
Svilen Dobrev, various: http://www.svilendobrev.com/rabota/
That's by Andy Hunt, one of the Pragmatic Programming authors. Pragmatic Programmer, as a publisher, has produced dozens of books. They're like another O'Reilly.
This are called Tracer Bullets in the book "
The Pragmatic Programmer" by Andrew Hunt and Dave Thomas. They advocate:
Users get to see something early on.
Developers build a structure to work in.
You have an integration platform.
You have something to demonstrate.
You have a better feel for progress.
As a solo founder I need working code, that I can put out of mind, while I produce more.
Your point about key bindings is very prescient.
At my work, our book club is (re)reading The Pragmatic Programmer. There's a section which advocates picking one text editor, mastering its arcane secrets, customizing it until it's perfect, and never using anything else. All my colleagues happily agreed with this, and I couldn't quite express why I didn't.
Then I did a bit of pair programming with a few different people. In every case there was a significant learning curve just to follow what the driver was doing in their comfortable editing environment, and in the most customized cases, it was nigh impossible for me to drive at all.
So we relocated to my desk instead. I have a standard qwerty keyboard with vim, emacs, and textmate - all completely un-customized and ready to go. I couldn't care less which editor we use as I've learnt the bare minimum to be proficient in all of them. And importantly, so have my colleagues. Sure they grumble at not having their own autocompleting magic, but we can get our work done at a good enough rate, and either of us can drive.
(My previous work took this one (enterprise management style) step further and forced everyone to use the exact same model laptop, operating system, and editor. As a youngster I hated this required conformity. As a cynical old bastard I can see the logic...)
I definitely sit in the middle of the two camps. Not 'The Best', not 'The Worst'; just 'The Satisficing'.
[1] https://en.wikipedia.org/wiki/Satisficing
From its preface: "This book has only one major purpose - to trigger the beginning of a new field of study: computer programming as a human activity, or, in short, the psychology of computer programming."
Still a worthy topic, still worth your time. As was mentioned about 'The Pragmatic Programmer', I think reading this works best once you have a few years of experience.
There is a great chapter in
The Pragmatic Programmer on why you should stick with text files for everything possible. Section 3 / Chapter 14 "The Power of Plain Text".
It argues that as programmers, our base material as craftspeople isn't wood or metal, but knowledge, and with plain text we have the ability to manipulate knowledge with virtually every tool at our disposal.
http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master...
This blog post doesn't express things nearly so well as the book, but the argument has validity.
I guess you just need some mentoring to get some skills/structure. Difference between hacking and engineering is the "structure:. I can't find the right word in english, I would say "rigueur" in French.
Any if you can't find mentoring at your current position, try some books. My first mentors were Andrew Hunt (The Pragmatic Programmer) and Martin Fowler. Start with them, or find your own.
Code mindfully, go deep to understand every little detail of the code you write or read. Ask questions. A lot. Don't stop at the first draft. Don't stop a the first pass of questions.
Keep at it for a while. That one day you'll wake up with the feeling that the code you write yesterday was good. And hell if it's not a beautiful day to make it even better!
Get some CS background if you feel you miss it. https://teachyourselfcs.com/ gets one Hacker News every now and then.
Work on architecture/design. Try to understand design patterns for example. Be critical. Try to understand architectural decisions of the code you read.
Don't understimate the efficiency that comes with really being fluent with a language but do not give fluency too much credit either.
This is a lifetime journey. Improve step by step, little by little, every day. But improve mindfully. Get a direction. Get learning goals.
It's not a "try harder" it's juste question of better orienting the energy maybe.
That's my 2cents.
Good luck, I'm sur you can get, better you just need guidance.
Anytime I'm going to poke into a topic I like to nab one of the Head First books. They're a fast, easy way to learn a topic and after I'm done with it and into it deeply I'll find a dry reference.
The Pragmatic Programmer
Meta-programming at it's finest. Be a better programmer.
Joel on software blog:
Here's an example post.
http://www.joelonsoftware.com/articles/fog0000000043.html
There's quite a bit to learn in there.
Many other books available free online. Primarily I suggest you read to an end, and as you get to a stagnation point you alternate between reading to learn new technologies or languages and reading to improve yourself as a programmer.
"Pragmatic Thinking and Learning" was Andy Hunt, but as he and Dave Thomas are kind of a double act I can see why you'd get mixed up.
As to your point about whether they wrote any books on 'agile' I think it could be argued either way. More specifically, whether or not "The Pragmatic Programmer" (the book they made their name with) counts as a book about 'agile' is an interesting question, and one that throws some light on the wider debate.
Although they sometimes talk about "pragmatic programming" as if it were a thing, in the same way as XP and Scrum, their approach was more one of giving a smorgasbord of potentially useful techniques and practices rather than codifying a tightly defined set of best practices.
Serendipitous, as I'm planning on doing a lightning talk on ST2 tonight.
Editors seem to raise a lot of religious issues, and not to totally discount the distinctions that can be made between them, but I think it's more important to know your editor well than to worry about "the best editor." (If such a thing exists.) As Hunt & Thomas say in The Pragmatic Programmer: "use a single editor well."[1] You'll be most productive if you learn your editor from head to toe, than if you half-assedly know several. That takes some effort and conscious practice, sitting down and memorizing key combinations and the like. And a cursory glance at any editor might leave you unimpressed until you've gotten somewhat fluent with its features.
Just a couple of suggestions if you do use ST2:
+ get package control: http://wbond.net/sublime_packages/package_control/installati...
+ For rails, a couple of nice packages are RubyTest and SimpleRailsNav
+ Learn the multi-edit commands
+ Familiarize yourself with cmd-P/ctrl-P (osx/win)
+ Keyboard shortcuts: WIN: https://gist.github.com/1925069 OSX: https://gist.github.com/1207002, or look at Default (OS).sublime-keymap
[1] I would amend that to add "and also know vim at least a little" for stuff like sshing in to servers and whatnot.
'The Pragmatic Programmer', Hunt and Thomas
Read
The Pragmatic Programmer, then Code Complete 2. These books will help you approach problems and people. Most important thing I've learned is to write code other people can read. A lot of times that person can be future you.
Learn design patterns, approaches to getting requirements, and how to read/create diagrams.
Learn how to write unit tests.
Learn source control tools and how to use them. If it's a command line, know how to do this from the command line.
Learn best practices for your language and get really good at your editor/IDE. (For instance, I use VIM with syntastic and pylint to check PEP8 compliance).
Learn to type quickly and accurately. This helps with everything.
If you've done those, enjoy your Summer! It's the last one you'll ever have :).
Some other things that would be fun:
- Set up a Docker image
- Write a REST API server in Python on a Linux OS
- Build in authentication, authorization, documentation
- Have Docker build and run your REST API server
- Set up a load balancer container to distribute load between multiple Docker containers
- Set up a shared cache like Redis or Memcache with containers
- Set up a MySQL Database
- Write unit tests for API
- Have Docker container automatically build, test, and deploy when you check in code
That will bring up a lot of questions of how you design things and how everything is tied together. Maybe you will just be working on a small part of this, but then you might know why things are done a certain way or how to do them better. That's where you can make a difference and distinguish yourself. You can bring a fresh perspective. Don't take anything for granted. Ask questions when they need to be asked. Learn how things can be improved.
Personal preference I guess.
I reread Pragmatic Programmer every year.
The other two you mention I find pretty poor, to be honest. I may reference them once in a while, but to really understand the topics they cover I'll rely on a well written, colorful article over those books.
In general I've found books written by more than 2 authors to be quite boring, impersonal, and oftentimes misleading.
Code Complete and Pragmatic Programmer are two of my favorites alongside C, and the Practice of Programming.
It has taken me considerably longer than a year. But I might not be smart. And I've tried to do it on my own, rather than taking a job (see prior sentence).
Caveat: I'm not a developer, so my comments about learning how to program should be taken with considerable skepticism. But I have some opinions based my effort to learn.
For me, programming syntax is less a problem for me than poorly organized code, poor grasp of problems and poorly thought out solutions. Design is a subtle and important topic that does not lend itself to the shorter coverage typical of internet material. Book-length immersion in the concepts is only a beginning to an understanding. So I think your "internet only" restriction is a severe constraint.
But it isn't as if there are many design books for beginners. These generally target people who've mastered some languages and know the design-problem space. "Pragmatic Programmer" was a big help.
I have found test-driven development an enormous help. It feels cumbersome, but you always know what problem you're trying to solve. "Test Driven JavaScript Development", Johansen, is an excellent overview of the approach. I'm also trying to work through Beck's "Test Driven Development By Example" doing the exercises in Ruby, but it's a side project that hasn't gotten much attention.
I repeat: I'm not a developer. Hopefully this is thought-provoking, but I'm no authority.
It sounds to me like you haven't internalized a lot of the advice in the first half of "Clean Code" and/or the entirety of "
The Pragmatic Programmer". Either of those books takes a few weeks to read slowly and a few months-to-years of deliberate practice to internalize and synthesize as your own. The good news is that admitting you have a problem is the first step.
Personally I find I still frequently write pretty atrocious code on the first draft, and it's only by stepping back from the problem after demonstrating to myself I understand it well enough to solve it at all that I can begin to write a more graceful solution. But deadlines and reality being what they are, I think the majority of us are embarrassed by our past code a majority of the time.
So don't be too hard on yourself, but also frankly don't worry about shoe-horning yourself into "A Career" either. They're kind of a recent invention and the whole concept might need a few more iterations. You could spend a few years as a Product Manager, an Engineering Manager, a Highschool Teacher, or a Business Analyst, leveraging your past experience to gain competency in a new niche.
I want to emphasize of self-awareness you have is commendable and not universally present: If you can realistically assess your own current skill level and then apply yourself to improving, you could be an above average software engineer before you know it. And right now it seems like so so many companies just can't get enough software engineers, so it's a pretty safe place to practice learning how to learn while also earning a decent income.
I have written a book and have a blog on this topic. Primarily focused on "soft skills" (I think they're pretty hard) because that's what I wanted to write about.
https://letterstoanewdeveloper.com/
There are some other books covering similar ground.
From my book proposal and other research, here's a set of books/sites I'd recommend:
* https://medium.com/basecs
* New Programmer’s Survival Manual: https://pragprog.com/book/jcdeg/new-programmer-s-survival-manual
* Your First Year in Code: https://leanpub.com/firstyearincode
* Code Complete (long and some parts aren't very modern, but very in depth)
* The Pragmatic Programmer
* Don't Make Me Think
* Badass: https://boingboing.net/2015/02/27/kathy-sierras-badass-how-to.html
* The core docs of whatever language you are using (don't underestimate the power of understanding the core libraries!)
I'll be interested to see what else is suggested here.
Don't let the title fool you - 90% of the advice given in this book isn't specific to Clojure, and boy is it good advice.
This book contains some of the deepest programming insights I've encountered, to be put on the same level as SICP or the Pragmatic Programmer.
The discussions on naming and abstraction are particularly illuminating, exposing some fundamental tradeoffs like synthetic vs natural names, or principled vs adaptable systems of abstractions. Were these notions more widespread, a lot of the pointless rants and debates we hear in programming circles would disappear.
I would not recommend this book to beginners - this book is most useful when you are experienced enough that your struggle is to make choices, not to get things to work.
To the contrary, some of the best books have so much knowledge in them that you instantly level-up many notches with a single chapter.
For instance, reading The Pragmatic Programmer and JavaScript: The Good Parts early-on changed my professional life irrevocably, both in terms of programming and career.
I am sure there are various other books like those that truly are impactful, and it doesn't hurt to look up recommendations for those from people who are experts / polymaths.
The case against wikis (with the exception of design docs) and blog posts is that they are erratic, restricted, unedited, stale, and low on pedagogical focus. Some of the books are meticulously structured-- there's no comparison.
I remember reading this here a while back - wonder what happened:
https://neil.fraser.name/news/2015/04/13/But like others in this post I would recommend CS unplugged.
And depending on how long he is in there for he might want to look at:
How to Design Programs - This is a good book, and although it's in Scheme, it teaches how to create appropriate levels of abstraction, which seems to be something many programmers struggle with.
Concepts, Techniques & Models of Computer Programs - Discusses the different paradigms and how they are inter-related.
Also something a bit more vocational like The Pragmatic Programmer or Clean Code / Clean Coder probably wouldn't hurt either.
If he can read all of those he will be very well prepared to do some actual programming when he gets out.
SICP not a bad shout either, although I've not got past the first chapter.
Has there been ANY programs written in lisp that has risen to the status of anything more than novelty?
IBM's watson, the best thing we got going for artificial intelligence, is it written in lisp? NO, it's written in java. The link from lisp to artificial intelligence is a lie. Lisp is just a very poor language, it's designed to get eager novices working on things that are irrelevant so they will learn (the hard way) that being a good programmer means laughing at the people who promote lisp as "an epic language". Lisp had its day, somewhere back in the 1950's/1960's. That day is gone.
If I'm working on any sort of problem needing a programming solution, and someone suggests we use lisp, I buy that person a copy of "The pragmatic Programmer", and tell them to read it closely.
I think this is what Andrew Hunt and David Thomas meant when they said "program _into_ a language" as opposed to "program in a language" in their book The Pragmatic Programmer.
The Pragmatic Programmer, Dave Thomas, Andy Hunt
Fooled by Randomness, Taleb
Linchpin, Seth Godin
I totally agree. Code Complete was my road map to a new field, full of recommendations for other books to read. I gave away my first two copies of the first edition, and eventually bought the second edition. It didn't have the same magic. I've looked for it in other books, like The Pragmatic Programmer, The Practice of Programming, and others, but it's like The Sixth Sense (or The Crying Game or The Usual Suspects): you can only see it for the first time once.
The first edition suffers from being a victim of its own success. Much of it has become common wisdom and many of the refactoring techniques now have IDE support.
"Working Effectively with Legacy Code"^1 is usually what I recommend instead. It felt like a more up to date approach
More generally "The Pragmatic Programmer"^2 is a classic for a reason. But from you're comment you've probably already read it.
1. https://amzn.to/2I4rIWP
2. https://amzn.to/2GfxVTa
2.
Exactly. Perl 6 was forever delayed, and along came Ruby. Or rather, out from the shadows came Ruby, which was already there before the Perl 6 debacle, and just needed promotion.
The Pragmatic Programmer books were pretty good at pointing to this cool replacement for Perl that you never knew was already there (as well as all the buzz from the RoR folks for those of us who weren't in on the beginning)
I don't really think that the people who left perl all went to PHP.
Now if only there was a "Ruby lite" that ran more like Perl 5 (skipping the GC for reference counting and a few other performance shortcuts)
The Pragmatic Programmer book talked about creating a solutions log, which can be consulted at a later time.
To date, I have only dabbled in a few Scala scripts on top of an existing Java code base. I found it straight-forward for that job (albeit a small job). I found the "scaladoc" to be a bit sparse, but otherwise navigable. I mostly like the Scala book that
the Pragmatic Programmers published (forgot author's name), other than the slow intro.
I'm sure my use of Scala would disappoint the first interviewee, but it was an effective use-case for me. Use the index on the book to scan for likely topics, then round things out with Google.
I found the IDE support a bit broken in NetBeans (6.9). I suspect that the Scala plugin was incompatible with my vi/vim plugin, but I'm not sure. (it would go into a mode where the editing keys would stop working)
I was until recently one of those people who insisted on finishing any book (or movie or TV show, for that matter) they started. Otherwise, I wouldn't feel
closure. I dropped a few books (
Lolita,
The Pragmatic Programmer,
Kitchen Confidential etc.) but kept feeling guilty later on. I am glad to hear from so many people here that dropping in between isn't such a bad thing after all.
Related question: do you guys have a similar system for research papers? I've tried reading them a lot but have successfully made it through only a few. At this point, I even question if the effort in getting through their drudgery is worth it.
Short answer: No, but your best bet might be to read old, substantial books, and find other work by the kind of people who read and wrote those books before they were old.
Longer answer: Basically, you need to get away from the world of front-end web development, and from the echo chamber blog posts and conference talks by people who have only ever worked in that area. No-one is writing anything large, high-performance, high-reliability or long-lived there yet, so you need to look for experience from people who have had to do those things in other contexts instead.
Classic books like Code Complete and The Pragmatic Programmer, early "serious OO" books like Design Patterns, and practical advice books of a similar generation in the Effective <programming language> style all contain a wealth of knowledge and insightful commentary. Of course some of the technical details are quite dated today and some of the specific techniques discussed might no longer be considered good practice a decade or two later, but many of the underlying principles and the discussions around them are as relevant as ever. A bit more recently, there were interesting discussions about a broad range of programming issues in Beautiful Code and the related titles, and there have been some interesting case studies based on open source software too.
If you want to read some shorter pieces online, I recommend finding a few authors who work in fields like games or embedded software, where there are often significant performance and reliability constraints to deal with, not to mention hard deadlines that force difficult decisions and compromises. There are some healthy doses of reality in there that you won't find in less demanding environments.
Enterprise applications, while often considered bland, can also be large and some of the longest-lived software we develop, and much has been written about organising and maintaining them, including real-world pressures like changing operating environments and large development teams whose members come and go. Perhaps a little ironically, this now includes a fair bit of back-end web development. Some of the writing around this is well worth a read as well, but beware that this part of the industry is plagued by consultants who talk a good talk but don't have much of a track record or other evidence to back up their advice. Approach with caution, particularly anyone who uses words like "agile", "lean", "craftsmanship" and anything else on the buzzword scale.
I agree that
the Pragmatic Programmer is well done in it's audio form, and I also agree that Grokking Algorithms is terrible.
I am currently listening Designing Data Intensive Applications and it's phenomenally done - the author clearly worked with the narrator to adapt the content to audio format, and the narrator seems to have experience or familiarity with the subject because he pronounces the technical jargon very naturally.
I hope to find other software related audiobooks as good as DDAI is.
Everyone's said this, I'll say it too: Awesome!
I fell into programming by accident at about 21, and I remember what it was like, it's much as you described. Fun times!
All the advice here is good, but nobody has recommended you read "The Pragmatic Programmer", which I found to be a bit enlightening. I still go back to it years later to read and ponder.
Good luck! You sound like you wont need it. It's a damn good career for those who enjoy it and are willing to put in some effort.
EDIT: I never did a CS degree, but considered doing it many times (if work dried up, it never did). I believe though that the people you meet and work with is a major part of doing a degree, so that'd be why I would go. I get to work with good people anyway. This article was posted on HN recently and I think is relevant:
http://sheddingbikes.com/posts/1275258018.html
I admit there are CS-type stuff I can't do (but I know where and who to ask) because I never did a degree. Saying that though, I have worked with people who have had CS degrees and couldn't code themselves out of a paper bag. If I were to go back in time to when I was your age, I'd do the degree, though.
"SELECT" isn't broken. (h/t
The Pragmatic Programmer, by Hunt and Thomas) Junior programmers will sometimes think the problems they encounter are the fault of bugs in well-tested system software, rather than their own code. (1)
The implementers of the legacy code aren't stupid. It's very common for junior programmers, tossed into the swamp of some codebase that's been around for years through many different hands, think the code is junk and the original implementers were fools. Usually, it's just that the problem is much more complicated than the juniors understand, and that's how the code got that way.
New tools probably won't solve the problem. There's a tendency with junior programmers to whine about the antique tools in use, convinced that the new Foobaz framework or Language X will magically clear up the issues they encounter. But the problems with code usually aren't from the tools used to build the code - they're from failure to understand the requirements, and time/scope/resource constraints on development.
Perfect isn't as important as finished. It's easy to get caught up in perfectionism. It's a good excuse to avoid releasing something you find embarrassing into the world. But the more time you squander polishing that turd, the less time you have for the next tur... er, cool new project.
If you can't write a test for it, you don't understand it well enough. Writing good tests is hard. It's easy to fall into a trap of "That's too hard to test. I'll just sort of check manually to make sure it works". This will bite you in the ass later!
(1) My first really good bug as a junior programmer actually was a "SELECT is broken" kind of problem (technically, mmap() was broken). I went to a great deal of effort to prove to the senior programmers (and then IBM) that my code was actually correct and I had an OS bug. And if some junior programmer came to me today and said a deep system call like mmap() was broken, I'd laugh at her and tell her to check her code. So sometimes, SELECT actually is broken - just not as often as junior programmers think.
I disagree with this. I read every software engineering book I could get my hands on when I was in school - GoF, Refactoring, SICP,
Pragmatic Programmer, XP Explained, Implementation of Functional Programming Languages, TAPL, Basic Category Theory, On Lisp, Art of the Metaobject Protocol, numerous textbooks I wasn't assigned. As a result, my code ended up overcomplicated, with a bunch of cool algorithms, a lot of OO design, a nice smattering of patterns...but relatively few useful solutions for people. It was only when I was like "Alright, I've already read every book anyone I've met has ever mentioned...I need to push through and actually finish a project now" that my skills started shooting up.
Write code first. Write code until your programs collapse under their own weight. Then go out and read what the masters have written. You'll understand it much better when you have personally faced the problems that they were facing.
I'll suggest
The Pragmatic Programmer by Hunt and Thomas. Basic stuff, but lives up to the title of being "pragmatic".
If you're going to write commercial software for a living, it's useful stuff to know (or be reminded of).
Having to assume a timeframe, I do not think you have actually learned the languages. It usually takes years to be really good with one. That is not to say you have learned nothing (exposure to many paradigms is good), but that it takes a lot of effort, may be confusing and that you would probably be better-served by concentrating on one or two and working on actually programming first. The dual nature of languages is that they are nontrivial (at the "mastery" level) and they can profoundly affect how you program but that at the same the specific one you end up using is kind of immaterial to programming which is to say composing logic into a functioning program.
All of that is a long-winded way of introducing the suggestion that you learn to program by programming. The second-best is understanding others' programs (select well-respected, progressively larger codebases). Books, suggestions of which I hope others will provide, may give you some good ideas and thought patterns. "Software design" is a vast field with tons of completely obsolete advice, and terrible amounts of overengineering. Perhaps something like an agile workflow book, "The Pragmatic Programmer" once you can construct programs.
Can you please call out which books are bad though? That's some very useful information. I know I've read books that were garbage that are very highly recommended. (Code Complete as a "guide to the craft of programming", for example is extremely poor when compared to The Pragmatic Programmer). And even if I disagree with your judgements in some cases, it's good for calibration.
The Pragmatic Programmer by Andrew Hunt and David Thomas
I love Erlang so much I haven't yet gotten around to learning another functional language. (still growing with erlang).
I learned it reading Armstrong's book from Pragmatic Programmers. It was a joy. I'm also reading the OReilly book, and it seems good as well, though I can't tell how it would be if I didn't know the language already. As for the titles-- one is Programming Erlang, and the other is Erlang Programming!
"The Pragmatic Programmer" by Andy Hunt and Dave Thomas
Pragmatic Programmer (importance of plain text) and How to Solve it (set of logical steps to get to grips with an otherwise overwhelming problem / situation).
Applying Domain-Driven Design and Patterns was the book that made me fall in love with software engineering. Perhaps a little dated now though.
Head First Design Patterns - I never grokked any of the patterns from the GoF book, but this one 'clicked' for me, if you can get past the cutesy presentation.
Peopleware - Shows importance of focusing on people, rather than the tech, as this is often the main cause of project failure in the software realm (and perhaps others).
I loved reading Steve McConnell's books when I was starting out, especially Code Complete and I feel that book made me a better programmer.
Having read it a few times since I think it falls into the same group of books as Mythical Man Month, Peopleware, and the Pragmatic Programmer where the earlier in your career you read it, the more you'll get from it.
Reading these books after 20 years of programming I found that I really struggled to find anything useful to take away from them.
It's not that these books are bad, or out of date. It's more that they exposed some new ideas at the time that, to the books credit, have been picked up and made mainstream or basic/required knowledge for the working programmer
As a long time Medium author and publisher and occasional business partner I have all kinds of feelings.
But the main one is about the need for urgency.
One basic way to read these changes is that it just looks like Medium getting savvier about what drives and grows their subscription business. There's been no pivot there. The challenge for them still is to get their subscription business over the hump.
And the hump they have been at for awhile is that the subscription has been growing despite being generally meh quality. It's just $5 and a lot of people like supporting authors that way. But what are the ways to go from meh to great?
What I think Medium found is that they were getting better value by spending in other places. For example, I was part of bringing the back catalog of The Pragmatic Programmers books onto Medium. That was a deal that was relatively economical and had a direct hypothesis related to growing the subscription. For programmers now, at least, they have a nice headline for why a programmer would spend $5.
So to see Medium focus more on what's working to actually tip the subscription over puts me at ease because I still see the company has being in a zero to one situation. It could succeed, but it hasn't yet.
Syntopic reading can be really rewarding. For example, once you read Thinking Fast and Slow, and a few of Taleb’s books, suddenly you notice implicit and explicit references in virtually every business book published later than those.
A similar effect can be found with Grit, Fogg’s Behavior Model, Superforecasting, and most Gladwel books.
On the coding side, I’ve only noticed this with Pragmatic Programmer, Clean Code, and maybe Phoenix/Unicorn project. Could I don’t read enough of those or they’re too focused on specific technologies instead of broad ideas … or I get too much of my technical reading from blogs and twitter. Those do get repetitive and you quickly find common patterns, but no titles to refer to.
I thought about posting this here after a relative success asking the question on Reddit:
http://www.reddit.com/info/6mikl/comments/
but it looks like you've beaten me to it!
I did create a listing of the most popular books mentioned on the comment thread, if you're interested. The following were mentioned by 4 or more people:
14 The C Programming Language
11 Structure and Interpretation of Computer Programs
8 Introduction to Algorithms
7 Compilers: Principles, Techniques and Tools
6 Programming Erlang
5 The Mythical Man-Month
5 The Pragmatic Programmer
5 Applied Cryptography
4 Beautiful Code
4 The Little Schemer
4 Programming Perl
more here: http://www.reddit.com/info/6mikl/comments/c04abpy
To be accurate it is published by
The Pragmatic Programmers, not written by them as the title kind of imples.
Maik Schmidt is the author of this book.
> Maik Schmidt has worked as a software developer for nearly 20 years and makes a living creating complex solutions for large enterprises. Outside his day job, he writes book reviews and articles for computer science magazines. He is the author of Arduino: A Quick-Start Guide, Enterprise Recipes with Ruby and Rails, and Enterprise Integration with Ruby for Pragmatic Bookshelf.
The Pragmatic Programmer.
My suggestion: don't read another book until you've read this.
Your experience mirrors mine exactly: we would go broke if we had to buy all of the picture books we checked out for our kids (sometimes on the order of 20/week). And for myself, the inter-library loan has been incredibly useful (especially for recent popular science titles).
I also appreciate being able to browse the small selection of fiction/non-fiction at our local branch. As with the bookstore, I often pick up things I wouldn't dream of searching for online and would therefore never have found.
I likewise wish my library system had more of a "long tail" stored somewhere.[1] Older books (no matter how popular and well-known they were at one time) are often simply not available.
I had practically written off libraries when I was in my 20s:
* The hours didn't mesh well with my work schedule
* I could afford to buy whatever I was interested in
* They never had the up-to-date programming books I wanted/needed
That has changed completely now that I'm a parent. And yes, I do think libraries need books. Communities need books. This stuff needs to be available, even if just in principle.
I was skeptical but surprised to find that my local library system has one copy each of:
* Introduction to Algorithms
* The Art of Computer Programming (vol 1)
* The Pragmatic Programmer
But the list of computer science classics they don't have is far larger. What they do have are a ton of of titles like _Teach Yourself Visual Basic.NET in 21 Days_ (real) and _Excel 14.2.32.rev13 for Boneheads_ (made up). No doubt it reflects what patrons are requesting...but I would personally wish for a collection that leans a little more heavily on the perennial classics.
[1] http://www.dlib.org/dlib/april06/dempsey/04dempsey.html
Here's the thing, all that other stuff you mentioned are things I can do with my family. Side projects aren't. I have trouble reading seriously now for the same reason; it is a solitary activity. But at least if I'm reading a book I can still pop out and participate in conversations; not so with programming.
The other important difference, and the reason there is always strong pushback when this topic comes up, is that many of us believe there is a subtext that people who spend a lot of time outside work on side projects are better employees. (I mean, it isn't even really subtext, it is in the text of the OP, and I've been reading the new edition of The Pragmatic Programmer, and it's in the text there as well.) If that view wins out (and in many circles it already has), then what you see as harmless, fun, and enriching side projects are actually a job requirement, one that is extremely hard for many of us to satisfy. So we (reasonably, I think!) push back on this view because we think we're good programmers and good employees without needing to spend our evenings doing solitary work away from our friends and families.
For beginners, these are good:
- How to design programs (http://htdp.org)
- The Little/Seasoned/Reasoned Schemer.
- Code: The Hidden Language of Computer Hardware and Software by Petzold
- Coders at work by Peter Seibel
- The Pragmatic Programmer by Hunt and Thomas
- Code Complete by McConnell
For intermediate/experienced people:
- Structure and Interpretation of computer programs (http://mitpress.mit.edu/sicp/full-text/book/book.html)
- Software Tools in Pascal by Kernighan and Plauger.
- Programming Pearls by Bentley
- Smalltalk 80: The Language and Its Implementation by Adele Goldberg.
- Paradigms of Artificial Intelligence Programming by Norvig
- A Discipline of Programming by Dijkstra
While I've ommited some important language specific books, and ignored essential areas (algorithms, discrete math, hw arquitecture), I think this is a good starting point.
1. Godel, Escher, Bach -- Because it sparked my interest and got me started down the path.
2. The Pragmatic Programmer -- a classic. Reminds me that I need to re-read it.
3. Effective Oracle by Design, by Tom Kyte -- Not that I use Oracle any more, thankfully, but really provided a lot of insight about how databases function and how it pays to deeply understand their internals when writing webapps.
I disagree with this to the point of saying that the Artima book is one of the most well written technical books I've ever read and the O'Reilly book is rather a mess. The Artima book is written by the creator of the language and while it is a couple of years old the information is still 95% relevant to the latest language changes.
I would recommend getting a copy of both of them, but you might want to check out the online version of the O'Reilly book before buying it:
http://programming-scala.labs.oreilly.com/
The Pragmatic Programmers book is not bad either, but it's only a short introduction to the language compared to the other two books mentioned.
All three books have nearly identical titles: Programming (in) Scala
The Pragmatic Programmer:
http://pragprog.com/titles/tpp/the-pragmatic-programmerCode Complete: http://cc2e.com/
Introduction to Algorithms (google that one, it's hard to find a good link)
Domain Driven Design: http://domaindrivendesign.org/books/evans_2003
Design Patterns: Elements of Reusable Object-Oriented Software
The term "web development" doesn't mean much. There is web design. There is application development. When the two mix, there is web application development. Any kind of application development is hard, and simply knowing a language or two isn't going to make you a good application developer any more than knowing english will make you Stephen King. (IMO)
"We’re offering 40% off everything in the store—books, PDFs, and screencasts. There are a couple of exceptions, including The Pragmatic Programmer book itself (ironically, we don’t publish it), and the Programming Ruby 1.9 which is already on its anniversary sale."
I like a lot of what the author is saying, but there is still value in learning the theory.
You can get learn a lot building your own apps, but then you're forced to learn some lessons the hard way. Sometimes you can avoid making mistakes by learning from someone with years of experience. You don't need to take a course, but reading can help so much. Books like The Pragmatic Programmer, Code Complete or Literate Programming can set a good base for thinking about your code.
Also to address the how self taught programmers get jobs, it's worth pointing out that the first question was from a 17 year old. I'd say it would be tricky at that age to get given a chance by an employer. So with time and age their employ-ability should increase as a factor of age alone.
Hm have you taken the inspiration for the woodworker metaphor from Andy Hunts "
The Pragmatic Programmer"?
I immediately thought of his metaphor with the woodworker and his toolset, that needs skills build on it, as well as the working material.
How many have actually read Code Complete Some books are references and some are read throughs. I read Code Complete while in college and thought it really helped my programming. Effective Java is another great book that I've read. The Pragmatic Programmer is another one that I've read that really is worth the time.
Many books are just good references though. Pick it up and read a chapter for example. I think the more experience a programmers gets the less they need to read right through a book. When looking at a book on a particular language I can usually skip the first half because I know the parts that are common across most languages. I only need to know what's different/cool/idiomatic in this particular language.
Algorithm books are another example that falls into mostly the reference category. I don't think I've read any entire algo book, but I have read many chapters from many different algo books that touched on what I needed to learn at the time.
I'm convinced you shouldn't be allowed to write production code unless you've read and understood The Pragmatic Programmer.
The problem with any book list like this is the scope. Software is turning into a very diverse culture, a very heterogeneous ecosystem. Subjects that are very important to one area might not be as important to other areas. Design patterns are essential for enterprise development, not so much for AI and low level systems programming. Algorithms are essential for the latest but not for the former.
Given this, there are some books you might add or remove depending on the area you are interested (e.g.: Knuth's "Art of Computer Programming", Martin Fowler's "Patterns of Enterprise Application Architecture", ...)
To finish, 2 books people recommend a lot for beginning programmers:
"The Pragmatic Programmer"- Hunt, Thomas: a very good book, with sound advice and very easy to read. The only bad side is that it became so influential that its ideas became vulgarized in thousands of blogs.
"Code Complete" - Steve McConnel : A very dangerous book. It does give have a lot of sound advice. But, IMO, it has some big problems. First is that it gives the false impression that there is a lot of empirical evidence on what works on software engineering. Second, it perpetuates some myths that don't have such evidence: the "orders of magnitude programmer's productivity" and "the cone of uncertainty" (see: https://leanpub.com/leprechauns).
Breakthrough Rapid Reading (Peter Kump)
The Pragmatic Programmer (Andrew Hunt)
Cashflow Quadrant (Robert T. Kiyosaki)
How long had you been programming when you read it? Code Complete and
The Pragmatic Programmer had been on my Amazon wishlist for nearly ten years when I finally ordered them a couple years ago. I had the same reaction as you to both. I had already learned all those things through experience. On the other hand, I don't know if the books would have done much good for me ten years ago. Maybe I needed to learn those things on my own, over time.
I think more people read those books and say, "yes, I agree with all of this already" than read them and think, "oh, here is a new thing I haven't thought before and will use from now on."
"Getting Things Done" by David Allen didn't change the way I think about
everything, but it definitely changed the way that I looked at a lot of things. It's often panned today as being "common sense", but I think that's a mischaracterization - at the time it became popular, it ran counter to the conventional wisdom of how to manage your time and attention. Reading it made a profound and lasting impact on how I approached my work.
From a technology standpoint, "The Pragmatic Programmer" changed the way I looked at programming. When I read it the first time, I was a Visual Basic programmer, with only a passing familiarity with the world outside the Microsoft ecosystem. After reading that I began to explore Perl, then Python, and installed Linux and learned it. For my career as a developer, then team lead, and then manager, that book changed me more than any other book I've read in the field.
That same nugget was in The Pragmatic Programmer which I recently have been reading. In regards to estimates or questions about things you don't know, if you can't give a good answer on the spot the second best answer is "Let me get back to you.". The bad answer or estimate will just cause pain for your team/org.
There are 3 books on software development in Javascript. I view JS as an inferior language, not just for semantics, but because it's origins are troublesome for me. JS started as a language to provide interactivity to web pages. Contrast that to C#, which started as a general purpose language with serious minds working on it.
Is it worth reading JS based software engineering / design books, as compared to Code Complete or The Pragmatic Programmer?
Not sure if this is already mentioned but for me the most concise illustration of this fallacy was in
The Pragmatic Programmer book.
They had a function like this:
double f( double x ) { return 1/ x; }
They pointed out that it is trivial to get 100% coverage in test cases but unless your tests include passing in 0 as the parameter you are going to miss an error case.
He says not to use your repository commit messages as the source for your changelog text.
That's exactly what I do use.
I started doing this after reading "The Pragmatic Programmer" where it's argued that the DRY principle should apply to everything including documentation.
It starts with the bug tracker. So when entering something in that I'll also add the text that I want to appear in the changelog for the user to see (these lines will have a // at the start).
When a bug/feature is completed a commit is made and the text in the bug tracker is the commit comment.
If the commit comment has a line starting with a // then that line will have another line inserted above it //Bug fix: or // Feature:
Finally on building the distributable the changelog is constructed entirely from the lines in the commit messages that start with //
The following is a list of my favorite books on software engineering, cyber-security, and the history of IT business development.
Bowden, Mark (2011) Worm: The First Digital World War
Brooks, Frederick (1995) Mythical Man-Month, 2nd ed.
Christensen, Clayton (1997) Innovator's Dilemma: When New Technologies Cause Great Firms to Fail
Hafner, Katie and Matthew Lyon (1996) Where Wizards Stay Up Late: Origins of the Internet
Hunt, Andrew and David Thomas (1999) Pragmatic Programmer
MacCormick, John (2012) Nine Algorithms that Changed the Future
McConnell, Steve (2004) Code Complete, 2nd ed.
Mitnick, Kevin and William Simon (2002) Art of Deception
Poulsen, Kevin (2011) Kingpin: How One Hacker Took Over the Billion-Dollar Cyber-Crime Underworld
Raymond, Eric (2003) Art of Unix Programming
Stone, Brad (2013) The Everything Store: Jeff Bezos and the Age of Amazon
Torvalds, Linus and David Diamond (2001) Just for Fun: Story of an Accidental Revolutionary
Wallace, James and Jim Erickson (1992) Hard Drive: Bill Gates and Making of the Microsoft Empire
Williams, Sam (2002) Free as in Freedom: Richard Stallman's Crusade for Free Software
Wilson, Mike (1996) The Difference between God and Larry Ellison: Inside Oracle Corp
Not the user you replied to but, according to my experience, Code Complete is useful in that, as many other well-written books, it gives advice that comes from common sense and gives it a name. Much like Martin Fowler did with Refactoring, after all: breaking down long methods into smaller, well-named ones is common sense, but calling it Extract Method gives everybody a handle to use for further research.
Saying that whoever recommends Code Complete made some wrong life choices is a bit rude and uncalled for. Books are just tools, the benefits they bring depend on whether the reader goes through them in a smart way or not.
Then again, but this is a matter of taste, I would suggest The Pragmatic Programmer as a first read. It's shorter, well-written and with laser-like focus on the topic at hand.
Lastly, since designing and writing software is as much of an art as it is science, what's really important is to avoid reading passively and blindly applying anything the knowledge one finds in a book, and instead strive to understand why, and going against the grain and see why certain practices are called "best".
I think it really depends on when you read it.
Code Complete was in the first handful of books I read about the practice of programming, apart from language-specific books, and I loved it. Years later I bought the second edition, having given away my first copy, but the magic was gone.
I didn't get much out of The Pragmatic Programmer myself. Maybe if I'd read it ten years earlier, it would have been my Code Complete.
The ranking of this list is extremely suspect.
Code Complete is a fine book. The Pragmatic Programmer is okay. But neither book holds a candle to Introduction to Algorithms for career-long usefulness. For that matter, neither one holds a candle to Design Patterns for the ability to expand your mind and improve your ability to think about code (I read both at the same time, and Design Patterns is the only one whose lessons I remember distinctly, years later).
I think the main problem here is that the easy, mechanical reads get more votes than books that are harder, but more valuable. It's the technical equivalent of a lolcat photo.
Trading and Exchanges: Market Microstructure for Practitioners, An introduction to quantitative finance by Blyth.
Avoid pop finance books that is light on numbers. If you want to understand the qualitative aspects/culture/history, books like Flash Boys or Flash Boys: Not so fast are more than sufficient. Stay away from "technical" books that are designed for layman and non-technical readers. They will handwave Black Scholes and economic math and you will simply be going through the movements without truly understanding.
Books like Reminiscences of a Stock Operator are great secondary books to supplement your primary readings. You don't give a beginning programmer Pragmatic Programmers/Clean Code/Programmers at Work when he or she can barely write a hello world, let alone a quicksort. You want a intro to programming course followed by something like SICP to lay in the foundations of abstraction and computer science. It is the same for finance. Half of the books in this thread are either financial pop science or has little relevance to somebody who wants a rigorous understanding of how the stock market system works.
Also to note, Buffet and A Random Walk Down Wall Street are books that espouse certain schools of thought on managing portfolio. Judge them by their history and backtest their theories rigorously. It is like Object Oriented Programming, fads wax and wane with time and everyone has their opinion on how trading should work so take things with a grain of salt. Lastly, trading and managing a 10 billion dollar fund is quite different from e.g. 100k in your tax free social security account due to stuff like network effects and doors that can only be opened when you have enough zeroes on your spreadsheet so what's good for the goose is not always great for the gander.
Once you are done with stock markets, get a macroeconomics textbook to understand how it ties into the federal reserve (or central bank) and how government bonds affect liquidity, that sort of thing. Again, avoid pop science books which shows up way too often on HN (this is worse with biology, another subject that this forum has a poor grasp of).
Read the pragmatic programmer. For starters.
I had the same experience (but after only about five years). I landed on Code Complete a couple years after devouring
The Pragmatic Programmer (and requiring my developers to read it), and generally found some good ideas of varying quality buried on mountains of text. I think most of it is right, but after having some experience in the field, it seemed it was targeting all audiences at once, from the newbie to intermediate programmer but also to organizations, managers, and others related to code. It's hard to make a book that's to the point if the book lacks focus.
That said, I've still used it for my research ... although I can often find other sources that say things better, CC2 has made a good starting point for ideas on how to present ideas about code.
Some things good programmers care:
* good engineering practices (as all those described in books like "Pragmatic Programmer" and "Code Complete": code reviews, unit testing, continuous integration, coding standards)
* tools worth respect (e.g.: subversion, git or mercurial but not Visual Source Safe)
* a well defined development & project management methodology, agile or not (e.g.Scrum, RUP), instead of clueless project managers.
* a concrete problem/puzzle in the company website to filter out bad candidates
* respect for the developer private life; i.e: what to expect in overtime work
My preference is for erlang. I believe it is the only one that does concurrency "right", though I don't know the others well enough to prove it. Any blocking, as in transactional memory or locks is, in my opinion, a real concurrency problem.
As I learned erlang and OTP I kept finding design choices I really appreciated.
The pragmatic programmers book on erlang was written by the creator of the language and I think is one of the better programming books ever. Clearly he's spent several decades teaching this language to perplexed students, cause he found the right way to illuminate it.
Three boks I'll recommend you read as soon as possible.
1) The Mythical Man month
3) The Pragmatic Programmer
3) Code Complete.
The thing about these books, well atleast 1 and 3 is that when they were written they broke new ground. Or if that phrase bother you, they were the first mainstream publications that brought their core ideas to developers.
Reading these books early in your career will help cement these best practices.
Reading these books after you've been a practicing programmer means,IMHO, that the return you get from reading them goes way way down.
You'll find that you've already learned all/most? of what they are trying to teach.
You'll find yourself getting frustrated that they are preaching what you already know as common sense and first principles.
Or put another way, I'm not sure there is much that someone who has programmed for 5-10 years can get out of those books that they haven't picked up somewhere else already or learned the hard way.
I struggle with the same thing. My mind is often too noisy to filter out the signal, let alone put into a structure suitable for tractability. I happened upon George Polya's "How to Solve It" book several years ago, which contains a very wholesome (and very useful) strategy for tackling problems. It's ostensibly about math problems, but you can apply it to anything.
Here are a few portions of his method that I always come back to:
---
Understanding the problem:
- What is the unknown?
- Draw a figure. Introduce suitable notation.
- Separate the various parts. Can you write them down?
Devising a plan:
- Have you seen it before? Do you know a related problem?
---
You can see the whole method at this link: https://imgv2-1-f.scribdassets.com/img/document/68994766/ori...
I use this approach in conjunction with an A4 piece of paper, or a note program capable of "outlining" functionality (expandable nodes). The latter works great for containing and structuring lots of information, and you can selectively show and hide different parts depending on what you're focusing on. Again, helping with filtering out the "noise" factor.
Another good approach is falling back to a plain-text editor such as Notepad.exe when you want to write anything down. I got that tip from the Pragmatic Programmer book. You can easily extend this to Markdown if needed.
For me it was the stroke of luck in my first programming experience being punched card FORTRAN IV (but more like a II, no logical IFs) on the IBM 1130 in the fall of 1977.
I realized there had to be a better way and so I went straight to the library and read up on the software engineering of the time ("structured programming").
Since then I've read a lot on the practice of programming and applied it to my programming. And kept reading and applying stuff; the key here is to never stop learning.
Studying good software was probably the other major way. Back then, it was learning the UNIX V6 kernel with Lions' Commentary on UNIX 6th Edition, with Source Code plus reading the sources of all sorts of things and working on some of them.
If you haven't read The Pragmatic Programmer, AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis, something by Gerald Weinberg and something by Tom DeMarco and Timothy Lister (Peopleware is pretty much required reading), and The Mythical Man Month I strongly recommend them.
The recent Coders At Work is really good, although at a somewhat higher level.
My other recommendation is to get serious knowledge of other domains that have useful ideas and metaphors; for me that would be science in general and biology in particular.
Hmmm, reading a lot of classic SF (from the '40s on) and studying nanotech also helped. You want to have a big bag of problem solving tricks.
It also helps to gain a top to bottom understanding of how it all works. There are many approaches and books for this, I like The Structure and Interpretation of Computer Programming (SICP) for the higher level stuff, but also be sure to study some EE, digital design and low level architecture. And operating systems.
And if you're at all good with your hands, build (assemble) yourself a computer and get UNIX/Linux running on it. Design and implement a network with routers and static IP addresses or something like that. Etc.
Here's my rant on Code Complete and Clean Code:
I find that these two books are in many recommended lists, but I found them entirely unforgettable, entirely too long, and without any "meat."
So much of the advice given is trivial things you'll just figure out in the first few months of coding professionally.
Code for more than a week and you'll figure out how to name classes, how to use variables, how scope works, etc.
The code examples are only in C++, Java, and Visual Basic (ha!). Completely ignoring non-OO and dynamic languages.
Some of the advice is just bad (like prefixing global variables with g_) or incredibly outdated (like, "avoid goto"? Thanks 1968!).
Work on a single software project, or any problem ever, and you'll know that you need to define the problem first. It's not exactly sage advice.
These are cherry-picked examples, but overall Code Complete manages to be too large, go into too specific detail in some areas, while giving vague advice in others.
All books are written in a time and a few become timeless. Software books have an especially short half-life. I think Code Complete was a book Software Engineering needed in 2004, but has since dropped in value.
I will say, that Code Complete does have utility as a way to prop up your monitor for increased ergonomics, which is something you should never ignore.
I have similar issues with Clean Code. One is better off just googling "SOLID Principles" and then just programming using small interfaces more often and use fewer subclasses.
A better alternative is (from above) The Pragmatic Programmer (2019), a good style guide, and/or get your code reviewed by literally anyone.
If you're like me, nothing. I need to sit down and find ways to break something to understand how it works.
What I do find useful is listening to books on practice or management. Something like The Pragmatic Programmer, The Practice of Programming, and Clean Code. These are high on substance but (relatively) low on examples, so I feel I can still benefit from their insights without having to be in front of a screen.
The Mythical Man Month, Peopleware, The Pragmatic Programmer and all the classic Joel On Software Articles - they taught me so much. Unfortunately, just like you I have encountered very few people in my day job who have heard of these books. I am not sure if that is reflective of a big company, or IT folk in general?
That's an interesting metaphor because I picked it up somewhere else, but it might well be that Hunt and Thomas actually coined this phrase in "
The Pragmatic Programmer".
If you think of orthogonality in geometry, you can describe any N-dimensional vector space through a set of N orthogonal vectors (say the unit vectors in X, Y, Z). "Orthogonal" in this case means that moving something along one of those (say the X axis) won't alter its position from any other base vector's perspective.
In the same way, "orthogonal implementations" is a way of saying that the things are independent from each other. You can find their explanation in the Google preview for the book [1].
So, say you write utility code for a couple of applications, for example: Message transmission and subscription management. Then, you should try and keep both as independent as possible from each other, so that as a downstream user I won't have to pull in or even "massage" both just to use one of them.
As I wrote before, that sounds totally obvious when said out loud; yet I constantly find new examples where someone found a way to unnecessarily "complect" [2] multiple things.
[1]: https://books.google.ch/books?id=LhOlDwAAQBAJ&pg=PT70&dq=ort...
[2]: If that word also seems strange to you, I highly recommend watching https://youtu.be/oytL881p-nQ
Based on all of the coding "best practices" books/blogs I've read, it is unwise to develop something which heavily depends on the internal implementation of the String class (or any library class). Many other commenters here are bemoaning the impacts the specific implementation of String will have on their existing applications. However, we should be designing based on the interface/contract presented, not specific implementation details of interfaces/libraries. Any optimization based on specific implementation details is "at your own risk."
If changes to the implementation of String could cause issues for you, you really should be using a custom solution anyway. A quick and dirty option would be to write a wrapper class which uses all of your preferred String hacks in a central location, and using that in place of String throughout your code. When String's implementation changes, you can update your hacks all in one place.
Here is some relevant advice from The Pragmatic Programmer: https://pragprog.com/the-pragmatic-programmer/extracts/coinc...
me too, just bought the pragmatic programmers book.
It doesn't have to be an either/or proposition. I would like to have a bookshelf of paper books
and electronic copies on a reader. The one for reading in traditional fashion and the other for reading on a plane/ train etc.
Owning two types of cars (or a car and a motorcycle) maybe a more helpful metaphor than horse and buggy vs car. The Pragmatic Programmers release all their books as non drm-ed pdfs and you can buy both the electronic copy and the pdf if you choose. They seem to do well.
But yes, the kindle is very underwhelming, I'll for a better reader without DRM (or at least hackable DRM).
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.
Our field is so varied that there is no good answer to this question unless you specify what you want to focus on.
Some people are inevitably going to recommend The Art of Computer Programming, which hardly anyone has read and isn't that relevant to the work that 99% of us are doing.
Someone will probably recommend The C Programming Language, also called K&R after the authors, but again it's not very useful unless you're going to be using a lot of C and even then I personally don't think it provides anything you can't get from guides on the internet. (I have actually read this one, but it's been a while)
There are other classic textbooks that will probably be mentioned that are only useful to those in that domain. Many of us can get by without a deep understanding of algorithms and data structures, most people don't need to read a compiler book, etc, etc.
However, there are some generalized books that people often recommend like The Pragmatic Programmer and Code Complete. These are, in my opinion, good recommendations if you're looking for something to read but I wouldn't say that someone starting a career in software engineering should read them. Software engineering isn't really a field with seminal texts that should be read by everyone.
For example, every political scientist should have probably read The Republic by Plato and Politics by Aristotle among many other texts. I don't think software engineering has that equivalent, partially due to the relative newness of the field and partially because the primary output of our field is not written texts.
Another interesting question would be "What codebases should someone starting their career in software engineering look at?". Are there things that the average joe programmer can learn by poking around the Linux kernel or Firefox? Maybe. I don't know. I've never done it. I'd be interested in hearing from those who have, though. Maybe I'll do my own ask HN.
edit: I feel I should clarify that this is written from the perspective of a software engineer, not an academic in computer science. For all I know there could be seminal texts that those on the academic side should all have read.
Books like these can be quite a shock to a large set of devs out there. Think enterprise code jockeys who don't read tech books or pay attention to what is going on out there and learn everything they do on the job.
I read Code Complete 2 after developing software for maybe 6-7 years in an environment like this. Much of it was obvious, but the rest was a revelation. Same with The Pragmatic Programmer.
Several years later I read a book called "The Passionate Programmer", which was like the book described in this article - soft, career development skills. That was probably the most important book I've ever read. In fact it's how I found out about Hacker News in addition to a whole bunch of different books. It lit a fire in me.
4 years later, I have a career that is so dramatically different I don't even know where to begin. On the same token, I reread that book (Passionate Programmer) recently and it does seem like common sense I would absorbed over time from things I read on HN.
I remember reading the term for the first time in The Pragmatic Programmer by Hunt and Thomas. They give the experiences of one of the authors as the origin of the term, but I would really be interested where the term was used the first time. Personally, I'm sticking with the technique ever since. Although I've never managed to use it in an office environment with other people. I don't know if this is caused by the environment or if it simply feels too awkward to me.
Second the Pragmatic Programmer, however: I read it when I just started programming (like not much more experienced than basic hello world and some fiddling) and, looking back, didn't really get it. I mean, I got the principles, but couldn't apply it as there was just not enough experience for the higher level abstract stuff. I recently read it again and it makes complete sense now, but I ddn't learn much new from it. So I'd suggest that if you read it, do so after a couple of years of programming.
If you read the article he doesn't say those things should be taught as CS degrees. The exact phrase is "They're far less inclined ... to spend their time" which implies what they're doing above and beyond their formal education.
Would you hire a graduate who wasn't inclined to spend their time learning about version control, bug tracking or release management systems (all of which are part of the ITIL standard) ?
A lot of ITIL isn't that much different from what you find in Code Complete or the Pragmatic Programmer books on deployment. Just because you prefer your buzzword to their buzzword, doesn't mean it's any more important.
>>As Hunt & Thomas say in
The Pragmatic Programmer: "use a single editor well."[1] You'll be most productive if you learn your editor from head to toe, than if you half-assedly know several.
If this advice is to be taken seriously the only editors you can learn is vim and Emacs.
Shiny editors like Sublime Text come and go every 2-3 years. And putting effort learning them, only brings you back to your statement: "You'll be most productive if you learn your editor from head to toe, than if you half-assedly know several."
Read:
The Pragmatic Programmer by Andrew Hunt & David Thomas
Code Complete 2 by Steve McConnell
Clean Code by James O. Coplien
Test Driven Development by Kent Beck (save this for last)
These books will teach you how to think and approach coding in a way that will make Object Oriented programming simpler to comprehend.
I can't suggest a book that explains basic OOP principals, hopefully some other much smarter person here can. I learned basic OOP through practice and through my education/class - but to be honest the basics are dead simple. It's only when you start getting into the very abstract that OOP starts to get really complicated and that's where the above books will help you.
I would get 5 books on the topic. Bring them home, try them all, and you're bound to find one that you like and can work your way through.
One I'd recommend is "Eloquent Javascript". It may be a tiny bit out of date now (I read it over 5 years ago maybe, and Javascript has improved a lot since then), but it's a solid book.
Other books you might like: Pragmatic Programmer, Pattern on the Stone, Clean Code, Mastering Regular Expressions.
Learn about yourself and the answer will come. Learn to meditate. Learn to run. Learn wine tasting. Learn to sew. Volunteer. Go to the zoo. Hang out with friends and family.
Learn who you are, what you enjoy, and where you want to go with your career. Technology stacks change more often than I buy new shoes. Is that a reflection on the technology or the shoes?
I see Mobile development, web dev, FP, and devops technologies in your list. What excites you?
Instead of specific languages, what about learning new concepts? Learning about functional programming will change how you program in other languages. Studying algorithms will change how you think about efficiency. Reading books like "The Pragmatic Programmer" or the classic "Mythical Man Month" will give you a bit of a higher-level understanding of what it is we do.
Yes.
This is only one of these "must-read book list", what you can do is search several of them and see which ones are quoted by almost everyone!
About "everything" I would rate the following books very highly, for their sheer usefulness:
- Thinking Fast and Slow (really do the exercises!)
- then Neuroleadership which describes the purpose of brain structures, it's somehow wider than kahneman
- A Mind for Numbers (include very useful data points for knowledge workers)
- Distinction: A Social Critique of the Judgement of Taste
- Cutting Through Spiritual Materialism
About programming I would rate the following books highly, but at the same time it seems a bit fruitless to me to read about programming, rather than spending more time reading about psychology or sociology:
- the Economics of Software Quality
- Peopleware
- Pragmatic programmer
- Mythical Man month
^you'll see that these books are hardly kept secret, it's just that people quote them but don't actually read them, or so it seems.
I'm not a hiring manager, but if your self-description is accurate (see comments re: impostor syndrome for the possibility it isn't), I wouldn't want to work on a team with you. The problem doesn't seem to be that you're not smart or technical or industrious enough, but that you're not conscientious enough:
I figure out what needs to be done in order to get something to work reasonably well, and if I can’t do it myself I google it till I find snippets of code that mostly do what I need, then I modify them and hack around till I get something that works decently enough.
To me this is a much bigger problem than your ability to implement a linked list or describe big-O notation -- I'd be worried that I'd always be cleaning up after your messes.
The good news is that this is a solvable issue. Start collaborating with people, maybe via open source. Find a project of yours that's useful but maybe not profitable, open source it, and start handling requests for features and submissions. Learn how to deal with bad incoming code, and how to deal with your code being confusing to other people. Maybe read some of the classics on code as collaborative effort, like the Pragmatic Programmer or Clean Code.
Or maybe just decide that this isn't for you! There are lots of jobs oriented around achieving specific goals with throwaway code that you might be happier in than being a slave to the CI server, and they aren't less valuable. But if you want to be hireable in a code-oriented company, I think you have to change some things.
I have read Peopleware. I was thinking about getting
The Pragmatic Programmer next. I somehow feel that just reading books without doing anything with the knowledge doesn't work.
The books I enjoyed the most were Richard Stevens' Network Programming and Unix Programming books. Those books teach you a ton of things while helping you implement something useful. They were very hands on. I haven't been able to find anything similar in a long while.
These are a bit specific. I feel as though they might, in fact, have been the last 4 books the author has happened to read.
Anyhow, I expect we'll get the usual round up here. Code Complete, of course; plus a smattering of rebels who think it was boring or irrelevant. The Pragmatic Programmer will receive universal praise, especially from those who didn't take the time to read Code Complete from cover to cover.
Some of the debate will be about whether Code Complete is "better" than Clean Code or not. A silly argument, they are complementary (though, really, is this even a debate worth having? Code Complete is clearly the better book).
Let's see, what else?
Structure and Interpretation of Computer Programs will get mentioned, which will spawn a fertile subthread arguing about whether computer science books really belong on a list for developers. That subthread will debate the merits of Introduction to Algorithms vs everything else, and someone will mention a lisp book that changed their life. Probably Paradigms of Artificial Programming or On Lisp.
The Gang of Four will get nodded at. Like the Bible, Homer, or Peopleware it will be the book everyone says they've read but which almost nobody has actually read.
The C Programming Language will be mentioned. These days that means Zed Shaw will be named and hilarity will ensue.
Myself? I'd definitely have Code Complete (I still have my first edition), perhaps A Discipline for Software Engineering and Software Estimation: Demystifying the Black Art. I've found pretty much everything from Dorset House to be worth my time, so to PeopleWare I'd add The Deadline and Adrenalin Junkies and Template Zombies.
What we don't do in this industry, however, is read more widely. Get out of your rut. Read about history, read some classics, read deeply in another field you pursue as your hobby. Everything illuminates everything. Get out there, see the intellectual sights (for which, get a copy of Dawn to Decadence by Jacques Barzun for a guided tour). You'll be a better developer and a better person for the trouble.
I just finished reading
the Pragmatic Programmer for the first time and felt that it was pretty much a letdown. For one, it makes a huge number of claims but does not back up these claims by any empirical evidence (even though I think it's mostly right, and that empirical evidence for some of their claims exists). Two, I feel like an undergraduate software course covers 75% of the material in the book (at least mine did). Maybe people have learned since it was first published, or maybe I've just worked on pretty good teams that practiced the stuff, but nothing in there was ground breaking or made me a better developer. Three, there was a lot of filler in the book, summaries, talking about future, and past chapters, etc that added no value except to inflate the page count.
I feel like Pragmatic Programmer would be a good book to read before starting your first job, or maybe your undergraduate year of college.
I was going to start Code Complete next, but Pragmatic Programmer was so disappointing I decided to read fiction for the next few weeks instead.
So to answer your question, the best language agnostic development books I've read are:
1. Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity
2. The Best Software Writing I
3. Hackers and Painters
I always wish Joel would come out with a second volume of #2, or to start his blog up again. I've yet to find something that equals his quality since he stopped writing.
I wonder about this style of thinking. In particular, the distinction between making it work and making it right.
I've read The Pragmatic Programmer, and early-on, it mentions "broken windows" principle -- fix errors as soon as you notice them, or else they'll get more difficult for you to fix as time goes by. And like broken windows are like a green-light for a neighborhood to decline, unfixed hacks similarly invite poor quality code.
In practice, do "working" and "working well" end up being sort of the same as suggested by the broken windows principle? Or Is "make it work" refer to making a quick prototype, and "make it right" refer to filling out substantial functionality?
On my desk:
Getting Real (37Signals),
Hardball (Chris Mathews),
Prioritizing Web Usability (Jakob Nielsen)
Nearby shelf:
The Design of Everyday Things,
Maverick,
Founders at work,
A Brief History of Time,
A Pattern Language,
Peopleware,
Made to stick,
Web Standards Solutions,
Designing Interactions,
The Pragmatic Programmer,
The Mythical Man-Month,
Oh, the Places You'll Go!
Other good reads:
Blink,
Tipping Point,
Long Tail,
Freakonomics
Reminds me of an anecdote from
The Pragmatic Programmer:
Andy once worked on a large graphics application. Nearing release, the testers reported that the application crashed
every time they painted a stroke with a particular brush. The programmer responsible argued that there was nothing
wrong with it; he had tried painting with it, and it worked just fine. This dialog went back and forth for several days,
with tempers rapidly rising.
Finally, we got them together in the same room. The tester selected the brush tool and painted a stroke from the
upper right corner to the lower left corner. The application exploded. "Oh," said the programmer, in a small voice,
who then sheepishly admitted that he had made test strokes only from the lower left to the upper right, which did not
expose the bug.
I started reading things that were related to programming but weren't textbooks (i.e.
The Pragmatic Programmer and
The Mythical Man-Month).
Then I started reading books on skills I wanted to acquire (i.e. Traction for marketing and SPIN Selling for sales).
All of those books lead to recommendations into other books.
Listening to podcasts that recommend books increase the breadth of books I'm reading.
My wife brings home books from the library and I read whatever she reads (i.e. Hillbilly Elegy and The People vs Democracy), and those lead to other nonfiction books I become interested in. And then there are the "classic" novels I interleave from time to time (i.e. Siddhartha and Meditations).
It just starts with maybe a handful of books you are dying to read, try to read for 15 min before bed, and before you know it, you're 50 books into the year!
After I graduated from university back in 2006 (studying Management Science), I decided that I liked computers more than I liked Banking or Management Consulting, so I worked for a friend of a friend doing web design, and began to learn Ruby and Ruby on Rails. I read
the Pragmatic Programmers books, and spent 6 months at home learning Ruby and Rails in my free time.
About a year later (summer 2007), I got a job working for a ticket search engine called Tickex, doing Rails. I was paid £9 per hour, and worked at a BBQ table and chair. It was a really enjoyable time. we were Seedcamp finalists and nearly got funding from Sequoia, but sadly the funding ran out and the business moved back to California and then shut down. Since then, I've worked at a few other startups, at a web agency called New Bamboo, at AOL, and now I work in a small business. I also had offers to interview at Square and Facebook, but a temporary lack of nationality/family circumstances meant that I couldn't move to California.
The decision to deviate from the path offered by my degree has been one of the best in my life. Before I had learnt to program, I had ideas but no ability to program, so they remained as ideas. Having learnt to program, I have the ability to have ideas and do something about them.
McConnell, Steve. Code Complete. Redmond, WA: Microsoft Press, 1993.
McConnell, Steve. Software Project Survival Guide. Redmond, WA: Microsoft Press, 1998.
Maguire, Steve. Writing Solid Code. Redmond, WA: Microsoft Press, 1993.
Ranade and Nash. The Elements of C Programming Style. New York: McGraw-Hill, 1992.
Kernighan and Plauger. The Elements of Programming Style. New York: McGraw-Hill, 1982.
Caner, Cem, et al. Testing Computer Software, Second Edition. New York: Wiley Computer Publishing, 1999.
Hunt, Andrew, et al. The Pragmatic Programmer. Reading, MA: Addison-Wesley, 2000.
Holub, Allen. Enough Rope to Shoot Yourself in the Foot: Rules for C and C++ Programming. New York: McGraw-Hill, 1995.
A few ideas:
- Link the name to a list with all the recommendations by that person, use the date for a link to the place where the recommendation was made (using the date for a permalink is convention).
- Link tags.
- Show everyone who recommended something and sort by how many people recommended it. (For instance The Pragmatic Programmer is recommended by Joel Spolsky, Steve Yegge and Jeff Atwood.)
- Use Amazon Affiliate links to make money.
Couple of things:
1) You'll likely get better/more response if you prefix your post with "Ask HN: " (lots of folks have triggers for that type of thing)
2) You don't have to be a mathematician to be a good programmer. Tons of great programmers were not comp-sci majors so don't let that sort of thing get you down. If you've done "some basic noodling here and there... in a few languages" and you want to improve as a programmer, I'd advise you to:
- Pick a language
- Pick a pet project
- Buy a few books or take a few online classes that are on your chosen language
- Begin reading the book
- Implement your project while reading the book
- Find some sample apps written in your language and review how they did things differently
- Finish your book and buy another book/class that is specific to your language
- Pick a new pet project and implement it
- Review some open source apps written in your language
- Contribute to some open source apps
At this point you're likely ready to spend a bunch of time reading non-domain specific books but, up until this point, the value you would receive from reading books not directly related to a specific language/task is debatable. Now that you've had some experience, I think this is a great time for books like:
* The Pragmatic Programmer
* Code Complete
* Head First Design Patterns
* The Mythical Man-Month
* Design Patterns: Elements of Reusable Object-Oriented Software
(Those are all titles of books BTW)
Next up: build a startup!
Notice there are no math books in my list. This is different from what others would propose but, given the scant description you wrote, I don't see any need for math except to satisfy a possible desire to learn.
Not so sure if it "must" be _one_ config file.
I also don't think that the format matters more than it's use.
Reminds me of some good advice in The Pragmatic Programmer, should be
(simple) text-files for editing and (regardless if one or multiple files), a single source of truth (e.g. if multiple files, not the same time the same data to edit in). This is roughly as I remember it and I found it always useful to apply.
If I see duplication, it's about fighting the rot and remove it.
If configuration files are generated, they don't belong under version control (there are some exclusions to this rule, e.g. pinning dependency versions for example when shared with the repository).
I think the fact The Pragmatic Programmer is a little less "crunchy", in terms of the technical content, than books like SICP and Code Complete probably has something to do with the fact it doesn't seem to get mentioned as much any longer. It's still one of the best programming-related books I've ever read, and I'm kind of disappointed that it does not seem to get mentioned as much as it once did (based on what I've seen).
I wish I could
like reading certain technical books in dead tree format, but I recently bought both the digital and dead tree versions of
the Pragmatic Programmer, 20th anniversary edition; and I really couldn’t stand the lack of colour syntax highlighting and colour diagrams in the dead tree version. Mind you, I bought from InformIT, so it was definitely not counterfeit; it was just the printing quality that the authors/publisher chose.
Plus, with a digital version like epub, I could change font size and let it reflow, change the colour theme to sepia in Apple’s Books app or Calibre, and it would still be beautifully formatted.
The books that I think are must-read are "
The Pragmatic Programmer" and "Apprenticeship Patterns". I learned a lot from them.
I'm aware you expect some quick tips from HN though. Have a look at my old blog posts that summarize these books. While 3 years old and written in Polish, Google translated it very well. Direct links to the translations: https://bit.ly/1oZiidn and https://bit.ly/1w8ELhY.
I try to do this with any technical book I read, and summarize things in an org-mode outline in Emacs while I read. It helps to have a bookstand (the BookGem is nice). Combine this with advice from "How to Read a Book" and follow the guidelines from "
Pragmatic Programmer" of at least one technical book every three months, and it makes for a wealth of handy notes and better retention.
Another big helper (which works well when you're already in Emacs), is to type in and test code examples, and force yourself to solve/work all the exercises/problems given.
A couple of last things to look up: the PQ4R strategy and SQ3R strategy. I've heard these are taught in England; I really wish they would teach it here in the states early in public school.
I would recommend a classic that you haven't read that isn't directly about a specific programming language, since it would seem to me that the virtue of reading a book about a specific language when you aren't in front of a computer is dubious. (Note I didn't say it had no virtue, I just find it dubious. YMWV.)
Already mentioned is Code Complete and The Pragmatic Programmer. I'd add The Mythical Man Month, still a classic, but note that's a relatively short book and may not last long enough. (A depressing read in some ways; decades have passed and what's in the book is arguably common wisdom, yet I still encounter the errors outlined in that book every year.)
Godel, Escher, Bach (mentioned by caffeine) is a love it or hate it book; check out a couple of summaries and see what you think.
Personally, I don't recommend the SICP unless you're actually working through the exercises to some extent, and without a computer it's too easy to think you understand it when you don't.
If you have already read all those, well, I'd suggest replying and saying so. :)
IMO you should learn ruby and rails framework at the same time. The knowledge of ruby will help you gain a deeper understanding of rails inner workings like the use of method_missing, concept of self and so on. I would recommend The Ruby Programming language by David Flanagan. The Pragmatic Programmer's book Programming Ruby is quite good as well.
I'd also be interested in what you have to write about it.
Off-topic: what books do you recommend on chemical engineering? What's the equivalent of The Art of Electronics for analog electronics, or HDL Chip Design for digital chip design, or Code Complete or Algorithms in C or CLRS or The Pragmatic Programmer or SICP or TAOCP for software?
> "non-DRMed ebook" you mean the 4 or 5 that exists and is not RPG or fanfic?
The Pragmatic Programmer's ebooks, from their site, are all non-DRM, on the technical side (I think a number of other big technical publishers do non-DRM on direct-from-publisher ebooks).
(On the fiction side, I know Baen has included CDs of DRM-free ebooks -- mostly the all-but-most-recent books in major series -- with hardbacks, and also allowed them to distributed on the web.)
My list, categorized:
Business & Management
1. Innovator's Dilemma and Innovator's Solution by Clayton Christensen
2. Built to Last and Good to Great by Jim Collins. Built to Last is more applicable for startups.
3. Mythical Man Month by Fred Brooks. Anyone who has to manage a team of programmers and hasn't read this will fail utterly, unless they've already failed before (or been on a failing team). There's a lot that's counterintuitive about software project management.
4. Peter Drucker's work. Kinda long and repetitive, but some good insights.
Marketing
1. All Marketers are Liars by Seth Godin. I like this better than Purple Cow, Guerilla Marketer's Handbook, and The Big Red Fez. Most of those have fairly obvious stuff.
2. The Tipping Point by Malcolm Gladwell
3. Crossing the Chasm by Geoffrey Moore
Technical
1. Building Scalable Websites by Cal Henderson
2. High Performance MySQL by Jeremy Zawodny
3. Pragmatic Programmer by...well, it's mentioned elsewhere here.
There are lots of other technical books I like, but most of them aren't directly relevant to the startup I'm building
Gosh, there's so many. But these come to mind:
1. Neuromancer - William Gibson
2. Snow Crash - Neal Stephenson
3. Hackers - Heroes of the Computer Revolution - Steven Levy
4. How to Measure Anything - Douglas Hubbard
5. Godel, Escher, Bach - Douglas Hofstadter
6. The Pragmatic Programmer - Andy Hunt and Dave Thomas
7. The Soul of a New Machine - Tracy Kidder
8. Code - Charles Petzold
9. The Shockwave Rider - John Brunner
10. Ambient Findability: What We Find Changes Who We Become
Book - Peter Morville
11. Don't Make Me Think - Steve Krug
12. The Design of Everyday Things - Donald A. Norman
13. The Mythical Man-Month: Essays on Software Engineering - Fred Brooks
14. Decline and Fall of the American Programmer - Ed Yourdon
15. Cube Farm - Bill Blunden
16. The Philip K. Dick Reader
17. The Cuckoo's Egg - Clifford Stoll
18. The Prince - Niccolò Machiavelli
19. The 48 Laws of Power - Robert Greene
20. The Atrocity Archives - Charles Stross
21. Business @ the Speed of Thought: Using a Digital Nervous System - Bill Gates
A few sort of random selections from my bookshelf (in no particular order):
* GEB:EGB - Hofstader
* The Pragmatic Programmer - Hunt / Thomas
* Peopleware - DeMarco / Lister
* The Mythical Man Month - Brooks
* Paradigms of Artificial Intelligence Programming - Norvig
* Nausicaa of the Valley of the Wind - Miyazaki
You can't really judge a book solely by the imprint it belongs to or, in the case of "
The Pragmatic Programmer", stated. They're all written by different authors so their style and quality will naturally differ.
For what it's worth, it's the same imprint that gave us the pickaxe book (Programming Ruby), so perhaps that ought to be a point in it's favour.
Given your goals, you might want start by reading books like
The Pragmatic Programmer and Code Complete cover-to-cover, and taking it easier with the theory books. You want your basic software development skills to be solid before you start going into proving algorithm complexities.
Beyond that, off the top of my head the number one theory book for working programmers would be Introduction to Algorithms by Cormen, Leiserson, Rivest and the new guy.
I echo prior advice about habits -- the standard stuff I've heard is after doing something for ~3 weeks, it becomes habit. I have had moderate success with streaks (both for exercise and coding). Esp. insofar as coding goes, I would say "just to a little bit every day". Find 10 minutes here to just open the editor and fix/improve/write one line & commit (or work on design or something, since writing software is def. not all coding). You'll be there before you know it. See:
http://lifehacker.com/281626/jerry-seinfelds-productivity-se...I would point you to two other reference materials. One, is Andy Hunt's (of the Pragmatic Programmers) book: "Pragmatic Thinking and Learning" which I cannot recommend enough. Second is 37Signals "Rework", which I also heartily reccomend.
One thing Pragmatic Thinking & Learning touches on is S.M.A.R.T. See: http://en.wikipedia.org/wiki/S.M.A.R.T.
Also? I have A.D.H.D., too. I also struggle at times -- it's a bitch to admit you're both intelligent & disabled.
I don't have much practical advice on this topic, just be aware.
Finally, work on balance. Work on goals. And don't sweat the small stuff -- relax and work slowly. Change is hard.
Best of luck.
-N
P.S. Exercise helps everything (ditto sleep) -- cognition, bodily health, focus, etc. Even if you don't lose any weight (or gain slightly due to fat -> muscle) it's still worth it. Trust me.
"If I'm working on any sort of problem needing a programming solution, and someone suggests we use lisp, I buy that person a copy of "
The pragmatic Programmer", and tell them to read it closely."
Then I'd recommend you go back and read it closely yourself, because there's an entire chapter on domain-specific programming which includes tips on implementing mini-languages to write code close to the problem space, which is a very Lispy suggestion.
Here's what I've read recently:
* The Pragmatic Programmer
* Coders at Work
* Cocoa Programming for Mac OS X
The Pragmatic Programmer is quite old (published 1999). It provides a lot of useful (generalised) information on how to build a scalable, useable and easy-to-maintain application. The small handout that comes in the back of the book is also a great reference to keep next to your desk!
Coders at Work takes a slightly different approach. Odds are you've heard about it from other users of HN, but in short: It's a selection of interviews with some of the most accomplished programmers around; Knuth, Simon Peyton Jones etc. I'd still recommend this book, but I would probably cut out around 15% of it.
C++ was never given enough time at my University (it was a Java school) and so I wasn't too tied to it when starting out with Cocoa Programming for Mac OS X. If you can understand basic pointer use in C, then this book will hold your hand through Objective-C and into using Interface Builder and XCode to build native Mac applications. It's not going to teach you how to build iPhone apps, but it will give you the correct core knowledge to go on and do so using the Apple docs should you wish.
I'm currently in the process of reading K&R (The C Programming Language book) and Thinking in Java, both of which are regarded quite highly. Although K&R is definitely seen as THE technical book to read.
Fiction, English
Listening:
Swords in the Mist, Fritz Leiber. Third in the Fafhrd and the Grey Mouser collections.
Reading: The Dispossessed, Ursula Le Guin.
Fiction, Spanish
I’m trying to learn Spanish. I’ve picked up a few Spanish language fiction books, presently starting on
Harry Potter y la piedra filosofal. I’ve tried reading other books, like Jorge Luis Borges’
Ficciones, but I’ve found it to be above my present level. I’ve restarted four or five times and made it further each time, but always stalled out.
Non-fiction
The Design of Everyday Things, Don Norman.
I have other books started lying around the house, but these are the ones I’ve been actively engaged with in the last couple weeks. When I can type properly again (two to three weeks) I’ll resume Lisp in Small Pieces, Christian Queinnec. And at the office I have The Pragmatic Programmer, I’ll be back there next week and bring it home so I can continue with it.
I've wanted to work with Elixir for 5 years now. I attempted to go through The Pragmatic Programmer's Elixir textbook and couldn't make it through. This comment applies solely to me, I feel I didn't have the aptitude to pick up functional programming (and that's coming from someone who graduated in CS from a T3, had years of experience, and starting med school next month).
Anyway you cut it, she's probably going to have to pick up some basics coding skills to become familiarized with the skillsets of a programmer. Might want to look at the following books:
The Pragmatic Programmer
The Mythical Man-Month: Essays on Software Engineering
And oh yeah,Dilbert & The Tao of Programming for philosophical contemplation.
muzanionFeb 3, 2020
That said, The Pragmatic Programmer is my favorite resource for it. https://refactoring.guru/ is also a nice reference point, in an easy problem-solution format.
aloknnikhilonSep 24, 2019
https://pragprog.com/book/tpp20/the-pragmatic-programmer-20t...
muzanionAug 19, 2019
For that, I'd recommend The Pragmatic Programmer, A.Hunt, D.Thomas.
tmalyonJan 26, 2018
Kent Beck's 4 rules of simple design is great. You can find the rules online.
Some great books are Clean Code, Pragmatic Programmer, Working Effectively with Legacy Code
daveslashonApr 6, 2018
jonkiddyonNov 22, 2016
exception_eonApr 18, 2017
This book is amazing and still holds up today, for the most part.
chenshuilukeonDec 18, 2018
...
I think a toy robot would be great
randomsearchonSep 13, 2015
- the pragmatic programmer
- clean code
I'm not sure I believe articles like this, but myself and colleagues have found these books to greatly improve our coding.
bicxonJune 30, 2014
beatonAug 30, 2013
krogeronAug 12, 2013
q-baseonJune 22, 2018
chollida1onApr 26, 2019
Agreed, that's why I listed that book in my linked comment:)
stevefinkonOct 6, 2010
usrmeonJune 22, 2021
aaronbrethorstonMay 7, 2011
BamboonMay 27, 2021
GFischeronFeb 8, 2013
Well, the first book recommended is The Pragmatic Programmer, we can all get behind that one :)
ratherlongnameonSep 20, 2019
Doing this attaches your reputation to your code. Anybody reading it knows to expect a certain level of quality given it is written by you, and you get the much needed motivation to write good code.
Amazing piece of advice I picked from the Pragmatic Programmer.
matrixonNov 11, 2010
StudyAnimalonApr 18, 2011
Also going to dojos and doing katas.
hon08onOct 19, 2016
treerexonMar 3, 2013
muzanionJan 25, 2021
dllthomasonDec 2, 2020
tmalyonJune 28, 2016
I did find some value in Code Complete, but it is a little too long for my tastes. The naming and abstract data structure sections were probably my favorite parts of that book.
rffnonJuly 22, 2016
- Computer Architecture - A Quantitative Approach (Hennessy/Patterson)
- Expert C Programming - Deep C Secrets (van der Linden)
I woud call the Pragmatic Programmer though by far the most influential.
BFattsonJune 5, 2017
lo_fyeonSep 3, 2009
crazypyroonSep 5, 2015
Also got Rapid Development for 5 dollars, but haven't started on that. Haven't really read any software engineering books like these before, but enjoying them so far.
conradfronDec 8, 2014
The Pragmatic Programmer - It has been recommended to me by a good developer that is self-taught like me. So far so good. Some things are a bit dated though.
haastedonAug 8, 2008
It reads a bit like "the 7 habits for effectice developers", except that it contains about a 150 "habits". I have wished many, many times that I could force colleagues to read this.
http://www.pragprog.com/titles/tpp/the-pragmatic-programmer
grigyonOct 31, 2011
http://pragprog.com/the-pragmatic-programmer
lordmattyonAug 7, 2010
pmorrisonflonDec 6, 2010
I'm reading 'Growing Object-Oriented Software guided By Tests', Pryce, Freeman right now, and think it's really worthwhile.
dmuxonAug 1, 2016
I read both The Pragmatic Programmer and Code Complete (2ed) before Thinking Forth. The latter provides a wonderful software engineering foundation (in clearer, more concise language too).
grigyonJan 13, 2014
amatechaonDec 19, 2020
mullronMay 9, 2011
* Head first design patterns
* Agile Web Development with Rails
It's not obvious, but the rails book is a great introduction to test-driven development in general.
chicagoscottonOct 11, 2018
Or, more seriously, I think an O'Reilly book on common Lisp would go a long way toward promoting the language. As would one from the Pragmatic Programmers.
wnevetsonAug 30, 2013
virtuzonNov 11, 2013
lylejohnsononMar 17, 2013
The Pragmatic Programmers offer their authors 50% of the net. I was lucky enough to publish one book with them, and despite that book's anemic sales I made out pretty well. Cant recommend them enough to prospective authors.
idlemindonJune 22, 2015
The Pragmatic Programmer: Hunt and Thomas
The Mythical Man Month: Frederick Brooks
henrik_wonJune 5, 2017
- Code Complete by Steve McConnell
- The Effective Engineer by Edmond Lau
- The Pragmatic Programmer by Andrew Hunt and David Thomas
vram22onApr 26, 2019
sidcoolonDec 22, 2016
Then there was The Kite Runner
Also, Zen and the Art of Motorcycle Maintanence
Then Becoming a Technical Leader by Gerald
I wish I had read more.
EvgenyonOct 16, 2015
diego_moitaonMay 2, 2018
Pragmatic Programmer is a much better book.
pjmorrisonAug 7, 2016
mtoledoonAug 28, 2008
mrvenkmanonAug 6, 2021
Learning to keep it simple & methods for avoiding code duplication. I tend to find when learning a new language that avoiding duplication teaches me how to use the language properly.
And the book, The Pragmatic Programmer helped me to communicate better.
tedmistononNov 18, 2016
[1]: https://pragprog.com/book/tpp/the-pragmatic-programmer
[2]: https://pragprog.com/book/ahptl/pragmatic-thinking-and-learn...
chollida1onNov 13, 2008
I've finished reading the fist draft of the Pragmatic Programmers new book on Clojure and I can't wait until they release another draft. The first draft only contains about half the chapters.
pbr_robonJuly 8, 2014
For a Software Engineering book, it's hard to beat The Pragmatic Programmer.
A good working-with-other-people book is Extreme Programming Explained 2nd ed.
dschaddonFeb 3, 2020
pjmorrisonSep 10, 2018
saasinatoronJuly 22, 2016
gnaritasonAug 2, 2016
ConfusiononAug 28, 2010
muzanionJan 29, 2019
lmarcosonMar 1, 2021
Software engineering has more to do with people than with software. Have you checked Peopleware? Also, perhaps The Phoenix Project could help as well.
clumsysmurfonMay 9, 2018
wmatonOct 29, 2012
Reminds me of Jesse Storimer http://jstorimer.com/ who originally published 'Working With Unix Processes' independently which subsequently got picked up by The Pragmatic Programmers: http://pragprog.com/book/jsunix/working-with-unix-processes
Currently working on some books myself.
jacques_chesteronJan 25, 2011
Code Complete, Rapid Development, The Mythical Man-Month, The Pragmatic Programmer, Peopleware and A Discipline for Software Engineering? (The last one is controversial).
mssundaramonApr 7, 2021
zevebonAug 1, 2016
shelfuonOct 4, 2010
SideburnsOfDoomonJuly 2, 2015
Unfortunately it looks like you have to watch the video in order to find out what the practices and details are.
va_coderonOct 15, 2009
alexis_fronFeb 28, 2019
datavirtueonMar 26, 2021
Do what needs to be done to make the intent of a block of code super clear, in plain English. Comments don't count, as illustrated clearly in The Pragmatic Programmer, for instance.
alfiedotwtfonDec 9, 2020
PaulAJonMar 28, 2020
* Making Software, edited by Oram & Wilson. A bunch of papers about evidence-based software engineering.
* Beautiful Code, also edited by Oram & Wilson. A bunch of papers about especially elegant pieces of software.
* Eiffel, by Bertrand Meyer. What Java should have been.
* The Devil's DP Dictionary, by Stan Kelly Bootle. A satirical look at the computer industry circa 1980.
* The Jargon File. (http://www.catb.org/jargon/html/). The language of the Elder Days.
* Facts and Fallacies of Software Engineering by Robert Glass.
* The Pragmatic Programmer by Hunt & Thomas.
munificentonMay 23, 2020
retrogradeorbitonMay 6, 2013
Best resources and books? There are just so many good books. Last one I enjoyed was The Pragmatic Programmer. Next I'm going to try reading Clean Code.
Keep learning. Keep reading. Keep writing.
tobyjsullivanonFeb 11, 2018
2) The Decision Maker by Dennis Bakke. This one pairs well with the more thorough Reinventing Organizations which has been mentioned in another comment.
aaronbrethorstonAug 31, 2010
weejonNov 1, 2017
* Code Complete https://www.amazon.com/Code-Complete-Practical-Handbook-Cons...
* Programming Pearls https://www.amazon.com/Programming-Pearls-2nd-Jon-Bentley/dp...
* Pragmatic Programmer https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...
yockonDec 10, 2010
New office chair -
Candy/Chocolate/Wine/other goodies
The wife and I bought a new car this Christmas season, so I think that counts. We already have it though. '06 Volvo S60.
jdconJan 1, 2020
apertureonNov 23, 2012
floydpriceonJuly 30, 2012
This and "The Pragmatic Programmer" are my top two books, relating to Software Development and Running a small business.
kirang1989onMay 19, 2014
The Pragmatic Programmer - My all time favorite. Awesome book to learn best practices of various aspects in programming.
The Code Book: The Evolution Of Secrecy From Mary, Queen Of Scots To Quantum Cryptography, if you have a thing for cryptography.
randitoonApr 13, 2011
To misquote the "Pragmatic Programmer" book... don't use wizard code you don't understand. The opposite applies in my opinion.
jasonwockyonJuly 9, 2014
I bought this ebook when it was first released. The level of care Dave has given to it is astounding. I believe he's released at least 10 significant updates to it as the language has evolved.
Maybe he said somewhere on the book's marketing page that he was going to be doing that, but if he did, I missed it. Extremely pleasant surprise.
dansoonSep 4, 2013
With that in mind, it makes it easy to write tests and more comprehensible variable names (still thinking and re-thinking how to best do documentation...was checking out github's Ruby guide and Tomdoc yesterday http://tomdoc.org/)
aurahamonMay 25, 2021
[0] https://pragprog.com/titles/tpp20/the-pragmatic-programmer-2...
ZeroGravitasonDec 22, 2019
GoldaronApr 30, 2020
Thanks for the suggestions, I'll give it a listen on Audible.
jefuriionMar 6, 2015
Context: it was published in 1999.
ananya125onMay 22, 2020
aerophiliconFeb 22, 2019
I have used the concepts in this book weekly, if not daily. Note: The tracer bullet framework helps with thinking about any complicated system, not just software.
re_toddonMay 31, 2014
1. Code Complete by Steve McConnell
2. Refactoring by Martin Fowler
3. The Pragmatic Programmer by Andrew Hunt and Dave Thomas
LameRubberDuckyonOct 28, 2019
Database Internals,
Snowden book,
Algorithms book,
BPF Performance tools,
Your Linux Toolbox,
The Go Programming Language,
The Pragmatic Programmer,
Quantum Computing,
A Programmer's Introduction to Mathematics,
An Elegant Puzzle
I had to go up to page 14 of the items list to find all of the items you listed and to find the wire-type soldering iron tip cleaner.
Edit: Took out unneeded snark. It seems I fell prey to Amazon algorithms.
jon-woodonApr 9, 2015
breckenedgeonOct 3, 2018
variedthoughtsonMar 21, 2019
The Pragmatic Bookshelf published it's most important book, in my opinion, in 2017 with the first pytest book available from any publisher.
Topics:
The Pragmatic Programmer, the book
The Manifesto for Agile Software Development
Agile methodologies and lightweight methods
Some issues with "Agile" as it is now.
The GROWS Method
Pragmatic Bookshelf, the publishing company
How Pragmatic Bookshelf is different, and what it's like to be an author with them.
Reading and writing sci-fi novels, including Conglommora, Andy's novels.
Playing music.
beatonJune 7, 2019
manaskarekaronApr 26, 2019
- A quick reference for the important points in Pragmatic Programmer :https://blog.codinghorror.com/a-pragmatic-quick-reference/
- Code Complete: http://codecourse.sourceforge.net/materials/Code-Complete-A-...
andrewlonJuly 19, 2016
I have a few of their books, and they're pretty good. Their store is also very straightforward and friendly.
Does anybody have experience writing for them?
MarinaMartinonOct 30, 2010
I'd definitely be interested to see two different programmers write up their approach to a given problem. Something like this would be an excellent monthly blog post.
throwawayswedeonJuly 11, 2021
People feed the beast and then wonder why it's come back for more.
jpincheiraonJuly 31, 2018
I'd go for that and some JS on the side but if you got an iPad, I'd definitely try Swift with the Playgrounds app.
rosejnonJuly 6, 2009
terrasectonDec 1, 2014
alfiedotwtfonJune 28, 2016
aedonSep 3, 2012
zgmonMar 6, 2015
Pragmatic Programmer fills in the gaps you need to succeed as a professional programmer.
Code Complete is a field guide to managing software complexity.
gnaritasonFeb 19, 2020
But from the writers:
Fowler is the most prolific writer of the bunch, but he was largely documenting and naming what he saw all of them doing.
namuolonFeb 15, 2020
> The trouble with DRY is it has no reference to the knowledge bit, which is arguably the most important part!
Okay. Now what does this mean? Is this article effectively a tantalizing recommendation to read The Pragmatic Programmer?
lkbmonJuly 27, 2018
maksaonJune 6, 2017
- Code Complete 2nd Ed.
- Quality Software Management Vol 1-4, by Gerald M. Weinberg
I'd also throw in: Code Reading - The Open Source Perspective
innocentoldguyonFeb 19, 2018
I also like the debugger. It allows you to easily capture your steps as you click around your application, save those steps into a file, and send that file to other developers, which allows them to run through your steps on their own machine; seeing Elm's output at each stage. It works like a "steps to reproduce" bug report, only automated, which makes finding and fixing difficult bugs easy.
There is a lot of good documentation for Elm as well. Elm's documentation itself is good. Manning and Pragmatic Programmers both have good books on Elm (both are still early access versions though). Pragmatic Studio also has an excellent video course on Elm for about $60 (https://pragmaticstudio.com/courses/elm), if you're interested in learning it.
codr7onDec 24, 2020
https://pragprog.com/titles/tpp20/the-pragmatic-programmer-2...
It's been a long, long time since I had access to the book; and much of it is internalized by now; but back then it changed everything for me.
douglaswlanceonDec 16, 2019
The best books I've ever read:
shagbagonMar 4, 2012
If you're looking to write books that will be read years from now, you need to focus on wider or more fundamental issues. The caveat here is that primers for long-lived languages like C++ have remained relevant for decades.
tiffanionSep 3, 2009
And yes, being able to rollback bugs or things your users don't like in a systematic, traceable way is absolutely the best. Undo only works up to a point lol.
Check out The Pragmatic Programmer for more nice ideas about being a developer. http://www.pragprog.com/the-pragmatic-programmer
de107549onJuly 23, 2016
As a programmer :
1. The C++ Programming Language by Bjarne Stroustrup.
2. Operating System Concepts by Silberschatz
3. Compilers by Aho
As an agile software developer:
1. eXtreme Programming by Kent Beck
2. Pragmatic Programmer by Hunt and Thomas
3. Continuous Delivery by Jez Humble
As an architect:
1. Domain Driven Design by Evans
2. Pattern-Oriented Software Architecture by Buschmann
3. Envisioning Information by Edward Tufte
As a CEO:
1. Good To Great by Collins
2. Lean Startup by Eric Ries
3. Beyond Budgeting by Pfläging
LockeonMar 3, 2008
I had a hard time deciding whether or not to include the Pragmatic Programmer, in the end I decided to go with The Ruby Way because it was an unusually enjoyable read for a language book.
I know the original list was supposed to be more esoteric books, not classics, but I'm anticipating this becoming a thread of everyone's favorites. : ))
jakubholynetonAug 29, 2012
Thank you for your comment, I thoroughly enjoyed it. Thank you also for summarizing the many forseeable possible discussions upfront so that we could have avoided them here.
The books were chosen by a group of five, half of us with 10-15 years of experience, so no, they aren't the latest books the author by a chance happend to read.
I admit that, as others have complained, the title might be percieved as misleading. The reason is that these are books that our company recommends to its developers and we want the developers to be something more than coders (= what most people understand under 'developer'). Though it's important to write great code, it's even more important, IMHO, that it is the right code that gets written, i.e. that the resources available are used to produce the maximal business value possible (and we believe that this cannot be planned but must be discovered based on feedback from reality - that's why lean/agile). Going quickly (great coding skills) in the wrong direction isn't progress.
Some of us have read Code Complete or The Pragmatic Programmer but it hasn't made it into the list. More of us will read it now and we will reevaluate the list afterwards. I hope it's good with you :-)
skfistonMay 16, 2018
- Pragmatic Thinking & Learning by Andy Hunt
- The Design of Everyday Things by Don Norman
-
The Effective Engineer* by Edmond Lau- The Pragmatic Programmer by Andy Hunt and Dave Thomas
- SQL Performance Explained by Markus Winand
And http://teachyourselfcs.com curriculum is pretty good as well.
As a side note, there's so much we can learn from game programmers and OS/database/compiler engineers.
arunkumarlonFeb 13, 2016
So, Ruby on Rails.
Rails is a stack that has:
Ruby - a very simple developer friendly language. This is responsible for putting together
JavaScript - this lang is responsible for all the fancy stuff you see on websites. The animations and all.
HTML, CSS - this is the stuff that websites are made of. Ruby and JavaScript are used to generate this the way you want.
I used to be an accountant and started coding in Nov 2014. I have many rails apps ever since as prototypes and maintain one app that is in production (meaning people use it).
I used this Rails Tutorial by Michael Hart (https://www.railstutorial.org/book) significantly. You will end up with a cool website at no cost at the end of the book.
I also highly recommend Codecademy courses on HTML, CSS, JavaScript and Ruby.
If you are really serious about this stuff, which is great news, you might want to read more about making software. Start with the Pragmatic Programmer. It is a great book to read in your formative years.
And finally (this is important), try to solve a problem (like building a website for yourself or a friend etc) with programming. Learning just to know doesn't stick for long in my experience and probably is true for others.
nocmanonSep 29, 2010
There's a wiki article about it here:
http://www.c2.com/cgi/wiki?RubberDucking
flniuonMay 10, 2020
kriroonSep 24, 2012
The examples and language tend to be programming related (for example one chapter is titled "Debugging your Brain" iirc) because that's the intended audience but I'd also recomend it for non-programmers.
Very good blend of theory (Dreyfus model, r-/l-mode) and practical advice on how to improve your learning and generally use your brain better.
http://pragprog.com/book/ahptl/pragmatic-thinking-and-learni...
dmulleronJune 22, 2021
Last year, I was lucky enough to sign a book deal with The Pragmatic Bookshelf to write an intermediate level book on Python. (The Pragmatic Bookshelf is the publishing company founded by the authors of one of my favorite programming books: The Pragmatic Programmer.)
Having written Python most of my professional career, I wanted a resource that I could give to engineers who might have deeper experience in some language that wasn't necessarily Python. I wanted to help teammates newer to Python quickly discover its virtues (and limitations). I think there are tremendous Python resources available online, but wanted to capture another perspective to help teammates level up their skills.
The book ("Intuitive Python: Productive Development for Projects that Last") went through a beta release this spring, and was officially released this month.
It's available (including a few free sections) here: https://pragprog.com/titles/dmpython/intuitive-python/
In case anyone is thinking of becoming an author with the The Pragmatic Bookshelf, I'd be happy to share my thoughts about the publishing experience there (spoiler: I had a positive experience).
I'm proud to have released this book, and excited to share it here.
Thanks!
-David
pjungwironFeb 18, 2016
paulgbonNov 18, 2020
I've also had good experiences with SCPD courses from Stanford, if your budget would cover those (they are at the other end of the price spectrum).
DoctorDerekonFeb 4, 2021
What you’re reading now is not a collection of mazes for you to solve. No, this is something much more exciting. This is a collection of ideas to inspire you.
You’re about to learn how to generate your own mazes. Random mazes, unique, each one different than the one before. It’s a voyage of discovery where you never know quite what you’ll find when you crest the next hill."
Mazes for Programmers by Jamis Buck — Pragmatic Programmers (3 / 121)
Read more: https://medium.com/pragmatic-programmers/introduction-f7e108...
petercooperonFeb 5, 2010
Luckily with many tech and non-fiction books, the author isn't quite as important as when you're buying fiction or high profile books from the likes of Seth Godin or Malcolm Gladwell. Those guys will always be able to charge the premium rates :-)
smyatkin_maximonJune 7, 2017
Personally:
- Code complete
- Pragmatic programmer
- Design patterns
- Programming pearls
- If you're going for hardcore programming: the dragon book, something on modern hardware and something on OS internals.
bcbrownonDec 15, 2014
muzanionDec 4, 2020
According to the preface, "As a result, this book is something of a Ship of Theseus. Roughly one-third of the topics in the book are brand new. Of the rest, the majority have been rewritten, either partially or totally. Our intent was to make things clearer, more relevant, and hopefully somewhat timeless."
It looks like it did get a substantial update.
weeksieonMay 2, 2018
Code Complete is fantastic. I haven't re-read the Pragmatic Programmer in probably a decade but I remember that giving me a very good handle on approaching code as a young developer.
hsitzonMay 13, 2019
https://www.amazon.com/Pragmatic-Programmer-journey-mastery-...
dkulchenkoonApr 3, 2012
Books are great, but I prefer using solely online resources to learn; I find it to be a more efficient use of my time. Though there are notable exceptions: The Pragmatic Programmer (http://pragprog.com/the-pragmatic-programmer) and Getting Real (http://gettingreal.37signals.com/) come to mind.
askmeaboutloomonJan 12, 2012
Maybe it would be a good idea to put a bit more stress on the "no" in "no sacred cows", that's an important point beyond just K&R. Nothing should be sacred, including "Learning C The Hard Way" - and a "question everything and everyone" mindset is generally a good thing to have as a programmer [I think I read that in "The Pragmatic Programmer" ;-)]. But other than that I now think that chapter is fine. I do apologize for the somewhat passive-aggressive form of my question.
Thanks a lot!
hbienonMar 12, 2008
I'm a fan of "The Pragmatic Programmer".
Other books I thought were a good read: getting things done, 4 hour work week, and founders at work.
I've also got all 6 seasons of 24 on my bookshelf =/, probably not the most productive times of my life.
honkycatonNov 3, 2019
I have a previous comment on this site about reading. That is actually what I look for, intellectual curiosity and a desire to continue learning and growing.
I'll just quote myself:
"""
What I look for in a developer: READS BOOKS. ( Audio books count )
That's the only thing. I'm sorry, if you are not reading and studying to keep up, you are getting left behind. There are so many brilliant people writing amazing books on a huge array of subjects. If I could get every one of my developers to read ONE book on software design[0] a year, I would die happy and the entire industry would be 10 years ahead.
They don't even have to be technical books. I just want to see intellectual curiosity and a commitment to self improvement.
- 0: In the vein of Clean Architecture, The Pragmatic Programmer, The Mythical Man Month, Designing Data-Intensive Applications, The Google SRE book, etc
"""
haastedonNov 23, 2008
Things like amount of unit tests and comments are influenced heavily by this effect.
It's elaborated further in The Pragmatic Programmer (http://pragprog.com/titles/tpp/the-pragmatic-programmer), which actually introduced me to the concept some time back.
cnasconApr 13, 2019
[1] https://pragprog.com/book/btlang/seven-languages-in-seven-we...
[2] https://pragprog.com/book/7lang/seven-more-languages-in-seve...
venaonFeb 16, 2010
as with the same argument presented in that book, i have a little trouble with this since i've been under the impression the broken windows hypothesis was discredited...
ak39onJune 19, 2015
Also, IMO, the worst of such "considered harmful" essays were those that advised against the use of stored procedures and programmatic constructs directly on relational databases in favour of the shiny new hive-mind created ORMs.
The funny thing is, just as the best ORM technologies are beginning to sort their shyte out, we are seeing essays that they are now considered harmful. Reboot.
isaachieronJan 12, 2020
tonystubblebineonJuly 11, 2021
I don't think this is fair or accurate.
Authors are choosing to put their articles behind Medium's paywall because they want to get paid. So when you see a paywall that's the author's choice. It's not any different than a Substack newsletter other than scale. So to say Medium is preventing people from reading... it's really that Medium is home for a lot of writers who want to get paid for their work and probably wouldn't even have written the piece you are trying to read without that incentive.
Then this Skymall article isn't even behind the paywall and doesn't have any sort of block on it or login wall. Or am I seeing something different than you? I tested it while not logged in.
FWIW, there is a ton of great writing on Medium even if there is also a lot of trash. For example, I helped port the full back catalog of books from The Pragmatic Programmers over to Medium. Those are great and it's great to have easy access to all of them.
mbeihofferonJune 1, 2009
I also like most of O'Reilly's Perl books.
Also, Jonathan Rockway's book on Catalyst was very helpful for me, although there were some issues with typos in the first edition (which is to be expected.)
Also, Philip Greenspun has published a good free collection of computer-science and web-development related texts on his website.
(Sure, he's a little arrogant and some people find his writing style to be somewhat abrasive or even borderline nonsensical, but I certainly liked most of his work. And I believe I learned quite a bit from it, as well, though I'm sure that is debatable.)
kahaweonDec 7, 2011
speedplaneonMay 4, 2019
In my years of software development I had the fun but unfortunate experience of coming across not one, but two compiler bugs. The program would segfault on a seemingly innocuous line, but after looking a the assembly, it was clear the compiler was doing something screwy. These types of bugs are exceedingly rare, and they can be maddening to debug, but when you catch them you get a nice sense of satisfaction.
fireismyflagonAug 24, 2010
diego_moitaonDec 23, 2019
Code Complete is a problematic book. It has some good ideas but also has some very bad ones (cone of uncertainty, 10 times productivity in good programmers, etc).
Design Patterns is mostly obsolete. Functional programming techniques made a lot of Object Oriented techniques irrelevant (e.g.: observer pattern vs callbacks with lambdas).
Art of Computer Programming is the book everyone mentions but no one reads. A classic that people actually read is Structure and Interpretation of Computer Programs.
My recommendations: "Code" by Charles Petzold,"Don't make me think" by Steve Krug, Working Effectivelly with Legacy Code, by Robert Feathers, Clean Code by uncle Bob,..
randomsearchonSep 25, 2015
I really don't know the answer, but find it fascinating and can't wait to see what Facebook is doing in 10 years time.
H_Romeu_PintoonJune 5, 2017
It has good parts. But it has some very bad parts too, when it reinforces myths that, IMO, are very wrong (e.g.: cone of uncertainty, X times better programmer, etc).
I'd recommend to read it with care.
> - The Pragmatic Programmer by Andrew Hunt and David Thomas
After many years I still read parts of it, again and again. And I still like it.
andrewprockonDec 18, 2018
* The Pragmatic Programmer
* Clean Code
* The Clean Coder
* Domain-Driven Design
* Growing Object-Oriented Software, Guided by Tests
All of these books take the simple maxim:
"Be organized, and stay organized"
and spend thousands of pages expanding on that.
PJDKonJune 15, 2018
Read the "classics" - Code Complete, Pragmatic Programmer, Clean Code etc. Google "best books about programming" and you'll find plenty.
When you're reading think about the why. You're job is dealing in complexity and there is no one true way. Understand as many of the different ways as possible.
If you think an idea is weak, try and figure out a question that exposes the weakness (how does this handle a date before 1970?). Expect that sometimes this question will reveal the idea isn't as weak as you initially expected.
Remember you only need to solve the problem that's in front of you. If that problem doesn't seem easy try to break it up into smaller problems.
Complicated solutions are often bad solutions.
Complicated solutions can be good solutions.
Write your code for people to understand.
Advice on good writing is often very applicable to code... See Orwell(1), particularly "Break any of these rules sooner than say anything outright barbarous"
1.https://www.writingclasses.com/toolbox/tips-masters/george-o...
crispinbonFeb 14, 2020
I think they're assuming that everyone has read The Pragmatic Programmer. To quote the original DRY principle from there:
Every piece of knowledge must have a single, unambiguous, authoritative representation within the system
Note that this has only an accidental relationship with code duplication, and in some cases could increase the latter.
adamrmcdonNov 23, 2011
You were lucky because you consistently had the entire page width. For mine, because the book's formatting was pre-defined, the column width was variable depending on content type. I could have anywhere between 20 to 65 chars for code. The only place I had control was in the screenshots of code in Vim, but even Production decided to scale those down to make it fit.
wallfloweronJan 28, 2009
http://en.wikipedia.org/wiki/Fixing_Broken_Windows
RoboprogonFeb 8, 2015
Generally, programmers who are afraid of the command line aren't very good at putting textual commands into a program text file, either.
They will cling for dear life to code generators and other such facilities in an IDE. (but not the good kind of code generators that define an original source DSL to be expanded into otherwise unseen code by the build process itself, always the IDE based code generators that generate mountains of crap code that now must be read and saved in source control)
They will cling to rigid, bloated, frameworks that require that they fill in parameters in an XML file, and write (many, scattered) tiny pieces of code to fill in the blanks for that framework, but which allow little variation from the application style which the framework mandates.
Beware the illiterate, programmer, grunting at cave paintings on the wall (clicking pictures on the screen, only).
See also: Pragmatic Programmers - power of text/shells sections; Neil Stephenson - "In the Beginning was the Command Line" essay.
larrywrightonJan 9, 2015
All this to say: despite the negative comments here, this is worth your time to read.
JtsummersonMay 25, 2021
lawnonDec 27, 2011
* Song of Ice and Fire series. I never really liked fantasy but this series is wonderful. The TV-series (Game of Thrones) is okay but a far cry from the books.
* The Pragmatic Programmer. The best programming book I've seen. A must read for programmers I'd say.
* Introduction to Algorithms. Haven't really gone through it but so far it's been great.
pulkitsh1234onSep 16, 2018
Should you invest time in learning for interviews or your own personal growth once you are 2-3 years in the industry ?
I understand that both sets are not mutually exclusive, but where should you put your time on ?
Investing time specifically to give interviews: Leetcode, Cracking the Coding Interview, TopCoder, etc., may increase the chances of getting a better job then your current one (and will make you a better programmer too).
On the other hand reading books like 'the pragmatic programmer' and other classics, won't necessarily put you in a better position to get a better job (in most companies), but will surely make you perform better in the current one.
So, is it ok to put it this way:
* If you are happy with your job and you can see that you can stay 5+ years at the company (basically FAANG ?): Invest time in learning for personal growth (Design Patterns, Refactoring, etc)
* If you plan to switch / want a better salary / company sucks / <every_other_reason> : Invest time towards preparing for interviews specifically ?
InclinedPlaneonDec 22, 2012
kleer001onMar 2, 2021
We are legion (We are Bob) - Finally broke down and listened to all the praise. It wasn't misspent. What fun!
The Emotional Craft of Fiction - Can never have enough writing advice
The Pragmatic Programmer (20th anniversary) - Again, relenting to the pressure to read classics
gjm11onJuly 8, 2010
Norvig, Paradigms of Artificial Intelligence Programming (I agree with plinkplonk and am quoted on Norvig's web site saying as much; a good book about all of {AI, Lisp, programming}).
Hunt and Thomas, The Pragmatic Programmer (no big surprises but lots of little insights and very little I disagree with; nicely written).
Bentley, Programming Pearls (absolutely superb for the sort of low-level algorithm-heavy stuff that, er, hardly anyone does any more).
Cormen/Leiserson/Rivest/Stein, Introduction to algorithms (best single-volume algorithms text I've seen, but not for the faint-hearted; might be well supplemented with Skiena's The algorithm design manual, a very different sort of book).
dpritchettonDec 6, 2011
Full agreement on this point. Once I started looking at my own career from this perspective I couldn't stop. Books like The Passionate Programmer and The Pragmatic Programmer as well as heaps of prose from pg, patio11, edw519, and tptacek guide my continuing quest for increased leverage.
swansononNov 9, 2016
That has been my experience. The best book club discussions (we do probably 10 different groups a year for 5+ years at this point) have been for books like The Pragmatic Programmer, Rework, Lean Startup, etc -- ones that focus more on a methodology or have room for discussion about trade-offs. Framework/language specific books tend towards the reference material side of things and don't have much room for discussion. One exception is the Seven Languages in Seven Weeks book -- we would work the exercises on our own and then meet together to discuss and share our solutions.
TrevorBrambleonDec 1, 2009
I avoided The Passionate Programmer when it was called My Job Went To India, deterred by the title and lack of reader recommendation. Maybe I'll give it a look now. Somewhat related, I found Land The Tech Job You Love to be a comprehensive and insightful resource.
eranationonDec 12, 2012
Other resources that were helpful for me as well
Books:
Courses:
Open source:
Q&A sites:
and of course most coding related articles here on HN
edit: SICP has an online course at MIT OCW:
http://ocw.mit.edu/courses/electrical-engineering-and-comput...
it might cover a lot of things you know, but I think it's a must have for every developer out there.
amerkhalidonJuly 22, 2016
2. Pragmatic Programmer - A classic, learned many practical tips for day to day programming job.
3. Founders at Work - Motivated me to work on my side projects and be constantly learning.
justinweissonNov 19, 2009
It's disappointing that they don't discount The Pragmatic Programmer, as that's a book I wholeheartedly recommend to every working developer. I think that's still owned by Addison Wesley.
th3byrdm4nonMay 2, 2018
My mentoring CS professor's recommendations included these 5 books as well as the following:
* Pragmatic Programmer
* Gödel, Escher, Bach.
* Programmer Pearls
He also had a great deal of Computer Vision expertise/recommendations (his specialization / side job was as doing R&D for RED Cameras). Great professor, even better guy.
throwaway170805onAug 16, 2017
However, computer science and software development are not the same thing. If your primary goal is to up your game as a software developer, you might get more out of well-regarded software development books like "The Pragmatic Programmer," "Working Effectively with Legacy Code", or "Design Patterns."
Hope this helps.
dannywarneronJune 29, 2021
"Text manipulation languages are to programming what routers are to woodworking. They are noisy , messy, and somewhat brute force. Make mistakes with them, and entire pieces can be ruined. Some people swear they have no place in the toolbox. But in the right hands, both routers and text manipulation languages can be incredibly powerful and versatile. You can quickly trim something into shape, make joints, and carve. Used properly, these tools have surprising finesse and subtlety. But they take time to master. "
Quoted from https://flylib.com/books/en/1.315.1.37/1/
DeestanonMar 4, 2010
The problematic activities described here, overgeneralization and solving imaginary problems (aka Coding for A Rainy Day), are simply typical newbie mistakes.
Otherwise highly competent developers almost always fall into this trap early in their careers, so the important thing is to have someone experienced in charge of the project who can veto their weirder ideas until they mature.
I think every software company should hand out a copy of "The Pragmatic Programmer" to all new hires. It gives much good advice on how to not overcomplicate things.
cambalacheonNov 15, 2020
Also Pragmatic Programmers has very good books on both, written by the creators.
I love Phoenix but I will disagree with the OP in 2 points.
Yes probably Elixir/Phoenix will manage better thousands of concurrent connections, but if you are doing personal projects or are a start-up that condition is irrelevant in the meantime. So that only lefts us with the big established applications. That does not mean Phoenix is not good, it only means you will not notice a difference with Rails for most of your projects.
The second thing, that OP failed to mention is that the Rails ecosystem is at least an order of magnitude larger. From the gems available, job opportunities,developers available, instructional material, SOP for many tasks and so on.That is boring, but valuable.
madhadrononNov 13, 2020
Leo Brodie, 'Thinking Forth'
Roland, 'Program Construction'
Ullman, 'Elements of ML Programming'
De Marco, 'The Deadline'
Brooks, 'The Mythical Man-Month'
Skiena, 'The Algorithm Design Manual'
Hunt, 'The Pragmatic Programmer'
Stevens, 'Advanced Programming in the Unix Environment'
Stevens, 'TCP/IP Illustrated, Vol. 1'
Ross Anderson, 'Security Engineering'
Also, the Phoenix Project is a ripoff of Goldratt's 'The Goal.' I suggest reading Goldratt instead, and then think very carefully about what transfers from manufacturing to software.
vxpzxonJune 2, 2019
Also, you don't necessarily need to cover something completely in order to get started. And these will be useful mostly if your work is in some way part of a software product instead of being some "offline" analysis, model build or forecast. Just learning to use version control, to collaborate with other developers and to run tests goes a long way.
prpatelonOct 4, 2013
http://www.infoq.com/presentations/Simple-Made-Easy
The "Joy of Clojure" is the best book on understanding the mid and high level constructs and design of Clojure (and FP). It's not a beginner book though - for that the books from the Pragmatic Programmers or Oreilly are excellent.
smountcastleonAug 8, 2016
* High Output Management by Andy Grove https://www.amazon.com/gp/product/0679762884/
* Turn the Ship Around by David Marquet https://www.amazon.com/gp/product/1591846404/
* The Score Takes Care of Itself by Bill Walsh https://www.amazon.com/gp/product/1591843472/
For interns I give out these two books:
* The Pragmatic Programmer https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...
* The Passionate Programmer https://pragprog.com/book/cfcar2/the-passionate-programmer
samelawrenceonOct 15, 2015
"The Mythical Man Month" - http://amzn.com/0201835959
"Peopleware: Productive Projects and Team" - http://amzn.com/0321934113
"The Pragmatic Programmer" - http://amzn.com/020161622X
"Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams" - http://amzn.com/032182203X
"Joy Inc: How We Built a Workplace People Love" - http://amzn.com/1591845874
"A Lapsed Anarchist's Approach to Being a Better Leader" - http://amzn.com/0964895692
"Becoming a Technical Leader: An Organic Problem-Solving Approach" - http://amzn.com/0932633021
"Code Complete" - http://amzn.com/0735619670
sonecaonJan 9, 2018
If you passed that stage, I recommend the book The Pragmatic Programmer as a very good book on how to become a good software developer. The book Clean Code is a good starting point too.
Other than it depends on your circumstances. A good heuristic (particularly in frontend world) is to study the language, not frameworks.
OompaonDec 16, 2008
ivanmaederonJuly 18, 2014
But I've also heard about math PhDs write the sloppiest code code imaginable: functions 1000+ lines long, copying and pasting functions to add a parameter... (in production code for a software company, not a research project).
So like you said, math helps but I'd like to extend that thought and say that you can make bigger gains elsewhere. For example, if you're a sloppy coder and don't know math, go out and get a book like "Code Complete," "The Pragmatic Programmer" or "Clean Code" first.
binarynateonApr 7, 2020
1. The Pragmatic Programmer by Andy Hunt and Dave Thomas
2. The Clean Coder by Robert Martin
3. Design Patterns: Elements of Reusable Object-Oriented Software (the "Gang of Four" book)
The first two contain a range of advice pertaining to working as a professional software engineer. The third one, although very dated, is still a great resource for understanding many of the design patterns used in OOP.
lostphilosopheronApr 9, 2015
My go to recommendations:
http://www.amazon.com/Structure-Scientific-Revolutions-50th-... - The Structure of Scientific Revolutions, Thomas Kuhn, (1996)
http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master... - The Pragmatic Programmer, Andrew Hunt and David Thomas (1999)
Things I've liked in the last 6 months:
http://www.amazon.com/How-Measure-Anything-Intangibles-Busin... - How to Measure Anything, Douglas Hubbard (2007)
http://www.amazon.com/Mythical-Man-Month-Software-Engineerin... - Mythical Man Month: Essays in Software Engineering, Frederick Brooks Jr. (1975, but get the 1995 version)
http://www.amazon.com/Good-Great-Some-Companies-Others/dp/00... - Good To Great, Jim Collins (2001)
Next on my reading list (and I'm really excited about it):
http://www.amazon.com/Best-Interface-No-brilliant-technology... - The Best Interface is No Interface, Golden Krishna (2015)
alasdair_onDec 2, 2018
When I first read Refactoring, IntelliJ wasn't released yet and refactorings still needed to be done by hand. Automated refactorings are so incredibly useful when it comes to improving code quality over time that I don't know what it was we did without them.
JarwainonDec 19, 2018
Right now I've got:
- Design Patterns by the Gang of Four
- The DevOps Handbook by Gene Kim
- The Phoenix Project by Gene Kim
- Designing Data-intensive Applications - Martin Kleppmann
- Peopleware - Tom DeMarco
- Code Complete - Steve McConnell
- The Mythical Man Month - Frederick P Brooks Jr
- Growing Object-Oriented Software - Steve Freeman
- Domain Driven Design - Eric Evans
- The Clean Coder: A code of conduct - Robert C martin
- The Pragmatic Programmer - Andrew Hunt
- Building Evolutionary Architectures - Neal Ford
- The Design of Everyday Things - Don Norman
- Don't Make me think - Steve Krug
lawnonJan 6, 2012
I find that the best way to evaluate yourself is to look at your code all the time and think critically. Be careful not to overdo it though, maybe take a closer look in between projects or in some interval is fine.
What should you work on? What do you find interesting? I think you're a lot better off working on something you find interesting than forcing you into something that you don't find thrilling. As always you should do stuff you're not comfortable with: do some low/high level stuff, try a new framework or do something you think is hard.
I wouldn't obsess too much on how good you are compared to others, there's always someone better, period.
Instead focus on your relative improvement. If you read your old code (which you should) you should think "this is awful, I could write something better" or at least "this is ok... but if I did it this way it would be much better".
And finally read code, read books about code, try to code with other people and try to make something useful.
Some book tips:
The Pragmatic Programmer:
Read this!
Introduction to Algorithms:
If you don't know algorithms, here's a nice book for it
Effective Java, Effective C++, More Effective C++:
Just good practices
sergiotapiaonJan 14, 2013
1. Micheal Heartl's Rails Tutorial.
2. Pragmatic Programmers Bookshelf - Agile Rails 3.2 (4th Edition)
Both are a good start but delve far too much into unit testing with the horrific RSpec. When you're learning something new, you don't want to muddle with learning a DSL on top of things.
beatonJune 17, 2015
Read "The C Programming Language", by Kernighan and and Ritchie. Written decades ago, still accurate and relevant today. "The Mythical Man-Month", "The Pragmatic Programmer", "Design Patterns"... books like this will always be relevant.
Maybe a good rule is to stick to CS books that have been in continuous print for at least ten years.
afarrellonMay 1, 2014
It is foundational though: you won't likely write lisp in real life.
Good books to read about practical software engineering are sold here:
https://pragprog.com/
I'd start with The Pragmatic Programmer.
By copy-pasting things, you've gotten yourself into a habit of just banging things until they work. Now, you should approach things from a scientific prospective: try to understand why they work, then write something to test that understanding. Build coherent and clear mental models.
devinmcafeeonNov 12, 2019
Two I've enjoyed are:
"The Pragmatic Programmer" by Andy Hunt and Dave Thomas
"Clean Architecture" by Robert C Martin
That being said, no harm in deep diving individual languages. Secrets of a JavaScript Ninja by John Resig was an excellent introduction to JavaScript!
fernandokokochaonSep 16, 2018
2. "The Power of Your Subconscious Mind" by Joseph Murphy. Sold me on the idea of positive thinking, but generally I found the book crappy.
3. "To Kill a Mockingbird" by Harper Lee. The only nover on the list. Definitely a good read.
4. "The Pragmatic Programmer". I fell in love with the idea of "the network" of views and controllers.
5. "The Software Craftsman" by Sandro Mancuso. Great one. Made me recosinder a few (quite a few!) things in my workflow and project.
6. "Deep Work" by Cal Newport. Amazing one. Can't wait for Monday to implement some at work. I even ordered 3 more copies for my team.
npsimonsonApr 3, 2012
matsemannonDec 16, 2019
For patterns, "Head First" is a bit childish maybe, but the content is fine for someone learning to recognize patterns. "Patterns of Enterprise..." is also good, but more dry. I'd stick with one of those two. And then skip the one by GoF, unless you want to read the "original" for some reason.
"The Pragmatic Programmer" is probably the book that has shaped my work the most.
slowmovintargetonFeb 1, 2015
2) Create software (for about 10 years at least) for fun and profit. Assume others must read and understand your code. Write it for them. Also love the code you write. Find the beauty in solving problems elegantly and simply. You'll learn a lot.
3) Teach others how to create high-quality software, most especially focusing on "why". This keeps you thinking about what you're doing and leads to you finding ways to improve.
4) Listen and evaluate honestly when others criticize your choices. Maybe you did do it wrong or you don't have the whole picture. Have strong opinions, weakly held.
5) Repeat.
These aren't qualifications so much as guidelines for when people ask me how I got "so good." My title has been "Software Architect" for the last twelve years.
There's a lot more to it, naturally. Your biggest job as an architect is to extend the reach of the entire development team. Be it by writing libraries and frameworks for the project, mentoring developers, or creating designs and guidelines for developers to work within. Like a building architect, you are responsible for crafting and engineering the space in which people will live and work. For a software architect those people are the users, the developers, and the stakeholders. Your job is to strike the right balance between the three groups.
The reason you see so many posts in this thread deriding software architects is that as an industry we have largely forgotten what software architecture is. B-School and CIO Magazine have been selling executives on out-sourcing so that they don't have to "worry" about that kind of thing (and we're just now recovering from this). Capital "A" Agile came along and sold them another bill-of-goods that doing Scrum would fix all the issues.
For these and other reasons, the title basically came to mean "really good programmer" and was handed out as a simple promotion. But the real software architects are never just that. When doing their job properly, they become the foundation for excellent software development teams, and for excellent software.
valbacaonAug 11, 2020
"Unwritten Laws of Engineering" https://www.amazon.com/dp/0791801624
Originally meant for mechanical engineers, it provides specific and general non-technical career advice. It focuses on what we call “soft” skills today. This field puts so much weight into technical prowess that we often think of these “soft” skills as somehow beneath the “hard” skills. Nothing could be further from the truth. If you don’t spend time on learning how to navigate your career, you’ll be as well off as a dragster on the backroads: you’ll get nowhere fast. I only wish I could have read this book sooner; it would’ve saved me a lot of trouble early on.
"Becoming a Technical Leader" https://www.amazon.com/dp/0932633021
Don’t let the title fool you: this is not just for people planning on becoming a “Tech Lead.” It’s for anyone in the tech field, period. If you pickup this book you must work through the exercises to get the full effect. It will be worth it. It’ll be like having your own therapist, life coach, and mentor, except that it’s just you and a notebook answering very important questions.
"The Pragmatic Programmer" https://www.amazon.com/dp/020161622X
I consider this book 10x better than Clean Code and Code Complete combined! (Though that may just be because I read PragProg first?) As the name suggests, this book provides more tactics advice but also gives great career advice too. The most famous is to “learn a new language each year.” This kind of advice seems a bit much, but over my career I’ve had to write in over a dozen different languages, even though 90% of the code I’ve written has been in just one language, the ability to pickup new languages quickly and easily is a solid skill to have. And that’s just one particular tip from this book.
(These are excerpts from my suggested reads blog post: https://valbaca.com/posts/my-suggested-reads-3cie)
eddie_31003onJuly 7, 2014
1) Clean Code
2) Pragmatic Programmer
3) Patterns for Enterprise Application Architecture
There's some overlap in contents, but I feel they complement each other very well.
whimatthewonJune 3, 2017
If you make decisions reversible or abstract away the interface from the implementation, you may be doing it for nihilistic reasons, but still a decent idea.
Also, "good enough" is underrated.
user5994461onMay 3, 2019
How come you give this example just now? This can't be a coincidence. select() just caused us a major production outage.
FYI: select() is broken on pretty much all Linux kernels up to very recent ones. Doesn't work when there are more than 1024 opened file descriptors, not a lot for a server app. Side effects include crashing the application.
notoriousarunonFeb 18, 2021
These books will help you day-to-day with your general programming knowledge...
> Philosophy of Software Design https://www.amazon.com/Philosophy-Software-Design-John-Ouste...
> The Pragmatic Programmer https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...
> Clean Code https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...
> Mythical Man-Month https://www.amazon.com/Mythical-Man-Month-Anniversary-Softwa...
HCIdivision17onAug 10, 2015
But I do have two formative things:
Feynman's lecture on Cargo Cult Science is excellent, with this gem:
"The first principle is that you must not fool yourself--and you are the easiest person to fool. So you have to be very careful about that. After you've not fooled yourself, it's easy not to fool other scientists. You just have to be honest in a conventional way after that... I'm talking about a specific, extra type of integrity that is not lying, but bending over backwards to show how you're maybe wrong, that you ought to have when acting as a scientist. And this is our responsibility as scientists, certainly to other scientists, and I think to laymen." - Feynman [0]
I can't tell you how many times this has saved me in the field. Replace the word 'scientist' with '<YOUR DISCIPLINE HERE>' as needed. (And I think moreso for engineers than scientists, since safety absolutely requires this mentality.)
And I really like the ideas in The Pragmatic Programmer [1]. More than anything specific, the idea of not being married to any particular concept or solution, but rather to pragmatically chose what is correct then for that circumstance helps a lot. The book is opinionated, but reasonable, and copying that pleasant tone is a fast way to make allies when solving problems in a group. And it's a pretty good book to boot.
[0] http://neurotheory.columbia.edu/~ken/cargo_cult.html (and is an HN favorite, to be sure)
[1] https://pragprog.com/the-pragmatic-programmer (another HN favorite, though not always brought up in terms of engineering)
yuraonMar 1, 2021
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.)
neoviveonFeb 4, 2021
[1] https://learning.oreilly.com/library/view/the-pragmatic-prog...
tonystubblebineonMar 26, 2021
That's really what Medium aspires to be--a place worthy of a five dollar subscription.
Many people here probably end up on Medium repeatedly via Google search and yeah, the results are mixed. But also, it's worth noting that a lot of those results wouldn't exist at all without Medium paying and encouraging writers and editors.
What I hoped would start to take Medium over the top though was the addition of all of The Pragmatic Programmer books. That was paid for by other tech people who had already subscribed. (And I played a role in bringing them on board).
There's more coming. But overall, this is 100% Medium's direction and belief that a soft paywall is a better business and a bigger win for all parties than free & ad supported. So this paywall isn't going away, and it's really on them to do more to justify it.
TheMonarchonDec 20, 2012
Set up the CI/build server on your machine, have it email everyone when the build fails. They will see the use of the tool then, and when the team accepts it they will hopefully get an official server to host it on.
Write tests for your code, and when other devs work with you on issues, or break things, write tests and send to them "Hey, i wrote this test that shows the code you wrote is failing, can you make it pass?" Also ask others to make unit tests. You will have to write the bulk of tests. You probably know which others on the team are open to writing tests and working with you on the pocket of excellence. Get them involved first, and then the idea will spread. A good idea would be buy them copies of Pragmatic Programmer too.
No, you aren't process oriented. A software team that doesn't at least like the idea of automated builds, and tests is crazy. As far as if it's a good place to work and improve one's skills? That depends. In some teams you might never get them to adopt the pocket of excellence. If you are working in a place like that, then it's probably not a good place to work. But if you have a shot at converting them by just doing it on your own first, then it would be a great opportunity to get experience with setting up these aspects of a software shop. And you can put that on your resume, blog about it, etc. In that case it would be a great experience.
llamatabootonNov 6, 2014
mdemareonApr 6, 2008
1-4: Books on computer organization, operating systems, networks and distributed systems (I like the ones by Tanenbaum, but there are many).
5: Another about compilers/languages (the dragon book is a classic, but there are many others).
6: Something about Lispy-languages (e.g. SICP, but the Little/Seasoned Schemer is another favorite).
7: A book about algorithms. I have Knuth, but something less thorough covering a wider area may be preferable.
8: A book about the practice of programming. My favorite is The Pragmatic Programmer.
9: A book about software engineering as a profession (I recommend Peopleware.)
q-baseonJuly 5, 2018
ulisesrmzrocheonJune 17, 2018
I've learned that lesson the hard way I think. I read the Pragmatic Programmer early in my career but I don't think I understood it very well.
andycrollonJune 30, 2010
http://fivesimplesteps.com/books/practical-guide-designing-f...
It's more about the theory of design, but presented in an accessible style and 'web' context.
There's also the Pragmatic Programmer's 'Design for Developers' book, but I haven't gotten around to anything more than skimming that one yet.
http://www.pragprog.com/titles/bhgwad/web-design-for-develop...
Hope these help.
sjellisonNov 2, 2017
The Pragmatic Programmer, by Dave Thomas and Andy Hunt, is a fairly slim book that aims to cover the unwritten knowledge that experienced programmers have. It came out a long time ago, but it's one of those timeless classics. If you can read this book and everything in it seems obvious, you are probably the equivalent of an intermediate-level software developer.
Similarly, Code Complete, by Steve McConnell, explains how to think like a project lead. In contrast to The Pragmatic Programmer, this is a large book: it aims to cover many concerns. Again, the less that you know, the more value that you will get from it: if you are starting with no training in programming, this book could be immensely valuable.
harry8onMay 3, 2018
It's one thing to say, I'd do it different. I'd have this book, or that book, or my list would have more this focus or that focus. It's a whole different beast to claim this list is "poor." And it is stupid to do so without countering with a list of exactly 5 books. Yes stupid.
I have read all 5 books. All 5 are excellent books. All 5 are very highly regarded in the field of programming and computer science. The descriptions that are attached to the list in TFA are accurate and useful to anyone reading the list. If there's a book on that list you haven't read, I'd say read it. This list simply isn't in the same postcode as "poor" and the descriptions of it as poor can't back it up in a meaningful way. Maybe there's another reason why the general mood of this thread is hypercritical? Smells a bit though, don't it? Do you really think if Guttag submitted that list the tone here would be the same or would the whole "this book is better" comments be rather more respectful of the original list and author? I've stated my opinion and why. You may of course, disagree.
Here's mine, Petzold "Code", Kernighan and Pike's "Practise of Programming", "The Pragmatic Programmer", Abelson and Sussman "Structure and Interpretation of Computer Programs" (with video lectures on youtube), Richard Stevens "Unix Network Programming" or maybe "Advanced Programming in the Unix Environment" - Which betray my OS accent. I'm not sure it's better than Ana Bell's. You can decide for yourself on that point.
rmasononMar 29, 2018
BeetleBonJuly 9, 2019
The DRY principle was created by the authors of The Pragmatic Programmer, and as they formulated it, your example is not DRY.
DRY is about requirements, not code or logic. The specification of a requirement should exist in only one place in the code. It aims to reduce instances of "The requirement changed, and I thought I fixed all the places in the code, but I forgot one and it became a bug." If two pieces of code have very similar logic/code structure, but are tied to different features, then the DRY principle absolutely does not suggest you should refactor to make that logic appear in only one place.
Pretty much every time I've seen people complaining about DRY, they're complaining about something unrelated to the original DRY principle.
peelleonJune 14, 2020
Equally important are your soft skills. I would recommend reading The Hard Truth About Soft Skills: Workplace Lessons Smart People Wish They'd Learned Sooner by Peggy Klaus.
ThorinJacobsonJuly 27, 2018
I usually recommend:
* Code Complete (Steve McConnell)
* The Pragmatic Programmer (Andrew Hunt and Dave Thomas)
* Clean Code and The Clean Coder (Robert Martin)
* The Mythical Man-Month (Fred Brooks)
* Test-Driven Development By Example (Kent Beck)
I also recommend blogs for more bite-sized knowledge. Jeff Atwood's blog at https://blog.codinghorror.com and Joel Spolsky's at https://www.joelonsoftware.com in particular have been helpful to me.
droobyonMar 22, 2021
Here is Bob responding to OPs link: http://blog.cleancoder.com/uncle-bob/2020/10/18/Solid-Releva...
Stating:
“SRP) The Single Responsibility Principle.
Gather together the things that change for the same reasons. Separate things that change for different reasons.”
That’s a pretty clear delineation IMO.
p4wnc6onMar 16, 2016
IDEs exist for the same reason 7/11 exists. Convenience. You pay a higher price (lost productivity) to experience certain comforts (clicking a button instead of issuing a keystroke command).
My experience has universally been that IDEs only get in the way of focusing on creating. They might be necessary when you are literally just beginning with software and you need a lot of scaffolding to help you -- and I don't think anyone would begrudge university students using IDEs.
But not using a power editor once you are an experienced programmer is hard to understand. I mean, it's so important that it was even included as a whole chapter in The Pragmatic Programmer.
Paying the up-front costs of proficient editor usage is like paying the up-front costs of wearing braces so you can have straight teeth or wearing correcting shoes so you can walk properly. Of course it's more convenient in an absolute sense to simply not wear braces or corrective shoes. But that's not the point. The point is that the value you get from the outcome (e.g. straight teeth, proper walking, or dramatically increased productivity when developing) is far greater than the cost.
In other words, I think you're using a hyperbolic discount function. You are placing such a high value on absolutely immediate "focus on creating" that you incorrectly discount how much more focus on creating you would be able to do with the power of a real editor framework.
auslegungonSep 16, 2018
1. [The Pragmatic Programmer](https://pragprog.com)
2. Martin Fowler's [Refactoring Book](https://martinfowler.com/books/refactoring.html)
3. Kent Beck's [Test Driven Development: By Example](https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...)
4. [Thinking in Systems: A Primer](https://www.amazon.com/Thinking-Systems-Donella-H-Meadows/dp...)
5. [Zen Mind, Beginner's Mind: Informal Talks on Zen Meditation and Practice](https://www.amazon.com/Zen-Mind-Beginners-Informal-Meditatio...)
6. [Pragmatic Thinking and Learning: Refactor Your Wetware](https://www.amazon.com/Pragmatic-Thinking-Learning-Refactor....)
radicalbyteonDec 26, 2012
I'm surprised that you didn't mention The Pragmatic Programmer..
I think that a lot of the people here (and who read your blog) could do worse than to check out "Team Geek". It's about people, not programming, but the impact it has had on me is equal to PoEAA..
gravlaksonMar 6, 2015
I read the Pragmatic Programmer last year, and it was .. very boring. Most of the tips were like "doh, of course". It's a beginner's book, not for someone who have been trying to improve their code (and processes around it) already for some years.
kurtisdipoonMar 19, 2017
2. Learn to fail and feel good with that. And as above, to gain as much knowledge from that, as possible.
3. Learn to be confident enough to defend your solution.
4. Read as many non stricly technical books related to programming as possible. Ie. "The Pragmatic Programmer", "Rework", "Clean code", etc.
5. Don't take your job too serious. If you worry about your code after hours, stop! And if you can't, change your employer.
6. Everyone makes mistakes. Just try to not repeat them.
schoenonOct 21, 2016
There have been some long threads here about other people's evolution as programmers and what kinds of things they felt helped them improve. I don't have one in mind right now, but maybe you could find one.
You could also try reading a couple of software engineering books that talk about some of these concepts. Wikipedia mentions The Pragmatic Programmer, and there's also Code Complete and others. (I haven't read either of those.)
Here's a list of the best "software engineering" books, although the focus of these is incredibly varied and some probably wouldn't be relevant to you.
http://noop.nl/2008/06/top-100-best-software-engineering-boo...
DanielRibeiroonJuly 22, 2010
People who are passionate about what they do have a tendency to stand out (pg makes a similar argument on Amateur section of http://www.paulgraham.com/opensource.html).
If you are passionate enough about software development aspects, most HN articles will not feel overwhelming, as you will be constantly improving on your craft. But then you will know how much more there is to learn. Just don't feel overwhelmed then.
kolinkoonApr 6, 2018
The idea was to construct development teams in a way similar to the surgery teams - one lead developer, one assistant developer (these two "adult" and very good), and a 3-4 other people who
's job is to make the life easier for the main devs - someone to manage documentation, someone else to do detailed testing, one average dev to do the simple and boring stuff, and so on.
That way, in a company of a 100 devs, you'd need 15-30 super-smart developers (who don't need methodologies and scaffoldings), and the remaining 75 just junior/average specialists doing specific tasks and fitting into the structures provided by seniors.
ubernostrumonDec 18, 2018
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.
msurelonAug 9, 2011
i don't think you've really leveled up until you get past using phrases like 'Level Up'. You're not a 14th level Ranger with a potion of strength and +4 leather armor. You're supposed to be an engineer ( or software developer or pick your favorite name ) helping real people solve real problems.
anonymous-devonDec 21, 2012
About CI server, it is on its way but only for production release. No continuous build for now mainly because there is no unit test infrastructure setup.
About writing test, well, no one uses unit-test for the reason above. It maybe a good time to introduce that and get to show them the light :)
"In some teams you might never get them to adopt the pocket of excellence. ". I am a bit afraid of that. Why ? I have spent some time trying to change things and yet I see little or no effort from others.
What are you thoughts on documenting things ?
aaustinonAug 29, 2016
Good unit tests are absolutely crucial to any kind of future refactoring effort. They are helpful at finding regressions and give you some confidence that you do not break the paths that are tested. If you work in a team larger than one, code reviews are a must. Code reviews allow both participating parties the opportunity to learn, improve the overall codebase, and catch bugs. I also think writing code comments and documentation is absolutely important. Mostly so the "next guy" understands why the code is doing what it is doing. Most of the time the "next guy" ends up being you.
JabavuAdamsonDec 25, 2019
One lesson that often comes later in one's programming journey is that there are surprisingly, shockingly, many bugs that won't be found by just running the code. Like you're debugging one thing, and you find this other thing that has been in the shipped code for a year, intermittently causing crashes, but no one was the wiser. The "how could this possibly be working?" moment.
So, I fully embrace the idea of of incremental ground-up development, but running the code just to see if it crashes is too low a bar. Beginner versus craftsperson. I would suggest a high-value compromise is to single-step through any function that you just wrote. This has revealed a huge number of logic errors to me, even without writing additional tests. It's super low-hanging fruit that a lot of people don't even pick. I think that suggestion came from Code Complete, which although old, is still a great resource for beginning programmers. I also recommend The Pragmatic Programmer.
EDIT> Liked the article. Am also interested in standup. Also just recently had a very productive couple of evenings kit-bashing together some wood scraps where the tactile nature of holding a battery here, there, trying to orient it etc. seems to have been vastly more productive than sitting down with Solidworks or overthinking the early design.
pkruminsonDec 3, 2017
Can anyone comment how, if at all, these books are different from classics in the field, such as The Practice of Programming, The Elements of Programming Style, The Pragmatic Programmer, or Complete Complete?
I can't think of anything new that another book on writing good code could say, that hasn't been said already.
That's why I haven't looked at these books yet. It feels to me these books are like another book about Newtonian mechanics, there just can't be anything new.
Thoughts?
billturneronFeb 25, 2010
Rails 3 does have many improvements, but it's still a "beta" in every sense of the word as many of the plugins don't work yet, or require many modifications to work.
I still think just about the best book/introduction to Rails is the Pragmatic Programmer book: http://pragprog.com/titles/rails3/agile-web-development-with... - They don't yet cover Rails 3 yet, but in the meantime you could fill in the gaps with weblog posts and the like. If you get a solid grip on 2.3, you should have no problem adjusting to 3.0 once it becomes final.
trilinearnzonMar 19, 2020
I also have a few for purely nostalgic value, representative of key moments in my past. Notably: the OpenGL Red Book and C++ The Complete Reference.
MachaonMay 27, 2019
Nowadays, most students have a library of pirated PDFs, meaning they have the information on hand where they need it and with no need to return it or find it already borrowed in the college library. Most colleges will give you access to online databases of journals, so they aren't a draw either.
The other problem encountered was that of QC. At least in my institution more substantial books were always in short supply, as they'd never have more than 5-6 copies of a single book, so you'd arrive at the computing section and find... "Java 2 for Dummies". Or "Teach yourself C++ in 24 hours". Books that might have been fine to self-learners (when they were not significantly outdated), but nothing that wouldn't be covered in a textbook and nothing more substantial.
Probably this is a disconnect between the people running the library and the lecturers, but the attitude of the library was "Yes, we have software development books. What do you mean 15 years is out of date? The psychology books have been there since the 70s. And our figures show that more students have taken out 'Java 2 for Dummies' than 'Design Patterns' or 'The Pragmatic Programmer', so we don't need more copies."
But those two factors, the greater accessibility of pirated PDFs and blogs (and for some of the slightly more recent students, Stack Overflow), and the lacking quality of what was probably available on the shelves at any given point you chose to look meant that the library was definitely way more useful as a study space than for the contents of the shelves for the other students and myself during my degree.
pehejeonNov 6, 2019
That example sticks with me.
michaelvkpdxonDec 8, 2014
They're both big and both published by Microsoft. Two strikes, yes, but don't be fooled. These books have so many nuggets that I've gone back to again and again as a programmer. "Code Complete", in particular.
Neither book is a cover-to-cover read. They're both books you dip into for a tip, a skill, some perspective. But they've held up amazingly well, and for my money and time, they're both a step up from the Pragmatic Programmer. If you like what you found in "Pragmatic", you'll love "Code Complete".
I just wish it wasn't from MS, at the peak of MS evil in the 90's.
mattfrommarsonJune 29, 2018
I have a STEM (non-CS) degree but very recently, started working as a programmer. Doing my first internship at a 'techy' corporate company. One of the things I'd be doing on the side is to go through https://mitpress.mit.edu/books/elements-computing-systems. The video introduction to it just gives me goosebumps to this day. I don't know why. It's fascinating.
Than there is other paradigm books such as "pragmatic programmer", "Thinking Like A Programmer", "Design Patterns: Elements of Reusable Object-Oriented Software", etc.
So far, I've done plenty of reading on Algorithm & Design Structure and leetcode here and there. In the past, I didn't qualify for internship at Google, Amazon or M$ as a software developer/engineer. I feel the reason why I didn't was because I didn't have a "computer science" keyword mentioned anywhere on my resume. Hence, my hope is after getting through "Element of Computing System" & Design Pattern, I'll be able to shove in "computer science" keyword one way or another on my resume.
rodhanonApr 28, 2016
[1] https://www.goodreads.com/book/show/4099.The_Pragmatic_Progr...
[2] https://en.wikipedia.org/wiki/Broken_windows_theory
[3] http://www.artima.com/intv/fixit2.html
swansononMay 7, 2011
I would highly recommend both.
[1] http://swanson.github.com/writeup/2010/10/25/pragmatic-progr...
[2] http://swanson.github.com/writeup/2010/10/26/apprenticeship-...
loegonMay 2, 2019
poll() was broken on early versions of Mac OS X for quite a while[1] :-). And I thought I recalled select() being broken too, but might be mistaken. Looks like some reports of kqueue() being broken too.[2][3]
[1]: https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-...
[2]: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#OS_X_AN...
[3]: https://discussions.apple.com/thread/4783301?tstart=0
jonkeonMar 10, 2009
Chapter 3, Debugging, Rubber Ducking.
However, even if I agree with the great use I really use it more for code reviews than for actual hardcore debugging. (This could be my fault because I use distributed async processes in my work)
I think the rubber ducking has more advantage if you use a high level dynamic type language to code in (rather than more low-level C with pointers).
ndiscussiononMar 31, 2021
Another good one is The Pragmatic Programmer.
Lastly, this wiki is a gold mine of wisdom from hardened devs: http://wiki.c2.com/?StartingPoints
I really recommend you read lots and lots of those pages.
dylanhassingeronMay 29, 2011
Your wish list is all over the place. It would help to pick one of the goals listed (i.e. Ruby, or Node, or Python) and hone in on that. Once you figure out what language you want to learn, devour everything on the topic from these sources:
* Peepcode tutorials
* Slideshare slideshows
* Youtube videos or other longform tutorials
Get a Hello World example running in your new language, and then see if you can get it wired up to a database. Congrats, now you're up and running...
It's not sexy or new, but the book the Pragmatic Programmer is the bible on how to become a good programmer and not just a hack.
RE: How to build a web app - read Getting Real by 37signals, this will give you a nice high level approach. This is also a great introduction to agile development principles.
"but I never really have an itch to scratch" sounds like you're not brainstorming hard enough. Even in your post there's the seeds of many different itches. Find the most basic thing you trip over every day, and write a tiny tiny software tool to fix that problem.
Last but not least, sounds like you could use some more experience with front-end concepts. I recommend Bulletproof Web Design by Dan Cederholm as a great overview.
Technology moves too fast for anybody to keep up, just do your best and always keep learning! Good luck
davegaueronApr 2, 2021
The Pragmatic Programmer serves as inspiration for me every time I read it. I know everything in it, but somehow I always come away with at least one "I could totally be solving my current problem with this!" insight from a re-reading.
koblenskionAug 30, 2013
Code Complete, on the other hand, is a little more hit-or-miss. Some parts of it are still very relevant, like how to write clear, readable code. But other parts have been supplanted by better practices. The book tends to lean more towards waterfall development approaches.
mooredsonMay 25, 2021
Use programming adjacent tools that he is familiar with or wants to play with. Excel, html, no code solutions. This should be a low time investment but will either get him hooked or deter him.
Read some core books like "The Pragmatic Programmer" about general skills.
Pick up a friendly book like https://www.railstutorial.org/ for web development. I'm sure there are other similar books for other types of development.
cforsonNov 6, 2019
Does anyone have any recommendations for finding interesting papers? Do I need to buy subscriptions? Is there a list of “recommended” papers to read like we have with programming literature e.g. The Pragmatic Programmer?
b0rsukonSep 21, 2020
muzanionJuly 2, 2021
Something like React is the norm now. It's not necessarily any simpler or faster, but it's more efficient past N hours, which is the case for many larger companies.
It's also why functional programming has regained popularity, or at least writing functions the way you would for functional (immutable, output of one is the input of another).
However, we're still using a lot of old techniques. The best book on Design Patterns was written in 1997. Pragmatic Programmer was written in 1999 (though revisited a few years ago). The best TDD book is still from 2002; a lot of modern takes on TDD gets the philosophy completely wrong. TDD was meant to reduce fear, not improve test coverage.
diminotenonDec 18, 2018
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.
tonystubblebineonMar 27, 2021
vlovich123onMar 31, 2021
Generally, good software would have to be first defined and there's no universal definition. In most projects, I require it to have the following properties:
* New developers find it easy to ramp up on
* A handle on the defect rate (usually through adoption of best-practices like unit tests, fuzzers, automated tools, CI/CD, reproducible builds, etc).
* "Fires" infrequently enough relative to team size that it's manageable to accomplish your business goals.
* No "surprises" in adding new features/fix bugs where you didn't expect them.
* Meets business requirements today & can meet them tomorrow.
However, in other cases, like prototyping, "good software" means, "explores the problem space as quickly & cheaply as possible without worrying about any of those other things". Some of those other things can be useful in accomplishing this, especially if you plan to pivot from prototyping to the above definition. If you don't use them effectively then throw away your prototype before productionizing & start from scratch.
akprasadonJuly 24, 2017
shubhamjainonMar 6, 2015
I kind of believe that, have I not read the book, I would have stumbled upon the ideas later anyhow, by reading blogs, tinkering, and making mistakes. Albeit, it is wrong to expect any magical words that can shift your direction completely, but still I am not sure how much value do printed ideas provide vs learning them by experience. I am not implying that books like it are futile but I don't buy that they are "career-changing".
Same goes for reading about Design Patterns. I believe it is better to learn "Design Patterns" by building and reading code and finding a certain code organization better for your use-case, rather than enforcing a kung-fu-singleton-ninja pattern where it might be simply an over-engineering.
hsitzonDec 2, 2019
https://www.amazon.com/Pragmatic-Programmer-journey-mastery-...
yingw787onMay 9, 2018
Definitely check out "The Pragmatic Programmer"! There's definitely some good nuggets in there that helped me. Distinguishing full-blown prototypes vs. prototypical kernels that can be productionized, a.k.a. tracer bullet prototyping, is one.
jm4onJuly 21, 2009
fdsvnsmvasonSep 10, 2018
Robert C. Martin, Clean code: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...
Vaughn Vernon, various: https://vaughnvernon.co/?page_id=168
Steve McConnell, Code Complete: https://www.amazon.com/Code-Complete-Practical-Handbook-Cons... 2
Clean coder: https://cleancoders.com/ videos
Hunt and Thomas, The Pragmatic Programmer: https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...
Hitchhiker's Guide to Python: https://docs.python-guide.org/
Dustin Boswell The Art of Readable Code: https://www.amazon.com/Art-Readable-Code-Practical-Technique...
John Ousterhout, A Philosophy of Software Design: https://www.amazon.com/Philosophy-Software-Design-John-Ouste... This one looks particularly interesting, thanks AlexCoventry!
Kent Beck, Test Driven Development: https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...
Dan Bader, Python Tricks: The Book: https://dbader.org/
Ian Sommerville, Software Engineering: https://www.amazon.com/Software-Engineering-10th-Ian-Sommerv...
Svilen Dobrev, various: http://www.svilendobrev.com/rabota/
beatonJune 5, 2017
techbioonAug 31, 2010
Users get to see something early on.
Developers build a structure to work in.
You have an integration platform.
You have something to demonstrate.
You have a better feel for progress.
As a solo founder I need working code, that I can put out of mind, while I produce more.
BeetleBonJan 11, 2020
https://news.ycombinator.com/item?id=22022599
https://news.ycombinator.com/item?id=22022842
https://news.ycombinator.com/item?id=22022896
https://news.ycombinator.com/item?id=22022836
The author of this piece was not engaging in a DRY activity even if he thought he was. He (perhaps unwittingly) admits to it himself:
> My code traded the ability to change requirements for reduced duplication, and it was not a good trade.
The acronym DRY was coined in The Pragmatic Programmer, and the author of that book makes it clear that DRY is about not repeating requirements in code. You definitely don't want to deduplicate similar code if it involves multiple requirements because then you entangle yourself, which is what the author of this piece did.
anujmehtaonMar 22, 2019
https://pragprog.com/book/tpp/the-pragmatic-programmer
SchwoloponNov 27, 2012
At my work, our book club is (re)reading The Pragmatic Programmer. There's a section which advocates picking one text editor, mastering its arcane secrets, customizing it until it's perfect, and never using anything else. All my colleagues happily agreed with this, and I couldn't quite express why I didn't.
Then I did a bit of pair programming with a few different people. In every case there was a significant learning curve just to follow what the driver was doing in their comfortable editing environment, and in the most customized cases, it was nigh impossible for me to drive at all.
So we relocated to my desk instead. I have a standard qwerty keyboard with vim, emacs, and textmate - all completely un-customized and ready to go. I couldn't care less which editor we use as I've learnt the bare minimum to be proficient in all of them. And importantly, so have my colleagues. Sure they grumble at not having their own autocompleting magic, but we can get our work done at a good enough rate, and either of us can drive.
(My previous work took this one (enterprise management style) step further and forced everyone to use the exact same model laptop, operating system, and editor. As a youngster I hated this required conformity. As a cynical old bastard I can see the logic...)
I definitely sit in the middle of the two camps. Not 'The Best', not 'The Worst'; just 'The Satisficing'.
[1] https://en.wikipedia.org/wiki/Satisficing
pjmorrisonJune 5, 2017
Still a worthy topic, still worth your time. As was mentioned about 'The Pragmatic Programmer', I think reading this works best once you have a few years of experience.
jedwhiteonOct 18, 2010
It argues that as programmers, our base material as craftspeople isn't wood or metal, but knowledge, and with plain text we have the ability to manipulate knowledge with virtually every tool at our disposal.
http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master...
This blog post doesn't express things nearly so well as the book, but the argument has validity.
uxenthusiastonSep 11, 2020
Any if you can't find mentoring at your current position, try some books. My first mentors were Andrew Hunt (The Pragmatic Programmer) and Martin Fowler. Start with them, or find your own.
Code mindfully, go deep to understand every little detail of the code you write or read. Ask questions. A lot. Don't stop at the first draft. Don't stop a the first pass of questions.
Keep at it for a while. That one day you'll wake up with the feeling that the code you write yesterday was good. And hell if it's not a beautiful day to make it even better!
Get some CS background if you feel you miss it. https://teachyourselfcs.com/ gets one Hacker News every now and then.
Work on architecture/design. Try to understand design patterns for example. Be critical. Try to understand architectural decisions of the code you read.
Don't understimate the efficiency that comes with really being fluent with a language but do not give fluency too much credit either.
This is a lifetime journey. Improve step by step, little by little, every day. But improve mindfully. Get a direction. Get learning goals.
It's not a "try harder" it's juste question of better orienting the energy maybe.
That's my 2cents.
Good luck, I'm sur you can get, better you just need guidance.
cldropeonJune 9, 2012
The Pragmatic Programmer
Meta-programming at it's finest. Be a better programmer.
Joel on software blog:
Here's an example post.
http://www.joelonsoftware.com/articles/fog0000000043.html
There's quite a bit to learn in there.
Many other books available free online. Primarily I suggest you read to an end, and as you get to a stagnation point you alternate between reading to learn new technologies or languages and reading to improve yourself as a programmer.
robin2onMar 11, 2014
As to your point about whether they wrote any books on 'agile' I think it could be argued either way. More specifically, whether or not "The Pragmatic Programmer" (the book they made their name with) counts as a book about 'agile' is an interesting question, and one that throws some light on the wider debate.
Although they sometimes talk about "pragmatic programming" as if it were a thing, in the same way as XP and Scrum, their approach was more one of giving a smorgasbord of potentially useful techniques and practices rather than codifying a tightly defined set of best practices.
msluyteronJune 26, 2012
Editors seem to raise a lot of religious issues, and not to totally discount the distinctions that can be made between them, but I think it's more important to know your editor well than to worry about "the best editor." (If such a thing exists.) As Hunt & Thomas say in The Pragmatic Programmer: "use a single editor well."[1] You'll be most productive if you learn your editor from head to toe, than if you half-assedly know several. That takes some effort and conscious practice, sitting down and memorizing key combinations and the like. And a cursory glance at any editor might leave you unimpressed until you've gotten somewhat fluent with its features.
Just a couple of suggestions if you do use ST2:
+ get package control: http://wbond.net/sublime_packages/package_control/installati...
+ For rails, a couple of nice packages are RubyTest and SimpleRailsNav
+ Learn the multi-edit commands
+ Familiarize yourself with cmd-P/ctrl-P (osx/win)
+ Keyboard shortcuts: WIN: https://gist.github.com/1925069 OSX: https://gist.github.com/1207002, or look at Default (OS).sublime-keymap
[1] I would amend that to add "and also know vim at least a little" for stuff like sshing in to servers and whatnot.
pjmorrisonApr 24, 2020
thebigspacefuckonJuly 22, 2015
Learn design patterns, approaches to getting requirements, and how to read/create diagrams.
Learn how to write unit tests.
Learn source control tools and how to use them. If it's a command line, know how to do this from the command line.
Learn best practices for your language and get really good at your editor/IDE. (For instance, I use VIM with syntastic and pylint to check PEP8 compliance).
Learn to type quickly and accurately. This helps with everything.
If you've done those, enjoy your Summer! It's the last one you'll ever have :).
Some other things that would be fun:
- Set up a Docker image
- Write a REST API server in Python on a Linux OS
- Build in authentication, authorization, documentation
- Have Docker build and run your REST API server
- Set up a load balancer container to distribute load between multiple Docker containers
- Set up a shared cache like Redis or Memcache with containers
- Set up a MySQL Database
- Write unit tests for API
- Have Docker container automatically build, test, and deploy when you check in code
That will bring up a lot of questions of how you design things and how everything is tied together. Maybe you will just be working on a small part of this, but then you might know why things are done a certain way or how to do them better. That's where you can make a difference and distinguish yourself. You can bring a fresh perspective. Don't take anything for granted. Ask questions when they need to be asked. Learn how things can be improved.
breckonDec 7, 2011
I reread Pragmatic Programmer every year.
The other two you mention I find pretty poor, to be honest. I may reference them once in a while, but to really understand the topics they cover I'll rely on a well written, colorful article over those books.
In general I've found books written by more than 2 authors to be quite boring, impersonal, and oftentimes misleading.
Code Complete and Pragmatic Programmer are two of my favorites alongside C, and the Practice of Programming.
chernevikonSep 18, 2011
Caveat: I'm not a developer, so my comments about learning how to program should be taken with considerable skepticism. But I have some opinions based my effort to learn.
For me, programming syntax is less a problem for me than poorly organized code, poor grasp of problems and poorly thought out solutions. Design is a subtle and important topic that does not lend itself to the shorter coverage typical of internet material. Book-length immersion in the concepts is only a beginning to an understanding. So I think your "internet only" restriction is a severe constraint.
But it isn't as if there are many design books for beginners. These generally target people who've mastered some languages and know the design-problem space. "Pragmatic Programmer" was a big help.
I have found test-driven development an enormous help. It feels cumbersome, but you always know what problem you're trying to solve. "Test Driven JavaScript Development", Johansen, is an excellent overview of the approach. I'm also trying to work through Beck's "Test Driven Development By Example" doing the exercises in Ruby, but it's a side project that hasn't gotten much attention.
I repeat: I'm not a developer. Hopefully this is thought-provoking, but I'm no authority.
q845712onMar 31, 2021
Personally I find I still frequently write pretty atrocious code on the first draft, and it's only by stepping back from the problem after demonstrating to myself I understand it well enough to solve it at all that I can begin to write a more graceful solution. But deadlines and reality being what they are, I think the majority of us are embarrassed by our past code a majority of the time.
So don't be too hard on yourself, but also frankly don't worry about shoe-horning yourself into "A Career" either. They're kind of a recent invention and the whole concept might need a few more iterations. You could spend a few years as a Product Manager, an Engineering Manager, a Highschool Teacher, or a Business Analyst, leveraging your past experience to gain competency in a new niche.
I want to emphasize of self-awareness you have is commendable and not universally present: If you can realistically assess your own current skill level and then apply yourself to improving, you could be an above average software engineer before you know it. And right now it seems like so so many companies just can't get enough software engineers, so it's a pretty safe place to practice learning how to learn while also earning a decent income.
mooredsonJuly 28, 2021
https://letterstoanewdeveloper.com/
There are some other books covering similar ground.
From my book proposal and other research, here's a set of books/sites I'd recommend:
I'll be interested to see what else is suggested here.
valwonSep 27, 2019
This book contains some of the deepest programming insights I've encountered, to be put on the same level as SICP or the Pragmatic Programmer.
The discussions on naming and abstraction are particularly illuminating, exposing some fundamental tradeoffs like synthetic vs natural names, or principled vs adaptable systems of abstractions. Were these notions more widespread, a lot of the pointless rants and debates we hear in programming circles would disappear.
I would not recommend this book to beginners - this book is most useful when you are experienced enough that your struggle is to make choices, not to get things to work.
ignoramousonAug 9, 2019
For instance, reading The Pragmatic Programmer and JavaScript: The Good Parts early-on changed my professional life irrevocably, both in terms of programming and career.
I am sure there are various other books like those that truly are impactful, and it doesn't hurt to look up recommendations for those from people who are experts / polymaths.
The case against wikis (with the exception of design docs) and blog posts is that they are erratic, restricted, unedited, stale, and low on pedagogical focus. Some of the books are meticulously structured-- there's no comparison.
otodiconJune 5, 2017
phesonOct 8, 2016
https://neil.fraser.name/news/2015/04/13/
But like others in this post I would recommend CS unplugged.
And depending on how long he is in there for he might want to look at:
How to Design Programs - This is a good book, and although it's in Scheme, it teaches how to create appropriate levels of abstraction, which seems to be something many programmers struggle with.
Concepts, Techniques & Models of Computer Programs - Discusses the different paradigms and how they are inter-related.
Also something a bit more vocational like The Pragmatic Programmer or Clean Code / Clean Coder probably wouldn't hurt either.
If he can read all of those he will be very well prepared to do some actual programming when he gets out.
SICP not a bad shout either, although I've not got past the first chapter.
maeon3onAug 6, 2011
IBM's watson, the best thing we got going for artificial intelligence, is it written in lisp? NO, it's written in java. The link from lisp to artificial intelligence is a lie. Lisp is just a very poor language, it's designed to get eager novices working on things that are irrelevant so they will learn (the hard way) that being a good programmer means laughing at the people who promote lisp as "an epic language". Lisp had its day, somewhere back in the 1950's/1960's. That day is gone.
If I'm working on any sort of problem needing a programming solution, and someone suggests we use lisp, I buy that person a copy of "The pragmatic Programmer", and tell them to read it closely.
dmuxonJan 17, 2015
kentfonJuly 22, 2016
Fooled by Randomness, Taleb
Linchpin, Seth Godin
SloopJononDec 8, 2020
arthurjjonMar 27, 2018
"Working Effectively with Legacy Code"^1 is usually what I recommend instead. It felt like a more up to date approach
More generally "The Pragmatic Programmer"^2 is a classic for a reason. But from you're comment you've probably already read it.
1. https://amzn.to/2I4rIWP
2. https://amzn.to/2GfxVTa
2.
RoboprogonJune 9, 2014
I don't really think that the people who left perl all went to PHP.
Now if only there was a "Ruby lite" that ran more like Perl 5 (skipping the GC for reference counting and a few other performance shortcuts)
donretagonFeb 10, 2016
RoboprogonOct 4, 2011
I'm sure my use of Scala would disappoint the first interviewee, but it was an effective use-case for me. Use the index on the book to scan for likely topics, then round things out with Google.
I found the IDE support a bit broken in NetBeans (6.9). I suspect that the Scala plugin was incompatible with my vi/vim plugin, but I'm not sure. (it would go into a mode where the editing keys would stop working)
6ak74rfyonJuly 3, 2018
Related question: do you guys have a similar system for research papers? I've tried reading them a lot but have successfully made it through only a few. At this point, I even question if the effort in getting through their drudgery is worth it.
SilhouetteonApr 20, 2018
Longer answer: Basically, you need to get away from the world of front-end web development, and from the echo chamber blog posts and conference talks by people who have only ever worked in that area. No-one is writing anything large, high-performance, high-reliability or long-lived there yet, so you need to look for experience from people who have had to do those things in other contexts instead.
Classic books like Code Complete and The Pragmatic Programmer, early "serious OO" books like Design Patterns, and practical advice books of a similar generation in the Effective <programming language> style all contain a wealth of knowledge and insightful commentary. Of course some of the technical details are quite dated today and some of the specific techniques discussed might no longer be considered good practice a decade or two later, but many of the underlying principles and the discussions around them are as relevant as ever. A bit more recently, there were interesting discussions about a broad range of programming issues in Beautiful Code and the related titles, and there have been some interesting case studies based on open source software too.
If you want to read some shorter pieces online, I recommend finding a few authors who work in fields like games or embedded software, where there are often significant performance and reliability constraints to deal with, not to mention hard deadlines that force difficult decisions and compromises. There are some healthy doses of reality in there that you won't find in less demanding environments.
Enterprise applications, while often considered bland, can also be large and some of the longest-lived software we develop, and much has been written about organising and maintaining them, including real-world pressures like changing operating environments and large development teams whose members come and go. Perhaps a little ironically, this now includes a fair bit of back-end web development. Some of the writing around this is well worth a read as well, but beware that this part of the industry is plagued by consultants who talk a good talk but don't have much of a track record or other evidence to back up their advice. Approach with caution, particularly anyone who uses words like "agile", "lean", "craftsmanship" and anything else on the buzzword scale.
chana_masalaonJuly 19, 2021
I am currently listening Designing Data Intensive Applications and it's phenomenally done - the author clearly worked with the narrator to adapt the content to audio format, and the narrator seems to have experience or familiarity with the subject because he pronounces the technical jargon very naturally.
I hope to find other software related audiobooks as good as DDAI is.
ryan-allenonJune 16, 2010
I fell into programming by accident at about 21, and I remember what it was like, it's much as you described. Fun times!
All the advice here is good, but nobody has recommended you read "The Pragmatic Programmer", which I found to be a bit enlightening. I still go back to it years later to read and ponder.
Good luck! You sound like you wont need it. It's a damn good career for those who enjoy it and are willing to put in some effort.
EDIT: I never did a CS degree, but considered doing it many times (if work dried up, it never did). I believe though that the people you meet and work with is a major part of doing a degree, so that'd be why I would go. I get to work with good people anyway. This article was posted on HN recently and I think is relevant:
http://sheddingbikes.com/posts/1275258018.html
I admit there are CS-type stuff I can't do (but I know where and who to ask) because I never did a degree. Saying that though, I have worked with people who have had CS degrees and couldn't code themselves out of a paper bag. If I were to go back in time to when I was your age, I'd do the degree, though.
beatonFeb 12, 2016
The implementers of the legacy code aren't stupid. It's very common for junior programmers, tossed into the swamp of some codebase that's been around for years through many different hands, think the code is junk and the original implementers were fools. Usually, it's just that the problem is much more complicated than the juniors understand, and that's how the code got that way.
New tools probably won't solve the problem. There's a tendency with junior programmers to whine about the antique tools in use, convinced that the new Foobaz framework or Language X will magically clear up the issues they encounter. But the problems with code usually aren't from the tools used to build the code - they're from failure to understand the requirements, and time/scope/resource constraints on development.
Perfect isn't as important as finished. It's easy to get caught up in perfectionism. It's a good excuse to avoid releasing something you find embarrassing into the world. But the more time you squander polishing that turd, the less time you have for the next tur... er, cool new project.
If you can't write a test for it, you don't understand it well enough. Writing good tests is hard. It's easy to fall into a trap of "That's too hard to test. I'll just sort of check manually to make sure it works". This will bite you in the ass later!
(1) My first really good bug as a junior programmer actually was a "SELECT is broken" kind of problem (technically, mmap() was broken). I went to a great deal of effort to prove to the senior programmers (and then IBM) that my code was actually correct and I had an OS bug. And if some junior programmer came to me today and said a deep system call like mmap() was broken, I'd laugh at her and tell her to check her code. So sometimes, SELECT actually is broken - just not as often as junior programmers think.
nostrademonsonAug 20, 2014
Write code first. Write code until your programs collapse under their own weight. Then go out and read what the masters have written. You'll understand it much better when you have personally faced the problems that they were facing.
dshahonAug 16, 2009
If you're going to write commercial software for a living, it's useful stuff to know (or be reminded of).
rueonNov 27, 2010
All of that is a long-winded way of introducing the suggestion that you learn to program by programming. The second-best is understanding others' programs (select well-respected, progressively larger codebases). Books, suggestions of which I hope others will provide, may give you some good ideas and thought patterns. "Software design" is a vast field with tons of completely obsolete advice, and terrible amounts of overengineering. Perhaps something like an agile workflow book, "The Pragmatic Programmer" once you can construct programs.
DannoHungonDec 5, 2013
kentfonJune 5, 2017
nirvanaonAug 20, 2011
I learned it reading Armstrong's book from Pragmatic Programmers. It was a joy. I'm also reading the OReilly book, and it seems good as well, though I can't tell how it would be if I didn't know the language already. As for the titles-- one is Programming Erlang, and the other is Erlang Programming!
ishmaelahmedonJune 5, 2017
trilinearnzonJuly 26, 2021
Applying Domain-Driven Design and Patterns was the book that made me fall in love with software engineering. Perhaps a little dated now though.
Head First Design Patterns - I never grokked any of the patterns from the GoF book, but this one 'clicked' for me, if you can get past the cutesy presentation.
Peopleware - Shows importance of focusing on people, rather than the tech, as this is often the main cause of project failure in the software realm (and perhaps others).
chollida1onDec 8, 2020
Having read it a few times since I think it falls into the same group of books as Mythical Man Month, Peopleware, and the Pragmatic Programmer where the earlier in your career you read it, the more you'll get from it.
Reading these books after 20 years of programming I found that I really struggled to find anything useful to take away from them.
It's not that these books are bad, or out of date. It's more that they exposed some new ideas at the time that, to the books credit, have been picked up and made mainstream or basic/required knowledge for the working programmer
tonystubblebineonMar 24, 2021
But the main one is about the need for urgency.
One basic way to read these changes is that it just looks like Medium getting savvier about what drives and grows their subscription business. There's been no pivot there. The challenge for them still is to get their subscription business over the hump.
And the hump they have been at for awhile is that the subscription has been growing despite being generally meh quality. It's just $5 and a lot of people like supporting authors that way. But what are the ways to go from meh to great?
What I think Medium found is that they were getting better value by spending in other places. For example, I was part of bringing the back catalog of The Pragmatic Programmers books onto Medium. That was a deal that was relatively economical and had a direct hypothesis related to growing the subscription. For programmers now, at least, they have a nice headline for why a programmer would spend $5.
So to see Medium focus more on what's working to actually tip the subscription over puts me at ease because I still see the company has being in a zero to one situation. It could succeed, but it hasn't yet.
SwizeconAug 3, 2021
A similar effect can be found with Grit, Fogg’s Behavior Model, Superforecasting, and most Gladwel books.
On the coding side, I’ve only noticed this with Pragmatic Programmer, Clean Code, and maybe Phoenix/Unicorn project. Could I don’t read enough of those or they’re too focused on specific technologies instead of broad ideas … or I get too much of my technical reading from blogs and twitter. Those do get repetitive and you quickly find common patterns, but no titles to refer to.
kyleconJuly 9, 2008
http://www.reddit.com/info/6mikl/comments/
but it looks like you've beaten me to it!
I did create a listing of the most popular books mentioned on the comment thread, if you're interested. The following were mentioned by 4 or more people:
14 The C Programming Language
11 Structure and Interpretation of Computer Programs
8 Introduction to Algorithms
7 Compilers: Principles, Techniques and Tools
6 Programming Erlang
5 The Mythical Man-Month
5 The Pragmatic Programmer
5 Applied Cryptography
4 Beautiful Code
4 The Little Schemer
4 Programming Perl
more here: http://www.reddit.com/info/6mikl/comments/c04abpy
nickknwonAug 8, 2012
Maik Schmidt is the author of this book.
> Maik Schmidt has worked as a software developer for nearly 20 years and makes a living creating complex solutions for large enterprises. Outside his day job, he writes book reviews and articles for computer science magazines. He is the author of Arduino: A Quick-Start Guide, Enterprise Recipes with Ruby and Rails, and Enterprise Integration with Ruby for Pragmatic Bookshelf.
_nh_onJuly 7, 2014
My suggestion: don't read another book until you've read this.
davegaueronJuly 27, 2018
I also appreciate being able to browse the small selection of fiction/non-fiction at our local branch. As with the bookstore, I often pick up things I wouldn't dream of searching for online and would therefore never have found.
I likewise wish my library system had more of a "long tail" stored somewhere.[1] Older books (no matter how popular and well-known they were at one time) are often simply not available.
I had practically written off libraries when I was in my 20s:
* The hours didn't mesh well with my work schedule
* I could afford to buy whatever I was interested in
* They never had the up-to-date programming books I wanted/needed
That has changed completely now that I'm a parent. And yes, I do think libraries need books. Communities need books. This stuff needs to be available, even if just in principle.
I was skeptical but surprised to find that my local library system has one copy each of:
* Introduction to Algorithms
* The Art of Computer Programming (vol 1)
* The Pragmatic Programmer
But the list of computer science classics they don't have is far larger. What they do have are a ton of of titles like _Teach Yourself Visual Basic.NET in 21 Days_ (real) and _Excel 14.2.32.rev13 for Boneheads_ (made up). No doubt it reflects what patrons are requesting...but I would personally wish for a collection that leans a little more heavily on the perennial classics.
[1] http://www.dlib.org/dlib/april06/dempsey/04dempsey.html
a_a_r_o_nonDec 22, 2011
It talks about what to do, in your life as a programmer, and how to approach it.
EDIT: http://www.codinghorror.com/blog/2004/10/a-pragmatic-quick-r...
sanderjdonOct 9, 2019
The other important difference, and the reason there is always strong pushback when this topic comes up, is that many of us believe there is a subtext that people who spend a lot of time outside work on side projects are better employees. (I mean, it isn't even really subtext, it is in the text of the OP, and I've been reading the new edition of The Pragmatic Programmer, and it's in the text there as well.) If that view wins out (and in many circles it already has), then what you see as harmless, fun, and enriching side projects are actually a job requirement, one that is extremely hard for many of us to satisfy. So we (reasonably, I think!) push back on this view because we think we're good programmers and good employees without needing to spend our evenings doing solitary work away from our friends and families.
adolfopaonAug 26, 2012
- How to design programs (http://htdp.org)
- The Little/Seasoned/Reasoned Schemer.
- Code: The Hidden Language of Computer Hardware and Software by Petzold
- Coders at work by Peter Seibel
- The Pragmatic Programmer by Hunt and Thomas
- Code Complete by McConnell
For intermediate/experienced people:
- Structure and Interpretation of computer programs (http://mitpress.mit.edu/sicp/full-text/book/book.html)
- Software Tools in Pascal by Kernighan and Plauger.
- Programming Pearls by Bentley
- Smalltalk 80: The Language and Its Implementation by Adele Goldberg.
- Paradigms of Artificial Intelligence Programming by Norvig
- A Discipline of Programming by Dijkstra
While I've ommited some important language specific books, and ignored essential areas (algorithms, discrete math, hw arquitecture), I think this is a good starting point.
msluyteronJuly 22, 2016
2. The Pragmatic Programmer -- a classic. Reminds me that I need to re-read it.
3. Effective Oracle by Design, by Tom Kyte -- Not that I use Oracle any more, thankfully, but really provided a lot of insight about how databases function and how it pays to deeply understand their internals when writing webapps.
brlonMay 14, 2010
I would recommend getting a copy of both of them, but you might want to check out the online version of the O'Reilly book before buying it:
http://programming-scala.labs.oreilly.com/
The Pragmatic Programmers book is not bad either, but it's only a short introduction to the language compared to the other two books mentioned.
All three books have nearly identical titles: Programming (in) Scala
dboydonDec 14, 2010
Code Complete: http://cc2e.com/
Introduction to Algorithms (google that one, it's hard to find a good link)
Domain Driven Design: http://domaindrivendesign.org/books/evans_2003
Design Patterns: Elements of Reusable Object-Oriented Software
The term "web development" doesn't mean much. There is web design. There is application development. When the two mix, there is web application development. Any kind of application development is hard, and simply knowing a language or two isn't going to make you a good application developer any more than knowing english will make you Stephen King. (IMO)
pietrofmaggionNov 22, 2010
xupybdonMay 14, 2017
You can get learn a lot building your own apps, but then you're forced to learn some lessons the hard way. Sometimes you can avoid making mistakes by learning from someone with years of experience. You don't need to take a course, but reading can help so much. Books like The Pragmatic Programmer, Code Complete or Literate Programming can set a good base for thinking about your code.
Also to address the how self taught programmers get jobs, it's worth pointing out that the first question was from a 17 year old. I'd say it would be tricky at that age to get given a chance by an employer. So with time and age their employ-ability should increase as a factor of age alone.
abponOct 25, 2010
I immediately thought of his metaphor with the woodworker and his toolset, that needs skills build on it, as well as the working material.
matwoodonMar 26, 2012
Some books are references and some are read throughs. I read Code Complete while in college and thought it really helped my programming. Effective Java is another great book that I've read. The Pragmatic Programmer is another one that I've read that really is worth the time.
Many books are just good references though. Pick it up and read a chapter for example. I think the more experience a programmers gets the less they need to read right through a book. When looking at a book on a particular language I can usually skip the first half because I know the parts that are common across most languages. I only need to know what's different/cool/idiomatic in this particular language.
Algorithm books are another example that falls into mostly the reference category. I don't think I've read any entire algo book, but I have read many chapters from many different algo books that touched on what I needed to learn at the time.
getsatonFeb 20, 2012
diego_moitaonJan 2, 2013
Given this, there are some books you might add or remove depending on the area you are interested (e.g.: Knuth's "Art of Computer Programming", Martin Fowler's "Patterns of Enterprise Application Architecture", ...)
To finish, 2 books people recommend a lot for beginning programmers:
"The Pragmatic Programmer"- Hunt, Thomas: a very good book, with sound advice and very easy to read. The only bad side is that it became so influential that its ideas became vulgarized in thousands of blogs.
"Code Complete" - Steve McConnel : A very dangerous book. It does give have a lot of sound advice. But, IMO, it has some big problems. First is that it gives the false impression that there is a lot of empirical evidence on what works on software engineering. Second, it perpetuates some myths that don't have such evidence: the "orders of magnitude programmer's productivity" and "the cone of uncertainty" (see: https://leanpub.com/leprechauns).
hendrikmakaitonApr 23, 2021
A few classics that focus on improving "general code style" would be:
- "Clean Code" (https://www.oreilly.com/library/view/clean-code-a/9780136083...)
- "The Pragmatic Programmer" (https://pragprog.com/titles/tpp20/the-pragmatic-programmer-2...)
EDIT: Since you are talking about coding like at a top company, one book that has been sitting on my shelf for a while, but I haven't gotten around to reading yet is "Software Engineering at Google: Lessons Learned from Programming Over Time" (https://learning.oreilly.com/library/view/software-engineeri...)
espinchionNov 13, 2011
The Pragmatic Programmer (Andrew Hunt)
Cashflow Quadrant (Robert T. Kiyosaki)
dionidiumonJan 12, 2014
I think more people read those books and say, "yes, I agree with all of this already" than read them and think, "oh, here is a new thing I haven't thought before and will use from now on."
larrywrightonFeb 5, 2019
From a technology standpoint, "The Pragmatic Programmer" changed the way I looked at programming. When I read it the first time, I was a Visual Basic programmer, with only a passing familiarity with the world outside the Microsoft ecosystem. After reading that I began to explore Perl, then Python, and installed Linux and learned it. For my career as a developer, then team lead, and then manager, that book changed me more than any other book I've read in the field.
ryanaronDec 30, 2018
kumarvvronJune 15, 2019
Is it worth reading JS based software engineering / design books, as compared to Code Complete or The Pragmatic Programmer?
johnwatson11218onMay 9, 2017
They had a function like this:
double f( double x ) { return 1/ x; }
They pointed out that it is trivial to get 100% coverage in test cases but unless your tests include passing in 0 as the parameter you are going to miss an error case.
barkingonJuly 28, 2018
That's exactly what I do use.
I started doing this after reading "The Pragmatic Programmer" where it's argued that the DRY principle should apply to everything including documentation.
It starts with the bug tracker. So when entering something in that I'll also add the text that I want to appear in the changelog for the user to see (these lines will have a // at the start).
When a bug/feature is completed a commit is made and the text in the bug tracker is the commit comment.
If the commit comment has a line starting with a // then that line will have another line inserted above it //Bug fix: or // Feature:
Finally on building the distributable the changelog is constructed entirely from the lines in the commit messages that start with //
mitchelldeacon9onMar 28, 2020
Bowden, Mark (2011) Worm: The First Digital World War
Brooks, Frederick (1995) Mythical Man-Month, 2nd ed.
Christensen, Clayton (1997) Innovator's Dilemma: When New Technologies Cause Great Firms to Fail
Hafner, Katie and Matthew Lyon (1996) Where Wizards Stay Up Late: Origins of the Internet
Hunt, Andrew and David Thomas (1999) Pragmatic Programmer
MacCormick, John (2012) Nine Algorithms that Changed the Future
McConnell, Steve (2004) Code Complete, 2nd ed.
Mitnick, Kevin and William Simon (2002) Art of Deception
Poulsen, Kevin (2011) Kingpin: How One Hacker Took Over the Billion-Dollar Cyber-Crime Underworld
Raymond, Eric (2003) Art of Unix Programming
Stone, Brad (2013) The Everything Store: Jeff Bezos and the Age of Amazon
Torvalds, Linus and David Diamond (2001) Just for Fun: Story of an Accidental Revolutionary
Wallace, James and Jim Erickson (1992) Hard Drive: Bill Gates and Making of the Microsoft Empire
Williams, Sam (2002) Free as in Freedom: Richard Stallman's Crusade for Free Software
Wilson, Mike (1996) The Difference between God and Larry Ellison: Inside Oracle Corp
kidmenotonJuly 24, 2017
Saying that whoever recommends Code Complete made some wrong life choices is a bit rude and uncalled for. Books are just tools, the benefits they bring depend on whether the reader goes through them in a smart way or not.
Then again, but this is a matter of taste, I would suggest The Pragmatic Programmer as a first read. It's shorter, well-written and with laser-like focus on the topic at hand.
Lastly, since designing and writing software is as much of an art as it is science, what's really important is to avoid reading passively and blindly applying anything the knowledge one finds in a book, and instead strive to understand why, and going against the grain and see why certain practices are called "best".
SloopJononSep 19, 2019
I didn't get much out of The Pragmatic Programmer myself. Maybe if I'd read it ten years earlier, it would have been my Code Complete.
timronDec 6, 2011
Code Complete is a fine book. The Pragmatic Programmer is okay. But neither book holds a candle to Introduction to Algorithms for career-long usefulness. For that matter, neither one holds a candle to Design Patterns for the ability to expand your mind and improve your ability to think about code (I read both at the same time, and Design Patterns is the only one whose lessons I remember distinctly, years later).
I think the main problem here is that the easy, mechanical reads get more votes than books that are harder, but more valuable. It's the technical equivalent of a lolcat photo.
sansnommeonMar 28, 2020
Avoid pop finance books that is light on numbers. If you want to understand the qualitative aspects/culture/history, books like Flash Boys or Flash Boys: Not so fast are more than sufficient. Stay away from "technical" books that are designed for layman and non-technical readers. They will handwave Black Scholes and economic math and you will simply be going through the movements without truly understanding.
Books like Reminiscences of a Stock Operator are great secondary books to supplement your primary readings. You don't give a beginning programmer Pragmatic Programmers/Clean Code/Programmers at Work when he or she can barely write a hello world, let alone a quicksort. You want a intro to programming course followed by something like SICP to lay in the foundations of abstraction and computer science. It is the same for finance. Half of the books in this thread are either financial pop science or has little relevance to somebody who wants a rigorous understanding of how the stock market system works.
Also to note, Buffet and A Random Walk Down Wall Street are books that espouse certain schools of thought on managing portfolio. Judge them by their history and backtest their theories rigorously. It is like Object Oriented Programming, fads wax and wane with time and everyone has their opinion on how trading should work so take things with a grain of salt. Lastly, trading and managing a 10 billion dollar fund is quite different from e.g. 100k in your tax free social security account due to stuff like network effects and doors that can only be opened when you have enough zeroes on your spreadsheet so what's good for the goose is not always great for the gander.
Once you are done with stock markets, get a macroeconomics textbook to understand how it ties into the federal reserve (or central bank) and how government bonds affect liquidity, that sort of thing. Again, avoid pop science books which shows up way too often on HN (this is worse with biology, another subject that this forum has a poor grasp of).
niksteronDec 27, 2012
ksmithonApr 17, 2011
If you'd like to learn best practices, check out Hunt & Thomas' 'The Pragmatic Programmer' (http://www.pragprog.com/the-pragmatic-programmer).
To get up to speed fairly quickly on what's going on under the hood, check out Petzold's 'Code' (http://www.charlespetzold.com/code/) and Nisan & Schocken's
'The Elements of Computing Systems' (http://www1.idc.ac.il/tecs/).
alttagonMar 26, 2012
That said, I've still used it for my research ... although I can often find other sources that say things better, CC2 has made a good starting point for ideas on how to present ideas about code.
diego_moitaonSep 13, 2010
* good engineering practices (as all those described in books like "Pragmatic Programmer" and "Code Complete": code reviews, unit testing, continuous integration, coding standards)
* tools worth respect (e.g.: subversion, git or mercurial but not Visual Source Safe)
* a well defined development & project management methodology, agile or not (e.g.Scrum, RUP), instead of clueless project managers.
* a concrete problem/puzzle in the company website to filter out bad candidates
* respect for the developer private life; i.e: what to expect in overtime work
lzwonAug 19, 2010
As I learned erlang and OTP I kept finding design choices I really appreciated.
The pragmatic programmers book on erlang was written by the creator of the language and I think is one of the better programming books ever. Clearly he's spent several decades teaching this language to perplexed students, cause he found the right way to illuminate it.
chollida1onMay 9, 2018
1) The Mythical Man month
3) The Pragmatic Programmer
3) Code Complete.
The thing about these books, well atleast 1 and 3 is that when they were written they broke new ground. Or if that phrase bother you, they were the first mainstream publications that brought their core ideas to developers.
Reading these books early in your career will help cement these best practices.
Reading these books after you've been a practicing programmer means,IMHO, that the return you get from reading them goes way way down.
You'll find that you've already learned all/most? of what they are trying to teach.
You'll find yourself getting frustrated that they are preaching what you already know as common sense and first principles.
Or put another way, I'm not sure there is much that someone who has programmed for 5-10 years can get out of those books that they haven't picked up somewhere else already or learned the hard way.
trilinearnzonOct 28, 2020
Here are a few portions of his method that I always come back to:
---
Understanding the problem:
- What is the unknown?
- Draw a figure. Introduce suitable notation.
- Separate the various parts. Can you write them down?
Devising a plan:
- Have you seen it before? Do you know a related problem?
---
You can see the whole method at this link: https://imgv2-1-f.scribdassets.com/img/document/68994766/ori...
I use this approach in conjunction with an A4 piece of paper, or a note program capable of "outlining" functionality (expandable nodes). The latter works great for containing and structuring lots of information, and you can selectively show and hide different parts depending on what you're focusing on. Again, helping with filtering out the "noise" factor.
Another good approach is falling back to a plain-text editor such as Notepad.exe when you want to write anything down. I got that tip from the Pragmatic Programmer book. You can easily extend this to Markdown if needed.
hgaonFeb 17, 2010
I realized there had to be a better way and so I went straight to the library and read up on the software engineering of the time ("structured programming").
Since then I've read a lot on the practice of programming and applied it to my programming. And kept reading and applying stuff; the key here is to never stop learning.
Studying good software was probably the other major way. Back then, it was learning the UNIX V6 kernel with Lions' Commentary on UNIX 6th Edition, with Source Code plus reading the sources of all sorts of things and working on some of them.
If you haven't read The Pragmatic Programmer, AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis, something by Gerald Weinberg and something by Tom DeMarco and Timothy Lister (Peopleware is pretty much required reading), and The Mythical Man Month I strongly recommend them.
The recent Coders At Work is really good, although at a somewhat higher level.
My other recommendation is to get serious knowledge of other domains that have useful ideas and metaphors; for me that would be science in general and biology in particular.
Hmmm, reading a lot of classic SF (from the '40s on) and studying nanotech also helped. You want to have a big bag of problem solving tricks.
It also helps to gain a top to bottom understanding of how it all works. There are many approaches and books for this, I like The Structure and Interpretation of Computer Programming (SICP) for the higher level stuff, but also be sure to study some EE, digital design and low level architecture. And operating systems.
And if you're at all good with your hands, build (assemble) yourself a computer and get UNIX/Linux running on it. Design and implement a network with routers and static IP addresses or something like that. Etc.
valbacaonMay 25, 2021
I find that these two books are in many recommended lists, but I found them entirely unforgettable, entirely too long, and without any "meat."
So much of the advice given is trivial things you'll just figure out in the first few months of coding professionally.
Code for more than a week and you'll figure out how to name classes, how to use variables, how scope works, etc.
The code examples are only in C++, Java, and Visual Basic (ha!). Completely ignoring non-OO and dynamic languages.
Some of the advice is just bad (like prefixing global variables with g_) or incredibly outdated (like, "avoid goto"? Thanks 1968!).
Work on a single software project, or any problem ever, and you'll know that you need to define the problem first. It's not exactly sage advice.
These are cherry-picked examples, but overall Code Complete manages to be too large, go into too specific detail in some areas, while giving vague advice in others.
All books are written in a time and a few become timeless. Software books have an especially short half-life. I think Code Complete was a book Software Engineering needed in 2004, but has since dropped in value.
I will say, that Code Complete does have utility as a way to prop up your monitor for increased ergonomics, which is something you should never ignore.
I have similar issues with Clean Code. One is better off just googling "SOLID Principles" and then just programming using small interfaces more often and use fewer subclasses.
A better alternative is (from above) The Pragmatic Programmer (2019), a good style guide, and/or get your code reviewed by literally anyone.
mbaumanonSep 4, 2017
What I do find useful is listening to books on practice or management. Something like The Pragmatic Programmer, The Practice of Programming, and Clean Code. These are high on substance but (relatively) low on examples, so I feel I can still benefit from their insights without having to be in front of a screen.
fendaleonNov 18, 2010
btschaeggonDec 27, 2020
If you think of orthogonality in geometry, you can describe any N-dimensional vector space through a set of N orthogonal vectors (say the unit vectors in X, Y, Z). "Orthogonal" in this case means that moving something along one of those (say the X axis) won't alter its position from any other base vector's perspective.
In the same way, "orthogonal implementations" is a way of saying that the things are independent from each other. You can find their explanation in the Google preview for the book [1].
So, say you write utility code for a couple of applications, for example: Message transmission and subscription management. Then, you should try and keep both as independent as possible from each other, so that as a downstream user I won't have to pull in or even "massage" both just to use one of them.
As I wrote before, that sounds totally obvious when said out loud; yet I constantly find new examples where someone found a way to unnecessarily "complect" [2] multiple things.
[1]: https://books.google.ch/books?id=LhOlDwAAQBAJ&pg=PT70&dq=ort...
[2]: If that word also seems strange to you, I highly recommend watching https://youtu.be/oytL881p-nQ
jaawnonJuly 10, 2015
If changes to the implementation of String could cause issues for you, you really should be using a custom solution anyway. A quick and dirty option would be to write a wrapper class which uses all of your preferred String hacks in a central location, and using that in place of String throughout your code. When String's implementation changes, you can update your hacks all in one place.
Here is some relevant advice from The Pragmatic Programmer: https://pragprog.com/the-pragmatic-programmer/extracts/coinc...
jclemensononApr 16, 2010
plinkplonkonNov 20, 2007
Owning two types of cars (or a car and a motorcycle) maybe a more helpful metaphor than horse and buggy vs car. The Pragmatic Programmers release all their books as non drm-ed pdfs and you can buy both the electronic copy and the pdf if you choose. They seem to do well.
But yes, the kindle is very underwhelming, I'll for a better reader without DRM (or at least hackable DRM).
bad_useronDec 18, 2018
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.
wilsonnbonMay 9, 2018
Some people are inevitably going to recommend The Art of Computer Programming, which hardly anyone has read and isn't that relevant to the work that 99% of us are doing.
Someone will probably recommend The C Programming Language, also called K&R after the authors, but again it's not very useful unless you're going to be using a lot of C and even then I personally don't think it provides anything you can't get from guides on the internet. (I have actually read this one, but it's been a while)
There are other classic textbooks that will probably be mentioned that are only useful to those in that domain. Many of us can get by without a deep understanding of algorithms and data structures, most people don't need to read a compiler book, etc, etc.
However, there are some generalized books that people often recommend like The Pragmatic Programmer and Code Complete. These are, in my opinion, good recommendations if you're looking for something to read but I wouldn't say that someone starting a career in software engineering should read them. Software engineering isn't really a field with seminal texts that should be read by everyone.
For example, every political scientist should have probably read The Republic by Plato and Politics by Aristotle among many other texts. I don't think software engineering has that equivalent, partially due to the relative newness of the field and partially because the primary output of our field is not written texts.
Another interesting question would be "What codebases should someone starting their career in software engineering look at?". Are there things that the average joe programmer can learn by poking around the Linux kernel or Firefox? Maybe. I don't know. I've never done it. I'd be interested in hearing from those who have, though. Maybe I'll do my own ask HN.
edit: I feel I should clarify that this is written from the perspective of a software engineer, not an academic in computer science. For all I know there could be seminal texts that those on the academic side should all have read.
brandall10onJan 12, 2014
I read Code Complete 2 after developing software for maybe 6-7 years in an environment like this. Much of it was obvious, but the rest was a revelation. Same with The Pragmatic Programmer.
Several years later I read a book called "The Passionate Programmer", which was like the book described in this article - soft, career development skills. That was probably the most important book I've ever read. In fact it's how I found out about Hacker News in addition to a whole bunch of different books. It lit a fire in me.
4 years later, I have a career that is so dramatically different I don't even know where to begin. On the same token, I reread that book (Passionate Programmer) recently and it does seem like common sense I would absorbed over time from things I read on HN.
pmr_onMar 13, 2012
hackermailmanonJuly 15, 2020
All the "engineer"-ry things like constructing testing oracles or understanding code complexity this can all be found in Programming and Programming Languages https://papl.cs.brown.edu/2020/ that uses Pyret which has similar enough syntax to Python none of your bad engineers will be lost. There are lectures for it too: https://learnaifromscratch.github.io/software.html#org4eef4d... you could teach this class to them the lectures really teach you concepts like trees and graphs and how to reason about them.
stinosonJune 5, 2017
ig1onJune 22, 2009
Would you hire a graduate who wasn't inclined to spend their time learning about version control, bug tracking or release management systems (all of which are part of the ITIL standard) ?
A lot of ITIL isn't that much different from what you find in Code Complete or the Pragmatic Programmer books on deployment. Just because you prefer your buzzword to their buzzword, doesn't mean it's any more important.
kamaalonJune 27, 2012
If this advice is to be taken seriously the only editors you can learn is vim and Emacs.
Shiny editors like Sublime Text come and go every 2-3 years. And putting effort learning them, only brings you back to your statement: "You'll be most productive if you learn your editor from head to toe, than if you half-assedly know several."
blindhippoonNov 25, 2013
The Pragmatic Programmer by Andrew Hunt & David Thomas
Code Complete 2 by Steve McConnell
Clean Code by James O. Coplien
Test Driven Development by Kent Beck (save this for last)
These books will teach you how to think and approach coding in a way that will make Object Oriented programming simpler to comprehend.
I can't suggest a book that explains basic OOP principals, hopefully some other much smarter person here can. I learned basic OOP through practice and through my education/class - but to be honest the basics are dead simple. It's only when you start getting into the very abstract that OOP starts to get really complicated and that's where the above books will help you.
breckonJuly 4, 2019
One I'd recommend is "Eloquent Javascript". It may be a tiny bit out of date now (I read it over 5 years ago maybe, and Javascript has improved a lot since then), but it's a solid book.
Other books you might like: Pragmatic Programmer, Pattern on the Stone, Clean Code, Mastering Regular Expressions.
csixty4onDec 24, 2015
Learn who you are, what you enjoy, and where you want to go with your career. Technology stacks change more often than I buy new shoes. Is that a reflection on the technology or the shoes?
I see Mobile development, web dev, FP, and devops technologies in your list. What excites you?
Instead of specific languages, what about learning new concepts? Learning about functional programming will change how you program in other languages. Studying algorithms will change how you think about efficiency. Reading books like "The Pragmatic Programmer" or the classic "Mythical Man Month" will give you a bit of a higher-level understanding of what it is we do.
p0nceonMay 29, 2019
This is only one of these "must-read book list", what you can do is search several of them and see which ones are quoted by almost everyone!
About "everything" I would rate the following books very highly, for their sheer usefulness:
- Thinking Fast and Slow (really do the exercises!)
- then Neuroleadership which describes the purpose of brain structures, it's somehow wider than kahneman
- A Mind for Numbers (include very useful data points for knowledge workers)
- Distinction: A Social Critique of the Judgement of Taste
- Cutting Through Spiritual Materialism
About programming I would rate the following books highly, but at the same time it seems a bit fruitless to me to read about programming, rather than spending more time reading about psychology or sociology:
- the Economics of Software Quality
- Peopleware
- Pragmatic programmer
- Mythical Man month
^you'll see that these books are hardly kept secret, it's just that people quote them but don't actually read them, or so it seems.
jdminhbgonNov 29, 2012
I figure out what needs to be done in order to get something to work reasonably well, and if I can’t do it myself I google it till I find snippets of code that mostly do what I need, then I modify them and hack around till I get something that works decently enough.
To me this is a much bigger problem than your ability to implement a linked list or describe big-O notation -- I'd be worried that I'd always be cleaning up after your messes.
The good news is that this is a solvable issue. Start collaborating with people, maybe via open source. Find a project of yours that's useful but maybe not profitable, open source it, and start handling requests for features and submissions. Learn how to deal with bad incoming code, and how to deal with your code being confusing to other people. Maybe read some of the classics on code as collaborative effort, like the Pragmatic Programmer or Clean Code.
Or maybe just decide that this isn't for you! There are lots of jobs oriented around achieving specific goals with throwaway code that you might be happier in than being a slave to the CI server, and they aren't less valuable. But if you want to be hireable in a code-oriented company, I think you have to change some things.
f2enderonJan 25, 2011
The books I enjoyed the most were Richard Stevens' Network Programming and Unix Programming books. Those books teach you a ton of things while helping you implement something useful. They were very hands on. I haven't been able to find anything similar in a long while.
jacques_chesteronAug 20, 2012
Anyhow, I expect we'll get the usual round up here. Code Complete, of course; plus a smattering of rebels who think it was boring or irrelevant. The Pragmatic Programmer will receive universal praise, especially from those who didn't take the time to read Code Complete from cover to cover.
Some of the debate will be about whether Code Complete is "better" than Clean Code or not. A silly argument, they are complementary (though, really, is this even a debate worth having? Code Complete is clearly the better book).
Let's see, what else?
Structure and Interpretation of Computer Programs will get mentioned, which will spawn a fertile subthread arguing about whether computer science books really belong on a list for developers. That subthread will debate the merits of Introduction to Algorithms vs everything else, and someone will mention a lisp book that changed their life. Probably Paradigms of Artificial Programming or On Lisp.
The Gang of Four will get nodded at. Like the Bible, Homer, or Peopleware it will be the book everyone says they've read but which almost nobody has actually read.
The C Programming Language will be mentioned. These days that means Zed Shaw will be named and hilarity will ensue.
Myself? I'd definitely have Code Complete (I still have my first edition), perhaps A Discipline for Software Engineering and Software Estimation: Demystifying the Black Art. I've found pretty much everything from Dorset House to be worth my time, so to PeopleWare I'd add The Deadline and Adrenalin Junkies and Template Zombies.
What we don't do in this industry, however, is read more widely. Get out of your rut. Read about history, read some classics, read deeply in another field you pursue as your hobby. Everything illuminates everything. Get out there, see the intellectual sights (for which, get a copy of Dawn to Decadence by Jacques Barzun for a guided tour). You'll be a better developer and a better person for the trouble.
iendsonJan 13, 2014
I feel like Pragmatic Programmer would be a good book to read before starting your first job, or maybe your undergraduate year of college.
I was going to start Code Complete next, but Pragmatic Programmer was so disappointing I decided to read fiction for the next few weeks instead.
So to answer your question, the best language agnostic development books I've read are:
1. Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity
2. The Best Software Writing I
3. Hackers and Painters
I always wish Joel would come out with a second volume of #2, or to start his blog up again. I've yet to find something that equals his quality since he stopped writing.
elangoconApr 21, 2012
I've read The Pragmatic Programmer, and early-on, it mentions "broken windows" principle -- fix errors as soon as you notice them, or else they'll get more difficult for you to fix as time goes by. And like broken windows are like a green-light for a neighborhood to decline, unfixed hacks similarly invite poor quality code.
In practice, do "working" and "working well" end up being sort of the same as suggested by the broken windows principle? Or Is "make it work" refer to making a quick prototype, and "make it right" refer to filling out substantial functionality?
trotzkeonJuly 9, 2008
Getting Real (37Signals),
Hardball (Chris Mathews),
Prioritizing Web Usability (Jakob Nielsen)
Nearby shelf:
The Design of Everyday Things,
Maverick,
Founders at work,
A Brief History of Time,
A Pattern Language,
Peopleware,
Made to stick,
Web Standards Solutions,
Designing Interactions,
The Pragmatic Programmer,
The Mythical Man-Month,
Oh, the Places You'll Go!
Other good reads:
Blink,
Tipping Point,
Long Tail,
Freakonomics
vivanonOct 16, 2017
Andy once worked on a large graphics application. Nearing release, the testers reported that the application crashed
every time they painted a stroke with a particular brush. The programmer responsible argued that there was nothing
wrong with it; he had tried painting with it, and it worked just fine. This dialog went back and forth for several days,
with tempers rapidly rising.
Finally, we got them together in the same room. The tester selected the brush tool and painted a stroke from the
upper right corner to the lower left corner. The application exploded. "Oh," said the programmer, in a small voice,
who then sheepishly admitted that he had made test strokes only from the lower left to the upper right, which did not
expose the bug.
acconradonNov 6, 2018
Then I started reading books on skills I wanted to acquire (i.e. Traction for marketing and SPIN Selling for sales).
All of those books lead to recommendations into other books.
Listening to podcasts that recommend books increase the breadth of books I'm reading.
My wife brings home books from the library and I read whatever she reads (i.e. Hillbilly Elegy and The People vs Democracy), and those lead to other nonfiction books I become interested in. And then there are the "classic" novels I interleave from time to time (i.e. Siddhartha and Meditations).
It just starts with maybe a handful of books you are dying to read, try to read for 15 min before bed, and before you know it, you're 50 books into the year!
paulbjensenonSep 30, 2013
About a year later (summer 2007), I got a job working for a ticket search engine called Tickex, doing Rails. I was paid £9 per hour, and worked at a BBQ table and chair. It was a really enjoyable time. we were Seedcamp finalists and nearly got funding from Sequoia, but sadly the funding ran out and the business moved back to California and then shut down. Since then, I've worked at a few other startups, at a web agency called New Bamboo, at AOL, and now I work in a small business. I also had offers to interview at Square and Facebook, but a temporary lack of nationality/family circumstances meant that I couldn't move to California.
The decision to deviate from the path offered by my degree has been one of the best in my life. Before I had learnt to program, I had ideas but no ability to program, so they remained as ideas. Having learnt to program, I have the ability to have ideas and do something about them.
xstartuponFeb 12, 2018
McConnell, Steve. Software Project Survival Guide. Redmond, WA: Microsoft Press, 1998.
Maguire, Steve. Writing Solid Code. Redmond, WA: Microsoft Press, 1993.
Ranade and Nash. The Elements of C Programming Style. New York: McGraw-Hill, 1992.
Kernighan and Plauger. The Elements of Programming Style. New York: McGraw-Hill, 1982.
Caner, Cem, et al. Testing Computer Software, Second Edition. New York: Wiley Computer Publishing, 1999.
Hunt, Andrew, et al. The Pragmatic Programmer. Reading, MA: Addison-Wesley, 2000.
Holub, Allen. Enough Rope to Shoot Yourself in the Foot: Rules for C and C++ Programming. New York: McGraw-Hill, 1995.
amadeuspagelonAug 17, 2018
- Link the name to a list with all the recommendations by that person, use the date for a link to the place where the recommendation was made (using the date for a permalink is convention).
- Link tags.
- Show everyone who recommended something and sort by how many people recommended it. (For instance The Pragmatic Programmer is recommended by Joel Spolsky, Steve Yegge and Jeff Atwood.)
- Use Amazon Affiliate links to make money.
ScottWhighamonAug 31, 2009
1) You'll likely get better/more response if you prefix your post with "Ask HN: " (lots of folks have triggers for that type of thing)
2) You don't have to be a mathematician to be a good programmer. Tons of great programmers were not comp-sci majors so don't let that sort of thing get you down. If you've done "some basic noodling here and there... in a few languages" and you want to improve as a programmer, I'd advise you to:
At this point you're likely ready to spend a bunch of time reading non-domain specific books but, up until this point, the value you would receive from reading books not directly related to a specific language/task is debatable. Now that you've had some experience, I think this is a great time for books like:
(Those are all titles of books BTW)
Next up: build a startup!
Notice there are no math books in my list. This is different from what others would propose but, given the scant description you wrote, I don't see any need for math except to satisfy a possible desire to learn.
hakreonAug 6, 2020
I also don't think that the format matters more than it's use.
Reminds me of some good advice in The Pragmatic Programmer, should be
(simple) text-files for editing and (regardless if one or multiple files), a single source of truth (e.g. if multiple files, not the same time the same data to edit in). This is roughly as I remember it and I found it always useful to apply.
If I see duplication, it's about fighting the rot and remove it.
If configuration files are generated, they don't belong under version control (there are some exclusions to this rule, e.g. pinning dependency versions for example when shared with the repository).
apotheononOct 4, 2010
k_szeonNov 21, 2019
Plus, with a digital version like epub, I could change font size and let it reflow, change the colour theme to sepia in Apple’s Books app or Calibre, and it would still be beautifully formatted.
NowakeronAug 20, 2014
I'm aware you expect some quick tips from HN though. Have a look at my old blog posts that summarize these books. While 3 years old and written in Polish, Google translated it very well. Direct links to the translations: https://bit.ly/1oZiidn and https://bit.ly/1w8ELhY.
npsimonsonJune 2, 2013
Another big helper (which works well when you're already in Emacs), is to type in and test code examples, and force yourself to solve/work all the exercises/problems given.
A couple of last things to look up: the PQ4R strategy and SQ3R strategy. I've heard these are taught in England; I really wish they would teach it here in the states early in public school.
jerfonAug 16, 2009
Already mentioned is Code Complete and The Pragmatic Programmer. I'd add The Mythical Man Month, still a classic, but note that's a relatively short book and may not last long enough. (A depressing read in some ways; decades have passed and what's in the book is arguably common wisdom, yet I still encounter the errors outlined in that book every year.)
Godel, Escher, Bach (mentioned by caffeine) is a love it or hate it book; check out a couple of summaries and see what you think.
Personally, I don't recommend the SICP unless you're actually working through the exercises to some extent, and without a computer it's too easy to think you understand it when you don't.
If you have already read all those, well, I'd suggest replying and saying so. :)
andhapponNov 20, 2009
kragenonMar 29, 2011
Off-topic: what books do you recommend on chemical engineering? What's the equivalent of The Art of Electronics for analog electronics, or HDL Chip Design for digital chip design, or Code Complete or Algorithms in C or CLRS or The Pragmatic Programmer or SICP or TAOCP for software?
dragonwriteronSep 22, 2014
The Pragmatic Programmer's ebooks, from their site, are all non-DRM, on the technical side (I think a number of other big technical publishers do non-DRM on direct-from-publisher ebooks).
(On the fiction side, I know Baen has included CDs of DRM-free ebooks -- mostly the all-but-most-recent books in major series -- with hardbacks, and also allowed them to distributed on the web.)
nostrademonsonMar 22, 2007
Business & Management
1. Innovator's Dilemma and Innovator's Solution by Clayton Christensen
2. Built to Last and Good to Great by Jim Collins. Built to Last is more applicable for startups.
3. Mythical Man Month by Fred Brooks. Anyone who has to manage a team of programmers and hasn't read this will fail utterly, unless they've already failed before (or been on a failing team). There's a lot that's counterintuitive about software project management.
4. Peter Drucker's work. Kinda long and repetitive, but some good insights.
Marketing
1. All Marketers are Liars by Seth Godin. I like this better than Purple Cow, Guerilla Marketer's Handbook, and The Big Red Fez. Most of those have fairly obvious stuff.
2. The Tipping Point by Malcolm Gladwell
3. Crossing the Chasm by Geoffrey Moore
Technical
1. Building Scalable Websites by Cal Henderson
2. High Performance MySQL by Jeremy Zawodny
3. Pragmatic Programmer by...well, it's mentioned elsewhere here.
There are lots of other technical books I like, but most of them aren't directly relevant to the startup I'm building
mindcrimeonMay 29, 2017
1. Neuromancer - William Gibson
2. Snow Crash - Neal Stephenson
3. Hackers - Heroes of the Computer Revolution - Steven Levy
4. How to Measure Anything - Douglas Hubbard
5. Godel, Escher, Bach - Douglas Hofstadter
6. The Pragmatic Programmer - Andy Hunt and Dave Thomas
7. The Soul of a New Machine - Tracy Kidder
8. Code - Charles Petzold
9. The Shockwave Rider - John Brunner
10. Ambient Findability: What We Find Changes Who We Become
Book - Peter Morville
11. Don't Make Me Think - Steve Krug
12. The Design of Everyday Things - Donald A. Norman
13. The Mythical Man-Month: Essays on Software Engineering - Fred Brooks
14. Decline and Fall of the American Programmer - Ed Yourdon
15. Cube Farm - Bill Blunden
16. The Philip K. Dick Reader
17. The Cuckoo's Egg - Clifford Stoll
18. The Prince - Niccolò Machiavelli
19. The 48 Laws of Power - Robert Greene
20. The Atrocity Archives - Charles Stross
21. Business @ the Speed of Thought: Using a Digital Nervous System - Bill Gates
LockeonDec 4, 2007
elemenoonDec 7, 2011
For what it's worth, it's the same imprint that gave us the pickaxe book (Programming Ruby), so perhaps that ought to be a point in it's favour.
rsaarelmonSep 15, 2010
Beyond that, off the top of my head the number one theory book for working programmers would be Introduction to Algorithms by Cormen, Leiserson, Rivest and the new guy.
mayonJuly 27, 2010
I would point you to two other reference materials. One, is Andy Hunt's (of the Pragmatic Programmers) book: "Pragmatic Thinking and Learning" which I cannot recommend enough. Second is 37Signals "Rework", which I also heartily reccomend.
One thing Pragmatic Thinking & Learning touches on is S.M.A.R.T. See: http://en.wikipedia.org/wiki/S.M.A.R.T.
Also? I have A.D.H.D., too. I also struggle at times -- it's a bitch to admit you're both intelligent & disabled.
I don't have much practical advice on this topic, just be aware.
Finally, work on balance. Work on goals. And don't sweat the small stuff -- relax and work slowly. Change is hard.
Best of luck.
-N
P.S. Exercise helps everything (ditto sleep) -- cognition, bodily health, focus, etc. Even if you don't lose any weight (or gain slightly due to fat -> muscle) it's still worth it. Trust me.
spacemanakionAug 6, 2011
Then I'd recommend you go back and read it closely yourself, because there's an entire chapter on domain-specific programming which includes tips on implementing mini-languages to write code close to the problem space, which is a very Lispy suggestion.
ZevonDec 14, 2008
-Erica Sadun's iPhone Developers Cookbook: http://www.amazon.com/iPhone-Developers-Cookbook-Building-Ap...
-Apple's documentation.
-If you're really confused about ObjC, check out Steve Kochan's Programming in Objective C: http://www.amazon.com/Programming-Objective-C-Developers-Lib...
scorchinonApr 18, 2010
The Pragmatic Programmer is quite old (published 1999). It provides a lot of useful (generalised) information on how to build a scalable, useable and easy-to-maintain application. The small handout that comes in the back of the book is also a great reference to keep next to your desk!
Coders at Work takes a slightly different approach. Odds are you've heard about it from other users of HN, but in short: It's a selection of interviews with some of the most accomplished programmers around; Knuth, Simon Peyton Jones etc. I'd still recommend this book, but I would probably cut out around 15% of it.
C++ was never given enough time at my University (it was a Java school) and so I wasn't too tied to it when starting out with Cocoa Programming for Mac OS X. If you can understand basic pointer use in C, then this book will hold your hand through Objective-C and into using Interface Builder and XCode to build native Mac applications. It's not going to teach you how to build iPhone apps, but it will give you the correct core knowledge to go on and do so using the Apple docs should you wish.
I'm currently in the process of reading K&R (The C Programming Language book) and Thinking in Java, both of which are regarded quite highly. Although K&R is definitely seen as THE technical book to read.
JtsummersonAug 27, 2020
Listening: Swords in the Mist, Fritz Leiber. Third in the Fafhrd and the Grey Mouser collections.
Reading: The Dispossessed, Ursula Le Guin.
I’m trying to learn Spanish. I’ve picked up a few Spanish language fiction books, presently starting on Harry Potter y la piedra filosofal. I’ve tried reading other books, like Jorge Luis Borges’ Ficciones, but I’ve found it to be above my present level. I’ve restarted four or five times and made it further each time, but always stalled out.
The Design of Everyday Things, Don Norman.
I have other books started lying around the house, but these are the ones I’ve been actively engaged with in the last couple weeks. When I can type properly again (two to three weeks) I’ll resume Lisp in Small Pieces, Christian Queinnec. And at the office I have The Pragmatic Programmer, I’ll be back there next week and bring it home so I can continue with it.
organicfigsonMay 13, 2020
voltageekonJuly 16, 2009
The Pragmatic Programmer
The Mythical Man-Month: Essays on Software Engineering
And oh yeah,Dilbert & The Tao of Programming for philosophical contemplation.