anchor.diff:  will pay a visit to the school and hopefully this teacher stops killing kid's motivation to learn 
   and specially learn math.
   
  -For a final statement I will leave here another comment from the thread that really rounds things up 
  +For a *final statement* I will leave here another comment from the thread that really rounds things up 
   with this topic by explaining a real life example of how common sense might not make your life easier 
   all the time:
   
  -[quote, Former Bank Employee, 'https://www.reddit.com/user/ituralde_[ituralde_]']
  -____
  +[source]
   Hey, former dev at a bank here.
  -
   Being "better" isn't strictly right. This isn't just your professor being an asshole, I was on an actual 
   project that had pretty much this exact same problem.
  -
  -
   Project involved effectively automating some collateral value calculations. We were given a spreadsheet 
   with some sample values and were given the maths and were told to match output. We didn't bother to check 
   that the formatting rules truncated at certain point (at the millions). We get into UAT and the business 
  
positive.code: Anyways, you can also have the case of having specs that do not make sense (or common sense) in 
  many areas (disorganized, contradictions, etc). In such cases it's always good, in my opinion, to 
  start your own documentation stack, or your own specification in a better format and language. For 
  these cases I've recently found that my colleague's 
  link:https://twitter.com/_jameswatts_[@_jameswatts_] 
  specification for *XHTTP* is really well outlined and it's a nice starting point: 
  
  link:http://www.xhttp.org/specification[XHTTP Specification]
  
  
negative.code: that's pretty unfair. But I'm not an expert in that field, or actually any field to begin with. What 
  really got my attention were the comments that followed this post in reddit:
  
  [source]
  I actually just recently ran into an issue with my programming course where they knocked off 10 
  points because my output was 1 cent off what their "desired" output was, regardless of the fact 
  that my program was actually rounding properly instead of truncating, making it more accurate 
  than it actually was. I never hated a teacher so much in my life.
  
  [small]#- By some guy on reddit, https://www.reddit.com/user/Evilsqirrel[Evilsqirrel]#
  
  
  
  To which somebody *replied*:
  
  [source]
  I've got bad, bad news for you if you want to be a software engineer that works for money.
  
  [small]#- By some other guy on reddit, https://www.reddit.com/user/qwertyslayer[qwertyslayer]#
  
  
  
  He can't be more right! I've gone through similar situations during my career, in many projects 
  and in very different scales. What I've really learned is that you have to choose your battles, 
  you're paid for your expertise and for your skills, my problem is that I have amazing skills 
  to detect this kind of problems (_The client wants something that will eventually lead you and 
  him to hours of frustration and bug hunting due to bad approaches and rules that don't follow 
  common sense_), my advantage is that I have good ways to work this through by communication and 
  negotiation (_Sometimes the client really wants that feature that will shut his business down 
  and it will be extremely hard to convince him otherwise_). 
  
  So what do I recommend: *don't be an asshole*. When some points in the specs doesn't follow common 
  sense or has some technical underlying issue -> Go and talk about it with your client/boss since 
  it will free you from the suffering caused by taking one of the 2 potentially wrong decisions: 
  1. You fix it and keep your mouth shut, then it will explode in your face when he tells you that 
  