Things I QUIT to be a better software engineer | Learn from my mistakes
Вставка
- Опубліковано 21 лип 2024
- In this video, I share my personal journey as a software engineer and the five things I stopped doing to improve my skills.
#softwareengineer #coding #tips
Timestamps
00:00 Introduction
00:27 Writing shorter code is not always better
01:42 Why chasing new technology may be a mistake
02:40 Are functions worth it all the time?
03:43 Project management skills are just as important!
05:13 The biggest mistake you can make!
Link to document here: docs.google.com/spreadsheets/... - Наука та технологія
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!
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.
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!
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.
My favorite thing is seeing a function in the code that I am working on that is only used once.
Great advice! I enjoy your content! Keep up the great work!
Thanks so much for the support. Always great to see your comment
Such great tips :) and from experience, yes always peer review.. and test no matter how small the change 😶
Hey Dee, would love the document! Amazing content
Thanks for watching! I've added the link in the description
Nice! Keep it up Sis! :D
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.
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
The last programming mistake was hilarious 😆
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!