Ask Slashdot: What Are Some Lies Programmers Tell Themselves?

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?

Comments

Lies?

[msauve]

That they never GOTO work.

Re:Lies?

[Tokolosh]

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

Re:Lies?

[MikeB0Lton]

DevOps will solve our problems.

Re:Lies?

[davester666]

"I'll clean up this code later."

Re:Lies?

[quenda]

Number one lie:

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

Re:Lies?

[freeze128]

"I'll document this code later."

Re:Lies?

[Anonymous Coward]

"I am worth what they pay me."

Why would this be a lie? Most developers produce software that generates their company many orders of magnitude more profits than they earn, so developers are typically worth far more than what they usually actually earn.

Even when I was junior I was earning the equivalent of about $60,000 USD, but the development I was doing with very little input from anyone else was directly pulling in over half a million USD in sales. How is that not worth it? Most businesses would love to get a half million dollar return on a $60k investment, and I think this story is similar for most developers.

This is precisely why developers are in so much demand that the supply can't be met - because most of them are genuinely a cash cow.

Re:Lies?

[fisted]

"I'll have sex later."

Re:Lies?

[AmiMoJo]

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.

Re:Lies?

[SCVonSteroids]

Damnit no wonder I'm so lonely

Re:Lies?

[squiggleslash]

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.

Guaranteed unreadable. Worse than GOTO. And, hey, guess what, that's pretty much what exception handling is in 99% of implementations. The only way around it is to put one statement, and one statement only, in your try { ... } block, and who does that?

Re: Lies?

[dougdonovan]

i like my job...i like my job.

Re:Lies?

[Big Hairy Ian]

Anyone can read my code!

Re:Lies?

[Big Hairy Ian]

There are no bugs in my code

Re:Lies?

[Oswald McWeany]

Right after I clean the Cheetos dust off my keyboard and mouse.

Re:Lies?

[Bongo]

Dictionary says, "a person who uses scientific knowledge to solve practical problems".
That raises question, is programming a science or art, or somewhere in between, like a disciplined craft?
Is a cook an engineer because he or she knows the correct way to poach an egg?
Does working with hardware make it more engineering than working with purely software?
Maybe the difficulty with definitions is that engineering often involves the physical world (physiosphere) but approached with a lot of knowledge held in the mind (the noosphere), and whilst there is a lot of discipline in erecting a bridge, there is also a lot of discipline in how to think about the bridge in the first place.
So I suspect that when people say "engineer" they mean that there is a lot of careful, rational, knowledgeable design going on.

Re:Lies?

[AmiMoJo]

Interesting way of defining it. For me I certainly do have to consider the physical world, even when writing firmware code. For desktop... Well, we mock patents that are just something that happens in the real world by "on a computer", so maybe building virtual stuff counts too.

Re:Lies?

[Anonymous Coward]

Where do you draw the line on being an engineer?

Have you studied physics, chemistry, and thermodynamics? Do you have an engineering degree from an ABET-accredited university? Do you hold a Professional Engineer license?

Re:Lies?

[vakuona]

The value of a developer is dictated by the value of what they produce, but their cost (as in what a developer is paid) is determined by two things (1) the cost of a replacement developer, and generally what another developer with a similar skillset, will demand, and (2) what the same developer is able to earn elsewhere.

In a reasonably working labour market, (2) is implied by (1).

Re:Lies?

[DickBreath]

I read it online, so it MUST be true!

Do what management says because they know best.

They couldn't possibly hire anyone that can replace me.

This change is so small and inconsequential that it doesn't need to go through the formality of testing and staging.

If one of the power supplies in a server is on fire, best practice is to notify all of the stakeholders to schedule a meeting to resolve the issue and put out the fire.

Trump will direct NASA to redesign SLS to use coal. Effective April 1, 2017.

Re:Lies?

[srmalloy]

"The database definition requires this field to be populated; I don't need to check to make sure it's not NULL."

Re:Lies?

[Anonymous Coward]

That's called Intercal and "fixed" every "wrong" that language designers talked about at that time.

Re:Lies?

[arth1]

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

One that designs based on actual data and tolerances.

What the overwhelming majority of programmers do has nothing to do with engineering, and more to do with jerry building.

Re:Lies?

[null etc.]

I've seen far more problems caused by a lack of DevOps than I've seen from DevOps implemented well or even moderately passable.

Re:Lies?

[arth1]

Is a cook an engineer because he or she knows the correct way to poach an egg?

If he designed his own method for poaching it based on actual scientific data and tolerances, sure. Being able to read a recipe book or repeat what someone else has decided is "correct" has nothing to do with engineering. Then you're an operator.
And if you're able to modify the recipe to fit the kitchen, perhaps adjusting the amount of water, acid or cooking time because the original recipe doesn't work, you're still not an engineer, but might be worthy of technician.

Re:Lies?

[Ihlosi]

Is a cook an engineer because he or she knows the correct way to poach an egg?

He or she is a technician in the field of (chemical, biological, thermal and mechanical) process engineering involving food.

Re: Lies?

[maple_shaft]

Anybody that does any kind of programming is working on an abstraction level of some kind all the way down to the transistors connected together to form a basic NAND gate. Judging each other as "Not a True Scotsman" is nothing more than a dick measuring contest. Engineering is a codified discipline for the practical application of principles based in science to build pragmatic solutions in an ethical way.

Re:Lies?

[ranton]

Why would this be a lie? [...] Even when I was junior I was earning the equivalent of about $60,000 USD, but the development I was doing with very little input from anyone else was directly pulling in over half a million USD in sales.

I highlighted the lie he was talking about in your statement. If there was really very little input from anyone else, you really should have went into business for yourself and made that half million dollars directly. But my guess is your work required your company's existing products/services, clients, marketing, client services, business processes, etc to make that $500k. You might not have needed many people on your team, but there was still a huge infrastructure put in place by your employer to attain that revenue.

Your value is more related to your replacement cost, and the extra value you bring in as opposed to your potential replacement. If another programmer making $60k per year could have also wrote software that made your company $500k, then you were worth $60k. It should be noted that this is no different than the value your employer's goods and services have in the marketplace. The value is in comparison to alternatives in the marketplace, not simply the ROI the buyer can make on the purchase.

Re:Lies?

[waveclaw]

Just because the standard for a title where you live is low enough to admit anyone who self-identifies does not mean that other people place a lot of value in their definition of that title.

Depending on where you work there is a very clear line for being an engineer. In many cases Engineer is a protected title with legal obligations.

Only passing the PE as an EIT can you actually call yourself an Engineer in Texas. Even software developers in Texas, USA have to site before the Board of Professional Engineers and pass the Exam to call themselves an Engineer.

You can't just walk in with your freshly minted Software 'Engineering' degree from an ABET certified college program. You have to be a Texas Engineer in Training (EIT) to register to take the PE exam. That is usually having worked under a PE mentor in the capacity you are training for.

This is very similar to other protected titles in other counties like Registered Pharmacist in the UK.

This title caries with it a lot of ethical and legal requirements that most "coders" or "programmers" would not be able to meet just based on the code they write. But such titles carry with it the authority to tell management where they can stick it when they ask for faster, cheaper by cutting corners that are not Salespeople Features.

The biggest lie, just based on the number of empty GitHub Projects is probably "I can do this."

Re:Lies?

[david_thornley]

I believe you're thinking of Intercal, whose control structures were based on COME FROM and COME FROM UNLESS, provided there were enough PLEASEs in the code.

Exception handling is for exceptional situations, and should be used only in cases where what happened is significantly more important than exactly where it happened, for example the inability to allocate memory.

Re:Lies?

[micahraleigh]

5th grade (25 years ago)

Re:Lies?

[EndlessNameless]

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

An engineer has all of the skills of a technician in the field, plus a deep theoretical understanding of the field which allows him to create new devices or improvise solutions reliably.

There are generally quality and liability assurances with professional engineers which are absent from software engineering. However, these are social/legal concerns which do not relate directly to the skills and knowledge of the individual.

I believe there should be a software engineering profession with licensing and liability. Fields with public health and safety concerns should be required to employ engineers in good standing rather than unlicensed programmers (e.g., the automobile, food, medical, aviation, and space industries).

Re:Lies?

[nasch]

The idea is you have logging that tells you what happened. If necessary that will include a stack trace that indicates exactly where the error occurred. I think some IDEs can highlight the statements that could trigger the caught exception. Do you often find yourself looking at a catch block and needing to know what throws to it? If so, why? If not, then it isn't a problem.

Re:Lies?

[dranga]

I think that was Intercal... Though, in a way, catching an exception is just a dynamic form of the comefrom statement...

Re:Lies?

[squiggleslash]

The idea is you have logging that tells you what happened. If necessary that will include a stack trace that indicates exactly where the error occurred.

Computers do not read logs, nor do they parse stack traces. If you're at the point you're reading a log or stack trace, then there's obviously a serious problem with your code. Subtle problems are likely to never appear.

Do you often find yourself looking at a catch block and needing to know what throws to it?

Alas. Yes.

If so, why?

Because structurally it encourages developers to hide issues rather than handle them at the time. Exceptions are rarely exceptional, they're thrown over common situations such as files not existing or servers not responding with data over a network.

Really we need to rethink what we use exceptions for - and, indeed, if we should have them at all.

Re:Lies?

[Dixie_Flatline]

I rarely find it's programmers that say this, it's people that are programming adjacent that say this.

Programmer:
"This'll be finished on time barring "

Manager/Marketing/Whoever:
"It'll be done on time? Great! NO BACKSIES"

Re:Lies?

[luis_a_espinal]

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

One that designs based on actual data and tolerances.

What the overwhelming majority of programmers do has nothing to do with engineering, and more to do with jerry building.

As someone that works under the title of software engineer, I agree with this, except with the jerry building part. There is jerry building and there is jerry building, one on actual data and tolerance, one done as a craft, and one where people throw shit at the wall and package whatever sticks.

If you apply the scientific method to your work, have clear tolerances and work on actual data, or data inferred by some type of model, then shit, a lot of software jerry building then also accounts as engineering (and there is lot of that.)

But it is also true a lot of what is done in software is not engineering, not even craft (but shit flinging.) The field of software is still too young to clearly define what is engineering and what is craft (and far more dynamic than most fields that have come before it.)

Re:Lies?

[havana9]

"I am an engineer."

I am a Chartered Engineer, actually.
I work as a programmer for now. But for instance I could legally design and sign network and electrical wiring and lighting protection systems.

I'll document it tomorrow

[El Cubano]

I'll document it tomorrow

Re:I'll document it tomorrow

[Geoffrey.landis]

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

Re:I'll document it tomorrow

[Anonymous Coward]

And "It's documented so nobody will ask that again"

Re:I'll document it tomorrow

[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.

Re:I'll document it tomorrow

[Anonymous Coward]

"If I work extra hours to get this crisis resolved, they will see how awesome I am, give me a raise, and give me more say over my development priorities."

"If I do this side-project on my own time, so that it is ready to go by the time they realize they need it, they will see how proactive I am, and what a rainmaker I am, and give me the salary and respect I deserve."

"If I stay at this job for many years, they will reward my loyalty by giving me raises that not only keep up with market rates, but exceed them."

"Searching for another job just to invite my employer into a bidding war over my salary is an asshole thing to do."

Face the facts: people value that which they pay for far more than that which they receive for free. That includes your time and your talent. Furthermore, they want to keep as much of their money for themselves as they can, so they will do everything they can to pay you as little as you will accept. The *only* way you can get what you are worth is to force the issue.

Re:I'll document it tomorrow

[doesnothingwell]

Short version, my boss says, "Your bonus is in the mail."

Re:I'll document it tomorrow

[Anonymous Coward]

That old code of mine is unintelligible rubbish. Thankfully I'm a much better programmer now, so this new code will be a monument of pure, self-evident brilliance.

Re:I'll document it tomorrow

[ancientt]

If I think I'll have to do it at least twice and the program takes less time than doing it twice, then I'll write the program.

If I actually have to do it twice, I add documentation the second time.

Re: I'll document it tomorrow

[Kabukiwookie]

I don"t need to document my code. My code is the documentation.

Re:I'll document it tomorrow

[gnasher719]

"Searching for another job just to invite my employer into a bidding war over my salary is an asshole thing to do."

It's not an asshole thing to do, it's a stupid thing to do. If you pull it off, you'll be gone within a year. If you don't pull it off, you'll still be gone within a year.

Search for another job to find a new employer who is willing to pay you more for leaving your old job and starting with them.

Re:I'll document it tomorrow

[FalcDot]

I would expand this to:

"I'll have time to improve on this later."

Documentation is certainly the most common improvement that gets postponed, but kludged together code will also tend to survive longer than expected.

Re:I'll document it tomorrow

[No Longer an AC]

"If I work extra hours to get this crisis resolved, they will see how awesome I am, give me a raise, and give me more say over my development priorities."

This one.

I actually came to say essentially the same thing.

I went several years without a raise. I finally got a bonus one year. It was so small it was practically an insult. The CEO openly told us that we were lucky to even have jobs as he laid off our co-workers.

I can't tell you how much schadenfreude I feel now that they are under criminal investigation now.

One of the execs has been charged with "crimes against the financial system” in Brazil.

I'm kind of surprised it isn't getting more press but I guess most of the corruption was in South America rather than their American assets. I'm sure it's just a coincidence that the family who runs that company shares the name of a Cuban dictator that was in power before Castro. Really, I am sure it's just coincidence. Batista is a common enough name.

See Operation Car Wash and Operation Weak Flesh for more info. Who makes up these names?

Completely unrelated video: Car Wash

Dunno why, but I really appreciate that song even more now.

Re:I'll document it tomorrow

[DickBreath]

"Management really means what they say when they talk about how they want us to build quality software."

"Management really means what they say when telling us that they'll get us whatever we need to do the job properly."

Re:I'll document it tomorrow

[null etc.]

That old code of mine is unintelligible rubbish. Thankfully I'm a much better programmer now, so this new code will be a monument of pure, self-evident brilliance.

I'm legitimately surprised whenever I try to rewrite something I've done previously, and fall short of my past efforts. There have been cases where I thought source code went missing, so I reprogrammed something, and eventually rediscovered the original source code and found it to be far superior.

What, is solving technical problems actually making me more stupid?

Re:I'll document it tomorrow

[Rei]

Or the more annoying:

void fn193(dt_1011 a)
{
/* BEGIN FUNCTION */

/* IF a is greater than 5 THEN*/
    if (a > 5)
    {
/* Loop 10 times */
        for (int i = 0; i < 10; i++)
        {
/* Call fn828 with arguments a and i */
            fn828(a, i);
        }
/* end IF statement */
    }
/* end FOR loop */

...

/* END FUNCTION */
}

.... without ever having mentioned why they're doing any of it. Yes, someone who used to work here actually programmed like that. A comment on almost every line, and none of them at all useful. :P

They did sometimes have function headers. Unfortunately they were mostly cargo-cult style copies, full of meaningless cruft and long-outdated information, and... it almost hurts me to say this... doublespaced. ;)

Re: I'll document it tomorrow

[Zero__Kelvin]

Which reminds me "Everyone will assume I'm right if I sound authorative, and say 'you're damned right it is' a lot" :-)

Re:I'll document it tomorrow

[david_thornley]

Comments should be high-level explanations. If any reasonable rewrite of a function would invalidate a comment, other than doxygen comments and similar, remove the comment. It won't be kept current, and will become misleading.

One example of a useful comment would be why a certain approach isn't being used, or a brief comment mentioning the user request that caused you to write or change the code.

Re:I'll document it tomorrow

[orgelspieler]

The crappier my code, the more I document it. I have been through some of my old code, and right where I was thinking "WTF dude?!" I see a comment along the lines of "you put this in here because there was a bug in somebody else's component, and this was the only work around. Do not try to 'fix' it!" Or my personal favorite: "PFM: Do not touch!"

Re:I'll document it tomorrow

[micahraleigh]

+1. This! And the negative example where everyone wants to rewrite someone else's code because it's spaghetti.

Re:I'll document it tomorrow

[swillden]

Concisely put.

Re: I'll document it tomorrow

[swillden]

Which reminds me "Everyone will assume I'm right if I sound authorative, and say 'you're damned right it is' a lot" :-)

Well, I am right, so that works :-)

Maybe I should have said "you're damned right it is" more than once, to increase the authoritativeness quotient.

Re:I'll document it tomorrow

[swillden]

Absolutely agreed. There are exceptions to every rule -- which doesn't make the rules any less valuable.

"I've done enough testing"

[david.emery]

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

Re:"I've done enough testing"

[Anonymous Coward]

"Tabs are better than spaces"

"Enforcing scope via indent was a good idea"

Re: "I've done enough testing"

[Ken_g6]

Along the same lines, "It was just a minor change, I don't need to test it."

Re: "I've done enough testing"

[DickBreath]

This is not a lie, but a true statement: ALL developers have a testing environment that they can deploy to. Some developers also have a production system that is separate from the testing environment.

Re:"I've done enough testing"

[codlong]

How about, "I don't have time to write tests."

Re:"I've done enough testing"

[Jason Levine]

This bit me hard years back. I had made a "minor change" and pushed it live on a Friday afternoon. (Do you hear the sirens blazing yet?) That weekend, my parents were visiting so I was looking forward to some family time. Instead, I had to go into work on Sunday and debug the application because my "minor change" brought the whole system down.

I learned two important lessons that day:

1) Always test everything no matter how minor it seems.

2) NEVER push something live on Friday - even if you've done all your testing. Wait until Monday to push it live so that your weekend isn't interrupted by support calls.

Re: "I've done enough testing"

[DickBreath]

ALL developers have a testing environment. You do. You may just be mis-naming it as a "production" environment.

But SOME developers also have a production environment separate from their testing environment.

Get the joke?

Re:"I've done enough testing"

[minstrelmike]

the networking department we have is notorious for scheduling updates Friday at 5pm. They even tried to force us to change our standard timing for major updates but we refused. We release Tuesdays at 10am with everybody ready to take calls and fix foul-ups and that's when everyone is on the system actually using it. We do have folks who sign in over the weekedn but they aren't power users and their error reports leave a lot to be desired.

Re:"I've done enough testing"

[ebvwfbw]

Supposedly Dijkstra used to say Error Checking is for Chumps. Yes, the C++ Dijkstra.

Re:"I've done enough testing"

[david.emery]

And all those users who you inconvenienced, or worse, in the middle of the day with an update, loved you for this....

Re:"I've done enough testing"

[minstrelmike]

No. If there was a problem, they called Tuesday at lunch. They didn't _try_ calling someone Friday at 10pm.

Seriously?

[yodleboy]

"We'll fix it in the next release."

Re:Seriously?

[DickBreath]

"There actually will be a next release, we can fix it then."

That was a really small change.

[Anonymous Coward]

We can put it right into production.

I'm just a hobby programmer but...

[Dunbal]

"One more compile then I'm going to bed..."

Re:I'm just a hobby programmer but...

[Dog-Cow]

Sounds more like the message is unintelligible because it's being used by retarded morons.

Re:I'm just a hobby programmer but...

[petermgreen]

Anywhere you care about being able to answer the question "what was on branch x on date y".

Re: I'm just a hobby programmer but...

[Zero__Kelvin]

In fact, with svn, if the network is down there is no step one either ;-)

It will be finished next week

[Zemran]

... honest... repeat each week for six months.

"I can make that deadline ..."

[NoCleverName]

"... including the testing."

Most coders

[Jamu]

I'm a better than average programmer.

Re:Most coders

[K. S. Kyosuke]

And by "most", you mean "half of them"? ;)

Re:Most coders

[rtb61]

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.

Re:Most coders

[TsuruchiBrian]

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 |W intersect B| is shockingly close to |W|, 50% (the theoretical maximum). Or to put it another way most bad coders believe the lie that they are better than average.

Re:Most coders

[Sarten-X]

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 of the programming industry. If someone is indeed a terrible programmer, they are likely to be driven out of the industry, either by their own choice or by management. On the other hand, the good programmers will usually be encouraged to stay. That puts a bias on the distribution, raising the average quality of programmers beyond the median quality of programmers.

Re:Most coders

[viperidaenz]

That comes down to smart people realise they don't know what they don't know, so they know they don't know everything,
Stupid people people don't realise this. Once they know a bit, they think they know it all.

Re:Most coders

[turbidostato]

"1) The overwhelming majority of the time, the programmer is not in control of key aspects of the development process, all of which cause bugs. Examples include determining the deadlines (rushed code = buggy code), determining the required hours (overworked programmer = buggy code), determining the right amount of QA resources (too little investment in QA = buggy code), and enforcing requirement stability (changing requirements during development = buggy code)."

And that's they lie developers tell to themselves that executives love the most: that somebody setting a deadline somehow makes it a law in stone. You promised it for tomorrow? You code it, or else, it'll be done when it's done, and not a minute earlier.

Re:Most coders

[TsuruchiBrian]

Average is a general term that can refer to the mean or the median among other things. I would argue that phrase " is better than the average " implies a median average rather than a mean.

Re:Most coders

[mrvan]

The majority of coders can actually be better than the mean (average) coder. The median coder, though...

Re:Most coders

[crispytwo]

I have an opinion about that!

Re:Most coders

[gnasher719]

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.

Re:Most coders

[gnasher719]

The majority of coders can actually be better than the mean (average) coder. The median coder, though...

If the number of coders is odd, then less than half the coders are better than the median. And less than half are less good than the median. And at least one is exactly as good as the median.

If the number of coders is even, then at most half are better than the median.

Re:Most coders

[Dog-Cow]

For the purposes of this discussion, non-practicing programmers don't count. Thus, if the worst leave the industry, they are no longer contributing to the average.

Re:Most coders

[pr100]

Suppose we had a numeric measure of programmer quality - say a number out of 10.

Suppose every programmer except Fred had quality 5.

Fred has quality 4.

If there are lots of programmers then the average is just below 5. And everyone except Fred is better than average.

If all programmers believe they're better than average, then this is a correct belief for everyone except Fred.

Re:Most coders

[Hognoxious]

I would argue you should take a stats course. If you mean mode, say mode. If you mean mean, say mean. And say whether it's arithmetic, geometric, harmonic...

Re:Most coders

[Hognoxious]

if the worst leave the industry

You owe me a new keyboard.

Re:Most coders

[roman_mir]

Stop picking on Fred, dammit, he has it hard as is already!

Re:Most coders

[VeritasRoss]

90% of people make up statistics. The other half are bad at math.

Re:Most coders

[TsuruchiBrian]

I am not the OP. I can only infer that he/she meant median (because that's what most people mean in this context). I used the same terminology as the OP in an attempt to make it clearer how my claim was intended to relate to his/her claim. It should also be obvious that I was also referring to a median given the definition of a median. And you are free to infer that my claim is only valid for a median average.

I don't begrudge you for nitpicking, especially since that was what I was basically doing. I just think my "nitpick" may actually have some actual value, rather than only being a nitpick. My intention wasn't to nitpick even though it kind of ended up that way.

Re:Most coders

[K. S. Kyosuke]

Now you're just being mean!

Re:Most coders

[minstrelmike]

My "tell" for knowing who is smart and who isn't is not the answers they give; it is the questions they ask.

I'm an engineer...

[Anonymous Coward]

Rather than just a programmer.

That Slashdot is still worth reading.

[ZecretZquirrel]

See subject line.

Re:That Slashdot is still worth reading.

[topology]

"I'll quit reading and posting on Slashdot, just after I finish this post about how far it has declined."

His numbers may be accurate, but his English?

[whoever57]

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.

Re:His numbers may be accurate, but his English?

[Anonymous Coward]

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.

FYI: You're a special kind of douchebag. The California/Nevada "Sierra" is the only "Sierra Mountains" that isn't called "The Sierras" by locals. Maybe he's just not a local, douchebag.

Re:His numbers may be accurate, but his English?

[tsqr]

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.

FYI: You're a special kind of douchebag. The California/Nevada "Sierra" is the only "Sierra Mountains" that isn't called "The Sierras" by locals. Maybe he's just not a local, douchebag.

I don't know which of you is the douchebag, but I know which of you is wrong. "Sierra" means "mountain range". Saying "Sierra Mountains" is like saying "Rio Grande River" or "tree forest"; this sort of usage is common among people who refer to San Francisco as "Frisco".

Re:His numbers may be accurate, but his English?

[the phantom]

I lived in Reno for over a decade, and referred to the mountains as ``the Sierras'' for years. I am so embarrassed that no one ever corrected me. :(

It compiles...

[dkh9]

It compiles, so it has to work. Right?

Re:It compiles...

[DickBreath]

It works on my machine. Oh, wait.

"Good programming discussion is found at /."

[Anonymous Coward]

"Good programming discussion is found at Slashdot"

Re:"Good programming discussion is found at /."

[Boronx]

Who believes that?

Re: "Good programming discussion is found at /."

[Anonymous Coward]

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

Re: "Good programming discussion is found at /."

[AntiSol]

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.

Re: "Good programming discussion is found at /."

[Anonymous Coward]

If you are in such a situation, what incentive as an individual there is to not commit sloppy code? As far as I can see it's a win-win. Not only you get the task done quicker and make the boss happy, it also provides job security as nobody else will be able to fix the mess you made. Unless the whole company goes under but that's probably not something you can affect significantly anyway.

Re: "Good programming discussion is found at /."

[Hognoxious]

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

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

Re: "Good programming discussion is found at /."

[arth1]

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: "Good programming discussion is found at /."

[Asgard]

If you are in the on-call rotation, it means your sloppiness will cause you to be up at 2am fixing it while also answering 20 emails asking for status.

Re: "Good programming discussion is found at /."

[Kiaser Zohsay]

Tradition.

Re:"Good programming discussion is found at /."

[Caesar Tjalbo]

My coworkers are ok

"Rust will replace C++"

[Anonymous Coward]

"Rust will replace C++"

Re:"Rust will replace C++"

[Anonymous Coward]

"Java is fast"

Re:"Rust will replace C++"

[amicusNYCL]

If the customer asked for it, that must be exactly what they want.

Re:"Rust will replace C++"

[Anonymous Coward]

My job can't be replaced by artificial intelligence.

Re:"Rust will replace C++"

[Anonymous Coward]

"Neural nets and deep machine learning are artificial intelligence"

Re:"Rust will replace C++"

[Z00L00K]

"This has to be configurable".

Re:"Rust will replace C++"

[sonamchauhan]

That particular statement has somehow been working out true for most of us in the last 50 years. Lets see.

Re:"Rust will replace C++"

[Hognoxious]

... with XML. Lots of it.

Re: "Rust will replace C++"

[Anonymous Coward]

"The Luddites are wrong. Only appy apps can app app."

Re:"Rust will replace C++"

[Big Hairy Ian]

"I don't write Spaghetti Code"

*Doffs Colander*

Re:"Rust will replace C++"

[DickBreath]

Another lie programmers tell themselves: "This doesn't need to be configurable. The state legislature would never change this particular value from 3% to 2%. It's 3% and that's the state law! End of story."

Re:"Rust will replace C++"

[swillden]

"Java is fast"

What is generally not a lie, though, is "Java is fast enough".

Re:"Rust will replace C++"

[DivineKnight]

State machines are Artificial Intelligence.

Re:"Rust will replace C++"

[Hotawa Hawk-eye]

The customer knows what they want.

Re:"Rust will replace C++"

[Lemmeoutada Collecti]

"I know AI when I see it." often followed by "That is not AI"

Error free code...

[Anonymous Coward]

I once had a newbie programmer tell me that we could skip the code review because he wrote bug free code. I thought he was joking until he got insulted when I laughed my ass off.

Re:Error free code...

[amicusNYCL]

A programmer I used to work with would never say that his code had bugs, he would always refer to them as anomalies and not know how to fix them. He didn't last long.

Re:Error free code...

[DickBreath]

I definitely do not like programmers with small pricks.

They usually do not know what they are talking about. They don't understand the business, the customer, the product, or the technologies in use. But they have a stack of certifications.

Re:Error free code...

[micahraleigh]

After programming for 12 years and taking incremental pay increases in the local mean for the field, I got a couple certifications and my compensation went up 30%.

Generally MCSDs get paid 7 to 13% more than developers who are not MCSDs.

"I don't need any unit tests."

[PJ6]

That one's my favorite, and I run into it all the time.

Seems obvious.

[Gravis Zero]

"The code is self-documenting!"

Delphi will make a comeback.

[SensitiveMale]

I tell myself that all the time.

Re:Delphi will make a comeback.

[dysmal]

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

Re:Delphi will make a comeback.

[BarbaraHudson]

You have to admit it beat the shit out of it's biggest competitor at the time - Visual Basic.

Re:So topical

[Anonymous Coward]

You meant, of course, discrimination FOR women:

http://www.news.cornell.edu/stories/2015/04/women-preferred-21-over-men-stem-faculty-positions

I'll add the documentation

[SensitiveMale]

as soon as I get this working.

Deus Ex Scriptus

[sonamchauhan]

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

[sonamchauhan]

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

or...

[mrsquid0]

Fortran is a dead language.

The project is almost 90% complete ...

[Anonymous Coward]

... and that last 10% will take no time at all!

The System is Usually in an Error-Free State

[michael.karl.coleman]

The truth is that some part of whatever system you're thinking about is almost always suffering from errors.

It worked yesterday.

[Anonymous Coward]

I didn't change anything that matters.

I know I tested that.

That shouldn't matter for this case.

I'll fix that later.

This should only take ten minutes and fix things.

The hardware upgrade will fix all the performance problems.

Lies

[JustAnotherOldGuy]

"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....

The smartypants fallacy

[flopsquad]

"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."

Biggest Lie: We know better

[ghoul]

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.

Re:Biggest Lie: We know better

[david_thornley]

On the other hand, plenty of users will say what they want, and will be very unhappy with you if you implement it and claim it's the solution they wanted. Frequently you have to understand the actual problem, and that then you'll do a much better job of figuring out what they need than they will.

I will clean up later

[GuB-42]

... not just for code.

Re: uh huh

[sycodon]

I understand the task
I have thought of all the possible test scenarios
I have coded for all possible test scenarios
The scope will not change

Re:One in a million is rare. One in a billion is n

[BarbaraHudson]

1 is prime, 3 is prime, 5 is prime, 7 is prime, 9 is prime ...

Someone will read the manual

[ASDFnz]

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.

Re:Someone will read the manual

[Actually, I do RTFA]

I sent out a program with a 1 paragraph install set of instructions, and the lead tester didn't read it. Messed up all the installations for that round of testing.

We weren't up to testing the installer yet.

Re:So topical

[BarbaraHudson]

I calll bullshit. There's a HUGE difference between positions in education and in industry and commerce.

It's not my fault.

[AnotherBlackHat]

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.

Re:It's not my fault.

[avandesande]

FIFY


1.) The error is in my code.
2.) The error is in my code.
3.) The error is in my code.

Re:It's not my fault.

[Anonymous Coward]

Don't forget the compiler! Bloody compiler sabotaging my perfectly good code!

Re:It's not my fault.

[Anubis IV]

We had a third-party try to pull this one just this week with the client we both serve. Strange thing is, it actually seems like it was true this time!

Re:It's not my fault.

[ET3D]

You forgot the drivers. As a GPU programmer I often blame the drivers. Of course it's usually my error, but I did come upon driver bugs and even hardware bugs.

Re:It's not my fault.

[jittles]

We had a third-party try to pull this one just this week with the client we both serve. Strange thing is, it actually seems like it was true this time!

I've found a compiler bug one time in my entire career. It was a pretty tough bug to pin down and was only a problem on a specific version of g++ when doing some very unusual things with templates. It was causing a mutex to not initialize properly. It was a nightmare and I wanted to strangle the person who wrote that code once I figured out what was going on. Fixing their code was so difficult that we ultimately just used a semaphore instead of a mutex on that specific platform.

Re:It's not my fault.

[michael_wojcik]

Yes. I suspect many of us have cried wolf about the compiler once or twice, only to be proven wrong.

I still remember the time I found an actual silent code-generation bug (for standard-conforming source) in the Hi C compiler, verified by the vendor. It was around 1990. I've looked at a lot of compiler output over the years, and caught the occasional noisy bug (where the compiler issues a diagnostic indicating it's detected an internal error); but I don't know that I've ever seen another genuine silent code generation error for conforming input.

I found a bug in a commercial C library implementation once, too (also verified by that vendor). That's out of dozens of implementations, and hundreds of versions of them, that I've used. Again, it may have happened more than once, but I'm not recalling any other instances at the moment.

I haven't counted errors in code I've written, but a reasonable estimate puts it somewhat greater than 1. These days, while I'm open to the possibility of hardware, OS, library, and compiler errors, I start with the assumption that It's My Fault.

Re:It's not my fault.

[Anubis IV]

Yeah, about the closest I've seen (and even then, it's still exceedingly rare) is a compiler optimization that results in unexpected behavior.

For instance, when I was in grad school I was looking through the assignments for a class of intro-level students. They were using functions for the first time, so the prof had them take some inputs, do a simple summation in a function, return the result, and output it to the screen. Nothing fancy. Everything ran as expected when I tested this one student's program, but when I looked at the code, I saw that his addition function had no return statement. I figured he had cheated and put all of the logic in main() so as to circumvent using a function, but that wasn't the case. His code called the function and then output the result it was somehow getting back.

Eventually I dragged some other grad students in and we realized it had to be a compiler optimization that had taken his single-line function and optimized it as an inline function, effectively allowing it to return a value, despite the lack of a return statement. After we had the compiler output the assembly so we could look it over, we were able to confirm the theory.

Re:It's not my fault.

[david_thornley]

I have encountered, IIRC, three legitimate cases of compiler error in my career, one of which was easily fixed. That's about one every 13 years or so.

Re:It's not my fault.

[T.E.D.]

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.

I can get that done by...

[kwerle]

I can get that done by <any duration>.

"Nobody will ever re-purpose this ...

[davidwr]

... so I don't have to write defensively."

or the opposite extreme

"Someone may re-purpose this for [insert laundry list here] so I better spend 10x the effort to create perfect code, never mind that it will blow the budget and make the product too late to market."

For the newbie programmer:
There are times when you do NOT need to write defensively. There are times when you must strive for perfect code at the expense of time and money. Most of the time the best approach is somewhere in between. With experience, you will begin to learn which times are which.

Time, Names, Murphy's Computer Laws

[UnknownSoldier]

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

* Falsehoods about Time

* Falsehoods about Computers, aka, Murphy's Computers Laws

* 97 Things Every Programmer should know

My gripes with the first 2

[TsuruchiBrian]

"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 acceptable (not good), when the alternatives are something worse or nothing.

"Human relationships can be codified"
They absolutely can be codified. Geneology software is pretty good at doing just this. It is not a hard problem. Even the article suggests that the rel problem is that the software may not properly reflect local laws due to ambiguities in the laws. If the title were "Ambiguous laws written by politicians can be codified", it would be a well accepted fact rather than a lie.

Re:My gripes with the first 2

[BasilBrush]

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.

Re:My gripes with the first 2

[TsuruchiBrian]

Obviously your function should be well documented and actually do what it says it will do. And if it's possible to ensure that a function can never fail, and can forcibly disallow NULL returns through some language construct, then by all means do that.

What *should* your function do, in the event that something goes wrong enough that returning a "normal" object is not possible.

For example: you need a function that loads an image from a filename and returns a bitmap. There are lots of things that can go wrong. You can fail to allocate enough memory. You can discover that the image file is malformed. You can fail to read the file.

There are many other ways of dealing with this problem than returning a NULL pointer in place of an object pointer, but depending on the language those other ways may not actually be much or any better. So I'm not saying that returning NULLs is always good. I'm saying that it might need to be adequate given the alternatives.

Re:My gripes with the first 2

[jellomizer]

Normally in SQL where I know Null to be a problem I set the default values in the table to a valid default for the datatype.
However nulls can be used as nice tricks but for the most part they get in the way as a null value puts your datatypes in a broken state and can work in mysterious ways.
In my previous job I was asked to give new hires a test. So in the area of their knowledge in SQL and in debugging I had some code that didn't work correctly because it was appending a null value to a string making the entire string null. I gave this question because with the data we needed to work with and the manipulation we normally do to the data this was a common problem.

Re: My gripes with the first 2

[Megol]

It isn't nonsense. Missing relationship is one interpretation of a null value but it isn't the only one. The big problem are the languages where a pointer can always be null however using null as a return value have real problems too.

Re:My gripes with the first 2

[AmiMoJo]

In C you often return pointers, so returning null is fine and you can return any error codes by reference or with a GetError() function.

What I do find kind of batshit are nullable bools in C#. At the very least it's not a bool any more, since it has three states.

Re:My gripes with the first 2

[lgw]

Your code must have a uniform way to signal errors. In Java/C# this is done by throwing an exception, full stop.

You can use exceptions, but exceptions come with their own problems that are worse than NULL pointers in many cases.

Unless you're talking about the performance implications in C++, that debate was settled last century. Exceptions are the right way to signal errors, because the problem of forgetting to check for errors is endemic. Exceptions translate "I don't handle errors" to "abort", which is obviously the correct translation.

In C code, the return value is consumed by the error code, and any values have to be returned by output parameters. If done this way uniformly, you can at least try to catch the places where people forget to check in code review.

Just returning "null" because you don't have a standard convention for returning errors is the most wrong answer. Null for a potentially expected case is different (like an object not found in a map) - then it actually makes sense, rather than being a hack to avoid error handling.

Re:My gripes with the first 2

[TsuruchiBrian]

My claim is that "null is acceptible" is not *always* a lie. *Sometimes* it is either the best solution or at least one of the better solutions, given the circumstance. I am not claiming that returning NULL especially in languages with better constructs to handle errors.

Unless you're talking about the performance implications in C++,

That is one of the cases, yes.

I did not mean to imply NULL be used as a hack to avoid proper error handling, and I will not infer that you are making this claim.

All I am saying is that in some very specific cases returning NULL may be the least (or one of the least) bad choices. You are still responsible for performing due diligence in exhausting the search for better options before settling on returning NULL.

The purpose of my comment was to maybe discourage people from choosing a worse option than returning NULL because of the "rule" that "returning NULL is always bad". It is important to understand the reasons for rules, so you have a better understanding of when they no longer apply.

Re:My gripes with the first 2

[lgw]

Sure, there are cases where null is semantically valid - it's not an error, but nothing was found. But folks shouldn't use it unless it's correct, as there's always a better way to signal an error.

Re:My gripes with the first 2

[TsuruchiBrian]

I guess it depends on what you consider an "error", which can depend on context. I am definitely more comfortable with the statement "Returning Null to indicate a catastrophic failure condition is unacceptable". I am currently unaware of any languages that do not allow you to abort ( or something equivalent).

The original article's problem with returning null, was the requirement to check the return value for NULL that is created. And yeah, I agree that's not ideal, but my point was that there is not *always* a much better alternative (i.e. *sometimes* it is acceptable).

Furthermore, there are ways of indicating an error other than returning NULL that still require a check equally as onerous(and easy to neglect) as a NULL check. So the problem isn't just returning NULL, but error-prone error-handling systems in general.

Re:My gripes with the first 2

[BasilBrush]

Absolutely, loading something from a file is a case where you would want to allow null returns, optionally also an error code.

But many other functions are either guaranteed to be able to return the correct value, or to have a suitable default.

My point is to know the difference, and only allow nulls when you have a good reason to. Never because of an ill-defined "there might be an error".

Null has to mean something. It should never be a vague possibility because "shit happens".

I don't think we have different opinions on this.

Re: My gripes with the first 2

[BasilBrush]

No one is saying nulls are always bad. What's being said is that nulls should never mean "indeterminate state". They should always mean something.

You say it's a missing relationship. But that's one example of a meaning for null. One that makes sense to someone who's doing database work all the time, or who thinks of object graphs as databases. It's certainly not the only use people make of nulls.

Re:My gripes with the first 2

[TsuruchiBrian]

I don't think we have different opinions on this.

I don't think we do either.

Catch

[Zenzilla]

I'll add some error handling to this catch statement later......

Re:Catch

[BasilBrush]

Swift helps a bit with this, in that it insists you either cover all possible values, or have a default clause.

Of course you can just leave the default empty. But at least that's a visual clue you missed the error handling.

"There are jobs for programmers."

[Anonymous Coward]

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.

Re:"There are jobs for programmers."

[Anonymous Coward]

1) Maybe you live in a bad place for tech.

2) Maybe you are overqualified. Most employers don't want to hire people with multiple advanced degrees...they want exactly one degree.

3) Maybe you are asking for too high a salary. It doesn't matter if your skill justifies it, what matters is what the employer is willing to pay for the job.

4) Maybe you have some kind of social deficit that makes you unemployable, despite your programming skill.

5) Maybe you have a criminal record, or a history of suing your employers, or other something that you aren't telling us about, that scares employers away.

6) Maybe you are simply too insistent that you get hired on your terms, instead of the employer's terms.

I live in Denver, CO. I have never had trouble finding a programming job. I think the highest number of resumes I have sent out before getting an interview has been about 6, and the highest number of interviews I have attended before getting an offer is about 3.

I think the problem here is you.

Re:"There are jobs for programmers."

[Anonymous Coward]

I forgot these:

7) Maybe the skills you have are not the skills they want. If they are asking for full MEAN stack developers, or full Microsoft stack, and what you have is C++, Cobol, Lisp, and extensive mastery of artificial intelligence algorithms...nobody is going to want to talk to you.

8) Maybe you are too old. Agism is rampant in the industry (illegal, but that changes nothing). Employers want young developers because they are cheap, put up with shit, are willing and able to be overworked, are less likely to retire without warning, and (it is believed) have a more modern skill set.

9) Maybe you have all degrees and no experience, and you are applying for senior-level positions or leadership positions. That's not how it works. Employers don't hire eggheads to lead a team of veterans who have actually spent time solving real-world problems. It doesn't matter how many degrees you have, you must pay your dues in entry-level positions just like everybody else.

Simple logic should make it obvious to you that an industry that generates so much buzz about big tech leaders pushing for programming education at every age level, and that has such issues with employers desperately trying to bring in talent from overseas, is one in which there are jobs available. If you can't find those jobs, it is not because the whole world is lying about the need for programmers, it is because you are doing something wrong.

Re:"There are jobs for programmers."

[lucasnate1]

8) Maybe you are too old

you are doing something wrong

All these stupid bums just choosing to be too old, to hell with them, right? They could have just chosen to be young instead.

Re:"There are jobs for programmers."

[StarryEyed]

Job listings ARE lies. Every decent tech job I've ever had was handed to me by a friend who already worked there. If I somehow got through the horrible interview process via the front door, the job was shit.

Re:"There are jobs for programmers."

[david_thornley]

FWIW, I was laid off once when I was 48, and had difficulty getting offers. I solved the problem by dying my hair. I'm now happily employed doing interesting things at a company I like (and, given the likely pace of corporate culture change at this particular company, I should continue liking it until retirement age).

Re:"There are jobs for programmers."

[micahraleigh]

(8) I'm surprised more people haven't mentioned this. Most devs leave the field by 35 because they are very afraid of it. But how real is it? The devs I know who are > 50 have to consult over long distances and are usually divorced.

I'll fix that later

[Anonymous Coward]

No. No you won't.

Sting operation

[Anonymous Coward]

What is this, some kind of sting operation?

Re:I'll just get this working...

[Anonymous Coward]

Are you fucking kidding me? I refactor just to break shit because my code works too well!! Tech debt my ass! If it's working right, it's got hidden bugs I just haven't fixed yet!!

Applies not just to programmers

[Ulfilas2000]

Those lies don't just apply to programmers, but also to mass media reporters:
(There is only one answer): Is it true you want to hurt the poor people by blocking the raising of the minimum wage?
(Numbers are accurate): The economy is doing great, the unemployment rate is only 3%!
(We're in control)...

Just a quick fix?

[PhunkySchtuff]

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

Re:Just a quick fix?

[asylumx]

Second that a million times! Possibly categorized as a we tell others rather than a lie we tell ourselves, though.

Re:Just a quick fix?

[david_thornley]

I always figure a change will take, at a minimum, half a day, longer when it's a fix to code in production. If I can find the problem in two minutes, and come up with a good fix in another two, I then have to compile, test, and go through code review.

Be open minded

[TsuruchiBrian]

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

Example:
"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."

Re:Be open minded

[imidan]

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 code.

Re:Be open minded

[Kjella]

What do you expect, it's like creating Linux software by writing a Win32 binary because you can run it in WINE. Regardless of the merits of XML, if the constraints demand that you produce it taking a detour through a different format certainly won't help.

Re:Be open minded

[Yunzil]

anyone who can't have zero memory leaks directly using malloc and free shouldn't be coding anyway."

This part is actually true.

Re:Be open minded

[imidan]

taking a detour through a different format certainly won't help

This was my objection to his idea, but I wasn't in charge. I think the guy learned to code from the Internet, and hung out on a lot of forums where XML is ridiculed, and he picked up his opinion there without ever understanding why. Everything he hadn't made was "needlessly complex." When we told him we had to adhere to the XML-based standard for I/O, he suggested that we create a new standard and then get all of the equipment makers to use it instead of the existing one.

At the time, I thought he was being stubborn for no reason I could see. I realize now he was just really, really green, and all this stuff that was needlessly complex was stuff that he was having a hard time understanding, and he found it easier to code up a simplistic replacement than to RTFM and understand there are reasons for the complexity of existing systems and standards.

Re:Be open minded

[TsuruchiBrian]

There certainly is some truth to it, but it is a bad argument against mechanisms that prevent mistakes.

Unfortunately, everyone makes mistakes. This is why such a huge amount of software development effort is put into mechanisms preventing human errors that would otherwise have occurred. It's not like these mechanisms are just for the bad programmers, and Knuth and Dijkstra don't need to use them. It also frees human time for real problem solving that would have otherwise been spent bug hunting.

Re:Be open minded

[nasch]

Do you think there are not very many programs* with memory leaks, or not very many programs written by people who should be coding?

* written in an unmanaged language

Programmer lies:

[buss_error]

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.

This will be easy..

[Anonymous Coward]

Enough said.

Mindests aint mindsets

[enrique556]

"This framework I'm writing will make it easy for new programmers to understand and modify the system."

Women even better off in industry

[SuperKendall]

I calll bullshit. There's a HUGE difference between positions in education and in industry and commerce.

Outside of the educational community, the desire for companies to hire ANY technical women is massive. You can for sure gat an interview at any tech company if you are a woman. You will be 99% sure to be made an offer if you are at all competent (and sometimes even if not, the power of quotas).

I have a friend with a daughter who is a CS major, and she was offered extremely well paid internships with a large signing bonus at every single company she applied for (ten or so I believe). She is pretty skilled but currently only in Python.

I say that not to say it is negative but just to speak the truth about how things are, because so many seem to think it hard for women to find tech jobs once they acquire skills and they are scaring away young women from a gold mine with a very rich vein.

To be frank it's not hard for any competent male to find tech work either, but loads of large companies have diversity quotas and they are absolutely desperate to fill them which gives women a huge advantage...

Note that his ease of hiring is utterly separate from the conditions they may find once working there. Outside of Silicon Valley women are usually treated well and as equals, in most California companies they will probably face horrific abuse and discrimination (which is where the myth that tech women are mostly mistreated in companies comes from).

Re:Women even better off in industry

[Anonymous Coward]

To be fair, handing out jobs to women for being minimally competent doesn't really sit well with people that earned their position with years of effort. It harms women, especially the actually competent ones that also put in the work. It fosters an atmosphere of "she only got the position because she's a woman" which is absolutely unhealthy but in a world where that actually happens it's not unreasonable to feel that way either.

Re:Women even better off in industry

[squiggleslash]

Outside of Silicon Valley women are usually treated well and as equals

Meh, I've witnessed awful treatment of women in the industry and never worked anywhere near SV.

Remember that stat, that 25% of women in colleges have been sexually assaulted? How initially it seems unbelievable because, hey, you wouldn't, and I wouldn't, and most men you know wouldn't, so how can that be?

The reason it's likely true is that it doesn't a huge proportion of men to be assholes for a disproportionate number of women to be affected. If, say, 2-5% of men in college think it's OK to touch women inappropriately and non-consensually in environments in which they can get away with it, and you assume each of them gets away with it, and so assaults multiple women, then, wow, you're up to 25% of college women being sexually assaulted pretty quickly.

And the same is true in businesses. Leaving aside institutional and structural problems - which exist everywhere - it doesn't really take a lot of male employees to be assholes, showing a level of disrespect for women they'd never show to men, for women to be disproportionately affected.

One office I worked for had such a person. As in every male member of the programming team knew he hated women, and that the extremely qualified, hard working, smart woman working with him was being treated like shit solely because she was a woman, and neither young nor blonde enough to make him at least be chivalrous to her as compensation.

To my and my coworkers shame we never did anything about it. We didn't talk to him about it, we continued to treat him as a - distant, perhaps - friends. We didn't talk to management about it. "G is strong", we told ourselves, "She doesn't put up with his bullshit", and, well, yeah, but bullying is bullying, and working in that environment wears down the strongest of all of us.

It's getting a lot of press in SV right now because SV is the hub of the tech industry, and has sizable number of progressives involved in it. But the idea it's limited to SV is absurd, that'd be to assume either that base human behavior (because there'll always be sexism) somehow is under control elsewhere, or that management skills have developed to a remarkable level outside of SV.

I work for a good company

[ohnocitizen]

• 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

Re:I work for a good company

[david_thornley]

I knew a guy who liked to keep a pile of his stock options for amusement value.

Skip The Article

[StormReaver]

You can safely skip the article without missing anything. I stopped reading after, "Relationships Can Be Codified" because I realized that the author of the article seems to have very limited programming and design experience. All of his examples up to, and including, that point are elementary issues with simple solutions.

Re:Skip The Article

[jellomizer]

For the most part the point of the article wasn't as much of the technical lies but the fact that programmer often code themselves into boxes. Relationship mother father wife husband can quickly cross gray lines with divorce, remarried, widowed, adopted, same sex marriage, gender identity...
So often programmers will program hard coded what they know. If they are better skilled then they will make a look up table. If they are really fancy they will make some adaptive control for self maintenance of the value. Then as the relationships may change it is what to do with the historical data.
I have been coding for 30 years. And often I will get in arguments with newly grads and college professors (normally the ones who's career was entirely in academia) when they see that I written some less than efficient overly complex code for something easy. E.g. Why did you create a gender table and just populate Male and Female and the keys? Just code the drop down box with the values it will save on loading time. Then after release we get a request to add additional values such as trans genders so all I need to do is tell the customer to edit the lookup table and I don't have to go to all the forms that ask and show the value. Add the value, recompile make sure the code is merged in future development tested...

Re:Skip The Article

[Greyfire]

Wish that had been said earlier. Heck, he even makes a case for abandoning Macs, and I don't think that's something he intended.

My manager would never post on Slashdot just to...

[engineerErrant]

...get some ammo to discredit my point of view in our next meeting.

That is just an edge case.

[sabt-pestnu]

Nobody will ever do that.

Lies!!! Damn Lies!

[ogdenk]

"The company cares about my well being and if I work 80 hours per week to complete this project I've poured my heart and soul into, it will all pay off in the end and I'll be a well paid rockstar and get my fair share!"

"Shareholders really care about me and appreciate my hard work."

It will be better if we start from scratch

[albeit unknown]

If we completely rewrite this old, messy, patched-up code, the new code will be better-architected, well-documented, and bug-free.

Re:It will be better if we start from scratch

[david_thornley]

I had a very good friend working on a system running on a baby IBM, and the new CTO decided to rewrite it in Java and run it on WIndows. I got to hear all about it.

Coding is a profession with a long term future

[Required Snark]

also described as: "I can keep working as a software developer as long as I want to".

Re:Coding is a profession with a long term future

[swillden]

also described as: "I can keep working as a software developer as long as I want to".

I dunno. I'm almost 50 and work with guys who are in their 60s. That's definitely as long as I want to work.

Re:Coding is a profession with a long term future

[david_thornley]

I am in my 60s, and see no reason why I can't continue to work for something under two more years until I retire, which by definition is as long as I want to.

Re:Coding is a profession with a long term future

[micahraleigh]

What stack ?

Re:Coding is a profession with a long term future

[swillden]

What stack ?

I've done a lot of things. I've somewhat specialized in security of the cryptographic sort, but I've done embedded work, web sites (LAMP, J2EE, other stuff), networking (network drivers, worked on a reverse proxy, even wrote a TCP stack back in the day), point of sale systems, and a lot more. These days I work on Android, but that may change in the next year or two.

Re:Coding is a profession with a long term future

[micahraleigh]

Cool! Thanks. That speaks to several things I've been turning over in my mind.

Re:Coding is a profession with a long term future

[swillden]

Cool! Thanks. That speaks to several things I've been turning over in my mind.

YW. Note that I think the industry has changed a little, and I'm not sure that being a generalist is practical any more. Which isn't to say that you shouldn't know about a lot of different things, but there's value in being expert in one field. Note I said one field, not one technology and especially not one tool. Being expert in one tool is great in the short term while that tool is in demand, but it's also a good way to get left behind. Oh, and you have to expect that you'll constantly be learning new stuff for your entire career.

My bottom line, though, is that if you're smart and have an actual interest in software technology for itself, rather than just as a profession, you can develop software for as long as you want to. At some point you'll run into a compensation ceiling, and breaking that requires moving into a different sort of role. But... the ceiling is pretty high if you find a company that values you. And you can make it even higher if you go independent, though that comes with considerable risk.

Re:Coding is a profession with a long term future

[micahraleigh]

That's encouraging to hear, and the generalist/specialist feedback is insightful.

Database lies

[devnullkac]

Seems like the article is mostly lies that database programmers tell themselves.

Forever

[devnullkac]

Here's one of those not-what-you-expect lies that you learn you're telling yourself after a year or so: This code will be used everywhere forever. It will be totally worth it to make it super flexible and super maintainable.

I need more coffee

[avandesande]

EOM

no comment

[Jaegs]

"The purpose of this line of code is pretty self evident. There's no need to add a comment about its function."

I only surf the web while compiling

[Snotnose]

Along with "I never start a compile because I wanna surf the web".

sigh

The best in town learn from the best in the world

[raymorris]

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.

Structure by indentation is a sensible approach

[thesjaakspoiler]

.... if you haven't worked with any other decent programming language

Easy to understand, use, modify

[myid]

My app is easy for a non-technical person to understand and use.

My code is easy to understand and modify.

The receptionist totally digs me.

[tgrigsby]

She's probably thinks intelligence is sexy.

This app...

[HockeyPuck]

This app is gonna make me millions...

Biggest programmer lie: "I'm an engineer" (nt)

[Brannon]

nt

Re:Biggest programmer lie: "I'm an engineer" (nt)

[mwvdlee]

Isn't that a big lie for every engineer except for the people running steam engines in old trains and boats?

Re:Biggest programmer lie: "I'm an engineer" (nt)

[serviscope_minor]

No:

http://www.etymonline.com/inde...

Re:Biggest programmer lie: "I'm an engineer" (nt)

[mwvdlee]

Ah okay, so according to that site a software engineer IS an engineer? Unless of course only civic architects and/or war-machine makers are to be considered engineers.

The point I'm trying to make is that the idea that a sofware engineer is not an engineer is just a case of marking one arbitrary point in time in the long chain of an ever-changing definition of "engineer" as the only, absolute and final definition of that word. Whereas most of the people claiming such, work in fields which also didn't exist when the word "engineer" was first used.

Re: Biggest programmer lie: "I'm an engineer" (nt)

[Hognoxious]

That's unfair. Some of them are good at one of those things and almost competent at one of the others.

Never say never

[b1ng0]

This condition will never happen

I can get this...

[FrozenFrog]

...simple program done on time, on budget, and with no bugs.

Well, *I* know what it means ...

[petes_PoV]

Not mentioned yet:

* Every user speaks my language (so my text can all be ASCII), So Y and N are always fine. So everyone's address includes a city.

* It doesn't matter that error codes are meaningless, or that the same catch-all message appears for several different conditions.

* Every user will know what "enter a 6 character alphanumeric field" or "please assign a unique key" means

* Using technical jargon in user interfaces is good, Plain English is for WIMPS

* it doesn't need documenting, it's obvious how to use it.

* The website doesn't need a description of the product, everybody knows what it is
(So let's make the first page a user will encounter a list of the change log, or a name-check for everyone who worked on the project, instead)

Bigger lies

[Brett Buck]

" I can write a Python script and get grandma's printer to work, so I am a genius in all areas of life, particularly politics"

The project will be done on time

[s1d3track3D]

see subject

// TODO

[El_Muerte_TDS]

or the alternative: // FIXME

demo code

[rastos1]

"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.

Re:demo code

[MadKeithV]

In my career I've had a couple of instances where I've requested management to actually put down in writing that what we were developing was a "prototype", with the stipulation that "prototype" means that after it's done and it has proven the concept, *all the code* gets thrown away and we can start over.
Because every single time you don't, the end result after the prototype presentation is "oh, you're 90% of the way there, it'll only take 10% of the time you've already spent to finish it!".

Re:demo code

[david_thornley]

At a couple of places I worked, we had something like a strategic development unit that would basically write a proof of concept and throw it over the wall to Development, and we were expected to turn it into something production-ready. This didn't necessarily work.

Re:demo code

[TeknoHog]

Also: I'll just hack up something quickly so the rest of the team has something to work with. I'll rewrite it properly later.

This actually comes from my experiences as a theatre tech guy, mostly relating to lighting design. I think it applies quite generally to projects where several people work in parallel, initially with little interprocess communication but increasingly interdependent until the grand premiere. The actors and the director will need some lights to get started, but I also need to see some action before doing the final design. The trick is making that initial quick hack good enough, so you never have to redesign from scratch, and I guess that takes some experience.

Planning

[mwvdlee]

"I've been planning badly for decades and know to double my estimate; this time my planning will be close to the truth".

So is Poettering, and me, and a million others

[raymorris]

> I am the best developer for my domain.

For an sufficiently narrowly defined domain, so am I. Then again, so is Lennart Poettering.

Eric S. Raymond is a far more accomplished developer than I am. It is good for me to remember there are many, many far more accomplished, and many who are just plain more knowledgeable all around.

I happen to be, or once was, the best in the world at protecting paid web sites from unauthorized access. I was a longtime member of many cracker forums, and got a certain amount of respect because I had been around for many years and knew the ins and outs of the various security systems. Little did they know I was a spy, that the most senior member of their community was there to surveil them and feed them misinformation. So I was the best at my particular speciality, but plenty of people are better than me in much larger, more general domains. Being the best at one very specific thing doesn't make me good, it makes not versatile.

Re: So is Poettering, and me, and a million others

[Zero__Kelvin]

Which reminds me ... "I happen to be, or once was, the best in the world at protecting paid web sites from unauthorized access" is another one I've heard ;-)

My current situation

[MonoSynth]

"I fully understand the problem"

later

[Tom]

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

I'll fix this later.

Usually...

[nospam007]

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

This bit made me laught

[Chrisq]

They [the Unicode consortium] also toss aside certain emoji, effectively denying someone’s feelings.

Because nobody ever felt anything before there was an emoji for it.

Here is another one

[master_p]

"functional purity creates less buggy code".

I can trust the compiler.

[Ihlosi]

I can trust the compiler.

I can trust the libraries I use.

I can trust the linker.

I can trust the hardware the code runs on.

Re:Agile

[Ihlosi]

We are agile here.

What is this "we" you speak of?

I am agile here.

But ... but ... but ...

[Ihlosi]

... I have two engineering degrees!

Oh.

I get it.

That means I'm not a programmer.

Re:But ... but ... but ...

[n329619]

Graduate with a Bachelor of Science.

I must be a scientist!

Bachelor of Science in Religion.

Close enough.

"The customer will not want the bug back."

[Ihlosi]

Most ironic of situations. You fix a reported bug, and shortly after get reports from customers asking for the bug back.

Documentation

[GerryHattrick]

"My code is self-documenting, I need do no more."

"I can find my own bugs."

[Ihlosi]

No ... you usually can't. Unless you don't look at your code for six weeks, and then read it and wonder what exactly you were thinking.

I will fix it tomorrow/next iteration/sprint

[umghhh]

or another one I really love "this will never happen (so I do not have to prepare for that)".

I don't need a union

[MrKaos]

I will be able to adapt to the legal environment, I'm a great negotiator, someone will lobby the government to look after my interests, that aside they really need me.

Someone has my back

MM/DD/YYYY

[deburg]

"Everyone uses the American Date format, that is MM/DD/YYYY", 'nuff said

Re:MM/DD/YYYY

[jez9999]

Seriously, why did you guys start doing that? Can't you see how illogical it is? It makes about as much sense as CRLF.

Re:MM/DD/YYYY

[michael_wojcik]

A thousand times yes. Or they use the US order with hyphen separators, increasing the confusion. Or they mix formats in the same application. Just the other day I was dealing with a web page that used MM-DD-YY and DD-MM-YYYY for different fields.

Sometimes I think ISO 8601 should be required by law. Everywhere.

(Of course, I'd also like to see everyone required to use UTC for all non-specialty applications. What do I care if the sun reaches its zenith locally at 17:00 or 19:00 rather than 12:00?)

Re:MM/DD/YYYY

[david_thornley]

Like DD/MM/YYYY is any better. The only good order is the ISO one, YYYY followed by MM followed by DD, optionally followed by the time.

Re:MM/DD/YYYY

[codeButcher]

Hmmm, and everyone has a name and surname (and in that order).

Re:MM/DD/YYYY

[angel'o'sphere]

It would be actually interesting how that date format evolved, because in my opinion it is the most retarded one and has nothing to do with how you would write it as in "Monday, the thirteenth of January 2017", or "say it" for that matter.

Any ideas?

Re:MM/DD/YYYY

[jez9999]

It's objectively better because it's in order: short -> long.

This will take 10 minutes.

[Rufty]

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.

Sad, but true

[SCVonSteroids]

Almost all the +5s I've seen are the excuses (not lies) that I hear from the less competent and/or lazier workers. (Note, I said workers, because this doesn't only apply to programming)

I'm going to attack on the "deadlines" ones specifically though because it hits home the hardest for me. I've had deadlines where everyone around me, seniors et al, laugh and say it's impossible, and I just think about it a bit and go "Gee, if we all were actually collaborative and proactive about it, we'd actually achieve that deadline without much stress."

Then I realize those same people spend half their days either chatting with others or tackling problems in a grossly inefficient manner. This isn't always the case, obviously, but you need someone who gets annoyed and takes the reigns when it does happen. I tend to play that role, but I also almost end up burning myself out and morph into one of those lazier workers in turn. Not fun.

tl;dr? Too early in the morn to summarize, read it or move on.

Re:Sad, but true

[asylumx]

Almost all the +5s I've seen are the excuses (not lies) that I hear from the less competent and/or lazier workers.

In addition to that, they are almost all lies programmers tell their coworkers, not lies they tell themselves.

Even worse:

[Ihlosi]

"C++ and C are quite similar."

Actually...

[zedaroca]

There is nothing wrong with Java.

That stripper

[sabbede]

really liked me!

Favorite programmer self-delusion

[Mister Mudge]

That's an edge case - it won't ever happen in the real world!

Re:The best in town learn from the best in the wor

[Dog-Cow]

Perl actually has excellent documentation, written by the the authors/developers of the language.

The big lie:

[johnnys]

"Those security guys worry too much!"

I'd be filthy, stinking rich if I had a dime for every time a developer made the same well-known security mistake over and over and over even after their code was pen tested and it was pointed out to them with a fully documented POC and screenshots.

null?

[baadfood]

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.

Re:null?

[ath1901]

I didn't get the thing with nulls either. Maybe it's a Java thing. I vaguely remember such issues with Java since there are so many pointers and object allocations. If you forget just one, there's a null pointer exception waiting to happen. I suppose the lack of explicit pointer syntax might also help / make it worse since you may think about your variables as values and not as pointers.

It doesn't happen in C++ as much since you use heap allocated values more often and perhaps pay more attention to dynamic allocation, when it happens. I have accidentally created null pointers of course but it really isn't a major concern.

in Python, it's even less of an issue even though it should supposedly be a bigger issue since any pointer can point to any value, not just nulls. My guess is that the ease of writing unit tests more than makes up for whatever is lost from not having static type checking. Static type checking can't detect accidental nulls anyway but unit tests can.

Having said that, yes, I do hate nulls and I try to avoid them as often as I can. An empty string or empty list is often a better "empty" value than a null pointer.

Maybe avoiding Java and replacing nulls by empty values is enough to not consider them a menace.

Javascript is not THAT bad.

[TheSunborn]

Javascript is not THAT bad.

(This lie is the only way, I can continue work).

Object relational impedance

[ramirodt]

"Our model changes too frequently, we can't use a relational databas, only JSON will be as versitile as we need". Lies...

Re:Object relational impedance

[SharpFang]

Well, we don't happen to have money to hire a database designer, to invent the SQL queries that would do what 20 lines of Perl over JSON file can do.

Actually, we do use the relational database, except for the most wildly varying entries, there's a text field, which contains the JSON objects. I mean, if the field "measurement" may be an int, a float, an enum, an array, an array of arrays of variable length, containing int, float, NULL or NaN, or a structure composed of a string and three booleans, yeah, that can be normalized into a bunch of tables, and queries for these can be written, but... seriously, why?

What makes an engineer in the US?

[opentunings]

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)

- once you're licensed, then you're an engineer, unless

- the state finds out that you aren't following the state's (electrical / civil etc.) code regulations and pulls your license. Then you're no longer an engineer. And by the way, good luck finding your next job.

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. For example, a plumbing engineer can spec out either a Moen or a Delta faucet for a design. Could a Cisco engineer spec out a Juniper switch? Maybe...or maybe not.

When I was getting my degree (90's) the ACM wrote about the issue of whether software could truly be called "engineering" or not. Two things that they pointed out were that (1) in a couple of US states, it was illegal to call yourself a software engineer because you weren't licensed by the state, and (2) a lot of mechanical etc. engineers are pretty PO'd at the software industry because any fool can call himself / herself a software engineer without having skills, practices or state certs to back it up. Both point to a level of respect and trust in the skills of the person who puts "engineer" in their title. Would you go to a doctor who didn't have a state license? Or use a lawyer who wasn't a member of the state's bar? Probably not, because you don't know if you can trust their skills. A state's "engineer" stamp is a similar scenario: "this person is trustworthy in their trade and their opinions deserve respect."

Re:What makes an engineer in the US?

[swillden]

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 by which to judge whether an individual merits the label.

Re:What makes an engineer in the US?

[russotto]

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 different course than it did, or had a different standard for professional supervision, you might be fucked.

When I was getting my degree (90's) the ACM wrote about the issue of whether software could truly be called "engineering" or not.

ACM broke with the IEEE over the issue of whether a professional engineering licensing program for software was appropriate; ACM felt it was not while IEEE felt it was.

A lot of P.E.s are certainly butthurt over the fact that others call themselves engineers without being P.E.s. Too bad on them; train drivers were called 'engineers' long before there was a P.E., and those who built and operated siege engines were 'engineers' long before that. I don't see why we should cede the term to Johnny-come-lately stick-in-the-mud State-worshipping credentialists like P.E.s

Re:What makes an engineer in the US?

[Dixie_Flatline]

My definition of 'engineer' includes 'legally responsible for the work they do', which is what happens with P.Engs in Canada. I don't know how it works in other places, but an engineer signing off on something means something. I have no legal liability for my code and I make no guarantees to anyone about it. (Keeping in mind that I'm a game programmer so, y'know, whatever.)

Re:What makes an engineer in the US?

[sjames]

You're speaking of a PE. Indeed, software engineers are not PEs (unless they pursued a dual career, of course) nor are they required to be. Many engineers are not PEs. You may not claim to be a PE without going through the whole process.

I can do this in two hours

[kbdd]

Most frequent lie I tell myself or others.

Re:One in a million is rare. One in a billion is n

[DickBreath]

1 is prime. 3 is prime. 5 is prime. 7 is prime. 9 is simply experimental measurement error. 11 is prime. 13 is prime. . . .

Manager: how do you measure leadership?
Programmer: with a suitable test insturment!

Re:Stuart says...

[DickBreath]

"I have excellent social skills."

Overcommenting is good

[SlideRuleGuy]

Many mentioned under-commenting, but don't forget the waste that is over-commenting. I want to scream every time I see a function (e.g., a graphics function) that takes two variables, x and y, and someone took the time to comment those as "the x coordinate" and "the y coordinate". No kidding!!! Or if you're using ghostdoc, they get commented as just "the x" and "the y". When the best comment you can come up with adds no information, just skip it. Over-commented code is not better in any way.

Customers' firewall will protect them

[doggo]

"Eh, it's secure enough. They've got a firewall, right?"

Easy

[jon3k]

"I can finish that in a week."

ugh

[FirstNoel]

The Users will never do that.
My code doesn't need documentation

Estimates

[HellYeahAutomaton]

"I can do this in two weeks."

After the 4th release

[mr.witherspoone]

It's only a demo ....

From a QA perspective....

[Lordfly]

"Hey, it works on my machine"
"This doesn't even really need testing."
"Users will never use it that way."

Re:From a QA perspective....

[OrangeTide]

"Hey, it works on my machine" is a valid troubleshooting step. It's good to find out why QA's environment is so fucked up compared to my dev environment. And in some cases it works in the release team's environment and my dev environment but QA is escalating their configuration troubles as show stoppers. I'm happy to help as soon as the finger pointing and assumptions stop.

Re:From a QA perspective....

[david_thornley]

"Hey, it works on my machine"

That's not necessarily a lie. I've had it happen twice. Both times it was a real pain because I couldn't debug on my machine.

"Users will never use it that way."

Now you're hitting one of my sore spots.

Full Stack DevOps Engineer

[DougWare]

That they are a "Full Stack DevOps Engineer". When I hear that I die a little inside.

"I'll be ready for extensions."

[SharpFang]

"If I write this program in an easily extensible way, expanding this later will be a breeze."

Lots of classes, rich inheritance trees, broad project on top of a robust framework, making adding extra modules fairly easy. Your program is clean, well-documented, and has a logical structure, all according to best practices. It's also about 4 times bigger than it would really need to be, it takes 3 times as much RAM (primarily due to loading all the neat frameworks and libraries that you used "not to reinvent the wheel" even if you only use one or two simple functions from these), but who cares, this is the modern paradigm, and everything is automated and works so smoothly you can be nothing but proud of it. Now just to support it, fix some bugs, and implement extra features.

Then the new requirements arrive, you look at the email, you look at the top level schematics of your system and you realize, with a sinking feeling, that you never imagined the system would need to be expanded *that* way. And that this particular framework doesn't support this approach, and never will, because its authors decided they never plan to support it, or that the target platform doesn't support, and can't ever support the kind of libraries you use, or that you currently depend on a piece of hardware to do a job which you will need to write from scratch, or the new legal requirements (which are not disputable; new law says so) go completely against your system philosophy, which provides equivalent but completely different functionality, or the essential library just has been discontinued, and new security holes have been found in it...

Or at the very least, you realize that a feature that amounts to ten lines of code performing a really simple tricks requires you to create ten different files, two thousand lines of code, config and extras, and modification of several existing files, because the way the extensions of this type are applicable is writing a plugin which is a separate project with a whole non-trivial instantiation of framework, build system, security, and compatibility with your smart dynamic plugin loading mechanism. What would amount to pasting a 12-line function called once per tick from the main loop, amounts to a three-week project building the plugin/wrapper for that 10-line snippet.

You CAN NOT foresee future requirements. You CAN NOT plan all possible future extensions ahead of time. And the more you plan for, the more "flexible" you try to be, the larger and more rigid your project becomes in areas you failed to foresee, and the harder it will be to adapt it for these.

Yes, leave hooks for stuff you have it on a good authority WILL happen. Do not try to plan for every eventuality though. Write good clean code that does what it's meant to do, and doesn't try to be ready for anything else. It will be *easier* to expand once the time comes.

hmm

[Wuhao]

"This time will be different."
"A rewrite will fix everything."
"This will make it future-proof."
"I'll go to bed after I write this last part."

Why spread lies??

[SuperKendall]

Remember that stat, that 25% of women in colleges have been sexually assaulted? How initially it seems unbelievable because, hey, you wouldn't, and I wouldn't, and most men you know wouldn't, so how can that be?

And then you found out that it was unbelievable because it was a lie?

One office I worked for had such a person

Nothing helps a lie along like a nice little one-off anecdote, am I right?

But the idea it's limited to SV is absurd

It's not limited to SV but it's rare outside of there. In SV it is pervasive. If I were a woman I would stay far away from SV if I valued my mental health. There's plenty interesting stuff going on outside of SV, and then you also avoid being in a huge bubble of groupthink that has fifty Snapchat clones getting funding.

But if you are a women and want a lot of money, suck it up and take SV for all they are worth. After 5-10 years you could probably retire for life if you play your cards right and change companies often enough.

Re:Why spread lies??

[david_thornley]

Your cite doesn't say that the 20% figure it mentions is a lie, but rather that the study the statement was based on had seriously flawed methodology, and that we really don't know. I find it entirely plausible that 20% of women may have been sexually assaulted, defining "sexual assault" as "an action that would be illegal according to the Minnesota Criminal Sexual Conduct statutes", but I have no real way of knowing what the correct figure is.

Re:Why spread lies??

[BarbaraHudson]

All I can say is that the majority of women I know have been sexually assaulted on one or more occasions. The figures are probably under-estimated, but this is over the course of a lifetime, not a 3 or 4-year university stint. Still ... (and that's not counting stalkers and other creepy crap).

Accountability and CYA

[Ukab the Great]

"When someone above asks me to do something I know will be problematic, they will ultimately take responsibility for that decision and will not use me as a scapegoat to protect their own ass when the shit hits the fan. And even if they were to do so, my reams and reams of CYA documentation that document their ridiculous decision will serve as a magic talisman that prevents me from getting fired."

Doesn't harm women, harms respect for women

[SuperKendall]

To be fair, handing out jobs to women for being minimally competent doesn't really sit well with people that earned their position with years of effort.

For sure, they get annoyed.

It harms women

But here's the thing - it doesn't harm women. It harms people's respect for women as competent developers.

But think of it from the standpoint of the woman. Were I a woman, and people thought I was incompetent because of diversity quotas, I would laugh and wave my arms wildly in my pit of extra money I was making.

Respect of others is only valuable when you can use it as leverage to get things like jobs you enjoy. But currently being a woman has far more leverage in getting hired at technical jobs than does respect or competency. So why care what people think about you?

Plus honestly in the end after a while people will respect you for what you have done anyway, no matter what they think at first. So it's not like I'd slack off if it were me, thinking about it from a very long term standpoint, not to mention maintain an internal measure of respect which is important for a strong feeling of self-worth.

There are 60 seconds in every minute

[OrangeTide]

Oh shit, what's a leap second?

Re: Biggest programmer lie: "I'm an engineer" (nt

[Zero__Kelvin]

Of course what you say is true! There is no way I could have experience with all of those things in a mere 30 years! If someone has 5 or 10 years in the field you might have a point, but beyond that a truly talented Dev will have experience in all of that as well as virtualization.

Start at the top

[tchdab1]

"I love my job."

We'll always have jobs

[SoftwarePearls]

Programmers think that their jobs will always exist.. I think we've got another 20-25 years before the bulk of programming jobs have vaporised in the face of AI.

Re:We'll always have jobs

[russotto]

Programmers think that their jobs will always exist.. I think we've got another 20-25 years before the bulk of programming jobs have vaporised in the face of AI.

And another 5 years after that before the bulk of humans have been vaporized by the AI.

My card has said "Computer Scientist" for 25 years

[mpercy]

Just so I never bumped into those legal issues. Before that it was "Systems Analyst". We use "Software Developer" for the same reason, and it covers a lot of ground.

Cannot reproduce the fault

[safetyinnumbers]

So "the bug just went away by itself".

Re: The best in town learn from the best in the wo

[Jason Levine]

I am the best developer for my domain.

I'm the best there is at what I do, but what I do occupies a narrow niche.

Re:One in a million is rare. One in a billion is n

[TeknoHog]

It's funny because 1 isn't really prime.

(It may have been prime according to some old definitions, but not any more. Factorizations are not unique if we include things like 2*3, 1*2*3, 1*1*1*1*1*2*3, etc. so it's better to leave out one.)

The customer will stick to the script

[lcllam]

'Requirements? No worries - just build it first, and I'll give you my feedback.'

I hate these two:

[WetCat]

"Mathematics is an exact science"
and
"Miracles do not happen"

Performance Problems?

[Agripa]

I do not need to worry about cache organization.

Language barrier

[Jetty Jetty]

I've heard it has to do with the language barrier overseas. Director's and contractors here want to be able to describe the type of work they want done and the best way to do that is in the English language they're used to. Communicating that with a programmer from India presents a challenge and so for that reason a well spoken English-as-a-first-language developer can usually be paid better.

A really fat lie

[dddux]

"Users won't notice". ;) Oh yes we do.

Security

[ebvwfbw]

The firewall is keeping my program from running.
I'll add security later.
The security routine is stopping it from working.
Let's disable SELinux, then it'll work.
I'll just su to root to delete these files. I'm not really in /dev.

Others:
I don't need to test this code.
VI is a good editor.
Ruby is a great language.
Java is a great language.
I don't need to worry about freeing memory. Modern systems have more memory than we'll ever use. (java actually does this last I knew).
I don't need to worry about metadata.

My favorite - "Things will naturally just work out."

It's just a short term fix...

[pepik_knize]

"Short term" means 5+ years minimum. MINIMUM.

"But..."

[Krokus]

"...I didn't change anything!"

One day JavaScript will cease to exist...

[TheOuterLinux]

(Deep scifi narrator voice or Morgan Freeman) IN THE YEAR 2000, all audio and video will be ogg vorbis. All documents will be in an open format. Micro$oft will be no more. Artificial Intelligence will be our friend and not the privacy cracking monster it's always been since the 1940s. Cloud computing becomes easy for everyone to do and not just a farce for Silicon Valley to use open source to destroy open source.

reuse

[wateringcan]

We'll definitely be able to reuse this module in our next product, no hacks or shims required.