If I had to summarize this book with a single word it would have to be "disappointing". I had quite high hopes for it as I read some of the “beautiful” book series before and they were really good. Unfortunately beautiful teams is not that great at all. I am not sure who would I recommend it to anyone.
The art of lean software is a very short book. I was really surprised when I got it delivered home. It is not a bad book though. Even that most of the practices are common sense nowadays I still people should spare few hours to read it.
I have seen too may people not following these common sense rules to discourage anyone from reading the book. Don't expect breakthrough, just a list of useful advice.
I have not read a book about computer algorithms for a long time now. I liked parts of the programming pearls and I disliked parts as well. I think it is worth going through the book if you are a software engineer. Especially if you want to get better at designing efficient software or if you want to practice on some non-trivial programming puzzles.
In general I think it is a a solid book.
That is a really exceptional book! You would expect googler's books to be good, but this one is really great. Don't waste time, just order a copy you wont regret it.
Team Geek is a great source of knowledge not just for leaders but for all the people who work with software engineers (or who are engineers themselves).
I have been in quite a few technical job interviews in recent years and I think I can see some patterns of why people fail. You can find a lot of guides on how to get the dream job or how to behave in the engineering interview but there are few tips on what not to do. I thought it may help some people in getting their dream jobs or maybe even becoming better engineers. Here are three simple things to avoid during the software engineer interview.
Whenever I conduct job interviews for a while or go to interviews myself I realise how much is there to learn and how often we forget to stay sharp. Over the years I developed a personal regime that lets me stay reasonably up to date. As they say in China “sweat during peace so that you would not bleed during war”.
It would take a longer discussion to analyse my beliefs and explain better how was my career shaped but I think there are a few core advices that have worked for me so far.
Web Operations is a really awesome book, there is no question about it. Even that the book consists of multiple short chapters it contains so much insight and experience that every software engineer should read it.
I have been quite lucky with my book readings recently. Most of the books I read were good or very good. I think it is mainly because of a more careful selection process. I stopped reading random titles and I try to read books that were recommended to me by people I know.
Web Operations is a MUST HAVE, let me explain why.
Last week we had a Yahoo! winter hack day. It was my third hack day in Yahoo! and it was the best one so far! The hack party started at 5pm on Thursday. We hacked all night with some people working throughout the weekend as well.
2012 "winter hack day" was an amazing event. We got so much love from management teams and office folks. We produced over 20 super cool hacks with prototypes of mobile apps, internal tools and all sorts of freakn cool code. It was AWESOME! YO SYDNEY, YAHOO!7 IS IN DA HOUSE!
From time to time I see bugs in the code and I start thinking "really? is it possible that no one noticed that bug before? am i the first person to see this code?". I thought it might be worth writing a little post on what helps me to deal with bugs and software quality in general and what are the common pitfalls in developer's thought process. Although it is not a very extensive post i hope it may inspire some developers to try new approaches :-)
In general it is extremely rare for me to commit bugs that would make it into production (maybe less than one a year? hard to say as it is really rare). To be honest I can't remember a serious issue with my code for last 5 years.
To make it short and clear, I liked the book a lot. From a very begining it is clear that author has a vast experience in software design and development.
There are a few bits that really stand out.
First of all I loved the chapter showin pair programming and minimal effort principles. It is really fun to read and shows some very interesting observations.
Well, i am not sure what to think of this book. It is a bit uneven as it is a composition of many separate articles written by different authors.
First chapter was really poor. A lot of talk but no real value. How many times do we have to hear that architecture and design are important? Entire chapter is a very vague and buzzword filled blob.
Second chapter was actually very entertaining but again also bringing little value. Author describes two systems he used to work on. He brings a list of factors that made them fail / succeed. I like the chapter as it seemed a bit funny and had some good points.
After many years of reading references to it, i finally read Design Patterns by the famous Gang Of Four (GOF). Book is probably one of the most quoted and refereed IT books ever :-). Many of the articles I have read, that referred to the book, were really badly written. In most cases I had a feeling that authors did not understand design patterns at all. As a result my impression was that book has to be poor as well and does not do good job explaining patterns. This made me think that book has to be horrible if so many people write these vague and confusing articles referring to the GOF book itself.
I know it is obvious but i guess people still ignore the fact that documentation and knowledge sharing is important. Through my career as developer (so far 8 years) i have not joined a single project nor company that would have a proper up to date documentation. As a result it takes half year to catch up, instead of 3 months, for every new person joining the team and it causes constant headaches. I believe that could be improved if there was proper high / mid level documentation.
I know, I know, all the 'lazy developers' will jump and scream "but you should not waste time on documentation! code should document itself!". Well great, should IP addresses, web services, database schemas also document themselves? Being lazy is not a virtue, even that it seems to be cool.
From time to time I like to read some non technical books. It always gives you some new perspective on life and you can easily pick up on skills that were completely neglected : -)
10 Day MBA is very good book. It is written in simple and easy to read way. It provides nice overview of marketing, accounting, planning strategy etc. All the pieces you need to understand better how businesses work and how money is earned.
Joel on software is a very disappointing book. The amount of reviews this book gets, stating it is a 'must read', is just ridiculous. It is seriously a very average book.
I would not care so much but i bought the book and i feel it was not worth it, it is totally overrated.
Book could be described as random thought on Software Engineering and software development. Little bit of this and little bit of that. Some valid points and some gibberish i would not recommend. Book also has a lot of storytelling, little bit about this project and little bit about another. All in all very average piece on Software.