2017-08-20 The Command Line Podcast

This is an episode of The Command Line Podcast.

I explore the value and appeal of complex learning curves.

You can directly download the MP3 or Ogg Vorbis audio files. You can grab additional formats and audio source files from the Internet Archive.

Creative Commons License

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

If It Sounds Right

One of My GuitarsWhen I first starting learning guitar, before I had a teacher and was just using books and videos to learn on my own, I worried whether I was learning good technique. I admit to obsessing a little bit about the shape of my grip, the arch of my fingers, whether I was fretting cleanly enough or not. I suppose I was carrying over assumptions I had from other skills into the pursuit of the new one. When writing software, there are definitely more and less correct ways of putting a program together. A lot is bound up in language and tool choice, often in terms of certain idioms that both affect correctness but also readability of source code.

A couple of months along, I decided I would benefit from a teacher. I didn’t really reflect on this choice but thinking back, I suppose it was motivated in equal parts by the desire to want to progress a bit faster than I was on my own and by that worrying over proper technique. One piece of advice I kept encountering was to make sure that whatever I was practicing, I should make sure I was doing so correctly. After a little searching, I found a local teacher with stellar online reviews.

My guitar teacher is great. He seems to have an intuitive grasp of when I need to refine something in my practice or am ready to stretch out and tackle something new. At first he took a little while to understand my tastes and interests. Some of that was no doubt do to how much those tastes have been changing and growing in the last year or so. Lately he has been supplementing more structured skill work with learning songs I enjoy, showing both the applications of the techniques I am learning and rewarding my efforts with playing real songs as opposed to simpler studies.

I expected from the start that my teacher would pay close attention to my technique and correct minute imperfections. This is how I learned Tai Chi, with an eye towards correctness, one that progressively looked deeper and deeper into form and movement. Brewing has involved close attention to key variables in the process, ensuring good control as well as exercising good taste. Why would guitar be any different?

A few months into my guitar lessons, we finally discussed my expectations, briefly. I had already started to realize on my own that there was something different in approaching guitar so really we just confirmed a certain truism that is common among musicians: if it sounds right, it is right.Basically, my teacher just confirmed this notion and we got back to the business of producing right sounding notes.

For most guitarists, certainly at my level of just gaining some basic fluency, the result usually far more important than the way it was produced. Guitar reinforces that because it is such a flexible instrument. The same note can be sounded on several strings. Chords can be constructed and varied in an infinite number of ways. Realizing this, I understand that training of the ear and using judgement takes priority over particular technique.

How can we draw a parallel with programming? Certainly when creating software for regular people, there is definitely a sense of what seems right trumping hard and fast engineering precepts. If someone sitting down at an app cannot figure out how to make best use of it, like a muddled or disharmonious tune, then it has failed. I suppose even the compiler could be thought of as enforcing a similar, if more rigorous, critical evaluation. Witness single line programming, underhanded and obfuscated contests that play with the plasticity arising from language rules and semantics while still producing something that can by some definition be deemed “right.”

What role, then do the volumes of text on correct theory and practice, for coding and guitar both, serve if ultimately the prime criteria admits so much variation?

If you are working with others, either to make some software or some music together, than a better understanding of your craft is invaluable. If you want to advance beyond a certain level of competence, as well, and tackle the greatest challenges, and hence feel the most keen depths of accomplishment, likewise you’ll need to cultivate an expertise beyond just a reasonably critical ear or eye.

Technical skill is a large part of the vernacular of a pursuit. To talk about challenges in programming, it helps to have clear and accurate terms and phrases. I have certainly struggled with some subtle aspect of a bit of code, for instance figuring out the right data structure, or kind of code to hole some information, that makes working with data simple, clear and effective in terms of code complexity and efficiency. When I don’t stop and really listen closely to someone trying to help me, I end up spending more time, struggling harder, than when I recall my fundamentals of computer science and theory. In either case, I usually get there, improving or fixing my program, but when I leverage the full depth of my technical mastery, I get there sooner and with much less stress.

I am only just learning music theory but see a strong parallel. Most times when I am learning a piece of music with my teacher, I have to trust the music as written and his recommendations of where I can vary from it. As I have been reading about scales, intervals and the basics of chord construction, I am now able to think back and understand my teacher’s guidance. I can easily foresee a day where my grasp of theory lets me interpret and improvise much more easily than I can now. Knowing the theory increases my appreciation even if I have to rely on trust more than a skill, or lack thereof, to reverse engineer a piece or part of a piece and really, rationally understand why it works.

The sound of a song, or the user apparent function of a program, is still important but truly understanding the hows of producing a result both deepens the ultimate appreciation and allows for even more nuanced play in both cases. The interplay between correctness and playing to ear yields a far more interesting result than hidebound adherence to trade craft. Strict formalism is sterile. Grit yields joy. In a song, that’s a catchy lick or memorable chorus. In code, it is a program that delights, that allows you to do something or something more easily while to the source code reader reveals a fun-loving and inspired mind.

Getting Back Up to Speed

I had three hours to write a JavaScript single page application that implemented a very simple Reddit client in the browser. I was assured I would likely not need more than one hour. At the end of the first hour, the interviewer checked back in with me to see how I was progressing. I had been struggling just to get the basic scaffolding of the application put together. I had used a lot of the hour on looking up libraries and tools as well as refreshing myself on my JavaScript syntax.

I managed to complete the assignment in a little over two hours. I felt not only frustrated but embarrassed at how long it took me as compared to when I was in my top programming form. The interviewer assured me it was fine but I knew it was far from my best possible effort. As it turns out, the interviewer was right. For that particular prospect in my recent job search, I progressed to the next round of interviews.

I wrote an Inner Chapter years ago about brushing up programming skills after a period of not using them. I wrote that chapter for a listener who had gone through some hardship and was looking for help adjusting. Partly it was coping with changes in physical ability specific to that listener, partly it was more general advice on sharpening skills. I’ve been thinking a lot again on the subject of getting back up to speed at programming having just left a full time management job to go back to a full time programming one.

Even in the first year at the job I just left, when I was still in more of an engineering role, I didn’t feel like I got a lot of practice at programming. They had some technology projects but the pace of and pressures on them were very different, being a non-profit, than what I had experienced up to that point. Even when I was promoted, a lot of my skills as a technical manager didn’t apply very well. The kinds of stakeholders we had didn’t really know much about the standard software life-cycle. I ended up spending far more time managing personnel, managing budgets, and fund raising rather than implementing and supporting processes for creating software in a regular and consistent way. It was a rare day when I got to work with technology directly.

As I’ve written about recently, a large part of my decision to leave that job was realizing how unhappy the lack of opportunity to code was making me. To make matters more stressful, during my job search I had to explain over and over again why I was leaving an upper management role and looking for work as a programmer.

“You are currently director of technology?” “Yes.” “You know this is not a management job, right?” “Yes.” “You’ve been a manager before. You truly understand this is just a programming job?”

I got very practiced at telling the story of my multiple runs at management. I would tell them that I never started as a manager. Working at a small organization, it would become clear, usually due to growth, that more leadership was needed. Foolishly, perhaps, I would volunteer, at least until they found someone better at managing. They never did. Eventually the strain and the desire to get back to programming would become overwhelming. Taking a demotion was never a practical option so three times, now, I have found myself in this same juncture.

I have only been on my new job three weeks but I’ve been thinking about a few experiences that could be helpful to someone else looking to get up to speed. I already shared the first one but I had several other experiences just as part of the job search process that I think are relevant. Just going through several successive coding assignments, especially in a very reflective state of mind, revealed insights I continue to ponder.

In that very first coding assignment, I mostly felt frustration. I had to look everything up, even the basic tools and libraries I was using. I had lost the equivalent of muscle tone. I couldn’t reflexively just spin up the bare minimum set up and configuration to get some arbitrary bit of new code working. I was struggling with my tools rather than feeling that they were smoothing and accelerating my efforts. The silver lining to that frustration was the immense sense of accomplishment on mastering it. As long as I remember this frustration, I am less likely to take my tools for granted. When I have felt that frustration again at the new job, even with more time and resources to get something done, I am able to see it in context, as a very normal part of the experience, trusting that if I persevere, I will be rewarded.

In a good environment, getting tools and configurations right will be a shared burden. My new gig is very much like this, though the work to keep the tooling up to snuff is a little bit of a guerilla priority. Engineers have to squeeze time in around things other people find more pressing. A lower priority on process and tools compared to more obvious business value is actually common in my experience. Regardless, I was grateful, as a consequence of the frustrations I felt during the coding assignments throughout my search. My new colleagues apologized for the roughness of the code and documentation, I was just glad to not have to do all the necessary grunt work on my own. I was motivated to contribute what I could out of that appreciation. I felt that contributing to improving the basic set up in this way paid forward the kindness done to me, lessening the frustration of the next new hire. Jumping in was also good practice to help with my overall brushing up and gave me an opportunity to understand the set up a bit better, always a good thing when the need to troubleshoot it arises.

I didn’t even have to get to the new job to realize some improvements in my disused coding skills. In the subsequent coding assignments, I was able to make better progress more quickly. I had to do a second assignment for the same prospect as that very first, super frustrating assignment. On that second attempt I was better able to focus on the challenge at hand and the quality of my code. I found that trend continued through a few other coding projects I did as part of my search. By the end, I was spending as much time on the code comments and the commit history, to really show off my thought process and how well I understand the problem I had been presented.

The last coding assignment I did, I completed in less than an hour. I got to show off a little, too. The problem definition included some hints that could easily be missed. It asked to include some comments on the code’s performance. I was given the maximum expected input size. Once I had the code provably working, as demonstrated by some unit tests I turned in with the assignment, I thought about that maximum input size. I didn’t think it was included for no reason so added a unit test that run a random input sample that matched the stated max. Not surprisingly, my code slowed to a crawl.

I was able to recall not just my core programming skills but also some troubleshooting. I didn’t fire up a full on interactive debugger but did add some logging. I worked from very broad to increasingly narrow sections of code until I had isolated the problem. I figured out and made some changes that my tests now revealed improved the performance to be acceptable. I even left some code comments suggesting how the performance could be improved further.

I think that just the opportunity to practice with some clear goals can do a lot to help knock off the rust. You may not always have coding assignments like in a job search but there are online resources that can serve a similar purpose. As part of my orientation packet at my new job, I was turned on to Code School. The topics are limited, focusing on web development with just a few technologies but I like the approach. The courses combine short instructional videos and interactive exercises.

Whatever resources you find to use, I think the practical aspect is important. I am still relying on books a lot, even if I am loading them on my tablet rather than accumulating heavy stacks of paper as I did far earlier in my career. The best books, just like the online courses, include exercises that give the reader a chance to work with the material covered. Application is key to cementing a new skill or reviving a disused one.

I suppose there is a role for trivia, accumulating simple facts about programming or tools, but it is less helpful when learning for the first time or getting back into the swing of things. When working through an exercise, I will often have one of two very gratifying experiences. I will either laugh out loud or nod and smile as some bit of skill or knowledge comes flooding back to me. I laugh when feeling the visceral joy of either getting something to work or even more powerfully, of feeling come concept really snap into place in my mind.

The next challenge for me is getting back into good daily habits for coding. I think I will save my thoughts on that subject for another post. Hopefully, my early experiences getting back up to speed make sense and are useful to at least some of you.

TCLP 2014-12-21 A Sense of Scale and Getting Back Up to Speed

Used under CC license, by Wikipedia user Sunil060902This is an episode of The Command Line Podcast.

In this episode, I share a couple more essays. Before the essays, I help spread the request for support from the GnuPG project. You can donate here. The first essay was already published on the web site, “A Sense of Scale.” The second essay is new, “Getting Back Up to Speed,” and I will publish it on the site in the next few days.

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

Creative Commons License

Searching for Myself

Detail of an orrery made by Benjamin Martin in London in 1767, used by John Winthrop to teach astronomy at Harvard, on display at the Putnam Gallery in the Harvard Science Center, used under CC-BY-SA, by Wikipedia user Sage Ross

I sat across a table today from an account manager at a staffing firm. I didn’t expect to be there. I had taken a phone screen the week prior, my first in-depth technical assessment, that I thought I had completely fumbled. Looking back at my notes from right after the call, I wrote in big block letters, FAIL.

Right after that, I wrote three quick bullet points, things I needed to do in order to avoid failing like that again. In a nutshell, I had not prepared for the call. Things I knew when I was more actively programming refused to pop instantly into my head. Instead, I struggled even though I knew I knew the answers to his questions. The questions were mostly what I call technical trivia, information that is easily searched for online and rarely demonstrates a grasp of useful programming knowledge or skill.

I have since made good on those action items in my notes. I promised myself I would not take an opportunity for granted again, preparing as best I could for each one from here forward.

I have been on the job search a handful of times over the years. I am not sure I previously had such a moment of self awareness. In the past, even under difficult circumstances, I found it too easy to take my knowledge and skills for granted. If I failed, I wrote it off and blithely looked towards the next opportunity. If I had to be charitable in explaining myself, I suppose I would say that more often than note I have had the good fortune to be looking when time was a luxury, when I was still employed. Dismissing a failure without learning from it didn’t seem to carry any meaningful risk.

For some reason, this failure was different. Maybe it was because of an earlier failure in the same search. I had come close but ultimately failed at a first opportunity when I started my search in earnest, back in September. That first chance was like all the others, I guess. I didn’t especially prepare. I relied on my wits, my ability to communicate, and luck more than anything else.

When I didn’t get that job, I was crushed. I really liked the company and the people. The whole experience was great, even doing a thirty hour quick turn around trip from coast to coast. The role was a new one to me that seemed like an amazing way to both return to more hands on technical work as well as to continue to engage my writing and speaking skills. They even found me through my podcast, rather than the other way around.

Maybe the disappointment, in myself as much as anything, was a wake up call. I had used several weeks pretty much exclusively on one job prospect.

At that time, I didn’t have an end date for my current job. I have been blessed to have my hard work during a difficult transition be rewarded by my current employer with support and patience. I now have an end date, one that is still incredibly generous, not in the least because they know I am actively looking. On some level, I knew even before I discussed an explicit end date that it would come, that it would be soon. Realizing I had worked through several weeks with no other prospects to show for it definitely lit a fire under me.

I may have over compensated. I usually am skittish about working with recruiters or staffing firms. In my experience, they don’t save time and often focus on opportunities very different from the ones I find most rewarding. Despite my prior experience, I didn’t feel like I could afford to leave anything unexplored. After I applied to all the obvious good fits, I kept on applying, to the consulting and contracting jobs I know I could do but that I would not enjoy anywhere near as much.

That is how I ended up, today, at a staffing firm talking to an account manager.

Up to this point, I had convinced myself I could and would pursue this all the way through. Part of me added, “if I had to,” to that last sentence while the rest of me, prior to today, worked hard to ignore that contingency. This account manager called me on it.

He grilled me about the usual stuff. Had I used this technology and where. What about this tool. How had I approached this challenge, solved another problem. At some point, he stopped. He looked at me and asked me frankly if I felt I would be happy at this job he was pitching. He went so far as to explain that his reason for asking is that he suspected I wouldn’t be. At the risk of his commission, he didn’t think that made sense in the long run.

For a moment, I prevaricated. I doubt he even noticed, the moment was so fleeting. I admitted he was right. I admitted it as much to myself as to him. Giving up on an opportunity, even one I knew wasn’t right, didn’t feel great. But the notion of stringing it along only to say, “no,” when a better offer came along didn’t feel any better.

At that moment, I realized that this entire  job search really was different. In the past, I have always at least tried to focus on what I really want to be doing. I haven’t always succeeded. I don’t think I was making as intentional choices as I could have, rolling with what came my way and rationalizing it after the fact. My engagement and especially my learning from those experiences were thin at best.

For this search, the stakes haven’t really changed. I still need a job, ideally before the end of this year. What has changed is my openness to being honest with myself. I am far more willing to learn from every single experience along the way this time around. Maybe opening up will improve my prospects, maybe it won’t. I am pretty sure I will find the rest of my search far more rewarding by admitting that I am both searching for a job, for a career next step, and at the same time, searching for myself.

Keep on Walking

8286401024_e0441285ef_oI woke up late this morning, at least late for a weekend. Despite sleeping in, my mind and limbs felt heavy. I skipped my usual habit of making myself breakfast from scratch, instead throwing something frozen in the microwave. Out the window, the neighborhood was gray, wet from overnight rain. I felt unmotivated to keep at another, more recent habit, of taking brisk walks on as many days as I can. I will be traveling this coming week, I knew I should get out of the house to walk when I have the time and space so I feel less bad if I have to skip a day later on.

(Photo by Derek Adkins. Used under a CC-BY-SA 2.0 license.)

The sun broke out for a moment a little later in the morning, painting the houses across the street in warm, liquid gold. That sight was all the invitation I needed. Once I started moving, it was easier to keep moving. I have mapped out a few different routes, of various lengths. I can choose based on the time and my motivation on any given day. Better yet, the routes overlap. I can make a decision in the moment, to head home sooner or to push myself, to get my heart rate up a bit more, for a bit longer.

Today I chose to take my longest walk yet. I am proud of myself. A parade of chill and drab lawns and homes didn’t dissuade me. Having the choice of a quicker loop counter intuitively invited me to choose the longer loop. In the home stretch I contemplated that decision for a bit, how just putting myself in a situation to make smaller, more active choices lead me to a better outcome.

Just like I shared in another recent post, I broke my problem into smaller pieces. More than that, mulling over those pieces while in the midst of them helped me make a connection. I realized at least one reason this idea works, for my anyway. I made a connection between a powerful idea and putting it into actual practice. I had an experience I will try to keep in mind as I contemplate larger projects, whether they are writing or coding. I will try to find parallel experiences that bolster this perspective of a series of simple choices.

As a budding musician, I have been thinking about a phenomenon that I realize is similar. I am best able to play a song without sheet music correctly when I don’t think about the whole song. Rather, the playing flows best when I am just anticipating the next change. I had very similar thoughts the last time I was actively studying Tai Chi. Dozens of poses are daunting all together but when in the midst of doing them, just remembering the movement to the next pose is all it takes to get through to the end.

I have been returning to reading technical books, as part of my renewed focus on coding. I have worked through more than a few short exercises and tutorials. I can bring a greater awareness and intention to these efforts. I can choose both short, attainable chunks for each time I sit down to chip away at refreshing an old skill or tackling a new one. Better yet, I can give myself some possible next steps, an invite I will just as likely accept to continue working for a little while longer, with more energy and focus.

Ironically, I had a topic on my writing list for I don’t remember how long, on the loss of motivation. Today by holding to the thoughts that occurred to me while out walking, I was able to present myself with another easier step. I have some more ideas in my notes for this topic. I took the first step by putting my butt in the chair to share some fresh experiences and thoughts. I will no doubt feel less inertia to overcome when I return to this topic, to talk more about what causes loss of motivation and other ideas for restoring it.