Don't buy shitty tech books

Don't buy this shitty book even though it's old and has some stars in review (better read reviews with fewer stars). I'm telling you: don't buy "The Pragmatic Programmer: From Journeyman to Master". It has nothing to do with pragmatic. It simply looks like a book written while travelling, in a break, when tired, while taking a dump etc (you get the idea).

This book can only be good for people that want to chat about programming and have only written short "hello world"-like programs while alive.

---

"Use Saboteurs to Test Your Testing

If you are really serious about testing, you might want to appoint a project saboteur. The saboteur's role is to take a separate copy of the source tree, introduce bugs on purpose, and verify that the tests will catch them.

When writing tests, make sure that alarms sound when they should."
---

So this means that we should test our tests? What the hell is that?

Now really, who in the world allocates budget for testing the tests? It is clearly that who wrote this never understood what developing software means. How much time do you think you need to test your tests when most of the projects don't have enough tests?

Simply idiotic!
---
"Testing Thoroughly

Once you are confident that your tests are correct, and are finding bugs you create, how do you know if you have tested the code base thoroughly enough?

The short answer is "you don't," and you never will. But there are products on the market that can help. These coverage analysis tools watch your code during testing and keep track of which lines of code have been executed and which haven't. These tools help give you a general feel for how comprehensive your testing is, but don't expect to see 100% coverage."
---
Again, it is clearly that this guy (the book was written by two guys) wrote some unit tests for getters and setters and then saw that writing complete unit tests for functions with at least a loop and an "if" is difficult.

As I've written unit test for a safety critical project I had to achieve 100% coverage. Coverage that was not possible was detailed in a report.

Example of code that is not normally coverable (we don't discuss stubs):

~~~
....
handle = OpenFile(...);
if (!handle)
    return;
size = GetFileSize(handle);
if (size != 100)
   return;
if ( !Read(handle, buff, 100) ) // this will most likely succeed
   return; // this won't execute - must explain why
....
~~~

So when I see that sentence with "don't expect 100% coverage" I feel like  I need to shout to the author and tell him to stop writing books. Do whatever you do, I'm sure you're good at what you do, but STOP WRITING SHITTY ADVICES!

100% is totally achievable for most of the algorithms written. Special cases like the one above should be documented and documenting it means that the code is reviewed and expected to work ok even in weird cases (for example when drive is unmounted/disconnected exactly after the GetFileSize function).

So, stop writing shitty advices in books, 100% coverage can be achieved even if it means documenting what's not covered.

Oh, and when I mean 100% I mean 100% for most types of coverage (dc,path, mcdc usually):

http://www.bullseye.com/coverage.html

The only reason you can't achieve 100% coverage is laziness from my point of view.
---
"Even if you do happen to hit every line of code, that's not the whole picture. What is important is the number of states that your program may have. States are not equivalent to lines of code. For instance, suppose you have a function that takes two integers, each of which can be a number from 0 to 999.

int test(int a, int b) {

return a / (a + b);

}"
---
If you write code like that monkey above you surely treat all cases the same when in fact you should be treating special cases separately. A sane person knowing what the 0,999 interval means would write code like this:
int test (int a, int b)
{

if (a > 999 || b > 999 || a < 0 ||  b < 0)
  return -1; // invalid

if (a  ==  0)
  return 0;



// right now a > 0 so we don’t get division by zero since b >= 0
return a / (a +b);

}

Any programmer knows about division by 0. The code from the book is simply ... not relevant.

---
"In theory, this three-line function has 1,000,000 logical states, 999,999 of which will work correctly and one that will
not (when a + b equals zero)."
---

In theory, code like that should never be found on a decent file system. It should be found on some whiteboard, paper or other non-it related communication method. Simply putting such code on a file system is an insult to the IT industry. (I apologize to the industry for publishing it)

And what does he mean by "states"? Because I'm thinking of a state machine but he clearly means something else which is ... only he may know.

---
"Simply knowing that you executed this line of code doesn't tell you that—you would need to identify all possible states of the program. Unfortunately, in general this is a really hard problem. Hard as in, "The sun will be a cold hard lump before you can solve it."

Tip 65
Test State Coverage, Not Code Coverage"
---
Showing such arguments only goes to say that some people don’t deserve to use a computer keyboard, not to mention coding. If special cases are correctly identified then coverage is most likely enough. Writing code like a unevolved monkey is no excuse to create a new “pseudo-science” where state means ... whatever the hell the author wants.

So my advice to you is not to buy this book. It is a book full of crap and stupid advices.

What this book does is like recommending people to put a mattress on front of the car to avoid injuring pedestrians. Looks like a new idea, but it is not applicable and in the end it only proves stupid.

I also have some insights on how these types of books are written but that may be for later. I offer just a hint: don't expect the authors to always be the ones actually writing books.

Interviuri

EL: Aveam sala la ora 9 ... mai tarziu nu se putea??
---
EU: Dar despre proiectul pentru care am venit la interviu ce imi puteti spune?
EL: Avem destul timp pentru asta
(probabil dupa interviu?!)
---
EL: Serverele noastre servesc peste 10 milioane de reclame pe luna
EU (gandind cu voce joasa): 10 milioane / ~300 zile pe an ; 1 mil / 30 ~ 30000 pe zi / ~30h --> cam 1000 pe ora / 3600 ....
EU (cu voce normala): Pai nu cred ca e mare lucru ca performanta pentru ca serveste mai putin de o reclama pe secunda. Cel putin asa cred...
EL (contrariat): .... mda
---
Eu recomandand un om care stia treaba garantat.
EU (dupa 2 zile): ce a facut X?
EL (responsabil cu angajarile): Nu l-am chemat. Nu se potriveste profilul.

NOTA: CV-ul e comun cu 80% din ce am eu pe CV cand vine vorba de job description
---
EL: Cum faci sa adaugi o functionalitate dar fara sa restartezi aplicatia
EU: O solutie ar fi un plugin
EL: Da, dar cum...
EU: Pai un plugin... ca in browsere
EL: Pai mai clar...
EU: Un shared object/DLL
EL: Da, asta voiam de la tine
EU: Pai asa se fac plugin-urile...
EL: Da... dar voiam mai clar
---
EL: Va anuntam cand sa semnam contractul cat de repede
EU: Va multumesc

EU: Cum a ramas cu semnatul contractului?
EL: Am uitat sa va spun, proiectul nu a mai ajuns la noi. E in Slovacia.
(acolo era de frecat duda daca semnam - angajat si fara proiect)
---
EL: Care este nota pe care ti-ai da-o pentru tehnologia X?
EU: Nu asta e scopul interviului?
EL (ganditor): ... hmmm
---
Telefonic:
EL: Hi, this is X, recruiter for Y. How are you doing?
EU: I'm ok, doing some shopping...
EL: You could be shopping with a lot of money in your pocket if you were to work for ...
---
Telefonic:
EA (remote HR): Salut, te-am contactat pentru o oferta de job la compania X
EU: Pai acolo lucrez...
EA: Ah, da. Acum am vazut. Spor la lucru

A good reason to know your neighbors

Image the Internet connection drops because of a faulty router. But there are other routers available (and working!), you just don't know which of the connected neighbors will get mad if you switch cables.

It might be that one of your neighbors:
- is out of town
- doesn't need Internet that bad
- rarely uses his Internet connection
- may call ISP in 2-3 days to come and figure out the problem (while being calm)
- understands your addiction (and doesn't want to see some weird Internet withdrawal symptoms)

Having such neighbors provides you a way to quickly gain access to the Internet when needed. But for this you need to know them. Failure to do so is risky as you might end up cutting the Internet connection of some psycho whose reaction cannot be predicted.