Dry is the only sensible rule in coding advice. Apart from when you end up hacking that dry method to do every single special case, then it becomes nasty. But I think in that case unshould keep breaking down that code into smaller methods.
4:53 I think you should mention procedural too. With that I mostly mean C and simple C alternatives, like Zig, Odin, C3 etc. Learning Zig and hardcore memory management with no handholding really helped me understand how things work, and it helps me even in Rust and Python to know how things really work under the hood. It also helps to understand a program as ultimately being a linear series of transformations on data. Being able to frame every problem as procedural, OO or functional helps solve problems in any language
Great video! As for point 21 about comments, I'd like to add in actual use cases for code in comments. There are a couple of them (still working on an exhaustive list): 1. Hidden coupling (that cannot be deduced from looking at code) 2. Purpose of the code / who will be using it and why 3. The shortcomings of the code with respect to the project And that leads to the real purpose of the code that can be summed up with two rules of thumb. 1: "Comment what your code doesn't say" (courtesy of Kevlin Henney) and 2: "Comment the context the code lies in". For a lot of code, that will probably be unnecessary, so I agree with your point as well.
Fair points 👍 there are always exceptions. Complexity is normally the problem and in that rare case I'd agree in making some comments in the code so it's easier to understand
The principle I’ve been focusing on is #32: _Write code that fails fast_ . This approach takes effort because it’s counter to the instinct to check for a condition and fail only if it’s unmet. However, the goal here is to halt the logic as soon as the condition is false, making the code run faster. This means that, in some methods, several fail checks will be in place before the actual logic begins, requiring the coder to think about potential failures first.
A problem I’ve faced in the past runs counter to Kiss that you mentioned and actually this point should have a caveat. Keep things simple sure, but whatever you do don’t build solutions that are less complex than the problem you’re trying to solve. I’ve suffered this many times and it’s usually because I’ve under abstracted leading to a dead end. I also like your point about If statements, over use them and you’ll serve up a stinking heap of spaghetti
Simple is an art mainly because it's subjective and it's an art. It's also very difficult to achieve. A lot of third party libraries and services look simple and are simple to use but they hide a lot of complexity. Yup 👍 I pretty much grew up in spaghetti PHP code land 😂
22. I think that learning can be done in a balanced reverse order. If you read about a concept, it might go over your head. However, if you implement something--even if you are just copying code that you don't know--and then go back and read what it is, you are more likely to catch the concepts in what you are reading.
Good insights, Liam. If I were to add my own two cents after 20+ years in the industry, those would be: * Reduce uncertainty as quickly as possible. Clarify requirements before you start coding, and tackle the tough part of the code first. That will let you give much better estimates and make your deliveries much more predictable. * Make it as simple as you need to fulfill the requirements (but not simpler.) Simple is easily understandable and more flexible. Over-engineering is the new root of all evil. * Teaching is a fantastic way to learn.
100% agree with all of those 👍💯 especially the first one. I never sit down and start writing code without planning and discovery. Understanding what the problem is if half the battle 🫡
There's a good short clip by Uncle Bob about how people commonly misunderstand DRY. It is NOT about avoiding code duplication at all costs. It is about providing only a single source of information for a certain problem / task so that, should you ever have to change it, you only have to change it in one place.
Really good advice. *Disagree on specifics of 12:* The way you describe the situation it sounds like you already have something to abstract. If the code you did makes you think of an abstraction, then there's probably not much need to think "do I need it?", only "is this the right one?". The most dangerous thing is coming up with an abstraction before writing the code that will use it. That is, the right time to introduce an abstraction is usually when it requires a little bit of simple refactoring to do. A callback/delegate should be the first form of abstraction to consider. *Addition to 20:* Often the easiest way to simplify code is simplifying the job it has to do. This aspect is easy to forget sometimes. *Disagree on 21:* Commenting every line is not a natural tendency of people that weren't taught to do so by bad teachers. Most people don't write enough comments. For this reason advising against comments is wrong. *I'll also add this one:* Always avoid maxims and dogmas. Any programming principle you read or come up with yourself is a hint and food for thought, not a hard rule.
Some things need hard stances, I do believe there are certain things, if you believe to be true, then you shouldn't budge on unless evidence proves otherwise. Otherwise it's one person's opinion against another. You bring up some fair points. I agree with leaving comments in code for "why" reasons rather than how but it does mean there's a bit of a code/process smell there. Side effects that can't be seen etc. All great feedback 👍 thanks for sharing
I have never regretted commenting code. I would comment more rather than less. Also would emphasize testing- it’s one of the most important skills. The more your code is untested is the riskier it is to your company.
If it exists to explain WHAT the code is then I think there's a problem there. If it exists to explain WHY the code is the way it is then it serves a purpose that cannot be conveyed with code itself. I agree on testing, always analyse the value the test brings though
These are good points, and yes DRY needs more nuance... basically, everything with a slogan, like DRY, use your brain whenever people slap you with slogans, they are usually too blunt. that's my take after nearly 30 years in multiple languages and paradigms.
All very obvious and simple points. Great for beginners though. Nice video. I actually still find debuggers hard to get any benefit from even after 30 years, but obviously they are a great tool when needed.
Thanks for watching 🙏 Yes, this advice is much more valuable for beginners. It's the advice I would have given myself years ago when starting out 👍 Some debuggers can leave a lot to be desired.
@@LiamWalshTech yeh i wish id seen this when i was 20, ive been through every bad step to the point where i say these are obvious. But they were not obvious when I was 20.
Disagree about “comments only last resort” don’t comment how/what code does, comment what/why needs to be done. And do it often. Good code is self explanatory of what it’s doing. A comment should say why it needs to be done. That lets you know later why you did x. Not how you did x. The how can change. The why shouldn’t really change. “Why did I reverse this array?” Bet a comment saying // blah later depends on this order, faster to do it here before blah. That’s gold.
I can see that being a good case. I'd still lean on the side of last resort because if you're constantly needing to explain why code is the way it is then clearly it's too complex or Ipoorly structured.
@@LiamWalshTech complex problems don’t always have simple solutions. If you’re doing something that isn’t obvious why you would do it, comment it first not last. If your implementing spec logic comment the spec link, etc.
I agree with this. I often include comments about my reasoning, because I've learned that why I did something is the most likely thing I'll forget. If I miss something subtle but important when reading my own code in the future, what chance does someone else have?
I started with object oriented programming, until I truly believed in it to be the gold standard in programming. Everything is an object! Then, I learned functional programming and amazed by its elegance I was soon converted into a true believer in functional programming. Side effects are evil, data structures must be immutable, who needs loops when you have recursion? In the end, I got fed up with recreating objects on every change and hardly debuggable generators, so I crawled back to OOP. Today, I use both where appropriate.
To be honest I only clicked on the video expecting to roast the majority of the points raised. However I was surprised that it's not actually one of those videos and I generally agree with pretty much everything. So, instead, here are my thoughts on some of the things I also wanted to hear, with a little bit of disagreement sprinkled here and there. 4. Cannot agree with how this point is put originally - there are certain fields of tech where only a select few of languages do the job. These languages may be vastly different to popular things like javascript, python or java/c#. While some skills may transfer - they operate on a different basis and learning such languages is like starting completely fresh. There are also languages that irrevocably "corrupt" the way you think, which is very hard to break away from. You either need a good starting language with a similar basis or start from something that makes sense in the field, which is something you said yourself. Maybe what you're trying to say is: When you're just starting out and you're on the fence about a handful of languages that suit the use-case - don't overthink it and just start with something already. You'll have to learn a those other languages at some extent either way, and if you will start feeling that your original choice is somehow worse - you will have a better reference point. 5. Also learn what are the advantages and disadvantages of other container types. My personal pet peeve is when people are using 6 data members of the same type in their class and then copy-paste the operations on these variables changing just the member name. Dude, just use a hash table. 7. Try Vim or vim-mode plugin for your IDE of choice. You might find it surprisingly convenient. Or not. It doesn't require MONTHS of learning as some people say, you can try it out in 30 mins by launching a vimtutor. 9. In a lot of cases I've seen, a hash table or a set may do an even better job than if -> return and switch case -> return. Just make sure you're not constructing it on every function call. 11. It's not only that you may wanna try both - actually a lot of functional style techniques apply really well in OOP and make your code more legible, simple and better. Both of these programming paradigms adjust the way you think, simply being aware that a certain problem might be better solved via OOP or functional technique makes you a better programmer in general. 15. LLMs are pretty good for these too, but you need to "discuss" the problem you're experiencing generally, instead of giving it code and expecting it to find a bug for you. 18. Also write notes. 19, 20. You're not really saying anything and being too vague. This leads to people avoiding writing functions, because they thing doing something inline is simpler than putting it into a function, and the code should be simple. This also leads people to using 10 if-else statements instead of using a hash table, and 10 variables instead of an array. "Code simplicity" is truly just a modern buzzword. 19.2. LLMs can help you name things too, often times through a process of Rubber Duck Naming (a term I just invented). Sometimes you might also realize that a function/class/variable/package you're naming has too much responsibility, and it would be a good idea to split it into multiple parts and name them separately effortlessly. 21. "Self-documenting code" is just BS. But I'm not saying you shouldn't adhere to self-documenting principles - you totally should. It's just in the real world there are a lot of corner cases and exceptions to the general rules, which make matters more complicated. And these corner cases and exceptions are ignored, because people think they're writing self-documenting code, so they're free from responsibility to write documentation at all. So yes, don't write redundant comments and docstrings like my_array.clear(); // Clearing an array float get_width() { return my_width; } // Call to get width But always challenge whether the assumptions you have and limitations you apply to your API are as obvious to other people unfamiliar with the context. Try to highlight possible failure points in code and documentation, try to indicate code path indirection and indirect interaction with other systems. Other people might have only worked with other technologies, other fields or other parts of the codebase and they might not have some implicit knowledge. They don't need to spend 20 minutes recompiling their code after getting a runtime error, because when you designed an API it was obvious TO YOU that a function here clearly doesn't check for a null pointer on this nullable input or this other function is clearly not designed to work with negative values. 22. Read the damn books! Practice doesn't substitute studying. Studying doesn't mean that you don't have to practice. There are things you can never learn by doing, just because you are sometimes simply unaware of prerequisites to discover something. Answer honestly to yourself: Could you invent quicksort without prior knowledge? Could you invent the quake inverse sqrt algorithm? That's why discovery is a collective effort and that's why we learn from each other. The field is not stangant - new techniques and new takes are being discovered every day on things you deemed to be true or false. Also, watching a youtube video like "learn language X in 30 minutes" isn't a time spent productive - you just watched another youtube video to feel good, don't deceive yourself. 26. Learn how to use a terminal in the first place. Don't rely too much on your IDE, because by making things easy for you it hides things that might be actually useful. A coworker of mine once couldn't untrack a file from git, because his IDE considered it an operation on a tracked file and added it back automatically every time he tried to commit the change of untracking a file.
Wow 😮 thank you so much for the detailed reply! I definitely agree about using the terminal. It is a must. Especially the git example you mentioned. If you're learning anything you should absolutely write notes. In your own words, very important. You've got a lot of good information in here. I really appreciate the time you took to write this 👏 pure value
One little thing I'd add about DRY: - before refactoring repeated blocks of code - ask yourself - if at any point of lifetime of this app you are going to expand or change functionality of each of those blocks. If you will - keep them separated. This comes from me spending too much time refactoring blocks of code into short and concise code just to later realize - I can't expand on that anymore and each of this thing now need unique behavior, which is now impossible and I just need to roll back. Yes, it could be done in s smart way, but until you know for sure what is "end state" of this code - I'd keep it separate. Sometimes refactoring too much not just a waste of time, but also leads to maintenance hell.
4:20 but isn't just using if statements in a chain like this when you know only one can be true less efficient (in terms of runtime) than using switches/elseifs? I know it's a minor deal, but it can add up to become performance issues, right? Especially if it's a commonly run code in the background of a game or something.
One thing I read on commenting long ago was: Don't comment what the code does. Comment on why you wrote it that way. Knowing the thought process behind your choices will give the code context. Then, if someone needs to maintain the code, they can decide if the changes needed fit with the original context. If it doesn't, then they'll feel confident in making the decision to rewrite it.
Seen a lot of people with this take. It's a fair point. Documenting the why for more complex code or code that has side effects later on etc is a good reason to comment. It is still a sign of problems with the code itself though.
My personal way is writing the intent and not what it does. Like what are you trying to achieve and not how. But I guess intent and the why is related.
The "take a walk" tip of course also works with "go to the bathroom" at work. But walks are great! And various other tips are great as well. Definitely a must watch for developers and those who want to become developers!
1:34 I disagree on this point, your starting language does matter. It's like choosing a Linux distro; if you're getting your feet wet you should start with a popular option (e.g. Ubuntu), rather than one specifically tailored towards a niche (e.g. Kali). Sooner or later, you *will* need help, and the more niche your pick, the more likely you'll find that help lacking if not absent in its entirety.
It matters as far as the type of application you want to develop. Picking something reasonably suited. But people get hung up too much on this. If you can't decide between Go or Java for a backend API you just need to pick one and get moving. Make an informed decision and get to learning the language and building.
Generally good advice, but whether arrays are important depends on the type of work. You might find linked-lists, associative arrays, heaps , various trees and other data structures more useful for specific problems or domains. I would suggest learning and trying all the common data-structures and understand when each is more appropriate to use. You don't want to be a one-trick pony, choosing the wrong or right data-structures will determine the success and performance of a project . If fyou update this advice in 5 years time I think you will be talking more about modularity, type systems and design strategies like type-driven design and onion architecture.
Very good points. Maybe it's my web based background getting in the way but you're right about the right type for the right job 👍 Thanks for the value add 👏
If a start is matter, then start with assembler. Besides of explaining to a duck, you can explain to friends. You do not need an answer, but you should wrap your problem in a writing understandable by others. It works.
DRY falls under "taking things literally". The author has explained clearly in the book that DRY is about don't duplicate business rule but people misunderstand it as no code duplication for any type of code
@@chauchau0825 Haha, yeah, people never read the source I guess. Currently trying to learn art and in that, people use the "Loomis method of head construction" often, introduced by a guy named Loomis, who wrote a book about it. Now you get many people saying you'll get "same face syndrome" if you just use Loomis method. Aka, all your faces will look the same as the method tells you how far down the chin should be etc. But in the actual book, which I guess no one reads, Loomis shows how those things are just guidelines and how you're supposed to vary them (with examples) to draw different faces
All of these are great. What do you think about using comments to call out edge cases? I'm a huge fan of using comments to explain why something exist, more than what is going on. I'm also strongly in favor of calling out edge cases that aren't worth addressing "right now".
Yep 👍 I agree. If something is complex and really can't be broken down to a simpler form or has side effects etc then comments definitely help with giving context 👍
I had to add a line of code to a project to work around a bug in the compiler. The line of code was never called. It fully deserved a whole paragraph of comments.
My version of the rubber duck technique includes writing a question on Stack overflow. This forces me to clearly state my problem and provide a minimal example where the problem occurs. These two things help me to find the solution myself in about 50% of cases.
Number 8 resonates. I was working with one language and trying things out. A friend said to work with this language instead. At the time I figured why not because I wasn't that comfortable with the language I chose, but I still chose it for my own reasons. Anyway, as I was learning the language my friend suggested, all I kept thinking about was the language I chosen. what if I did this in my chosen language? After 6ish months, I went back to the language I picked from the start.
Yup 👍 for efficiency it's always best to lean into the languages and tools you already know. There are only a few occasions where the language or stack are actually limitations.
@@LiamWalshTech wrong. There is no such a thing as a general purpose language. You cannot pick a single language and go addressing all possible problems with it. You'll need dozens of languages to be efficient.
Good video with lots of good advise in it. I just want to point out that DRY and the rest of the principles were never meant to be applied as dogma. DRY should be read as Don't Repeat Yourself Unless You Have A Good Reason. That is, it sets the default, but it shouldn't be read as obligatory. The rule of thumb from the video is a good one.
When I go back to fix old code and cannot understand what is going on, I'll leave comments explaining what it does for next time, so I don't have to figure it out again.
I belief you would be a great conversational partner. Your tips align well with my opinions. So, provided that "the similar" successfully connects, that'd be nice. If it's just redundancy, well, at least we are not alone.
KISS is a tricky one. It's often a compromise between the details and the big picture. Adhering to clean code principles too religiously often leads to unnecessarily complicated code when you "zoom out" that's actually harder to understand.
Einstein said "It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience". Often paraphrased as “Everything should be made as simple as possible, but no simpler”.
I think Python's docstrings (and Javadoc, too) is how commenting should be done in general. I also use comments for separation purposes, when I want to draw attention to a crucial piece of code. One thing that docstrings are awesome at, is explaining the dependencies of a class, module, or function. While a SWE can trace it given enough time, why waste that? I write docstrings for myself to explain where all the dependencies are and how they tie together. This is especially necessary for configuration when it has to be spread across multiple files and you cannot trace it.
Let's just merge 15 (Ducky) and 16 (Walky) with a ChatGPT session. A half hour walk and I get back to my desk with a document of ideas and example code/test code. This is how I solve problems now.
@LiamWalshTech I sure do. When I get back to my desk, I use it directly. I have been doing it for more than 18 months. OpenAI now supports searching through conversation history, so I have over a year of discussions on all sorts of topics. I assume this will eventually be RAGgable.
been coding for 16 years, i can confirm basically all of these. kiss yagni, keep learning, name things better, only abstract once you understand what's going on, only abstract/make reusable or scalable or extensible if it actually solves a real problem... i mean in general i'd say solve problems that actually need solving X) some study showed about 80% of software dev in companies is pure waste, so uuh, don't do that.
1) remove all dependencies, internal and external. 2) one language. however it does not exist... 5) not needed 6) do not use tools 7) typing is never the issue 8) never assume 9) code with no conditionals 10) makes no difference 11) stay away from fads 12) nothing is abstract, "A rose" 13) NEVER write reusable code 18) write less 19) A name is not a technology 20) finish your logic 22) using someone else's logic is not learning 25) never assume future use 26) wasted time [different systems] 27) never log 29) always new 31) know. Every 10 years your list will change. With the same issues you will get better at seeing that nothing you do helps. 274 years of a computer technology and nothing is improving. Look for the underlying problems, not how to live with them. 32) think how it benefits the company, not your personal preference. Nothing is "COOL" or "NEAT" 33) you are not a subject matter expert (job description)
@@LiamWalshTech Yes, just a slight variation of your list. Just step over the line a bit, and see the underlying assumptions we all take. We all do your list, mine is just what I am working on to perfect. Nothing now really works, so I search for something that might.
@@LiamWalshTech Sorry, I am very literal. I was thinking you were asking if I typed this list in. You said to log, I said to never log. In theory you are correct but in practice, it wastes time, and injects unnecessary code. Clear code above all else. Take out everything that does not perform the actual mission. Never code an assumed future non-functional benefit. It is far harder to not log, but the benefits are huge if you can get to the point were logging is not necessary (a perfect app). There are many more reasons why not to log (added dependencies, more code, usefullness, etc), but I will stop here. The rest of my list is harder to explain why, but I have 50 years of why. (I hate to see / use conditional compilable statements)
I have wasted so much of my life trying to follow DRY principle. But when code is rewritten so often I wonder what is the point? May as well write it N times then waste 2^N time on trying to turn it into a method. Only for someone to come and delete it later anyway.
Refactoring is such an important skill. Being able to take code and reshape it when it's becoming cumbersome into something more relevant, reliable, testable and easier to read is so important 👍
Ok how about preventing rippling changes? If you have a fundamental type that is used extensively accross the code base, is that a bad sign? If you have to change that type then anything that uses it will be affected. So how to fix this? Perhaps have intermediate types that act as a firewall?
Not necessarily a problem if the type truly reflects what the data is but if it's just the fact that it looks like the data structure somewhere else then that will cause problems. If it's in fact the same data type then the cascading effect is actually a bonus because less places to change it and type safety covering breaking changes etc.
@ thanks. I asked this question for a specific reason about one of my current projects and I realised I’ve made a type dependent upon another for no other reason than convenience: ie B depends on A, but A is a camparitively wide type and could change for reasons that B is not interested in. So to fix this, I should introduce a narrower type C and provide the correct mapping between A and C.
#2 Learn Multiple Languages Imo a great language to learn later is C. Not to use it to replace another language but to increase understanding of programming in general. Every managed and scripted language is one layer above native code. Many libraries are just wrappers around C/C++. And it doesn't matter if it's Python, Java, C# and if it's on server, desktop or a game engine. I'd say C with structs, pointers and and their raw arrays is more useful to learn than C++ classes. This directly leads to #5 data manipulation. Pushing around structured data, as structs, arrays, arrays of structs and pointers to data is so damn old and yet it is the building block of everything.
That is some great advice 🙏 thanks for sharing. I'm expanding into new languages and learning Go and livestreaming the journey with it. Maybe one day I'll do C 👍 you're spot on though
To be honest the most valuable skill ever in software is to be able to sell yourself. You can be the best programmer (or the best at anything) but if you can't convince your hiring teams or investors that you are valuable, you will have a really hard time achieven anything
@@LiamWalshTech Its not easiest to read, but totally worth the time. Also Practices, principles and patterns of DDD and the DDD book by vaugh vernon are highly recommended
I disagree with #4. The first language matters, a lot. It makes a huge difference if your first language is imperative like JavaScript or Python or if your first language is e.g. Haskell or Ocaml. You learn totally different techniques and in my opinion you will benefit if your first language is declarative. Even Rust is a better start than Python.
I was mainly drawing attention to action. People spend too much time deliberating something they shouldn't. Make an educated decision based on what you want to produce (web, app, service etc) and then get to building.
The only thing I wish is that RUclipsrs start getting original and not letting themselves get raw-dogged by the algorithm. You owe me one for commenting, pushes this shit.
I find the video Liam made interesting. I agree with most of the recommendations, but some less. I do recognize programming is complex and yet I think the list should be shorter. Or at least with some order and structure :-) Good luck.
Hi Erez 👋 thanks for the feedback. It's hard to structure lists like these because the points are not always connected and sometimes there's no natural order to things but I see what you mean. Good luck to yourself as well. Are there any tips you would add to the list?
Perhaps understanding development methods like TDD, agile, water fall and understanding mode of collaborating with other developers. The important of testing as part of development, like unit test and regression tests. The importance of planing and architecture for development. Learning programming methods, object orient and functional are just 2 examples. I can find more concept, understanding what are pointers and memory management and what is garbage collection. What are evaluation and lambda function, as example for programming technics. Just few things I think developers should know. I am sure you can find more 🙂
If you think these 30 tips were worth sitting through then consider signing up to my free weekly newsletter ⬇️
www.liamwalsh.tech/
I'm a simple man. see something calling out dry code dogma, I click
Nuance is the key 🗝️
Dry is the only sensible rule in coding advice. Apart from when you end up hacking that dry method to do every single special case, then it becomes nasty. But I think in that case unshould keep breaking down that code into smaller methods.
Yeah DRY is always good. I'm almost 37 so I win against the author of the video
@@i-am-the-slime can't beat you on that one 😂
@@i-am-the-slime No, there are definitely some times when DRY is bad.
4:53 I think you should mention procedural too. With that I mostly mean C and simple C alternatives, like Zig, Odin, C3 etc. Learning Zig and hardcore memory management with no handholding really helped me understand how things work, and it helps me even in Rust and Python to know how things really work under the hood. It also helps to understand a program as ultimately being a linear series of transformations on data. Being able to frame every problem as procedural, OO or functional helps solve problems in any language
That's a great point 👍 being from more of a web development background I've never used procedural before.
Definitely something I should change 👍
Great video! As for point 21 about comments, I'd like to add in actual use cases for code in comments. There are a couple of them (still working on an exhaustive list):
1. Hidden coupling (that cannot be deduced from looking at code)
2. Purpose of the code / who will be using it and why
3. The shortcomings of the code with respect to the project
And that leads to the real purpose of the code that can be summed up with two rules of thumb. 1: "Comment what your code doesn't say" (courtesy of Kevlin Henney) and 2: "Comment the context the code lies in". For a lot of code, that will probably be unnecessary, so I agree with your point as well.
Fair points 👍 there are always exceptions. Complexity is normally the problem and in that rare case I'd agree in making some comments in the code so it's easier to understand
The principle I’ve been focusing on is #32: _Write code that fails fast_ . This approach takes effort because it’s counter to the instinct to check for a condition and fail only if it’s unmet. However, the goal here is to halt the logic as soon as the condition is false, making the code run faster. This means that, in some methods, several fail checks will be in place before the actual logic begins, requiring the coder to think about potential failures first.
That's an interesting approach, I've never heard of that before 🤔
Are you just describing Guard Clauses?
You're just describing guard clauses. Validation (pre processing), process, post processing (mapping response).
A problem I’ve faced in the past runs counter to Kiss that you mentioned and actually this point should have a caveat. Keep things simple sure, but whatever you do don’t build solutions that are less complex than the problem you’re trying to solve. I’ve suffered this many times and it’s usually because I’ve under abstracted leading to a dead end. I also like your point about If statements, over use them and you’ll serve up a stinking heap of spaghetti
Simple is an art mainly because it's subjective and it's an art. It's also very difficult to achieve.
A lot of third party libraries and services look simple and are simple to use but they hide a lot of complexity.
Yup 👍 I pretty much grew up in spaghetti PHP code land 😂
On point! I've learned the same lessons during my career.
Thanks 🙏 glad it resonates
22. I think that learning can be done in a balanced reverse order. If you read about a concept, it might go over your head. However, if you implement something--even if you are just copying code that you don't know--and then go back and read what it is, you are more likely to catch the concepts in what you are reading.
That's a good idea. Going back to the theory after implementing something would help with understanding it better 👍
Good insights, Liam. If I were to add my own two cents after 20+ years in the industry, those would be:
* Reduce uncertainty as quickly as possible. Clarify requirements before you start coding, and tackle the tough part of the code first. That will let you give much better estimates and make your deliveries much more predictable.
* Make it as simple as you need to fulfill the requirements (but not simpler.) Simple is easily understandable and more flexible. Over-engineering is the new root of all evil.
* Teaching is a fantastic way to learn.
100% agree with all of those 👍💯 especially the first one. I never sit down and start writing code without planning and discovery.
Understanding what the problem is if half the battle 🫡
Love your second point about making your solution too simple for the problem
There's a good short clip by Uncle Bob about how people commonly misunderstand DRY. It is NOT about avoiding code duplication at all costs. It is about providing only a single source of information for a certain problem / task so that, should you ever have to change it, you only have to change it in one place.
Good Ol' Uncle Bob 👍 he's right
Really good advice.
*Disagree on specifics of 12:* The way you describe the situation it sounds like you already have something to abstract. If the code you did makes you think of an abstraction, then there's probably not much need to think "do I need it?", only "is this the right one?". The most dangerous thing is coming up with an abstraction before writing the code that will use it. That is, the right time to introduce an abstraction is usually when it requires a little bit of simple refactoring to do. A callback/delegate should be the first form of abstraction to consider.
*Addition to 20:* Often the easiest way to simplify code is simplifying the job it has to do. This aspect is easy to forget sometimes.
*Disagree on 21:* Commenting every line is not a natural tendency of people that weren't taught to do so by bad teachers. Most people don't write enough comments. For this reason advising against comments is wrong.
*I'll also add this one:* Always avoid maxims and dogmas. Any programming principle you read or come up with yourself is a hint and food for thought, not a hard rule.
Some things need hard stances, I do believe there are certain things, if you believe to be true, then you shouldn't budge on unless evidence proves otherwise. Otherwise it's one person's opinion against another.
You bring up some fair points.
I agree with leaving comments in code for "why" reasons rather than how but it does mean there's a bit of a code/process smell there. Side effects that can't be seen etc.
All great feedback 👍 thanks for sharing
I have never regretted commenting code. I would comment more rather than less. Also would emphasize testing- it’s one of the most important skills. The more your code is untested is the riskier it is to your company.
If it exists to explain WHAT the code is then I think there's a problem there. If it exists to explain WHY the code is the way it is then it serves a purpose that cannot be conveyed with code itself.
I agree on testing, always analyse the value the test brings though
These are good points, and yes DRY needs more nuance... basically, everything with a slogan, like DRY, use your brain whenever people slap you with slogans, they are usually too blunt. that's my take after nearly 30 years in multiple languages and paradigms.
Absolutely, 100% agree. Catchy slogans sound smart and on the surface make sense but you need to dig a little deeper and think about it critically
All very obvious and simple points. Great for beginners though. Nice video. I actually still find debuggers hard to get any benefit from even after 30 years, but obviously they are a great tool when needed.
Thanks for watching 🙏
Yes, this advice is much more valuable for beginners. It's the advice I would have given myself years ago when starting out 👍
Some debuggers can leave a lot to be desired.
@@LiamWalshTech yeh i wish id seen this when i was 20, ive been through every bad step to the point where i say these are obvious. But they were not obvious when I was 20.
Disagree about “comments only last resort” don’t comment how/what code does, comment what/why needs to be done. And do it often. Good code is self explanatory of what it’s doing. A comment should say why it needs to be done. That lets you know later why you did x. Not how you did x. The how can change. The why shouldn’t really change.
“Why did I reverse this array?” Bet a comment saying // blah later depends on this order, faster to do it here before blah. That’s gold.
I can see that being a good case.
I'd still lean on the side of last resort because if you're constantly needing to explain why code is the way it is then clearly it's too complex or Ipoorly structured.
@@LiamWalshTech complex problems don’t always have simple solutions. If you’re doing something that isn’t obvious why you would do it, comment it first not last. If your implementing spec logic comment the spec link, etc.
I agree with this. I often include comments about my reasoning, because I've learned that why I did something is the most likely thing I'll forget. If I miss something subtle but important when reading my own code in the future, what chance does someone else have?
I started with object oriented programming, until I truly believed in it to be the gold standard in programming. Everything is an object! Then, I learned functional programming and amazed by its elegance I was soon converted into a true believer in functional programming. Side effects are evil, data structures must be immutable, who needs loops when you have recursion?
In the end, I got fed up with recreating objects on every change and hardly debuggable generators, so I crawled back to OOP. Today, I use both where appropriate.
They've both got their place. Use the right tool for the job
What about procedural programming? I'm not hearing his name in any of this.
@@haha71687 I'd argue that OOP is procedural programming with objects. Imperative programming languages aren't that dissimilar from each other.
To be honest I only clicked on the video expecting to roast the majority of the points raised. However I was surprised that it's not actually one of those videos and I generally agree with pretty much everything. So, instead, here are my thoughts on some of the things I also wanted to hear, with a little bit of disagreement sprinkled here and there.
4. Cannot agree with how this point is put originally - there are certain fields of tech where only a select few of languages do the job. These languages may be vastly different to popular things like javascript, python or java/c#. While some skills may transfer - they operate on a different basis and learning such languages is like starting completely fresh. There are also languages that irrevocably "corrupt" the way you think, which is very hard to break away from. You either need a good starting language with a similar basis or start from something that makes sense in the field, which is something you said yourself.
Maybe what you're trying to say is: When you're just starting out and you're on the fence about a handful of languages that suit the use-case - don't overthink it and just start with something already. You'll have to learn a those other languages at some extent either way, and if you will start feeling that your original choice is somehow worse - you will have a better reference point.
5. Also learn what are the advantages and disadvantages of other container types. My personal pet peeve is when people are using 6 data members of the same type in their class and then copy-paste the operations on these variables changing just the member name. Dude, just use a hash table.
7. Try Vim or vim-mode plugin for your IDE of choice. You might find it surprisingly convenient. Or not. It doesn't require MONTHS of learning as some people say, you can try it out in 30 mins by launching a vimtutor.
9. In a lot of cases I've seen, a hash table or a set may do an even better job than if -> return and switch case -> return. Just make sure you're not constructing it on every function call.
11. It's not only that you may wanna try both - actually a lot of functional style techniques apply really well in OOP and make your code more legible, simple and better. Both of these programming paradigms adjust the way you think, simply being aware that a certain problem might be better solved via OOP or functional technique makes you a better programmer in general.
15. LLMs are pretty good for these too, but you need to "discuss" the problem you're experiencing generally, instead of giving it code and expecting it to find a bug for you.
18. Also write notes.
19, 20. You're not really saying anything and being too vague. This leads to people avoiding writing functions, because they thing doing something inline is simpler than putting it into a function, and the code should be simple. This also leads people to using 10 if-else statements instead of using a hash table, and 10 variables instead of an array. "Code simplicity" is truly just a modern buzzword.
19.2. LLMs can help you name things too, often times through a process of Rubber Duck Naming (a term I just invented). Sometimes you might also realize that a function/class/variable/package you're naming has too much responsibility, and it would be a good idea to split it into multiple parts and name them separately effortlessly.
21. "Self-documenting code" is just BS. But I'm not saying you shouldn't adhere to self-documenting principles - you totally should. It's just in the real world there are a lot of corner cases and exceptions to the general rules, which make matters more complicated. And these corner cases and exceptions are ignored, because people think they're writing self-documenting code, so they're free from responsibility to write documentation at all. So yes, don't write redundant comments and docstrings like
my_array.clear(); // Clearing an array
float get_width() { return my_width; } // Call to get width
But always challenge whether the assumptions you have and limitations you apply to your API are as obvious to other people unfamiliar with the context. Try to highlight possible failure points in code and documentation, try to indicate code path indirection and indirect interaction with other systems. Other people might have only worked with other technologies, other fields or other parts of the codebase and they might not have some implicit knowledge. They don't need to spend 20 minutes recompiling their code after getting a runtime error, because when you designed an API it was obvious TO YOU that a function here clearly doesn't check for a null pointer on this nullable input or this other function is clearly not designed to work with negative values.
22. Read the damn books! Practice doesn't substitute studying. Studying doesn't mean that you don't have to practice. There are things you can never learn by doing, just because you are sometimes simply unaware of prerequisites to discover something. Answer honestly to yourself: Could you invent quicksort without prior knowledge? Could you invent the quake inverse sqrt algorithm? That's why discovery is a collective effort and that's why we learn from each other. The field is not stangant - new techniques and new takes are being discovered every day on things you deemed to be true or false. Also, watching a youtube video like "learn language X in 30 minutes" isn't a time spent productive - you just watched another youtube video to feel good, don't deceive yourself.
26. Learn how to use a terminal in the first place. Don't rely too much on your IDE, because by making things easy for you it hides things that might be actually useful. A coworker of mine once couldn't untrack a file from git, because his IDE considered it an operation on a tracked file and added it back automatically every time he tried to commit the change of untracking a file.
Wow 😮 thank you so much for the detailed reply!
I definitely agree about using the terminal. It is a must. Especially the git example you mentioned.
If you're learning anything you should absolutely write notes. In your own words, very important.
You've got a lot of good information in here. I really appreciate the time you took to write this 👏 pure value
One little thing I'd add about DRY:
- before refactoring repeated blocks of code - ask yourself - if at any point of lifetime of this app you are going to expand or change functionality of each of those blocks. If you will - keep them separated.
This comes from me spending too much time refactoring blocks of code into short and concise code just to later realize - I can't expand on that anymore and each of this thing now need unique behavior, which is now impossible and I just need to roll back.
Yes, it could be done in s smart way, but until you know for sure what is "end state" of this code - I'd keep it separate.
Sometimes refactoring too much not just a waste of time, but also leads to maintenance hell.
Absolutely, don't abstract too early.
If you reimplement at least three times then it's time to think about it.
4:20 but isn't just using if statements in a chain like this when you know only one can be true less efficient (in terms of runtime) than using switches/elseifs? I know it's a minor deal, but it can add up to become performance issues, right? Especially if it's a commonly run code in the background of a game or something.
Probably not the best example but when you come across the else if problem you'll know it
One thing I read on commenting long ago was: Don't comment what the code does. Comment on why you wrote it that way. Knowing the thought process behind your choices will give the code context. Then, if someone needs to maintain the code, they can decide if the changes needed fit with the original context. If it doesn't, then they'll feel confident in making the decision to rewrite it.
Seen a lot of people with this take. It's a fair point. Documenting the why for more complex code or code that has side effects later on etc is a good reason to comment.
It is still a sign of problems with the code itself though.
My personal way is writing the intent and not what it does.
Like what are you trying to achieve and not how.
But I guess intent and the why is related.
@@MrDavibu Yeah, slightly different. Sometimes one makes sense and sometimes the other
The "take a walk" tip of course also works with "go to the bathroom" at work. But walks are great! And various other tips are great as well. Definitely a must watch for developers and those who want to become developers!
Thanks 🙏 there's similar activities like walking that elicit the same thing like shower thoughts etc 👍
1:34 I disagree on this point, your starting language does matter.
It's like choosing a Linux distro; if you're getting your feet wet you should start with a popular option (e.g. Ubuntu), rather than one specifically tailored towards a niche (e.g. Kali).
Sooner or later, you *will* need help, and the more niche your pick, the more likely you'll find that help lacking if not absent in its entirety.
It matters as far as the type of application you want to develop. Picking something reasonably suited.
But people get hung up too much on this. If you can't decide between Go or Java for a backend API you just need to pick one and get moving.
Make an informed decision and get to learning the language and building.
Generally good advice, but whether arrays are important depends on the type of work. You might find linked-lists, associative arrays, heaps , various trees and other data structures more useful for specific problems or domains. I would suggest learning and trying all the common data-structures and understand when each is more appropriate to use. You don't want to be a one-trick pony, choosing the wrong or right data-structures will determine the success and performance of a project .
If fyou update this advice in 5 years time I think you will be talking more about modularity, type systems and design strategies like type-driven design and onion architecture.
Very good points. Maybe it's my web based background getting in the way but you're right about the right type for the right job 👍
Thanks for the value add 👏
If a start is matter, then start with assembler. Besides of explaining to a duck, you can explain to friends. You do not need an answer, but you should wrap your problem in a writing understandable by others. It works.
I'm gonna need a minute to decipher this comment.
@@LiamWalshTech Clear writing is also a useful skill.
I need to learn more about arrays and try out new languages, but I'm happy to say I'm used to the other 28 tips you presented. Ty.
Never hurts to be more efficient with data handling 👍 hope you enjoyed the video
DRY just falls under "don't take any guideline as an absolute rule"
Absolutely 👍 the code is more what you'd call "guidelines" than actual rules 🦜
DRY falls under "taking things literally". The author has explained clearly in the book that DRY is about don't duplicate business rule but people misunderstand it as no code duplication for any type of code
@@chauchau0825 Haha, yeah, people never read the source I guess.
Currently trying to learn art and in that, people use the "Loomis method of head construction" often, introduced by a guy named Loomis, who wrote a book about it.
Now you get many people saying you'll get "same face syndrome" if you just use Loomis method. Aka, all your faces will look the same as the method tells you how far down the chin should be etc.
But in the actual book, which I guess no one reads, Loomis shows how those things are just guidelines and how you're supposed to vary them (with examples) to draw different faces
All of these are great. What do you think about using comments to call out edge cases? I'm a huge fan of using comments to explain why something exist, more than what is going on. I'm also strongly in favor of calling out edge cases that aren't worth addressing "right now".
Yup to this.
Yep 👍 I agree. If something is complex and really can't be broken down to a simpler form or has side effects etc then comments definitely help with giving context 👍
I had to add a line of code to a project to work around a bug in the compiler. The line of code was never called. It fully deserved a whole paragraph of comments.
@@johnridout6540 that's fantastic. What language? I'm really enjoying this.
@@yramagicman675 It was a long long time ago in VB, version 3 or 4.
My version of the rubber duck technique includes writing a question on Stack overflow. This forces me to clearly state my problem and provide a minimal example where the problem occurs. These two things help me to find the solution myself in about 50% of cases.
That's a great technique! StackOverflow would be much emptier site if people took this approach
This has worked for me so many times. The process of explaining your issue so somebody can understand usually ends up in you finding your answer.
I do the same asking chat gpt now
A problem well stated is a problem half solved
Overall this is great advice. Nice video too, no waste.
Thanks 🙏 I don't like to make videos long for the sake of it. However long it takes to convey what's intended and no more
Number 8 resonates. I was working with one language and trying things out. A friend said to work with this language instead. At the time I figured why not because I wasn't that comfortable with the language I chose, but I still chose it for my own reasons. Anyway, as I was learning the language my friend suggested, all I kept thinking about was the language I chosen. what if I did this in my chosen language? After 6ish months, I went back to the language I picked from the start.
Yup 👍 for efficiency it's always best to lean into the languages and tools you already know.
There are only a few occasions where the language or stack are actually limitations.
@@LiamWalshTech wrong. There is no such a thing as a general purpose language. You cannot pick a single language and go addressing all possible problems with it. You'll need dozens of languages to be efficient.
Good video with lots of good advise in it.
I just want to point out that DRY and the rest of the principles were never meant to be applied as dogma. DRY should be read as Don't Repeat Yourself Unless You Have A Good Reason. That is, it sets the default, but it shouldn't be read as obligatory. The rule of thumb from the video is a good one.
I agree 👍 the problem is a lot of people forget the nuance and try to abstract everything 😬 gotta be careful out there
When I go back to fix old code and cannot understand what is going on, I'll leave comments explaining what it does for next time, so I don't have to figure it out again.
Yup. When there's complexity that can't be expressed by the code itself then I'd agree 👍
I belief you would be a great conversational partner. Your tips align well with my opinions. So, provided that "the similar" successfully connects, that'd be nice. If it's just redundancy, well, at least we are not alone.
Thanks 😅👍
KISS is a tricky one. It's often a compromise between the details and the big picture. Adhering to clean code principles too religiously often leads to unnecessarily complicated code when you "zoom out" that's actually harder to understand.
Yup. The thing is people think simple = easy and it's not.
Achieving simplicity is often quite difficult
Einstein said
"It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience".
Often paraphrased as
“Everything should be made as simple as possible, but no simpler”.
I think Python's docstrings (and Javadoc, too) is how commenting should be done in general. I also use comments for separation purposes, when I want to draw attention to a crucial piece of code.
One thing that docstrings are awesome at, is explaining the dependencies of a class, module, or function. While a SWE can trace it given enough time, why waste that? I write docstrings for myself to explain where all the dependencies are and how they tie together. This is especially necessary for configuration when it has to be spread across multiple files and you cannot trace it.
So highlighting the why instead of the what and how?
Mature advices, thanks
You're welcome 👍 thanks for watching 🙏
Functional vs Oop? I use both, if done right, they complement each other.
Try both 👍 they both have their pros and cons
... vs Event-driven programming.
Awesome stuff 😎
😎👊
One I’ve had to learn, Not everything requires code ❤
Absolutely 👍 more code just means more to maintain. If you can get done what you need without it then it's probably a win
Let's just merge 15 (Ducky) and 16 (Walky) with a ChatGPT session.
A half hour walk and I get back to my desk with a document of ideas and example code/test code.
This is how I solve problems now.
Do you record your ideas during your walk? Do you chat to GPT while walking?
@LiamWalshTech
I sure do. When I get back to my desk, I use it directly. I have been doing it for more than 18 months.
OpenAI now supports searching through conversation history, so I have over a year of discussions on all sorts of topics.
I assume this will eventually be RAGgable.
been coding for 16 years, i can confirm basically all of these. kiss yagni, keep learning, name things better, only abstract once you understand what's going on, only abstract/make reusable or scalable or extensible if it actually solves a real problem... i mean in general i'd say solve problems that actually need solving X) some study showed about 80% of software dev in companies is pure waste, so uuh, don't do that.
Agreed 🤝 nothing worse then time and effort wasted
1) remove all dependencies, internal and external. 2) one language. however it does not exist... 5) not needed 6) do not use tools 7) typing is never the issue 8) never assume 9) code with no conditionals 10) makes no difference 11) stay away from fads 12) nothing is abstract, "A rose" 13) NEVER write reusable code 18) write less 19) A name is not a technology 20) finish your logic 22) using someone else's logic is not learning 25) never assume future use 26) wasted time [different systems] 27) never log 29) always new 31) know.
Every 10 years your list will change. With the same issues you will get better at seeing that nothing you do helps. 274 years of a computer technology and nothing is improving. Look for the underlying problems, not how to live with them. 32) think how it benefits the company, not your personal preference. Nothing is "COOL" or "NEAT" 33) you are not a subject matter expert (job description)
Is this your list?
@@LiamWalshTech Yes, just a slight variation of your list. Just step over the line a bit, and see the underlying assumptions we all take. We all do your list, mine is just what I am working on to perfect. Nothing now really works, so I search for something that might.
@@LiamWalshTech Sorry, I am very literal. I was thinking you were asking if I typed this list in. You said to log, I said to never log. In theory you are correct but in practice, it wastes time, and injects unnecessary code. Clear code above all else. Take out everything that does not perform the actual mission. Never code an assumed future non-functional benefit. It is far harder to not log, but the benefits are huge if you can get to the point were logging is not necessary (a perfect app). There are many more reasons why not to log (added dependencies, more code, usefullness, etc), but I will stop here. The rest of my list is harder to explain why, but I have 50 years of why. (I hate to see / use conditional compilable statements)
@@ClifCollins-k8d each to their own 👍 thanks for contributing
Excellent!
Thanks 🙏 glad you enjoyed
I have wasted so much of my life trying to follow DRY principle. But when code is rewritten so often I wonder what is the point? May as well write it N times then waste 2^N time on trying to turn it into a method. Only for someone to come and delete it later anyway.
Refactoring is such an important skill. Being able to take code and reshape it when it's becoming cumbersome into something more relevant, reliable, testable and easier to read is so important 👍
@@LiamWalshTech Yeah, better to refactor once the usage is clear than try to avoid repetitive code from get go. KISS > YAGNI > DRY
Ok how about preventing rippling changes? If you have a fundamental type that is used extensively accross the code base, is that a bad sign? If you have to change that type then anything that uses it will be affected. So how to fix this? Perhaps have intermediate types that act as a firewall?
Not necessarily a problem if the type truly reflects what the data is but if it's just the fact that it looks like the data structure somewhere else then that will cause problems.
If it's in fact the same data type then the cascading effect is actually a bonus because less places to change it and type safety covering breaking changes etc.
@ thanks. I asked this question for a specific reason about one of my current projects and I realised I’ve made a type dependent upon another for no other reason than convenience: ie B depends on A, but A is a camparitively wide type and could change for reasons that B is not interested in. So to fix this, I should introduce a narrower type C and provide the correct mapping between A and C.
#2 Learn Multiple Languages
Imo a great language to learn later is C. Not to use it to replace another language but to increase understanding of programming in general. Every managed and scripted language is one layer above native code. Many libraries are just wrappers around C/C++. And it doesn't matter if it's Python, Java, C# and if it's on server, desktop or a game engine. I'd say C with structs, pointers and and their raw arrays is more useful to learn than C++ classes. This directly leads to #5 data manipulation. Pushing around structured data, as structs, arrays, arrays of structs and pointers to data is so damn old and yet it is the building block of everything.
That is some great advice 🙏 thanks for sharing. I'm expanding into new languages and learning Go and livestreaming the journey with it. Maybe one day I'll do C 👍 you're spot on though
9. I think that guard clauses are a useful alternative to if else statements
Yup 👍 good option as well. Anything that avoids the basic beginner logic trap
To be honest the most valuable skill ever in software is to be able to sell yourself. You can be the best programmer (or the best at anything) but if you can't convince your hiring teams or investors that you are valuable, you will have a really hard time achieven anything
Communication is the missing piece for a lot of engineers
nice video, I would also add read DDD by eric evans and other DDD literature
About DRY. In my opinion DRY "is acceptable only inside single context"
Haven't read that one, I'll add it to my reading list 👍
@@LiamWalshTech Its not easiest to read, but totally worth the time. Also Practices, principles and patterns of DDD and the DDD book by vaugh vernon are highly recommended
Go and learn a Lisp as well. Common Lisp is pretty good, but any Lisp will do. It will make you a better programmer
I'll put that on my to-do list as well 👍
I'm at 12 and so far, i agree with everything you said...
Thanks for watching 🙏
I disagree with #4. The first language matters, a lot. It makes a huge difference if your first language is imperative like JavaScript or Python or if your first language is e.g. Haskell or Ocaml.
You learn totally different techniques and in my opinion you will benefit if your first language is declarative. Even Rust is a better start than Python.
I was mainly drawing attention to action.
People spend too much time deliberating something they shouldn't.
Make an educated decision based on what you want to produce (web, app, service etc) and then get to building.
#3: is so not false!
#21: document why you do it this way
Is true false 😂
I dont remember making this video when i was 30, i somehow look different too ...
You're not another Liam Walsh are you? 😂
I've never ran into another one in life this far.
@@LiamWalshTech No, its just uncanny how similar these points are to my own experience.
@@spacechemsol4288 oh right 😂 well good to know the experience is shared 👍
The only thing I wish is that RUclipsrs start getting original and not letting themselves get raw-dogged by the algorithm.
You owe me one for commenting, pushes this shit.
I wondered why my butt was hurting.
Thanks for the comment 👍
I find the video Liam made interesting.
I agree with most of the recommendations, but some less.
I do recognize programming is complex and yet I think the list should be shorter.
Or at least with some order and structure :-)
Good luck.
Hi Erez 👋 thanks for the feedback.
It's hard to structure lists like these because the points are not always connected and sometimes there's no natural order to things but I see what you mean.
Good luck to yourself as well. Are there any tips you would add to the list?
Perhaps understanding development methods like TDD, agile, water fall and understanding mode of collaborating with other developers.
The important of testing as part of development, like unit test and regression tests.
The importance of planing and architecture for development.
Learning programming methods, object orient and functional are just 2 examples. I can find more concept, understanding what are pointers and memory management and what is garbage collection. What are evaluation and lambda function, as example for programming technics.
Just few things I think developers should know.
I am sure you can find more 🙂
The list can go on and on to be honest 😅👍
Normies keep talking about OOP and functional on and on. The enlightened know: procedural is king. :D
Long live procedures!
How about logic programming?
I'll be honest, I've never tried it! Is there any particular language it's suited for?
My code comments are almost always apologies for tech debt
We've all been there bro 👊
The DRY vs. DAMP dichotomy is false and both are important in producing "good" software.
The DAMP part was a joke 😂
The best ideas come under the shower.
Or during a long walk 🚶
Weird guy, but yes... I wasn't programming for 12 years, buteverything said here s true
Thanks? 😅
Luckily, naming variables and functions has been greatly solved by AI like Copilot
How well do you think AI names variables?
10:22 And off-by-one errors!
Classics 😂
🎉🎉🎉
🙏
31 learn javascript
32, then learn Typescript 😄
7) get more dumb? :D
🤨
@@LiamWalshTech Subtitles! Cool vid btw.
@@robertkrasa9316 oh right 😅 still trying to get everything working right 😂👍 thanks for the comment. Will check it through twice next time
@@LiamWalshTech Sorry for the nitpicking, I just found it hillarious.
@@robertkrasa9316 me too 😂 no offence taken ma guy 👍
Every single third party dependency is a liability. If you can afford avoiding a dependency - do it.
Easier said then done but true
started my journey lets where we going
;
Always fun sharing the journey 👍
Great video!
Thanks 🙏 glad you enjoyed it