• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Who is the target market?

 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
From looking into the table of contents of the book I can guess that you are targeting IT Project Managers for your market.

Would I, as a busy programmer spending lots of time learning new technologies, benefit more from reading this book - or would I be better off studying more about the programming languages and tools I use?
 
Ranch Hand
Posts: 529
C++ Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Would I, as a busy programmer spending lots of time learning new technologies, benefit more from reading this book - or would I be better off studying more about the programming languages and tools I use?



If you are a programmer in the U.S., I would advise spending some time learning about product management. The days of the programmer are coming to an end. The future for U.S. programmers is innovation, management, etc.
 
Ranch Hand
Posts: 236
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As a developer, I can't speak highly enough about the wisdom, relevance and importance of just about everything in the "Pragmatic Programmers Bookshelf" series.

Let's face it - we benefit directly when the process works ... and we suffer the most when it doesn't.

One could argue that not only *should* developers read this book, but also they should be the *first* to read it. Who better to explain it to their managers ;-)?

IMHO .. PSM

PS:
The contest doesn't begin until tomorrow, but you asked a very good question - and I wanted to get my $0.02 in.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Paul Santa Maria:

Let's face it - we benefit directly when the process works ... and we suffer the most when it doesn't.



And, let's face it, we are the ones who make the process work (or don't). As a developer, I feel that it's *my* responsibility to enable management to ship the software I build early and often - and with confidence. (That's not to say that it's not also managements job.)

From the descriptions at Amazon, it sounds like that's what the book is about, and that it's quite clearly targeted at developers: http://www.amazon.com/exec/obidos/ASIN/0974514047/ref%3Djranch-20/002-5836327-9042432
 
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ship it! Is not a very long read (one or two sittings). But there is enough in there for programmers to make a purchase worthwhile.

I ended up reading Pragmatic Version Control using Subversion, Pragmatic Project Automation and Pragmatic Unit Testing with JUnit before this book. Anyone who hasn't read those books will probably find that they are the next logical step after Ship it!

If you are already scripting your builds (ex: ANT), automating your builds (ex: Cruise Control), and writing and automating your test cases (JUnit + ANT) then you will find this book an affirmation of those techniques. If you are not, then you are likely to be convinced to investigate the books I mentioned above.

There is also some interesting sections on the Trace Bullet development methodology and Real World "What if?" scenarios that are given solutions.
 
author
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by A Flatoff:
From looking into the table of contents of the book I can guess that you are targeting IT Project Managers for your market.

Would I, as a busy programmer spending lots of time learning new technologies, benefit more from reading this book - or would I be better off studying more about the programming languages and tools I use?



Hi guys. Sorry the late entry. Looks like a busy thread already!

The target audience of the book? We tried to put in information that could be used by developers ~and~ tech leads (or project managers). I've worked in both roles and we tried to pick out useful practices for both roles.

For instance, we talk about doing very small code reviews. Instead of large, formal code review, we suggest that you get your code reviewed in smaller chunks, several times a day. This helps to cross-train, share information, catch bugs, etc.

As a tech lead, you can make these mini-code reviews mandatory. However, as a developer on a team that doesn't code reviews, you can grab a buddy and still do your own code reviews. You will personally benefit from using this practice even if your team doesn't formally adopt them.

We tried to point out these types of dual use practices where ever we could. So the audience is both developers, testers and tech leads.

As to whether you should take the time to learn the sorts of things in the book... What's the fastest way to chop down a tree? Do you start chopping and keep chopping until the tree falls down or do you stop and sharpen your axe first?

In our experience, investing the time to set up tools like source code management, Continuous Integration, etc will pay you back very quickly.

Quite often we encounter certain pains for so long that we think they are simply part of doing our jobs. In reality, a lot of the pain in software development is not necessary. For instance, Integration Hell. Many people think that merging your code to the team's baseline has to be difficult. It's all they've ever seen. Put those same people in a shop using a Continuous Integration system and they can't believe what they are seeing. It takes a while before they actually believe that everything is working right. For the first few weeks, they keep waiting for the CI system to blow up.

You ought to see these same people around release time when the code is being covered by automated tests. They are used to seeing everyone panic.

Does that answer your question?
 
Paul Santa Maria
Ranch Hand
Posts: 236
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I really lke Ilja's observation:

As a developer, I feel that it's *my* responsibility to enable management to ship the software I build early and often - and with confidence.


You can buy all the books and tools, follow all the best practices, get all the CMMI certifications you want ...
... but if the staff doesn't feel a personal committment, it's definitely going to be a lot harder - and a lot less fun - than it needs to be.

IMHO .. PSM
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic