Podcasts about 178646439x

JSJ 270 The Complete Software Developers Career Guide with John Sonmez This episode features a panel of Joe Eames, AJ O’Neal, as well as host Charles Maxwell. Special guest John Sonmez runs the website SimpleProgrammer.com that is focused on personal development for software developers. He works on career development and improving the non-technical life aspects of software developers. Today’s episode focuses on John’s new book The Complete Software Developers Career Guide. Did the book start out being 700 pages? No. My goal was 200,000 words. During the editing process a lot of questions came up, so pages were added. There were side sections called “Hey John” to answer questions that added 150 pages. Is this book aimed at beginners? It should be valuable for three types of software developers: beginner, intermediate, and senior developers looking to advance their career. The book is broken up into five sections, which build upon each other. These sections are: - How to get started as a software developer - How to get a job and negotiate salary - The technical skills needed to know to be a software developer - How to work as a software developer - How to advance in career Is it more a reference book, not intended to read front to back? The book could be read either way. It is written in small chapters. Most people will read it start to finish, but it is written so that you can pick what you’re interested in and each chapter still makes sense by itself. Where did you come up with the idea for the book? It was a combination of things. At the time I wanted new blog posts, a new product, and a new book. So I thought, “What if I wrote a book that could release chapters as blog posts and could be a product later on?” I also wanted to capture everything I learned about software development and put it on paper so that didn’t lose it. What did people feel like they were missing (from Soft Skills) that you made sure went into this book? All the questions that people would ask were about career advice. People would ask things regarding: - How do I learn programming? - What programming language should I learn? - Problems with co-workers and boss - Dress code What do you think is the most practical advice from the book for someone just getting started? John thinks that the most important thing to tell people is to come up with a plan on how you’re going to become educated in software development. And then to decide what you’re going to pursue. People need to define what they want to be. After that is done, go backwards and come up with a plan in order to get there. If you set a plan, you’ll learn faster and become a valuable asset to a team. Charles agrees that this is how to stay current in the job force. What skills do you actually need to have as a developer? Section 3 of the book answers this question. There was some frustration when beginning as a software developer, so put this list together in the book. - Programming language that you know - Source control understanding - Basic testing - Continuous integration and build systems - What kinds of development (web, mobile, back end) - Databases - Sequel Were any of those surprises to you? Maybe DevOps because today’s software developers need to, but I didn’t need to starting out. We weren’t involved in production. Today’s software developers need to understand it because they will be involved in those steps. What do you think is the importance of learning build tools and frameworks, etc. verses learning the basics? Build tools and frameworks need to be understood in order to understand how your piece fits into the bigger picture. It is important to understand as much as you can of what’s out there. The basics aren’t going to change so you should have an in depth knowledge of them. Problems will always be solved the same way. John wants people to have as few “unknown unknowns” as possible. That way they won’t be lost and can focus on more timeless things. What do you think about the virtues of self-taught verses boot camp verses University? This is the first question many developers have so it is addressed it in the book. If you can find a good coding boot camp, John personally thinks that’s the best way. He would spend money on boot camp because it is a full immersion. But while there, you need to work as hard as possible to soak up knowledge. After a boot camp, then you can go back and fill in your computer science knowledge. This could be through part time college classes or even by self-teaching. Is the classic computer science stuff important? John was mostly self-taught; he only went to college for a year. He realized that he needed to go back and learn computer science stuff. Doesn’t think that there is a need to have background in computer science, but that it can be a time saver. A lot of people get into web development and learn React or Angular but don’t learn fundamentals of JavaScript. Is that a big mistake? John believes that it is a mistake to not fully understand what you’re doing. Knowing the function first, knowing React, is a good approach. Then you can go back and learn JavaScript and understand more. He states that if you don’t learn the basics, you will be stunted and possibly solve things wrong. Joe agrees with JavaScript, but not so much with things algorithms. He states that it never helped him once he went back and learned it. John suggests the book Algorithms to Live By – teaches how to apply algorithms to real life. Is there one question you get asked more than anything else you have the answer to in the book? The most interesting question is regarding contract verses salary employment and how to compare them. It should all be evaluated based on monetary value. Salary jobs look good because of benefits. But when looking at pay divided by the hours of work, usually a salary job is lower paid. This is because people usually work longer hours at salary jobs without being paid for it. What’s the best place for people to pick up the book? simpleprogrammer.com/careerguide and it will be sold on Amazon. The book will be 99 cents on kindle – want it to be the best selling software development book ever. Picks Joe Wonder Woman AJ The Alchemist Charles Artificial Intelligence with Python John Algorithms to Live by: The Computer Science of Human Decisions Apple Airpods Links Simple Programmer Youtube

JSJ 270 The Complete Software Developers Career Guide with John Sonmez This episode features a panel of Joe Eames, AJ O’Neal, as well as host Charles Maxwell. Special guest John Sonmez runs the website SimpleProgrammer.com that is focused on personal development for software developers. He works on career development and improving the non-technical life aspects of software developers. Today’s episode focuses on John’s new book The Complete Software Developers Career Guide. Did the book start out being 700 pages? No. My goal was 200,000 words. During the editing process a lot of questions came up, so pages were added. There were side sections called “Hey John” to answer questions that added 150 pages. Is this book aimed at beginners? It should be valuable for three types of software developers: beginner, intermediate, and senior developers looking to advance their career. The book is broken up into five sections, which build upon each other. These sections are: - How to get started as a software developer - How to get a job and negotiate salary - The technical skills needed to know to be a software developer - How to work as a software developer - How to advance in career Is it more a reference book, not intended to read front to back? The book could be read either way. It is written in small chapters. Most people will read it start to finish, but it is written so that you can pick what you’re interested in and each chapter still makes sense by itself. Where did you come up with the idea for the book? It was a combination of things. At the time I wanted new blog posts, a new product, and a new book. So I thought, “What if I wrote a book that could release chapters as blog posts and could be a product later on?” I also wanted to capture everything I learned about software development and put it on paper so that didn’t lose it. What did people feel like they were missing (from Soft Skills) that you made sure went into this book? All the questions that people would ask were about career advice. People would ask things regarding: - How do I learn programming? - What programming language should I learn? - Problems with co-workers and boss - Dress code What do you think is the most practical advice from the book for someone just getting started? John thinks that the most important thing to tell people is to come up with a plan on how you’re going to become educated in software development. And then to decide what you’re going to pursue. People need to define what they want to be. After that is done, go backwards and come up with a plan in order to get there. If you set a plan, you’ll learn faster and become a valuable asset to a team. Charles agrees that this is how to stay current in the job force. What skills do you actually need to have as a developer? Section 3 of the book answers this question. There was some frustration when beginning as a software developer, so put this list together in the book. - Programming language that you know - Source control understanding - Basic testing - Continuous integration and build systems - What kinds of development (web, mobile, back end) - Databases - Sequel Were any of those surprises to you? Maybe DevOps because today’s software developers need to, but I didn’t need to starting out. We weren’t involved in production. Today’s software developers need to understand it because they will be involved in those steps. What do you think is the importance of learning build tools and frameworks, etc. verses learning the basics? Build tools and frameworks need to be understood in order to understand how your piece fits into the bigger picture. It is important to understand as much as you can of what’s out there. The basics aren’t going to change so you should have an in depth knowledge of them. Problems will always be solved the same way. John wants people to have as few “unknown unknowns” as possible. That way they won’t be lost and can focus on more timeless things. What do you think about the virtues of self-taught verses boot camp verses University? This is the first question many developers have so it is addressed it in the book. If you can find a good coding boot camp, John personally thinks that’s the best way. He would spend money on boot camp because it is a full immersion. But while there, you need to work as hard as possible to soak up knowledge. After a boot camp, then you can go back and fill in your computer science knowledge. This could be through part time college classes or even by self-teaching. Is the classic computer science stuff important? John was mostly self-taught; he only went to college for a year. He realized that he needed to go back and learn computer science stuff. Doesn’t think that there is a need to have background in computer science, but that it can be a time saver. A lot of people get into web development and learn React or Angular but don’t learn fundamentals of JavaScript. Is that a big mistake? John believes that it is a mistake to not fully understand what you’re doing. Knowing the function first, knowing React, is a good approach. Then you can go back and learn JavaScript and understand more. He states that if you don’t learn the basics, you will be stunted and possibly solve things wrong. Joe agrees with JavaScript, but not so much with things algorithms. He states that it never helped him once he went back and learned it. John suggests the book Algorithms to Live By – teaches how to apply algorithms to real life. Is there one question you get asked more than anything else you have the answer to in the book? The most interesting question is regarding contract verses salary employment and how to compare them. It should all be evaluated based on monetary value. Salary jobs look good because of benefits. But when looking at pay divided by the hours of work, usually a salary job is lower paid. This is because people usually work longer hours at salary jobs without being paid for it. What’s the best place for people to pick up the book? simpleprogrammer.com/careerguide and it will be sold on Amazon. The book will be 99 cents on kindle – want it to be the best selling software development book ever. Picks Joe Wonder Woman AJ The Alchemist Charles Artificial Intelligence with Python John Algorithms to Live by: The Computer Science of Human Decisions Apple Airpods Links Simple Programmer Youtube

JSJ 270 The Complete Software Developers Career Guide with John Sonmez This episode features a panel of Joe Eames, AJ O’Neal, as well as host Charles Maxwell. Special guest John Sonmez runs the website SimpleProgrammer.com that is focused on personal development for software developers. He works on career development and improving the non-technical life aspects of software developers. Today’s episode focuses on John’s new book The Complete Software Developers Career Guide. Did the book start out being 700 pages? No. My goal was 200,000 words. During the editing process a lot of questions came up, so pages were added. There were side sections called “Hey John” to answer questions that added 150 pages. Is this book aimed at beginners? It should be valuable for three types of software developers: beginner, intermediate, and senior developers looking to advance their career. The book is broken up into five sections, which build upon each other. These sections are: - How to get started as a software developer - How to get a job and negotiate salary - The technical skills needed to know to be a software developer - How to work as a software developer - How to advance in career Is it more a reference book, not intended to read front to back? The book could be read either way. It is written in small chapters. Most people will read it start to finish, but it is written so that you can pick what you’re interested in and each chapter still makes sense by itself. Where did you come up with the idea for the book? It was a combination of things. At the time I wanted new blog posts, a new product, and a new book. So I thought, “What if I wrote a book that could release chapters as blog posts and could be a product later on?” I also wanted to capture everything I learned about software development and put it on paper so that didn’t lose it. What did people feel like they were missing (from Soft Skills) that you made sure went into this book? All the questions that people would ask were about career advice. People would ask things regarding: - How do I learn programming? - What programming language should I learn? - Problems with co-workers and boss - Dress code What do you think is the most practical advice from the book for someone just getting started? John thinks that the most important thing to tell people is to come up with a plan on how you’re going to become educated in software development. And then to decide what you’re going to pursue. People need to define what they want to be. After that is done, go backwards and come up with a plan in order to get there. If you set a plan, you’ll learn faster and become a valuable asset to a team. Charles agrees that this is how to stay current in the job force. What skills do you actually need to have as a developer? Section 3 of the book answers this question. There was some frustration when beginning as a software developer, so put this list together in the book. - Programming language that you know - Source control understanding - Basic testing - Continuous integration and build systems - What kinds of development (web, mobile, back end) - Databases - Sequel Were any of those surprises to you? Maybe DevOps because today’s software developers need to, but I didn’t need to starting out. We weren’t involved in production. Today’s software developers need to understand it because they will be involved in those steps. What do you think is the importance of learning build tools and frameworks, etc. verses learning the basics? Build tools and frameworks need to be understood in order to understand how your piece fits into the bigger picture. It is important to understand as much as you can of what’s out there. The basics aren’t going to change so you should have an in depth knowledge of them. Problems will always be solved the same way. John wants people to have as few “unknown unknowns” as possible. That way they won’t be lost and can focus on more timeless things. What do you think about the virtues of self-taught verses boot camp verses University? This is the first question many developers have so it is addressed it in the book. If you can find a good coding boot camp, John personally thinks that’s the best way. He would spend money on boot camp because it is a full immersion. But while there, you need to work as hard as possible to soak up knowledge. After a boot camp, then you can go back and fill in your computer science knowledge. This could be through part time college classes or even by self-teaching. Is the classic computer science stuff important? John was mostly self-taught; he only went to college for a year. He realized that he needed to go back and learn computer science stuff. Doesn’t think that there is a need to have background in computer science, but that it can be a time saver. A lot of people get into web development and learn React or Angular but don’t learn fundamentals of JavaScript. Is that a big mistake? John believes that it is a mistake to not fully understand what you’re doing. Knowing the function first, knowing React, is a good approach. Then you can go back and learn JavaScript and understand more. He states that if you don’t learn the basics, you will be stunted and possibly solve things wrong. Joe agrees with JavaScript, but not so much with things algorithms. He states that it never helped him once he went back and learned it. John suggests the book Algorithms to Live By – teaches how to apply algorithms to real life. Is there one question you get asked more than anything else you have the answer to in the book? The most interesting question is regarding contract verses salary employment and how to compare them. It should all be evaluated based on monetary value. Salary jobs look good because of benefits. But when looking at pay divided by the hours of work, usually a salary job is lower paid. This is because people usually work longer hours at salary jobs without being paid for it. What’s the best place for people to pick up the book? simpleprogrammer.com/careerguide and it will be sold on Amazon. The book will be 99 cents on kindle – want it to be the best selling software development book ever. Picks Joe Wonder Woman AJ The Alchemist Charles Artificial Intelligence with Python John Algorithms to Live by: The Computer Science of Human Decisions Apple Airpods Links Simple Programmer Youtube

My Ruby Story 009 Brian Hogan On this episode we have another My Ruby Story and there is a good chance you might recognize him, he is one of Devchat.tv’s panelists Brian Hogan. Aside from being a panelists on Ruby Rouges, he also has a couple other projects like codecaster.io as well as Railsmentors.org. How did you get into programming? Brain talks about how his Dad has an old Apple 2 computer. His father was a teacher for the blind and the computer had a box on it that would talk. His Dad taught him that computers can have programs written for them and make them do things. Brain talks about having math issues one evening and his Dad helped by making a math program that would quiz him. His Dad wasn’t a programmer but he had picked up some of it from being around it. Brain talks about how the library had games you could get for the Apple 2 but you had to write code into the computer to make it work. He started tweaking the code to learn that it adjusted things in the game like the speed of the spaceship or the damage of the bomb. Brian’s First Program Brian’s first program was in fourth grade. He had an assignment on the topic of the seas and instead of doing a typical handwritten assignment he created a program for it. He learned that he could make the computer do things. Over time Brian got interested in other things, planning to go to school for law. His Dad lost his job making his plans for law school unreachable without student loan debt. He started making money on the side repairing and building computers. Computers solving problems He talks about how he never really got into the computer science level of things, but he was always excited about being able to solve people’s problems with computers. He remembers getting internet for the first time. It was Netscape and it came with a book on how to setup the internet and then in the last chapter it had a section teaching how to make a webpage with HTML. He loved making websites and so he made pages for businesses and made money on the side. He went to college aiming for computer science and then when he got into classes like computational theory, he found that it was boring to him still. He changed his major to business. He then got a job working for the college working with website stuff. The developer for the pages ended up quitting and so they asked Brian to help out. So he learned Microsoft server SQL and ASP. He adds that essentially he fell into web development by accident. He talks about his code being bad until he learned Ruby, crediting Ruby with making object oriented programming easier to understand. Charles mentions that he felt the same way in school, it wasn’t until he needed to fix a real problem that programming really started to seem useful and fun. Brian talks about how he isn’t really the best programmer, but his strengths are helping other people to program. He has trained many people to program since then. Learning with Context He talks about in school how they throw JavaScript at you and teach you the higher concepts before understanding it. He tells about how doing something like teaching Git on the first day doesn’t make sense because the students don’t understand why they need it. He suggests that the thing that is missing from the curriculum is the real work connection. Majority of adults need to be able to connect what they are learning to something they have already learned. Context is important for learning. How did you get into Ruby? Brian talks about doing PHP for a while as well as ASP. He was working with a project as an Oracle DBA. They were moving from Java to an Oracle Database. But no one there knew what Java was and a person there named Bruce suggested that the work they were doing would be better written in Ruby. The team disagreed but afterward one day Brian was talking to Bruce about a side project he was working on and how he wasn’t accomplishing it the way he wanted to. Bruce asked him to get lunch with him. Brian then talks about how in life if someone very smart asks you to get lunch that you should drop everything and do it. In a single night he was able to accomplish everything he was trying to. He took his project to work the next day and they said they wouldn’t be able to use it on Windows. Brian started working on finding ways to deploy it, and that has been the starting point of Ruby for Brian. He went to Rails full time after that. Publishing an article on how to get it deployed. His work with Ruby led to him teaching and writing books. When he needs to make something heavily data driven he always reaches for Ruby. He isn’t interested in scalability because usually he is working on a small business process behind the firewall used by less than 100 people. Framework Peer Pressure Brian talks about the fear and pressure to use the latest and greatest frameworks in the development community. He talks about how the only people who know what framework a person uses is the developer and the peers. You don’t get paid to impress peers in the community. A developer gets paid to solve peoples problems. Charles and Brian add that using new frameworks are great and can teach you new ways to solve problems, but no matter how a person solves a problem, it should be celebrated. Learn new things but don’t make people feel bad for not doing things the same way you do them. Brian adds that another reason he likes Rails is that it has a lot of things that came from basecamp and it is a well developed and tested and the framework is strong. He talks about how sometimes frameworks come out and they weren’t well thought out. Rails is not an academic framework but it is easier to integrate or upgrade to by design. What contributions have you made to the Ruby community? Brian talks about getting the Rails deploy working for Windows is one of his proudest moments. Other than that his contribution has been mainly helping people find mentors at Railsmentors.org. On Railsmentors.org, most of the work is done by volunteers and help a lot of people. Charles adds that sometimes open source project contributions tend to get glorified but things like Railsmentors.org are really what make the community great. What are you working on now? Brian talks about how he is working on a book but he can’t tell much about it at the moment. He also works on the content team on Digital Ocean. He helps other community authors with their writing and to get it published and out. He also handles some system admin background to test that each article works and he finds it a good way to keep his skills tuned. He is also working on a project in Elixir for teachers to work in the classroom better. For a teacher teaching development they can use the program, CodeCaster, to display code to the screens and the students can do things like flag things they don’t understand or let the teacher know that it’s moving too fast. It allows the students send up code for the teacher to check as well as the teacher get a snapshot of what’s on the students screen to check on them. Picks Brian Exercises for Programmers Tmux 2 Productive Mouse-Free Development Charles Coursera on AI Artificial Intelligence in Python Links Twitter bphogan.com

My Ruby Story 009 Brian Hogan On this episode we have another My Ruby Story and there is a good chance you might recognize him, he is one of Devchat.tv’s panelists Brian Hogan. Aside from being a panelists on Ruby Rouges, he also has a couple other projects like codecaster.io as well as Railsmentors.org. How did you get into programming? Brain talks about how his Dad has an old Apple 2 computer. His father was a teacher for the blind and the computer had a box on it that would talk. His Dad taught him that computers can have programs written for them and make them do things. Brain talks about having math issues one evening and his Dad helped by making a math program that would quiz him. His Dad wasn’t a programmer but he had picked up some of it from being around it. Brain talks about how the library had games you could get for the Apple 2 but you had to write code into the computer to make it work. He started tweaking the code to learn that it adjusted things in the game like the speed of the spaceship or the damage of the bomb. Brian’s First Program Brian’s first program was in fourth grade. He had an assignment on the topic of the seas and instead of doing a typical handwritten assignment he created a program for it. He learned that he could make the computer do things. Over time Brian got interested in other things, planning to go to school for law. His Dad lost his job making his plans for law school unreachable without student loan debt. He started making money on the side repairing and building computers. Computers solving problems He talks about how he never really got into the computer science level of things, but he was always excited about being able to solve people’s problems with computers. He remembers getting internet for the first time. It was Netscape and it came with a book on how to setup the internet and then in the last chapter it had a section teaching how to make a webpage with HTML. He loved making websites and so he made pages for businesses and made money on the side. He went to college aiming for computer science and then when he got into classes like computational theory, he found that it was boring to him still. He changed his major to business. He then got a job working for the college working with website stuff. The developer for the pages ended up quitting and so they asked Brian to help out. So he learned Microsoft server SQL and ASP. He adds that essentially he fell into web development by accident. He talks about his code being bad until he learned Ruby, crediting Ruby with making object oriented programming easier to understand. Charles mentions that he felt the same way in school, it wasn’t until he needed to fix a real problem that programming really started to seem useful and fun. Brian talks about how he isn’t really the best programmer, but his strengths are helping other people to program. He has trained many people to program since then. Learning with Context He talks about in school how they throw JavaScript at you and teach you the higher concepts before understanding it. He tells about how doing something like teaching Git on the first day doesn’t make sense because the students don’t understand why they need it. He suggests that the thing that is missing from the curriculum is the real work connection. Majority of adults need to be able to connect what they are learning to something they have already learned. Context is important for learning. How did you get into Ruby? Brian talks about doing PHP for a while as well as ASP. He was working with a project as an Oracle DBA. They were moving from Java to an Oracle Database. But no one there knew what Java was and a person there named Bruce suggested that the work they were doing would be better written in Ruby. The team disagreed but afterward one day Brian was talking to Bruce about a side project he was working on and how he wasn’t accomplishing it the way he wanted to. Bruce asked him to get lunch with him. Brian then talks about how in life if someone very smart asks you to get lunch that you should drop everything and do it. In a single night he was able to accomplish everything he was trying to. He took his project to work the next day and they said they wouldn’t be able to use it on Windows. Brian started working on finding ways to deploy it, and that has been the starting point of Ruby for Brian. He went to Rails full time after that. Publishing an article on how to get it deployed. His work with Ruby led to him teaching and writing books. When he needs to make something heavily data driven he always reaches for Ruby. He isn’t interested in scalability because usually he is working on a small business process behind the firewall used by less than 100 people. Framework Peer Pressure Brian talks about the fear and pressure to use the latest and greatest frameworks in the development community. He talks about how the only people who know what framework a person uses is the developer and the peers. You don’t get paid to impress peers in the community. A developer gets paid to solve peoples problems. Charles and Brian add that using new frameworks are great and can teach you new ways to solve problems, but no matter how a person solves a problem, it should be celebrated. Learn new things but don’t make people feel bad for not doing things the same way you do them. Brian adds that another reason he likes Rails is that it has a lot of things that came from basecamp and it is a well developed and tested and the framework is strong. He talks about how sometimes frameworks come out and they weren’t well thought out. Rails is not an academic framework but it is easier to integrate or upgrade to by design. What contributions have you made to the Ruby community? Brian talks about getting the Rails deploy working for Windows is one of his proudest moments. Other than that his contribution has been mainly helping people find mentors at Railsmentors.org. On Railsmentors.org, most of the work is done by volunteers and help a lot of people. Charles adds that sometimes open source project contributions tend to get glorified but things like Railsmentors.org are really what make the community great. What are you working on now? Brian talks about how he is working on a book but he can’t tell much about it at the moment. He also works on the content team on Digital Ocean. He helps other community authors with their writing and to get it published and out. He also handles some system admin background to test that each article works and he finds it a good way to keep his skills tuned. He is also working on a project in Elixir for teachers to work in the classroom better. For a teacher teaching development they can use the program, CodeCaster, to display code to the screens and the students can do things like flag things they don’t understand or let the teacher know that it’s moving too fast. It allows the students send up code for the teacher to check as well as the teacher get a snapshot of what’s on the students screen to check on them. Picks Brian Exercises for Programmers Tmux 2 Productive Mouse-Free Development Charles Coursera on AI Artificial Intelligence in Python Links Twitter bphogan.com

My Ruby Story 009 Brian Hogan On this episode we have another My Ruby Story and there is a good chance you might recognize him, he is one of Devchat.tv’s panelists Brian Hogan. Aside from being a panelists on Ruby Rouges, he also has a couple other projects like codecaster.io as well as Railsmentors.org. How did you get into programming? Brain talks about how his Dad has an old Apple 2 computer. His father was a teacher for the blind and the computer had a box on it that would talk. His Dad taught him that computers can have programs written for them and make them do things. Brain talks about having math issues one evening and his Dad helped by making a math program that would quiz him. His Dad wasn’t a programmer but he had picked up some of it from being around it. Brain talks about how the library had games you could get for the Apple 2 but you had to write code into the computer to make it work. He started tweaking the code to learn that it adjusted things in the game like the speed of the spaceship or the damage of the bomb. Brian’s First Program Brian’s first program was in fourth grade. He had an assignment on the topic of the seas and instead of doing a typical handwritten assignment he created a program for it. He learned that he could make the computer do things. Over time Brian got interested in other things, planning to go to school for law. His Dad lost his job making his plans for law school unreachable without student loan debt. He started making money on the side repairing and building computers. Computers solving problems He talks about how he never really got into the computer science level of things, but he was always excited about being able to solve people’s problems with computers. He remembers getting internet for the first time. It was Netscape and it came with a book on how to setup the internet and then in the last chapter it had a section teaching how to make a webpage with HTML. He loved making websites and so he made pages for businesses and made money on the side. He went to college aiming for computer science and then when he got into classes like computational theory, he found that it was boring to him still. He changed his major to business. He then got a job working for the college working with website stuff. The developer for the pages ended up quitting and so they asked Brian to help out. So he learned Microsoft server SQL and ASP. He adds that essentially he fell into web development by accident. He talks about his code being bad until he learned Ruby, crediting Ruby with making object oriented programming easier to understand. Charles mentions that he felt the same way in school, it wasn’t until he needed to fix a real problem that programming really started to seem useful and fun. Brian talks about how he isn’t really the best programmer, but his strengths are helping other people to program. He has trained many people to program since then. Learning with Context He talks about in school how they throw JavaScript at you and teach you the higher concepts before understanding it. He tells about how doing something like teaching Git on the first day doesn’t make sense because the students don’t understand why they need it. He suggests that the thing that is missing from the curriculum is the real work connection. Majority of adults need to be able to connect what they are learning to something they have already learned. Context is important for learning. How did you get into Ruby? Brian talks about doing PHP for a while as well as ASP. He was working with a project as an Oracle DBA. They were moving from Java to an Oracle Database. But no one there knew what Java was and a person there named Bruce suggested that the work they were doing would be better written in Ruby. The team disagreed but afterward one day Brian was talking to Bruce about a side project he was working on and how he wasn’t accomplishing it the way he wanted to. Bruce asked him to get lunch with him. Brian then talks about how in life if someone very smart asks you to get lunch that you should drop everything and do it. In a single night he was able to accomplish everything he was trying to. He took his project to work the next day and they said they wouldn’t be able to use it on Windows. Brian started working on finding ways to deploy it, and that has been the starting point of Ruby for Brian. He went to Rails full time after that. Publishing an article on how to get it deployed. His work with Ruby led to him teaching and writing books. When he needs to make something heavily data driven he always reaches for Ruby. He isn’t interested in scalability because usually he is working on a small business process behind the firewall used by less than 100 people. Framework Peer Pressure Brian talks about the fear and pressure to use the latest and greatest frameworks in the development community. He talks about how the only people who know what framework a person uses is the developer and the peers. You don’t get paid to impress peers in the community. A developer gets paid to solve peoples problems. Charles and Brian add that using new frameworks are great and can teach you new ways to solve problems, but no matter how a person solves a problem, it should be celebrated. Learn new things but don’t make people feel bad for not doing things the same way you do them. Brian adds that another reason he likes Rails is that it has a lot of things that came from basecamp and it is a well developed and tested and the framework is strong. He talks about how sometimes frameworks come out and they weren’t well thought out. Rails is not an academic framework but it is easier to integrate or upgrade to by design. What contributions have you made to the Ruby community? Brian talks about getting the Rails deploy working for Windows is one of his proudest moments. Other than that his contribution has been mainly helping people find mentors at Railsmentors.org. On Railsmentors.org, most of the work is done by volunteers and help a lot of people. Charles adds that sometimes open source project contributions tend to get glorified but things like Railsmentors.org are really what make the community great. What are you working on now? Brian talks about how he is working on a book but he can’t tell much about it at the moment. He also works on the content team on Digital Ocean. He helps other community authors with their writing and to get it published and out. He also handles some system admin background to test that each article works and he finds it a good way to keep his skills tuned. He is also working on a project in Elixir for teachers to work in the classroom better. For a teacher teaching development they can use the program, CodeCaster, to display code to the screens and the students can do things like flag things they don’t understand or let the teacher know that it’s moving too fast. It allows the students send up code for the teacher to check as well as the teacher get a snapshot of what’s on the students screen to check on them. Picks Brian Exercises for Programmers Tmux 2 Productive Mouse-Free Development Charles Coursera on AI Artificial Intelligence in Python Links Twitter bphogan.com

My Angular Story 015 Danny Blue On today’s episode we have a My Angular Story with Danny Blue. Danny is a Google Developer Expert for web technologies. In this episode we hear the story about how Danny first started coding, a method suggestion for picking a frameworks, and how vocabulary is vital for a new programmer to learn. It’s a good one, stay tuned. How did you get into programming? Didn’t get started until college. In school he was under the impression that you had to be a math genius to be a programmer. Didn’t even try until college. He wish he would have taken more in College. His first dive into code was ActionScript 2. He was offered a class that taught how to make Flash games and he took the class and made a few games, which he mentions were most likely awful. His game was an infinite runner with a robot. It taught him the basics like loops and storing variables.In his class he realized that as long as he understood some of the key concepts, he would be able to handle it.Soon he went out and just bought a book and after experiencing the code in action he got hooked. Managing memory in C Danny’s friend tried to teach him how to build a checkers game in C. He remembers the pains of manually managing memory. His feedback on malloc is that it’s one of his favorite words because it rolls off the tongue. Charles talks about how in college he had to design systems in VSDL with transistors and silicon. How do you get from that to JavaScript Development First job was at a swimming pool manufacturing company’s marketing department in West Virginia. He worked a lot in Dreamweaver until a man that started after him decided they were going to write all the markup and CSS by hand. From that Danny learned how websites were put together. He talks about a contact form that they wanted to animate. He knew that he could figure it out. He would use code snippets to figure out and build the animation. He started to do more and more JavaScript and teaching himself as much as he could. He did the CodeSchool JavaScript Road Trip. The first few episodes ease you into JavaScript and helps you learn where things lives. From that point he became obsessed with building things with JavaScript. Charles talks about how CodeSchool wasn’t around when he started. Modern code seem to be more complicated but it can be learned best by breaking it down into smaller bites. CodeSchool is good for that. Getting your start or foothold is the hardest part. It’s easy to skip over fundamentals. Charles talks about how that things like CLI came second nature for him and sometimes instructors dismiss that new students may get hung up on those sort of fundamental concepts and tools. Danny adds that there had been times where he would read articles on sites like StackOverflow that would be explaining something but even the baseline instructions has information in it that can something someone has skipped. Little pieces of information can really help pull things together. He talks about the dissociation that can happen for someone who only learned JavaScript and doesn’t know what CLI is and how hard it would be to explain the difference between JavaScript running in the browser and Node, or explaining what a package manager is, then a package , etc. Many people come into it not understanding any of it. He can remember copying commands into a terminal but not understanding what was going on. For learning JavaScript from a basic level, what do you suggest? Finding the beginner tutorials for stuff. CodeSchool is good, Code Academy as well. Do those first. Don’t skip it assuming you know too much to do them. After that just make something. From there you will figure out stuff that works and stuff that doesn’t. Twitter is a great resource for finding helpful people. Being in the environment helps to get exposed to the information. Mainly just write code. Charles mentions that people have grown to understand the concepts and lingo of web development by just listening. Danny also advises that if you learn the vocabulary before learning the concepts, you’ll be able to do things like Google your issues affectively as well as reading articles or talking with others. Complicated concepts end up be boiled down to single words. Ultimately you will need to be able to communicate with everyone on projects anyway. How did you get into Angular? While working at DualLink Digital, they started looking at a few different things, he started looking at Ember and found that he really enjoyed the concepts. One of his friends started messing around with angular and they started workshopping with it to make it work. Afterwards he started to like it, really the plain JavaScript objects. The more he worked with he, the more he started enjoying it compared to Ember. It’s interesting to see how people have moved from Backbone or React or Ember to things like Angular. One of Embers pluses is how large their community is. Charles talks about how the history of Ember is great and the people behind Ember are great. Also, the JavaScript community used to seem to have animosity against the different communities but now it’s more collaborative. Picking the right framework. Danny suggests that when trying to figure out what framework to go with, be able to describe in your own words why the framework you’ve picked is better. Making sure that you do understand the decisions that you are making is important. He uses the example of within the React community and the use of virtual DOM. There was a common misconception that the virtual DOM was faster than the regular DOM, which is just not true. Later the details had to be expressed to clear the misunderstanding. If you don’t talk about the specifics, you may believe something without knowing the facts behind it. Charles adds that its sort of like politics in that way. Tell us the work you’ve done with Web Standards. Danny talks about getting interested in web components through his friend Eric and actually interviewed at the company Eric worked at. He didn’t get the job but they stayed in touch and Eric introduced him into Polymer. He started to learn about Polymer, specifically custom elements. He remembers very early on wanting to make a custom HTML tag. He suggests that being able to do things without the framework has been a piece that has been missing. Having lower level building blocks to build off of is really exciting to Danny. He talks about using custom elements to build a familiar API surface to interact with. He talks about an example where he wrapped a bunch of HTML APIs, like the notification API and the fullscreen API, wrapping another element within it. He was trying to build things that the younger version of himself could use. He things that could be something we are heading towards more often. Danny adds that Web Components come with 4 major parts: Custom elements, HTML Imports (kind of), ShadowDOM, and templates. Custom elements allow you to create a unique piece of HTML and is the most widely accepted and supported. What are you working on now? Danny talks about how the Angular’s component model is very similar to Custom Element component model. Where you pass information in through properties and you listen for changes through events. You can use Custom Elements with very little setup. There is a specific Custom Elements Scheme that will let you use custom elements without any properties being thrown. You use the custom event in the exact same way and syntax as for any other component. The one issue with the source code where it parses the metadata, losing the friendly compiler messages out of the box. He is playing around with trying to find a way to whitelist different element names and properties. He wants to learn how the Framework is parsing potential data and make it easy to whitelist a set of custom elements. Picks Dannys Daemon by Daniel Suarez Bob’s Burgers CodeSchool Charles VR & Augmented Reality IoT Artificial Intelligence Veritone.com Coursera on Artificial Intelligence Artificial Intelligence with Python Machine Learning for Absolute Beginners Links Twitter Blog on Medium

My Angular Story 015 Danny Blue On today’s episode we have a My Angular Story with Danny Blue. Danny is a Google Developer Expert for web technologies. In this episode we hear the story about how Danny first started coding, a method suggestion for picking a frameworks, and how vocabulary is vital for a new programmer to learn. It’s a good one, stay tuned. How did you get into programming? Didn’t get started until college. In school he was under the impression that you had to be a math genius to be a programmer. Didn’t even try until college. He wish he would have taken more in College. His first dive into code was ActionScript 2. He was offered a class that taught how to make Flash games and he took the class and made a few games, which he mentions were most likely awful. His game was an infinite runner with a robot. It taught him the basics like loops and storing variables.In his class he realized that as long as he understood some of the key concepts, he would be able to handle it.Soon he went out and just bought a book and after experiencing the code in action he got hooked. Managing memory in C Danny’s friend tried to teach him how to build a checkers game in C. He remembers the pains of manually managing memory. His feedback on malloc is that it’s one of his favorite words because it rolls off the tongue. Charles talks about how in college he had to design systems in VSDL with transistors and silicon. How do you get from that to JavaScript Development First job was at a swimming pool manufacturing company’s marketing department in West Virginia. He worked a lot in Dreamweaver until a man that started after him decided they were going to write all the markup and CSS by hand. From that Danny learned how websites were put together. He talks about a contact form that they wanted to animate. He knew that he could figure it out. He would use code snippets to figure out and build the animation. He started to do more and more JavaScript and teaching himself as much as he could. He did the CodeSchool JavaScript Road Trip. The first few episodes ease you into JavaScript and helps you learn where things lives. From that point he became obsessed with building things with JavaScript. Charles talks about how CodeSchool wasn’t around when he started. Modern code seem to be more complicated but it can be learned best by breaking it down into smaller bites. CodeSchool is good for that. Getting your start or foothold is the hardest part. It’s easy to skip over fundamentals. Charles talks about how that things like CLI came second nature for him and sometimes instructors dismiss that new students may get hung up on those sort of fundamental concepts and tools. Danny adds that there had been times where he would read articles on sites like StackOverflow that would be explaining something but even the baseline instructions has information in it that can something someone has skipped. Little pieces of information can really help pull things together. He talks about the dissociation that can happen for someone who only learned JavaScript and doesn’t know what CLI is and how hard it would be to explain the difference between JavaScript running in the browser and Node, or explaining what a package manager is, then a package , etc. Many people come into it not understanding any of it. He can remember copying commands into a terminal but not understanding what was going on. For learning JavaScript from a basic level, what do you suggest? Finding the beginner tutorials for stuff. CodeSchool is good, Code Academy as well. Do those first. Don’t skip it assuming you know too much to do them. After that just make something. From there you will figure out stuff that works and stuff that doesn’t. Twitter is a great resource for finding helpful people. Being in the environment helps to get exposed to the information. Mainly just write code. Charles mentions that people have grown to understand the concepts and lingo of web development by just listening. Danny also advises that if you learn the vocabulary before learning the concepts, you’ll be able to do things like Google your issues affectively as well as reading articles or talking with others. Complicated concepts end up be boiled down to single words. Ultimately you will need to be able to communicate with everyone on projects anyway. How did you get into Angular? While working at DualLink Digital, they started looking at a few different things, he started looking at Ember and found that he really enjoyed the concepts. One of his friends started messing around with angular and they started workshopping with it to make it work. Afterwards he started to like it, really the plain JavaScript objects. The more he worked with he, the more he started enjoying it compared to Ember. It’s interesting to see how people have moved from Backbone or React or Ember to things like Angular. One of Embers pluses is how large their community is. Charles talks about how the history of Ember is great and the people behind Ember are great. Also, the JavaScript community used to seem to have animosity against the different communities but now it’s more collaborative. Picking the right framework. Danny suggests that when trying to figure out what framework to go with, be able to describe in your own words why the framework you’ve picked is better. Making sure that you do understand the decisions that you are making is important. He uses the example of within the React community and the use of virtual DOM. There was a common misconception that the virtual DOM was faster than the regular DOM, which is just not true. Later the details had to be expressed to clear the misunderstanding. If you don’t talk about the specifics, you may believe something without knowing the facts behind it. Charles adds that its sort of like politics in that way. Tell us the work you’ve done with Web Standards. Danny talks about getting interested in web components through his friend Eric and actually interviewed at the company Eric worked at. He didn’t get the job but they stayed in touch and Eric introduced him into Polymer. He started to learn about Polymer, specifically custom elements. He remembers very early on wanting to make a custom HTML tag. He suggests that being able to do things without the framework has been a piece that has been missing. Having lower level building blocks to build off of is really exciting to Danny. He talks about using custom elements to build a familiar API surface to interact with. He talks about an example where he wrapped a bunch of HTML APIs, like the notification API and the fullscreen API, wrapping another element within it. He was trying to build things that the younger version of himself could use. He things that could be something we are heading towards more often. Danny adds that Web Components come with 4 major parts: Custom elements, HTML Imports (kind of), ShadowDOM, and templates. Custom elements allow you to create a unique piece of HTML and is the most widely accepted and supported. What are you working on now? Danny talks about how the Angular’s component model is very similar to Custom Element component model. Where you pass information in through properties and you listen for changes through events. You can use Custom Elements with very little setup. There is a specific Custom Elements Scheme that will let you use custom elements without any properties being thrown. You use the custom event in the exact same way and syntax as for any other component. The one issue with the source code where it parses the metadata, losing the friendly compiler messages out of the box. He is playing around with trying to find a way to whitelist different element names and properties. He wants to learn how the Framework is parsing potential data and make it easy to whitelist a set of custom elements. Picks Dannys Daemon by Daniel Suarez Bob’s Burgers CodeSchool Charles VR & Augmented Reality IoT Artificial Intelligence Veritone.com Coursera on Artificial Intelligence Artificial Intelligence with Python Machine Learning for Absolute Beginners Links Twitter Blog on Medium

My Angular Story 015 Danny Blue On today’s episode we have a My Angular Story with Danny Blue. Danny is a Google Developer Expert for web technologies. In this episode we hear the story about how Danny first started coding, a method suggestion for picking a frameworks, and how vocabulary is vital for a new programmer to learn. It’s a good one, stay tuned. How did you get into programming? Didn’t get started until college. In school he was under the impression that you had to be a math genius to be a programmer. Didn’t even try until college. He wish he would have taken more in College. His first dive into code was ActionScript 2. He was offered a class that taught how to make Flash games and he took the class and made a few games, which he mentions were most likely awful. His game was an infinite runner with a robot. It taught him the basics like loops and storing variables.In his class he realized that as long as he understood some of the key concepts, he would be able to handle it.Soon he went out and just bought a book and after experiencing the code in action he got hooked. Managing memory in C Danny’s friend tried to teach him how to build a checkers game in C. He remembers the pains of manually managing memory. His feedback on malloc is that it’s one of his favorite words because it rolls off the tongue. Charles talks about how in college he had to design systems in VSDL with transistors and silicon. How do you get from that to JavaScript Development First job was at a swimming pool manufacturing company’s marketing department in West Virginia. He worked a lot in Dreamweaver until a man that started after him decided they were going to write all the markup and CSS by hand. From that Danny learned how websites were put together. He talks about a contact form that they wanted to animate. He knew that he could figure it out. He would use code snippets to figure out and build the animation. He started to do more and more JavaScript and teaching himself as much as he could. He did the CodeSchool JavaScript Road Trip. The first few episodes ease you into JavaScript and helps you learn where things lives. From that point he became obsessed with building things with JavaScript. Charles talks about how CodeSchool wasn’t around when he started. Modern code seem to be more complicated but it can be learned best by breaking it down into smaller bites. CodeSchool is good for that. Getting your start or foothold is the hardest part. It’s easy to skip over fundamentals. Charles talks about how that things like CLI came second nature for him and sometimes instructors dismiss that new students may get hung up on those sort of fundamental concepts and tools. Danny adds that there had been times where he would read articles on sites like StackOverflow that would be explaining something but even the baseline instructions has information in it that can something someone has skipped. Little pieces of information can really help pull things together. He talks about the dissociation that can happen for someone who only learned JavaScript and doesn’t know what CLI is and how hard it would be to explain the difference between JavaScript running in the browser and Node, or explaining what a package manager is, then a package , etc. Many people come into it not understanding any of it. He can remember copying commands into a terminal but not understanding what was going on. For learning JavaScript from a basic level, what do you suggest? Finding the beginner tutorials for stuff. CodeSchool is good, Code Academy as well. Do those first. Don’t skip it assuming you know too much to do them. After that just make something. From there you will figure out stuff that works and stuff that doesn’t. Twitter is a great resource for finding helpful people. Being in the environment helps to get exposed to the information. Mainly just write code. Charles mentions that people have grown to understand the concepts and lingo of web development by just listening. Danny also advises that if you learn the vocabulary before learning the concepts, you’ll be able to do things like Google your issues affectively as well as reading articles or talking with others. Complicated concepts end up be boiled down to single words. Ultimately you will need to be able to communicate with everyone on projects anyway. How did you get into Angular? While working at DualLink Digital, they started looking at a few different things, he started looking at Ember and found that he really enjoyed the concepts. One of his friends started messing around with angular and they started workshopping with it to make it work. Afterwards he started to like it, really the plain JavaScript objects. The more he worked with he, the more he started enjoying it compared to Ember. It’s interesting to see how people have moved from Backbone or React or Ember to things like Angular. One of Embers pluses is how large their community is. Charles talks about how the history of Ember is great and the people behind Ember are great. Also, the JavaScript community used to seem to have animosity against the different communities but now it’s more collaborative. Picking the right framework. Danny suggests that when trying to figure out what framework to go with, be able to describe in your own words why the framework you’ve picked is better. Making sure that you do understand the decisions that you are making is important. He uses the example of within the React community and the use of virtual DOM. There was a common misconception that the virtual DOM was faster than the regular DOM, which is just not true. Later the details had to be expressed to clear the misunderstanding. If you don’t talk about the specifics, you may believe something without knowing the facts behind it. Charles adds that its sort of like politics in that way. Tell us the work you’ve done with Web Standards. Danny talks about getting interested in web components through his friend Eric and actually interviewed at the company Eric worked at. He didn’t get the job but they stayed in touch and Eric introduced him into Polymer. He started to learn about Polymer, specifically custom elements. He remembers very early on wanting to make a custom HTML tag. He suggests that being able to do things without the framework has been a piece that has been missing. Having lower level building blocks to build off of is really exciting to Danny. He talks about using custom elements to build a familiar API surface to interact with. He talks about an example where he wrapped a bunch of HTML APIs, like the notification API and the fullscreen API, wrapping another element within it. He was trying to build things that the younger version of himself could use. He things that could be something we are heading towards more often. Danny adds that Web Components come with 4 major parts: Custom elements, HTML Imports (kind of), ShadowDOM, and templates. Custom elements allow you to create a unique piece of HTML and is the most widely accepted and supported. What are you working on now? Danny talks about how the Angular’s component model is very similar to Custom Element component model. Where you pass information in through properties and you listen for changes through events. You can use Custom Elements with very little setup. There is a specific Custom Elements Scheme that will let you use custom elements without any properties being thrown. You use the custom event in the exact same way and syntax as for any other component. The one issue with the source code where it parses the metadata, losing the friendly compiler messages out of the box. He is playing around with trying to find a way to whitelist different element names and properties. He wants to learn how the Framework is parsing potential data and make it easy to whitelist a set of custom elements. Picks Dannys Daemon by Daniel Suarez Bob’s Burgers CodeSchool Charles VR & Augmented Reality IoT Artificial Intelligence Veritone.com Coursera on Artificial Intelligence Artificial Intelligence with Python Machine Learning for Absolute Beginners Links Twitter Blog on Medium