Scott Berkun1 is a former Microsoft Engineer who severed ties with the
mothership and went full-time public speaker some years back. His book,
Confessions of a Public Speaker2 is sort of his manifesto on how he felt
comfortable making that change and how he feels he’s found success.
Scott acknowledges the simple fact that he feels comfortable giving away these
secrets and hard earned knowledge simply because he knows that most people will
never do the necessary work to become a truly great speaker. I know that I’m
not apt to immediately. I feel that presentation is important, and I often
present at regional Code Camp events and for WSU’s Application Developer’s
group, something I began doing in part because I was tired of going to events
and sitting through talks that I felt had little value either due to poor
presentation, or just because I felt I knew more than the presenter.
More than that, I think that it’s important to share information within our
community. Between techniques and tools, we are certainly spoiled for choice,
but without discussion and presentation, the majority of people developing
software today have no chance to get expose to any idea that isn’t backed
by a marketing budget (this is a notable problem in the .NET and Java
communities, but that’s another post).
If you’ve done anything with public speaking in the past (and odds are you’ve
taken a class at some time that did something with public speaking), you’ve no
doubt heard much of this advice before. Practice, prepare more content than you
think you need (but be prepared to cut content on the fly if necessary), practice,
learn to harness your nervous energy, practice, show up early, etc. However,
Berkun goes into a depth on this material that I’m not sure I’ve ever seen before.
He debunks common myths, like “people would rather die than speak in public,” by
showing where such myths came from and the inherent ridiculousness in such
statements. He presents many cases from his own career of things not going well
at all, like giving a presentation at the same time and across the hall from
Linus Torvalds’, who’s crowd was overflowing into the hall, while he had less
than a dozen sitting in his enormous conference hall.
While Berkun does stress that preparation is the key to making any public
speaking gig succeed, it’s the flexibility to deal with surprises that makes the
best speakers as good as they are. Quick thinking doesn’t trump preparation, but
it’s necessary sometimes to avert disaster.
One bit of advice that I’d like to share is what to do in that circumstance where
no one shows up to hear you speak. Berkun suggests getting the crowd to move
and sit near one another so that you can at least pretend the space is smaller
than it truly is, while also making it easier to engage directly with the audience,
perhaps turning it more into an informal directed conversation than a full-blown
presentation with slides.
It is clear that Berkun was in technology, and still primarily speaks about
tech, but despite his background, and the examples that he uses from his own
career that refer to that, this is absolutely a public speaking book, and I
think it’s accessible to anyone who wants to improve their public speaking,
even if you’re not interested in turning it into a career.
The prospect of government transparency is very important to me. I firmly believe that best way to protect the integrity of our union is by the populace taking a more active role in their own governance. This is why I have always been such a supporter of GovTrack, though I have had to become increasingly selective on what events I track (I limit to activity of my own legislators, a few classes of issues, and the occasional specific Bill). It was the key part of Obama’s electoral platform that I supported, though there was plenty with his candidacy that I did not. We, the people, require more data to be able to participate meaningfully with the government.
Incidentally, the Open Government book, a collection of essays from a wide variety of people trying to better the interaction of the public with government, was driven in large part by the promises made by Obama during his campaign, and the efforts begun shortly after his election, like data.gov. The book was published just over 1 year ago, and at that time, nearly every single contributor felt that the efforts to date were disappointing. I doubt many people’s minds have changed much in this regard.
Now, I work for a state institution, and I’ve made it a goal to make our data more accessible. I understand that it’s hard, but the data that I expose is unquestionably public, has been available in the past (I’m just trying to make it better), and I have a lot fewer roadblocks to the work I’m doing than I suspect most people do. But the federal transparency efforts have been wrought with delays and missed deadlines. Part of this is the fact that much of this data has been behind a paywall in the past, since it required people to physically copy and mail the information, with the new directives, that income, which I suspect had become something of a profit center for many department since transcripts are for us, will be drying up.
A great many of the essays in this book are from people associated with projects like GovTrack, which take government information (either that freely available, or sometimes behind paywalls which they then digitize), and often do analysis of the data to show connections that may not have been directly obvious. Sites like FollowTheMoney.org, or MAPLight.org, both of which show voting records and campaign contributions, and how they may be related. Both sites do a reasonable job of not editorializing on what they’re presenting.
My favorite technology that I read about was RECAP, which is a Firefox Plugin (I’ve considered porting it to Chrome) which detects when you’re browsing PACER, an online database of all US Federal Court decisions used when researching case law. PACER costs about 8 cents per page, with a max cost of $2.40 for a document. While not an exceptional amount of money, with the number of documents that someone may need to pull can really add up, particularly for a non-profit legal defense firm. Using RECAP, when you request a PACER document, it checks the RECAP database, serving it for free if it exists, and if it doesn’t, if you buy the document, it will be uploaded to RECAP automatically. Even for-profit legal firms can benefit from this, by reducing their research costs (and hopefully passing that on to clients).
This is a really interesting book, but like others of it’s ilk (collections of essays on a similar topic, Beautiful Code being one example), this is not a book meant to be read from cover to cover without breaks as far as I’m concerned. As someone who wants to write a review, this puts me in an awkward position. By the end, I was bored, and not inclined to say much nice about the book. Hell, the only reason the tone of this review is so positive is because I finished reading this book almost two months ago and have had time to reflect on it.
The reason the book got boring by the end was because everyone contributing to it had similar ideas on why openness in government is important, so I kept reading the same points repeated time and again in almost every single essay, and not just in single sentences, but often whole paragraphs felt paraphrased and redundant. To be clear, I don’t know how one would ‘fix’ this issue in a compilation book such as this, but when reading straight through, I know it’s detrimental to my experience.
Still, I think the work these people are doing is interesting and important, and there are plenty of resources I’m now aware of that I wasn’t before, and a lot of great disucssion about the challenges in the data and the way it’s collected that I hadn’t been aware of. It’s absolutely worth a read, but it’s absolutely unnecessary (and I’d say unadvisable) to read from cover to cover.
Neal Ford’s The Production Programmer1, published by O’Reilly Media, claims to teach you the tricks of the best programmers in the industry. The book proceeds to meet this goal by, in the first half, giving specific tips and tricks for various applications and tools across Windows, Mac, and Linux. The second half discusses the techniques that one can use to learn or familiarize yourself with a new tool in order to ultimately improve your productivity.
I’ll be frank. I don’t think this book is worth the value.
The first half talks about too many tools, too many platforms. It’s not able to cover any one tool terribly well, and it’s attempts to cover a given class of tools felt unfocused and messy.
The advice overall is sound. Learn the tools you’re using. Focus on tools that eliminate the need to move your hands from the keyboard. Automate tasks, often by building scripts.
Maybe it’s just because I’ve been developing on Unix for the past decade, and grew up on the DOS command line before that, but most everything in this book just felt obvious. Hell, I was playing around with Beagle2 (now defunct) for desktop search in it’s very earliest days, well before Google had their own desktop search product3. I live at the command line, even when I’m on Windows as I am at my current day job.
I am not trying to brag. It’s just a familiarity that I’ve gained that even in college I recognized as grossly missing in a lot of my class mates who were bound to their GUI’s and their mouse. For me, the advice was all obvious.
Part two, which covers more of software best practice, like not over developing, or doing proper testing, learning multiple languages, using continuous integration, is also great advice, but I can’t help but think that other books cover the topics better. Admittedly, this book isn’t trying to be comprehensive or definitive on any of these topics, but in it’s general coverage, it seems to fall short.
In retrospect, I am not the target for this book. I read plenty of blogs and other books on the subject of software development and general computing. Ben Collins-Sussman claims that there are two kinds of programmers, the 80% who just plug away, and the 20% who really excel and care4, while Jeff Atwood makes the claim that the 20% are largely the people who actually take the time to read this sort of material5. I am not so proud as to claim myself to be in that 20%. I think I could be some day, and I know that I am above 50%, but I am reluctant to accept the idea of a hard 80/20 split.
This book isn’t bad. It’s fairly entertaining, and it’s got a lot of good information. But it’s almost too introductory. If you feel like you’re trying to get your feet underneath you, and that you really, truly want to be at the top of your field (as you should), then by all means pick up this book. It’s worth it. But if you’ve spent a bunch of time studying the material, reading the blogs, and most importantly, working on techniques to make you faster and better at your day-to-day tasks, then odds are you won’t get too much out of this book.
O’Reilly Media is really fond of the ‘Cookbook’ format of technical guide. I’m guessing it sells well for them, and I’m glad because I happen to enjoy it. They’re good for reference for solving specific kinds of problems, and if you’re like me, they provide a solid ‘learn-by-example’ mechanism to learn how to work with a new technology or technique. It’s not ideal for everything, but it’s good. I’ve had web-service stuff hanging in the back of my head for a while, so I decided to pull the “RESTful Web Services Cookbook” by Subbu Allamaraju1 to stimulate my thinking on the matter.
And it worked greatly. This particular cookbook is of the ‘Patterns’ variety, as there is absolutely zero code anywhere in the book (XML and HTTP Headers don’t count). This never really feels like a weakness, since HTTP and XML (and even JSON) are all well supported across virtually every programming environment you could imagine.
While these cookbooks are not necessary to read from cover to cover, and this is no exception, I found it to be comfortable to read from that perspective. The chapters are organized such that they start with the simplest things that you need to know to work in REST, and then slowly layers on top of that with more detail and nuance that help to make a really stellar web service. And I suppose that you could be building a service while reading this book, though I found it short enough I’d probably suggest reading at least any potentially relevant recipes while in the design phase, since I think some recipes are easier to integrate into an existing design than others, though depending on your tolerance for changing the API, or the ease of your ability to keep multiple version endpoints, this may be more or less of a problem you.
I started reading this very shortly after I had put together an API for Washington State University Schedule data2, and I found this really inspiring. Our heaviest API user is using a few hundred megabytes per day, and the Queries chapter hinted me toward the way that I can reduce that usage dramatically by giving them more querying options, which incidentally also supports my plans for a Mobile site that can be completely API driven in the near future, and saves me from creating a ton of specialized endpoints when query parameters just make more sense. A lot of this book isn’t relevant to what I’m doing at this moment, since I’m working with GET only resources right now, but the more I play around with REST, the more I like it as a mechanism for web services, there is an elegance there that I don’t see in other web-based API standards, and it’s not really even a standard on it’s own, it just leverages other existing standards.
I think this is a great book for anyone working in REST. I have a few others on my reading list that I need to get to, but this one has definitely pushed my thinking on this technology in a way that has me really interested in how I can best design my services. I can’t say that it’s definitive, but I was really happy with having read it, and I look forward to reading more on the topic.
Jeff Potter’s book, Cooking for Geeks, was published last year and received
quite a bit of praise over the web. As a Geek who is into food, I was
interested in picking this one up and reading through it.
My taste is cookbooks is a bit specialized. I don’t tend to care much for
books that are simply collections of recipes. My favorite cookbooks have
been Michael Ruhlman’s Ratio and Mark Bittman’s How to Cook Everything.
But these cookbooks, which do both contain recipes, are more about the
process of food. Of what differentiates classes of recipes from one another.
Cooking for Geeks falls solidly in this class of cookbooks. Yes, there are
plenty of recipes, as there are in those others, but it’s much more about
imparting a deep understanding of the science of food. And it’s done through
interviews with known chefs and scientists and geeks, including Tim O’Reilly
and Adam Savage.
Potter effectively shares the language used in the food world. In the chapter
on Wine, there is significant discussion with a sommelier about the reality
of wine pairings and descriptive characters that are used inside of the
industry. He goes into detail on ‘molecular gastronomy’, both in the sense
that it’s used today to mean ‘using chemicals in cooking’ (by which metric,
the Twinkie is probably the pinnacle of food), but also in the sense of hard
science that’s being done on food to better understand the reactions that take
place inside of food.
I kid a bit about molecular gastronomists, and while I respect the skill of
chef’s like Wylie Dufresne, there have been people practicing molecular
gastronomy for far longer that aren’t chefs, and approach the problems from a
purely research perspective. However, the techniques of both are discussed, and
presented in ways that left me interested in them, and thinking critically
about what I’m doing while cooking.
That is where Cooking for Geeks really excels. If you’re into geek, and
by that I mean you eat, drink and breathe geek, and you’re also into food (or
want to be), then I think you’re likely to enjoy this. It goes into enough
detail to sate your desire for information, while driving it home time and
again that just like whatever else you’re doing, it’s okay to experiment, and
even fail. After all, like Potter points out, even if you’ve created an
inedible atrocity (and believe me, I have), pizza is only a phone call away.
I’ve been doing web development for the last four years, not exceptionally long, but in that time I’ve thrown myself into the problem space trying to become proficient. Had I read this book three years ago, I’d probably feel a lot more positive about it. Which is unfair, it’s actually an excellent book, even with it’s near constant referrals to the companion website, and even having finished the book, I have used it for reference on a few things that I knew I’d remembered reading in it, particularly when investigating how to deal with the IE menace from time to time.
This book is not the canonical source for any one topic, but as an overview, it’s excellent. And Henick is always there pointing toward more complete resources, from references to dozens of other books or websites that cover the topics in more details. If I managed new web developers, this is probably the book I’d issue to all my hires. It contains plenty of good information, and it’s a solid overview.
If you’re new to the web, it’s where I’d suggest you start. If you’ve been in the ecosystem for a while, and have really been immersed in it, well…this probably isn’t the book for you. I suspect the primary reason I reached to it for reference recently was largely that it was fresh in my mind. Make no doubt, this book is useful, but the size of the problem it’s talking about is so broad, that is mostly only scratches the surface. I know that I’ve collected more complete references on many of these issues, either in books or in links.
The book was good, but I don’t necessarily think it was good for me.
This week, I read Maximiliano Firtman’s Programming the Mobile Web, as I will be starting on a mobile project very soon. This book, I believe, will prove to be a great source for this project, since it covers the Mobile Industry in a nearly comprehensive fashion, which is great to see these days when so many mobile web development books focus on the iPhone. Now, admittedly, there is a lot of iPhone coverage in this book, but there are plenty of features that the iPhone has available today, that haven’t yet all come to other platforms.
There are also several chapters that focus on Web Widgets, which are supported on a few high-profile platforms, but omitted from others. And discussions of web-like development platforms for developing native apps, like PhoneGap, which I didn’t read as closely as other sections.
As an aside, I really responded to the section on transcoders. At Portland Code Camp, I attended a session by someone who does a lot of Mobile Web and training herself, but her tone on Transcoding seemed to be more in the lines of “It will happen, just deal with it.” Firtman has Luca Passani contribute a much more, “I’m mad as hell, and I’m not going to take it anymore” attitude. Transcoders do happen, but they should always be opt-in for the developer, instead of opt-out like the transcoder vendors are pushing. Particularly how often a transcoder will try to inject advertising into a stream. As a person who is doing web development for a State agency, this would be a massive problem if someone injected advertising into our data stream.
I enjoyed this book. It has a ton of good information, is fairly platform agnostic, and was clearly written for programmers, not designers, which I gladly count myself on the first group. Though Designing the Mobile Web, from Brian Fling is a pretty useful guide if you’re full-stack like I am.
I recently finished Beautiful Code from O’Reilly Media. The Beautiful series of books each contain a series of chapters from experts in their fields, in this case, software developers from all over the industry. The contributors are given guidelines, of a sort. Some focus on programs, others focus on algorithms, still other focus on techniques.
There was, for me, at least some information to glean from each chapter, though there were some, like the Gaussian Elimination chapter, that felt less useful to me. However, by and large, the thirty three chapters are excellent reads. Now, I read through the book, one chapter after another, but there really isn’t any need to do that. You’re going to be just as well off opening the book to a chapter and reading through.
Charles Petzold, best known as the guy who wrote the books on Win32 API Programming, has an excellent piece on dynamic code generation in .NET, and how spending a small amount of time up front to build a complex algorithm with some customizations for a specific run case (such as loop unrolling, dropping no-ops, etc) can save an enormous amount of processing time. The fact that he did it in .NET was pretty cool, since this is a technique that most people simply never consider anymore, but it’s something I’ve been thinking about lately for a project that I’m planning.
While those were my favorites, in part because they felt relevant to projects I’m considering, the rest of the chapters are pretty excellent. The discussion of concurrency using Haskell’s Software Transactional Memory is a fascinating approach to safe concurrency. It works exceptionally well in Haskell, due to the fact that the language makes side-effects so implicit that it’s easy to prevent STM and side-effects from getting nested irresponsibly.
Then there are several chapters on code quality and formatting, mostly focusing on trying to make code read more like natural language. Which makes a lot of sense for long-term maintainability, which was really run home by the chapter from a Perforce developer on their DiffMerge algorithm, and how strong code standards have helped it evolve over ten years or so. Or from Ruby’s Matz about keeping code succinct and ‘bookish’, which is greatly aided in his mind by using a language like Ruby, of course.
Beautiful Code is a heavy book, there were a few chapters where the code was very Fortran or LISP heavy, both languages I know well enough to read, but with the Fortran in particular, my eyes glazed over a bit. Even the chapters written in languages I’m intimately familiar with, and that I was interested in the subject, occasionally would go down paths that were far more interesting to the author of that chapter than to me, but that happens in Essay.
I can say one thing for sure: You’re not going to love this entire book. But you will find several chapters to love, and I doubt there will be many you can’t at least appreciate. I’m not entirely sure that I feel the book is worth it’s $50.00 cover price, but then, I’m a little cheap. I got it under their eBook deal of the day, and I know it was worth well more than the $10 I did spend on it. Overall, it’s a really good read, with some excellent essays, but I would definitely suggest treating this book like what it is, a compilation of disparate pieces, and not a cohesive whole.
Michael Lopp, or Rands as he is better known on line, at least by those who read his blog, released this year Being Geek, subtitled “The Software Developer’s Career Handbook” through O’Reilly Media.
The book brings together much of the content from Rands’ blog about working in technology as well as managing technology. I don’t know how this book may relate to his 2007 book “Managing Humans”, but I suspect there is a lot of overlap, but I may take the opportunity to investigate later.
Being Geek is many things. It provides information on how to ensure your career is growing. On how to identify when it’s time to ‘jump ship’ and move on from one company to another. It stresses, time and again, that you alone can drive your personal and professional growth. It gives solid advice on interviewing, and not only how to do well in an Interview, but how you can get the information that you need to determine if a job is appropriate for you as well.
The discussion about how to find the right job was the most interesting, as I’m fast approaching a time when circumstance will require me to move on from my current job, but more than that, it drove home the nagging feeling that I’ve been carrying, that I’m ready to move on.
The majority of the rest of the book talks about Management. Rands assumes that anyone reading the book has the mentality to be a domain expert, and to do well in a variety of jobs, but, in his words, we’re taught to “manage bits, not people.” A lot of Engineers struggle greatly when they make the transition to management because we usually just don’t know what to do.
At this point in my career, the management lessons are slightly less relevant, but even if you’re not making that jump (now or ever), they’re worth reading. Poor managers can sometimes be made better with a tiny bit of management from their people. And thinking, even a little bit, like a manager, can help you identify a good manager when you’re thinking about making a move.
In some ways, I wish that less of this book dealt with the issues of managing people. They’re important, surely, but I wonder if it would have been possible to put in more of the content from the first section, the one that was most relevant to me at this time. However, the content that was present, I believe will be invaluable.
This isn’t a job hunting book. It also isn’t really a management book. Yes, it contains a lot of data on both, and maybe it contains enough on both subjects. But the book is exactly what the subtitle says: It’s a book about managing your career.
My father has worked for the same company since 1980. My mother, has worked for maybe a half-dozen companies, and the latest she’s been with for over fifteen years. I’ve been out of school for five years now, and I’ve been with two companies, implying I’m well on my way to beating those numbers. And that’s become the norm for many people. Technology has very much become a field where if you’re not a growing, you’re shrinking, and you need to always be looking for something new and bigger, if not for the personal gratification of it, to make sure that if you ever need to go looking for a job, people will take notice.
Being Geek also has what I consider something of a ‘bonus’ chapter. “The Nerd Handbook” is a chapter meant not for you, but for your significant other. In fact, I would almost suggest that you not read it, because having someone nail your personality and habits so accurately is…a little depressing. And while this book is called “Being Geek”, understand that it’s very much about computer geeks, maybe just general engineering geeks too, but I’m not wholly sure. My wife is at least as big of a geek as I am, but her focus is on biology and phylogenetics. While there are overlaps in the behaviors described in this chapter, it definitely applies more strongly to me, and not her.
If I were faculty in Computer Science, I would probably build a list of required reading I’d hand every senior after they applied for graduation. Hell, I’m going to make that list anyway. This book would be at the top of that list. I would call it excellent reading for any technology geek at any stage of their career, but for geeks under 30, it should be mandatory.
Plus, the book addresses the coming changes in Web Standards with the older information. For instance, in the chapter on Responsive Interfaces, the bulk of the chapter talks about the techniques you can use to break up tasks for to keep the UI thread free to respond to the user. However, there are still a few pages devoted to the Web Workers stuff that’s showing up in Browsers which stands to revolutionize background threading.