Reading Time: 9 minutes

About twelve weeks after graduating from bootcamp, I walked into the Chicago office of Pivotal Labs for my first day as a professional software engineer. Given the boundless intelligence and vast expanses of knowledge of other people I knew who held this title, I felt like an impostor. This isn’t uncommon in the tech community, especially among women, but just because it was a normal feeling didn’t make me believe that it didn’t have some basis in reality. So I decided that my best bet was to level up as quickly as possible so I could be of some service to the other engineers with whom I would be pairing each day.

I also decided to document, for each day of my first two weeks, what I studied outside of work. Many of the resources mentioned herein were recommended to me by other Pivots, to whom I owe a debt for their continuous support. I hope that this resource list, though it is specific to the project I worked on in those first two weeks, can be of some service to others who want to improve quickly in their full-time developer roles.

Days 0: Learning Go (I knew my first project would be in Go)

I studied the Go programming language before my first day at Pivotal Labs because I knew that I would be starting on a project that used it. I started at Caleb Doxsey’s book (and subsequently wrote a reader’s guide for it here on the blog!). The first real library I wrote, though, I wrote with the help of Ahmed’s binpress post on setting up Go and testing in Go. I thought it an ingenious move, and especially sensible for a programmer learning his or her second, third, or nth language, to begin with an understanding of how to write tests, rather than to learn the language and write untested code until later.

I also learned much about the language’s structure from this long blog post answering the deceptively simple question “Is Go object-oriented?” and from Mark Bates’s metacasts (think Ruby Tapas for Go). A few articles from the Pivotal arsenal itself also helped me along my way.

So that was the pre-start-date preparation. Then came Day 1.

Day 1: Introduced to many new tools. Had no idea what was going on. 

What were these new tools? They were the next ring of integration outside of what I already knew.

See, when you build your first app, you start with our own, isolated repo on your own personal computer. Maybe, to do this, you download some outside libraries: Rails or Sinatra if you’re coding in Ruby, Spring if you’re coding in Java, Django if you’re coding in Python. You may even download an IDE like Eclipse or XCode. Believe it or not, these are your very first integrations: making your code interact with somebody else’s code.

The next ring outward of integrations might include pushing to GitHub: more code that doesn’t belong to you. You need to be able to use commands that someone else made up. Then you push to Heroku, maybe. Things are getting a little more complicated. Pushing your app up to the cloud doesn’t work on the first try. You have to troubleshoot. You look for instructions on line and hope that they’re both complete and correct. If they’re not (which is usually), you have to actually read someone else’s code and figure out what they meant by it.

Well, the project that I joined, CloudFoundry’s Diego Edge (now Lattice) project, integrates with a variety of outside developer tools. So I turned to The getting started guide for Vagrant, this Upstart Wiki, and the GitHub repository for codegangsta’s cli to learn how to use them.

Day 2: Still confused. 

On day 2, I went back to learning more about the Go programming language. I had to learn what a mutex was. I had to look up RLock.

I found a fantastic site devoted to code examples in Go, and I began hand-copying them and test-driving them, breaking them and fixing them. I learned more about Go from this site than any other single resource.

Day 3: Started asking questions.

On Day 3, I gave up on trying to withhold from my pair partner how little I knew. I started asking him, “why are we doing this?” “What is that for?” “How do we make this decision?” He answered my questions happily, for the most part, and I learned a ton. Do this at your job. It’s an important part of why we pair.

Ater work I also ended up looking at more tools that we were using, from Foreman to git-duet to GoCD.

I also found this fantastic resource on dereferencing, which clarified some coding jargon for me.

Day 4: Met the PM!

Out project manager is both friendly and knowledgable, and his talk about Cloud Foundry clarified for me the big picture of what we were working on.

Day 5: Wrote my first function for Pivotal Labs. It was called warnOnError, and it got deleted almost immediately in favor of a better solution. But upon writing it, I got inspired. I asked my pair to let do the typing for a few hours. And on this day, I learned much. And helped make changes to a test suite which we will refactor on Monday.

I also asked my Office Director for suggestions on a library to write in Go as a learning tool. He said “Do something with websockets.” “What is a websocket?” “Well, that’s part one of the exercise.”

Day 6, a Monday: Got in early and started wading through error messages for a few minutes before my pair arrived. Asked questions. Started questioning the code’s design. Realized I am going to be much more effective at questioning the code’s design if I can understand it. Decided the best way to do that would be to attempt to draw a picture of it. Did not draw picture…but applauded myself for thinking about drawing a picture. I will do it over tgiving break.

Day 7: Hack day for Cloud Foundry! My primary contribution to my team (whose project was to run Diego on a Raspberry Pi) was to dredge up Caleb Doxsey’s book, Programming in Go, where I remembered seeing an example of how we could implement a library with the same name as a Golang core library without having Golang freak out (I knew I read that book for a reason!) We needed to get atomic, a Golang library that makes use of 64-bit ints, to function for diego’s dependencies on Pi’s 32-bit system. Thus, a wrapper class was born. Here is a screenshot because I think Matt Mcnew will probably take it off GitHub:

Thanksgiving break: I spent time working on a physics package. This is how I learned all the wrong ways to set a gopath.

This is the blog post that finally saved me.

Day 9: Indigo

On this day, my pair and I made a little class with some methods to colorize terminal output. We talked about how we could extract it into an external library to use on other projects. When I went home, I tried it. The library, called indigo, included a few more colors than the package we had made at work. I pushed it to GitHub. The gopath got messed up, but my coworker noticed the problem and helped me fix it.

Day 10: Worked with another new Pivot on refactorings. 

I love refactoring. I love the feeling of making code cleaner and more elegant. Today was the day that I got inspired to borrow all the refactoring books from our windowsill bookcase.

Day 11: Frustrating. Worked with the project anchor to make a PR to codegangsta/cli. I felt useless the whole time. How does one get past this?

This is something that I am still figuring out, but it was an instructive exercise to face that feeling of uselessness. All programmers feel like this sometimes. When working in a pair, one has the luxury of asking questions in this situation. But if one works alone and feels useless/unproductive, there are still things to remember. I was reminded of these the very next day.

Day 12: AWS integration. My pair was just as confused as I was. However, instead of getting frustrated or feeling useless, he kept a sense of humor at the situation and just kept trying new things. The experience made me realize that sometimes, no one exactly knows how to do whatever we’re doing.

When that happens, we can Google information about the topic and try out what we read, or we can form hypotheses and test them on our own. But the trick is to persevere. One can do this either by having a sense of humor or by remembering that failure is progress: it’s ruling out one of the many possible reasons something doesn’t work, which ultimately does bring us incrementally closer to the one that does.

On this particular day, we got the thing working with 30 seconds left in the workday. It rarely works out so perfectly, but on this particular occasion, I like to believe that the universe sent me a day of frustration followed by a just-in-the-nick-of-time success to remind me of the critical importance of maintaining an attitude of curious perseverance while programming. No one has all the answers, but the best programmers derive their satisfaction from finding out the answers they don’t know.

So those were they key resources and lessons from my first two weeks at Labs. I’m now about six weeks in and about to switch to another project, so it seemed appropriate to post this before that one starts. Maybe there will be a post in the future about switching projects :).