"EFFECTIVE PROGRAMMING: MORE THAN WRITING CODE" by Jeff Atwood

• Slinging code is just a tiny part of the overall solution in my experience. Why optimize for that? On the earliest computers, everyone had to be a programmer because there was no software. If you wanted the computer to do anything, you wrote code.
• I view the entire arc of software development as a field where we programmers spend our lives writing code so that our fellow human beings no longer need to write code (or even worse, become programmers) to get things done with computers.
• I'm hesitant to recommend any particular approach to coding other than the fundamentals as outlined in Code: The Hidden Language of Computer Hardware and Software, because I'm not sure we'll even recognize coding in the next 20 or 30 years.
• The toughest thing in life is not learning a bunch of potentially hypothetically useful stuff, but figuring out what the heck it is you want to do.
• What I advocate is shamelessly following your joy.
• People who work with money tend to make a lot of money; see Wall Street.
• Dead Programmer This is the highest level. Your code has survived and transcended your death. You are a part of the permanent historical record of computing. Other programmers study your work and writing.
• Successful Programmer Programmers who are both well known and have created entire businesses — perhaps even whole industries — around their code.
• Famous is good, but successful is better.
• Talent often has little to do with success. You can be very successful if you have business and people skills.
• Don't knock the value of self-awareness. It's more rare than you realize. There's nothing wrong with lacking talent. Be bold. Figure out what you're good at, and pursue it. Aggressively.
• Being an amateur is a good thing; from this level one can rapidly rise to become a working programmer.
• Over the last six years, I’ve come to believe deeply in the idea that that becoming a great programmer has very little to do with programming. Yes, it takes a modicum of technical skill and dogged persistence, absolutely. But even more than that, it takes serious communication skills.
• Communication is just plain hard, particularly written communication.
• If you’re not writing because you’re intimidated by writing, well, you’re likely to stay that way forever.
• If you can effectively write for and be accepted by a group of programmers you can write for anyone.
• If you’re an author, editor, reviewer, blogger, copywriter or aspiring writer of any kind, professional or otherwise — check out writers.stackexchange.com. Becoming a more effective writer is the one bedrock skill that will further your professional career, no matter what you choose to do.
• Clarifying your communication helps you to clarify your own internal thought processes, in my experience. It’s amazing how much you find you don’t know when you try to explain something in detail to someone else.
• Teaching peers is one of the best ways to develop mastery.
• The concept of intrinsic motivation may not be a new one, but I find that very few companies are brave enough to actually implement them.
• Of course, the best way to improve at something is to do it as often as possible.
• People are often successful not despite their dysfunctions but because of them. Obsessions are one of the greatest telltale signs of success.
• Boyd decided that the primary determinant to winning dogfights was not observing, orienting, planning or acting better. The primary determinant to winning dogfights was observing, orienting, planning and acting faster. In other words, how quickly one could iterate. Speed of iteration, Boyd suggested, beats quality of iteration.
• Whenever possible, avoid interruptions and avoid working on more than one project at the same time.
• The First Rule of Programming: It’s Always Your Fault.
• An essential part of being a humble programmer is realizing that whenever there's a problem with the code you've written, it's always your fault.
• No matter what the problem is with your software — maybe it's not even your code in the first place — always assume the problem is in your code and act accordingly.
• Whatever the problem with your software is, take ownership.
• As a software developer, you are your own worst enemy. The sooner you realize that, the better off you'll be.
• 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.
• If you can't get away with no code, the next best thing is to start with brevity.
• No matter what the documentation says, the source code is the ultimate truth, the best and most definitive and up-to-date documentation you're likely to find.
• True hackers have come to terms with a simple fact: If it runs on my machine, it's my software. I'm responsible for it. I must understand it. Building from source is the rule and not an exception. I must control my environment and I must control my dependencies.
• Sometimes asking the right question seems like half the problem.
• "Ask the Duck" is a very powerful problem-solving technique.
• The critical part of rubber duck problem solving is to totally commit to asking a thorough, detailed question of this imaginary person or inanimate object.
• But if you aren't willing to put the effort into fully explaining the problem and how you've attacked it, you can't reap the benefits of thinking deeply about your own problem before you ask others to.
• Even if you don't get the answer you wanted, forcing yourself to fully explain your problem – ideally in writing – will frequently lead to new insights and discoveries.
• To me, ideas are worth nothing unless executed. They are just a multiplier. Execution is worth millions.
• Success is rarely determined by the quality of your ideas. But it is frequently determined by the quality of your execution.
• I don't care how internet famous you are; nobody gets a pass on execution.
• If you give a good idea to a mediocre group, they'll screw it up. If you give a mediocre idea to a good group, they'll fix it. Or they'll throw it away and come up with something else.
• If you want to be successful, stop worrying about the great ideas, and concentrate on cultivating great teams.
• Software developers do love to code. But very few of them, in my experience, can explain why they're coding.
• Software developers think their job is writing code. But it's not.* Their job is to solve the customer's problem.
• Writing code is something you have to do to deliver a solution. It is not an end in and of itself.
• There’s plenty of experimental data proving that the slower your website loads and displays, the less people will use it.
• When it comes to website performance, there is no getting around one fundamental law of the universe: you can never serve a webpage faster than it you can render it on the server.
• I was incredulous when I read this observation from Reginald Braithwaite: Like me, the author is having trouble with the fact that 199 out of 200 applicants for every programming job can't write code at all. I repeat: they can't write any code whatsoever.
• If you can successfully write a loop that goes from 1 to 10 in every language on your resume, can do simple arithmetic without a calculator, and can use recursion to solve a real problem, you're already ahead of the pack!
• How to interview a programmer:
• 1. First, pass a few simple "Hello World" online tests.
• 2. Ask to see their portfolio. Any programmer worth their salt should have a portfolio of the things they've worked on.
• 3. Hire for cultural fit.
• The goal is to make sure that the candidates that do make it to the next step are not wasting their time or yours. So don't be shy about sticking to your guns and ending the call early if there are too many warning flags.
• If you want to determine beyond the shadow of a doubt if someone's going to be a great hire, give them an audition project.
• You should be 95 percent certain that a candidate would be a great hire before they ever set foot in an interview room.
• Have the candidate give a 15-minute presentation on their area of expertise. I think this is a far better indicator of success than a traditional interview,
• Even in the best of circumstances, hiring human beings is hard.
• If you think of work as a relationship, one you'll spend 40 hours a week (or more) in the rest of your life, it behooves everyone involved to "date smart."
• Coding interview questions:
• Write a function to reverse a string.
• Write function to compute Nth fibonacci number.
• Print out the grade-school multiplication table up to 12×12.
• Write a function that sums up integers from a text file, one int per line.
• Write function to print the odd numbers from 1 to 99.
• Find the largest int value in an int array.
• Format an RGB value (three 1-byte numbers) as a 6-digit hexadecimal string.
• Object-Oriented Programming interview questions:
• Design a deck of cards that can be used for different card game applications.
• Model the Animal kingdom as a class system, for use in a Virtual Zoo program.
• Create a class design to represent a filesystem.
• Design an OO representation to model HTML.
• Data Structures:
• What are some really common data structures, e.g. in java.util?
• When would you use a linked list vs. a vector?
• Can you implement a Map with a tree?
• What about with a list?
• How do you print out the nodes of a tree in level-order (i.e. first level, then 2nd level, then 3rd level, etc.)
• What's the worst-case insertion performance of a hashtable? Of a binary tree?
• What are some options for implementing a priority queue?
• What software developers do best is learn.
• It's been shown time and time again that there is no correlation between years of experience and skill in programming. After about six to twelve months working in any particular technology stack, you either get it or you don't. No matter how many years of "experience" another programmer has under their belt, there's about even odds that they have no idea what they're doing.
• I'm not saying experience doesn't matter in software development. It does. But consider the entire range of a developer's experience, and realize that time invested does not automatically equal skill.
• What I'm optimizing for here is the ability to communicate. Most programmers, once they pass the FizzBuzz level of competency, are decent enough. But coding chops aren't enough. To go from good to great, you must be able to communicate effectively: with your teammates, your manager, the users and ultimately the world.
• Usually the things that make or break a project are process and people issues.
• The people you choose to work with are the most accurate predictor of job satisfaction I've ever found.
• It takes discipline for development teams to benefit from modern software engineering conventions.
• If you want to pull your team up to a higher level of engineering, you need a leader, not an enforcer.
• The best way to earn credibility and respect is through hard work and real results.
• Actions speak louder than words.
• The most effective kind of technical leadership is leading by example.
• Gerald Weinberg's book Becoming a Technical Leader: an Organic Problem-Solving Approach provides a much deeper analysis of leadership that's specific to the profession of software engineering.
• Weinberg's Becoming a Technical Leader is truly a classic. It is, quite simply, the thinking geek's How to Win Friends and Influence People. So much of leadership is learning to give a damn about other people, something that we programmers are notoriously bad at.
• “bunch of engineers in a room” is not leadership.
• Just because you’re a hotshot programmer doesn’t mean you have mastered networking and server configuration.
• In a healthy team, everyone feels their abilities are being used and not squandered.
• The advantage of pair programming is its gripping immediacy: it is impossible to ignore the reviewer when he or she is sitting right next to you.
• When your code is reviewed by another human being — whether that person is sitting right next to you, or thousands of miles away — you will produce better software.
• Meetings should be viewed skeptically from the outset, as risks to productivity.
• No meeting should ever be more than an hour, under penalty of death.
• If you tolerate even one developer whom the other developers think is a problem, you'll hurt the morale of the good developers.
• More than any other single aspect of team leadership, members are disturbed by leaders who are unwilling to deal directly and effectively with self-serving or noncontributing team members.
• Software developers often won't complain directly, so you have to ask if there's a problem when you hear many wisecracks.
• Let me be quite clear on this point: if your team leader or manager isn't dealing with the bad apples on your project, he isn't doing her job.
• Removing someone from a team is painful; it's not fun for anyone. But realizing you should have removed someone six months ago is far more painful.
• The worst team member is the best predictor of how any team performs.
• If you can't tell who the bad apple is in your group, it might be you.
• Don't even think about working remotely with anyone who doesn't freakin' bleed ones and zeros, and has a proven track record of getting things done.
• Chat is the most essential and omnipresent form of communication you have when working remotely, so you need to make absolutely sure it's functioning before going any further.
• Never underestimate the power of actually talking to another human being.
• Time spent staring at a progress bar is wasted time.
• Good programmers never write what they can steal.
• Programming requires focused mental concentration. Programmers cannot work effectively in an interrupt-driven environment.
• I know I've harped on this, but it bears repeating: a quality desk and quality chair will be some of the best investments you'll ever make as a software developer.
• The price of a few monitors is negligible when measured against the labor cost of a programmer or information worker salary.
• Ideally, your monitors shouldn't be any brighter than a well-lit book.
• “Getting the details right is the difference between something that delights, and something customers tolerate.”
• The only variable you can really control is your application's usability. The barrier to entry has to be absurdly low to even get people to look at your software — much less use it.
• Details matter, in fact, a hell of a lot.
• This is all your app is: a collection of tiny details.
• As far as the user is concerned, the UI is the application.
• You have to build an impressive UI if you want to be taken seriously.
• Remember, to the end user, the interface is the application.
• The book Paper Prototyping: The Fast and Easy way to Design and Refine User Interfaces is an excellent introduction to paper prototyping.
• Once you have thousands of items, you don't have a pagination problem. You have a search and filtering problem.
• The plain fact is users will not read anything you put on the screen.
• The time to acquire a target is a function of the distance to and size of the target.
• Fitts' law indicates that the most quickly accessed targets on any computer display are the four corners of the screen, because of their pinning action,
• The edges could be your most valuable real estate.
• The ultimate unit test is whether or not users want to use your application.
• The velocity and responsiveness of your team to user feedback will set the tone for your software, far more than any single release ever could.
• All it takes is one user with a weak password to provide attackers a toehold in your system.
• Limiting the number of login attempts per user is security 101.
• You can think of a checksum as a person's full name: Eubediah Q. Horsefeathers. It's a shortcut to uniqueness that's fast and simple, but easy to forge, because security isn't really the point of naming.
• A properly designed secure hash function changes its output radically with tiny single bit changes to the input data, even if those changes are malicious and intended to cheat the hash.
• Speed of a checksum calculation is important, as checksums are generally working on data as it is being transmitted.
• Rainbow tables are huge pre-computed lists of hashes, trading off table lookups to massive amounts of disk space (and potentially memory) for raw calculation speed.
• The first rule of security is to always assume and plan for the worst.
• You should never, ever store user passwords.
• Encryption is only as effective as the person using it.
• When was the last time you even met a customer, much less tried to talk to them about a problem they're having with your website or software?
• If we aren’t constantly testing our ability to succeed despite failure, then it isn’t likely to work when it matters most — in the event of an unexpected outage.
• The best way to avoid failure is to fail constantly.
• I believe that peer code reviews are the single biggest thing you can do to improve your code.
• The only hurdle to a code review is finding a developer you respect to do it, and making the time to perform the review.
• The general adoption of unit testing is one of the most fundamental advances in software development in the last 5 to 7 years.
• You ask, "What code will I write to generate a solution?" But that's backward. The first thing you ask is not "What code will I write?" The first thing you ask is "How will I know that I've solved the problem?"
• I've increasingly come to believe that unit tests are so important that they should be a first-class language construct.
• Any tests are better than zero tests.
• If a bug exists but no user ever encounters it, do you care?
• Automated test suites are a poor substitute for real-world beta testing by actual beta testers.
• Usability testing is only as difficult as you make it.
• The best-kept secret of usability testing is that it doesn't much matter who you test.
• Some people recommend making your software robust by working around problems automatically. This results in the software "failing slowly." The program continues working right after an error but fails in strange ways later on. A system that fails fast does exactly the opposite: when a problem occurs, it fails immediately and visibly.
• 90 percent of all community feedback is crap.
• Users often don't know what they want, and even if they did, the communication is likely to get garbled somewhere between them and you.
• Make sure your application or website is capturing user activity in a useful, meaningful way.
• Always have some kind of user activity data to corroborate and support the valuable user feedback you're getting.
• Every web forum is the way it is because users wanted it that way.
• A hellbanned user is invisible to all other users, but crucially, not himself. From their perspective, they are participating normally in the community but nobody ever responds to them. They can no longer disrupt the community because they are effectively a ghost.
• If I learned anything from reading The Great Brain as a child, it's that the silent treatment is the cruelest punishment of them all.
• We human beings are a selfish bunch, so it's all the more surprising to see how easily we can be manipulated to behave in ways that run counter to our own self-interest.
• Realize that some premium options exist as decoys — that is, they are there only to make the less expensive options look more appealing, because they're easy to compare.
• Scale your purchases to your needs, not your circumstances or wallet size.
• You will tend to overestimate the value of items you get for free.
• Steer clear of offers of low-rate trial periods which auto-convert into automatic recurring monthly billing.
• There are three fundamental quirks of human nature. We fall in love with what we already have. We focus on what we might lose, rather than what we might gain. We assume that other people will see the transaction from the same perspective as we do.
• We feel compelled to preserve options, even at great expense, even when it doesn't make sense.
• This is the purest form of A/B testing imaginable. Given two choices, pick the one that "wins", and keep repeating this ad infinitum until you arrive at the ultimate, most scientifically desirable choice.
• If it looks corporate, change it.
• Despite popular assertions to the contrary, science tells us that money can buy happiness. To a point.
• But even if you're fortunate enough to have a good income, how you spend your money has a strong influence on how happy — or unhappy — it will make you.
• Most people don't know the basic scientific facts about happiness — about what brings it and what sustains it — and so they don't know how to use their money to acquire it.
• Buy experiences instead of things.
• Help others instead of yourself.
• Buy many small pleasures instead of few big ones.
• Because we adapt so readily to change, the most effective use of your money is to bring frequent change, not just "big bang" changes that you will quickly grow acclimated to.
• Buy less insurance.
• Pay now and consume later.
• Don't overestimate your ability to independently predict how much you'll enjoy something. We are, scientifically speaking, very bad at this.