Programmer's Paradox

Short musing on interesting links

Google's Maturation, Part 2

Buried in this article about the crazy recruitment of developers these days (not that I can complain - it works out well for me) is a note that Google has become more bureaucratic and now almost never fires anyone. Google is slowly calcifying. It has been fun watching them try not to become a slow dinosaur, but it looks like they are losing the battle. 

Of course, it's worth counter balancing the thought above with the idea contained within this tweet: "worth remembering: a startup exists to stop being a startup." 

Google's Maturation

If you've followed my main blog for any period of time, you know there was a while where I pondered Google - a lot. I often wondered how Google's growth would affect them and how long they could maintain their dominance.

Scott Berkun has thoughts he posted today on the closing of Google Labs. He doesn't dwell on the fact that Google is closing labs - he mostly focuses on the language of their press release. It's a revealing look at how Google has changed and how their growth has affected them.

100% Utilization

We used to think the goal for a computer was to utilize it's resources at 100%. This was good, but then came the age of the multicore.

In the age of the multicore, running at 100% means you have thrash, as the system is constantly having to swap items, leading to reduced throughput.

So too it is with humans. We make our goal 100% utilization, but if we operate at that level, we burn out.

It's much better to operate at less than full utilization. This leaves time to contemplate the problem, discuss it with others, manage the inevitable interruption, or just take a break.

As a result we produce more, and better, work. 

Optimizing Software

How to optimize software:

"What I learned most from this experience was the importance of a structured, systematic approach to programming. I have found that is it always better to write a simple, direct program to solve a problem, having become convinced through experience that radical structural transformations can come later; and I can depend on those transformations to preserve the original semantics of my program. I have also learned that I can be free to focus on the NATURE of whatever problem I am trying to solve, rather than on how "efficient" my solution is. Real efficiency comes from elegant solutions, not optimized programs. Optimization is always just a few correctness-preserving transformations away."

- Jonathan Sobel, in "Is Schema faster than C?"

The Software Craftsmanship Movement

Martin Fowler's post on the Software Craftsmanship movement largely mirrors my own thoughts.  I ascribe to the movement because I value good code; but the relationship with the customer is still important.  Ultimately, like many things in life, it's a balancing act between quality and speed, values and compromises.

Each person will take their own path, based on their own values, while making different tradeoffs and dealing with differing consequences.  

We can each describe how we dealt with issues, and the software craftsmanship movement is one way to deal with issues.  It isn't the only way though, so there will always be differences and disagreements.  They hardly seem worth arguing over.  That doesn't mean they aren't worth discussing, as in discussing we learn new things.  It's just not worth wasting time yelling into the either over which approach may or may not be better.
Posterous theme by Cory Watilo
  
​