Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Programming Education Software Hardware Technology

Ask Slashdot: What Are Some Lies Programmers Tell Themselves? 548

snydeq writes: "Confidence in our power over machines also makes us guilty of hoping to bend reality to our code," writes Peter Wayner, in a discussion of nine lies programmers tell themselves about their code. "Of course, many problems stem from assumptions we programmers make that simply aren't correct. They're usually sort of true some of the time, but that's not the same as being true all of the time. As Mark Twain supposedly said, 'It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so.'" The nine lies Wayner mentions in his discussion include: "Questions have one answer," "Null is acceptable," "Human relationships can be codified," "'Unicode' stands for universal communication," "Numbers are accurate," "Human language is consistent," "Time is consistent," "Files are consistent," and "We're in control." Can you think of any other lies programmers tell themselves?
This discussion has been archived. No new comments can be posted.

Ask Slashdot: What Are Some Lies Programmers Tell Themselves?

Comments Filter:
  • Lies? (Score:2, Funny)

    by msauve ( 701917 )
    That they never GOTO work.
    • by Anonymous Coward

      "Good programming discussion is found at Slashdot"

      • by Boronx ( 228853 )

        Who believes that?

      • by Anonymous Coward on Wednesday March 29, 2017 @02:50AM (#54133129)

        The main one: 'I'll fix that later'

        • by AntiSol ( 1329733 ) on Wednesday March 29, 2017 @05:12AM (#54133385)

          This is what I was going to say. You see it ALL THE TIME.
          Your boss is NOT going to let you go back and clean stuff up later unless there's an imminent business need to do so. Do it right the first time. Don't commit sloppy code.

          The only time it's ever acceptable to tell yourself this is on a personal project, and only if you have the discipline to make it be true.

        • by Hognoxious ( 631665 ) on Wednesday March 29, 2017 @07:06AM (#54133617) Homepage Journal

          The main one: 'I'll fix that later'

          Often found in close proximity: "Hmm, it's not *that* bad".

          • by arth1 ( 260657 ) on Wednesday March 29, 2017 @09:56AM (#54134269) Homepage Journal

            Often found in close proximity: "Hmm, it's not *that* bad".

            Or "This is how I/we have always done it".

            Duplication of the same bad code over and over again is the sign of inept programmers.
            Passing enormous structures as a stack arguments might work fine the first time or even the fifth. But sooner or later it will blow up.
            Empty try/catch blocks might work well when there isn't anything that needs catching, but sooner or later, there will be.
            Eschewing "this.", using generic names, and letting the compiler handle it might work well now, until someone else makes a change somewhere else.
            Oversizing arrays and always having an off-by-one that ensures overrun if the array ever were to get full will work as long as the array never gets full. But one day it will.
            Not providing a default case because you "know" a variable can only be one of N things create code that works. Now, that is.
            Writing unittests that rubberstamps the exact code you wrote and not what it's meant to do will give you a pass for code coverage. But it is a waste of time. ... and hundreds of other examples of things programmers do over and over again. It compiles, it runs, so it must be okay? What's my next task?

    • Re:Lies? (Score:5, Informative)

      by Tokolosh ( 1256448 ) on Tuesday March 28, 2017 @08:56PM (#54131959)

      "I am worth what they pay me."
      "I am an engineer."
      "Users wish they knew who created this wonderful software."

      • Re:Lies? (Score:5, Insightful)

        by MikeB0Lton ( 962403 ) on Tuesday March 28, 2017 @09:39PM (#54132199)
        DevOps will solve our problems.
      • Re:Lies? (Score:5, Insightful)

        by quenda ( 644621 ) on Wednesday March 29, 2017 @01:17AM (#54132927)

        Number one lie:

        "Yes, this program/module/milestone will be completed on schedule. "

      • Re:Lies? (Score:5, Interesting)

        by AmiMoJo ( 196126 ) <mojoNO@SPAMworld3.net> on Wednesday March 29, 2017 @06:14AM (#54133493) Homepage Journal

        Where do you draw the line on being an engineer? Seems like a good topic for a discussion.

        I think of myself as an engineer, but then again I work at a pretty low level (C/assembler, no OS) and do hardware design too (design, schematic capture, PCB layout). I engineer whole systems, engineer firmware from the ground up.

        The desktop guys... Well, some of the stuff they do is just plugging modules together. But they also build stuff, like web platforms, and have to know how to assemble the modules and write all the glue code. Maybe it's not so different from when I use chips made by other people, rather than building op-amps and microcontrollers out of transistors.

        • In the US, if you want to be a mechanical, or civil, or electrical, or plumbing engineer, these are the rules you generally have to follow.

          - you go to school and eventually graduate

          - you may have to serve as an apprentice (in my state, electricians serve a 5 year apprenticeship)

          - you take an exam that's created and run by the state government in which you want to practice (not by a vendor)

          - if you pass the exam, then you ask the state, not the vendor, for a license (probably some money involved here too)

          • On the other hand, even without a government seal of approval, there are highly-skilled programmers in the world who have written lots of important and well-respected code that runs critical systems and does it very well. These are clearly worth of the name software engineer. The same applies to certain people who do software architecture, and deserve the label software architect.

            So it's not that software engineering doesn't exist, or isn't a valid title, the only issue is that there's no defined standard

          • you may have to serve as an apprentice (in my state, electricians serve a 5 year apprenticeship)

            An electrician and an electrical engineer are rather different.

            So whether you're an engineer or not depends on the state government, not a vendor or a school. This also provides more global skills.

            Global? Ha. If you have a professional license it's good in one state. Other states _may_ provide reciprocity, or they may not. If the state you want to move to requires that your education took a slightly differen

    • Re:Lies? (Score:5, Insightful)

      by davester666 ( 731373 ) on Wednesday March 29, 2017 @12:54AM (#54132883) Journal

      "I'll clean up this code later."

    • I honestly can't remember the last time I used an explicit GOTO. That said, exception handling in most programming languages seems to actually be worse and I've used that.

      Some time ago, someone proposed a spoof programming language, whose name temporarily escapes me, that included just about every bad idea possible. This included a "COMEFROM" structure that replaced GOTO - instead of marking where you wanted the jump at the location of the jump, you instead marked at at the location you jumped to.


  • by El Cubano ( 631386 ) on Tuesday March 28, 2017 @08:25PM (#54131715)
    I'll document it tomorrow
    • by Geoffrey.landis ( 926948 ) on Tuesday March 28, 2017 @08:33PM (#54131791) Homepage

      and "anybody can understand this by just looking at it, it doesn't need to be explained."

    • Re: (Score:3, Insightful)

      by Anonymous Coward
      I suppose that makes me a honest programmer. I usually document stuff as I work because it helps me remember what I've done when I come back to it two years later. I also expand the comments of other peoples code or comment it from scratch because it helps me understand how the hell their code works.
  • by david.emery ( 127135 ) on Tuesday March 28, 2017 @08:25PM (#54131717)

    or even "My code is correct, so I don't need to test."

  • Seriously? (Score:5, Insightful)

    by yodleboy ( 982200 ) on Tuesday March 28, 2017 @08:25PM (#54131719)
    "We'll fix it in the next release."
  • by Dunbal ( 464142 ) * on Tuesday March 28, 2017 @08:27PM (#54131737)
    "One more compile then I'm going to bed..."
  • by Zemran ( 3101 ) on Tuesday March 28, 2017 @08:27PM (#54131749) Homepage Journal
    ... honest... repeat each week for six months.
  • "... including the testing."
  • Most coders (Score:5, Insightful)

    by Jamu ( 852752 ) on Tuesday March 28, 2017 @08:28PM (#54131757)
    I'm a better than average programmer.
    • And by "most", you mean "half of them"? ;)
    • by rtb61 ( 674572 )

      Better than the average programmer but still like warranties that guarantee nothing. It's like the warranties that programmers like, kind of prove how they are all equally bad.

    • This is not mathematically true.
      A = set of all programmers. |A| = 100%
      W = set of programmers that are worse than average. |W| = 50%
      B = set of all programmers that believe they are better than average. |B| = ?%
      (W intersect B) is a subset of W and therefore |W intersect B| <= |W|

      Even if every programmer thinks they are better than average (|B| is 100%) then only half of programmers are lying (not most) to themselves.

      I, however, 100% agree with this sentiment. From my experience, I would guess that |

      • This is also not mathematically true. You are assuming an even and symmetrical distribution of "better than average" and "worse than average" programmers, but the term "average" doesn't necessarily equal the median.

        If you have a number of exceptionally-good programmers, but few exceptionally-bad programmers, the average will be raised to where over 50% of your programmer population is actually qualified as "below average", regardless of their opinions about their skill.

        However, we must consider the dynamics

      • by raymorris ( 2726007 ) on Tuesday March 28, 2017 @11:16PM (#54132607) Journal

        I've discussed the Linux RAID code with Neil Brown, who wrote most of it. That conversation made me keenly aware that my grasp of Linux storage it is rather pitiful.

        I've discussed proposals for new internet protocols with Vint Cerf, known as "the father of the internet". I was reminded I'm the big fish only in a very, very small pond.

        A few weeks ago someone at work asked for "a Perl guru". Just that morning I had participated in the Slashdot discussion with Larry Wall - a fresh reminder of who is a Perl guru and who isn't.

        My co-worker read something about Linux on Stackoverflow, and he knew as much as other people posting to that question knew - he felt like an expert.

        A co-worker once used "telnet 25" to do smtp. Nobody else he knows does that, so he's an expert.

        My own experience is that the more I learn, the more I am exposed to actual experts, the more I discover that there are many people much more knowledgeable than I. If I think I'm really good, that actually just means I *might* be better, in some ways, than the people I talk to - thinking I'm good just means I'm failing to learn from people who are better.

        I strongly suspect those who are humble are the people who read the work of Knuth, T'so, Engelschall, etc - the really programmers know they aren't the best.

      • Re:Most coders (Score:4, Insightful)

        by gnasher719 ( 869701 ) on Wednesday March 29, 2017 @04:05AM (#54133259)

        W = set of programmers that are worse than average. |W| = 50%

        Says who? As an example of a situation where 99% are above average: Most people have two arms. Some are unlucky and have one or none. The average number of arms is maybe 1.99. More than 99% of humans have more than the average number of arms.

  • Numbers are accurate
    As I type this, snow is falling across the Sierras from one of the biggest storms in some time.

    It's "the Sierra". Singular.

  • by dkh9 ( 4914653 ) on Tuesday March 28, 2017 @08:29PM (#54131771)
    It compiles, so it has to work. Right?
  • That one's my favorite, and I run into it all the time.
  • Seems obvious. (Score:5, Interesting)

    by Gravis Zero ( 934156 ) on Tuesday March 28, 2017 @08:40PM (#54131845)

    "The code is self-documenting!"

  • I tell myself that all the time.

    • by dysmal ( 3361085 )

      I tell myself that all the time.

      "I would kill you but then I'd have to fix your shit"

      What I tell our (only) Delphi programmer at work

  • as soon as I get this working.

  • One day, a Slashdot /Soylent/The Inquirer article will point me to silver bullet tech that'll make all this wasted time worthwhile.

  • Unit Tests (Score:4, Interesting)

    by sonamchauhan ( 587356 ) <sonamc@[ ]il.com ['gma' in gap]> on Tuesday March 28, 2017 @08:45PM (#54131883) Journal

    All units pass. Who needs integration tests/functionality tests/load tests?

  • by mrsquid0 ( 1335303 ) on Tuesday March 28, 2017 @08:49PM (#54131911) Homepage

    Fortran is a dead language.

  • Lies (Score:5, Informative)

    by JustAnotherOldGuy ( 4145623 ) on Tuesday March 28, 2017 @08:52PM (#54131933)

    "That error condition will never happen because I trap for it."

    "No one will ever put that kind of stuff into this form field."

    "No customer will ever need more than X number of records for $DATA_ITEM." (kids names, addresses, cars, phone numbers, etc etc etc)"

    "TLD extensions will never be longer than X number of characters."

    "I can positively validate an email address with my home-grown code."

    "No one has a one-letter name." ...and on and on and on....

  • by flopsquad ( 3518045 ) on Tuesday March 28, 2017 @08:56PM (#54131951)
    "I went to the smart school and do intellectual things. My boss went to the party school and does PHB things. I think it's pretty clear who's winning here."
  • than the people paying for it.

    Ultimately software is supposed to solve a real world problem. Its a means not an end. If you focus on writing the greatest, most stable software of all time and the company goes bankrupt around you because you never released and you feel it doesn't reflect badly on you - after all your code was perfect- than you are lying to yourself.

  • ... not just for code.

  • I have honestly sent out software with a 1 page manual and have someone ring me up about a question that is answered in bold at the top of the page.

  • It's not my fault. (Score:5, Insightful)

    by AnotherBlackHat ( 265897 ) on Tuesday March 28, 2017 @09:11PM (#54132033) Homepage

    Order of blame;
    1.) The error is in the hardware.
    2.) The error is in the library routine.
    3.) The error is in my code.

    Order of probability;
    1.) The error is in my code.
    2.) The error is in the library routine.
    3.) The error is in the hardware.

    • by T.E.D. ( 34228 )

      Order of probability; 1.) The error is in my code. 2.) The error is in the library routine. 3.) The error is in the hardware.

      This is exactly why errors in library routines and hardware tick us off so much. Its the next best thing to being betrayed.

  • by kwerle ( 39371 ) <kurt@CircleW.org> on Tuesday March 28, 2017 @09:11PM (#54132035) Homepage Journal

    I can get that done by <any duration>.

  • by UnknownSoldier ( 67820 ) on Tuesday March 28, 2017 @09:21PM (#54132083)

    These should be required reading for programmers AND designers. I'm looking at you Mr. shitty designer/programmer that only lets me put 13 characters in for my (first) name.

    * Falsehoods about Names [kalzumeus.com]

    * Falsehoods about Time [infiniteundo.com]

    * Falsehoods about Computers [imgur.com], aka, Murphy's Computers Laws

    * 97 Things Every Programmer should know [oreilly.com]

  • "Null is acceptable"
    Yes null is problematic. What's the solution? Some languages (like java) allow you to use notnull annotations, etc, but what do you do when something went wrong in a function and you don't have an object to return? Sometimes you can just abort (I'd rather have a nice core dump than a messy memory bug), but this is not always appropriate. You can use exceptions, but exceptions come with their own problems that are worse than NULL pointers in many cases. So I would say NULL is accept

    • For a given function, null return either has a meaning or it does not. "Something went wrong" is not a good enough reason to return null, unless your function documentation says what might go wrong and what that null therefore means.

      If null has no meaning then make it a notnull return, or in Swift a non-optional.

      I used to work with a programmer that used to make all returns optional "just in case". I wanted to punch him.

  • by Anonymous Coward on Tuesday March 28, 2017 @09:36PM (#54132171)

    All throughout school, everyone told me there are jobs for programmers. Everyone lied. I have multiple advanced degrees in computer science. I have started open source projects. I have contributed to open source projects. I debug software for fun. I live and breathe code. And yet, I have no job, and I have no prospects. I apply for jobs, and nothing happens. In my experience, all job listings are lies, and there aren't any jobs out there. There's absolutely nothing at all.

  • by Anonymous Coward

    No. No you won't.

  • Just a quick fix? (Score:5, Insightful)

    by PhunkySchtuff ( 208108 ) <.ua.moc.acitamotua. .ta. .iak.> on Tuesday March 28, 2017 @10:14PM (#54132353) Homepage

    It's just a quick fix - that'll only take 10 minutes.

  • by TsuruchiBrian ( 2731979 ) on Tuesday March 28, 2017 @10:14PM (#54132355)

    "If something seems stupid to me, it is, because I am definitely smart."

    "Smart pointers are stupid. I know how to manage memory, and anyone who can't have zero memory leaks directly using malloc and free shouldn't be coding anyway."

    • by imidan ( 559239 )
      In our shop, we use a lot of XML because our systems communicate with a lot of equipment that requires inputs according to a particular XML standard. We hired a new guy who thought XML was "old and busted" and could not be convinced to write code that output XML. He wanted to store all the values in mongodb as JSON objects and then translate them later. Which, to be fair, would work, if you were good enough to pull it off. He wasn't. He no longer works here, and we're painfully rewriting all of his cod
  • by buss_error ( 142273 ) on Tuesday March 28, 2017 @10:17PM (#54132365) Homepage Journal

    1. I can have this done by the deadline
    2. Oh, it's a simple change, just commit it.
    3. I can adapt another routine, it'll cut the programming time
    4. Your code sucks
    5. My code shines
    6. Don't bother with that use case, it'll never come up.
    7. Our users wouldn't be that stupid.
    8. Our users wouldn't be that smart.
    9. It's completely debugged.
    11. There are no errors in this top 10 list.

    • It's normal to work these kind of hours.
    • Management knows what they are doing.
    • It's normal for the company to fire people frequently and without warning.
    • Working long hours then going home and working on open source my company uses for free is normal and a good idea.
    • My stock options are going to be worth a lot of money someday
    • I'll never have to worry about office politics
    • It's okay if the pay is lower and the hours are longer if my company has a great culture
  • also described as: "I can keep working as a software developer as long as I want to".
  • demo code (Score:4, Insightful)

    by rastos1 ( 601318 ) on Wednesday March 29, 2017 @02:03AM (#54133047)

    "Don't worry. This will be used only as a demo/proof of concept and never in production".

    Actually that's a lie told to me by the management and I tend to believe it up to the date when the demo happens.

  • by MonoSynth ( 323007 ) on Wednesday March 29, 2017 @02:21AM (#54133091) Homepage

    "I fully understand the problem"

  • by Tom ( 822 ) on Wednesday March 29, 2017 @02:37AM (#54133117) Homepage Journal

    The most often told and most consequential lie that programmers constantly tell themselves is this one:

    I'll fix this later.

  • by nospam007 ( 722110 ) * on Wednesday March 29, 2017 @02:49AM (#54133123)

    I will document that piece of code later so that I remember why it does what it does.

  • by GerryHattrick ( 1037764 ) on Wednesday March 29, 2017 @04:28AM (#54133299)
    "My code is self-documenting, I need do no more."
  • MM/DD/YYYY (Score:5, Insightful)

    by deburg ( 838010 ) on Wednesday March 29, 2017 @05:48AM (#54133447)
    "Everyone uses the American Date format, that is MM/DD/YYYY", 'nuff said
  • by Rufty ( 37223 ) on Wednesday March 29, 2017 @06:02AM (#54133475) Homepage

    Well, 10 minutes after the upgrades, the install of the new service, the hard reset of the router, the changes to the firewall ...
    Currently only had one 10 minute job that's hit the day 3 mark ... this month.

  • by baadfood ( 690464 ) on Wednesday March 29, 2017 @08:02AM (#54133771)

    Whats the deal with nulls?
    While I can attest to the accuracy of the other 8/9 issues causing extended bouts of hair-pulling stress, I've never found nulls be problematic.

    I mean, sure they have been a source of errors while developing, but dealing with them is just as aspect of dealing with function boundry conditions, and whether you do it via bools, nulls, exceptions or whatever, it has to be done.

Perfection is acheived only on the point of collapse. - C. N. Parkinson