I love studying history. I’m always fascinated by what I learn, and take away lessons that inform my life choices. Today I finally got around to reading Eric Steven Raymond’s wonderful essay “How To Become A Hacker”, which has been sitting open in a browser tab on my laptop since Steve Huffman recommended I read it almost 9 weeks ago.

I came away from this piece with two big takeaways. The first is a rehash of a previous thought about the recency of open-source software. I’m constantly amazed by the recency of much of what I take for granted. From tools I depend on (Bundler comes to mind), to languages (Ruby, circa 1995) and frameworks (Rails, 2005) I’m learning to use, much of my infrastructure is younger than I am. Some of this I know and am comfortable with, but other parts surprise me.

I had previously read about the recency of the open source movement, but some of the details provided by Eric Steven Raymond amaze me. Islands of closed-source, Unix hackers sounds depressing. As amazing as it must’ve been to work in the earlier days of technology, I’m glad I’m walking into this world now. I don’t want to live without open source or Linux. They’re both a huge part of the culture and community I’m joining. I don’t want to imagine life without them, but even considering that possibility makes me incredibly thankful for everyone’s contributions.

The second, and perhaps more consequential, takeaway comes from this piece and one referenced by it (Peter Norvig’s “Teach Yourself Programming in Ten Years”). In the lead up to the last week at Dev Bootcamp, I’ve thought a lot about what comes next for me. I’ve spent the last 7 months learning to program, but more importantly learning how to learn to program. I want to leave Dev Bootcamp and go somewhere where I know that the learning will continue. I want to be a full stack developer. I want to take my strong knowledge of Ruby and comfort with Rails and go deeper. I want to learn more JavaScript.

I’m particularly excited to learn other languages. If I only need Ruby and JavaScript on the job, I’ll likely dig into C next. I want to know what’s going on at the lower levels. I want to understand, more than just in the abstract, what Ruby is hiding from me, and how I’d manage the things it does automatically. I want to learn Lisp, because it sounds like a fascinating language. The list doesn’t stop there: Scala, Go, Java, Haskell. And that’s just the languages.

The important thing, however, is that none of this is just for the sake of learning, and none of it needs to happen next week. I want to learn these languages over the course of years. I want to learn them because I think each of them will teach me something important about writing code and solving problems. I’m especially interested about learning languages and techniques for solving problems of scaling. If I was to choose one issue to focus on out of the gates, it’d be scaling. I think that’s a fascinating challenge, because it gets at how the code as written meets the limits of the hardware it’s running on. It means understanding more than just writing good, well-tested, OOP code.

A note to readers: I love the look of www.dmragone.com, but understand if you want to just read things here. Wherever you read, enjoy!

While I’m improving in all areas of my coding, one area that always feels slow is styling. There’s a lot that goes into making something look good, and certainly one thing cause of my perceived slowness is a difficulty in knowing ahead of time what looks good. I’m not sure if I should expect this to change as I get more experience with design, but for now I try some things out, poke around my favorite design resources to get some inspiration, and sketch a lot. Eventually I make progress, and have a decent-looking site. Or so I like to think.

One thing that can be a huge drag is swapping between a text-editor and browser to hit refresh each time I want to see what a change looks like. It doesn’t sound like an experience operation at first, but can really drag on me. So I couldn’t be happier to report on the huge success I’ve had tonight using Guard and LiveReload.

For those of us using Rails, installing guard is as simple as adding it to your Gemfile, bundling, and then running “guard init” on the command line. Getting live-reload running took a little bit more digging to figure out, as it appears to have a non-stated dependency, but that’s easily resolved. Simply add the following to your :development section of your Gemfile: “guard-livereload”, “rack-livereload”, and “em-websocket”. Then run guard init livereload, and start up guard.

The last thing you’ll need to do is install a browser plugin to handle the auto-refreshing part. Chrome has the lovely “LiveReload” plugin. One click after running guard and it’s listening for updates, and auto-refreshing each time I save a file.

Life is made better with a lot of small wins. This one’s pretty awesome.

Oz had lions, tigers, and bears, oh my. The internet has spammers, scammers, and trolls.

Once upon a time I wrote Python. It’s been a few months since I’ve even looked at a line of pretty and clean Python code, so I figured I’d brush up some and review my notes and code from Udacity and practice a bit. After remembering a bit about why I liked Python, I decided to check out my very first web app, notforcred, which I wrote in Python. I hadn’t looked at the site for quite a while (pretty much since I put it up), so wasn’t even sure if it was running.

I got a 500 error. Worse things have happened, but now I wanted to fix it. Looking at the logs, I was surprised to see someone (something?) hitting notforcred.com every couple of minutes. Sadly Google’s AppEngine wouldn’t let me look at the database to understand the error it was throwing (because of being beyond the app’s free limits), so I decided to do two things: comment out a bunch of lines of code around the area that was throwing the error, and blacklist a number of the IPs that were hitting the site. There was no reason that anyone should be going there, so I assumed it was something at best automated and broken, at worst malicious. Why anyone would intentionally do a denial-of-service on my site was beyond me, but I wanted to make it work again.

After waiting a day to get back under the limits Google’s AppEngine places on free apps, I was able to load up the site and see what was going on. I shouldn’t have been surprised, but was disappointed to see countless posts made on the site for all the sorts of things that end up in my gmail spam folder. Without any sort of authorization required or any limit to the number of posts any IP could make, the internet took its toll on my web-app, and drowned it in ads for viagra.

I chose the quickest and dirtiest solution, which was to manually clear out all the bogus posts and change the controller to more or less ignore new ones. I may work up a longer-term solution for this app, or just know not to make this mistake in the future. I’ve learned a great lesson in handling user-submitted content, and now know to take some precautionary measures whenever there’s an open form and submit button on any web-app I create.

Yesterday I had the pleasure of meeting new thoughtbotter (thoughtbottian? thoughtbot?) Britt Ballard. We had a great chat about learning to program and life changes (Britt is new to San Francisco and thoughtbot, I’m new to coding in general).

One of many things I took away from our conversation was the importance of growth and learning to being a developer. Britt mentioned that this comes up often in the context of looking at code he wrote just six months ago, and realizing how much he has learned since (and consequently how much better he would write that code now).

I strongly empathized with that feeling. It’s something I felt recently as I went back to the first Rails app I wrote and worked to clean it up, but more than that it’s an approach to self-reflection that I instinctively employ. As someone eager to learn more and grow personally (across all skills, not just knowledge), I often look back at my former self and see ignorance and incompetence in how I acted. None of this comes from a place of self-loathing; rather, it’s a recognition of the importance for me to change meaningfully and be a better version of me, constantly.

And so it’s easy for me to accept that I write bad code, from the perspective of me, 6 months from now. If ever there’s a point where I’m not learning new things and coming up with different ways to solve problems, I’ll know there’s something wrong.

I don’t speak any foreign languages (for those unfamiliar, that’s what Americans call languages that are not English). I studied German during high school and took a couple semesters of Italian in college, but never took the time or made the effort to truly get comfortable with either of those languages. I’ve been told it’s harder to learn a new language as one gets older, and I believe it. Putting ability to learn aside, free time is an incredibly rare thing.

I love the amount of respect and demand for polyglots in the programming world. If you know one language, you can learn others. If you know a few different languages, you can bring in experience and understanding of different paradigms to your coding.

I can’t wait to dig into C (to understand what’s going on at a lower level) and to learn a truly functional language like Haskell. For the time being, however, I’m working on staying familiar with the languages I’ve worked with so far. For me, that’s Ruby, JavaScript, and Python. I’ve learned a lot about writing good Object-Oriented code since I started focusing on Ruby almost full-time. I can still pick up JavaScript, and have done so frequently enough over the past few months to remain comfortable with it, but I fear that it’ll take me a little while to get comfortable with Python again.

I feel that the most important thing to learning new programming languages is having a meaningful goal. I enjoy writing Ruby, and JavaScript is a must-have for web-programming. My goal for keeping up with Python is to provide perspective for learning Ruby. Python and Ruby are similar but have differences that I can’t articulate to the extent I want. Learning Python will help me better understand the benefits and drawbacks of coding in Ruby.

In addition to having a goal, I feel it’s important to take the time to truly become comfortable working in a different language (and potentially different paradigm). There’s no benefit to writing Java code in Ruby (and I imagine any attempt to write Ruby code in Java will end poorly). Don’t do a rush job. Take the time to really understand what the language offers. And perhaps what the community offers, too.

Finally, I’m a fan of learning by building something specific. I’m thinking of a good-sized project for me to brush up my Python, but in the mean-time prefer to focus on building in Ruby and JS. Once I have something I can work for, I’ll be creating context for learning, which helps me learn.

I’m not sure what language I’ll be using primarily when I leave DBC, but I plan to add a language to my skill-set each year, at least for the first few years. There’s a lot to learn, and a lot of different approaches and styles. I’m excited to expand my horizons by understanding what each of those are.

Pairing with Jonathan yesterday and today was pretty awesome. We kicked some ass, and I definitely learned a lot. It was certainly one of the pairing highlights for me at DBC - we were in good flow and each brought useful knowledge and experience (even though we’ve only been learning Rails for a few short weeks).

jypepin:

I started to pair with David to do a Hacker News clone. I was pretty impressed on how fast we could go. That’s what I call pairing like you’re supposed to.

A lot of discussions have been made on wether or not pairing to learn is efficient; Everybody seem pretty convinced that pairing is an amazing practice… as far as both pairs know at least a little about what they’re doing.

Since the beginning of DevBootcamp I’ve been pretty easily convinced by anything Shereef has been saying. Because I’m like that. I’m really into the master-student model, and as soon as the skills of my master have been proven, I just do what they say trusting them.

But with more experience about pairing, it is true that last week, while we started the resources on rails, I found pairing more uncomfortable. Because we both just had no idea of what we were doing, and the major part of our studies at that state was reading, and trying things while we had no idea of what we were doing.

So I think, depiste Shereef being totally convinced that pairing is better anytime, pairing is amazing, but not always. 

But in the case where David and I were pairing on the Hacker News clone, we both knew exactly what we were doing. David might be a little more advanced, which was nice for me, but the gap wasn’t too much either. He was leading, but I had total understanding and control on what he was doing. If I had a comment on something, best practices, or question, he was willing to instantly stop and start talking about it. Because it was ok for him. Because any interruption I’ld bring would teach him something or bring some interesting questioning. Same way around for me.

In that state, pairing was super efficient, because as soon as one had a doubt about something, the other one was here to confirm “yeah I’ld have done the same” so you just move on, instead of constantly loosing minutes searching the internet for confirmation.

In like 2 hours we were able to make, from scratch, no scaffold or gem, the articles, the comments and the users (YES, no scratch, NO DEVISE OR BS LIKE THAT WE’RE CRAY I TOLD YOU).

So yeah, that is exactly what I call good pair programming. And that is the perfect example of why pair programming is amazingly efficient.

But when both (or one) has no idea of what’s happening, I think it brings more frustration, and even time loss, because a pair will put both in a rabbit hole…

Last week I started my first consulting project. I also hired my first consultant.

I picked back up a project I worked on in August. My first Rails app after getting semi-comfortable with Ruby and working through the Hartl tutorial twice, I wanted to build something fun to practice Rails and TDD. Sadly, August-version of me did not yet grasp the importance of writing concise methods or separation of concerns. Looking at the code I wrote only a couple of months ago, I am amazed at how much I’ve learned.

One possibility for post-Dev Bootcamp life is working at a consultancy. There are some awesome ones here in San Francisco, and I’m sure I’d learn a ton were I to go that route. I imagine one type of project that those companies get hired for involves picking up a codebase that is not unlike what I wrote in August: unruly, poorly designed, and on the verge of failing miserably. Forget adding any new features. The thing needs a re-write.

I had two options when I decided to work on this project: scrap it all and start from scratch, or work to remember what on Earth I was doing and fix it, re-writing both code and tests in the process. I opted for the latter. As a result I’m learning about technical debt and developing some heuristics for how to tackle ugly code. I expect to make some good progress today, and will write some before-and-after type follow-ups this week on how I dealt with the various problems I caused myself.

In any learning environment, some students have more knowledge and or experience with a particular topic than others. Depending on the age of the students, I expect two possible responses to the question of who knows what, when asked to the group as a whole.

Young children seem eager to share what they know, and specifically to show off and receive recognition. They eagerly raise their hands when asked “Who knows …” sort of questions. There’s no shame felt in claiming knowledge, or at the least a desire for recognition greatly outweighs any shame.

Something different happens in adult learning environments*. I see it every day at Dev Bootcamp. A staff-person asks who knows about a particular topic (perhaps “ActiveRecord”), and a couple people raise their hands, meekly. I don’t think it’s because only a couple people know anything about the subject. Everyone’s paying attention, so it’s not a lack of involvement or alertness.

It’s only a working theory, but I believe the reason people didn’t answer fully (equal parts honestly and enthusiastically) comes from a sense of shame in knowing more than their peers. We learn at different paces, and at DBC we take the opportunity to learn different material at different times. No one wants to brag or be seen a know-it-all. This seems a perfectly reasonable reaction. And yet this results in students not acknowledging their own knowledge and learning progress. I think this ultimately detrimental to the everyone present and the learning environment.

I suggest we dispel the shame of knowledge. We recognize what we’ve learned and what we know, and disregard what impact it might have on our peers. They shouldn’t be ashamed by not knowing something. Everyone doesn’t know things, and in the ideal learning environment, there’s not-knowing and learning everywhere. The latter requires the former. And it’s only natural for some people to know something, while others don’t. Let’s not be afraid to acknowledge that.



*: I’m not sure when this shift happens. I definitely see an age element in it, but I can’t say for sure when that happens, nor whether there’s some additional classroom cultural component involved. As usual, all theories wait to be proven incorrect or at least unreasonable, and are assumed possible and reasonable until then.

I take pride in my new-found ability to create something useful and (usually) interesting by writing code. It’s an amazing experience, and the high hasn’t gone away in 6 months of doing it full-time. I hope it never does.

Pride in one’s work is a wonderful thing to have. But it should never get in the way of making that work better. I’m not sure I believe in perfect code, but I am certain that I don’t write it (or anything close to it). With learning as the primary goal, I seek out code reviews regularly.

A code review can seem rough. Sometimes after a couple of minutes of looking at the junk I wrote, a teacher will just open a new document and start sketching out a better way of approaching the problem. If I was too caught up in what I wrote, and felt it being thrown out so quickly reflected my worth as a human being, that might be a devastating experience. I fear that some people think that way, as I see fellow students at DBC really kicking themselves after a rough code review.

The important thing for me is to keep a good mental distance from my code. Disowning it might be a bit extreme, but what I’m doing isn’t far off in terms of my ability to receive feedback. Yes, I wrote that, but I’m sure it can be better. I might know how to make it better, or might have forgotten to apply a principle I’ve learned previously, but that’s ok.

I love code reviews, including (and especially) the ones that rip my code to shreds. I don’t want a pat on the back. I want to take a great leap forward. I want to level up. The only way to do that is by almost getting killed by the dungeon’s boss.

dmragone.com’s posts come direclty from tumblr. Thanks to the wonderful rigoneri, I can use his creation called syte to put a good looking blog up, connect a couple of the social networks I  use actively to it, and not worry about any complicated support or set-up.

The blog posts come directly from a tumblr account I have. One thing that I’ve missed out on so far has been embeddable gists. The tricky part is that I need to be able to support them on both the tumblr and dmragone.com.

Thanks to Moski Doski, I can now do just that. With a simple script to add to the bottom of any post that will include a gist, I can add a gist via just the id. The script handles the rest of the magic.

Now I can show you cool things like how I learned about using the factory pattern in JavaScript a couple weeks ago. Check it out:

I’m still reflecting on the experience from a week ago Wednesday, what the staff at DBC called “Wax on, Wax off”. Silent pairing for 45 minutes was pretty awesome, and I mentioned briefly the roles that resulted in that session of one person advocating for the code, and the other for the tests. I continue to believe this approach leads to both better code and better tests. The question I continue to ponder is whether this can be attained without the added challenge of silence.

The best code I have written at DBC has come when equal energy, effort, and thought went into the code and the tests, and the interaction between the two turned into a negotiation where each worked to be meaningful. I’ve had this experience both with a pair and coding solo, and aim to make it happen more regularly. Getting there seems to require a few key ingredients.

The first is agreement on the design. This isn’t necessarily easier solo. While TDD aims to use tests to design, I’ve found greater success in writing specs and code when I’ve put time and effort into designing before I begin writing serious tests (meaning that I might play around with some tests to see how they sound, but refuse to write code to make them pass until I’m more confident in the design that results). Without agreeing on the design, and with two junior programmers (or just one if I’m solo) writing code, I’ve found it much too easy to move into flushing out the design by trying things out in the code. Every time this happens, the specs are forgotten for at least part of the time as design happens in code. But if instead the pair has agreement on where they’re going at a high level, it becomes easier to write both good tests and good code.

The second is a willingness to begin with the minimum code necessary, and a simultaneous eagerness to refactor as we go. If I write more code than the test calls for, all I’m doing is ensuring we’ll have weak tests and flushing out the design in the code. Since we’ve agreed on the design, we need to make sure the tests reflect it properly and test thoroughly. Don’t write code your tests don’t call for.

The third ingredient is mental separation of test and code concerns. If there’s not someone fully in each camp, it’s too easy to leave one side behind. For me and my fellow junior coders, we easily fall prey to thinking not just about but in the code, and can lose track of our tests easily. This is equally if not more difficult solo, as it requires a bit of split-personality, swapping back and forth between the advocate for the tests and the advocate for the code.

I’ve noticed good progression when solo in accomplishing these goals, though I’m far from where I want to be. It’s doable with a pair, but requires agreement that each of the above ingredients is necessary, and good communication throughout. That doesn’t always come right away with a new pair, but at the least this provides the opportunity to work on developing the skills necessary to work with new people and adjust to their patterns and explain mine.

It’s easy for an organization to aim to only hire A players. Who wouldn’t want to work with only the best? I’ve seen various arguments about how this is unsustainable for a company, as well as how easy it is to mistake B players for A players. Yet there remains enough interest in hiring only A players to have practically spawned an entire Amazon category on the subject.

My working thesis here is that while some people might be better at a particular job than other people, the concept of hiring only ‘A’ players misses the crucial point of hiring: finding the right person for the right job. Go ahead, find and hire the best and the brightest. Tell me how that turns out for you.

Or would you prefer to have the smartest guys in the room? I’ve heard that can cause some trouble.

An alternative title for this post might be “There is no One Size Fits All Employee”. I believe an organization wastes everyone’s time by looking for only the best people it can find if it comes at the expense of proper job-candidate fit. Here in the San Francisco Bay Area I hear a lot about problem-solution fit, product-market fit,  and market-team fit. Hiring should be approached with the same mindset. You need to find the right A players for your organization.

Coding is uncertainty.

I’m not sure how many people have said or thought that previously, but I feel it every day. I’m not sure if this sentiment goes away as you learn more, but it’s still with me. I may know what Ruby’s #inject method does, but given enough complicated interactions, enough external systems, and enough variation in environment, the only certainty I can find is that I will be surprised by what happens.

In the face of this uncertainty, I find confidence from my most central mental heuristic. I look for patterns and connect disparate pieces of data. I record various bits of information, and always seem able to recall the right information in the right setting. I use what I learned previously to create guiding assumptions and reasonable theories. With these, I can be confident in what I expect might happen, or at the least know what changes my assumptions need if something else happens.

This comes naturally to me, but I think anyone can do it. It’s simply a matter of practice and persistence. When code you wrote (or didn’t write) provides unexpected results, make a theory from the information at hand, and then test that theory. Have expectations for how various results from that test will alter your theory.

In the end, you can’t know everything, but you can develop good instincts for making useful assumptions and theories. It’s well worth the practice.

As a newbie programmer, I’m often amazed at how much progress has been made on programming tools in the last few years alone. Between beautifully simple deploys (thanks Heroku, et. al.) to amazing tools for installing different versions of Ruby (rvm) and managing differing dependencies of gems between projects (bundler, rubygems), I am infinitely grateful to all the coders who have taken the time to build out the infrastructure I now depend on.

Two of my favorite tools are rvm and bundler. Even though I currently use ruby-1.9.3 about 99% of the time, but enjoy the flexibility to experiment pain-free. The wonderful Ruby on Rails Tutorial by Michael Hartl introduced me to much of the Ruby/Rails eco-system, including Bundler. While going through it, there was one thing that drove me nuts: the need to always type ‘bundle exec’ in front of every command. Whether by luck or a infinite loop of google searches, I happened upon a page on rvm’s site that I interpret to say that rvm 1.11.0+ now by default removes the need to type ‘bundle exec’ every time I want to type a command that is run via the gems that bundler knows (via the Gemfile). I say ‘interpret’ because the post is a bit confusing to me - it refers to various points in time, and has not been cleaned up to provide clear context. I’ve been rolling with this assumption, and haven’t broken anything major yet, but would definitely appreciate confirmation.