It’s Fine. Don’t Fight It. Six Steps to Programmer’s Zen.

1-ZEN

Being a software dev is an exciting adventure and a great way of life.  

It’s not all moonlight and roses, though.

Numerous challenges await you down the road. Nemeses who will summon distress and anxiety for you. They will tamper with your mood, undermine your confidence, jam the performance and turn your efforts into dust.

If you’re an emotional person, like me, then you know how easy it is to subdue to them.

But fear not, my friend!

There are ways to defeat the gloom. Let me share some of the tricks I am using while fighting off my everyday enemies.

 wall1. The Wall

This one comes from Robert Pankowiecki: How to get anything done.

There are times you’re just stuck. Be it a bug you can’t find, a problem you don’t know a solution for or a new tech you’ve never tried before. You feel intimidated and afraid. You want to get out, forget and procrastinate.

It’s fine. Don’t fight it.

Instead: accept these negative feelings and… just start.

It’s not easy, quite the opposite, I know. The trick is to realize: worrying gets you nowhere, bad feelings will remain intact.
But once you start, even with the smallest thing, and you progress, these feelings will start to fade away.
Remember to bite off the smallest possible piece for a starter – it’s just easier to digest.

To make it more effective, you need a little mind trick, a little routine.

A completion ritual.

It may be something as simple as pulling a card into a ‘done’ column on your Trello board. Ticking a checkbox on a todo list, going for a smoke, if you please. Whatever works for you.
It’s such a small, seemingly irrelevant thing and I’ve been failing on this for a long time. I didn’t see the value. But it can work magic.
Did you know that forcing yourself to a fake smile actually makes you happier? This is similar. The completion ritual has the positive effect on your brain, no matter how small and trivial the tasks you finish may seem to you.

 shame2. The Shame

So you’ve started. And you’ve written some good code. It’s decent, you’re proud and happy with it. All good. And then, after a couple of months you want to add a feature. You look at your previously-super-duper code and all you can think of is “Man, who wrote that crap?” Ask your experienced colleagues how many times they have felt the shame.

It’s fine. Don’t fight it.

It means that you’ve progressed, that you’re growing, that you can see your mistakes. Nevertheless, you still feel bad and ashamed.
The key is to understand that, just like you’re not your 8th grade English paper nor your college entrance score – you are not your code.
My tip here is very simple to grasp and difficult to master: detach yourself from the results, treat them as external to you as possible. It’s not going to happen overnight but if you keep reminding yourself often enough – you’ll get there.

 imposter3. The Imposter

Sometimes your code looks gross to you but there are people around saying it’s good. Users are giving feedback: “Hey, thanks, it solved my problem!” Your colleagues are appreciating your work, heck, you may even be getting a promotion.
And then, a funny thing happens – you feel like a fraud.

It’s fine. Don’t fight it.

It’s a proven psychological phenomenon called Imposter Syndrome. I rarely meet a developer who is completely free from it.

Dealing with imposter syndrome is arduous and I am still looking for my ways.

Please check out these articles for some tips that may work for you: How I fight the imposter syndrome, Feel like an impostor? You’re not alone.

imposter-syndrome

source: @rundavidrun

Keep in mind:

It’s not who you are that holds you back. It’s who you think you’re not.
~Denis Waitley

expert

4. The Expert

Knowing you’re not a fraud is one thing, but this alone doesn’t make you an expert yet. Speaking of experts, I absolutely love this definition of an expert:

An expert is a man who has made all the mistakes which can be made, in a narrow field. 
~Niels Bohr

And it’s really simple as that. Go, do your mistakes. Fail, fail and then fail better. Take a look at the picture. This is Lunar React workshop. These guys have years of experience in their respective fields. Wojtek has been testing apps on java, c and rails platforms for years. Ania is fluent in ruby, js, objective-C, swift and what not. Cichy, my good friend, is my js go-to-person. To me, they are all experts in their respective fields. And yet, guess what day was the workshop happening?

Lunar React Workshop

Lunar React Workshop

Saturday.
These guys came to the office on their free day and studied React for 8 hours.
The message here is clear. Keep learning and accept the truth: You will suck in the beginning. But then again:

It’s fine. Don’t fight it.

Sucking at something is the first step to becoming sorta good at something.
~Jake the Dog

perfectionist

5. The Perfectionist

Needless to say, in the beginning you’ll make a graveyard of mistakes and your work will be far from excellent. You’ll encounter complex problems with many rational solutions and it will be difficult to decide which way to go. Should I use inheritance or mixins? Does this belong to a separate class? Am I using too many mocks in this test? Questions, questions. Questions everywhere.

It’s fine. Don’t fight it.

There is always more than one solution to a given problem. There is always something you can fix or refactor forever. There is never one definite answer to a design problem. The golden answer to any architectural question is “it depends”. Every design decision has it’s tradeoffs. Learning how to assess these tradeoffs is a lifetime challenge.

If you ever happen to delve on some issue for days, remember: better done than perfect. Don’t try to reach the absolute. Focus on delivering and take shortcuts if you need to. We all did. Sometimes we’re laughing at it:

shady_tricks

Must-have programming books

The truth is we’ve all made those shady things. Who has never copy-pasted some code from Stack Overflow? Googling an error messages? Every freaking day. Trying stuff until it works? The story of my life.
They are probably not the best practices but you should not hesitate to use them. If it helps you to move on, to deliver, to solve a problem you’re stuck with – do it! You’ll revisit later. Or not. The world is not going to fall apart.

 hermit6. The Hermit

It’s fine. But fight it. Don’t go alone.

The biggest mistake I made in early days of my career was not engaging enough with the community. You know, social fears, low self-esteem etc.
Find yourself a programming buddy, a mentor, go to a local programmers meetup and leverage social media (Programmers on snapchat).

Find people who are interested and talk to them about what you do. There are lots of them out there waiting to listen and to help you.

Programming is not a solo act, it’s a team sport. And it’s not so much about the code as it is about the people.

Final round

No one said it’s going to be easy. The enemies are real, the challenges are big.

But once you learn how to deal with them, once you manage to reach your inner zen – you’ll be rewarded. If you’re lucky you may even get into the state of flow. And then you know, you’re in the right place.

For me programming is a satisfying job and a one that keeps me in a positive state of mind for most of the time. A mental shape, in which I feel that I am constantly growing. Not only in terms of technical skill but, more importantly, as a human being.

Do you have similar experiences? Or perhaps you have other enemies you’re fighting every day? Please share your story in the comments and let’s talk about it!

PS. All drawings by the one and only Gosia.

  • Alex Astva

    And, you can avoid programming errors at an early stage, if you read this e-book https://yadi.sk/i/zKHIOS84r87nk

    • Tomek Rusilko

      Thanks! I’ll have a look. It seems to be published very recently, right?

      • Alex Astva

        Yes, you are right :)

  • Bobby

    Thanks a lot for this article. I just wanted to add my 2 cents, especially applicable to those of us that work in a large organization. For years I had become a person that by default assumed that all my colleagues are my friends and trustworthy. Now I am practicing to instill this belief in me that unless proven otherwise:

    * Everybody is my enemy
    * Nobody is trustworthy
    * And my colleagues are a bunch of backstabbers that if one day you happen to complain about something related to a project you’re working on, they will find a way to turn that into a weapon to backstab you with.

    Basically as Elton John sings in The Circle of Life: Some say eat or be eaten. Some say live and let live. I used to be a member of the latter group. I still probably am. But in a new workplace I always assume that my colleagues are waiting for the right moment to “eat” me. So dark, but I guess so true.

    • Tomek Rusilko

      I am sorry to hear that, man. I understand it’s a defensive mechanism but it sounds like it can get depressing at times. Based on my experience, and I did work at a huge corpo, it doesn’t have to be like this. I mean, size of the company definitely matters but it’s NOT the only factor which shapes organisation culture. Don’t give up on the light side. Best of luck to you!

  • Learning rocks! Learning functional programming rocks even more. You can have *so* much fun in these languages… such as Elm and Haskell. If you want to start learning Haskell, I recommend our book http://www.happylearnhaskelltutorial.com

    • Tomek Rusilko

      Absolutely. Thanks for the link.

  • Raf

    LOVE THIS ARTICLE!

    • Tomek Rusilko

      <3

  • wow! great article!
    kudos for the author ;)

    • Tomek Rusilko

      kudos for the comment :)

  • AnonMX

    Agreed with everything except with point 6….
    “Social Coding” is a thing invented by “millennial developers” to hangout with people and feel not alone in an abstract world (in the end we are interacting with the world day by day through a computer not in person, sometimes there isn’t even a real communication) but developing is an a alone task, you can’t work together doing one thing without having fights for style and decisions, pair programming is a buzzword for “let’s share one pc for but of us”. Going social is sucks unless you are comfortable working from laptop computer and people seeing your screen even asking you mundane things on why you choose this language or library then you probably are ok attending this “Social Coding” meetings you recommend otherwise is a waste of time since i prefer to hangouts with my friends and talk about anything is besides why NodeJS/React/Angular2/Go is/not the next big thing.

    • Tomek Rusilko

      “Social coding” is one thing and you’re absolutely right that it’s not for everyone. I know a great deal of awesome developers who just can’t pair program. And it’s fine. The other thing, which I am referring to in the post mostly, is sharing experiences. Imho it’s an important factor in your growth as a software developer. Not only you learn faster that way but you also practice “people” skills. And this means both – having a mentor and being a mentor to others. But as you said, developing is mostly an alone task. Sometimes you just have to sit down, put your headphones on, disconnect and get shit done.

  • Shyngys

    Wonderful article , thanks a lot . At the moment , this article is my motivation to study!!!

  • Amol

    Good for learner.

  • Great article. I want to add that these things are not specific to programming. I’ve found them true for most endeavours that I take on in life. Anything new is difficult in the beginning. Only with persistence and failing can you get better at things. Only by talking to other people do you learn new things.

    I especially liked the image for the imposter syndrome. Great job!

    • Tomek Rusilko

      Thank you. That’s a true observation. In programming community we tend to expect very much from ourselves and often forget that it’s ok to suck at something, be rejected or simply have a bad day. Big egos, big money and all this “be a ninja” culture doesn’t make it easy to accept failures.

  • Lovely article! I can relate to all the points. This totally motivated me to finish this course that I have been procrastinating with, for long. Also, I religiously follow the tick-things-off-the-list trick and it works like magic :)

    • Tomek Rusilko

      Thanks. I am glad it helped!

  • Well, I’ve seen the oposite, entering zone makes you feel better about yourself but usually overestimate your experience and expertise. This usually results in ‘why on earth did I think this will work’. Ever happened to you?

    • Tomek Rusilko

      Good observation. It did happen to me many times. My solutions are:
      1. Small batches of work and frequent and critical reassessment.
      2. Frequent peer code reviews (hard if you’re a freelancer).
      3. “Underdog mindset” i.e reminding yourself constantly about staying humble and not letting the ego take over.
      That doesn’t mean not appreciating your work. But “You are not your code” works not only when your code is piece of crap but also when it’s awesome. It doesn’t make you a god or a ninja. You just wrote some good code. Appreciate it for a while and move on.
      Extremums are bad. I guess finding proper balance is the key here and a real challenge.

  • Marek

    Great article!

  • Thanks for the link back. I like the remake of the diagram!