Things I QUIT to be a better software engineer | Learn from my mistakes

[@paradoxicalcat7173]

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!

[@anttikarttunen1126]

Also, not all months have 31 days, and one even has only 28.

[@mynosycat]

Well, as an old timer developer (from Apple 1986) this is the first video of (x things I'd change) that is right on the mark... 100%. Congrats!

[@minteo1980]

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!

[@scottbeall2212]

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.

[@barrymunro6861]

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.

[@foo0815]

Another lesson to be learned: Never write code dealing with dates, times, languages, etc. yourself, always use a library!

[@olafbaeyens8955]

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.

[@sirfith]

My favorite thing is seeing a function in the code that I am working on that is only used once.

[@colinmaharaj]

So (only 1 min in your video so far) I am a C/C++ developer for many years, what I do with the more complex portions of my code is just isolate it in a function. Then I will write the higher level code using those high level function, be it functions that comes from the compiler, or O/S or written by me, I will not mix low level code and high level code. This is what makes it readable for me. If I need to call something like c = mask & 0x01 I may place that in a macro and give it a verbose name like ifisodd(char c), but the goal for me is not mix low and high level together. That said, my low level code may not appear readable, and I may not particularly format well. It just has to work when tested. 2:40 wrt writing functions, you may have a particular type that you may want to operate on. So in a case like that, Id use operator overloading to make the mathematical operations, then use the operations in a high level way later in the code

[@jefflindholm5695]

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)

[@mind_of_a_darkhorse]

Great advice! I enjoy your content! Keep up the great work!

[@codingwithdee]

Thanks so much for the support. Always great to see your comment

[@SaintChachki]

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

[@skjones91199]

Good video. I started programming with basic and Pascal in the late '80s! If you could share that document it would be great! 🙂

[@codingwithdee]

Hey, thanks for watching. I just added the google link in the description

[@FitNishM]

Such great tips :) and from experience, yes always peer review.. and test no matter how small the change 😶

[@ohwow2074]

The last programming mistake was hilarious 😆

[@CodeJourney_JAD]

Hey Dee, would love the document! Amazing content

[@codingwithdee]

Thanks for watching! I've added the link in the description

[@dankaa6livedona448]

ZABEZPEČIT Doňa Jana RADOST Done já mám ODŽITO minulost to mě Ženě do SÍLY

[@Adnan_Inspires_Official]

Nice! Keep it up Sis! :D

[@karihardarson1234]

Excellent advice! Thank you.

[@joshua43214]

As an end user, the biggest flag for bad programming is importing dependencies. As a bio-informatic scientist, I use a ton of open source packages as part of my job. Most of these are not written by professional engineers, but by other bio-informatic scientists who fancy themselves to be engineers. flags start going up when I see a package written in Python, if I see dplyr, I know I am in for a hot mess and ending up in dependency hell. The only thing worse is seeing R code using tidy. Please people, keep this stuff to yourself.

[@dankaa6livedona448]

PATHS PŘEVLEKY tak ODLIŠNÉ POHLAVÍ

[@dankaa6livedona448]

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

[@joseville]

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]

[@chrishabgood8900]

Haaa, 11 months for a bug to show up.

[@dankaa6livedona448]

shipfast

[@dankaa6livedona448]

NOOOOU PROBLÉM BUžIRKY

[@dankaa6livedona448]

OD Boha Bez PŘIJETÍ Janku pořád Dokola Jedna Otázka SLYŠELS VIDĚLS POMOHL JSI? Nedělej sám sobě OSTUDU