Tammy Cravit proposed (and more or less implemented) an interesting new feature: integrate Calibre to generate ebooks in EPUB and MOBI format from Glyph’s native standalone HTML output format.

Although the support is still somewhat rough, you can, as a matter of fact, generate ebooks with Glyph, using Calibre.

This release features an update at syntax-level: the possibility of “composing” macros, thereby eliminating nesting provided that containers take only one parameter and no attributes. What? This:

?[
  not[output?[pdf]]|
  ...
]

Can be written like this:

?[
  not/output?[pdf]|
  ...
]

In this case, the not macro was composed with the output? macro, thus removing one level of nesting.

Additionally, I used this features to create an xml macro dispatcher that can be used to render raw XML tags, and an s macro dispatcher that basically is able to call nearly all the instance methods of the Ruby String class. So you can write things like s/sub[This feature makes my life easier|/my/|your] and similar.

As of this version, Glyph can be considered Turing-complete, as it satisfies the following requirements for Turing-completeness:

• A conditional construct, implemented via the condition macro.
• Variable assignment, by setting the value of snippets using the snippet: macro and of attributes using the attribute: macro.
• (infinite) iteration implemented through the new while macro or recursion, which is possible thanks to the new define: macro.
• A memory model which emulates an infinite store: there are no enforced limits on attribute/snippets allocations and number of algorithms or parameters.

Plus, Glyph now understand basic integer arithmetic:

def:[factorial|
  ?[
    eq[{{0}}|0]|1|
    multiply[
      {{0}} | factorial[subtract[{{0}}|1]]
    ]
  ]
]

Not that you need to be able to calculate factorials in your documents, but know that now you can. An you can also define lexically scoped variables, err… attributes, like this:

let[
  @:[a|bits]
  @:[b|bobs]
  section[
    @title[Something more about attributes]
Attributes are like lexically scoped variables. You can use them to store @[a] and @[b].
  ]
]

Handy enough.

Too lazy to create snippets? Feel the urge to re-use something you already wrote somewhere? Use a fragment and embed it, as follows:

Snippets and fragments ##[good_way|are a good way to reuse] small chunks of content, 
while the include and load macros <=[good_way] entire files.

…And you can also use a new load macro, to embed entire files without performing any evaluation (like include does).

To sum up:

• snippets.yml is no more, define all your snippets inside your document instead.
• New “invisible space separator”: \/ instead of \.. Because it’s slightly prettier, nothing else.
• The rewrite: macro has been replaced by the define: macro, which also allows recursion, so be careful!
• If you want to render raw XML tags, use xml/tag_name instead of =tag_name.
• No more match macro, use s/match instead.

For the full list of the issues fixed in this release, see the Changelog.

Hope you’ll enjoy this new release of Glyph. If you want to contribute, go ahead and fork the repo!

Over the past five years, I must have tried dozens of different digital todo lists, and every single one of them had something wrong with it. Here are the most common flaws I encountered in many applications:

• Too many fields – I don’t want to specify (or see, either) a due date, a start date, a completion date, priority, effort, risk, tags, categories, sections, flags, stars, projects, reminder, pre-reminder, recurrency, location, contexts, and finally the actual task. I just want to write down what I have to do. Maybe I want to flag it as important. Sometimes I may need to set a deadline with a reminder, but that starts getting complex already.
• Too few fields – On the other hand, just a title and a checkbox won’t do. I want some form of categorization and (optional) deadlines.
• Not cross-platform – I use Windows at work, Linux at home, my wife has a Mac. We both have iPhones, but someday I may get an Android device, too. There aren’t many todo lists out there that support more than two operating systems, nevermind mobile devices or web access!
• Too fiddly – See the first complaint, above. With too many fields almost always comes a complex interface. I don’t want to wait 17 clicks to save my task. I want to type in what I want to do, and press Enter. Is it too much to ask for?
• Made for a particular methodology – GTD is great and David Allen is the God of Productivity, but I don’t want to use @contexts or specify next actions because don’t believe in them, therefore I shouldn’t be forced to do so.

90% of the digital todo list suck. Believe me. 10% – perhaps – don’t. Luckily, I just need one, and guess what: I found it!

Wunderlist, the List of Wonders, you can use it anywhere and at any time. It’s so awesome that… I should stop the ass-kissing right now, and get to the facts.

I discovered Wunderlist when my endless quest led me to the App Store. I think I must have installed nearly all the damn todo list apps, even the crappy ones. I didn’t fall in love with Wunderlist at first tap: it took a few install-uninstall cycles, but in the end I settled for it. Here’s why:

• Free – Not that it matters that much, I would happily pay a few bucks for a good app. And yes, I did pay for a few todo lists that I dumped afterwards. Bummer.
• Cross-platform – iPhone, iPad, Android, Windows, OS X. And Linux? Not really, but who cares: the web app is fine and it probably plays well Haiku as well.
• Simple and Efficient – Two clicks to add a task to any list. No compulsory extra-fields, optional deadlines, unlimited lists. Got something important to do? Tap the star on the left of the task to move it to the top of your list and bookmark it.
• Amazing email integration – Create tasks via email, share tasks with others via email, get reminders via push… or email. They even email you if you have overdue tasks. Like… everyday! I was so happy when they implemented this feature that I nearly cried when I got the first few emails.
• Everything is sync’ed – On your iPhone, iPad, Android device, Windows PC, Mac, web, etc. It’s all there, always, everywhere.

When I finally realized how awesome this app was, I started using it for chores, and as a shopping list. Then I figured it was good enough as a backlog for my open source projects and my web site, and then… Then my wife discovered it.

One of the relatively unusual features of Wunderlist is the possibiliy of sharing lists with others. All you have to do is click a button, specify one or more email address, and send invitations out. People will then signup for a free Wunderlist account and they’ll be able to access (as in read/write access) your list.

Because Roxanne, my wife, has an iPhone, she was the most obvious candidate to try out this collaborative feature. First I shared my Shopping list with her: we needed to make a list of things to get for a party, and that was fun. Wunderlist worked perfectly: we went around the supermarket and ticked things off the shared list, which updated in real-time!

All went great until I decided to share the infamous Chores list. You know the one: bills, fees, errands… I used to say things like “it’s on my list, honey, I’ll do it”, or even “Yes… I’ll add it to the Chores, just gimme a minute”. Little did I know that my beloved liked Wunderlist so much that she started using it frequenly, constantly updating the damn chores list with things like “Take the rubbish out” or “Collect the package from the post office”.

I realized she became a true Wunderlist ninja when I found a task called “Flowers for Roxanne!” – starred and with a deadline set to two months ago!

After months of trial, I decided to use Wunderlist at work as well. With caution, of course: I made sure not to write down any sensitive information in my tasks, because you never know. I started off with just one list, but it got crowded very quickly. I now use five lists for work only:

• Work [!] – This is the most active one, I use it for things to do ASAP. Starred tasks are urgent and important, and should be dealt with within the day. At work, that’s my default list.
• Work [~] – This is for things that in progress, for tasks I delegated to other people, for keeping track of emails waiting for a reply, etc. I tend to check it at least a couple of times per day (if something is really urgent gets moved to the first list).
• Work […] – This is for someday/maybes. Something that is most definitely not urgent, and not too important either. I normally review it once a week, except in the middle of August when I won’t be able to do anything because everyone will be on holiday… It will become my default list for a week or two, then.
• Work [CoP] – I also work as the coordinator of a Community of Practice, and I want to keep CoP-related stuff separate, so that I know where to look when I can allocate some CoP time during my day.
• Work [@boss] – This is a special list for my boss only. We email each other frequently, but rather then sending her long emails she can’t afford to read, I write down discussion topics in this list, which I’ll then load up at the following status meeting.

The next step? Maybe sharing lists with my boss and collegues, who knows…

Saying that Wunderlist is the perfect todo list for everyone would be pointless: there would always be people who wouldn’t agree with that. Wunderlist is not perfect, but close enough for me: it has most of the feature I need, and – most importantly – very little features I don’t need. In the end, this is what makes an app truly awesome.

I give it four stars out of five. Why not five? Because in this way 6Wunderkinder can make Wunderlist even a better product by surprising its users with something they didn’t know they wanted. That’s what Steve Jobs does at every Keynote, isn’t it?

If you put The Rails 3 Way and the original The Rails Way one next to the other, you can see that the new book is considerably shorter: about 200 pages less. This doesn’t mean it contains less information, quite the opposite: the new book contains a lot more stuff with less fluff. Obie managed to reduce digressions to a bare minimum and focus on providing more informative content to the readers using less text. Think of it as a fat-free book.

While no What’s new in Rails 3 section is included in the book, Obie points out the new stuff when needed (but not always). An example is chapter 12, Ajax on Rails, in which changes introduced by Rails 3 clearly stand out, especially the section on Unobtrusive JavaScript (UJS).

Although the book is divided into chapters, it can also be divided into parts (each dealing with a specific theme) simply by looking at the front edge. According to this theme-based partitioning, Active Record makes up for nearly a quarter of the book (173 pages), followed by Active Support API appendix and the All About Helpers chapter.

Another nice addition that can really make the difference when you’re in a hurry is the Method Index, which is separate from the main Index. It seems to account for all the methods in all (or at least the most important) classes in Rails. I didn’t check method by method, but it is pretty comprehensive nonetheless, based on some quick spot checking.

The first thing you notice once you read the first few pages, is that this book is even more opinioned than its predecessor.

Even though Rails 3 is less opinionated than early versions, in that it allows for easy reconfiguration of Rails assumptions, this book is more opinionated than ever.

– Obie Fernandez, Introduction to The Rails Way

In other words, you won’t find an ERb view in the whole book (Haml rulez!) and if you don’t like RSpec… well, you’d better skip Chapter 18 altogether.

The other big difference with traditional Ruby and Rails books is the amount of reference to third-party code, mainly rubygems. Rails comes with no authentication functionality? So what: Authlogic and Devise are great for the job, go check them out! Do you need to test your Active Mailer emails? email-spec is all you need.

I was actually surprised to find so much content not strictly related to Rails in this book: the first chapter starts off with Bundler (now a Rails dependency, however), Chapter 2 (Routes) mentions Rack, and so does Chapter 4 (Controllers). If you want a nice and to-the-point practical introduction to RSpec, the first part of Chapter 18 covers that.

Then there’s reference material. Plenty of it, a good 40% I daresay. The good thing is that (unlike the first edition) it won’t bore you to death: take Chapter 5 (Working with Active Record) for example, you’ll fly through find-related methods so swiftly you’ll regret when it’s over. Active Support? I didn’t read every line of Appendix B, but when I want to know something about inflection methods I will know exactly where to find them, and what to expect: the method signature, a few lines of text, and a short example at most.

My only regret? Cheat sheets. Or better, the lack of them. More tables, please! Granted, the web is full of Rails cheat sheets, but a few of them at the end of the book or even in a separate foldable add-on like in the Pragmatic Programmer can’t hurt.

Finally, some words about the code examples. The code/text ratio is almost 1:1, but Obie’s choice of not turning this book into a huge tutorial by implementing a single example application was absolutely right: The code snippets used in throughout the book are concise and relevant to the text around them and won’t distrupt your reading. If you want to play with them, they’re even on GitHub for you to clone and fork.

The Rails 3 Way is a book for Rails professionals. If you don’t know Ruby or if you never heard of Ruby on Rails, this book is not for you. It won’t teach you what MVC is, it won’t waste time on explaining convention over configuration, it won’t even describe the structure of a Rails app! If you’re newcomer to Rails… well, that’s what The Rails Tutorial is for.

To be honest, I’m with Obie on this. If this book had been beginner-friendly, it would have been even longer than the previous edition, and probably more boring. Instead, by assuming that the reader has been already initiated to the world of Ruby and Rails, the author can dive into the framework straight away. Moreover, chapters are not ordered by difficulty: they don’t need to be, they need to be ordered in a way that makes sense for a Rails developer.

Once again, this book includes personal sidebars used to voice the opinion of one of the co-authors or Rails gurus: there are plenty of “Yehuda says”, “Xavier says”, “Durran says”, and so on. Nothing new there, it’s just a nice way to provide the reader with authoritative opinions on some matters.

As I progressed through the book, I started noticing how Obie anticipated my questions and doubts: I found this to be a remarkable feature of this book, and an excellent way to make the readers feel they are on the same page with the author. If something should not be done because it may cause you problems, the author won’t hold back. See page 214, “Extra Columns on has_and_belongs_to_many Join Tables”, for example: it’s a cool feature, but it can cause all sort of annoyances, and the bottom line is: use has_many :through instead, if you need extra columns on join tables.

The Rails 3 Way remains the de facto reference book for Rails. I was quite pleased to see that Obie improved it so much, compared to the first edition. Sure, it cannot be recommended to absolute beginners, but it’s not a big problem: if you’re new to Rails, all you have to do is browse around and read a few basic tutorials first.

What I really missed was a What’s New section, or something like that. The new stuff that was introduced in Ruby on Rails v3 is seamlessly blended with all the rest, which is great if you’re tackling the framework for the first time, but not so much when you already read tons of books on Rails 2.×. I would have tagged content specific to Rails 3 in some way at least, for example with labels on the side of each page. Or maybe have a short introductory chapter covering the new features, and directions on where to find them in the book.

Overall, The Rails 3 Way is a great book, and if you plan on using Rails 3 for your next web site, it deserves a special place on your desk.

Generally, I don’t bother writing anything about the authors in my reviews: you can easily find this kind of information online if you want to. I’ll make an exception in this case, you’ll understand why as you read along.

Watts S. Humphrey was a true legend in Software Engineering, he’s often referred to as The Father of Software Quality. He worked at IBM for 27 years and eventually became Vice President of Technical Development. In the 80s, he arrived at the Software Engineering Institute (SEI) where he developed some key development processes of our time: the Software Capability Maturity Model (CMM), the Personal Software Process (PSP), and the Team Software Process (TSP). He received many awards, culminating with the National Medal of Technology in 2005.

He wrote several books focusing mainly on software development and managing software projects through his PSP and TSP methodologies. Reflections on Management — How to Manage Your Software Projects, Your Teams, Your Boss, and Yourself was the last book published while he was alive. Leadership, Teamwork, and Trust: Building a Competitive Software Capability, co-authored with James W. Over, was published posthumously.

Watts S. Humphrey died on October 28, 2010.

In many ways, Reflections on Management can be seen as the summa of Humphrey’s work on PSP, TSP and management of software projects, condensed in a very readable 288-page-book, co-written with William R. Thomas, Senior Technical Writer and manager of SEI’s Technical Publications Team.

I noticed the tech writer’s touch simply by flicking through the pages of the book when I first got it: its structure is impeccable.

Organized into four parts, totalling 8 chapters, an Epilogue and an Appendix, this book is a prime example of order and readability: pick any section title (just the title) of any section in any chapter, and you get a clear idea of their content and purpose, and a key principle of management. Examples? Sure:

• Chapter 8: Learning to Lead
  • 8.1 How You Behave Affects Your Team
  • 8.2 Leaders Set an Example for Their Teams
  • 8.3 Learn to Avoid the Symptoms of Poor Leadership
  • […]

If you print the Table of Contents alone you get a priceless cheat sheet on management and leadership. If you want slightly more detail, each chapter contains a summary table of all its sections, with a two-line summary of its contents. There are no subsections, only first-level sections, which make the book much easier to understand and “digest”.

You can read it all at once, then you should keep it readily available for consultation. It will take you only a few seconds to look through the contents and pick the most relevant section in a time of need.

The book is very clear and simple to read, always. Each section is self-contained, and always aims to make a point, usually expressed right in its title. If I were to find a common pattern in most of the chapters of this book, it would be the following:

1. Identification of the problem – a particular situation or aspect is described in a way that problems are self-esplanatory.
2. Labeling and classification – the situation is analized and often a set of causes are presented to the reader, often labeled or classified.
3. List of possible solutions – a list possible solutions is presented to the reader, often as a definition list.
4. Solution details – more details are provided to prove the effectiveness of the solution, often including personal anecdotes.

By doing so, the author makes sure that everything he writes about can be easily understood and accepted, because proven by personal experience.

Reading certain sections of this book felt a little bit weird at first. TSP, PSP, heavy planning and documents… are they still relevant in a “real world” now dominated by agile practices, Scrum, Kanban and similar? Do you really have to provide detailed plans and documentation to convince management?

• You may not have detailed design documents, but you still have user stories.
• You may not be required to plan ahead of 6 months, but you still have to plan frequently and provide accurate estimates.
• You may not be required to trace and track everything you do, but at the very least you have to monitor your velocity and produce burndown charts.

Yes, you read “PSP” and “TSP” everywhere in the book, but they are just labels. The methodologies and processes may change, but the principles will always remain true. This book is about understanding the very essence of management and leadership, and it will remain an invaluable resource for anyone who wants to build a career in the Software Industry.

This book is extremely well-structured. Its Table of Contents follows some very rigid rules which make this book one of the most organized texts I’ve ever come across. It is divided into six chapters, each organized as follows:

• A snapshot or an introductory story for the chapter’s main topic
• Four frames, each describing a lean practice or personal quality
• A portrait of a leader
• Your Shot, i.e. some questions and exercises for the readers

In total, the book contains 24 frames constituting the “Big Picture”, which is actually a very powerful framework for lean software leadership. You can read the book’s TOC online on the Poppendieck website and read the book’s Introduction (PDF link) on the whole concept of framing (yes, both the authors do love photography!).

When I started my career as a technical writer I used to love carefully-structured, simmetrical manuals. After a while, however, I understood that such rigorous structuring can even be dangerous if it becomes an obsession: you end up adding extra “padding writing” to make sections roughly match in length, or you start cutting down some other parts, for the same reason. Writing well-balanced books is hard, but I must say that the authors do a very good job with this book: it flows very naturally while keeping to its rigorous structure.

The first chapter is about customers, what they want and the goals of your system. It describes some interesting high level concepts like failure demand and policy-driven waste, and how to spot opportunities to improve the process.

What I found particularly interesting was the usage of process maps to analyze an existing process and find bottlenecks or leaks (in terms of time). I was instantly sold on this practice after reading the success story of how a company manage to reduce the overall time to process and solve customer issues simply by connecting customers directly to developers instead of tech support engineers. This is something you can’t apply everywhere, but after creating a process map for that specific case, the solution was evident.

More generally speaking, this chapter provides a recipe/checklist outlining the sequence of the phases of process improvement and problem solving:

1. Understand
2. Observe
3. Visualize
4. Evaluate
5. Implement

This is the only chapter focusing primarily on technical topics and knowledge. It starts with a very lengthy digression on the history of programming methodologies, aimed at understanding what works and what doesn’t. Some examples of IT stuff that worked include the Internet, PCs and …Open Source Software.

This chapter provides a general overview on Software Development as a whole. It contains some interesting information on software complexity and dealing with architectural dependencies, comprehensive sections on testing and continuous integration, and just a half page on refactoring (understandable, seeing that there are already plenty of excellent books on the subject).

The Race to the Sky section at the beginning of Chapter 3 is by far the most fascinating of the non-IT stories included in this book. It describes the construction of the Empire State Building in 1930, how it was planned out, what strategies were followed, and why it succeeded (why the construction succeeded: the building itself remained totally unprofitable for quite some time).

There are plenty of books on the subject, but Tom and Mary Poppendieck well summarize the key points of this modern-day epic achievement: how to build the tallest skyscraper in the world in a single year. This story teaches us how to work under very tight deadlines, by designing a system to fit constraints, rather than estimating up-front.

This story was perfect to introduce, in the same chapter, concepts like Kanban, pull scheduling and adaptive control, which only recently have been seriously considered in the world of Software Development but they are becoming more and more relevant.

Chapter 4 starts with a brief history of the checklist, which was invented in 1935, to be used by airplane pilots. It then moves on to its usage in hospitals, describing how checklists helped dropping infections caused by inserting central venous catheters incorrectly. Why all this? To focus on the concept of process standards, or better, how we can improve processes to accomplish our goals.

Basically, this us what Toyota does: regulations should not be written on stone, but they should reviewed and updated frequently for continuous improvement or Kaizen.

Finally, this chapter also briefly introduces a few different ways to perform root-cause analysis, such as using fishbone diagrams.

This chapter and the last one are actually focused on people and management. In this chapter, an unusual (for this kind of books, that is) but intriguing analysis on different countries using the following dimensions:

• power distance
• individualism
• masculinity
• uncertainty avoidance
• long-term orientation

Turns out that individualism is abundant in the Western world but not so much in the Far East (who would have thought!), but the opposite applies to power distance. A bit stereotypical, if I may, but not too much: the results are not surprising, especially when it comes to considering different cultures as a whole. Once more, the focus is again on Toyota’s Kaizen and their culture of respect for the people.

On page 198, the meaning of the subtitle of the book (Results Are not the Point) is revealed: developing the people and the system so that together they are capable to achieve successful results is the point. Agile is precisely about this: focusing on the people.

But what about leaders? This is an aspect of the whole Agile philosophy that I keep stumbling upon: if you want The Team to be in charge, what happens to leadership? As I found out myself working in and with Agile Teams, often there’s a serious lack of strong leaders. Leadership needs to be gently refactored into Agile, that’s what Mary and Tom recommend. How? It depends on each specific case, but it must always be done gently.

The final chapter begins with the history of Agile@IBM, or how to turn the biggest software company in the world into a massive agile machine. It wasn’t a top-down decision, the CEO didn’t just wake up one morning and decided that everyone should go Agile. Quite the opposite: it was something that was pulled by developers rather than pushed at them.

In cases like this, companies should be focusing on developing people, including good leaders, instead of particular initiatives and processes. Leaders in turn should shift their focus from details to more high-level decisions. When it comes to facing changes, leaders should look at the 12 principles of the BBRT leadership model.

The final portrait, Leaders at all Levels, well summarizes the key to successful leadership: leadership is about example, coaching and helping others to achieve their goals.

If you’re looking for a manual on implementing Lean Software Development in detail, this is probably not the best book on the subject. If you’re a developer at the start of your career, with no management responsibilities, you’d want more technical juice, so probably you should read the other two books by the Poppendiecks on the subject first.

On the other hand, if you have been working in IT for a few years, and maybe you already started to climb up the corporate ladder, reading this book could make the difference between being successful leader or not. This book does not go very in-depth with any particular methodology or process, but it does provide an excellent overview of a lot of them.

To get the best out of Leading Lean Software Development, you should read it a least once sequentially, skipping the parts that are not relevant to you (right now), taking notes on the more interesting frames, and then go back over them to digest them properly. Do not skip the introduction of each chapter though, for one because they are always pleasant to read between frames, and also because they do teach some very important values or strategies that you must assimilate.

The general message that stands out when reading this book is focus on people. Customers, of course, but also employees: every single successful company mentioned in this book, from Toyota to Southwest Airlines, became successful because they always focused on developing people first, and then products.

Randal Schwartz is a world-famous Perl guru, author of the best Perl programming on the market, and a very prolific column writer.

Randal is not a full-time writer though (“writing books doesn’t pay”). His day job consists in being a “guru on-demand”: you can hire him to fix your code, refractor complex enterprise applications, or simply provide useful advice to IT managers.
Being the host of FLOSS Weekly is not a job, and Randal doesn’t do it for the money of course, but for passion: “I’m trying my best to do one show per week, even when I am away”, he said, and he does go off traveling around the world a lot!

“Once I was at home for 8 weeks and it felt really strange. I kept thinking I had to pack to go somewhere else”. He’s been on nearly every Geek/Insight Cruises (51, if I remember correctly) and his travel plan is always very busy.

I was extremely lucky to catch him on the way back from one of the few cruises in the Mediterranean! It must be a sign of some sort.

I have always tried to raise awareness about Open Source and Free Software among my friends, co-workers, and even managers. Sometimes it’s easy to make people realize that Free, Libre, Open Source Software matters, other times is much harder.

When Randal got half way through his pizza, I asked him if he had any tips on open source advocacy and on overcoming corporate resistance. I explained that the main concerns I get when I talk about open source in an enterprise environment are:

• the cost or support/training
• the immaturity of the product and fear of it being abandoned at some point
• overall, a high Total Cost of Ownership

Randal was almost laughing at one point: “why are people concerned about paying for support for open source software? Don’t they pay it already for proprietary applications?”, also “the chances for open source software being discontinued are the same, if not lower, than proprietary software. Plus, proprietary software often forces compulsory upgrades, and similar things that can eventually damage your business”. Additionally, if I may add, in the unfortunate case that an open source project is abandoned or turns nasty, it is often forked, so at worst you always have the source code anyway.

Randal also pointed out that what really matters about an open source project is the community built around it. He mentioned that the MongoDb guys that came on FLOSS Weekly #105 were really enthusiastic of having embraced open source. Unfortunately, some projects just don’t seem to get the whole idea behind open source at all: community vs. enterprise editions always makes me suspicious, and Randal agreed to an extent.

In a nutshell, Open Source is not about the company or the license, it’s about the people and the community behind a project.

“You should [re-]listen to one of my very first podcasts, the one with ”http://www.webmink.net/“>Simon Phipps, the former Chief Open Source Officer at Sun”, Randal told me in the end, and he’s right: FLOSS #39 is a must for anyone truly interested in the subject.

Seeing that Randal seemed to be perfectly happy to play with his iPhone, I went for the obvious question and asked him what he thought about Apple, and at the same time Claudio asked him what was his operating system of choice.

“OS X”, admitted Randal, “I use what gets the job done”. In all things, there’s no point in being an extremist for the sake of argument, and being an open source advocate does not mean that you have to condemn every piece of proprietary software (at this point, Richard Stallman would have thrown up his pizza, had he been there —but he wasn’t).

“From a GUI point of view, Apple is still ahead of the competition: if others want to win, they have to come up with something better, and different. […]Ubuntu is getting there, but not quite yet.”

Randal also pointed out the importance of contributing to open source projects: “you don’t have to code, you can just provide feedback, submit bug reports, write documentation, or test… I am the one who checks if git builds on a Mac, for example”.

Programming was another major topic of our discussion. Randal, after all, is a living Perl legend having written 6 Perl books and over 250 magazine columns. Unfortunately I don’t know much about Perl, and neither does Claudio. I am quite open-minded about languages—although I am slightly favorable towards Ruby—so I enjoyed every little bit of the discussion anyway.

Most of the discussion was about Perl 6, which was recently featured on FLOSS Weekly #140. After listening to what Randal had to say about it, I am definitely going to try it out at some point (hopefully skipping Perl 5 altogether).
“We [Perl programmers] say that Ruby is an alpha version of Perl 6” said Randal, joking about the similarities between the two languages and the amount of time it took to come up with a working Perl 6 (which to date is still unfinished). He reckons Perl 6 will be used in production for small and medium projects within a few months, and he’s going to write a book about it.

He then briefly described what makes Perl 6 so special. The top feature we were talking about was grammars: the language offers the possibility to create grammars to parse other languages and even Perl 6 itself. Moreover, the Rakudo implementation running on the Parrot VM aims to implement the full Perl 6 specification in Perl 6 itself “[…] therefore, at run time, a program is able to access the its syntax tree itself…”, he said, while playing with an imaginary Perl 6 parse tree in the air.

We then moved on to Smalltalk, and both Claudio and I asked him a few questions about it, in particular about the whole concept of image, particularly in reference to the Squeak implementation. We observed how many programmers of other languages (Ruby included) end up going back to the origins (Smalltalk) and how Smalltalk is far from dead. “It’s only a matter of getting used to it”, said Randal when I asked him how to work with a Smalltalk image and how to distribute it, “you program as you would in any other language, you can communicate with the rest of the world just fine. What you get in Smalltalk that you don’t get in most other languages, is the ability to inspect and work with the underlying source code of the objects at run time, thanks to the amazing reflection features the language offers”.

At one point I had to asked Randal what he though about Haskell, having tried to learn it three times without succeeding: “I have tried ten times to learn it myself, with no luck”, he said. At least I’m not alone!

The discussion then shifted towards tools, and then of course text editors. I just had to remind him that I am a Vim guy. Randal looked at me smiling, and said: “That’s fine. You WILL join us. Sooner or later you will join us… join us…”.

Randal’s involvement in Emacs dates way back to the end of the 80s, and he has been using it ever since. He even contributed to it, back then, by writing pp.el, the pretty printer module.
“I posted my code to the emacs mailing list, and Richard Stallman himself replied asking if he could include my code in Emacs. If you read Emacs acknowledgements, I’m there as well”, said Randal, proudly.

I confess I almost felt the urge to give Emacs another try. I often get hyped up about things like this. If I had received such a reply from Richard Stallman, I would have probably sworn not to touch the Editor of the Beast ever again.

“Just try out Org mode. I didn’t know it very well myself until I had a show about it, but now realize why people should always load up an Emacs instance just to run Org mode.”, said Randal again, talking about yet another recent show.

After our pizza, we all went back to my place, which is literally around the corner for the restaurant. It was only when we were happily starting the second glass of my family’s very own home-made wine that Randal looks at me and says: “You know that I started off as a Technical Writer myself, don’t you?”

I was baffled. I did brush up on Randal’s life on his web site, Wikipedia and similar, like any good fan meeting his hero, but I never came across this tiny detail. This triggered yet another round of questions on my part, as I have been working full time as a technical writer for years now. Randal shared a couple of anecdotes about his early technical writing career.

“When I joined, I had a boss called Lyle. He used to say that the manual itself is the product. If it’s not in the manual, it simply doesn’t exist for the customer.” A statement that can come handy as as a reminder for Product Managers, Project Leaders and similar when they try to belittle documentation, and for writers themselves, when they feel that they can be sloppy because no one cares.

I really enjoyed when Randal told us about his first encounter with his editor, Jack:

“He was a big guy. 6 ft tall, with huge hands. He used to hold his pencil like this… [shows a fist grabbing a pencil] …he starts reading my first draft and crosses a word, then a paragraph, and another, and so on. Then he looks at me and says: ‘OK, what did you really want to say here?’

I said ‘Well, that you set option -s to enable XYZ’, and he starts writing down on my document ‘Set option -s to enable XYZ…’, and so on."

When you start as a Technical Writer, you often end up writing a lot trying to be thorough, making even really simple things complicated. Jack reminded me of a great editor that was hired at my company for a summer, and revolutionized the whole department by applying some principles and vocabulary of Simplified English. As it turns out, instructions written in a plain and simple language are far easier to understand than anything else.

We spent the whole evening talking non-stop. We met at his hotel at 7:30 PM and I drove him back around 11 PM. The guy does talk a lot. Luckily, I got a chance to take a couple of pictures and get a funny autographed note, as long as I promised not to use it for cheques, that reads: “To Fabio, without whom this note will make no sense”.

There’s obviously a lot of stuff we talked about that I didn’t write about, mainly because I was trying to keep this article focused on IT-related topics. Before his cruise, Randal visited the CERN in Geneva, so for a good half hour we talked about the LHC, experiments, neutrinos being shot from Geneva and collected in Rome, things like that.

We also talked a lot about Randal’s day job, then about his company Stonehenge.com, then his trip to England (and to the real Stonehenge); and we talked about Italy, both about good things (food?) and bad things (bureaucracy, backwards mentality mainly in relation to IT, lack of English speakers, etc.).

The evening couldn’t have gone better. Especially considering Randal and I don’t agree on some EXTREMELY important matters (programming languages and text editors). It was a great chance to learn from each other. I doubt he will be ditching Perl in favor of Ruby, but at least I hope to have made it very clear to him that Ruby is much more than Rails, at least for some of us.

sudo apt-get install emacs

Damn! Wrong terminal. Sorry about that…

After two introductory chapters, aimed at answering questions like “Why bother?” or “What do big shots in software do?”, the book starts analyzing what graduates get when they get out of school. I was really taken by the following paragraph, outlining the main difference between school and work:

[…] although schools encourage students to do their own work, on penalty of expulsion or severe reprimand, professional work is saturated with the ubiquitous mantra of “teamwork.” In school, your success depends on individual effort, whereas professional life depends frequently on your ability to work in teams.

So true. I never thought about it until I read it in this book. And this is a common causes of failure in the workplace: not being able to work in a team. It’s understandable: after years of striving to be the best, to do things for yourself, you’re suddenly asked to work for and with others.

The author gives junior graduates some useful tips to get a job in software development (or the software industry in general), with some useful tips on how to create a proper résumé, how to survive interviews, the usual. Hell I wish I had this book when I started!

Readers like me who already have a job should not dismiss this part. Maybe skim through the first few chapters, but towards the end there are some useful suggestions on how to build essential interpersonal skills and a nicely-written chapter about career killers.

The second part of the book opens with Chapter 9, Working the Org, which I found most amusing for the funny, but insightful, Negotiating 101 section. Again, particular emphasis is put on non-technical skills, which are however essential for success. I particularly enjoyed reading this part of the book, because I could relate to it, being a Technical Leader myself.

Chapter 12 is a must-read, as the author himself says:

If you read only one chapter in this book, this should probably be the one.

If you never read anything about time management, you rhave to read this, as it helps you realize how much time you waste, why, and what you can do to improve the situation. I attended a course on the subject at work, a while ago, and I was shocked to read most of the stuff I learned at that course so tidily organized in no-nonsense prose in this chapter. Granted, it doesn’t substitute a time management course or practical experience with managing your priorities, but it is a good starting point.

Chapter 14 deals with Zen and the critical art of balance [between work and personal life]. The diagram on page 249 scared the hell out of me. Here it is, transposed in tabular form:

Thirtheen hours? Really? If you work 13-hour days then you have to read this chapter and put it into practice instantly or you’ll regret it. Luckily I manage to work most of the time for 8 hours a day (as everyone should, by law).

Another chapter I particularly enjoyed (and will re-read periodically) is Chapter16, which contains the best definition of leadership I ever came across:

“Leadership is communicating to people their worth and potential so clearly that they come to see it in themselves.”

– Stephen Covey

Again, this chapter teaches you the basics on leadership and management. If you didn’t take a course on the subject yet, it’s definitely worth a read.

I particularly enjoyed the first two chapters of this last part: Chapter 17 and Chapter 18 are about innovation, which I found to be the fastest and best way to get noticed in a company.

These two chapters won’t teach you to become a genius or an inventor, but they do provide help on the subject: why innovating is important, how to innovate and what to do once your idea gets a shape. The Patenting, Publishing and Public Speaking sections in chapter 8 are useful and practical, and deserve a good read. Again, the book does not go too in-depth, but the author provides just enough information to make you aware of the main issues.

The final chapters of the book felt a bit distant from my current work reality. Business talk, stock options, startups, acquisitions… They may interest some readers with an enterpreneurial mindset, but not me, at least not now. Nonetheless, business and politics pay a very important role in any IT job, so it’s wise to be aware of them.

The 17 interviews with software gurus, miracle workers and other extremely successful chaps make up for about the 20% of the book. They are carefully placed by the author in specific places of the book where they make the most sense (well, most of the time). Every person had to answer a similar set of questions, like “How did you get started in software”, “How do you stay on top of technology trends and innovation?” or “Technical leaders and executives are famous for being time-strapped. What strategies do you use to stay sane and use your time effectively?”.

Every interviews has at least one personal anecdotes. Some feel almost legendary, like the following:

In 1967, at the age of 12, I dreamed of making a difference in the field of computer science. I went off to the local IBM office, literally knocked on their door, and said, “I will do anything for the summer-empty trash cans, you name it.” They said, “Go away kid.” But there was a sales guy who took pity upon me and threw me a nice Fortran IV [IBM Mathematical Formula Translating System] manual, with the expectation that I’d probably read it and get bored and never come back. But much to his surprise, I came back the following Monday and said, “Hey, this is cool! I just wrote a program and I want to run it.” The sales guy was so impressed that he found me an open computer to work on where I could teach myself how to keypunch, program, and debug for what I still recall as a delightful summer.

– Grady Booch, IBM Fellow and Chief Scientist for Software Engineering, IBM Research

Every interview provides at least a good piece of advice for newcomers to the field. The last chapter of the book summarizes the interviews attempting to draw the profile of the successful IT professional: some founded their own companies, other climbed up the corporate ladder, a few contributed with key inventions (email, the Internet, …) that changed society as we know it. Different levels of greatness, and different ways to reach it: this is what this book is really about.

Making it Big in Software is very well organized, in its three main parts. Unless you’re already the CEO of a multi-million-dollar company, you can learn something from this book, and even if you are, learning how other people made it is always beneficial.

It is not a specialized book, and as such it does not go in depth on anything specific. This is a good thing though, because after you read some of the chapters you feel motivated to learn more about this or that particular topic, skill or problem. In a way, it can be a good surrogate for more specialized books about résumé creation, job interviews, time management, leadership etc.

Overall, I recommend this book to everyone who wants to become successful in the software industry. Success can come to different degrees of course (or not come at all), but if you’re motivated enough and interested in your work, it is definitely within your grasp. Be goal oriented. It’s not enough, but it’s a good start.