Friday, February 24, 2017

A little something written by Mirko Borach ("Stringburner"), with Mirko on bass, Daniel van den Berg on guitar, Danny Handler on drums, and me on piano. I love this track, and especially love the playing of the musicians. Killer work. And another example of how a multi-disciplinary, remote team can create something effective and excellent with good communication, individual expertise, creativity, and empathy.

Tuesday, January 17, 2017

When you're too busy to eat, eat.

Here's what happens: 

I'm coding, and am deep into the "zone". One moment it's 11am, and the next it's 7pm.

I'm practicing piano, or working on a new music project. One moment it's 11am, and the next - 7pm.

Here's what used to happen when I finally took a break: 

I'd rummage around the kitchen looking for something to make for dinner and finally settle on a delivery-menu & just order something in.

Here's what happens now, when I finally take a break: 

I take the pot of some home-cooked delicious food out of the fridge, put it on the stove, heat it up, and have a healthy meal.

Staying healthy is a proactive process.

Look, fellow software devs, we've heard it before: you have to stay healthy, and it not only means getting the ever-expanding butt out of the chair and getting some exercise; it also means eating wisely, featuring home-made and healthy food.

Not a cook? Don't have time for it? Who cares? You are, you do, and you should -- all of those burritos, sushiritos, pizzas, chicken & waffles, and craft-IPAs will catch up to you - and sooner than you think.

This is delicious. 

This is easy, and freaking delicious.  It's one of my favorite, go-to one-pot-meals that lasts a few days and is a great re-heater. I prepare it on a Sunday so it is ready at a go during the week.

Trust me on this. Follow along. Most of the time you'll spend on this will be doing other things: the cooking happens while you're not paying attention to it.

2 packages of chicken thighs (bone in, skin on) 6 to 8 pieces.
2 cups of good, dry red wine (Pinot Noir, Merlot, etc)
3 sprigs fresh thyme
1 bay leaf
1 sprig parsley
4 to 6 shallots, peeled
2 T olive oil
salt & pepper
1/2 Cup dry farro

In a good dutch oven or braising pot, heat up the olive oil over a medium to high heat. Add a little salt and pepper to each of the chicken thighs. Once the oil starts shimmering, put in the chicken thighs, skin-side-down. Brown the chicken for 4 to 6 minutes. How do you know when the chicken is browned? The skin side will be.. wait for it... browned. Literally. They will go from chicken-skin-colored to various shades of cooked-over-heat-brown. If you're getting some spatter from the pot while they're browing, put the lid on.

Flip the chicken over and toss in the shallots, and let them cook a little in the oil and chicken fat for about a minute. Then toss in the thyme, bay leaf, and parsley sprig and the 2 cups of red wine.  The chicken should just be peeking above the surface of the wine (also known now as "braising liquid"), and if it isn't, add more wine.  Once the wine starts to boil, toss in the farro, stir it into the braise, and lower the heat so that the pot is simmering, and not wildly boiling.  Put on the lid and set a timer for 45 minutes.

Check the simmer after 10 or 15 minutes - you want a slow cook, not a roiling, steaming boil. Once it's simmering at a nice gentle-to-moderate pace, you can leave the heat alone until completion.

After about the 30 minute mark, check on the farro. It should be distributed reasonably evenly, and you may need to stir the pot a bit. After the 45 minute mark, check again. The farro should be al dente, slightly firm to the bite.  If it needs more time, give it more time.  This recipe is difficult to overcook, but by the 60 minute mark it should be done, and the farro al dente.

When it's done, it's done! Leave the lid on, take it off of the hot burner, and let it sit. Once it's cool enough for the fridge (room temperature will do), put it in the fridge.  Reheat during the week as needed. 

All of the ingredients can be found at a good supermarket. If you really can't find farro, you can order it online. 

Don't have a dutch oven or a braising pot? I'm a big fan of Staub. On a trip to Paris, I noticed that every good restaurant I'd visited used this brand. This is a buy-once-use-forever purchase. 

This is just good, home-cooked comfort food. You know what went into it, you can control the salt and fat content (just dump out the fat after you've browned the chicken if you want to cut back), adjust the amount of thyme or other herbs, and so on.  Want more veggies in there? Add some carrots, parsnips, small potatoes at the beginning.  Don't care for farro? Leave it out and serve over pasta you cook on-demand. Options; you have them.

The combination of chicken (protein and fats), farro (whole-grain fiber & carbs) and some veggies means you're eating well. If you're like me, you won't need much at one meal - this stuff is filling!

And yeah, it does require that you get up and away from the computer (or piano or guitar or DJ rig) and get to the store for stuffs, but you had to do that anyway, right? A little bit of time one day a week means an easy-to-reheat homemade one-pot meal you don't have to think about when you're otherwise busy creating things.

Sunday, May 15, 2016

A short comment about the technical interview

There’s been a terrific backlash against the whiteboard-test commonly given in technical interviews. I think it’s a terrible tool to use in an interview. What the hell is the interviewer really testing for? Proximity to date-of-graduation? How well someone has memorized a breadth-first-search algorithm?

The first question I asked myself after several years of being a bad interviewer was “What am I really testing for when I interview a candidate?”

What’s the goal of each section of the interview? Better yet, let me back up even more: What are the values of my product development team (the team that includes the software developers) and the values I look for in co-workers?

Once that’s answered, an interview can be developed to filter for these values.

That list is for another post, so for now I want to focus on two values that’s pertinent to the kind of developer I like to hire: The ability to intelligently, quickly, and accurately find solutions to tasks and problems and implementrobust(1) solutions quickly. And: Are they a mature human being who can communicate well, govern their emotions while under stress (interviews are stressful), and have some level of intellectual curiosity with the ability and drive to satisfy this curiosity?

One of the big complaints lately was about getting the dreaded (and useless) “Go to the whiteboard and code a BFS”, or “Go to the whiteboard and code a maze-solver”, one solution for which requires a BFS and an implementation of Dykstra’s shortest-path algorithm (I had to look it up, of course). I’d never ask someone to do that at a whiteboard sans tools, references, etc., ever. What the hell would it tell me other than how well the candidate can remember university CS degree work? (Maybe it might tell me whether a developer suffers from not-invented-here syndrome, but that’s probably silly, and I digress)

But the question itself is a good one. Even though very few developers, especially ones who’ve been working for several years, can stand up and — under the stress and pressure of an interview — code this up from memory. But most developers understand the problem, regardless that this is one that seldom comes up in the daily grind of work, and given the right tools the best candidates can arrive at the solution. Now I don’t know about you, but I want to work with the kinds of devs who can find the right solution using the right tools.

So here’s what I’ve been doing to replace the whiteboard test: I want to know what kind of person the candidate is to work with. Given an uncommon problem (implement a maze-solver, or implement k-Nearest-Neighbor), lets use the tools we’d expect to have available to us day-in-and-day-out and come up with the beginning of an implementation. So therefore, the candidate and I sit side-by-side in front of their laptop and I watch them, and if necessary coach them through, work on the task.

I look for several things: do they search for solutions in the problem domain; can they discern between correct and robust solutions vs. incorrect, hacky solutions; a corollary to the previous point is do they understand what they are reading, and understand the underlying algorithms and implementation; do they simply pick the first answer they find from Stack Overflow? (a big red flag). This latter point should tell me whether or not a candidate truly understands data-structures.

Overall, can the candidate research, understand, and implement a correct solution to a problem that’s either unfamiliar to them or not memorized and do so in an environment that resembles the real-life environment of our team? What are they like to work with? Are they eager to learn or uninterested in anything not immediately familiar? Are they easy to work with or easily frustrated and/or defensive? Can they use the tools they will be expected to use in their daily work(2)? Can they communicate clearly? Do they ask pertinent questions?

I think that the best way to find whether or not you want to work with someone and have them on your team is to — wait for it — work with someone. Although an interview of an hour or two isn’t the same as working with someone on a team (it’d be great to bring in a candidate for a day or two and have them work alongside us, but I haven’t figured out how to get this though H.R.), it’s close enough if and only if you set up the interview to simulate as closely as possible the actual conditions of your technical environment.

(1) adj: strong and effective in all or most situations and conditions

(2) And we’ll do some debugging too. Can they and do they use a debugger, logs, and print statement? Do they ask the right questions when debugging: what do I expect the code to do, what is the code actually doing, and how do I know it’s actually doing it?

Tuesday, January 05, 2016

Minding your I's and T's

The rant.

The CEO was exasperated. "I'm at a loss, J, and I'm never at a loss." He waved his hands in the air, and was speaking quickly and loudly. "I hired the best and the brightest. A-players, all of 'em. I hired the best developers, a data guy from Google, you name it. I can't get them to ship a damned thing."

I nodded, and listened. He said, "They can't get a [expletive deleted] thing out the door. Yesterday saw the third time two of them came to me and insisted we need to re-write everything, whatever that means, again. They told me it's six months of work! They've rewritten everything, whatever that means, two times in the last two years. If they're as smart as they say they are and as smart as I think they are, why do they keep writing software that needs to be completely re-written?"

The litany of complaints continued, "They don't talk to each other. Half of them never come to the office. This one writes a server API that that one won't use, and they spend weeks - weeks, J! - arguing over how the two systems should talk to each other. If they'd just spoken with each other in the first place they wouldn't be in that mess. They ignore my designer, who's a great designer by the way, they won't speak with the product lead, who's a great product lead by the way, except to tell her that they've missed the deadline. They tell her this on the day of the deadline!  Up until then, it's all peachy when she checks in with them - they're confident they'll hit the deadline, until they don't. Terrible communication. It's killing my company."

He continued, "I'm a sales guy, you understand? I don't know tech. I hired these technical guys to get the work done and ship the product, not to argue over the little things and get stuck in analysis-paralysis.  Nothing's been shipped, and I can't get all of them into a room together unless I call an all-hands. And then they just complain that I'm rushing them; that software takes time and all of the ship-dates for product we decide on create technical debt. I don't know what that means, and I don't want to know. I want happy, paying customers, and I can't get them without shipping product."

"I don't get it," he said, "I hired the A-players, the best of the best. I thought that's what we're supposed to do."

I said, "It sounds like your developers don't collaborate. Not with each other, and not with design or product."

"No [expletive deleted]!", he said.

The advice.

This is where I put on my adviser hat, such as it is. I said, "First of all, lets talk about hiring, and then about how to try to fix the mess you're in."

"You did what most everyone likes to do, and that's recruit the smartest, most able people in their domain of expertise. The best designer, the brilliant developer, and so on.  You hire, or try to hire, for skill in a specific area, and fail to hire for all of the other skills that are necessary for a team in a business to succeed."

I continued, "So, the first thing to fix is hiring.  And the first question is: what are your values? What do you value the most from a product team? I don't mean just the devs, but I mean the whole team. Design, product, quality-assurance, developers, customer support, everyone composing that team.

Is individual skill and ability the most valued? What about collaboration and teamwork? Communication? How do you identify the abilities that allow for shipping the most engaging, quality product and features?"

The CEO interjected, "I value shipping. Ship and keep shipping the best product, and a solid, unfailing, and great customer experience." he emphasized, "Get it done. Get the work done. Increase revenue."

I nodded, "OK, then! So clearly, we want to hire for the abilities that support that, and not hire only for 'smart'. What if I said: when hiring developers, we value (among other things) drive, intellectual curiosity and the ability to satisfy that curiosity, good or great communication skills, wisdom to know when and what to apply the best-fit solution for the business problem, and domain expertise?"

He nodded, "I'd call that just 'smart'. I'd consider all of those things covered by 'smart'"

"OK", I said, "So how do you hire? What'd the interview look like?"

"Well, we do a phone screen of some basic computer science stuff. Anyone with a degree and a handful of brain cells should pass it. Then we get them in the office and present to them some tough problem, and ask them to solve it on the whiteboard."

"Do they have access to the internet during the interview? Can they research solutions? And what's an example of a question?

"Hell no. If they can't solve the problem on their feet, they're not smart enough for us. An example, well, we took a bunch of questions from Google and Microsoft. Here's one: 'Write a routine to calculate the optimal price for washing all of the windows in San Francisco.'  We also ask them to do some technical thing, my guys call it a 'data-structure test'. I don't know what a data-structure is, but whatever it is they're [expletive deleted] it up because they keep asking for six more months to re-write everything. It sounds to me like everyone here has failed that test!"

I said, "So in other words, you're testing in interviews for raw intelligence and domain expertise in the programming language your team uses. Where's the test for how well they can find a solution to a problem, or communicate effectively, and so on?  You're not giving one. You're not hiring for your own definition of 'smart', as you've just given it to me. Also, Google has dropped those brain-teaser questions. It doesn't correlate to great hires, and it just angers the candidate, these days.

So, look.  Drive, right? That's the desire to get things done. To ship. I like to look at what a candidate has done previously. Ask them what they've shipped in the past in previous jobs. Get them to talk about it and look for whether they mention a team or not. Was it a one-person effort? That's a sign that they may not have worked on a successful team. What do they do outside of work? Did they self-publish a novel, or complete the marathon? Are they bike enthusiasts or play some team sport? Do they DJ parties, or put their own music up on the web? Did they meet some goal, like read 24 books in a year? I  look for indications of a wide range of interests - that's the intellectual curiosity part - and a drive to produce, to create, and to achieve. And, can they collaborate? Can they and will they communicate early and often? This last one's a tough thing for which to interview, but it can be done."

I continued, "Problem solving. In an interview, lets give the candidate some challenging and pertinent technical problem to solve.  Unless you're in the window-washing business, the one you've been asking is not an appropriate question. How about asking them to do something they either have never done or haven't done in a long time? For example, implement some complex data-structure that they might encounter as a part of their daily work. We've all done data-structures in school, but for some people, school is a distant memory or some structures weren't a part of the curricula. So, using a laptop and the candidate's preferred development environment, work together to implement the data structure, a few functions, and a couple of tests. Use the internet to research solutions and discussions.  I look for whether the candidate can identify quality information amidst the crap that's out there; which websites they choose for research (if any. Big red flag if they don't research anything); and how well they understand and can implement the information they find.  That's just an example. This whole process will take some thought and preparation."

Minding your I's and T's

I asked, "Have you heard of Tim Brown?"

The CEO said, "Yes, of course. Famous CEO of IDEO."

I nodded, "Great. He spoke and wrote about I-shaped and T-shaped people and successful cross-disciplinary work. By the way, almost all modern product development is cross-disciplinary work.

It sounds like your interviewing strategy is biased toward I-shaped people, when what you need are T-shaped.  Tim Brown said,"
T-shaped people have two kinds of characteristics, hence the use of the letter “T” to describe them. The vertical stroke of the “T” is a depth of skill that allows them to contribute to the creative process. That can be from any number of different fields: an industrial designer, an architect, a social scientist, a business specialist or a mechanical engineer. The horizontal stroke of the “T” is the disposition for collaboration across disciplines. It is composed of two things. First, empathy. It’s important because it allows people to imagine the problem from another perspective- to stand in somebody else’s shoes. Second, they tend to get very enthusiastic about other people’s disciplines, to the point that they may actually start to practice them. T-shaped people have both depth and breadth in their skills. [1]
"He also said",
Most companies have lots of people with different skills. The problem is, when you bring people together to work on the same problem, if all they have are those individual skills-if they are I-shaped-it’s very hard for them to collaborate. What tends to happen is that each individual discipline represents its own point of view. It basically becomes a negotiation at the table as to whose point of view wins, and that’s when you get gray compromises where the best you can achieve is the lowest common denominator between all points of view. The results are never spectacular but at best average. [1]
"So in your case," I told the CEO, "your developers are spending most of their time negotiating, and by that I mean arguing and debating, with each other as well as with product, design, sales, and executives.

I like to hire with a bias toward the values we've discussed, and I look for things in the candidate's history that shows some sort of teamwork. Were they in a band in college that managed to play a few gigs, and what happened to the band? Did it implode under conflict of personality, or enjoy a fine local run before everyone graduated? Are they on a cycling team, or a rowing team? Are they a part of a burning-man collective? A regular contributor to an open-source project? Have they had to manage collaboration not only with each other but with coaches or customers? You get the idea. I try to spend a lot of time with them, to get a feel for how well they collaborate, communicate, and of course how intelligent and driven, empathetic and enthusiastic they are."

I concluded, "Think of this problem as concerning a whole team, not just as a team of developers who have to interface with other teams. Design, product, all of them make up your team.  I think of analogies like a great band, or a great sports team. You're going to need the right players who all understand and are in agreement of the goal, can communicate effectively, certainly can perform as individuals but just as certainly can perform as a team, collaboratively.  The Dave Brubeck quartet. The 1990s-era Chicago Bulls.  Not everyone loved each other, but they could superbly work toward, and achieve, a goal.

[1]  IDEO CEO Tim Brown: T-Shaped Stars: The Backbone of IDEO’s Collaborative Culture

Sunday, September 20, 2015

One Very Bad Awful and Ridiculous Interview

It became apparent in late 2014 that my entire team, including me, was about to be laid-off and our products "sun-setted". We were an isolated group in a huge company, and such is the fate of most acquisitions and "labs" groups.  And so, I started looking for a new job.

Most of the technical interviews were benign but unremarkable, unfocused, and vague, and the interviewers ill-prepared. most of them caught flat-footed when asked if they could go interview this guy sitting in conference room "Thailand".  It seemed that most wanted to know whether I could reverse a singly-linked-list from memory (mine, not the computer's), via iteration and via recursion (That just tests for how well I remember the work from my CS classes, but that's a topic for another time).  Anyway, most were just fine, pleasant and uninteresting experiences. Some, however, were hair-raisingly bad. Terrifically bad. 


Over a couple of months I spoke with 17 software engineers, managers, and CTOs. Five of them were either openly hostile or terrible. That's 29.5% of the interviewers. To be fair 4 of them were from the same company, so if we reduce to the number of companies (excluding the one I'm at now), one of four provided horrifically bad culture.

The bad ones went something like this:


The interviewer entered the conference room at 10:20 for our 10:00am interview. He closed the door, sat down, and placed a paper copy of my LinkedIn profile on the table.  I watched as he read the first page. 

"So", he said, "It looks like...", he paused, "'re not a software developer. Is that why you want to be a manager? Because you don't write code?"

My profile is clear that I do write code, and have for many years. I asked, "Sorry? Are you sure that's my info you're reading? And, also, I love writing code."

"Hmmm", he said, flipping through the three pages, "I think so. This is the resume you sent?"

"Well", I said, leaning forward to see that it was actually my information he was looking at, "It's my LinkedIn profile. That's what I use for work history."

He nodded. "Well. Ok, So it looks like you are a musician. Are you looking for a day-job or something? How do I know you won't just leave when you start making money in music, or leave to go on tour or something?"

(I immediately forgave him his massive ignorance of the music business, and for overestimating my desire to 'go on tour')

"I write code, and manage engineers. You can see there.. mostly Python, some iPhone work, JavaScript, and prior to that a bunch of other languages that I don't really touch anymore."

"Python? That does not count for it is a ridiculous language. You should learn Ruby and JavaScript.", he said. He tilted his head back as he talked. 

"Yes, ah, well, I'm pretty sure it says JavaScript in there, right...there. Anyway, I'm familiar with Ruby." I asked, "So, what don't you like about Python?"

"It's a language worthy of ridicule, therefore it is a ridiculous language.  And did you learn Python in a code school or something?"

I replied that no, I'd learned it, by myself, in order to start a company building web applications and Facebook apps, back in 2007.  I had to pick up Python and ActionScript, and get back into JavaScript. 

He nodded, "And you did that because your music career wasn't taking off? Is that when you decided to change careers and become a programmer, in 2007?"

(My profile clearly lists my first programmer job, and it's wellllll before 2007).

"No, it's because I love building things on computers and getting them to market. And I've been a professional programmer, since, a long time, look here, this line, my first programming job. So no, I didn't just change careers, as you put it. I did move to consumer web and away from enterprise software. So that was a change. "

He asked, "The enterprise software work is pointless. So. What's an example of something that I'd recognize that is in the market right now?"

I said, "Pono Music.  The rest of the stuff I've worked on or published are all dead, or sunsetted."

"OK", he nodded, "Music doesn't count.  And if I can't see and touch what you've actually created, then they also do not count. So in other words, you have actually done nothing. Let us move on to the next question. Do you contribute to any open-source that I can look at? Your github page was fairly non-existent."

"Very little", I said, "I'm not a recreational coder. I do have some private repos I can show you, with recent code."

"What language is it in?", he asked with a tone of extreme caution. (He just as well have asked "Does that cake have a bomb in it?")

"Python", I replied.

"No thanks", he said, "If it is all Python then it is insignificant. It does not count.", he said while looking at his phone, and scrolling through what I imagine was his email. Or his Twitter account.

"What do you do that is recreational?"

"I read", I said, "I create music, or cook, or write. Other things that don't involve coding."

He looked up from his phone, "You should just write code. Serious professional developers write code and contribute to projects on their own time. No one will take you seriously otherwise."

"I can't believe that the well-respected devs out there who spend weekends riding bicycles, or climbing, or spending time with their families, or doing other non-coding things aren't respected."

"Bah. Those people are douche-bags, not generally-respected-developers."

He put down his phone. "When is the last time you wrote code?", he asked.

"This morning.", I said. 

"What was it?", he asked. 

"Some software to control a synthesizer module via MIDI messages."

"Why would you want to do that?"

"It's a vintage piece of hardware, and it's FM synthesis. It's easier for me to program the synth from a CLI than it is from the little LCD screen on the front panel."

"That sounds stupid. Actually, what you should do is, there is this thing called Logic, it's recording software, and you should use some what-are-called virtual instruments. It's like a real piece of hardware, but virtual. But you need to be on Apple hardware, which you are probably not."

"Yes, I know what Logic is, thanks, I have it. And a Mac."

He feigned surprise, "You have a Mac? Quite Impressive! I had you figured for a Windows person. I am surprised and a little impressed."

"I use Ubuntu for work, actually. Windows for games."

"I didn't figure you for a gamer either."

I shrugged.

"So when did you learn to code?"

"I started when I was ten years old. And I took CS in college.", I replied.

"Everyone codes when they're ten, that's not very impressive.  Why didn't you finish your degree? Music again?'

"I finished my degree. See?", I said, pointing toward the paper in front of him, "CS degree."

"Oh. Yes. I see. That was a long time ago, so it kinda doesn't count.... So. How old are you?"

(By this time, my face was a glowing, red-hot coal, and my answers curt.)

"Uh, that's probably an HR violation, but I think you can do the math..."

"We don't have HR here. But you're like my Dad's age. I guess that's OK. I'm pretty shocked that you even know Python, if indeed you actually do know it...", he looked at me the way Sherlock Holmes looked at one-twentieth of a piece of cigar ash found on a recently dead body,  "...but it makes sense that you've never heard of Ruby. No one can stay on top of new technology after the age of thirty-five. So what's your super power?"

I let the age thing go as generational-conceit and not ageism. "I have heard of Ruby, I just have not made the opportunity to work with it much. My super power.. getting things done. Creating and delivering product from idea to consumer."

He waved his hands, "Examples?"

"Several CDs of music, for example, and an app I sold to a company. Also some web apps I put out there to test the market, and for work: several products. Listed there, on the LinkedIn page..."

"CDs do not count. No one cares about that. And music is easy. Everyone does music. I do music at home.  Being a DJ is common. Everyone is a DJ now. It's a thing."

"Uh, not a DJ", I said, "I compose, play and record the piano and keyboard parts, hire musicians, designers, mixing and mastering engineers, manufacturing, the works, the whole process to final product."

He shrugged and continued, "And no one cares about apps that sucked or got bought or from dead companies. That is not a super power."

"Well, that doesn't detract from the fact that I produced and developed and coded and delivered these things. I get stuff done."

He waved me off and shrugged, "No not really. No one cares."

He handed me a whiteboard marker. "Ok, now we need to do the dreaded white board test. Almost everyone fails this. I think it is elementary.  Go up and reverse a linked-list for me. If you don't know what a linked-list is just say so."

I pointed at the whiteboard, on which were pseudo-coded two routines: one to iteratively reverse a singly-linked-list and another to do so recursively.  "Your predecessor already asked me that question."

He read the code on the board while slowly stroking his beard, and said, "Wrong.. I would not do it that way, no, that's wrong. Well, points for trying, I guess?"

I asked, "What's wrong with the code? Your predecessor said it was correct. We walked through it, by hand, and it does what it's supposed to do. I'm pretty sure that'll work.  Lets look it up and compare my answer-"

He interrupted, "If you have to ask that question then you would not understand the answer. And I do not need to Google it, I know how to linked-list. The only good thing I can say about that code is that it is not in Python. I do not allow Python in my office. It would be better if that wasn't pseudo-code, but given your limitations it is acceptable." He shrugged.

"Are you sure you wouldn't like to see some examples of my professional work? I have a repo we can walk through.", I asked, but really knowing it was futile.  There was no way on this good green Earth I was going to take a job at this place, even if they offered.

He shook his head. "Python?"

I said, "Yep?"

He made a face, "Ew. Disgusting."

I shrugged. 

He stood up. "Well, to be completely honest I do not think you are a good fit for us. We can't spend the time retraining someone your age and I don't think you would like the culture here anyway."

"You know, you really shouldn't say things about age, right?"

"It's fine, I'm just being honest, and we don't have HR here. You have to have a thick skin to work here."

He stood, and left the room.  


0. I hate the white-board singly-linked-list-from-memory question with a passion normally reserved for lima beans and pickled beef tongue.  The question tests for proximity to graduation-date of a CS degree, and for personal memory. It does not test for whether the candidate will be good for your company.  And, the algorithm is not commonly implemented in apps, consumer web, etc, and so easily forgotten over time for most professional, experienced developers.  It's a practically useless question as delivered.   

If I want to know whether a candidate really knows data-structures, I might ask them to reverse a singly-linked list and  provide for them access to the web. I want to see whether the candidate has the drive and wherewithal to search thoroughly, find the correct answer, and understand what's asked of them and what they're reading.  If they grab the first available answer from some q&a site, it's a bad sign. If they look at a few sites, whether to refresh their memory or to acquire to an understanding of the problem & answer, and intelligently select some guidance, that's a great sign.   Ask them to explain what they're doing and why.  And, if someone really doesn't understand data-structures, no collection of answers from the web will help them.

Better yet - ask the candidate to implement the basics of a kd-tree, or to write a function to find next-nearest-neighbor.  Let them use the web and whatever other resources are available, including asking you questions. The best candidates will use a combination of their drive, intelligence, and rational/research skills to find appropriate guidance, and won't rely on asking you for every answer. The great ones will be excited at coding a solution to the question (kd-trees are cool!), especially if you can provide as intimidation-free an interviewing-environment as possible.

In other words, I want to test for how they'd function in a real-world situation in a startup where they will need to find the right answers (or right-enough answers), sometimes alongside their team-mates, and implement them quickly so we can get product shipped and continue to find, or develop, the company's product/market fit.  

1. Do not check your phone when you're interviewing someone.

2. Show up on time. 

3. Know what you're interviewing for.  I personally look for drive, intelligence, intellectual curiosity, social skills.   It's a tight race for importance among those top four attributes. 

4. Don't be a jerk. 

5. That dialogue was taken from a few different interviews, but most came from one interviewer who was taking out his company-related frustrations on interview candidates.

6. (Update) The conversation is fictionalized although many, but not all, of the statements are vebatim. Some lines I paraphrased and stuck close to the original statement. It is also condensed from three or four interviews into one. 

7. (Update) Did the most egregiously-bad interviewer really talk, as I've written him, like he was an extra in "Stargate"? Why, yes. Yes he did.

Wednesday, January 14, 2015

Software Developers Are Like Cats

Software developers are like cats.

  • The like to sit on high perches and look down at you.
  • They'll all gather together, in a hurry, when you have food.
  • Corollary: when you have food, they love you. When you don't, you're just a nuisance to them.
  • They like to play with something until the thing breaks, and then move on to find something new to play with and leave the thing they broke for someone else to clean up.
  • They'll "wrestle" with each other for hours, spending lots of energy but not getting anything accomplished. 
  • They like to think they're in charge. Of everything. And, you're just a necessary annoyance. Until you have food.
  • They love to jump into containers before looking. 

Some software developers are like cats, anyway. But of course I'm not talking about you. Must be talking about somebody else.

Sunday, December 14, 2014

Some thoughts on managing teams of engineers and engineering-team leaders.

Give them autonomy and authority to make decisions & execute
 - No micromanaging. Tell them what the product is, and leave it to them to figure out how to get it done. (See below for more on this subject),
 - Teach process, techniques and tools for achieving success, and teach how to be on the lookout to prevent catastrophic and systemic failures,
 - Teach them how to efficiently and effectively recover from general failures (transient bugs, regressions, errors in interpreting product requirements not avoided by normal process & procedures),
 - Let your reports figure out the resourcing needed to execute. Do teach them how to be as efficient as possible, but too few developers on a project is almost as bad as too many.  (The work will get done, eventually; but timelines for delivery will stretch to unacceptable lengths and your too-small team will eventually wear-out).

Ask them to accept accountability for those decisions
 - To themselves,
 - To their product manager,
 - To each other: reports and peers,
 - To you, their manager,
 - Accountability as personal responsibility and pride in the work -- not as an instrument of fear: fear of failure, fear of losing their jobs, etc.

Provide tools with which to be accountable (if they don't have the tools already)
 - Tools for planning of work, tracking of work, measurement of success (as defined by the product team), tools for forensics and for quick and efficient recovery from failure.

Everyone should think and lead with solutions, not problems, especially in communications.
 - Define work caused by change as tasks to be done, and not as problems preventing progress:
    "Moving these systems will cause a whole bunch of tasks, which we'll identify and estimate."
    "There are a lot of problems caused by moving these systems. We don't know what we'll run into."
 - Recognize and teach the difference between proactive and reactive responses to change.

The answer is always "Yes".
 - The answer to (almost) every request for work is "Yes - and it will take [time] and [resources] to deliver by [date]."
 - Create a few options for the stakeholder: split the project into pieces, add or change some resources, etc.
 - It's crucial to provide stakeholders with the information with which to make informed decisions. Don't make the decisions for them by saying "No",
 - You may need to teach your teams (and yourself!) how to more accurately estimate work.  Estimation is a challenge for most developers to get right with regular frequency.

Teach them how to teach others
 - Help find the most effective teaching method that works for them.

Do not micromanage.
 - Find ways to help your staff make better decisions & to execute more efficiently & effectively,
 - Look for opportunities to improve every day,
 - "Make better mistakes tomorrow",
 - Get out of the way and let brilliant people be brilliant. You'll find out very quickly who's not up for the job & you can replace them when necessary,
 - Remove roadblocks, and no "back-seat driving",
 - Tell them what needs to be done. Do not tell them how to do it.
 - Trust your team-mates; start from a position of trust and respect and go from there.

Nothing happens if it is not planned, executed, and measured.  
 - Get the plans from the Product team. Ask questions, discuss, and agree on deliverable(s) and date(s). Plan!
 - Planning is a team sport - it is an ongoing conversation between Product and Engineering,
 - If it's not in a story/on a card in a project-management tool, it doesn't exist,
 - If it isn't assigned to a person, it does not get done,
 - All technical-debt gets a card, and debt-payment is considered for action in subsequent planning,
 - QA (Quality Assurance) is an engaged part of the product development process; "execute" isn't just programming, it's quantitative QA (automated QA testing and automated execution of test-scripts), qualitative QA (testing by human beings), and "UAT" ("User Acceptance Testing") by the representatives of the stakeholders: the product manager(s).
 - Measurement of bugs, regressions, ticket-completion velocity, and other engineering-internal metrics (some are more valuable than others, and YMMV),
 - Measurement of product-related key-performance indicators.

Tuesday, August 12, 2014

How The Black Cloud Works

I've lost a few friends to The Black Cloud.  Several more of my friends are currently involved with The Black Cloud, against their consent (though they're fighting it).

The Black Cloud is a sneaky bastard. It is insidious.

         causing harm in a way that is gradual or not easily noticed
a :  awaiting a chance to entrap :  treacherous
b :  harmful but enticing :  seductive
a :  having a gradual and cumulative effect :  subtle
b of a disease :  developing so gradually as to be well established before becoming apparent
Life in the Black Cloud can be as normal to you as is water to a fish. It's what you know. It's what you've always known.


Here's one way the Black Cloud works.

Early on, in the beginning of your unwanted relationship with The Black Cloud, sunny colorful days are punctuated with periods where the colors are not as vibrant as they usually should be. A bit of faded gray, everywhere. Feelings are dulled, less interesting, less felt. The first words are whispered in you mind by the faded, gray thing around you: "Oh, who cares?", and "It is what it is...", and "Why bother?".

After a few days, or weeks, perhaps the gray lifts, and colors are as colorful and music is as musical and experiences are as sensual as before.

The Black Cloud returns. A darker shade of gray this time.  And the whispers in the back of your mind become more specific. "Remember that thing you did to your best friend when you were seven? That was a horrible thing to do. Horrible. They can't ever forgive you - who would? What kind of person does such a thing? Well. You. And you're a horrible person".   And, "You're not able to do this. You're not qualified. You suck. Look at these people - they all know what they're doing. And when they find out you don't? That you're faking? You're done. They expect so much more of you, of everyone, and you'll let them down. Why bother? Save them the suffering, and just stop. Stop."

Coffee loses its taste. Sleep is peppered with the Black Cloud, reminding you of everything you haven't done. Everything you can't do. The wrong thing you said at that meeting yesterday. You know they're going to fire you. The book you're writing will never be sold. No one cares about your crappy work. The music you wrote today is crap, no one will listen. The bowl you threw is lopsided, what's the point of completing the mugs? No one will attend the gig on Wednesday. You're not even good enough for a Friday, that's how much you suck.  Those people are lucky. You're not lucky. You're not working hard enough, you're sure they're going to let you go.  That thing you said when you were ten years old? For fuck's sake, no wonder nobody likes you.

For some, wine or beer or whisky or vodka dilutes the voices to a warbling, filtered drone. There's no taste in the stuff.. only an eventual haze.  Until tomorrow, when you feel like someone emptied the contents of a hotel-vacuum-bag into your skull. The Black Cloud whispers, "You suck. You drink when everyone else is living a life, and working. What's wrong with you? By the way, drinks are at 4pm".

For a long time, The Black Cloud varies it's shade of gray. Some days, less gray than others. But the messages are constant: "You suck. You're a terrible person. No one can stand you. You're not talented. You're not funny. You can't write. You can't run a company.  All of those people who buy your music, your books, your art, laugh at your routines, cry at your performance, give you money for your company or your product? What the hell are you going to do when they find out the truth? The truth that you have no idea what you're doing. You're not funny. Your music is terrible. You company will fail. You can't do it.  Why (says the Black Cloud), are you leading these people on?  What the hell is wrong with you?"

"When people compliment you, it's a lie. And you know it. They're just trying to be nice, to be kind. They pity you, really.  The people who criticize you? They're right. They're always right.  They're the honest ones. The know-nothing high-school kid who says you suck as a guitarist despite your 40 years of constant practice, hundreds of thousands of sales and fantastic fans? He's right. You know he's right. He just knows something that everyone else, whom you're fooling, do not."


The Black Cloud keeps at it.  Eventually, its visits are not intermittent. It's hanging around, all of the time.  It says, "You don't need all of these emotions, you greedy asshole.  Keep sadness, anger, frustration, loathing. Those are emotions, what are you complaining about? There's no budget for happiness, joy, ecstasy, or pleasure for you. Libido? What for? Who says you deserve a libido? Like someone will love you enough for you to use it? Please. Go do something amazing, and then maybe you can have a libido. You have to work for it, you have to deserve it. And you do not.  And don't complain. I'm leaving you some emotions, aren't I?"

Eventually, there are no emotions. And then, when this happens, the Black Cloud has you. It's no longer about feeling low, about feeling sad, or feeling angry. It is now: There is no feeling.

All colors are clear.  All sounds are dull. There is no melody. Art has no meaning. Work is futile. There is no emotion. No sadness, no joy, no passion, no anger. Nothing.


"Don't be sad", they say.  You're not sad, you say.

The Black Cloud, no longer the occasional visitor, no longer an increasingly less faded shade of gray, is now here, around you, and it is black.

The voice in your mind (it's your voice. Your one, true, wise and correct voice) is constant: "You suck. You're terrible. Nothing you say is right. You're worthy of nothing but derision. No one can love you. You can't do anything. There is no point. Someone else will just take credit. You can't do it.  You're not ready. You don't work hard enough. You don't practice enough. You missed those notes in your performance. That shade of blue was laughable and wrong.  They are laughing out of pity. No one is telling you the truth, except for the harshest critics. You are a worthless, useless human being. No one will help you, so don't bother asking. You're just getting in their way, being a burden to them."

And one day, sometimes after decades of hanging around unchallenged, it says you're not even worthy of being a human being.

The Black Cloud has you.  It convinces you.  It says, "You don't feel desire because you don't deserve it. You don't deserve a bath with a sexy partner. But a bath with a loaded rifle is a good idea. And it'll make an easier cleanup for your friends. You don't want them to think you were a slob."

It says, "You're not funny. Never were. All those people laughing? What do they know.  This has gone on too long. There's nylon rope in the shed, and the beam in the dining room is strong. Can you think of a reason not to?"

It says a different thing to different people, and eventually narrows their focus to one thing: nothing. The means are all different, but the end is the same. The Black Cloud has won.


If you're struggling with your own Black Cloud, get some help. A psychologist or psychiatrist who's good and who has experience in treating depression is a great start.  The probability is high that you're a creator of some sort: musician, artist, writer, comedian, actor, etc.  Keep creating, keep working, and get help. You didn't ask for this, and it's not your fault any more than it would be getting cancer. If you had cancer, you'd get some professional help! Right? And so with depression.

Note: Before anyone gets worried, I'm fine!  This isn't a cry for help, or some cryptic message. It's just my way of discussing the problem of depression.   Really, we're good here!

Tuesday, August 05, 2014

9/10 from Prog Metal Zone

A fantastic review from Prog Metal Zone:

One of the things that I’ve always loved about much of early progressive rock was not only how adventurous it was but also how damned heavy it could be. The music often had as much to do with Jimi Hendrix as it did with classical music. I ain’t talking about Yes’s flights of fancy or the pastoralism of Genesis but more along the lines of King Crimson’s angularity or even the early grittiness of Emerson Lake and Palmer. Yeah, I hear ‘ya, ELP??? Sure, just give a listen to that first album of theirs way back in 1970 and tell me that Knife-Edge, The Barbarian and Tank wasn’t some damned heavy shit! And heavy without being metal and often the heaviness came from the keyboards – mostly just Moog synthesizers and Hammond organs. The Italian bands from that era (remember Goblin?) also relied on keyboards to really knock you on your ass and many hard-core rockers from that era dug ELP as much as they loved Black Sabbath and Led Zeppelin. So why do I bring this up now? Well giving a listen to keyboardist Jason Rubenstein’s new album (and first in over 10 years), New Metal From Old Boxes has not only struck a heavy prog chord in me but has really made me realize how great it is to hear an all-keyboard album be one hell of a great and totally heavy instrumental experience. 

Read the whole thing.

Also, check out this great review from Progarchy.

Saturday, July 26, 2014


Since the launch of the album I've been keeping track of all metrics, statistics, and information as to the efficacy of various advertising.

Here are some interesting statistics from the date range April 1 through July 26, 2014 regarding visits, downloads, and sales from my Bandcamp page as a result of some ad campaigns I've been running.

Visitors (non-unique) who listened to music: 42.5%

Customers per all visits (non-unique visitors): 1.09%

Customers per unique visitors: 2.79%

Customers who also paid for music: 16.75%
(Customers who did not pay for the download: 83.25%)

Increase in the quantity of downloads of NMFOB when price was set to "pay what you want": 25.8%

Sales that were for a "Bundle" rather than a single CD: 33%

A "customer" is defined as someone who either downloads or purchases music from the page. The music can be any one of the releases on offer; as long as the person arrived at my page via one of the ads live at the time, they count.

"NMFOB" is "New Metal From Old Boxes", my most recent album that is available in both digital and physical format.

The goal of my advertising campaigns has been to reach the "right" audience -- music lovers of the progressive rock, heavy rock, instrumental rock and rock/fusion genres.   Some of my music is available for "pay what you want" and starting at $0.  Some of my music is on sale for a fair price, and all of my back catalog is available for free download & "Pay what you want".

Sunday, July 20, 2014

Walking On Hot Sand

The first single of the summer!

This is "Walking On Hot Sand", written by my friend & drummer Tom Hipskind.

Tom plays drums, Shawn Sommer is on bass and Brian Kahanek is on guitar.  I played piano, Moog synthesizer, a screamin' B3 organ, and some synth pads.

This is a bit different from the heavy work of my album; it's still heavy, but it's much more lighthearted. Brian and Tom kick ass on this, and Shawn and I hold down the foundation all the way down to the bottom of the granite.

I love this. I hope you do as well.

Tuesday, July 01, 2014

Real Musicians and Boxed Musicians

I prefer to hire musicians for productions. Real, live, creative guitarists, bassists, drummers.

Hire someone brilliant, and then get out of their way. They'll be brilliant.

But - when I was creating New Metal From Old Boxes (and This Is Not A Love Letter), the musicians I wanted to hire were busy.  They're professionals! And professionals work.

And so, what to do? I needed to get this music out of my system, and out into the world, as quickly as possible. It'd been too long since my last production, and it was much more important to me to get a great album of music created and shipped than it was to wait until all of the stars aligned and I could get the perfect group of people on the thing.

And so, just me. I had to rely mostly on my technical and programming chops to create tracks that sounded cool. I didn't have a guitarist? Great - that created an opportunity for me to get creative with creating "guitar-like" sounds for the arrangement.  And so, after creating a stack in the Native Instruments amp simulator (Guitar Rig 5 Pro), I dialed-up a few sounds: a sampled guitar, a sampled English Lute, a tone generated by a Korg Mono/Poly.   The solos I played are unlike anything a guitarist would play (which was the point, right?) - they're evocative of a monophonic, distorted solo but very rooted in keyboard technique.

No bass player? Keyboard bass. Sounded good to me, and still does, and the performances are rooted in keyboards.

The drums required a lot of technical work. The software I used creates procedurally-generated drum sections: patterns and fills based on tempo, time signature, and so on. I hand-edited some sections and fills, depending on what I needed, but most of the parts are generated and then played through a sampled, huge drum kit in a beautiful room (Native Instruments again, Abbey Road Modern Drummer).

Although I didn't have access to the source code of the drummer software, I was able to take some educated guesses as to the input parameters I could tweak to get the performance I wanted. I've been around procedural generation of music before (in C and in Python programming languages), and had an idea of how tempo, time signature and key signature would effect the output of the program.

Here's a good example: if I handed a chart to a drummer that had alternating 5/4 and 6/4 measures, the drummer would create a part that fit the feel of 11/4, or 11/8 depending on the overall style of the song. But the software would produce wildly different outcomes based on whether I set the DAW to (5/4, 6/4), or (5/8. 6/8), or 11/8, or 11/4, or even (4/4, 4/4, 3/4).

In the end, I wanted to great music that I loved, and I did that. Would the album be better with live musicians? No.  It would be different, but not better.

And what now? Well, for my next productions, I've hired some incredibly talented musicians. I can't wait until it's ready for the world, and I can't wait for everyone to hear these people.  I'm sure I'll create more music that 100% "me", but it's much more interesting to get a bunch of musicians together and see what happens.

Thursday, June 12, 2014

Looping Piano

One of the things I've been working with in the studio is a series of piano-loops that build in intensity.

Here's a working-demo from a few months ago that builds some improvised piano-loops into a heavy rock section.  It's a "sketch" for an idea for my next recording project.

Listening to this, I'm struck with the idea that I might be able to swap out, or double, the guitars with some very heavy piano (piano/bass/drum unison riffing).

I'll also have to play with re-introducing some distortion to the piano. I have an old Tube Screamer I can put in line & mix with the clean piano signal, and I'll try that this weekend.  The trick is to make it sound good without an immediate association with NIN.

We'll see what happens. In the meanwhile, here's that track:

Looped Piano with Rock Band No. 1 ver 2.0 (Updated) by Jason Rubenstein

Thursday, June 05, 2014

Album Review!

Whew, this is a great review.

Thanks, Unsound America, for the insight, commentary, and track-by-track overview.

Unsound America
Now what?  Now, Jason Rubenstein.  He may have his own storied history of making music over the years, but “New Metal From Old Boxes” is a break-through – to my ears, anyway.  As I have described it elsewhere, this album is replete with an articulate viciousness.  This is not an over-the-top mad-dash for the loudest, most obnoxious noise – but rather a calculated aural assault with something to say (clearly, with perfect annunciation) before it bashes your head in.

Read it all here.

Friday, May 30, 2014

Release Day!

My new album, "New Metal From Old Boxes", is available today!

Look for it on Bandcamp, CDBaby, iTunes, Amazon, Spotify, and many other places.

Saturday, May 03, 2014

An interview for Prog-Sphere

Friday, May 02, 2014

"Transforma" Progressive Rock Compilation XVIII Is Out Now

The new compilation of progressive rock and metal bands & musicians, from around the world, has just been released. "Transforma", the eighteenth (XVIII'th!) release from Prog-Sphere.

My song "The Blow Off" is the opening track! I'm honored, gang. And thrilled to be included among these bands, who are very, very good.

Seriously, the curation of this series is excellent. I'm not kidding when I say I'm honored, and excited, to have been included.