Norman L. Kerth
Use Team-Based Review Sessions to Maximize What You Learn from Each Project With detailed scenarios, imaginative illustrations, and step-by-step instructions, consultant and speaker Norman L. Kerth guides readers through productive, empowering retrospectives of project performance. Whether your shop calls them postmortems or postpartums or something else, project retrospectives offer organizations a formal method for preserving the valuable lessons learned from the successes and failures of every project. These lessons and the changes identified by the community will foster stronger teams and savings on subsequent efforts. For a retrospective to be effective and successful, though, it needs to be safe. Kerth shows facilitators and participants how to defeat the fear of retribution and establish an air of mutual trust. One tool is Kerth's Prime Directive: Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand. Applying years of experience as a project retrospective facilitator for software organizations, Kerth reveals his secrets for managing the sensitive, often emotionally charged issues that arise as teams relive and learn from each project. Don't move on to your next project without consulting and using this readable, practical handbook. Each member of your team will be better prepared for the next deadline.
This is a poll asking the Stackoverflow community what non-programming books they would recommend to fellow programmers.
Please post only ONE BOOK PER ANSWER.
Please search for your recommendation on this page before posting (there are over NINE PAGES so it is advisable to check them all). Many books have already been suggested and we want to avoid duplicates. If you find your recommendation is already present, vote it up or add some commentary.
Please elaborate on why you think a given book is worth reading from a programmer's perspective.
Note: this article is similar and contains other useful suggestions.
by Dale Carnegie
Although this was first published in 1936, the advice contained within is still as fresh and appropriate as ever. Don't be put off by the name. This isn't some underhand guide to having your way with unsuspecting victims, but rather common sense advice on how to get on with people, how to nurture relationships and make the most of yourself and your fellow man (and woman).
It is well known that technical folk (including programmers) are often thought of as not being terribly 'people oriented' (whether this is a justified stereotype or not is subject of another discussion) and so this book is an invaluable resource for teaching you the finer points of human interaction.
It's warm, heartfelt, sturdy, straightforward and timelessly written. Highly recommended.
by Eliyahu M. Goldratt and Jeff Cox
To elaborate: It is a book on how to approach problems. To identify bottlenecks in your system and work on them. So in short, it isn't a programming book, but shows (in novel format) how to problem solve -- and is thus very valuable to a programmer.
[Update Gishu] It's an eyeopener on how the throughput of your entire system depends on the bottlenecks. Optimizing other stages/operations will not produce any results. Although this is ingrained in developers who have had experience optimizing a scenario in their app; however zooming out to a more higher level and applying this can have profound gains. Beck's XP Book has a dedicated chapter on the Theory Of Constraints. Programmers who move onto Leads/PMs will find this a valuable addition to their toolkit.
This book will inspire anyone to think and be original.
for those more into game development.
This might not be a popular one, but
by Thomas Pynchon
Gravity's Rainbow is my favorite book of all time. I read through the whole thing last summer, and I'm in the process of reading it again. From a writer's point of view, it's pure, beautiful art. However, I recommend it here because it really forces the reader to think and make a lot of mental connections.
Of course, this book has a reputation for being impossible to finish. It's definitely the hardest book I've ever read. Pick it up at your own risk.
Don't Make Me Think by Steve Krug. An essential book about web usability. As Krug says, "Common sense isn't always obvious."
(Hint: Amazon.com has good usability)
Update: This is now part of the library at work. I've gotten about five people to read it so far. 100% positive reviews, predictably.
Here's a strange one for you all to think about.
It's a modern classic that everybody should read, and I'd be very surprised if English or Media Studies students weren't recommended to read it at some time. Reading should not only be informative and educational, but enjoyable as well. If you're not going to read a book for pure fun now and again then you'll only end up frustrated with the books you need to read as a programmer/developer.
This book is a real eye-opener; a book that'll really make you think about your own life, and for a programmer whom spends their day dealing with pure thought-stuff it's a great way to get you thinking on a different track.
It's a very fast paced action story that's excellent to clear your head with. It's a fun book to read (will make you laugh), and the characters are rather tragic (will make you feel more satisfied at work). This is one of those books that is hard to explain the content without fear that people will think you different and odd, but all the same you must tell everyone about (I.e. makes you talk to people).
The Humane Interface by Jef Raskin.
Questioning the Unquestionable and Thinking the Impermissible
by James P. Hogan
God programmer meet God marketing guy, and no it's not Steve Woz and Steve Jobs, but it's the Johns, Carmack and Romero.
Business, gaming and programming all rolled into one. a definitely page turner all the way until the end.
by Fred Brooks
My personal opinion is, apart from programming, in life we need to find a balance, about everything (or keep striving for it). Many times, I have found myself getting too immersed in one aspect of life (frequently programming/work) at the cost of others. Over the years I have learnt to recognize this and act accordingly.
In work, sometimes I have come across pretty difficult people, making it hard to work with them (not just my opinion, but also of other team members). Previously I used to try hard to convince them, make them more helpful, etc. and get frustrated when I don't succeed.
But this book Tigana, by Guy Gavriel Kay helped me understand that sometimes a person can be inherently complex, hard to work with, without he/she helping it. It is a science fiction novel, and it may not be completely appropriate here, but it helped me work better with my team, so I am linking to it here. It helped me become more objective in dealing with people I work with.
Jeffrey K. Liker - The Toyota Way (Amazon link). A good if at times semi-boring read, but loads of information from the company which invented Lean.
Games People Play by Eric Berne.
IMHO it is a very useful aid to understand and deal with office politics (among others).
We think we’re relating to other people – but actually we’re all playing games.
Forty years ago, Games People Play revolutionized our understanding of what really goes on during our most basic social interactions. More than five million copies later, Dr. Eric Berne’s classic is as astonishing–and revealing–as it was on the day it was first published. This anniversary edition features a new introduction by Dr. James R. Allen, president of the International Transactional Analysis Association, and Kurt Vonnegut’s brilliant Life magazine review from 1965. We play games all the time–sexual games, marital games, power games with our bosses, and competitive games with our friends. Detailing status contests like “Martini” (I know a better way), to lethal couples combat like “If It Weren’t For You” and “Uproar,” to flirtation favorites like “The Stocking Game” and “Let’s You and Him Fight,” Dr. Berne exposes the secret ploys and unconscious maneuvers that rule our intimate lives. Explosive when it first appeared, Games People Play is now widely recognized as the most original and influential popular psychology book of our time. It’s as powerful and eye-opening as ever.
As well as the mentioned Gadwell's Tipping Point, Blink is a good choice.
A Brief History of Everything by Ken Wilber.
In the ambitiously titled A Brief History of Everything, Wilber continues his search for the primary patterns that manifest in all realms of existence. Like Hegel in the West and Aurobindo in the East, Wilber is a thinker in the grand systematic tradition, an intellectual adventurer concerned with nothing less than the whole course of evolution, life's ultimate trajectory—in a word, everything. . . . Combining spiritual sensitivity with enormous intellectual understanding and a style of elegance and clarity, A Brief History of Everything is a clarion call for seeing the world as a whole, much at odds with the depressing reductionism of trendy Foucault-derivative academic philosophy.
The Fountainhead by Ayn Rand. Atlas Shrugged is already on this list, but the Fountainhead deals more with craftsmanship and integrity, rather than supply-side economic theory. Definitely worth a read for anyone in a creative field.
Could not put this one down, The Evolution of Cooperation by Robert Axelrod. Its a fascinating read and as game theory books go it's pretty accessible.
Snow Crash By Neal Stephenson
Ender's Game by Orson Scott Card
An analysis of the 12 worst Supreme Court decisions
Great and interesting book about how our liberties are being trodden on by the government. Libertarian viewpoint, but objective.
Burton G. Malkiel
Nothing else will teach you better how to get a handle on your money.
Niccolo Machiavelli's The Prince. After wondering why people acted so strangely at work, this book was the first of many, that taught me why.
How was JPod not posted? It's like a (already posted) Microserfs with internet. It's typical Coupland novel, must read for every techie, geek, webz hipster.
Here are some quotes
"You googled her?" "Of course I did. Didn't you?" I'd somehow forgotten to perform this essential task.
“After a week of intense googling, we’ve started to burn out knowing the answer to everything. God must feel that way all the time. I think people in the year 2020 are going to be nostalgic for the sensation of feeling clueless.”
“It turns out that only twenty percent of human beings have a sense of irony – which means that eighty percent of the world takes everything at face value. I can’t imagine anything worse than that. Okay, maybe I can, but imagine reading the morning newspaper and believing it all to be true on some level.”
Nothing too programmer-specific, but being in the industry that we are, it helps immensly to have a positive mindset depicted in this book.
Note: I had to move this book from my previous answer to here, to comply with the question's specific rule that one post -> one answer
This is probably not going to be popular, but "If liberty means anything at all it means the right to tell people what they do not want to hear."
by Neal Stephenson
It's very dated, but I have yet to find a single book (or essay for that matter) that gives a quasi-outsider's view of an industry that the public is apathetic to understand. The insights and descriptions are spot-on, even though the conditions have dramaticly changed over time.
by Alan Cooper
It's about using the right language to talk about projects - using stories (and personas) instead of 'features' to talk about stuff that needs to be realized. Also a lot of emphasis on interaction design and related activities. Delivering what is needed instead of what is asked for.
Also read these free manifestos
(Note: moved the other book to a separate answer)
Awaken the Giant Within by Anthony Robbins.
This book as about why stock markets are not predictable like casinos and the lottary. It is very readable though querky. It will help you to understand when statistical techneques do not work, why math is not understanding, why project managers can't predict schedules and how they can with less effort.
The book does not go into heavy math but will give you a feal for when the math can and more ofter can not be used.
Author: Nassim Nicholas Taleb. Also wrote 'Fooled By Randomness'
Read it if you work with mathematics, statistics or finance - Or if you have a pension.
Simon Singh's Fermat's Last Enigma is one of the greatest books I have ever read.
This non-programming book has taught me a lot about running after the solution of a problem, no matter how old and complex it is.
by Roger Penrose
Somehow in the line of Godel, Escher, Bach but, I think, easier to read.
Dealing with people you can't stand:
Dealing with People You Can't Stand: How to Bring Out the Best in People at Their Worst (Paperback) ~ Dr. Rick Brinkman (Author), Dr. Rick Kirschner (Author), Dr. Rick Kirschner (Author), Dr. Rick Brinkman (Author)
Sensation & Perception by E. Bruce Goldstein will really pull a lot of software engineers out of their comfort zones. I found it to be fascinating when I started thinking about effective scientific visualization techniques with the user's physiology and psychology in mind. Issues with the user's potential for color blindness, visual acuity, attention span and information processing abilities are just some of the reasons why I keep going back to this book.
If you're a Python developer, you will not get around viewing Monty Python stuff. But to quickly look up a quote you find in any Python doc, I really recommend those:
(as well as part two, they're great; Amazon) and
Reading doesn't give you the great look of a puzzled Michael Palin or the anger of a furious John Cleese, but it still is a worthwhile lecture.
by Tracy Kidder
"The Ultimate History of Video Games" of course!
Why? Because in one book you get history, fun, anecdotes, business decisions, project management, opinions, wonderful quotes, the hardware and the software ... all in all portraying an industry that went through numerous cycles, ups and downs, deaths and reincarnations. But most of all: Steven Kent managed to make this book a very entertaining read, you'll be captivated by each chapter.
This is similar to another question. Here is a link to my answer over there.
Now, Discover Your Strengths is my favorite personal/career development book. It teaches the most successful people become successful by focusing on building on their strengths, rather than covering up weaknesses. This book helps you find out where your strengths lie.
by Tom DeMarco and Timothy Lister
Great background on what managing risk means and lots of good tools for quantifying risks. They discuss a risk estimation tool which uses statistics to produce a pragmatic and reality-based understanding of the effects that risks will have on a given projects completion date and confidence level.
The prologue on "The Ethics of Belief" is not to be missed.
Concise, bare essential and time-less!
The First Quarter : A 25-year History of Video Games. Unabashed old-school video game geekery.
by Gabriel Garcia Marquez
by Steven Levy
Does a great job of outlining some of the eras in computing, from the enviroment that sprung up around the Tech Model Railroad Club at MIT, to the Homebrew Computing in the bay area, to the story of the game companies of the early 80s. Especially the MIT section has wonderful descriptions of hackers at work, doing what they do best (in a wholly non-technical writing style), bumming instructions, making the machine do their bidding, and in the mid-seventies, it describes the self-made community of hardware hackers (including Wozniak), who built their own computers. Hugely entertaining, and a good way to understand where some of these communities originate from (academics, hackers, tinkeres).
If you don't want your job to be outsourced (as have happened to many programmers) then you need to read this book, A Whole New Mind - Why Right-Brianers Will Rule The Future, actualize it, and put it into practice yesterday!
I would recommend: "Code" by Charles Petzold.
It completely opened my eyes on how computers actually work, explained and illustrated clearly. I learned that computers have no inherent understanding of numbers, letters, words or anything like that. These were human concepts and it was up to the computer programmer (at a very low level) to present they patterns of bits from computer memory to something users would find meaningful.
Despite its title, "Code" has nothing to do with coding, but explains how computers work at the electrical level.
by Tom DeMarco and Timothy Lister
This classic book encourages us to think about the people instead of the process. It's full of practical advice on team building, productivity and office environments. It's a must read, not just for managers, but anyone related to software development.
Get two copies, one for you and one for your manager.
by Robert M. Pirsig
This book is many things, but you could say it's sort of a philosophical take on what it means to "grok" something.
Commentry from Garth Gilmore:
I credit this book with teaching me more about software development than any programming book I ever read.
The central thread in the book is how our romantic (artistic) and classical (technical/rational) perceptions of the world are both derived from how we perceive quality in the environment around us. This understanding is then applied to apparently mundane tasks like motorcycle maintenance.
To give some examples of how this applies to coding:
Long story short its a good read :-)
Simon Singh's The Code Book is a great book about how cryptography was born and how people is always trying to challenge it.
by Douglas Adams
Life, the universe, and everything
"See first, think later, then test. But always see first. Otherwise you will only see what you were expecting. Most scientists forget that." -- Wonko the Sane
by Keith Ferrazzi
Comments from duplicate answer by Flory:
I did not think that I would like it before I got the book but I really enjoyed it. It is basically about how to build a relationships. Prior to reading it I expected it to be very trite and about how to use people for your own ends. Instead it was the opposite in how to be used to everyone's ends. Very interesting.
What is the name of this book?, by Raymond Smullyan. It is a wonderful book of puzzles about the intricacies of logic.
by Michio Kaku
There's a lot of space out there to get lost in.
-- John Robinson, Lost in Space
A Short History of Nearly Everything by Bill Bryson
by Neal Stephenson
This book follows parallel stories of a World War II code breaker and his present day descendant, and deals a lot with the development of computers (Alan Turing is actually a character in the book). A geek's must-read!
Stranger in a strange land because every programmer should grok the word "GROK".
Lessons Learned in Software Testing by Kaner, Bach, and Pettigrew. Brilliant book, easy to read.
The Thermodynamics of Pizza by Harold Morowitz.
This could have all kinds of morals, depending on how you take it. 1. You can use science to improve EVERYTHING! :-) 2. Make sure you choose the right level of abstraction when designing and coding. 3. You can really improve your life if you just take a few minutes to think about it.
by David Allen.
Written in 1966 this classic science fiction novel takes place on the penal colony Luna (the moon). The story is told by the only programmer/computer repairman on Luna, Manuel. Manuel has a secret. The master computer (Mike) that controls all of Luna has become a sentient AI and happens to have Manuel as its only friend. Mike is rough around the edges at first, its speech is fuzzy and it plays childish but dangerous jokes with its god-like abilities. As time wears on Mikes abilities fully develop into a mature being. With Manuel's guidance they will go on an adventure together that spurs the revolution of freeing Luna from Earth!
This novel is the first Robert A. Heinlein novels I have read but will certainly not be the last. The fact that this book was written in 1966 still astonishes me! It has barely any dated parts and could easily pass for a contemporary novel. It wont he Hugo award for best novel.
Truly one of the better "programmer" style novels I have read. Great adventure the whole way through. If anyone has a suggestion as to which Heinlein novel I read next, please leave a comment!
Written in 1950, Dianetics: The Evolution of a Science describes the optimum computer as an introduction to a science of the mind.
by George Orwell
by Mark Haddon
It will give you some perspective of your odd co-workers.
This is an amazing book that details some very counter-intuitive conclusions about the LACK of THINKING actually predominates our decision process.
Player Piano by Kurt Vonnegut
Beyond Fear by Bruce Schneier.
From Amazon: "Schneier provides an interesting view of the notion of security, outlining a simple five-step process that can be applied to deliver effective and sensible security decisions. These steps are addressed in detail throughout the book, and applied to various scenarios to show how simple, yet effective they can be....Overall, this book is an entertaining read, written in layman's terms, with a diverse range of examples and anecdotes that reinforce the notion of security as a process".
Or just consider it a straight read on understanding what security means - whether for computers or in real life. It can give you the tools to handle the ginormous amounts of FUD we encounter every day.... And it's entertaining, besides. (Even got my father to read it, and he's enjoying it...)
Universal Principles of Design, by William Lidwell, Kritina Holden, and Jill Butler
One of this biggest issues I have with many programs I have used is the lack of design put into the interface and into the product. This book goes in-depth describing how to enhance the usablilty within a interface. It also tells you all of the basic principals and rules of design, and they give many examples for many different applications whether its techinical or non-technical. The book reads a little like a college classroom book (and it probably is for many design schools), so it the not the most exciting thing to read, but I find the most informative when it comes to interface design.
One notable premise contained within this book reminds me of the saying "If you go far enough away, then you're on your way back home". For example, the Eastern and Western approaches to philosophy and science were so diametrically opposed for centuries but perhaps they're coming around the other side towards similar conclusions these days?
It may be 30 or so years old, but it's still very much worth the read.
I can't believe I didn't see this already listed:
by Frank Herbert
Dune is the pinnacle of Sci-Fi novels!
I've been really enjoying haiku recently. To that end, I'd very strongly recommend The Haiku Handbook: How to Write, Share, and Teach Haiku by William J. Higinson.
I recommend reading/writing haiku as a way to relax.
The Tipping Point is one of the best books that I have ever read.
by Lynne Truss
Becoming a better communicator in people language, I believe, makes you a better communicator in code. Punctuation is a very good place to start improving your writing.
Every programmer should read this book to learn how to pick up women.
Information theory, betting, value of information, etc.
by Mihaly Csikszentmihalyi
The best and most productive coding is done in a flow state. This is a psychological study of the phenomemon. Although the book is scientifically rigorous it remains accessible to the lay-person.
21st Century Jet: The Making of the Boeing 777, by Karl Sabbagh
From coffee cup holder to three-hundred-foot wing, this book is the story of how a group of people came to build a brand new aeroplane.
The book describes the development of the Boeing 777, from initial concept, through requirements gathering, design, development, testing, production, and delivery. The engineers and management implemented a new development system, overcame changing requirements, met strict safety requirements, and continually optimized the solution. It describes how the designers and engineers worked to make the aircraft easier, safer, and more intuitive for everyone who would come in contact with it (air crew, maintenence crews, and passengers).
Software developers can learn a lot from this book. It's very well written, it reads like a novel. I've read it twice and highly recommend it.
Boeing Computer Services president John Warner said, the Boeing 777 is "three million parts flying in close formation." Sounds like software to me.
Charles Perrow's "Normal Accidents" investigates what can happen when complex technology goes horribly wrong, and formulates his theory of the "normal accident": complex, tightly coupled systems will have accidents, because minor faults interact with catastrophic consequences. We see this all the time in programming and systems administration, and yet, as far as I know, few of these concepts are understood outside safety engineering.
(He also writes very well, and brings life to what could have been a rather dry book).
by George Lakoff
It's a book about how people categorize things, and about reasoning in general. It's long and extremely boring for some people, but it is still great.
If you live on the Unix side of the world, The Art of UNIX Programming by Eric Raymond (see also here). Despite its title, it is not a programming book, and it contains very few lines of code indeed. It's the best book I know about the Unix philosophy.
I found Zero: The Biography of a Dangerous Idea to be pretty decent. He has a followup to this called Decoding the Universe: How the New Science of Information Is Explaining Everything in the Cosmos, from Our Brains to Black Holes which I have but haven't read yet so I can't comment on how it is.
Secret Rendezvous by Kobo Abe. Abe's the frickin' man, man.
But seriously, if you like Murakami, you owe it to yourself to check out Abe.
Happiness is a Choice by Barry Neil Kaufman
It's a great book that can help you understand you can choose how to feel. Turns out you can be responsible for a lot more of your emotions than you think.
Another one from a different angle from prior posts: Gödel, Escher, Bach: an Eternal Golden Braid, by Douglas Hofstadter.
I can not believe this book has never been mentioned!! It is one of the best book about product management I have read in years. If you are working for a startup, it is a must read.
The Milkshake Moment: Overcoming Stupid Systems, Pointless Policies and Muddled Management to Realize Real Growth by Steven Little
The Right Stuff by Tom Wolfe
Walter Murch's "In the Blink of an Eye"
Or any other Speed Reading text. Learning my own quirks about how I read has helped me to be conscious of other aspects of how I think. Having the ability to control my reading speed has proven to be invaluable. I still choose to read books for pleasure at my previous reading speed with all its flaws.
The Illuminatus! Trilogy by Robert Shea and Robert Anton Wilson. In many ways, this book changed the way I do my thinking. Not sure whether it is good or bad to completely distrust anything and everything, but at least it keeps ones mind critical instead of automatically accepting something as truth without questioning.
The book also introduced me to the concepts of discordianism, which I find having quite a few interesting points.
I just bought it on Audible last week and I can't stop listening to it. It goes through the factors of successful people (ex: Bill Gates, Bill Joy, The Beatles). Fascinating!
by Hugh Sebag-Montefiore
Having a bad week at work? Well at least when you can't figure out some algorithm people aren't dying in their hundreds in the freezing North Atlantic waiting on you to work it out.
As well as being a great read about the dawn of the modern computing age, this book can help with perspective.
A great book about the development process. It also highlights how developers are doomed to keep repeating the same mistakes over and over again
Juggling is mandatory. All programmers must juggle. Sorry, it's a rule.
Rick Cook - The Wiz Biz
This is a compilation of the first two novels in a series, called 'Wizard's Bane' and 'Wizardry Compiled', respectively.
It all began when the wizards of the White League were under attack by their opponents of the Black League and one of their most powerful members cast a spell to bring forth a mighty wizard to aid their cause. What the spell delivers master hacker Walter "Wiz" Zumwalt. With the wizard who cast the spell dead, nobody can figure out what the shanghaied computer nerd is good for--because spells are not like computer programs.
Lots of in jokes for the Unix/Linux crowd to enjoy. Pretty much anybody in the software industry will enjoy it, I think.
What concepts in Computer Science do you think have made you a better programmer?
My degree was in Mechanical Engineering so having ended up as a programmer, I'm a bit lacking in the basics. There are a few standard CS concepts which I've learnt recently that have given me a much deeper understanding of what I'm doing, specifically:
Obviously, the list is a little short at the moment so I was hoping for suggestions as to:
I find it a little funny that you're looking for computer science subjects, but find wikipedia too academic :D
Anyway, here goes, in no particular order:
As a recent graduate from a computer science degree I'd recommend the following:
As mentioned in various posts Big O notation
Data structures & Algorithms (can't remember the exact title of the book I used will update if i remember)
Operating Systems http://www.amazon.com/Modern-Operating-Systems-2nd-GOAL/dp/0130313580
Some of the OS concepts
( memory, IO, Scheduling, process\Threads, multithreading )
[a good book "Modern Operating Systems, 2nd Edition, Andrew S. Tanenbaum"]
Basic knowledge of Computer networks
[a good book by Tanenbaum
A programming language ( I learnt C first then C++)
Algorithms ( Time\space complexity, sort, search, trees, linked list, stack, queue )
[a good book Introduction to Algorithms]
I've had some interesting conversations recently about software development metrics, in particular how they can be used in a reasonably large organisation to help development teams work better. I know there have been Stack Overflow questions about which metrics are good to use - like this one, but my question is more about which metrics are useful to which stakeholders, and at what level of aggregation.
As an example, my view is that code coverage is a useful metric in the following ways (and maybe others):
But I don't think it's useful for senior management to see this on a team-by-team basis, as this encourages artifical attempts to bolster coverage with tests that merely exercise, rather than test, code.
I'm in an organisation with a couple of levels in its management hierarchy, but where the vast majority of managers are technically minded and able (with many still getting their hands dirty). Some of the development teams are leading the way in driving towards agile development practices, but others lag, and there is now a serious mandate from the top for this to be the way the organisation works. A couple of us are starting a programme to encourage this. In this sort of an organisation, what sort of metrics do you think are useful, to whom, why, and at what level of aggregation?
I don't want people to feel their performance is being assessed based on a metric that they can artificially influence; at the same time, the senior management are going to want some sort of evidence that progress is being made. What advice or caveats can you provide based on experience in your own organisations?
We are definitely wanting to use metrics as a tool for organisational improvement not as a tool for individual performance measurement.
Interestingly I just finished reading PeopleWare, and the authors strongly discourage individual metrics being made visible to superiors (even direct managers), but that aggregate metrics should be very visible.
As far as code specific metrics I think it's good for a team to know the state of the code at the current time, and to know the trends affecting the code as it matures and grows.
The question is obviously not focussed on .NET, but I think the .NET product NDepend has done a lot of work to define and document common metrics that are useful.
The documentation section on metrics is educational reading, even if you're not doing .NET.
I've been working with my manager to move myself from a designer/programmer role in to a lead designer/programmer role.
I have several years experience in programming. I've not became that "super" programmer that I've always wanted to be but my manager said that he thought I'd make a good team lead; I’ve since been put in charge of a couple of projects that I feel are going well.
My question is about what makes a good team leader. I know that I could use tips and pointers to improve myself and so I want to ask:
It's all about the people. A great leader understands that. I would just suggest reading the classic:
Putting aside potential objections to the idea of a non-programmer having to manage programmers (needs must in a small software start-up), what should the non-programmer try to learn about how to better work with the programmers? This is me.
I say 'non-programmer', but actually I have spent a few years in the industry and have tried to read and self-educate because I find the stuff interesting and I aspire to learn more. But, reality is that I cannot write code to a professional standard and I know it'll take a while to build up such knowledge, and people tell me I shouldn't even try. Perhaps the coders would rather someone like me just keeps the hell out. If not, is there a particular direction I should take in my self-study, which would make me more effective?
I've read Joel's book and he has plenty to say about, for example, giving coders good working conditions. I'm not asking here about that aspect of management - my question is really a question about whether there are some particular technical skills I should aim to acquire rather than just continuing my unstructured 'wandering' around things that interest me.
If you haven't read Peopleware, you should definitely read it. It deals with your issues. In short, it explains that a manager's job is not a technical job (although of course it doesn't hurt if (s)he is knowledgeable about technical aspects of the development). The manager's main task is communication, not dealing with technology. Your main concerns are, among others:
That's what you do better than them - and all of these are "people" issues, rather than technical tasks.
I don't mean that you shouldn't try to learn more about or practice coding yourself - just that it may not make you a better manager, and does not necessarily help your project succeed.
I'm baffled by the responses to another question that say you shouldn't bring a code portfolio to a programming job interview.
“It would be ludicrous to think of hiring a juggler without first seeing him perform. That’s just common sense. Yet when you set out to hire an engineer or a designer or a programmer or a group manager, the rules of common sense are often suspended. You don’t ask to see a design or a program or anything. In fact, the interview is just talk.”
So, what gives ? Any "war stories" of what went wrong when you showed up with a code portfolio ? Or of when you interviewed a candidate who had one ?
I am a really young software engineer/QA Team leader. I have been developing software for about 2 years and for 1 of those years I have also been the head of the QA team at a software development company. Currently I am still working as the QA team leader/software engineer for QA tools. Recently I have been invited to join a group of friends and associates who would like to start a software company. They want me to be the architect/tech lead of the software (a special chat client written in Java is all I can say about it). I am very good at learning under fire and I learn a great deal by doing. However, I worry that my lack of experience will cause the project to fail (or at least be developed poorly). So I am wondering would you suggest I take the position, do my best and learn as I go? Or would you suggest I refuse?
If you would suggest I take the position would you please provide one or to resources that would be good for a beginning Java Architect?
I want to know if others have experienced the situation where people around you are very smart and have few star programmers but as a team you are still struggling to move. I am not talking about people with arrogance/pride or social handicap.
Does motivation to create shared vision of product play any part?
I understand the value of Star programmer and teams but what I am really looking for is when even in the presence of such teams, product team is not reflecting that! Have people experienced such situation?
As others have said, no visible progress in terms of lines of code, etc. does not necessarily mean that no progress is being made.
Having said that, yes, I've been in situations where there were plenty of good people, some stars, but things moved slowly or not at all. That can be a result of many factors: "corporate knowledge" (i.e. is there any one around who knows how things were done and why), proper background/training/aptitude/interest for the jobs people are assigned, support of and clear direction from management, autonomy, that shared vision thing, and other things.
As for team building, there's more to it that just having a star programmer or two. To wit, in sports, it's not uncommon for even bad teams to have a star player or two. It's often how the whole group interacts that determines how successful it is. So, do you have a team, or - as I think Casey Stengel said - "an interesting collection of individuals"? If you're not already familiar with it, I'd recommend reading DeMarco & Lister's Peopleware. It's a classic that deals with team building, amongst other things.
I experienced to work with the code which was reviewed, but still of low quality. Actually reviewer looked through the code and could think that this is more formal procedure and didn't pay enough attention to the process of review and said: "I have reviewed the code!". Some small fixes can be made but significant flaws are missed.
The problem is to explain that it is important to make the thorough review, because in future this code is easier to support, extend, fix, easy to reassign to other person etc...
But all these reasons are not essential for reviewer. Responsible for code is another person. Oh, author of code can leave company? Reviewer didn't think about this. Company spend more time to fix bugs when they reproduced by tester? it doesn't mater for reviewer. Some things are not documented? Author explain this to the reviewer. And reviewer even can support effectively such code. others... others...
Start with the Macadamian Code Review Checklist. Edit and adapt it to suit your specific needs. This way you will have specific guidelines for reviewers. If possible, reviews should follow The Ten Commandments of Egoless Programming. Other than that - invest in team building. Peopleware is a good source of ideas. The Psychology of Computer Programming is another.
I have been working at entering and sustaining periods of flow while working, and while researching the concept I came across this site which addressed the idea of sustaining flow in short bursts. The technique specifies that one sets a timer for 48 minutes in which they focus purely on their work, and when the timer runs out they spend 12 minutes doing whatever.
However, in the paragraph directly above that statement is a quote from Peopleware saying that it takes at least 15 uninterrupted minutes to enter a state of flow.
When reading that point, the 48 minute technique seemed counter-intuitive, since every 48 minutes you are "breaking" your flow, and once you start up again you have to spend 15 minutes going back into it, so you really only get (at a maximum) 33 minutes of "flow time". Obviously these quantities aren't necessarily rigid, but you get the idea.
My question is to those who have tried a timing technique similar to the one described. As I see it, the only justification for this technique is that it possibly reduces the amount of time it takes to re-enter that period of flow. Can anyone who has used this technique provide some clarification?
I've tried the Pomodoro Technique for a week or so. I didn't focus too much on the details of maintaining check lists of completed and interrupted sprints, but rather I started the day with the tasks that I wanted to do on that day, and went through them as best as I could using the 25-minute sprints and five-minute breaks.
The Pomodoro Technique suggests to use the breaks to relax, stretch your legs, grab a coffee, etc. I've noticed that activities like those that don't require a total focus shift and can be done on automatic don't break the flow, but rather helped me cleanse my mind and refocus my attention. It's as if you're allowing yourself to step away from the trees to survey the forest for a bit before diving back in.
I dropped Pomodoro after that short trial period because I found that in my case I got the most benefit from simply sitting down in the morning and writing down what I wanted to do on that day. Once the decision is made and the work is started I found that I fall into a natural rhythm of sorts. I work until I'm bored, frustrated, or interrupted, then I take a break and continue. I didn't find that time boxing my sprints added much value.
YMMV, but it's worth at least giving it a try.
In a workplace where many people (including management) feel long hours is the way to demonstrate commitment, what are effective arguments that such practices are harmful, not just to the team members themselves, but to the project itself?
I am familiar with - and I believe - the common arguments: the risk of burnout, compromised quality, insufficient attention to keeping our skills up and our code malleable. But what arguments are most persuasive? What is the most persuasive way to deliver them?
Update Thanks, everyone, for all the great links to data - it's helpful, but what I'm really after is what arguments will be persuasive to people who are deeply invested in the crunch-mode ethic. I think I need more than data to shake loose their preconceived notions.
If you have $100 in your hand right now. And have to bet on one of these options. That would you bet it on? The question is:
What is the most important factor, that determents the cost of a project.
Update: Ok, just for the record. This is the most stupid question I ever asked. The question should be. Rank the list above. Most important factor first. Which are the most important factor. I ask, because I think the character count matters. Less character to change when requirements change. The faster it's done. Or?
UPDATE: This question was discussed in Stackoverflow podcast #23. Thanks Jeff! :)
[For a software project], size is easily the most significant determinant of effort, cost, and schedule. The kind of software you're developing comes in second, and personnel factors are a close third. The programming language and environment you use are not first-tier influences on project outcome, but they are a first-tier influence on the estimate.
I don't think you accounted for #3 in the above list. There's usually an order of magnitude or more difference in skill between programmers, not to mention all the Peopleware issues that can affect the schedule profoundly (bad apples, bad management, etc).
I've always used Subversion or CVS for version control, which use a 'merge' methodology. One of my friends raves about Perforce and how great it is with its change lists and check-out methodology.
While I'm sure a lot of it comes down to experience & personal preference, I was wondering if any research had been done into which method of version control is more efficient to work in?
EDIT: To clarify, I know both Perforce & SVN allow locking & merging, but SVN 'encourages' a liberal edit & merge method, whereas as I understand it, Perforce encourages a checkout-checkin method.
I definitely prefer the merge methodology.
I've used Visual Sourcesafe (hopefully never again), CVS, subversion and bzr. Visual sourcesafe enforces the "checkout before editing" methodology and can be painful. CVS and subversion haven't been great at accepting merges historically, though I hear subversion 1.5 has improved that.
I would recommend using a VCS that has been designed with frequent merging in mind from the start. bzr is the one I've used that does this, but the other major distributed vcs systems (git and mercurial) also do.
But ultimately I don't know of any research on this specific area. In general there is very little research into efficiency of programming, Peopleware being one of the notable exceptions.
I believe that Tom DeMarco (the author of Peopleware and other light classics ;-) has developed and published a formula that relates the project effort and the optimal team size.
I think that he uses it to mathematically derive Brooks law: "adding more people to a late project makes it even later".
Can someone tell me what the exact formula is and in which book or article it is published?
Thanks in advance.
Empirical evidence has shown that the optimum number or resources (personnel) that can be devoted to a project to shorten its calendar time is about the square root of the number of man months of WORK estimated to complete the project. Therefore, if you have a 10 man year project, or 120 man months, about 11 people is the number you can effectively assign to the project, eleven being the square root of 121, for those of us without a calculator handy.
According to the references of the page, this formula must be from Peopleware.
I have been a software developer for a while but was not interested in the above topics, currently I am put in the position of wanting to learn more about them but don't have a clue where to begin.
I have done task estimations and I can do decent ones, but have little/none experience in the field of budget/product pricing and would want to learn more.
Do you have any suggestions of good resources that I could look up in order to learn more (eg. books, blogs, ...)
This need arised while talking to a friend about management and he brought up management terms that I wasn't aware of (eg. KPI, ...)
Project Management with Respect to Time and Budget
There are a couple of books you should check out:
Joel Spolsky posted a quick estimation technique.
I found this software project management blog.
I attended a Project Management class (as part of a Masters in Technical Management) and they used the Project Management: A Systems Approach to Planning, Scheduling, and Controlling book. It is a very dry book but has a ton of very useful information; luckily our professors were pretty good at their job (one topic that helped me a lot was dealing with conflict -- but that has little to do with estimation and budget which your question seems to focus on).
I think that the book, Micro-ISV: From Vision to Reality, discusses that. Basically, you should already have established a relationship with some people that represent your customer base and who have cobbled together a crappy solution. If your software represents an elegant solution that fixes their needs, you ask them 1) would you use this if it was free? If they say yes, then you ask them 2) Would you pay a million dollars for it? At which point they'll say, no way, the most I would pay would be $500 (or whatever) -- that's one way to price your product. :)
If you are going to be managing people, read these books:
I'm wanting to get better/more accurate at time estimates/durations for larger projects and am looking for any good books/resources that could assist.