I've been programming for 8 years now. Only half that time professionally. It seems like a long time to me but is a drop in the bucket compared to many in this industry.
If I had to pick two big lessons from the past 8 years to tell someone getting into Software Development for the first time, I would probably say:
- Software is never finished.
- Software is never "right".
Software is Never Finished
Software is never finished because it exists in a social context. Software is an accessory to daily life and life changes. As our needs evolve, and the context around software shifts, so must the software itself.
Not to mention the fact that the teams working on software and the organizations around it shift. We cannot forget Conway's Law!
I often cannot imagine how the Software industry will ever settle with regards to tools and practices, when I see our tumultuous past 50 years. But even if our techniques and tools settle, I don't imagine our codebases will.
Software is Never "Right"
You might imagine that this section is redundant. Certainly it sounds similar to "Software is Never Finished". But I mean something different. I mean that there isn't a single right way that all software should be written or made.
The internet would lead you to believe otherwise. Programmers are nothing if not evangelists, even zealots, about their tools and techniques, their pet styles and practices, their esoterica.
The most important thing you can do is ignore this. Ignore the hate, Ignore the hype. Do not second guess yourself.
Tools, practices, and domains of knowledge are just that. Even if Software wasn't a moving target (see: Never Finished), we still do not have a single methodology understood to always produce the ideal code. Indeed, there isn't some ideal code we're after. The code is not the most important part, it's just the part we're paid to obsess over.
So don't sweat the folks who insist everyone should follow their "better" way. At the end of the day, good documentation and happy customers are probably more important than most particulars of your codebase.
By all means, don't stop learning and write the best code you can. But chart your own path through our tangled maze of lore. And remind yourself that it's okay to be an average programmer. We've got to find time for families and lives, after all. Speaking of which ...
The Right Thing
It's tough to try to plan for retirement. I'm still too young to think confidently on decade plus time scales.
It's tough to decide how to teach my students and gauge assignments. It's tough to decide what to learn next to become better at programming. It's tough to decide what I want from my career, how to nourish it and have it nourish me. It's tough to decide what's worth doing in general, when our lives are so busy and full.
But there's one decision I make that's really easy, even when it makes my life harder.
It's coming up on six years since Dad died. I cannot measure the amount I've grown since then. I know he'd be proud. But I'm proud and that's even more important. The biggest lesson I might have learned from John Glenn is this:
Loving other people is so obviously the right thing.
I cannot think of a time when I am as confident in my decisions as when I am loving and supporting others.
I'm not proud of my programming skills or code, though cl-6502 is kind of neat. I'm not proud of my job or relationship, though I am thrilled with those aspects of my life.
I'm proud that I handle hard situations with all the grace I am able. I'm proud that I treat others with respect and care because I didn't used to.
Most importantly, I'm proud that when I see someone struggling, I love them.
We do not get to have many easy decisions in our adult lives. But loving those around us, pleasant or unpleasant, in good times or bad is an enormous undertaking. I certainly fail at it, but I never regret it.
It's unfortunate that with our busy lives, in the sea of our alerts and notifications, it is so difficult to focus on the simple and important things. But I truly believe loving others is the most important thing that I do.
I have failed many times before and in many ways and modalities. I have character flaws. I have shortcomings. But if I have helped those around me through difficult periods in their lives and supported them when they were in need? Well, then it's all probably worth it.
For the bulk of my professional career as a software developer, I've felt like a fraud. To some extent, I think various aspects of tech hiring practices and tool fads/fetishes in the software industry create or exacerbate this feeling in most of us.
I read Joel Spolsky's Java Schools article way back when, before I was really programming. I looked down on Web Dev for a long time. I played with lisp, played with emulation. ... But I've been a professional web dev. Why am I fighting it and being hard on myself for not being a systems programmer?
I flogged myself for some time, a little voice in my head saying that web devlopment "isn't real programming". I would flog myself for not being good at web development when I hadn't embraced it. I would flog myself for not being knowing systems programming when I haven't put any time into it.
Sure, there's plenty I still don't know. But "I don't know but I can figure it out" is the right instinct to have. Trying a bunch of stuff and not finishing is vastly better than paralysis. Exploring any ecosystem and building better apps is better than misguided elitism.
I'm a hacker, through and through. I want to learn, want to improve, want to synthesize new things from my understanding, grow, share, and change. I looked up to the hackers of lisp lore and AI Labs. But that hero worship has become negative, is distracting me from just building things.
Part of the reason that little voice is in my head (and I listened to it for so long) is because I thought I didn't have a chance in this industry.
I've been a successful developer for years but often unable to enjoy my jobs because I've been too uncomfortable to embrace them. Then feared I'll be found out as a fraud, not a "real programmer".
I've been telling my students that since they understand the major components in web development and have some understanding of how they fit together, their real focus to grow should be practice. Constantly building bigger things, trying to make each piece more cleanly than in the past, gradually knowing how to solve harder and harder problems.
I stopped taking my own advice at some point. It's time to build new things again. Bigger things. Not the prettiest or the best, but real.
Recreation and Balance
For years, I've been focused on production. Even my "relaxing" activities aside from throwing dinner parties or going to concerts with friends have been productive in nature.
- Open Source
- Trying to Make Music
- Pseudo-Competitive Smash Brothers Melee
You get the idea. For the past 5 years or so, I've been terrible at doing things purely for recreation and fun. I struggle not to think of it as "wasting time". I'm always anxious about my technical abilities, my ability to find employment, my preparedness for the future. Rationally, I know that's all pretty ridiculous but I struggle to unwind all the same.
Work life balance has for a while seemed a relic of a bygone era. But I want to turn that around this year. Ironically, I've worked more 50 and 60+ hour weeks this year than any previous one. It turns out becoming responsible for the education of 15 people in a 12-week programming bootcamp is pretty demanding. That's why I'm listing these purely recreational goals to try and commit myself to doing some things just for fun.
- The Causal Angel by Hannu Rajaniemi
- Saga by Brian K. Vaughan
- One of Idoru or Pattern Recognition by William Gibson
- One of Redemption Ark by Alistair Reynolds or The Player of Games by Iain Banks
- Prince of Persia journals
- One of Transmetropolitan / Y: The Last Man
- Retro/Kickstarted: Hyper Light Drifter
- New Adventure: One of Rime or Legend of Zelda Wii U
- Nostalgia: One of Ocarina of Time, Fez, or Pokemon Red/Blue
- Sci-fi: One of SW: KoToR or Mass Effect
- Fantasy: Final Fantasy III or Chrono Trigger or Final Fantasy IX or Earthlock
- Magic: Play more Magic the Gathering with James, spend money on cards. Be a kid.
- Watch at least 2 documentaries about creative passions: Cooking, Indie Games, etc
- Game Loading?
- Mind of a Chef?
- No Map for these Territories?
- One of Modulations / Hi-Tech Soul
- Take at least one trip to the beach for no less than 5 days.
- Take at least one trip to see: James, Burke, or Justin.
I've been in a technical rut for a while. Sure, I learned new things at my job but limited myself outside of it by sticking to projects I wasn't motived about and only working with tools I was familiar with.
As much as anything, 2015 is going to be about playing with new projects, experimenting with new tools, and focusing on fundamentals again. Seeing as I have 3 big goals here, I might just try to tackle one each semester. :)
To that end, my primary goal will be to learn Ocaml and build something cool with it. I'm leaving that just as open ended as it sounds.
I'm interested in Ocaml for a variety of reasons. Its origin dates from a time before Intel and Microsoft created a 20-year dominant platform. It was envisioned as a systems language, much like Lisp, to compete with C++.
That said, it employs pattern matching and a strong, static type system like Haskell. Unlike Haskell, it has a fairly simple runtime and compiler built to give very clear intuition about code performance. While Ocaml is strongly functional, it provides for use of imperative state without monad machinations (sorry @James).
There are other reasons but I think this is a good start. I'd be interested in everything from writing an IRC bot, to scripting tasks, to NES reverse engineering tools (i.e. lots of graph manipulation), to OpenMirage toys.
I've leaned towards backend work in my career where possible. After helping TA Tim's Frontend engineering course last semester I finally want to pick up some front end skills. I'm not angling to get much better from a design or HTML/CSS perspective, but have a definite interest in mithril and Clojurescript's om. Elm also seems really cool but I'd prefer to stick to slightly less alien tech for the time being.
I'm considering porting my Nintendo emulator to Clojurescript and getting it to use canvas but I worry about getting bogged down as I did with the Lisp version. It was fairly painless getting a rough cl-6502 port up in Clojurescript in a few days though.
To be honest, my algorithms chops have never been terribly good. I think one thing that's intimidated me working on trowel is a lack of confidence in my algorithmic reasonining. So I'll be working through the latest edition of Sedgewick's Algorithms with a particular focus on graphs. With any luck I'll actually make some progress on trowel. Maybe I'll even wire it to an om app with some logic programming or constraint propagation tricks.
I've got plenty of things to work on in 2015 so I'm breaking this into a sequence of posts based on subject. I'd like to broadly note that for my first semester (roughly January through March) I might barely get anything done and that is okay. I've never taught before and I expect that learning curve to take up most of my time until early April. Now without any further ado ...
A Few Goals for 2015
A Fresh Start
I've been struggling a lot this year. I got stuck in a hole and it took me a while to find my way out. But I learned a few things along the way and I'm very excited about what's coming next.
I've accepted a job as a Ruby on Rails instructor at The Iron Yard. I'll be training people to become engineers in a very short timespan. For over a year, I've been whispering now and then about an interest in teaching, to Norma and friends. Starting January 5th, I'll have my first students. I'm equal parts nervous and exhilarated. I can't wait.
Learning How to Quit
A lot of my happiness and self-worth is tied up in making visible progress on things I care about. Over the past 10 months I lost faith in what I was doing at work and enthusiasm for my personal projects. Rather than recognizing that I should find a job I was passionate about or spend time on projects that excited me, I dug my heels in. No longer.
At one point, I said a Nintendo emulator was my forever project. I'd still like to see it taken further but I'm not going to work on that now. Belligerently sticking to those guns has been limiting my own potential. The only purpose of personal projects is to learn and to grow. They are mine and no one else's.
So until further notice, the emulator is on the backburner. Coleslaw will still get maintenance work but probably not much feature development. There are new things I'm fired up about and my focus will be on deriving as much momentum from them as possible.
I'm playing with Renoise and trying to pick up some music theory. I'm still not really making songs but I'll get there. I'm continuing to learn melee and now that I have a real training regiment in place I'm seeing much faster improvement. Hopefully I'll make it out to local tournaments every now and then.
I want to become more structured about practice. That includes starting to chip away at the stacks of CS and programming books I own that I haven't gotten around to reading. And experimenting with new tools like Ocaml, OpenMirage, and Ansible. And making room for play where nothing gets done.
I need to learn how to love and care for myself in spite of how much I get done, in spite of visible progress made or unmade. Part of that is going to be taking back my online presence, away from the more cultivated space of the last few years. There's a lot I want to accomplish over the next year or so. I'm sure plenty of what I learn won't be according to plan. But it's time to get going. It's time get organized. It's time to dig in.
This post is mostly written for myself. It assumes familiarity with various terms, people, equipment, etc. If you find it useful or entertaining, whether you play melee or not, cool. This post is not intended to be a training guide. I'm not good enough to be educating beginners, just to observe my experience over the last year.
If you do want to get started with Melee, you need a few things:
- Good condition Gamecube Controller (Nintendo-only, no knockoffs)
- A CRT or lagless setup, I rock a BenQ RL2455HM with the Sewell Wii-to-HDMI converter and an Avermedia LGP for recording
- A Gamecube and Melee disc, or better, Wii and 20xx hack pack on SD card
- Familiarity with the basics of smash as a series and a character to focus on
- A good guide, maybe check the resources at the end :)
I'm not a gamer. The last time I really put substantial time into video games was high school. I also wouldn't describe myself as a competitive person. But for whatever reason, I've always been competitive in Smash Bros. I want to win.
Late last October, I stumbled on a documentary detailing the history of the competitive smash brothers scene. I was riveted. I was suddenly aware of a massive depth to the game I'd hitherto missed. I had to know more, I had to try to my hand at competitive play.
Why Do This?
In addition, I've always struggled with things I'm not immediately good at. I'm terrible at being patient with myself, at viewing life (and goals) as a journey and not a destination to be reached post haste. Melee remains an excellent opportunity to practice being loving and patient with myself, and handling failure and defeat gracefully.
As I said before, it's a monumentally deep game. Like in chess, character positioning and board layout is paramount. As in poker, bluffing and calling your opponent's bluffs is crucial. There's also an executional aspect. Professional players routinely execute 300 actions per minute and have to perform complex controller inputs in a 20th of a second window or less. Not to mention just learning the properties of 25 characters, their moves, and the Rock Paper Scissors of what beats what in which situations.
I've been at it for a while now. I'm still not good but I'm much more at peace with that than I was when I started. Here are a few things I've learned playing melee the past year. A lot of these things are habits I've had to work hard to break. Just remember not to get discouraged. Melee can be very unforgiving.
Rule Number 1: Keep It Fun
You have to stay motivated. If things get too serious and you're not having fun you're going to play less and your skill will plateau. There are a lot of things beginners have to absorb and a plethora of suggestions, bordering on rules, about how to practice. Feel free to violate anything anyone says in order to keep things fun.
A few semi-regular suggestions I violate in the name of fun are:
- Focus on 1 character
I play 2 seriously (Sheik/Marth), 2 semi-seriously (Fox/Falcon), and 2 for fun (Pikachu/Doc Mario). If I don't switch it up, I find myself getting frustrated with progress on a single character. And when playing with friends, it can be surprisingly rejuvenating to go play a quick falcon ditto after an hour or more of serious play.
Additionally, I find some characters make certain kinds of practice more rewarding. For me, Fox makes it really fun to practice tech skill and Marth makes it really fun to practice spacing. Those characters really emphasize those attributes which makes the practice payoff very clear.
- Don't practice against CPUs ... (above level 5, to hone your mental game, etc)
The big argument here is that CPUs ingrain bad habits. Especially if all you're trying to do is win. So don't try to win. PPMD talks about doing something called shadowboxing, essentially playing the CPU like a human opponent. The 20xx hack pack is supposed to improve their behavior in various ways, especially DI. I find it helpful to practice tech skill at a level where the CPU will punish me if I'm too slow or miss an input.
Rule Number 2: Structure Your Play
Editor's Note: Some of the advice in this section is specific to me because I don't attend or plan to attend lots of local tournaments. The core advice of separating different kinds of play still applies.
To play competitively, you're going to wind up doing 3 things:
- Practicing tech skill
- Experimenting with your play
- Competing seriously
It is important that you keep these things distinct. For example, I try to spend 20-30 minutes a day practicing tech skill. I move around the stage, working on flubs or things I execute too slowly. I try to learn new tech (such as waveshines). I don't go to many local tournaments so I experiment with different approaches and punishes against a CPU. Finally, when I want to be competitive I play (seriously) against friends.
Initially, you'll want to blur all this together. You'll be playing semi-seriously with a friend and be tempted to try "new stuff": platform movement, wavedashing, the "Ken combo", getting an off stage Falcon Punch. Don't give in to the temptation. Melee requires you to adapt to your opponent above all else. If you're too busy obsessing over moves you want to land, you'll limit your options and your play will suffer for it. This isn't to say you shouldn't try to work on specific things in matches with your friends. Just that tech skill you haven't mastered and particular combos are not those things.
To emphasize further, don't practice specific combos. Part of Melee's depth comes from DI, or Directional Influence, the upshot of which is that getting a specific combo might be impossible depending on the opponent's actions. Long story short, DI allows you (and your opponent) to change the direction a hit knocks them in, potentially making follow up attacks miss. The interesting choices in melee come in between hits as you watch what your opponent does and react to it. While there are "guaranteed" combos in specific situations (character a vs character b at XX%), most of our combos come from reacting not planning.
Rule Number 3: Work To See The Neutral Game
If you've spent years playing Smash casually, you'll largely see the game as hitting or being hit, offense or defense. But that brutal simplification will limit your ability to see the larger game. Two common adages fall under this section:
- Don't Mindlessly Approach (your opponent)
- Don't Mindlessly Trade (hit for a hit)
The takeaway is, It's better to not get hit than to get a hit.
You'll be tempted to rush in right away, ignore that impulse. You'll be dying to hit them back for hitting you, re-establish good footing instead. The "neutral game" is everything that happens outside of getting a hit or combo and trying to escape being hit. The sooner you can see encroaching on an opponent's space on the stage as a useful form of micro-aggression, the better off you'll be. Just positioning yourself in a threatening way is a hugely useful tool.
Don't force your play into a false dichotomy of attacking or defending.
Rule Number 4: Remember Where Your Good Options Are
Editor's Note: This rule was originally called "Stay Grounded" and came from my reflections on the Marth v Link matchup with my buddy Max. Some of this section will be dependent on the matchup.
Stage position is important. Let's say it again: Stage position is really, really important. When I first started playing Marth, I always wanted to approach in the air. Just all the time. Lord knows why. But being in the air takes away a huge number of movement options. Your opponent can plan around and react to your play more easily when you have fewer options.
I wound up above Max a lot and got punished. Even if your character has good aerial attacks, unless you're talking cross up nairs with Pikachu or Fox there are probably safer, better approaches. So, being above your opponent is usually a pretty negative situation.
In general, center stage is a great place to be, and above the opponent, in a corner, or on the ledge, are bad places to be. Platforms are a bit more of a mixed bag. But remember where on the stage you have advantage and where your good options aren't available and figure out why that is.
In addition, spacing is really important. Spacing is more than just trying to throw out attacks from a safe distance, or thinking about your opponent's range. It also has to do with thinking about the range at which your character performs best. Marth and Falcon, for example, are mid-range powerhouses, while Fox and Sheik generally need to get in close to be really effective. Know where your character performs well and remember to stay in that effective range as much as possible.
Rule Number 5: Do Think About Options, Action States, and Transitions
Kirbykaze's blog posts explain this much more clearly than I will. Any time you can keep most of your options open while limiting your enemy's, do it. That's a huge advantage. And any time you can narrow their range of choices you have a much better chance of predicting their play, or finding a tactic that covers every possible outcome.
Since Melee is so much about movement and positioning, being fast is key. And indeed, most of the executional aspects of high-level play are in service of eliminating as much lag as possible from your character's moves. It's useful to try to build a formal model here.
Every move in the game has a set duration, though certain moves (dash dancing, wave dashing, aerials) can be shortened to varying degrees. Once you've committed to a move, the opponent knows more or less how long the move's hitbox will be active, how long you'll be unable to execute a different move, etc.
Consequently, speed mostly comes from transitioning quickly between moves or, as Kirbykaze's blog says, "action states". The better you get at switching between shielding, standing, walking, dash dancing, wavedashing, and attacking, the faster you'll be. Seamlessly and quickly transitioning between these states is vastly more valuable than L-canceling all your down aerials.
This is something I'm just now realizing and trying to improve on. It's very appealing to just work on l-canceling or short hops or wavedashing but misses the real point. The connecting tissue between action states is where most of our sluggishness comes from.
Don't Give Up
Finally, it should be obvious that regular, focused practice makes a big difference. I'm going to try to practice 20 minutes a day, 5 days a week going forward. I'm still figuring out exactly what that practice regimen will consist of, probably mostly tech skill and movement with Sheik and Marth. Wavedashing and L-canceling are muscle memory, sure, but practicing the basics shouldn't ever really stop.
And I'm still not where I want to be but I've had a few good moments. I hope this has been an interesting post on some things I've struggled with while learning melee. Happy smashing and if you're in Atlanta and want a game, feel free to drop me a line.
Various people have posted articles for beginners on getting better:
Why do Programming?
After going to Strangeloop for the first time in 2012, I was really fired up about programming. I'd only been out of school a year and was already a full-remote Clojure developer making a great salary. Even better, I had made good progress on my lisp emulation project and received some recognition from hackers I respected for it.
The last two years Strangeloop has been a lot more sobering. I told myself things in 2012 about how fast I'd get better and how good I'd be. Even though my expectations were unreasonable it's taken a long time to not feel bad about my (relative lack of) progress. I've been slow to accept the fact that I don't want to fight my way to being the best in my field.
I got in Tuesday night, dropped my bags at the hotel, and immediately ran off to drinks and phenomenal conversation at the Schlafly Tap Room. Many of the best experiences I've had at Strangeloop have been at the tap room. Sure there is excellent food, beer, and technical conversation, but I've always gotten a sense of personal acceptance at gatherings there. Strangeloop is certainly a welcoming crowd.
Wednesday was a blast as well, as any day with a trip to the STL City Museum should be, but more and more I found I cared about personal interactions more than the content of the talks I attended.
By the end of Thursday, I was stressed out. I wasn't even excited about the talks, which isn't to say they weren't good. I hated the idea that I was just an average programmer, that I didn't aspire to more than hacking bog-standard Rails apps as a career, that I'd spent almost $2000 out of my own pocket to come to a conference that someone else might have gotten more out of. I went to bed early that night.
I kept my mindset in check much better on Friday. I reminded myself to be excited about others discoveries and creations, not to demand myself learn every tool or technique. The conference wrapped up well and I particularly enjoyed some of the Distributed Systems talks, a subfield I still have no experience with. Not to say I want to go fight distributed heisenbugs soon or design highly reliable systems. The talks were quite entertaining and informative is all.
The main takeaways I've had from Strangeloop have nothing to do with tech and everything to do with me. Strangeloop has, in many ways, been a time for me to reflect these last two years. I'm not sure that's a good way to use the conference but it seems to be what I've done.
The first takeaway that comes to mind is that I need to try and respect myself for just being a decent Rails developer. I'm not great at solving algorithmically tricky problems and my CS background is, frankly, pretty damn weak. But no matter what I shouldn't beat up on myself for being "just a programmer". I need to put in an honest day's work and actually pat myself on the back at the end of it.
The second takeaway is that I need to program for me again. I got into programming mostly because I wanted to know more about how computers work. The emulator and talks surrounding it, some of my favorite work, is really more an investigation than artifact. I still want to support coleslaw. It actually has a few satisfied users and I'm one of them. But the only real purpose of the emulator is to sate my curiosity. Not to become a real thing or be special or groundbreaking.
There is plenty I'm still digesting and plenty I'm still not sure of, both technically and in terms of what I want for myself, my career, my life. But I'll leave that for another day. Cheers.
I'm working towards 1.0 and Coleslaw's basic architecture seems to have settled down. The areas of focus for 1.0 will be better error handling, command-line conveniences, more content types, and possibly some new ways to ingest data.
Coleslaw 0.9.6 will be released this Saturday and, not long after, make it into the next quicklisp release. Seeing as it contains big changes, some of them breaking, I thought I'd put out an announcement.
Coleslaw 0.9.6 unifies how we handles URLs throughout the application and
simplifies the deploy strategy. The good news is, this makes the install
process easier for new users. The bad news is, if you've got an existing
install, you'll need to add a new plugin
(versioned) to your config
file for the old deploy behavior.
That's not so rough, right? In addition, custom themes and plugins that haven't been upstreamed may need some minor tweaks. The NEWS has more details.
Feel free to grab the
basic-deploy branch from my repo and
try it out. There are some new docs and the README has been
cleaned up. There's also a plugin for Twitter Summary Card
support and the usual smattering of bugfixes.
While I'm happy to maintain Coleslaw if no one else steps up to work on it, I'm going to try and shift my focus towards emulation work and weird lisp noodling. If you're interested in taking on a co-maintainer role or working with me on the project please get in touch. I've been very appreciative of the help and interest thus far. If there's anything I can do to make the project more approachable or help people get started, do let me know.
It's time for the best programming conference of the year, again!
I fly out to Strangeloop later today. Here are the talks I'm planning on attending:
Thursdsay the 18th:
- 09:00 - Joe Armstrong, The Mess We're In
- 10:00 - Stephen Kell, Liberating the Smalltalk Lurking in Unix
- 10:50 - Christine Flood, Shenendoah: Open Source Pauseless GC for OpenJDK
- 12:20 - Leo Meyerovich, The Sociology of Programming Languages
- 13:10 - Paul Snively, Type Systems: The Good, the Bad, and the Ugly
- 14:00!! - Core.async Debugging Toolkit, or Production Prolog?
- 15:10!! - Consistency without Consensus, or Aeron: High Performance Messaging?
- 16:00 - Stefanie Schirmer, Dynamic Programming at Ease
Friday the 19th:
- 09:00 - Nada Amin, Programming Should Eat Itself
- 10:00 - Evan Czaplicki, Controlling Time and Space
- 10:50 - Yodit Stanton, The Internet of Things in Practice
- 13:10 - Ian Davis, The Challenges and Benefits of an FRP Frontend
- 14:00 - David Renshaw, Cap'n Proto and Rust: Type Systems for Sharing
- 15:10 - Julia Evans, You Can Be A Kernel Hacker!
- 16:00 - Aaron Bedra, Deterministic Memory Management for Managed Runtimes
- 16:50 - Carin Meier, Sam Aaron - Our Shared Joy of Programming
!! = Denotes time slots I'm uncertain about. Open to suggestions...
This blog covers 2015, Books, Butler, C, Dad, Discrete Math, Displays, Education, Erlang, Essay, Gaming, Gapingvoid, HTDP, Hardware, IP Law, LISP, Lecture, Lessig, Linkpost, Linux, Lists, MPAA, Milosz, Music, Neruda, Open Source, Operating Systems, Personal, Pics, Poetry, Programming, Programming Languages, Project Euler, Quotes, Reddit, SICP, Self-Learning, Uncategorized, Webcomic, XKCD, Xmas, \"Real World\", adulthood, apple, careers, coleslaw, consumption, creation, fqa, games, goals, heroes, injustice, linux, lisp, math, melee, metapost, milosz, personal, poetry, programming, ragequit, recreation, rip, strangeloop, work
View content from 2015-05, 2015-03, 2015-02, 2015-01, 2014-11, 2014-09, 2014-07, 2014-05, 2014-01, 2013-10, 2013-09, 2013-07, 2013-06, 2013-05, 2013-04, 2013-03, 2013-01, 2012-12, 2012-10, 2012-09, 2012-08, 2012-06, 2012-05, 2012-04, 2012-03, 2012-01, 2011-10, 2011-09, 2011-08, 2011-07, 2011-06, 2011-05, 2011-04, 2011-02, 2011-01, 2010-11, 2010-10, 2010-09, 2010-08, 2010-07, 2010-05, 2010-04, 2010-03, 2010-02, 2010-01, 2009-12, 2009-11, 2009-10, 2009-09, 2009-08, 2009-07, 2009-06, 2009-05, 2009-04, 2009-03, 2009-02, 2009-01, 2008-12, 2008-11, 2008-10, 2008-09, 2008-08, 2008-07, 2008-06, 2008-05, 2008-04, 2008-03, 2008-02, 2008-01, 2007-12, 2007-11, 2007-10, 2007-09, 2007-08, 2007-07, 2007-06, 2007-05