One thing that I used to really struggle with and to an extent I think I still do, is taking on board the advice of people with more experience than me. In life and especially as a software developer, you will come across people with more experience than you. No matter what the area there will be someone who has been there longer, worked harder and failed more. When I began my first job as a dev I went in with the mentality that I can learn 100 times more from the seniors than I will from any text book. As a result I tried to always no matter what the situation, take the thoughts and comments of those with more experience on board. I don’t think I’ll ever forget this, maybe 3 months into my first job and I had created a PR for something I was working on, now it was a bit of a big PR as some requirements had changed along the way. It had gone from one ticket to three. Sure enough it became a bit of a mess of work, no one was quite sure what code was solving what problem. This of course resulted in quite the discussion, 100 comments later on Bitbucket and I can say I wasn’t exactly full of confidence. My PR had more or less been torn apart by three developers with a whole lot more experience than me. After feeling a little down about my god awful PR, the three reviews all told me that it was nothing personal and that it was all about getting better. At first as you can imagine it didn’t exactly make me feel to much better. However, in retrospect I look back on it with fondness as it has made me a lot better dev. No longer will I create PRs for three different tickets, combined into one monolithic beast. Instead it’s one PR for one ticket, sometimes tickets need to be broken down into smaller parts, each one with it’s own PR.

I could have cried and went running to my mother, as I’m sure many people can attest to, getting your code torn apart piece by piece isn’t what I call confidence building. Yet it’s these moments when we face adversity that make us better. These moments build us up, my failure of a PR made me a better programmer and if it wasn’t then, it could have been years down the track when I really should have enough experience not to make those kinds of mistakes.

One thing that I have learnt and I’m still learning is how to interact with the client, more specifically how to interact with non-technical people when talking about technical things. This is something that has a junior I have never had to do, you don’t need to do any of this in university. Interacting with non-technical people is something that really takes time to develop, but you can speed up the process by listening to people around you. Take for instance my boss, he's been working in this field for 20 years, he knows a thing or two about interacting with non-technical people. The do’s and don’ts when discussing design decisions, how you explain why you shouldn’t do it they way they want, rather they should do it this way instead. On the other end of the spectrum is time estimation, now I still don’t have a clue how to estimate my time, and I don’t think I will for a while. However, I do have a better understanding on how to describe how long something will take and why it will take that long. As anyone who’s dealt with a client directly they will know that if they don’t have any programming experience it can be a nightmare to explain why adding this simple function could in fact take weeks and would mean a complete rewrite of a major part of the system. It’s these situations that become difficult, it’s hard to describe why a simple feature is so time consuming. It will take me years to learn how to handle all these client interactions properly, but if I listen and take in what the senior people around me are saying, I might just get there a little quicker.

It’s not just PRs that I have improved, it’s my overall code as well. I wrote this code that I thought was perfect, it looked great, it was broken down into functions nicely, there wasn’t any code duplication. Or was there? When I went to show it to one of my coworkers (Jeff) he quickly pointed out although it was good, it could be vastly improved. Now this hit my ego pretty hard, I had carefully, meticulously written this code, refactored it and here was Jeff telling me it could be better. How could someone with an entire 6 months of experience not have written the most perfect code ever? Turns out I didn’t, little did I know but some authentication I was doing in regards to a users access permissions could have been done much more simply, in fact it would refactor a lot of my code. I wasn’t happy but I did it anyway, I rewrote my “perfect” code. After some fiddling, some breaking and some fixing it was complete, my code was now perfect! “Hold up” says Jeff, “You can also get rid of this duplication here that you created”, so I went back and improved it once again. This sequence of events has happened a few times in the past 8 months, to the point where I expect that when I create a PR, I wait for the few comments saying this can be done this way, or how about doing it this way it's much more efficient. It’s these comments that are making me a better programmer each and every day.

It's not just code improvements that your boss might suggest for you to improve on, its other areas as well. About 1 month into starting at OVO there was a new project starting, one that would require some investigation into the right technologies to use. I was given the task of investigating whether we should use Dot net or Elixir for a brand new startup. I created two test applications one in Dot net and the other in Elixir. After one week I was told to report back with what I had done, and which one I should think about using for the project. After one week I had built a very basic crud application with dot net, in the Elixir application I had done just about nothing. I reported back to my boss that we should go with Dot net because it was easier and more familiar. He immediately replied with “no we will use Elixir”. At this point I was slightly annoyed that I had wasted the week when a decision was already made, but on the other hand I was kind of freaking out as Elixir was the first functional language I had ever used and it was doing my head in. Now 8 months later I couldn’t imagine using any other language as I’ve completely fallen in love with Elixir and it’s libraries. Time and time again the wisdom of people who’ve been there, done that, has proved to be very helpful. When they say you learn the most from failure, there not wrong, it just doesn’t have to be your failure. Using the teachings of others to guide you around the pitfalls that many of us fall into, can skyrocket your growth as you don’t have to waste your time falling into the holes that others have already dug, instead let them give you the bridge to pass over.