Signs that you're a bad programmer

I have to say, I really didn't like the document much. Not because of substance. Some of what he says is true.<p>On style, though, I think the document is trash. Some of what I say is probably even a bit ad hominem.<p>Most of the good programmers I know don't spend time worrying about bad programmers. They just write good code and cleanup bad code when they see it.<p>If someone feels compelled to write up an essay about bad programmers, he probably spends a lot of time dealing with bad programmers.<p>That experience should lead to humility, not arrogance. If you deal with a lot of bad programmers, you might not be as good as you think you are. After all, you work at the same place on the same project as a bunch of bad programmers. They where hired under the same standards as you.<p>To me, the document just seemed like arrogant posturing. An attempt at crafting a "negative identity" (define a group by vilifying the outsider). The best way to "be", and to be recognized as, a good programmer is to write good code. All the other stuff is just horse shit.

Google cache for those who hit the "pageview limit exceeded" nonsense:<p><a href="http://www.google.com/url?sa=t&#38;source=web&#38;ct=clnk&#38;cd=1&#38;url=http%3A%2F%2F74.125.155.132%2Fsearch%3Fq%3Dcache%3AA7_WaV28LBcJ%3Asites.google.com%2Fsite%2Fyacoset%2FHome%2Fsigns-that-you-re-a-bad-programmer%2Bhttp%3A%2F%2Fsites.google.com%2Fsite%2Fyacoset%2FHome%2Fsigns-that-you-re-a-bad-programmer%26cd%3D1%26hl%3Den%26ct%3Dclnk%26gl%3Dus&#38;ei=G6p7Spq1CovYsgPg8KXvCg&#38;rct=j&#38;q=http%3A%2F%2Fsites.google.com%2Fsite%2Fyacoset%2FHome%2Fsigns-that-you-re-a-bad-programmer&#38;usg=AFQjCNHJJZpSR-zgzZoC-dz6oeOChaPpqA" rel="nofollow">http://www.google.com/url?sa=t&#38;source=web&#38;ct=clnk&#3...</a>

Oh man, I wish I had this at my last job half the team had over 50% of these symptoms, one guy had 90%. They believed, and had somehow convinced management, that they were great programmers! Some awesome practical examples from those guys below:<p>Overheard statement "You know when I was in college I learned C. I just can't get the hang of these objects, so I try to avoid them". The guy who said this is now 34, and has programmed python for 4 years.<p>A guy who would copy and paste 100 line blocks of code, and then occasionally thing "oh yeah, i need functions", and then finish out the current function by passing 12 parameters of state to current_function_2(). If you combined the func, func_2 and factored out the 100 line blocks it would be reverted with a commit: "stop making this so complicated".<p>There was one guy who insisted that using templates was only for web frameworks, to use them to write system/config files (done frequently due to 3rd party daemon limitations) was an abuse of the templating system, and we should just use inline prints. The program was to be called with prog &#62; /etc/conffile.<p>One guy who decided that threads were so tricky, that he was the arbiter of thier use. My idea of a job queue and worker threads was "too abstract and hard to debug", so we stuck with the "tried and true" one thread per job method, all spawned at once.<p>I could go on, but you're all prolly bored now :)<p>tl;dr: i worked with the guys the article was written about

Funny that he has this under "Signs that you shouldn't be a programmer": "you think the presence of code in a program will affect its runtime behavior, even if it is never invoked".<p>Anyone who has written code in C can probably cite an anecdote where exactly this was the case, be it from a compiler bug or as fallout from a memory corruption bug.<p>Maybe we should add "does not understand the von Neumann architecture" to the list of signs that you're a mediocre programmer... On second thought, let's not -- the piece is bad enough to begin with. The "alternative careers" sections are just odious, and the whole thing breathes an air of inconstructiveness.

Here's a flaw which I've seen in several otherwise <i>good</i> programmers - forgetting that sometimes the core purpose of code is to be read and maintained by other human beings. Some of those other human beings may not have had the time to catch up on the latest/greatest language feature or 'trick' and may miss subtleties of your implementation.<p>I get worried when I see someone take a mainstream language (C#, Java, Python) and try and twist its idioms into whatever their favorite language is (lisp, the ML family, Perl, etc). Or if someone wants to be on the bleeding edge and use the latest language syntax/library trick. This is a pain because<p>- Someone new to the codebase may not have as much familiarity with all these nuances of the language. For example, I've seen crazy things done with C++ templates. I don't think there was ever a justifiable reason for doing any of them.<p>- The esoteric, cutting edge features often have bugs and/or don't have great tool support. Fact of life is that the more some feature gets used, the more the bugs found and fixed. If you're on the bleeding edge, you're going to hit weird language/runtime bugs which you need not have inflicted on everyone.<p>- Debugging. Often, the only thing you have after a weird bug is a crash dump and caffeine. You want to give yourself all the chances you can of tracking down that issue. Esoteric language features rarely lead themselves to great crash dump debugging. I'm not suggesting writing C code but the closer the mapping from code you write to x86/64 code, the easier it is for you

I'm skeptical of these lists because people can work through things. For example, the stuff listed under "Inability to determine the order of program execution" is something that many people will get jammed on eary on as they try to take their brains (which is honed on the syntax of school level maths) into the programing world (where equals is an instruction rather than an assumptions). Another one is "Lisp is opaque to you". It's very sweet for MIT types to make these declarations from mount olympus, but lisp is something that can take time to acquire. If someone isn't a natural programmer but is happy to work at it to overcome hurdles then there's nothing wrong with that.<p>One of the examples of bad technique is:<p><pre><code> Homebrew "Business Rule Engines" </code></pre> Can anyone give examples of the sorts of things the author means by this? What sort of systems have people seen, and why is it necessarily a bad thing?

I love the insight that lacking critical thinking "originates in both lazy thinking and egocentric thinking". The latter is very true. I have never met a great programmer who thinks they are at the top of their game. Being aware of the trade offs in any solution requires a degree of humility.

Signs that you're a bad web host: "pageview limit exceeded"<p>If Google can't figure out a way to monetize popular content targeted at a professional technical audience, something's very wrong.<p>The best idea I've seen for such situations is to let people trying to view the page buy an instant traffic upgrade on the site's behalf; I'd chip in 100x the costs to serve my single hit if I knew it would restore visibility for me and some others.<p>The help link is also uncharacteristically inept for Google -- it doesn't lead to an explanation of pageview limits, and searching [pageview limit exceeded] in the help area turns up only user questions, no official article on the topic. The third hit is this unanswered gem, from a popular site <i>with AdSense</i> that keeps going down due to the limits:<p><a href="http://www.google.com/support/forum/p/sites/thread?tid=08f19dca3ab69764&#38;hl=en" rel="nofollow">http://www.google.com/support/forum/p/sites/thread?tid=08f19...</a>

This is a very good article, and hits lots of very good points.<p>However, it seems that there is a little bit of a self-diagnosis problem. For example, if you write "voodo code" (great description), unless there is some one to tell you, how do you know? And if you write voodo code, do you know what idempotent means? There is maybe a bit of the "Blub" effect here.<p>Perhaps between "Symptoms" and "Remedies" there needs to be "Diagnosis" or some hints at self-evaluation or tools for self-assessment.

This is absolutely amazing and comprehensive! I can't think of anything he really left out.<p>I've seen articles like this before, but they're usually super-parochial, and I've never seen one that offered 'remedies' (much less the hilarious 'alternative careers' in the last section).

Signs that you're a bad programmer: 1) You think you're an amazing programmer.

Just reading that made me a bad programmer. :/

Pageview limit exceeded<p>We are sorry, but this site has exceeded its page view limit at this time. Please try again later. For more information, see Google Sites help.

He's missing the third part, signs your a decent programmer, to differentiate the good from the great.

That was mostly high quality except for the wannabe "you might be a redneck" (shouldn't be a programmer) section at the end.<p>&#62; (Functional) Manually caching the results of a deterministic function on ... Haskell<p>You still have to explicitly memoize at times in Haskell.<p>&#62; refactor his old code with the goal of reducing its instruction count by 10:1 or more<p>What a loser! I go into my old code with a goal of 10000:1.<p>&#62; Recursive subroutines that concatenate/sum to a carry-along output variable<p>This can be justified.<p>&#62; Using strings/integers for values that have (or could be given) more appropriate wrapper types in a strongly-typed language<p>Not always worth it.<p>&#62; Unit Testing, which you use at design time.<p>No, I don't.<p>&#62; You don't use whitespace or indentation<p>If I'm not using whitespace, what am I supposed to indent with?

Seems to be a good source for creating interview questions.

It's down, but it sounds like a copy of <a href="http://badprogrammer.infogami.com/" rel="nofollow">http://badprogrammer.infogami.com/</a>

"Phase 5: "By letting a constraint solver figure out the mundane details, I can write programs by describing what I want, rather than how to give it to me""<p>This is one of the best arguments for why anyone should bother to learn Haskell (or likewise language)

1. (Haskell) Propagating the myth that Haskell would do some automagic caching of function results.<p>(Haskell simply does call-by-need: square (x+1) evaluates to (x+1)*(x+1), but there's still only one (x+1) that gets evaluated.)

Some praise for this article: Identifying a set of patterns for sub-quality programming practise is useful in order to set about correcting those things esp. if you're in a mentoring position. I think it would have been nice to have given these names (like design patterns perhaps) and fleshed out their definitions further.<p>Yes, the author is more arrogant than desirable in his delivery but don't let that blind you to the good stuff. Some of the teaching analogies, in particular, I thought were good.

High cohesion is bad in exactly which programming environment? Functional or procedural?<p>I've always understood high cohesion to be related to low coupling. Also, writing util classes before you need them (where low cohesion may be necessary) is a nothing more than a time sink. Do something when you need it, not before. You are not omniscient and will not be able to account for everything no matter how hard you try.

FTA: "Signs that you shouldn't be a programmer<p>1. Inability to determine the order of program execution<p>Symptoms<p>a = 5 b = 10 a = b<p>print a You look at the code above and aren't sure what number gets printed out at the end"<p>The answer is not always obvious. If the above code were in Java and print a was running in a different thread then it very well print 0, since a or b could be 0. JMM can really bite you if you don't understand within-thread as-if-serial semantics.

This is spot on:<p><pre><code> 5. Lisp is opaque to you</code></pre>

I'd been looking for a name for what the author terms "yo-yo" code. I've often wondered if others have to deal with such head scratchers too.

Great doc to make screeners with.

After reading it twice, there are many points that are good, but there also some points that are not so clear cut, or plain bad. Maybe I am a bad programmer, but I disagree with some points:<p># (OOP) Writing lots of "xxxxxManager" classes that contain all of the methods for manipulating the fields of objects that have little or no methods of their own<p>I guess they keyword 'lots' make this ok, but having plain objects (scruct like), passed around in the application, and having some managers is fine. eg. if you have an application that passes around contacts, you can have a ContactsManager, taking care of all the messy bussines (local peristence, remote persitence, deleting, etc., while contacts remain simple objects. ActiveRecord pattern goes the other way, where this logic is placed in the objects. Both are fine.<p># (Relational) Treating a relational database as an object store and performing all joins and relation enforcement in client code<p>--I guess all those programmers in the "NOSql" movements are idiots. (they are not, some of these people are really smart). Don't take this statement too seriously.<p># Re-inventing or laboring without basic mechanisms that are built-into the language, such as events-and-handlers or regular expressions<p>--I think regular expressions are evil, obscure, and performance is highly depended on the implementation. Practical example, checking if an email address is valid. While some people go all the way crazy with regular expression, All I do is check that there is an '@', or a '+', at least one '.', and minimum/maximum lengths. You don't regular expressions for that, as no matter how smart you think your expression is, there is a great chance somebody that edits it will fuck it up just by changing a character on it.<p># Re-inventing classes and functions that are built-into the framework (eg: timers, collections, sorting and searching algorithms) *<p>Done many times. If you are doing mobile, most of platform implementation (at least in J2ME) just suck ass. You can't rely on them. Heck, in my previous company we did even font rendering, thread worker queues, etc. as the scheduler was unreliable, etc.<p>#Recursive subroutines that concatenate/sum to a global variable or a carry-along output variable<p>--For some problems carry-along variable are needed.<p>eg, in a binary search tree, trying to print only the nodes in a certain level. printTreeLevel(tree, 2) -- will print only the nodes at level two<p>print(node, level)<p><pre><code> if level == 0 print node.data else printTreeLevel(node.left, level - 1) printTreeLevel(node.right, level - 1) </code></pre> # Writing business-logic functions with tragically compromising side-effects, such as updating a user interface or performing file I/O<p>--I guess it depends on the definition of what "business-logic" is. This guy thinks it more as the transactional/model part and not a controller. For some apps, the business logic is the main controller. Plus, "bussines logic" is more of a managerial speak anyways.<p>#Homebrew "Business Rule Engines"<p>-- Maybe I am not old enough, but I had to look it up what a "Business Rule Engine" is. Seems stuff from the Dot Com era/enterprise world.<p>#Code that tries to prevent an exploit from working by searching for the exploit's signature<p>--Haha. That's the whole Antivirus industry. I agree with him, and I don't have antivirus software, but it seems that those companies made millions by breaking this rule.

The author lists the following as a symptom of being "unable to reason about code":<p><i>"5. 'Bulldozer code' that gives the appearance of refactoring by breaking out chunks into subroutines, but that are impossible to reuse in another context (very high cohesion)"</i><p>I disagree with this. The purpose of breaking out code in to subroutines isn't only for code reuse. If you don't break out code in to subroutines, at some point your code is going to become unwieldy and difficult to read.<p>I try to stick to the rule of having each subroutine consist of no more than a page of code (so that each subroutine can be seen all at one time, without needing to scroll). Often that leads me to break up the subroutine in to many other subroutines. This improves readability greatly and makes it much easier to reason about the code. If any of the subroutines I break my code out in to happen to be reusable, that's just icing on the cake, not a necessity.

How to avoid (if you're a C programmer) writing utterly terrible code - always include these WARNINGS in your build step:<p>WARNINGS := -Wall -W -Wunused-parameter -Wmissing-declarations<p>WARNINGS += -Wstrict-prototypes -Wmissing-prototypes -Wsign-compare<p>WARNINGS += -Wconversion -Wshadow -Wcast-align -Wparentheses<p>WARNINGS += -Wsequence-point -Wdeclaration-after-statement -Wundef<p>WARNINGS += -Wpointer-arith -Wnested-externs -Wredundant-decls<p>WARNINGS += -Werror -Wdisabled-optimization -pedantic<p>CFLAGS += $(WARNINGS)<p>Note: -pedantic is pretty good if you really wanna learn how to write code that will work properly.<p>Also: Treating Warnings as Errors is a good thing. You'll learn a lot, and the most important thing will be: handle all warnings. Do not release code until it builds clean.

Oh, you can put it as simple as:<p>If you think you are good, you are not. If you think you have to improve, chances are you will become <i>better</i>.<p>(Life is baby steps; ask a baby...)