Tag Archive: developer

The Flow and the Ebb

I loved SXSW. I sat up-front center for as many sessions as possible. I introduced myself instead of vanishing after each session. And my presentation at the TechBreakfast there went great: I talked with dozens of potential users, validated my product idea, and met amazing people who I want to know for many years. I also allowed myself to enjoy serendipity. I kept returning to a Peruvian food truck because every time I went there, I met someone interesting.

Back in the NYC area, I’m completing a new course on GitHub basics and writing an intermediate course on GitHub gymnastics. I continue to sell my first course on programming concepts for true beginners. I’m speaking at a security conference in May on a topic related to my master’s thesis, and then plan to transform the thesis and the talk into courses as well. I’m continuing to build out my software, focusing on the open-source plugin and adding features requested by potential users.

And I keep doing things that scare me. My mission statement is to say YES when I’m scared and see what happens. So far I feel right about everything, even though I also feel uncertain about where the edge lies or what awaits me there. I remind myself that no one ever really knows what they’re doing, and as long as I’m adding value I’m doing okay.

FacebookTwitterGoogle+Share

What I’ve Been Doing

I spent February doing several things that are fun and also a first step toward fulfilling my Phase Two mission: Make useful things. (My Phase One mission was: Travel and learn.)

Programming in Plain English

I’m creating stand-alone software to let you program in plain English. I have a basic plugin version of the software working, which I’ll present at a SXSW TechBreakfast. If the fancier, fuzzier stand-alone software is also working well enough by then, I’ll demo that as well. It’s an iOS app and will also be a Mac app initially. Here’s a beta website for the project: Plain English Programming.

Short and Sweet Courses

I created a Udemy course called “Short and Sweet: Basic Programming Concepts in 2 Hours.” It was fun, frustrating and rewarding to create a two-hour course that presents the essential ideas of programming in real-world language, using pseudocode. The goal is to make it easier for students to learn any programming language after taking the course, and to understand good practices around program structure and refactoring. I’m happy with the end result (for now), I’m loving the ability to communicate instantly with my students and help them get past roadblocks and succeed, and I’ve made my first online revenue, which is exciting. The course is here, if you’re curious, and I’m including a coupon for blog readers: Short and Sweet: Basic Programming Concepts in 2 Hours

I’ve drafted an eBook to pair with the course and am planning my next courses in the Short and Sweet series. Initial feedback is that the concept is good: A Short and Sweet course will be the best, fastest, easiest intro to a topic — no oxymorons! I’ll be testing this premise some more and then launching my own course platform. Now that I have a course recording process down, it shouldn’t take me long to produce content.

Flashcard App Final Phase

I’ve hammered out many of the bugs in my flashcard app, which I plan to tailor as a study aid for each course I release. I’ll also release some stand-alone flashcard apps to help people study for various exams, starting with the NASM personal trainer exam, simply because it was the first test database I created for the app.

I have several other ideas swimming around in my head, mainly around how to help people learn and do more, better, faster. I’m really enjoying this phase of my sabbatical and will send updates. Apologies for the bat-cave moment on this blog, I know it was quiet here for a few weeks. I wasn’t sleeping :-)

Los Angeles, Again

Apologies for my absence from the blog for the past few weeks; I spent the time immersed in Udemy, getting my new course ready for publication. It’s submitted for review now, waiting only for an image before it gets set live. I’m super-excited and will let you know more when it’s released.

I’m spending the winter in Los Angeles.

I promised myself last winter, as I was freezing in my NYC apartment with the heat cranked up to max and my poor tree actually leaning away from the window to escape the polar vortex (who knew trees even DID that?), that if I actually went ahead and pursued this plan to travel and learn and find a new path, I’d spend the winter someplace warm.

I chose L.A. I’ve lived here before, for four-plus years in the early 2000s, and I know where to go, where to avoid, where to relax, where to hike. Most of all, I have friends here who I’m looking forward to spending time with, making the city feel more like a village hamlet or a reunion than a sprawling sprawl.

I’m already feeling the pull of L.A.’s unique rhythm, the blend of seasons into endlessness, the no-hurry mornings and the bright blue perfection, though now I am uniquely qualified to fight it with productivity. I spent the last seven years in New York, where busy-ness is a way of life, even when it’s fabricated.

I remember traveling around L.A. when I was working in journalism, wondering as I passed by cafes in the middle of the day, “Who are all these idle people?”

Now I am one of those people. But I’m not idle. In the past month I’ve doubled down on my (now-working!) Xcode plugin, signed up to present it at a SXSW breakfast, added new capabilities and started planning a standalone software product; created a Udemy course to teach basic programming concepts to would-be programmers, non-technical co-founders, and parents and teachers; and fixed major bugs in my flashcard app that were preventing progress. I’ve spoken with a lawyer about creating a company and am prepared to move forward.

I expect to launch all of these projects by the time I leave in March, along with an organic food finder I prototyped last summer. It’ll be an interesting couple of months.

Then I’ll see what sticks.

In the meantime, I’ll enjoy being productive in the midst of laid-back L.A. I’m also trying to get back on track with my organic, hack-your-health lifestyle, which I decided a few years ago was non-optional if I wanted to live an optimal life. It’s super-successful for me when I’m on-board with it, so I’m back on board and ready to enjoy my (non)-winter.

73 degrees. I love it. Lots of work to do.

GitHub Fails and Lessons Learned

I messed up my Xcode plugin yesterday. GitHub failed me, or rather, I failed GitHub. Then I fixed it and implemented better practices.

This blog post is an open, transparent attempt to share my mistakes and solutions.

For non-GitHub users, GitHub is sort of like Google Docs for software. It allows multiple software developers around the world to work together on software (relatively) seamlessly. So, if a software developer in Dubai makes a change, and another software developer in France makes a different change, those two changes can be merged into a single version of the software without significant hassle.

One Branch to Rule Them All

My first mistake was that I had only one GitHub branch: master. Initially, this worked well for me, because I used one laptop for development and pushed changes frequently from my local machine’s master branch to GitHub’s remote master branch.

Yesterday, I decided to push changes from a second machine, a test iMac with OS X Yosemite and Xcode 6 GM installed (for stability of the plugin, my laptop is still running Mavericks and Xcode 5/Xcode 6 beta. This turned out to be a good idea, at least until quirks are worked out).

Using the test iMac, I added the UUID (unique identification code) for Xcode 6 GM to my plugin. I did some limited testing (MAJOR MISTAKE) to verify functionality, pushed the code to GitHub’s master branch from the iMac, published a few more minor commits, and then pulled the new master version onto my laptop to make sure it also worked there.

Spoiler Alert!

The plugin did not work on my laptop. Previously functional commands produced no output. One command to create a for loop actually executed the Undo function instead! (If you’re not a software developer, just know that this is a bad kind of bug.) Most of these commands had worked fine on the test iMac.

Baffled, I decided to test every single command on the iMac (maybe I should have done this the first time, hmm?). I quickly discovered that with only one exception (of course, the one I’d tested before) my conditional-statement methods crashed Xcode. Some of the other methods that had produced no output on the laptop worked perfectly on the iMac. And entering slightly non-matching commands, which should produce no action, also crashed Xcode.

Clearly, my program now had crossed wires — and this crossed-wires version was the master branch on GitHub and the working version on my iMac and my laptop.

It was time to revert.

Don’t Cross the Streams

I researched how to revert GitHub commits. I wanted to roll back to a canonical, stable version that had worked with Xcode 5, and then go forward from there in a more measured way.

It turned out there were many ways to do this, many of which seemed complicated. The simplest way, doing a hard reset, was utterly bad practice (see: rewriting history) and I didn’t want to go there.

I found a Stack OverFlow answer that solved my dilemma. A poster there recommended doing this:

git revert –no-commit #######..HEAD (where ####### is the ID of the commit)
git commit -m “Commit message explaining what I just did”

This approach would revert all of the commits at once and re-create the state that had existed after the target commit. But it would not rewrite history by entirely removing old commits. Perfect.

Executing the Plan

First, in case something went wrong, I created a new branch with the old commit that I considered to be stable:

git checkout -b xcodestable #######
git push origin xcodestable

Then, reassured that I had a stable version stored on a separate branch, I switched back to the master branch and rolled it back to the old commit using the “git revert –no-commit” solution from Stack OverFlow:

git checkout master
git revert –no-commit #######..HEAD
git commit -m “Commit message explaining what I just did”
git push -u origin master

This seemed to work beautifully. But when I tried to run the plugin on my laptop, I encountered the same problems as before.

Into the Logs

Stymied in all other ways, I dealt with the situation I had in front of me and started logging messages to the console. I stepped through each process to see where things were going wrong.

To my surprise, the main problem appeared to be that many commands, after detecting the correct start point, were jumping into a method that adds items to an array. That method started with the word “Put “.

I had added case insensitivity to the plugin recently. That meant any text containing “put ” also would trigger the add-items-to-array method. For example, if the word “input” appeared anywhere in the code or comments, that would be a trigger. Whoops. I wasn’t sure why the case-insensitivity feature had worked perfectly when I first implemented and tested it, but it was breaking now.

I cleaned that up by making the command start point more specific (“Put item “) and built the program again. This time everything functioned. I tested every piece of functionality and then pushed it to the master branch:

git add –all
git commit -m “Functioning version”
git push -u origin master

Since everything was working, and the prior “stable” snapshot actually had not functioned correctly, I created a new stable branch from the functioning master branch:

git checkout -b xcode5stable2
git push origin xcode5stable2

Then I deleted the old, non-stable-after-all snapshot branch:

git push origin –delete xcode5stable
git branch -d xcode5stable

On to New Frontiers

At this point, the master branch functioned on my laptop and I had taken a snapshot (branch) of this stable state.

I still wanted to update the plugin for Yosemite and Xcode 6 GM functionality.

Unlike the last time, I decided not to do that on master. I created a new branch for testing new functionality, with the goal of merging it into the master branch once it verifiably worked on Mavericks and Yosemite:

git checkout -b newyosemite

Using the laptop, I opened the plist file as source code and added the Xcode 6 GM UUID. Then I built, re-tested every piece of functionality on the Mavericks laptop, and then pushed to the newyosemite branch.

git add –all
git commit -m “Now compatible with…”
git push -u origin newyosemite

Next Steps

The next step is to test this seemingly functional version on the test iMac with Yosemite. I’ll do that this weekend. I’m not sure if it will work, but I believe I found and fixed the major bug behind the wacky, unpredictable functionality. I also think I figured out what is causing another bug and have several ideas on how to make the code more robust.

My major takeaway is that no matter how small a project, better Git/GitHub practices are worthwhile. Specifically:

  • Preserve stable versions before major changes in a separate branch;
  • Make new changes in a separate branch before merging those changes into master; and, possibly most importantly:
  • Test ALL pieces of functionality before pushing or merging anything to branch master. Don’t just do spot tests.

 

Sabbatical Phase 2: Coworking and Bootstrapping

As I gear up for Phase Two of my adventures, I feel pulled in different directions. My primary goal is to make things that are helpful, useful improvements to the world. I’m conflicted about how and where to do it, specifically whether to try coworking, and how to bootstrap/fund until those things either succeed or fail.

Dilemma 1: Where to Work

On coworking, I’m an introvert. I enjoy meeting people, but a day in a noisy space leaves me needing to rest and recharge. I do my best work in focused, productive bursts, either alone or with a small team of people. (I’m also good at political wrangling and large meetings, but that skill is less useful for my current activities, at least right now.)

I’m not sure I see the benefit of paying money to sit in a noisy space that saps my concentration and energy.

Fortunately, I have alternatives. On Thursdays and weekends, I can visit the Hacker School space. This space is special: It manages to be quiet and focused for much of the day even while full of people, which astonishes me but also makes me extraordinarily grateful. As a bonus, it’s a great place to find lunch or dinner partners for non-work breaks.

Tomorrow, I’ll be trying free space donated by an incubator for Hacker School alums to continue working on cool projects. I love this idea and look forward to seeing how it goes, especially because it requires one-day-at-a-time sign-up rather than an ongoing five-day-a-week commitment.

About the only thing I don’t gain from these spaces is a permanent “home” for my work. What I would pay for is a service that provides office trappings without actually being an office. Things like a non-P.O.-box mailing address, faxing, copying and printing, supplies like envelopes and a receptionist and phone numbers (which I could forward to my cell phone), with conference rooms rentable by the hour for meetings. But no work desks — I could take care of that part by going to quiet-ish coffeeshops or working from home, wherever home is.

Does anyone know of a service like this?

Dilemma 2: How to Bootstrap/Fund

On the bootstrapping/funding side, I could continue without focusing on money at all — and it’s been a blessing to do that for the past six months at Hacker School and while traveling — but I feel like that might be short-sighted. I can extend my options if I earn money by freelancing, consulting, investing, fundraising or seeking fellowships.

One thing I don’t want to do is become too focused on making money at the expense of actually doing things and making things. So I’ll need to find the right balance, and that will be a process of trial and error. Ideally, some of the things I do and make will become sources of income and possibly allow me to raise funds or get fellowships. But I don’t want to force an outcome; I want to experiment, make useful things, and see what sticks.

I suppose I have a sabbatical bucket list. If I do a self-check, I’ve done some interesting things so far (though not all of the things on this list). Travel to places I’ve never been. Attend Hacker School. Make YouTube videos. Write a blog. Write an eBook. Make apps and plugins. Make websites. Make training courses. Be an e-tutor. Speak up on Twitter. Present at conferences and meetups. Attend different types of conferences. Try crowdfunding. Make or contribute to some real-world products.

This list sometimes makes me feel disorganized or scattered. But if I think about my mission statement, it’s pretty clear:

Experiment, make useful things, see what sticks. Keep doing the things that stick. Be myself and see what happens.

Hacker School Gratitude Journal

I’m grateful for everything about Hacker School and this summer.

I’m grateful for the people who made this experience possible. I’m grateful for the programmers who shared their knowledge and welcomed me to share mine. I’m grateful for the friends I made, and the hours I spent in deep concentration, and for the fact that these two things were not mutually exclusive.

I’m grateful for the chance to attend this magical place.

I’m grateful for the community that extends beyond Hacker School and makes the motto, “Never graduate,” a real thing, so I can keep growing and learning and sharing and participating in different ways over time.

I’m grateful for idealism winning out over realism, and making reality more ideal. I’m grateful that my Xcode plugin worked. I’m grateful that I didn’t overthink the idea before starting to try to figure it out. I’m grateful for the help I got from people in and around Hacker School. I’m grateful for brainstorming sessions, the comfy couch to sit on, the amount I’ve learned, and the feeling of being surrounded by lots of motivated, curious people.

I’m grateful for the lovely apartments I had to stay in, the noise of trains over the Manhattan Bridge reminding me that things are always moving and shifting, reminding me to keep pace and keep pushing and change things.

I’m grateful for my roommates and the wonderful experiences I’ve had with them, and I’m grateful that I took the chance to push out of my comfort zone and into the world of adjusting to others. I’m grateful for the occasional privacy that balances out my experiment in living more cooperatively and nomadically.

I’m grateful for the awesome people in my life, and for serendipity.

I’m grateful for my health. I’m grateful for the great food I eat every day and the opportunity to try anything. I’m grateful for New York City and its never-ending options, and I’m grateful for my ability to focus.

I’m grateful for persistence and creativity, which are only good together and have allowed me to do all of this — everything I’ve done for the past few years, leading me to this point of creating and exploring and learning and enjoying the world.

I’m grateful for the tough weeks and the easy weeks and the mistakes and the things done right, and the amazing summer that all these things combined to create. I can feel that I will look back on this summer with utter thankfulness, probably when I’m tired and stressed-out and working hard and struggling to sleep enough. So I thought I’d start now and say

Thank You.

Hacker School, Week 9 Postscript

I can’t believe week 9 of Hacker School just ended. Because of varying start dates for different Hacker School batches, batch lengths can vary. My batch is 11 weeks long, not 12, so week 9 is pretty far toward the end.

I’m learning a lot. I feel like I’m on a march to get as much done as possible in the time allotted, though I know this is an artificial deadline. I’ll keep learning the next day after Hacker School ends, and the next, and the next.

Granted, I’ll be learning in a hammock on a farm in Italy, which will be a nice change of scenery and pace. Instead of going out for dinner when I’m hungry, I’ll pick tomatoes and bake some organic bread.

But I still feel pressure about the upcoming end of the batch.

One of the great things about Hacker School is its open-ended nature. “Never graduate” is their motto, and they mean it. I’ll still be able to visit the Hacker School space on Thursdays, nights and weekends after my batch ends, and I’ll be able to attend Monday night talks, which means I’ll continue meeting great people whenever I’m in New York.

But I won’t be in Hacker School. I’ve loved this experience for the pure learning-friendliness of it, and I’ll miss the feeling of shared focus. I don’t feel quite ready to leave, but at the same time it will be nice to find out what “post-Hacker School” means for me.

I’m putting together some lessons learned that I’ll post when I’m done and on my way.

Hacker School: Week 7

I’m in the second half of Hacker School, feeling short of time and not sure what to do about it. My only option is to keep showing up every day and getting things done. I sit at a long table in a huge room or abscond to my personal favorite work space, a living-room-like corner with a high ceiling, a metric ton of computer books, and a metal staircase leading up to a door that doesn’t open.

On a beanbag or couch in this corner, surrounded by books and people hacking on projects and a robot mural painted on the wall, I feel equally at home and unsettled.

After focusing on C for two weeks and then an Xcode plugin for a month, I’m switching my “learning” focus to JavaScript and node.js. I’m using the excellent Learn JavaScript Properly outline suggested by Richard of Stanley, and so far it’s going well.

Turns out I like JavaScript. A lot.

This is sort of a surprise to me, because I’ve heard JavaScript is weird. Inconsistent. Unreliable, even.

But I resonate with the C-based parts of the syntax, and it’s helping me understand the function-based parts that aren’t quite the same as Objective-C’s classes and methods. I’m learning from a solid base. And that’s reassuring.

I also feel like I can eventually build almost anything with JavaScript, and that’s motivating. I don’t feel like I’ll need to learn it for six months before I can do anything useful.

My “building/maintenance” focus remains on expanding and extending the plugin, so I have two tracks to switch between. This is my best mode of working, because even procrastination can become productive — if I get tired or burned-out on one thing, I can switch to the other. It also ensures I write code consistently and don’t get bogged down in only book-learning.

I’ll write a full-on technical post about the plugin soon.

Day 89: Victory

I cannot begin to describe how happy this makes me:

Terminal output from Xcode voice recognition plugin

And this:

Xcode voice recognition plugin

I went back to the voice recognition plugin. I thought about it differently. And it works.

It’s not perfect. Far from it. But the key bottleneck is broken. This basically means everything I want to build, from a functionality perspective, I’ll be able to build.

I’ve never actually experienced this in coding before. I always just had someone help me through the hard parts, which was good for productivity but meant I never really learned to work through a tough problem in code. It’s awesome.

Referencing the “Day 89” in the title of this post, it’s Day 89 since leaving my job. Day 31 of Hacker School.

Things Accomplished versus Distance Covered

I’m in week four of Hacker School.

It’s awesome. But I’m struggling with a dilemma: balancing the tough problem and the maximum ground.

I view Hacker School in terms of two metrics: Things Accomplished and Distance Covered.

Of course I want to accomplish some things. I have a whole list of things I want to accomplish, some while at Hacker School and some afterward.

But the whole point of doing Hacker School, for me, is to learn the maximum possible amount in the time given, so that I become a much better programmer for whatever comes next.

This means I also need to keep an eye on the Distance Covered.

It doesn’t mean I will abandon tough problems forever; but it does mean I don’t want to spend the entire 11 weeks on one problem without any guarantee that I’ll solve it in that timeframe.

Asking the Right Question

So I’m forced to balance things. The right question is not, “How long will I spend on a particular project?”

The right question for me is, “Given the rate of progress I am making, the amount of code I am writing, and the amount of learning going on, how long will I spend on a particular project at Hacker School?”

That’s why I’ve decided to set the voice recognition project aside for now and continue forward with my Hacker School plan by turning my attention to Swift for the next two weeks.

But I Love Tough Problems

I wasn’t too happy about this decision, because my experience has been that the projects and problems I delve into tenaciously and refuse to let go until I’ve figured them out always produce my greatest successes and joy. It was true with high-speed trading risk controls at my prior job. It was true with health issues that I defeated.

But those projects take years, not weeks.

I don’t have years at Hacker School. I have time to learn a lot about a lot, meet and enjoy working with great people, and build a base for tackling the really tough problems afterward.

The Nights-and-Weekends Compromise

I discovered that the voice recognition project is 100% doable — it just requires a lot of work. More work than I have time to dedicate to it at Hacker School.

So, my compromise is to make it a nights-and-weekends project, while spending my time in the Hacker School space completing my Hacker School plan.

That means Swift for the next two weeks and then a shift to JavaScript and node.js.

Meanwhile, I’ll be mulling the voice recognition project in my spare time, which is probably the best way to tackle tough problems that are at an impasse. I will figure it out. But I will also accomplish other things and cover the distance.