Effective Programming: More Than Writing Code

by Jeff Atwood

What's in the book?

Your one-stop shop for all things programming.

    • The Art of Getting Shit Done
    • The Principles of Good Programming
    • Hiring Programmers the Right Way
    • Getting Your Team To Work Together
    • Your Batcave: Effective Workspaces for Programmers
    • Designing With the User in Mind
    • Security Basics: Protecting Your Users' Data
    • Testing Your Code, So It Doesn't Suck More Than It Has To
    • Building, Managing and Benefiting From a Community
    • Marketing Weasels and How Not to Be One
    • Keeping Your Priorities Straight

Description

ABOUT THE BOOK

Jeff Atwood began the Coding Horror blog in 2004, and is convinced that it changed his life. He needed a way to keep track of software development over time – whatever he was thinking about or working on. He researched subjects he found interesting, then documented his research with a public blog post, which he could easily find and refer to later. Over time, increasing numbers of blog visitors found the posts helpful, relevant and interesting. Now, approximately 100,000 readers visit the blog per day and nearly as many comment and interact on the site.

Effective Programming: More Than Writing Code is your one-stop shop for all things programming. Jeff writes with humor and understanding, allowing for both seasoned programmers and newbies to appreciate the depth of his research. From such posts as

“The Programmer’s Bill of Rights” and “Why Cant Programmers... Program?” to “Working With the Chaos Monkey,” this book introduces the importance of writing responsible code, the logistics involved, and how people should view it more as a lifestyle than a career.

ABOUT THE AUTHOR

Jeff Atwood lives in Berkeley, CA with his wife, two cats, three children and a whole lot of computers. He was weaned as a software developer on various implementations of Microsoft BASIC in the '80s, starting with his first microcomputer, the Texas Instruments TI-99/4a. Atwood continued on the PC with Visual Basic 3.0 and Windows 3.1 in the early ’90s, although he also spent significant time writing Pascal code in the first versions of Delphi. He is now quite comfortable in VB.NET or C#, despite the evils of case sensitivity. He's currently learning Ruby.

Atwood considers himself a reasonably experienced web software developer with a particular interest in the human side of software development, as represented in his recommended developer reading list. As he avers, computers are fascinating machines, but they're mostly a reflection of the people using them. In the art of software development, studying code isn't enough; you have to study the people behind the software, too.

EXCERPT FROM THE BOOK

As a software developer, you are your own worst enemy. The sooner you realize that, the better off you'll be.I know you have the best of intentions. We all do. We're software developers; we love writing code. It's what we do. We never met a problem we couldn't solve with some duct tape, a jury-rigged coat hanger and a pinch of code. But Wil Shipley argues that we should rein in our natural tendencies to write lots of code:

The fundamental nature of coding is that our task, as programmers, is to recognize that every decision we make is a trade-off. To be a master programmer is to understand the nature of these trade-offs, and be conscious of them in everything we write.In coding, you have many dimensions in which you can rate code:

  • Brevity of code
  • Featurefulness
  • Speed of execution
  • Time spent coding
  • Robustness
  • Flexibility

Now, remember, these dimensions are all in opposition to one another. You can spend three days writing a routine which is really beautiful and fast, so you've gotten two of your dimensions up, but you've spent three days, so the "time spent coding" dimension is way down.So, when is this worth it? How do we make these decisions? The answer turns out to be very sane, very simple, and also the one nobody, ever, listens to: Start with brevity. Increase the other dimensions as required by testing.

I couldn't agree more. I've given similar advice when I exhorted developers to Code Smaller. And I'm not talking about a reductio ad absurdum contest where we use up all the clever tricks in our books to make the code fit into less physical space. I'm talking about practical, sensible strategies to reduce the volume of code an individual programmer has to read to understand how a program works. Here's a trivial little example of what I'm talking about:

if (s == String.Empty)if (s == "")

It seems obvious to me that the latter case is better because it's just plain smaller. And yet I'm virtually guaranteed to encounter developers who will fight me, almost literally to the death, because they're absolutely convinced that the verbosity of String.Empty is somehow friendlier to the compiler. As if I care about that. As if anyone cared about that!

It's painful for most software developers to acknowledge this, because they love code so much, but the best code is no code at all. Every new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported. Every time you write new code, you should do so reluctantly, under duress, because you completely exhausted all your other options. Code is only our enemy because there are so many of us programmers writing so damn much of it. If you can't get away with no code, the next best thing is to start with brevity.

If you love writing code -- really, truly love to write code -- you'll love it enough to write as little of it as possible.

Like what you're reading? Buy this book!

Follow us on Twitter!

Like us on Facebook!

Signup for our newsletter!

Price: $2.99 Add to Cart
  • Lifetime guarantee
  • 100% refund
  • Free updates