So today is a pretty important day for me as it marks my third month at my new company, which also marks the end of my 3 month probation period.

I am also ecstatic to say that the company has been happy with my progress and work so far, and have kindly extended my employment as a permanent addition. High five!

I thought this would be a good opportunity to look back on the 3 months in this role and talk about the (many!) things I’ve learnt and the challenges I’ve faced.

no-idea-what-im-doing

Ok, it wasn’t QUITE like this. I wasn’t wearing a tie on my first day.

So I started my first day on the job 3 months ago, opening up Visual Studio for the very first time, to start my C# development, a language I had up until that point never used before, on my first task on an existing Windows Form application for one of our big clients.

Everything was new to me, and it was a lot to take in over the course of the first few days. Fortunately though, I was given the first week to try and get to speed with my new development environment and find my way around a bit on the project and the language I’ll be using.

“I’m Starting to C Things a Little More #’ly Now..”

(Ok, that pun was terrible. But moving along..)
The company kindly offers to sponsor their developers a PluralSight account, which is an indispensable resource of video tutorials and screen-casts of a multitude of tech related subjects (seriously, if you don’t know yet about PluralSight and looking for resources to learn from, do yourself a favour!). I took the opportunity to then dive in and watched a number of videos around the basic fundamentals of C# 5.0, to getting familiar with Visual Studio 2013, and some basic Windows Form practices. I didn’t get around to completely finishing all those courses, but I watched enough to start becoming a bit more productive and able to carry on my first couple of tasks, and then take it from there.

What I also found important, and helped me a lot, was the ability to read the code and try to ‘reverse engineer’ what is already written to accomplish my tasks. Sure, a lot of my time was spent effectively ‘copying and pasting’ various other solutions of code into the areas I’m working on, but it was a good way to learn the structure of the project and get the scope of it (it was a pretty complex project with many classes and forms dealing with various levels of data calculation and manipulation, so even finding my way around was a challenge in itself).

616_lrg_dilbert_9

While our project wasn’t 100% true ‘Agile’, we worked to what was close to 1 week sprints. So a typical week consisted of a new fresh challenge, which involved a fair time of investigation, then development, then a good time spent pulling my hairs out in frustration, then having an epiphany when it all starts to make sense, then QA of the work I just completed, then fixing any push back from the testers, then off to staging/UAT. Then the next week starts all over again.

It is a roller-coaster of emotions and experiences from feeling on top of the world when you finally accomplish what was at first an ‘impossible’ new task, to then questioning how did I ever end up here when trying to debug some bizarre edge case pushed back from testing which requires possibly a whole new and possibly a more complex solution. But then you make it through that and all is good in the world again. :)

Truthfully, while I experience many moments of doubt in myself during the tough days, wandering if I am truly capable of pursuing a deeper career in this field when surrounded by so many other seemingly more naturally clever and experienced people, the joys of solving a problem and achieving the desired result is something which makes it all worth it and gives me the confidence again.

Sure, I might not yet know C# like the back of my hand as well as my peers and mentors do, and I might not be on top of all the best practices and recommended standards when it comes to writing efficient code, but I’m hopeful it will come. I mean, we all start somewhere, right? :)

000146454

Unit Testing – “The Best Way to Test Code, Is to Write Code That is Testable.”

Recently as well our team has begun making an effort in complimenting our development code with Unit Tests. This has been a fairly new experience for most of us, and has been challenging working out how to test a unit of code and how not to rely on database transactions by mocking and faking data.

The time spent on writing these, while started off quite slow, ended up paying off when a client reported a small calculation change that is required on one of the report generators and an area where we started our unit testing for. I made the change and could immediately see how that impacted our other scenarios we had written unit tests for, and saw straight away the impact one line of code can do that wasn’t immediately apparent. This allowed me to not only catch edge cases, but saved time from testing the work manually myself, and allowed me to push the completed change to QA more confidently. If they find a new edge case scenario, I just create and update a new unit test for it. Done. Never a problem again (in theory!:p).

They also say that the best way to test code, is to write code that is testable. And that has proven to be a wise proverb while writing our unit tests, since we quickly saw how difficult it is when it is not the case. A piece of knowledge I hope to use when I start on new development tasks…

“Party in the front, Business at the back”

What I have been grateful as well about this project is the amount of exposure we have to all areas of the project’s system. I’ve spent some time in a couple software companies where the front-end team was kept very far away from the back-end/server side team.

In this project we as front-end developers have been required to get our hands dirty on the back-end side as well. From updating scripts to accommodate new front-end changes, to writing whole new stored procedures from scratch where required. I’ve learnt a fair share of new things about what SQL functions are, what dynamic SQL is, what Views are helpful for, and the power that is SQL profiler.

It is definitely some valuable experience to be able to work on both the the front-end and back-end without much friction of ‘designated roles’ for each, and it broadens my scope of the inner workings of development far more.

Actually starting to know what I'm talking about!

Actually starting to know what I’m talking about!

“So the journey continues…”

It has been a wild 3 months and has gone pretty unbelievably fast. It is sort of hard to reflect back on the first day I started and get grasp just how much I’ve progressed, since it *almost* feels like just a couple weeks back that I started. But I’m confident that I have made decent strides from then till now, and the pieces of the puzzle are all coming together and the picture is becoming clearer with regards to understanding the world of software development.

The project I am currently working on is slowly coming to an end as we prepare to hand over the final build to the client, and I think it has been an intense and awesome project that I joined on to get me on the ground running.

So while I’m not sure what project or environment I’ll move onto next, I’m confident I’ll survive and learn even more from the new challenges that await. :)

15