Nothing Found

It seems we can’t find what you’re looking for. Perhaps searching can help.

FAF deciding on filters on post to be syndicated:

How to Escape Callback Hell with JavaScipt Promises

Array ( [post_title] => How to Escape Callback Hell with JavaScipt Promises [post_content] =>

What's callback hell and what the hell are Promises?? To dive into those questions requires some basic understanding of the Javascript callstack, so I'll go into brief detail about that first and then navigate you through and out of callback hell.

Nature of the Beast

JavaScript is a single threaded language - meaning it has a single callstack and it can only execute one line of code at a time..

The callstack is basically a data structure which keeps track of what the program should run next. It follows the rules of FIFO - First In, First Out.

Step into a function call and it gets adds to the top of the stack, return a function and it pops off the top of the stack.

You wouldn't grab the waffle at the bottom of the stack. Neither would JavaScript.

So yeah, Javascipt has a single callstack. And this actually makes writing code simple because you don’t have to worry about the concurrency issues - or multiple computations happening at the same time.

Great!

...except when you do want stuff to happen at the same time. For example, writing web applications that make dozens of asynchronous calls to the network - you dont want to stop the the rest of your code from executing just to wait for a response. When this happens, its called holding up the event loop or "main thread".

Callback Hell

The first solution to work around JavaScript's single thread is to nest functions as callbacks.

It gets the job done, but determining the current scope and available variables can be incredibly challenging and frustrating.

And it just makes you feel like:

When you have so many nested functions you find yourself getting lost in the mist - this is whats referred to as callback hell. Its scary and no one wants to be there!

Nested callbacks tends to develop a distinct pyramid shape -

fightTheDemogorgon(function(result) {
  rollForDamage(result, function(seasonsLeft) {
    closeTheGate(seasonsLeft, function(finalResult) {
      console.log('Hawkins is safe for ' + finalResult + ' more seasons.');
    }, failureCallback);
  }, failureCallback);
}, failureCallback);

And just imagine this happening even further, with 10 or 15 more nested functions calls. SCARY RIGHT??

JavaScript developers recognized this was a problem, and they created Promises.

Introduced in ES6 (2015), a Promise is an alternative way to format your asynchronous functions without breaking the event loop. It returns a special promise object that represents a future result.

Whats the Difference?

A lot of it is formatting.

Callbacks do not return anything right away, they take a function as an argument, and then you tell the executing function what to do when the asynchronous task completes.

Promises on the other hand immediately return a special promise object. They do not need a function argument, thus it does not need to be nested.
You provide the action to be taken when the asynchronous task completes using a promise method called then().

Chaining, aka the Power of Friendship

Alt Text

The truly AWESOME thing about Promises is that they can be chained by using their then() method when we need to execute two or more asynchronous operations back to back.

Each chained then() function returns a new promise, different from the original and represents the completion of another asynchronous step in the chain.

You can basically read it as Do this, THEN do this, THEN this.

Promises also have a catch() method. Chaining a catch() to end of a chain will give you the errors for any failed promise in the chain. Its also useful to set an action to take in the event of a failure in the chain.

Promise chaining allows us to get rid of the nasty nesting callback pattern and flatten our JavaScript code into more readable format.

fightTheDemogorgon()
.then(function(result) {
  return rollForDamage(result);
})
.then(function(seasonsLeft) {
  return closeTheGateIn(seasonsLeft);
})
.then(function(finalResult) {
  console.log('Hawkins is safe for ' + finalResult + ' more seasons.');
})
.catch(failureCallback);

With ES6 syntax we can condense this even further!

fightTheDemogorgon()
.then((result) => rollForDamage(result))
.then((seasonsLeft) => closeTheGateIn(seasonsLeft))
.then((finalResult) => console.log('Hawkins is safe for ' + finalResult + ' more seasons.'))
.catch(failureCallback);

Defeating the Beast, Escaping Hell

The beast here being asynchronous calls, and hell being callback hell.

There is nothing stopping you from nesting Promise functions in typical callback fashion. But it's not necessary! This is usually accidentally self inflicted and is just a lack a familiarity with Promises.

You can think of Promises as callbacks in fancy new clothes. It allows asynchronous code to look cleaner, promotes ease of use and readability, most importantly, it gives you a way out of callback hell.

Alt Text

There is an even newer method called Async/await introduced in ES8 (2017). Check it out!

Thanks for reading!

References:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise
https://www.youtube.com/watch?v=8aGhZQkoFbQ

[post_excerpt] => What's callback hell and what the hell are Promises?? To dive into those questions requires some basic understanding of the Javascript callstack, so I'll go into brief detail about that first and then navigate you through and out of callback hell. ... [post_date_gmt] => 2019-10-21 05:18:10 [post_date] => 2019-10-21 05:18:10 [post_modified_gmt] => 2019-10-21 05:18:10 [post_modified] => 2019-10-21 05:18:10 [post_status] => publish [comment_status] => closed [ping_status] => closed [guid] => https://dev.to/amberjones/how-to-escape-callback-hell-with-javascipt-promises-42d0 [meta] => Array ( [enclosure] => Array ( [0] => ) [syndication_source] => DEV Community [syndication_source_uri] => https://dev.to [syndication_source_id] => https://dev.to/feed [syndication_feed] => https://dev.to/feed [syndication_feed_id] => 15 [syndication_permalink] => https://dev.to/amberjones/how-to-escape-callback-hell-with-javascipt-promises-42d0 [syndication_item_hash] => 7d0e2d77ad881ab570b1635df8ed3f79 ) [post_type] => post [post_author] => 7098 [tax_input] => Array ( [category] => Array ( [0] => 21 ) [post_tag] => Array ( ) [post_format] => Array ( ) ) )

Doing filter:faf_link_filter

What's callback hell and what the hell are Promises?? To dive into those questions requires some basic understanding of the Javascript callstack, so I'll go into brief detail about that first and then navigate you through and out of callback hell. ...

What's callback hell and what the hell are Promises?? To dive into those questions requires some basic understanding of the Javascript callstack, so I'll go into brief detail about that first and then navigate you through and out of callback hell.

Nature of the Beast

JavaScript is a single threaded language - meaning it has a single callstack and it can only execute one line of code at a time..

The callstack is basically a data structure which keeps track of what the program should run next. It follows the rules of FIFO - First In, First Out.

Step into a function call and it gets adds to the top of the stack, return a function and it pops off the top of the stack.

You wouldn't grab the waffle at the bottom of the stack. Neither would JavaScript.

So yeah, Javascipt has a single callstack. And this actually makes writing code simple because you don’t have to worry about the concurrency issues - or multiple computations happening at the same time.

Great!

...except when you do want stuff to happen at the same time. For example, writing web applications that make dozens of asynchronous calls to the network - you dont want to stop the the rest of your code from executing just to wait for a response. When this happens, its called holding up the event loop or "main thread".

Callback Hell

The first solution to work around JavaScript's single thread is to nest functions as callbacks.

It gets the job done, but determining the current scope and available variables can be incredibly challenging and frustrating.

And it just makes you feel like:

When you have so many nested functions you find yourself getting lost in the mist - this is whats referred to as callback hell. Its scary and no one wants to be there!

Nested callbacks tends to develop a distinct pyramid shape -

fightTheDemogorgon(function(result) {
  rollForDamage(result, function(seasonsLeft) {
    closeTheGate(seasonsLeft, function(finalResult) {
      console.log('Hawkins is safe for ' + finalResult + ' more seasons.');
    }, failureCallback);
  }, failureCallback);
}, failureCallback);

And just imagine this happening even further, with 10 or 15 more nested functions calls. SCARY RIGHT??

JavaScript developers recognized this was a problem, and they created Promises.

Introduced in ES6 (2015), a Promise is an alternative way to format your asynchronous functions without breaking the event loop. It returns a special promise object that represents a future result.

Whats the Difference?

A lot of it is formatting.

Callbacks do not return anything right away, they take a function as an argument, and then you tell the executing function what to do when the asynchronous task completes.

Promises on the other hand immediately return a special promise object. They do not need a function argument, thus it does not need to be nested.
You provide the action to be taken when the asynchronous task completes using a promise method called then().

Chaining, aka the Power of Friendship

Alt Text

The truly AWESOME thing about Promises is that they can be chained by using their then() method when we need to execute two or more asynchronous operations back to back.

Each chained then() function returns a new promise, different from the original and represents the completion of another asynchronous step in the chain.

You can basically read it as Do this, THEN do this, THEN this.

Promises also have a catch() method. Chaining a catch() to end of a chain will give you the errors for any failed promise in the chain. Its also useful to set an action to take in the event of a failure in the chain.

Promise chaining allows us to get rid of the nasty nesting callback pattern and flatten our JavaScript code into more readable format.

fightTheDemogorgon()
.then(function(result) {
  return rollForDamage(result);
})
.then(function(seasonsLeft) {
  return closeTheGateIn(seasonsLeft);
})
.then(function(finalResult) {
  console.log('Hawkins is safe for ' + finalResult + ' more seasons.');
})
.catch(failureCallback);

With ES6 syntax we can condense this even further!

fightTheDemogorgon()
.then((result) => rollForDamage(result))
.then((seasonsLeft) => closeTheGateIn(seasonsLeft))
.then((finalResult) => console.log('Hawkins is safe for ' + finalResult + ' more seasons.'))
.catch(failureCallback);

Defeating the Beast, Escaping Hell

The beast here being asynchronous calls, and hell being callback hell.

There is nothing stopping you from nesting Promise functions in typical callback fashion. But it's not necessary! This is usually accidentally self inflicted and is just a lack a familiarity with Promises.

You can think of Promises as callbacks in fancy new clothes. It allows asynchronous code to look cleaner, promotes ease of use and readability, most importantly, it gives you a way out of callback hell.

Alt Text

There is an even newer method called Async/await introduced in ES8 (2017). Check it out!

Thanks for reading!

References:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise'>https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise
https://www.youtube.com/watch?v=8aGhZQkoFbQ'>https://www.youtube.com/watch?v=8aGhZQkoFbQ

Doing filter:faf_remove_html

Doing filter:faf_post_expirator

Decide filter: Returning post, everything seems orderly :How to Escape Callback Hell with JavaScipt Promises

Array ( [post_title] => How to Escape Callback Hell with JavaScipt Promises [post_content] =>

What's callback hell and what the hell are Promises?? To dive into those questions requires some basic understanding of the Javascript callstack, so I'll go into brief detail about that first and then navigate you through and out of callback hell.

Nature of the Beast

JavaScript is a single threaded language - meaning it has a single callstack and it can only execute one line of code at a time..

The callstack is basically a data structure which keeps track of what the program should run next. It follows the rules of FIFO - First In, First Out.

Step into a function call and it gets adds to the top of the stack, return a function and it pops off the top of the stack.

You wouldn't grab the waffle at the bottom of the stack. Neither would JavaScript.

So yeah, Javascipt has a single callstack. And this actually makes writing code simple because you don’t have to worry about the concurrency issues - or multiple computations happening at the same time.

Great!

...except when you do want stuff to happen at the same time. For example, writing web applications that make dozens of asynchronous calls to the network - you dont want to stop the the rest of your code from executing just to wait for a response. When this happens, its called holding up the event loop or "main thread".

Callback Hell

The first solution to work around JavaScript's single thread is to nest functions as callbacks.

It gets the job done, but determining the current scope and available variables can be incredibly challenging and frustrating.

And it just makes you feel like:

When you have so many nested functions you find yourself getting lost in the mist - this is whats referred to as callback hell. Its scary and no one wants to be there!

Nested callbacks tends to develop a distinct pyramid shape -

fightTheDemogorgon(function(result) {
  rollForDamage(result, function(seasonsLeft) {
    closeTheGate(seasonsLeft, function(finalResult) {
      console.log('Hawkins is safe for ' + finalResult + ' more seasons.');
    }, failureCallback);
  }, failureCallback);
}, failureCallback);

And just imagine this happening even further, with 10 or 15 more nested functions calls. SCARY RIGHT??

JavaScript developers recognized this was a problem, and they created Promises.

Introduced in ES6 (2015), a Promise is an alternative way to format your asynchronous functions without breaking the event loop. It returns a special promise object that represents a future result.

Whats the Difference?

A lot of it is formatting.

Callbacks do not return anything right away, they take a function as an argument, and then you tell the executing function what to do when the asynchronous task completes.

Promises on the other hand immediately return a special promise object. They do not need a function argument, thus it does not need to be nested. You provide the action to be taken when the asynchronous task completes using a promise method called then().

Chaining, aka the Power of Friendship

The truly AWESOME thing about Promises is that they can be chained by using their then() method when we need to execute two or more asynchronous operations back to back.

Each chained then() function returns a new promise, different from the original and represents the completion of another asynchronous step in the chain.

You can basically read it as Do this, THEN do this, THEN this.

Promises also have a catch() method. Chaining a catch() to end of a chain will give you the errors for any failed promise in the chain. Its also useful to set an action to take in the event of a failure in the chain.

Promise chaining allows us to get rid of the nasty nesting callback pattern and flatten our JavaScript code into more readable format.

fightTheDemogorgon()
.then(function(result) {
  return rollForDamage(result);
})
.then(function(seasonsLeft) {
  return closeTheGateIn(seasonsLeft);
})
.then(function(finalResult) {
  console.log('Hawkins is safe for ' + finalResult + ' more seasons.');
})
.catch(failureCallback);

With ES6 syntax we can condense this even further!

fightTheDemogorgon()
.then((result) => rollForDamage(result))
.then((seasonsLeft) => closeTheGateIn(seasonsLeft))
.then((finalResult) => console.log('Hawkins is safe for ' + finalResult + ' more seasons.'))
.catch(failureCallback);
Defeating the Beast, Escaping Hell

The beast here being asynchronous calls, and hell being callback hell.

There is nothing stopping you from nesting Promise functions in typical callback fashion. But it's not necessary! This is usually accidentally self inflicted and is just a lack a familiarity with Promises.

You can think of Promises as callbacks in fancy new clothes. It allows asynchronous code to look cleaner, promotes ease of use and readability, most importantly, it gives you a way out of callback hell.

There is an even newer method called Async/await introduced in ES8 (2017). Check it out!

Thanks for reading!

References: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise'>https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promisehttps://www.youtube.com/watch?v=8aGhZQkoFbQ'>https://www.youtube.com/watch?v=8aGhZQkoFbQ

[post_excerpt] => What's callback hell and what the hell are Promises?? To dive into those questions requires some basic understanding of the Javascript callstack, so I'll go into brief detail about that first and then navigate you through and out of callback hell. ... [post_date_gmt] => 2019-10-21 05:18:10 [post_date] => 2019-10-21 05:18:10 [post_modified_gmt] => 2019-10-21 05:18:10 [post_modified] => 2019-10-21 05:18:10 [post_status] => publish [comment_status] => closed [ping_status] => closed [guid] => https://dev.to/amberjones/how-to-escape-callback-hell-with-javascipt-promises-42d0 [meta] => Array ( [enclosure] => Array ( [0] => ) [syndication_source] => DEV Community [syndication_source_uri] => https://dev.to [syndication_source_id] => https://dev.to/feed [syndication_feed] => https://dev.to/feed [syndication_feed_id] => 15 [syndication_permalink] => https://dev.to/amberjones/how-to-escape-callback-hell-with-javascipt-promises-42d0 [syndication_item_hash] => 7d0e2d77ad881ab570b1635df8ed3f79 [_expiration-date] => 1572096471 [_expiration-date-options] => Array ( [expireType] => delete ) [_expiration-data-status] => saved [faf_process_expire_date] => 1572096471 ) [post_type] => post [post_author] => 7098 [tax_input] => Array ( [category] => Array ( [0] => 21 ) [post_tag] => Array ( ) [post_format] => Array ( ) ) [post_except] => What's callback hell and what the hell are Promises?? To dive into those questions requires some basic understanding of the Javascript callstack, so I'll go into brief detail about that first and then navigate you through and out of callback hell. ... )

FAF deciding on filters on post to be syndicated:

20 Most-Recommended Books for Software Developers

Array ( [post_title] => 20 Most-Recommended Books for Software Developers [post_content] =>

"Доверяй, но проверяй" ("Trust, but verify")
-- Russian Proverb

People are often wrong: we make bad bets, buy property before housing bubbles burst, and go on fad diets. We make poor decisions, sometimes on the advice of others (going to the Lephrechaun Museum in Dublin is 2 hours of my life that I'll never get back).

In spite of this anecdotal evidence, listening to the advice of those who have had different life experiences from us is a supremely valuable activity. If someone else has taken the time to read an entire book and strongly recommends it, maybe we should listen. If 100 people have done so and all of them recommend it, it's almost definitely worth your time. Following this logic, and being the extremely type-A person that I am, I've constructed a meta-list: a list of the books recommended most often in lists of recommended books.

I've compiled the suggestions of dozens of programmers, managers, career coaches, and other industry professionals to bring you a list of the 20 most-recommended books for software developers, with some short summaries (courtesy of Amazon). All of the data I used to compile this list is freely available as a single Excel workbook on GitHub. As of Saturday 19 October 2019, my meta-list cites 36 sources and includes recommendations for 297 unique books.

I did this mostly to help myself organise the books I want to read in the near future, but also to help out anyone else who wants to build a good foundation, but might be frustrated by all of the different lists on the Internet making different recommendations. Why trust one of them when you can take everyone's opinion in aggregate? You're welcome, Internet.

Here are the rules of thumb I used to compose this list:

  1. As often as possible, articles asking for recommendations are not included.

  2. Recommendations for different editions of a book are considered recommendations for the same book, but recommendations for multiple editions within one article are not double-counted.

  3. Articles where an author simply lists books they've read or are currently reading are not included. The article must be presented as a list of recommended books.

  4. Lists which are geared toward a particular level of developer (i.e. CTO, junior developer, newbie) are included.

  5. I tried to skip lists which are geared toward a particular technology (i.e. PHP, CSS, Java), but some lists have these types of books interspersed; every book on an included article is included in my list of books, even if it's a novel, technology-specific, or not related to programming.

  6. Although they may be interpreted slightly differently by some, for the purposes of this list, "software developer", "software engineer", "developer", "programmer", and "coder" are all equivalent. Articles geared toward any of the above are included, unless point (5) also applies.

This is -- as far as I can tell -- the most complete meta-list of software development book recommendations anywhere on the Internet. I went through every result Google returned for "books software developer" as well as every article with "books" in the title on Dev.To and this is the result. If you find a list of book recommendations for general software development which isn't included in my sources spreadsheet on GitHub, please let me know. I'd be happy to add it to the list if it meets my criteria outlined above.

And, without further ado, the list:

Patterns of Enterprise Application Architecture by Martin Fowler

#20. Patterns of Enterprise Application Architecture

by Martin Fowler (3-way tie with #19 and #18)

13.0% recommended

This book is actually two books in one. The first section is a short tutorial on developing enterprise applications, which you can read from start to finish to understand the scope of the book's lessons. The next section, the bulk of the book, is a detailed reference to the patterns themselves. Each pattern provides usage and implementation information, as well as detailed code examples in Java or C#. The entire book is also richly illustrated with UML diagrams to further explain the concepts.

Armed with this book, you will have the knowledge necessary to make important architectural decisions about building an enterprise application and the proven patterns for use when building them.

-- Amazon.com

Clean Architecture: A Craftsman's Guide to Software Structure and Design by Robert C. "Uncle Bob" Martin

#19. Clean Architecture: A Craftsman's Guide to Software Structure and Design

by Robert C. "Uncle Bob" Martin

13.0% recommended (3-way tie with #20 and #18)

-- Amazon.com

The Art of Computer Programming by Donald Knuth

#18. The Art of Computer Programming

by Donald Knuth

13.0% recommended (3-way tie with #20 and #19)

This magnificent tour de force presents a comprehensive overview of a wide variety of algorithms and the analysis of them. Now in its third edition, The Art of Computer Programming... contains substantial revisions by the author and includes numerous new exercises.

Although this book was conceived several decades ago, it is still a timeless classic. One of the book's greatest strengths is the wonderful collection of problems that accompany each chapter. The author has chosen problems carefully and indexed them according to difficulty. Solving a substantial number of these problems will help you gain a solid understanding of the issues surrounding the given topic. Furthermore, the exercises feature a variety of classic problems.

-- Amazon.com

CODE: The Hidden Language of Computer Hardware and Software by Charles Petzold

#17. CODE: The Hidden Language of Computer Hardware and Software

by Charles Petzold

15.9% recommended (tied with #16)

What do flashlights, the British invasion, black cats, and seesaws have to do with computers? In CODE, they show us the ingenious ways we manipulate language and invent new means of communicating with each other. And through CODE, we see how this ingenuity and our very human compulsion to communicate have driven the technological innovations of the past two centuries.

Using everyday objects and familiar language systems such as Braille and Morse code, author Charles Petzold weaves an illuminating narrative for anyone who’s ever wondered about the secret inner life of computers and other smart machines.

It's a cleverly illustrated and eminently comprehensible story—and along the way, you’ll discover you’ve gained a real context for understanding today's world of PCs, digital media, and the Internet. No matter what your level of technical savvy, CODE will charm you—and perhaps even awaken the technophile within.

-- Amazon.com

Agile Software Development: Principles, Patterns, and Practices by Robert C. "Uncle Bob" Martin

#16. Agile Software Development: Principles, Patterns, and Practices

by Robert C. "Uncle Bob" Martin

15.9% recommended (tied with #17)

Written by a software developer for software developers, this book is a unique collection of the latest software development methods. The author includes OOD, UML, Design Patterns, Agile and XP methods with a detailed description of a complete software design for reusable programs in C++ and Java. Using a practical, problem-solving approach, it shows how to develop an object-oriented application—from the early stages of analysis, through the low-level design and into the implementation. Walks readers through the designer's thoughts — showing the errors, blind alleys, and creative insights that occur throughout the software design process. The book covers: Statics and Dynamics; Principles of Class Design; Complexity Management; Principles of Package Design; Analysis and Design; Patterns and Paradigm Crossings. Explains the principles of OOD, one by one, and then demonstrates them with numerous examples, completely worked-through designs, and case studies. Covers traps, pitfalls, and work arounds in the application of C++ and OOD and then shows how Agile methods can be used. Discusses the methods for designing and developing big software in detail. Features a three-chapter, in-depth, single case study of a building security system. For Software Engineers, Programmers, and Analysts who want to understand how to design object oriented software with state of the art methods.

-- Amazon.com

Introduction to Algorithms by Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and Clifford Stein

#15. Introduction to Algorithms

by Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and Clifford Stein

17.4% recommended (3-way tie with #14 and #13)

Some books on algorithms are rigorous but incomplete; others cover masses of material but lack rigor. Introduction to Algorithms uniquely combines rigor and comprehensiveness. The book covers a broad range of algorithms in depth, yet makes their design and analysis accessible to all levels of readers. Each chapter is relatively self-contained and can be used as a unit of study. The algorithms are described in English and in a pseudocode designed to be readable by anyone who has done a little programming. The explanations have been kept elementary without sacrificing depth of coverage or mathematical rigor.

The first edition became a widely used text in universities worldwide as well as the standard reference for professionals. The second edition featured new chapters on the role of algorithms, probabilistic analysis and randomized algorithms, and linear programming. The third edition has been revised and updated throughout. It includes two completely new chapters, on van Emde Boas trees and multithreaded algorithms, substantial additions to the chapter on recurrence (now called “Divide-and-Conquer”), and an appendix on matrices. It features improved treatment of dynamic programming and greedy algorithms and a new notion of edge-based flow in the material on flow networks. Many exercises and problems have been added for this edition

-- Amazon.com

Head First Design Patterns: A Brain-Friendly Guide by Eric Freeman, Elizabeth Robson, Kathy Sierra, and Bert Bales

#14. Head First Design Patterns: A Brain-Friendly Guide

by Eric Freeman, Elizabeth Robson, Kathy Sierra, and Bert Bales

17.4% recommended (3-way tie with #15 and #13)

At any given moment, someone struggles with the same software design problems you have. And, chances are, someone else has already solved your problem. This edition of Head First Design Patterns—now updated for Java 8—shows you the tried-and-true, road-tested patterns used by developers to create functional, elegant, reusable, and flexible software. By the time you finish this book, you’ll be able to take advantage of the best design practices and experiences of those who have fought the beast of software design and triumphed.

-- Amazon.com

Cracking the Coding Interview: 189 Programming Questions and Solutions by Gayle Laakmann McDowell

#13. Cracking the Coding Interview: 189 Programming Questions and Solutions

by Gayle Laakmann McDowell

17.4% recommended (3-way tie with #15 and #14)

-- Amazon.com

Don't Make Me Think: A Common Sense Approach to Web Usability by Steve Krug

#12. Don't Make Me Think: A Common Sense Approach to Web Usability

by Steve Krug

18.8% recommended (tied with #11)

Don't Make Me Think is a book by Steve Krug about human–computer interaction and web usability. The book's premise is that a good software program or web site should let users accomplish their intended tasks as easily and directly as possible. Krug points out that people are good at satisficing, or taking the first available solution to their problem, so design should take advantage of this. He frequently cites Amazon.com as an example of a well-designed web site that manages to allow high-quality interaction, even though the web site gets bigger and more complex every day.

The book itself is intended to be an example of concision (brevity) and well-focused writing. The goal, according to the book's introduction, was to make a text that could be read by an executive on a two-hour airplane flight.

-- Wikipedia

The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. "Uncle Bob" Martin

#11. The Clean Coder: A Code of Conduct for Professional Programmers

by Robert C. "Uncle Bob" Martin

18.8% recommended (tied with #12)

Programmers who endure and succeed amidst swirling uncertainty and nonstop pressure share a common attribute: They care deeply about the practice of creating software. They treat it as a craft. They are professionals.

In The Clean Coder: A Code of Conduct for Professional Programmers, legendary software expert Robert C. Martin introduces the disciplines, techniques, tools, and practices of true software craftsmanship. This book is packed with practical advice–about everything from estimating and coding to refactoring and testing. It covers much more than technique: It is about attitude. Martin shows how to approach software development with honor, self-respect, and pride; work well and work clean; communicate and estimate faithfully; face difficult decisions with clarity and honesty; and understand that deep knowledge comes with a responsibility to act.

-- Amazon.com

Soft Skills: The Software Developer's Life Manual by John Sonmez

#10. Soft Skills: The Software Developer's Life Manual

by John Sonmez

23.2% recommended (tied with #11)

Soft Skills: The Software Developer's Life Manual is a guide to a well-rounded, satisfying life as a technology professional. In it, developer and life coach John Sonmez offers advice to developers on important "soft" subjects like career and productivity, personal finance and investing, and even fitness and relationships. Arranged as a collection of 71 short chapters, this fun-to-read book invites you to dip in wherever you like. A Taking Action section at the end of each chapter shows you how to get quick results. Soft Skills will help make you a better programmer, a more valuable employee, and a happier, healthier person.

-- Amazon.com

Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister

#9. Peopleware: Productive Projects and Teams

by Tom DeMarco and Timothy Lister

23.2% recommended (tied with #12)

Peopleware is a popular book about software organization management. The first chapter of the book claims, "The major problems of our work are not so much technological as sociological in nature". The book approaches sociological or 'political' problems such as group chemistry and team jelling, "flow time" and quiet in the work environment, and the high cost of turnover. Other topics include the conflicts between individual work perspective and corporate ideology, corporate entropy, "teamicide" and workspace theory.

The authors presented most subjects as principles backed up by some concrete story or other information. As an example, the chapter "Spaghetti Dinner" presents a fictional example of a manager inviting a new team over for dinner, then having them buy and prepare the meal as a group, in order to produce a first team success. Other chapters use real-life stories or cite various studies to illustrate the principles being presented

-- Wikipedia

Programming Pearls by Jon Bentley

#8. Programming Pearls

by Jon Bentley

26.1% recommended

Computer programming has many faces. Fred Brooks paints the big picture in The Mythical Man Month; his essays underscore the crucial role of management in large software projects. At a finer grain, Steve McConnell teaches good programming style in Code Complete. The topics in those books are the key to good software and the hallmark of the professional programmer. Unfortunately, though, the workmanlike application of those sound engineering principles isn't always thrilling -- until the software is completed on time and works without surprise.

The columns in this book are about a more glamorous aspect of the profession: programming pearls whose origins lie beyond solid engineering, in the realm of insight and creativity. Just as natural pearls grow from grains of sand that have irritated oysters, these programming pearls have grown from real problems that have irritated real programmers. The programs are fun, and they teach important programming techniques and fundamental design principles.

-- Amazon.com

Working Effectively with Legacy Code by Michael Feathers

#7. Working Effectively with Legacy Code

by Michael Feathers

27.5% recommended (tied with #6)

Is your code easy to change? Can you get nearly instantaneous feedback when you do change it? Do you understand it? If the answer to any of these questions is no, you have legacy code, and it is draining time and money away from your development efforts.

In this book, Michael Feathers offers start-to-finish strategies for working more effectively with large, untested legacy code bases. This book draws on material Michael created for his renowned Object Mentor seminars: techniques Michael has used in mentoring to help hundreds of developers, technical managers, and testers bring their legacy systems under control. Topics covered include:

-- Amazon.com

The Mythical Man-Month: Essays on Software Engineering by Frederick P. Brooks

#6. The Mythical Man-Month: Essays on Software Engineering

by Frederick P. Brooks

27.5% recommended (tied with #7)

Few books on software project management have been as influential and timeless as The Mythical Man-Month. With a blend of software engineering facts and thought-provoking opinions, Fred Brooks offers insight for anyone managing complex projects. These essays draw from his experience as project manager for the IBM System/360 computer family and then for OS/360, its massive software system. Now, 20 years after the initial publication of his book, Brooks has revisited his original ideas and added new thoughts and advice, both for readers already familiar with his work and for readers discovering it for the first time.

-- Amazon.com

read my review of The Mythical Man-Month on Dev.To

Refactoring: Improving the Design of Existing Code by Martin Fowler

#5. Refactoring: Improving the Design of Existing Code

by Martin Fowler

33.3% recommended (tied with #4)

For more than twenty years, experienced programmers worldwide have relied on Martin Fowler’s Refactoring to improve the design of existing code and to enhance software maintainability, as well as to make existing code easier to understand.

This eagerly awaited new edition has been fully updated to reflect crucial changes in the programming landscape. Refactoring, Second Edition, features an updated catalog of refactorings and includes JavaScript code examples, as well as new functional examples that demonstrate refactoring without classes.

Like the original, this edition explains what refactoring is; why you should refactor; how to recognize code that needs refactoring; and how to actually do it successfully, no matter what language you use.

-- Amazon.com

Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, and Ralph Johnson

#4. Design Patterns: Elements of Reusable Object-Oriented Software

by Erich Gamma, Richard Helm, and Ralph Johnson

33.3% recommended (tied with #5)

This book isn't an introduction to object-oriented technology or design. Many books already do a good job of that...this isn't an advanced treatise either. It's a book of design patterns that describe simple and elegant solutions to specific problems in object-oriented software design....Once you understand the design patterns and have had an "Aha!" (and not just a "Huh?" experience with them, you won't ever think about object-oriented design in the same way. You'll have insights that can make your own designs more flexible, modular, reusable, and understandable--which is why you're interested in object-oriented technology in the first place, right?

-- Amazon.com

Code Complete: A Practical Handbook of Software Construction by Steve McConnell

#3. Code Complete: A Practical Handbook of Software Construction

by Steve McConnell

44.9% recommended

Widely considered one of the best practical guides to programming, Steve McConnell’s original Code Complete has been helping developers write better software for more than a decade. Now this classic book has been fully updated and revised with leading-edge practices—and hundreds of new code samples—illustrating the art and science of software construction. Capturing the body of knowledge available from research, academia, and everyday commercial practice, McConnell synthesizes the most effective techniques and must-know principles into clear, pragmatic guidance. No matter what your experience level, development environment, or project size, this book will inform and stimulate your thinking—and help you build the highest quality code.

-- Amazon.com

The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and Dave Thomas

#2. The Pragmatic Programmer: From Journeyman to Master

by Andrew Hunt and Dave Thomas

47.8% recommended

Programmers are craftspeople trained to use a certain set of tools (editors, object managers, version trackers) to generate a certain kind of product (programs) that will operate in some environment (operating systems on hardware assemblies). Like any other craft, computer programming has spawned a body of wisdom, most of which isn't taught at universities or in certification classes. Most programmers arrive at the so-called tricks of the trade over time, through independent experimentation. In The Pragmatic Programmer, Andrew Hunt and David Thomas codify many of the truths they've discovered during their respective careers as designers of software and writers of code.

Some of the authors' nuggets of pragmatism are concrete, and the path to their implementation is clear. They advise readers to learn one text editor, for example, and use it for everything. They also recommend the use of version-tracking software for even the smallest projects, and promote the merits of learning regular expression syntax and a text-manipulation language. Other (perhaps more valuable) advice is more light-hearted. In the debugging section, it is noted that, "if you see hoof prints think horses, not zebras." That is, suspect everything, but start looking for problems in the most obvious places. There are recommendations for making estimates of time and expense, and for integrating testing into the development process. You'll want a copy of The Pragmatic Programmer for two reasons: it displays your own accumulated wisdom more cleanly than you ever bothered to state it, and it introduces you to methods of work that you may not yet have considered. Working programmers will enjoy this book.

-- David Wall via Amazon.com

Finally, the single most-recommended book for software developers:

Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. "Uncle Bob" Martin

#1. Clean Code: A Handbook of Agile Software Craftsmanship

by Robert C. "Uncle Bob" Martin

52.2% recommended

Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way.

Noted software expert Robert C. Martin presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship. Martin has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code “on the fly” into a book that will instill within you the values of a software craftsman and make you a better programmer—but only if you work at it.

What kind of work will you be doing? You’ll be reading code—lots of code. And you will be challenged to think about what’s right about that code, and what’s wrong with it. More importantly, you will be challenged to reassess your professional values and your commitment to your craft.

Clean Code is divided into three parts. The first describes the principles, patterns, and practices of writing clean code. The second part consists of several case studies of increasing complexity. Each case study is an exercise in cleaning up code—of transforming a code base that has some problems into one that is sound and efficient. The third part is the payoff: a single chapter containing a list of heuristics and “smells” gathered while creating the case studies. The result is a knowledge base that describes the way we think when we write, read, and clean code.

Readers will come away from this book understanding

-- Amazon.com

The above "recommendation percentages" are the fraction of all lists surveyed which contain that book. So even if a book is only "12.5% recommended", it means that, on average, 1 out of every 8 developers has read that book and recommends it to other developers. All of the books above pass that 1-in-8 threshold.

More surprisingly are the books in the top 10. Books #10 through #6 are recommended by 1 in every 4 developers on average. Books #5 and #4 are recommended by 1 in every 3. And the top three books, Code Complete, The Pragmatic Programmer, and Clean Code, are recommended by about every other software developer. That is an immense impact on one of the most critical industries in modern society. If you're looking to strengthen your software development knowledge and you haven't yet read these three books, there's a good chance about half of your coworkers would recommend that you do so.

If you enjoyed the above article, maybe you'd like to follow my work on Dev.To? Or read my dumb tweets on The Tweeter? Or buy me a cup of coffee? (I have a debilitating caffeine addiction.)

Anyway, thanks for stopping by!