The growth stages of a programmer - FunFunFunction #6

Key Takeaways

today we are going to explore the growth stages of a program a couple of weeks ago I made a video that turned out to be one of the most controversial ones I've made so far the video was called straight line code over functions where I stress that you should prefer simple inline code over function extraction that video got a lot of responses like this one thanks for the rest of the videos but I have to respectfully disagree with with this one testability composability and reusability are completely lost when you don't decompose into smaller units I plead with you to take this video down before my co-workers see it and continue writing huge monolithic functions that do 50 different things M Costello This is a fantastic comment you are right that some people should not watch that video because they might get the wrong idea and that depends on where they are in their growth as programmers and that is what I would like us to explore today today's video is a complete and utter rip up of a uh core answer by a fantastic former colleague of mine Blick I have linked the answer in the episode description Blick talks about three phases in the life of a developer the novice hacker the philosophy abstractor and the wise hacker Blick describes the novice hacker like this what this code it sure is ugly and I don't quite understand why it works but here it is and that is me and everyone when they are starting out as programmers you are copy pasting things all over the Internet and you don't quite understand all of it but it works and you're getting done as you grow older as a programmer you grow more and more into the second face the philosophy abstractor Blick describes the philosophy abstractor like this well this code works for now but if I move this part into a factory and create an interface for these methods it will also support all of these future edge cases that I can think of as a professional programmer most of your time would almost all of your time is spent understanding other people's code and I have done this a lot I have recently had the interesting experience of taking over code written by somebody who isn't a programmer by trade I've never done that before and it was very eye openening to me the person in question knows some programming and has written a complete piece of software but he's not a programmer by trade he's actually a doctor I expect expected his code to be messy and that I would have to spend a lot of time to make sense of it but in fact it was quite the opposite understanding his code base was actually much easier than most of the code bases that I encounter at work H and his code is messy there's a duplication Galore and there's spelling errors all over the place but that doesn't matter because his code is straightforward his code consistently takes the simplest possible route to solve a problem and that makes it really easy to understand and follow even though it is the very opposite of elegant in contrast I've uh many times taken over software by developers who have a lot of knowledge about software design patterns and how to do optimization and man have they made use of that their code does not have spelling errors their code does not have duplication no their code has an abstract Base Class you simply need to implement this abstract Base Class and pass it an object that implements this specific interface and then you have something that just works with logarithmic time complexity it is magnificent gaze upon my creation and in a way it is incredibly impressively put together but when it comes down to it code like that is very often very difficult to understand to figure out what the program does you have to move to this other file and remember that this other thing that is being called here is being injected over here the programmer that wrote this did it with the best of intentions trying to abstract problems away from you but in the end it just made things harder and that brings us to Blick's third stage of programmer growth so there's the novice hacker the philosophy abstractor and the wise hacker and BX describes the wise hacker like this move fast break things revise and fix and get done the wise hacker knows the same patterns and optimization techniques that the philosophy abstractor does the difference is that the wise hacker knows that you should almost never use them the keyword There is almost there will be parts of your code where you should optimize or generalize or modularize the hell out of it and when that happens the wise hacker knows how to do it and how to do it well but again the wise hacker only does it when absolutely necessary and that is because the wise hacker knows that modularization and generalization and optimization have costs these things are not like world peace or kittens they are not universally good they are not free you need to get a lot of value out of them or they will not be worth it when you are modularizing or optimizing or generalizing you are making a tradeoff the wise hacker does modularize the wise hacker does generalize the wise hacker does optimize but like Spider-Man teaches us with great power comes great responsibility and you should only use your powers when necessary the wise hacker writes stupid simple and straightforward code whenever possible you have watched an episode of fun fun function a weekly show where we try to become more excited and confident about programming by exploring old wisdom wild ideas and having fun bye Jo do not miss out on the next episode follow me on Twitter at mpj me until until next Monday stay curious