Tracking Improvements

We all want to make improvements to ourselves. It is a long process that takes a lot of work and continuous effort towards our goals. Recently, I have been asking myself a few questions about my goals and the progress that I am making towards them.

The first question is, what are my goals? This is a question that I never have really asked before. I always knew that I wasn't going to be a truck driver like my dad, but beyond that I was always flying by the seat of my pants. It seemed to work out relatively well at first. I graduated high school and went to college. I can't even tell you how many different courses I took in college to find what I "wanted to be when I grew up." I decided finance. Well, I didn't love finance so I changed careers and now am a Software Engineer in Test. I like this job for the most part, but what is my end goal?

 I would say I want to become a full developer, this raises another question on is this a good long term goal for me? Great, I have an end goal for now. But what is the time frame for this goal? 1 year, 5 years, 10 years (better not be the later two). To reach this goal I have been setting intermediate goals. Here are a few of the goals I have been thinking of lately:

• Build API
• Build App
• Deliver App to App stores
• Speak at a conference

Great news! I have already completed the first one. I know that each of those goals have steps I need to take in order to reach them, I just need to figure them out. Not only do I need to figure the steps I need to take, but I also need to keep track of what I am doing to achieve these goals.

I recently saw part of how a person I look up to keeps track of his goals and self improvements. I look up to him as I believe he is very organized and able to keep up on everything, from sports (both U of U and BYU!) to family, and technology to his work. I can't even keep straight who the quarter back is for the U of U, how can I be expected to remember so many other things. I need to find a process that works for me that allows me to keep track of my daily activities, my goals (need to look at more and come up with a long term plan), the stuff I read, and other activities I feel will help me reach my goals.

The plan I saw was a checklist of sorts that had many different categories. I saw it and decided to try something similar in OneNote. I created different tabs, 5 year goal (nothing here yet), 1 year goal (becoming a dev and the ones you see above), monthly goals (did this for one month then forgot all about it), and daily goals. My daily goals are simple, like read a tech blog and learn some code. Really generic and I know in order to reach my long term goal of becoming a full dev I need to get more specific goals. That then shows my lack of what I don't know. What are the daily goals that will help me reach my long term goals? 

I have recently been teaching myself Xamarin.Forms using a course through Udemy and other online resources. I posted about my learning of MVVM the other day. Let's be honest, the MVVM "challenge" has been really hard. It is refactoring some code that I wrote early in the course. This let me to think that I don't know the basics as well as I maybe should. I had trouble separating out the responsibilities and seeing what each ViewModel would need in order to work correctly (it still isn't working, the app dies when I try to save and then won't start up again until I delete the SQLite Database that was created). I also took more then a few hints from the answers to find that in some parts I was doing well and had a good start and others I was totally wrong. 

I here that everyone uses Google to help with their work. But what goals do I need each day to reach my end goals and how do I keep track of them. There are some days where I am really good at keeping track of the daily goals. Other days, like Tuesday, I totally forget to even look at my goals and many of them don't get done. Questions arise such as how often should I look at the longer term goals and adjust them? I think this will be an iterative process. Find something that doesn't work and move to the next method. Keep trying, just like code, right? One day I will find something that works.

"Success is not a good teacher, failure makes you humble." - Shah Rukh Khan

Attempt at explaining MVVM

100 Days of Code is done. I may not be coding every day (last weekend we went to Moab and spend our days in Arches National Park and I didn't code) but I am still taking time to learn things. I am nearing the end of a Xamarin.Forms class on Udemy taught by Moshfegh Hamedani. I have one more activity left and then "Beyond the Basics" section to go. Then I will be a great Xamarin.Forms developer, right?

Well, I will have more tools to help me at least do some development in Xamarin.Forms. Today I did the section on MVVM (Model-View-View Model) pattern. I knew that using the code behind, like we did in all the examples, may not be the best way to code in XAML. We use MVVM in some of our applications at work and I thought this section would be great to learn for my own project and also so I can better understand what we are doing at work.

We hear that teaching is the best way to learn. And by we, I mean that I have heard that many times and again today in a video post on YouTube channel called Top 8 developer habits: Teaching - Fun Fun Function. Watching that today I thought, why not, let's blog about MVVM to help make sure I really understand what I learned.

What is the best way to describe MVVM? Well, it helps separate concerns of the front end and the back-end logic. This will ensure that the front end doesn't need to know the logic behind the data and the back end get's to do all the calculations and only give the data when it is asked for. Your view just needs to know what to pull and the model will just store the content.

Model: The model is a domain model that has both the behavior and the data. When you enter new data to be stored, the model will handle any transformations to new data and then store the data.

View: This is what the end user sees, so make it pretty. It isn't going to do much else.

View-Model: This is a layer of abstraction between the model and the views. The view model will make the calls to the model and send the data to the view to be shown. It also works the other way. It can take that data from the View and send it to the model to be stored. It will also know what to do when you change a setting or click a button (that doesn't change/add data to the model) in the View. It let's the model just know what to do with the data and the view to just continue looking pretty.

Quick lovely drawing that you probably won't be able to read:

Ok, why do you want to use MVVM? From what I have heard (I still need to do this on my own) it makes your code more testable. If you are using Xamarin.Forms and do all the code in the code behind, you can't test it. It is too tightly coupled with the XAML code and your tests won't be able to see what is happening in the UX layer. MVVM will also keep a separation of powers.

What could be a downside of MVVM? The amount of time it takes to implement MVVM may be overkill when you have a simple application or you never plan on doing testing (pretty sure this is unit tests, you will always want to have some sort of testing before you release to the wild). What is the size of the application it would be overkill? Good question, maybe a small to medium application would be fine using just code behind or using a model and view alone. Large projects you will probably want to use some framework that will allow for better testing.

That is probably an over simplification of the MVVM model, I think I am going to put some time on my team leads calendar tomorrow to discuss it with him and make sure I have it correct, isn't Ryan lucky?

"All great achievements require time." - Maya Angelou