Hello Weekdays

ccto

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

God I'm immature.

Sales employee Bob wants a clickable blue button.

Bob tells product owner Karen about his unstoppable desire for clickable blue buttons.

Karen assigns points for potential and impact (how much does a blue button improve Bob's life, how many people like Bob desire blue buttons)

Karen asks the button team how hard it is to build a button. The button team compares the request to a reference button they've built before, and gives an ease score, with higher score being easier (inverse of scrum points).

These three scores are combined to give a priority score. The global buttonbacklog is sorted by priority.

Once every two weeks (a "sprint") the button team convenes, uses the ease scores to assign scrum points. Difficult tasks are broken up into smaller tasks, because there is a scrum point upper limit. They use the average of the last 5 sprints to calculate each developer's "velocity".

The sprint is filled with tasks, from the top of the global button backlog, up to the team's capacity as determined by velocity. Approximate due dates are assigned, Bob is a happy Bob.

What if boss Peter runs into the office screaming "OUR IMPORTANT CLIENT WANTS A FUCKING PINK BUTTON WHICH MAKES HEARTS APPEAR"?

Devs tell boss to shut the fuck up and talk to Karen. Karen has a carefully curated list of button building tasks sorted by priority, can sedate boss with valium so he calms the fuck down until he can make a case for the impact and potential of his pink button.

Karen might agree that Peter's pink button gets a higher priority than Bob's blue button.

But devs are nocturnal creatures, easily disturbed when approached by humans, their natural rhythms thrown out of balance.

So the sprint is "locked", and Peter's pink button appears at the top of the global backlog, from where it flows into the next sprint.

On rare occasions a sprint is broken open, for example when Karen realizes that all of the end users will commit suicide if they don't have a pink heart-spawning button.

In such an event, Peter must make Bob happy (because Bob is crying that his blue button is delayed). And Peter must make the button team of devs happy.

This usually leads to a ritual involving chocolate or even hardware gift certificates to restore balance to the dev ecosystem.

the truth about python...

Pro tip: If you are a junior, or senior but new at the company, don't start your conversations with:

"We're doing X wrong. At my previous company we did / at school I learned /in this book I read / according to this talk I watched, the right way to do X is ..."

Instead try:

"I'm curious why were doing X this way. I'm used to doing it differently."

I love flat-hierarchy teams, and people who think about flaws in procedures and proactively try to improve the tools we use are awesome, but the next kid walking up to me yelling we use git flow "wrong" will be smacked in the face with a keyboard.

If you come to me with curiosity and an open mind, I'll explain, and even return the favor by behaving the same way when I'm baffled by your seemingly retarded implementations.

Maybe we can learn from each other, maybe discover that "how I learned it" is sometimes good, sometimes bad.

But let's start with some social skills, not kicking off into every debate with a stretched leg and a red face.

Finally the right answer

When you love python too much..

Train track info screen on a friday in Sweden. Someone has some work to do!

1. The quality of the coffee and toilet paper you encounter during an interview tells you more than promises about table tennis or fruit baskets.

2. Try to determine who their primary client is: subscribers, app buyers, advertisers, etc. It's a major influence on the company dynamic.

3. Before an interview, you can just say: "I would like to sit down with a PO and run through one backlog feature and one bug, to get a feel for the type of tasks at the company". Such an activity immediately reveals team structure, whether they have product owners & scrum masters, what a sprint looks like, how they prioritize tasks, and how organized/chaotic your work experience will be.

And you can only hope you don't have to compile it yourself using alternate sources.

I am the internet...

Found on 2019's Stack Overflow Annual Developer Survey

Hahahaha 😂😂😂

So true 💡

Just shaved my beard off.... now I can't remember how to use the bash shell :(

Not a racist, but there is a guy on the train that smells curry! How the fuck can you bypass that smell...

... nope.

not worth it...

Sooo my friend asked my to become more active on steam and i did something about it! I'm going to be become the most activities steam user!

* Me entering the interview room:
Me: Hello
Interviewer: Hi, You are XYZ right?
Me: Yes, that is me
Interviewer: You know we offer {low_number} as a salary right?

*Me going out of the room

Programmer one-line horror stories? A few off the top of my head:

Segmentation fault (core dumped)

'Undefined' is not a function

Unit test failed: expected '0' but got '-1'

Connection to 'localhost:8080' has been lost

Malformed JSON string at col: 46,372. Expected '}'

;____;

START FUCKING USING GIT.

😅

Optimising code

This is gold 😂

Had to post this...

Such a relief

People bashing JS and PHP while I wonder why XML still exist.

"If you have an apple and I have an apple and we exchange apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas." - George Bernard Shaw

A non-techie just asked me this, "when your computer overheats, why does it freeze?"