MakerSquare Day 54: Wherever you go, there you are. And your code is there too! (12/1)

We're coming down to the wire here. And as much as I want to look up where that phrase comes from--something about horse-racing, maybe related to a photo finish? or maybe something related to barbed wire and trench warfare in World War I?--I feel a little too busy.

I would love to slow down a bit and tell you all the stuff I'm learning and trying. "Learning" includes a lot of trial and error, so I'm learning a lot with my final projects.

Of course, one of the things I'm learning a lot about is me. (Also: Rails and Foundation.) Which reminds me that, a few weeks ago, while the full-time MakerSquare students were filing out and the part-time students were filing in, I made a joke of the form, "I thought I was learning about JavaScript, but I was really learning about myself."

(If I had had more time to think about it, I might have gone with a Russian reversal joke: "In America, you learn about JavaScript, but in Russia, JavaScript learns about you.")

Besides getting a laugh (which is the point of jokes, right?), it seems that I might have accidentally said something truthful there (which is the real point of jokes, right?).

I mean, working on final projects is a reminder of everything good and bad about yourself. I like working in teams or at least talking through ideas with other people. (Brainstorming for other people is one of my favorite things. What do you need? A title? An app idea? A villain for your superhero RPG? Whatever it is, I want to brainstorm with you about it.) So working on a project all by myself--not my ideal situation.

Similarly, I love doing research before attempting something; but, at least in this situation, I've learned a lot by just getting in there. As I learned as a kid, breaking something is one of the best ways to learn how it works and how to fix it (and how to run faster than my older brother). So that day that I spent reading the docs for Foundation wasn't any more helpful than the hours I've spent wrestling with putting that into practice.

MakerSquare Day 53: Incremental (11/5)

I named this blog "Incremental Code" for the best reason of all: brand consistency. Either that or a lack of ideas.

See, my other blog--the one where I talk about movies and books (mostly)--is called Incremental Catastrophe. Which is a name I chose years ago to capture that feeling of sudden and irreversible upheaval happening very slowly.

So when I started this blog to focus on my MakerSquare time*, I went through a few ideas about what to name it before deciding that "Incremental Code" was, you know, good enough.

Which is how I've discovered that "Incremental Code" is the perfect name for a blog about coding for me.

MakerSquare's program is accelerated; and there have been times when my knowledge of these issues has gone up sharply. And there have been times when I've felt my knowledge increase barely. But if you were to draw a line of my learning, it would, overall, average out to a very reasonable, incremental increase.

Which is, coincidentally, how I would describe my coding process. Sure, there are times, usually in the shower or when falling asleep, when I am hit by sudden inspiration about how to solve some problem.**

But most of the time, I get the work done by sitting in a chair and doing the work. (That's a lesson I take into coding from my time working on fiction.) You move the code forward every day; and even an incremental process can result in a big step forward.

*Note to future MakerSquare students: writing every day may not be for everyone. But I would set yourself some schedule and stick to it. If you say, "I'll just write when I have something to say," you'll never write.

If you say, "I will write every week to summarize what I've learned," you'll find--magically--that you do have something to talk about every week. It's almost as if--as if!--putting your butt in the chair and getting to work can be productive and inspiring.

**Of course, that sudden inspiration only happens because I've been steadily working on that problem before the shower/sleep. Again: incremental.

MakerSquare Day 52: Ask and ye shall receive, time permitting (11/4)

I'm inspired by this recent week, when I really worked on my skills in one particular area: asking questions.

See, I've always been of the "let me try this for myself" bent. And I still am; but when it comes to web development, I've gotten better about setting myself a time limit. "Let me try this for myself--for a half hour."

And when that half-hour is up, I go find a peer or an instructor to talk through the issue. Thanks to that half-hour I spent, my questions are less  like "Help!" and more like "I'm trying to do X; I've already tried methods Y and Z and wrapped all the way around to A." So really, I'm glad that I try to do things myself.

But I'm also glad that I've gotten more comfortable asking questions about this.

I'm also glad that I've gotten more comfortable asking people for help. For instance, I reached out to someone who came to speak to us the other day, and he graciously offered to talk for an hour on the phone about some questions I had.

That's just one very concrete example of how, if you ask, sometimes you get what you need.

So, inspired by this last week, I wanted to ask you: do you have any questions?

MakerSquare Day 51: "You don't know what you don't know." (11/3)

A very short blog post today--please, contain your disappointment!

I realize I didn't tell you my plan for this last week before our open house: having finished (for now) with my Chrome extension, I'm going back to my first project, Sharecare, which was really in not the best state.

Which is a shame for a few reasons: reason one, I would actually like something like ShareCare. (And yes, I'm inconsistent with my capitalizations because I haven't decided yet; tonight, I am leaning towards the camel case of "ShareCare.")

Reason two, the closer we get to our graduation, the more we're talking about the upcoming job search. For instance, today we had two lectures by outside consultants: a HR person and a VP of engineering. Which made for a very interesting day, if not totally coherent.

I mean, the HR person might be one of the first people to see our resumes: he's the guy who decides whether our resume goes forward after that first brief glance. (Note: Not him, exactly; he's pretty high-powered.) So he's looking for a certain set of skills on paper; and then, in a behavioral interview,  he's looking for a human being to fit a human-shaped hole in the company.

By contrast, the VP of Engineering might not see our resume at first; but he's not only going to be weighing in--and weighing heavily--on whether we've got the actual technical and human skills to fit in with the company on a day-to-day basis. Ultimately, if we get hired, we might not see the HR person, but we'll be working with the Engineering person.

So these two people come to the task of interviewing with a slightly different set of perspectives.

But--and here's my English grad school education to the rescue--I can see the patterns of similarity that run between these two widely disparate views. (If I were writing an English paper, I might call these "themes.") They may differ on some details, but the core advice is mostly what you hear about interviews: be the best version of yourself.

On top of that, both speakers hit the notion that informs today's title: at this stage in our career, we may have some ideas about what we want to do, either technology-wise (front- vs. back-end) or field-wise. But we don't know what we don't know, so we should also think about being flexible, not getting too tied down to any fantasy of what the right job would be for us. The right job might be something we don't even know about.

MakerSquare Day 43: A very little view of a week's worth of work (9/5)

When we did our hackathon, I was in a team of four people; Kelsey and I had whiteboarded (with our TA Ben's help) the night before and focused on our minimum viable product, with a whole bunch of extension possibilities; and the four of us had pretty distinct responsibilities.

So when I look at my current project and compare it to my hackathon project, I don't feel terrible that this project is not as advanced. I mean, we had 4 * 2 programmer-days for that, while I've only had 5 * 1 so far for this.

That said, I'd like to take the focus off of me for a second--just a second, mind--and talk a little bit about the cool things I've seen my peers make. Now, not all of this is ready for prime-time, but I don't think anyone would mind me talking about, for instance--

A neat little web app for playing pong (all in JavaScript);
The neat front-end design of a recipe box (with some very nicely done CSS);
The figuring out of the interface with Yelp API or Twitter API;
A large content management system service;
A well-constructed financial modeling system;
A way to get info from Steam.com that pays attention to the performance issues;
A front-end only collection of math/science tools with a really nice panel system;
A neat list-sharing app with a great in-place editing system;
The updated and improved version of the hackathon flash card app and the ping pong tournament app.

Like I said, they're not all done. But when I look back at what my peers have done before and see what we're capable of doing now, I'm very proud.

Bonus: yesterday we had a meeting with some people from Ivity Labs, an offshoot of SpringBox, including a MakerSquare alum; and today we had a MakerSquare alum from Lou Malnati's in Chicago come by. All of which adds up to this:

When we started, we weren't that good; now, we're a whole lot better; and with just a little more experience, we have the capacity to be a whole heck of a lot better.

MakerSquare Day 42: Stone on stone--until ... (9/4)

I don't have anything to show you right now. I'm not entirely sure when I will. (There's a possibility that I don't have any website to show you to, but only some screenshots since we build most of our apps on our computers; porting these local "sites" to other sites can be done, but may not be worthwhile at this stage.)

But rest assured, when you spend several days moving stones, eventually you will have...

... something resembling a pile of stones.

That might not sound like much, but I'm actually very excited. Because--and watch this metaphor of stones get extended--sometimes it can feel like you're hitting your head on a stone wall and not accomplishing very much. But sometimes some stones get dislodged with enough hitting. And then you might notice that some stone that you're looking at is actually the perfect shape to rest on this other stone that you just happened to be looking at.

(I don't want to over-dramatize the importance of happenstance and luck; but if you've spent as much time in libraries as I have, you know sometimes the important book is right next to the book you went to find. Almost the same could be said for coding: you can go research AJAX calls and instead find a cool Ruby gem for editing in place.)

All you need is time, a head hard enough to survive repeated pummeling, and the will (and curiosity) to keep going on moving stone after stone.

(To be more--ahem--concrete, today we learned about Promises in JavaScript (which is a way to chain asynchronous calls); and I got my database tables all re-written to do what I know think they should do.)

MakerSquare Day 41: Commas; or, Masonry, Part 2 (9/3)

Oh, I remembered the joke I was going to use yesterday--and it wasn't actually that good.

Oscar Wilde comes into the pub at lunch, looking exhausted.
"Hard morning of work?" asks the publican.
"Yes," says Oscar, "I spent all morning putting a comma in."
Oscar has lunch, leaves, and comes back for dinner, looking exhausted.
"Hard afternoon of work?" asks the publican.
"Yes," says Oscar, "I spent all morning taking that comma out."

There are (as I've said before) some big similarities between comma world and coding world; and, in fact, a lot of today has felt like some version of this Wilde joke. Like:

"Oh, I should add in a section on all pages that will be blank unless there's been an error and that section could report the error."

Then, later:

"Hey, I just implemented a section for good messages under my section for error messages. Why not just make a section for messages and pass in any messsage--good or bad?"

That's not the only example of an added comma/removed comma shuffle. And I won't lie, I understand why Wilde might be so exhausted after a morning and afternoon wrestling with a comma. He feels--and I feel--exhausted because it is exhausting.

So why keep doing it? Because Wilde and I are secretly masochists who like torturing ourselves? No. Well, maybe a bit of that. But mostly because this thing that we're so exhausted by--we're making it better by playing with it.

Alternate possibility: Maybe Wilde just didn't know how to use a comma correctly?

MakerSquare Day 40: Masonry (9/2)

I thought of a really funny--and also insightful and humane and most of all, humble--joke to start off today’s post; but it was quickly forgotten during today’s grind.

“Grind" might be the wrong word to describe today’s work on my final project #1. When I hear “grind,” I imagine one stone … ::looks up synonym for “grind”:: … pulverizing another. Slowly, thoroughly, with great and terrible purpose. So after a full day of grinding, I expect a lot of dust and debris--and not a lot of stone.

Whereas today, yes, there was some dust and debris (some rejected bits of code and collections of bookmarked websites answering questions I'm no longer asking). But at the end of the day, there were a few more stones on stones than there were yesterday.

Which is why today’s title is “masonry.” It’s not a romantic, fantastic word. No one raises a flag for masonry. (Well, except maybe the Masons.) 

But masonry gets stuff done.

For instance, I figured out how to alter an ActiveRecord database table when I'd already added an email column and needed to re-add it to use the Devise gem's authentication capabilities. (The secret is t.change in your migration.) That said, today was also the day when I realized that security is not part of my minimum viable product.

Maybe "minimum viable product" should really be today's title. Or maybe I should go with my first choice and just get that tattooed on my hands so I always remember.

Because masonry gets stuff done, but it takes time.

MakerSquare Day 39: ...but implementation is hard (9/1)

Last Friday was a reminder that ideas aren't all that hard to come by. (Especially when you are a student and can feel free to, you know, steal from major companies and try to do it yourself. Because, honestly, my version of Facebook isn't meant to compete with Facebook, but merely demonstrate that I could make one.)

But today, Monday, was all about how putting ideas into practice is hard. Because today, I started to work on my first final project.

I'm calling it ShareCare: a web-based, mobile-ready(?), team-based app for sharing caretaking duties and keeping track of those duties.

And yes, it was inspired by the fact that my girlfriend and I sometimes need to communicate about whether the dog's been out and pooped (or as we say, "was productive").

So, in honor of the difficult process of implementing the (pristine, beautiful, unsullied) idea, here's some photos of notes I made as I attempted to chart out my path on ShareCare.

1) Minimum viable product:

Here's a reminder when doing, well, just about any product. You may be making something incredible, but you start with a deadline and a minimum viable product. Anything that's cool that's not part of the minimum viable product goes into the bucket.

2) "Weeks of programming can save hours of planning":
That's an old coding joke; it's also the reason why I didn't write a line of code until I had mapped out my database and the relations between these entities. (Note: And I still had to go back to change a few things!)

3) Don't be afraid to make mistakes:

If we were supposed to do everything right the first time, we wouldn't have invented erasers. Or, in my case, invented more ink to cross out things--and then even more ink to re-write what I crossed out.

Let's see what I can show you tomorrow.