Coding Blocks - How to be an Advanced Programmer

Episode Date: March 20, 2016

Are you an Advanced Programmer? We dig into the final section of Robert Read’s fantastic writing: How to be a programmer. Also, how to cheat at Jira, a lazy butcher and if learning web development is worth it. Link to Episode 40’s Full Show Notes http://www.codingblocks.net/episode40 This Episode’s Survey To squash, or not to squash, […]

you're listening to coding blocks episode 40 subscribe to us and leave us a review on itunes stitcher and more using your favorite podcast app visit us at codingbox.net where you can find show notes examples discussion and more send your feedback questions and rants to comments at codingblocks.net follow us on twitter at coding blocks or head to www.codingblocks.net and find all our social links there at the top of the page. With that, I'm Alan Underwood. I'm Joe Zach. And I'm Michael Outlaw. This episode is sponsored by Infragistics.

Visualizing the Internet of Things and making sense of big data. The Internet of Things, mobility, and connected systems are driving the need for big data solutions. It is imperative to help your users and customers make better decisions faster than ever before. Experts in data visualization, Infragistics developer tools drive custom app development for any data visualization scenario on any platform. And ReportPlus is an enterprise-ready, self-service, bi dashboard solution that opens up your enterprise for big data for end user consumption head over to www.infragistics.com today and get your free trial okay so let's get into the podcast news here so first up i gotta say like we thought that last time the reviews were awesome and they doubled down this time it was just as awesome so i do you want me to try to read these again do you think it's comical enough if i do it

i think people don't i haven't even talked to it this episode it's my turn oh look at this joe stepping up stepping up really i just wanted to say bebop 6585 because it's awesome also phil britain barry carey gnu henson tells tells ny tells me eskimo dragon 13 jordan g lee archimedes j psycho vodkadam redwin lowell moore j ridell greg pakes sorry i had to take a breath there because there's so many names thank Thank you so much. And now it's just for iTunes. We also had a few on Stitcher. FPW23, CDEguia, CyberPod, ManReek, and FoopFiffer.

Foop Fiffer? These are awesome names. I think it's Foop Fiffer. Like you did a much better job of pronouncing. That's why I thought it would be comical if I had to pronounce some of these again. Although I got to say, when it comes to any type of Dom manipulation, Vodka Dom is definitely my favorite kind of Dom that if I have to manipulate a Dom, that's the one I want to go with.

True that. I also like Gnu Henson. That's good. I should get a high five for figuring out Archimedes on the fly there. Oh, yeah. Man, there were excellent, excellent written reviews in those two. So thank you guys for taking the time and doing that we really do appreciate it we say it every single time and

we'll continue to say we mean it every time we really do so thank you very much for doing that and for all of you who haven't done it yet come join us over on slack man the conversations are just getting better and better they're oh man there's been some great like the dev talk channel yes definitely one of my favorite channels yeah that one's excellent we got a nice gear channel where everybody talks about things that they're either programming for thinking about getting to program for there's some good stuff and if you want some comic relief you can just read james constantly on the flow so yeah yeah yeah, I mean, there's seriously a ton of value happening over there. And, you know, please do send us

an invite on, or no, you can send us an invite, but I don't know what to. If you'll send us your email address, we'll send you an invite into the Slack channel. So you can send us an email at comments at codingblocks.net or if you prefer to send us a DM via so so you can send us an email at comments at coding blocks.net or if you prefer

to send us a dm via twitter you can send it that way just as long as you send us your email address and then we can send you the invite via slack and then you can join the fun yep it's been it's really been excellent so uh and don't forget the jobs channel oh man then uh posting some job leads and i know there's a lot of people from all over the world in here but i kind of like the idea that um of promoting at least remote jobs in there nothing else you know and uh it's kind of cool yep and i anybody's free to post in there i've posted several that i get hit up on linkedin or whatever so you know if you have something or you know of a position that

needs to be filled, please do feel free to go in there. We don't want to turn into some sort of, you know, spammy type thing, but you know, real things go ahead and throw in there. But next up, we got an email from Magnus and this was an interesting email that we just received the other day. And I thought it was worth talking about briefly here in the in the news section basically he does a lot of c++ and game development type stuff and he said when he went looking for a job like basically every job out there is requiring some sort of web programming like javascript or or something like that and he's like do I really need to learn this stuff I mean he said he's not into it.

And then he also did a follow-up email after I replied. And he said, you know, the problem is he lives in a country where, like, basically to get a job programming, you have to have a master's degree. Like, a bachelor's isn't even enough. And he asked, you know, is it the same over there in the States? So there's several questions rolled up there. And I think that would be a great talking point. And, you know, seeing as how we do seem to have people all over the world listening, I mean, you know, let's see what we can do here. I wanted to point out that the Stack Overflow survey just came out and it had actually a pretty big section on types of jobs. And like you mentioned, Alan, web developer was at the tippy top by far. So it's not a bad area to have some skills in, even if you don't love it.

You know, there's a lot of stuff that goes into making a website besides just the HTML and CSS. You know, there's a lot of scalability issues and just the whole pipeline and everything. And there's a lot of cool, interesting challenges there, even if you don't necessarily like the medium itself yeah i mean i was going to say that you know the sad fact is if you're looking for a programming job then by far and away the majority of the jobs you're going to find are going to be for websites you know web development next after that you're going to probably have find the next i would guess that the next biggest or percentage of jobs that you're going to find that aren't web programming are going to be either Android or iOS. So if you like one of those two things, that's a hot market.

So it's definitely not a bad place to be. If you want to do specifically game development, that's a small market. And you're really tied into a few dev shops that make enough money to be able to support that kind of thing. And I'm also assuming that by game development, we're talking about desktop game development. He didn't go into it. Not iOS or Android-type game development. Right. And then the list starts to get smaller you know if you're talking about like um operating systems so like if you wanted to work at microsoft working on windows like you know it's just smaller and smaller

pieces of the overall pie that you that you start cutting at so yeah unfortunately i would say you need to you need to pick up some of that i mean i don't know like i when I wrote them back, my take was if, if web development isn't your thing, then, and just to be clear, like when we say websites, people have this idea that it's just HTML, CSS, whatever. Okay. If it's just a website, maybe, but typically when you get a programming job, it's web applications, right? It's usually something that has some sort of backend that you're supporting some database, all that kind of thing. So there's a lot of moving pieces to it. But I will say, like, if your heart is truly in game development, then I don't know that I would tell somebody to go learn JavaScript

or anything just to be able to get a job, right? It's such a tough sell. Yeah, but here's the reason why I'm thinking this, though, is that, like, let's say in a, in a hypothetical, you know, best of world situation, you get that dream job,

right. And you know, let's say it was never soft as just an example company, right. Right. So you get a job at never soft, uh, you know,

doing game development for them. And then I don't know, let's just say that something bad happened, never soft. And they go through a round of layoffs. And unfortunately, your name got in that pile, right? You got to go start looking for the next job, right? You're going to start putting your name out there as having no web development at all.

No experience, no skills in it, right? That's why I'm saying, like, you need to pay attention to it. It's kind of a big thing right it's so hard i mean it's almost i guess for me because i actually enjoy a lot of the aspects of web application work it's not a big deal but but there are definitely things that people throw out that they're like hey why don't you learn x y and z and i'm like yeah i don't really yeah i don't want to right and i guess because i work in an area where there is a ton of demand it it works out for me so i don't know how it how i would be if i was truly in love with

game development doing c and plus plus and saying yeah I don't really want to do JavaScript, right? I mean, Joe, what about you? What are your thoughts? I'm still stuck looking at Neversoft video games. Tony Hawk, Pro Skater 2. I got a little derailed. But no, I mean, I agree with what you're saying. You know, I, in particular, don't love HTML and CSS. And a lot of things are going wrong with being a web developer,

but I've also been a web developer for a long time. And there's a lot of different areas to to work in and so it kind of depends on what type of things you don't like about working on the web and maybe seeing if there are some newer technologies or maybe different ways of working that kind of augment the things that you do like that's interesting right yeah you could work on the business end of web applications and then that way you're doing things that are more closely related or even like big data type stuff right like there's a lot of problems to be solved there well are we talking about like server side yeah like server side type stuff right because if you're doing batch processing kind of like like those type of jobs

yeah i mean i don't know what would actually like satisfy his appetite right like There's a certain type of programming that each person kind of... Well, I mean, I think he specifically said game development. It is, but what part of it? Yeah, is it just the graphical piece? C++, OpenGL, Assembly, Java, and libraries to make games. So, I mean, he's clearly into the game development world. Yeah, I mean, and you can do that on the web too, right? Oh, and actually, let me correct that because he says because it's not he says c

c plus c plus plus well it was both right because and because then the next question that i was about to ask myself but then i rechecked his notes was that most games are in c right but i don't know like if i was going to do a game, I'd just do Unity, but that's because I'm lazy. So yeah, I don't know. That's a tough one. And then on the education question, right? So I think here in the States, it might be slightly different. I mean, going back to that survey that Joe brought up a minute ago, like I think more than half the people were self-educated. They were self-taught developers. Oh, it was way more than half it was high 80 it was high yeah but it's 70 but um there's overlap so you couldn't have identified as self-taught and had a bachelor okay fair enough but so i think the better number to look at there is um who has a

bachelor of science in computer science it was 34 and there's ba you know computer science or related field was another eight percent so basically, 40, depending on how, yeah, so you're looking around 40, depending on how people kind of did it. And that's just for the bachelor's. And so master's was 20%. So, yeah, so I mean, that's kind of interesting. I mean, a lot of the people, for instance, like Joe, you didn't end up finishing your bachelor's, right?

Right, correct. And I finished mine, but well after I'd been programming for years like it was basically for me it was nothing more than to check that box so that if my name ever did end up in a resume pile somewhere mine wasn't just going to get discarded because I didn't have that piece of paper so literally I had already been programming for a long time before I did this so it may be region specific, like here in the States, I definitely feel like if you're one of those people that shows a high aptitude for it, you don't necessarily need a degree. Now, it might make it a little bit tougher for you to even get

your foot in the door, because they're going to be looking at a bunch, you know, they got 100 people over here with degrees, and then the stack over here with people that don't and for employment a lot of places will have that requirement that you know you have a bachelor's or equivalent and so sometimes you kind of get discarded before yet it ever happens i really feel like those degrees are like in your first few years of you know whatever your career is totally right once you get you know past year five then i don't know that it matters as much. Yeah, it's usually at that point references, accomplishments, networking.

It's what you're currently doing. The things that you learned five years ago, you might have covered technologies that we don't really care about today so much. Hopefully, you got good, strong foundational patterns and things like that. Also curious too, we don't really care about today so much. I mean, hopefully you got good, strong foundational patterns and things like that. But yeah. Also curious to bootcamps show up as like 6.5%. I wonder whether it's going to be like,

say five years from now, you know, there definitely seem to be a lot of those spring up and I hear good things about the graduates. So, well, it makes sense too, right?

Cause a lot of those bootcamps, they are not cheap and a lot of them guarantee placement for people afterwards right like if you if you were one of those people that did something they'll be like hey we're going to hook you up with a job now i don't know what kind of level it's at like i doubt you're going to be jumping into a super duper high paying job when if this is your first go around but you know that's that's a good point too. Well, for all the self-taught developers out there, I've got a tip for you then during the tips section of the show. So, you know, I just think it's interesting to think that a company might think that someone who's spent, say, six weeks, you know, working exclusively on Ruby on Rails

is, you know, more or as valuable as a college graduate to, you know, at least to them for that, for what they need. So yeah, I'll be interested to see how that continues to evolve. Yeah. I mean, we've all been involved with interviewing people and I will say like a lot of times people coming out of college, like you, you have them sit down and try and do, you know, a problem on the board, you know, Hey, show me try and do you know a problem on the board you know hey show me uh you know how you would model this particular problem right and they'll struggle through it but then somebody that sat through a boot camp for you know we'll call it six weeks where they are literally just hardcore programming and trying to create something it's a little bit

different than taking a test here and there so there's definitely some value and they pick up some valuable skills as well. So yeah. So with that, um, you know, like we said, uh, I think Joe tweeted out the stack overflow, uh, developer survey was out kind of a little bit early on that one. Didn't you, Joe? I sure did. They yanked it back. So I got to retracted it and then put it back up.

So that just means you get to tweet it twice. Right. I'm going to tweet it again right now. Yeah. Three times. Thrice. Thrice. Oh, and then one other thing that came up on our Slack channel that I thought was interesting,

and a lot of people will say things like this and it and this is just my take and this is the reason i wanted to bring it up if somebody says if we had had unit tests we would have caught that problem that problem has to be a problem with the code right a unit test is made to test that the code that was written does what you think that code should do however writing a unit test to cover a business case that wasn't implemented the right way is not valuable so but you can have unit tests for your business rules too you can but that's what i'm saying like when you hear somebody say um so basically somebody implements something wrong a unit test is not going to catch that well no in that case the unit test is just going to prove

that it's that it's working it's working you designed it correctly right and that's that's my whole point like you can't just say things in a vacuum right like when you but that sounds like a problem of like you're describing not having valuable unit tests then. No. You don't have a business processes review properly, right? And we've talked about this before with having tools that allow users to be able to verify a unit test. SpecFlow we've talked about. I think Cucumber was the JavaScript version of it.

But that's kind of my point is just saying if you are a development manager or something oh if we had unit test it would caught that no no no if you implement the business rule that was made and you have unit test to cover your code and all those things are online then yeah you'll catch these problems for they go out right possibly yes possibly that's Yes, possibly. That's best case scenario. But it's just, I don't know. That was one thing I wanted to bring up because I hear a lot of times people just throw out buzzwords like, if you do this, you wouldn't have this problem. And I'm like, no, that's not necessarily true.

The developers have to understand the business problem first so that they can actually design it properly. And that's where we talked about this before with test-driven development. Well, I was about to bring that up. If you start first so that you truly understand the business problem before you even start writing the code, right? Like you write your unit tests cases first so that as you implement your code, it adheres to that. That makes a lot of sense. But I just wanted to throw that out there. Like, don't just make statements, you know, kind of broad sweeping statements that are true. Only if you meet these certain criteria, you know, we got to own it, right? Like, I make so many mistakes all the time. And I'm sure I don't all of them because I would never get any work done. But when you do make a

mistake, and trust me, if you're programming professionally, you're going to make so many millions of mistakes a day that you just got to get used to just kind of taking it and knowing it and fixing it. You're not blaming it on unit tests. That's the bigger thing. And we've talked about owning things before. I think most recently during the conversation

about the 12-factor app. Yeah, it was in there. So, anyway. All right. What's our next? All right. Well, we're going to be continuing on. This is the final part of our How to Be a Programmer series.

This is How to Be an Advanced Programmer. As we continue on with Robert L. Reed's book, and we will have links to the latest version of his book that you can check that out, or essay, I guess is what he called it. Yep. Although, I wanted to point out, too, so this book divided into beginner, intermediate, and advanced. Tonight we're doing advanced. In Slack, we had quite a bit of conversation around at one point does a developer

go from like a junior to senior and so if i were to kind of try and take those type of that type of terminology and apply it to this book would you guys say like junior is beginner senior is intermediate and then maybe like fellow senior senior maybe architect maybe project or maybe programming lead would be the advanced that's maybe kind of i mean a lot of these topics we're going to touch on tonight seem to be a lot about developing people under you and that kind of thing uh yep so maybe but the only problem i have with that is an architect is usually still highly involved in design and may not necessarily be the develop the the person development person you know the guy that's trying to build up people under him you know a lot of times i see that more in

a managerial type role so it's hard to say but i do think that one of the topics that came up with that was, is it time? Is it experience to me? Like if, if I, I'd have no problem calling a 25 year old, a senior level developer, if they had truly experienced a lot, you know what I'm saying? Like they, they knew how the tiers of applications are supposed to work, the design, the architecture, how things fit together, how to make things faster, all that. Like I think senior is a level of comprehension and understanding of problems that you deal with in software development, right? So it's not necessarily, Hey, you're, you're 35 years old or 40 years old or 50 years old. That, that to me is not a senior developer and an architect could also be a young person right somebody that truly understands how all the pieces fit together like they're the ones that that that know how to make these things work so i will say i've always

personally hated the titles junior developer and senior developer only because it does immediately draw age because you think you think of like well how long have you been doing this right and that's that's a you know measure of time and it's not necessarily because you immediately think of a measure of time and not instead of a measure of skill i've never liked those titles so kind of like the amazon way where they'll have like a software development engineer one two and three that you'd prefer more like that right like you've gone up the levels as opposed to which well like okay if you were a fellow all right that's a title that uh you that's the highest title that you could have at microsoft and at ibm

um i'm not sure where else but you know that example of, like, that one doesn't bother me. I guess that one's probably not too friendly for women. I don't know if they would want to be called a fellow. Interesting. But, you know, that's the only, that title as an example, though, doesn't bother me as bad as junior and senior.

Yeah, so just food and senior. Yeah. So just food for thought. Yep. Well, let us know what you think. Yeah, definitely. Hey,

all right. Yeah. All right. So let's get into, uh, the first section, technological judgment, how to tell the hard from the impossible.

Love this part because apparently everything i do um is impossible so i it basically boils down to um the quote here is from the point of view of most working programmers something is impossible if it is either uh if either it cannot be grown from simple system or cannot be estimated so i'm either bad at estimating or i do the impossible all the time. They do go on to describe, but I just kind of plucked that out because it was funny. But the example that I really liked from this section talking about what they mean is basically if you kind of imagine that you had a system where your goal was to compute the most attractive hairstyle and color for a person, then that's an impossible problem. And your job as a programmer is to take that impossible goal and say, well, you know what?

If we did this and we did that, we could maybe solve this solution or solve this problem 75% of the way. And that's enough to make a lot of money and keep this ball rolling. And, you know... So your job is to... Sorry, go ahead. Yeah, no, you're right. That was one of the interesting things about this is impossible didn't mean that it couldn't be done.

It meant that there was no way to scope the thing, right? That's really what it all seemed to be is, okay, if you start trying to build this, you know, enormous thing, but you have no way to scope it down to where you can ever make any tangible progress, then it's impossible. Right. Well, yeah. I mean, one of the sections that I had made note of was if there's not a crisp definition of success, you will not succeed, which kind of goes in line with what Joe was saying was that

you take this vague requirement that's impossible to meet and then you start whittling away at it until you can make a clear definition of this is the goal line yep if we get here imagine like we're good sorry i'm bad about stepping today sorry guys you need a little buzzer for me but i was just thinking uh you know google's kind of primary function is to help people find things. That's an impossible problem. But searching things based on backlinks or, say, Google Maps, you know, those are partial solutions to an impossible problem. Right.

Matching on keywords. And we're pretty good at it as well. That's iterating, right? You iterate towards creating something impossible. And so that makes the other things you know doable so yeah that's pretty much it all right well let's move on to how to utilize embedded languages huh right yeah i got a little lost on this one but then i started well it wasn't so much loss it's just i've never had an experience with really embedding a language into something.

And so I kind of struggled with it initially until I thought about, you know, there have definitely been times I've exposed SQL and, you know, some sort of back admin piece or, you know, even some JavaScript functionality. But it's not really the same thing. It's funny that you said SQL because, because you know when i was thinking of a very similar type of example that but i also added into that html because there have been some you know maybe gross times or you know apis or uis where like that kind of thing has been exposed to you allow a user to add or edit or whatever. But I've never had the case where he was talking about embedding a language into a text editor, right? Right. Yeah.

I haven't had the need to do that. Same here. What this whole section struck me as is sublime with being able to do macros or something in there, like writing your own things. I don't know. Like I've never really decided to do it. And one of the important things he points out in here is it's dangerous to do it to a certain degree. Because if you try to embed a language in something, let's say that you create your own text editor, right, and you embed a language in there.

Is that something other programmers are going to want to learn? Especially if it's not something common. Well, that was why he was saying use one that already existed. And so that's one of the things is if you're trying to do it, and text editors are the things that come to mind because your Notepad++, your Sublime Text, other IDEs typically have some sort of scripting language in them that you can use to leverage things.

So that was the closest thing that I could think here. And the other thing would be like if you're actually doing truly embedded programming on a device, like IoT might become a big deal with this kind of thing here in the near future. I also thought video games, like Warcraft has, I think, Lua embedded into it. So people can make mod modifications

or mods and um they basically limit the features of the language and kind of lock it down to a like a sandbox environment but people like game developers you know who work for blizzard can do things with this environment for their ui but also they you know allow the people to use a portion of that language to make their own stuff well i mean even if it wasn't like a like a full-on language let's just say it was just more of like a um i think you made a reference to like a scripting type language like let's just say if it was something of a markup style right you know have you ever had a situation where, like, you've created your own quote markup for some simple field, you know, and to tell the user, like, hey, you know, maybe you don't want to give them access to raw HTML or something like that, right? And so you give them something of a templating type of markup that they could use, right? Yeah.

But then that's something else that they have to learn. And he makes this great point of saying, like, hey, it's a joy to create they could use, right? Yeah. But then that's something else that they have to learn. And he makes this great point of saying, hey, it's a joy to create a new language, right? But we should not let that blind us to the needs of the user, right? So you might think that creating that new templating engine in this case, I hate to call it that, but-

Pretty close, yeah. Whatever that scripting templating style language is, like you're having fun and you think that you might be helping people, but... Pretty close, yeah. Whatever that scripting, templating style language is, like, you're having fun and you think that you might be helping people, but really, are you? Because now you're giving them something else to learn. Now, in that statement that I just said, how many JavaScript frameworks did I just insult because they created a new

templating framework? Handlebars. Mustache. It goes on. Okay. Yeah. But people mustache yeah right it goes on okay yeah uh yeah that but people like learning new javascript frameworks every day all right so all right so the next one is choosing languages right yeah i thought this was interesting too i i do feel like this kind of um almost should be choosing languages and frameworks now.

And if I were a better person, I might consider doing a pull request. Because choosing languages, like a lot of times for a lot of companies, there's not a whole lot of choice. You've either kind of bought into one ecosystem or another. And so your language choices are usually pretty limited. And a lot of it depends on things like cost higher ability stability the platform um you know the future how's it you know all sorts of stuff licensing so choosing an actual language doesn't really seem that important to me but whether i'm going to go with say ember or angular now that's a decision that i'm much more likely to make in

the next couple months or you know whatever well you say Angular. I'm sorry, Alan. No, go ahead. But there was one quote in here that I know is going to drive it home for Alan here. Often managers are driven by the need to be able to hire programmers with experience in a given language. And Angular was the one thing that came to mind right away. Yeah, and here's the truth of it right like you can try and do that but it i mean inevitably you may or may not it's hit or miss right like hiring for a particular language you don't know the skill set of that person until they get in there

and that's the god's honest truth for any of it so but i did before before we go too far like he was kind of brutal on this one like one of the things i highlighted was generally this issue is dictated by pointy haired bosses who are making a political decision rather than a technological decision and like the courage to promote an unconventional tool even when they know often with firsthand knowledge that the less accepted tool is best now i do want to say to be fair a lot of times these pointy haired bosses don't really have a choice now wait a minute we we gotta believe that he's talking about dilbert here he is absolutely right but but that's kind of what i'm saying though like i mean to what joe's point was a minute ago if you are a microsoft shop are you just gonna go do java like are you going to invest in a whole new set of tools

when you're on the entire windows platform but the crazy thing is though is it happens it does i mean sometimes sometimes they'll just be like a regime change and the new manager will come in and he's like, you know what? I want to change this. This is the platform that I like. I've used this elsewhere and I don't care what we're doing here. We're changing everything to move to this platform. So it does happen.

It does. And I don't necessarily agree with it. Yeah. I mean, because sometimes I think that the reasoning isn't necessarily coming from the right place. Yeah. Yeah, I could see Pointy Hair Boss,

a programmer comes in and says, hey, we need to do this in, say, Lisp or what's something cool or Cylon or Rust or something. And the Pointy Hair Boss

is thinking, you know what? There's a good chance you're quitting in the next year and a half and I'm going to have to find someone else to take this on and no,

but I will say this though. And he brings up a good, a very, very good point down here. And this kind of goes back to our junior versus senior level developer type thing. He says to beginners and to some outsiders, learning a new language seems a daunting task,

but after you have three under your belt, it's really just a question of becoming familiar with the available libraries and let's be honest that's pretty accurate right it is unless you go to different types of languages so if you're doing a functional versus an an oo or a scripting then then there are nuances there but otherwise jumping, jumping from C Sharp to Java is not that difficult. I mean, I questioned where the three came from. Okay, three is trivial. Even one.

Because, yeah, if you know one extremely well inside and out, then going from C Sharp to Java, you're not going to struggle too much on that. No. If anything, it's the you're not going to struggle too much on that that no if anything it's the frameworks like what joe said like this should almost be titled choose choosing a language or a framework right like if you jump from i don't know spring into something else it's a totally different ball game he did make the comment though um about learning a language is not learning a programming language isn't too far from learning, you know, or any more

difficult than learning a natural language, a foreign language. And I remember being in school and I always questioned like, hey, if I'm in this programming class, why am I not getting foreign language credit? Because I can speak this, can you? Right? Like, what's the difference? Right? There's another thing that he said here that I thought was pretty spot on is he said,

One tends to think of a large system that has components in three or four languages as being a messy hodgepodge. But I argue that such a system is in many cases stronger than a one-language system in several ways. And he goes on to list some bullet points. There is necessarily loose coupling. It has to be. Right? You don't have an option um you can evolve to a new language or platform easily by rewriting each component individually it is possible that some of these modules are actually up to date so those are pretty interesting things and that also goes back to using languages for what they're strong for.

Using the best tool for the job. Yes. I mean, some are very good at parallel programming, threading, and that kind of stuff, right? Others are better for, I don't know, scripting out cron jobs or whatever the case may be. I mean, Perl got its name just for string manipulation. Right. Or where it's made its name. There's nothing wrong with using the right tool for the job.

And one of the things that is very important about this is you can also keep your programmers happy if you allow them to explore these things, right? And keeping morale high among programmers, and I think we talked about this in the previous podcast, is a big deal, right? Like, happy people produce better work. That's all there is to it. There was one point, though, in this section that I really didn't agree with, and this kind of goes back to the previous section.

But he says that, you know, when you're trying to choose a language, if it can be embedded, you should always consider it. And, you know, going back to the point that you know when you're trying to choose a language if it can be embedded you should always consider it and you know going back to the point that you just made like why if it's not you pick the best tool for the job and that best tool for the job might not necessarily be uh you know something that could be embedded right and and really how often do you need to embed something and and if we're thinking about you know if, if we're putting our OWASP security hats on, do you want it to be embeddable, right? Right.

Think about that. Look at Java applets now. All right. Let's move on. The compromising wisely here. So how to fight schedule pressure. Yes. And so I actually had my own little list of things here. So how to fight schedule pressure. Yes. And so I actually had my own little list of things here. Um, but I first wanted to mention that with the one, uh, the one thing, my, the thing I got out of this, the most, I guess the section. So what will you give up to get the thing that you

want? Which is, I feel like the best response you can give to someone whenever, you know, scope creams, scope creep comes up like, all right all right um what am i deprioritizing in order to get this done yeah i mean the the part that i thought was so key and a lot of people don't realize is when when business owners or managers or whatever are trying to put this pressure on you they believe that asking for it sooner will make us work harder to get it there sooner. And this is probably true, but the effect is very small and the damage is very great.

You create burnout when you do this, right? Like when you apply that pressure, somebody is going to work themselves to the bone. The quality of work might even go down because they can't focus as well and after they're done with that and then you hit them with the next one and they try to apply schedule pressure again motivation starts dropping off a cliff yeah well i was going to actually address that because he he mentions you know there's there's time to market pressure which is good pressure right that's the pressure to deliver something quickly because there's a financial realization there, right?

But there's the schedule pressure to deliver something, and that's bad because that's just arbitrarily you've decided, hey, we need to get this done in the next three weeks. There was another statement he put in here that I actually really liked. You can't pack more into a span of time any more than you can pack more water into a container over and above the container's volume. Right? You can't do more than time will allow you to. In a sense, a programmer should never say no, but rather say, what will you give up to get that thing you want? Which is exactly what Joe said.

What is it? There's time, resources, and there's cost. Cost, yeah, so money. There's that three-pronged pyramid. And as you drag one point out, the other two become longer. As you stretch these things, one gets really short and the other two get really long. So which two are you willing to give on right you know and he called he calls labor an almost incompressible fluid yep so so you can't you can't you can't squeeze any more out of that because at some point you know your

developers are just going to lose uh you know the morale like you said the morale is going to go down they're going to get tired as they get tired. They're going to make mistakes. Yeah. And that cost may not necessarily be financial. There's also, you know, mental, mental and physical costs to working a lot of hours. Yeah. I mean, if you burn out your team, then your team isn't going to want to hang around. Right.

Yep. And they even say asking somebody to do something that basically is impossible is demoralizing. It's just like if you're standing at the base of that hill and you look up and there's no end in sight. You don't even want to start climbing it, right? I'm not going to make it and someone's going to be yelling at me the whole time. That's kind of the way I feel every time I'm at the bottom of the hill on a bike. And I'm like, oh my God, I got to climb that. That's why I don't get on bikes. That's impossible. the way I feel every time I'm at the bottom of the hill on a bike. And I'm like, oh, my God, I've got to climb that. That's why I don't get on bikes.

That's impossible. Nobody can ride that. And then someone goes past me, and I'm like, dang it. All right, fine. Let's go. All right. All right. Let's move on to how to understand the user.

Love it. Do you really? I really like this section. Yep. There has been so many times when I thought I understood what needed to happen. And, or, you know, I talked with the person, you know, paying the bill for the project and they thought they knew what needed to happen. And you get to actually meet and see how people who really use your software interact with it. And you're like, oh my gosh, this is terrible.

Like I can make this so much easier with just a few little tweaks that your life could be so much better. Right. Yeah. I mean, you, he, he makes a point here saying that like, it's your duty to understand the user and to help your boss understand the user. And the more time you spend with users, the better you will be able to understand what it will be to really be successful for them. Absolutely. If you watch them work, like I've've i've found it immensely useful to where if you are doing something for a particular department or a set of users just go sit down and watch over their shoulder and see what they're trying to like the biggest problem and he even touches on it here is he's like they usually think of small improvements that they can make right because

they're used to doing a job a certain way and And that's what they think like it's, it's your job as an advanced developer to know the end game, right? You're trying to get from point A to point Z. They think about all their little steps that they do. And so they kind of miss out on the big picture. And it's, it's basically your job to say, oh, I see what you're trying to do. And I know a way to make this immensely better as opposed to creating all these little micro enhancements. Right? Right. Also, a side effect is as you get to know the user better, they get to know you better.

And so they may be more sympathetic or they may, you know, listen to the things that you tell them a little bit more intently rather than distrusting. It's just basically building a good relationship. You know, if you say, I can do that, but I don't think you're going to like it and you just have to trust me, then, you know, they might be more prone to do that if you've built that relationship up and there's trust there. Yeah, I mean, he makes the point of just saying, you know, just to hang out with them. You know, just getting to know them better. Go to lunch it doesn't have to necessarily be like what what you were describing alan about you know watching them but you know just as long as you get to know them because then kind of to joe's point you know they'll be more willing to share as well absolutely oh before we move on to the next

section i want to bring up a topic that our friend john we we had a discussion at lunch one day and in the i don't know if it was in the previous one in our in our intermediate or if it was in the beginning we talked about scope creep and he made a very good point and it's funny because as developers it can be really frustrating for scope creep right but he made a great point scope creep is the business owner or the end users way of trying to integrate or uh iterate on the problem right like we talk about as software developers like you can't just try and start off with this huge idea you have to have this mvp or you have to iterate towards something, right? That is the business owner's way of doing that. And that's why scope creep happens. So it was a very important point to bring up that, you know, there's two sides to any kind of software development, right?

There's the user who needs something, and then there's the developer who's trying to create something. And so scope creep can be frustrating, but you just need to figure out a way to implement it. And that's where like Agile and those types of things have come into play, right? Because you have these shorter sprints to where, hey, a user says, I do need that. Okay, well, let's try and work it into this sprint or get it into the next sprint.

And so that's kind of the valuable part of that. But I did want to bring it up because I thought it was a great point that he made in that if you cut out scope creep, you've kind of cut the legs off the user who's actually looking to get this delivered product. Yeah. I mean,

I, I like that explanation a lot, but the frustration of it is, is that while, you know, you might be all on board for doing that, but then the reality is like, well,

we're trying to get this feature out today can we push that feature out tomorrow right because if i gotta try to fit that into today's schedule like i'm not going to be able to get today's feature out either so i'm going to fail on both so can i have like micro successes and get one and that's where it gets to be frustrating and totally and that's a good point and And that's where the old waterfall approach was really bad, right? Because you'd spend a year speccing out this program, and then you lock that document, right? And then it's like, okay, you're going to develop it to this. Well, business needs change over time.

And so that becomes a problem. And that's why I think something like Agile is a lot better. Maybe it's not perfect. So if you had a time machine, okay? You're Marty McFly. Yes, I am. You jump in your DeLorean and you hit 88 miles per hour. Yes.

20 point, 21 point one gigawatts. And someone's trying to tell you about Waterfall. Let's say it was 20 years ago. Man. You could be the guy that invents Agile could you could be that guy i don't know if i'll be that guy oh okay well and this is why we still have waterfall in our history thanks thanks man i mean what are your thoughts we can't have nice things like time travel what are your thoughts nothing ever goes away right like waterfall is never going away agile is never going away whatever comes next is never going away like it's it's just piling on man it's a big old mess of spaghetti it'll be and that's why uh programmers get paid it'll be an agile waterfall all right agile fall agile

fail we've just created the next one all right let's move on yep to how to get a promotion uh yes please join our slack uh this this topic actually comes up quite a bit and it kind of ties back to the whole junior senior developer when is it time um you know do you need to change jobs to get a promotion do you need to you know be doing the job before you get the promotion do you just need to talk to your boss like does there need to be a formal you know process with well- with well-defined rules for getting that role? Depends on where you're at. Yeah. I mean, I think we kind of hit on this recently, too.

I don't remember. I think it was the last episode, I believe. Was it? I think so. But yeah, we did recently. Yeah, because I the the conversation was something along the lines of like the fake it till you make it right yeah you start doing the job of what you want to be but there was another part so yeah we did talk about that and i think that's a good

piece of advice but there was another piece of advice in here that's golden that i think way too many people ignore ask your boss what you need to do to get that promotion right like a lot of times in your mind you think that you just need to be you know doing awesome software right and in some places maybe that'll get you the next promotion but maybe your boss is looking for you to be a leader and to start organizing things or whatever. It's hard to know. Ask your boss. He can tell you what's in his mind.

Now, the uncomfortable truth may be that, hey, I don't think you're ready for it. Yeah, you might not like what you hear. You may not. It may be, hey, dude, I don't like your work ethic. You're not pulling your weight. You're not doing this. Whatever. But you'll never know unless you ask yeah yeah although um another kind of point there was a podcast or a book or something i shouldn't even mention because i don't remember what it is so

anyway um nice nice job ultimately your boss just wants to look better right everyone's accountable to you know somebody um so if it's ultimately a lot of times a promotion isn't necessarily about you so much as it is what you can you know provide to your organization so if you can figure out how to you know ask your boss or talk to your boss or whoever about what they need fulfilled then that's a great way, you know, as Alan say of, of getting that promotion or getting where you want. Well, also kind of in the vein of making people happy though, if, if they can't, if there's no visibility into what you're doing, right, then, then it's easy for them to not appreciate your efforts. Right. And so he makes a point that, you know, if you work remote,

then sometimes that can be, you know sometimes that can be more difficult to accomplish, to make what you're doing more visible to your boss and to your peers, right? It really can. And I think this also might be showing a little bit of the age of the document, because at least nowadays there are a ton of tools to help with that, right? Like you can have face-to-face meetings with people that are a country away. I don't think it shows the age of the document at all. You don't think so?

No, because you could still be working remote. And if you're not, it's still, the onus is on you to call it out, to call out your successes. Okay, yeah, good point. So if all you do is just uh you know submit commit um pull requests and you submit 15 a day but you never make a point of like hey here's this new feature i added how's anyone to know yeah you gotta be a good salesman like i guess one of the big things that a lot of people don't understand about a promotion is you have to sell yourself, right? You have to be a good salesman

for yourself. And that might mean creating a presentation to show what you did or setting up a meeting to where you can say, Hey, look at this, this feature that we've got, that's going to help X, Y, and Z out, right? There's nothing wrong with doing stuff like that. And it will help you out tremendously throughout your career. Yep. And I also liked that they said to get a pay raise, negotiate armed with information, which is basically what you're talking about.

But it'd be nice if you can go into that quarterly review or whatever and say, you know what? I worked on the three biggest, bestest features that we released this year and I did a super job. So hook me up. Hey, and, and if you can put some metrics to it,

like, well, yo, what I did just increased our profitability by 10%. That's a huge thing, right? And that was a point that we addressed. I think it was in the last episode as well that, you know, because I made the point of pointing out. I made the point of pointing. And I pointed very well.

Yeah, apparently. Better than I am right now of uh you know i used the e-commerce as an example that we're like that's that's an easier situation to where you know you can you could say hey i implemented this feature and that feature after implementing that feature we saw x amount of dollars right and that's something that like when you can quantify that in a number like that, then everyone can understand it. Yeah, and it doesn't always have to be dollars.

Like it could be I took this processing time down from eight hours to five minutes. That was an increase of, you know, a gazillion percent or something. Average session time. Yeah, I mean. Bounce rates. I mean, there's a ton of different ways that you could measure that. It doesn't have to be dollars. Yeah.

And all these metrics, I think the key is, and we've discussed this on Slack as well, ironically enough, is be able to quantify things. Don't say, well, how much money did you make? A lot. Yeah. A lot to Bill Gates is how much. A lot to you is how much, right? A lot is so generic and non-informative. I guess from my own experience, though, the reason why I say that use the dollars as an example, though, is that there have been situations where, you know, maybe it was something like, hey, we implemented this feature and our average session time increased or bounce rates went down or whatever.

And the response is, okay, but so what? But if you can say, well, X amount of more dollars, like we brought in, I don't know, let's say it was $100,000 more this month because of this feature, then it's hard for them to argue and say it doesn't matter because you can say well that's a six-figure number bigger than what it was last month so it matters and if you equate that out over a year that's 1.2 million dollars right so and by the way uh for those of you who have no idea what he meant when he said bounce rate that's that's generally a website type term if you come to the site and you leave from that first page, that's a bounce. That's somebody that did not go

any further than the first page they landed on. Yeah. I don't know what to say there. How about I just automated accounting and you were able to lay off 20 people because of me. High five. And everybody hates Joe now.

Yeah, your car is keyed and your tires are flat, so you're walking home. You know, you jest about that, but I'm not kidding you. I have a buddy who got fired because he literally automated a job that like four or five people were doing in a department. He automated that job job had it done like literally their entire job done in seconds that would take them days to do and he got fired why because because that's crazy because he worked for one of the people that he just kind of

replaced with that thing that he wrote right nice and so that's kind of an important thing to know. Like you kind of need to know your target audience as well. I mean, I've definitely been in situations where, especially as a consultant and you arrive and you're tasked with doing something, right? And you start going around to some of the end users and talking to them and asking questions, kind of like what we were talking about in the previous section about getting to know the user, right?

And there's definitely this vibe from them about like, oh, crap, you're about to automate my job, aren't you? But you know what? Go ahead. Well, no. I mean, just the point being is that there's that vibe there. And sometimes it's difficult trying to just overcome that. Yes. Like, you know, and kind of reassure them without actually coming out and saying like, hey, I'm not here to get rid of your job. Right.

That's not what I do. That's what I was going to say. That's part of being this advanced programmer is it's almost your job to make them understand that, look, I'm not trying to replace you. I'm trying to enable you to be able to do more things better. I mean, it doesn't help that when I start the question with something along the lines of, so what exactly would you say you do here, Bob? I'm the bean counter. I'm a people person.

So what I'm hearing here is I should be sandbagging. So if I don't have good metrics now, then I should put out a feature, throw some sleeps in there. And then a couple of months later I take those sleeps out and I can say, Hey, I improved performance 30%. By the way,

that is the same as reporting off Jira statistics. If you get it, if you get it into a pull request and no one notices, then maybe, but I have a feeling that when you go to remove it someone's going to notice so you might want to be a little bit more clever about it than just doing a sleep that's awesome so you got to get your buddies in on it okay whoever the pull request approver is i'm pretty sure that minification is going to be involved and that way you could

just cram a bunch of stuff into the code and then a month later delete it all and be like hey look i removed 20 of the page weight that's awesome all right this episode is sponsored by dev boot camp thinking about becoming a software developer check out dev boot camp the original short-term immersive software development program that transforms those new to coding into job ready full stack web developers learn front and back All right. Visit devbootcamp.com slash codingblocks to learn more. All right. So we've been having some fun with the surveys, and I want to have some more today. So you guys haven't cheated, have you? You haven't looked at the results yet, right?

Man, how do you think I got through college? Okay. So going back to that education conversation. Joe, did you? Why do you always ask this question? Do you want me to lie to you? Oh my God. You guys.

Don't you know the rules by now? I didn't look. I didn't either. You liars. All right. Well, last survey was girl Power, the Princess Rap Battle, and I can never pronounce her name. Galadriel. What?

Galadriel. Okay. Well, her versus Leia. Who wants to take Mrs. G versus Leia? Oh. I prefer Leia, but Mrs. G. She dropped the Alderaan bomb. Okay. You know, what can Leia say to that?

Right, right. Alan, who do you think was the winner? Leia. Leia? Yeah. Well, only one of you is right, and it's Alan. Woo-hoo! By a long shot.

She has a blaster, man. Come on. Yeah, man. How can you beat beat lasers that's what i'm saying especially lasers that you can see yeah it was it was like more than three quarters of the votes were for leia wow yeah definitely the popular choice was leia nobody wants some fantasy chick beating beating leia it's just not going to happen. Yeah, I'm definitely more, when it comes to sci-fi, I definitely like the sci part better than the fi part. Yeah. Although I'm not really

even sure who Galadriel is, even though I've read all those books. She was the person in the rap battle with Leia? Right. Maybe she was an elf? I don't knowia right okay maybe one of that maybe she was an elf i don't know so yeah i hated that whole series um i know that probably just upset a lot of people but there it's out there i thought it was horrible all right so we won't make that the next survey though but what the next survey is is on one of my favorite topics get and we had this conversation

in the slack channel again if you want to join hit us up with an email uh specifically with the email that you want us to send the invite to either at comments at codingbox.net or hit us up on DM on Twitter. And the conversation was whether or not to squash your commits, right? So to squash or not to squash. That is the question. And you're talking about racquetball? No, we're talking about Git. I already said that part.

You weren't listening? All right. Sorry, I just got to up. Is this microphone... James, can you hear me? Okay. Alright. Alright, so your choices are... Wait, wait.

First. Are you going to explain what that is? Okay, fine. You're right. It's a squash or not a squash what fine fine fine okay so so a little backstory here if let's say you are in let's speak specifically to get your you have uh let's say 10 commits that it took you to implement some feature right and now it comes time to put a pull request together and submit that pull request now you could

uh using git squash all of those 10 commits into one nice commit and that way the people reviewing it only see the the one commit and when they look through their git log after it after that feature gets later merged into uh into the into the master or whatever the main trunk is called, then you know, they only see that feature as one commit in the Git log, right? So it makes it easy from that point of view. Or you could not squash those commits and just leave the 10 commits as they are. Put your pull request together.

Now there's 10 commits. And then when it gets merged into whatever the main trunk is, now there's 10 commits for the implementation of that feature. Right? So your questions for this survey are, your options for this survey are I squash because I care or everyone can learn from my path so I don't squash or wait what okay but I do want to clarify something here there's actually a slight little nuance all right so the squash does take all your commits your 10 commits puts it into one right so you just literally see here's where I started and here's where I ended up. That's it.

You see no intermediate stuff. However, the not squash does not imply that your stuff will be linear, like you're just going to see it played out. In order to do that, you would have to rebase. Yeah, this is not a rebase conversation. But I just wanted to point out that if you're working on a team with a bunch of different people and you don't do anything except put in a pull request, then it's going to be extremely difficult to actually see your path at all because it's going to be so intertwined and interlaced with other commits. times where people, I've heard people or read where people have confused the topics or think that squashing and rebasing go hand in hand.

And they don't. If you rebase, what that is doing is it undoes your 10 commits, it merges in whatever branch you're merging in and then it replays your 10 commits on top of it and those 10 commits get new commit

ids as part of that process right so when you look back in the history you'll now see those 10 commits in order so for instance if you worked on your branch for i guess you're trying to talk me into not squashing no no i'm not trying to talk you to not squashing i'm just saying that i think that it should be squash or don't squash with rebase. So that because there's really no value to not squashing if you're not going to line your commits up because you can't follow it. Like it's straight up. Wait, there's not value in squashing? No.

If you're not going to. There's not value in not squashing in this in this survey if you're not going to rebase because what i'm saying is if you rebase i say that there's not i i say okay so here's my opinion okay no i don't i'm not trying to sway the the jury but uh but he's going to but i'm going to and so what i say is that you know if you if you, you should, if you can, unless you just can't for some reason, then I say that you should. And here's my reason is that I don't care if you do rebase it or not. Clearly, clearly rebasing your 10 commits in on top would be better than not. But I don't care what your thought process was to implement that

feature. What I care about is the feature. The end state of the feature is what matters. Your journey to it isn't important. And if that doesn't sway your opinion, Git bisect should. Because now let's picture three months have gone by and I need to do a get bisect because I'm trying to figure out some problem or maybe not three months but you know however some duration of time has gone by and now I land at one of your partial commits that may be incomplete hopefully it compiles and works it's not going to help me to bisect the problem that I was originally trying to because now I've landed on a partial feature

so that doesn't help me hey where's that where's that bisect button in the github app I'm not seeing it what Joe says for real sometimes the path is important

have you ever done something and say you do it version one and as you're about to check in the ticket boss says no no no do it this way and so you do version two now if you squash those changes and then two days later your boss says whoa sorry version one that's very legit no no that's that is a very different story that he's describing yes because he's describing iteration. Yeah. And we're not talking about iteration. We're talking about you're developing a feature, right?

And that feature took you 10 commits to develop that feature, and now you put the pull request together. If you're at the point of already putting the pull request together, then the feature is done, right? I work on some things that change during the day no i actually agree with joe on this because i've totally been there to where you're not ready to put the pull request together but it has changed and so it so what you're saying is if you get to a point to where you can put a pull request together and that

didn't happen we'll say then you squash it like i'm on board with that but what he's saying is you're working on something you show it to your boss and he's like uh i want you to go in this direction and so you keep developing now if you squash that when you now put the pull request in after your boss has changed his mind three times you lose all that history you're not putting the pull request together until he okayed it that's what i'm saying so now you're going to lose all that history because yeah you're missing the point you're missing the point none and during none of this time have you have you put the pull request together you're saying you developed a feature you went to get sign off from your boss he didn't like it he wanted some change so you make his change right now you should be getting sign off from him again you're before you put the yeah you're committing but before you put the pull

request in you get sign off from him hey do you like this he doesn't like it now you can still revert back to your commit no no you put the pull request in he wants it tomorrow no tomorrow yeah no the tomorrow he's like no wait you know? That's not what we want. Go back. You can't. You can't, right? You do lose history. I mean, I change stuff all the time. I'll do something one way, and then an hour later, I do it another way, and then I go back because I'm crazy and don't think ahead sometimes.

And so it is nice to have that history. But my solution to that is to squash my pull request and then keep the local branch so that I have those changes unsquashed so i i can do that keeping the local branch can help this so so to the survey though i mean i i think we should do the survey but he's describing a tool though hold on let's be careful there because the way the way that joe's describing that is he's depending on the the tool that he's using for the pull request right specifically i I know he's referring to Visual Studio team services. He's relying on them to do the squashing because if you're doing your

squashing by command line locally, then local branch doesn't matter. You've already done it unless you're going to branch it into a new directory or clone it into a new directory. Oh, that's a good point. You could branch the branch. You could branch the branch, but yeah, you could branch the branch or, or, but then it's just a mess, right? Trying to keep up with it.

Don't branch your branch. And so, so, I mean, I just wanted to lay all that out there though, to make sure, because a lot of people don't even know what this rebasing versus squashing and all that stuff is. And so I wanted people to actually understand what you get and what you lose in both of those cases. And, and honestly,

to me, not to sway, I'm on the fence. Like, it depends on what I'm working on. Like if I've been working on something for three months and I've had to make a bunch of changes along the way, and I haven't put in a pull request yet because this is a feature branch,

I'm not squashing that commit. I'm going to keep the entire history all the way up. Yeah. Now, if it's something that's like a week long, I'm going to be like, squash it, you know, whatever. It was something that was relatively quick to do. Squash it. I don't care.

But I'm not losing three months' worth of work with 50 000 changes in between just just because i want one clean commit man get can keep those diffs and they can be happy with it and if you want to bisect it you don't know how to go past my broken commit you need a better tool no but that's no that's that that's actually not a fair statement that's not a fair statement because if you're bisecting and, and at the point where you're bisecting at that commit, if, if it's a broken build,

for example, then what are you supposed to do? Right? Like you can't, you can't evaluate whether or not what you were trying to fix, the problem that you were trying to, to, to inspect and dissect,

you can't evaluate whether or not that commit is before or after the problem was there. Yeah, I'm with you. Again, like I said, I'm actually on the fence. This is one of those situations where I say there's no one-size-fits-all type thing. It really boils down to what kind of development you've been doing, how quickly it's been done, and that kind of thing. To me, I'm not going to squash every time,

and I'm not going to rebase every time, and I'm not going to just simply do the same thing over and over. It really depends on what my workflow was leading up to that point. I wasn't taking an absolutist point of view that you have to do it every time. I said if you can.

I think you were. But I guess my point, though, is that more often you can. More often, especially if it's a quick feature, right? Like if it's something you knock out in a day or two, more than likely there's no reason to keep it. All right, so in your next pull request, I'm going to see it squashed. I'm going to use that button online to do it. I was going to say, like, I squash if there's a convenient checkbox for it.

Wow. Roger that. All right. So wait, did we ever finish this? Well, yeah, you did. You did. You got them all out there. Yeah, yeah.

The three options, I squash because I care, or Alan's approach, everyone can learn from my path. And then Joe's approach is, wait, what? Yeah, it's like next time someone says, you know what, man? I'm trying to bisect this stuff and it's a big mess because of all your commits. You just need to say, you know what? You need to learn from my path. You need to study up.

Give it a good look. There's value in my mistakes. You can learn from them. I can't teach your principles, man. Oh, no. I have a feeling we're going to hear about this one. Oh, man.

I'm going to go ahead and move us along to serving your team and how to develop talent. So, I got to say right here, he says, what does not destroy me makes me stronger. And all I could think of was Kanye. So for the rest of the section, I got this song playing in my head.

Oh, man. I've never been a fan of that analogy you're saying. Because I could think of a lot of things that would be so much worse. That wouldn't actually destroy me. I mean, stretch them not by giving them more work, but by giving them a new school. would be so much worse that it wouldn't actually destroy me. I mean, stretch them not by giving them more work, but by giving them a new skill or, better yet, a role to play on the team. I like that.

I actually really do like that. Anytime that I've tried to help bring juniors up and try and get them to do better or junior level developers or people that are trying to learn whatever the case may be like i just i just saw like grandpa alan here every time i'm trying to bring the juniors up yes right so like i my approach was always, okay, you're trying to accomplish whatever this task is. Go do it. I really don't even want to give you any advice. I want you to go do it. So that I can see that you tried, you struggled through it.

You're going to learn a lot just by doing it. That's a tough assignment to give to someone who's fresh out of school. This is their first gig. I'm not saying it's a hard thing. It might be just a task. I impossible thing no this is more like okay i need you to change the label right something like that it could be just a very small task but i want you to go figure out how to do it and then when they come back if they did a good job and be like hey that's excellent if it could be improved upon i'm going to be like hey this really isn't

that important of a thing right now to where we have to have it today i want you to see if you can improve upon that and let's do it by doing x y and z right but i can't help but kind of smile and laugh because like you mentioned label specifically and i seem to recall certain someone who worked in a particular framework where it took i don't know how many days was it dude joe laughed at me yeah i was like yeah i remember that framework very well man no this wasn't fair so sometimes if it's a crappy framework that you're working in changing a label is a harder task than you're making it out man this is no joke this is when i first met joe and he was kind of the guy that i had to go to to

talk about the things that i'm working on right and and my very first task was literally changing a label on a page and i'm like are you kidding me like this is this is ridiculous why are they paying me for this right man i'm not kidding two days later in a two-page wiki that I wrote, I had changed the label on the page. And I went to Joe, man. I was, like, defeated. I was like, dude, look, I apologize. I'm sorry, but, like, I thought this was going to take me five minutes, man. He's like, nah.

Nah, he's like, totally don't worry about it. And I'm like, what are you? That's why you got the ticket, man. I knew you'd be out of total hell. And I literally, I felt like I had just been destroyed, right? Like I had been shot by some meteors. It was insane. Like I said, crappy framework.

It could be changing a label. It could be a big problem. If you hear the letter CMS, beware. Yeah, there was a couple statements in here. One that I strongly agree with and one that I wasn't so on board with. He says that if there's never any failure, there can be no sense of adventure.

I'm like, wait, what? No. No, I can definitely have a sense of adventure and sense of accomplishment just by being done early. I don't need to fail. Yeah, I can definitely have a sense of adventure and sense of accomplishment just by being done early. I don't need to fail. Yeah, I'll get my adventure in my own time. Thank you.

But I did like the statement that I strongly agree with, which was saying that if there's not occasional failures, you're not taking enough risks. Totally agree with that. Totally. You need to get outside your comfort. Go ahead. He also kind of pushed it. He didn't quite phrase it like this, but basically credit out, blame in, and I put parentheses private.

And the credit out, blame in is like a seven habits of affecting people thing. But I did like the fact that he was kind of saying the same thing, except that praise people, give them the high fives in public, and if you've got to talk to them about something, do it in quiet. Do it alone. And don't embarrass anybody. Don't you know egos on the line don't start an argument so i thought it was kind of cool those are all super important now again keep in mind this is how to develop talent right and he says he says you can't give up on someone who's intentionally not carrying their share of the load right because of low morale or

or dissatisfaction right you can't just let them be slack and you must try and motivate them yeah and and you know what there's truth to that and that is very very difficult to do because you as the person that is trying to motivate them sometimes it's like everybody else is pulling their weight why aren't you right like you kind of hate them a little bit you do like you have a little bit of resentment it's hard not to i think you already go go into the situation kind of judgmental though like you kind of have a tip on your shoulder right well it's going to be well what's this person's track record though right has this person has have has this person brought major you know wins for me in the past or have they not because if they haven't then i might be less inclined like if they've if they've brought

consistent failures right then i might be less inclined and which is not the response that he's going after here well he's saying why i'm probably not the advanced programmer but hold on this is why he's not saying people that have been terrible he's saying people that are intentionally slacking right and there's a difference right like if you have somebody that's unfortunately the most motivated person in the world but they just can't seem to put together anything that works like a label that's you know as it happens um no it worked it just took me a long time right but but there's a difference right maybe you just need to find out hey man

what do you what is it that you want to do like what's going to excited? You know, and so maybe that's the approach you have to take. Maybe that person's kind of been backburnered for a long time. Like Joe talked about in the past, like he likes to work on Greenfield stuff. A lot of times as an employee, you get stuck with all the old garbage, right? Because you have the business knowledge behind it. So maybe that person seeing that everybody else is getting to work on this cool stuff and he's just kind of hanging out. I have a different perspective on life now after 2016 election cycle.

I just keep thinking, you know, what would Trump do about a demotivated employee? You're fired. All right, next topic. Yeah, I mean, he does say like when your patience is exhausted and you fire them but that's why i guess to my point though is this we're all human right you're going to take your past experiences with you and so if this person has brought successful wins to you then you're going to be more likely to give them that extra time, right, and work with them that extra bit. But if it's someone who hasn't brought you wins, you know,

regardless of why they're slacking, you're going to have less tolerance for it, period. And that's just human nature. That's just how we are. It is, and it's hard not to be that way. Well, the next one we've got is how to choose what to work on don't you get to do that every day you're just like yo this is what i'm doing today yeah i kind of feel like i don't have a whole lot of choice here i basically you know like we're all using ticket managers right and they all have priorities and and the only really question for me

uh you know when i'm trying to pick my next task is if two things are the same priority do i go with the one that i think is going to be easier to do or the one that is going to be more mercury um more murky and hard to figure out yeah because the business owners get to decide what we work on they do but i would say that having an open line to your manager or whoever that may be and voicing the kind of things that you enjoy to do can go a long way right like maybe they see that you're busting your tail and they say hey i know that you know hey what's going to make you happy if he doesn't reach out to you it's your job to get in his ear and be like and and i don't mean

complain and whine and moan i mean hey you know uh i've been working on a lot of this stuff and i and i and i love contributing to the team but hey man could i work on something along this line right like i want to get more involved in databases or i want to get more involved in this can i can i do that so there's that approach but the approach that i was thinking of that I think I've actually had more success with is just going back to that one about getting to know the users, right? Yeah. there's a strong chance that you're going to be involved in. And part of the reason why you're working that idea out with him in the first place is from an interest point of view. So that can help you be the guy because you're already the go-to guy

from the business owner's perspective, right? Well, I was trying to not say design perspective, but the guy who was originally trying to sort out the details of it, then a lot of times, more often than not, by default, you get to be the guy to do it. So sometimes it's making your own destiny is really what it comes down to.

And you could even end up leading that project, right? Even if you weren't the lead, if you've got that connection, you could. Yeah. He also said to do what you're best at, which I thought was kind of interesting, but also to stretch. So I know that sometimes I feel like I should do the things I know how to do. Also, sometimes it's nice to do something I'm not good at just because I need to get better at it and I want those things to be fluent.

Well, yeah. I mean, I actually thought that that was kind of an interesting point too because I've always thought of it from the opposite point of view, which is you should practice the things that you're weaker at to get better at them. And I mean, I've kind of taken that approach. There's definitely diminishing returns, right? Huh? What?

There's diminishing returns. Oh. Yeah. I mean, I know I've taken that approach with times where they're, like you mentioned, here's a few tickets, which one do I want to work on? And there are definitely times where I'm like, well, this is an area that I don't touch often, and if I work on this ticket, I can get better at it. Right.

And that'll pay off in the long run for me. Yeah, assuming that you like the things that you're not as good at. That's a good point. I mean, it really is. Well, yeah. I mean, yeah, I mean, I was thinking more to, like, not necessarily, like, business rules or things like that, but more, like, technology stacks, right? Like, you know, if, if SAS isn't your thing, right.

But a SAS ticket comes along and you're like, well, Hey, this gives me an opportunity to increase those skills. Right. That that's not going to be a bad thing for me. Right. Right. So it might not be something I want to do day in day out, but you know, Hey, nice change of pace. Yeah. Yep. All right.

For the next one, how to get the most from your teammates. The obvious answer here is donuts. I was going to say. But I keep control effing, and it's not coming up. I was actually going to say the same thing. You show up on Friday with two dozen donuts. All right. Then I have one question.

Where's my donuts? Apparently, you both wanted to give me some donuts and I didn't get any. It's not Friday. I absolutely would bribe with donuts when it was available to me. I have absolutely good reviews. I expect a shipment of donuts. Yeah. Respect.

Respect's a huge one, right? If everybody respects everybody else, else then everybody it's almost like the daddy complex you don't want to let your friends down or your teammate down if you if you've ever played a team sport like you don't want to be that guy that lost the game because you weren't playing your position it's the same type thing right like if you have a strong team and usually close team people go out to lunch. We talked about this before. People that hang out have the same type morals and beliefs and all that. Then that can go a long way to having that effect.

And donuts. And donuts. And donuts. We've mentioned this concept before, but it came up again about the disagree and commit. One of the Amazon principles, and did this guy start Amazon? I'm pretty sure he didn't. But yeah, he made the point about if you don't, sometimes you just need to let your team do things their own way,

even if you don't agree. And you can disagree openly, but you need to accept the consensus of of the team there was another thing that he said that i actually know a very good friend of mine who did this he basically he says sometimes it occasionally means allowing your teammates to be wrong so so you know that what they've decided to do is not going to work but you let them do it anyways because you have to show that you have faith in the decisions and all that kind of stuff and i actually know a guy who did this at a very high level with one of his high level managers this guy wanted to work on a project and he was like yeah i don't think that's a great idea but the guy he really wanted to do it like he thought there was gonna, I don't think that's a great idea. But the guy, he really wanted to do it.

Like he thought there was going to be a lot there. And he's like, all right, we'll go ahead and do it. And then after he did it, it didn't turn out to do what he thought it would. But he was like, you know, I mean, you can't let somebody go their entire career and not be able to do some things, right? You sometimes have to let them go. It's almost like having kids to a certain degree. You can't box them all up right you got to let them explore and find out what's out there if you hold everybody down they're never going to get better at anything they do right all right

how about how to divide problems i like to divide by two i don't know maybe you like to divide by two. Maybe you like to divide by three. I like what he said about dividing early. A lot of times a project will get to the end. There's like one week left. It's severely behind schedule, and suddenly it's time to split it up. And so there's a lot of communication. Things get confusing. So I definitely like the idea of kind of from the get-go working with someone or splitting up amongst other people yeah i mean that again i guess it depends too because like i guess i got so um

i won't be the way to put this you know there was so much like project planning and waterfall type things mentioned in here that i guess i kind of like glossed over things when when it came to like project planning again i was like oh not this again yeah it's i think you tend to favor kind of like one person owning like a feature or a thing and that can kind of you know walk it all the way through to the end which might involve splitting up but not so much 50 50 as it it might be 90-10, right? Wait, I am that guy? Yeah, I think so.

I mean, you've mentioned before, like the 12-factor apps and stuff that you like the developer to kind of own a feature all the way through to the end, right? Well, I want you to take ownership of it, yeah. But you might be, there could be two people or more people that are part of that.

But yeah, definitely if you wrote some code, you should take ownership of it and not say, well, you know, it, it doesn't work because I didn't have a unit test and blame it on something else. Well,

you know what I'm saying, I guess it's like, if one person is doing the front, one person is doing the back, you're working on the front, you're owning the front. There's something you see to make it better, but the,

you know, the other person's kind of dragging their feet a little bit on that feature. Like, are you really, you know, are you just going to let it go? Are you going to dive into their see to make it better but the you know the other person's kind of dragging their feet a little bit on that feature like are you really you know are you just gonna let it go are you gonna dive into their code to make that fix you know what happens with maintenance you know are you really gonna rely on someone else to to you know potentially mess up your feature i mean if i if i'm working with somebody, if I follow your example correctly, right? Like I'm working on, say, the front end, someone else is working on the server side.

There's definitely been times where I finished my part ahead of time and I've jumped in to try to help where I can. But that's also a situation, too, where it's kind of difficult because it's almost like, well, how many hands can you have in the cookie dough before there's too many in there and nobody is able to actually make cookies, right? Hmm, cookie dough. Yeah, I know what you're saying. And so, yeah, that's why I have a hard time with the 50-50 split for smaller features. But if you kind of have one person who's running the lead on that feature, then I think that makes sense a little bit. And so, you know, someone else can do part of it, but ultimately I think one person's really got to kind of take ownership of it.

You know, otherwise it gets to be a, oh no, there's a bug. And then, you know, it becomes finger pointing time as each person tries to figure out, you know, what needs to happen. Yeah. Yeah. I mean, yeah. happen yeah yeah i mean yeah i i i would i don't have a good answer divide by two and have cookies this doesn't even mention pair programming well does any does anyone actually pair program or is that just like a thing that Ruby people talk about but never do? I've heard that there are shops that do it and some of the people that have done it actually like it quite a bit. No.

Yeah. Even here in the Atlanta area, there are shops that do it. It seems sort of crazy to me. I mean, like, I don't know. I don't know that I've ever done it for an extended period of time. There have definitely been times where I've sat beside someone and we've worked some problem out. But it was more like one or two days to complete something. And then you go about your day.

Yeah, but no like Monday through Friday, you know, eight to five. Programmers have bad breath. There's no way I could do that all the time. Yeah, man. I think there's a generality. Are you trying to tell me something here, man? Like, this is awkward. Look, man, if there's any programmer on the planet who does not have bad breath, Outlaw

spends like $30 a day on gum. There's no way. There's no way I have bad breath. I'm just saying. All right. Well, how to handle boring tasks? If somebody knows how, please tell me. Delegate?

I actually really like the advice here, which is kind of funny because of what we just talked about. But basically, they say split it up. But I don't think that necessarily means split the task up 50-50 like I was saying, but when I think of a boring task, it's kind of like a repetitive thing that's kind of either hard to work on or it's boring but still needs to be babied or for some reason we can't automate it.

And so it kind of sucks to give it to one person and have that one person always lugging that around. So if you could split that up, even if it's just one other person and they kind of take turns, it doesn't feel like they're off on their own carrying this burden. Well, so there was this quote in here about sometimes it's not possible to avoid boring tasks that are critical to the success of the company or the project. And I immediately,

like in my notes here, I wrote down CSS sass and less like those are those are things that you can't avoid in in your web application but yet they're also you know if you were a designer then you're probably taking huge offense to what i'm saying here so it you know it's one of those things that like i'll do it and and you know i'm i it's going back to trying to practice the things that you're you know that you're not as strong at right to increase those skills i'll definitely do it and and gain something from it but if i had my choice of picking something to do you know it's not my most favorite thing. Right. Well, I think I agree with what Joe said a second ago, and he even puts it, I guess,

in so many words, if all else fails, apologize to those who have to do the boring task. That actually goes a little ways to helping, right? Like, dude, I know this stinks this stinks but you know we just got to get through it and then but under no circumstance allow them do it alone and i think that's important right like don't just stick it on one dude or or girl or whatever the case may be lady woman guy don't stick one person with it because it really does feel like, dude, why am I on traffic duty? Why am I the dude standing out in the middle of the road? Here's a good example.

Localization. Imagine your boss was like, hey, we want to port this thing to Russians. So get to tokenizing. Google Translate. Right. I would totally write an API really fast with that. Yeah. And then go to every string in the application and swap it out for its appropriate variable.

Yeah. See, I'm already asleep. Yeah. All right. How to gather support for a project. This sounds like politics to me. Yeah. Prot prototype was mentioned and i've seen a lot of times when like someone would kind of go off on their own for a weekend and kind of build something come back and say look i told you it was possible but i'm not crazy about that

because i've also seen you know the person come back and then they take the prototype and they try to just use it and it fails in production because it's not production ready or you know it totally gets dismissed like yeah that's nice but i don't wanna so you just wasted your weekend um there's also the possibility that you bring in the prototype and i don't even remember what i was gonna say i just i'm not super big on this one although sometimes it does work out and i i get it i get how it could be helpful but just kind of sucks for the person who has to spend their own time doing it definitely been on you know there have definitely been times where it's like oh hey great i have this idea for the prototype do it and then it just falls flat right and even though you're like but there's value here like why would you not want to do this

and you know it doesn't matter well unfortunately what i said about the politicking while somewhat a joke is not like if you really want to gather support for a project you need to get some key players on your team right and which is such a crappy way to have to do it it is but i mean it's just the way it is so if it provides value then it provides value, then it provides value, period. But you need to prove that it provides value. And if you can get certain key people on your team, then they can help sell it for you. But I would say, so to the prototyping part of it, I think it's important. You know, actions speak louder than words. I'm not saying you go build something.

Like, there's the Infragistics prototyping tool to where you can like kind of create flows and that kind of stuff. Right. After you have gotten like maybe just, there's even apps on an iPad where you can literally just do like little screen, screen flows to where, you know, you click on here and it goes here or whatever. You can do that pretty quick. Get key people on your team after you show them that stuff. And if you get enough buy-in, then at that point you start building a you can do that pretty quick get key people on your team after you show them that stuff and if you get enough buy-in then at that point you start building a prototype because building prototypes can take plenty of time and to joe's point a lot of times they're not even done well because it's

literally just hey let's do whatever we can to at least get this thing on the screen and you know yeah not worry about performance not worry worry about abstraction, anything, right? How many times have you seen the prototype become the production instance? And it happens too much, right? Yep. Oh, fine. Yeah, we'll just take that. But I do think that to a certain degree, and it's not so much politicking because politicking implies usually some negative connotations. But you do need to get key people on your team, right? Like if, if you're trying to do,

I don't know, if you're trying to add something to a page that's, that's going to bring in clicks, then maybe you want to get a marketing person involved, right? And explain to them why it's important. You know, I don't know. There's value in knowing who will care about it and then getting those people to work with you. I'm just thinking like, you know, if you don't have support for this project, then you're probably going to have a tough time working on it for 40 hours or whatever. You know, so that to me immediately means that you're kind of doing this, you know, on the weekend or outside of work or sneaking around to do it. Yeah. And that's, that's not good either.

All right. How about... So, wait, how do you gather support then? I guess you just... Oh, you mean, so... Donuts? No, I mean... So, I guess to your point, like, you shouldn't be spending a ton of time

on the nights and weekends unless you're just super passionate about it. But like I said, you know, even an iPad app or something like that that can just kind of mock up something right in a pretty way that looks attractive that will show your idea if you can't get it across with a simple mock-up then maybe you need to refine your idea before you even take it any further right yeah maybe um listen to what the reservations are like if they don't want to do it because they don't

want to maintain it then show how easy it is to maintain it if they don't want to do it because they don't want to maintain it, then show how easy it is to maintain it. If they don't want to do it because it's a financial risk, then find a way to do it without that risk. Yeah, all very good points. All right, let's move on to how to grow a system. Well, a little bit of water. Yep, some sunshine. They mentioned spiral milestones. well grow it a little bit of water yep some sunshine yeah how do you guys um they mentioned

spiral milestones i've never heard that term before but i thought it was kind of interesting you imagine like starting in the center and kind of going around and having you know these milestones either go more often or less often i wasn't really sure which one it was i don't think i read that in there yeah it's kind of weird i'm gonna have to google i don't think I read that in there. Yeah. It's kind of weird. I'm going to have to Google this. I don't recall that either, but I've never heard of it. Oh, no, it was the spiral development. But, no, I don't – I've never heard of it described that way before. It sounds like it's somewhere between waterfall and agile. I mean –

So you have, like, little milestones that are, you know, various points apart. This reminded me a lot of what we always talk about is iteration right like they they equated it to a bridge right like a software is not a bridge a bridge has to be complete before you can use it software you can add parts to it as you go along that make it more and more valuable over time and that is how you should grow it you should have your vision of where you want it to be but you should take the steps to grow it slowly and get it or maybe not even slowly but not just try and be like hey we're not going to do anything we're not going to put anything out there until this whole

thing's done right he makes the analogy of of a baby right like every day that baby is growing that child is growing and learning something and still able to do things but you know it's like a constant iteration every day right whereas like you said the bridge is not you can't you can't call software you know use software uh i'm sorry you can't use a bridge as an analogy to software because the bridge isn't a bridge until it's complete. Before that, it's just a piece of junk. I don't know. What would you call it? A ramp?

I did look up the spiral model, by the way. If you've ever had one of those horrible management training sessions, and you've seen this, it's basically you start out in one quadrant like determine objectives you go around the wheel identify development plan you know and it just kind of keeps cycling and as the the circles get bigger you know you end up doing more stuff until finally you're done but very water folly yeah i mean one thing that he said and this kind of goes to what we've said, I don't know how many times on here. I would even go further and state it is a law of nature. No large, complex system can be implemented from scratch.

It can only be evolved from a simple system to a complex system in a series of intentional steps. And that is completely true. If you ever have a boss that's like like we're totally replacing these five systems with these 10 systems that we picked out man and they say that it's going live on you know one year from today uh run because it's not going to happen you can't do it what you do is you slowly integrate new systems and you slowly phase out old systems or you slowly grow software you having ideas look at ideas sorry to interrupt but look at ideas from students who are you know maybe in whatever their program is like a final you know a senior project or you know their

thesis or whatever they they develop some idea there, right? And regardless of how well that idea is received at that time, they start iterating on that idea until now it becomes a big thing. There's two big examples that come to mind. Facebook. Actually, okay, fine. There's three examples that come to mind.

Wait, you forgot facebook well i was thinking i was thinking of linux that was that was the first one that came to mind okay and then you know thinking outside of the box uh coincidentally fedex right there's two ideas that that started out like fedex was originally, if I remember right, the guy who started it, it was like a Harvard dissertation that he gave or master's theory or something. I forget what it was. It was an assignment in school.

Let's put it that way. And if I remember right, he actually failed the assignment. And now it's a major company. Oh, that's cool. I didn't know that. So those are small ideas that started out as just a simple classroom assignment that then grew and grew and grew and grew and grew

to big things that they are today, right? That's really cool. I didn't know that. I'm actually on FedEx's About page right now. That's kind of cool. I think it it's a book that's pretty nifty but yeah i mean even facebook right like it started out as a hot or not type thing and he just started growing it like it was a college basically chat site at one point and then it was oh well let's open this up to more people let's build a platform that other people can hook into like facebook wasn't an overnight thing it did not grow into

the multi-billion dollar thing it did because he said no no no i have this idea we can't put anything out until we're all done with it right right so you mean there's a facebook before farmville right i just kind of assume they just launched at the same time. I mean, it's one of the things that I think stops some people with really great ideas from ever accomplishing them. Oh, you know,

sorry. No, go ahead. I just got excited. I remembered when Images was an app. It was a Facebook app that was separate from the rest.

So if you wanted to upload photos and whatnot, you had to use a little, like the plug-in, whatever. And now, thanks to their constant iteration, we have React. I mean, seriously.

And they open sourced it in GraphQL. Oh. Yeah. Does that count as embedding? No. No. That's greatness. The point being, though, is that, like, yeah, you can't start out with an end goal in mind of it being something big and it never happens that way you you can't show me

one example you know windows has been a constant evolution over the past what uh 20 30 years now until it's gotten gotten to be you know the behemoth that it is that still provides you know backwards compatibility for stuff from 10 years ago right like yeah you know it's a constant evolution so you have to just keep iterating on it yep so how to communicate well well i could probably improve on this one i prefer satire. Oh. If you could slip some funny things, then it keeps me awake. No, really, you didn't really talk about this so much,

but some things I wanted to kind of add here, basically trying to keep conversations in tickets so that they're searchable, viewable by people who don't have access to your email. If you do do an email, you know, use a good subject line, make it searchable because, man, there's so many emails fly around, they get lost.

And so the closer you can keep the things you're saying to like 140 characters or even, you know, broken up or even better in somewhere like a wiki or a ticket, the better because there's just too much information flying around to keep it in your head all at once. Yeah, he makes a great point that you know part of the problem that makes communication so hard is that the the whole process is flawed because the person that you're trying to communicate with they're not working hard to try to understand you right and and to

your point about the 140 characters like you know i have a good friend that I used to work with that he and I had exact opposite approaches on things, especially when it came to emails. Because, you know, I would take the point of view of, well, you know, if I'm only going to grab your, if I'm only going to get 30 seconds of your time, let me focus you in on, here's the thing that I want to say. Right. Whereas he would take the approach of, well, if I'm going to get any of your time, then I want you to have all of the information. So,

you know, mine would be a paragraph. His would be a book. And, you know, it was like, well, I,

I understood his point of view. Right. Cause if you're, if you're, especially if you're talking to like, you know, it was like, well, I understood his point of view, right? Because if you're, especially if you're talking to like, you know, if this email, imagine if this email was going to like a C-level exec, right? They're only going to read so many emails from you, right? So his point was, well, just give them all the information that they have, so, you know, that you have, so that they can have it to evaluate it right then and there rather than trying to have a discourse with them over several it's like information overload yeah that's kind of the way i took it though what you ever get someone who uh who will forge you like a you know 17 email long chain like here catch up right yeah i don't know i get why they're not going to,

you know, be able to really summarize that easily. But man, going through, there's something about scrolling to the bottom and reading up. That's just painful. I guess, I guess though the takeaway from that,

um, you know, from that, that exchange with my friend was that like, it did kind of make me become more, um, verbose. Yeah.

Okay, fine. We'll call it verbose. Yeah. Okay, fine. We'll call it verbose. Yeah, it's funny because I actually feel differently about it. So a lot of times now, when I write important emails, most of my emails, they're basically glorified chat.

They're short. They're one sentence, whatever. But the ones where I'm actually trying to express something now, I'll actually do something like have a header that's five words saying, here's what I think we should do and then I'll have another header down below that says you know other options or something so

rather than providing you know three paragraphs kind of talking about this and that and whatever I try to kind of present the information in the way that I think they're looking to hear it and a lot of times I'll even do something like in a nutshell here's my two sentence saying let's do this now here's the details that says how i got to that conclusion yeah i think honestly formatting what like what you said having like headings that can be huge oh yeah i definitely try to do that like if if if you say this is what i think we should do and then a couple bullet points right quick reads something that they can skim with their eyes and get the gist of the whole thing. And then, like you said, if you want to throw the details down at the bottom because now you've grabbed their interest, perfect.

But if you literally just have blobs of text everywhere, like somebody, I know we've all done it, right? Like you open an email and you're like, I don't have time to read this right now. Right. But if there had been a heading two up there that had something that was attention grabbing, a couple bullet points, another heading two, and a couple bullet points, chances are you would take the time because your eyes can easily hit those points, right? And, I mean, one of the things that he said in this chapter that I really agreed with is if he had something important to communicate, he would try and talk about it. He would have a white paper that he could hand out. And then he might also have a presentation, you know, a PowerPoint type thing. And I think that's important because everybody is stimulated in different ways.

Some people are visual learners. Some people are audible. Some people like to just read things, right? And so having things prepared in that way, if it's important enough to warrant that amount of work, can be super important. But, I mean, that assumes that the problem itself warrants that type of thing. Like a presentation? I mean, come on. If I'm just sending you an email,

I don't want to do a presentation. But I know that there have been times where I've sent emails that were, the subject matter itself was already complicated. Right. Right? And so now I'm trying to convey very complicated topics, information convey very complicated topics,

you know, information about very complicated topics. And like he says, you know, the reader or listener, they're not working as hard to understand it necessarily. Right. And so there are times where like,

I'll get responses back and think, man, it just went completely over their head like all of that effort that I put in there to try to be clear to explain it as clear as I could and and to avoid confusion and it feels like it was all for naught and then I know that there have been times where I've been guilty of getting that response and then completely missing their point. Because it's too much to read. It's too much to take in, especially out of context, right?

Like when you are the developer and you're in the code and you're in the problem, it's very easy because you are immersed in that world, right? Now you're trying to recreate that world for somebody that's not immersed in it. And it's really hard to do that

in a way that doesn't bore someone to tears. And I'm sorry. Okay, so you don't like my emails. I actually have a problem when I'm writing emails like that because I'll look at it and go, man, nobody's going to read this. They're going to open this email and go, oh man, they're going to read the first sentence and be like,

man, I really don't even want to have to try and figure out what's going on here. But where I thought you were going to go with this, though, is that you were talking about sometimes you're too involved in whatever that problem is that you're not taking a step back to see their response the way they saw it. Right. And that's where I meant there have been times where I've gotten responses that it took me several reads before I was like, oh, wait a minute. I see what they're getting at now. Right. Because I was too deep. I was too lost in the weeds. Right. reads before i was like oh wait a minute i see what they're getting at now right because i was too deep i was too lost in the weeds right and it took me a while to like step back out and come

back out so there's definitely times where like i'll read that response multiple times you know trying to make heads or tails of it yeah when i write a long email like that um a lot of times what i'm really saying is, I have an impossible problem. I can think of two solutions and they're both bad. And so what I'm trying to do now is to basically have that, exactly what I said, be the first sentence or two. Like, I have a problem. I don't know how to solve it.

You know, see more details below. Because that gives the person, you know, actionability. It gives your boss or whoever is reading it something to respond to. And if they want to dive deeper on either of those solutions, you know, they've got the information below. And they can kind of skim or hop around to what they need to. But ultimately, your ask is right there front and center and with its own header. That's fantastic advice, actually. It really is.

And it's a great segue into the next section which is how to tell people things they don't want to hear uh in email uh with headers right yeah i mean seriously unfortunately it's been proven time and time again sales copy on pages is usually just kind of bam in your face type stuff and it affects you psychologically anyways oh yeah i mean you know one of the points that he makes here is exactly to what joe was saying is the best way to tell someone about a problem is to offer a solution at the same time yep that was the one sentence i highlighted in this entire area really yep yeah i mean i've heard some stuff in like management Yep. Yeah, I mean. I've heard some stuff in management-type training before about, you know,

give them a situation, give them the thing that happened, give them what they did, and give them the outcome, and blah, blah, blah. Oh, and compliment them at the same time. But really, you know, I feel like keeping it kind of clinical. If it's really bad news, then just keep it short and say, we're not going to be able to launch this May 1st. But you look nice today. I'm not going to be able to do this ticket.

Well, that's awkward. No, man. When I start crying, I'm a mess. I am not a pretty crier. Why? Why? Why did we go there yeah i mean i will say it is often better to just suck it up and do it right like unpleasant things in life period it's better to just get them out of the way so that they're not weighing on you and you just do it in the in the best way possible you know hey the schedule is going to have to slip we're not going to make it so we've become a nike commercial just do it that's right you know i do with this with them like if i'm you

know like if i'm legitimately sick or some emergency or something happened like a lot of times i'll hem and haw about the email that i'm writing say i have to miss work tomorrow you know i'm really sorry. And I'll write it and rewrite it and rewrite it. And then ultimately at the end, I'll just delete it all and say, I have to miss tomorrow. Yeah, done. Right. Send me an email if you need anything.

Yeah. I mean, that's really the short and the sweet is that if they want more detail, they'll ask. Right? Don't inundate people with detail on on especially uncomfortable topics unless they want it and if they want it give it to them yeah i'm always tempted to be like listen i had 101 fever from five to seven then it went up to 100.5 and i don't really want to work today because you know no man just you're sick that's all they care about right yeah no but really i had diarrhea at 323 and again at 347 i got 99 problems but joe's diarrhea isn't one apparently all right how to deal with managerial myths. Yeah.

Oh, you know what? There are, is this the one where there are a bunch of them? Yeah, let me open this page. Yeah. I thought these were really good. The four points are highlighted. More documentation is always better. Yeah. Yeah.

They want it, but they don't want to spend any time on it. Right. And another thing he didn't even mention. Definitely include that documentation. We talked about earlier is a lot of times that documentation will get stale, and that's also a problem. Right? Yep.

You know, I've actually come around to the idea that sometimes they're – okay, I'm doing a horrible job of explaining this. What was that section on how to communicate well? So, wikis are prevalent now, right? It's really easy to have a wiki for your organization. And you can put a lot of great information in there, but sometimes I've kind of come to the opinion that, you know what would be even better than that wiki?

That wiki would be great, definitely for people who don't have access to the opinion that you know what would be even better than that wiki that wiki would be great definitely for people who don't have access to the code but for those that do a really good readme right there next to the project goes a long way yeah and i like readme's in every folder oh yeah well whatever my point being is like you know that like put put the documentation there for the developer and not in just the wiki. Because then, to your point about the wiki growing stale or the documentation growing stale, then it could definitely happen. Programmers can be equated. Nope. What?

Different people have different strengths. You can't just say, hey, sue off this and put Bobby on it, and let's not adjust any of the timelines. But as a manager, I have this project that's going to take X amount of time, and if I can add more developers to it, then I can reduce that amount of time. Yeah, the swimlines in Jira are all the same. It says programmer. This one that you just read i actually almost dropped my kindle when i when i read it you cannot everybody hear this you cannot scale a team up at

the tail end of a project and expect it to go faster as a matter of fact what you should expect is that it's going to slow to a snail's pace because now the people that were actually getting work done now have to bring everybody else up to speed on something that they're going to have no clue about trying to double the size of a team or triple or quadruple the size of a team. When you're already late on a project will not help the project. I, it depends. Well, let's say i do largely agree with you okay but if you're if you're like you know early into the project and

you know yeah we're late you know we were planning to have it done in you know four months but we now see it's going to be six months yeah you know you got enough time to bring a couple more people in you know it might not help you uh you know get get any further you might still be four months long but just in case if there's additional problems that come up yeah so yeah if if you're what you're describing is like you've got two weeks left i'm totally on board yeah i mean even even a month left in a lot of cases. So I equate this almost to the overhead of having dual processor systems, right? When you have two processors, your system's not twice as fast.

What? It might be. That's what the turbo button's for. It might be 150% faster or 50% faster than just one processor right there's overhead in managing resources and it's even more true in the case with people and so and i'm not saying don't get me wrong i'm not saying that everything should just have one person working on other two people please i'm not trying to go to extremes here, but people that believe that, that programmers are just cogs that can be plugged into situations.

Yeah. That is an incorrect assessment of how things work. I agree. So I think the takeaway is to replace your programmers with SSDs. Yes. All right. Resources can be added to a late project, speed it up. We. All right. Resources can be added to a late project to speed it up.

We already covered that. It is possible to estimate software development reliably. Nope. It's not even theoretically possible. All we can say is we're going to try. Hey, until quantum computing comes out, which apparently they've made steps where like... Wait, no.

Wait. That's going to make estimating software development? Absolutely, man. They can do all the permutations. We won't ever have to think again. Right. It'll either take one day, two day, three day. It'll just be like the number of days.

It'll be from one to N. I do like to say that the smaller task is, the more accurate your estimates can be. But if Visual Studio starts crashing on you, then sometimes that doesn't work out so well. Even if you know exactly what you need to do, you know what to type. I will agree, though, with where you're going with that. The smaller tasks are definitely easier. All right.

Programmer's productivity can be measured in terms of some simple metric like lines of code. God. You remember the days when people actually got paid per lines of code? Like that actually happened? I never saw that. Tickets, though. I would see, you know, like so-and-so closed 11 tickets.

Like they wrote those tickets. Yeah. Yeah. It was really one ticket that they broke into 12 pieces. Yeah. Man. No, I've never seen lines of code as any kind of valuable metric ever. I mean, yeah, it goes kind of like what Joe was saying about the number of tickets closed.

Like, who cares? By the way, yeah, if anybody ever thinks it's a great idea to report on how well you're doing on tickets and all that, you can almost guarantee that's going to be gamed in some way, right? Oh, yeah. Well, lines of code is the same way. Yeah. I mean, those kind of statistics don't matter unless somebody's really paying attention to what those tickets have in them, right? But then again, every ticket has its own weight and its own life, really.

Like you get into it and you think, oh, this one's going to be easy. And then you get into the system and you're like, oh man, this is not a five point ticket, right? This is, it's not a realistic way to do things. And it's not just programmers either. I worked somewhere where QA was kind of incentivized to find tickets. And it was kind of weird for them because basically the more tickets they

found the better so at the end of the release cycle even if the product that went out was totally crap and qa did a terrible job they always had the defense of saying well i wrote a thousand tickets and it was still crap so obviously the programming was terrible but that's not really the case that you know because everyone was incentivized to write more tickets so there were lots of junk tickets right and they had the uh the effect of basically masking the true quality yeah they could be like little things like grammar or yep you know not really functional things that are you know more important but like oh this is two pixels off yeah i think the key really is having everybody on board with what the vision is, right?

Yep. Let's try and get towards what the goal is. And let's all do it in a collaborative way, right? If you're focusing on metrics on things that really do not matter, like number of tickets open or number of tickets closed, you're doing things wrong, period. Yep. The same place, there was a reverse incentive for the programmer.

So your team would show up with the number of tickets. And so if a QA person would write a ticket, you would rush down there to talk to them, try to talk them out of it, see if you can hurry up and squeak that in before they wrote that ticket. And then they eventually got to the point where they would show the names of the people who had the most tickets. And so, man, if you were the person who was on that you know the hot chart the idea they said was basically

if you know if you could help that person or you saw that person had you know the most tickets and you can kind of you know it was highlighting the problem so that people could help out but it really had the effect of like feeling like you had like the evil eye of soren on you as you walked around the hallway you know like you have 11 tickets. How dare you get coffee? Man, that is no way to motivate. Because that also, let's be fair, right? That's going to lead to sloppiness.

I'm going to do whatever it takes to get these tickets out of my pile. And you're not going to be as thorough. Yeah, and it really did encourage sandbagging. Like, you say, you know what? I can't do all 11 tickets. You're going to have to be as thorough. I got it. And it really did encourage sandbagging. Like you say, you know what? I can't do all 11 tickets. You're going to have to reassign them and you keep, you know,

you fight like hell for the easiest tickets and you make sure that you're able to deliver them, you know, on the times that you estimated. That's ridiculous. And that's how you get ahead in that system. Yeah. I hate that.

Yeah. All right. So last but not least, how to deal with temporary organizational chaos. Temporary? First hope it's temporary. Right. Yeah. Well, I mean, he's going along from the point of view of that within your organization,

sometimes there are things like layoffs or buyouts or IPOs or firings or hirings. So it's not necessarily like the chaos isn't necessarily bad. Right. Right. Right. An IPO is a big deal. Yep. Right.

That could be a good thing for your company. Hirings could be a good – a buyout could be a good thing. It doesn't have to be bad. But the point is that there's a lot of commotion going on. Thank you. Yeah. Yeah. The one thing that he says here, and this is actually the reason why I love what we do. Engineers have the power to create and sustain. That is so true. And that is really kind of the power behind what we do is it's easy to show value because you, we do, we create things. And so it's easy to show value because you we do we create things and so it's easy to kind of

rise above and become important even when there's chaos going on yeah i mean we've made this um we've commented on this before because he's definitely opinionated on the engineer versus the non-engineer right and makes he And he says that non-engineers cannot create or sustain anything without an engineer. And it's kind of like, eh, all right. You know, I've definitely known some people that were not engineers or software developers by trade, but they knew enough around it to hack something into place

to create something that got a business up and going. Yep. Right? And, you know, we're able to, you know, hire on additional teams and whatnot. So it was, it just felt unfair. This is a little arrogant sort of towards, you know, engineers being above and beyond everybody else

which yeah it feel it felt kind of elitist and that's i mean we've talked about it before but yeah i i didn't really agree with it i mean the one i guess my one takeaway from this that i actually did appreciate is the fact that when there is chaos continue doing what you do it you know create things add value and that will show through right and you might get fired but if you are truly good at what you do and you are good at adding value then it's not going to be hard for you to pick up somewhere else and go do that somewhere else as well right but what about his point, though, that he says that if during all this commotion someone comes up to you to create something that you think is just stupid,

that you should just smile and nod and go along with it until they walk away and then just ignore it. And if you are a leader, you should tell your team to ignore it to ignore all that nonsense too like that's pushing it right i mean i guess it depends on what kind of position of power you're in like that's and who the position is that's making the stupid comment right you know the comment that you feel is stupid i i there's so many

yeah i when i read that i was like i don't even know where to go with this because I mean, obviously if somebody comes and asks you to do something that you just know you shouldn't be doing, yeah, then it's pretty common sense. Right. But I don't listen. We're only going to skim a couple of pennies for every transaction.

Yep. I saw this in Superman. This works great. Like, you know, the feds are coming tomorrow if they ask about me then i tell them you never heard of me i never worked here you don't know what's going on and who's that you know call me afterwards but yeah i don't know i don't really feel great about

what that last part was yeah i'm sure we've all worked places that have done things but i've seen like you know credit cards stored at the clear or cbvs in the database or you know lots of crappy stuff but it's not really organizational chaos but there's definitely been times when there's been an incentive to do you know to cut a corner or do things the wrong way or whatever and you just got to kind of stay on your ground and if you get fired then uh that place sucked anyway well i kind of like the approach that whenever whenever i've been in situations kind of like that, and it may not be because of organizational chaos, but just someone comes up to you with an idea. And generally, what I think that you're really describing there is someone is going,

they're coming to you with this idea that you might think is stupid, because really what's happening is they're trying to sub with this idea that you might think is stupid because really what's happening is they're trying to subvert the process. In that situation, I'm just like, yeah, we'll put a ticket in and it can get prioritized like everything else.

If it makes it, it makes it. If it doesn't, I might not tell them that part. A good example is breaking the chain basically you have you know either your buddy or someone from uh you know under you know someone outside your tree kind of trying to slip little favors in yeah and that's kind of stuff that happens with the organizational chaos yeah definitely yeah all the time especially it's it's rough when i'm like the things they want aren't stupid. Yeah, I mean, it's both ways, right? Great point.

Yeah. Hey, we know this thing that we'll make the company an extra 20% in revenue. Yeah, dude. If I do that, I'm going to get shot on site. So I can't do that right now. Wait, if you make 20% more in revenue for the company, you're going to get shot on site? If you work on something that wasn't approved. I'll tell you what. If you do know of something that can make an extra 20%, you just go ahead and do it.

Oh, dude, that is not the case. No. And you know it. You get fired. There are absolutely organizations that, yeah, their priorities aren't necessarily tied to revenue, strangely enough. Yeah. Yeah. Sadly.

Yeah. All right. Well, that will conclude that take on how to be a programmer by Robert L. Reed. So, that leads us into

Alan's favorite portion of the show. This is the tip of the week. That's right. So, I mentioned that for any of the show, this is the tip of the week. That's right. So, I mentioned that for any of the self-taught developers

out there, I would have a tip for you. And so, I got two for you. One is, and there will be links to both of these in the show notes.

But the first one is this really great course on Pluralsight that a friend of ours pointed us to on React with Relay and GraphQL and Flux.

I'm the one who pointed us to that, aren't I? No. Really? No, it was John. Oh, it was john yeah wow look who look who tried to take credit wow wow i give it credit to john and i take it the way apparently but uh you know i mean it's a really great a great uh course you know again you know you have

to be willing to um watch the course on something javascript related so if you know, again, you know, you have to be willing to, um, watch the course on something JavaScript related. So if, you know, if that's not your forte, then, you know, maybe you're not interested. But, uh, one of the things that I did like about it is just the speaker himself, like the presenter himself, he does a great job like of, of presenting the material through this course. Um, so it was just, it was a well put together course. I think you'd really like it. We'll have a link to that one in the show notes, but then also wanted to give a link to,

and this one came up in the Slack channel, actually a link to a specific video and it came up, but to a YouTube video, but the link that we're going to have in our show notes is for the overall contributor, which is the MIT OpenCourseWare. And there's just some great content. And it's one of those sources of content that you just kind of forget about every now and then.

And then someone will be like, oh, well, hey, I like this video. And you're like, oh, yeah, I forgot they were doing that. And then you go back and you look through it, and there's just this treasure of great content out there so we'll have those two links uh out there for you to take a look at yeah and on the uh on his first one the react one the guy's use of vi or vim or whatever you want to call it, it makes you really want to learn that IDE because that dude just breezes through it. Wait a minute. Wait a minute.

No. I will not ever support that statement that you just said. VI is not an IDE. Oh, no, you're right. It's a text editor. It's a text editor. But, man, that guy is so good in it. It's kind of ridiculous to watch him just go through it.

But, yeah, I totally agree. It was an excellent course. All right. So my tip of the week is open row set. So this is SQL server specific. If you ever wanted to say, create a table and you wanted to do it by executing a stored proc. So like think of something in the case where like if you do a select into new table from existing table, right? That's something that you do a lot in SQL Server, especially if you're used to transforming data or moving data around. Well, it's kind of frustrating because you can't do like an exec into from a stored proc to build a table on the fly. What you can do is you could do a select into my new table from open row set. So you could use open row set to open a connection to that same server and to that same database. You have to pass in the connection type string and then the actual

connection string itself, but then you could just exact the stored product that you want and the results of that would get inserted into a new table so if you ever have the need to generate a table based off of stored procedures results or or even do any number of other things you can use open row set as kind of your way to trick sql server into doing what you want and we will have a snippet example up on the show notes. So if you want to see how that's done, just click the link in the show notes here or in the notes here and go up to the site and take a look. Yep.

And now it's time for my tip. So I don't know. Hold on real quick, real quick. Because if I remember right too, that's also the only way that you can can make sure I use my wording correctly. It's the only way that you can bulk update is through open roles. Rosa, like,

or, um, you're talking about like a BCP. No, like if you wanted to do, if you wanted to do, maybe bulk update is the wrong way to phrase that. If you wanted to do like a certain count of the time,

like, you know, a count of the time, like, you know, a thousand at a time, like you could bulk insert. I don't know, but I'm pretty sure that like it, but, but it has,

it's file specific though. Um, it has to be talking about bulk copy then. Like, like if you wanted to, okay, let's say you had a million records, right?

And you wanted to bulk insert that, then you can easily do an insert statement and say like, well, not easily. But you could do that over whatever, say a thousand at a time if you wanted to do that. For OpenRowSet, you can do the similar thing but at an update because you can't do updates in in bulk like that hmm i don't know or batch might be a better way to describe what i'm trying to say yeah i don't know i'd have to look into that so maybe that'll be our next tip we'll have to look it up cool all right so uh yeah my tip is i don't remember if we mentioned this last time or not but it's code wars which is a awesome site for learning the program and solving the kind of problems that you typically see in like interviews and we actually have a clan on there coding blocks

and carl from ms dev show is currently at the top of that list so you guys should join and knock him down a peg sorry carl oh by the way i didn't find this out until after i've been in there playing around if you do it in the order that it presents them to you you won't get points that fast you actually have to go over the more difficult ones and that's why i spent my time just kind of going step by step yeah don't do that get the ones that'll get you some points if you want points i haven't tried this one it's kind of fun it's i had more fun than i thought i would really yeah and our and our clan is coding space blocks right yep yep so if you want to join our little group of people

so that you can compete freely with us coding space blocks for your clan yeah i solved like i think like three or four problems and i realized i hadn't gone up a level i'm like what the heck it's because i was doing all easier problems same thing they were they were interesting problems though they were all you know kind of fun not too hard but they were definitely still head scratchers you know you know what i liked about it joe was the fact that you cannot see the solutions beforehand unless you kind of want to forfeit the problem. So you have to code up what your solution is,

and after you do, you get to see everybody's, and you actually get to see the top-rated ones that people voted up, right? Now, one thing I will caution against, because this is fun this is like competitive stack overflow sort of sort of it's more just interesting challenges to do but the thing that is both kind of cool and slightly annoying is like i think i commented on ones i was like dude there's no type checking in this at all he's like dude this is a this is just a

little thing to try and get this solution like this is definitely not production ready code so that's one thing to keep in mind you can't use like flow js in your uh right no but it is something to keep in mind right like some of the solutions you see it's not like you want to copy and paste these things and stick it in your production code because these people are little. In some cases, you're just trying to do the most clever thing ever, even though the performance is going to be, you know, quadratic, quadratic. Right. It could just be terrible. So.

Right. So. So it's just. I think you're just describing exponential. Yeah. Something like that. But it's just it's just i don't know it's fun to kind of see to do the challenges and also see the other solutions that people come up with so it's definitely worth a spin yeah a good example is um the one that i did uh which was to basically

convert a string to morse code and they actually provide the dictionary that you know you give it a character you get the morse code back and you kind of had to do something special with the spaces. But it wasn't too hard at all, and it was just kind of fun, and I felt like a better program afterwards. That's cool. All right. All right. Well, like I said, that wraps up this show on how to be a programmer.

So we hope you know now. And you can tell your boss, I now know how to be an advanced programmer. Yeah, that's it. So that'll help you in your negotiations. That's right. So we'll have all the show notes ready for you. But like always,

be sure to subscribe to us on iTunes, Stitcher, and more using your favorite podcast app. And if you haven't already, be sure to leave us a review on iTunes or Stitcher or wherever more using your favorite podcast app. And if you haven't already, be sure to leave us a review on iTunes or Stitcher or wherever you happen to find our podcast. And if you want to head over to www.codingblocks.net slash review to find easy links to either of those, use that too. Yeah, we totally didn't beg this episode.

What's that about? I know, I forgot. I feel like we should beg now. Please, please, please, please, please go leave us a review. That would be amazing. All right, beg over, end beg. All right, also visit us at codingblocks.net where you can find all our show notes, examples, discussions, and more. And visit us at, oh, dang, I did that again.

How do I not know this by now and then if you haven't visited us at codingblocks.net let's go ahead and visit us at codingblocks.net hey you know what we haven't done we haven't begged for reviews are we going backwards now yes we are

you're listening to episode one you're listening to episode one. You're listening to Joe Struggle. So send us an email at comments at CodingBlocks and follow us on Twitter. And really, if you just go to CodingBlocks.net, we have links to Twitter, to Facebook.

We should have one to Slack. That's probably a good idea. And I mean, Code Wars too. And just, yeah, we're everywhere. So however you want to communicate, we are probably there and we want to hear from you. Hey, and if, too. And just, yeah, we're everywhere. So, however you want to communicate, we are probably there. And we want to hear from you. Hey, and if you find somewhere where we're not that you think we should be, let us know.

Drop us a line. Yep. Email us or add us. Oh. What? Man, tweet us jokes, too. Rebecca Marquis just tweeted us one. And it was awesome.

And we forgot to read it. But, yeah, send us jokes. We love it. Hey, wait. What's this joke? Read it. We're not done yet.'re not done i'm looking i think i read it the other day and it was pretty good hold on where you go oh it was something about meat right oh yeah gosh i know the one you're talking about i gotta i gotta nobody's gonna find it here we go i have it i found it yeah all right i went to the butch's and I bet him 50 pounds that he couldn't reach the meat off the top shelf. He said, no, the stakes are way too high.

Love it. Thank you, Rebecca. That's amazing. Yeah, that was a great. I also liked the retweet that Joe did. And I felt like this was, I guess it was Mike Ash that originally tweeted it. But I guess I think I really liked it a little bit more because it had Joe's name in it. Joe's code has 20 bugs.

Oh, yeah. If Joe fixes two bugs per hour for eight hours, how many bugs does Joe's code now have? 40. Answer, 27. So how do they know? Is somebody spying on me? It's so true. The NSA.

We got them after us already. I loved that one. All right. That's it. Good night. © transcript Emily Beynon