Learning is enjoyable sometimes…

A few weeks ago, I signed up to take an Algorithm and Data Structures course on Coursera. Part of my reason for this is that I like having stuff explained to me, but mostly because the course has deadlines and I find it easier to stay motivated if the threat of a “0” is looming.  The coursework can be completed in any language but they have starter files and tests already set up for C, C++, Java, & Python.  We’re welcome to use other languages, but we’d have to write our own tests.  Fortunately for me, my first language was Python so I’m dusting off those skills to complete the coursework.

I’m in week 4 of 5 in course 1 of six-course series.  While I don’t know if I’ll complete all six, I have gained some pretty nice insight into how to tackle problems.  Greedy strategies, divide-and-conquer, among others are explored and the course requires us to think about the time-limits required when we submit our assignments.  The correctness of the assignment is not only “can you write an algorithm to complete the task, but  also “can you keep the algorithm from going over the time limit?”  No brute-force/naive answers allowed!

Getting back into Python has been entertaining. Initially I had to write out my algorithm in Swift using Xcode’s playground, and then translate it into Python.  After a couple of weeks I’ve been able to transition into just using Python.  I still write it in Swift afterwards just to compare the syntax differences of the two, but it’s nice to be able to pick something back up after not using it for almost two years.

So what problems have I solved? We started with Fibonacci, which I’ve done before but this was the first time I spent really exploring how it is computed recursively vs. iteratively. Even if not optimal from a memory allocation standpoint (most of the time), recursive functions are really beautiful in their simplicity of code. It reminds me of a more elegant while-loop. Initially I begin to wonder why even learn to use recursive functions if they suck memory so quickly when dealing with large numbers, until we got to the Greatest Common Divisor (GCD) problem.

Note: Recursion in programming is a function that continues to call itself until some terminating condition is met.  I write the function and call the function in the same code. For example:

someFunction(parameter A, parameter B) -> Value {
// do some stuff
return someFunction(parameterA, parameterB)

Screen Shot 2017-09-22 at 9.23.00 AM

GCD is is comparing 2 (or more numbers) and finding a divisor that both numbers share. For example:

gcd(6,8) -> 2

2 is largest number that six and eight can both be dividing by. 3 works for 6, but not 8, 4 works for 8 and not six; you get the idea.

But what if the numbers are really large? say 2,877,988 and 956,432 ?

can you imagine write a loop that starts at 1 and divides all the way up to those numbers checking to see if both have remainders of 0 when being divided? How long that must take?!

Well the course let us know a secret about large numbers. The remainder taken when dividing the first number by the second number has the same GCD as the original two numbers.

Screen Shot 2017-09-22 at 9.23.52 AM
I didn’t really understand this until I saw it in action. (See below) Also, how did people figure this stuff out?!

So even though the number is smaller, the GCD is still the same.  So basically, to find the GCD of the original numbers, keep dividing the first number by the second number until the remainder is 0.  Once you have that, the first number left is your GCD.

Here is a better visual of “trick”:

Screen Shot 2017-09-22 at 9.29.38 AM.png
This made much more sense to me than the Lemma above.

I have two numbers, A: 3,918,848 and B: 653,264. I divide 3,918,848 by 1,653264 and the remainder is 612,320, which we will call A-prime.  I replace the A with B, and put A-prime in B’s old place and perform the same operation again.  I keep doing so until A-prime is 0.

In this case, recursion actually doesn’t take terribly long as it’s reducing the size of the number pretty quickly, unlike when building numbers up during a Fibonacci sequence (1, 1, 3, 5, 8, 13, 21…).  So an efficient way to find the GCD of two numbers actually is to use recursion, though probably not the only efficient way…

Here is the Python function:

Screen Shot 2017-09-22 at 10.00.43 AM

It amazes me how short it is.

Using that algorithm allowed me to complete another assignment that finds the Least Common Multiple.  I won’t go into it but they provided another tip on how to calculate LCM using GCD and again, it provides a short elegant solution.

I think the decision to take this course, for me, was the correct one.  I’m being exposed to some handy tools, I’m obligated to finish assignments since it is costing me a monthly fee and the assignment are providing a nice warmup to my day for me while I drink my first cup of coffee.  (Note: if I haven’t finished the problem after 10-15 minutes, I wait until my lunch break to finish).

This week we began looking at binary and linear search algorithms.  In the past, when I would look at these, I just tried to memorize it so I could regurgitate it if it came up in an interview. Now, I have a list of questions I ask myself and can look at mathematical explanations and make sense of them, which aids in my understanding all the more.

None of what I’m doing may ever be needed, but I’ve finally gotten to the point where I view learning algorithms as not a means to an end in a job search…which is where I was a year ago.  Instead, it has become “I really want to learn this stuff. I find it interesting.” Perhaps at some point I’ll even do it without having to spend money to motivate myself!


Tripped up on closures…again!

I’ve posted before about learning closures. Earlier this year, I was really making an effort to understand how they work. My examples, though, were contrived, or rehashes of other peoples’ examples. As such, my ability to remember them suffers. Context is so crucial to understanding something. I was working on a problem at work today where I need to sort an array of data.  For some reason, I kept blanking on how to do it.  I could write the code that does it, but I couldn’t explain it to myself.  Here was my problem…

var meetings : [Meeting] = [
Meeting(startTime: 0, endTime: 1), Meeting(startTime: 8, endTime: 11),
Meeting(startTime: 2, endTime: 8), Meeting(startTime: 10, endTime: 12),
Meeting(startTime: 9, endTime: 10)]

I wanted to sort the array by startTime. Had this been just an array of numbers, I could have sorted it pretty quickly. For some reason, though, having instances of a Meeting class was throwing me off. I knew that this code would give me what I needed:

let sortedArray = (meetings.sorted { $0.startTime < $1.startTime }) 

This is really shorthand syntax. I know it works, but I could not explain to myself. So I tried the long hand way. Unfortunately, when I tried to write it in a way that made sense to me, I kept getting errors from the Swift Playground page I was working in. Undaunted, I went looking for answers. The Apple documents offer this when working with closures:

{ (parameters) -> (return type) in (statements) }

Hmmm…okay, the parameters I want to pass in, I thought, were the startTime of the meetings. So I wrote something like this.

let sortedArray = meetings.sorted(by:
 { (s1,e2), (s2, e2) -> Bool 
in return s1 < s2 }

What I thought I need to pass into the closure were the start times and end times and sort it that way. I was way off.

As it turns out, when I create a new array like I did with sortedArray, if I declare the type of Array it is, in my case [Meeting], that is the parameter that is passed into the closure, not the properties within the Meeting instance. I didn’t discover this until I explicitly typed it out, and used my old friend, Option-click, which told me what type sortedArray was. When I began typing in the sorted function on the meetings array, Xcode offered this little gem:

Screen Shot 2017-08-28 at 8.02.04 PM

As it turns out, I’m not passing in meeting.startTime or meeting.endTime into the closure. I’m passing the entire Meeting instance. In fact, the closure, as seen in the screenshot, takes two meetings from the array and compares them to return a Boolean value. What it evaluated is everything after in. Once I have the meetings passed in, I can access any of it’s properties to do my comparison.

Screen Shot 2017-08-28 at 8.12.52 PM

What I didn’t understand before is that m1 and m2 are just parameter names for the objects I’m passing in. They represent the meeting instance, not the properties contained within the meeting…which is what I really wanted to evaluate.

So in the end, in order to explain something to myself, my code wound up looking like this:

let sorting : [Meeting] = meetings.sorted(by: 
 { (m1, m2) -> Bool 
in return m1.startTime < m2.startTime}

Yes, it’s not very “Swifty” and in the future, I can use the shorthand trailing closure syntax and be able to look at it and know exactly what is going on. However, using code and being able to explain what the code is doing is a better indication of understanding than blindly trusting something I find on the internet, see that it works, but have no idea why.

I realize this topic is pretty junior for many developers, but it further reinforces what I discovered when taking calculus in college. If you don’t use something often, you forget it. Code is no different. It also helps when learning something, you have a problem you are trying to solve rather than seeing someone else’s example and saying “Yeah, that makes sense.” I do not expect this to be my last post on closures. Especially since I still have more functional programming to learn!

On the upside, at least as I see it in my growth as a developer, I went to Apple documentation rather than Googling for an answer in StackOverflow. As tempting as it was to ask my fellow iOS Slack channel mates, I decided to see if I could figure it out first. When time isn’t urgent, it’s amazing how much patience I have when solving a problem!

Algorithms…necessary annoyance

Update: It was mentioned to me over the weekend that my title didn’t really tie into the content I presented (tip of the hat to Abbey Jackson!).  The original title of the post was supposed to discuss why I was continuing A&DS stuff even though I could spend that time learning new Apple APIs from the forthcoming Swift 4 release (the lab I work in does a ton of research using machine learning so I’d like to get a better understanding of how it works and it’s uses in app development).  The necessary annoyance part, to me, means that although I have a developer job, and I managed to get one without having to pass a rigorous A&DS interview, I do realize that potential future moves may require it and that I’m not particularly prepared for it. So rather than devote time to specific iOS-related stuff, I’m working on this instead. It’s interesting, but annoying too! 

A couple weeks ago, I hit the one year anniversary from when I graduate from The Iron Yard.  Since then, (after a couple months of interviewing) I’ve been employed by Emory University’s School of Medicine, seen The Iron Yard announce they’re shutting down, and generally just kept plugging away at learning all I can about Swift and app development.

There is always a general doubt that lingers when I attempt to teach myself new stuff.  Not having a background in CS, I occasionally have reminders about imposter syndrome (that voice that tells you that you aren’t really a developer, you’re faking it).  True, it’s stayed quiet for most of the last six months or so, but when I start learning something new and I’m not getting it, the voice gets a little louder.

When I was in interview mode last year, the common feedback I received after an interview was “your algorithms skills are really weak, you need to work on it.”  Algorithms and Data Structures (A&DS) is a course CS students take fairly early in their major. Bootcamps don’t look at it much.

Still, it’s a rite of passage that basically reminds me of the SATs in high school.  Colleges don’t really know how you are as a student compared with others, so there has to be some sort of fairly objective assessment that might indicate that you can indeed solve problems.  (* NOTE: this isn’t an endorsement of the SAT or ACT, and those scores aren’t an indicator of your success level in college and beyond, but, as imperfect as it is, a college having to decide among 10,000 candidates who may have a 4.0 in high school to fill 500 spots has to use something to distinguish the candidates and the test is the same across the country.)

Anyway, algorithm questions in interviews are just one of those things. I say this as a newer developer, as I have no idea what senior developer interviews are like.  When I was in the job search, a couple friends and I bought a subscription to a website that helps prepare for those type questions.  I used it for a couple weeks, but never made much effort at it (by then I had a job offer).

Fast forward to today and I’m looking over it again to see if some of those questions are easier for me now, than they were a year ago.  The short answer is: “not hardly”.  It’s a skill that must be worked at (at least for me). I’ve started working on one problem every two days during my lunch time to try and train myself to be better at these questions.  I’m in no hurry to change jobs as I really enjoy what I do, but I also don’t want to try and cram for stuff like this when the time does come for me to interview elsewhere.

And really, it doesn’t hurt to know this stuff anyway, regardless of whether I’ll ever be asked questions like this in the future.

So my first problem to solve was this:

Given a list of stock prices over the course of one day, write a function that would calculate the maximum profit you obtain from buying one share of the stocks.

So basically I have an array (list if you’re using Python) of stock prices.

let stockPricesYesterday = [10, 7, 5, 8, 11, 9]

The rules are:

  1. Buy one share and sell later (no shorting the stock)
  2. Account for if the stock price contained any negative numbers (or if all were negative, what’s the best “loss” you have.

Clearly look ing at the 6 prices, it’s easy to see that we need to buy when the price is $5 and sell when it’s $11.  But what if the array contained a price for every minute the market was open?  The function should work regardless of the size of the input.

So, looking at this and knowing the answer, I still had no clue how to get started.  I’ll use the array, look at each element and decide when to buy and when to sell.  Aside from that, I wasn’t really sure how to do this without the need to use multiple loops. (Big O notation is not something I’ll talk about at the moment, but basically it’s a measure of how long an algorithm takes to solve something…the shorter the better)

I’ll be the first to admit, that I had to use the website’s help on this.  I didn’t look at the solution, but I did have to keep choosing the “I need a hint” button.  Eventually I got to a point where I feel like I could get started.  These are the hints I was given.

  1. Maximum profit is the goal. We calculate it by selling at the current price.  It’s the difference between the current price and the lowest price we’ve seen so far.
  2. If the difference between the two (Current Price – Minimum Price) is larger than the current maximum profit that we’re keeping track of, then update the currentMaxProfit to the new profit.

So I have to keep track of several things. The minimumPrice I’ve seen, the maximumProfit I’ve seen thus far, the currentPrice I’m looking at and the currentProfit margin while I’m at the currentPrice.

The website mentioned an idea of using a “greedy” approach to solving this.  The greedy approach is basically keeping a running total of the end result (max profit) while I search through the list of numbers, and updating it along the way if I find a larger max profit.  (more information about greedy algorithms can be found here: Greedy Algorithm Basics

Once I had all this information (hints), I was ready to start writing a function.  I want the function to be able to take an array of prices, process each price and determine if the current price I’m looking at minus the lowest price I’ve seen thus far gives me a better profit than the currently held maximum profit. If the current price I’m looking at is lower than the minimum price, then I need to update that as well.

All my life I’ve never been one to make lists, or to outline. If a paper needed writing, I’d just start typing and edit on the fly.  This isn’t the best approach.  I must have re-written this function quite a few times as I made several mistakes.  As I look back on the answer, an outline might have been helpful.

  1. Find the minimum price (basically the first price in the array to start)
  2. Find the maximum profit (basically the difference between the first two prices in the array to start)
  3. Now, look at each price individually (i.e. Iterate through the array/list)
    1. find the current price (that is the price a that particular iteration array[0] is the first price, array[1] is the second price, etc…)
    2. find the current profit (difference between current price and the minimum price we originally set)
    3. Compare the current profit to our already found max profit.  If current profit is larger, then update max profit to be the current profit
    4. Compare the current price to minimum price set earlier.  If the current prices is lower, update the minimum price to be the current price
  4. Move on to the next price in the list and repeat

Strangely, once the blueprint (outline) is listed, the problem doesn’t seem to be that terrible.  However, my biggest problem was not being able to visualize what variables I’d need to keep track of.  I go back and forth on this.  Sometimes I just jump in and start adding a bunch of variables that I think I’ll need and delete the ones I don’t use.  Other times, I try to add as I go.  Neither way has proven to be very useful.  They’re both hit or miss.

I guess that’s why I need to practice.  Anyway, my final function wound up looking like this:

Screen Shot 2017-08-25 at 9.34.46 AM

Note: stock_prices_yesterday was a global property I declared earlier in the code…it’s just not visible.  I probably should update it to stocks[1] - stocks[0] instead.

This was question 1 of the website.  It took me about a 1/2 hour to work through. I’m trying to keep in mind that I haven’t done this in a while and I’m just getting my brain used to thinking this way.  Algorithms aren’t like riding a bike…yet.

Of course, I might go the rest of my career without every being asked to do this. But problem solving is a skill in constant need of refinement, and despite my outward appearance, I don’t want my brain to be rough around the edges!

Adjusting the sails…

Most have heard the quote that I reference in my title.  I remember hearing it at my high school graduation. It’s pithy, memorable, but for a long time, to me, utterly useless.  I had no context to apply it.

That all changed on Memorial Day last month.  For those unfamiliar, the last Monday in May is Memorial Day, a time where we honor the memories of soldiers fallen to defend the United States. For most, it’s a long holiday spent at the lake or a cookout. For others it is remembering loved ones that paid the ultimate sacrifice.

For the past month, I’ve taken a more pro-active role learning delegates and protocols in swift.  Most documentation or how-to videos involved protocols with extension, which provide a default implementation on how to use the protocol.  It’s much harder to find a good tutorial to pass some data from one file to another via a delegate.  I’ve tried to find good examples that help to answer my questions instead of bringing up more.  Much of what I’ve found hasn’t been helpful.  For a couple of weeks, this kept me pretty much at a standstill.

Fast forward to Memorial Day.  It’s a CrossFit tradition to perform the Hero WOD “Murph” on Memorial Day. Michael Murphy was a Navy SEAL who sacrificed himself to get a radio message to help his fellow SEALs.  Part of his story is told in the book & movie “Lone Survivor”.  Murph’s favorite workout when he couldn’t get to a box was a 1 mile run, 100 pull-ups, 200 pushups, 300 air squats, and then finish with a 1 mile run…all while wearing a 20 lb. weight vest.


So I participated in Murph for the first time over Memorial Day. There is nothing glamorous about it, at least from my perspective.  It’s a way to honor his memory as well as others who have fallen to defend the United States.  There is very little fanfare.  We show up, we workout, mostly in silence, and then we encourage others who are still trying to complete the workout.

I’ve been battling shoulder issues for the past few months and was recently allowed to resume so activities that involve the shoulders.  However, I was really worried about the pushups in Murph.  I decided to scale them so as not to face the wrath of physical therapist and endure more therapy (aka torture) at her hands.  So I did pushups from my knees rather than the standard.  At around 120 reps, my shoulders started complaining.  What to do?  End my workout, disappointed in myself and feeling like my contribution towards Murph’s memory didn’t count?   I came really close to calling it.  However, in the midst of the heat, humidity, and mild discomfort (yes, that’s sarcasm), the whole quote about adjusting the sails popped up.  I think there is something spiritual about trying to stretch your physical capabilities.  In this case, I had a moment of clarity.  An “a-ha!” moment.   Rather than just stop the workout, just change what you’re doing.  So I went to sit-ups for the rest of my pushups requirement.   Sure, it’s not the prescribed “Murph” (not that I was anyway as I wasn’t wearing the weight vest), but it’s still a way to honor his workout, and not give up.

So at the hour and twenty minute mark, I finished my final 1 mile run and completed my first Murph.  Of all the accomplishment I’ve had, this wasn’t bound in glory, a sense of accomplishment or any sort of fanfare.  Instead, I felt grateful.  I had the privilege of completing Murph.

The following Tuesday at work, sore from the previous day, I decided to change my approach to learning how to use a delegate pattern with protocols.  Instead of reading and searching for tutorials, I searched for code.  Any sort of delegate paired with a protocol.  How did they use it?  What triggers the delegate?  How do I assign it to View Controller that I need to perform the action.  I stopped waiting to have someone explain it to me, and instead went and found what someone did, and try to explain it to myself.

The end result is that I gained a small foothold in how delegates work.  I’m no expert.  But I was able to accomplish what I wanted, learn to adjust during my learning process, and once again, use a lesson learned in CrossFit in my career.  It never ceases to amaze how I can learn career lessons from a non-career related part of my life.



What a difference a year makes…

 This week marks a year when I left for Utah to start The Iron Yard Mobile Engineering bootcamp. I remember being worried about not being smart enough or able to comprehend fast enough the knowledge transfer about about Swift, Objective-C and iOS Development. If I’m honest, though, I still worry about that…it’s just the topics are a bit more advanced now than they were then.

Someone asked me the other week, “Would you do it again?”. I answered with an emphatic “YES!”. I took a major chance by quitting a stable job in the hopes of landing one in the tech industry. Corporation, dev shop, non-profit? I wasn’t sure where I’d end up. University never entered my mind though. I’ve now been an iOS Developer for Emory University for 8 months. I’ve helped build two games within the same app. The games could be stand apps in their own right, but we’ve kept them together. We’re also starting the 3rd game this week.

I had the same thought, over and over, as I made the 1900 mile drive out to South Jordan, Utah last year…”What if you make it through the bootcamp, but can’t find a job?” Well, it took a couple months of intense searching, failing (aka learning) at multiple interviews, but that, too, took care of itself.

I’m heading out this week to visit the campus and say my goodbyes to the staff. The Iron Yard – SLC is closing it’s campus so it’s unlikely I’ll cross paths with them very often. I’ll actually be flying out on the same day I left last year, just not with the same worry and anxiety that sometimes overwhelmed me then.

Donuts, catching up with my instructor, seeing the campus director (and beating him at ping pong!), visiting with some of my cohort (if they come visit!), experiencing the gorgeous Utah geography and even seeing my parents, who just happen to be out there as they RV their way through the country are all in my plans. This is definitely a low-stress trip compared to what I embarked on last year.

I don’t think much about the work I put in to get where I am. When you enjoy something, it doesn’t feel much like work. It feels like legos. I used to sit for hours and build stuff out of legos. Whatever my mind could think up, I’d try to build. The same holds true for coding. I put in 60 hours a week at the bootcamp, 60 hours a week during my time being unemployed, and probably still contribute the same both at work, home, and the volunteer organization I’m a part of. The hours fly by. I love learning new topics. Still, had I put the bare minimum in, I’m certain I’d still be searching for that first dev job.

I have a couple posts lined up in the next week or so regarding stuff I’ve been trying to learn so I hope to post soon. I try to let this blogging thing happen naturally rather than try and force something out there.

But of this week, I’m going to enjoy my time in Utah, recharge with fellow coders, eat some fabulous donuts, and reflect on how fun this journey has been.

Balance…a high wire act

I’ve been working for Emory University for about 6 months now. I’ve certainly grown as a programmer, and my confidence in figuring out problems is getting better. Yet, sometimes, I am still overwhelmed at how much I don’t know.

I received multiple calls from recruiters lately. While varied in how much they’ve actually chosen to read through my resume and learn of my experience, most have been genuinely interested and the positions closely match my experience. It’s flattering if I’m honest.

Six months ago I would have jumped at any opportunity. I was unemployed, desperate for a chance to prove my talents. However, after listening to the needs and the timeline of some of these positions, I politely declined. Sure, being employed makes that easier, but given what I’ve learned over the last five months, it has also made me more cognizant of what I can and cannot do (yet).

There is something to be said, though, for the ability to set my work hours to avoid traffic. The lab I work in has gone out of there way to make the office not feel like an office. The office perks are nice.

Ultimately, though, I’m still challenged and intrigued by the work. Why leave a job you enjoy? I spent enough years working a job I did not enjoy to appreciate where I’m at and what I’m doing.

So balance? I work right at 40 hours a week. I’m able to commute without traffic, enjoy the work I do, leave before traffic gets worse, get my CrossFit workout in and still get home before my daughters have to go to bed. If I take another position, I may have to give up one or more of those things…for what? More money? I suppose as I get older, I tend to evaluate more of the opportunity costs of a higher salary than I used to–that is, what am I giving up? Is $5k more per year really worth an extra 2 hours in traffic everyday? Is it worth reducing the amount of time I get to see my daughters play and tell me about their day? Attend and coach their respective volleyball and soccer practices? No. No it isn’t.

That’s not to say I won’t take another position elsewhere at some point, but I have become more discriminating in what it will take for me to make that jump. There is more to life than work (even though I really do love my work).

Leveling up

My lab consists of four developers, all bootcamp graduates. We have 2 iOS developers, and 2 Android developers. The Android developers are converted from other disciplines, so they have some experience in other areas besides Android. Both are very good back-end developers, having built back-end systems for the lab in both Ruby on Rails and Golang.

My supervisor has suggested I do the same so in the little spare time I have, I’m venturing into Golang and Dart to learn more about back-end and front-end development. That rabbit trail has led me into systems programming, which has historically been done in C. On top of that, I’m still playing with Algorithms and Data Structures so that I can be prepared for the eventual job interviews after my time at Emory in concluded.

Make no mistake. I’m not a front-end guy. I’m not really a back-end guy. But the pragmatist in me understands the appeal to a candidate that is more well-rounded. I’m not trying to leave iOS or Swift. I’m just trying to make sure I have an understanding of how the other stuff works in conjunction with iOS.

It can be overwhelming. Do I look at several things or focus on just one and get really good at it? I tend to go back and forth. “This week I only want to focus on A&DS” or “This week I’m going to spend the first 30 minutes of work on A&DS and then my lunch break on Dart.” It’s not particularly well-organized, I admit. Still, I’m feeling my way around and trying to find what works best for me. Organization has never been a strong suit of mine.

Podcast ranting

I listen to a few Swift podcasts while driving to/from work. Most of these are quite good. A few months ago, I thought I’d found a promising one. It was supposed to be geared toward new developers and the topics were one’s I was (still am) currently learning.

I was please with the first few from this one particular podcast, but around the time of the inauguration, it turned to more of a ranting/preaching podcast on what the podcaster deemed as not fair/ or “here’s how it should be.” Initially I defaulted to his judgment because, here I was, a brand new developer, and his first few podcasts were helpful and informative. Over time, I discovered he had 1 week more experience as a developer than I did. Not that being new at development is wrong. I’ve learned some good things from him. But once he began preaching about how new developers should or should not do this/that/the other, I began to wonder why he thinks he’s experienced enough to make these kind of opinions. Most developers I talk to on Slack are constantly having to adapt to an ever changing industry. His advice runs counter to that logic. It reminded me of the pointless faculty meetings I sat in on as a teacher and were told “Do it this way.” Why? I have a better way. I have a circumstance that doesn’t make your “way” the best way. Why should I adopt it/limit myself?

I reached out to him to ask if he was planning to go back to discussing iOS dev because lately I didn’t get much out of his podcast. He said he was, so we’ll see. I say all that to say if someone with 30 years experience talks about how much she’s changed in the industry and had to adapt, why does someone with 8 months experience feel like he’s got it all figured out? I don’t like limitations. I feel it stifles problem solving and makes my job boring.


I’ve started working through a book called How to Solve it by Computer by R.G Dromey. It was written in 1982. It was recommended to me on the iOS Developer Slack forum as a good starter book for bootcamp grads that need to level up on Algorithms logic. It’s a great read. The programming language he uses is Pascal, but aside from that he walks through the steps on how to solve basic problems. So far I’ve worked through how to reverse a number, how to convert a decimal number to any other base system (octal, binary, ternary, etc…) and how to calculate the factorial of any number. It’s enjoyable without being overwhelming, which I what I got when trying to solve problems out of Cracking the Code or Interviewcake.com.

Functional Programming

My previous posts on closures has led me down this rabbit hole called functional programming. I briefly touched on FP in those posts without explicitly calling it that. But as I read through a book on test-driven development (writing tests to make sure functions work the way they’re supposed to), the author is trying to move away from what he calls “writing swift in an objective-c way”…aka…the way I currently understand…

For example:

return string.characters.reduce(0) { $0 + (vowels.contains($1) ? 1 : 0) }

This is the Swift-y way of writing what is basically a for-loop and an if statement.

What I think it’s saying is this: take all the characters in a string and starting with a value of 0, reduce all the values of an input I give into one single value. Basically, this is starting with 0 and if conditions are met, we will increase that value. At the end of the function(closure), we’ll have our final value.

Ok…so what exactly are we combining/reducing/evaluating? Well, we’re reducing the characters in a string, but the closure part of the expression above specifies what will be reduced. In this case, comparing the characters of the string to some vowels. If this character matches with any of the vowels, increase the value that we started with (0), by 1. Otherwise, if the character does not match with any of the vowels, increase the value by 0.

I have left a few things out to reduce for simplicity. I could have expanded on what $0 or $1 mean, but I haven’t come up with a good explanation yet. It makes sense in my head, but I haven’t figured out the best way to put it in writing. Perhaps the next blog post will cover that.