Testivus On Test Coverage

Early one morning, a programmer asked the great master:

“I am ready to write some unit tests. What code coverage should I aim for?”

The great master replied:

“Don’t worry about coverage, just write some good tests.”

The programmer smiled, bowed, and left.

...

Later that day, a second programmer asked the same question.

The great master pointed at a pot of boiling water and said:

“How many grains of rice should I put in that pot?”

The programmer, looking puzzled, replied:

“How can I possibly tell you? It depends on how many people you need to feed, how hungry they are, what other food you are serving, how much rice you have available, and so on.”

“Exactly,” said the great master.

The second programmer smiled, bowed, and left.

...

Toward the end of the day, a third programmer came and asked the same question about code coverage.

“Eighty percent and no less!” Replied the master in a stern voice, pounding his fist on the table.

The third programmer smiled, bowed, and left.

...

After this last reply, a young apprentice approached the great master:

“Great master, today I overheard you answer the same question about code coverage with three different answers. Why?”

The great master stood up from his chair:

“Come get some fresh tea with me and let’s talk about it.”

After they filled their cups with smoking hot green tea, the great master began to answer:

“The first programmer is new and just getting started with testing. Right now he has a lot of code and no tests. He has a long way to go; focusing on code coverage at this time would be depressing and quite useless. He’s better off just getting used to writing and running some tests. He can worry about coverage later.”

“The second programmer, on the other hand, is quite experience both at programming and testing. When I replied by asking her how many grains of rice I should put in a pot, I helped her realize that the amount of testing necessary depends on a number of factors, and she knows those factors better than I do – it’s her code after all. There is no single, simple, answer, and she’s smart enough to handle the truth and work with that.”

“I see,” said the young apprentice, “but if there is no single simple answer, then why did you answer the third programmer ‘Eighty percent and no less’?”

The great master laughed so hard and loud that his belly, evidence that he drank more than just green tea, flopped up and down.

“The third programmer wants only simple answers – even when there are no simple answers … and then does not follow them anyway.”

The young apprentice and the grizzled great master finished drinking their tea in contemplative silence.

Found on stack overflow https://stackoverflow.com/questions...

Yeah, fuck gravity xD

"Documentation is like sex; when it's good, it's very, very good, and when it's bad, it's better than nothing." - Dick Brandon

Food for thought

Invent punch over ip protocol (POIP)

Some people just need that sort of thing

Tips for all the programmers out there:

- A programmer is not a PC repair man, just no one seems to remember about that

- Programming is thinking, not typing.
Counting starts from zero, not one.

- Even after completing a degree and courses and working on IT projects, learning never stops. If you want to stay competitive you should also work on personal projects that force you to use languages and software you never work with on the job.

- You don’t need serious math skills to be a developer. However, you’ll need basic algebra, logic, strong problem-solving skills, and most of all, patience.
- You don’t need a degree to be a developer - programming is like almost any profession: if you’re good at it, people will pay you for your skills, regardless of how you got there.

- Sleeping with a problem, can actually solve it.

Exiting Vim!!

❤C♥O❤D♥E❤

Programming fact....

My working style in a nutshell...

Every time....

If you have some troubles with some errors/bugs:
Never underestimate the power that a short break from coding can give you

Looking for a bug.

Plugged headphone into my ears.

Suddenly part of code caught my attention, started debugging.

10 minutes of intense debugging, wondering why there's no music in my ear.

Realised I forgot to plug the headphone into my mobile :(

In case of Fire

Git Commit
Git Push
Exit Building!

There are in fact three unique Boolean values.
Their names are "true", "false", and
java.lang.NullPointerException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
...

Get a ticket for a low priority bug, reported internally. Fix the issue mentioned in the bug.

Moves to QA environment, the original bug reporter tests and *passes* the ticket.

Moves to Staging environment, same exact individual then *fails* the testing. Cites totally new/unrelated changes that need to be made.

Apparently our the workflow is -

Code->QA->Staging->Requirements

Makes sense! :)

True..

When code runs without bug and whole team is like...

Client: "Can you move this to a little bit there"

Me: "okay, have a look"

Client: "Meh, Can you make the text a little like ${x}"

Me: "There you go"

...this goes on for 10 minutes...

Client: "Meh, I like the original better. Just scrap everything and switch to what you had"

Me: *nuclear explosion*

I just started a new job where PHP and JavaScript are the primary languages. I came from a position as a firmware engineer where I coded in C/C++. I'm learning PHP as I go. I don't see why everyone hates on PHP. I find it extremely powerful. Especially when used in an object-oriented context.

Real HR policy ...

HR Manager in Heaven!!!

One day while walking down the street a highly successful HR Manager was hit by a bus and she died. Her soul arrived up in heaven where she was greeted by God himself.

"Welcome to Heaven," said God. "

"Well, What we're going to do is let you have a day in Hell and a day in Heaven and then you can choose whichever one you want to spend an eternity in."

"Actually, I think I've made up my mind, I prefer to stay in Heaven", said the woman.

"Sorry, we have rules."

And with that God put the HR Manager in an elevator and it went down-down-down to hell.

The doors opened and she found herself stepping out onto the hell wt beautiful golf course. And a country club and standing in front of her were all her friends - fellow executives that she had worked with and they were well dressed in evening gowns and cheering for her. they talked about old times.
She met the Devil who was really a nice guy and She was having such a good time that before she knew it, it was time to leave.

Everybody waved goodbye as she got on the elevator.

The elevator went up-up-up and opened back up at the Pearly Gates and found God waiting for her.

"Now it's time to spend a day in heaven," he said. So she spent the next 24 hours around on clouds and playing the harp and singing. She had great time and before she knew it her 24 hours were up and God came and got her.

"So, you've spent a day in hell and in heaven. Now u must choose ur eternity,"

The woman paused for a second and then replied, "Well, I never thought I'd say this, I mean, Heaven has been really great and all, but I think I had a better time in Hell."

So God escorted her to the elevator and again she went down-down-down back to Hell.

When the doors of the elevator opened she found herself standing in a desolate wasteland covered in garbage and filth. She saw her friends were dressed in rags and were picking up the garbage and putting it in sacks.

The Devil came up to her and put his arm around her.

"I don't understand," stammered the woman, "yesterday I was here and there was a golf course and a country club and we ate lobster and we danced and had a great time. Now all there is a wasteland of garbage and all my friends look miserable."

The Devil looked at her smiled and said:
...
...
...
....
....

"Yesterday we were recruiting you, today you're an Employee".😁😁😁
☝dedicated to all companies

I went to Paris for my first interview (that was 1989) for a job of Unix kernel developer. All dressed up. I step out of the elevator and see a young punk with scruffy hair and different colour shoes. I reckon he must be the pizza delivery guy. I ask him "dude, can you please point me to the CEO's office for interview". He said "sure, follow me man, I'll show you". We arrive at a desk, he sat down in the big chair and looks at me with a big smile and says "Ok dude, here we are. I am the CEO. Now let's see how good you are!"
I got the job. And 26 years latet, last week, amazing coincidence: I met him again at a trade show in Paris ... with the same coloured shoes. How cool is that!!!

"You gave us bad code! We ran it and now production is DOWN! Join this bridgeline now and help us fix this!"

So, as the author of the code in question, I join the bridge... And what happens next, I will simply never forget.

First, a little backstory... Another team within our company needed some vendor client software installed and maintained across the enterprise. Multiple OSes (Linux, AIX, Solaris, HPUX, etc.), so packaging and consistent update methods were a a challenge. I wrote an entire set of utilities to install, update and generally maintain the software; intending all the time that this other team would eventually own the process and code. With this in mind, I wrote extensive documentation, and conducted a formal turnover / training season with the other team.

So, fast forward to when the other team now owns my code, has been trained on how to use it, including (perhaps most importantly) how to send out updates when the vendor released upgrades to the agent software.

Now, this other team had the responsibility of releasing their first update since I gave them the process. Very simple upgrade process, already fully automated. What could have gone so horribly wrong? Did something the vendor supplied break their client?

I asked for the log files from the upgrade process. They sent them, and they looked... wrong. Very, very wrong.

Did you run the code I gave you to do this update?

"Yes, your code is broken - fix it! Production is down! Rabble, rabble, rabble!"

So, I go into our code management tool and review the _actual_ script they ran. Sure enough, it is my code... But something is very wrong.

More than 2/3rds of my code... has been commented out. The code is "there"... but has been commented out so it is not being executed. WT-actual-F?!

I question this on the bridge line. Silence. I insist someone explain what is going on. Is this a joke? Is this some kind of work version of candid camera?
Finally someone breaks the silence and explains.

And this, my friends, is the part I will never forget.

"We wanted to look through your code before we ran the update. When we looked at it, there was some stuff we didn't understand, so we commented that stuff out."

You... you didn't... understand... my some of the code... so you... you didn't ask me about it... you didn't try to actually figure out what it did... you... commented it OUT?!

"Right, we figured it was better to only run the parts we understood... But now we ran it and everything is broken and you need to fix your code."

I cannot repeat the things I said next, even here on devRant. Let's just say that call did not go well.

So, lesson learned? If you don't know what some code does? Just comment that shit out. Then blame the original author when it doesn't work.

You just cannot make this kind of stuff up.