Feeds:
Posts
Comments

Sometimes you can spend years trying to find a book that you can recommend to someone who’s asked you a question. My latest read, The Software Craftsman: Professionalism, Pragmatism, Pride is one such book. A recent volume in the Robert C. Martin book series, this volume by Sandro Mancuso is not what it appears to be. And that, is a good thing.

When you look at the other books in the Martin series (Working Effectively with Legacy Code, Agile Estimating and Planning, Clean Code, The Clean Coder, Clean Architecture, …) you see topics decomposed and methodologies expressed by which the title’s subject is achieved. That’s not what you get with The Software Craftsman. In my case, that was a very fortunate turn of events.

This is not to say that the journey of the software craftsman is not discussed. It is and in a reasonable amount of detail. But an equal amount of time is given to the ecosystem within which the craftsman practices. These parts of the book are not for the consumption of the craftsman or aspirant, but for the owners of the firms who employ (or should employ) them.

The book does well in describing the trials and tribulations of a member of the craft; from the point where they realized that they aspired to more than the dichotomy of coder / architect; to the creation of the volume itself. It lays bare this false dichotomy within the broader context of the entire point of software development. That being to produce value to the customer and income to the creator. Within that context, there is the easy path of whatever works and the hard path of building a thing that no only does what it is supposed to, but does it in a way which is both high quality and highly maintainable.

At it’s core, this is book about philosophy. In a landscape of Google and go; and compile it, link it, ship it, debug it; this is a thoughtful volume. It makes the point that I’ve never seen in print, that the individual software developer is responsible for their own career development. Not their manager, not their company, but they themselves are responsible. Heady stuff this.

As to the remainder of the book’s material, it’s more a wake up call to upper management. There you’ll find discussion of recruiting, hiring, retaining, shaping change and showing ROI. I know of very few who could look at this volume and come away unmoved.

It might be the separation of authority and responsibility, the hire for what we needed yesterday, the CYA so we get our bonus, or the factory worker mentality encouraged by so many firms today. If you can read this book and not get something out of it, you’re part of the problem.

Truly quality software is designed, built, and tested by passionate individuals working together toward the creation of something which will well server the customer. Everything else is just code. Any 10 year-old can be taught to write code. I know, I’ve done it. Do you want your life’s critical systems to be build by 10 year-olds? Of course not, that’s a ridiculous question. How about people who are just doing it because they make a better than average day’s wage?

I hope you’re intrigued. At the very least, I hope you’ll reflect on your own views of the responsibilities of a software developer. At fewer than 250 pages, you can read this book in one or two sittings, but reading the book is only the starting point.

 

The book, The Character of a Leader: A Handbook for the Young Leader, is an odd beast. There aren’t many non-fiction books I’ve read where the author uses a nom de plume. According to the Amazon description the author Donald Alexander is an executive officer within the United States intelligence community. Presuming this to be true, they’re desire is to provide a foundation for aspiring leaders and not their own aggrandizement. I say aspiring here because a leader isn’t a title or rank, but rather a state or behavioral characteristic. Leaders can at the same time be led. They are also in a constant state of self-education.

The author argues that a leader is grounded in a set of core characteristics and beliefs about themselves and others. This position is opposed to those who believe that one can be an effective leader and hold that there are no absolutes with regard to attitudes and actions (moral relativism).

Given the books short length (about 120 pages of main text), it struck me as unusual that the introduction was about 15 pages in length. Why not simply incorporate it into the body of the work? My view is that this device allows the author to create the questions that the main text then answers. In a way, it is as though a student approaches a teacher and in asking questions inspires the teacher to assemble a lesson for all their students. I look at it this way because that’s what I have done in similar circumstances. It’s not usually the case that people coming to me with questions realize that their questions are of import to others, but it is the obligation of those of us who people approach with such questions to “spread the wealth.” Noblesse oblige, if you will.

The book is divided into sections defining a working definition of leadership, leadership and character, leadership traits, expectations, becoming a leader, and the fundamental obstacle  to leading (tribalism). It concluded with a call for leading with integrity.

No one who has been in a position of leadership will be surprised at either the structure of brevity of this book. You could put the totality of the facts conveyed onto a business card (I’d’ve said index card, but no one knows what an index card is anymore). But just like a PowerPoint, you don’t need to write every word you’ll speak on the slides (they’re not really slides anymore either). This book is a touchstone. For those newly recognized leaders, this book is a cross between a travelogue and a cautionary tale. For the former, the inclusion of additional material would simply be superfluous. For the later, it might convey the idea that the actions of a leader are paint-by-number, whereas in reality the are very much free-hand.

There are numerous quotes by and about leaders from various periods in history. These both build the case for the author’s assertion that character is essential to being a leader and provide jumping off points for further exploration of specific aspects of leadership.

I am impressed at the tightness of the narrative and the compelling argument made by the author. They strike me as one of those individuals that I would very much enjoy learning from and working along side.

 

 

I spend much of my time these days doing long-term strategic research and planning. Part of that time is spent identifying areas where technology training is warranted. The ways and means I use to create and present training materials have been developed through years of trial and error. In the midst of one particular line of research into a non-training-related area, I found Building an Innovative Learning Organization by Russell Sarder.

The book is relatively short, about 220 pages, but in many ways, you really don’t need more than that to cover the concepts of training. While it’s true that it would take far more to cover all aspect of training, from organization by-in, to facilities, to choice of materials, to length of courses, etc., those are details. And the details are as pointless as ornaments without a tree if you don’t have the fundamentals in place. That’s where this book shines.

Yes, there are all the requisite elements of a business-oriented book (voices from industry, outcomes of research, anecdotes, and the like). Not to mention the mound of acronyms tossed in for good measure. But, I expect those. This book asserts that learning should be a systemic attribute of any thriving company. As such, learning must be part of the culture of the company for it to be successful. You cannot slap training on the side and expect that you will have any serious ROI to the company. It would be like thinking that buying Girl Scout cookies or Boy Scout popcorn has a substantive impact on the members of either organization. Yes, it does provide financial support for programs, but it’s not “the program.”

Training needs leaders, resources, people interested in learning, and a purpose (lest we forget why we do training in the first place).

Training has a structure and that structure is not one-size-fits-all. People have varying modalities of learning. Even the best material won’t work well for everyone. This is were that whole (materials, time, place, etc.) details thing comes into play. But, again the focus of the book is to lay out the challenges and considerations, not specifics.

Finally, you need to see that training produces results. This can be fiendishly difficult to measure, so it’s vitally important to set expectations before doing the training. Being happy is not considered a valid measure of ROI for the company.

As mentioned earlier, the book is replete with references and for those who create training material or even those who want to create an environment within their company where can be effective. It is a good starting point. For those who have been involved in training for some time, the book can serve as a reference that can be used to educate management in the scope, cost and investment (they’re different) necessary to create a learning environment that will have long-term benefits.

Overall, a decent read. I found the interviews with CLOs (chief learning officers) incisive. As with all organization-level things, there are no easy answers. And you do get what you pay for. You’ll dispatch this book in a few hours and then find yourself going back over it later.

 

The latest trend seems to be reading what the rich and powerful read. I regularly peruse these lists of recommendations and occasionally an interesting title catches my eye. The Sixth Extinction by Elizabeth Kolbert is one of those books.

For a while now this book has been in my ‘highly parallel reading queue.’ This is to say that my usual method of reading consists of a bookshelf of a hundred or so books that I’m somewhere in the midst of reading. From this bookshelf, a subset of about 20 find their way to a smaller bookshelf. These will be read randomly a chapter or so at a time until I’ve worked my way through them and have to reload from the primary bookshelf. Occasionally, as with my last reviewed book, I’ll do a cover-to-cover in a burst, but that is the exception. I’ve got some books that I’ve been reading for the better part of 30 years (75% footnote material).

Needless to say, by the time I’ve finished a book there has been a fair amount of reflection and integration that’s taken place. The material in The Sixth Extinction is fairly heavy stuff. It’s not that the science is particularly difficult or that the writing requires you to keep a tablet handy for side exploration (I love side exploration). The thing is that if you have a decent understanding of the history of the planet (so far as we have come to understand it) and appreciate the impact that man can and does have on the biosphere, then by the time you finish the book, you’ll come away with a sense of profound sadness.

I’m a fan of John Brunner‘s work. He had a way of making the large scale personal. He also had a habit of killing off all his main characters within the first ten pages of his books (yes, this is a bit of hyperbole). In many of his works there is a sense that things aren’t going to work out, but you keep pulling for the hero anyway.

The Sixth Extinction is a methodical tour of the effects of the age of man (Anthropocene epoch). It takes us around the world, unblinkingly moving from one die-off in progress to the next. It puts a face and a context to each creature we’re introduced to. If the books thirteen chapters were made into a season of television, it would be the most stunningly depressing series ever. Whereas Carl Sagan‘s Cosmos appealed to our better nature and James Burke‘s Connections left us asking if we were any more than cogs, The Sixth Extinction ends with rats inheriting the Earth.

This may all sound like a bit of a downer, but it’s one of those mirror books that is a distinct departure from all the wishing that we lived back in 1950’s America or how can we become millionaires by eating the same breakfast as Warren Buffet or Mark Zuckerberg. We need to read books that show us the big picture. Otherwise, what’s the point of it all?

Many books on bad situations leave us with a call to action. Realistically though, the damage has been done. The question is one of how long it will take for all the dominoes to fall. For the vast majority of people, asking them to look further than their tribe is near unto impossible. Asking people to consider the planet, therefore, represents an intractable problem.

Read the book, if for no other reason than to come away with a greater appreciation of the impact of man on the planet.

There’s been a lot of churn lately over the price of Bitcoin. There’s also been much talk about uses (commercial and otherwise) for the blockchain technology that underlies it. I’ve taken an interest, as of late, in the subject and I found a promising source of information in the Michael J Casey, Paul Vigna book The Truth Machine.

If you’re looking for a book on how to write blockchain software. This book isn’t going to be of much interest to you. If you have interest in the history of the technology, its applications and societal impacts, you will find it to be a solid read.

Bitcoin and  Ethereum, and the like are discussed with enough depth to provide non-developers a good sense of use cases. This is after all the point of a technology. Otherwise you’ve got yourself shelfware. All the major players are discussed running the gamut from crypto-anarchists to Wall Street bankers. I find the dynamic of these two extremes battling over this technology fascinating.

One definitely comes away with the sense that the technology is still very much a work in progress. Personally, I find it unfortunate that the public sees it as another get-rich-quick methodology. This loops back to the volatility of the Coin markets.

Another, and arguably more important, takeaway is that the systems currently in place do not scale (or at least have yet to be proven to scale). That Bitcoin can process six transactions per second in a world where Visa processed ten thousand is quite telling.

The underlying problem of who’s in charge comes to mind. Without some form of human governance, poor programming will result in bad actors taking advantage of the system. Nowhere does the book address the issue of longevity. The thing about paper (or animal hide for that matter) is that it has a permanence that has proven itself outside of our advances in storage technology. If we did move to a blockchain-based system of ownership tracking, what happens when another, better one comes along? What will the impact of quantum computing be in a world where work is proportional to CPU expended? What happens when people decide that it’s easier to steal the resources used to mine the coin?

I only have a few issues with the book.

First, for a book on a complex technological subject, I expect extra fact checking. I noticed two rookie mistakes in this department. ASIC is defined as ‘Application-Specific Integrated Chips’ whereas it should be ‘Application-Specific Integrated Circuit.’ It also doesn’t require quotes. In the realm of techno-history, the authors attributed Public-Key Cryptography to Whitfield Diffie and Martin Hellman. This is of course incorrect. That distinction belongs to James H Ellis (at least until the NSA owns up to when they started using it). Although his work was once classified, it have been publicly recognized for some time now.

Second, the book wanders off the path of techno-history and into the realm of  conspiracy theory and political opinion when they introduce ‘speculation’ of hacking in the MH370 incident and spend the bulk of the last chapter on the latter.

On the whole, I found the book to be a very good and current survey of the landscape of blockchain technology and its history.

 

So, you’re the newly minted leader of a group of software developers. Are things really going well or have you merely ‘assumed’ control?

Have You “Assumed” Control

So, you’re now the manager / director / vice president of engineering responsible for a software development team. Are you in control or do you merely assume so? How much do you know about your process, resources, etc.?

It’s 8PM, Do You Know Where Your Source Code Is?

Do you know where your source code is? Without source there is no product. No worries you say, “it’s all in source control.” Cool. Where? Who can access it? Is your IP kept separate from the open source and third party bits you use? Do you have appropriate access control if you have dual company relationships? How much can be accessed by non-developers / contractors? Have your development and IT department worked to establish appropriate backup behaviors to prevent you from capturing third-party source into your corporate backup system in a way that will not withstand an audit? There are mainstream third-party libraries which upon termination of use require removal of all copies. Failure get you an additional year of license payments.

What’s up Doc?

How long would it take to put together a top-to-bottom explanation of any given project in your organization portfolio? Not to have someone explain it all, but simply to arrange a soup-to-nuts set of documents arranged in some kind of self-guided tree that anyone could follow should everyone in the development group be waylaid by aliens. Follow-on, how much critical information is stored only as tribal knowledge, squirreled away in the brains of your staff? How many of your processes require human intervention from a special person to  work at all? Does the documentation you do have match the process you use? Does each piece of documentation have an owner?

The Open Source of Our Disk Content

Do you use open source components? In this day and age, who doesn’t? How long would it take you to inventory your open source use on a per product release basis? Do you have an engineer who works with legal to ensure that the open source you use have licenses that harmonize? Do you have an approval process for using open source? Does you appropriately fulfill the licensing requirements? If you modify the source, do you return it to the author? Do you make the source available on your web site (on a per product / release basis)? On our site, why? In a word “abandonware.” Is this really necessary? Well, there’s open source poisoning. And let’s not forget FSF vs. Cisco. Are your developers using code they found on the web and not worrying because about it because there is no stated license? You do remember that that material is protected under copyright law under the Berne Convention (additional exposition here).

The Very (Threat) Model of a Modern Software General

Does your product ever have interact with anything else? Of course it does. Do you have a threat model for it? At every abstraction level? Do your developers know how to read and create a threat model? A good threat model will help drive your security position papers. Security should be a tangible thing and not simply a warm fuzzy. Make your security staff’s job easier. This also reduces the time required to respond to identified security threats in the wild.

Old Isn’t Gold

There’s a phrase that show up a lot in ads for stock services. You know the one. “Past performance is not a guarantee of future results.” This is absolutely true in software. Whether you’re referring to tools, processes or people, the way things have been done is in no way guaranteed to be best practice, or even supported, in the future. This mirage of stability and security may take the form of build systems without build masters, tool chains no longer available or supported, or any tools that new hires have never heard of. Software development is not a capitalized asset, but rather on ongoing expense. We expect that pens today will serve us well tomorrow, but this is definitely not the case with software tools. Strangely, many companies expect that people will want (and in fact demand) their new software products because of the added functionality. Why would the software tools used to product said software be any different. Additionally, there is the issue of support from the vendor and in some cases the very existence of vendor. It’s akin to acting offended when the doctor you had as a child retires.

Pay no Attention to the Man Behind the Curtain

Do you have projects which are the equivalent of the mystery meat you were served in school for lunch? You know the ones. Old projects or products kept around because there’s one really important customer who still uses it. The kind of projects that rely of AS400‘s or AIX cross-compilers to work. The ones where if one particular individual left the company, you’d end up having to pay them as a contractor just to do the build. This is the hardware / process analog to knowing where your software is. If you have these, they will require special attention and not in a good way.

See No Evil or Monkey See, Monkey Do?

If your software development organization doesn’t believe that there is any reason to review the full offering every two years or never looks outside the organization when setting future directions, you have a big problem. The superstars who brought the organization their last breakthrough are only as good as the last thing they learned. As was heard at GE, “Woe unto ye corporate superstars who have not this day performed a miracle, for you shall be known as bums.” If you never look outside, one day you will discover that you have not been surpassed, you have been rendered irrelevant.

Can’t Touch This

If you’re not organization won’t even consider touching sections of the code base because there might be testing impact (scheduling or resources) or the “you can only change the code if a failure has been identified via some test,” you have severe issues. There are advances in every aspect of computing every day. From the processors, to the compilers,  debuggers, static and dynamic analysis tools, to the very algorithms, someone is working to make the software development process easier, faster, safer, and less fattening. To declare a piece or vast chunk of the code base untouchable says that you don’t understand it and are afraid that merely looking under the hood will loose all kinds of unspeakable horror; or that you hold the belief that the code in question is the realm of genius and mere mortals may not intrude.

Back to the Future

In any sufficiently complex system, there is a not insignificant amount of time between design and production. When instantiated in hardware, the lifetime is further extended. Issue of support will demand that less than state-of-the-art tools be expected and managed. If your product has a lifetime of ten years and you build it with tools, techniques and targets from ten years ago, where do you think you’ll be by the time you end-of-life the product? Where will the people who can work problems be? If you’re lucky your organization will have an Office of the CTO. For those of you who just did a head tilt, the mandate of the CTO’s office to keep abreast of futures. So even if you can’t use the bleeding edge tech today, you can be aligned for when you can. These are people you can go to with the “what if” questions. They provide options and evaluations. Let’s be real, you probably have your product developers working on existing products. You also probably have a very short design phase for new features and products. It’s amazing how many products have suffered from just getting something working and calling it good. Wouldn’t you rather have something better than the top result on Google driving your product design?

Is This the Way to the Vice-President’s Office?

In any healthy organization, you can expect that your developers will want to advance. Do you have a clear, straight-forward and consistently-applied technical career ladder? It should cover both the qualifications, duties and expectations of each rung. Is it up-to-date? Do the engineers understand it? Are there soft aspects? Is it actually used? This is a hearts and minds thing. It speaks to the relationship between staff and management. Some people will reach a particular level and be completely content. Others will want to run the ladder. Having a documented path, gives everyone a basis for conversation and a way to set goals.

On the Bench or On the Beach?

So the organization you’ve assumed has the people, skills and processes to handle all your current needs. You’re golden, right? Now ask yourself how deep your bench is. Do you have an inventory of your teams skills? Is it up-to-date? How fast can you assemble an inventory? Look at it.

Are you tracking the current software industry trends in terms of desired skills, programming languages and tools? Why? Look at your bench. See the rookie end? How do you think they select what they study in school? The smart ones are being guided into the high-demand skill areas by the time they’re in their second year of school. Where is all this drive coming from? The FANG companies. They’re the cool kids. They run at scale. They have the money to explore. They’re the companies you’re competing with for new graduates. Save money and see where they’ve been, what’s worked, what hasn’t and where they’re signalling the future is. Remember, you can tell the pioneers by the arrows in their backs.

Did you notice how the TIOBE and Stack Overflow surveys differ on programming languages? They’re using two different metrics. TIOBE sample commits to open source, Stack Overflow surveys active developers.

Now look at the middle of your bench. It’ll be the biggest section. They’re your bread and butter. Are their skills fresh? This speaks to the career ladder. If you’re using a ladder with out-of-date qualifications and expectations, where does that put you? Do you have mechanisms in place to keep your teams fresh date current?

The veteran end of your bench represent your heavy hitters. These individuals have depth or breadth of experience in domain or technology. If you’re extremely lucky you’ll have a few who have both. There may be a tendency to let them get a pass when it comes to their staying current. Don’t ever give them a pass. With great experience comes great expectations. It’s far too easy to simply trust the word of experience without making sure that they aren’t simply recycling knowledge they gained decades ago. Remember that your organization is competing in a global arena. These are the people who should be spending a large amount of their time exploring both the state-of-the-art and the competitions; and also digesting and disbursing that knowledge within the organization. If you’ve got insular vets setting direction, you’ve got a recipe for failure. Maybe not today, but rest assured, the piper always gets paid. Choice of processor, operating system, development language, communications protocol, user interface all come with cost not only today, but downstream. Finally, are your veterans creating information silos in order to ensure their position or do they make sure that knowledge is spread as far as possible within the organization? The former creates an environment of dependency, the latter spurs innovation. The rookies and mid-career developers must never believe that the views of the veterans are unassailable.

View to a Skill

We’ve explored the experience axis of the bench, but what about the skills axis?

If you speak with your development staff about a new technology / methodology / language and you hear, “that’s cool, but here we …,” it’s time to get those wagons out of the circle. This is sure sign that developers are either unwilling to work on their skills or have been beaten down by management in the past. The former is a one-on-one issue, the latter is a systemic problem.

Back to your skills inventory. Does your organization have the right skill sets to accomplish your mandate? If not, can you get there from here? If you can’t what will you do? If you can, how will you engage and implement? Do you have individuals with skills who aren’t being engaged where they could have a positive impact? It shouldn’t matter their tenure. Do you have team members with skills your teams need? How can you uplift the teams with their knowledge? What if they don’t have skill in the area of teaching others? Your organization should have an active mentoring program in place. If you can mentor one person, you can explain to someone who can train others. Your mentors can be brought into group teaching as domain experts. Your team members with teaching experience already know how to extract information from various sources. To them domain experts are a source capable of answering questions.

The Grass is Always Greener

What is the flow of the development staff? Do developers see sustaining and current projects as a dead end? This may be indicative of the shiny ball syndrome. If developers are climbing over one another to get to the greenfield project is it because there’s the perception that only the shiny and new get resources and the attention of management? Does every greenfield project manifest the same patterns of behavior as the sustaining and current only with newer tools? Are greenfield projects used to reward performers rather than being staffed based on background? When a developer moves to a new project, is sufficient knowledge transfer done to ensure no loss of continuity? This information is particularly indicative of the nature of the organization and is a way that management communicates the value and priority of various projects.

Princely Behavior

Is your organization a minefield of fiefdoms and politics? Allocate half your time to dealing with it. Few things will run your development teams into the ground faster than time lost for engineers trying to please two masters. Many people would like to believe that software development is a democratic process. That’s a very naive view. If that were the case, we’d vote on every decision and everyone would have equal weight to their opinion.

And, Action

Keep in mind the words of Brian Kernighan and P. J. Plauger in their book The Elements of Programming, “Write and test a big program in small pieces.” Make your plan with modest, attainable, measurable goals. It’s no different than creating a software project plan. As you proceed, beware individuals with an all-or-nothing attitude. No large undertaking will cover all the bases regardless of planning. Don’t let the desire for a mythical über-solution stand in the way of a good partial solution. Solve problems in the priority order of the problems, not the perceived importance of individuals or groups.

Homework


Image credit: Four Worlds. Creative Commons.

I just finished reading Walter Isaacson‘s biography of Leonardo da Vinci. As with his previous biographies, this one is just as well-researched and presented.

Leonardo is one of those one name people. Long before Prince, Madonna or Usher (funny how they’re all designations of some sort) the name da Vinci was attributed to only one individual. All this fuss over a distracted, self willed, person who started far more things than he finished.

Yes, he was a prima donna. Yes, he tended to tinker over a thing far after the commissioner expected it to be complete. Yes, he was distracted by, well, just about anything. But, what a mind.

Best of all, he just didn’t seem to give a damn. About expectations, glory or money. Which is not to say that he didn’t care about comfort. He liked pretty things (and pretty people). But one gets the distinct impression that what he really wanted was to have a patron (patron sounds so much nicer than sugar daddy) who would appreciate the quality and not quantity of his work. He wanted the freedom to explore the universe (such as it was in the late 15th and early 16th century).

He loved pageantry. He loved to learn, to teach and to collaborate. He was a self-promoter who appears to have been not really up to the task.

He was always stretching, always reaching beyond his understanding. He was always reinventing himself.

People would commission him based on his past works. Many times this lead nowhere for them. With da Vinci, they should have been thinking about what he might do rather than what he had done. How poorly would he fare in today’s world where people are hired to essentially give repeat performances. This being especially true in the technology sector. Kind of like wanting to visit an exotic land where you stay at Holiday Inn, eat at McDonalds and everyone speaks English. Or in perhaps more relevant terms, you invest in a startup that’s going to change the world with a guaranteed return and no risk.

Leonardo was the definition of the deep bench. It wasn’t until the end of his life that he found in the king of France a person who got that you don’t “hire” a Leonardo for what he does, but rather for who he is and how he changes those around him. I find it quite disappointing they expectation that people have of being assured an immediate return at a cut rate. This is the measure of mediocrity in both the individual and business worlds. People want to be given a fish and have no patience to learn how to fish themselves. How much better would the world be if we sought out and nurtured those capable of creating a multiplier effect?

He was also very human. He could be unreliable and ill tempered. His relationship with his relatives was the stuff of reality television.

Isaacson does an excellent job of putting meat on the bones of this icon of creativity.

I’ve read quite a few treatments of da Vinci’s life s one is by far the best. So many seem to be intended to ride the tide of get-genius-quick that is so pervasive today. Nothing like everyone being above average. He didn’t become the man come icon overnight. He became who we know over a lifetime, with the attendant work. As Isaacson noted, he is seen as a genius rather than a craftsman because, but certainly not solely, of his habit of not releasing his work until it was perfected. Granted for most people this would be attributed more to OCD than genius (and with good reason).

Isaacson’s narrative style is engaging and I hope that someone takes the time to translate it to a long-form, visual format.

Overall, I came away with the sense that da Vinci was a real person who inhabited a real world. I can’t say I’d’ve liked to have lived there, but it’d’ve been fun to visit.

%d bloggers like this: