Well, I have finally stopped doing most of my work for the old Sustaining team. I am now doing most all of my work for the Core Services team. That means I am writing code and tests. This week I have been working on writing acceptance tests that will test our implementation of a rest API.
A few things. I have been doing some Pluralsight videos to try and understand what it was we were actually implementing. I think I have a better understanding of what and API is and how we are actually going to use it (although there is always more learning I can do on this topic).
Next, acceptance tests.I have never written acceptance tests and needed to understand what acceptance tests were and what they test. Happy Path. You know, make sure the code is doing what we expect without the weird scenarios (other sets of tests should make sure that these scenarios are caught).
On to the writing of tests! Well, it was more pairing with one of the developers on the team for the first few tests (get, post, and patch) to make sure I understood the framework and what I was doing. After working with Jason on the tests, I took what we wrote and changed them a little, added a few scenarios, and added the delete tests without help.
All the tests were working! It was a total of seven tests, so not many, but the most code I had ever written and it felt good. The green check when running the tests makes you feel great! The code you wrote is actually testing functionality of your code and will add to the program by ensuring it doesn't get broken. What's next? Send in a pull request (I hope I have all my terminology correct, but a code review for Git). That is when it happens.
This is my first code review for anything greater than one line of code. Once Ben was done with the pull request he turned to me and said, "Sorry I was brutal." Really? I think Ben was just prepping me for all the comments he was giving me.
The pull request was great. I don't think it was brutal, but it was a learning experience for me. Should I have known and coded some of the suggestions before I sent the pull request? Maybe. Okay, the answer is yes. One of the comments was to move some code to a shared base class with the tests I wrote and the tests another tester/engineer wrote. I should have read their pull request the week before and known that there was code in both of our classes. Remember to read others pull requests or ask more questions in our daily standups to make sure I am not duplicating code. Something for me to work on, make sure I am more aware of what everyone on the team is doing.
The moral of this story is that Ben thought he was being brutal. I think he was being very helpful. I am still refactoring the tests to implement all of his comments (I already have a few of the tests working again using the new initialization from the base class). Everyone needs to be continuously learning. That is what helped get me from finance to the software industry (although I still feel I am lucky and maybe don't belong in a coding role). The pull request is a learning tool. As I continue to grow the comments will come back and be different then the "brutal" comments I got from Ben. I hope they are all brutal and continue to help me improve my coding ability.
I saw a great quote today on
Twitter. It said, "It takes time to get good at coding." And it does. I will get there, eventually, and the pull requests that are rejected help me see how I can improve and help me get there quicker.
P.S. My wife goes back to work on Friday. No more morning C# on the treadmill at work! I hope to still wake up early enough to get some learning in before I take my daughter to day care.
