Your January example highlights a deeper problem: individual software developers not thinking about the code they are writing! Why were there no bounds checks? In the case of January minus 1, it's not enough to wrap to December, but also subtract one from the year (see...this is where you need to actually UNDERSTAND WHAT YOU'RE DOING). Sadly, this is lacking all too often, and is the reason we see the same problems time and again (buffers, memory mis-management, and so on). Slow down, take a breath, and check what you think is happening, is actually happening. I rarely see devs hand-execute their code, or consider program flow. Great videos! Subbed!
full agree! write more code dont means more slow,but more readibility! and hype of new stuff....like all javascript new....if you can do it with 2 or 3 for()....more easy to understand and change than map().thing() etc....and one line stuff is near impossible to debug! i really love this chanel!
An example given clearly with description and I like that. Your current wounds are my 30 yr old scars. I like these series of vids you've done - thanks.
These are good examples. Another one I learned long ago, and will use when conducting interviews - Know when it's "good enough". Something with all the bells and whistles that runs as fast as possible can be worthless if it misses a critical deadline, when speed and the bells and whistles were not part of the requirements. I will also add a personal comment here - the terminology of "Software Engineer". A vast % of people (I would even say a majority) in the industry are coders or programmers, not software engineers. While Software engineering is not the same as mechanical, chemical engineering, etc, many of the same principles can apply about how we design, build, test/evaluate, and manage our products, and there are a lot of people in the industry who know little to nothing of these principles.
When you write code you must think what is the purpose of the code. I create the code where there is a primary function and a secondary. Primary could be designed for speed or designed for easy logging. Could also be designed for readable in the logging files or designed for being robust. Designed for speed means the code will be unreadable, but I compensate that by creating a second function that does exactly the same but human readable. In the code you can self-check the code however I do not use unit testing in this case. There is no point in wasting code that used not used in your working program. Designed for logging then I use the logging itself as a way of commenting. The idea is to modify the code in such a way that the log files is telling a story. Design for readability means that you design the code in such a way where the code itself becomes the story. Everything is written in such a way that you can predict what the code would look like when it got called and all code that is going to be called. You do that in choosing different naming. Designed for reliability then the error recovery is more important than the functional code. You don't want life support suddenly crash when you get a negative number 🙂 The error recovery should then not only report but also explain why it crashed to logging in one line.
1. Write code that is self documented, and consise. 2. Master a syntax, is easy and will give you more flexibility to understand and master it all, IE, master OOP, C#, Typescript, and Java will be hecka easy. 3. Understand structures, in code, it simplifies structure. 4. There is no good developer. These practices are gained, and mastered. Everything changes over time. 5. DO NOT TOUCH WORKING CODE!!!Delegate it to a simple task/ library
your first item: Kernighan's Law Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. (Brian Kernighan)
Your January example highlights a deeper problem: individual software developers not thinking about the code they are writing!
Why were there no bounds checks?
In the case of January minus 1, it's not enough to wrap to December, but also subtract one from the year (see...this is where you need to actually UNDERSTAND WHAT YOU'RE DOING).
Sadly, this is lacking all too often, and is the reason we see the same problems time and again (buffers, memory mis-management, and so on).
Slow down, take a breath, and check what you think is happening, is actually happening.
I rarely see devs hand-execute their code, or consider program flow.
Great videos! Subbed!
full agree! write more code dont means more slow,but more readibility! and hype of new stuff....like all javascript new....if you can do it with 2 or 3 for()....more easy to understand and change than map().thing() etc....and one line stuff is near impossible to debug! i really love this chanel!
An example given clearly with description and I like that. Your current wounds are my 30 yr old scars. I like these series of vids you've done - thanks.
These are good examples. Another one I learned long ago, and will use when conducting interviews - Know when it's "good enough". Something with all the bells and whistles that runs as fast as possible can be worthless if it misses a critical deadline, when speed and the bells and whistles were not part of the requirements.
I will also add a personal comment here - the terminology of "Software Engineer". A vast % of people (I would even say a majority) in the industry are coders or programmers, not software engineers. While Software engineering is not the same as mechanical, chemical engineering, etc, many of the same principles can apply about how we design, build, test/evaluate, and manage our products, and there are a lot of people in the industry who know little to nothing of these principles.
Great advice! I enjoy your content! Keep up the great work!
Thanks so much for the support. Always great to see your comment
My favorite thing is seeing a function in the code that I am working on that is only used once.
Such great tips :) and from experience, yes always peer review.. and test no matter how small the change 😶
Nice! Keep it up Sis! :D
1:10 the list comprehension alternative is very readable and still one line
:= is the walrus operator
[x := math.sqrt(num) for num in nums if x > 2]
Hey Dee, would love the document! Amazing content
Thanks for watching! I've added the link in the description
When you write code you must think what is the purpose of the code.
I create the code where there is a primary function and a secondary.
Primary could be designed for speed or designed for easy logging.
Could also be designed for readable in the logging files or designed for being robust.
Designed for speed means the code will be unreadable, but I compensate that by creating a second function that does exactly the same but human readable. In the code you can self-check the code however I do not use unit testing in this case. There is no point in wasting code that used not used in your working program.
Designed for logging then I use the logging itself as a way of commenting.
The idea is to modify the code in such a way that the log files is telling a story.
Design for readability means that you design the code in such a way where the code itself becomes the story. Everything is written in such a way that you can predict what the code would look like when it got called and all code that is going to be called. You do that in choosing different naming.
Designed for reliability then the error recovery is more important than the functional code.
You don't want life support suddenly crash when you get a negative number 🙂
The error recovery should then not only report but also explain why it crashed to logging in one line.
The last programming mistake was hilarious 😆
Good video. I started programming with basic and Pascal in the late '80s! If you could share that document it would be great! 🙂
Hey, thanks for watching. I just added the google link in the description
ZABEZPEČIT Doňa Jana RADOST Done já mám ODŽITO minulost to mě Ženě do SÍLY
1. Write code that is self documented, and consise. 2. Master a syntax, is easy and will give you more flexibility to understand and master it all, IE, master OOP, C#, Typescript, and Java will be hecka easy. 3. Understand structures, in code, it simplifies structure. 4. There is no good developer. These practices are gained, and mastered. Everything changes over time. 5. DO NOT TOUCH WORKING CODE!!!Delegate it to a simple task/ library
Another lesson to be learned: Never write code dealing with dates, times, languages, etc. yourself, always use a library!
PATHS PŘEVLEKY tak ODLIŠNÉ POHLAVÍ
NEdorozumění u Anděla SLOŽKA Michal Ví přesňě panty jiné VYCHYTÁVKY Interiéru Don Yegr Takového ZDRAVÉHO NEmají Dokončíme
your first item:
Kernighan's Law
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
(Brian Kernighan)
shipfast
NOOOOU PROBLÉM BUžIRKY
OD Boha Bez PŘIJETÍ Janku pořád Dokola Jedna Otázka SLYŠELS VIDĚLS POMOHL JSI? Nedělej sám sobě OSTUDU