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

In Some Small Measure, Wisdom

Picture of the Interior of the Jefferson Memorial, taken by Thomas Gideon

Yesterday I took what ended up being an epic walk. I have already written about how I have been walking more lately. Walking more has been easier over the last two months. I had been taking days off or at least working from home while focused on my job search. The other week, I had a sudden run of days in DC but hadn’t yet come up with attractive walking routes to help me keep up my new habit. In looking around an online map of what was nearby, I found Constitution Gardens. The Gardens truly are one of the hidden treasures of DC and I wish I had found them sooner. There is a huge water feature within which is a small island that has a ring of stone engraved with the signatures of all those who signed the Declaration of Independence. The Gardens are a decent half hour walk from where I work. Worked–today is my last day and my new gig is located much closer to home, in the suburbs.

During that first walk to the Gardens, I paused near the World War II memorial and happened to noticed the Jefferson Memorial was close by. On that day, I promised myself I would come back to see that site before my last day working in DC. I did just that yesterday, taking advantage of some cold but stunning weather.

The online maps make the memorial seem far closer to the Gardens then it is, at least by foot. I walked around the World War II memorial. I crossed several beating arteries of downtown traffic and started around the tidal basin. The view of the memorial as you walk under the cherry trees is breathtaking, especially on a clear, sunny day like yesterday. The view lingers as the walk around the basin is a good twenty minutes. When I finished my visit, I continued my around the other side of the basin which is even a little longer than the side I walked on the way down.

The time and distance (an hour and a half and more than four miles respectively) were only part of what made the walk epic, at least to me. Thomas Jefferson holds a special place in my regard. He attended my alma mater where we refer to him as either Young Thom or Our Thom. We used the latter especially around UVa students. Jefferson founded UVa but he was a student at William and Mary. The claim to him is part of the two schools’ long standing rivalry.

More importantly, when I was just getting involved in online activism, exploring topics around creativity and intellectual property in a post-digital, post-network world, a quote of his spoke to me deeply. In a letter to Isaac McPherson, he wrote this particular turn of phrase in talking about intellectual property, its nature and how we should think of its regulation, for instance by copyright:

Its peculiar character, too, is that no one possesses the less, because every other possesses the whole of it. He who receives an idea from me, receives instruction himself without lessening mine; as he who lights his taper at mine, receives light without darkening me. That ideas should freely spread from one to another over the globe, for the moral and mutual instruction of man, and improvement of his condition, seems to have been peculiarly and benevolently designed by nature, when she made them, like fire, expansible over all space, without lessening their density in any point, and like the air in which we breathe, move, and have our physical being, incapable of confinement or exclusive appropriation. Inventions then cannot, in nature, be a subject of property.

Visiting his memorial was a touchstone. At first I thought also it might be a farewell, a sort of personal resignation. I am leaving the world of working directly for the public interest to return to private industry. The memorial is filled with inspiring quotes, four of them in massive panels interspersed with openings out onto views of the tidal basin, the Potomac, and parts of DC. A more subtle quote is worked into the stone just beneath the dome.

I have sworn upon the altar of god eternal hostility against every form of tyranny over the mind of man.

Standing in a contemplative space dedicated to someone whose writings called to me across the generations, thinking about this transition in my life, that last part really struck me. Even though for reasons related to my own pursuit of happiness I was leaving the service of the public interest, in my own way I can certainly hold to fighting every form of tyranny over the mind of man. I can do so wherever I find myself, not in the least on this site and in my podcast as I am renewing and recommitting to my writing and thinking here.

That thought touched off what I hope is at least some small measure of wisdom I can take away from this job, more so than I have managed to realize when leaving jobs past.

Earlier in my career, I often gave into the urge to demonize the the people or experiences from a job I was leaving. I’ve read enough to understand I am not alone in feeling the urge to do so. Humans are story telling creatures. We continually weave a story of our own life. Our own individual narrative first and foremost supports who we think we are. When the world around us is at odds with who we believe ourselves to be, we feel pain in the form of cognitive dissonance. The easiest way to relieve that pain is to change our narrative, despite the facts, to restore the version of ourselves we believe is true.

I increasingly believe the secret of true wisdom is to resist rewriting our personal narratives. If we admit our own faults, the tale becomes the richer for it. We invite in opportunities to learn, to actually grow and honestly become more of whom we would like ourselves to be, in fact and deed. In holding more to the complicated, messy, objective facts of our lives, we can better embrace humility, honesty and courage, rather than simply rewriting the narrative. If we revise our story, we miss that chance to harness our faults and mistakes to urge us on to do and be better in the future.

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.

In a Job Search, Nothing Trumps Personal Advocacy

Jeff Atwood has an interesting, if somewhat bait-y, post where he asks if open source experience is overrated.  To be fair, Jeff has espoused support for open source development in the past and even starts the post re-iterating this position.

If you’re looking to polish your programming chops, what could possibly be better, more job-worthy experience than immersing yourself in a real live open source software project? There are thousands, maybe hundreds of thousands, and a few of them have arguably changed the world.

He then shares details from a personal correspondence, a developer recently undertaking a job search expressing extreme frustration at his open source experience not apparently helping persuade any perspective employers.  He culminates with the thought that Jeff uses as his bait-y head line.

One of the reasons I worked so hard on open source projects was to make job interviews easier. By providing prospective employers with large samples of publically available working code, I thought I would give them something more useful to think about than my performance on a particular coding test or whether the acronyms in the job skills matched my “years spent”. I am very aware of the hype behind open source. I’ve heard it, lived it and even spun some of it myself. But sometimes it’s good to take a sobering reality check — is open-source experience overrated?

Jeff certainly didn’t share the entirety of this person’s message but in the parts he does share with us, I fail to see the candidate doing much to actively answer the most important questions a prospective employer should be asking.

In principle, it’s simple. You’re looking for people who are

  1. Smart, and
  2. Get things done.

The irony that this advice comes from Joel Spolsky, Atwood’s partner in crime at Stack Overflow should not be lost on you.

As someone who has sat at least as many times on the hiring side of the table as the candidate’s, I have to say that being presented with a large blob of code by a prospect is less than helpful.  If I develop specific questions about coding style and competency then having such a work or set of works is indeed quite invaluable.  Its mere presence isn’t enough to persuade me of much of anything.

Don’t get me wrong, when I am sitting on the other side of the table, I include a small set of active open source projects as part of my arsenal.  But I don’t rely on their existence and availabilty alone.  I prepare for any given phone screen or interview by considering how my open source projects, as well as the rest of my skills and experience, are relevant for the position I am pursuing.

I see it as my job as a candidate to be my own best advocate.  I have to share truthful, accurate stories about how I am 1. smart and 2. get things done.  Open source or proprietary doesn’t really matter.  You have to get your foot in the door, spark enough interest until your interlocutor is prepared to look at some bit of specific work that you’ve done.  Merely presenting a portfolio of code doesn’t do much in the way to answer either question on its own without the narrative you provide to engage the interviewers interest and convince them your assets are not only applicable but valuable to the specific job requirements.

If you want to include your open source work as enticement, which parts of what you have done demonstrate your smarts?  Did you learn something during the development of the code that you did not know before?  Have you released multiple versions where you can speak to clear improvements made?  Is there a particularly clever or efficient bit you are justifiably proud of?

On the getting things done side, how many people are using your code?  How did you handle the inevitable bug reports?  Did you yourself use your tool or library on a larger project where it made a decisive difference in that other projects outcome?

These questions aren’t unique to open source experience.  They and many more focused questions like them are the sort of mental framing a candidate should prepare for all of their experience.  Tools, experiences, open source projects–they are all fodder for your advocacy efforts.

I am also stunned at Jeff’s lack of insight on the typical success ratio of a job seeker, even in a good economy.  To be fair, maybe he reserved any more constructive thoughts for a private correspondence.  But practically speaking, a candidate has to be prepared to continue applying for positions and advocating themselves until they have offers in hand.  Yes, multiple offers.  Not to play any games of leverage which I think are foolish and ill advised but to prevent you as a candidate from merely leaping at the first job that comes along.  Having more than one offer encourages you to consider each opportunity as a whole.

From snippets Jeff shared, it sounds like there may have been some cultural fit issues that this candidate ran into. I have run afoul of more than one organization that puts too much stock in coding tests or, worse, brain teasers.

One company seemed impressed with my enthusiasm for the job but it was part of their policy to provide coding tests. This seemed perfectly reasonable and I did it by using the first solution I thought about. When I got to the phone interview, the guy spent about five minutes telling me how inefficient my coding solution was and that they were not very impressed.

Did the candidate ask questions up front, such as whether the efficiency of the solution was a concern?  Really, though, I am more concerned at the prospective employer’s response.  It seems to me to be more of an excuse than a reason.  If they genuinely felt that efficiency was the problem, an excellent follow up question would have been to ask the candidate to characterize the solution in terms of big O notation or efficiency in general.  If that went well, then an exercise in re-factoring could provide further insight into how a candidate approaches improving their own code.  This is how an interviewer gets good information on the candidate’s intelligence and effectiveness.

In my experience, the urge to pontificate is a siren call when on the hiring side of the table.  It is heady to show off when you know more than a candidate but that’s missing the point.  If this interviewer felt this strongly, this negatively, then it would have only been worth the time to share an in-depth code review if they felt the candidate might have some potential worth mentoring.  And only then after exhausting the follow ups I recommended.  My advice to the candidate here is that this interviewer isn’t worth the time, not that it is a poor reflection on the candidate’s actual skills and experience.

Better yet, to keep this in the frame of using open source as fuel for self advocacy, did the candidate point out a specific example in his open source work that shows where he was able to address issues of efficiency?  Again, asking the interviewer to just review the totality of an open code base doesn’t demonstrate any particular grasp of the issues or questions the interviewer is pursuing.

Open source is no magic bullet.  Not a novel idea though in this case perhaps a novel application.  Just like a business cannot magically make its business model solvent by adopting open source, a developer isn’t guaranteed an edge by contributing to or starting open source projects.

I remain convinced by Jeff’s original stance, though my conviction long predates any expression of it on his blog.  Open source software can provide the benefits he lists.  But in any given situation, it is up to the developer to figure out how best to leverage that experience, whether it is with more straightforward tool support or code sharing directly enabled by the open licensing of a project or as in this case indirectly by way of the skills and experience acquired from being able to take the initiative to work in an open collaboration rather than waiting for the right opportunity, and abit of luck, to acquire those through traditional professional development.