Posts tagged 'weakness'
-
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.
-
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.
-
I don't deal with stress well. I like when I know what I'm doing and when things are working well, but struggle to overcome impasses.
I don't know if there's a known thing called "coder's block", but I have, in the past, pooh-poohed writer's block. There's always something to write, in my head, and if I have problems I just read other people's work and get ideas there. However, I've never written a proper story, so I don't think I can properly state that I know what writer's block is like.
On the other hand, I've been dealing with coder's block for the better part of a week.
One reason is that I'm really not excited about the CRUD aspects of this project. I thought I'd be able to plow through much more easily than I have, and while I now am happy with the framework I've developed, the knotty puzzles are pretty much behind me (for now?).
I spent some time cleaning up other things, and there is some value in those. I've learned quite a bit—from playing with Bootstrap to getting familiar with Sass, solidifying my knowledge of Javascript fundamentals, and so forth—and I've put some polish on things that don't really matter? I'm consolidating, but there's a line where you realize that your "polishing" bears a strong resemblance to "work avoidance".
So, you can spend time doing other things, but you can't, because the work you really need to be doing isn't going anywhere. All this stuff would need to have happened in time, but I can't say that it needed to happen now.
By contrast, though, I was spinning my wheels last week. I'm not so much anymore—I've gotten more actual useful work done on my project in two hours today than in any eight last week. Why is that, I wonder?
-
I never quite accomplish what I wish to. There is a long list of stuff in my head that I can never seem to get out. I know this doesn't make me unique in any way, but so much of my identity is tied up in the belief that I have a lot to offer the world, and I just need to get it out, so it's frustrating to constantly hit the wall.
A core problem seems to hit when I regress. I start down what should be a productive train of thought, and find myself thinking about bigger and bigger ideas, or at least more and more abstract ones, until I get to a point that I'm trying to solve all the problems of the world at once.
People don't really care about big ideas if they can't see a solution. The same reaction I give students when they tell me they know the material, but they just can't solve the exercises, is what others rightfully give me. In the meantime, I recognize that doing is more important to me than thinking, at least from an emotional perspective, but I also find myself questioning the merit of the things I do when I simply act. When actions don't fit into a larger context, they don't seem to make me better or lead to anything. This is how I believe people waste their lives.
-
I'm trying to take
gitvery seriously, which means that every time I wrap up some context, I'll try to stage it separately and commit just that portion of the project. I was joking with someone today that others' commit messages consist of "Monday", "Tuesday", etc. I've made 55 commits (according to github) in the past two days, which is something. party hornSo, what'd I do today? Well, there was a bit of yak shaving today, although admittedly not as much as yesterday—I'm making a lot of progress learning the details I need to know to accomplish what I want to do—but there's always more to learn. Some time around lunch, I broke down and started trying to hammer out as much as I could as quickly as possible, and damn the looks… for the most part.
So, in terms of physics, my position is way behind where it could be—I'm jealous of the guy who's got robust rspec unit tests running—my velocity is just about what it should be, and my acceleration is going really well. I think… I have a hard time perceiving the struggles of the people around me, and seeing which things I'm doing better than them, but every time someone transitions from Rails to Backbone I get a bit more self-conscious.
This seems to be a theme with me.
It's not that bad. Honestly, most of the pressure I'm feeling comes from the instructors. I know they mean well, and I know I should work faster and get over some of my hangups, but … I guess I'm overcoming my baggage in terms of how I attack problems. This is my problem and I'm personally invested in it, as opposed to some of the "toy" work we'd done, and I'm much more certain of the architecture and layout of all the tiny pieces. When I want to add something, I know which three files I need to tweak to make it happen (most of the time…), I open those windows, make those tweaks, commit, and am off to the races.
Contrast that with the general befuddlement I'd often experience when following along with some of the projects' specs. It's kind of nice.
Oh, I neglected to comment on my actual workflow. So, among the panes that I keep open are a small set of text files for "overall TODOs" (e.g. architecture and styling), for "upcoming TODOs", which are tasks that are a bit less ambitious than the first set but don't fit nicely into a smaller context (generally, I have 5-8 of these at a time), and then individual TODO: comments inside the source files. These last identify places where my code is broken but I can't do anything about it (I don't have the skills/time to fix it) or where there's an edge case that's known and I know how to address it, but it's not a priority at the moment.
This seems to be working pretty well for me, at least today. It certainly helps me shed the weight of tangential thoughts (helping me maintain focus on the matter at hand) and have a good place to go to feed me when I hit one of those transitional lulls.
They told us to try to finish our rails apps tonight. I got all my models composed, and have a lot of headway on my controllers; my views are sparse… and I need sleep. There's only so much that can be done in a day, although I could keep working.
-
Today's partner: Jake
Yes, you read that right. We didn't travel back in time; to the contrary, time keeps marching forward (despite the date overflow back to Jan 1).
Today was the day we put Jonathan's lectures on CSS to use. It was kind of funny; I made sure to do my best to read the lectures for the day last night, and by this morning not only had I been assigned a different partner, but the readings and project were different. It turns out that JT was putting some final touches on his version of the CSS day, and it was (I believe) a much more effective day than what I thought we would have been doing.
On a plus note, today was much more approachable than Backbone has been, for me. Boxing off elements and figuring out style hierarchies is something I'm capable of wrapping my mind around, and despite some of css' foibles it was easily in reach. Per usual, coming up with descriptive names for things was challenging—Jonathan is of the belief that you should add
classes to DOM elements early in the design process, even though we often weren't sure what role something would be playing—but this is one of those times that the cmd-D shortcut, for selecting the next token in the source file, came in handy. You see, any time you decide that something isn't named quite right, you can simply find the first occurrence of that name in your source file and mash cmd-D to select subsequent items, then overwrite them all at once.There's something very satisfying about using eight or more cursors to overwrite some chunks of text. :D
I'm not totally solid on CSS, but I am much more comfortable with it than I ever have been with Backbone. Really, I would not mind doing more of this—converting wireframes into semantic websites—but I know that this is not, by far, my strong suit. After all, I didn't have the skill to actually create a design from scratch, only to make it into semi-sane CSS, and I can't believe that that's a skill that's so much in demand that I can make my mark there.
It's fun, though :)
Tomorrow's the Backbone assessment, and per usual, I feel like I understand it a lot more than I have so far. I still have issues juggling state between all the separate files, but I was able to cobble together 100% passing specs by the 50 minute mark (out of an hour) despite not always knowing exactly what the pattern I was trying to replicate looked like. Looking at the practice solution and my own code side-by-side, there were maybe two redundant lines, and very few differences otherwise.
-
Today's partner: Wes
Thank god for Jonathan's CSS lectures.
We skipped the W6D2 content, which was supposed to be on CSS, but last week JT held lectures on CSS at the end of the day each day. Today, we took pre-baked JS solutions for the Tic-Tac-Toe game and Towers of Hanoi and made "visual" versions of them in the browser by using CSS selectors enabled by JQuery.
Holy crap, that paragraph was a mouthful. Basically, instead of using (e.g.) Canvas (which, it turns out, is a difficult term to Google), or a text-only terminal to represent our game state and to select pieces/grid squares, we contrived to capture mouse clicks on a simple webpage, and then to draw game states using document properties of the webpage.
The most important things we learned were the varied uses of JQuery selectors, and how to do basic styling with CSS. By the end of the day, the most we were struggling with were edge-cases in the implementation of our final project, Snake; JQuery and CSS were well under our belts.
I've mentioned before that my memory is one of my best character traits. Well, after this week, I'm realizing that (syntax?) debugging is also another skill I have that others don't always. It's not entirely clear to me whether this is because of my deliberate pace when learning (and the consequent, presumably, deeper understanding that I can achieve), or if I just have more practice/skill than others—or if it's just because I only try the right thing after I've tried all the wrong things. No matter the root cause, I've been happy with my ability to read a stack trace or error message and smash the bug in question, most of the time.
Wes, on the other hand, is much better than I am at identifying a minimum testable product. There were a couple times he had me tie something off and open it in the browser, and while I wasn't immediately certain what he was doing, as soon as we nipped a problem in the bud, I understood. I'd like to add this to my toolbox, too.
Storytime: So it turns out that I'm not very good at games such as chess. My friend tells me that I have a comet-sized ego, and this was nowhere more visible than how I'd play games, especially when I was younger. At the time, I would play a move that could only be considered good if my opponent had no skill whatsoever… but my opponents were never were so bad as I wanted them to be, and inevitably they'd paint the floor with me.
Typically, I want to code for a couple hours, and then run my code and have it be perfect. It is, perhaps, a skill to have the humility to know that you're not as good as you want to be, and (especially when testing carries low overhead) to test your assumptions at good breakpoints. "Measure twice, cut once."
Or, in my case, measure three times, take a break, measure again, and cut once.
-
Today: solo day
The project today was solo.
Besides seeing that, still, I need to practice more, there wasn't much that was tricky today. Everyone else in class seemed to be progressing much faster than I did - and given how many people got to the bonus material before the end of the normal class time, I know I can do better. Or should.
The thrust of today's work: make a rails app that does the standard stuff for user creation and session authentication, and then create bands, albums, and tracks, then permit users to comment on tracks, and so on and so on… nothing earth-shattering. The migrations and models are old hat by now, controllers are pretty straightforward, there's still more to be learned about creating proper views… but it's very evolutionary.
Again, nothing was tricky: left to my own devices, I almost never need to ask the TAs for help. I can't tell if this is a bad thing. Carolina remarked, early into working at my last job, that I need to learn to ask for help earlier in the process of trying to attack a problem, and maybe she's right, but I never feel in over my head, just slow.
Nonetheless, by 4 pm I was moving at a steady clip, and was knocking out stuff left and right. Honestly, I was trying to be slightly too abstract before noon (creating partials that didn't need to exist in ways that didn't make sense) but by 4 I was doing a lot of rote fixing of the same stylistic flaws across three or four or six different files. When would have been the right time to refactor? Some of what I was doing needed to be done right then in order to test functionality; other stuff, not so much.
It's all very engaging, which is a plus, but there's only so much more time I have to commit to this. Ned or Kush said that we should be committing 80-90 hours to a/A, and that works out to about 12 hours a day doing something a/A related. If I get there at 8(:15) and leave around 8 pm on the weekdays, I'm getting well toward 80-90 hours per week, but then I could be doing more on the weekends to round it off. Does that 90 hours count lunches? Does it count time not actually in front of the computer?
One of the weaknesses of the pair programming model is that if you're thinking about one half of a given project and your partner is thinking about other things, it's possible to not quite totally learn something you'll need to know. After typing
BCrypt::Password.create(password)about ten times Friday, I wasn't able to remember that string of tokens today. This might be problematic.As I knew before applying, one of my weaknesses is syntax. I seem to have the architectural details overall pretty solid, but I spend five minutes here and five minutes there playing with the syntax of a command, first trying to make it work, then trying to make it better, so as to not have to pay technical debt down the road, and what I do learn I learn very solidly. But I just don't have the speed yet.
-
Hoo boy. I can feel stuff stacking up.
Checkers was basically a repeat of chess, but simpler. I thought I had learned a lot, but today was a real learning day.
For background: it was our first solo day, and without anyone next to me who was depending on me to drive/navigate, I was somewhat slow to sink my teeth into the project. I thought I was sticking to the spec, but I spent a long time running off on tangents, trying to get minor methods to do what I needed in order to be able to get printable output as quickly as possible.
This was a mistake.
I've come to suspect that my working memory isn't great, and that that's why I try to recursively abstract problems—I can only manage 5 +/- 1 ideas at a time, and the more high order the chunks are, the bigger the idea I can digest.
So when it comes to seeing how different parts of a multi-class project will fit together, I miss things that become both obvious and painful a couple hours in. (Debugging complex interactions in similarly challenging for essentially the same reason.)
Today's big pain: I misread the spec, in a way. There are basically three general ways to send moves around the core class of the checkers project: as positions ([1,1] to [2,2]), as differences from a starting position (start, [+1,+1]), or as some general class of methods I will refer to by the technical term "totally effing stupid".
Yesterday we generated moves early, and only passed moves around. That worked well; we had a simple wrapper on the class that translated algebraic notation ("b3" = [2,3] = [1,2] in 0 indexed arrays) to the position references we were using, and then we only passed those around.
Today, because I misread things, I started out passing around differences, then I realized that I needed moves, then I tried to simplify things using one of the last methods, and that was, predictably, totally effing stupid.
I got a lot working, but my errors weren't working right on certain literal edge cases, and finally I threw in the towel at 9.
Lessons "learned":
- When doing solo work, pseudocode flowcharting might be necessary for someone like me to avoid super-dumb mistakes
- I need to rubber-duck, either with a human, or with a rubber duck. I think I'm going to put my plush octopus next to the home computer. She needs a name, though, so I can talk to her properly. (Completely serious, by the way.)
- If I'm going to rubber duck on solo work, I need to not be in a place where I'm going to be self-conscious doing so
There's more, I'm sure, but I have a ton of readings to do before 2 am, god willing.
"Am I the one who holds good pairs back?"
-
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 implementbubble_sort!that was called bybubble_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.