Programming is relentlessly structured by business value: it's always about the MVP with product-market fit. Managers wish it was a simple physical task, easy to motivate with money, with all the benefits of innovation but 0 risks. Many want a completely controllable process, like fast-food. It's not uncommon for sales people to exploit that fantasy selling to potential customers with questionable expectations. But any pro can tell you: it's just not that simple.
I spent a summer in the city with the largest density of artists in North America, French-Canadian Montreal. Blessed to stay in an Airbnb hosting a party for the founder and participants of Neoism, this engineer entered a new world. Artists and creatives have amazing insights on the creative process, yielding underrated context to my own profession.
A creative coworking space in Montreal: Nomad Nation
Because, despite the business, programmers are intensely passionate people. If the open source community isn't enough to convince you, compare the late-night hacking sessions to the obsessed artist's creative fervor. Think of Linux, with contributions by over an astounding 15,000 people from 1,300 countries . What about Git? An impossibly futuristic collaborative platform where the whole world can collaborate together on projects.
Programming is a creative process, so what does that look like and how do we manage it?
Good programmers are phenomenally passionate about their projects, almost to a fault. It can lead to abrasively strong opinions about technical subjects and project plans. This leads us to a recurring theme: communication. We need to be able to communicate disagreement well and healthily. Because they care so much about their work, we have to communicate our plans and business motivations as well. Good communication isn't just about articulating the specific concept, it's also about laying a foundation of trust. We want to help shape and influence people's decisions, and we can only do that with a rapport and respect. Let me make clear: apps and 1-on-1s are NOT sufficient for the early stages of team-building.This is about establishing communication with respect and trust, and using it to guide the engineering process and gain valuable insights from the engineers.
I think the worst example of bad communication I've seen is an engineering department that sunk 6 months of labor into a project that was eclipsed by an open-source Google solution, but could never tell the executives about that wasted time, so they continue to maintain and spend on the inferior solution. It became an example of the sunk-cost fallacy, instead of the late-stage pivot it should have been. This demonstrates an absence of trust.
We must care about people's careers and let people know. Programmers are generally obsessed with mastery and understanding. Most creatives want something out of a job on top of money- mentors that they truly respect, a career path that will lead them to the top of their professions, or maybe creative freedom. It is important to care about how their employment will affect their career, and who they are learning from. It's important to understand what's important to the employee and how you can align that with your mission.
Furthermore, the passion and enthusiasm comes with discernment and perception of status. You will frequently have to re-earn the respect of the most talented new hires by demonstrating that you are not a "fake" engineer. Overselling your own skills and stomping on someone's life passion by masquerading as one of them is an extremely rude thing to do, and will not facilitate a good relationship. Likewise, it's important that creatives understand and respect where their colleagues skills are. Many people put decades of work into their careers, and it needs to be respected.
Junior engineers often have a lot of energy. Some dogs need to run. The largest strokes of a new project are always the most fun- and innovative projects with challenges are particularly motivating to junior talent, especially if it expands their repertoire. Unfortunately, this isn't always correlated with business value. However, it's also where you see the absurdly long hours working on a project as they scratch the creative itch. This is one of the hardest things to manage and is obviously not sustainable. The tedious detailing of a true professional doesn't motivate people the same way. Error handling, tests, benchmarks, race conditions can often escape the engineering process here. Really the only solution is to have people with experience doing what needs to be done. Otherwise, your projects can stay in proof-of-concept phase.
Senior engineers should understand their own creative process and be good communicators, as well as covering whatever curricula are necessary given the organizational structure- code review, team building, project management, accounting. This is on top of making or at least facilitating architecture decisions.
External influences causing burnout are the most dangerous. Bad markets and bad managers are some dangerous issues. In the documentary "Waiting for Superman", about the quiet employment of incompetent but tenured teachers in empty classrooms, it's mentioned that bad teachers affect not only the student's mastery of their subject, but of every other subject the student is taking. I have no easy solution for this type of burnout.
Other types of burnout should be avoided with vacation. Long term and short term burnout can be handled differently, despite the fundamental problem of it being hard to leave an unsolved problem alone. Personally, I handle short-term burnout with rigorous exercise. In either case, self-care often needs to be explicitly addressed to positively impact performance.
Money is a nutrient in any project. It's not the only primary goal for a life work, but squeezing a project will always lead to worse results. This is why fixed-price contractor relationships are often inherently dangerous, the natural antagonism of lowest-price negotiating betrays the fact that you are also building intangible assets: workforce in-place- workers trained on your use case and your technology, not to mention intellectual property. Check out this fantastic lecture animated by RSA on what drives us.
As a last mention, if you really want to avoid these difficulties, the secret is fixing costs by reusing code. Clearly this is more relevant to an agency than SaaS, but the basic idea is that you pull creativity out of the business model. I think any good business model combines both ideas to some extent, since an innovative and creative engineering department, enabled with the tools to be productive, is not something that should be given up once it's acquired.
Thanks for reading! Stay tuned for another blog posts on why senior engineers should write documentation, from an accounting and policy perspective. To subscribe for now, follow me on twitter.