LinLog

Slashdot recently ran a story on why so many tech workers dislike their jobs.  The article links to a survey by TinyPulse, a company that measures employee engagement.  The thrust of the article was that people in IT are less happy and engaged in their jobs than their fellow employees in other departments. 

The article itself was somewhat interesting.  They showed a number of graphs that showed IT pros reporting reduced engagement as compared to people in other departments.  However, in looking at the graphs and the numbers, I got the distinct impression that somebody at TinyPulse was trying to pump up business by manufacturing a crisis.  For example, consider this screenshow of the graph (captured 2015-09-21):

This is the first graph in the article and the way it's shown is literally straight out How to Lie with Statistics.  No, seriously - read the book.  One of the ways to lie that it discusses is to use a bar graph with a discontinuous scale.  In this case, the horizantal axis appears to start at about 17%, which is why the bar on the right is about three times as tall as the one on the left, even though it only represents a 3% difference.

To their credit, TinyPulse didn't do that with any of the other graphs in the report, so maybe it was just a garden-variety screw-up.  It fould just be that somebody pushed the wrong button in the graph-generation tool and the result got pushed out.  Who knows?  You'd think a company that does statistics as part of its core business would be a little more careful, but hey, things like that happen.

The problem is that when you notice something like that, it immediately puts you on your guard and makes you suspicious of the rest of the data. Of course, that's assuming you know to look for it, which most people probably don't.  And that's the beauty of lying with statistics - you don't have to actually lie.  Why risk an out-and-out lie when you can just be careful in your presentation and trust that the vast majority of the people will draw the conclusion you want them to draw rathen than the one that's actually supported by the presented data?

Just a quick note on a small customization to Tiny Tiny RSS.  If you're not aware of TT-RSS, it's the online RSS aggregator that I switched to after Google Reader closed down.  It's got all the features I care about, has a fairly nice web UI and there are mobile apps and mobile-web front-ends available.  And despite what it says in the official system requirements about needing a dedicated server, it works perfectly on my el cheapo shared hosting account - wasn't even hard to set up.

Anyway, I recently switched the configuration for the web viewer from the "default" theme to the "night" theme, which is a white-on-black color scheme.  I decided to try that because it matches better with a lot of the development tools I'm using (Komodo IDE, Visual Studio, command prompts - all light text on dark backgrounds).  The only problem is that, unlike the default theme, which shows headlines of posts you've read in a different color, the night theme doesn't visually differentiate read and unread posts.

Fortunately, this is easy to fix.  You can just open up the preferences and there's an option to customize your stylesheet.  To change the highlight color, copy something like the following into the custom CSS box.

body#ttrssMain .hl .hlTitle a {
    color: #878787;  /* A slightly darker gray to use for "read" posts. */
}

body#ttrssMain .hl.active .hlTitle a,
body#ttrssMain .hl.Unread .hlTitle a {
    color: #CCC;  /* Normal headline color for the "night" theme. */
}

Note to self: when getting regular expression warnings from JSHint, remember the inline option for disabling them.

/*jshint regexp: false */

This is useful for adding to the top of a function definition when you want to use "unsafe" regular expressions.  Apparently the idea is that using an unescaped "." in your regular expressions can match more data than you intend and potentially lead to bad validation and insecure applications.  So it's actually a good thing that JSHint check for this.

On the other hand, in my case the regex in question was just a simple extraction of the extension from a file name.  Since I was comparing the result to a white-list and substituting a known default if it wasn't found, there wasn't really any serious risk.  I just wanted JSHint to shut up.

I've decided it's time to do a little professional development.  In other words, stop putzing around with whatever new technology is "cool" these days (grumble, grumble kids with their Snapchats, and their Node.js, and their Dan Fogelberg) and get back to fundamentals.  That means design and architecture, development process, project management, quality control, documentation, and all those other things that are important, but not even remotely "hip".

To that end, I'll be doing some reading.  The first book on my list has been on my bookshelf for about 13 years - The Mythical Man-Month, by Fred Brooks.  I bought and started reading the 20th anniversary edition over a decade ago, but never got around to finishing it. 

In retrospect, I think I was just too inexperienced at the time really get the significance of the book.  After all, it might be a classic, but its's an old book (written in 1975) about an old project (much of it relates to developing OS/360).  How relevant could it be?  Especially once you get past the punch line of why the man-month is mythical - which is revealed in chapter two.

Now, after almost 14 years in tech, it's easy to see just how brilliant a book it is.  While there is some discussion of obselete methods and technologies, that's beside the point.  The Mythical Man-Month is still relevant because it isn't really about specific development techniques or technologies.  It's about the complications of managing and communicating with lots of people on a large project.  And while we've come a long way as an industry in the last 40 years, the "human nature" part of the equation hasn't really changed appreciably.

One of the nice things about this book is that Brooks clearly gets what it means to be a developer.  He starts the book with an essay on the joys and woes of the craft of programming, all of which are as relevant today as they were 40 years ago.  There are a number of other such insights sprinkled throughout the book.  My personal favorite is his statement that all programmers are optimists.  When you think about the process of estimation and how that usually turns out, this is the sort of insight that seems so blindingly obvious that you're suprised you didn't think of it yourself.

The third chapter, "The Surgical Team," was particularly interesting to me.  The proposal is essentially to treat building software less like building a bridge and more like performing surgery.  So, in other words, you'd have one senior developer act as the "surgeon" and he and a core junior assistants perform all of the deliverable work.  The rest of the team supports him, doing the project management work, building supporting tools, serving as expert consultants, etc.  Since one top-notch programmer is supposedly ten times as productive as a mediocre programmer, having one of them do the work and nine other people support them gives you the same total productivity while reducing communication problems and maintaining design consistency.

One of Brooks' themes throughout the book is that the way to manage complexity is to maintain consistency of architectural vision.  That is, the overall system architecture should reflect as few viewpoints as possible, rather than being a mish-mash of the viewpoints of everyone who worked on it.  This plays into another major issue Brooks discusses: communication cost.  This is part of the reason the man-month is mythical - because not only does adding new people to a project add ramp-up time, it also increases the communication cost because you now have more people to keep in the loop.

I think one of the best things about the 20th anniversary edition is the added chapters.  For starters, they include Brooks' classic paper No Silver Bullet - Essence and Accident in Software Engineering, which is a good read.  It also includes a chapter of analysis and reflection, in which Brooks discusses not only the legacy of the book, but also what he got right and wrong.  The things he got wrong are particularly interesting.  They include the classic "build one to throw away" quote, which Brooks says is wrong "not because it is too radical, but because it is too simplistic," being rooted in the waterfall model that was popular in the 1970's, as well as his notion of communicating the full project workbook to everyone.

Overall, The Mythical Man-Month is a very engaging and surprisingly easy read, especially given the volume of references.  While it contains some details that now seem like quaint digressions into the history of computing, the majority of the material is still relevant.  It definitely contains useful insights for anyone who is interested in the dynamics of running a large project.  I'm very glad I came back to it.

My shipment of Komodo IDE swag arrived today.  I won a Twitter contest to find an Easter Egg in the new Commando feature of Komodo 9.  Turns out that if you type "kitt" or "michael" into the Commando box, it will play an animation of Kitt's cylon eye-light, complete with whooshing sound, from Knight Rider.

So my prize was a Komodo IDE T-shirt, some Komodo and Stackato stickers, and a pack of Komodo IDE playing cards. The shirt is actually pretty nice.  It just has the komodoide.com URL on the back and that logo on the front.  A nice little swag selection, at any rate.  Thanks, ActiveState!