Software, Fear, Neuroscience and Agile Person-Hood

  • The same ‘agile’ principles that make your project team more effective as a whole will make you a better teammate as an individual.
  • Agile principles are about letting go of fear and control, and optimizing for transparency and trust.
  • This is true enough in good times, but it’s *especially* true in harder times.
  • Your own limits and challenges in life are no different than the limits and risks that the team encounters. Be as transparent about yourself to your team as your team is to the project’s stakeholders.
  • Embrace the inevitability of risk, and activate your brain’s optimism module.
  • Renovating a house while you build software is going to provide you with far too many opportunities for recursive learnings about agile project management from all possible perspectives.

Fairly recently, I failed. Fortunately, it wasn’t a messy, catastrophic, collective failure of an entire project, or blowing through $200 million of my investors’ money, then selling off the company for scrap. Rather, my project team succeeded in doing what it set out to do, in spite of the fact that I failed to be a good teammate for them. We didn’t fail together; I failed them.

The proximate cause wasn’t hard to identify: I was totally, completely overwhelmed. Tons of work, and tons going on at home. (Among other things, we gut-renovated an apartment, which is pretty much a full time job, even when you’re paying other people to do the heavy lifting. Cancel all your other commitments if you should ever be so foolishly inclined.) And then the previous, particularly important project suffered spectacular scope-creep and nearly went off the rails, resulting in a bunch of 80-hour weeks and working through most of Christmas vacation.

And so I showed up to this specific project with my gas tank pretty empty. No doubt about it. But that’s not *why* I was a bad teammate. It’s just the set of stressors that exposed some underlying weaknesses: habits that were flawed but manageable under normal circumstances, but which became totally non-viable when things hit the fan.

The thing is, you can be overwhelmed and still be a great member of your team, albeit with a decreased output, or with a need to rely more heavily on other people, or without your normally sunny disposition being quite as sunny. But you have to make the right choices and have the right habits in order to do that. That’s what I’m here to talk about. Continue reading

Find the Comments for Bootstrap CSS: ‘Hiding’ in the Less/Sass

Surprisingly, for such a mature and robust open-source product, the basic bootstrap.css file most people download is almost entirely uncommented. The only comment characters you’ll find are the credits/attributions, an old IE 8-9 hack, and at the very bottom, the sourceMappingURL. And that’s in the unminified version of the file.

This comes from a very fundamental bias on the part of the authors: they’d apparently really, really, really like you to use Bootstrap with Less or Sass. The source files for Bootstrap CSS are Less files, and have to be compiled into the basic .css or .min.css download versions. In the source, you’ve got all kinds of handy inline comments. And I have to admit, it’s an awfully good idea to use a preprocessor with Bootstrap. There’s a whole additional layer of abstraction and customizability that opens up to you when you use one: whole files full of handy variables and mixins, and the ability to toggle CSS modules on and off at-will, by simply commenting out an @import statement from the bootstrap.scss/bootstrap.less file. (Which, indeed, is nothing but a long list of categorized @import statements.) Leaving aside the other virtues of CSS preprocessors, using one with Bootstrap suddenly switches it from being monolithic, over-opinionated, and fit only for rapid-prototyping, to something a real CSS pro could reasonably take home to Mom. Particularly if you’re on Bootstrap only because your team is used to it and doesn’t want to switch to something a little more pro-grade (<cough>… Foundation… <cough>), at least using a preprocessor is the way to go.

That said, I think a good chunk of the Bootstrap community never has used it with a preprocessor, and won’t do so soon. Those folks are missing out in a major way. With decent comments, you can easily toggle the modules on/off by just commenting them in/out, and you can better understand what Bootstrap is doing for you. (Largely so you can get it to STOP doing the things that are bugging you.) For those folks, I’ve got a recommendation.

Download either the Sass or Less version of the source. Even if you’re not going to start using Sass or Less, you can crack open the source files and see all the helpful comments there. Starting from the bootstrap.scss or bootstrap.less files, you can see all the individual modules that are @import-ed, and the order in which they contribute to the final compiled .css file. Then, diving into the individual modules, you’ll find comments that explain what most of the classes do and why they do it. And, using the module files as a reference for start and end points, you can more easily strip out the modules that contain classes that are just cruft.

Bonus recommendation: tell the dev team (politely and helpfully!) that you’d like to see the comments make their way into the un-minified .css, perhaps with an indicator for where each module begins and ends.

Tagged , , , , ,

Directives from Scratch: Slides from AngularJS DC Meetup

You can find the associated (poorly-documented) demo files on github. And here are the slides from my previous ‘From Scratch’ Meetup, which was an introduction to the rest of Angular.

Tagged , , , , , ,

The Common Cold, Common Stock, and TDD; Or: the ‘Cargo-Culting’ of Automated Testing

Nearly everyone in software engineering, whether they use automated testing and/or TDD (test-driven development) or not, should read Test Double’s post on “The Failures of ‘Intro to TDD'”. It encapsulates quite nicely the best intentions of TDD, and demonstrates that Test Double are smart people working hard at the Craft of Software.

But… here’s my problem with it: saying that “TDD is about solving problems incrementally with a side effect of total regression safety” is a lot like saying that “Airplanes are about having 5 hours of distraction-free work time with a side-effect of getting you from one place to another.” Both statements are true independently, but it confuses the purpose with the side-effect, even if the side-effect is overall more important to the success of the system. (There are days when having 5 hours of distraction-free work time does indeed feel like it changed my life more than did merely getting from New York to San Francisco. But it’s still merely a side-effect of my trip, not its purpose.) Continue reading

Tagged , , , , ,

Slides: “I’m Postal For Promises in Angular”, delivered at NG-Conf 2014

(I’m a text guy myself, but if anybody prefers to absorb content through audio/video, you can catch this presentation on YouTube.)

This presentation is a high-level introduction to promises, with some additional details related to Angular. But if you’d like deep-dive training on the structure of Promises, and building your own, see my previous post, with slides from a two-hour hands-on training.

Tagged , , ,

Eliminating Distracting Duplicate Files From Sublime Text

Sublime has some super-cool productivity features: the Sidebar, GoTo Anything, site-wide search, etc. But they run smack into the modern web dev workflow reality that we often have multiple copies of everything sitting around. You’ve got your `app` folder perhaps, where your source lives. Then you’ve maybe got a `dist` for building into, and you may have that weird `.tmp` folder that lives in the hellscape purgatory between the two. And therefore, there might be a `main.css` file in all three of those places.

Which means you’ve got a problem if you just <CMD-P>, take the first `main.css` you see there, and edit away. Or, you’ve got a ton of files and folders in the sidebar, and you just glance over and open the one that *looks* the one you need, only it turned out to be nested inside the totally wrong folder, because you had been checking out the success of your build a couple minutes before. Etc. Shit Happens.

But, lo: you can reduce the incidence of such shit! You can make Sublime ignore those folders – and their non-authoritative contents – entirely, without needing to change the way you organize your project, or the folders you add to it. You’ll still be able to access them whenever you need them, via the magic of the `Open` command, but they’ll no longer be cluttering your view – and your mind – the vast majority of the time.

To disappear them from Sublime (which I thought would bother me, but doesn’t in the least now, as I can always get them with File >> Open), just add a single line to your *User* Settings file. Here’s the original line in the Default Settings:

"folder_exclude_patterns": [".svn", ".git", ".hg", "CVS"],

So, Sublime is by default hiding all your files and folders related to source-control metadata. We’re going to add a couple more items to that, which will then really allow you to de-clutter, and focus in on just what matters: the source code you’re actually writing:

"folder_exclude_patterns": [".svn", ".git", ".hg", "CVS", "dist", ".tmp", "node_modules", "bower_components"],

No surprises here, but a quick explanation for anyone just getting used to these items: my Yeoman/Grunt-based workflow tools build distributable files into the `dist` folder; and they use `.tmp` as a staging area for pre-compilation during development and build. `node_modules` is where Yeoman and Grunt themselves live (along with all their other handy workflow cousins). And Bower is an amazing package manager that handles Javascript dependencies like Libraries and Frameworks. `bower_components` is where it stores them all.

All of those things are files that I most certainly need and want in my project. And yet they’re also stuff that I need to see and interact with only occasionally. When I need to do that, <CMD-O> takes care of it. But if this isn’t your exact cup of tea, take this basic idea, and customize it to your heart’s content. Cheers.

BONUS HINT ON FILE NAVIGATION: Lots of folks already know this, but don’t forget that you can use Sublime (and many other apps) to view invisible files in the Open Dialog using a simple key-stroke: < CMD – SHIFT – . > I use this most often when I need to add stuff to ~/.bash_profile, but it comes in handy any other time you want to poke around and find a hidden file in an environment more visual than Terminal.

Angular from Scratch: Slides from AngularJS Meetup DC

Thanks to all who attended! Thanks to Leigh Frampton for organizing and to LearningObjects (and Optoro :-)) for hosting. Demo files available to clone here.

Tagged , , , , , ,

Migrating to Angular 1.2: Modular Routing, Animations, ng-If, et al.

Note that Angular 1.2 is not yet officially released. They’re currently at Release Candidate 3, which you can install via direct download of the ‘unstable’ release at, or with:

bower install angular#1.2.0-rc.3

There’s no official migration guide available as yet. So, I’m assembling bits and pieces from my own experience and from posts by others. Bottom line: many big changes in Angular are incremental and break nothing. But other changes are pretty substantial and will require modifications of your existing code to even get your app up and running.  Continue reading

Angular’s ng-Show vs ng-Switch (and ng-If!): Important Differences

There’s a critical and undocumented (AFAIK) distinction between several of Angular’s directives. On the surface, ng-show/ng-hide, ng-switch and the new ng-if all produce exactly the same results: partials/DOM-fragments that appear and disappear. I used to think that ng-Show and ng-Switch were just different syntax for the same thing: convenience variations, essentially. And then, ng-If came along for Angular 1.2, which made me scratch my head and take another look.

Turns out the apparent similarities in outcome are deceptive, and mask fundamentally different implementations: ng-show & ng-hide simply toggle the visibility of an element or DOM fragment that’s already in the DOM, while ng-switch and ng-If actually detach and reattach the elements/fragments/templates from the DOM. (Note that Angular 1.0.8 and 1.2 do this in different ways. The 1.2 implementation is far preferable. Comparative implementations are linked from the relevant code below.)

This has significant implications for performance, for how you construct your CSS selectors, and much else.

I built a CodePen to demonstrate the differences between these directives, and added a separate Plunker (linked from the CodePen) to show how Angular 1.08 did ng-Switch differently than 1.2. Use your inspector to see what’s going on under the hood. I’d embed said Codepen, if only was a little more flexible…

Angular 1.2 CodePen

Google+ Finally Permits Cross-posts from WordPress!

I wrote previously about what a pain it is to get your WordPress blog posts over into G+, like you can easily do for Twitter,  Facebook, and LinkedIn. Really, it was only semi-feasible, and didn’t work automatically. Problem solved. You can now add Google+ to your ‘Publicize’ options in the WordPress Dashboard, at least on

Does anybody know: has Google at last opened up an API for this (years too late), or did WordPress just find a creative workaround?