Podcasts about soft skills engineering

Watch this episode on YouTube (https://youtu.be/3B6sNvVmjcw). Dima is concerned with the fate of expertise and how easy experts have it now, and together with Slava they look experts in the workplace and how they mess up code reviews. * The Death of Expertise (https://www.amazon.co.uk/Death-Expertise-Campaign-Established-Knowledge/dp/0190865970), the 2018 book * The Death Of Expertise (https://thefederalist.com/2014/01/17/the-death-of-expertise/), the 2014 article * Was it better for experts in pre-Internet times? * Well, who is an expert after all? * How can one tell a true expert from a false expert? * We expect experts to be able to explain things * Experts do not really need to cry out "I'm an expert!" * Expertise and appeal to authority * Expert opinion vs. just an opinion * Usually, we have interactions, not individual opinions * Feedback and areas of growth * Practicing expertise in a team or a company * Soft Skills Engineering episode 321: Politely, no and participation at scale (https://softskills.audio/2022/09/12/episode-321-politely,-no-and-participation-at-scale/) * In the next episode we read Pitch Anything (https://orenklaff.com/books/) by Oren Klaff

In this episode, Dave and Jamison answer these questions: I work at a small company that has recently grown from a couple of engineers to 40+ due to some great new project opportunities. As part of this transition, many new policies are being implemented. The policies concerning the engineering department primarily revolve around task tracking and reporting time. Gone are the days when an engineer can charge eight hours to “fixing stuff” and earn a paycheck. Most of us are on board, but there are three engineers in particular who have been around for quite some time and vary between subtly passive aggressive to downright combative when it comes to creating JIRA tasks and logging their hours. The problem? They serve an absolutely critical role in our company. They are nigh irreplaceable in an extremely niche market. How should a manager strike the perfect balance between forcing an engineer to do something that they don't want to do and not forcing them out? If this was a more common skillset, there wouldn't be an issue with telling them “You don't like it, go find another job”. But when there are a handful of people in the world that do this kind of thing and it closely involves hardware and these three just happen to be local… well, you get the idea. Losing these individuals would be a staggering blow the company. Making them redundant isn't economically feasible. Time to ramp up for this position would be close to a year. So I've recently followed the first rule of Soft Skills Engineering and quit my job. All right! I believe in the new role and I think it'll be a good change to me. Despite this, I'm feeling guilty about leaving my team behind. When my managers asked me how I was feeling in the last few quarters, I've mostly said I'm fine! I never told them my reservations about how the codebase I'm working on has no oversight, that they need to hire another dev because I don't trust being the sole keeper, that it seems like product has forgotten this feature. I even indulged them when they asked me to make a long-term career plan when I was certain I would leave by early next year at the latest. So, what's your take on how disgruntled employees often have to hide their true feelings? Maybe I could've been open, but it really seemed like the odds were against us, it's just that upper leadership was neglecting this feature and there was no urgency to improve things. But I still feel like I wasn't being fully honest. What do you guys think? Thanks so much and keep up the good work! Feelin' Guilty P.S. Do you feel that this industry naturally rewards lack of loyalty and connection? What do you feel about that?

Today we're going to talk about soft skills, and we're going to do so with an expert on the subject, Dave Smith. Dave and his cohost Jamison Dance are the founders and hosts of the Soft Skills Engineering podcast where they answer questions from technical people about non-technical work problems. Both Dave & Jamison have worked as software engineers from staff levels through director levels at a variety of companies including Lockheed Martin, Walmart, & Amazon to name a few.   Dave's team is currently hiring software engineers to join his company eVisit where their mission is to simplify healthcare delivery to everyone, everywhere. Apply here: https://evisit.com/company/our-story/#careers ABOUT BEING AN ENGINEERThe Being an Engineer podcast is a repository for industry knowledge and a tool through which engineers learn about and connect with relevant companies, technologies, people resources, and opportunities. We feature successful mechanical engineers and interview engineers who are passionate about their work and who made a great impact on the engineering community.The Being An Engineer podcast is brought to you by Pipeline Design & Engineering. Pipeline partners with medical & other device engineering teams who need turnkey equipment such as cycle test machines, custom test fixtures, automation equipment, assembly jigs, inspection stations and more. You can find us on the web at www.teampipeline.us***We hope you enjoyed this episode of the Being an Engineer Podcast.Help us rank as the #1 engineering podcast on Apple and Spotify by leaving a review for us.You can find us under the category: mechanical engineering podcast on Apple Podcasts.Being an Engineer podcast is a go-to resource and podcast for engineering students on Spotify, too.Aaron Moncur and Rafael Testai love hearing from their listeners. Feel free to email us, connect on Facebook, Twitter, Instagram, and subscribe on Apple Podcast and Spotify!

eVisit CTO Miles Romney shares his vision of how Telehealth can be leveraged to support and optimize the concept of Integrated healthcare delivery.  The use of telehealth increased significantly during the pandemic but the need exists to ensure that this technology is used to support an integrated care team.  Show Notes:   Favorite Books:  The Castrato by Martha Feldman; Hit Refresh by Satya Nadella; Cash & Dash: How ATMS And Computers Changed Banking by Bernardo Batiz-Lazo; The Everything Store: Jeff Bezos And The Age Of Amazon by Brad Stone.  Favorite Podcasts:  Dr. Nick: The Incrementalist; Stuff to Blow Your Mind; Soft Skills Engineering; This American Life.

In this episode, Dave and Jamison answer these questions: Questions This question came with a delightful ASCII-art diagram that I will now dictate as follows: “pipe space space space space” JK TLDR: I want to move up the ranks but I’m not sure what might await me… except meetings. What should I expect? And how do I get there? Too Small, Want MOAR! I work in a big enterprise as a Tech Lead in an ““agile team””. So day-to-day I focus on getting our team to build the current feature we’re meant to be building (eg by helping other devs, attending meetings, and sometimes writing code). The next step for my career would be what we call an “Engineering Lead” but I’m having a hard time figuring out what that role actually is and our “EL” is so slammed with meetings I’m afraid to take any of their time to ask… SO - Dave & Jamison, can you enlighten me? What might the goals and life be of someone at that level and how would someone who still codes every day(ish) start figuring out what to do to get there? P.S. It’s taken me about 4 years but I’ve finally managed to listen to every single SSE episode! (I have a kid, binging podcasts isn’t possible for me). P.P.S. In an interview recently I was asked ““What’s the most valuable piece of advice you were ever given?”” to which I replied ““To negotiate for better benefits in job interviews, got it from a podcast called ‘Soft Skills Engineering’””. The interviewer thought that was cool, subscribed to your podcast during the interview then REFUSED TO NEGOTIATE ON ANYTHING! >:( Living in a small town my options as a software engineer have been limited to working for one company straight out of uni for 7 years. Wanting to develop in my career, and knowing you have advised others in the past to move on from their first job out of uni. What is your opinion of seeking out and switching jobs into remote work? Will this provide the same development value found in a traditional job switch, especially after the impact COVID has had on the way companies see remote work.

🎉🎉🎉 Celebrating 200 episodes! 🎉🎉🎉 In this special episode, Dave and Jamison share crazy work stories contributed by listeners to celebrate 200 episodes of Soft Skills Engineering Right out of graduate school I was in the process of interviewing and got through two phone interviews to get the final in-person interview at a location-based startup. The office was mostly sales but also had a small dev team. The in-house recruiter gave me a rough itinerary two days before: get there at 8AM, have four hour-long interviews with the team, then possibly a coding “quiz.” I was skeptical of what the quiz was but all she said was that everyone who got through the other interviews wouldn’t have a problem, it was multiple-choice, and it would take less than half an hour. I get to the office 20 minutes early but have to wait 45 minutes more for my first round of interviews because an internal meeting went over; the recruiter apologizes and asks if I want breakfast, and I say I’ll take something small like a bagel; she says okay and disappears from the room never to return with food. I get through the culture interviews just fine, though I thought it was a bit odd that several of my interviewers (including a VP) brought in their catered breakfast/lunch into the room but never offered me to get some and I had to go find my recruiter so I could get a cup of water between interviews. The final interview was with who would have been my boss: the senior engineering lead. She proceeds to ask me the normal bank of engineering questions and then lets me ask anything. She starts sending me the vibe that the engineering team isn’t really respected and that as a junior I’d be expected to put in overtime and be on-call on weekends without comp-time and without being able to have a say in when I would be on-call. Then I get some seemingly weird questions: Do you work well with loud noises? How noise canceling are your headphones usually? Is it okay that I would develop on a Windows machine? The engineering lead takes me to the recruiter’s office so I can wrap up the day but the recruiter had left early and nobody knew where she had gone so I was escorted to the front door by a receptionist and left. I didn’t hear back for a week and got a call late in the evening saying they had moved on with other candidates. A few days later I got an email from the engineering lead apologizing for my experience and that they were revising their hiring process due to my experience. Hi Dave and Jamison, I have a crazy work story to share for your 200th show! In my first role as a developer I was working for a small agency building websites for clients. One day I was uploading a new site, which involved FTPing into the server and doing all the config myself. I didn’t really know what I was doing, all of this terminal stuff was pretty alien to me at the time. For some reason or another I needed to change the permissions on the files for this site, so I uploaded it to the server and ran a chmod, (which was a brand new concept to me - luckily Stack Overflow had my back. OR DID IT?) Anyway, when I ran the command, my terminal went crazy and way more files went flying up the screen than I had for my website, so I thought ““that doesn’t look right””, hit ctrl-c and went to lunch, thinking I’d fix it later. When I got back from lunch, everyone was rushing about like headless chickens. Everything was down. When I enquired, it turned out that for some reason everyone was locked out of the entire server. After several hours it turned out that all of the permissions for every file on the server had been changed and nobody had any access to anything. Also, every client site had been brought down in the process. To make matters slightly worse, when I enquired about backups, it turned out that the main server WAS the backup server, because the main server died a couple of years before and nobody had bothered to fix or replace it. Whoops! I didn’t fess up - I was too scared - but coincidentally, a few days later I was fired. Oddly, during the firing, no mention of this incident was made and to this day I have no idea if the two were related. At the time I was devastated, I thought my career was over and I shed tears over how I was going to be able to provide for my family. However, in less than two weeks I was in a new role with a 25% pay increase, and my career has bloomed ever since. So 👍🏻 I guess! And here ends my tale. I hope you enjoyed it - it was devastating at the time, but now I can look back on it with both amusement and bemusement. Thanks for all of your work bringing this podcast to us for 200 weeks, I hope you continue until you also accidentally lock everyone out of your own servers. This is a crazy interview story. It was with a healthcare tech startup. The building was across the street from the healthcare tech company where my wife worked. After meeting the 9 people on the team and doing some white boarding, I met with the CEO. When he asked why I was excited to work at his company, I mentioned in passing that my wife worked at the company across the street. CEO then says “Oh, wow. They just announced that they are going public.” At this point, the company had not announced that they were going public yet, but my wife already knew about it and told me that it wouldn’t happen for a few months. I demurred, but the CEO pressed more “Yeah, I saw it on the news this morning.” Yep. The CEO of a company that rivals my wife’s was asking for insider trading information. I actually had to rehash my conversation to my wife’s boss to make sure I didn’t give away anything important (which I fortunately did not). After that, I decided I would never work for any company in the same industry as where my wife works. About 7 years ago I was looking for a side income. A fellow engineer I worked with told me that the park he spends his weekends at was looking for someone to build them a website, run some wires and a bunch of other IT odd jobs. I was interested so I made the drive down to the park which further confirmed my suspections of my co worker: it was a nudist facility. I sat in my car for a few minutes to consider my options and walked in. It’s weird how being the only clothed person in the room made me feel so awkwardly naked. I spoke to the owner, shared my resume, and my co worker showed up (naked) to vouch for me. I got the job but only under the condition i ““wore the uniform””. I agreed and worked there over the summer weekends for a few months doing everything in the buff. Being near the beginning of my career I wanted to put this on my resume, but didn’t want to expose the private parts of this job. I ended up listing it as ‘contracter’ with just a note: references available on request. The company I work at is a privately owned B-to-C e-commerce shopping platform. Over the past two years the non technical management has been trying to position themselves to be bought out. Their strategy has been to create a new layer of director level management and hire in candidates directly from FAANG with the specific intent of injecting “FAANG” culture into the company. I guess the thought is - if you want to be acquired from a player like FAANG, then become a mini FAANG. Unfortunately, it hasn’t been working out so well. The 💩hit the fan. The new director have absolute power, and as it goes, ““absolute power corrupts absolutely””. The new Director of Engineering did a culling of senior engineers and managers that raised any questions to initiatives proposed by the director (you know, healthy project analysis probing to make sure potential risks are considered). One day, 15 devs were let go. These were senior engineers with years of domain knowledge. Not surprisingly, the platform started to have issues. Payment processing integrations started going down, checkout processes needed maintenance - but… the domain knowledge was gone. In the usual “throw more people at the problem” approach, everyone was assigned pager duty, even for systems they didn’t know. The system got so bad that the director resorted to shutting off one of the major payment processing integrations since it couldn’t be fixed. This had repercussions of course, and we started losing completed checkout conversions. The rest of the senior engineers were leaving voluntarily at this point. Now that the ship was pretty much on fire, and the engineering department pretty much destroyed, we found out that the director was applying to another job at the new Twilio office in the city 😂. We found out he got rejected because his reputation had preceded him and the recruiters at Twilio had actually heard about the mayhem he was causing at our company. But it gets better! One of my coworkers thought it would be a funny prank to put a Twilio sticker on the director’s office window. Nope, my colleague was promptly fired. We later found out that the director was so pissed that he ended up going through the CCTV surveillance recordings to see which employees had entered the building early to find out who put the sticker on his office window 🤦🏻‍♂️. Had a manager who had transitioned to IT help-desk work from teaching elementary school and then worked their way up to manager over a large development team. They never let go of the elementary teacher mentality. The highlights were: Requiring multiple forced-fun team activities a year, like cubicle decoration contests. Playground level nick-names for everyone on the team. (Think banana-fo-fana level rhyming). All team members got emoji stress balls, and were required to place the ball that reflected their daily mood on the wall of the entrance of their workstation.

We’re excited to have special guest Charity Majors on the show! Charity is the CTO and former CEO of Honeycomb. She has worked at Second Life, Parse, Facebook, and more. She blogs at charity.wtf. Dave, Jamison, and Charity answer these questions: I’ve had the role of tech lead informally for the past two years at a fast-growing tech startup. We were a team of 6 developers, and now we are 16. Recently, we had a department meeting in which the Software Development VP communicated that we have 3 teams and I was the tech lead of two of them. I was surprised. He hasn’t mentioned his decision of splitting the teams nor that I’ve been officially promoted to tech lead. I was expecting a one-on-one where he would “pop the question”: Will you be my tech lead? I asked him privately if that meant I would be officially promoted and would have my title changed. He said that he was going to have this conversation with the HR Manager and would get back to me, but potentially. He doesn’t spend time on one-on-ones, nor is he very good at managing people although he’s good technically. How weird is this situation? A manager tells his team that they now have a tech lead along some org changes. I haven’t been informed, haven’t had my title changed yet, and haven’t been offered a raise yet. Hi! I love your show and have been listening to it almost since day one. I was an engineer for about 10 years, and I’ve been a manager for about 1 year, and I love my team. They’re high performers, we have a high level of trust. I also like my boss! But the larger org has some issues, and in time-honored Soft Skills Engineering tradition, I plan to quit. I would like to stay in management. So I have these questions: 1) My employer is a very large public company. How much should I care about negative headlines and Wall Street’s opinion? 2) How long should I stay in my role as a manager before looking for a new job? 3) How do I message this to my team when I leave?

Jamison quickly took us through his studies, how he zoomed in on computer sciences... not without a few detours beforehand. We talked about his part time jobs and how he learned what a bad manager can be. We then jumped forward a few years to talk about management, what it takes to do a good job there, the challenges and successes of the function. We finished talking about two dreaded responsibilities of a manager: hiring and firing and how Jamison made his way through this.Jamison is a code whisperer and experienced product engineer. He has led teams and been led. Jamison is currently an engineering manager at Walmart Labs leading a distributed team in building delightful APIs and UIs that configure Walmart’s performance systems. He also co-hosts the "Soft Skills Engineering podcast". If this name is new to you, you should definitely listen to Episode 77 of this very DevJourney podcast where I interviewed Dave Smith, the other half of the co-hosts of this show. Oh and Jamison thinks you are great!Here are the links of the show:https://www.twitter.com/jamison_dancehttps://jamison.dancehttps://softskills.audiohttps://devjourney.info/Guests/77_DaveSmith.htmlhttps://tinyurl.com/shitty11meetingsBook: The making of a manager by Julie Zhuo https://amzn.to/37VTt1cBook: An elegant puzzle by Will Larson https://amzn.to/31layz0https://conf.reactjs.orghttps://www.reactrally.comhttps://devjourney.info/Guests/52_CharityMajors.htmlhttps://en.wikipedia.org/wiki/Camille_FournierCreditsMusic Aye by Yung Kartz is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License.Your hostSoftware Developer‘s Journey is hosted and produced by Timothée (Tim) Bourguignon, a crazy frenchman living in Germany who dedicated his life to helping others learn & grow. More about him at timbourguignon.fr.Want to be next?Do you know anyone who should be on the podcast? Do you want to be next? Drop me a line: info@devjourney.info or via Twitter @timothep.Gift the podcast a ratingPlease do me and your fellow listeners a favor by spreading the good word about this podcast. And please leave a rating (excellent of course) on the major podcasting platforms, this is the best way to increase the visibility of the podcast:Apple PodcastsStitcherGoogle PlayPatreonFinally, if you want to help produce the podcast, support me on Patreon. Every cent you pledge will help pay the hosting bills!Thanks!Support the show (http://bit.ly/2yBfySB)

Dave first told us where the idea for the Soft Skills Engineering Podcast first came from. Then he took us back to when he started programming, with the Basic language on a Texas Instruments calculator. We then followed his studies, and the start of his career... just after the DotCom burst. We then talked about his first steps toward management, and how he swung from individual contributor, to manager, and back. And after he changed company, how he continued swinging, becoming "Director of Engineering" in the process. We continued talking about his move back to more individual contribution at Amazon, and closed in on mentorship inside Amazon. Dave has 15 years of experience as a software developer. He led hundreds of engineers as a director, tech lead, and mentor. He's grown teams from 3 engineers to 50, 50 engineers to 100, and even had a front-row seat for Alexa's hyper growth from a few hundred to a few thousand. And Dave is finally the co-host of the Soft-Skills Engineering podcast!Here are the links of the show:https://www.twitter.com/djsmith42https://softskills.audiohttps://conf.utahjs.comStreet-Fighter for the TI calculators: https://www.ticalc.org/archives/files/fileinfo/83/8337.htmlCreditsMusic Aye by Yung Kartz is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License.Your hostSoftware Developer‘s Journey is hosted and produced by Timothée (Tim) Bourguignon, a crazy frenchman living in Germany who dedicated his life to helping others learn & grow. More about him at timbourguignon.fr.Want to be next?Do you know anyone who should be on the podcast? Do you want to be next? Drop me a line: info@devjourney.info or via Twitter @timothep.Gift the podcast a ratingPlease do me and your fellow listeners a favor by spreading the good word about this podcast. And please leave a rating (excellent of course) on the major podcasting platforms, this is the best way to increase the visibility of the podcast:Apple PodcastsStitcherGoogle PlayPatreonFinally, if you want to help produce the podcast, support me on Patreon. Every cent you pledge will help pay the hosting bills!Thanks!Support the show (http://bit.ly/2yBfySB)

JavaScript Jabber celebrates its 400th episode with former host Dave Smith and some other familiar voices. Each of the panelists talks about what they’ve been up to. Dave hasn’t been on the show for 3 years, but he and Jameson Dance have started a podcast called Soft Skills Engineering where they answer questions about the non-technical side of engineering. When he left the show he was the director of engineering on Hire View, and currently he works for Amazon on Alexa.  Christopher Buecheler has been on several JSJ, RRU, and MJS episodes. His time is divided between contracting for startups and his own company closebrace.com, a tutorial and resource site for JavaScript developers.  Dan Shapir has also been on JSJ as a guest, and is currently works for Wix doing performance tech. He enjoys speaking at conferences, such as JS Camp in Bucharest, Romania and the YGLF conference. Steve Edwards was previously on MJS 078. He started on Drupal in the PHP world, switched to JavaScript, and then a few years ago he started looking at Vue. Now he does Vue fulltime for ImageWare Systems. As for Charles, his primary focus is the podcasts, since DevChat.tv produces around 20 episodes per week. 5 new shows were started in July, and he talks about some of the challenges that that brought. One of his most popular shows recently was JSJ 389: What makes a 10x Engineer? This helped him realize that he wants to help teach people how to be a successful engineer, so he’s working on launching a new show about it.  The panelists share some of their favorite JSJ episodes. They discuss the tendency of JSJ to get early access to these fascinating people when the conversation was just beginning, such as the inventor of Redux Dan Abramov, before their rise to stardom. The talk about the rise in popularity of podcasting in general. They agree that even though JavaScript is evolving and changing quickly, it’s still helpful to listen to old episodes.  Charles talks about the influence JavaScript Jabber has had on other podcasts. It has spawned several spinoffs, including My JavaScript Story. He’s had several hosts start their own DevChat.tv shows based off JavaScript Jabber, including Adventures in Angular and The DevEd Podcast. JavaScript Jabber has also been the inspiration for other podcasts that aren’t part of DevChat.tv. There aren’t many podcast companies that produce as many shows as they do and they’re developing their own tools. DevChat.tv moved off of WordPress and is in the process of moving over to Podwrench. Charles talks about all the new shows that have been launched, and his view on ‘competing’ podcasts. Charles is also considering doing an audio drama that happens in a programming office, so if you would like to write and/or voice that  show, he invites you to contact him.  The show concludes with the panel talking about the projects they’ve been working on that they want listeners to check out. Christopher invites listeners to check out closebrace.com. He also has plans to write a short ebook on unit testing with jest, considered doing his own podcast, and invites people to check out his fiction books on his website. Dan talks about his involvement with Wix, a drag and drop website service, that recently released a technology called Corvid which lets you write JS into the website you build with Wix. This means you can design your user interface using Wix, but then automate it, add events functionality, etc. Dan is also going to be at the Chrome Dev Summit conference. Dave invites listeners to check out the Soft Skills Engineering podcast, and Charles invites listeners to subscribe to his new site maxcoders.io.  Panelists Dan Shapir Christopher Buecheler Steve Edwards Dave Smith Charles Max Wood Sponsors Tidelift Sentry use the code “devchat” for 2 months free on Sentry’s small plan Adventures in .NET Links The Dev Rev MJS 099: Christopher Buecheler JSJ 338: It's Supposed to Hurt. Get Outside of Your Comfort Zone to Master Your Craft with Christopher Buecheler RRU 029: Christopher Buecheler Getting Ready to Teach Lessons Learned from Building an 84 Tutorial Software Course MJS 108: Dan Shapir JSJ 334: Web Performance API with Dan Shapir JSJ 371: The Benefits and Challenges of Server Side Rendering with Dan Shapir MJS 078: Steve Edwards JSJ 179: Redux and React with Dan Abramov JSJ 187: Vue.js with Evan You JSJ 383: What is JavaScript? JSJ 385: What Can You Build with JavaScript JSJ 390: Transposit with Adam Leventhal JSJ 395: The New Ember with Mike North JSJ 220: Teaching JavaScript with Kyle Simpson JSJ 313: Light Functional JavaScript with Kyle Simpson JSJ 124: The Origin of JavaScript with Brendan Eich JSJ 073: React with Pete Hunt and Jordan Walke JSJ 392: The Murky Past and Misty Future of JavaScript with Douglas Crockford JSJ 391: Debugging with Todd Gardner JSJ 389: What Makes a 10x Engineer? cwbuecheler.com  Closebrace.com Corvid by Wix   Soft Skills Engineering podcast maxcoders.io                                                                                                                                                                           Follow DevChatTV on Facebook and Twitter Picks Steve Edwards: form.io Christopher Buecheler: Apollo GraphQL Playground @TheTimeCowboy Jake Lawrence Charles Max Wood: St. George Marathon GU Energy Original Sports Nutrition Energy Gel Vrbo devchat.tv/15minutes Dan Shapir: Revolutions by Mike Duncan podcast The Winter of the World book series Dave Smith: 13 Minutes to the Moon podcast by BBC The Mind

JavaScript Jabber celebrates its 400th episode with former host Dave Smith and some other familiar voices. Each of the panelists talks about what they’ve been up to. Dave hasn’t been on the show for 3 years, but he and Jameson Dance have started a podcast called Soft Skills Engineering where they answer questions about the non-technical side of engineering. When he left the show he was the director of engineering on Hire View, and currently he works for Amazon on Alexa.  Christopher Buecheler has been on several JSJ, RRU, and MJS episodes. His time is divided between contracting for startups and his own company closebrace.com, a tutorial and resource site for JavaScript developers.  Dan Shapir has also been on JSJ as a guest, and is currently works for Wix doing performance tech. He enjoys speaking at conferences, such as JS Camp in Bucharest, Romania and the YGLF conference. Steve Edwards was previously on MJS 078. He started on Drupal in the PHP world, switched to JavaScript, and then a few years ago he started looking at Vue. Now he does Vue fulltime for ImageWare Systems. As for Charles, his primary focus is the podcasts, since DevChat.tv produces around 20 episodes per week. 5 new shows were started in July, and he talks about some of the challenges that that brought. One of his most popular shows recently was JSJ 389: What makes a 10x Engineer? This helped him realize that he wants to help teach people how to be a successful engineer, so he’s working on launching a new show about it.  The panelists share some of their favorite JSJ episodes. They discuss the tendency of JSJ to get early access to these fascinating people when the conversation was just beginning, such as the inventor of Redux Dan Abramov, before their rise to stardom. The talk about the rise in popularity of podcasting in general. They agree that even though JavaScript is evolving and changing quickly, it’s still helpful to listen to old episodes.  Charles talks about the influence JavaScript Jabber has had on other podcasts. It has spawned several spinoffs, including My JavaScript Story. He’s had several hosts start their own DevChat.tv shows based off JavaScript Jabber, including Adventures in Angular and The DevEd Podcast. JavaScript Jabber has also been the inspiration for other podcasts that aren’t part of DevChat.tv. There aren’t many podcast companies that produce as many shows as they do and they’re developing their own tools. DevChat.tv moved off of WordPress and is in the process of moving over to Podwrench. Charles talks about all the new shows that have been launched, and his view on ‘competing’ podcasts. Charles is also considering doing an audio drama that happens in a programming office, so if you would like to write and/or voice that  show, he invites you to contact him.  The show concludes with the panel talking about the projects they’ve been working on that they want listeners to check out. Christopher invites listeners to check out closebrace.com. He also has plans to write a short ebook on unit testing with jest, considered doing his own podcast, and invites people to check out his fiction books on his website. Dan talks about his involvement with Wix, a drag and drop website service, that recently released a technology called Corvid which lets you write JS into the website you build with Wix. This means you can design your user interface using Wix, but then automate it, add events functionality, etc. Dan is also going to be at the Chrome Dev Summit conference. Dave invites listeners to check out the Soft Skills Engineering podcast, and Charles invites listeners to subscribe to his new site maxcoders.io.  Panelists Dan Shapir Christopher Buecheler Steve Edwards Dave Smith Charles Max Wood Sponsors Tidelift Sentry use the code “devchat” for 2 months free on Sentry’s small plan Adventures in .NET Links The Dev Rev MJS 099: Christopher Buecheler JSJ 338: It's Supposed to Hurt. Get Outside of Your Comfort Zone to Master Your Craft with Christopher Buecheler RRU 029: Christopher Buecheler Getting Ready to Teach Lessons Learned from Building an 84 Tutorial Software Course MJS 108: Dan Shapir JSJ 334: Web Performance API with Dan Shapir JSJ 371: The Benefits and Challenges of Server Side Rendering with Dan Shapir MJS 078: Steve Edwards JSJ 179: Redux and React with Dan Abramov JSJ 187: Vue.js with Evan You JSJ 383: What is JavaScript? JSJ 385: What Can You Build with JavaScript JSJ 390: Transposit with Adam Leventhal JSJ 395: The New Ember with Mike North JSJ 220: Teaching JavaScript with Kyle Simpson JSJ 313: Light Functional JavaScript with Kyle Simpson JSJ 124: The Origin of JavaScript with Brendan Eich JSJ 073: React with Pete Hunt and Jordan Walke JSJ 392: The Murky Past and Misty Future of JavaScript with Douglas Crockford JSJ 391: Debugging with Todd Gardner JSJ 389: What Makes a 10x Engineer? cwbuecheler.com  Closebrace.com Corvid by Wix   Soft Skills Engineering podcast maxcoders.io                                                                                                                                                                           Follow DevChatTV on Facebook and Twitter Picks Steve Edwards: form.io Christopher Buecheler: Apollo GraphQL Playground @TheTimeCowboy Jake Lawrence Charles Max Wood: St. George Marathon GU Energy Original Sports Nutrition Energy Gel Vrbo devchat.tv/15minutes Dan Shapir: Revolutions by Mike Duncan podcast The Winter of the World book series Dave Smith: 13 Minutes to the Moon podcast by BBC The Mind

JavaScript Jabber celebrates its 400th episode with former host Dave Smith and some other familiar voices. Each of the panelists talks about what they’ve been up to. Dave hasn’t been on the show for 3 years, but he and Jameson Dance have started a podcast called Soft Skills Engineering where they answer questions about the non-technical side of engineering. When he left the show he was the director of engineering on Hire View, and currently he works for Amazon on Alexa.  Christopher Buecheler has been on several JSJ, RRU, and MJS episodes. His time is divided between contracting for startups and his own company closebrace.com, a tutorial and resource site for JavaScript developers.  Dan Shapir has also been on JSJ as a guest, and is currently works for Wix doing performance tech. He enjoys speaking at conferences, such as JS Camp in Bucharest, Romania and the YGLF conference. Steve Edwards was previously on MJS 078. He started on Drupal in the PHP world, switched to JavaScript, and then a few years ago he started looking at Vue. Now he does Vue fulltime for ImageWare Systems. As for Charles, his primary focus is the podcasts, since DevChat.tv produces around 20 episodes per week. 5 new shows were started in July, and he talks about some of the challenges that that brought. One of his most popular shows recently was JSJ 389: What makes a 10x Engineer? This helped him realize that he wants to help teach people how to be a successful engineer, so he’s working on launching a new show about it.  The panelists share some of their favorite JSJ episodes. They discuss the tendency of JSJ to get early access to these fascinating people when the conversation was just beginning, such as the inventor of Redux Dan Abramov, before their rise to stardom. The talk about the rise in popularity of podcasting in general. They agree that even though JavaScript is evolving and changing quickly, it’s still helpful to listen to old episodes.  Charles talks about the influence JavaScript Jabber has had on other podcasts. It has spawned several spinoffs, including My JavaScript Story. He’s had several hosts start their own DevChat.tv shows based off JavaScript Jabber, including Adventures in Angular and The DevEd Podcast. JavaScript Jabber has also been the inspiration for other podcasts that aren’t part of DevChat.tv. There aren’t many podcast companies that produce as many shows as they do and they’re developing their own tools. DevChat.tv moved off of WordPress and is in the process of moving over to Podwrench. Charles talks about all the new shows that have been launched, and his view on ‘competing’ podcasts. Charles is also considering doing an audio drama that happens in a programming office, so if you would like to write and/or voice that  show, he invites you to contact him.  The show concludes with the panel talking about the projects they’ve been working on that they want listeners to check out. Christopher invites listeners to check out closebrace.com. He also has plans to write a short ebook on unit testing with jest, considered doing his own podcast, and invites people to check out his fiction books on his website. Dan talks about his involvement with Wix, a drag and drop website service, that recently released a technology called Corvid which lets you write JS into the website you build with Wix. This means you can design your user interface using Wix, but then automate it, add events functionality, etc. Dan is also going to be at the Chrome Dev Summit conference. Dave invites listeners to check out the Soft Skills Engineering podcast, and Charles invites listeners to subscribe to his new site maxcoders.io.  Panelists Dan Shapir Christopher Buecheler Steve Edwards Dave Smith Charles Max Wood Sponsors Tidelift Sentry use the code “devchat” for 2 months free on Sentry’s small plan Adventures in .NET Links The Dev Rev MJS 099: Christopher Buecheler JSJ 338: It's Supposed to Hurt. Get Outside of Your Comfort Zone to Master Your Craft with Christopher Buecheler RRU 029: Christopher Buecheler Getting Ready to Teach Lessons Learned from Building an 84 Tutorial Software Course MJS 108: Dan Shapir JSJ 334: Web Performance API with Dan Shapir JSJ 371: The Benefits and Challenges of Server Side Rendering with Dan Shapir MJS 078: Steve Edwards JSJ 179: Redux and React with Dan Abramov JSJ 187: Vue.js with Evan You JSJ 383: What is JavaScript? JSJ 385: What Can You Build with JavaScript JSJ 390: Transposit with Adam Leventhal JSJ 395: The New Ember with Mike North JSJ 220: Teaching JavaScript with Kyle Simpson JSJ 313: Light Functional JavaScript with Kyle Simpson JSJ 124: The Origin of JavaScript with Brendan Eich JSJ 073: React with Pete Hunt and Jordan Walke JSJ 392: The Murky Past and Misty Future of JavaScript with Douglas Crockford JSJ 391: Debugging with Todd Gardner JSJ 389: What Makes a 10x Engineer? cwbuecheler.com  Closebrace.com Corvid by Wix   Soft Skills Engineering podcast maxcoders.io                                                                                                                                                                           Follow DevChatTV on Facebook and Twitter Picks Steve Edwards: form.io Christopher Buecheler: Apollo GraphQL Playground @TheTimeCowboy Jake Lawrence Charles Max Wood: St. George Marathon GU Energy Original Sports Nutrition Energy Gel Vrbo devchat.tv/15minutes Dan Shapir: Revolutions by Mike Duncan podcast The Winter of the World book series Dave Smith: 13 Minutes to the Moon podcast by BBC The Mind

01:53 - Jamison’s Superpower: Moving swiftly between layers. 03:59 - Being An Engineering Manager * Context Switching * lftm (https://github.com/CoralineAda/lftm) * Career Advancement as an Engineer * Title Inflation * Providing Team Members with Growth Opportunities * Psychological Safety (https://en.wikipedia.org/wiki/Psychological_safety) * Challenging People with Goals * Comradery via Video Conferencing * Latent Learning 23:44 - Starting the Soft Skills Engineering (https://softskills.audio/) Podcast My Brother, My Brother and Me Podcast (https://www.maximumfun.org/shows/my-brother-my-brother-and-me) Engaging with People of All Backgrounds All Over The World The Emphasis of Soft Skills 35:42 - The Evolution of Tech Culture and Bootcamp Practices 39:54 - Conference Organization Balancing Technical and Interpersonal Talks Making Connections and Friendships Encouraging Speaker Choice Reflections: Jamison: Zone of Proximal Development (https://en.wikipedia.org/wiki/Zone_of_proximal_development). This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Amazon links may be affiliate links, which means you’re supporting the show when you purchase our recommendations. Thanks! Special Guest: Jamison Dance.

This week we talk Jamison Dance about the parts of programming that are distinctly non-technical. We talk about the perfect TLD, working with a team, finding psychological safety, the organization of React Rally, and how to recycle batteries. Jamison is co-host of the podcast Soft Skills Engineering where he and Dave Smith answer non-technical questions for technical folks. It's a great show that I highly recommend. check it out at softskills.audio

Vote for Soft Skills Engineering on the Hackernoon Noonies awards for best Dev Podcast! In this episode, Dave and Jamison answer these questions: How do I stop getting angry at other peoples’ code? Often when solving a complicated problem or implementing a feature, I have to modify or at least use systems designed by someone else. Often I find myself thinking ““Why did they do it like this??? This is so dumb!”” and literally getting mad in my chair. This happens no matter who wrote the code, and occasionally I discover that the author of the code was in fact Past Me. I know logically that everyone codes the best way they know at the time. So how do I avoid such a visceral reaction? Is this a common problem? Is this why many programmers seem to be Grumpy? My frustration often derails my focus and makes problems take longer to solve than they need to. What is the right etiquette for a code review for a pull request? I recently had an amazing code review. The reviewer pulled my branch, make a branch for changes he suggested and those changes all led to better and cleaner code. I felt the reviewer really tried to understand my design and test every suggestion before he wrote it. I felt that my code really got respect from the reviewer. However, a lot of my code reviews are just passive aggressive nitpicking like the comment formats are not right, the variable names aren’t clear enough. The worst was when I got a comment saying “this is already implemented” which after hours of figuring out what it meant was a different thing that would not work in my case. It seems like people have different ideas of what code reviews are and the etiquette and the expectations for it. As a reviewer and a reviewee, what should ideally happen in a code review process? Right now most code reviews are exhausting and infuriating experiences.

Vote for Soft Skills Engineering on the Hackernoon Noonies awards for best Dev Podcast! In this episode, Dave and Jamison answer these questions: One of my co-workers at the software company I currently work on has an ‘uncommon’ set of beliefs that include, among many other things, a strong mistrust of mainstream science. He is currently very concerned about the effect that Wi-Fi signals have on our health and wants the company to make some changes to our Wi-Fi hubs and our devices’ wireless connection usage. I’ve found in the past that it’s not easy to have a conversation with him about this type of topic. How can I be respectful to him and not undermine our work relationship while not giving in to connectivity inconvenience based on fringe-science beliefs? Hello! I love the show! The humor interjected into real advice (or real advice injected into humor?) makes thinking of boring and scary things like coworker relations or quitting your job sound fun! Everyone should resolve conflict and/or quit! I just started a new gig and I’m running into a situation I haven’t before. We have flexible work hours, but, unlike at previous jobs, people actually use them! I am meant to be pairing with another dev who is working quite different hours than me. I have a couple questions. 1) How do we communicate about this clearly? I tried to set expectations at the onset, but it seems we missed the boat. I asked when he works, told him when I work, and it didn’t seem this far off. But on a day we’re supposed to pair, he’s here an hour and a half after me, which means I’ll leave an hour and a half before him. 2) How do we make the time together the most effective? How can we turn about six hours of work into something meaningful, given normal distractions of meetings, bathroom breaks, etc?

Dave and Jamison host the Soft Skills Engineering podcast. Jamison talks about how he got into coding, and they talk about how they met and why they started the podcast, as well as the Dunning–Kruger effect, and React Rally.

Sponsors Netlify Sentry use the code “devchat” for 2 months free on Sentry’s small plan Triplebyte offers a $1000 signing bonus CacheFly Panel Nader Dabit Justin Bennett Lucas Reis Dave Ceddia Charles Max Wood Joined by Special Guests: Thomas Aylott, Conlin Durbin Episode Summary Conlin Durbin is a front end software engineer for a company called Lessonly and occasionally writes about React. Thomas Aylott is a web guy from the 90’s who was briefly on the React team, and he makes thingsthatdostuff.com and groovytiesquad.com. The panel discusses  Conlin’s article Link Lists in the Wild: React Hooks. They begin by talking about the relationship between linked lists and React hooks. Linked lists are used under the hood to render hooks every time that they’re created and maintain integrity of the hook chain. They discuss the importance of knowing what goes on under the hood share their methods of learning. They give tips for learning on the job. The panel agrees that one of the best ways to learn is to teach. Conlin shares his experience working for Lessonly, a company that builds lesson-building software. The panel discusses WET (Write Everything Twice) vs DRY (Don’t Repeat Yourself) programming. They talk about when it is beneficial to have abstractions in code and when it is not. It’s also important to think about the humans that are going to be using it, and to write the code so that it’s humane. They praise good error messages that tell you exactly where you went wrong and how to fix it. They talk about the dangers of putting invariants everywhere, and finish by talking about ways to improve. Links Linked list React Fiber Hooks Backbone JavaScript Redux Gatsby Flow Jake Archibald: In The Loop-JS Conf Asia 2018 (video) What the heck is the event loop anyway? (video) Practical 00 Design in  Ruby, Sandi Metz Stop trying to be so DRY, instead Write Everything Twice (WET) Sebastian Markbage: Minimal API Surface Area – Learning patterns instead of frameworks Someone Is Changing Your Code Conlin Durbin username for most places is ‘wuz’, except Twitter for twitter it’s @CallMeWuz Follow DevChat on Facebook and Twitter Picks Justin Bennett: The 3 most effective ways to build trust as a leader article Pheonix Live View Lucas Reis: Pamela Zave Small Functions Considered Harmful article Dave Ceddia: New Redux course Kinesis Advantage 2 Keyboard Charles Max Wood: MicroConf BuzzSprout Thomas Aylott: Noflojs.org The Laws of Human Nature by Robert Greene Conlin Durbin: https://dev.to/ Soft Skills Engineering Conlin’s Discord server

Sponsors Netlify Sentry use the code “devchat” for 2 months free on Sentry’s small plan Triplebyte offers a $1000 signing bonus CacheFly Panel Nader Dabit Justin Bennett Lucas Reis Dave Ceddia Charles Max Wood Joined by Special Guests: Thomas Aylott, Conlin Durbin Episode Summary Conlin Durbin is a front end software engineer for a company called Lessonly and occasionally writes about React. Thomas Aylott is a web guy from the 90’s who was briefly on the React team, and he makes thingsthatdostuff.com and groovytiesquad.com. The panel discusses  Conlin’s article Link Lists in the Wild: React Hooks. They begin by talking about the relationship between linked lists and React hooks. Linked lists are used under the hood to render hooks every time that they’re created and maintain integrity of the hook chain. They discuss the importance of knowing what goes on under the hood share their methods of learning. They give tips for learning on the job. The panel agrees that one of the best ways to learn is to teach. Conlin shares his experience working for Lessonly, a company that builds lesson-building software. The panel discusses WET (Write Everything Twice) vs DRY (Don’t Repeat Yourself) programming. They talk about when it is beneficial to have abstractions in code and when it is not. It’s also important to think about the humans that are going to be using it, and to write the code so that it’s humane. They praise good error messages that tell you exactly where you went wrong and how to fix it. They talk about the dangers of putting invariants everywhere, and finish by talking about ways to improve. Links Linked list React Fiber Hooks Backbone JavaScript Redux Gatsby Flow Jake Archibald: In The Loop-JS Conf Asia 2018 (video) What the heck is the event loop anyway? (video) Practical 00 Design in  Ruby, Sandi Metz Stop trying to be so DRY, instead Write Everything Twice (WET) Sebastian Markbage: Minimal API Surface Area – Learning patterns instead of frameworks Someone Is Changing Your Code Conlin Durbin username for most places is ‘wuz’, except Twitter for twitter it’s @CallMeWuz Follow DevChat on Facebook and Twitter Picks Justin Bennett: The 3 most effective ways to build trust as a leader article Pheonix Live View Lucas Reis: Pamela Zave Small Functions Considered Harmful article Dave Ceddia: New Redux course Kinesis Advantage 2 Keyboard Charles Max Wood: MicroConf BuzzSprout Thomas Aylott: Noflojs.org The Laws of Human Nature by Robert Greene Conlin Durbin: https://dev.to/ Soft Skills Engineering Conlin’s Discord server

This episode is sponsored by the O’Reilly Velocity conference. Register today and use discount code SKILLS for a 20% discount: http://velocityconf.com/skills. In this episode, Dave and Jamison answer these questions: Hello! Thank you for the show! What do you think about employee monitoring software? I received a message from a company about a job position and they use such software. It seems weird for me to make screenshots on my computer and to see what software I’ve use and what websites I’ve open. How do you feel about it? I’m a software engineer with about 2 years of professional experience. When I started working, I was motivated to learn all the things. I consumed technical blogs and podcasts in my personal time and proactively identified and solved problems for the team. Things recently changed. I can’t bring myself to care about work anymore. Curiosity used to come naturally to me but I can no longer summon curiosity about anything related to software development. A few things lead to this. 1) I got a lower than expected rating on my performance review due to an issue with my soft skills. I thought the feedback was valuable but didn’t think such a rating was warranted, considering my overall contributions. 2) Our team has spent the past few months writing code that didn’t ship. 3) I took the Soft Skills Engineering advice and got a new job. In order to do that, I spent many mornings and weekends preparing for technical interviews. After accepting the offer, I felt totally burned out. I very much want to be back to my previous, curious self by the time I start my new job. Unfortunately, I can’t take a long break before the start date. How can I get to a place where I feel motivated again?

Today is a special episode of Developer Tea, we're airing an episode in which Jonathan was interviewed by the folks at Soft Skills Engineering podcast.

Этот выпуск в YouTube: https://youtu.be/D1cmlsKhRcU Как это иногда бывает, тему этого выпуска сложно определить. Тут есть все от Славиной статью об ошибках в английском влияния окружения на чтение и психологических аббревиатур FOMO и FUD. * Подкаст Soft Skills Engineering (https://softskills.audio) * ДОУ опубликовал статью Вячеслава "Learn your mistakes, или Как исправлять свои ошибки в английском" (https://dou.ua/lenta/articles/learn-your-mistakes-in-english/) * Оптимистичные наблюдения * Новости year of liberation * Влияние места на то, как мы выполняем различные задачи * Fear of missing out (FOMO) (https://en.wikipedia.org/wiki/Fear_of_missing_out) * Fear, Uncertainty, and Doubt (https://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt) * Вольный пересказ лекции "Mental Accounting" от Вячеслава * 2-я теорема Вейерштрасса (http://ib.mazurok.com/2013/05/18/sec-theor-veyer/) * Снова opportunity cost * Cliffhanger (https://en.wikipedia.org/wiki/Cliffhanger): "Ты играешь в компьютерные игры?"

Этот выпуск в YouTubeКак это иногда бывает, тему этого выпуска сложно определить. Тут есть все от Славиной статью об ошибках в английском влияния окружения на чтение и психологических аббревиатур FOMO и FUD.* Подкаст Soft Skills Engineering* ДОУ опубликовал статью Вячеслава "Learn your mistakes, или Как исправлять свои ошибки в английском" * Оптимистичные наблюдения* Новости year of liberation* Влияние места на то, как мы выполняем различные задачи* Fear of missing out (FOMO)* Fear, Uncertainty, and Doubt* Вольный пересказ лекции "Mental Accounting" от Вячеслава* 2-я теорема Вейерштрасса* Снова opportunity cost* Cliffhanger: "Ты играешь в компьютерные игры?"

Welcome everybody to a Thanksgiving Day edition of Eggs! Today's guest is Dave Smith, senior software engineer at Amazon.com and co-host of the Soft Skills Engineering podcast. We had a great talk about working in the technology field, hiring and firing, what you can do to land your dream job and we attempt to get to the bottom of the creepy laugh that Alexa was doing for a while. This was a really valuable conversation chock full of insights and great information for aspiring developers, programmers and really anyone looking for work. So while that turkey is settling in your gut and you're tipping a tall one join us for a round of (devilled) Eggs, the Podcast! Rate, like and subscribe wontcha! Gobble gobble! Our Guest: Dave Smith - Podcaster and Senior Engineer at Amazon.com Soft Skills Podcast Twitter @SoftSkillsEng YouTUBE Live broadcast: https://www.youtube.com/watch?v=DrVjpC1t1SQ The Eggs Podcast Spotify playlist: bit.ly/eggstunes The Plugs: The Show eggscast.com @eggshow on twitter and instagram On iTunes: itun.es/i6dX3pC On Stitcher: bit.ly/eggs_on_stitcher Also available on Google Play Music! Mike "DJ Ontic" shows and info djontic.com @djontic on twitter Ryan R2 SLC/BCN r2mg.com ryanroghaar.com @r2mg on twitter @r2mediagroup on instagram

Dave Smith is on the Alexa Team at Amazon, he hosts the Soft Skills Engineering podcast and headed up the recent Utah JS Conference.Recently Dave asked on Twitter "on a scale of 1 - 10 in difficulty how would you rate the task of writing a function that iterates over a list of strings and returns the top 10?" This sparked up a lot of good, and most people rated it a 2-3 until people started asking "wait, is this question in an interview context? In that case, it's a solid 10." Dave talks about how the external stresses of an interview can turn even a "simple" question into a very stressful and challenging experience.The topic of interview "red flags" comes up, and Dave explains how the biggest one is refusing to answer a question. He says that even if you don't have an answer to something try to follow up with more questions and have humility, you are there to present yourself. Dave also says not to make up or guess at something if you don't know the answer, try to ask them to rephrase the question and give the angle of your own understanding.Dave has his own excellent podcast with his co-host Jamison Dance called Soft Skills Engineering, check it out in the link below.Transcript"Success and Failure in the Interview Process with Dave Smith" TranscriptResources:Soft Skills Engineering PodcastUtah JS ConferenceDave Smith:LinkedInGithubTwitterMediumJohn Lindquist:TwitterWebsite

Membahas seputar Soft Skills dan rekomendasi podcast bagus yang secara spesifik mengulas tema ini, yaitu Soft Skills Engineering. Lihat https://devmuslim.id/episode30 --- Send in a voice message: https://anchor.fm/devmuslimid/message Support this podcast: https://anchor.fm/devmuslimid/support

Membahas seputar Soft Skills dan rekomendasi podcast bagus yang secara spesifik mengulas tema ini, yaitu Soft Skills Engineering. Lihat https://devmuslim.id/episode30 --- Support this podcast: https://anchor.fm/devmuslimid/support

Dave and Jamison answer these questions: I’m a junior developer on a team of seniors, and I’m also the Scrum Master. Our team has lots of problems. What do I do? Jamison openly talks about not finishing his degree. How did he put it on his resume or explain it to potential employers? In question two Jamison discovers he has been lying on his LinkedIn profile for half a decade, and freaks out a little bit. The mistake is corrected, but can the damage ever be undone? Tune in next week on SOFT SKILLS ENGINEERING.

Jamison Dance: @jergason | Blog | GitHub | Fivestack | Soft Skills Engineering Podcast | React Rally Show Notes: 00:58 - The Elm Programming Language 01:36 - Who should try Elm? What is the attraction? 03:09 - Scaling an App Across a Team; Conventions 06:19 - Routing 07:48 - Writing Tests 09:38 - Jumping Into Elm from a Component-based Framework 12:20 - Tooling 17:28 - Productivity 19:21 - The Elm Community 25:13 - Could Elm Replace JavaScript? 28:28 - Lessons Learned from Elm to Write Better JavaScript 33:45 - The Elm Syntax 35:49 - Checking Out New Languages and Communities 37:31 - Data Modeling Resources: Elm Packages elm-format Evan Czaplicki: Let's Be Mainstream! User-focused Design in Elm The Elm Guide Elm on Slack The Elm Tutorial Jamison Dance: Rethinking All Practices: Building Applications in Elm @ React.js Conf 2016 Transcript: ALEX: Hey, everybody. Welcome to The Frontside Podcast Episode 49. I am your host, Alex Ford, developer at The Frontside. With me as well is Chris Freeman. Chris, do you want to introduce yourself? CHRIS: Hi, everybody. I'm Chris. I'm also a developer at The Frontside. ALEX: We have a really special guest for today. I'm really excited. Jamison Dance is with us. JAMISON: Hello. ALEX: Jamison runs Fivestack Software Consulting Company, hosts Soft Skills Engineering Podcast, organizes React Rally Conf, and spells 'array.length' incorrectly sometimes. Is this true? JAMISON: It is true, yeah. I think I have a special ESLint plugin to yell at me now when I do that or something. But that has caused some pain in my life. CHRIS: Oh, that was very brave. Thank you. ALEX: We're going to be talking Elm today and writing better JavaScript with Elm. This is really exciting for me. I've gotten the chance to dive into the Elm tutorial a little bit, which is an absolutely beautiful tutorial if you haven't checked it out yet. JAMISON: Yeah, Elm is a programming language that runs in the browser and compiles down to JavaScript. It's a pure statically-typed programming language, which if that doesn't mean anything to you, don't worry. The take away for you is that Elm tries really hard to make it easy to write programs that don't crash and are easier to refactor and easier to work on and maintain, basically. CHRIS: And Elm is a language in of itself but it is pretty specifically intended for front-end development. Is that correct? JAMISON: Right now, there are some long term plans, but yeah. For now, it's front-end for building UIs and applications in the browser. ALEX: I heard about Elm. When should I check it out? Who do you see jumping into this language? JAMISON: I think it's aimed at people that want to build robust applications which is so vague, it sounds meaningless. Maybe I talk about what attracted me to it. The two things where I was interested in functional programming -- that's kind of like the technical language wonk, like geeky side of it. But the other side is I've worked for a while in some fairly large JavaScript applications and I've seen the nightmares that I can create for myself In just building something that works and is just really hard to work on. So the idea of a language that's focused on keeping your productivity high as the application skills and as the team skills was really attractive to me. Like the bio says, if I spell array.length wrong, sometimes I catch it, sometimes I don't, then my program breaks. Elm has a compiler that runs on all your code and basically, make sure that your code cannot crash. You could still have bugs and you can still just make your code do the wrong thing but it helps eliminate whole categories of errors. It just makes them impossible to create in Elm. If you're interested in functional programming or if you're interested in just building stuff that is easy to work with, like this kind of this curve of productivity over time where some environments and some languages start out really high, it's really easy to build something fast at the beginning and then maintaining it is just really hard so the productivity drops over time. Elm is trying to kind of flatten that out so your productivity stays high throughout the lifetime of your application. CHRIS: I actually have a question about that. I'm planning on bringing this up later but you gave me such a good segue that I feel compelled. You mentioned that one of the things that is nice about Elm-type system is that it helps scale an app, especially when it comes to a team. My experience there are kind of true different facets to what scaling an app across a team looks like. One is the categories of bugs that something like [inaudible] compiler helps you catch. But the other is, and this is totally coming from the fact that I use Ember every single day, that conventions also help scale across a team. I'm curious like what I've looked at with Elm, it looks like they definitely have the type system there and error messages there to help quite a bit. But I haven't seen conventions arising yet in terms of a lot of things, about how you build a front-end application. I'm curious, is it that those conventions are there and just haven't found them yet or they're still very much in development? Or is that not even really a goal for Elm in the same way that it might be nothing like Ember or Angular. JAMISON: You mentioned first the kinds of bugs that the compiler will help you catch. I want to talk about that really quickly. If people aren't familiar with what a compiler or type system will do at build time, it checks all of your code to make sure that all of the variables and inputs and outputs from functions match up. So you say this function takes in an 'int' and returns a string and it will go find everywhere that calls that function and make sure that they're always passing in an 'int' and return it, so that it always return a string. It kind of does that throughout the whole flow of the program. It eliminates those kind of areas where you just get the interface wrong. The program is huge. You don't remember all the inputs to a function so you just like passing an object when it expects a string or something and then later on it will explode. You don't get those errors with Elm which is the first kind of thing you're talking about. You mentioned that conventions and I'm not on the Elm core team or whatever. I don't have any special insight but my experience is Elm very much wants to create strong conventions around how you build applications. The Elm architecture is kind of a way to build front-end applications that is basically baked into the language. There isn't like a UI framework for Elm. It is Elm. That to me is a huge point on the strong convention side. There isn't like an Elm fatigue because there isn't a choice between a hundred different UI frameworks in Elm. Some patterns around how you build apps this small, I think are still being established but I think there are strong conventions already and the trend of the Elm community is towards picking strong conventions. You'll see Evan, the creator of the language, He'll talk about how he wants to have one really good library instead of 15 overlapping libraries of varying quality to solve the same problem. Elm has conventions already. The places where it doesn't have strong conventions are I think places that will get filled in but the goal is to pick up the language and you get everything you need to build an application attached to it that's all kind of figured out for you. CHRIS: It's been interesting you mentioned the thing about it's better to have one good library, rather than 15 libraries of varying quality. I've seen that a little bit in practice. One of the things that I started looking for pretty early on when I was messing with Elm was what client-side routing look like. There are a couple of different routing libraries. But if you look at them, you can see that they're actually kind of this progression, like you can see how they have built on each other and they're kind of like building up the stack of abstractions toward one final solution. It's very interesting because it's not like those other libraries that are still there. If you really wanted to use just a regular URL parser and build your own, you could. But you can also see this development towards something that anyone could take off the shelf and start using. JAMISON: Yeah, and Elm has been around, I think it was 2011 when it first started. But really, Elm as like a popular thing that people hear about and use in production is only a couple of year's old maybe. There are still some things that are evolving like that. I think you're right that they're evolving towards convention instead of, in my mind JavaScript values, the proliferation of tons of different ideas and just wild exploration. Elm seems like it values a little more consensus and aligning the community behind one solution. I think it's happening, if it's not there yet, it'll get there, I guess. ALEX: I have a question about writing test in Elm and how that feels different than writing tests in JavaScript because the way I find myself writing tests right now is I understand the language to be fragile and I understand some frameworks have some fragility because of that language so I find myself writing really strong tests that are easy to break. I imagine that maybe in Elm, that's a little bit different with this very strong convention that you're talking about. JAMISON: Yes, some of it is around not having to be as defensive in your testing. If you wanted to get really, really down in the nitty-gritty in JavaScript, there are just an incredible array of different inputs you would have to test to make sure someone doesn't pass in like [inaudible] to this function where you think it's an array or whatever, like you just don't have to write any of those tests because the compiler catches that. We haven't talked about purity at all and this concept in functional programming where your functions can't cause side effects. They can't just go make a network request or write to disc or console.log like right in the middle. The functions take an input and return an output. You can do that in JavaScript. You can write your functions that way but because that feature is built into the language, it's the only way to write functions in Elm which makes it really easy to test functions because you just pass them stuff and you check what they return. In my experience, that makes them easier to test. You still build UIs and you still make network requests so you still construct some HTML at some point in your program. You can if you want to test that the HTML looks right or that elements have certain classes and stuff. But I guess what I'm saying is the tests feel like they're testing the behavior more than the edge cases when I write tests in them just because the compiler eliminates a bunch of weird edge cases you don't have to worry about. ALEX: Coming from a component-based JavaScript framework, what is going to be my experience jumping into Elm? How is that going to feel different for me? JAMISON: That's a great question. Myself and almost everyone I've seen get started in Elm that comes from something based around components that the instinct is to create components in Elm for everything. You have a select box in Ember or React or whatever and you wrap it in components. You can just reuse it everywhere. In Elm, if you try to do that, you will hate it and think Elm is broken and horrible and just sucks. It's because the Elm architecture comes with, I guess, you could call it boilerplate, there's some work you have to do to build a component that can do IO and respond to events and stuff. That work is... I don't know, maybe like a dozen lines of code. Then there's some work to wire those components up together, that's maybe a couple more lines of code. So if you have like 300 components in your Elm application, you'll have... I don't know, like thousands of lines that just wiring stuff together code which won't really buy you that much because in my experience, using components is an attempt to make things understandable and isolate concerns. You get a lot of that from having peer functions and having a strong a static-type system. In Elm, you end up making a lot wider components, instead of having this deep tree of lots of components nested inside of each other. You'll have a much flatter but wider tree. That took a while to get used to but I think it makes sense for the language now. You can still create reusable things but you focus more on creating reusable functions instead of creating components that are black boxes, that you kind of package up and pass around. You can still do reuse but it's a little bit different than reuse in a component-based framework. This is a thing. I would say, in the last year, there's been a lot more discussion on blogposts and screencasts and stuff on a year ago, a couple of people were talking about it but there weren't really lots of great examples of this and now, I think, even the Elm Guide has some examples of reuse without components. ALEX: Yes. One of my favorite things about component-based JavaScript is because I've learned to test them so well. Even though, sometimes they can turn into a configuration ball, I've been able to make them very reliable, even if they are deeply nested so going away from that scares me. JAMISON: Yeah, it totally scared me. It felt wrong and weird and bad. But now, it doesn't. I don't know, I'm used to it, I guess, and I still write a lot of JavaScript. It's not that hard switching back and forth between those two mental models but I definitely had to develop a different mental model when writing Elm code. CHRIS: I'm interested in talking about some of the tooling. I know Elm has a lot of tooling. They have elm-reactor and they have the compiler. But I think I know that you also do the kind of dip into some of the JavaScript tooling if you are getting into bigger Elm application. You're probably still going to need something like a Webpack or Browserify, I guess. I'm curious what's your experience with that has been? JAMISON: You can definitely just write an Elm application and then compile it into this JavaScript file then drop that in a script tag on your page and it will all work. The complexity can get very low. If you want to do more advanced stuff like talking to JavaScript, You can still do all that without any additional tooling, if you would like. If you have a lot of dependencies in your JavaScript or you have a large JavaScript application or code base that you want to integrate with Elm, then you can use something like Webpack or Browserify. In my experience, it's no more painful than Webpack or Browserify. All the rest of that stuff already is. I don't know, there's an Elm Webpack plugin that will run the Elm compiler and allow you to import your Elm application into JavaScript file and I think there are similar stuff for Browserify and some of the other module bundlers. I don't think there's anything radically new on the Elm side as far as bundling up your application or anything like that. It just kind of works like you expect. The places where, I think Elm tooling is cool in ways that I haven't seen that much in JavaScript are in the Elm package manager. If you are building a package yourself, it has automatic semantic versioning built in so they have a type system. They can detect when your interfaces change automatically. If you try and release a version that you change the interface and you don't bump the version, they will like yell at you because that's a breaking change. There's some cool stuff around that that you get with the language having a static-type system. The debugger is a new thing as of a couple of weeks ago. That's built into the language. You might have seen similar stuff in other frameworks but it's all kind of extra add-ons. In Elm, because it has kind of a framework built into the language, they can also build in a debugger for that framework in the language. You can enable debug mode, pull up an application, click around, do a bunch of stuff, and then it'll record a log of all those actions and you can scroll back through them and jump to any point in that timeline to reload the state of the application to that point. You can export that log to a JSON file and then kind of send that around, have someone load that log in, and it'll get your application back into the same state. It's a really good for creating bug reports. You click some button 15 times and then it breaks -- do that, export the logs, send that to someone else. Instead of having to follow all the steps, they can just load your state and then figure out what's broken about that. I think that there are some tooling advances that are enabled by both the language itself, like the static type system and also the focus on strong conventions and frameworks built into the language. Does that makes sense? CHRIS: Yeah, absolutely. As you were talking, I thought about was that some tooling that you lean a lot on in JavaScript is kind of rendered unnecessary by the error messages in Elm. All of the things that you may bring in an extra tool to catch in JavaScript when in Elm will just tell you when it compiles and it will give you this just unbelievably friendly, informative, and easy to diagnosed error message that tells you like, "This is the exact line where this happened. Maybe you mean to do this instead," because it can make all sorts of inferences about, like what you probably meant to do based on the type signature you gave to a function or something. I could see that going a long way toward making a subset of tools just unnecessary in Elm. JAMISON: Yeah, a lot of tooling around JavaScript has sprung up to address... I don't know, not weaknesses but areas where people have identified JavaScript needs a little help now. If that's passive aggressive enough way to say it. The language is 20 years old. It was created way before people were building giant, million line code bases in it. But Elm is much younger and has the benefit of a lot of history and hindsight. It turns out you can avoid a lot of tools if you eliminate their need. I have had that weird feeling where I'm building a JavaScript project and it feels like I'm flying a 747. There's a thousand switches everywhere. I'm like powering up a bunch of different things. It feels like I'm being really productive because I'm configuring ESLint in Webpack, in Flow, and all these different tools. Then I go to Elm and I just start typing and it feels like I'm less productive but I've just skipped so many steps. It is a different feeling. ALEX: Would you say that maybe you feel so productive in JavaScript because it has such a strong community, with so many examples and so much shared code? Elm being a younger community, and this is strictly an assumption, may not be at that maturity level where you can share code and have that particular level of productivity. JAMISON: Yes. There are definitely third party libraries in Elm. There's probably a few orders of magnitude difference in the community sizes between Elm and JavaScript. There are just way more people writing JavaScript. The likelihood that someone will have ended up at your weird feature that you need for some random program is probably a little higher. There are some numbers differences. In my experience, the people that are really into Elm right now enjoy solving their own problems because it does feel like they're a little bit more of your own problems to solve. It's a tradeoff. I was going to say, if you value 100% focus on building business features, JavaScript might be better but I don't necessarily think that's the case. Using a bunch of third party code comes with a cost and some of that cost is you have to understand the API and some of it is you have to kind of take some responsibility for knowing where it breaks down. In Elm, I think that responsibility is lessened by the language because the API is a lot easier to understand when you can look at the types that the API creates and uses. It's a lot harder for it to just break your stuff. I think you could make the argument that even though there's a giant repository of JavaScript code out there, a lot of it might not be great for your program. But if you're using Elm, the smaller amount of code that is out there already could be easier to use and help you even more productive. ALEX: I would like to try to segue into the Elm community now and what that looks like? What is this Elm community? How do you get involved, say, I'm coming from JavaScript or any language and I love it? Maybe my work doesn't use Elm just yet but how can I contribute? How can I continue to write more Elm code for not just my specific use cases? JAMISON: I think my favorite thing about the Elm community is its focus on friendliness and learnability. I call it 'ruthless focus'. They are aggressively committed to building a language that is easy for people to pick up. If you are coming to Elm for the first time, you're pulling your hair out because it looks totally different from JavaScript. That might not make any sense to you. But a lot of the ideas that Elm has come from other languages like Haskell or ML languages and those languages, I would say, are proudly hard to get into. It's like a badge of honor to learn Haskell and then you like bleed to do it and then you enter this elite club where you got to talk about monoids all day. Elm is like a strong negative reaction against that, like they want this to be a language that people can learn and get some of the benefit. Because there are cool things in languages like Haskell so the goal is to take some of those cool things and other cool things from other places too. But put them in a package that is easy for people to pick up without devoting their life to an arcane branch of mathematics. I think they do a really good job of that. I've done Haskell pretty hard a few times and I'll bounce off it some more. I don't feel confused about Elm at all in anyway. In Elm, it's not like I'm some genius that can pick it up. It's that they have eliminated a lot of complexity and made it friendly and easy to learn. I think that carries over into the community. They're really interested in helping people who are new to functional programming or are new to programming in general. They're also just nice. if there's an Elm Slack channel that you hang out in and like any internet chat channel, sometimes people will get a little testy and in the Elm one, they're so good at defusing situations, calming people down, like apologizing, and like being human beings. You don't see a lot of rage-y arguments where people say mean things about each other. I've been really impressed with that. I want to talk a little bit more about what the community is like and then maybe talk about how to get into it, if that's okay. I would say the community is -- I know, it's evenly split but it seems fairly evenly split between people coming from JavaScript's who don't have any functional programming experience and people coming from functional programming who don't have any UI experience. It's interesting seeing those two very different groups come together and they're both attracted to Elm for different reasons and they kind of pull it a little bit in different ways. But it makes an interesting group of people to be around because you learn a lot of cool UI stuff, a lot of cool functional programming stuff. ALEX: Sounds like a recipe for success, really. JAMISON: Yeah. I think if they can make functional programming not have the snootiness that it has sometimes in genders and people, then I think functional programming is great technically. I think the culture around it can be just obnoxious. So I think if Elm can take the good things without the bad things, that's amazing and that's kind of what it's trying to do. As far as getting into the Elm community, are you talking about writing open source or contributing to open source or just where they hang out? ALEX: Yeah, I was talking about contributing to open source but maybe Elm is just a better community for a certain style of contribution and maybe that looks like a blogpost and a coding example of how to do something yourself. JAMISON: Like any new technology, there are definitely in the kind of evangelism phase. If you do write a blogpost that says nice things about Elm, there's like a horde of people that will swarm all over it because they like people to say nice things about Elm. There's a bunch of people like writing books, doing screencast, speaking on it, introducing people to it, and that's well received very well. I think there's at least one podcast on Elm already. So all that to say that I think the community receives kind of education and I guess, you can call it evangelism stuff very well and they're excited about that. If you are interested in contributing to open source, you can actually go to Package.Elm-Lang.org and you can see all of the Elm third party libraries and they all have these GitHub for the backing of its package manager. They all have source links right there. You can just find any random library and get to its source. I think the community is pretty open to contributions from people. If you want to see Elm source code and contribute to it, they're very open to that. This is kind of a culture shock to me coming from other communities where you can't just like show up, submit a patch to Elm core, and then have a discussion, and get it accepted or rejected. They're not super open to direct code level contributions. They would prefer more use case feedback, discussion, and suggestions. Then the core team will take all these feedback in, think about it, come up with a plan, and then implement it, instead of take a lot of little patches from people. Some of the core libraries are a little bit harder to directly contribute code to but they are very open. If you try and use it, you run into something that doesn't work the way you expected and you can create a small example that demonstrates that. They're super open to discussions about that to influence the direction of the API. CHRIS: I think over the course of JavaScript and front-end development, there has been kind of waves of abstraction over JavaScript. There were just libraries and there were things like backbone and then it kind of moved into doing something like CoffeeScript or TypeScript and a couple others where the idea is -- ALEX: Good old Objective-J. CHRIS: Yeah, exactly. You might be transpiling down a JavaScript but there are still very much a clear link between something like CoffeeScript and JavaScript. Elm seems like it is one of a new batch of approaches where we're actually going to just sidestep JavaScript almost entirely. Like it is going to be like JVM bytecode or a browser and we're going to build an entirely new language on top of that. I know there's also a bit like ClojureScript, Scala.js, and PureScript and I'm curious, do you think that is going to be a continuing trend that front-end development is going to land on a mainstream solution that might not actually be JavaScript at all? Or do you see it as eventually circling back and pulling a lot of these features into JavaScript itself? JAMISON: I don't think that front-end development will be Elm in like five years or whatever. I don't think it's going to replace JavaScript at all. I think it might definitely influence tooling libraries or the language itself. The Elm architecture looks a lot like Redux because the Redux author read Elm and they're like, that's cool and then they wrote it in JavaScript. There are other places where like time-travelling debugging. I believe the JavaScript thing came from the Elm time-travelling debugger as well. There are cases where it has influenced JavaScript's already and I think that will continue to happen. Flow is a gradual-type system. You can lay it on top of JavaScript and they have done a lot of work on their error messages influenced by Elm. It's super cool to see all those influences back into the JavaScript community as a whole. I think there are classes of people who are more interested in doing some sprinkling of JavaScript on to pages. They might not even be like programmers really. They're kind of like designers who do a little bit of coding and I don't know if Elm makes sense for that kind of role where you just need to add a little bit of interaction. You can do that but it doesn't seem like a thing that group would focus on. It's just really hard to change the world. I write a lot of JavaScript so I'm bias but it feels like it's the most popular language in the world and being the most popular Language in the world is not a thing that's easily overthrown. But I think it will grow, like programming will look more like Elm does just in general in the future and I think JavaScript will as well. But I also think Elm will continue to grow. There's a lot of excitement about it and there's not a ton of people bouncing hard off of it. There's some people they're looking at it and they're like, "Eh, not yet." Some people just look at it and hate it. But from people that use it, I don't see a lot of those people dropping out. I've seen most of them sticking around. I think the trend is definitely -- Elm will grow. But I don't know if that will take over the world. ALEX: Then what lessons are developers bringing back to say and to write better JavaScript? JAMISON: I think a lot of people are learning about types and data modeling. If you learn programming through JavaScript, the idea that there's this defined shape that your data has and some tool will help you make sure that your data always looks like that is kind of like strange and foreign. I think a lot of people are learning that there's value in that. If you grew up in the MongoDB / Angular world like everything is schema-less, you just kind of slam some JavaScript objects everywhere, it all works, then it breaks, and you don't know why and you need to track it down. But I think seeing the value and thinking a little bit more clearly about what your data looks like and then forcing that through tooling is one lesson. That is taking a little bit more root in JavaScript. All the stuff around functional programming in JavaScript is like achieved buzzword status by now. But there is definitely still some education happening around how it's easier to test peer functions, how they're easier to understand and reuse, and how it's good to write them. I think Elm will continue to push that. Some of it though is there are some ideas you can take from Elm but it's just so much easier to use them to their fullest potential in a language and environment built around those ideas. You can kind of like cram a type system on to JavaScript. It's still really easy to get around and it does not model side effects at all. The elm type system modeled side effects so it helps you reason about where my program can talk to a network, where it can do things that are going to take a while to come back, and kind of sandbox those things into a place where you expect them, instead of have them sprinkled all over your program. CHRIS: I definitely feel that uncanny valley of trying to bring FP -- functional programming -- things back into JavaScript when it comes to pattern matching. That's something that in Elm or Elixir or any number of more functional languages. Pattern matching enables a lot of these higher level patterns that don't always translate super great back to JavaScript land. JAMISON: Yeah, the uncanny valley is a great way to put it. There are a lot of things that you can do that will lead to better JavaScript. But you always have to take the environment that you're working in into consideration. There are just some things you can't do or some things that are going to be more pain than they're worth to do. On the other hand, it is kind of nice to just type console.log wherever you want or type like '$.getJSON' or whatever. The added security that Elm brings comes at a cost of locking you down a little bit and that can be a little frustrating to people sometimes. But I think the payoff is worth it. ALEX: A side story. About six months ago, I tried to get into the Haskell programming book. That's currently being worked on. That's because I want to learn some functional programming lessons, maybe bring them back into my JavaScript, or just learn something new. It's useful to learn a new language and bring it back to your work. Of this 1300 page book, I got just past Chapter 2 and I was in a Haskell book club like everybody held each other accountable to finish this book. I did not make it. I could not figure out how to bring any of these lessons back into my code which is what I wanted to do here. Elm takes that functional programming concept and says, "We're applying it to UI right away." There's no, "How do I apply this? How do I side step this?" No, you're doing it immediately. Really, you're getting me excited to jump back into this tutorial and learn it and check out the community, just to be able to bring this back to my day to day and bring those lessons and do it. JAMISON: Yeah, the first time I tried to learn Haskell, I learned that I could sort an array of integers in memory and that was it. That was as far as my Haskell skills took me so I definitely feel you there. In Haskell, they'll tell you it's a research language so they have a lot of reasons why it kind of works the way it does and learning it takes the pathway it does. Elm is definitely not a research language. It's trying to be incredibly pragmatic so you build UIs. In the guide, that's how they teach you the language. It's the stuff you normally build. Thank you for bringing that up. I think, it's a thing that they focus on. I'm glad you picked it out. ALEX: Yeah, at the learning curve is the syntax but you're still solving those same problems. If you're coming from UI, you already have that context. That is probably the majority of the hard work -- it's solving problems that are meaningful to you. JAMISON: Yeah, for me the syntax, I had learned enough Haskell that the syntax wasn't hard -- how to make HTTP requests and do site-affecting things like that. It was the hang up for me but Elm, there is a way to do it and they show you and that's how you do everything and it all works the same way and it's fairly easy to understand. I don't want to call it easy because that makes people that struggle to feel that but they put a lot of work into making that both robust so it won't break your program and also learnable. CHRIS: One thing I would love to mention about the syntax, I have learned a number of languages, I guess and the Elm syntax was definitely one that threw me the most and it put me off for, I guess it wasn't so much just the syntax, it was the syntax combined with how people do things that I would call more like style choices. JAMISON: The formatting? CHRIS: Yeah, Elm formats things in weird ways. Except that there is a tool called 'elm-format'. Once I've discovered that it has a really great editor integration for a lot of editors, it effectively remove that problem because I discovered that I can essentially write garbage basically in my editor and I can say that anything will make it look beautiful. It's fantastic. It removes such a big barrier for me when I was trying to learn it. JAMISON: Yeah, elm-format, there were some great debates about it while it was being created but now that it exists, it's awesome. Speaking a little bit more of tooling, Elm comes out with new releases of the language with some backwards and compatible changes. But along with that, they release a tool to upgrade your Elm code automatically. It's not perfect and it won't run on 100%. It won't fix everything but with most projects, it fixes everything. Again, the benefit of having such a strict language is there's tools that will just upgrade all your stuff for you. That's pretty awesome. It lowers the cost of evolving the language because they can keep adding new things and changing things without just leaving the community in the dust like we've seen in some other stuff. That's kind of an Ember-ish thing, I guess. Ember has the whole stability... What is it? Something without stagnation? Stability without stagnation? CHRIS: Stability without stagnation. JAMISON: Where you just get all these free upgrades that are really easy to opt into and Elm has that same philosophy. ALEX: What made you decide to check out Elm, to check out this community? Do you like to jump into new languages, new communities, and poke around and see what sticks? Or is there something that attracted you to Elm in particular. JAMISON: Yes to both of those. I do poke around in a lot of new languages. I have a good friend, Sean Hess who's really into functional programming and he's a Haskell true believer. I am not but he is, so he teaches me stuff by Haskell. I think, he told me about it. I might be misremembering though. It might have been just some random blogpost or podcast somebody did a few years ago. But I was already excited about new languages and functional programming and I had tried to learn Haskell and bounced off so the idea of a functional programming language that takes some good ideas from Haskell, that runs in the browser that's new. It was like all the shiny things that I look for altogether in one thing. I tried it and I liked it. I, also was really impressed by Evan Czaplicki, He's the creator of Elm. His philosophy around creating a language and the goals he wanted to accomplish with it. There's a really good talk he gave and called 'Let's be mainstream' which talks about some of the stuff we talked about around if functional programming is pure statically-typed functional programming is so amazing and it has all these people that love it and swear it's the only way to write software, why no one does it? Why the number of people use it is so small? His thesis is basically because the languages that do this are kind of user hostile so he's trying to make it a user friendly, the one that takes all those ideas. I just really liked that philosophy. CHRIS: I want to go back to something that you mentioned a little bit ago and that was data modeling because that is definitely something that I noticed being extremely helpful, any time I'm using a statically-typed language. It is very much something that I brought with me back to JavaScript. But I was wondering, Maybe you could talk a little bit more in depth about what data modeling really means in terms of Elm, the type system, the record type, and that kind of stuff. JAMISON: Yeah, if you've worked with statically-typed languages like Java or C++ or something, you might have an idea of things like classes as a way to model data where you create a class and you say it has all these fields on it. I think, in the Elm type system, I'm going to say it's a lot better than those languages because it has a lot less ceremony and it is a lot more powerful. Elm has type inference which means you don't have to declare the type of everything. It can just figure it out from a lot of places. That's the thing that makes your code a lot friendlier to write. To model data in Elm, there are two main ways to do that. One is with these record types that you mentioned, Chris. You basically declare an object that has a certain shape like I'll make a type called 'user' and it has a user ID and a hash password and... I don't know, a list of my favorite cats or whatever. Then you can just refer to that user type in function arguments or in return types or anything like that. In Elm, because you created that type, it knows that these are all the fields it has. If you try to access a field that's not on there, it'll yell at you because you're doing something that won't work. Because you have to think through all of the different fields that are on your types, it forces you to do a little bit more. It's kind of like the other side of TDD instead of writing test first. You have to think about your data first. You could call it type-driven development, I guess. CHRIS: That's awesome. JAMISON: In my experience, that's helpful. In the same way, TDD is, right? It helps you to do a little bit of design first. Think about how you're going to interact with the program in some way. Instead of writing tests, you're thinking what data do I need here. They also have these things that you could call them -- there are a bunch of different names for them: algebraic data types, I guess. Some people call them tagged unions. They're kind of like enums where you say this type can take any of these finite list of values. But instead of an enum being like an integer, like it is in some languages with a fancy name wrapped around it, the enum types can contain other value. You can say... what's a good example for this? You could say a user is either an authenticated user with a user record inside it or an unauthenticated user. Then when you're using that type in your program, you check, "Is this user type the authenticated user?" Then, if so it has this user field inside of it that you can pluck out and use. Or, "Is it an unauthenticated user?" Those two different things, the super enums, the algebraic data types plus the record types are really powerful for modeling what data looks like in the real world. I haven't run into that many issues where it's been hard to do something I want to do with just those two concepts. Type systems are hard to explain over the air but hopefully, that helped a little bit. ALEX: I thought that was great. CHRIS: I think a good example of the algebraic data type thing is looking at messages in Elm versus actions in Redux. If our listeners are familiar with those, they are very, very, very similar at a high level. But in Redux, you just have string then you do a switch statement or something and you match on some strings. You hope that you synced everything up correctly. JAMISON: Yeah, you say, "This action has a message and then has a payload that looks like this." See if it match against the message and then hope that the payload somebody sent actually looks like you expect it to look. CHRIS: Yeah, whereas in Elm, you can actually say, "My message type is a union of all of these different things," and now, Elm knows exactly what you're saying and you can't accidentally send the wrong payload to the wrong update function or something. It's one of the cases where I found that there's a very, very clear similarity in JavaScript and it highlights, I think a lot of the nice features that Elm brings to that equation. JAMISON: Yeah and there's even more strictness around that, like you have to handle every message type in Elm. So if you say, "This function takes in a message and does something with it," and then you check against what kind of message it is, you have to check every case or Elm won't compile because they don't want you to just blindly miss something, I guess. But in Redux, you could just happily forget a thing in your case statement and then you send a message and it doesn't do anything and then you have to kind of trace through it and debug why that's happening. There's just more helpful stability stuff built in. CHRIS: Cool. I am so incredibly happy with how this podcast went. I'm just excited to start coding and start getting into Elm. I think people and developers maybe at an inflection point with JavaScript and just going and checking out something else that they can immediately apply back to their day to day. I think, it's so incredibly valuable and something that I'm going to be looking to explore very certain. JAMISON: The value pitch is pretty strong because everyone that's written JavaScript has just written code that breaks when things get passed around that they don't expect. I do that all the time and Elm makes that impossible. You can break it in other ways but you just eliminate this class of errors that plagues your existence in JavaScript. If you want to experience that life, check out Elm. It's got a lot of other good things too but just writing code that does not crashes is a pretty strong pitch, I think. ALEX: Jamison, are there any resources that you might recommend for someone who wants to get started with Elm? JAMISON: Somebody mentioned the guide a few times. Everyone says that about every language, check out the official tutorial or whatever, and they have wildly varying quality. The Elm guide is the thing that worked a ton on. It's pretty good, I think and geared towards people that have no knowledge of Elm, no knowledge of functional programming stuff. That's a Guide.Elm-lang.org. Then there's a Slack channel. If you just go to Elm-lang.org, it will have links to the Slack channel and there are lots of helpful friendly people there. I think those are the two best resources because with those, you can find all the other stuff. CHRIS: There's also another one that I really like to mention which is the elm tutorial. I think, it's Elm-tutorial.org. I found it to be a really great compliment to the official Elm Guide. I think it walks through a little more in building a full app where the Elm Guide kind of touches on a bunch of different related topics. But they're not necessarily one narrative. The Elm tutorial did a really good job of tying all that together for me. JAMISON: Yeah and this is been around for a long time and has kept it up through the evolution of the language. This is good stuff. ALEX: Jamison, thank you for coming on the Frontside Podcast. We really appreciated talking to you. JAMISON: Thanks for having me. ALEX: If you love Jamison's voice, you should check out his React Conf talk from 2016 also about Elm. It's a wonderful talk. Go check that out as well. JAMISON: Thank you. Can I pitch my other stuff too? Is that kosher? ALEX: You can absolutely pitch it. CHRIS: Soft skills engineering! JAMISON: Yeah, I do a podcast called Soft Skills Engineering with my friend Dave Smith where we talk about all of the non-technical stuff in writing code. It's like you [inaudible], you can submit questions, and we answer them. If you're interested in talking about building software together, you should talk to the Frontside first. But after that, you can find me at Fivestack.computer. That's where my consultancy lives. Consults is maybe a strong way of describing it. That's like saying the three toddlers standing on top of each other in a trench coat is like an adult. But if you want to work together, then check that out. ALEX: Great. All right. That wraps it up for us. Thank you very much for listening and we'll talk to you next week.

Welcome to Soft Skills Engineering, where we answer your questions about non-technical topics in software engineering. Come get some wisdom, or at least some wise cracks. In episode 1, Dave and Jamison answer two questions: I’m a developer who gets approached from time to time to work on new software ideas. While I find working on something new and intriguing I have no experience with business. How do I determine how legitimate these opportunities are? At my current job, our codebase is a few years old and we use an “older” javascript framework. In my spare time I’ve really really enjoyed using one of the newer paradigms and technical stacks and I wish I had more opportunity to get experience with these technologies. I don’t see a rewrite or even a migration any time soon for our codebase at this company and have been considering taking a job where I’d have opportunity to work with these newer technologies. This despite enjoying my coworkers, and lacking any major complaints at this company. On a scale from 1 to 10 how crazy am I for considering a job change?