Play the Game

I once had a boyfriend. We used to talk about work a lot. We worked in the same department at the same workplace, so there was a lot to discuss. Working together could be a bit overbearing at times (see also: the break up). But I loved his observations and wry musings on professional life. After each day we would wind down outside on his patio and talk about the day. His words in the gentle glow of the weekday dusk still echo in my head:

“play the game”.

He was a bit older than me so he certainly took advantage of that position to act like he knew everything. But he was correct about this. Software development is so much better when you approach it as a game. It’s a mind-field that is easy to get sucked into. When work is a game, you have psychological distance. And as with all games, there are rules:

1. Do not take it too seriously.

Work. You get caught up in it. You form a connection to it. And if you’re not careful your self-worth depends on it. Because if I get this feature out in time, I will be a good developer. Without us being conscious of it, we transfer our deep-seated fears and feelings into our work. A project then takes on the form of our ruthless fathers, overbearing mothers, or doubtful peers. And we become neurotic about finishing things on time, even with the obstacles outside of our control.

It can be difficult to not take your work seriously. But you must try. Start by acknowledging that it is a game. Then see yourself and your coworkers as players. Assuming your employer is stable you’ll still get a paycheck if you lose. The good thing about games is that they start and end. If you fight your coworker(s) on Monday and sing with them on Friday, then you know you will have followed this tip.

2. Write good code and write it ruthlessly.

I am a better programmer than I was last year and always aim to keep improving. Programming skill is hard to measure so I can only guess. But I am still not as fast nor as good as I would like to be. Yet by accepting this mindset and always having room for growth, the only way is up.

It can be hard to develop your skills if you are in a toxic or always-on-fire environment. So give yourself a break if you are. Otherwise, let your abilities get better with every project. You will need to start somewhere comfortable and have room to grow and improve. Don’t just apply your skills. Hone them.

Good fundamentals go far too. People in the industry forget their training after a while. These types end up writing a regex to parse HTML, wondering why it won’t work. Practice is worth it in the long term. I have a million unfinished side projects. But I have had fun and learnt amazing things to apply to novel situations.

3. Prepare your weapons

I could have used the word tool instead of weapon, but that’s boring. As a programmer, you have incredible power at your disposal. Arm yourself. Your weapons let you surmount massive batch processing tasks, destroy bugs, and find even the most secluded information buried in the remotest recesses of the company network.

The weapons you need will vary based on your role. Bash is a trusty rifle to have at your side. It is widely supported and can do anything. Learn to write it yourself instead of Googling and copying from Stack Overflow. Other weapons for your arsenal will depend on the type of developer you are and the work that you do. Pick them and learn them inside and out.

Hypothetical situations to arm yourself for are:

• An executive wants to work out utilisation rates over time. You need to search 730 gzipped log files and create a histogram of unique user IDs.
• There is a production incident you need to trace across three different servers.
• A colleague is annoying you and you need to decrypt the blackmail you have on them and email it to everyone in the company.

4. Push the boundaries, but not too hard.

Sometimes the system is against you. Sometimes you need to push against the boundaries or frame of reference set for you. Marx said that changing the world is more important than understanding it. You may not like Marx because a LinkedIn post told you a rags-to-riches story about an East-German escaping communism through sheer willpower. But he is right for the sake of this point.

Large businesses still want to meet market demand but make it hard with layers of Byzantine processes. To excel you need to work within the limits before breaking them. Get to know the bureaucracy well. Gain mana. You will know you have achieved this when people come to you for help with processes that once perplexed you. Keep your software stack as new and slick as the business allows. Once you arrive at the boundaries you can start pushing against and expanding them.

5. Defend your ideas

If you work in a good team your coworkers will politely challenge you. They might ask you to prove something works or get you to back up your ideas. This is good. Work is not about being always right or being the most original thinker. Good engineering is about proof. So be a scientist. Test your hypotheses. Be a lawyer. Keep a paper trail. Be an academic. Cite your sources. Work with your colleagues and always take feedback with grace.

Colleagues are not always impartial and can be ready to shoot your ideas down. So let your results do the talking. It’s hard for difficult coworkers to push back when you have a well-researched report with data and citations to back you up. And remember that only good ideas are worth defending. Ultimately your bastard coworkers or The System may reject a proposal despite your proof. When that is the case, refer to rule (1).

6. Always think, speak sometimes.

Working in a mind field means we developers must always think. We think about syntax, requirements, program states, computer architecture, business processes, and it goes on. On top of all this, we have to think critically. The modern developer is charged with a fair bit of responsibility. Critical thinking is the fuel for responsible judgement.

Critical thinking leads us to appropriately push boundaries and rigorously evaluate ideas (see 4 and 5!). With our critical faculties, we can come up with the best solutions to problems. But saying what you think too early can get you in trouble. When I was younger I spoke ill of the software at the new company I joined. They did not like that. I could have built good relationships with my peers and management (see also: ass-kissing). But the complaining made me a pariah amongst my touchy and testy coworkers.

7. Have fight and flair

When I first entered the workforce I thought I needed to be a depersonalised professional ready to serve the greater computing good. I suppressed myself. At times I let my colleagues walk all over me. After all, being combative was unprofessional, right? How naive I was. The Establishment wants boring professionals that are easier to manage. This does not have to be you.

Only after many years, have I realised that professionalism and personality aren’t foes. You are allowed to make work fun. When you let your personality shine through, you gain the fight that allows you positive influence over others. You might think that this can make you brash or unlikeable. But it’s a paradox. As long as you are judicious, people will admire your authenticity and courage.

***

When I made this list up I didn’t use any model or method. I prepared this from my own experience and intuition. As an individual programmer, you get to have your own set of rules. And as you grow and learn your little set of rules will change. But the most important rule is (1); it is an uncertain and uncaring world out there. You need good psychological defences in the mind-field of software development. Games are meant to be enjoyed. So above all, have fun. You’ll need to.