Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Pragmatic Programmer, 20th Anniversary Edition

pragprog.com

Post reply on HN
Print view View original

101–110 of 121 posts

Re: The Pragmatic Programmer, 20th Anniversary Edition

#101

Post by james_s_tayler »

maaaats wrote: post #81
alasdair_ wrote: post #3

The original version of this book is something I'll always treasure. It sits next to "Code Complete", the Gang of Four's "Design Patterns" book and Martin Fowler's "Refactoring" on my top shelf and I still read parts of it every year.

I bought a rubber duck for fun after reading the first passages as a student. Sincr then I've been known as the rubber duck guy and people constantly gift me them. They are all over the office.

I couldn't bring myself to do it for real with an actual rubber duck. But I recently came up with the concept of "comment ducking" which is when you just start writing a comment in the source code as if you were explaining to someone and that actually works as a substitute!

Re: The Pragmatic Programmer, 20th Anniversary Edition

#105

Post by greyhair »

jsperson wrote: post #41
jkaptur wrote: post #39

I was underwhelmed by this book. I think that so many of the practices (like version control) have become so popular that reading an argument for their use seems superfluous. That also makes it really jarring when it recommends something that decidedly hasn't taken off, like the blackboard design pattern. I had the same experience reading "The Design of Everyday Things". To some extent, these books seem most valuable…

> I think that so many of the practices (like version control) have become so popular that reading an argument for their use seems superfluous. This made me laugh - not because you aren't right (in theory), but because I just took over a project from a big four consulting company. When I asked about the location of the latest version of the code (after looking in VC and not finding it)...answer: on the production ser…

That boggles my mind. Maybe it is just where I have worked all of my 35 years, but source and bug tracking were always at the forefront of every engineering effort. Hardware and software, didn't matter. Code and documents. Requirements and design. Everything was tracked. If you had a printed requirements document in your hands, you could look up what the current working version was, and check that against the version printed on the first page. (yes, we used to print documents, back in the days of VT220 terminals....)

Who in their right mind works without version control? Who would want to? And version control has just gotten better and better over the years. I started with SCCS -> CVS -> SVN -> GIT (with a couple of side treks into Perforce and Clearcase). Currently using Bitbucket/Jira, but have also recently used raw git/gerrit. (The organization makes the choice)

Re: The Pragmatic Programmer, 20th Anniversary Edition

#106

Post by greyhair »

irrational wrote: post #66
jkaptur wrote: post #39

I was underwhelmed by this book. I think that so many of the practices (like version control) have become so popular that reading an argument for their use seems superfluous. That also makes it really jarring when it recommends something that decidedly hasn't taken off, like the blackboard design pattern. I had the same experience reading "The Design of Everyday Things". To some extent, these books seem most valuable…

30 years ago? That was 1989. How many companies were using source control in 1989? How about 1999? Still not very many. 2009? Well, now you will find quite a few using SVN, but Git hasn't really taken off yet.

My first engineering job, 1984. All source code was in version control (SCCS wrapped in some tracking tools) and all bugs were tracked. By 1989 we were doing root cause analysis on all defects.

Re: The Pragmatic Programmer, 20th Anniversary Edition

#107

Post by thebouv »

jkaptur wrote: post #39

I was underwhelmed by this book. I think that so many of the practices (like version control) have become so popular that reading an argument for their use seems superfluous. That also makes it really jarring when it recommends something that decidedly hasn't taken off, like the blackboard design pattern. I had the same experience reading "The Design of Everyday Things". To some extent, these books seem most valuable…

Oh I think you would be surprised and horrified at how many billion dollar companies with large development teams still don't do version control properly, or at all.

A pattern I see recurring from teams that were forced to start doing version control begrudgingly:

Pull down code from staging or production to local machine. Make changes. Push to qa or staging to test. All good? Push to production. All good? NOW push it to version control.

W. T. F. F?

Keeps me up at night.

Re: The Pragmatic Programmer, 20th Anniversary Edition

#108

Post by dawidw »

ilovecaching wrote: post #92
alasdair_ wrote: post #3

The original version of this book is something I'll always treasure. It sits next to "Code Complete", the Gang of Four's "Design Patterns" book and Martin Fowler's "Refactoring" on my top shelf and I still read parts of it every year.

I used to think those books were great before I got my first job at FAANG. Literally the only thing that matters is moving fast. Technical debt is just the price of scaling and beating the competition. Code quality is really not important at all as long as the product works and is bug free. So I’ve become extremely nihilistic about software development. It isn’t that I don’t think the properties of clean code and sof…

> Literally the only thing that matters is moving fast

> Code quality is really not important at all as long as the product works and is bug free

According to Robert C. Martin is not possible to move fast without good quality.

Re: The Pragmatic Programmer, 20th Anniversary Edition

#109

Post by vonseel »

cbanek wrote: post #86
jsperson wrote: post #41

Earlier quoted context omitted.

> I think that so many of the practices (like version control) have become so popular that reading an argument for their use seems superfluous. This made me laugh - not because you aren't right (in theory), but because I just took over a project from a big four consulting company. When I asked about the location of the latest version of the code (after looking in VC and not finding it)...answer: on the production ser…

I've seen this as well. It was also super critical bootstrapping code/config. It is so embarrassing I won't say who. But not having code in source control is still a thing. Sometimes if it's in source control, someone has still edited something on production and not checked it in.

> Sometimes if it's in source control, someone has still edited something on production and not checked it in.

I worked at a large fintech company that had serious problems with this. About the only hope we had for mitigating it was moving all the services to run inside docker containers and of course ban developers from accessing the systems directly.

Re: The Pragmatic Programmer, 20th Anniversary Edition

#110

Post by celticmusic »

ilovecaching wrote: post #92
alasdair_ wrote: post #3

The original version of this book is something I'll always treasure. It sits next to "Code Complete", the Gang of Four's "Design Patterns" book and Martin Fowler's "Refactoring" on my top shelf and I still read parts of it every year.

I used to think those books were great before I got my first job at FAANG. Literally the only thing that matters is moving fast. Technical debt is just the price of scaling and beating the competition. Code quality is really not important at all as long as the product works and is bug free. So I’ve become extremely nihilistic about software development. It isn’t that I don’t think the properties of clean code and sof…

I recently walked away from a client who had this attitude. I want to take pride in my work, when I cannot I suffer for it.

The way I look at it is the following:

There are times to take the shortcut (Business reason, for example), and there are times to do the technically sound thing (long term health, usually).

A healthy software team is doing both as it makes sense. That's quality software dev. It's when business takes over the software teams decisions and you always take the shortcut that quality falls off a cliff.

I've worked in those environments too much. I want to be able to take pride in the work I do.

Post reply on HN