TCLP 2015-05-31 Strength through Vulnerability

This is an episode of The Command Line Podcast.

I released this episode and the text version of the essay it includes at the same time. I owe a huge debt of gratitude to Chris Miller for helping my edit and polish this essay. Before I get into the long promised essay, I talk a bit about my experiences at JSConf US.

You can grab the flac encoded audio from the Internet Archive.

Creative Commons License

Strength through Vulnerability

Used under a CC-BY license thanks to Flickr user alachuacounty.

Used under a CC-BY license thanks to Flickr user alachuacounty.

I have mentioned a few times how hard the last year and a half have been, personally and professionally. From the portion of that hardship that I feel was self inflicted, I have been trying to learn, grow and improve. One lesson I have been dwelling on is how showing vulnerability may actually be a strength. I am only now starting to feel my mental well being coming back. By not finding healthy ways to reveal my vulnerability, I think I did as much to delay my recovery as anything I went through that caused me pain in the first place.

When I was a kid, my parents gave me the nickname Rule the World. They didn’t think I was some world dominating evil genius, that would come later. I don’t remember feeling or thinking this but when I must have been around six years old, they said I clearly got upset when the people around me didn’t get along. I would step in, trying to encourage compromise or discussion, to ease any conflict. I still try to be a peacemaker; that is how I often approach conflict as an adult. When I am feeling courageous, I throw myself bodily in to help resolve conflict and arrive at an agreeable compromise or at least an understanding. Often I feel anxious and avoid confrontation for fear of being unable to make peace. I am often paralyzed from the anticipation of trying, arising both from the stress of the attempt and from the fear of failing.

A little over a year ago, at my last job, I faced one of the most challenging confrontations I have ever faced. The organization was in crisis, clearly needing a change in leadership, away from its founder. The program had grown at a breakneck pace, more than doubling every year since I got there. The growth had placed a colossal strain on us all, not in the least due to the challenges in raising ever more money with each passing quarter. There was an emerging consensus among the rest of the leadership that different skills, expertise and experience were now required to lead us through these challenges. The founder wasn’t convinced that the change was needed. Once he realized the rest of us would not be dissuaded, we all pretty much immediately found ourselves on a very adversarial footing.

In the past, I avoided situations like these. I recognized my limitations, that I would feel a good deal of pain and was never certain I could ensure a good outcome. For some reason, perhaps the story I had been telling myself about how the purpose of the work was more important than any past job, I chose to stay. The first test was over a budget decision. The founder had one view of how what moneys we had secured should be spent, we had another. I prepared for the showdown with the founder along with my colleagues. We were agreed on our case, how we would press it, and we were resolute.

When the moment came, I prevaricated. After a few tense moments of rehashing the same arguments, I caved. The reasoned argument had failed to persuade the founder. I was deeply uncomfortable. I knew I made a mistake the instant I capitulated. As the senior most manager among my peers I was expected to be the most resolute. Realizing how I had let my colleagues, my friends, down, I dug deep. I found some well of courage that saw me better able to stay the course in every subsequent conflict. The whole transition didn’t get any easier. I had to set aside my desire to see everyone happy through some considered compromise. I had to push for what I knew was right, despite the tension and strain. Even harder, all of this had to be kept discrete. The staff still had work to do, they couldn’t help the situation one way or another. Battling this out openly might have jeopardized our ability to meet key funded commitments.

The organization survived the change. I like to think it was due to some measure of courage and leadership I exercised. While mostly everyone else ended up in a good or better place, I lost something. I didn’t realize it at first, though perhaps I should have. Despite new leadership and closer bonds forged with my direct peers as a consequence, I flailed in that post transition period. Maybe I had been pushing so hard I was caught off balance and wheeling my arms. I was definitely burned out but I didn’t know how to cope with that. Worse, despite our efforts overall to keep each other sane and support each other through this time of hardship, I let relationships suffer. How I chose to try to cope with the stress ended up causing more lasting damage, wounds the extent of which would not become clear to me for some time, even after I left that job.

Within days of deciding to leave my job, my immediate family was touched drastically by mental illness.Two days after telling my boss about my decision, I was on a video conference from home, trying to keep my emotions in check, as I told all of my co-workers I was moving on. I tried to put the best, brightest face on for them but inside I felt like I was breaking. While I worked on my transition, I continued to keep from most of them what had happened, keeping up that facade of calm and positivity. I worried that admitting to the majority of them what I and my family were going through would result in a reaction of pity that I didn’t feel I could handle. Thinking more about the few people I did tell before I left, I think that in worrying so much about pity I closed myself off from compassion and strength as well that I certainly could have used.

I want to make clear that my family is OK, or at least as OK as we can be. We’ve gotten help and are adjusting to how we all lives our lives now, a day at a time, coping with the singular event back in September and everything that has unfolded since. I finally feel able to share this essay regardless of how readers may react. I hope that it invites serious, constructive discussion and healthy sharing.

I don’t think what I went through was unique, including my decision to share very little. In the last several years I have read more and more articles about how technology leaders and innovators have suffered with mental health issues. There are the most extreme examples with which most people are no doubt familiar, the tragedies like Ilya Zhitomirskiy, the young co-founder of Diaspora, and the loss of the incredible activist, Aaron Swartz. Those are staggering losses and as a silver lining have encouraged some discussion along with the grief. I have stories shared by technologists like myself, just working in the trenches, that are not sensational or centered on known characters, just some people choosing to open up. These stories generally share a theme of struggle on two fronts, with mental health itself and with the stigma it bears. You would think that a space like technology that is generally more accepting of peculiar characters would be more receptive to mature discussion of these matters. Maybe it is but only by a matter of a few degrees compared to the mainstream. More optimistically, because more and more people have started sharing, even if only a handful at a time, mature and thoughtful discussion seems to be expanding and accelerating.

I agree with people like Mitch Altman who have been trying to raise consciousness and to circulate a call to action, to have even more open dialogue about depression, mental health, and the risk of suicide. I wanted to talk about this subject sooner, to add something constructive and positive. The time never seemed right, I didn’t feel like until now I had something to add, to help. I didn’t think I would experience these things first hand. I suppose no one ever does until they do.

I wish I could say that my recent experiences have granted me some kernel of wisdom to share. I don’t think life works like that. My family is still learning to cope, I am still learning a lot about myself, my loved ones, and where we have found ourselves. To be honest, there isn’t a lot of positives I can share. As a society, we still stigmatize mental illness. I wish this was just exhibited through social norms. I’ve found that it has led consistently to differences in the kinds of resources available to families affected by mental illness as compared with more socially accepted yet profoundly similar conditions like cancer, diabetes, or just about any other lifelong, chronic physical ailment. We are incredibly lucky that I earn enough for comprehensive health benefits and an income that puts us squarely in the upper end of middle class for our area. Despite that privilege, we are still scraping by in terms of covering out-of-network fees and finding enough professional help, whether our insurance covers it all or not. I can only imagine what those less fortunate must be going through when struggling with any form of chronic mental illness.

The one ray of hope I can try to offer is this, conversations that run something like this:

Them: “You seem really stressed. Is everything all right?”

Me: “…No but I don’t know how to tell you so I’ll just say it.” Followed by a disclosure of more particulars than I am comfortable sharing here.

Them: “I am so sorry. You know, my uncle/sister/cousin/loved one went through something very similar. I understand and if you need someone to talk to, I’m here.”

When I have chosen to share the specifics of our situation, I have been surprised at how understanding and supportive people are. The upside of what may well be epidemic numbers of sufferers of mental illness is that most people I talk to already have a frame of reference. They have some direct experience, either their own or of a loved one, that informs compassion and empathy.

The trick seems to be exercising sufficient intuition to understand when and how to be vulnerable. The attempt can often be seen as self pitying. There are days where my own exhaustion no doubt makes that worse. Talking one-on-one has helped me make clear that I am sharing from a place of trust, matter of factly, not to elicit any specific reaction but to explain what I have been going through, why I may seem preoccupied or stressed at times. The strength I have received through unlooked for compassion and support has surprised me a great deal. I expected shock, a lack of understanding, silence but humans are resilient. I have to believe that we are also inherently compassionate, leading us to find common experience or sentiment that bolsters empathy, reinforcing common bonds.

I am convinced that we who work in and with technology need to find appropriate and constructive ways to be more vulnerable as a community. There are many things that may be inhibiting honest sharing and candid discussion. I struggle out of worry that talking about my own experiences will be seen as only seeking pity. It is worse on the bad days but I think I have to try, in order to learn how to use intuition and discretion to share without oversharing, to make clear that while I want support and compassion, I am also doing my best to keep from wallowing in pity. I think part of the key is to go beyond intent, to think as much about how we share personal struggles as why. Keeping humility in mind, trying to figure out what is appropriate and responsible, and doing my best to establish a concrete context helps invite the best kinds of responses that both increase general understanding as well as helping me move forward and genuinely feel at least some small measure better for the sharing.

It is clear to me that a lot of people are suffering. Fear of open discussion isn’t helping, worse I think it is unjustified and irrational. We need to take care that we open up in healthy and appropriate ways, but when we do, I am optimistic we’ll have a lot to share and discuss. I am convinced a mature dialogue can do more good than harm. I think the drastic stakes warrant risking some discomfort as we feel our way forward. Sharing our burdens will make them feel lighter. We can stem the tide of tragedy, at least encouraging those who choose to suffer in silence to let those around them know how they are hurting. I believe when they do, the response will broadly be one of compassion.

TCLP 2015-05-24 Finding the Time

Used under CC-BY-NC-SA, thanks to Flickr user fieldsbh

This is an episode of The Command Line Podcast.

In this episode, I talk about how I find the time for all the interests, passions and projects I pursue. Even though I feel like I am doing less than I used to, I still get the question of how I managed to do so much. In starting a couple of new things, from baking for my family to a new job, I came up with some observations and insights might help. Ironically enough, I meant to record this episode last week but a surprise technical difficulty delayed me. That all seems to be sorted so hopefully more new episodes, soon.

You can grab the flac encoded audio from the Internet Archive.

Creative Commons License

Hiccup with My Mixer under Linux

My MixerA problem being mysteriously fixed through no clear action of my own bugs me. A problem this weekend with my mixer is just such a case. After upgrading to the latest version of my operating system, a flavor of Linux that I prefer called Kubuntu, I could not get the software driver I had been using with my mixer working. I could get close but not to the point where my audio workstation would see my mixer. Of course I discovered this right when I sat down to record. Last night, last thing, when there wasn’t time or will left for extensive research and troubleshooting left in the weekend. When else would I discover a problem resulting from upgrading my OS? Not when it would be more convenient to investigate and fix.

The break bugged me so much, especially losing an opportunity to record when I had the will to do so, that I spent some time this morning before work to see if I could get things working again. I installed the latest version of my audio workstation, Ardour 4, because I had been meaning to, anyway. Through some experimentation, I stumbled upon the fact that letting Ardour directly drive my mixer, rather than using an external software controller worked. Doing so only worked using an option I didn’t think had a chance in hell, just using the basic audio stack that comes with Linux.

I was simultaneously relieved to have my mixer back but vexed as to why something that previously did not work, suddenly did. I dislike mysterious fixes almost as much as random breakages. If I don’t understand why something suddenly starts working, I feel helpless to deal with any subsequent breakage. This situation is usually a recipe for cascading frustration.

I did a bit more searching, just now, and I think I found the explanation.

Very current versions of the Linux kernel will support most of the same devices that FFADO can support, directly via the normal ALSA audio device driver layer.

That is from Ardour’s own documentation, specifically on its requirements. FFADO is the separate driver I used to use for my mixer since it is a Firewire mixer, an increasingly less common way to connect peripherals to a computer but one still very well suited to the demands of audio. ALSA is basically the core sound handling component of Linux. As a consequence of my operating system upgrade, I indeed do have a very new kernel.

Mystery solved. Of course, I have only done several seconds worth of testing. In past versions of ALSA, it hasn’t done well with the demands of high quality audio, such as working with a prosumer mixer. It is entirely likely there are frustrations still yet ahead but at least they won’t be entirely mysterious. And I will hopefully get some new recording in soon, regardless.

JSConf US 2015 and Future Conferences

In a couple of weeks, I will be heading to JSConf US 2015. I was going to talk about this, I will still talk about this more, in my next podcast. Given the quickly dwindling time remaining before the conference comes up, I wanted to share a quick heads up. Any reader or listener who will also be there, please feel free to shoot me a quick note if you’d like to meet.

I have one other possible work related conference, AWS re:Invent, that I have tentatively agreed to attend later this year, in October. Again, if you are going to be there and want to hang out, let me know.

I am enjoying being at a gig that is well resourced. While I got to travel at times for my last job, it was feast or famine. Either I was traveling a lot, too much really, or not at all. Now I have some discretion. If you know of any conferences you think I might be interested in, let me know about those too. I can always ask and I think within reason can expect to go to some of the more interesting and relevant tech conferences for the foreseeable future.

So you know, and I’ll unpack these more in a future podcast and/or essay, the technologies I am currently using, learning or interested in include React/Reflux, Node, Scala, microservices, reactive/concurrent programming, Docker, continuous delivery, and automated testing. I can probably make a case for less tech specific but still work relevant conferences like ones that bear strongly on agile as I am currently a scrum master for my day job. Anything else, while it may be of interest to me, I’ll have to foot on my own dime.

TCLP 2015-04-18 Choosing Your Aspect

gangster-154425_640This is an episode of The Command Line Podcast.

I rushed this episode out for listeners who do not read the web site. I wanted to let those listeners know about the coming change in feeds, in case of any disruptions. I am hoping there are no problems, but if someone has one, I want them to have the heads up and to know I will help where I can if there are any feed hiccups.

I discuss some listener feedback, namely Pete’s recommendation of the Gundo plugin for vim and Tim’s move from nano to vim.

For the rest of the episode, I extemporize on lessons I have learned about the benefit of choosing between a hard or soft aspect as someone who used to almost unilaterally always approach situations with a firm set to his jaw.

You can grab the flac encoded audio from the Internet Archive.

Creative Commons License

Feed Change on 5/1/2015

I have been using Feedburner since before Google bought it to save bandwidth and for some nice high level statistics on subscribers. This service has not been updated pretty much since Google bought it, to the point where it breaks if the source file for any given feed it wraps is encrypted, an increasingly common practice for web pages and resources, it breaks. I’d like to move off of Feedburner before the next breakage or Google ultimately shuts it down.

I have updated all the feed links for this site and for the podcast. I will be deleting my Feedburner feeds at the end of the month. Deleting a feed can be done with a permanent redirect. The redirect means you should not have to do anything in order to continue to receive episodes and posts. However, technology frequently doesn’t work as we’d like. If you are an active subscriber, you may want to change over your feeds, now, to avoid any possible problem.

To make things easier, here are all my feed URLs, so you can just copy and paste as needed:

  • – The feed for this site, includes blog posts and podcast episodes both. I recommend this feed if you want everything.
  • – The feed for the podcast in MP3 format. If all you want is the podcast and you are not sure about what kinds of audio your device or software supports, I recommend this feed.
  • – The feed for the podcast in Ogg Vorbis format. This audio format is patent and royalty free, if you are a support of free software and open source, I recommend this feed. It should work well on any Android devices and Linux software but your mileage may vary with Google and Apple devices and software.

For iTunes subscribers, I have taken advantage of their support for updating feed locations so you shouldn’t have to do anything.

I will make this post sticky for the next few weeks in case you miss the change over and come to the web site looking for an explanation of what has changed or broken.

TCLP 2015-04-12 Hope and Fear in the World of vim

blank_preview1This is an episode of The Command Line Podcast.

I share a quick game review in this episode of Coup and its expansion, Coup: Reformation. The feature is a reading of my recent essay about my favorite text editor, vim.

You can grab the flac encoded audio from the Internet Archive.

Creative Commons License

TCLP 2015-03-29 My Drivable Computer

My New CarThis is an episode of The Command Line Podcast.

This episode is an experiment. I recorded an extemporized monologue in my car during what is a fairly regular drive for my right now. I expressed my gratitude for, and inspiration from, Patrick McLean, in particular his return to The Seanachai, and Dave Slusher.

I talked about the new car I bought at the end of January, my reasons for buying it and my experience of genuinely feeling that I am driving a computer.

You can grab the flac encoded audio from the Internet Archive.

Creative Commons License

Hope and Fear in the World of vim

For some reason, I decided to step back from any integrated development environments at work and just use my preferred power editor of choice, vim. If you are unfamiliar, an IDE is a very powerful tool, like an assistant constantly at your elbow to remind you of how to code better, how to use libraries, and kick off any number of tasks like builds, deploys, and debugging. Early in my career, I resisted them, feeling that I should be able to be productive with a loose collection of individual tools. I finally caved when I read Martin Fowler’s “Refactoring” and realized that the one thing the IDEs at the time could do that my much beloved power editor plus command line could not was tear through a project’s code base, transforming the code smartly, based on an actual understanding of how source files fit together. The alternative was to use tools like sed, grep and awk to essentially do global search and replaces across many, many files. To do so, you had to explicitly write out what you wanted changed, character by character. In an IDE, you could select a menu option–extract method, introduce parameter, rename class, etc.–and provide very lightweight input like new names and new locations, depending on how you are re-factoring the code.

As much as I have been using IDEs for the past handful of years, part of me still felt they were a little intellectually lazy. I’ll be the first to admit that feeling is fairly irrational but that is how I have felt. I guess that a quiet part of me feels I should be skilled enough and deeply embedded in the languages, tools and projects I use to make the loose collection of tools approach work, strengthening my abilities as a coder as I work by being much more actively in the mix of those tools. Sort of how I feel about having a manual transmission on my car rather than an automatic. Except the clutch is n-th dimensional and I have to use all five fingers of my right hand, plus a few toes of the corresponding foot, to manipulate the stick through the gear changes.

I have to say, I am enjoying engaging deeply with my power editor of choice. Even though I took a break from coding professionally at my last job for about two years, I still used vim for any and all of my text writing and editing needs. Since the last time I used vim for coding on a regular basis, the biggest difference is how much more mature and robust the plugin ecosystem has become. While I still supplement vim’s incredibly powerful and efficient text manipulating capability with tools to search, check and build code, and more, a lot of very passionate folks have written some very nice glue code to allow those tools to be invoked from within vim and to interact with the way the edtior thinks about text and files.

I have been sharing some updates as I noodle around with my vim set up, focused on the editor’s main configuration file, .vimrc. In response to one of those posts, a friend, Jed, asked if I’d write a post about the plugins I use. I am more than happy to comply. If you are curious, you can read along at the github repo I created to house and share my hacking on my .vimrc. I have tried to comment the various files I use to explain my thought process and pay forward the many, many tricks I have found in recent days to make working with vim that much more pleasant than it is already.

First and foremost, there are at least a few ways now to automatically install and manage plugins, a capability that was sorely lacking even a few years back. Of those tools, I use vundle. I like it because it only requires a one time manual install then self manages updates of itself as well as plugins. It provides a really nice set of commands within vim, and in editor help explaining them, to search, install and clean up unneeded plugins. My main .vimrc simply sources a supplemental file, vundle.vim, that both interacts with vundle and itemizes my current raft of plugins.

I have a bunch of language specific plugins, I’ll forego discussing those, for now. The other, more general plugins are both more likely to be of interest to any random reader and contribute the most value, and joy, to my use of vim on a daily basis.

The first plugin I’ll recommend is airline. I have long had a custom status line in vim, one I configure to be always present. It showed a few useful things but projects like airline and powerline improve on this massively and make it possible to have a very slick looking set up. I use the patched powerline fonts, explained and linked to in the airline docs, to gild the lily that is the info rich display of this plugin. The readme at airline’s github project is its own best sales pitch, I encourage you to give it a read. I like it even more for being a vim native re-write of the original powerline plugin. It demonstrates just how incredibly powerful vim’s own scripting environment has become.

Another backbone of my toolset is exuberant ctags. This is a unix program that digests source code for any number of languages and builds a database of tags. That database allows a programmer to quickly jump around a code base, from reference to declaration. vim has long supported integration with ctags so that if you have an appropriate database built and accessible, jumping to a function declaration is only a hot key away. If my aging memory is right, this support predates most if not all of the current popular IDEs. I use the plugin easytags which allows vim to continuously refresh my ctags databases as I work. I pair that with the plugin Tagbar which allows me to open a split frame that uses ctags to present a code structure aware outline view of any source file on which I am working. Further, Tagbar integrates with airline, enriching my status line with more contextual info about where I am within any particular segment of code.

I use two plugins from github user scrooloose, NERDTree and Syntastic. The first brings in a file explorer that is way more powerful and easy to use than the already pretty nice explorer built into vim. The second integrates any number of standalone programming language syntax checkers, like jshint and Java Checkstyle. That integration allows me to jump around my sources, seeing where I have slightly junky code I might want to clean up or an actual break I definitely need to fix well before it hits a compiler or a deployed application.

I just added a tool called fugitive. Mostly I pulled it in to see my current working git branch in airline. It supports invoking git, the whole hawg of distributed version control tools, from within vim but I have barely scratched the surface of that. I am still creeping towards the deep end of git at present, at present trying to use more interactive adds to selectively commit not just whole files I’ve changed, but collections of fragments of files that are related, separating them from other changes in those same files I want to save for a subsequent commit, for a separate reason. Being able to use vim to select those chunks to build up more smartly commit sets is intensely appealing while still slightly daunting.

Up to this point, if you are a coder, you may be thinking that all these plugins do is approach but not quite compete with a modern IDE. I wouldn’t necessarily disagree, as I said, these plugins just make existing tools easier to keep at the periphery of where I exert the vast majority of my focus every day. I have such deeply ingrained muscle memory for vim that I can create and change text far more effortless with it than even the best editor offered by the best IDE. I have tried “vim” bindings in some IDEs and even an abomination that yokes vim directly to Eclipse but all they have done is remind me of what I love about vim.

There is one last plugin that I feel is the most compelling response to the refactoring support available in packages like Eclipse and IntelliJ. For geeks of a certain age, tools like grep and sed are equal parts comfortable and frustrating. They are so responsive to sifting through masses of files yet so demanding in the exactitude of their use. A few years back, a colleague introduced me to a kinder, gentler alternative specifically for coders, ack. ack combines the expression power of grep with a better understanding of the peculiarities of source code and programming language syntax.

ack.vim brings that useful and useable code searching into vim. In this case, search is only half the picture. vim supports macros, not in the sense of scripting or snippet expansion, but the ability to record and play back key strokes. Everything vim does can be invoked without taking your hands off the keyboard. I feel this is vim’s best, most under appreciated feature. Imagine searching for some repetitive fixture in your code you feel must change, something thorny enough to require ack to confidently spot all instances of it. Now, couple that, through this plugin, with the ability to repeatedly and correctly apply that transform, not just something superficial, but a complex interaction with every single occurrence you unearth. Using vim, ack and ack.vim may not be as simple as picking from a few menu options but it also isn’t anywhere near as constrained. I’ve used macros to work over related sections of text, multiple lines together, not just a line or two around a simple declaration.

I’ve only been applying this latest deliberateness to my use of vim for a few weeks. My hope and fear is that there is so much more to explore. Hope in that I already feel I have finally found a combination and integration of tools capable of giving any IDE a run for its money. Fear in that these waters run very deep indeed and my ability to plumb them is only so great.