Tomorrow will mark 3 months as a full time engineer and as if on cue, I had a the most perfectly awful but wonderful day. A frustrating but deeply satisfying day where I struggled, celebrated, cursed, ordered pizza, high-fived and wrapped up before the hours became single digits again.

I say this was on cue because of everything I’ve learned in the last 3 months, how to deal with pressure has been the most vital. So in preparation for my 3 month check-in, I thought I’d reflect on some of the epiphany’s i’ve had along the way.

So here goes:

1. Make a list of everything you learn every day

I began doing this in a way, first by starting this blog, then later by writing super detailed training docs for myself, and most recently, a list of every new piece of information I pick up. The biggest mind-fuck I struggled with was feeling buried in the learning zone and not able to produce output. I discovered pretty early that “learning” on the job, while a great investment in your future, feels absolutely worthless at the end of the day if you have nothing to ship. Hence the list. The list also started serving as a useful data source. I started keeping track of what source files or websites were associated with something, so I could grab an example of it more quickly. Because as satisfying as it is to close tab after tab of stackoverflow threads when you figure something out, nothing is as sad as realizing it actually didn’t work and trying to find that “one” thread that had the answer. But at the end of the day, it just helped me sleep better on nights where I went to bed without shipping anything. I’m big into cold hard data. And looking over an extensive list of programming concepts I’d conquered, helped me see learning as progress.

2. Commit early, commit often. Not for just for git posterity, for your sanity

At the end of every week, I send my boss an email describing my progress, plans for next week and fires. It’s a bit corporate, but it’s good to document your work, lets you control your perception a little easier and managers tend to like it. About 2 1/2 months into my engineering gig, my boss asked me to include links to my PRs with the emails. I took it a step further and started committing small milestones, even if it wasn’t ready to ship, and tagging the commits to the emails. One of the worst things I struggled with was anxiety around having nothing to send my boss at the end of the week. Once my manager suggested I include PRs, I realized I could use leverage github as a record keeper and was able to relax… somewhat.

3. Break up your time into similar tasks

Probably the toughest thing about engineering is the never-ending amount of things to learn. Learning a language, building an app and conquering some coding questions is such a tiny part of programming. And it takes a really, really, really long time to find overlap in any of it. Which means it takes that much longer to feel like you’re making any progress. which makes it that much easier to want to give up. One thing that helped me was breaking up the week into common tasks so I didn’t have to deal with as much context-shifting. I spent most of the Monday through Wednesday working on my projects.Then in the evenings, I would pick something I didn’t feel solid on but had managed to get working and dig deep. I also dedicated time to general topics. Mondays was algorithms, Tuesdays was rails apps, Wednesdays was linux and git flows. Thursdays, I scheduled meetings with people to help me with stuff I was struggling with (side benefit was getting to temporarily put down something frustrating without feeling guilty). Thursday afternoons I would try and review other people’s code and stalk the slack channels to learn what was going on in the rest of the company. Fridays after the deploy lock, I’d pick a couple things from my “list of shit i heard someone say and don’t know what it is” and read up. As valuable as context-shifting is for an engineer, it’s terrible when you’re trying to learn. So I forced it.

4. Commit to the long hours

This seems obvious so allow me to explain why I’m including it. So, learning this shit is absolutely brutal. I pride myself on being extremely strong when it comes to learning new things. Moving around every 2 years growing up has left me with virtually no comfort zone. And I was still surprised at how brutal this is. The brutality was exhausting. And after 8 hours of laser-focused thinking, interrupted only by fits of rage, I would leave the office, come home, look at my computer and the anxiety would overwhelm me. And I would feel sorry for myself and decide I’d had enough torture for one day.

But I’d go into work the next day feeling behind, feeling even more pressure to get through things and much less able to handle setbacks. And I started making excuses. That everyone else had so much more experience, they never had it this hard. They got to learn in school, where you’re supposed expected to struggle.

Then one night, I was feeling so sorry for myself that I decided I was going to stay at the office until I finished something I was stuck on. I assumed it would take me all night. It did. But as I was walking home around midnight I realized it was the best I’d felt in months. There was pride in surrendering to the torture and coming out the other side. There was something relaxing about letting myself “take all night” on something. My self-proclaimed “success secret” is to make up for whatever you lack by working harder than everyone else. But somewhere amid the stress and identity crisis of not feeling smart for the first time in my life, my ego got the best of me. So, the lesson really, is to lower your standards for how you think you should be doing and just own your own pace, no matter how excruciatingly slow it may be. And if that means 15 hour days for a long, long time, then cancel your gym membership, stock up on redbull and get your fucking head down.

5. Learn early when to ask for the help and when to put time in the hurt locker

There’s two ways to get something done when you’re new; you can ask for help and or you can figure it out yourself. In engineering, the latter path can add days to a project. But you can’t always rely on the former and there’s an art to knowing which which to choose when. One thing to do early is setting yourself up with a good network. Get some people to commit to helping you ahead of time. Make friends in the beginning and take some time to figure out who the strong people are. Then play around with a mix of suffering through 6 hours of googling and bugging your coworkers for answers until you find the balance. And then let me know if you ever figure out that balance cuz I’m still lost af ; )

6. Don’t neglect your sanity

One thing I noticed immediately after my first week on the job was that how differently i felt after work. I was *exhausted.* And not just a usual “work tired.”  It took me longer than usual to shift from work to play mode. I struggled with small talk. I also started forgetting to eat. I would get buried in an intense problem and be so enraptured that it was suddenly 9pm and I hadn’t left my desk. Because of the nature of my projects, I had far fewer meetings than I did in my previous life and often would go an entire day at work not talking to another human being. it did weird things to my head. so i started doing crossword puzzles. like a lot of them. in 3 months i did the last 2 years of the New York Times. it helped me go from intense hard problems, to lighter problems, as a buffer before things go into social mode. I also make it a point twice a week to walk around the office and be social and get no work done and take care of my head. because it’s important.

So that’s my 90 day reflection. i know there’s a lot more to figure out but in keeping with the theme of this entry, i’m going to have a glass of wine (okay, continue drinking the glass of wine i poured when i started writing…okay i’m actually on my second glass). I’m gonna be proud of what i’ve learned, send it to a few friends so i can feel some connection and go watch nature documentaries.

Oh right, the Yak. Yak shaving is a term I learned a few weeks ago that describes the seemingly useless dependencies that derail you from the task at hand. Best described here:

I’ve made peace with the Yak.. or maybe just temporarily destroyed him in battle… either way, to be continued…

today i learned that memory and disk space are important distinctions and the difference between a source file and an executable file. I needed to know this to troubleshoot a gem install. which was step 1 of using a fake test server. which i need to TEST the FIRST piece of code i have for a much larger project. which already took me a week and a half to get working. because i had to back the fuck up and learn a bunch more stupid basic level ruby.

i feel like someone handed me a scalpel and said “go figure out how to perform this simple surgery, it’ll be challenging but you’ll figure it out.”

and then i’m like “whoa! there’s blood under here! I better figure out what this stuff is made of.”

and then i’m like “OMG CELLS ARE A THING!”

and then i’m like “uh oh, everyone else seems to know cells are a thing. i better keep this to myself.”

but then i need to figure out how mitochondria work.

but i don’t know the word mitochondria.

i just know it as “the purple thing that’s not working right.”

and the internet doesn’t have any results for “a purple thing.”

cuz everyone else knows the word mitochondria.

and also to find it, i really need to know what a membrane is. and an organism. and a eukaryotic cell.

which are all new words.

meanwhile my patient is bleeding out.

so i ask another doctor.

and he tells me it’s easy, i just need to make an incision.

which doesn’t seem to make sense considering i thought i was talking about cells.

so i wonder if maybe i’ve been wrong about what the word incision means.

but i’m standing there with a scalpel in my hand.

so i figure i better the fuck not ask what an incision is.

then he goes back to his own patient.

and people are coming in and out of the hospital. arriving sick, leaving better.

and i’m still on my first patient.

and i can’t let him down. so i keep googling.

and finally i figure out what the purple thing is.

and temporarily stop the bleeding.

and he’s not completely healed yet. so i have to come in and do it again tomorrow.

and i want to practice at home. i should be practicing at home.

but i can’t bring myself to face all that stress again. so i take a night off.

and start again tomorrow.

hoping i don’t kill him this time.

sorry, that got carried away and super dark.

new strategy is to live at the office forever. if it takes me 10 hours to do something another engineer can do in 10 minutes, then i will work another 10 goddamn hours.

a;lsdkfj

🙂

I mentioned back in february that I was working on a video montage about what the last year has been like. I really wanted it to be more of a comedy but it turned out to have more of an “inspirational” vibe. Go figure… Gotta let the art be what it wants?

It was a ton of fun to film and got me over a slew of learning curves I’d been putting off for a while; buying a nice camera, learning to use said camera, video editing, sound editing…

so…enjoy 🙂

Also, any feedback you have on the Neat Dude beanie prominently featured in the kitchen shots would be greatly appreciated.

Me: Can you help me with the S3 SDK? Trying to upload a file to S3.

Friend That Works For AWS: Did you read the tutorial?

Me: No. Not sure where to start. Can you walk me through creating a new bucket?

AWS:  AWS::S3::Bucket.create(‘my-new-bucket’).

Me: And what is that?

AWS: It’s an API. Called “create new bucket”

Me: How is that an API?

AWS: Now you’re messing with me 🙂

Me: That doesn’t make sense in that context.

AWS: API is the thing you call. The SDK has the API calls in it.

Me:  Sounds like a fancy word for a library full of functions.

AWS: Application Programming Interface.

Me: That makes no sense. You can’t “call” an “interface”

AWS: Yes, a set of methods is an API.

Me: Then it’s not really an interface, it’s a library.

AWS: KARI STFU. THE NOMENCLATURE DOESNT MATTER

Me: YES IT DOES. YOU CAN’T JUST GIVE SOMETHING A NAME THAT DOESNT MAKE ANY SENSE.

AWS: In computer programming, an application programming interface (API) is a set of routines, protocols, and tools for building software applications. An API expresses a software component in terms of its operations, inputs, outputs, and underlying types.

Me: By that definition, Rails is an API.

AWS: Yes. It is actually.

Me: I hate you.

AWS: Get used to it. It’s everywhere.

Me: I’m going to make a new database and call it an application where all the fields are called methods. And you’ll query it with my_SDK and it’ll live on a server that’s called an API.

Me: #patent

Me: I’m in so over my head…