Effective Programming: More Than Writing Code
Format: PDF / Kindle (mobi) / ePub
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.
TABLE OF CONTENTS
- The Art of Getting Shit Done
- Principles of Good Programming
- Hiring Programmers the Right Way
- Getting Your Team to Work Together
- The 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
you to tell me — no, better yet, stand up and tell the class — what do you wanna do with your life? You want to rock, naturally! Or at least be a rockstar programmer. It’s not a question that typically gets a serious answer — sort of like that other old groan-inducing interview chestnut, “what’s your greatest weakness?” It’s that you sometimes rock too hard, right? Innocent bystanders could get hurt. But I think this is a different and more serious class of question, one that deserves real
entry a few times every week and you’re bound to become a better writer. If you’re not writing because you’re intimidated by writing, well, you’re likely to stay that way forever. Even with the best of intentions, telling someone “you should blog!” never works. I know this from painful first hand experience. Blogging isn’t for everyone. Even a small blog entry can seem like an insurmountable, impenetrable, arbitrary chunk of writing to the average programmer. How do I get my fellow programmers
need more time! We ran into unforeseen technical problems that forced us to make compromises we are uncomfortable with. We had the wrong design, and needed to change it in the middle of development. Our team experienced internal friction between team members that we didn’t anticipate. The customers weren’t who we thought they were. Communication between the designers, developers and project team wasn’t as efficient as we thought it would be. We overestimated how quickly we could learn a new
years. Per user! But a dictionary attack, like the one used in the Twitter hack? Well, that’s another story. The entire Oxford English Dictionary contains around 171,000 words. As you might imagine, the average person only uses a tiny fraction of those words, by some estimates somewhere between 10 and 40 thousand. At one attempt per second, we could try every word in the Oxford English Dictionary in slightly less than two days. Clearly, the last thing you want to do is give attackers carte
should be a first-class language construct. However, I think the test-first dogmatists tend to be a little too religious for their own good. Asking developers to fundamentally change the way they approach writing software overnight is asking a lot. Particularly if those developers have yet to write their first unit test. I don’t think any software development shop is ready for test-first development until they’ve adopted unit testing as a standard methodology on every software project they