Posts tagged 'meta'
-
No matter how good my memory is, I forget things.
The things I forget tend to fit into two categories: that which I need an artifact to recall, and that which sounds foreign, even when I see evidence of it.
Dresden Codak addressed one face of this in a poignant comic, about future memories. The upshot of it, though, is that I think I have a good memory mostly because I've forgotten things I forgot… my bias is showing.
Some things I recall better than others, but perhaps because I obsess over them—reading and re-reading stuff from my Facebook timeline or what have you—but there's clear evidence that without pictures, documents, objects, souvenirs, and so forth, my brain prunes out or otherwise makes inaccessible whole portions of my life.
For instance: I can recall, broadly, what I was doing in 2011 only by remembering where I lived at that time, and then thinking of the sorts of things I did in that place. But otherwise the entire year is blur.
I don't think this problem is going to get less acute over time. Journaling is a way, then, to mitigate some of these effects.
Bruno laughed around the stem of his pipe. “Yes, make it work. Clever lad. Alas, I fear I'm not up to the task. These old chalkboards are getting white.”
“Eh?”
“Chalkboards. Blackboards. Ah, what do you children know?” The cloud around him thickened with his huffing, and he waved it away. “In the tradition-heavy wilds of Catalonia, where I cut my first set of teeth, the last vestiges of the stone age lingered very nearly until the rise of the Queendom. A chalkboard was a slab of hard, dark slate onto which you would scribble with little cylinders of soft, white chalk. Really! We had one in every classroom, every kitchen. You'd erase the board with a rag, you see, and write in a new batch of lessons or chores or ingredients. But sometimes you'd misplace the rag, and you'd have to scribble around the margins of what you'd already written. If you let this go on long enough, eventually the board would get so white with scribbles that you couldn't read it anymore. And so we learned: too much knowledge is as bad as none at all. We forget how to forget."
–Wil McCarthy, To Crush the Moon
-
Phase 1: Deleting/archiving presence elsewhere
A big part of this thrust to centralize … myself, for lack of a better word—is getting all the bits and pieces together in one place.
There have been a variety of platforms over the years. Some have died—I don't think I stored anything important on orkut—but on those that still exist, you can see the entropy.
I've been convinced of the value of holding onto your data in formats that will resist the test of time for years. Nevertheless, it's amazing to me how much entropy has struck in places where there has been platform continuity for over ten years. Embedded tags (nominally HTML, but obviously parsed somehow by the internal tooling) and other metadata has bit-rotted until everything is nearly unreadable.
After some effort, I have archives in local storage of almost everything I've ever posted online, and the old versions are "deleted"1 off those platforms.
With some exceptions. Facebook is a tough nut to crack; I needed to register as a developer to even begin to download my post graph entries, and after toying with it for a bit I'm not sure that I'm ready to go all the way down that rabbit-hole. It looks like I'd have to run a local server in order to scrape an effective copy of my data from them, since their "archive" tool is god-awful for someone who shared as many links as me.
Phase 2: Triage
A lot of the stuff I've written down can go back up in due time. A lot of it should never see the light of day.
This leads to a question of, what's the point of a blog? I know that a lot of what I write now will seem embarrassing by the standards of future me, but this process seems asymptotic. Meanwhile, angsty blog posts from when I was 15 contain … embarrassing turns of phrase, among other things, that don't shed light on who I am now.
Broadly speaking, I don't believe in deleting things. On reddit2, if I was blatantly wrong, and someone pointed it out, I'd always leave my posts up as a matter of principle, and to provide context for people who came by after.
But does that mean I have to put everything back up? I doubt it.
What's interesting about this place is that (my intent is) it is a place to focus and refine my thoughts. The ideas I've gotten the most mileage out of are the ones I write down in a place I also read. So, some turn of phrase or tiny stub in a page of a notebook I constantly flip through worms its way into memory via spaced repetition, essentially.
This suggests that the real goal is to find the kernels that reflect deeper truths… and then consolidate them into something wiki-like.
Further, blog entries outside my journals should be considered transient. This suggests another layer of metadata, for posts that don't hold interest because they've been superseded by something more refined or more correct. Not just for currently outdated posts, but for stuff that's fresh now that'll seem stupid in two or ten years.
Do I need to own up to everything I've ever said? That way lies madness, surely. But reading and consolidating is probably in the cards, which suggests something wiki-like is on the medium term road map.
Phase 3: Editing
For the stuff that's worth posting, editing is necessary. I may end up going through and doing this cleanup on everything, but the first-order changes involve more or less the following:
- Remove useless metadata (e.g.
date_gmt, added by Wordpress) - Clean up remaining metadata
- Change formatting to markdown
- Resolve obvious typos
- Add appropriate tags and categories
The point of this blog, again, is organizing the data, so having effective cross-links is the first part of that. As mentioned before, I'll probably need some sort of "archival" tag, to indicate to readers that what they're reading is historical reference3.
This is a highly manual task. An automated tool might sound good at first blush, but the data sources are heterogeneous and the sorts of formatting that each demanded differ that re-establishing the correct context in markdown syntax demands I re-read and hand-tweak everything.
In theory I'm not against this, because I want to re-read and consolidate as many of my old thoughts as I can, but 1) it's a lot of content and 2) it's going to screw up my plan to get permalinks running. I don't think date+slug is an effective permalink schema for content where date might not be the most important aspect of what I'm doing, but without a database there aren't really any unique primary keys to work against. I'll have to chew on this for a while.
Conclusion
What's the point of all this effort? Well, I have bits and pieces all over, and it's part of a process to more well-define my identity and make my thinking more coherent.
Journaling is more of a "in the moment" process, that reflects where I am in the day and time. Organizing, as an umbrella, is about finding a kernel of myself, and building on it logically.
-
Who knows if these platforms actually delete old content, though. ↩
-
… speaking of sites I wrote content for but never archived… However, so much of what I wrote on reddit only makes sense in the context of the thread it's in, so maybe it's okay that I don't have that. ↩
-
And perhaps add an obvious note, and cross-links to newer versions? ↩
- Remove useless metadata (e.g.
-
My mantra-in-testing right now is "Seek Pain." It's a reminder to always try to be doing something that is hard or causes you anxiety or stress, to make you better, so that the next level skills will come sooner and faster. So, do something until it becomes a habit, and then it won't be nearly as scary, and the harder thing won't appear insurmountable anymore.
Today I realized that I've been living my life in near-constant low-level anxiety for more than a month, and I haven't felt this good in a while.
So, to the world: You can't do anything to me that I'm not already doing to myself.
-
I've been thinking about interviews on a conceptual level a lot recently, and especially the question of what is my greatest weakness. Without exposing too many of my cards to people who might be interviewing me in the future, it's an interesting question, and one that's hard for me to nail down.
I have a hard time coming up with traits that are not both strengths and weaknesses. It reminds me of role-playing games: every skill point invested comes with an opportunity cost. Further, I have an outstanding question about real humans: to what degree are certain traits mutually exclusive? For instance, someone who looks really sharp all the time is probably not going to be the ultimate hacker; hygiene takes a non-trivial overhead cost on your mental processes that is (probably) incompatible with being a super-hacker.
We don't really know enough about how brains work to nail down everything there is to know about what traits are likely to manifest in a single individual. Does competitiveness relate intrinsically to violence or impulsiveness or something else? There's no way to know, yet.
So in light of all this, some things I'm not so good at:
- Putting down work when it's "good enough"
- Biting off small pieces of large tasks
- Trying to think through everything that could happen in an abstract situation instead of doing and seeing what happens
- Getting started
- Multi-tasking
- Giving myself enough credit
- Doing things whose purpose I don't understand
- Doing things when I don't respect the desired outcome
- Attacking a task via the sides instead of the front
- Killing my darlings
- Writing concisely; respecting my readers' attention
- Accepting less than an optimal solution
On the flipside, I am super-tenacious and will see a problem through to the bitter end, if it's possible at my level (e.g. without a PhD in Math and six years advanced study).
These bullets seem to cluster around a couple personality traits. I'm slow to start, slow to transition, and absolutely dogged in the middle. I work very well when I am concerned with the process and not the purpose—what I refer to as "suspension of disbelief" tasks. To elaborate, when I started in the Army it was easy for me to just perform, because I was working against my former self, trying to become faster, stronger, more Army, etc. When I just started at City College, it was easy for me to give my classes everything I had, because my purpose then was to get the best GPA I could, acting as if the degree was the only thing that mattered. Later on, I saw what a clusterf*** the Army was, and how misguided leadership was; later on, I saw what a house of cards the world of higher education was, and couldn't stay in that world when there are ways of educating that are clearly better.
The act of identifying trends and clusters gives some insight on how to attack them. For instance, when I don't respect the desired outcome of a task, try to identify something in it that will make me better. If, some day, the answer looks to be "get enough money to go home and do something that I care about", that will be a sign it's time to quit that job.
So, the answer to the "real" interview question—"what is your greatest weakness and what have you done to compensate for it—for me would be … something like this:
"I am not decisive when I don't have complete information. What I do to compensate is to try to identify some complete task that I can tackle, and set my mental benchmark for success in such a way that I do what needs done and move on to the next thing. By the time I've gotten my feet wet on something I understand the scope of the larger problem much better."
It's a work in progress, obviously.
-
Years ago, I was having a fight with a girlfriend, and when things had settled a bit, we had a level-headed conversation about what I needed to do.
One of the notes I wrote myself was to the effect of "Learning to ask for help, and getting it". Meaning, when I had problems, I expect(ed) to be able to deal with them myself, but that's not how being alive works. No one really get anywhere themselves.
A couple years ago, my boss sent me a curt email saying that I needed to start asking people for help earlier on in the troubleshooting process, because it can save time. There's a balance between being helpless and always asking others to do your work for you, and never asking for any help. This is, basically, knowing the right time to ask for help even though you could solve your problems on your own.
I was taking some pride in never asking for TA help on solo days, because there was never any problem that took longer than a couple minutes, but there were always more problems.
I write about the future of schooling, and how teachers and TAs are education multipliers: they help lead students to good avenues of attack, and know when to step back and let them struggle a bit.
Last night, I asked Jonathan for advice on an issue with the assets pipeline, and over the course of three quick interactions I was able to generate the behavior I wanted. (Why does every problem fix, including home DIY work, seem to require three tries? Is there some truth to fairy tales?)
There is no intrinsic virtue to being able to do everything on your own, because the guy who doesn't have that hangup will far surpass you, even though you might feel more self-reliant.
-
What are the relative demand levels for entry-level engineers vs. engineers with experience? Are they equivalent? Presumably, if the pipeline stays somewhat stable, there should be slightly fewer devs with 3+ experience at any moment than entry level devs; where are the demand levels?
If you just can't fill a slot for a mid-career developer, and you have a reasonably-sized team (i.e. not a single devops, a CEO, and a dude in sales), you should be able to take up some of the slack by hiring junior devs and managing/mentoring them adequately.
A company that can figure out how to do this will be picking up money that others are leaving on the table, because a lot of those Jr Devs will end up being the mid-career devs with (hopefully) a bit of loyalty.
Have I said these exact words before?
-
My biggest challenge of the moment is maintaining focus. Maybe if I had a single project to work on, it would be a bit different, but there are a lot of little time-consuming things that need to happen in a lot of areas to be ready for, say, next Friday's employer presentation day. I really need a decent portfolio to send out, or a bigger list of employers to contact, or a number of other things… I'm working constantly, but I'm not sure if I'm working on the best use of my time at any given moment. It's an old problem.
Today I think I'm going to take a break by putting some polish on some of the smaller portfolio-like work. I hope that will be enough to get me motivated to hammer on the rest of what I have to do. It's daunting, though, and I know there's not even any free time on the weekends, not that I would necessarily want it. What would I do with the time? Everything I know anymore is here.
-
I'm using this tumblr to keep a couple people up-to-date on my doings and not only for assignments, so I thought I'd offer an overview of what the program's about.
It is, of course, twelve weeks long. The first nine weeks are mainly curriculum, followed by three weeks of project development—looking at what the previous cycle is doing, this consists of cloning the functionality of another public website as an proof of skills. I don't think most people choose to make a novel project (it's easier to solve a solved problem), but I don't know whether it's banned per se.
As for the "curriculum", it consists of a couple languages in a sequence that ramps up in relevance to web design. So, to start, we're using Ruby to script basic stuff—algorithms, data structures, the fundamentals of programmatic thinking, that sort of thing—and then add in other elements, like JavaScript, SQL databases, CSS for visual design, and so forth. I haven't looked at the elements of the curriculum for a bit because I'm trying to stay focused on the here and now for the time being, but it's basically web development from end to end, from core scripting to design.
Of course, one part of the program is blogging your reflections on a public tumblr. My alumnus friend tells me that the only people who will be interested in most of this will be fellow students, but I try to cover enough other topics that maybe others will want to read about my time in aA.
Central to the instruction methodology is a working strategy called Pair Programming. How this works is a single computer is hooked to two monitors, and one person controls the keyboard and mouse, while the other talks about their thought process and, almost but not quite, tells the other person word-by-word how to get through the problem.
In practice what ends up happening is one of a couple things. First and most ideal, the pair is matched well, at which point you can easily forget who's actually in charge at any given moment—it feels like the executive portion of your brain is the other person, and you become the mechanical/error checking portion, or vice-versa.
Second, there's a close disparity, or a symmetrical disparity—A knows something B doesn't, and maybe B knows things A doesn't. My pet peeve is people doing motion commands multiple times, so I am constantly teaching my partners motion commands (delete line is ctrl-shift-K, select line is cmd-L, etc.). I don't restrict myself to this sort of thing—I've been spotting a lot of errors and edge cases while driving, which I don't do as much when navigating because I'm thinking of the overall strategy. It's sort of like the source of the analogy—the navigator in a car doesn't tell the driver how to pass or avoid an accident, but s/he does make damned sure the driver doesn't pass their exit.
My perennial weakness is syntax specifics; I don't bother spending a lot of brainpower memorizing the syntax of every command when the reference material is right there. What I have spent time on, by contrast, is understanding what the elements of the function signatures in the documentation are, so I can quickly parse and interpret what sorts of things a function is capable of, and what sorts of things it returns. I'd like to think I'm helping others learn how to do these things with greater facility.
Third and most rarely, one person is completely clueless and is basically told by the driver what to tell them ("okay, so how are we going to solve this problem? What search algorithm should we use?"), and then when they're the driver, they're simply a glorified typist. I think this is why Pair Programming often gets a bad rap—in organizations with programmers of vastly different skill levels, you won't always have two people who can pair well.
One of the advantages that you'll see regardless is that, as long as one person isn't a complete pushover, the pair will produce cleaner, more readable code, and each person will come away knowing more than when they started, either about programming and problem solving, or about communication and education.
The office, on Cooper Square, is relatively compact and a bit on the old side. It's not all glitz and glamour; it's functional, in a building that could really benefit from a bit of TLC from a motivated DIYer. The local shopping options, especially for food, are amazing—it's going to be hard not burning through my savings by going out to eat every day, especially because some of the best conversations happen at lunch when everyone has a chance to relax—and it's nice and central to a lot of people and train lines.
We only use the school's computers, not our own. I guess previous cycles had mechanisms for students to bring their own computers, but there are logistical problems with that, especially when it comes to supporting non-default install environments and version conflicts. Further, we all use the same editor to work—Atom, by the same people who make the git version control system (ed: this isn't true; it's made by the github people)—which is a good editor, but not great, out of the box. One advantage to learning Atom is that, in time, you can add plugins to do almost anything any other editor does, but it can be quite frustrating not having some of the more clever IDE shortcuts available by default (TextMate's "Command-enter autocompletes a function signature" is one I miss almost daily.)
One thing I'm noticing is that if you learn Unix shortcuts, specifically readline mode's motion and deletion commands, and the shortcuts for a single editor, most of the other editors out there will support the same shortcuts. So really, the learning curve to switching to Sublime or TextMate after using Atom should be quite low. Atom does file browsing better than TextMate, so even though I bought the latter, I am considering just sticking with Atom. (If you don't understand, navigating the file hierarchy of a big project can be quite a pain in the ass with bad tools.)
Their current stats are 98% of grads are hired within a certain timeframe for a median salary of $84,000 (in NYC). This is promising, because I run out of money mid-March :)