Posts tagged 'inventory'
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
- 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.
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
:locationargument, and rails does not respect that unless the
:formatis 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
deviseauthentication 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.
Today's partner: Marc
Today was the day of the first assessment. It went well—I was less nervous than when I did the practice assessment, which I guess is the point—but I ended up tripping on the same edge cases as I had doing the practice. Derp.
(Technical gore ahead: I was writing a
sortmethod per the instructions, specifically bubble sort—I know, I know—and wrote a helper method to implement
bubble_sort!that was called by
bubble_sort. Somewhere along the way I started getting wrong argument errors—0 for 1 or 1 for 0, depending on what I was doing at the time—and it took me ten minutes to see that I had been checking the function signatures for errors, when it was the call out to the helper method that was causing the problem.)
I felt guilty for finishing early since it seemed like most everyone else was still working, but looking around it seemed a couple people finished earlier than me. Sure enough, looking at tumblrs, another student finished absurdly quickly—the specific student I expected—and really, I ought to have been just a bit slower than him.
A lot of students have that moment when they first enter a highly selective program where they realize they're can't easily be the best anymore. I've had enough time in life to get used to that idea, but really there's little enough excuse for me not to push harder to get better. Having a decent target to reach has helped my typing speed (compared to just typing gibberish in a typing trainer) but I still have to test my assumptions about what a method can handle and what it returns too often for comfort. What I'd like, by the end of this program, is to be in the running as the "best" student and not just coast on … whatever it is that's gotten me this far in life. That will take work, and prioritization.
As any regular reader of this blog will be able to understand, most of my biggest demons are of my own creation.
We spent the entirety of the rest of the day working on Minesweeper. I can tell after a solid week that one of the critical pieces of Pair Programming is how well or poorly the personal dynamic plays out. Historically, I haven't been one who can easily convince another to adopt my priorities. This is another thing that I think raw competence can help with: people will listen to someone who seems to know what they're talking about, especially if they have easy confidence, even if that person doesn't actually know what they're doing (until, of course, that person is revealed as a sham). Further, sometimes the people you have to work with really want to go in one direction when you wholeheartedly believe that another route will bear more fruit. Wrestling with this sort of thing can be exhausting, because either you defend your idea and "win", or you realize the other person has the better idea and concede your point. Either way, you've expended a lot of mental energy.
I'm not saying, mind you, that my partner was particularly difficult to work with. I have had some amazing pairings so far, but today was one of those days where we each had an idea for what needed to happen, and we were pulling in different directions—vectored off from one another just enough that it was a challenge to move forward.
We got where we needed to be by the end of the day. The game worked, we had a somewhat clean data model, and our logic held up. We were even able to add some extensions—we changed the symbols used from rough ASCII to some nice Unicode that I think was much more readable on-screen. But toward 3:00 or so I began to think we ought to order T-shirts that say "Don't worry about that; we'll refactor later." Were this a production codebase, we'd have accumulated a lot technical debt today. Compare this to most of the projects in the first week: my style was much more comfortable and easy to read, with only a couple places (typically method chains) where I could benefit from some cleanup, and I think that's a direct consequence of having a solid idea of where we needed to be and the route we would have to take to get there in the first thirty minutes of class.
That is to say, all of our problems can be traced back to an overall bad approach to architecting the solution, specifically the separation of class responsibilities and the mechanism for passing certain objects. Prototyping, or figuring out a full schema earlier on, may have helped protect us from some wild goose chasing, but as Fred Brooks said, when solving a new problem teams should design a throw-away system first, because you're going to throw the first one out anyway. (See also: Annie Lamott's "Shitty First Drafts")
It's not easy to see your own failings, but looking around some common ones that others demonstrate include a resistance to learning skills that are not core to the "purpose" of a course (the purpose being debatable—I've been at enough colleges to know that what's on the final is a small fraction of what a student needs to learn), stubbornness about one particular approach (kill your darlings!), not being able to listen to others at all, not telling others what you're doing because it's obvious to you, not giving people the benefit of the doubt… to some small extent each of these has manifested in my time here, and I'm on the lookout for those times when I, myself, am guilty of these. Small sins can be hard to see.
It was a good day, overall. I love the people here, but the difference in energy level between a good day an an average day is really noticeable. Still, every day so far has been far better than any day of work or school until this point.