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.
"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."
Dreaming in Code, by Scott Rosenberg. Highest recommendation. 10x coders hired by visionary engineer to scratch their own itch. What could go wrong?
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.
To be fair, so does Perl 5. Perl 5.18.0 happens to be the yearly major release.
To my knowledge, Rakudo hasn't reached the point where its developers call any Star (runtime plus libraries) release a "major release" of the sort that users ought to use in the wild for a year or more.
From the perspective of somebody who needs a production-grade Perl implementation, Rakudo doesn't cut it, I'm saddened to say.
Monthly releases are a good step in the right direction, but they aren't very useful to those of us who need something more robust.
Perl 5 currently offers this robustness, while Rakudo unfortunately does not. The other Perl 6 implementations end up being worse than Rakudo in this respect, as well.
I think there should be some kind of changing of names. For a while it looked like it's another incremental step, if a big one. Which obviously requires running two implementations in parallel for a while -- similar to Python 2 and 3, or several operating systems and distros.
But right now, especially once Perl development really picked up, it might be time to "divorce" the two languages. It seems more like Algol60 vs. Algol68, or Modula-2 vs. Modula-3. Sure, there's a number in there, but it isn't just about the version of the main implementation.
Having said that, kudos to the Perl team. I really like that they now release new versions pretty regularly, which is a good sign to show people that Perl5 ist still very much alive and nobody needs to hold their breath for the time being.
If only I could use something more recent than 5.8 at work...
Lets assume that I'm switching from Perl5. Why would I switch to Perl6 over something else? Even assuming Perl6 were to be become production ready tomorrow, there is a cornucopia of good languages these days. I'm sure Perl6 can claim to be more expressive than most but is that enough?
You can use perlbrew to install any version of Perl your heart desires in a local directory of your choosing. You can also install multiple versions and easily swap them.
We deploy to a RHEL server where the stock Perl is 5.8.8. Sure, migrating that to a perlbrew/local::lib setup with up-to-date CPAN modules would be really nice, but would require some major testing, and right now nobody has the time for that. Never change a running system sigh...
But hey, generally it's not a big hassle, from a programmer's perspective that version ain't that outdated. About the only thing I really miss is "//="...
Sincere question - is it worth investing time into reading a 500 odd page book for something that I might not use that frequently in my career? From my experience, I've seen that I can get away by just Googling or just experimenting whenever I'm stuck on a regex.
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. ;)
Well, maybe not an entire 500 page book, though I'm sure it wouldn't hurt. You could always try Zed Shaw's the-hard-way book on the subject: http://regex.learncodethehardway.org/book/ (haven't read it but the the-hard-way books seem to be fairly well regarded)
I do take issue with your suggestion that you might not use this stuff all that frequently in your career. This is definitely at odds with my experience. Even though I don't use them that much in final-quality code, I use them all the time from the text editor, and quite often for quick one-off text manipulation or extraction scripts. Having a quick way to extract text from ad-hoc data can quickly get you a rough answer to a speculative question, the text equivalent of of back-of-the-envelope calculation, without needing to do a lot of work and without needing the question to justify a lot of work.
But I mainly use them for searching for one of two or three different strings in the text editor.
You don't need to read 500 pages to understand the core of regex. "The core" means "what you will use 99% of the time". You need 11 minutes: http://www.youtube.com/watch?v=hwDhO1GLb_4
I guess your question is why read a book when you can just learn as you go and as you need to. I didn't read a book, but I probably should have because it took a long time for me to pick up things that would have helped a ton earlier on. For example, I recently learned that you can turn off "greedy" when using .* by adding a ? after it. This was a huge revelation that I would have benefited from day one, ten years prior.
Yes, hundred times yes. Even rudimentary web coding involves regexps somehow. But the real benefit is mastering a topic that is complex and the sense of accomplishment and competency it brings you.
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.
I'm not my mom, so I can't do that! Such subjectivity is something to avoid in an analysis like this. And 'level of integration' seems just as hard to assess.
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.