In this podcast episode, Krish delves into the critical aspect of efficiency in software development. He underscores the importance of promptly reflecting code changes and minimizing time wastage during the development process. Through examples and scenarios, Krish highlights the significance of addressing challenges such as server bouncing and lengthy testing procedures, proposing various solutions to enhance productivity. He explores different testing strategies, stressing the necessity of frequent testing for robust code development. Additionally, Krish discusses platform-specific considerations and emphasizes the significance of effective time management to maximize productivity. Concluding with gratitude to the listeners, he expresses optimism for improvement in future episodes.
Summary
Efficiency in Development:
- Krish discusses the concept of efficiency in software development, particularly focusing on the quick reflection of code changes and minimizing the time wasted during development processes.
Examples and Scenarios:
- Krish provides examples of scenarios where efficiency in development is crucial, such as bug fixing and feature development.
Challenges and Solutions:
- Krish discusses challenges faced in development, such as the need for server bouncing and time-consuming testing processes, and suggests various solutions to mitigate these challenges.
Testing Strategies:
- Krish explores different testing strategies, including unit tests, functional tests, and manual testing, highlighting the importance of frequent testing.
Platform-Specific Considerations:
- Krish discusses platform-specific considerations for development, such as hot deployment support and different testing approaches for various programming languages or frameworks.
Time Management and Productivity:
- Krish emphasizes the importance of time management and productivity in development, discussing how small inefficiencies can accumulate and impact overall productivity.
Podcast
Check out on Spotify.
Transcript
0:00
Hello Hey, this is Krish.Hope you're doing well and welcome to Snowpal's podcast.If you're a teacher or a student, whether you're in high school or college, you want to consider signing up on snowpal.com. We have a service that's targeted specifically at you and has a bunch of features that will help you be very organized and improve your grades ultimately.
0:26
And in this podcast, I want to talk about efficiency in development.That's a broad 3 words it covers, it can potentially cover a number of areas. So let me be very specific.When you're doing development, you you're, whether you're building new features or fixing bugs or whatever it is that you're doing, when you make a change, a code change, you want to see that be reflected as quickly as possible.
0:53
And let me explain what I mean by that more specifically, let's say somebody reports a bug in production, it's a UI bug, or they report an API bug in production, or some bug, right?For for what it's worth, that's one scenario.Or you're building a new feature, it's going to take you several days to build it, and you've broken that down into smaller milestones.
1:14
So every few hours you know what you want to be able to accomplish.These are two pretty different examples, but the the underlying process in terms of efficiency of development that I want to talk about is no different between these two.And the aspect of developing efficiency I'm I'm trying to talk about here is when you make a code change, you don't want to have to bounce your server to see that code change be reflected, right?
1:44
So essentially a hot deployment. So you make a code change and then it boom, it shows up immediately, whether it's on the browser, on the mobile app, or wherever it is that you want to be able to verify the correctness of that change.Now if you have to bounce your server, it's going to take your time, right?
2:03
And it depends on which server it is and how your dev environment is set up. So typically in compiled platforms like Java, it tends to take a little bit more.But again, if you're making an API change in a Java, in a Java app, you don't have to, you know you're not hopefully right?
2:23
And I've seen some folks do this, but it's it's super inefficient. So hopefully you're not making the code change and deploying it to a server to test this whole thing, right.You Obviously you're only going to do it when you get to integration testing or when you verify that you change actually works.But sometimes I see people do that for every 10 lines of code they write.
2:42
They go through the whole process and it takes like a good 4 to 5 minutes.And if you did that like 10 times a day and you've lost 15 minutes already.But that probably is not the more common scenario, gladly, right?But the the scenario that is more common and in my mind it it shouldn't be, is even though you're not deploying it to the server, you make a code change.
3:05
I'm taking Java as an example here. It's probably applicable to C# and other things as well.You make a code change, it's an API change, so no UI repercussions.You you have your you.Let's say you have AUI app running on your machine as well, right?
3:22
Let's say again the devil is in the detail. So as I'm as I make a statement, I think about all the variations that are possible and I'm and I try to rethink, but I think that's all right.Hopefully I'll get to a point in my podcasting experience where I take a really small topic and only stick to that topic.
3:41
Apologies for that digression. So back to what I was trying to say, you made an API change and then you're like, OK, I need to now restart my server locally, right?API server locally to see that change.Now I go back to the UI and I hit that page and I can test the change.
3:58
That's all right because you're not deploying, so it's not taking a good 5 minutes, but it's still taking like probably 30 or 60 seconds, maybe more, depending on your app, your machine, and a combination of other factors.That's still a minutes worth of time completely wasted, right where you have to be twiddling your thumbs.
4:13
So the next step is what you do is locate.Let me not even bother with the UI, because it's not a UI change.Why do I have to test my API change through a UI page?So let me just let me write unit test, right J.Units or whatever unit test you want to be able to write. Behavior driven, test driven, all of those different kinds of tests depending on what your test suite looks like.
4:35
So you could write the test, but if you know, testing is great, right?We all have to do it.The more automated it is, the less headache. So there's no two ways about that, right?It'll be like stating the obvious, but here is the truth.Testing is expensive.
4:51
It costs a lot of money, right?I mean, human resources code are the most expensive.The machine clearly doesn't cost that much.But what I mean is it takes time to write these tests and I I believe it.You know, depending on your traversal and paths and the complexity of your code, I think it wouldn't be inaccurate to say that for every line of actual code that is executed, you may have to write like three times as many lines of test code because you want to catch all the permutations and combinations.
5:19
Now if you have a very robust test framework and you have the time and the bandwidth and and the dollars obviously to support it, then it's awesome. In my career I've worked for, worked in teams that I've had that kind of luxury of being able to implement all of those tests that they desire to.
5:36
So your code coverage is pretty high.But I have to say that it's not always been the case and it's actually been the minority of the cases.Most of the time you have a test framework or a test feed, but it's it's the code coverage is pretty low, right, Because you're trying to do a lot of things in a short span of time.
5:54
So you don't have the bandwidth to to add, you know, include all those tests.Now whether it's a good idea or not, that's a discussion.That's an item for a different discussion altogether.Let me get back here in my assumption here.Let's say you don't have a whole lot of tests and or you don't have time to write a lot of these tests.
6:13
So what do you do in that case?So even if you wanted to not have a formal test suite with all these unit and functional tests, even if you wrote like 5 lines of unit tests just to, you know, verify the few lines of code that you just wrote, it does take a decent amount of time, right?
6:32
So you want to have another alternative, and I've resorted to a few different options.Sometimes I write curl scripts to to which serve as a poor man's version of of unit test.They're not unit test, but they sort of play the role of a functional test, but it it serves multiple purposes.
6:49
I can have that documented and I can give that to the UI team.I can also use that for testing my code as well if I'm making API changes in this example, but again, I've digressed quite a bit, as always coming back to restarting and bouncing your servers when you don't have to.
7:06
If if your platform supports hot deployment then great, but if it does not support hot deployment, here is what I think you probably need to do.You want to minimize the number of times you have to restart your server. So you have to have some kind of test that you have to write, and what that is changes dramatically from platform to platform.
7:28
When I'm doing Java development, I have these standalone tests, even if they don't become part of a test suite or a framework.I have code code and code.Code that serves as a test so I can write that, which is essentially A standalone Java app, right?
7:43
So you write that quickly and then you don't have to worry about hot deployment or bouncing your server.And you can test these 10 lines of code that you wrote.And I'm the kind of person who writes 5 lines or 10 lines, makes sure that that works.Whatever the process I follow for testing, whether it's curl or actually unit tests or functional tests, or actually let having the UI run to verify something.
8:05
Whatever it be the case, I do make sure that I test every so often, and that so often is every 15 minutes or every 1012 lines of code.Sometimes I'm writing like 50 or 80 lines of code.I'm testing it afterwards because all of that is atomic and it's part of one small thing that I'm doing.
8:23
But you know, I I it should suffice to say that I tried to test as often as possible because you don't write like 500 lines of code and then test.Because then if something is not working and trust me, something wouldn't be working if you wrote 500 lines without testing, you wouldn't know which aspect of the code to go back and fix, and then you're going to spend more time trying to figure out whether it's the 1st 50 lines, the middle 70 lines, or the end 25 lines, right?
8:47
That's time wasted. So right, fewer lines of code and make sure they work.And then you move to the next set of writing the next set of lines.Now the reason I mentioned the platform and its support for hot deployment plays a role is in the case of let's say when I'm writing Ruby code for instance, right?
9:04
Ruby server side code like using code Ruby I I can just go to you know I use a few different gems.I use one called tux as well. On the Sinatra side with Rails you can use the rails console. So what you can do is you just go there execute your code literally in the console and if it works then you transfer and put that code over to your code base.
9:27
So you it is not a test, but you're actually writing that code and running it in your console before you make that those lines part of your code base.That's extremely quick, right?That's very, very quick.But the other times when I have to bounce the server and I don't need to, there are a few possibilities depending on again the platform that you're using.
9:49
I if I'm writing Node code versus Ruby versus Java versus whatever that you know, we find a different way to make that work so you don't have to bounce the server.But I've noticed that if it takes me like, say six or five to six seconds to restart the API server when I'm writing APIs, that's five seconds every 15 minutes or so, right?
10:12
And if it's assuming I'm testing every 15 minutes and then it's not just once, you may have written something and then it doesn't work, so you just kill and then restart. So you may have done it two times within the 15 minutes, but let's say you do it twice. In 15 minutes, that's 10 seconds.
10:29
In a in a minute, I'm sorry, in an hour that's like about 6040 seconds, about a minute.These numbers are small, but what I'm saying is at the end of the day, you would have spent like about 2025 minutes just restarting your service.And you know, if it's 2025 minutes, let's make a round Number.
10:47
Let's say it's half an hour and an 8 hour day, that's what that's, you know if you break 8 hours into 16, that's 116th of your day essentially, right?So 116th of your day essentially went and you bouncing servers and not doing anything productive because in those five or six seconds you really cannot do anything else.
11:06
So you're just waiting for that to start up and it's it can become very tedious and frustrating. So I make sure that as part of what I end up doing, you know, there are a few things you want to iron out on day one or day two, and you're getting started doing something new, whether it's for yourself or for a client.Just make sure that your dev efficiency, just in the context efficiency just in the context of bouncing and restarting servers and whatnot and testing the few lines of code that you write is is not eating up much time because you know it's it's like death by 1000 cuts. 5 seconds is not 5 seconds, and it's you do it 10 times, it's 50 seconds, 100 times it's 500 seconds.
11:42
And then there's a big number because I've seen places where sometimes to run your G units, you know, if you're a Java shop and you have a ton of spring beans and hibernate activity happening, depending on how you've structured, again, there's a bit of architecture, quite a bit of architecture, not just in terms of the overall functioning of the app in production, but also architecture from a dev efficiency standpoint.
12:07
It's possible that you're running this unit test might load a number of these beams and it's actually a three, a good 3 minutes before you can test your 10 lines of code.Now take 3 minutes.And if you did that like 20 times a day, that's one hour a day.And sometimes it's a lot more that's entirely wasted, right?
12:24
That's entirely wasted time. So we want to make sure we use that time more proactively and for some other things.Hopefully that made some sense.And as I improve my podcasting, hopefully things make a lot more sense.
12:41
Thanks for listening.
Top comments (0)