Wednesday, September 15, 2010

“Video Games Lead to Faster Decisions That Are No Less Accurate”

 

http://www.sciencedaily.com/releases/2010/09/100913121656.htm?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+sciencedaily+(ScienceDaily:+Latest+Science+News)

starcraft2-hell-its-about-time[1]ScienceDaily (Sep. 13, 2010) — Cognitive scientists from the University of Rochester have discovered that playing action video games trains people to make the right decisions faster. The researchers found that video game players develop a heightened sensitivity to what is going on around them, and this benefit doesn't just make them better at playing video games, but improves a wide variety of general skills that can help with everyday activities like multitasking, driving, reading small print, keeping track of friends in a crowd, and navigating around town.

Enuf’ said. Now I can play Starcraft II for as much as I like claiming it’s for my own good.

Saturday, September 11, 2010

Off Topic: Scaloppine Magiche

I’m seriously thinking about turning this blog into a cooking blog. Programming is a creative endeavor after all, isn’t it?

 

 

 

 

 

 

 

To create Scaloppine Magiche:

  • get thin beef (or veil) filets
  • cover the filets with flour on both sides
  • heat up olive oil (olive oil!)
  • when the meat is half cooked, poor red wine
  • serve with roasted vegetables, and the same red wine to drink

 

Squeezing a lemon instead of pouring red wine works equally well.

Enjoy!

Friday, September 10, 2010

Crunch… crunch… crunch…

http://www.estherderby.com/weblog/archive/2006_03_01_archive.html#114167242943470460

Extended periods of overtime are more likely to SLOW DOWN work than speed up work.

Rather than demand overtime,

  • Look at the universe of work for the department, not just individual work loads
  • Decide what to do and *what not to do* based on the mission of the group
  • Prioritize the work the group needs to do
  • Determine the level of quality required for work – what “done” means and what “good enough” means
  • Collect data on how people spend their time at work – not to beat people over the head, but to look at patterns that may be lowering productivity
    (Typical time-robbing culprits are: Multi-tasking, fragmentation, frequent interruptions, meaningless meetings, non-value adding corporate activities.)
  • Thursday, September 9, 2010

    The 'premature optimization is evil' myth

    In Bluebyte’s blog, Joe Duffy writes an extremely interesting essay about premature optimization, where his conclusions are:

    What I do advocate is thoughtful and intentional performance tradeoffs being made as every line of code is written. Always understand the order of magnitude that matters, why it matters, and where it matters. And measure regularly! I am a big believer in statistics, so if a programmer sitting in his or her office writing code thinks just a little bit more about the performance implications of every line of code that is written, he or she will save an entire team that time and then some down the road.

    Original link:
    http://www.bluebytesoftware.com/blog/2010/09/06/ThePrematureOptimizationIsEvilMyth.aspx.

    It’s a very good read over all, and very well reasoned, but I disagree with the approach entirely. I prefer simplicity first, making it work and making it simple, and then, where necessary, making it fast.


    This approach fails to recognise that even in low level programming, the scarcest resource is in the vast majority of the cases neither CPU time nor memory, but programmer's time. That's what we need to optimize for: making careful consideration of the performance characteristics of every line of code might optimize CPU time, but wastes programmer's time on a task that is totally irrelevant for 90% of the code. On the other hand I agree on: “Given the choice between two ways of writing a line of code, both with similar readability, writability, and maintainability properties, and yet interestingly different performance profiles”. No reason to make something slower for the sake of it, everything else being equal, right? Right, but very rare.


    The example with LINQ is emblematic: I will choose the LINQ version any day, because it's simpler to write, simpler to read and clearer. If the profiler says it doesn't meet the performance requirements, then and only then I will kill every single cycle I can from that code. In my experience this approach resulted in faster and simpler low level code.