Matt-Weiss

Keybase proof

I hereby claim:

• I am matt-weiss on github.
• I am mattweiss (https://keybase.io/mattweiss) on keybase.
• I have a public key ASDjOpddRYv3MeTYZxUJynXU5k-izWQbvOmferUDV5OuSgo

To claim this, I am signing this object:

Matt-Weiss

What motivates you? In my work, I'm motivated by the desire to do things the right way, and I tend to stay on a problem until all the details are right, for better and worse.

How will you keep yourself going when faced with rejection in the job search? I already got one rejection after making it to the final round, and it was pretty rough. My group for Mod 4 job search (Carrie, Corey, and Ian) were extremely helpful when it came to getting over it. I'll continue to lean on them to avoid the creeping self-doubt that comes with rejection.

How will you hold yourself accountable to your plans? (Ex: Attend Mod 5, meet with cohortmates, attend Kayt's coffee shop hours, etc.) I believe that a group of us from the cohort plan to get together for the Mod 5 sessions, and even get together a few days a week because we all tend to get distracted at our respective homes.

How do you like to communicate?

Matt-Weiss

Calendar

Short Answers

Why do you want mentoring in the job search?

Because I've always just walked in to a job and said hey would you hire me? And they said yes. Seriously, though, the whole process is new to me - finding contacts, doing cold outreach, customizing a cover letter - so I need all the help I can get. I want to do this well, so I want to learn from people who have been through it before. Also, I’m still unsure of how to talk about myself and my skills (though I’m getting better from past help). I need guidance about how to decide if I’m qualified for particular listings - or how to know which jobs to apply for.

How will you hold yourself accountable to balancing time for your job search and following your mentor and group's advice?

Matt-Weiss

Values, Types, and Operators

My main takeaway from this first chapter is that while very similar to the Ruby we've worked with so far, there are some very specific differences that could trip us up as we start working with JS. I was a bit surprised to see Infinity included as a "number" that can be worked with, as well as NaN which could return rather than an error.

Unary operators seem to be what we've just called methods (particularly the built in methods), while ternary operators look like a nice opportunity to dry up code where we would generally have an if/else block.

Type conversion may take some getting used to. Overall this chapter was straightforward and I'm confident in my handle on these points.

Program Structure

Matt-Weiss

My initial takeaway from this chapter is that I immediately got a clarification on return vs side-effect that I mentioned in my previous gist. I hadn't made the connection at first that ruby does the same thing (puts returns nil, .each returns the original collection). Defining a function has more complex syntax than defining methods in Ruby, but is functionally (pun intended) the same.

I was a bit confused by the hummus example. I understood the scoping, but wasn't sure what it would look like when executed. I got it when I mentally separated the ingredient function from the hummus function with some whitespace. What are JS's conventions surrounding whitespace within functions? Arrow functions seem to be shorthand that makes the code tough to read. The author says we'll dig more into them in chapter 5, but my initial impression is that these won't see much use in empathetic code. We had a lesson on the call stack in mod 1 and I'm glad this gave a review of that using different language. Seems to be someth

Matt-Weiss

My main takeaway from this is that the concepts we covered in Ruby in mod 1 remain unchanged, but there are some particular idiosyncracies in JS that we need to be aware of. The things that stood out are:

• the use of "let" to define a binding (variable). I also like the tentacle analogy they made here, and think it may help mod 0 students to hear it regarding ruby as well.
• Binding naming convention is going to take some getting used to. bindingNameHere
• Looping appears almost identical to Ruby
• Hopefully in future chapters I see more examples and clarification on side effects vs returns

Matt-Weiss

My main takeaway from this first chapter is that while very similar to the Ruby we've worked with so far, there are some very specific differences that could trip us up as we start working with JS. I was a bit surprised to see Infinity included as a "number" that can be worked with, as well as NaN which could return rather than an error.

Unary operators seem to be what we've just called methods (particularly the built in methods), while ternary operators look like a nice opportunity to dry up code where we would generally have an if/else block.

Type conversion may take some getting used to. Overall this chapter was straightforward and I'm confident in my handle on these points.

Matt-Weiss

I've been considering a home gardening app that would integrate hardware for monitoring and maintenance. Rob (1903 BE) approached me about building something for his home garden, and I recall that a past project had a similar feel, but no hardware integration.

A pi can run Node.js as a server, and would operate as a microservice serving up data to our main app. The main app could store and provide data about current and past conditions. There could be a heavy use of background workers and asynchronous programming for scheduling tasks.

The way I envision it, the hardware would only be receiving and executing commands from our main app, keeping the hardware element lean, despite its complexity. This would open us up to the possibility of having a weather element built in, with an algorithm that would plan tasks based around the forecast.

It would also be an interesting challenge to incorporate an interface into the hardware that would display relevant data and allow for changes. Watering the plants manuall

Matt-Weiss

My outreach and networking plan already goes beyond one person. I'll try to cover the questions in the template, but it may look a little different than expected. I currently have a 3 prong approach to networking for the job hunt.

Part one is leaning on 2 close friends in the industry to be aware of openings in their companies that they could recommend to me and recommend me for, as well as help me with interview prep. One works for Connekt, a startup that builds apps for smart TVs, and has hired 2 Turing grads already with great success. The other works for Charter Communications building Roku apps, and Roku devs are hard to find. By working with them and gaining a familiarity with their product, I may be uniquely prepared to land a position there.

Part two centers on the dream job at ULA. My wife has a friend who works there in accounting that is very outgoing and makes friends easily, so I've talked to her about getting to know some of the engineering team so that introductions could be made over coffee

Matt-Weiss

I'm a tinkerer, experimenter and innovator. I'm driven by a desire for efficiency, and believe that small iterations towards a solution are better than no change at all. I'm here at Turing to raise my value. My previous job working at a landscape supply parts counter scratched my problem solving itch by having customers come in with a vague description of their machine and problem, and leaving with the part they needed in hand. However, it wasn't a fulfilling career path. A couple years ago I invented a product, a tabletop gaming accessory made of wood and magnets that was modular and multifunctional. We ran a Kickstarter campaign that was successful but unfortunately could not parlay it into a long term success. However, the experience showed me that I had a wealth of unrealized potential. Taking the lessons learned from that and my desire to continue doing technical innovative work, I decided that going back to school for software engineering was the right choice for me. Building things and problem solving