Senior Code Review Buddy

Пікірлер

@RoyRope 3 күн бұрын

Nice suggestion, will add it to my reading list.

@cariyaputta 5 күн бұрын

Just found your channel. Full of helpful and practical videos.

@SeniorCodeReviewBuddy 5 күн бұрын

Thanks! Glad you like it

@MrDigDug 13 күн бұрын

Really appreciated this video! I was fortunate enough to read this at a book club at my first job out of university and it's made a big impact on my perspective and my career. The most productive environments I've experienced have always had extremely effective communication.

@SeniorCodeReviewBuddy 13 күн бұрын

Glad to hear you liked it! And now that I think about it, I'd also agree that the most effective teams I've been on have been ones that have really effective communication. And when communication starts to fall, productivity hasn't usually been far behind.

@JesseDoherty Ай бұрын

I'm still going to be annoyed whenever my build fails while I'm actively working on some code and just haven't gotten around to using a variable I introduced yet!

@SeniorCodeReviewBuddy Ай бұрын

I guess that's fair, unused variables aren't quite as bad when you're actively working on the code. It's more when they get merged into the main branch they become a problem :)

@xuntari 2 ай бұрын

This sounds great! Exactly what I've been missing while trying to learn general programming concepts online. Every example is simplified a lot and doesn't display the code in an actual environment, which makes it easy to read, but hard to get a good idea of how I can apply it in my code. Looking forward to this!

@SeniorCodeReviewBuddy 2 ай бұрын

Glad to hear it!

@sghosh4223 2 ай бұрын

We develop software for clients. When a 1 hr task takes 5 hrs and the client is paying only for 2 hrs, we know it is time. At that time, we propose that development could be faster if we are given 20 hrs to clean up the tangle. If we do not get the time then the developer can spend some non paid hours today to clean the code but finish future work in time or spend 5 hrs on future job but get paid for 1 hr and you know what happens then (accept the cut or change the company)

@SeniorCodeReviewBuddy 2 ай бұрын

I've not worked in a position like that before (writing code for clients), interesting to hear your thoughts on that. It sounds like the cost benefit becomes a lot clearer (at least in retrospect when you know how much time it took and how much you billed for). Thanks for sharing!

@xuntari 2 ай бұрын

Great to see the thought process of an experienced developer. I learned a lot, thank you! 😄

@SeniorCodeReviewBuddy 2 ай бұрын

Glad to hear it :)

@JesseDoherty 2 ай бұрын

How does this relate to black box vs clear box testing?

@SeniorCodeReviewBuddy 2 ай бұрын

Hmm, good question. When I think about black box and clear box testing, I usually think about them applying to an application (or component) that a user would interact with. So, something bigger than just a function. Although anyone that calls a function could be referred to as a user in that sense, so I guess really there isn't a different other than the naming. Just the I'd usually use black box to cover larger testing surfaces.

@vogelkop27 3 ай бұрын

Thanks for this video!

@SeniorCodeReviewBuddy 3 ай бұрын

No problem :) Thanks for watching

@JesseDoherty 3 ай бұрын

Are you going to give a demo of this podcast app ever?

@SeniorCodeReviewBuddy 3 ай бұрын

Hmm, good question. While I would like to share the code in the future, I'm not sure a demo would be interesting. It's just a command line script that moves some audio files while doing a bit of processing to them, not really much to look at our show at any point. But I'll think and see if I can figure out some kind of demo.

@user-gi3oc1kv5m 3 ай бұрын

Hello! I think your knowledge and expertise as a senior developer will definitely add value to what I think is missing in development education on KZfaq today (especially since it's flooded with a lot of newbies who are learning from other newbies - which isn't bad but isn't valuable either for those who need the next level, ya know?). I've subscribed and look forward to seeing your content. Thank you, I appreciate your time!

@SeniorCodeReviewBuddy 3 ай бұрын

Thanks for the feedback! Hopefully you enjoy the future videos and find them useful. And please let me know if there are any particular topics you'd be interested to hear me cover.

@JesseDoherty 3 ай бұрын

How long should I be spending on a technical doc? Do you have any guidelines for different scenarios?

@SeniorCodeReviewBuddy 3 ай бұрын

Hmm, that's a good questions. I don't know if I really have any solid guideline other than spend enough time that you think you've identified and addressed any major concerns or issues. You don't need to know exactly how to solve things in terms of what the code will look like, but you should know the patterns. I think the few couple of tech docs I've seen most devs write probably only take 1-2 days of focused work, because those initial projects tend to be smaller scoped. I'd probably say that for most devs, they should probably aim to not spend more than 2 days on their first tech docs, because they'll still be learning the process and feedback from peers will probably be more helpful in growing themselves and the doc than spending more time on it.

@iLoveAppl3947 4 ай бұрын

i don't know much about this i'm learning Swift as my first programming language i'm on month 5 since i started and i found out that plenty of people are over engineering and over testing the code resulting in a massive mess ending up in more protocols added...instead of keeping things simple as they were designed. I'm a beginner and i can spot so many devs coming from the other platforms trying to enforce SOLID principles and MVVM architecture for SwiftUI framework that was designed to be Model-View or Model-View and Controller... Apple documentation is crystal clear on how to build the app yet they choose to ignore best practices. Why is that? For me this looks toxic is just like moving to a country as a foreigner and ignoring the laws just because i have my own rules and everyone should obey them

@SeniorCodeReviewBuddy 4 ай бұрын

Interesting. I've not worked with Swift before so I don't really have an experience with it, but I suspect you might be right that developers are sticking with known patterns from other languages because that is what they are used to. Depending on their exposure to Swift documents, they might not realize they aren't going the Apple way. Have you engaged any developers you've seen doing these patterns to see why they made these choices?

@Michallote 4 ай бұрын

At the second example I find that your naming is a bit redundant. You already have a if not match_found: statement. Why do you need to name your variables NO_MATCH_FOUND_EXCEPTION_MESSAGE... or nomatchfounduserinput .... here are some recommendations for you and other viewers I hope you find these helpful: 1.- this message should not be im capital letters as it is not a constant. (Values will only be assigned if match_found is false). 2.- your function naming is not what in python usually is done. CamelCasing is reserved for classes and snake_case for variables and functions. UPPERCASING is just for constants at the top of the file, beware those should never ever be modified at runtime. 3.- remove all the redundancy in your naming conventions. Your variables could simply look like: prompt = "No match .... user_input = input(prompt) Communicate intent, dont describe with as many as 7 words what exactly is it that variable represent. 4.- great job on renaming the exception it does help. However again it didnt fail at loading did it? The file is missing or the input is wrong. A data loading error happens when files exist but are corrupted and those are different cases. In this case a better and more helpful error for a user is InputError or ValueError, FileNotFound error. All of the above are better suited for this purpose, I hope its clear why.

@JesseDoherty 4 ай бұрын

Did you ever write a tech doc that you were really happy to have rejected?

@SeniorCodeReviewBuddy 4 ай бұрын

Good question. While I wasn't the author of it, there was a tech doc written by one of teams I was leading that was rejected that I think we were happy about in the end. It was relating to how we were going to store files getting passed around as attachments, there was already a basic system in place but when we added a new attachment type it seemed like a good time to design a new system for it. After spending some time on the document, we realized that because of how things had been setup before it would have been a fairly complex eng effort to implement a new system that would follow the new best practices (probably 3 months of work for 1 person). The alternative was not as pretty, but it wasn't much worse and would only take about 2 eng days of work (and we'd be more confident in it's stability since it was just changing the current system, not bringing up something from scratch). With this information, it was clear we couldn't justify the investment for this better but more expensive solution, and went with the much more basic approach for just adding another attachment type to the old system.

@Globokol 4 ай бұрын

Thank you very much Keep up the good work!

@SeniorCodeReviewBuddy 4 ай бұрын

Thanks for the kind words :D

@Globokol 4 ай бұрын

@@SeniorCodeReviewBuddy No problem and i think you deserve more subs and viewers, Because your videos are amazing!

@chrisdiehl8452 4 ай бұрын

Read ability, or performance. Choose your poison.

@SeniorCodeReviewBuddy 4 ай бұрын

While there are always tradeoff, I think you often can have readable code that has good performance. Compilers and interpreter can usually be quite smart and help optimize the code. I personally think the times to pick performance at the cost of readable are fairly small, and only worth pursuing when the code performance issues are clearly shown in metrics, and the less readable code can be clearly shown to be more efficient (in whatever metric is being optimized). But I acknowledge I might be a bit bias in this direction, because I've probably seen too many cases were someone was picking performance when there wasn't a need and the decrease in code readability was a long term pain.

@chrisdiehl8452 4 ай бұрын

@@SeniorCodeReviewBuddy It is a fallacy to think that compilers/interpreters change and optimize code beyond what the programmer has created. The old saying, "garbage in, garbage out" still pertains. Known people that said that same thing just to be proven wrong in the end. Not once in all my 30+ years as a programmer has anyone said, "Let's make the code readable.". All the time it is,"Our code base it performing terrible in the real world. Can you solve the problem, and optimize it?".

@SeniorCodeReviewBuddy 4 ай бұрын

@@chrisdiehl8452 I think we'll just have to disagree on this point then :) I've heard people say "Let's make this code readable" plenty of times, but it's usually been part of a larger discussion where some chunk of code has gotten very messy and when bugs are are found it can extremely challenging and time consuming to fix. I've generally found that (usually) code that is hard to read is hard to optimize as it's tricky to understand what is going on and how to fix things.

@chrisdiehl8452 4 ай бұрын

@@SeniorCodeReviewBuddyDefinitely disagree. Well if it is optimized than for the "play" programmers it is hard to read, and doesn't need to be re-coded anyway. You know that saying, "If it works, don't change it.". Maybe in academic or open source surroundings readability is above functional, but not in the real world. There are also a lot of other senior programmers (Not just me.) on KZfaq saying the same thing I am.

@allthingsreversed 4 ай бұрын

I wanted to comment about the differences between first and last version of the function but @Winnetou17 already did that. For me the problem is that the original function did check for two cases. Player being dead and finishing the game. I would actually check if player still HAS health and is in the final room with the golden key. So basically what the final version of the function did. Coz in other case, what if I'm in the final room with the key but lost all the health? Did I won or am I dead?

@SeniorCodeReviewBuddy 4 ай бұрын

Good question about being in the final room with the key, but no health 🤔 This makes me think that IsGameOver should probably be split into a won and lost subfunction, since (I imagine), that the program probably wants to do different stuff if the user died vs. won, and that info isn't really surfaced right now. Given that this is just a made up example, I'm going to say that I like the idea of a player being able to win if they get the key to the final room, even if they don't survive 😁 A last minute victory for their world maybe?

@allthingsreversed 4 ай бұрын

@@SeniorCodeReviewBuddyI bet that bug/issue would be something speed runners would use to beat the game faster ;)

@Winnetou17 4 ай бұрын

Funnily, in the first example, refactoring it introduced a bug: if the player health is 0 it should return true, not false. At least based on what it returned in the first version. It's ironic that the more readable code is looked over, the bug is somehow not obvious, even though, at least partially, that's the idea of that readability refactor.

@Winnetou17 4 ай бұрын

If Chris is reading this, the video description also seems to have a typo "Code readable is extremely input, [...]" 😅 Since I might seem negative with all these complaints, I do want to say that the video idea and the examples were pretty good. Not too trivial / unreal-like, neither too complex or hard to follow.

@SeniorCodeReviewBuddy 4 ай бұрын

I am reading these :) And thanks for pointing out those two errors. I was able to the description typo without much trouble, but there isn't much I can do about that error in example 1. I had written the right return value in my copy of the improved code, but I didn't explicitly mention it in the script so I didn't catch that error. I'd say that's probably a great example of why it's really helpful to have unit tests, it (hopefully) would have been easier to catch and see that issue there. @Winnetou17, thanks for the comments and feedback!

@Winnetou17 4 ай бұрын

@@SeniorCodeReviewBuddy Thank you as well, keep it up!

@vogelkop27 4 ай бұрын

This was informative, thank you for making this video. I will keep this in mind and make sure to not clutter my codes

@SeniorCodeReviewBuddy 4 ай бұрын

Thanks for watching and glad you found it informative! :D

@redtree9193 4 ай бұрын

Great Video, thank you!

@SeniorCodeReviewBuddy 4 ай бұрын

Thanks for the feedback :D

@shikutoai 4 ай бұрын

Food for thought: during your video editing process, consider throwing a “de-esser” on your speech recordings. Your sibilants are really sharp. Don’t slam the de-esser so hard that you give yourself a lisp, just take some of the edge off of the “s-whistle.”

@SeniorCodeReviewBuddy 4 ай бұрын

Thanks for idea. I've not heard of a de-esser before so I'll look into it. The audio recording portion has been more complex than I'd originally expected and I've been learning a lot.

@GOZES 4 ай бұрын

Great video. One suggestion for next time. Can you make the code a bit bigger? It a bit hard to read when watching on mobile :)

@SeniorCodeReviewBuddy 4 ай бұрын

Thanks for watching and for the comment! And that's a good idea, I hadn't really thought there would be many people watching from mobile so I hadn't thought about the size. But I can probably make it bigger in the future which might make things easier for everyone

@KX36 5 ай бұрын

bonzi buddy does all my code reviews.

@superhiman99 5 ай бұрын

Great video. Very helpful

@SeniorCodeReviewBuddy 5 ай бұрын

Thanks and glad to hear it :D

@vadimljagatsov8190 5 ай бұрын

Flatter background, same quality content, maybe a dedicated mic at some point 😊

@SeniorCodeReviewBuddy 5 ай бұрын

Thanks! And yup, I'm working to improve the audio quality :)

@alkbolk 5 ай бұрын

Very informative and clearly explained. You could try to speak a bit louder and less softly when talking to the camera, to make the video feel more like an informative presentation for a crowd.

@SeniorCodeReviewBuddy 5 ай бұрын

Thanks for the comment and thanks for watching! And yup, I'm still working around with the audio to try and make the part clearer. Hopefully it'll be better as I go :)

@ronin2963 5 ай бұрын

You sound fake and over medicated. Drink some caffeine before you video yourself and lower your voice a little.

@redtree9193 5 ай бұрын

Great video and very informative. Excited to see your channel grow :)

@SeniorCodeReviewBuddy 5 ай бұрын

Thanks! Glad to hear it :D

@jacktheonion5052 5 ай бұрын

You are pretty quiet in this video, with maxed-out audio you are still kind of hard to hear.

@SeniorCodeReviewBuddy 5 ай бұрын

Thanks for the note. I had noticed that when editing and thought I'd increased it enough, but I guess it wasn't quite fixed like I'd thought. I'll make sure to pay close attention for it as I figure out my process.

Ең жақсы KZfaq

Пікірлер