I was sitting at the airport in wayward Detroit the other day, waiting for my early am flight to SF – on the way to start another new chapter. As I sat there thinking about what’s ahead, I was reminded that it’s been a year since I left Babson, the comfort of a traditional path through college, the often unary transfer of knowledge in the classroom, and a circle of close friends who I miss dearly. I’ve traveled tens of thousands of miles, lived in three major cities, worked with a number of brilliant people - some of whom I’m fortunate enough to call mentors, all of whom I’m beyond thankful to have met - and most importantly, have spent these twelve months learning more, personally and professionally, than I could have possibly imagined.

I took a series of calculated risks, often times without an expectation for a particular outcome.

Most of us take risks each day – sure, some are larger than others, but this habit is largely intrinsic to each and every one of us, even if we don’t make a conscious effort to recognize it. Most risks taken are done so with at least some thought given to tradeoffs and potential outcomes. But some aren’t. Some are calculated with very little to no thought given to an expected outcome. This is what differentiates a small minority of risk takers from the rest.

Some might think this is foolish  - I would disagree. I argue that college is one of the lowest-risk environments we will ever find ourselves in – a point that affords us the luxury of not always knowing or caring about the expected outcome of a risk taken. This leads me to a conclusion:

I am returning to college in the fall as I will be able to effectively extend this comparatively low risk environment for one final year.

I was able to help start the Boston Startup School (now Startup Institute) in Boston, work with Passion Capital and their portfolio companies in London, and finally learn to code in San Francisco because I had a year’s worth of credit from AP courses and college coursework completed in high school (and because I was fortunate enough to have an overwhelmingly large amount of support from my family). Some would have studied abroad for a year – I just decided to take a few more risks than most. And I took those risks because I was still “in college.” In other words, if everything fell to shit, I could have returned to school, no harm no foul.

I’ve had a number of people ask why I’m even considering going back. And sure, I think it’s a valid question: with this much experience, especially with a burgeoning technical background that opens many more doors in the startup world, what value does finishing my final year at school hold?

So for the sake of argument, let’s assume I were to drop out. What would I do? I could build out a prototype of some product, maybe pitch it in front of a few folks, maybe raise a small angel round. Say I do that and six months down the road the product is a failure. Now what? Can I get hired at a startup? Maybe. I could also find a job at a startup. Cool – more learning, more experience. Say I do that, the company fails a year later or I want a change, and now I have to go job searching. Will I be judged for not having a college degree? Probably not, but is it worth the risk? Because remember, I’m no longer in the lowest-risk environment anymore – I gave that up to start a company or start work one year earlier. Is this trade off worth giving up a year of college? And as I’ll be making a major decision that could potentially keep me away from that low-risk environment, I can no longer rationalize taking major risks without carefully weighing the costs and expectations…

For me, it’s not worth it. I will return to school and take advantage of the lowest risk environment I will ever find myself in. I will continue to learn to code. I will continue to build out projects I find interesting. I will learn from these projects if they succeed, and I will learn from these projects if they fail. I will continue to write about my experiences. And most importantly, I will take the largest risks I can find, knowing that failure will result not in homelessness, but in knowledge.

 I’ve talked about my sincere desire to learn selfishly – an even more exciting notion when you can take big risks – and I hope I can continue to glean knowledge in this manner back at Babson. I’m looking forward to spending my final year at school with friends, celebrating some milestones, and most importantly, learning as much as I possibly can so that when I do finish school, I will be in the best possible position to take risks while optimizing for success.

I started off my time in SF writing religiously about some of the more prescient learning points of my apprenticeship with Kyle Bragger. As time wore on, I got busier, became a part-time ski bum on the weekends, wrote more code than I ever dreamed possible, and wrote less frequently. I found writing  weekly round-ups to be a really useful way of capturing some thoughts during the week, highlight things I wanted to share with others, and generally reflect on my journey to learn Ruby/Rails. My last round-up was published on March 25 - wow. It’s time for a final recap.

April was an interesting month. I spent a large portion ramping up on Rails. I built a host portal for the bus company in SF/Lake Tahoe that I worked for on the weekends. I also built a small webapp called Clip.It that allows folks to “capture the soundtrack of your memories.” And I began work on another project whose goal is to encourage folks to express gratitude to their true heroes (this one’s still in progress). And most importantly, I finished the last month in my apprenticeship.

So as I transition to a summer engineering internship at One King’s Lane, I wanted to share a few quick thoughts in no particular order on some things I’ve learned over the past few months under Kyle’s tutelage.

• A schedule is an essential part of learning something largely on your own. It doesn’t have to be anything fancy, just something that will help frame how you’ll spend your time and hopefully keep you moving forward.

• There is no better feeling than building a product and being able to play with it live and in the flesh. Well…except for maybe seeing others play with it. But point being, for those who have always had ideas, but lacked the technical chops to see them to fruition, start learning.

• Learning things on your own is damn hard at times. Knowing where to seek out answers (e.g. language docs) is almost always part of the learning process, and will more often than not distinguish the person who succeeds, from the person who gives up.

• Learning things on your own is damn hard at times. Knowing how to get unstuck - be it writing a blog post, taking a walk, playing a game - is super important to help shift the load on your conscious brain to your subconscious. It sounds meta (and it is), but giving your brain the time to think through a problem can often reveal a solution not hitherto thought of.

• A network of near-peers and mentors has made learning to code a much more achievable goal. There have been countless occasions over the past three months when these folks were able to help me work through roadblocks - some complex and others embarrassingly trivial. Think of it as an educational support system.

• You can only spend so much time reading about code. Ultimately, you have to write code, write some more, refactor, write even more, refactor, write some tests, and ship. Then wash, rinse, and repeat. I’ve found that the process of building this third project has been easier in certain ways - something that building two other projects beforehand has allowed.

• Fortune favors the programmers who can ship code. What I mean is that you shouldn’t be paralyzed by ideas of features to implement, colors to change, code to refactor etc. As long as the project is functional and not too buggy, it should probably be put out in the wild. I mentioned this belief in a technical interview I had for OKL, and believe it helped me along in the interview process.

• Be open to, and embrace, change. I didn’t come out to SF thinking I’d be heading down the engineering path. But lo and behold, I’ll be spending the summer as an engineering intern, and have since recalibrated my career aspirations moving forward.

• Take the time to meaningfully thank the people who have helped you learn, grow, and succeed. Personally, my favorite expressions of gratitude include: handwritten notes, German beers, and thoughtful conversation.

This was an incredible learning experience. I would highly recommend anyone interested in pursuing any field that requires a certain skillset (whether it’s technical or nontechnical) to try and find an apprenticeship that will provide that type of unique and meaningful knowledge.

Thank you John G - for being the most giving roommate and putting up with my incessant amateurish questions, and thank you Jake - for being a super supportive roommate, and also for putting up with my loud banter & unintelligible vocabulary.

And lastly, thank you again Kyle - without you, none of this would have been possible.

tl;dr check out ClipIt

While in London last fall, I spent a weekend touring Amsterdam with an eclectic group of European friends. We captured this weekend of banter and debauchery with our eyes - in photos that would later wind up on Twitter, Instagram, and Facebook, and our ears - in the sweet melodies found on Kendrick Lamar’s newest album. And what we noticed is that we would often remember those memories captured in photos, when listening to a track from that album. Think about a tune you listen to every day - what sort of memories do you attach to it?

The mind has an extremely powerful capability to make those connections between sound and visual memory. We wanted a way to help record, catalog, and save each of these “clips” - this static photo with a dynamic, musical pairing. And thus the idea for ClipIt was born.

Clip.It allows folks the ability to sync photos with the music that accompanied them, thereby capturing the soundtrack of their memories.

While other services exist that do something similar, I like to think that ClipIt is a much more introspective way to accomplish this goal. It is less about sharing and more about reflecting. By themselves, photos are easily shared amongst friends - participation when the photo was taken: not required. But when linked with music, the photos become much more personal to the individual(s), as they represent a specific memory or point in time.

I’ve had an absolute blast building this project out from the idea stage to a functioning version 1. I don’t imagine that this is what the complete version is, but it’s something that works, and more importantly, something I’ll be able to use to capture the soundtrack of my 21st birthday next weekend ;)

A special thank you to my mentor Kyle Bragger for his incredible help with my second project - from his design critique to engineering perspective, I could not have done this without his help.

PS: In another post later this weekend, I’ll be writing a bit about how I’ve thought about the UI/UX of the product and what sorts of tools I used to help implement things.

It’s been awhile since I wrote a weekly round-up. I’m not entirely sure why that is. Sources point to a lack of self-accountability - that’s been an area of struggle since I’ve arrived certainly, but at least it hasn’t been too much of an issue when it comes to sitting down and writing code. And with that in mind, this isn’t going to be a weekly roundup, but a quick overview of the first real web app I’ve designed, built, and shipped.

tl;dr - check it out here - but be warned it’s probably not going to be useful for you…

The Why: I have a part-time job here in the Bay Area with a bus company (Bay Area Ski Bus) that does tours to Lake Tahoe. Fortunately, most of weekends were spent as a host on trips to the various mountain resorts a nascent 3 hours from San Francisco. Checking guests in, registering new folks to trips, accepting payments, and my favorite responsibility: pouring beer and manning the bbq, are all part of the job description. I built this host portal for the company to automate the portion of the hosts’ job that is currently dealt with on paper - namely, guest registration and check-in.

The What: John - my gracious roommate and fellow tour host - came up with the original idea while we were on the chairlift one weekend (Northstar, was it?). We talked through what the app needed to do, and I posted up at my favorite coffee shop the next day, drew up the mocks, and implemented the front-end in a half hour using Zurb - Foundation (good shout Jacob!). I then spent the next five days building the back-end portion. As this web app isn’t useful to the gross majority of folks out there, I’ve included screens of the various parts of the site to illustrate what I’ve built.

Homepage

New trip:

Guest Check-in:

New Guest Registration:

Stripe Integration:

Kyle and I had chatted earlier in the week about how it’s important for aspiring developers to be constantly building a toolkit to draw on in various projects. Here’s what this project consisted of:

• Zurb Foundation front-end framework
• File uploads & CSV parsing
• Using select forms
• Integrating the Stripe API

A special thank you to Kyle Bragger for consistently being there as a fantastic mentor to help me with implementation and debugging, and to John Gesimondo for being the roommate who never fails to help another roommate.

Just wanted to drop a quick piece of advice for those still getting familiar with GitHub/using a version control system - as well as those using the Paperclip gem from the awesome folks at Thoughtbot. For this week’s project, I’m building a simple way to share “clips” - that is a snippet of a memory, involving a photo & a song.

Using the Paperclip gem, folks can upload photos…and therein became the problem when I wanted to push some test clips (photos included) to the repo where this project is stored. I got this cheeky error while sitting in the Minneapolis airport yesterday: 

error: RPC failed; result=22, HTTP code = 411

fatal: The remote end hung up unexpectedly

fatal: The remote end hung up unexpectedly

Everything up-to-date

A WTF moment for me certainly. Until I started googling around (a useful skill as a burgeoning developer) and found this useful question - turns out uploading pictures is literally a big undertaking. So I changed the limit to a number of bytes (10000000000) that would allow the request to be processed and the code to be pushed. And voila - I was golden. Keep this in mind when you’re submitting large HTTP requests!

Solution:

git config http.postBuffer *bytes*

In an environment that is far less structured than a traditional academic or work setting, coming up with a proper and regular routine for work and personal activities has been useful in maintaining great progress month over month. I’ve found that it helps me continue to deliver on some of my smaller goals while here in SF - going to the gym regularly, making time for reading & writing, having a few coffee meetings here and there - but is also just as crucial in keeping me honest about spending the bulk of my time learning to code - which is why I’m out here in the first place. I like to think that a great routine doesn’t necessarily create stability and productivity, but instead clears the path to reach these constructs.

But just as a great routine will make it super easy for you to lead a challenging yet fulfilling lifestyle, a sense of complacency will make it exceptionally difficult to sustain such a lifestyle. So it’s a balance of recognizing the role a routine can play in your life, but also being aware that doing the same thing over and over, month after month, will make you want to bash your head against the wall.

And I think that was the point I was nearing last week. Things have been going really well out here, with a few exciting developments that I’ll be sharing over the coming weeks. But all that in mind, I somehow couldn’t shake this feeling of underachievement, disappointment, and procrastination that began to plague my daily thoughts. So I decided to switch it up.

Instead of getting up in the morning and heading directly to the gym, I spend some time to brew a cup of drip coffee and reflect with no interruptions for ten minutes or so - I highly recommend doing this, as thinking clearly helps set the tone for the rest of the day. I’ll then do an hour’s worth of work, and only then will I head to the gym. The rest of my day looks largely the same with a few smaller but more frequent chunks of coding, and slightly less writing. This small change in my morning routine found me much more energetic, happier, and generally super productive.

I try to optimize for small wins at the beginning of the day that help me keep focused and energized as I move onto some of the larger goals later in the day. I think it’s all too easy to accept feelings of dissatisfaction and lack of energy, dismissing them as “just a mood” or an “off week,” without being proactive enough to see if there’s any change a little active participation and effort can affect.

So the next time you find yourself lacking the motivation to feed your fish, brush your teeth, go to the gym, or write that paper, think first about your routine and whether switching things up might not help get you back in the zone.

How have you changed up your routine for the better? Let me know in the comments below and I’d be humbled if you followed me on Twitter (@jcap49).

I’m hard at work yesterday, putting some finishing touches on a new fingerpainting, when my phone buzzed and I got a text from an unknown number. Shit - it wasn’t the artist-turned-model French woman I met the other night over a glass of Bourdeaux. it was a text from “Luke” (his actual cell phone number in parentheses and a generic call to action of sorts. Ah - this is an invite to check out some new messaging app.

I’m going to avoid the fact that this is an invite to check out yet another messaging app, and instead focus on the user experience side of things, since that’s what I’ve been spending a lot of time recently learning about. And not just the “user experience,” but the “(potential) user experience” - because I, the recipient of the text invite/advert/call-to-action/whatthefuck, am not even an actual user of the service yet.

1. “Who’s Luke?” - Clarity || Understanding == Trustworthy - So as it turns out, Luke is my awesome cousin who lives in Portland. It took me literally thirty seconds to figure that out. I have no fewer than 5 Lukes in my phone, none of whom I’ve managed to memorize the phone number associated with that entry. Including only a first name as an identifier on an invite was a poor choice - the more time I have to spend thinking about who Luke is, the less likely I am to care about, let alone even consider checking out, the app advertised in the message. More importantly, I found this put me on edge, making me feel a bit uncomfortable, and ultimately trusting the message a bit less.

2. “Did you hear about hike?” - Generic || Impersonal == Untrustworthy - A few things that I noticed about the body text. Firstly - “did you hear about hike?” - as a question, this makes me think some poor fellow named hike (because who actually capitalizes names in texts anymore) had something rather unfortunate happen to him. Instead, the message continues by referring to a new app - cool - which clearly makes “did you hear about hike?” disingenuous. I think “have you heard about hike.in - a new messaging app?” makes more sense in this specific context. And above all else, the copy here is generic at best, gimmicky at worst. In short, it’s impersonal and, again, makes me less likely to click through and doesn’t do anything to make me trust the service any more than before. I’d consider giving users the chance to customize the message here (and maybe they do - haven’t downloaded the app to see if this is the case). But since I finally figured out who Luke was - and because I trust him - I clicked through the link…

3. Many clicks to…app store? Eventually, I was delivered to the AppStore, where I imagine the ultimate objective was to get me to download the app because my friend had sent me this generic invite that I don’t like or trust for the reasons mentioned…right. Sure, makes sense…but it took 4 clicks and a few distractions along the way for me to finally get there. Some of the distractions - namely the modal to redirect from iOS Safari to the native AppStore - are presumably required by Apple. But others - I’m looking at the unnecessary extra step of prompting me with the phone number (which I already had saved - and if I hadn’t, still wasn’t the goal of me clicking through…) and the link to http://hike.in (which then, for some strange reason, was treated as a contact - not sure if that’s an iPhone thing or a bug with this specific app). Lots of hurdles to the AppStore - each an opportunity for me to say “I’m outta here” and not download the app. I’d want to streamline this process as much as possible - starting by first taking out the hyperlinked phone number.

Nir Eyal wrote a piece on viral “oops” - the little hooks that web or mobile app developers build into products to help encourage (hyper) growth. But what differentiates the products that will grow virally, organically, and above all else sustainably, are the ones that don’t build in deceptive practices like the above.

Just a few top-of-mind thoughts. Would love to hear your thoughts/criticisms below or on Twitter (@jcap49)

This conversation isn’t new by any stretch - Fred Wilson and Mark Suster have covered the topic extensively from a business perspective.  7 weeks since the start of my apprenticeship have gone by, I’m now implementing the mockups for the front-end of my project, and this conversation has started to become relevant for me. So I want to share some thoughts on what how this argument applies to designing the product.

Since I’m learning design/front-end development as I go along, I wanted to start with the native web implementation (a bit easier) then work on adding the responsive web portion that would allow the site to render nicely on mobile. That said, I wanted to share a few learning points for others in a similar position.

1. Determine on which platform your product might function best. There are certainly others more qualified than I am that have written about this decision making process. See the above links for a place to begin. Have that argument internally or with other folks, make a decision, and go.

2. Sketch mobile AND native web mockups. If you’re keen on building a product that functions properly on web and mobile (mobile-optimized browsing that is), sketch out the chrome and layouts for both versions.  I learned this one the hard way, having only sketched out mocks for the mobile site - not the native web. It’s simple - the more time you spend sketching, the less time you spend coding and implementing. Be cognizant of the order you’re implementing the versions - probably best to build first the one you think most will use, unless you’re just starting out.

3. Framework vs. your own stuff. There’s some healthy debate to this one. Some argue that frameworks (like Bootstrap or Foundation) are super helpful for folks just starting out - less confusion, more polish - this is true. But what you’re lacking by using a framework is the ability to truly start learning and understanding HTML/CSS/other front-end languages and their quirks. And more importantly, you’re lacking the ability to get a feel for whether or not front-end dev/design is your bread and butter. I’m implementing the front-end for this project without the use of a framework - it’s taken me significantly longer to do so, but I think it’s been a much more valuable learning experience.

Happy coding! Let me know if you’d like greater detail on some, or all, of these points. Hit me up on Twitter (@jcap49) or in the comments below.

Back at it. Things are getting real. It’s hard to believe I’ve been here for 7 weeks. Woah.

This week I…

• started to implement a few mock-ups in HTML/CSS/ERb.

• had a successful first design review; lots of learning around layouts, affordances, color palettes, and the psychology behind user actions.

• began building out the backend, writing a few controllers and models to be fleshed out over the next two weeks.

• began going through the Hack/Design lessons. Highly recommend checking them out!

Any blockers?

• my eye for design or lack thereof…

What’s next?

• finish the front-end implementation this week.

• begin building out more of the backend, specifically relating to photo upload/storage.

• continue the search for summer gigs.