The Pragmatic Programmer

[ManiacD]

Hey all

My copy of the Pragmatic Programmer arrived in the post today so I'm ready to go.

I do have a couple of questions

Do we have an agreed start and end time to read it by yet?

How will the discussion on the books be formed.  Will it be under agreed subject format (ie. The Pragmatic Programmer - Chapter 1 or Part 1 Discussion) so that our slow readers out there aren't accidentally influenced by discussions on later chapters that they haven't read yet?

Will the next book be decided on at the end of the current book time frame allowing a couple of weeks for people to obtain that book or will it be decided during the current book reading time frame so that the next book will be ready to start at the end ie. No breaks between.

Anyway pretty keen on the whole idea as it'll give incentive to finish 1 book before starting on another.

[Michael Minutillo]

Well I defer to the wisdom of the crowd (they procrastinate better than I do). I'd say:

Everyone start now! If you have questions/comments/insights/etc. put them straight up. It'd be handy if threads are marked with some indicator of where in the book they relate to but I wouldn't be too religious about it. We are reading technical advice and not Agatha Christie novels. I'd like there to be some break between books just for sanity reasons. Discussion is likely to go on after the book is finished and with shorter books like this one people would end up buying 40-50 books/year which is cool but not sustainable for everyone (myself included unless someone wants to buy a kid). Not sure about end date. I'd leave it until the discussion starts to die down a bit.

Aaaaaaaaaaand Go!

--
Michael M. Minutillo
Indiscriminate Information Sponge
Blog: http://wolfbyte-net.blogspot.com

[Xerxes Battiwalla]

just throwing in my 2c worth...i generally have a habit of taking notes whenever I read books like this. if anyone is interested in following, i'm posting my notes up onto my tumblr:

http://tumblr.xerxesb.com/tagged/ThePragmaticProgrammer

[Xerxes Battiwalla]

so am i the only person who completely and wholly failed this really basic task?

The book is sitting on my desk at work with a bookmark about 20 pages in - hasn't progressed since May. :\

[Paul Batum]

I totally forgot about this. But in my defense I've already read the book and was planning on re-reading bits and participating in the discussions, of which we have had very few :)

I blame Michael! :D

[Michael Minutillo]

Outrage. I challenge you to a weetbix eating competion on board the QE2.

Also, yes, many of my projects have suffered greatly this year and this is one of them. Do we want to reboot this with this or another book? I think the idea still has some merit.

[Xerxes Battiwalla]

i know from my point of view that if i don't set myself a little milestone and am forced to achieve it in small iterations, it will probably just sit on the backlog. (yes, my life sounds like an agile project).

[Stonie]

I read it years ago ;)

and yes you should finish it. :)

[Dave Hng]

Yep same here, read it a while ago and really like the book. Whenever
you guys want to start discussing things i'll chime in :)

One of the topics I really liked was 21: Design by Contract. It's been
really useful in one of the products that i've been working on at the
moment because we have a pretty hostile interface: our system needs to
talk to many external systems and the interface specs are
(unfortunately) loose. It's pretty good to be paranoid because
sometimes external systems change, things break and the customer
starts pointing fingers and the blame game commences :)

Once you're in that situation, it's good to be able to analyse the
system and identify what's going wrong. We use preconditions to check
that the incoming data's sensible (e.g. within range) and log the data
so we know what's happened. So when the customer has problems, we can
go in and check the logs, identify the problem (even if it's not ours)
and then start working out how to fix it.

That might sound like a pretty basic thing, but it's been so helpful
in sticky situations that i'd like to make a point of it. :)

On Sep 8, 10:01 am, Stonie <and...@stonie.net> wrote:
> I read it years ago ;)
>
> and yes you should finish it. :)
>

> On Wed, Sep 8, 2010 at 7:11 AM, Xerxes Battiwalla <xerx...@gmail.com> wrote:
> > so am i the only person who completely and wholly failed this really basic
> > task?
>
> > The book is sitting on my desk at work with a bookmark about 20 pages in -
> > hasn't progressed since May. :\
>

[Paul Batum]

I agree the idea does have merit. Regardless of whether we switch books or not, the important thing is that there is at least one person committed to reading a chapter every couple of nights and then posting "so I read chapter X and it says Y but I wonder what you guys think about Z" - I think if we can get that, it'll take care of itself.

[Peter Gfader]

Hi All

I am currently in chapter 7 of Pragmatic Programmer, but would like to start the discussion about chapter 1

My 2c on chapter 1 and the tips 

Tip 1 : Care About Your Craft

Nuff said.. 

Tip 2: Think! About Your Work

This is something I do way too less, and most others I work with as well. 

We just want to get started, code or hack something together. 

But thinking beforehand saves lot of time...

I am good at thinking on paper, next to the whiteboard, brainstorming, everything works much better than sitting in front of a screen.

How do you "think"?

Personal note: Sometimes during doing TDD I get into this "brute force coding" mode, where I don't think too much, but I just want to get the test to green. Which is NOT good I think. It would be better to spend more time thinking about the problem on paper and then start writing tests and coding...

Just my personal experience with TDD

Tip 3: Provide Options, Don't Make Lame Excuses

Something I learned from my boss Adam Cogan. Always give options AND a recommendation. 

More on our rules here http://www.ssw.com.au/ssw/Standards/Rules/RulesToBeingSoftwareConsultantsWorkingInATeam.aspx#ManageUp

Tip 4: Don't Live with Broken Windows

Here Refactoring comes into my mind, and I think that the Java guys with their tools (Eclipse) are way ahead of me or us (.NET + VS2010 + Resharper). Eclipse has huge amount of refactoring's out of the box... 

As soon as you see a broken window, fix it or apply some Ninja refactoring's

Tip 5: Be a Catalyst for Change

I am big proponent for no big designs upfront, but for changes during project life.

I don't fear changes anymore since I am having a lot of automated tests (unit+integration) in place in our projects and VS2010+Resharper on my toolbelt. 

Tip 6: Remember the Big Picture

We are using Scrum and work "against" a Prioritized Backlog. That helps a lot on keeping the focus, and in the Sprint review meetings the product owner gives feedback and drives the whole project.

Tip 7: Make Quality a Requirements Issue

Because we are doing Scrum, we have a list of Done criteria and each user story has certain acceptance criteria.

Those lists act as quality gates and help us to focus on quality, although we are not following them always...

Tip 8: Invest Regularly in Your Knowledge Portfolio

I am not so good at that one, especially: "Learn a new language every year" (I played with F# recently, but didn't really learn it. My last new language was VB.NET ~3 years ago)

Regarding "Get wired" I heard from a lot of other developers, that they try to focus more. Less noise, less blogs, less Twitter, less Newsletters, Less Mailings lists, but more focus on high quality. I like the idea, but don't follow it ... yet...

Tip 9: Critically Analyze What You Read and Hear

I am naturally quite skeptic to a lot of things, not just Computer related stuff. 

I trust to information that I am closer to more than other info from sources that I don't know (this is pretty obvious :-)

E.g. People in my team, company = High trust   

Blogs from Random website = low trust 

etc...

Tip 10: Its Both What You Say and the Way You Say It

I don't follow this rule very much... as you can read in this email ;-)

To me it comes down to who i am talking to: Twitter, Internal email, Client, Meeting with Boss, ...

We (my company) have actually a rule that you are not allowed to send an email to a client without double checking it by one of your peers. Once you got 5 emails right without any major problem, you are allowed to send emails without checking...

There is actually a lot more in chapter 1, but that's my quick main picks out of it...

What improved myself a lot was sitting (pairing) with other developers (especially better ones, masters). 

Not sure yet if the book covers this tip: Learn from others

There are so many things that you pick up so quickly by just pairing for 4hours with another dev, even if it is a Junior developer, there is always something that you learn from someone else. Another tool, a communication problem tip, another way of thinking, another way to explain something, etc... 

1. What is your opinion on Chapter 1?
2. What is your experience with doing TDD?
3. How are you "thinking"?
4. Are you trying to get wired as much as you can or try to unplug more?

PS 

I love that book and regret that I didn't read it 15 years ago.... just realized that it was published in the year 2000 ;-)

.peter.gfader.

http://blog.gfader.com

--

.peter.gfader.

http://blog.gfader.com/

http://twitter.com/peitor

[David Tchepak]

Hi Peter,

Great summary. I had a couple of points on a couple of your points. :)

Tip 2: Think! About Your Work

This is something I do way too less, and most others I work with as well. 

We just want to get started, code or hack something together. 

But thinking beforehand saves lot of time...

I am good at thinking on paper, next to the whiteboard, brainstorming, everything works much better than sitting in front of a screen.

How do you "think"?

I find hastily scrawled diagrams on a whiteboard a great way to think through problems (especially with a pair). But I also find sometimes pushing ideas out straight into code is a good approach. It is quite easy to spend a large amount of time thinking through and debating the merits of various approaches, when you could have actually spiked out all those ideas in less time and come up with a good answer based on that. Sometimes there is no substitute for actually putting ideas to the test and seeing where they fall down.

I sometimes annoy my pair once we have been discussing an idea for too long without making progress by pushing the keyboard over and saying "explain it in code". :) (this is one of the reasons people no longer pair with me ;))

 

Personal note: Sometimes during doing TDD I get into this "brute force coding" mode, where I don't think too much, but I just want to get the test to green. Which is NOT good I think. It would be better to spend more time thinking about the problem on paper and then start writing tests and coding...

Just my personal experience with TDD

I've experienced this problem too. I find "calling the shots" one really useful technique for beating this. More here: http://www.davesquared.net/2010/08/calling-your-shots.html

 

Cheers,

David