< prev 11 Dec 2017 to 16 Feb 2015 next >

Posts filed under 'journal'

  • And, we're back

    So.

    When I graduated from AppAcademy, I hacked up a stand-in portfolio website using turn-key Wordpress provided by my hosting company and a slightly tweaked version of a theme I kind of liked.

    Well, over time I realized I didn't much like Wordpress. The toolkit seemed robust, but so slow, to the point that I would get frustrated playing with settings. I can sort of tolerate that sort of thing, except for the following:

    1. It's a personal home, not something for work, so comfort and familiarity is supreme.
    2. Comfort, for me, is derived largely from things like responsiveness. If there is every visible lag in typing, I get subtly frustrated and that frustration mounts.
    3. The plugins I most wanted to use were flaky at best, and I was not and am not inclined to learn PHP to get (for instance) an email-to-blog portal working
    4. It was subtly messing up some raw entries when they got written to database, leading to subtle rendering artifacts that were hard to fix due to the slowness mentioned above.
    5. I realized the theme I had landed on was flaky in its own way, and I didn't much want to debug someone else's idea of what a good layout looks like.

    All credit to the authors of WP, and free WP themes, but they're just not for me, not for this.

    So I had been vowing to re-write my blog to something I would enjoy, and fiddled around with a couple things over the years. It never was a priority, so I tinkered back and forth between rails and static site generators, like Jekyll.

    I'm going to elide a huge amount of history and research, but basically I realized a hand-written rails CMS was a total waste of time, and the half-measures—existing rails CMS apps and engines—were inappropriate for my goals. I made a fair shot at using Jekyll, too, but liquid is way too constraining1 for a personal site where I have total control over the build process.

    Meanwhile, I'd gotten sick of Facebook et al's controls. I pay for hosting, I pay for registration, and I know how to manage my own content—I don't need to be someone else's revenue source. So I downloaded as much of my own content from other sites as possible and archived it locally, and I'm in the process of shutting down my social media presence. This is my home now.

    This, then, is my blog. I have a backlog of topics and to-dos I want to address, so there should be a real burst of new topics as I have time to put things down. I'm not entirely sure what this is going to become, but it's lightweight (static site generated using Middleman), and it's mine.

    1. As I understand it, liquid is intended for things like storefronts where you don't want the store owners having the ability to break things or to access a full interpreter via templates. I don't care, so it's not right for my needs. 

  • Tilting at Windmills

    My time the past couple days:

    • Writing Project Euler solutions in Ruby, using the "get it done, get it fast, get it good" (alt: make it X) philosophy
    • Realizing that I could no longer write the Python code I wrote less than a year ago
    • Crushing it on phone interviews that I didn't plan on having anyway
    • Faceplanting on an in-person interview that I should have been able to do better on
    • Writing and analyzing algorithms with people at the office
    • Taking on projects that sound interesting until you realize that you're trying to bite off way more than you can chew

    It's important to stay busy with productive work, but it's tempting to think that what you're doing is valuable when in truth the marginal utility is pretty low.

    In other news, it's interesting to see how natural writing Project Euler solutions is in Ruby compared to Python. I have many fewer head-scratching moments when it comes to the natural plan of attack—generally, I can just implement the solution that comes to mind, and it runs well enough. Project Euler is, I think, like Alaska: it's not where you learn, it's where you prove yourself. It just happens to be the biggest name in toy programming problems, and many people assume that it's good at teaching you… something.

    Not sure what else to say. I'm trying to keep at good habits, and I started thinking about what I wanted to write on the train in today, but then I started thinking about how to build an Abstract Syntax Tree in Ruby (and whether I really need to in the first place, to do what I'd like) and lost what I was going to write. Oh well. More practice; back to the grind.

  • Dry Spell

    I don't know why this title made sense to me, except in that I haven't written in a couple days. It's been interesting, for sure—I've had a couple phone screens, which have been all over the map, but tremendously useful for learning how to better present myself—but I haven't felt like doing major work for a while.

    Is this bad? The projects I'd like to do are hard to wrap my mind around at the moment; part of me wants to learn a systems language in more detail, but I know that it's not a close synergy to anything that's going to get me work, now. The only places that want systems languages want Java for the backend (or C#); learning C would definitely be a stretch in terms of immediate utility. Is that so bad?

    Maybe statistical programming would be better. I don't know; there are so many things to learn out there, so many projects that could be useful to someone, and I could devote myself to them, but which? Will doing that make employers look on me more fairly? Do I want to work at a company where a single week of working in Angular would be the difference between me getting the job and not? (Probably not. A competent engineer could figure out what needs learned pretty quickly, and I don't know if I'd want to work for a company that would disagree.)

    I want to have a job, so I can worry about more granular things, instead of whether I'll run out of money before this process finishes. I want to be learning a ton of new things about production code, and making my own projects on the side. I want to write a couple books and learn TeX and not feel guilty that I'm not working on finding work. Soon.

  • A Constant State of Fear

    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.

  • Weaknesses

    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.

  • Learning to ask for help

    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.

  • The Matthew Effect

    For unto every one that hath shall be given, and he shall have abundance: but from him that hath not shall be taken even that which he hath. (Matthew 25:29)

    Yesterday I was looking up an old contact (who is a lot like me, but much further along, and with enough money to not have to care), and the memories came back in a rush. It's hard to sum up what anything is, what any experience is like to people who aren't you, but I can mention one thing, the thing that I needed to read.

    In this essay, he talks about how he writes. He has an easy writing style, and apparently people come to him and ask him how he writes so well. His response is that he deliberately writes what is easy and approachable (e.g. that which he knows a lot about), and in time the other things he wants to write get easier. He tackles those in their own time, once he has enough practice/warm up/etc. under his belt for those to be easy to write.

    Like others, I write darlings, and it's hard for me to kill my darlings. It's pleasing to me that when others proofread my work, they point out problem points in the same places I see them ("Oh, this is no good… I'll leave it in for now, though…" "Yeah, this is no good, you should change this/take it out/jump in a lake"). That's not to say that I always know how something needs to be changed, only that I recognize weak spots.

    Anyway, all this comes together into some thoughts about skill generation in general. Writing and graphic design and programming aren't so different in many ways, ways that could fill a book, which is not particularly surprising given my philosophy of "everything is everything". In keeping with the spirit of this entry, though, I'll point out that when you stumble in your craft, the best thing to do is keep working on something.

    Admittedly, you will need time to let your brain process. When you make a typo and overlook it for an hour straight, that's usually a sign that you need to do something else, like run on the treadmill for an hour, drink heavily, and pass out. (By morning, all your problems will be much shallower.) There is a route to maximal learning and maximal skill development, and it doesn't typically involve doing the same dumb thing until you're too tired to do anything right, and by the way, you've just spent an hour anti-training by practicing bad habits.

    It's been a long couple days, for no particularly good reason. I've actually made a lot of important progress—note here that I'm not saying a lot of progress, in an absolute sense—in getting my head screwed on straight and doing important work. I talked to a lot of people, in different contexts, and these low time, high value conversations are really great for figuring out what I want, and need.

    I started sketching out a book that I want to write in parallel with the book I need to write (because my battery died and I had a long train trip, oddly). I think this book will feed into the book I've been trying to write for the better part of three years, if I can make some headway on it. Meanwhile, I have my eyes on a half dozen pet projects that can help strengthen my portfolio. None of them are small enough to sink my teeth into at the moment, and none of them are dire, but like writing, the act of thinking of pet projects leads to thinking of more pet projects. I still need to figure out how to have a brainstorming repository, since every time I start something it all just gets more fragmented, but that should come in time.

    Ugh. In other news, I'm wrestling with some asset pipeline issues with heroku, and I'm about to tear my hair out. It's distracting me, and thus I'm not able to give enough attention to writing this. I know there's more I wanted to write, but I have a hard deadline tonight so I'll have to pick this up later, if I can find the track again.

  • Words of Wisdom

    I have to write for the book I owe in October starting soon, so I've been thinking more about writing in general and how things are communicated. (Perhaps this could be considered semiotic thought?)

    The urge to try to tackle a different book has resurged, especially now that I'm writing here without the threat of fine. Writing is comforting; however, this style of writing is a bit too unrefined and "work avoidance" to really lead anywhere. If nothing else, the medium format stuff seems to be a good lead in to starting work, and getting into a good groove. I wonder if other people feel the same way, and that's why some people get to the office early and work on email?

    (As a sidenote, perhaps that's reason enough to get out of bed early, other than the cat crying. Maybe I can find something to write about in a longer format and see what happens to my motivation/well-being.)

    The segue here is that Tommy asked me for a progress update, and I described to him some of my struggles, and he was pretty good at reassuring me that I'm on the right path. But what helped, and is helping, most, are the short phrases—remember, when you came here, you were already above the top 95%; what's more important than the company is the team you'll be working with, etc.

    I try to collect little clippings and reminders of things and hold on to them until they stick with me. This is one of my lingering problems, actually: getting all the clustered information out of my head and into a format where I can manipulate it. I was actually considering exploring some different technologies in order to make a Scrivener knock-off, because the plethora of similar tools never seem to quite mesh up with my needs, but I know that that's probably another blind alley. If I could figure out the interaction model or something, maybe it'd be easier, but it certainly wouldn't be trivial by any means.

    It's surprising how much productive work relies around having the right information available in the right format and being able to manipulate it in an easy manner. This is probably the central problem of software, in short: while maybe 90% of apps boil down to CRUD, making interactions painless and contextually meaningful is the where interesting work happens.

    There's a link here, though: getting the right "core idea" matters as much in writing as it does in software (or mathematical proofs, or… so many things). In most mental work, there's some foundational piece that helps you stay on track, and helps the audience get in tune with you. Good writing will have a rhythm, where a long description will build to a purpose, or a witty or touching statement, and that will stick with people. Good software has a clear purpose, I think, and should be similarly scrutable to an audience.

  • Reining in perfectionism

    I have the easiest time not being a perfectionist when I'm working on something that I don't care about.

    I think this is an extension of my thinking about identity. I identify strongly with my work, more specifically my work output, and when I don't feel that my work on things that I identify with is good enough I get tetchy.

    Meanwhile, I can recognize a finished product, and get my work there much more easily, when the topic isn't something I have strong opinions about.

  • Futility; Or: Old Habits

    Despite my half-vow last week to try to write more, it doesn't seem to have worked out that way. I only consider myself to have missed a single day (Friday), but that's enough.

    Thursday I left off having torn out my user auth and dropped in devise; I was getting frustrated with it by the late hour I left, whenever that was. I finally got it working today, and even though it's one of those things that's really powerful once it's up and running, there's so much going on with rails and devise metaprogramming that it was hard to pin down where the weird behaviors were coming from.

    Long story short: getting ajax sign-in working is highly non-trivial in devise, because it has a lot of expectations for how you'll be using it. There's no easy way to shove the user's account data down the pipe when logging in via ajax, and it's not clear from the documentation what's breaking.

    It turns out, though, that you can call respond_with with a :location argument, and rails does not respect that unless the :format is html. So when trying to debug what appears to be a straightforward statement, using the suggestions written by the devise authors, you're led to fixate on a couple small lines of code that actually have nothing to do with your problem.

    This is the double-edged sword of using a framework. Once you figure out enough of the gotchas to get things moving, you get a lot of reliability and power for free, but you're forced to either use things how they intend you to (in the given examples and configuration options) or hack up enough of the framework to bend it to your will.

    Oh, well; that's out of the way. I may have to generate a toy project using straight rails and vanilla devise authentication to see how it's supposed to work, because I'm not entirely happy with what I've got now. That seems to be the way of this latest phase of my final project: I've been adding things and discovering the limitations of a lot of the more robust options out there, and it's annoying.

    One of the things I added to my portfolio recently is a set of progress bars representing my knowledge of different tools. I was reluctant to do this, because any progress number seems quite arbitrary, but I'm willing to venture that one thing that represents knowledge level is when you begin to get frustrated with a tool.

    In fact, I'll put this forward: if we're all being honest, able to use something while using the documentation might be 10% knowledge; 20% would, then, be, able to complete simple tasks without reference to the documentation. 30% might be the point where you start saying "oh, this is neat!". At 40% you feel at ease; 50% would be the point where you have the documentation open, but you don't rely on it. By 60% you forget to even open the documentation, but at 70% you've got it open again because you're trying to do something that the tool just doesn't make easy. At 80% you're saying "oh, for god's sake"… at 90% you're patching the tool.

    It's rough, but it's something. With this framework, my resume is a bit of a lie, but it's close to accurate so I suppose I can leave it. And by this measure, I'm at 80% with some things I wrote as 70%, and 40% on some 50%s.

    I'm okay with this, in the end.

< prev 11 Dec 2017 to 16 Feb 2015 next >