Mike Schutte tmikeschu

Interview Reflection (Fireside Chat w/ Ingrid and Jeff)

It was very refreshing to listen to Ingrid and Jeff talk about the interview process. In my experience, the mind can really run wild when thinking about jobs from the junior perspective. There is so much we don't know, yet we make all these assumptions about things like why a company hasn't responded to an email, what they are actually looking for, and so on. Hearing these two experienced developers talk about what really matters (including attitude and manners) was very grounding for my perspetive. I'm excited to move forward in my job search with these things in mind. Specifically, I'm going to worry less about appearing more technically competent than I am, and focus more on showing my natural love of learning and empathy for others.

Mike Schutte: Module 4 Action Plan

Module 4 Goals

Secure a job offer by Week 6.

Strategy To Achieve Goals:

Every Monday morning, he sends three emails (either cold outreach or follow up) ( ~1 hour )
Every Tuesday at lunch, he meets with Lucy to talk about and research remote jobs ( ~1 hour )

Group: Nick Erhardt, Nick Gheorghita, Jesse Shipley, Brett Rivers, Mike Schutte

Guiding Questions to Define The Relationship:

What are your learning goals for this project?

Jesse: external API's and TDD (robust) Nick G: building services (POROs) Brett: DRY DRY DRY (will be challenging due to scope of project) Nick E: pair programming with each person to learn nuances, action-cable in rails 5 (non-refresh render)

Guiding Questions to Define The Relationship:

What are your learning goals for this project?
What is your collaboration style? How do you feel about pair programming vs. divide-and-conquer approaches?
How do you communicate best? How do you appreciate receiving communication from others?
How would you describe your work style?

The Way of the Bullet Journal

This technique is a tool. While I can't say the bullet journal is the best for everyone, I can say that learning to export data from your brain to other systems is essential for being a creative and productive human being. If you walk away from this unenthused by the bullet journal approach, I encourage you to still take seriously the habits it helps promote.

You are a student. You have code to write. Jobs to find. Bills to pay. Life to figure out. Friends and family to love and occasionally say hello to.

All this is to say: you have too much to do for your brain to handle all by itself.

There are many productivity tools that help alleviate overload of the brain. I do not promise this technique will save you, or even remotely help you, but I do promise to provide you with the information you need to get started and decide if it's right for you.

Summary

I am a lover of learning and craft. In both of these pursuits, I find tremendous amounts of fulfillment and energy. Because of this passion, I can maintain positive momentum in moments of adversity and failure. I seek a team that values quality, learning, and humility.

At the end of the day, I need to be surrounded by people who love the craft of software development as its own end.

What I Know

Software development
Sociology

ReciPlease:

curated recipes, custom ingredients, curiously easy

Goals for each member

Anne = love to try something new overall
Amy = do/be in charge of some front-end stuff
Kyle = pair time to figure out how others have been approaching Rails (perhaps some front-end stuff), incorporate some cool gems to improve workflow
Schutte = not use bootstrap

The Messenger: Robust Testing with One Factory Girl Variable

Prologue: "The Messenger came along and changed everything. Testing will never be the same." -Elon Musk (probably)

We all know test-driven development is essential for high quality applications. We also know that we want at least somewhat robust data in our testing environment. What is the best way to populate test data that simulates production level databases? Well, I don't know about best, but in the rest of this article I'll show you a way that I find particularly beautiful. Time to meet The Messenger.

A: Opportunity for improvement

Jason and I could have split out our analyst class more with def_delegators. We still had a couple hefty classes with gray area in terms of responsibility scope.

I also think we could have done a better job implementing mock tests somehow. It seems like a lot of the integration tests would be ideal for this, but implementing the mock was much harder than expected (e.g., method calls multiple mocks that lead to other methods).

B: My role

From my perspective, my role was to continunously come back to the macro/conceptual view of the project in a way that would define our next steps more meaningfully. I played more of a lead role in refactoring, breaking out logic, TDD, but once I set a basic model, Jason was great at future iterations of similar concepts.

	class Merchant < ApplicationRecord
	has_many :items
	has_many :invoices
	has_many :invoice_items, through: :invoices
	has_many :transactions, through: :invoices
	has_many :customers, through: :invoices

	def customers_with_pending_invoices
	Customer.find_by_sql("select customers.* from customers
	join invoices