jdursema · August 14, 2017 05:54
diff --git a/JDursema_CareerDevelopment b/JDursema_CareerDevelopment
 "6. Understand that Code is cheap." I think this is something I will definitely need to work on in the next couple months. When I put effort into something, like anyone, I tend to get attached to it. I think that learning when to scrap a piece of code and when to keep trying to make it work will be essencial to learning to code.
 "1. Use google very aggressively." My friend who worked in the IT department once said "I don't know more about technology than most people, I'm just better at googling than them". While doing the pre work so far, I've found myself turing to google a lot to find out more about something I didn't understand in the book. With so many elements and names to memorize, I think google will be a really useful tool. 
 "26. Act as a leader and not a boss" I think people often don't differentiate between being a leader and being a boss, however it's an important distinction. A boss will tell you what to do, while a leader will be down in the trenches with you showing you how it's done. A leader never assigns something to someone they wouldn't do themselves, a boss might. 
 Side note: "22. Skip a lot of meetings" This rule is my favorite. I hate large, unproductive meetings. I think they are helpful to make sure everyone is on the same page and everyone understands the end goals they should be working towards, but most of the time they're used so people to show that they're being productive. 


 Checklist are helpful because they keep you organizes, stops you from making assumptions, and it stops you from making stupid mistakes. With coding there are so many small details that it's easy to make simple mistakes, but that mistake can totally throw off your code. Having a checklist to go through when something is wrong in your code makes it easier to find mistakes. Also, having a checklist helps you stay organized. Instead of having to worry about what I am going to do next, writing it out on a checklist, helps me stay and the moment and feel productive when I get to check something off.


 What is your impression of strengths-based development? What questions do you have about this kind of development?
 I've hear of the strengths-based developement before and it sounds like a really interesting concept because it empowers employees to use what there good at (which is also usually what they love to do) to get something done instead of having a right and wrong way to do things. I think it would work in the technology industry because How do you get things done if they don't play to anyone's strength? Is this a viable solution for small companies, since they don't have as many people so most employees need to be multi fasited?

 What do you feel are your top strengths? How do you know?
 Working with other people and breaking down problems to find solutions. Working with a team helps me stay motivated and also, I'm not confrintational and relatively good at communication which helps me work with other people. The subjects that I was good at in school were math, history, and public policy (my major) all of which require you to analyze a problem whether it be an algebra problem, a moment in history, or a social issue and figue out the cause of the problem to find, to correct it and find a solution.

 How do you hope to develop your strengths for your new career in software development?
 I want to get better at communicating with other people, especially when it comes to talking about coding. I think working on communication and understanding other people will help me become a better team player.
	"6. Understand that Code is cheap." I think this is something I will definitely need to work on in the next couple months. When I put effort into something, like anyone, I tend to get attached to it. I think that learning when to scrap a piece of code and when to keep trying to make it work will be essencial to learning to code.
	"1. Use google very aggressively." My friend who worked in the IT department once said "I don't know more about technology than most people, I'm just better at googling than them". While doing the pre work so far, I've found myself turing to google a lot to find out more about something I didn't understand in the book. With so many elements and names to memorize, I think google will be a really useful tool.
	"26. Act as a leader and not a boss" I think people often don't differentiate between being a leader and being a boss, however it's an important distinction. A boss will tell you what to do, while a leader will be down in the trenches with you showing you how it's done. A leader never assigns something to someone they wouldn't do themselves, a boss might.
	Side note: "22. Skip a lot of meetings" This rule is my favorite. I hate large, unproductive meetings. I think they are helpful to make sure everyone is on the same page and everyone understands the end goals they should be working towards, but most of the time they're used so people to show that they're being productive.


	Checklist are helpful because they keep you organizes, stops you from making assumptions, and it stops you from making stupid mistakes. With coding there are so many small details that it's easy to make simple mistakes, but that mistake can totally throw off your code. Having a checklist to go through when something is wrong in your code makes it easier to find mistakes. Also, having a checklist helps you stay organized. Instead of having to worry about what I am going to do next, writing it out on a checklist, helps me stay and the moment and feel productive when I get to check something off.


	What is your impression of strengths-based development? What questions do you have about this kind of development?
	I've hear of the strengths-based developement before and it sounds like a really interesting concept because it empowers employees to use what there good at (which is also usually what they love to do) to get something done instead of having a right and wrong way to do things. I think it would work in the technology industry because How do you get things done if they don't play to anyone's strength? Is this a viable solution for small companies, since they don't have as many people so most employees need to be multi fasited?

	What do you feel are your top strengths? How do you know?
	Working with other people and breaking down problems to find solutions. Working with a team helps me stay motivated and also, I'm not confrintational and relatively good at communication which helps me work with other people. The subjects that I was good at in school were math, history, and public policy (my major) all of which require you to analyze a problem whether it be an algebra problem, a moment in history, or a social issue and figue out the cause of the problem to find, to correct it and find a solution.

	How do you hope to develop your strengths for your new career in software development?
	I want to get better at communicating with other people, especially when it comes to talking about coding. I think working on communication and understanding other people will help me become a better team player.