Pete has had some terrible luck with the lead programmers he's worked with. He's had a few which are… well, they don't take feedback well. Like his current team lead, who absolutely doesn't let any of the other developers review or comment on his code. "Don't ask me questions, you should know this already," is a common refrain. Speaking of questions:

String q1 = form.getQ1()!=null?request.getParameter("question_" + form.getQ1().getId()):null;
String q2 = form.getQ2()!=null?request.getParameter("question_" + form.getQ2().getId()):null;
String q3 = form.getQ3()!=null?request.getParameter("question_" + form.getQ3().getId()):null;
String q4 = form.getQ4()!=null?request.getParameter("question_" + form.getQ4().getId()):null;
String q5 = form.getQ5()!=null?request.getParameter("question_" + form.getQ5().getId()):null;
String q6 = form.getQ6()!=null?request.getParameter("question_" + form.getQ6().getId()):null;
String q7 = form.getQ7()!=null?request.getParameter("question_" + form.getQ7().getId()):null;
String q8 = form.getQ8()!=null?request.getParameter("question_" + form.getQ8().getId()):null;
String q9 = form.getQ9()!=null?request.getParameter("question_" + form.getQ9().getId()):null;
String q10 = form.getQ10()!=null?request.getParameter("question_" + form.getQ10().getId()):null;
String q11 = form.getQ11()!=null?request.getParameter("question_" + form.getQ11().getId()):null;
String q12 = form.getQ12()!=null?request.getParameter("question_" + form.getQ12().getId()):null;                   
String q13 = form.getQ13()!=null?request.getParameter("question_" + form.getQ13().getId()):null;
String q14 = form.getQ14()!=null?request.getParameter("question_" + form.getQ14().getId()):null;
String q15 = form.getQ15()!=null?request.getParameter("question_" + form.getQ15().getId()):null;

Jan's company has an application which needs to handle an Excel spreadsheet, because as I'm fond of pointing out, users love spreadsheets.

The JavaScript code which handles parsing the spreadsheet contains… some choices. These choices caused it to fail on any spreadsheet with more than twenty six columns, and it's not hard to see why.

One of the arguments against comments in code is that they create a need to have two things updated: the code and the documentation have to be kept in sync. Inevitably, they'll drift apart.

David works with a junior developer who came onto the team with strong opinions about, well, everything. One of those strong opinions is that every single line needs to have comments. Each and every one.

Folks who first learned to type on typewriters tend to prefer putting two spaces after a period.  Most of the rest of us prefer just one. And this may have caused a performance problem.

Rob's application had a quick search feature to track down customer claims. One day, the quick search was running quickly and efficiently. A user could type in a claim number, hit enter, and a moment later their screen would show the claim. Suddenly, it slowed down. It wasn't just the gradual decline of growing data or stale statistics or bad indexes. It was a code change, and it didn't take long to find the problem:

One of the "legacy" PHP applications needed a few bugfixes. "Legacy" in this case, means "written by a developer who doesn't work here anymore", so mostly everyone tried to dodge getting those bugfixes assigned to them. Joe was taking a three day weekend at the time, so a helpful co-worker assigned the tickets to him.

The code wasn't an absolute disaster, but it suffered from being written by a "smart" programmer. Since they were so smart, they couldn't just do things using the basic language constructs, they had to find clever ways to abuse them.

Arguably, the biggest problem with SQL as a query language is that we usually execute SQL statements from inside of some other programming language. It tempts us into finding quick hacks to generate dynamic SQL statements, and if we do it the quick way, we find ourselves doing a lot of string concatenation. That way lies SQL injection vulnerabilities.

Constructing SQL statements by stringing together text is always a bad idea, even if you're still using query parameters. There's a reason why most modern database wrappers provide some sort of builder pattern to safely construct dynamic queries. Even so, everyone wants to find their own… special way to accomplish this.