Back in college, as an English Literature major with a minor in journalism, most of my writing classes involved workshopping: sharing pieces of writing with the entire class or with a small group of classmates so we could constructively critique each other's writing in the hopes of making each piece stronger and better. While it's incredibly nerve-wracking (OK, sometimes downright painful) to share something of your own creation with others, we all quickly learned how valuable those objective insights were to the creative process, and with each critique, our writing got better and our skins got thicker.
The workshop/critique process prepared me well for the eventuality of being a professional writer and having at least one editor review, correct, revise and refine my stories. Behind every good writer is a great editor (in my case, I have two; thanks, guys!).
My husband, on the other hand, is a software engineer; he has a BA in Computer Science from the same university. But while I'm used to the process of writing, receiving feedback and critique, and then revising my work based on that input, the process for him has been more difficult to stomach. Sure, software engineers go through code reviews, or have to go back and rewrite buggy code, or update older code to integrate with new technologies, but most of that work has been done either in isolation or one-on-one with a manager or another engineer.
Nowadays, with an emphasis on collaboration, constant feedback, continuous delivery and the agile methodology in software development, it's more critical than ever that software engineers have some of that same "workshopping" experience; to show and explain their code in front of an audience of peers and subject it to similar critiques, refinement and revision -- but many older coders aren't used to this kind of group work and scrutiny.
Last week, I talked with load-balancing platform-as-a-service company BlazeMeter's chief evangelist Michael Sage about this new breed of software engineer, and the need for increased social interaction, collaboration and critique.
"It's such a caricature now -- the socially awkward, isolated software engineering nerd who never comes out of the basement. But that just isn't gonna cut it anymore, and especially with millennials there's a whole new set of skills coming into play here," Sage told me.
While there's a peer review and peer collaboration process happening on sites like GitHub, where developers can post their code publicly, in many companies it's difficult to get these highly technical people, especially from the older generation, to embrace collaboration, he says. And that's a huge problem for companies who really need to bring all the stakeholders together to make sure their products and services really hit the mark -- everyone from executives, marketing, customers, sales, engineering and IT must all work together on this, Sage says.
It's easier for millennials, who grew up being recognized and rewarded by peers and parents just for participating -- and they're eager to share their work and help out by contributing however they can. Getting older developers to do the same is tough, but it can be done, according to Sage. He encourages his development teams to blog, to participate in webinars, public speaking events, hackathons and meetups so they get used to the social aspects as much as they can, but he also understands that, for certain personalities, it can be almost impossible.
"We really try to meet our developers where they are, and help them promote their content and their ideas from a place where they're comfortable. It really can be helpful to their career direction, too, if they're getting out and meeting new people and exploring these other avenues," Sage says.
The need for collaboration isn't going away, so it's in engineers' best interest to get over their fears and get out there. Newer programmers are going to enter the workforce with these collaboration and communication skills already well-honed, so older developers need to step it up.