What is Digg?204 Comments
- EXTER, on 11/24/2007, -1/+102Signs You're a Crappy Programmer (and don't know it)
You know those crappy programmers who don’t know they are crappy? You know, they think they're pretty good, they spout off the same catch phrase rhetoric they've heard some guru say and they know lots of rules about the "correct" way to do things? Yet their own work seems seriously lacking given all the expertise they supposedly have? You don’t know any programmers like that? Come one, you know, the guys who are big on dogma but short on understanding. No, doesn’t sound familiar?
Then here are some signs you're a crappy programmer and don't know it:
* Java is all you'll ever need.
You don't see the need for other languages, why can't everything be in Java? It doesn't bother you at all to see Python or Ruby code that accomplishes in 10 lines what takes several pages in Java. Besides, you're convinced new language features in the next release will fix all that anyway.(BTW, this can be almost any language, but right now the Java community seems most afflicted with this thinking)
* "Enterprisey" isn't a punchline to you.
This is serious stuff dammit. "Enterprise" is not just a word, it's a philosophy, a way of life, a path to enlightenment. Anything that can be written, deployed or upgraded with minimal fuss is dismissed as a toy that won't "scale" for future needs. Meanwhile most of the real work in your office is getting done by people sending around Excel spreadsheets as they wait for your grand enterprise visions to be built.
* You are adamantly opposed to function/methods over 20 lines of code.
(or 30 or 10 or whatever number of lines) Sorry, sometimes a really long function is just what's needed for the problem at hand. Usually shorter functions are easier to understand, but sometimes things are most simply expressed in one long function. Code should not be made more complex to meet some arbitrary standard.
* "OMG! PATTERNS!"
Developers who actively seek to apply patterns to every coding problem are adding unnecessary complexity. Far from being something you look to add to your code, you should feel bad every time you are forced to code up another design pattern, it means you are doing busy work that makes things more complex and is of dubious benefit. But hey, your code has design patterns, and no one can take that from you.
* CPU cycles are a precious commodity and your programming style and language reflects that belief.
There are plenty of problem domains where you have to worry a lot about CPU cycles (modeling/simulation, signal processing, OS kernels, etc), but you don't work in them. Like nearly every software developer, your biggest performance problems are all database and I/O related. The only effect of optimizing your code for CPU is to shave 2 milliseconds off the time to get to the next multi-second database query. Meanwhile your development has slowed to a crawl, you can't keep up with the rapidly evolving requirements and there are serious quality issues. But at least you’ll be saving lots of CPU cycles... eventually.
* You think no function/method should have multiple return points.
I've hear this from time to time, and usually the reason given is because the code is easier analyze. According to whom? I find simple code easy to analyze, and it often simplifies the code to have multiple returns.
* Your users are stupid. Really stupid.
You can't believe how stupid they are, they constantly forget how to do simplest things and often make dumb mistakes with your applications. You never consider maybe it's your application that’s stupid because you're incapable of writing decent software.
* You take great pride in the high volume of code you write.
Being productive is good, unfortunately producing lots of lines of code isn't quite the same as being productive. Users never remark "Wow, this software may be buggy and hard to use, but at least there is a lot of code underneath." Far from being productive, spewing out tons of crap code slows down other devs and creates a huge maintenance burden for the future.
* Copy and paste is great, it helps you write decoupled code!
You defend your use of copy and paste coding with odd arguments about decoupling and removing dependencies, while ignoring the maintenance drag and bugs code duplication causes. This is called "rationalizing your actions".
* You think error handling means catching every exception, logging it and continuing on.
That’s not error handling, that’s error ignoring and is the semantically equivalent to “on error next” in VB. Just because it got logged away somewhere doesn’t mean you’ve handled anything. Error handling is hard. If you don’t know exactly what to do in the face of a particular error, then let the exception bubble up to a higher level exception handler.
* You model all your code in UML before you write it.
Enthusiastic UML modeling is typically done by those who aren’t strong coders, but consider themselves software architects anyway. Modeling tools appeal most to those who think coding can be done in conference room by manipulating little charts. The charts aren’t the design, and will never be the design, that’s what the code is for.
* Your code wipes out important data.
You wrote some code that’s supposed to overwrite application files with new files, but it goes haywire and deletes a bunch of the user's important data files.
That last one, I did that. Just last year. Honest mistake and it never showed up in QE’s testing. Sometimes I’m crappy. Sometimes we all are. I have been guilty of most of the items on the list and still struggle with a few (especially premature optimization). So try not to take anything on the list too personally, but feel free to flame me anyway if it makes you feel better. - morninglorii, on 11/24/2007, -2/+8313. GOTO 12
- inactive, on 11/24/2007, -2/+62Is she a crappy programmer?
- cconger, on 11/24/2007, -3/+6013. You designed this web server...
- duke, on 11/24/2007, -5/+5313. You link to sites that crash.
- tuxidomasx, on 11/24/2007, -2/+49not all methods are refactorable. i think the author is saying that you shouldnt needlessly break up methods JUST because they exceed some arbitrary length
- inactive, on 11/24/2007, -3/+44Digg me up if you banned this guy.
- inactive, on 11/24/2007, -2/+40Rather than spewing off this random *****, why don't you give us some solid reasons as to why you may think this to be true.
- physicx, on 11/24/2007, -3/+32I agree with 11, the one I don't is "You are adamantly opposed to function/methods over 20 lines of code." I am not opposed to it but I always see newbie programmers be William Shakespeare's, which means they write books instead of efficient code.
- tech42er, on 11/24/2007, -3/+28Comment abuse, but:
Signs You're a Crappy Programmer (and don't know it)
You know those crappy programmers who don’t know they are crappy? You know, they think they're pretty good, they spout off the same catch phrase rhetoric they've heard some guru say and they know lots of rules about the "correct" way to do things? Yet their own work seems seriously lacking given all the expertise they supposedly have? You don’t know any programmers like that? Come one, you know, the guys who are big on dogma but short on understanding. No, doesn’t sound familiar?
Then here are some signs you're a crappy programmer and don't know it:
* Java is all you'll ever need.
You don't see the need for other languages, why can't everything be in Java? It doesn't bother you at all to see Python or Ruby code that accomplishes in 10 lines what takes several pages in Java. Besides, you're convinced new language features in the next release will fix all that anyway.(BTW, this can be almost any language, but right now the Java community seems most afflicted with this thinking)
* "Enterprisey" isn't a punchline to you.
This is serious stuff dammit. "Enterprise" is not just a word, it's a philosophy, a way of life, a path to enlightenment. Anything that can be written, deployed or upgraded with minimal fuss is dismissed as a toy that won't "scale" for future needs. Meanwhile most of the real work in your office is getting done by people sending around Excel spreadsheets as they wait for your grand enterprise visions to be built.
* You are adamantly opposed to function/methods over 20 lines of code.
(or 30 or 10 or whatever number of lines) Sorry, sometimes a really long function is just what's needed for the problem at hand. Usually shorter functions are easier to understand, but sometimes things are most simply expressed in one long function. Code should not be made more complex to meet some arbitrary standard.
* "OMG! PATTERNS!"
Developers who actively seek to apply patterns to every coding problem are adding unnecessary complexity. Far from being something you look to add to your code, you should feel bad every time you are forced to code up another design pattern, it means you are doing busy work that makes things more complex and is of dubious benefit. But hey, your code has design patterns, and no one can take that from you.
* CPU cycles are a precious commodity and your programming style and language reflects that belief.
There are plenty of problem domains where you have to worry a lot about CPU cycles (modeling/simulation, signal processing, OS kernels, etc), but you don't work in them. Like nearly every software developer, your biggest performance problems are all database and I/O related. The only effect of optimizing your code for CPU is to shave 2 milliseconds off the time to get to the next multi-second database query. Meanwhile your development has slowed to a crawl, you can't keep up with the rapidly evolving requirements and there are serious quality issues. But at least you’ll be saving lots of CPU cycles... eventually.
* You think no function/method should have multiple return points.
I've hear this from time to time, and usually the reason given is because the code is easier analyze. According to whom? I find simple code easy to analyze, and it often simplifies the code to have multiple returns.
* Your users are stupid. Really stupid.
You can't believe how stupid they are, they constantly forget how to do simplest things and often make dumb mistakes with your applications. You never consider maybe it's your application that’s stupid because you're incapable of writing decent software.
* You take great pride in the high volume of code you write.
Being productive is good, unfortunately producing lots of lines of code isn't quite the same as being productive. Users never remark "Wow, this software may be buggy and hard to use, but at least there is a lot of code underneath." Far from being productive, spewing out tons of crap code slows down other devs and creates a huge maintenance burden for the future.
* Copy and paste is great, it helps you write decoupled code!
You defend your use of copy and paste coding with odd arguments about decoupling and removing dependencies, while ignoring the maintenance drag and bugs code duplication causes. This is called "rationalizing your actions".
* You think error handling means catching every exception, logging it and continuing on.
That’s not error handling, that’s error ignoring and is the semantically equivalent to “on error next” in VB. Just because it got logged away somewhere doesn’t mean you’ve handled anything. Error handling is hard. If you don’t know exactly what to do in the face of a particular error, then let the exception bubble up to a higher level exception handler.
* You model all your code in UML before you write it.
Enthusiastic UML modeling is typically done by those who aren’t strong coders, but consider themselves software architects anyway. Modeling tools appeal most to those who think coding can be done in conference room by manipulating little charts. The charts aren’t the design, and will never be the design, that’s what the code is for.
* Your code wipes out important data.
You wrote some code that’s supposed to overwrite application files with new files, but it goes haywire and deletes a bunch of the user's important data files.
That last one, I did that. Just last year. Honest mistake and it never showed up in QE’s testing. Sometimes I’m crappy. Sometimes we all are. I have been guilty of most of the items on the list and still struggle with a few (especially premature optimization). So try not to take anything on the list too personally, but feel free to flame me anyway if it makes you feel better. - n3rrd, on 11/24/2007, -1/+26But that would require real experience with any or all of the languages mentioned above, and their superior alternatives!
- oneoverzero, on 11/24/2007, -1/+25Perl is still one of the best (well, easiest at least) languages when it comes to modification of strings. Ruby isn't old by any stretch of the imagination. PHP is still great for web development, and python is still a good multipurpose language. I'm guessing that you tried to learn one of these, decided it was too hard and then gave up.
- w3torg, on 11/24/2007, -3/+26I laughed. Wife didn't get it.
- d03boy, on 11/24/2007, -8/+29Another crappy opinion list without any evidence to base any claims... Could have summed it all up with "You think the only way to do something is your way"
- xpankrat, on 11/24/2007, -1/+2113) You are confident that only your opinion on 1-12 is a correct one
- Lososaurus, on 11/24/2007, -0/+20http://xkcd.com/292/
- MikeonTV, on 11/24/2007, -2/+22Is one of the signs that your server goes down in a sinch?
Mirror - http://64.233.167.104/search?q=cache:nlhVOsFdG3AJ: ... - Error601, on 11/24/2007, -2/+21Yea, breaking up someone elses monster function into reusable pieces is something I get stuck with on a regular basis. The causes is linear verse structural thinking.
- ztexas, on 11/24/2007, -1/+20We all have limitations and deficits as programmers. IMHO one of the worst characteristics of a bad programmer isn't a particular bad practice but rather the absence of humility, thinking "I know it all - no need to keep up on best practices or learn a new language". Like most who have been in this business for years, I've had to wade through (and fix/refactor) some horrific code, but my personal pet peeve is the following: engineers who join a startup, throw together an app for demos that is claimed to be "ready for prime time", then exit the company at 12 months - just as the first quarter of their options have vested. Repeat yearly. Often these are very bright programmers/engineers, but often they don't truly learn from their mistakes, since they don't stick around for full product deployment, when issues such as scalability and maintainability become evident.
- fiendskull9, on 11/24/2007, -0/+18Ruby hasn't even really been picked up by many programmers as a serious language until 2005. and Python is still under an active release and use cycle (Look at nearly every recently released desktop application for linux!). The only language i could really agree on is Perl. Although it is still widely used for DB and server administration, it seems useless on the desktop anymore
- 2ktj, on 11/24/2007, -1/+17I can vouch for at least one that wasn't a script. I clicked Thumbs Down and enjoyed it.
- elnerdo, on 11/24/2007, -0/+15I'm 99.999% sure that it's not a script that keeps digging you down.
- artanis, on 11/25/2007, -0/+15A 100 line function that does a single task is better than 5 20 lines functions that call one another in a chain. Smaller is not always better when you're just splitting something for no other reason that to keep it small.
- kaykfrink, on 11/24/2007, -4/+18"Enterprisey" isn't a punchline to you.
I almost creamed myself here. I've spent almost a year working on a handed down project that was already half coded to be "enterprisey." The project itself is just a lot of databases accesses and calculations. It could probably be coded in a couple of months using PHP. Instead it had been in development for over 18 months with all this J2EE crap by the time I got the project. Not knowing anything about J2EE, I spent the next four months just learning about J2EE, the next two months trying to continue the enterprisey code, and then the next month trying to convince my higher ups that all the J2EE code was overkill and making the project nearly impossible to work on.
Fortunately, myself and a couple of fellow programmers where able to convince them that the project could be written much quicker using simple JSPs. Two months later I had the whole thing recoded and working beautifully. - nwoolls, on 11/24/2007, -8/+22"You are adamantly opposed to function/methods over 20 lines of code." Refactoring methods to make them smaller and reusable is NOT a sign you are a crappy programmer. Actually disagreeing with this, however, IMHO is.
- inactive, on 11/24/2007, -12/+26If this article isn't tounge-n-cheek, and I expect it is, I think Damien Katz might be one of those horrible programmers given his opposition to many of those practices. One or two of things he listed are signs of bad programming but other things he lists as bad are actually good qualities that are obvious to anyone who has done professional programming for a few years.
- derekivey, on 11/24/2007, -5/+18Mirrors:
http://damienkatz.net.nyud.net:8080/2006/05/signs_ ...
http://damienkatz.net.nyud.net:8090/2006/05/signs_ ... - nfollmer, on 11/24/2007, -0/+13How 'bout it. I hear it all the time. Someone is too lazy to learn a new language, so they think it sucks. Make yourself valuable, learn more than 1 language. Java and C++ aren't the only tools available to you.
- andycr512, on 11/24/2007, -1/+13Whenever I see that I think to myself "Man, I wish I had someone/thing that would hurt me every time I knowingly did something wrong in my code."
- RyanPT, on 11/24/2007, -1/+13You're hardly endearing yourself to everyone, mate.
- mayonaise15, on 11/24/2007, -0/+11No, that's just a sign that you are a crappy sysadmin.
- GMorgan, on 11/24/2007, -1/+11There are actually cases where that is true but it's rare. 99% of time the principle is right, the cases where it is not are obvious.
- GMorgan, on 11/24/2007, -1/+11Real Men don't make backups. They upload it via ftp and let the world mirror it
- crzdmn, on 11/24/2007, -0/+10Lol, no they don't vanish they infect projects like the ***** flu
- Fedaykin311, on 11/24/2007, -1/+10A developer's first priority should be the correctness of their code. All other qualities are second, and their nearness to first is dependent on the problem to be solved. For performance critical apps, performance is a very close second. For grandma apps, ease of use is a very close second, etc.
Worrying about performance beyond gross performance problems (like using unbuffered I./O or an unnecessarily complex architecture) is generally a mistake (again, except in cases when ultra high performance is a critical quality of your product). Trying to squeeze that extra few percent out of your code is a waste of time and money that is best spent else ware (like in testing). Add to this that most modern languages have compilers that do a far better job optimizing your code (stripping out unnecessary variables, optimizing loops, etc) and there really is no reason to try to do that by hand. - andycr512, on 11/24/2007, -0/+9That was just an example. The main point is that arbitrary standards that do not apply well to all situations but you "must" conform to anyway are a bad idea.
- chris9902, on 11/24/2007, -3/+12NASA, Google and Youtube all use Python so suck a dick.
- rolosworld, on 11/24/2007, -7/+15"Usually shorter functions are easier to understand, but sometimes things are most simply expressed in one long function."
-Damien Katz
LMAO - counterplex, on 11/24/2007, -0/+8Typically refactoring is programmer talk for optimizing - as in "Hey let me go refactor the piece of crap implementation of this functionality I wrote earlier due to time constraints"
- solinent, on 11/24/2007, -0/+8He'll get banned. We don't have that power.
- yndy, on 11/24/2007, -0/+713) You rebel against the Coding Standards of the shop you work in, because you don't understand why they were implemented.
Function length, multiple returns, modeling, documentation - those are things that are imposed for code maintainability... because 3 years after you leave, we don't want to have to spend unnecessary hours reverse engineering your crappy unstructured, uncommented code so we can make one small change to it.
James Dean wasn't a coder - you aren't a rebel. You're just a young hacker with potential who has a way to go before he gets WHY the Senior Programmer is so adamant about the shop standards. - opencoder, on 11/25/2007, -0/+7@incongruity: Why troll eplawless. He is just stating that UML is a usefull tool. Shouldn't we as programmers look for tools that make our lives more efficient. I don't really use UML tools, but I do draw out diagrams on paper of what could be considered UML. I think having a good plan to start off of gives you a good first step and a better direction that not planning things out.
- Firehed, on 11/24/2007, -0/+7You failed to understand the point here. More specifically, how crappy coders will waste time trying to shave off a tenth of a millisecond's worth of execution time off a function when that function then leads up to some sort of hideously inefficient database query that drags the whole thing down to a crawl no matter how much CPU power you have.
So yeah, avoid unnecessary recursion and simplify things where you can. But don't spend a ton of time obsessing over those kinds of things when you're still manipulating the results of a "SELECT *" query. - HaloZero, on 11/24/2007, -0/+7I think his point is that you shouldn't worry about small improvements in CPU cycles that will take a long time to code because its inefficient.
- trickyt, on 11/24/2007, -0/+6Yes because when you have a large switch statement on say, tokens returned from a tokenizer, you should put half of the cases into one method and the other half in a new method, to avoid going over 20 lines. Lines of code are arbitrary. Factoring out a method implies common functionality that is abstract, they have things called MACROS to reduce lines of code.
- naonao, on 11/25/2007, -0/+6Since when was PHP outdated? Last I heard every forum on the internet uses PHP...
- stripes, on 11/25/2007, -1/+7His main thrust for most of the items isn't that X, Y, or Z is normally bad but that it is "crazy" to insist that X, Y and Z are ALWAYS bad. So for example he says insisting that short functions are ALWAYS better then long ones is "crazy". Saying "5 10 line functions are almost always more readable then one 50 line function" is OK.
Or at least it looks like that is his main thrust, and I'll agree with "inflexibly applying 'good code style' rules tends to be worse then generally following the rules, but sometimes breaking them".
Sort of like the #1 rule of photographic composition "ignore any or all of the following rules if it makes the picture better (but if you don't know why breaking the rules is the right thing to do this time you may well be wrong)".
So "avoid design patterns" is a crock (they are frequently useful). "Shoehorning all of your code to follow at least one design pattern even when none apply" is good advice (sometimes no design pattern applies).
Now maybe I'm giving too much benefit of the doubt, and he is a loon, but I don't think so. Almost all his points focus on "always", and his clarifications in the comments I read reiterate that, and add an "always" to a section he missed. - bdbr, on 11/24/2007, -0/+6I would love to read the part about how CPU cycles aren't important, but the server is overloaded...!
- vdog, on 11/24/2007, -0/+6It cuts both ways. If your program crashes because a user enters text into a number field, it's both their fault for not entering the right data, and yours for not gracefully handling bad input.
The onus is on you, however, to fix it; you can always write smart code, they can't always write smart users. - jsebrech, on 11/24/2007, -4/+10The devil is in the details. It's possible to provide arguments in favor of almost all of the claims the author dismisses:
- Java is all you'll ever need:
Dictating a common programming platform (and language) can be useful from an administrative point of view because it allows greater redeployment of resources and increases maintainability. I guess you need the joyful experience of receiving code in a language you have no prior experience with and needing to produce a result the same day to really get this (special irony: in my case it was python code, which is supposed to be a "good" language). As far as that single platform being java: why not?
- "Enterprisey"
Yes, excel is good for rapid prototyping, but when it's all you use, IT administration and maintenance becomes a nightmare. Things like auditing, correlation of updates, bugfixes and feature developments, data security (backups, validation, ...), and so on all become major issues. "Enterprisey" is only a bad word if you apply it to every single need in the company. If one person needs a solution, make an excel sheet. If a hundred people need it, write a java program accessing an oracle database.
- 20 lines of code per function:
Small functions are more readable to me, always have been. I don't mind longer functions, I do mind longer functions if the function could have been more readable split up into smaller functions (speaking from experience, this is often the case).
- Patterns:
It's good to know patterns so you don't reinvent the wheel. Most problems don't need perfect solutions, they need cheap solutions. Patterns are cheap, because someone else already solved the problem for you and you just need to produce the lines of code. From a documentation standpoint it also helps you if your architecture is described as a set of patterns. And documentation becomes very important if your project becomes large enough that it's almost guaranteed that the next guy working on a specific piece of code won't be the guy that wrote it.
- CPU cycles are precious:
Not thinking about optimization at all is not a good idea. Sometimes the cpu does become the bottleneck. Although generally I agree that performance is determined by application architecture, not by inner loops.
- Functions should never have multiple return points:
I just think functions are more readable with a single return, most of the time. I've seen enough functions whose readability decreased because the programmer was too lazy to use a single return.
- Users are stupid
They are, and lazy as hell also. Fact: users almost never read dialogs, even ones they've never seen before. This is normal. You should expect users to only pay minimal attention to your application, because while for you it is your lifeblood, for them it is a tool that serves the actual purpose that their mind is engaged in. The error is not in thinking users are stupid, since they are, it's in thinking that it's not a job of your program to deal with that fact.
- Error handling means "log and continue".
Sometimes it does. For example, a syntax check should log all errors, not just the first one.
- You model all your code in UML before writing it.
I can see this making sense in a governmental project with absolute requirements regarding security and validation of behavior, where you need to have the behavior proscribed in detail before it is implemented. Although I have to admit that I think UML is not a good design tool, only a good documentation tool (I've only ever used it for documentation of a design myself). -
Show 51 - 100 of 205 discussions
© Digg Inc. 2009
— Content created and posted by Digg users is