April 2019
I just completed my last day of research at A&M.
It feels strange. When I started this position, I made it clear I know some coding, but I’m not what you’d call experienced. I ended up in a coding role anyway.
Sometimes that’s what happens in life. Sometimes you’re doing something you didn’t expect to be doing because there was a need. I enjoy coding, so there wasn’t much difficulty there.
I was told that the most important thing was to be consistent about how much time I was spending at lab. If I said I’d be there 40 hrs a week, I should show up 40hrs/wk come rain, sun, snow, or exams. Should I say that I’d be there 1 hr per week, I should be absolutely consistent with that hour.
All this took was some time management. Here’s the secret about time management: just commit the time. If you re-assign the time you block out as yours, then you’ll find a way to fit what you need into that time.
We’ve already done this with work, with school. The time blocks for your classes are immutable. Treat your obligation like it’s immutable too.
The task should have been simple. It sounded simple, on paper. I came in day after day staring at lines of C. After a time, I understood them. They still didn’t do what they should have. I kept my frustration to myself – I could be frustrated on my own time. This time belonged to the lab.
And I made progress of a sort. I eliminated possibilities. I tried things and watched them fail, and knew I wouldn’t have to try them again. I had epiphany after epiphany and each led to a dead end.
Sometimes that happens. Sometimes you have a brilliant idea and it doesn’t work. The brilliance of the idea doesn’t necessarily correlate with whether it’ll execute properly.
Some of the frustration was bound up in the fact that the task was simple. It should have been simple and I was making no progress; what did that say about me? I spent months within spitting distance from a solution, I was always certain that my next idea would fix everything.
A week or two from the end of my tenure at the lab, I found out that at least two undergrads had worked at this same problem, and none of them had solved it.
The problem was not simple.
But sometimes that’s how it is too. Sometimes someone throws the impossible task at you. As I said, I’m not an experienced coder. It’s easy to find someone – even if they’re an undergrad – who’s better at coding than me. I can say with certainty that I’ve become a much better coder over the last few months. I have tackled the most bizarre pointer declarations; I mastered *, ., ->, and &. I learned structs and header files.
Sometimes you give it what you’ve got and it’s not enough. So you learn, and hope to do better next time.
---Elizabeth Broadwell
Elizabeth Broadwell is a Masters student in the College of Arts and Sciences
It feels strange. When I started this position, I made it clear I know some coding, but I’m not what you’d call experienced. I ended up in a coding role anyway.
Sometimes that’s what happens in life. Sometimes you’re doing something you didn’t expect to be doing because there was a need. I enjoy coding, so there wasn’t much difficulty there.
I was told that the most important thing was to be consistent about how much time I was spending at lab. If I said I’d be there 40 hrs a week, I should show up 40hrs/wk come rain, sun, snow, or exams. Should I say that I’d be there 1 hr per week, I should be absolutely consistent with that hour.
All this took was some time management. Here’s the secret about time management: just commit the time. If you re-assign the time you block out as yours, then you’ll find a way to fit what you need into that time.
We’ve already done this with work, with school. The time blocks for your classes are immutable. Treat your obligation like it’s immutable too.
The task should have been simple. It sounded simple, on paper. I came in day after day staring at lines of C. After a time, I understood them. They still didn’t do what they should have. I kept my frustration to myself – I could be frustrated on my own time. This time belonged to the lab.
And I made progress of a sort. I eliminated possibilities. I tried things and watched them fail, and knew I wouldn’t have to try them again. I had epiphany after epiphany and each led to a dead end.
Sometimes that happens. Sometimes you have a brilliant idea and it doesn’t work. The brilliance of the idea doesn’t necessarily correlate with whether it’ll execute properly.
Some of the frustration was bound up in the fact that the task was simple. It should have been simple and I was making no progress; what did that say about me? I spent months within spitting distance from a solution, I was always certain that my next idea would fix everything.
A week or two from the end of my tenure at the lab, I found out that at least two undergrads had worked at this same problem, and none of them had solved it.
The problem was not simple.
But sometimes that’s how it is too. Sometimes someone throws the impossible task at you. As I said, I’m not an experienced coder. It’s easy to find someone – even if they’re an undergrad – who’s better at coding than me. I can say with certainty that I’ve become a much better coder over the last few months. I have tackled the most bizarre pointer declarations; I mastered *, ., ->, and &. I learned structs and header files.
Sometimes you give it what you’ve got and it’s not enough. So you learn, and hope to do better next time.
---Elizabeth Broadwell
Elizabeth Broadwell is a Masters student in the College of Arts and Sciences