Start with the "classics" like "mystical man month" (Brooks) for example, then get many of the books by Tom de Marco and possibly read Richard Gabriel's "Patterns of Software". The book about the "Chandler" project (forgot it's title) is also a particular good read. Those two in particular are interesting reads about why things fail.
Go on to reading the Toyota management style in itself, there's a couple of books about it, that's what many IT techiques are getting their ideas from.
It's mostly about finding your values so to speak and pinpoint what you really think makes up a good software development company - maybe your focus will be on organization, maybe on other things, so get an overview first.
These two articles are hopefully also an interesting nudge to think about many things:
O'Reilly has a very interesting book with analysis which practices actually work and why/how - sadly I also forget the title. There's for example a chapter about when and why pair programming works and when and why not.
Also, just watch carefully and learn to notice "good organization" - happens in surprising corners and niches and try to see WHY it's good.
I like working with them and having at least one on the team, because they're a great addition to the "naive optimist" or the "carefree hacker-fixer" who always see the solution around the corner - in a couple of minutes of course. ;)
And: There's a lot of tech scenarios where being overly careful and actually seeing the impending technical doom in every corner is an advantage.
Similar to the pedantry you get by the human robot, Cassandras have their place - and good management and coworkers know exactly where and how to take them.
For small stuff CouchDB directly (with Jade as templating) or Smalltalk's Seaside, for larger stuff build for running the next decade Perl due to boring stability and backwards compatibility and least surprises.
The book doesn't just teach you regex, but the why, how AND the dialects. It gives you an overview over different tools and programming languages and their regex-related functions and methods.
On top, it contains a ton of examples, is very well written (considering the insanely dry and difficult to typeset subject :) and is very polished (I think it's in the 3rd edition by now..)
If you just google or experiment on regex, you usally get bad regex, badly crafted regex, brittle regex and make every single mistake the book prevents you from doing.
It's really one of the most worthwhile books of reading through - it's also an excellent handbook to look things up.
Remember that a lot of commandline tools take in regex too - grep, sed, awk, you name it - it's not just for use in programming languages.
Your favorite editor has regex too.
I simple don't know how people can live without; I'm using regex practically every day.
P.S.: And _after_ reading the book, you will understand why people yell at you when you parse HTML with regex but you will know how to do it anyways and at least not completely badly. ;)
You mentioned in passing that you have a feeling that Picasa isn't surviving for long due to it's "old-fashionedness".
Considering how important "usefulness" and "usability" are by now, maybe add a criteria along those lines - how large is the "your mom uses it and likes it" factor, how "contemporary" are the UIs, how much effort puts Google into polishing it (it does a lot with G+ and Gmail for example) - something like this.
Another criteria could be "level of integration" - how much can you use a Google product as a standalone project or how deeply connected is a product into another one (e.g. Picasa used outside of G+) - which might in the end indicate not a direct shutdown but a product's dissolution into another one.
So far I'm just not using the Developer Tools at all, because they don't give me what Firebug does.
Debugger, Inspect and Web Console just aren't working well together, aren't interegrated smoothly into each other and I hardly can get from one to the other. I can't enable ALL of them at once.
If they _were_ like Chrome's tools or Firebug I'd wish for the features of Firebug's XPath and CSS extension: input expression, get matching elements highlighted.
So, either they have to be as useful as Firebug, or throw them out to keep FF lean for users who doesn't need them anyways.
Also "keep the DevTools as simple as possible" makes absolutely no sense to me as a Web Developer - I need those tools as GOOD as possible and as USABLE as possible with a specific range of features I've come to expect from Firebug and Chrome.
I mean, I basically live with an open Firebug during work...
I absolutely believe what he writes, because he's quite precise about his experiment and how he did it and this really works for a couple of reasons:
* This guy isn't 20 anymore. He has actually explored and learned and trained "productivity and focus" which he blogs and writes books about - so he doesn't start like a 18 year old directly from school, unexperienced maybe in this level of focus and discipline.
* He was pragmatic in his goals - very much so. He didn't write "becoming the world's foremost expert in linear algebra" but "passing an exam". And so he did. He also didn't write "passing everything with a top grade" but "just pass, if better - wonderful".
* He actually did his math on "hours to put in" - a semester doesn't take full 6 months, you usally don't attend lectures/lab every day 3 hours a day but 1-2 times a week, 2 (university) hours plus preparation. If you carefully add this up, you actually get a surprisingly low count of actual course/lesson hours.
* Taking in a course in a focused manner is actually quite efficient and helps you (at least it does for me) follow the material without interruptions. You also can repeat as often as you like (he mentions a fast forward and replay button in his TEDx talk) - which btw. makes part of the success of e.g. Khan university material.
* He also put some effort and training into the right way of learning and _that_ pays off massively in terms of speed.
Also, one of the points he is actually making is part of what most of you critizise: Going through the list of MIT requirements is something different compared to "becoming an expert in X" - don't mix that up.
Well, this kind of insanity made me step back 10 steps and invest some time (almost a year by now) into the "classics" so to speak.
Inspired by Crockford's talks in which he mentioned a couple of times the lack of history and historical knowledge among developers, I suddenly remembered that I got an education in humanities before I even went into programming and really did start with the classics - Greeks and Romans and Philosophy - and I asked myself why on earth I never really considered doing something similar in computing. (Someone called it in some article I've sadly forgotten the Oxford way - you learn Latin and Math and from there you can learn anything anyways ;)
So I decided to ignore all fashions, new things, upcoming frameworks and such for some time until I got what I would consider (totally subjectively) a solid foundation (not there yet, will probably take another year at least) of knowledge.
I personally decided to define "classics" along the lines of "knowing Unix and its history and concepts well" (re-learning shell and commandline wizardry on top), "understand decent C and Assembler", "becoming familar with the influential languages of important concepts like functional and OO programming (Scheme/Lisp and Smalltalk). This includes really understanding SQL (which I suddenly started to really like to my own surprise). Maybe I add some PostScript and TeX along the way. I also found a new appreciation for Perl's text processing capabilities and its influence from the 1990ies on.
Set aside that I constantly have to fight kind-of a "bad conscience" exactly BECAUSE I'm not hurrying along to try out the latest and greatest new fashion, I'm starting to feel a deep change in my programming skills, in my thinking about design and I'm constantly marveling where computing already has been and how much there is to learn from the classics. I also started to get a distinct feeling of "Man, I just don't NEED all this clutter and stuff" and a newly found appreciation of "simplicity" (Watch Rich Hickey's talk about "simple versus easy"..).
I started to slow down, to think more carefully, to read a lot more on concepts and ideas. I've finished recently Christopher Alexander's Pattern Language book for example to get a better feel for the "orginal" idea or read up on the history of "lean production" and Toyota's influence or looked again at Dieter Rams' design principles (I'm German and I basically grew up with Braun appliances, I didn't even realize how influential his designs have been to me..)
All this changed me and my thinking about programming deeply and made me find kind of a "central theme" or "essence" in programming and design I like and I'm starting to strive for.
In the long run, this also gives me a foundation of how I'm judging new tools, ideas, frameworks and programming languages.
On top of that, I'm better able to place myself into a certain "style" or "culture" of programming I'm not going to give upon as long as I can afford it.
Anyways - I personally think there actually is a choice whether one tries to catch up with everything new or peek into new things selectively or just steps back a little and watches how all this will unfold in the long run.
(I also have a long-held, un-proven personal theory that people simply like _writing_ frameworks a lot more than _using_ them - some are just faster to release theirs into the public.. :)
Stability, maturity, great backwards compatibility, whipuptitude, a sea of well-cared mature modules on CPAN, the ease and convience of CPAN itself, already installed/available everywhere, Unicode support, creativity and competence of the community, exceptionally good documentation, "the spirit", MOP via Moose if I want to, rarely gets in my way, scales very well in terms of "thinking" and "project" (everything from tiny admin-script up to full-blown financial district application possible), speed, amazing interesting features in perl 6....
And no, you don't write the same Perl as in 1996 anymore.
Go on to reading the Toyota management style in itself, there's a couple of books about it, that's what many IT techiques are getting their ideas from.
It's mostly about finding your values so to speak and pinpoint what you really think makes up a good software development company - maybe your focus will be on organization, maybe on other things, so get an overview first.
These two articles are hopefully also an interesting nudge to think about many things:
http://www.computerworld.com/s/article/9137708/Opinion_The_u...
http://alistair.cockburn.us/Characterizing+people+as+non-lin...
O'Reilly has a very interesting book with analysis which practices actually work and why/how - sadly I also forget the title. There's for example a chapter about when and why pair programming works and when and why not.
Also, just watch carefully and learn to notice "good organization" - happens in surprising corners and niches and try to see WHY it's good.