Thank you for sharing (student here) - I have gotten tied up in abstracting classes I think I will need later, causing delays in the feature at hand. It's nice to have a rule to go by when making these decisions.
Just in time, just enough. I use it for acquiring knowledge as well. No point in overstuffing your brain with nonsense if you're not going to use it. Doing the right thing at the right time is closely related. This is about prioritizing highest gain for least effort.
This video is an eye opener. It made me realise that some people actually write code that's nkt needed yet. I've never even considered that in the past decade
I think it is also because how code is written today. If you are programming in low level code, you will be more likely to create many functions that you will use and reuse, but as programming languages became more advanced it made more sense to write just in time, more akin to how we write scripts.
Hmm, that's an interesting thought. I hadn't thought about how the language abstraction level could potentially impact things. The amount/maturity of libraries for a language might also have a big impact, as you might be less likely to write common functionality when you can just import it.
I believe this follows naturally from the concept that code itself is worthless. The real value lies in the minds of developers who understand the problem they’re solving. Writing code that theorizes about the future implies that you didn’t fully understand the problem at hand. And if code is indeed worthless, then such speculative code is worse than worthless-it’s detrimental.
yagni is one of my favorite principles yeah :) (been coding for 15 years). Don't over-commit to designs, keep your options open, write less code so that you have less code to change later when making changes (makes code more flexible, readable, testable, stable, performant, list is long lol). Cases for writing code too early: thinking your code will need to scale up, thinking your code will need to be reusable or decoupled/replaceable, thinking your code will be a performance issue. premature optimization, root of all evil yada yada. Realistically, at best 20% of the code i've ever written got reused or touched later. Most code is cold code that gets touched never. It's also a matter is prioritizing: of all code you can be writing right now, what's most likely to be needed? work on that. Oh yeah and, you can /think/ ahead of time, just don't /code/ ahead of time.
Think about this when you bootstrap your next project. Maybe you just don't need that fancy framework you were thinking of just yet. For example: Don't start with an Angular/React/Vue whatever app when you can deliver your feature with pure html/css/js for now. Don't initialise a spring boot backend when plain old java/kotlin will get the job done. Don't write a node express server in typescript when you don't need type safety yet. And for gods sake: No GORM (Hibernate) until your SQL code is way too complex. Etc... Keep it simple - use the platform.
Highly disagree with most of what you said. Since I am typing from my phone I will address the two elephants only. Your point about using gorm when "queries get too complex" makes zero sense. That is exactly the point at which you should consider moving away from orm frameworks as the sql generated is way too general and has garbage performance. Elephant 2: have you ever tried making a backend in java with no framework? The most important part of a new project is picking the right tools for a task, ie you should not start building a skyscrapper with a hammer and a few nails.
A big downside (tradeoff really) of JIT/YAGNI that I experience is that it's common that existing code is extrapolated. For instance, extracting- and cleaning code is rarely done at the beginning of a change. So yes, having JIT as a 'sensible default' is great. But it requires effort at both the end- and at the beginning of a change. At the beginning it's tricky because you have to balance conforming to the style of the existing code with reworking the structure of the code. Whereas at the end, you might understand the code you just wrote and how the design can evolve; but you don't want to do all the work. Maybe leave some breadcrumbs? But how? Don't litter your code with comments saying 'TODO break this out', that's even worse. So...it depends?
Yup, that is a tradeoff to keep in mind. When you reach that end state and better know how you could/should structure the code, you do need to determine if it's worth spending the time to make those changes. If you're going to be working in this code for months, probably, if this file is unlikely to be touched for a long time and you need the feature soon, probably not. One of the approaches I've seen to handle how to leave the hints at the end is with a TODO, but have it link to a bug/ticket. That way the bug/ticket can hold more context, information and in theory be tracked to potentially deal with later. Although The rate that those tickets were fixed was a lot lower than they were created, so it still didn't feel like a great solution.
In perfect world you'd be right. But some lazy programmer colleagues will not refactor, ever... And extraction of util functions even if you need them only once is a good idea to help them find it and re-use it. for example if nobody knows where your function is they will not re-use it. Same thing with creating interfaces that you wouldn't need yet. If they are there they can be re-used. If course sometimes it can be too much, but unless you are working with perfect colleagues there are times when you can work ahead (and obviously im not perfect either)
Not a dev and dont know how i got here but this sounds like the reason we have such temporary/fragile/buggy code in everything.. And 500x things each for an individual purpose.. From whatever new fad is online to the new AI /ML /buzzword utilities i experience at work. Throw poop and see if it sticks i guess...
"JIT" coding is only good for the short term. I tried this and it has always led to disaster without fail in the long run. All crazy "abstraction" nonsense has come in handy. You suck at it at first but with experience you'll start to know what your clients want or will need. Clients never know what they want. That's why we always add unnecessary features. Yes it hurts when you guess wrong but the cost of an incorrect guess is just leaving the dead code or removing it. It's nothing. Your computer actually does this all the time with branch prediction. The most important thing is your client. Not code readability.
I agree that the client/user/outcome is the most important thing to focus on. I think having clean and readable code is an important step in being able to iterate faster and quickly respond to requests and changes. I'd also say that I'd view the cost of guessing wrong to be pretty high, as you've not only spent time working on that code, but dead code can make your code base harder to work with, so you'll also probably slow yourself down in the future (until you eventually delete the code, which while fast, still takes some time)
Thank you for sharing (student here) - I have gotten tied up in abstracting classes I think I will need later, causing delays in the feature at hand. It's nice to have a rule to go by when making these decisions.
Just in time, just enough. I use it for acquiring knowledge as well. No point in overstuffing your brain with nonsense if you're not going to use it.
Doing the right thing at the right time is closely related. This is about prioritizing highest gain for least effort.
This video is an eye opener. It made me realise that some people actually write code that's nkt needed yet.
I've never even considered that in the past decade
I was just fighting over this on a PR right now. This video came just in time 😆 I'll go with the reviewer's advice (and yours) and make it simpler
Glad to help!
I feel the same way about in-house frameworks
most important skill I try and pass on to my engineers. Focus! go to lunch on time! Make it small!!
Going to lunch on time is important too! :D
And small PRs are much nicer to review
I think it is also because how code is written today. If you are programming in low level code, you will be more likely to create many functions that you will use and reuse, but as programming languages became more advanced it made more sense to write just in time, more akin to how we write scripts.
Hmm, that's an interesting thought. I hadn't thought about how the language abstraction level could potentially impact things. The amount/maturity of libraries for a language might also have a big impact, as you might be less likely to write common functionality when you can just import it.
I believe this follows naturally from the concept that code itself is worthless. The real value lies in the minds of developers who understand the problem they’re solving. Writing code that theorizes about the future implies that you didn’t fully understand the problem at hand. And if code is indeed worthless, then such speculative code is worse than worthless-it’s detrimental.
Nice video! I always enjoy them.
feature request: add a bit of drama and spice to each one.
Also known forever as YAGNI (you aren't going to need it).
How many times did he say exactly this in the video, though? It's not useful to repeat it here.
Premature abstraction is the parent of all NegativeSentimentFactories
yagni is one of my favorite principles yeah :) (been coding for 15 years). Don't over-commit to designs, keep your options open, write less code so that you have less code to change later when making changes (makes code more flexible, readable, testable, stable, performant, list is long lol). Cases for writing code too early: thinking your code will need to scale up, thinking your code will need to be reusable or decoupled/replaceable, thinking your code will be a performance issue. premature optimization, root of all evil yada yada. Realistically, at best 20% of the code i've ever written got reused or touched later. Most code is cold code that gets touched never. It's also a matter is prioritizing: of all code you can be writing right now, what's most likely to be needed? work on that. Oh yeah and, you can /think/ ahead of time, just don't /code/ ahead of time.
Think about this when you bootstrap your next project. Maybe you just don't need that fancy framework you were thinking of just yet. For example: Don't start with an Angular/React/Vue whatever app when you can deliver your feature with pure html/css/js for now. Don't initialise a spring boot backend when plain old java/kotlin will get the job done. Don't write a node express server in typescript when you don't need type safety yet. And for gods sake: No GORM (Hibernate) until your SQL code is way too complex. Etc...
Keep it simple - use the platform.
Highly disagree with most of what you said. Since I am typing from my phone I will address the two elephants only. Your point about using gorm when "queries get too complex" makes zero sense. That is exactly the point at which you should consider moving away from orm frameworks as the sql generated is way too general and has garbage performance. Elephant 2: have you ever tried making a backend in java with no framework? The most important part of a new project is picking the right tools for a task, ie you should not start building a skyscrapper with a hammer and a few nails.
A big downside (tradeoff really) of JIT/YAGNI that I experience is that it's common that existing code is extrapolated. For instance, extracting- and cleaning code is rarely done at the beginning of a change.
So yes, having JIT as a 'sensible default' is great. But it requires effort at both the end- and at the beginning of a change. At the beginning it's tricky because you have to balance conforming to the style of the existing code with reworking the structure of the code. Whereas at the end, you might understand the code you just wrote and how the design can evolve; but you don't want to do all the work. Maybe leave some breadcrumbs? But how? Don't litter your code with comments saying 'TODO break this out', that's even worse.
So...it depends?
Yup, that is a tradeoff to keep in mind. When you reach that end state and better know how you could/should structure the code, you do need to determine if it's worth spending the time to make those changes. If you're going to be working in this code for months, probably, if this file is unlikely to be touched for a long time and you need the feature soon, probably not.
One of the approaches I've seen to handle how to leave the hints at the end is with a TODO, but have it link to a bug/ticket. That way the bug/ticket can hold more context, information and in theory be tracked to potentially deal with later. Although The rate that those tickets were fixed was a lot lower than they were created, so it still didn't feel like a great solution.
thougth u r talking about JIT
In perfect world you'd be right. But some lazy programmer colleagues will not refactor, ever... And extraction of util functions even if you need them only once is a good idea to help them find it and re-use it. for example if nobody knows where your function is they will not re-use it. Same thing with creating interfaces that you wouldn't need yet. If they are there they can be re-used. If course sometimes it can be too much, but unless you are working with perfect colleagues there are times when you can work ahead (and obviously im not perfect either)
Not a dev and dont know how i got here but this sounds like the reason we have such temporary/fragile/buggy code in everything.. And 500x things each for an individual purpose.. From whatever new fad is online to the new AI /ML /buzzword utilities i experience at work. Throw poop and see if it sticks i guess...
"JIT" coding is only good for the short term. I tried this and it has always led to disaster without fail in the long run.
All crazy "abstraction" nonsense has come in handy. You suck at it at first but with experience you'll start to know what your clients want or will need. Clients never know what they want. That's why we always add unnecessary features.
Yes it hurts when you guess wrong but the cost of an incorrect guess is just leaving the dead code or removing it. It's nothing. Your computer actually does this all the time with branch prediction.
The most important thing is your client. Not code readability.
I agree that the client/user/outcome is the most important thing to focus on. I think having clean and readable code is an important step in being able to iterate faster and quickly respond to requests and changes.
I'd also say that I'd view the cost of guessing wrong to be pretty high, as you've not only spent time working on that code, but dead code can make your code base harder to work with, so you'll also probably slow yourself down in the future (until you eventually delete the code, which while fast, still takes some time)
What a dumb premise.