Comment

Talent Mountain

Have you been to Talent Mountain?

Talent Mountain is a magical place, filled with endless potential and possibilities.  Many incredible young people live on Talent Mountain, each draw to the promise of a bright future and limitless opportunity.  If you can find your way to Talent Mountain you can do anything.  Talent Mountain is a dream come true.

But Talent Mountain has a dark secret.

Comment

Comment

How to Become an Insufferable Pseudo-Intellectual, or, How to Read a New Book Every Day

I love to read. To me, there is hardly anything more pleasurable than sitting on a couch and letting a skilled author weave a universe inside of my brain. In fact, if I am not sleeping, it is more likely than not that I am reading a book. On days in which I do not have the opportunity to pick up a book -- of which there are thankfully few -- I feel physical discomfort, like a heroin addict pining for his next hit.

For book lovers, there has never been a better time to be alive. Anyone with an Internet connection has essentially on-demand access to the vast majority of works that have ever been published. The Library of Babel has arrived, and it fits in our collective pocket. But this embarrassment of literary riches comes at a cost: analysis paralysis. Given that we now have access to a far greater number of books than any one of us can read in a lifetime, how are we to decide what is worth our time to read?

Comment

Comment

Men suck at tech

I admit, I've never read the entire Google Douche Manifesto, or whatever it's called, by James Damore.  I have little stomach for readings things that I think are idiotic, and I haven't made it past the first few paragraphs.  On the other hand, I've read a fair bit of the analysis, and some of the responses, and I think some truths about it, and its author, have come clear.

  1. James Damore is an irredeemable asshole.  No matter what you believe, taking the time to publish a screed that suggests over half of the population is biologically unsuited to work that you're still fairly junior at, well, that takes some unmitigated douchebaggery.  Imagine if a third-year associate at a law firm published an article suggesting all of the female partners lacked a "killer instinct" in the courtroom.  I hope he'd get shivved in the parking garage.  And then sued.
  2. James Damore is not an outlier.  No one publishes a potentially controversial "manifesto" if he or she doesn't feel support for the ideas.  The manifesto is probably the last thing we should worry about.  We should worry more about the weeks and months of bro-talk with like-minded colleagues, during which he shaped and polished his ridiculous thesis.  That culture is still there.  Everywhere in tech.  Google firing James Damore was like a surgeon removing an unsightly polyp, but ignoring the fact that it's a sign of systemic underlying cancer.
  3. James Damore is right about one thing -- as the saying goes, a stopped clock is right twice a day -- he's right about this: men and women are different.  But, someone smarter or with more experience or with a shred of humanity would realize that different is not the same as worse.

Men and women are different.  It's a biological fact, and one that I hope won't generate much controversy.  But, how do these differences manifest themselves in tech?

It's not 1983 any more.  Nor is it 1993, or 2003, or even 2013.  Long gone, if not forgotten, nor often enough missed, are the days of lone software "rockstars" communing with their black and green terminals late into the night.  Nowadays software is written by teams, and good teams are composed of people who are good at communicating with one another.  Would you want to go to trial with three brilliant lawyers who all planned a fantastic defense without talking with any of the others?  Me neither.

The traits that software teams depend on these days – communication, collaboration, empathy – are skills that women historically, if stereotypically, excel at over men.

Swing a dead lolcat and you'll hit a blog post about how software developers must be good problem solvers.  Problem solving is about creativity; the ability to look at problems from different perspectives, to come up with new approaches, to mentally juggle problems and solutions until they fit into patterns that make sense.

Again, women historically, if stereotypically, excel over men in creative fields.

But, software isn't just about finding a solution and communicating it to your teammates.  It's also about listening to other people's ideas, allowing those ideas to change the course of your thinking, and accepting when someone else's ideas are more appropriate than your own in a given situation.  All of this requires that software developers allow their own egos to take a backseat to the success of the project and of the team.

In my experience, on average, women dramatically outperform men in situations that require controlling one's ego.

Now, the astute observer will point out that I'm a white dude in tech, and I regularly tell people that I'm pretty good at this whole software thing.  I can't deny it.  I'm not suggesting that men can't excel as software developers, despite the obvious click-bait title of this article.  All I'm suggesting is that the skills that really matter -- not the ones that come up in whiteboard problems, or look-how-clever-I-am-puzzle-question interviews, but the skills that actually determine the success or failure of a software team -- are skills that women more naturally excel at.

I predict that women will dominate tech in the next two to three decades, just as the percentage of women has increased dramatically -- in some cases to a majority -- in medicine, law, business, scientific research, and other previously male-dominated professions.  The pace of this change only depends on how urgently the large tech companies, with their undeniably male-centric cultures, cling to the outdated glories of the past, and how spineless smaller tech companies are in their acceptance of this status quo.

Cross-posted at medium.

Comment

Comment

This is not the tech industry you're looking for

Do you think the software industry has diversity problems? I do. Do you think we should be doing more to attract women and minorities to development jobs? I do. Do you think tech companies are trying hard to attract a more diverse workforce? I do — at least in many instances.

Unfortunately, what I think doesn’t really matter. My opinions and viewpoints are from the perspective of a white dude with a job in tech. Chances are, if you’re reading this, your viewpoints are from the perspective of a white (maybe) dude (probably) with a job in tech (quite likely); so what you think probably doesn’t really matter either. We have to try to see the world through the eyes of people who are not white, not male, and — most importantly — don’t work in tech, have never worked in tech, and maybe haven’t yet decided if they want to work in tech.

Here’s what Melinda Gates has to say on the matter:

If I asked you to picture a computer programmer, you’d probably conjure up a pretty specific image. He — yes, he — grew up playing video games in the basement, went to an elite university, and breezed through to a job in Silicon Valley.

That’s a pretty solid negative if you’re not a male gamer from a relatively privileged background and you’re considering tech as a career.

You’re smart, you’re talented, you can choose amongst many career paths, and all you know of the software is the impression given by media stories, blockbuster movies, Internet memes, and — possibly— Melinda Gates. Do you want to scramble over a wall of gamer dude-bros when you could go into law (over half of law students are women) or medicine (nearly half) or some other profession whose practitioners command more respect than self-described “ninjas” who sometimes have to be reminded to wear pants?

So, tech has a perception problem. Worse, tech has a perception problem because a lot of that perception is based on reality. Software is mostly dudes. Big tech companies loudly advertise how they recruit technical wunderkinder exclusively from “top schools.” Job postings still include terms like “ninja” and “rockstar.”

But tech has a second, and more insidious, perception problem, which is primarily self-inflicted: we just can’t stop shouting about how great we are. Look around the Internet; most of the information about tech companies looks something like this:

COMPANY X JUST RAISED MORE MONEY THAN YOU CAN CONCEIVE OF!
SELF-TWEETING ROBOTS THAT WILL SAVE YOUR THUMBS FROM UNDUE STRAIN JUST AROUND THE CORNER!
TECH GIANT EXECS MEET WITH WORLD LEADERS TO DISCUSS SELF-TWEETING ROBOTS!
HUGE TECH IPO! ECONOMY GROWS ELEVENTY PERCENT OVERNIGHT!
Tech dude-bro describes women as “plankton;” some people express shock. BUT…
LOOK AT THIS THING WE MADE! WE ARE LIKE GODS!

If someone told you “Yeah, we’re considering something different, but things are really, really great the way they are,” would you be convinced?

If we want the software industry to grow, to mature (I do; you may as well), then we have to accept that it’s broken. Sure, we build things, but we could build things so much better. There’s a little diversity, and diversity is improving slowly, but it could be so much better. My career is fairly secure, and yours may be as well, but a lot of new developers can’t find work; we could offer a career path for potential software developers that is so much better.

We are the frog, and we have boiled ourselves. The current state of tech has as much in common with tech twenty years ago as modern healthcare has with medicine before the discovery of penicillin. Yet, we still approach problems in much the same way, value and reward the same skills and attributes, and cite articles and research from decades past. You may as well burst into a modern operating room with a bloody bone saw and a bottle of brandy.

Tech is broken. It’s sometimes good for those of us already on the inside, but generally terrible for anyone still on the outside. We love to say that empathy is super important for software developers; let’s try to put that into action. Let’s think about how we can use each success to create an opportunity for someone new to tech. Let’s show some humility when douchebags say or do offensive things, and accept that it’s not just a few bad apples; our industry has grown around that rotten core, and we own that. Let’s try, at every opportunity, to see our actions and our messages through the eyes of someone new to tech, and consider how that paints the industry as a whole. Then maybe we can start to become something the next generation will want to be part of.

Cross-posted from medium.

Comment

Comment

Addiction

I am an addict.

Chances are, if you're reading this, so are you.  My addiction is not to any chemical substance, but I believe the symptoms are very much the same.  When I satisfy my addiction I find myself only wanting more.  It makes me feel good, in control, powerful.  Anything that blocks or interrupts it makes me irritable.  In the throes of my addiction I lose track of time.  And, ultimately, it hurts the people around me.  Worst of all, there is no end of people who are ready, willing, and able to take advantage of my addiction.

My addiction, is to "flow," the mental state that the software industry has elevated to such a degree that it's almost seen as a unique attribute of exceptional software developers.  Which isn't true, of course; to a large extent it's a marketing ploy that, like the source of many addictions, is promoted largely by its devotees. 

Whoa.  Back up second.  Isn't "flow" the ultimate goal of every software developer?  A mental state of such concentration that the "flow-"er can solve problems and write code that is beyond the reach of mere mortals?  To some extent, yes, and that's a big part of what makes it so compelling.  But, that's not the whole story.

"Flow" boils down to a simple idea: the ability to hold many, many aspects of a complex system in your mind at once.  Software is complex, and writing software requires understanding and managing that complexity, but software isn't unique as a process that requires this sort of mental discipline.  Skilled chess players keep a mental picture of pieces on the board, as well as a series of potential future states of those pieces.  The more talented the player, the more future states they can process and consider at once.  It should come as no surprise that people enjoy playing chess, similar to how software developers enjoy working with complex systems.

But, writing software is not a game, and differs from chess in one far more important aspect: chess players work alone, while software developers work as part of a team.  Working on a software project is like having ten chess games going simultaneously, with ten separate players, and with the goal of winning every match while also having a specific combined number of pawns remaining at the end of all games, across all ten boards.  No Grand Master who has ever lived, or will live, can guarantee the end-result of another player's game.  At least, not without a lot of interaction.

On software project we have to consider the work of our peers.  "Flow" isolates us from others, when we need to be focused on interaction.  "Flow" helps us focus on our own work, to the exclusion of helping others learn or grow.  "Flow" encourages hoarding of knowledge that our teammates may need in order to make decisions.  "Flow" hurts the overall goal, while making me feel good about my own work.

Now, you may think this is tongue-in-cheek, that I'm using addiction as a metaphor, or a hook to make a tangentially related point.  I am not.  I don't want for a second to diminish addiction in any form by some spurious comparison.  I have never been addicted to alcohol, or heroin, or anything similar, but I feel a pull that seems like what I imagine people afflicted with chemical addiction feel.  I've been a devotee of pair programming for many years; I've had the extreme fortune of working for companies that support pairing for over a decade.  I feel -- I know -- in my bones, the value.  Yet, given an opportunity to work alone, unvexed by questions about my thought process or my conclusions, I feel an intense draw to retreat into my own thoughts and work unencumbered.  I know, through experience, that I will write inferior code without a collaborator, without someone questioning my ideas -- without a pair.  Yet, I want it.  I yearn for it.  Like a drug.

So, if you write software, please, I ask you, take a moment to consider your motivations.  Do you work the way you do because it truly provides the most benefit to your team?  Your customers?  Your company?  The software industry as a whole?  Or, are you satisfying a personal need -- one you may not even consciously consider -- at the expense -- even a little -- of the people you work with?

If you're honest, I think the answer might surprise you.

Cross-posted to medium.

Comment

Comment

Groundwork client A2Access acquired!

We're pleased to announce that Groundwork's first client, A2Access has just been acquired by leading financial services firm Dealogic.  For details you can read the official press release here.

Groundwork has now been working with A2Access for just over a year.  The acquisition means many changes, but we plan to continue working with A2Access, and with Dealogic, for the foreseeable future. Many congratulations to the A2Access team!

Comment

Comment

Moving On From Hacker Schools

Note: this article was first published on the Huffington Post Code blog [here].

In a recent article, I expressed my concerns about the software industry's current methods of training and preparing new software developers to achieve proficiency in their professional work. Unfortunately, a great number of people immediately responded by pitting four-year CS degrees against self-directed learning or accelerated software development programs. My argument was not whether or not a four-year degree is a necessity for someone who wishes to become a professional developer. The value, and expense, of education is a complex subject -- a subject which, particularly in our current economic climate, has been repeatedly addressed by people with more experience in, and knowledge of, higher education.

To refocus the conversation, from my original article:

The question is not how existing courses of study fail to provide value, but how proficient developers actually do learn their skills.

And:

The real question is how to provide a path from that open door [into software] to productivity and success. Many professions consider education programs - whether they result in a degree, a certificate, or a license - to be just the first step, followed by significant time doing real work, with dedicated supervision, and increasing autonomy based on performance.

Avi Flombaum, whom I quoted in my original article, seems to agree with me that we need to distinguish such a path:

Avi: Day 1, [Flation School students] start building something. After that, they're a developer, they may not be any good, but what else does being a developer mean besides building things? ...To become a great developer, that takes years.

Avi's comment clearly suggests agreement that novice developers need years to reach their full potential, but what exactly do those years involve? This is exactly my point. Imagine if we could shorten the time it takes a developer to reach their potential; if we could limit the impact of mistakes and inefficiency caused by their inexperience during their years of growth; if we could shave just one year off this learning curve from "not very good" developer to "great" developer. From carpentry apprenticeships to medical residency, mature professions have historically placed great value on the experienced teaching the inexperienced, doing real work with real clients. The classroom can prepare students to benefit from that experience; it cannot replace it.

Unfortunately, few, if any, software companies currently provide this type of mentorship. One reason is obvious: it has a high short-term cost. Businesses need their experienced developers building product, and they believe time spent mentoring inexperienced developers takes away from that goal. Unfortunately, a focus on short-term urgency causes long-term pain. As inexperienced developers struggle to learn on their own (or with limited mentorship) and the demand for developers rapidly grows, the supply of experienced developers shrinks in comparison. Businesses thus have even more need for their limited supply of experienced developers to focus on building product, compounding the problem.

A more subtle factor also contributes to the lack of effective mentorship. The software industry values highly technical and analytical thinking skills, generally to the exclusion of all else. Companies commonly emulate Microsoft and Google interviews, with their notoriously analytical questions. But an effective mentor needs more than just technical skills. Mentors need skills that software companies rarely, if ever, select for: patience, empathy, and communication. During the countless interviews I have had over the years I have never had an interviewer ask me to explain a solution to a problem in four different ways, reflecting four different learning styles, a skill expected for any teaching position. The unfortunate fact is that many senior software developers do not have the traits to act as effective mentors, and many more simply don't want to.

Avi Flombaum has suggested that Pivotal Labs should hire and train novice developers. Pivotal has some of the best developers -- and best mentors -- that I have had the opportunity to work with. However, Pivotal's business is high-end consulting; they provide a premium service for their clients, with rates that reflect that level of service. Suggesting that Pivotal hire novice developers is akin to suggesting that the Mayo Clinic hire classes of third-year medical students because it can provide a great learning experience. I'm sure the Mayo Clinic provides training opportunities, just as Pivotal provides a limited number of internships, but it is not their focus.

As it happens, I no longer work for Pivotal Labs, and haven't for well over a year. I currently work at Groundwork, where my goal is precisely to provide mentorship opportunities. If Pivotal Labs is the Mayo Clinic, Groundwork will be the Bellevue or Beth Israel Deaconess of software: an institution focused both on providing exceptional service and a learning environment where promising new developers can gain experience, learn from experienced mentors, and rapidly reach their potential while doing real work on real products for real clients with real challenges.

In addition, I hope to offer a new dimension of career growth for senior developers in a profession that has historically struggled with limited career paths. The software industry has a history of not valuing or rewarding the traits required for teaching and mentorship, but Groundwork does, and will. And, just as public teaching hospitals have traditionally provided healthcare to the most underserved patients, Groundwork aims to offer services to businesses that suffer most from the growing need for experienced developers: startups, non-profits, and foundations, especially those building unbuzzworthy -- but needed -- products.

I appreciate that the cause I'm championing will require a significant cultural shift in the software industry, and cultural change takes time. But, the fact that a thing takes time is not a reason to avoid it, nor an excuse for inaction. We know that aspects of the software industry change rapidly, and this is a new way for it to evolve. I hope both software professionals and educators will join the cause, for the benefit of developers, the businesses that employ them, and our increasingly technology-dependent society.

Comment

Comment

The Problem with Hacker Schools

Note: this article was first published on the Huffington Post Code blog [here].

In recent years, the popularity of accelerated software development courses has exploded. While this boom is due to the increasing need to fill empty development positions, I think it is also in response to a burgeoning desire to demystify a developer's path to proficiency. Four-year computer science degrees have not provided the needed skills; many successful developers have degrees in unrelated subjects, or none at all. The absence of clear alternatives to traditional four-year programs has generated a lot of confusion about what it takes to work effectively in software.

In a recent interview with Avi Flombaum from the Flatiron School, one particular section jumped out:

Rob: Some people have criticized the notion that you can become a developer in 3 months... How do you respond to that?

Avi: I think you become a developer the day you start building something. That happens pretty quickly at Flatiron School. Day 1, [our students] start building something. After that, they're a developer, they may not be any good, but what else does being a developer mean besides building things?

The final emphasis is mine. Employers who pay high developer salaries expect their developers to demonstrate skills beyond "can build things."

To become a great developer, that takes years. But to become an efficient developer, or a productive developer, 8-12 weeks sounds about right.

Most people would agree you can learn to write software in twelve weeks - just as you can learn to play chess, paint with watercolors, or immobilize a dislocated shoulder. But how long does it take to become a chess master, a painter, or a medical provider?

...this isn't casual.... It's like 700 hours of coursework. How many Computer Science classes do you end up actually taking in a 4-year college? ... And they meet 3 days a week for 2 hours...?

The real issue is: What content does a four-year degree lack that an accelerated course provides in only three months? I don't know where Avi went to school, but my college classes required work outside the classroom totaling significantly more than 700 hours. If accelerated courses simply provide the same basics as college degree programs (without the less relevant theoretical topics and pesky humanities requirements), then it leaves graduates at least equally unprepared for professional development work.

The question is not how existing courses of study fail to provide value, but how proficient developers actually do learn their skills. Many experienced developers will tell you that they learned by making a lot of mistakes. In the best of cases, a more experienced developer helped to identify and explain their mistakes; in the more common cases, they simply made the same mistakes over and over before learning the lesson.

Learning from failure is not unprecedented, or even unusual. After graduating from college (with a degree in computer science), I shelved my diploma and worked for a couple years as a street paramedic. The paramedic school I attended required more than four times the classroom and practical time than the program Avi describes. Regardless, EMS providers know that newly-graduated medics are next to useless, so they pair them with senior medics. The mentor's role is to identify or anticipate the mentee's mistakes, mitigate or prevent them, and make certain that the mentee learns the necessary lessons to prevent them from happening again. The mentee's goal is to show that they can learn these lessons, and become more than useless within an acceptable period of time. Even those who excel in the classroom can fail to meet this bar.

A paramedic's job, while stressful, is reasonably straightforward. My job as a medic was to deliver patients to the hospital quickly, dealing with any immediately life threatening issues if possible. A medic's skills and knowledge are narrow and focused: treatment options limited; patient interactions measured in minutes; team size only two. Medical providers with significantly more training handle the processes of diagnosis, repair, recovery, maintenance, and prevention - some of which are measured in years.

Contrast this with software in which you cannot simply hand off your paperwork and move on. Developers need to build things that will grow, change, and continue to provide value. Developers have to work on teams with other developers without duplication, misunderstanding, or strife. Developers need to know existing tools and libraries, how to solve problems without existing solutions, and how to tell the difference. The opportunities to make mistakes are myriad.

I don't think that people who criticize (The Flatiron School) like that are really thinking about it carefully.

I think it's entirely reasonable to say that Flatiron School provides value and opens a door into the software industry; although, no one has proven whether their program does so more effectively than traditional programs. The real question is how to provide a path from that open door to productivity and success. Many professions consider education programs - whether they result in a degree, a certificate, or a license - to be just the first step, followed by significant time doing real work, with dedicated supervision, and increasing autonomy based on performance. In contrast, software developers take years to learn from mistakes they don't know they're making, each learning the resulting lessons - or incompatible variations thereof - individually. This is enormously redundant in a profession that frowns deeply on duplication of effort. We can dramatically improve the learning process with dedicated mentors who identify, prevent, and explain mistakes as they happen.

Lack of mentorship delays new developers' progression from beginner to journeyman, stunting the growth of their professional value, and generating attrition due to frustration. The overall ratio of beginning developers to proficient developers defines the average proficiency of the software development industry as a whole. As the demand for new software developers continues to grow, the growth of the ranks of beginners will outpace progression to proficiency, causing an industry-wide drop in productivity. We cannot tolerate such a step backward, as software continues to grow in demand and importance.

Comment