Two months ago, I started the Machine Learning Course with Andrew Ng at Coursera.  It isn't just a challenging course.  It is both mentally taxing and time intensive for someone with a full time job that's a little more than full time and side work and other topics of study.  I did bite on more than I could chew.  I say "bite on" because I really didn't bite it off.  For one thing, work is preparing for a release of our product to its first users.  I've never worked on a product at the heart of so many massive businesses before, and this release is making me very anxious.  To top that off, I've still got some side projects I've been putting some effort in on, and just as I was finishing up that, I stumbled into some courses on building mobile apps which has morphed into learning React/React-Native.

沒關系 (méi guānxi - no problem) is a nice sentiment I've learned during the Mandarin lessons I'm also trying to stack in on myself.  I'm sure there's no real problem with putting too many things on my plate since they're all connected in some fashion.  I want to learn about Machine Learning so that I can effectively apply it, and I want to learn about mobile development because the future isn't in desktop computers since it does little good to have a desktop computer capable of solving problems you might encounter while you are out and about.  The language lessons are just because of some concept about the brain being able to form new connections even later in life if you challenge it to new stimuli and those new connections can help make other things easier to learn.

But there is an issue...

I paid for the Machine Learning course because I specifically want the certificate.  I want the certificate for work.  So falling behind was beginning to scare me a bit.  In fact, it's been a month since I last looked at the course.  When I logged in this afternoon, I got a nice surprise.  Coursera allows you to switch sessions without losing progress.  Whew!  So now I have more time to complete the coursework.

In a couple weeks, I should be considerably less stressed.  I will be able to slow down my mobile development learning and focus on the machine learning course and finish it before continuing.  Of course, this course is not even really required for working with TensorFlow which was built with the express purpose that developers could use machine learning without having in depth knowledge.

First, this is not a blog post about how much better one is over the other.  Plenty of valid arguments can be made in support of and against each of the platforms.  All of those arguments depend heavily on context.  The way I am approaching this subject is from my perspective as someone who has one weekend of experience in each of these platforms, so my views are very much leaning toward the limited experience, rapid development context.  

Xcode is the native platform for all things Apple.  It's a nice platform, and I could get used to it in a couple weeks.  I get the feeling that it would take me a minimum of 6 months of directed focus to become proficient in developing for more than one Apple device.  Because I'm specifically targeting mobile phone development, this is not a big issue, but just getting familiar with yet another IDE and the idiomatic expressions of yet another language means I'm going to spend yet more time learning instead of producing.

With Android App Studio, I can say immediately that the use of Java makes it more in line with my current skill set.  It didn't take long to get familiar enough to produce something that worked okay.  Like Xcode, it only took a weekend to go through some tutorials and get a little experience walking through the IDE.  The fact that Android doesn't have desktops and laptops and TV to program for helps to reduce some of the complexity of Android App Studio, but nothing you write here for your android device is usable in Xcode.  You literally have to do things twice or exclude some part of the App market.  While Android holds the healthiest share of devices in the world, Apple's customers are much more open to spending lots of good money on good product.  (I will not entertain any debates about Apple's quality.  It's a fruitless argument.)

What I like about React Native

• write once, works in iOS and Android
• JavaScript - one language to rule them all
• VS Code is a great multi-platform IDE

After completing tutorials each of the last two weekends, it still took hours to get a simple app with an image, two text blocks, and a button up and running appropriately.  Mostly because I had a heck of a time getting the layout to work for portrait and landscape modes, and I never actually got landscape to work on iOS.  I settled for locking the screen in portrait.  Not a real solution, but it prevented the app from displaying the elements in ways I didn't like.

I've put less than 2 hours into React Native, and I've recreated the application for both platforms, complete with portrait and landscape views.  Most of the 2 hours was spent locating, reading about, and installing the needed components for React Native.  That is a huge time savings.

It is very important to point out that there are limitations with using React Native.  Not all of each platforms' components are available to React Native, and because you aren't using the native platform, troubleshooting device specific problems will have to be left to someone with experience in that area.  Also, if you're not working in the respective platform, you're not going to become an expert in that platform; however, I really only have a couple weekends of experience with each of these three platforms, and the speed with which I was able to produce what I needed through React Native and the familiarity I already have with the tools and language lead me to believe this is the tool I should focus on until I find that my needs exceed its limitations.

I would be exaggerating if I said that every developer acknowledges the value of testing their code, but it isn't easy to find a developer who will openly advocate never testing code.  Usually, that guy is a disgruntled former employee of Google or Microsoft or Amazon and he's really just railing against someone who mentioned his lack of code coverage.  Not someone you want to listen to or receive career advice from.

If you're still early in your career and you haven't picked up any books on unit testing, you should.  The Art of Unit Testing by Roy Osherove is a good book that is focused on the subject, but Robert "Uncle Bob" Martin's books are a must read though they are generally focused on the entire practice of coding.  If you don't have a lot of time to dedicate to reading right now and need a quick shot in the arm to get a handle on what unit testing is, give Osherove a read.  I recommend it so much, I won't include a link so you can't accuse me of trying to profit off your education.  There.  A completely unfunded piece of advice.  I'm sure it's worth every penny and whole lot more.

Now, I'm guilty of this myself.  I talk about TDD and how awesome it is.  I know it's awesome because when I do it, I know I save myself a lot of headache.  What does it mean to do TDD?  Simple.  Write a test that fails (because the code hasn't been written yet), then write the code that's needed to pass the test.  This is the Red, Green in Red, Green, Refactor.  

Here is where even the best devs, of which I am nowhere close, begin to lose their religion about unit testing and code coverage.  The thought is, if I haven't written code, how do I know what the test is going to be?  THIS IS THE ERROR!  The truth is the opposite and actually a non-issue as I'll explain momentarily.  First, it's erroneous to ask this question.  The question should go the other way round.  You should be asking, How do I know what the code is supposed to do if I haven't written the test?  But really, let's address this question as it's often expressed: How do I know what the test is supposed to be?

Actually, I'll ask a question in retort: Do you have Acceptance Criteria?  I'll assume you do because if you're writing ANY software without it, you wasting everyone's time.  Maybe not right now, but down the road, a lot of wasted money is going to be your fault.  So stop writing software without Acceptance Criteria.  Now, in the AC, there's always a statement of what's expected.  That's the simplest form of non code test you can have.  Convert that AC into a unit test.  Do that first.  Now go write the code that passes that unit test.  Congratulations you've passed the acceptance criteria.  Only one thing left.  I'm sure you're a wonderful coder, but I'll bet some of that code you just wrote has some code smells.  Check for multiple responsibilities.  If some code is doing more than one thing, that's a good opportunity to refactor.  Naming is a good indicator of whether or not something is trying to have more than one responsibility....if you ever get a chance, crack open the DateTime class.  Pretty clearly stated in the name this class has two jobs.  Don't believe me, fine.  Check out Jon Skeet and NodaTime if you time to poke around.

And if you're on a project, your responsibility is senior dev or QA, and the lead engineers begin a project by saying "We don't have time to deal with automating the tests".  Raise concerns with your leadership.  Don't wait.  Because it's almost certain that there's an architect or an engineer in charge of things that doesn't realize that his leaders are opting to cut testing in favor of delivering bug-ridden code fast.