Shiny new computer, cruddy old flu, fun new Fizzbuzz in Elixir

I just updated my LinkedIn profile, so I might as well update you here: my new job is as a junior developer at Clutch Analytics, the digital invention arm of Windhaven Insurance. And this last week was my first week there.

Which makes it the perfect week for me to get the flu. Ah well, that's only tangentially related to coding, so I'll leave it at this: a slight fever might, occasionally, be helpful when studying a new language.

Another issue that's only slightly related to coding, but which I have to bring up here for other junior developers--especially those who come straight out of school without much work experience: starting a new job involves a lot of logistics, including filling out paperwork. (Note to self: fill out paperwork this weekend.)

So now I have a new(er) computer, set up with my preferred configuration; the lingering effects of a flu; some health insurance paperwork to fill out; and some fun Elixir challenges. To that end, I've (thank god) gotten back to committing to my Github, which has a new repo for Elixir challenges. The first, of course, is Fizzbuzz.

Post-MakerSquare, Week Two: Keeping your code sharp--and, oh yeah, about that job search

How do I not have just a plain jane "Coding" tag? Anyway, welcome to the tag family, "Coding"!

And I want a "Coding" tag here because I want to talk about a website that I have fallen in love with recently: exercism.io.

It is very much like those other websites where you get coding challenges, e.g., CodeWars, Project Euler, etc. (which I also like). That is, the goal of Exercism.io isn't to build any project (which I still maintain is the best way to really get into the nitty-gritty of a language), but merely to play around with a few challenges.

I especially like how Exercism.io keeps everything real clean and focused. Rather than running a test online (and oh, how online tests have given me heartache), you run the tests on your computer--as you would normally. Exercism.io also has a nice breakdown of various languages, so that you can try only the Ruby challenges or the Clojure challenges; and after you submit one solution, you can fetch the other. (The interface is not unlike Github, which is another reason I like it.)

And then, best of all, you get some commentary and feedback on your code. Because, sure, my DNA/RNA transcription agent worked, but the real benefit of using this is I have now discovered a new method--String#tr--that I never used before and wouldn't have used if I hadn't seen someone else use it.

So, if you want to practice a new language or keep an old language sharp, I recommend at least looking at Exercism.io

***

And about that job search, I've been offered and accepted a junior developer position. So I'm off the market for now; and very excited about starting in early December. I will say more about the job and the company--after I reread my NDA and figure out what I can say.

For now, my new challenge--both for fun and for work--is to learn functional coding. Come on, O'Reilly books, don't fail me now!

Post-MakerSquare, Week One: Don't be so apologetic on the job search (plus bonus FizzBuzz)

"So, one note for you," said a mentor, after I went through a mock technical interview, "is: Stop being so apologetic."

Which really might be the centerpiece of why I don't love interviewing. I mean: I love talking to people, I love asking questions, I love answering questions. God help me, I even love coding challenges. Ask me to do FizzBuzz in one line, please!

Sidebar: How to do FizzBuzz in one line:

(1..100).each {|num| num % 3 == 0 && num % 5 == 0 ? (puts "FizzBuzz") : num % 3 == 0 ? (puts "Fizz") : num % 5 == 0 ? (puts "Buzz") : (puts num) } 
It's not pretty--or really all that maintainable--but it works in one line. (Note: tested on repl.it; and inspired by a Paul Irish post.)
Let's break it down:

• 1..100 -- standard Ruby for an inclusive range
• each -- loop over each element in the array/range and slip it into the following block
• followed by a cascade of ternary conditionals
  • if it's divisible by 3 and 5, put "FizzBuzz", and if not, then
  • run through the next case (divisible by 3) and if that doesn't work,
  • run the next case (divisible by 5), and if that doesn't work
  • just put the number already

But I don't love selling myself. When I'm discussing my projects and my web dev foundation, it's pretty tempting for me to pick at the issues or the lessons (i.e., the mistakes that I made). Largely that's because of where I am in my career--just beginning, with plenty to learn and a big hunger to learn it. I mean, I really liked the early hackathon project we did, but weeks later, I can see some of the holes there.

Looking at those holes can be very educational and even rewarding. ("Look, ma, I'm learning!") But they don't always make the best interview discussion.

So, dear mentor, I'm going to try to be less apologetic during interviews.

And wouldn't we all rather talk about FizzBuzz anyway?

P.S. For actual information about my job search--well, I'm not going to get into details. Suffice it to say, I'm concentrating on Austin right now, with an eye cast on Chicago; I'm looking primarily for, let's say, middle-end to back-end--anything below HTML/CSS, which I can do, but don't enjoy as much. I've got some leads and had some positive interviews, so I feel OK. But I'll be 100% honest with you: I'd much rather be coding than searching for a job.

MakerSquare Day 58: And so it begins... or ends... or ends and begins. Or maybe just goes on (12/5)

So, today was our last official day at MakerSquare, and after some teary-eyed goodbyes, it became clear that a lot of people will probably be around on Monday.

Because even though we're done with one step--the immersive, 12-week course--we've got a lot more to do, both in terms of our development as web developers and in terms of our job search.

That said, I think it's important to take a moment to appreciate how far we've come, both individually and as a group. I remember back to our first day--well, I don't have to remember it, I can just point to my blog post about it here. Back then, we were told to parse a list and the class largely responded with "what a what now?" We were told to model a recipe and I thought about striking a model pose.

Well, OK, maybe we weren't that clueless, but we were pretty close.

And now, after 12 weeks of constant and steady work, all of us had several projects that we could show off pretty successfully. Many of us have already posted about our projects (on reddit and elsewhere) or posted our projects online for everyone to use (more or less). We have portfolios.

Some of us even have interviews and contacts; and all of us have pretty good prospects for the future.

So, I have a bunch more to do today and beyond, and I fully plan to keep up with my blogging. On a more limited scale of course. As we move away from the daily blog, with me memorializing my time at MakerSquare (for potential and actual students to check), I hope to transition more into helpful bits of code I've discovered or made; and a record of projects that I'm working on.

I hope the last 12 weeks of blogging have been helpful or interesting. The last 12 weeks have been both for me.

Also, one last comment about our last day: a week ago, a classmate of mine said that we should have a high-five graduation ceremony, where everyone got to play one song and go around the room high-fiving everyone. At first, I wasn't sure about this idea: is that really how we wanted to go out?

So let me offer this advice for you: if someone asks you if you want to play a song that's meaningful to you and high-five everyone after working really hard for 12 weeks--you say yes.

(For those interested, the songs ranged from triumphant for finishing the course; to hopeful for how we're going to get better at this; to joyful. I can't help but jump to Icona Pop's "I Love It," which was one of the songs on repeat during my finals weeks.)

MakerSquare Day 56: The short version (12/3)

For those of you who aren't going to make it to the open house tomorrow, I wanted to present a short, bullet-pointed version of things I may talk about. (It's OK, it's supposed to be terribly cold tomorrow, I get it if you can't make it.)

OK, so maybe this is just 15 minutes of me trying to articulate this stuff that I've been working on for a while. Starting with...

About me:

1. My career(s) and interests have taken some left and right turns, though you'll see a lot of themes running through--
2. People: I like working with people, I like working out problems with people in discussion, my dissertation was going to be on groups of people working together. Heck, even improv is primarily around being a good teammate. (And, though this is my professional blog, let's add here that I moved from Chicago to San Angelo, TX because my girlfriend got a job there. That too is about my love of people--or at least my love of one particular person.)
3. I like paying attention to detail--and I can tell you at length how close-reading in literature or paying attention to your improv team is a lot like double-checking your code before shipping it.
4. I like innovation and experimentation and getting better all the time. And here's the part where I kind of have to slag on my grad school experience. Not that English departments don't like innovation in certain ways, but those ways are somewhat limited. (Though, again, I can go on about the digital humanities/big data in literature movements.) But in web development, everyone I talk to has some interesting side project or is learning a new language or BUILDING A NEW FRAMEWORK. In a weird way, web development combines my loves of creation and analysis.

About my Chrome extension:

1. I knew it had to be a Chrome extension since it ran on the back of another site. (Which limits the applicability, but also made it easier to scope the project.)
2. I spent several days of the development cycle home sick, trying to read up on the subject; but as with most things CS related, reading gives you maybe half of the info--it's usually more informative to just get your hands dirty.
3. A Chrome extension is a lot like a regular website in terms of stuff in it--HTML, CSS, JavaScript. (You can even put Angular in! Though that didn't seem like a good way to go for my extension.)
4. But the architecture is very much based on convention rather than configuration: there's a way that things are done and you just have to learn them. So, for instance, content scripts are the only way to affect the DOM, while background scripts are sort of a virtual space where you can pass info from content to the browser itself and the pop-up window.
5. I played around with the omnibox before deciding on a pop-up interface.
6. My biggest difficulty was figuring out how to get it to re-run when new tweets get loaded, until I found out about Mutation Observers, which are perfect and new-ish, since they are objects with special methods for watching for changes.

About my ShareCare app:

1. The idea that I came with, inspired by my experience of sharing responsibility for a dog.
2. (I even tried to set up and send out a survey inspired by my watching of the Coursera course on Human-Computer Interaction. I did not get a lot of responses.)
3. My biggest (first) difficulty was exploring some options for tech stacks to use. For instance, I never used Foundation or Bootstrap before, so I wasn't sure which might be better for styling. (I went with Foundation, which I was moderately happy with, except for some bobbles trying to get Foundation and Rails to work nicely together.)
4. Rails was a lot of fun to work with, in part because it's so smart. You want an AJAX request from a button? Just add "remote: true." You want to separate out your page into modular parts so you can handle each part individually? Let me introduce you to partials.
5. The second difficulty was thinking about how to best design the database. Just a few days ago I realized I could drop one whole table (Claims) and make the same call by just paying attention to the Task table's "completed" and "user_id" columns. (The lesson, as always: Don't make things more complicated than necessary.)
6. The greatest lesson of dealing with a big project like this is the modular approach: break it down, and fix one thing at a time.
7. I probably learned more from this project--both the mistakes and the successes--than any other project.
8. Also, I have a ton of ideas for how to expand and improve this project. Though as it stands, it fits the need I had of passing info between me and my girlfriend about whether the dog's been fed or not.

OK, so that took longer than 15 minutes, but it's going to be mighty cold tomorrow, so some Austinites might not make it out.

MakerSquare Day 55: "I have the skills." (12/2)

That's my takeaway quote from tonight's alumni panel discussing, well, what it's like to be an alumni of MakerSquare. "I have the skills" was the realization that the alumnus in question had when working out a problem at their job. Maybe they didn't have the knowledge, per se; but from their time at MakerSquare they had the skills to find the answer.

Though today's panel was only a few hours of the day, with that sort of positive message, it certainly left something of a influence. Or maybe that's just how it is when people share their horrible interview stories.

(Although, is it wrong that every time I hear an interview story involving a coding challenge--like "reverse a string in JavaScript"--my brain always stops for a moment while I work out how I would do that? I guess the lesson here is, if you need to distract me, give me a fun coding challenge.)

(Also, it's a lot easier to laugh at horrible interview stories when the people are not employed and happily so.)

But really, today was spent doing a rather large amount of tasks. Is there anything better than crossing tasks off your task list? I don't think so, which is probably why one of my final projects is all about creating tasks and then marking them as done.

I also realize that I've been talking very vaguely about my final projects and about things I've learned. Well, OK, I did write about how to make a Chrome extension, both in general and in particular.

But what about Rails, which is what my ShareCare app uses? What about Foundation and HTML and CSS and JavaScript? (OK, not I'm just listing my tech stack.)

I'm coming to the end of my allotted 15 minute writing time, so I won't be able to get into all of that today. But I will say this: one thing that I've learned through my weeks here is that documentation--even the littlest bit--can make a huge difference. When I go to find a Gem to do something and there are several out there (there's a lot of overlap among Gems), I tend to choose the one with the best documentation.

Which is why I spent so much time this week working on my Github README files and that's today's lesson: good documentation includes a clear README.

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 47: Maybe locking myself in my room with the disease wasn't such a good idea after all (10/4)

I didn't get a lot of work done (or oxygen to my brain) today, which is a little disappointing. (Well, the oxygen thing is slightly more than disappointing.) But it does bring up something--in a round-about way--that I'm not sure I've talked about but which has been on my mind:

Why did I leave writing for code?

Well, I didn't really: I still enjoy writing fiction and plan to continue with it in the future. I just left behind the field of freelance non-fiction writing.

(Except for blogging, which you may notice I've kept to like a barnacle.)

As much as I enjoy writing, so much of it is solitary work. And, as I've been reminded by my unintentional quarantine, code can be solitary--but it can also be team-work. Even if you're not in an organized team, you'll find that an open-plan office leads to some interesting cross-pollination.

At the very least, when I'm at the MakerSquare office, when I hear someone talking about some interesting code--either an interesting solution or an interesting problem--it can sometimes get me thinking about something useful. Or when I run into a problem, there's usually someone around to talk it out, whether the other person provides a solution, a hint, or merely a willing listener while you solve your own problem.

In writing, that's not so much the case. Don't get me wrong: if you're working on something, you may have people you can turn to, whether it's your writing group or just a friend willing to read something. But there's not really that same sense of team-work and collaboration.

And that is one reason why I really don't like being stuck at home, sick, right now; and it's one reason why I decided to move into a coding career: I like teamwork.

MakerSquare Day 44: A different type of hackathon (10/1)

Today we had a hackathon, but not the usual kind. Today was our--

Resume Hackathon!

I'm probably just using bold here to make it sound more exciting. To be clear: the idea of going out on the job market; of going to interviews; of getting my first job in web development--all of that is very exciting to me.

But writing and revising a resume isn't as exciting as embarking on a lifelong career in a field that I'm kinda crazy about.

(Have I ever told you guys about meta-programming in Ruby? It's when you write code that then goes and WRITES MORE CODE. As a long time fan of infinite loops, the idea of code writing code makes me very happy.)

Part of the general (I think) lack of excitement when writing resumes is that resume writing is a lot more cramped than writing code.

Or rather: if I give you a coding challenge, you could probably think of five ways to code out a solution; and if any way fails, you'll get an error message that tells you how to fix it.

Man, I love feedback.

Unfortunately, resumes don't offer the same level of detail in their feedback. You get less "undefined variable" or "stack level too deep" and more "no thanks" and ::crickets::.

For me, with my big change in career from ex-PhD candidate and education writer to programmer, it's interesting to see how much of my resume is no longer relevant. Although maybe I should leave some of that in. Wouldn't you like to work with a web developer who once taught a class on 19th-century science fiction?

::crickets::

(Actually, now that I think about it, I think my teaching experience really does help me with both public speaking and with translating certain concepts into more easily digested forms. So, it's going back in the resume, people! Along with my improv classes at the Second City.)

MakerSquare Day 25: Shiny happy programmers (6/2)

I'm not on the job market right now, but I'd be lying if I said I didn't occasionally think about what the job market is like for developers. Or what it will be like in six weeks, when I am on the market.

And the market is even more on my mind on those days when we talk to career services; or when established developers--MakerSquare grads, mentors, or just allies--come to talk to us about what it's like for them out there in the real world.

The real world is rather disappointing when compared to the computer world, in that the real world has far fewer arrays. I hope it's not too forward of me to say this, but: I love arrays.

But the real world is not so disappointing in terms of careers and places of employment. For instance, today a group of front-end developers at RetailMeNot came to speak to MakerSquare at lunch and they were--what's the word? Happy. They seemed like they liked their jobs and their co-workers, which is a real shock for me to see. (In grad school, where a large chunk of my adult life post-college was spent, people by-and-large are not happy. Or not at my grad school, at least.) 

On top of that shocking expose of what it was like to work in this field (they have foozball tables!), I also had a nice one-on-one chat with the head of MakerSquare career services, discussing possible places I would like to end up and possible salaries. It was a little on the abstract side--nothing as concrete as "I will work for foozball table time"--but it was a good start and something I hope will pay off when I do go on the market.

Which, ahem, will be in six weeks now. In case any possible employers are reading. And have a foozball table that isn't being used enough.

Note: Although we did a bunch of coding today, from brain-waking morning coding challenges to logging users in to a website, I've tagged this as "Teambuilding" to memorialize the time we spent at the end of the day working through a bunch of visual puns and jokes. As a team.