« All Episodes

Listener Question: David asks About How to Answer Tooling Questions

Published 5/5/2017

In today's episode, I answer listener David's question about how to answer questions from peers about tooling.

Today's episode is brought to you by Linode. Linode Provides superfast SSD based Linux servers in the cloud starting at $10 a month. Linode is offering Developer Tea listeners $20 worth of credit if you use the code DEVELOPERTEA2017 at checkout. Head over to spec.fm/linode to learn more about what Linode has to offer to Developer Tea listeners .

Transcript (Generated by OpenAI Whisper)
What do you tell another developer when they ask you a question about a project you've done that you feel like really isn't that important? That's what we're talking about on today's episode of Developer Tea. This is in response to an email that I got from a listener named David. David, thank you so much for emailing in this question. On this show, my goal is to coach you through the hardest parts of your career. That includes answering your questions. If you have questions like David had for me, please send them in. You can email me at Developer Tea at gmail.com. Let's jump into this question from David. David says, hi, Jonathan. I'm in my final year of a degree in software engineering. And over the years, I've developed my skills in front and dev and UI design, which are not taught beyond an introductory level in classes at my university. That seems to be a common pattern. Whenever I show off my personal projects that people, including both students and professors, ask the question, what tools did you use to make that? I feel like it is a weird question. For example, would you ask a builder what tools they used to build a house or an artist, what brushes they used for painting? Sometimes I just answer the question with sketch or react and leave it at that. Other times, I launch into an explanation that the tools don't matter. That I could use PowerPoint to design the same thing or pure JavaScript to build it. So my question, have you been asked similar questions in your career? And how do you explain that it is skill and practice not tools that make a good product? Thanks, David. David, this is a very hot topic in software development. In fact, it will always be a hot topic in software development, as long as the pace of new tools coming into this industry, as long as that pace continues. The reason for this is because it's so easy to create a new tool and share it with the world. If we created a physical tool, it's much harder to gain any kind of adoption or gain any kind of exposure of that tool. But because these tools are digital, they're immediately available on the internet. And millions of people around the world can download and use the tool you created. And in fact, that happens on a regular basis. People create new tools every single day that are used by other people. So of course, as a result of this, tooling is a huge part of our industry. And tools are something we as developers, we love and we love to hate. And I want to be extremely clear about a few things on this podcast. I do believe that the right tools are important. I'm not shy about this. Picking a good tool, there's nothing wrong with saying that that is important. And I think, David, that you would agree with this at a basic level. Because secondly, I believe that a lot of the time for a given task or for a given project, there are multiple tools that can do the job. There are multiple tools that could be considered right. Here's what I want to do with this question. First, I want to put myself in the seat of the person asking the question. Right? To me, as a general rule, David, it sounds like you have more experience than the people who are asking this question, except maybe the professors, but even for the professors, it seems like you have more experience doing front-end dev and UI development and design than those professors may have. And this isn't unheard of. Many programs, including the program that I went through at Georgia Tech, they don't focus, hyper focus on any one tool set, or they may focus on a different tool set than you have experience with. They aren't going to cover the entire gamut of tool sets. And so you may be more experienced than some of your professors at specific skills, especially in something like a master's degree, where you've had time to practice some of these things. And David, I think what you're saying here is that sometimes it feels like when they talk to you about the work you've done, that they're reducing the work that you've done to the tool that you used rather than the idea, the underlying idea of the project you created. So let's shift the perspective a little bit and try to think about things from the position of the people asking this question. And before we go any further, I want to explain why talking about this question is important in the first place. Aside from the fact that a listener sent this in, and I value the questions that I get from all of you, aside from that fact, it's also true that as you go through your careers, you will likely have a chance to present and debrief the work that you've done. Right? This isn't just in the academic sphere. This is going to be throughout your career. You're going to have a chance to do this. Whether this comes in the form of a client or a boss appear or someone you're mentoring or leading debriefing your work is very likely a part of your career. It's a part of your future. So the way you talk about your work and the questions, the person you are talking to asks of you about your work are important to understand. And more specifically, it's important to think about why they're asking those questions in order to answer them correctly. We're going to talk about David's specific case right after a quick sponsor break. Today's episode is sponsored by Linode. No matter what tools you use as a developer, pretty much across the board, everyone that's listening to this podcast is very likely to experience the need for a server and more specifically, the need for a Linux server. If you haven't experienced that need yet, you almost certainly will in your career at some point and probably more likely sooner rather than later. Linode provides these Linux servers. They have eight data centers in their plan store at $5 a month. I can't imagine a better way of spending $5 a month, by the way. $5 a month, they have the best gigabytes of RAM per dollar in the industry. It's somewhere around double of what everyone else in the industry is offering pretty much. So go and check out Linode. They have native SSD storage. They have a 40 gigabit internal network. They have a seven-day money back guarantee and they're going to give you $20 just for being a listener of Developer Tea. So if you do the math on that, you get $20 for free and then it's $5 a month after that. So let's say you get four months for free and really you're only paying for eight months times $5. That's $40 for an entire year of Linux server that has a gigabyte of RAM. That is incredibly cheap. Once again, I can't imagine a better way of spending that kind of money. So go and check out what Linode has to offer to you as a developer. Obviously, we can't cover all of the amazing features that Linode has. Go and check it out. It's spec.fm slash Linode. Use the promo code Developer Tea 2017. That's Developer Tea2017. When you check out for that $20 with a credit, thank you again to Linode for sponsoring today's episode of Developer Tea. So we're talking about this question about tooling that David sent in. This question that basically says, you know, what tools are you using when David is showing these projects off? And he's a little bit ahead of the program that he's in at school in terms of his capabilities and his experience with front-end dev in that moment where he's showing these projects off. The response isn't to look at the project and focus on that. Instead, it's to think about the tooling. What tools did you use? So what I really want to do here is break down what's going on in the mind of the people asking this question and really actually ask, what are they really asking? This is an important thing to understand. When somebody asks you a question, most of the time they're asking a question that isn't really articulating their intent. Let me explain what I mean. When you and a coworker are talking about going to lunch and you ask them where do they want to go to lunch, most likely your driving purpose isn't to understand, you know, what their culinary preferences are. Your driving purpose is for you to decide on a place to go together. Where do you want to go to lunch actually translates to, I'm hungry. Let's pick a place to go to lunch. So let's think about questions that are being asked in these scenarios in the same way. What are they really asking? Oh, and someone who has a less experience than you asks, what tools you use to build something? It's likely that they are in the stage of picking their tools, either for a project that they're currently working on or maybe they're picking the tools that they want to use on multiple projects in the future. They're trying to build their toolbox. And they see that you have succeeded. They see that you have found and used a tool and you come out on the other side with something that looks like success. And they want to know what pathway you took to succeed. This is really what they're asking when they say, what tool did you use? What they're asking is, can you tell me how you succeeded so that I can also learn from your success and perhaps emulate you? It's also quite possible that they're seeing a particular aspect of the work you did, right? Something in the interface you built, some particular element. And they're trying to imagine how they would accomplish it with their current tool set and they're hitting a roadblock in their mind. This is especially likely for UI-driven things. Things that people can actually see the difference in. Finally, it is also possible that the people who are asking this question are simply enjoying the wide gamut of tooling available and aren't necessarily misinformed about the importance or lack of importance of tooling, but instead they're kind of talking shop for lack of a better term. So then the next question is, why do tools matter at all anyway? Why are we even talking about this? And not all tools are equal. This is part of the reason why it's so important. Not all tools are equal and not all tools produce equal outputs. For someone new to programming, for example, it wouldn't really be fair to expect them to create some complex graphical user interface using low-level assembly code. So it is important to notice the reality that some tools do indeed provide new and potentially even exponential leaps and capability and productivity. On the other hand, tools are also an important mechanism to shift our paradigm. For example, if you've ever experienced the differences of coding in a strong typed language versus a loosely typed language or perhaps even a functional language, there are new perspectives you gain moving between those tool sets. And it is very possible that by simply working with a given tool set, working within a given language or within a given framework, that you learn something brand new. That your brain changes the way it thinks about things in other languages. So tools do matter. They matter in the way that they shape the way we think about work. They matter in the way that they enable us to do work. But David, to your point, they are not the only thing that matters. And in fact, very often, two or three or 300 tools can be functionally and even from a paradigm perspective, equivalent. And the real differences between them are somewhat superficial. So as you can see, this is a complex topic. How should you respond? David, how? What is the best way to respond to these kinds of questions? Well, first, this is going to depend on your own value set. But for me, I want to make it a value to encourage younger developers or encourage less experienced developers, regardless of their age or regardless of their experience levels and other things like your professors, David, and help them on their journey. David, you have valuable experience that you can share with these students and with these professors about this tooling and how different tools can be used to accomplish the same task. I would consider using the popular improv technique, the yes and technique of both answering their question and also in addition, discussing how even though you used Sketch or even though you used React, there are other similar tools that could do the same thing and provide the names of some of those tools, maybe provide some discussion around the differences between what you used and something else. Instead of shutting down conversation or instead of compromising the importance of the conversation, you're opening it up. You're providing a valuable perspective, both on the tool that you used as well as the place that tools have in this kind of work. Most likely, the motivation of the students and of these professors is to get an insider's opinion, someone who is experienced. How can I build something like what you have built? How can I emulate your success? The industry has a very loud voice when it comes to tooling and there's a new tool every day, in fact, multiple new tools every day. So for many young developers, this feels less like a bunch of similar tools with slightly different opinions and more like a treasure hunt for exactly the right tool. As a more experienced developer, David, you have a chance to encourage them on their hunt and also encourage them to adopt the peaceful and focused mindset that allows the tool set to become only one piece of a much bigger puzzle in the given project. David, thank you again so much for sending in your question. If you're listening to this episode and you have a similar question or you have a follow question or something totally different, I'd love to hear from you. You can send me an email at Developer Tea at gmail.com. Thank you again to Linode for sponsoring today's episode of Developer Tea head over to spec.fm slash Linode use the code Developer Tea2017 and check out to get $20 worth of credit. Take five seconds and click subscribe and whatever podcasting app you are using. That'll make sure that you don't miss out on future episodes have developed for T. Thank you again and until next time, enjoy your tea.