I've been out of school for about five years, and had several different jobs. Think the most surprising thing was that as a student I have a strong belief in what I wanted and work. I found this belief to be incorrect.

At my first job I was hired on to a team that was in my Focus topics. The majority of my days were scrum Style. I was the first developer on this team, and it took about four months for the company to staff everybody correctly. This created a moving Target for our release goals. I was working in a very large code base, on an isolated feature . We still needed several developers in order to complete our task . The majority of conversations that our team had ,including during our scrum meetings , was on addressing these moving targets. We did all of our scrum and project planning using the traditional sticky note meetings. Although I believe I learned a lot of this company, and none of it had to do with the domain I thought I would.

My second job out of school, the projects were much smaller. I had a principal investigator who would Drive the project and act as a resource to me as I needed. The principal investigator was in charge of highly technical content, the team leader was in charge of reporting and optimizing on our workflows/progress. Every small team in the company used a different technology in order to report to their team lead. I used Basecamp for one team, and jira for another . For any software I felt we needed to complete our task, I was in charge of making the engineering and Design decisions. Everybody's schedule at the company was open access, and I could add myself to any meeting, or create a new one to gain appropriate advice.

My third job was remote contract work. I worked about 20 hours a week. Here, my tasks started by moving their technology stack to the cloud, in order to better facilitate remote work for everybody at the company. I would also hold regular conference video calls with Junior developers to grow them in several programming languages, and ides, and walk through code reviews / debug sessions . When working with mid to senior-level Developers, there was a very similar workflow to my second employer. When working with Junior developers, or with the business management side of the company, I was in charge of translating our discussions into tickets and appropriately handling them.

During this time, I also began volunteering for a project where I drove around the United States Gathering raw data by photographing Street lamps. Here I wrote a support software, as the primary developer. I moved towards using as much free and simple software as possible period off and making decisions based on whether or not a novice contributor would be able to extend my work at any given time. I would also hold sessions for scientists in our group, without prior programming background, to grow their knowledge in the domain.

At my fourth job out of school, I served as a ticket processing machine. I was at a very large company, and I would show up every day, check a ticket list, and select one to work on. This was a company where human interaction did not contribute to business success. Once a week we would talk about what our blockers were. The rest of the time we would clock an 8 hour day following a ticket. Much of my work here, was in replicating data storage environments in order to address bugs.

While working here, in the evenings , I taught at a boot camp. This meant that most of my weekend was spent developing curriculum.