After spending the last 15 months at Apple working on the Everyone Can Code program, bringing Swift and App Development training into high schools, colleges, and enterprise, I’ve got something big to announce.

Earlier today, I started in my new role over instruction at Lambda School, a new YC-backed six month online computer science program that’s free for students until they get a job. And I could not be more excited. Check out the website if you want to learn more.

I’ve gotten more questions about this than previous career changes, so I wanted to recap a few of the reasons why I’d leave a job almost perfectly tailored to my background and interests at a company I love for another startup.

First, to do right by my family. We loved our experience in the Bay Area, but we are thrilled to return home to Utah surrounded by friends, family, and gorgeous mountains. I mean, just look at them.

Photo of gorgeous Utah mountains

Second, to get back into my interests and hobbies. Working at Apple has many benefits, but I’ve missed being a part of developer, open source, and local startup communities. I’ve missed working on side projects and freelance work. I’ve missed freely commenting on Apple and other tech stories, and speaking at events or conferences. All of these are an important part of my psyche, identity, and career satisfaction. (Relatedly, we’ll be shipping Wired In very soon.)

Third, to start something new that has the chance to change the world. On a micro level, I’ll get to work more directly with students working to change their lives. On a macro level, we’re proving a new model of education that puts student success over profits. If you work in a one-size-fits-all school that fails to empower students with real-world skills, or you profit off of student debt, we’re coming for you.

With the number of jobs that will be displaced by technology, including machine learning, artificial intelligence, and self-driving vehicles, I believe that adult retraining is the most important social challenge we face over the next decade.

I’m ridiculously excited to get started.

I use the Microsoft Sculpt ergonomic keyboard. Since it’s made by Microsoft, it has keys laid out for Windows. Left of the spacebar you have Alt, Windows, and Control, whereas a typical Mac user would expect Command, Option, Control. The names don’t match, nor does the functionality.

To reset the keys to work using typical Mac keyboard muscle memory, one would go into System Preferences -> Keyboard -> Modifier Keys -> Microsoft 2.4Ghz Transeiver vX.0 and swap Command and Option.

However, when Apple updated OS X to 10.11.2 they broke the keyboard modifier key settings in System Preferences. They no longer persist between sessions. If I unplug the transeiver, the keys are reset.

I did my duty and filed a radar, please go and submit a similar one if you’re running into this issue as well.

I got tired of resetting it each time I plugged my Mac into my display with the transeiver plugged into it. So I used Karabiner, a great tool for key remapping, to swap the two.

If you’re in a similar situation, here’s how you do it:

  1. Download and install Karabiner. It works on a low level, and will ask you for potentially scary permissions. But it’s a pretty commonly used tool, well supported, and well regarded by Mac power users.

  2. Open the ‘private.xml’ file to enter your custom key remapping. You can find the ‘private.xml’ file by choosing the Misc & Uninstall tab.

  3. Add the keyboard definition and the two items included below. Your entire file should look similar to:

<?xml version="1.0"?>



    <name>Remap Sculpt Alt to Command</name>
    <appendix>This maps the Microsoft Sculpt's ALT Key to Command.</appendix>




    <name>Remap Sculpt Windows to Option</name>
    <appendix>This maps the Microsoft Sculpt's Windows Key to Option.</appendix>





  1. Open Karabiner again to the main ‘Change Key’ tab and tap ‘Reload XML’, you will now be presented with two options at the top (the two items we just added to Karabiner’s options).

  2. Enable both options, go and test that it works

  3. Move on happily knowing that you won’t have to wait for Apple to release an update to fix this obscure bug

I’ve spent the past 10 years in education. Two years in Uruguay co-teaching small groups and large congregations with living conditions well beneath the poverty line. Five years in public secondary education with 35-40 student teenagers. And the past six months working with adults at a software development bootcamp in Utah.

I’ve seen many learning environments: Groups of all sizes. Students from all backgrounds. Teachers with all kinds of experience. Learning environments of all types.

In all of these different scenarios, I’ve found two essential ingredients for high-level learning:

Both the teacher and the learner must have a clear understanding of what the learner should know, and what he/she actually knows.

The teacher needs to know what to teach. The learner must know what she is trying to learn. Both should know when that learning has occurred.

Missing this ingredient causes learning to break down in 3 ways. The teacher works toward the wrong goal. The learner ends up distracted, discouraged, or bored. Both end up disappointed with the unsuccessful results.

Assessment is required. It can be formal or informal, but the teacher and the learner need to know what is missing. Great assessments don’t summarize achievement, they drive instruction. Great teachers use assessment data to direct the next learning opportunity.

Teachers and learners must be working towards the same goal.

The learner needs a willing and able mentor to bridge that gap.

Sometimes this mentor is the teacher. Unfortunately, one teacher doesn’t scale beyond a very small group. This is why people complain about large classroom sizes. This is why MOOCs don’t work. This is why a teacher can’t just regurgitate the same Powerpoint presentation for a decade and expect great outcomes.

In the most successful learning environments, a specific mentor works with individuals or very small groups. A great mentor knows what the student can do (assessment), where the student is headed (objective), and how to guide him there (teaching).

What This Means for Teachers

A teacher’s job is not to stand in front of a group and deliver content.

A teacher’s job is to craft a learning environment with clear learning targets, positive learning activities, reliable assessments, and mindful mentorship interactions.

It works in small groups and large groups. It works with students from all backgrounds. And it works in every learning environment. No one is excluded or excused.

What This Means for Learners

Learning is not a passive activity.

A learner’s job is to find an opportunity where teachers set clear learning targets, create positive learning activities, use reliable assessments, and fosters mindful mentorship interactions.

Furthermore, a learner’s job is to understand those expectations, participate in positive learning activities, self-assess progress, and foster mentor relationships.

A Two Way Street

I believe in the learning process. It is an essential element of a happy and successful life. We can all benefit from understanding how we can teach and learn better.

If you’re a teacher or a learner, consider the two essential ingredients to a positive learning experience. Make them an integral part of that experience. Do it, and I guarantee a positive outcome. Both teacher and student will leave better for the effort.

I’m Caleb Hicks, a 27 year old junior high teacher out of Utah. I’ve been a DevMountain student for the past 10 weeks, here’s what I’ve learned.

A Non-technical Junior High Teacher

I’ve been playing with technology for 20 years. I graduated from Game Boys, home-built PCs, and Geocities sites to smartphones, a Macbook Pro, and Wordpress sites. I read TechCrunch, The Verge, and am a seasoned Twitter user. I’m the guy everyone turns to when technology fails them. Sound familiar?

So to say I’m entirely non-technical may be unfair. It just depends on the context. Neighborhood barbecue? Technical. Startup Weekend? Non-technical.

Why a Coding Bootcamp?

My high school C++ teacher took a new job right as we started digging in. I had done really well in the class, but the program was shut down shortly afterwards. Without a teacher or mentor to continue learning from, my interests shifted elsewhere.

I sometimes wonder how my life would be different if I had kept learning 12 years ago. So when one of my friends got involved with DevMountain, a coding bootcamp based in nearby Provo, I looked into it and decided to take a shot.

I had a few big questions before I committed to DevMountain.

  • What would I be able to learn over 12 weeks part-time?
  • Would I be able to build something cool?
  • Would I be embarrassed?
  • Would it be worth the price?

Now that I’m almost finished with my 12 weeks, I wanted to answer those questions for anyone else who has the same.

What would I be able to learn over 12 weeks?

DevMountain’s goal is to get students prepared to enter the workforce as Junior Developers. The first rung on a tall ladder to proficient software engineering.

I was under no illusions. A 12 week part-time coding bootcamp wasn’t going to put me on the same level as someone who has dedicated years to refining her practice as a software engineer. But having worked hard over 3 months, I’m able to speak coherently and work alongside many senior developers as I continue learning.

Specifically, here are a few of the things that I learned during the iOS Summer Cohort:

  • UIKit. Putting labels, textfields, tables and buttons on the screen using storyboards and programmatically.
  • Data Persistence. Saving data between app launches using NSUserDefaults, Core Data, and network services.
  • Networking. Working with data through open APIs, accessing Twitter feeds, World Cup match info, or custom APIs using Parse, NSURLSessions, and AFNetworking.
  • iOS Frameworks. Mapkit. Message center. Location services. Push notifications.
  • Best Practices. Version control. Github. Unit testing. Project architecture. MVC. Pair programming. And more.

I am not a master of any of those concepts. But I have experience and exposure to every one of them and I can use them to piece together some pretty cool apps.

Think about what you can build on iOS if you can put stuff on the screen, save data, use network services, and command the iPhone’s capabilities for sound, location, or Bluetooth LE. All of a sudden ‘I have an app idea’ turns into ‘I have a cool project I’m working on’.

Would I be able to build something cool?

Once people heard that I was learning to make apps for iOS, I started to hear one phrase over and over again.

‘Hey, I have an idea for an app’

In mid-June, about halfway through the cohort, I heard the first idea that I thought ‘Cool, I could build that!’ So I did.

I want an app that only counts down my son’s piano practice time when he’s actually playing the piano.

My first app, Piano Practice Timer, went live on the App Store two weeks ago. It hasn’t been a smashing consumer success but it is a technical success. I built an app that recorded audio from the microphone, sampled it in real time, and counted down a timer if the sound was loud enough to be a piano playing. I built a persistent settings screen, with options for practice length, timer type, e-mail reports, and a feedback form. And I built it all from scratch.

Pretty cool for 6-8 weeks of experience.

Noise Timer for iOS

Would I be embarrassed?

When I first looked into DevMountain, I was worried I would hold up the class. That I would get lost and be that guy who asks the dumb questions.

Turns out, no one in the class was experienced. That’s why they were in the class! So there was no reason to worry about being embarrassed or slow. Those of us who put in the time and effort got a ton out of the class, and no one was holding us up. Anyone who puts in the time and effort will get as much out of the class as I did.

Would it be worth the price?

Anyone who’s paid college tuition is used to spending thousands of dollars on education. Thinking back to my college experience, this is much better. A few reasons: I’m more interested in the subject than I am about American History. The teachers are full-time developers working in the field. The small cohort was a better environment for individualized learning. I had two great mentors ready and willing to help. And the curriculum was project-based, so we learned by doing.

Before I applied, my wife and I debated if the tuition was worth me finding out if I enjoyed software development. And I can wholeheartedly say that it was.

What’s Next?

I introduced you to my first app earlier. I’ve spent the last month working on my second app. It’s called Wired In, a modern productivity tool for Mac, iOS, and your desk. I’ve built the iOS component with UIKit, Core Data, iCloud syncing, Parse, submodules, and Core Bluetooth to communicate with an RFDuino hardware prototype I put together.

We Are Wired In

It’s not quite ready to go yet, but I’m hoping to announce the app launch soon. That will be followed up by an announcement for the Wired In desktop sign, to let your coworkers know that you’re in the zone and to come back when you’re on a break. I’m thrilled with the feedback I’ve gotten so far on the app and sign. If you want to learn more or get an e-mail when we launch, check it out at We Are Wired In.

If you have any questions about DevMountain, the iOS Cohort, or my experience in a coding Bootcamp, send me an e-mail, hit me up on Twitter, or ask me to answer your question on Quora anytime. I’d love to hear from you.

My Background

I’m a teacher by profession. I teach business, marketing, and technology to teenagers in Lehi, Utah. I’ve run a few websites in the past, and done some Wordpress consulting on the side, but prior to this summer my only real coding experience was a C++ class in high school that went from awesome to painful when the teacher took an industry job midway through the semester.

I often wondered what different paths my life would have taken if that teacher had stuck around and I had continued to develop my embryonic programming skills.

With development bootcamps sprouting up around Utah, I felt like that would be the right way to catch a glimpse of my missed opportunity.

I enrolled in the Web Development course through DevMountain for my summer break, but when they announced the iOS Course and I learned that my good friend Joshua would be writing the curriculum for it, I jumped at the chance and transferred.

I had done some work that ended up in the App Store before. I founded Lift Media, a niche third-party ad network with Joshua in 2011. I also collaborated with him on a couple of apps in late 2011 and early 2012. But my contributions were always web-related.

Class started 9 weeks ago, and today my first app went live in the App Store.

Piano Timer - A Noise Activated Piano Practice Timer

The first 4-6 weeks of class were great. Hard, but great. The first and most important thing we learned was how to learn the iOS frameworks.

We worked on class projects, with great sample code and solution comparisons. We learned UIKit, data persistence, basic MVC, Core Data and networking. But what I remember most from those first weeks of class was learning where I could go to learn more and turn my ideas into code.

My first real experience building something extracurricular was building a simple little pomodoro app. It had started as a class project, but I built it up into a working pomodoro with project time tracking using Core Data. It was spaghetti code, and terrible, but I was proud of it.

I never released it (story for another post). But I was hunting for something new to build alongside the classwork. I asked around for ideas at a family reunion when three people told me independently that they wanted an app that would help time their kids’ piano practices. Not just a straight timer, but one that only counted down the time when the piano was playing.

My gut reaction was ‘not a huge market, but definitely an interesting project for my current skill level’. So I got to work.

Building the App

I looked around online, I learned how to sample audio from the microphone for specific decibel levels, I built my basic timer view, and I had a label updating with the current decibel values before I went to bed that night.

‘I’ll have this done in a week!,’ I thought. Naïvete at it’s finest.

I kept at it. Refining my Timer class. Adding a settings page. Persisting those settings for each launch of the app. Building my own Onboarding Controller and views. Adding reporting and timer options. Putting in hours of learning, experimenting, fixing bugs, refactoring, and then doing it all over again for each change and new feature.

After a couple of weeks, I had something ready to submit to the store.

The Value of a Boot Camp

A quick aside for a moment. As I’ve gone through the bootcamp, I’ve been asked if I was really learning how to code in 12 weeks. The answer is no. You can’t master programming in 12 weeks in a part-time night class.

The value of the boot camp is building a foundation, working with other students on the same level, having access to mentors who can help you along the way, and most importantly… spending your own time outside of class to hone and develop those skills. You get out of it what you put into it.

Let me say that again. You’ll get out of a bootcamp what you put into the bootcamp.

Don’t expect to show up, have the instructor’s words wash over you, and start cashing checks from your high paying development job. It won’t happen. You’ll get frustrated and drop out. I promise.

What About Swift?

I was sitting with a talented group of iOS developers when Apple announced their new programming language, Swift. Initial reactions ranged from wild excitement to soul-searching introspection. One of them said:

My entire career just got deprecated.

I wondered the same thing. I was 5 weeks into my fancy iOS bootcamp! Was it all wasted? Should I toss everything out the window and start over with Swift?


Swift is cool. I’m excited to do more with it. But Swift is the language for the next 30 years of Apple. The language of the past 30 years isn’t going to just fade away into irrelevance in the next 12 months.

As I’ve learned while building Noise Timer and my current capstone project… iOS development isn’t about the language. It’s about the frameworks. It’s about how Cocoa works. The language is an implementation detail. The most important things I learned still apply whether it’s Objective C or Swift.

App Review

Back to Piano Timer. I had the skeleton of an app that I felt was ready to submit to the app store. But as I got ready to submit I realized that I didn’t have an interesting user interface, a logo, an icon, or a written description for the app.

I was running out of time I could spend on this side-project app, because I needed to get to work on my capstone project. In a world where Delight is in the Details, I was hesitant to push it live without spending more time on the little things. But, real artists ship, and it was time to move on to my next project. So I quickly put together the missing pieces, uploaded them to iTunes Connect, and submitted the app.

That was about a week ago. This morning the app went into review, and without a hitch was processed to go live on the store.

I’m happy to present my first iOS app, Piano Timer. Check it out in the App Store.

So What’s Next

I’m nose-to-the-grindstone on my capstone project, which I will be presenting during Demo Night at the Adobe Building in Lehi next week. DevMountain has an Eventbrite page set up for it, it’s free to attend, and I’d love to see you there.

I’m not sure where iOS development will take me in the future. But I’m thrilled with my experience so far. I’ve learned a lot. Most importantly, I’ve learned that development is something I truly enjoy. And even though it’s 12 years after my first failed development experiment, better late than never.

If you have any feedback, questions about how I learned, DevMountain, bootcamps, or anything else, I’m @calebhicks on Twitter. I’d love to hear from you.