As someone who has been in the tech industry for a while now, I’ve seen engineers getting disillusioned, overwhelmed and burnt out to a point where they couldn’t return to their original selves. Battling burnouts is still a subject that isn’t widely discussed in our field and a lot of those who’ve successfully survived it barely understand what they’ve been through. In an industry where we evangelize hackathons and sleeping under the desk, it’s hard to sustain as an individual that doesn’t associate failures in business or code as personal failures. This leads us to the general distinction between passionate programmers and the clock watchers.
The Passionate Programmer
The general notion of a passionate programmer is the guy who comes online at 1am to fix a production issue that he didn’t cause. The guy who ensures he is always up to speed with the latest libraries and tools. Someone who is willing to contribute to the project beyond the usual 8 hours. It’s also (kind of) obvious that he would be the more likely candidate for leadership roles and the one to be allocated stock options for putting his skin in the game, over the guy who prefers to check in fixes the next day.
The 9 to 5 engineer is the one who is in there for his day job. He is uncool and generally overlooked. The irony is, he is the one who is going to be more productive in the long run.
The passionate programmers usually succumb first.
There usually comes a point where it becomes impossible to keep a steady learning curve. This usually results in the plateauing of the graph in terms of the new things you learn, to the conventional stuff that needs to get done. Now, there is a gradual but growing resentment towards the job that holds him back from keeping up with all those things he could’ve learnt.
Let us assume that all the time needed to keep up with his learning was made available to him by the company; there still remains a sense of resentment as there is no way he can sustain that pace. Though his rational mind would reject the causation for the situation, it’s definitely much easier to place the blame on an entity that’s easy to dislike.
People who have a life outside work deal better with these situations.
In one of the 37signals’ blog posts(https://signalvnoise.com/posts/996-hire-family-people), DHH mentions how working with people with families seemed to be a better choice as they had to be somewhere, with someone more important at the end of the day. There were no honor badges available for killing it 12 hours a day at the office. And this is one of the most important distinctions I’ve learnt as a source to overcome the disillusionment associated with tech – having a life outside work which adds a sense of fulfillment or accomplishment could be invaluable.
Even mundane challenges like forcing yourself to a regular exercise regime or a book a week could go a long way in solving a lot of the problems associated with this.
Startups thrive off this
Most startups proudly describe how they’ve worked against Maslow’s hierarchy of needs to make the world a better place. My take on it is that it’s unsustainable and hence will eventually fall apart. Self actualization is a higher goal and at times may force you into thinking differently but eventually it does adhere to the laws. I’ve also come to realize that this is part of the reason why some of the best engineers that I’ve admired, teach.
The rewards of watching someone you’ve mentored succeed far outweigh the efforts that go into it. It inculcates several valuable qualities like patience, humility and empathy.
Why didn’t this pay off?
The worst reasons for disillusionment are failed projects, disgruntled co-workers and unhappy clients. This brings in a sense of failure that becomes hard to disassociate from. It’s usually never about the code, though it eventually transcends to it. Usually the problem lies in communication, conveying the vision, the goals and creating a sense of belonging. In one of my earlier posts, I’ve tried to highlight the importance of having the right project/product managers in the team. The value of having the right project managers (or leadership team in this case) is to ensure you embrace your team right from the beginning. Extroverts usually shine in such roles as they easily embrace their team forcing everyone to participate. Embracing your team right from the beginning helps deal with failures as a team and individuals aren’t singled out when things go bad. This is a more cultural problem and trickles down from the leadership team. For a quick low down on how to manage engineering teams here are some great reads by Greg Brockman of Stripe https://blog.gregbrockman.com/figuring-out-the-cto-role-at-stripe and Slava Akhmechet from RethinkDb. Every single post on his blog are words to live by if you work in tech (http://www.defmacro.org/).
Introverts have an uphill battle
Introverts have a constant battle in figuring out this balance. As a textbook introvert, it’s a problem I constantly have and one I am yet to find great solutions to. One of the problems I’ve frequently battled with, is coding in silos and finding ways to work alone. While the productivity boosts are hard to deny, it introduces a level of monotony and stagnation that’s hard to shake off immediately. I would love to hear about how you deal with these situations as an introvert.
Not being a slave to routine
Working from different places and meeting new people every now and then could introduce a fresh perspective to your problems. Speaking with people who have dealt with similar problems or even people with a fresh perspective towards approaching your work problem could infuse newfound energy in your approach towards it.
Conferences are (IMO) less about the tech and more about meeting people who tackle the challenges you face in entirely different ways. And generally, I find a new sense of purpose and energy after every conference I attend.
Follow me on Twitter