#152 in Business & money books
Use arrows to jump to the previous/next product
Reddit mentions of Coders at Work: Reflections on the Craft of Programming
Sentiment score: 9
Reddit mentions: 18
We found 18 Reddit mentions of Coders at Work: Reflections on the Craft of Programming. Here are the top ones.
or
- Apress
Features:
Specs:
| Height | 10 Inches |
| Length | 7.01 Inches |
| Number of items | 1 |
| Release date | September 2009 |
| Weight | 2.43169874986 Pounds |
| Width | 1.43 Inches |
Code: The Hidden Language of Computer Hardware and Software
The Mythical Man-Month
Peopleware: Productive Projects and Teams
Gödel, Escher, Bach: An Eternal Golden Braid
The Pragmatic Programmer: From Journeyman to Master
Coders at Work: Reflections on the Craft of Programming
I love Coders at Work. Not at autobiography though, but a set of interviews. Very entertaining.
There is also an older book with interviews: Programmers at Work.
I've posted this before but I'll repost it here:
Now in terms of the question that you ask in the title - this is what I recommend:
Job Interview Prep
Junior Software Engineer Reading List
Read This First
Fundementals
Understanding Professional Software Environments
Mentality
History
Mid Level Software Engineer Reading List
Read This First
Fundementals
Software Design
Software Engineering Skill Sets
Databases
User Experience
Mentality
History
Specialist Skills
In spite of the fact that many of these won't apply to your specific job I still recommend reading them for the insight, they'll give you into programming language and technology design.
I thought Coders at Work: Reflections on the Craft of Programming was a really enjoyable read.
It's just a collection of interviews. The book features some really interesting programmers such Ken Thompson, Joe Armstrong, Peter Norvig, and Donald Knuth. I had a great time reading their stories.
It's something that becomes a fad every couple years for about a week, and then dies out again. I think I first heard about it in the interview with Brad in Coders at Work and I'd been meaning to try it.
To be honest, I'm not sure if I'd start any new project this way now that I've tried it, but I'd recommend anyone who considers themselves a programmer try to do something with it, for the same reason I'd recommend trying out any other programming paradigm that they're not familiar with..
Coders at Work: Reflections on the Craft of Programming
Really annoying - available for the Kindle for $9.99 but to simply buy the eBook in PDF is $20.99.
I'd like to read this on my nook. Do I really need to pay 2x the price as a Kindle user for that honor?
Simon Peyton-Jones IS interviewed in the book. See the amazon page: "Simon Peyton Jones: Coinventor of Haskell and lead designer of Glasgow Haskell Compiler"
The 15 people interviewed are mentioned on that page.
Didn't he also attempt to shut down the Apple Macintosh project because he didn't really get it?
*Edit:
Wow. Thanks for the downvotes guys, talk about shitty reddiquette. I'm at home now, so I've got some time to dig out some citations.
The article from which I originally picked up that idea is this one, quoting Jef Raskin's interview in Peter Siebel's Coders at Work.
>What I proposed was a computer [the Macintosh] that would be easy to use, mix text and graphics, and sell for about $1,000. Steve Jobs said that it was a crazy idea, that it would never sell, and we didn’t want anything like it. He tried to shoot the project down.
When originally posted on Reddit, who should pop up in the comments but
Paul fucking Lutus! His summation was that yep, that's pretty much how it went down.
So, yea. If people who were actually there at the time (one of who is the guy that created the thing) are saying that technically Steve Jobs headed up that group, but only after trying to trash it because he couldn't get his head around it, I'm going to put some credence in those claims.
Stay classy /r/apple.
I loved your interview the most in this book. You seem to be an awesome guy.
Like you I work at a tech startup. When we were just starting, our business/strategy people asked the question you just asked. They opened a dialog with development team, and found good answers. I attribute our success in large part to that dialog being eager and open-minded, just as you are being right now. So, it's good tidings that you are asking.
For us, the answer came from conversation, but it also came from reading the following books together:
This is a thinly disguised ad for "Coders at work". Indeed, as I have added it to my wish list...
Rotina? Que rotina? :D
Eu trabalho como Quality Engineer; fazendo um trabalho misto entre "Software Engineer in Test", desenvolvendo soluções pra testes de produtos, e CI Engineer, desenvolvendo em mantendo o ambiente de integração contínua do time.
O meu dia a dia depende do tipo de produto, da fase do projeto ou da tecnologia envolvida. Então, em as vezes estou fazendo design/arquitetura de sistemas, programando, pesquisando, testando, etc.
Meu emprego é fenomenal e eu trabalho com alguns dos melhores profissionais do mundo em suas áreas. Apesar da pressão, o ambiente é relaxado e divertido.
Não creio, porém, que meu dia a dia seja suficientemente interessante além do meu mundo. Então, OP, se você tiver paciência, tempo e quiser se aprofundar mais sobre o assunto antes de tomar a decisão, tem um livro que talvez seja interessante para você e possa te dar uma ideia sobre programação sob o ponto de vista de algumas lendas da área. Talvez esse livro te ajude a reconhecer em você o mesmo tipo de interesse que esses caras tiveram. O livro em questão se chama Coders At Work: Reflections on the Craft of Programming.
Aside from the other excellent choices people have recommended, here are a few I liked that I haven't seen in the thread yet.
This one sounds super-obscure. It's basically the design notes for the Common Lisp Object System, which isn't exactly a manual you need to read to get your work done. However, if you look at it less a book about how to use CLOS and more a book about how an object-oriented language can be built from scratch, it's really a fantastic little read.
It's what it says on the tin -- interviews with several programming icons. What makes this one better than the other half-dozen or so similar titles is how well the author runs those interviews.
If I'm honest, I didn't find this one to be that engaging of a read, but it's worth the bit of effort to get through it just to absorb Stepanov's vision for how to express algorithms. He's got a newer book as well that I have high hopes for, but I haven't had a chance to read it yet.
Perhaps the best thing to do is ask the people who where there at the beginning.
Disclaimer: I'm still a student, so if you want to, go ahead and disregard my response. On the other hand, I have put in many hours contemplating this very question.
In "Coders at Work," Peter Seibel interviews the founder of JSON and JavaScript architect, Douglas Crockford.
Seibel poses the question
> Have you ever had problems ... (with) people who've been successful in one language (who) sometimes have a hard time giving up their old ways, even when working in a new language where they don't really make sense?
Crockford's response:
> I don't care. I just want to know that you know how to put an algorithm together, you understand data structures, and you know how to document it. (...) Generally, I prefer generalists. I want someone who's capable of learning any of those APIs but isn't necessarily skilled in any one.
In The Pragmatic Programmer, authors Andrew Hunt and David Thomas say
>The more different things you know, the more valuable you are. As a baseline, you need to know the ins and outs of the particular technology you are working with currently. But don't stop there. The face of computing changes rapidly -- hot technology today may well be close to useless (or at least not in demand) tomorrow. The more technologies you are comfortable with, the better you will be able to adjust to change.
The emphasis in comfortable is mine. It doesn't say the more technologies you master or are proficient at. Instead, being comfortable with many different areas, topics, technologies, languages, etc., will allow you to express your value to an employer in many different ways.
Now, specific to your current position. I have been with my current company for 9 years now. I started out as a cashier, moved into management after 9 months, and now I am a service technician working with all of the networking, computers, surveillance, construction, project management, etc. I am essentially a corporate representative with a LOT of autonomy, responsibility, and I wear a lot of hats. I am also the highest paid technician in the company for these very reasons. My job is perhaps one of the most stable in the company given the amount of general knowledge I have about the areas I work on actively.
Now, software might be different in that knowing a lot about everything is incredibly hard. However, picking a couple of specialized areas and being comfortable with many other areas is very likely to make you a valuable employee. It allows you to think up insightful solutions to multi-disciplinary problems. You can be the hero who comes up with novel solutions to larger problems, whereas people who specialize in C++, JavaScript, or Haskell might only know how to solve the same problems in their respective languages.
From what I can tell by reading the literature, those are the differences between people who specialize and people who generalize. I think you are experiencing what it's like to be good at generalizing. Incidentally, I would also equate CEO's, CTO's, COO's and other C-level people to generalists. They are capable of abstracting away the minutiae and details of their problems and delegate to others in order to get stuff done. They focus on big-picture stuff and let the specialists (accountants, technicians, programmers, drivers, etc) deal with the details.