• Seeker (unregistered) in reply to KattMan
    KattMan:
    I have had arguments with one particular manager (yes the one with 20 years experience) about why making check boxes work like radio buttons was a bad idea.

    In some situations where non-coding managers want to mess up the UI or some other aspect of the design, I've had success saying, "this will cost a lot more than letting the radio buttons and check boxes work like normal" (which is true) or "I don't know how to do that" (which is sometimes true, depending on the desired feature).

    And then I stop talking. No argument.

  • ugh (unregistered)

    Someone should lock Atwood and Spolsky in a room and toss the key.

  • Kuba (unregistered) in reply to Something Like A Name
    Something Like A Name:
    When I sit in the popular CS computer labs, it's not uncommon to hear a group of people agree that "yes, pointers to functions are too hard, and who needs them anyways?" or other similar tirades.

    I guess you missed their point: I presume that they fuss over the pretty abominable C syntax. Remember: syntax by itself is a barrier to entry, and a completely useless one. By itself, syntax is worth next to nothing. Vide successful Lisp projects (Yahoo Stores nee ViaWeb, Orbitz) where syntax was molded to the application (with macros & read macros), not the other way around. I doubt that they fuss over the concept itself.

    In several languages (Arc, Lisp, Scheme, Perl, Python) references to functions (having functionality of C function pointers) are 100% painless. In C, I used to pull up my cheatsheet. And then you get C++ (and Pascal!) with implicit function pointers (virtual methods), only to confuse matters some more. That's where you have things that behave like function pointers, but are not written as such. Yay! Very useful, but does it inherently "make sense" ? No.

    Compare this Perl example

    $default_exit = sub { exit(0); };
$exit_fun = $default_exit;

    or this Arc example [more readable than Lisp]

    (= default_exit (fn () (exit 0)))
(= exit_fn default_exit)

    to this:

    void default_exit(void) { _Exit(0); }
void (*exit_fun)() = default_exit;
// nothing that the below would work too!
void (*exit_fun)() = &default_exit;

    Go C!, go go, er, better not.

    Cheers, Kuba

  • spoonchops (unregistered)

    I think you're right, I should stop reading this page and spend the time on something that's going to grow me instead of amuse me. Thanks Mr. guest speaker

  • Joseph Newton (unregistered)

    In that vein, I would offer the following suggestion:

    Lesley Anne Robertson Simple Program Design: A Step-By-Step Approach

    I feel very lucky, in that when I started my formal education in programming, this book was the text for the first six weeks of class. We didn't touch a compiler or code editor until we had spent time studying the underlying process of functional decomposition that Ms Robertson teaches.

    The book focuses on procedural programming, but the principles it teaches extend well into object-oriented approaches. There is a good reason to have private scope on OOP functions, and that is to allow methods to be broken down into comprehensible and easily-maintainable components, without exposing them outside of a class. a bit more functional decomposition within class definitions would bear great fruit in providing solid functionality to client code.

    The other biggest tips that I would give to the new programmer are:

    1. Use natural language and real words in your identifiers. code will be much more comprehensible and maintainable if your variable state clearly what they represent, and your function names tell you clearly what purpose the code is intended to accomplish. It's been many years now since programming languages have imposed length restictions on identifiers, so there is really little need to garble code with cryptic abbreviations.

    2. Use line-breaks and whitespace well. Good programming languages tend to be whitespace-insensitive. The line for (i = 0; i < limit; i++) { will compile just as readily as for(i=0;i<limit;i++){ and IMHO is much easier to read and, if necessary, debug. Likewise, using an end-quote, concatenation operator, new-line, and open-quote may take a few extra keystrokes, but if it means the difference between a statement that scrolls off the right of a screen and one that can be seen an comprehended in in toto, it will save a lot of grief in the long run.

    3. Take a break. Sitting in front of a computer screen at all times can really narrow ones perspective, and a broad perspective is critical to understanding the real-world context in which your code will be used.

  • foo (unregistered)

    i'm laughing at you.

  • Marthinus (unregistered)

    I rather like bad code, as an independent contractor being called in as the fixer of bad code is very lucrative indeed.

    I like the bad Indian code if only to make me look better when it comes to my manager's perspective.

  • noobman (unregistered)

    to all those that say "i never write bad code":

    look for an other job!

    we do not need people that can not reflect and accept they sometimes do make mistakes

  • (cs)

    We all write bad code, just to different degrees. For a moment, let's assume that writing code is like riding a bike. You could say that 'everyone falls off their bike'. Therefore, even Lance Armstrong falls of his bike.

    This analogy implies that everyone screws up at an equivalent rate, and is also equivalently (un)skilled at their job. This implication couldn't be more flawed. While it is true that everyone makes mistakes, we don't all screw up code like people in WTF stories do (thankfully).

    I know I'm a good coder, but I also know that some people are way more talented at coding than I am. Just as I know that Lance doesn't fall off his bike nearly as often as I do (and I hardly ever fall off), and when he's not falling off the bike, he rides much harder, faster, and longer than I can.

  • (cs) in reply to Kuba
    Kuba:
    void default_exit(void) { _Exit(0); }
void (*exit_fun)() = default_exit;
// noting that the below would work too!
void (*exit_fun)() = &default_exit;

    I agree that C/C++'s syntax can be a pain to remember (I can never remember how to write template classes for example, even though I use Standard Template Library stuff all over the place). But to be fair, in C it would be much better to write:

    void default_exit(void) { _Exit(0); }

typedef void (*exit_function_ptr) (void);

exit_function_ptr exit_fun=default_exit;
exit_fun();

    But then C is still displaying it's irregularities now, since the standard typedef syntax is:

    typedef [old type] [new type];

    Whereas for function pointers the thing seems all mixed together. As for this:

    // nothing that the below would work too!
void (*exit_fun)() = &default_exit;

    Ouch, I never realised that was possible o_O

  • Rabid Wolverine (unregistered)

    The really scary code, the ultimate WTF, is going to be when it knocks at your door and ask:

    "Is your name Sarah O'Conner?"

    Yea laugh, it could and probably will happen...

  • chris (unregistered) in reply to Rabid Wolverine
    Rabid Wolverine:
    The really scary code, the ultimate WTF, is going to be when it knocks at your door and ask:

    "Is your name Sarah O'Conner?"

    Yea laugh, it could and probably will happen...

    Meh, by the time it happens you'll probably be able to reply

    "No, my name is Sarah O';DELETE FROM targets;"

    And go get a latte.

  • justin (unregistered) in reply to packrat
    packrat:
    I'm a Java Technical Lead. I have the following people working for me. Try to match the qualifications with the title.

    "Coding Machine" takes vague design, sucessfully implements it. Firm believer in the "junior developer 2 am page fix in 4 hours" rule.

    "Cowboy Tony" takes a design, reads it, decides he knows a better way, then codes it however he feels. Likes to rewrite existing code just because he can.

    "Silent Bob" takes detailed design, implements it. When he discovers issues, he suggests a good solution. Spends free time programmer testing or studying java books.

    "Mary" takes very detailed design and impliments it to the letter. Assignments must build upon one another or code example provided. Spends free time studying.

    qualifications person 1 - CS degree and 3 years experience in VB. No Java work experience. Returning to work after 7 year absence. ( Okay this is the easy one)

    person 2 - 3 years college. Ex mainframe programmer. 8 years professional experience 6 years of java.

    person 3 - non cs degree. Sun Certified Java Developer. 4 years current position. 5 years elsewhere. 4 years Java

    person 4 - cs degree. Sun Certified Java Developer. 20 years programming experience. 1st Java position. Less than 2 months java.

    I'm guessing: Person 1: cowboy tony Person 2: Mary Person 3: coding machine Person 4: silent bob

    Interestingly I myself have shown traits of all of them. I find it facinating that most of the comments so far have devolved into "those who can vs. those who can't" again. That does seem to be contrary to the point of the article, which nobody seems to have disagreed with so far (I haven't read all the comments.)

    The point, as I took it, is that we need to be more helpful to those who can't. We all right bad code (I wrote some last week), and we all right good code. Even "those who can't" occasionally put out a gem. One of the first concepts I learned from Agile is "criticize the code, not the coder". Honestly I remember that one the best because it was probably the hardest for me. It's easier (for me at least) to mock then to be helpful. We also need to make sure criticism is constructive. Mocking, while fun, is not criticism and does nothing to help those mired in supporting bad code.

    captcha: why would I post that?

  • stochastio (unregistered) in reply to evanm

    I couldn't put it better myself, evanm.

    Too often, professional and amators alike are thrown into the same pool of talent, only expected to deliver. Surely, there's a much better way to organized such a varied workforce for the benefit of everyone.

    I think a lot of it has to do with a generalized plug n' play hiring mentality. As long as companies keep hiring "techies" to take care of whatever's under the hood, the professions of software development will only live up to blind managerial expectancies and mediocrity will be rampant.

    Many employers don't want to admit themselves that they're not only in the business of producing value for their customers, but also of investing in the professional growth of each of their employees. I'm sorry to say that I have yet to find a company which sufficiently cares for what its employees, professionals, care about to genuinely commit themselves to building and maintaining a working environment that's conductive to quality output. More often than not, this kind of growth has to be realized through individual effort, which can become tiresome with time... and only marginally rewarded.

    Following your comment, I could also go ahead and bring up that there's a larger divide between, say, mechanical engineers and mechanics than there is between the software professions, where good "algorithmicians" are also expected to be great coders, and good coders architects, and so on... Software developers, it seems, are expected to be all around great at everything or be tagged with the mediocrity label. So, before pointing at management, maybe we should all start by having a look at ourselves and acknowledge first that each of us has something different to bring to a team.

  • retardonerd (unregistered)

    The real WTF

    Coding Horror = dork who does op ed pieces that usually turn out to be product reviews. This site even though it says its about .net code you will never see a single code snippet to laugh at.

    Worse Than Failure = dork who doesn't know what a good thing is until its gone. Like the name. Hey at least you have code I can laugh at.

    My pong clock is more gay than yours.

  • Andrew (unregistered)

    I stopped writing bad code the moment I discovered the "Generate Random Code" button that comes with all IDEs today.

  • (cs) in reply to MyKey_
    MyKey_:
    PS: Could any one PLEASE tell those "I'm a perfect developer"-kids not to post unless they have something to say.
    They are just playing back the sentences made by "expert" people illustrated in this site.
  • RickMan (unregistered) in reply to KattMan

    As documented by the authors blog and my own personal experience in interviewing CS graduates with Masters & PHds, there are some that can't even answer the most basic programming questions, let alone code. I have been developing for over 26 years and looking back at how I wrote code before college, I can say that I wrote alot of WTF code for those old apple II, LISA and TRS 80 machines, but it was a learning experience that led to a great career, where I can take WTF code and refactor or rewrite the code into better code, or even correct my own first pass at solving a problem.

    At this stage of my career I have to write text as much as I write code, and I have found that when creating documents, the first attempt may be just trying to get my ideas out and that the rest is just a refinement, of the original idea.

    Over the years I have done created many models and created a lot of paper describing the solution, but I also found that sometimes, spending all that time preparing takes more time and leads away from the simplest solution and burns alot of the customer's time. It is just as effective to create some code to solve all the problems and then refactor the code to elegant streamlined code.

    The trick is to for the developer to be able to look at the code and realize that the code they write should be looked at and streamlined, broken out, or dropped from their solution.

    In the eighties I also found what I still believe today, is that Writing Code is as much ART as Science. In the eighties when looking for potential programmers I found that people with music degrees made excellent programmers, they had the math skills, and they knew how to correctly string things together without wasted movements, all they had to be taught was the language to use.

    So a degree is not a very good indicator, I think the tests like the old Wolf test and simple questions like the authors Fizz Buzz test is a start.

  • packrat (unregistered) in reply to trianglman

    Answers

    1). Mary 2). Machine 3). Cowboy 4). Bob

    And Bob is turning into another coding machine.

  • Jeff (unregistered) in reply to Matt

    Seminal - Without Question!

  • Tony the Terrific (unregistered) in reply to jedifreeman
    jedifreeman:
    Long time lurker, first time commenter, I just have to say one thing about all the people claiming they never ever write code that is "bad" in some way or another.

    Bullsh*t.

    No one is perfect, do not claim you always write good code. Sure, we all attempt and strive towards writing good code, but everyone ends up writing something they look back on and go "what was I thinking?"

    Except for myself being perfect, I'd say you're spot on.

  • Y2036 (unregistered) in reply to Andrew
    Andrew:
    I stopped writing bad code the moment I discovered the "Generate Random Code" button that comes with all IDEs today.

    John Titor, is that you?

  • (cs) in reply to justin
    justin:
    We all right bad code (I wrote some last week), and we all right good code.
    Looks like we all right bad sentences too :)
  • (cs)
    If anything, there should be a website where you could marvel at the truly unique code -- the stuff that doesn't suck.
    You mean like byteMyCode or Experts Exchange? I'm sure there are others.
  • sergiogiogio (unregistered)

    I think that the problem is that our industry is still very young and immature (what, 50 years only?). We clearly don't have the right tools, nor the right theories, nor the right training, at least to achieve the goals we set for ourselves.

    Take cars. I've always been amazed at how dependable they are. They adapt to any driving style, they take shocks and holes in the road, they will continue to move even in hostile environments, etc. But this did not happen overnight, it literally took 100s of years! I would say the same for houses, roads, etc.

    CS and IT on the other hand are completely new fields and they cannot really build on experience inherited from the past (not even mathematics). Yet, we're already able to make some really amazing stuff. Today our programs are usually very fragile and do not adapt to hostile inputs, unexpected conditions, etc. They have countless bugs, misfeatures, they're not user friendly, they don't report errors... I guess we must all be very humble and accept that this is only the beginning of the industry. We need more time to understand how to make things better.

  • Rabid Wolverine (unregistered) in reply to chris

    I would probably reply:

    1100110111010111000111101011100000111100111011111110101

    As I activated a massive EMP...

  • anonymous coward (unregistered) in reply to Ryan H

    And I have seen many with formal CS education whom I would like to revoke the authorization to develop from.

  • Mattle (unregistered) in reply to Zak

    Hi Zak,

    Strange question, but I've often wondered why people include their captcha in their comment. Please enlighten this poor soul :)

  • Ranjiv Sinjah (unregistered) in reply to John

    I see a lot of xenphobia on this forum... there is a lot of reason because overseas workers are cheapers... Money exchange is one of them. I worked with excellent non-USA programmers and also I maintaned horrible code produced in USA. Guess what: there is good and bad programmers both, inside and outside USA!!

  • (nodebb)

    nice

    Addendum 2022-11-02 23:27: The promotion of every initiative, in my opinion, depends primarily on content marketing. Therefore, it's crucial to locate qualified authors that can give you high-quality essays. As for me, I selected a literature review services organization where I could get excellent papers on academic subjects for my site. It is highly practical, and I have complete faith in experienced editors and specialists who are certified.

  • eric bloedow (unregistered)

    "world's ugliest dog" reminds me of VERY old cartoon called "Mighty Man and Yukk". Yukk was a anthro dor who usually wore a hood shaped like a small doghouse on his head. he was so ugly, his face would literally shatter mirrors, make cameras explode, make MOUNTAINS COLLAPSE...

Leave a comment on “Guest Article: Our Dirty Little Secret”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article