Very funny timing lol. Core systems at massive scale cyber security companies supporting infrastructure for millions is a good example of a place where you probably don't want to write hacky code....
I’m not just talking about things that are over engineered. I think sometimes when you need things urgently or when the business wants to experiment with a feature you can actually implement inefficient hacky code to prove out the need before building something more solid.
@@TroiCodes I think we have a different definition of "Bad Code" I think complexity, feature set and refinement has nothing to do with "quality". In my opinion, the code is "bad" if it does not fulfill its purpose. A prototype's purpose is difficulty evaluation and experimentation. If it is not meant to be relied on or it's easy to replace (with well defined interfaces) while it provides insights to an unknown area, then it fulfills its purpose. On the other hand, if a piece of code is well documented, well tested and refined, but it fails to be a stable foundation for future features, then its bad code. You don't gain anything if you have to rework most of your foundation to implement a simple feature. Documentation, tests and uniform coding styles improve the Time-To-Understand and can help increase the "quality", but if the code is "bad", then its like a barely functioning car with all the luxury features: It might not always stats, but at least its cold in the summer.
When you need something urgently you contract technical debt.
3 месяца назад+47
"poorly abstracted" - I would definitely take "not abstracted" over that! Code with a lack of abstractions, i.e. very procedural and lots of repetitive code, that's the best "bad code" in my experience. When the time comes, it's so easy to sail through that code and create very good abstractions based on the information the code is presenting to you.
Good point! Honestly, that would have probably been a better way to word what I was getting at. Not everything needs to be built to solve a ton of use cases. You make a great point as well that code that's not abstracted is a great starting point for building abstractions ontop of when the time is right since you already know exactly how you'd want to consume said abstraction.
To everybody commenting, "Worst timing, lol!" The target audience for this video obviously isn't people writing kernel-level security software that powers half the internet. It's for the 15 person agency that will get 3 chat requests per day, that will never scale to need millions of concurrent requests, and if they do, that's a very good problem for them to have (and at that point they can throw money and developers at the problem).
Very agree- no point in building an api system with a hyper-accurate token bucket if the whole thing is in-house and called a grand total of once in the code.
I think a better term will be "Imperfect code". Bad code gives negative vibes, such as "if you change this code, the app crashes for some weird reasons". Often times we waste time by perfecting our code, which hinders us from building something meaningful. The opposite is to write really convoluted and obfuscated code. It may help you in achieving your short-term goals but it may not be long before you regret it when management starts to question why every minor UI change takes a few days to complete. Only experience helps you decide the best trade-off.
maybe it's more accurate to say it like you, but i would not have understood it as well as a junior developer. i feel disgust at myself when i write something i know could be better, and saying it with a more negative way lessen my apprehension of doing it. maybe it's too personal, idk.
That was the goal! I have been talking a lot about this in feedback sessions with more junior developers which is why I phrased it like I did. I agree "imperfect code" is a much better term for what I'm describing but I don't think it hits home quite the same way "bad code" does for more junior engineers.
Thank you for inspiring me to code more and i have realised when errors occurs i am able to sort the errors and this makes me feel that today i have learnt something new.😊
I agree with the sentiment, but I think you’re describing is “mediocre code”. Bad code is often over engineered, where the wrong tools have been used and is broken with lots of barely understood edge cases. It’s code that provides negative business value over time.
"yeah so we're going to deploy a scalable sharded database over several kubernetes clusters with multiple caches for performance" "dude we are storing literally fifteen kilobytes of data here. why"
As I've evolved my programming skills, I have noticed that the more organized I develop my systems, the easier it is for mantaining them. The only situation where "bad code" was a proper choice, was in situations where the codebase was already bad and I had to make some weird hacks to deliver a feature. In the end, a bad code is just... bad. There is a minimum quality threshold that you need to achieve, simple stuff, that's enough. You don't need to make a masterpiece, just don't commit any programming crimes..
Here's some nuggets - stay away from fancy data structures if you can just use a hashmap - try forming your code as a long recipe where immutable things are created and consumed - break out functions and classes very late, maybe never - add validation and types at the edges of your interface (input and output) and don't worry about the middle (if it doesn't mutate things or interact with the outside world) You should think of useful code as a little factory conveyor belt with machines along it doing meaningful changes to the end product.
So many people mindlessly commenting about this aging like milk due to the Crowd-strike bug. What you are suggesting does not align with what happened at crowd-strike.
Corpo guys goes on about the usual throwing together a bunch of technical debt and god forbid would code be reused and contributed to for the rest of the world. Got some real lizard people mentality in this one. :p
this aged very well over the span of a few hours
Very funny timing lol.
Core systems at massive scale cyber security companies supporting infrastructure for millions is a good example of a place where you probably don't want to write hacky code....
@@TroiCodesthe driver was literally filled with zeroes lmao
"Not over engineered" != "Bad code"
But we agree on the core principle: Unjustified complexity is a bad thing
I’m not just talking about things that are over engineered. I think sometimes when you need things urgently or when the business wants to experiment with a feature you can actually implement inefficient hacky code to prove out the need before building something more solid.
@@TroiCodes
I think we have a different definition of "Bad Code"
I think complexity, feature set and refinement has nothing to do with "quality". In my opinion, the code is "bad" if it does not fulfill its purpose. A prototype's purpose is difficulty evaluation and experimentation. If it is not meant to be relied on or it's easy to replace (with well defined interfaces) while it provides insights to an unknown area, then it fulfills its purpose.
On the other hand, if a piece of code is well documented, well tested and refined, but it fails to be a stable foundation for future features, then its bad code. You don't gain anything if you have to rework most of your foundation to implement a simple feature.
Documentation, tests and uniform coding styles improve the Time-To-Understand and can help increase the "quality", but if the code is "bad", then its like a barely functioning car with all the luxury features: It might not always stats, but at least its cold in the summer.
When you need something urgently you contract technical debt.
"poorly abstracted" - I would definitely take "not abstracted" over that! Code with a lack of abstractions, i.e. very procedural and lots of repetitive code, that's the best "bad code" in my experience. When the time comes, it's so easy to sail through that code and create very good abstractions based on the information the code is presenting to you.
Good point! Honestly, that would have probably been a better way to word what I was getting at. Not everything needs to be built to solve a ton of use cases. You make a great point as well that code that's not abstracted is a great starting point for building abstractions ontop of when the time is right since you already know exactly how you'd want to consume said abstraction.
To everybody commenting, "Worst timing, lol!" The target audience for this video obviously isn't people writing kernel-level security software that powers half the internet.
It's for the 15 person agency that will get 3 chat requests per day, that will never scale to need millions of concurrent requests, and if they do, that's a very good problem for them to have (and at that point they can throw money and developers at the problem).
This is the worst timed video of the year
Very agree- no point in building an api system with a hyper-accurate token bucket if the whole thing is in-house and called a grand total of once in the code.
That sounds oddly specific haha. I totally agree!
@@TroiCodes I find that oddly specific examples tend to drive the point home more than generic examples.
I think a better term will be "Imperfect code". Bad code gives negative vibes, such as "if you change this code, the app crashes for some weird reasons".
Often times we waste time by perfecting our code, which hinders us from building something meaningful. The opposite is to write really convoluted and obfuscated code. It may help you in achieving your short-term goals but it may not be long before you regret it when management starts to question why every minor UI change takes a few days to complete. Only experience helps you decide the best trade-off.
maybe it's more accurate to say it like you, but i would not have understood it as well as a junior developer. i feel disgust at myself when i write something i know could be better, and saying it with a more negative way lessen my apprehension of doing it. maybe it's too personal, idk.
That was the goal! I have been talking a lot about this in feedback sessions with more junior developers which is why I phrased it like I did. I agree "imperfect code" is a much better term for what I'm describing but I don't think it hits home quite the same way "bad code" does for more junior engineers.
A developer at CrowdStrike took your advice.
The simplest, dumbest code that gets the job done is the best imo
This aged like milk in like a day. You: ah yes write bad code... bad code: takes down half the internet with bluescreens.
recommended aboutt to go wild with this one
Thank you for inspiring me to code more and i have realised when errors occurs i am able to sort the errors and this makes me feel that today i have learnt something new.😊
I agree with the sentiment, but I think you’re describing is “mediocre code”.
Bad code is often over engineered, where the wrong tools have been used and is broken with lots of barely understood edge cases. It’s code that provides negative business value over time.
welp
this aged well.
"yeah so we're going to deploy a scalable sharded database over several kubernetes clusters with multiple caches for performance"
"dude we are storing literally fifteen kilobytes of data here. why"
As I've evolved my programming skills, I have noticed that the more organized I develop my systems, the easier it is for mantaining them. The only situation where "bad code" was a proper choice, was in situations where the codebase was already bad and I had to make some weird hacks to deliver a feature.
In the end, a bad code is just... bad. There is a minimum quality threshold that you need to achieve, simple stuff, that's enough. You don't need to make a masterpiece, just don't commit any programming crimes..
Here's some nuggets
- stay away from fancy data structures if you can just use a hashmap
- try forming your code as a long recipe where immutable things are created and consumed
- break out functions and classes very late, maybe never
- add validation and types at the edges of your interface (input and output) and don't worry about the middle (if it doesn't mutate things or interact with the outside world)
You should think of useful code as a little factory conveyor belt with machines along it doing meaningful changes to the end product.
Great video; my philosophy is as long as you write tests, we can always come back to it later and make it better if needed.
so funny to watch this now
You’d love me. Bad code is my forté
So you’re the one who inspired the the intern who pushed bad code from crowdstrike!!! 😮
Jk 😂
Just bad timing I swear LOL!
So many people mindlessly commenting about this aging like milk due to the Crowd-strike bug. What you are suggesting does not align with what happened at crowd-strike.
i think it might be better if the “bad code” is quoted. 😀
Cheeky flex in there (~3:15)
I agree, you learn from your mistakes, get better like AI but keep the human element.
It is very difficult to write good abstraction that aged well.
Corpo guys goes on about the usual throwing together a bunch of technical debt and god forbid would code be reused and contributed to for the rest of the world. Got some real lizard people mentality in this one. :p
if its good its not bad, so you are really saying people are wrong about what code is bad
let badCode; badCode = !badCode
Error. badCode not initialized