This is my opinion after almost 20 years as a professional software engineer: you can’t know if you want to work with someone until you’ve actually worked with them. Technical skills, soft skills, and research skills are all equally important, but modern interviews don’t really test for those things. Instead they typically only test your ability to solve a logic puzzle under severe time pressure while someone who already knows the answer is judging you and failure means the loss of a literally life changing opportunity. That kind of pressure, and the kinds of puzzles presented are… atypical, at best, of the day-to-day job. Giving a good interview is a difficult problem to solve on both sides of the table.
Time estimation is hard, even for experts on a subject ... aaand most people have an optimism bias. Overestimating by a factor of 2 is a very good start :) en.wikipedia.org/wiki/Optimism_bias
The first one can be prone to misunderstandings IME. I don't remember the exact words right now, but they were like "readable code is better than clever code", in the sense that it doesn't really matter how technically impressive your code is or how many lines of code you "saved" with it, if in the future no one but you can debug it. I say "in my experience" as nowadays I struggle with other's code exactly due to this reason: By trying to save "lines", you make your code harder to understand. Less code is not about less lines.
The second advice actually applies to almost ALL projects in life. I am learning to code as a hobby, and as a means to make my own apps/devices for my own personal use. I don't intend on getting a job as a dev. That being said I have MANY hobbies. One of which, is cars, and modifying them. As an old mechanic once told me: "Find out how much money and time you plan on spending in your project car, and multiply it by 2. That's two thirds, of what it will actually cost you." he was so right. :D
My controversial opinion is that, regardless of being new or very experienced, a good programmer is flexible and willing to experiment outside their philosophy. Cause only Sith deal in absolutes.
my cs prof at university once said something which always stuck to me: "Programming is the art to tell annother human being what you want the computer to do" and I think this is so true
@@cdunne1620 No, code is for human eyes as much as it is for machines. Programming is a professional and collaborative work, not some kid in a hoodie typing away. Anyone writing code has to keep in mind that others will use, maintain, and build upon their code. There's a reason why legacy code and spaghetti code are a problem.
"I only have about 5000 rep on Stack Overflow, so my opinion really doesn't matter very much" - I swear I watch your videos just for the satire at this point lmao
That was satire? I thought he was saying that the people who consider themselves stack overflow insiders would have much higher numbers and not see 5,000 as a big value. I'm around there too and it feels like I often see people with 10x my score blowing by, especially anyone that's a mod or a subject expert.
The opinion about not needing a college degree is very US centric, as in most other countries you can get a degree without getting any debt and often also without any side job.
I think not having a degree only works really well for certain people - those either very lucky or very good. I think I'm a pretty reasonable programmer (although my opinion of my skills goes down as my age goes up!) but my career has been quite mundane and I feel I paid an enormous opportunity cost in not getting a degree until I was 50, when it's almost too late to use it. I tried 3 times, but I flogged myself so hard to get good marks due to the chip on my shoulder I kept burning out and dropping out. I think I could have had much more interesting jobs if I'd got the stupid piece of paper when I was meant to - ie the start of my career. FWIW I didn't learn anything about programming that I hadn't already taught myself more of in all the times I tried uni. I did learn new stuff in all the math subjects, but I haven't had to use it yet. I suspect if I knew it better, like I know programming, I'd use it a lot more - the whole time I was doing stats or linear algebra I was thinking "you must be able to solve anything with this stuff" and promptly forgot all of it after the exam. So I don't think you need a degree to be a good programmer - I think that's a matter of how your brain works and if you have that sort of brain you'll just want to do it anyway, but I do think you pay dearly for not having one in opportunity cost.
Not a programmer, I'm a mathematician, but the comment about upper education really resonates with me. If i had not gone to university, i would have not gained the mountains of insight from profs, succinct explanations, had nearly as many helpful peers, and i would never have been able to write anything close to the scope of my undergrad thesis without the supervision i had. If i had wanted to understand something like "hyperelliptic curve cryptography with genus 2", i would have been bumbling through papers and stackexchange posts for weeks, but my prof explained it wonderfully within 2 lectures. The sheer condensed knowledge from people with literal decades of experience in it isn't something you should just forsake as being "easily googlable". I really despise it when people say things like "university is useless", because it's just a certain type of learning environment that might not work for you, but it works wonders for others. Google is a library, not a professor.
Mathematician turned programmer here, from teaching maths to teaching web dev. That's exactly right and what I always tell my students, particularly ones that act shy around class and don't shower me with questions. This isn't universities in the 1800's or 1900's. You're not paying for access to the information I'm giving you - all of it is freely available on Google nowadays, and more. You're paying for me to stand there cracking jokes and breaking down layers of abstraction into understandable and relatable concepts, and to separate the wheat from the chaff for you. Of course most people could learn everything on their own, but that takes a lot of time, and time is everyone's most valuable currency.
@@HichigoShirosaki1 you'd be surprised how completely but confidently wrong it can be when explaining math topics or providing even the simplest of proofs.
@@HichigoShirosaki1 Autopilot on planes has been better at everything a pilot can do for decades now. But they're still there because most people distrust machines. And using AI isn't as intuitive or effective once you get past the trivial introductory level on most topics, and it needs very careful steering if you want fined tuned answers or very specific information. AI just makes my job easier, not moot.
I have to remind myself of that all the time when I'm doing hobby projects. First focus on getting it done, after that, it can still be optimised, if needed.
so this is like saying "done is better than perfect" in another way, and yes i couldn't agree more, optimization is necessary when your app has reach a bigger scale of users.
This is an old saying that’s originally aimed at the perfection of a product/creation. I believe a famous artist was referring to a statue at the time the saying was quoted.
28 years of experience. OOP was the cool hotness when I was a student in the early 90's. Encapsulation has its place, but most problems don't need it and it tends to obscure the code from the solution. The more I write code the less I write programs with OOP patterns.
this, man! It's a neat idea but YOU DO NOT NEED IT. Also in say Java, if everything is an object, nothing is (it has no meaning). There should be exactly one and only one language construct for each aspect of programming: Encapsulation? -> Modules Inheritance? -> Subtyping Doing stuff? -> Functions Storing stuff? -> Structs Guess what happens if you try to use one tool for everything? Exactly! You need to invent dozends of useless and dumb patterns to make sense of it. Until this day, I have not fully understood why you would need a "Factory"-Pattern ... Classes are egg-laying wool-milk pigs (a german proverb for something which claims to do the work of several specialized tools), just like MS Excel and we all know how good that works for building reliable systems
I guess the language in itself is just a problem of syntax. If I want to order a beer in Japanese, I just learn how to order it in Japanese. The problem are Frameworks. In Javascript, the struggle is more about how to identify similar or identical concepts between Vue, Svelte, React, Angular... In Java, Spring Boot is really cool, but there the struggle is to find the superclass of the superclass someone else just injected into your constructor. I find myself more digging in the repo than actually writing one line of code.
@@MCRuCrYeah, you do not need it if your program consists of 1000 lines of code, but when it reaches 1.000.000 lines of code I found OOP to be greatly beneficial to me.
Damn, I actually like the speed of these videos. I hate watching tutorials where they type everything. I just want the core concepts. I end up using the arrow keys to jump giant chunks of the tutorial.
Ain't nobody got 1 hour to go through a tutorial. Especially not experienced devs who just want to get the idea and fundamentals of topic in shortest time possible. I completely disagree with people criticizing this channel for being too fast or not going into depth enough. For me this channel is a blessing and if someone feels like this is too fast and confusing, you probably need to go watch those 1-2 hour long tutorials with typing. People should understand that not every video about programming on UA-cam is made for beginners. If you can't follow you probably need to mature more as a programmer and come back later so you could actually value this awesomeness.
Opinion: Every time someone says "We need to get better at agile", what I hear is: "Agile doesn't work for us, it is causing stress in our company, but we'll keep pushing it anyway because it is trendy and will work somehow".
I think the core tenants of agile should work for *almost* every company. The times I've seen it not work is when it is pushes as a narrow approach, e.g. you *have* to do paired programming and have 100% unit test coverage from the get-go (or else your fancily compensated agile coach will tell you "you're not getting it").
@@MrEdrftgyuji This... I really felt it. My life was wonderful, I enjoyed my work, and then agile with 2 week sprints ruined it. Now I feel trapped and frustrated.
Oh so much agree. Agile is like a communism it may look like a good idea on the surface, but it is impossible to implement in any complex enough environment.
I have total respect for developers who are self-taught. I went the university route (got a masters in CS) and I met some pretty talented devs and a lot of horrible ones. If you want to do it, you will find ways to reach your goals, degree or not.
I'd say it's not about getting the actual degree that matters (i.e. the physical paper and graduating) but more so about the structure path school gives. yes you can be self taught (I am) but I would suggest getting your hands on multiple syllabuses and books for computer science and learn what it is that type of degree is trying to teach. the self taught path doesn't have to be like wondering in a dark factory with a weak flashlight
@@jamesking2439 Its not stupid. When I started in the early 1980s I had an arts degree and not a CS degree (my first 3 years of College was science/math, the next 3 were arts). I knew I was ignorant of a lot of things about CS, so I went to a university bookstore and bought text books in algorithms, compiler design, data structure theory, etc. I spent my spare evenings studying for the next 4 years, and it changed how I approached programming. I don't think I would have done as well without the advanced math, but I was taking Engineering level Calculus at a Community College when I was in 12th grade of high school. So math just wasn't an issue for me. HOW you get the knowledge is not important, THAT you get it IS important.
I like python & Kotlin because they allow you to use OOP when it's really beneficial and don't force you to do it all the time for everything like C# does so, most of the time you can stick to simple functions and modules.
explain to me how you can use python. the lack of brackets drives me insane. ive written things in python, had no errors pop up, dosnt work. send it to friend, he sends it back, no visible changes, it works. python spacing is black magic and i dont understand it
@@johnathanrichardson the lack of brackets is liberating :D once you get used to it, they will drive you crazy elsewhere :P I hated it at the beginning, but then for one big project I gave it a shot and now I love it. Just use some decent IDE like PyCharm and not that shitty VSCode.
As far as a computer science degree goes, I'd think what's really overlooked is the mathematics and logic skills that the graduates of good programs have. Many degrees require calculus 1-3, linear algebra, statistics, discrete structure logic, algorithm design, etc. I can tell you from personal experience companies that are designing products and solutions for important STEM fields aren't often hiring self-taught programmers because they lack the needed mathematics, scientific, and low level systems knowledge that are required for those positions. If someone has no interest in working in the STEM industry and just wants to make mobile apps or websites, then no, a computer science degree is not worth the time and effort, but, if they do, then it's pretty much required. Computer Science degrees were never designed to make app developers, that's what coding bootcamps are for. CS degrees are designed for the development of scientists who specialize in computer utilization. Telling people, especially young people, an incomplete and biased take of, "College is bad because I didn't need it to get my job," is misleading and dishonest.
I would add that education sometimes knows better what you will need and teach you subjects that are not obviously relevant and that you would overlook.
yeah, most software is easy web+db stuff and they call themselves "fullstack developers"... I know a few more-than-full-stack developers and for them this web+db is just frontend for extreamly complicated systems using the said math. + robotics, elecrical, embedded, heterogenous systems...
Oh yeah, as a self-taught programmer myself, I shy away from hiring "self-taught" programmers. Though there are a lot more factors to that consideration than lack of proven scholastic aptitude. I doubt I will ever take my two degrees off my resume, no matter how much field experience I have. The biggest difficulty I would have in finding a good mid-tier programmer is weeding out rogue programmers - they crop up more often in "self-taught" labor pools than formally trained. That said, when looking for a high-tier programmer (I like to think I fit that bill) I want someone who can tell me what I don't know. I want someone I can hand the project to, who communicates exceptionally (that absolutely applies to readability of code) and not need to question their decisions, in which case a self-taught programmer is indistinguishable from a formally-taught programmer.
I'll add a counterpoint to this from my point of view (for reference, I'm a self-taught audio plug-in dev, which requires a LOT of mathematical knowledge about dsp and a fair bit of low level programming knowledge) Pretty much everything I had to teach myself (especially regarding maths) was the same as what they teach in college/university and its something I often wish I did, not because it would be beneficial for a job but because it lays out a linear easy to follow path for learning this shit, however There is absolutely zero doubt in my head I can't just learn the same things by myself if I wanted to, because I already have been to a large extent and that similarly, for someone with enough determination to learn for their respective field, they couldn't do the same. From a purely academic standpoint, going to college definitely is NOT obligatory. You can become just as proficient, if not more, by literally spending zero dollars if you want. The biggest advantages having a college degree offers are: 1. An environment where everyone wants to learn the same things as you 2. A well thought out path for you to follow to gradually learn all of the stuff you need to know 3. Actual, tangible qualifications that are universally recognised. If an employer wants to hire someone, chances are them having done some form of degree will at the very least ensure some base level of skill without having to interview them. For me the disadvantages of the insane financial requirements + time and most importantly, mental strain far outweighed these advantages, which is why I chose not to go down a traditional education path but obviously that doesn't need to apply for everyone, but making generalised statements that you do or don't need college are both definitely very misleading
@@liamrobertson2670 somewhat, it's supposed to counter against coders making too sophisticated code for their own ego instead of making it functinal and readable
@@liamrobertson2670 Code should (amongst others): - be read like plain english - be straight-forward and predictable - be easy to alter/approach according to new requirements - be composed of/itself be simple block(s) - be explicit in error handling (+ great recovery mechanisms) - use the simplest concepts and structures to express complex relationships - be greatly covered in testing (unit testing/integration testing/E2E testing) - scream in the form of broken tests when core functionality is altered - not allow for buggy logic to be described (intensive domain modelling) The desired effect of the code should be one of safety and stability - for the customer, but also for the programmer - it should not make us be afraid of releasing/breaking prod/introducing subtle bugs because of convoluted logic/touching it because it's so complex. When you add all of the above together, "boring code" seems quite mean - but it is actually a great compliment - it allows us to focus on the important bit - the problem itself, and not the implementation detail which is the code.
That point about writing comments that explain _why_ something exists and not _what_ it's doing was such a good point for me. I've always had a hard time trying to figure out where I should put comments and ended up either putting them everywhere or nowhere, but in hindsight this is a super obvious rule of thumb to follow
Comments are for communication. Use them if your code is hard to understand. Before you use them though try to make your code easier to understand. If your comments contain no additional info (just explain what’s obvious) they are a liability.
@@ssssssstssssssss yeah well that's the issue... often idek what is obvious. ig a good way would be to get someone to look at your code and go "what the hell is that"
@@ssssssstssssssss comments lie. Instead of writing a comment, try to get code that negates what the comment was going to try and explain. If you can’t, then put a comment. But if you find yourself thinking of adding a comment, that is when you need to go back to writing the code. Code doesn’t lie, comments do, and no one ever updates or removes comments so they become bad actors over time.
Here’s an example of commented code that I write: my_wait_avail = asyncio.get_running_loop().create_future() if self.wait_avail != None : # somebody else using this socket -- wait till they’re done await self.wait_avail ♯end if assert self.wait_avail == None self.wait_avail = my_wait_avail # claim ownership of socket Now, would you suggest getting rid of those comments, or not?
@@lawrencedoliveiro9104 yes. If any anything, your methods and properties need better names. It’s like order of operations. Commenting should be the absolute last thing you do. Renaming variables should be done far sooner than leaving a comment.
The value of a degree is not so much about technical experience - ivy league universities teach largely the same content as other universities, but the value of hiring a graduate is knowing they passed the intense screening and application process. Same holds true for someone with a CS / EE / SWE degree. You can be sure they had to learn the difficult things they wanted to avoid, had to deal with stressful deadlines and full schedules, and had to deal with group projects where people are on different levels. With someone self taught this is not always self evident, and in my experience, a lot of them lack the teamwork and soft skills of graduates.
There is obvious selection bias here, because people who graduated and people who didn't weren't the same at the start. These two grouos weren't split randomly. Other things being equal, someone who is passionate about IT is more likely to pursue a degree from the start. But it's not that they owe their technical curiosity, their knack for analytical thinking etc. to that degree - the causation runs the other way round. It's like people who play basketball being taller than average. Statistics don't lie, right - "you wanna get tall? Join a basketball team, clearly it helps". Well... :)
Even this isn't 100% accurate. Yea you are technically taught the same subject matter as other less competitive programs but the depth in which the classes go in and the type of assignment you are given are on a whole new level. I thought my CS 101 was tough until I looked at my high school friend's CS 101 at a top engineering/cs program and it was a different beast
With the whole "lazy programmers are the best programmers" section, there have been times at work where I just get up walk away from the computer and take a walk for about 10-20 minutes, and come running back because an idea popped into my head. Luckily I work from home at the moment and didn't have management questioning why I needed to take a walk. A lot of programming is about creative problem solving and just sitting at a desk and typing away doesn't always help once your deep in the weeds in a program or even a piece of functionality.
Definitely agree, though with a slightly different rationale. A lazy programmer will frequently find a way to automate something that they don't want to deal with (within reason of course). While working as a research assistant, I was asked to build some simulation worlds that would have taken me weeks or months to do by hand since the world creator for the program we use is.... Less than good, and hand-coding all of the walls would take forever as you're working with object dimensions, rotations, and absolute positions rather than to-from points. So I took a couple of days and wrote a script that let me hammer out a single world with 70+ individual wall segments in about 30 minutes. I later expanded it to work with a couple of other things that were a complete pain to do by hand (for instance, some animated models required their movements to be timestamped with each waypoint rather than allowing them to move at a set speed, so adding or adjusting a waypoint or speed meant adjusting EVERY waypoint and timestamp with a new set of calculations) and saved myself and the lab a bunch of time and effort.
Absolutely correct. I’m retired now, but as a programmer for over 20 years, I found that a midday walk helped me clear my mind when I was stuck on something. Heck, a midday nap helped a lot too. One time I took a nap, and I had a dream with the exact solution I needed for my problem. Pretty sick to be dreaming in code, but at least it helped me when I woke up back in the real world.
Over the past 50 years, I've seen customers routinely make two deadly mistakes: 1. Proposing solutions instead of stating needs. When a user says, "I need a program to ..." I ask, "Where does it hurt?" That often gets to the heart of the matter. 2. Trying to make my job easier. I tell my customers, "Be unreasonable. Demand the sun, the moon, the galaxy, and a galaxy in the universe to our left. I'm an adult, and will tell you if something is infeasible."
Sometimes, going for the moon is actually easier to do than whatever "easier" thing the customer had in mind. I got that idea by watching the Corridor Crew (a yt channel) react to the moon landing from the pov of conspiracy theorists as an April Fools. Niko, one of the guys, said something along the lines of "actually going to the moon would've been easier and cheaper than faking going to the moon for that time". And I agree with you, people have the wrong idea about programmers. We don't look for answers, we look for problems. Finding solutions to given problems is what we do 😛. Constrainsts are the roots of creativity after all 😁.
The second one comes up a lot for me in the form of "It only needs to do X. But occasionally it needs to do Y, Z, W, and V, but those don't happen often so they shouldn't be a big deal." In software development, it doesn't matter how often something happens, the same amount of code still needs to be written to support it
As for that #1 - working with programmers for a while now. It happens many times that they tell me something's impossible or has to be done in an ugly way. Then I sit down and do research on my own, and go back to them with some ideas and suddenly it's possible. Maybe not exactly how I envisioned it, but it gives them a path forward. Not that they're bad programmers, but it depends on the type of person they are. My brother has been developing AI, and automated systems, and all sorts of stuff, but sometimes he just misses something that's obvious. Maybe tunnel vision? But I start asking him questions how stuff works and together we figure out the solution. I'm not a coder, it's just my job as a product manager to figure things out. I can't just let it end at "impossible" or "let me do the thinking just tell me what you want". So yeah, I don't think knowing how to code means that you can't benefit from others' input and ideas
All in all, the answer of almost every question in CS is basicly “It depends”. There are tons of ideas, design patterns, languages etc. and each of them is best for a specific situation that is defined by lots of parameters. How well you perform a task is directly correlated to how many of those parameters you considered right. And considering all parameters is just an utopia. So that, all I know is It depends.
Everything depends, doesn't it? The "fact" that 1 follows 0 depends on consent to three other "facts." Magic happens when we can discuss what it is that matters, why one tactic is better than others in which situations.
yeah im kinda tired of hot takes like "oop bad and it should burn down toghether with java" its like dissing a kind of food ingredient and tell everyone to stop using it entirely because reasons
I actually like coded testing when requirements are vague, or changeable. I write the tests to specifically cover what I've been told to implement. Then, I show the documentation of those tests to the product owner. If there is a change, or misunderstanding, I can update the test, and that will inform the change in the implementation
3:37 "Yeah i ordered 11 square blocks of concrete, but i only got 10 and a sphere for some reason" "Fuck! Uhhh yeah sorry about that, must be because of james, he's a new hire. We will quickly send the replacement"
2 Rules for dealing with customers: "The customer is always right" and "the customer never knows exactly what they want." Both statements are simultaneously true.
I agree. In my experience the customer has a problem, looks at the existing product which to them is a web interface. They'll ask for a change to the UI to get it to do what they need. When this gets to me (lead engineer) I don't have the context of the problem I only have a request for an odd feeling UI change. So my job is to coax the real problem out of the customer. Most of these problems are solved in the backend with no UI change.
@@ljones140 yep. "The customer is always right" is a contraction of the more exact statement, "The customer subconsciously knows what is right but cannot always tell you what that means."
The dude that said this channel sucks i felt that and you know why? Cause i was one of those guys years back when the channel was just angular and firebase commenting like that to every video of his lol. But i stuck around and I realized i had to level up to catch up with Jeff in other words experience is what i needed. His teachings are really for intermediate+ devs there is no hiding it.
Hmm I'd disagree that it's for intermediate devs based on my personal experience. As a beginner I've learned way more stuff on this channel in a short amount of time than any other channel on UA-cam. It feels like I've fast tracked my learning time using the short and to the point videos. It also forces me to do research if I don't understand something instead of being fed code to copy and paste into my projects without actually knowing what it does and why it does it. I know every one is human and makes mistake but ever since I've started watching this channel I just can't go back to watching 1+hour tutorials where they make typos and spelling errors thinking its good to show that stuff. Lmao it just messes with my ocd when I can clearly see the mistake or spelling error and they just continue with the video. So yeah that's my opinion based on my experience
Agreed. Even in some videos about subjects I'm familiar with, I watch it video and think "well, that was a nice overview in a very short time". I'd much rather watch a shorter video that makes me interested in the subject so I can read the docs by myself, than watch a long tutorial - sometimes with poorly written code - that barely helps when you actually use the language/tool/framework/etc.
I think a big takeaway is that even if you disagree on a topic or if you think code should not be done a certain way (like OOP) it is still important to understand the ins and outs of something you don't like, because you might still need to draw from it in the future or might even need to use it although you do not like it.
In my experience, 10X programmers are also about the culture where you work. I have seen hyperproductive programmers drop performance by 100X from micromanaging bosses, project leaders or agile coaches. Its depressing to see.
not yet a developer but i agree that working with certain people could boost your productivity by tenfold, but it only last long if its healthy for you
@@blackerhawk1508 consider pair programming… or get a 10X to break something down and explain it or… get them to show you how to get a new project up and running quickly.
Amen, well defined tasks and clear guidelines for what is needed usually get done 10x faster including unit testing etc. That’s why private projects usually grow faster than what you work with 🤷♂️
I remember having an interview where they asked me about error codes within a system. I was able to intuitively break down the first error, but ultimately the correct answer was to 'Google it'.
My professor in mechanical engineering warned us about a similar interview question where you're handed a technical drawing and ask you what you think that is and if you're not immediately looking at the name of the drawing on the bottom of the page where normally everyone could see it you're out lol.
I definitely agree to the comments one and I think I wrote literally one comment in my code in the past few months because the thing the code was doing was not immediately obvious and it looked like that part served literally no purpose. It was a class that was getting SNSMessages from AWS via an API endpoint. The part with the comment was a try/catch block with a call to a Amazon supplied parse method for the incoming message Json and the catch block would return an http code 500 if tripped. Then I'd take the message json, re-parse it on my own, and process it by checking what kind it is and what's in it. At first glance it looked like the call to the Amazon parse method served no purpose, the result wasn't used for anything else, it just parses and then it does something else entirely. It was in fact a verification check, if it can parse that means that the message is legitimate, it's the right format, the certificates check out, and everything is good. If there's something wrong with the message it'd throw an exception that the catch block would catch and send back a 500. The problem is that the class it parses into is hot garbage that's a pain to work with so I just wrote my own but instead of verifying the message on my own I just used Amazon supplied classes for that only.
As as programmer in his 60s, I agree with your takes on things. I find OOP to be good for a certain class of problems, and I find inheritance to be a difficult thing to do really well, because there is so much of a tendency for programmers to do things that make inheritance hierachies make no sense (usually classes have code in common which quite legitimately belongs in a super-class, but I've seen SO many cases where common code that isn't related to a class is hidden in a super class and then actually called from both sub-classes and from non-related classes.. what a confusing mess!). I started out doing Structured Design in the late 1970s, and then switched to OOP in the mid 1990s. My take after all these years is very simple. Take good programmers and have them use any design method they want, you'll get good stuff. Take mediocre programmers with any design method and you'll consistently get poor stuff. I think the majority of programmers fit into the 'mediocre' category. I'm not saying they aren't needed, just that they need good programmers looking after them a bit. I think most of the insults thrown at OOP are actually insults thrown at bad programmers that just don't understand what NOT to do in ANY methodology, with the predictable bad results. Teaching coding is hard enough, but teaching wisdom about what to do and NOT do is incredibly difficult. I've met some programmers that seemed like the human equivalent of a brick wall. Unyielding, unchanging, resistant to change. The trifecta of terror. Good vid!
@@rbarnes4076 Personally, one of the better arguments against OOP and its design patterns is that languages shouldn't focus on making it hard-to-impossible to write bad code, they should focus on making it easy to write good code. Rust is a good example of a language which made it easy to make good (memory safe) code, without preventing people from writing unsafe code (anyone can throw an unsafe block around their code and do horrible things, but it's far easier to just write good code)
Spot on. A lot of bad programming stems from the Top > Down since corporate heads wanting to ship out their software asap while having unrealistic deadlines and expectations, forcing the Dev leads to opt for Oject Oriented languages to get the job done in a timely fashion. Combine short deadlines with a bunch of mediocre + bad programmers with unrealistic expectations and OOP, you get a bunch of spaghetti code with a ton of bugs that'll end up costing the company 10x as much in the long run than if they did it correctly from the start. Things get overly abstracted, functions with side-effects, and all that jazz it make it so hard to maintain and very slow to get new devs up and running with the code bases. It's just not a very scalable approach. OOP just allows for bad code design and implementations to seep into the codebase, but it also allows for faster development. It's a double edged sword, but if you have a great Dev Lead and solid programming team, you can get away with it and reap the full benefits that OOP gives you. Functional programming reels in the programmer, forcing them to design and develop better and more scalable codebases, but corporate heads hate the time it takes to get the products rolling and thus are very short sighted. It sucks because most jobs are looking for programmers with OOP experience, and most companies have most of their codebases developed in some OOP language. 80-90% of programmers are mediocre and don't push themselves to get better. They're just the guy working that 9-5 for a paycheck, comes in and just focuses on the small section of code they've been assigned, and only worry about whether that feature they worked on does its job without worrying about any inefficiencies and possible scalability/side effects it could create later on. From my experience, software developers that take the time to truly understand software design and the design of the codebases they're working in are few and far between, which is why a functional programming approach is so desirable since that mediocre 9-5 programmer can just work on that small section, knowing that whatever they implemented has a deliberate outcome with no side-effects.
A lot of the issues with OOP come from how it is taught. Most tutorials focus on abstract examples that bear no real relevance to real code e.g. "class Mammal" / "class Cat". They then go on to detailed discussions on inheritance, which isn't really used that much in modern code outside of a few small categories (interfaces, etc.). There is also a lot of confusing dogma and theory surrounding OOP that textbooks and some programmers focus on religiously - e.g. Liskov Substitution, SOLID principles. One of the best introductions I saw threw away all of that and instead did a step-by-step walk through for creating a "string" class in C++. Not only did it teach me the most relevant parts of OOP, it also made it clear to me straight away what the advantages and disadvantages are. Especially if you have ever tried manipulating strings in C versus C++!
@Sky Gardener oop is amazing for complex simulation stuff imo. Not so much business. If you're making something like a dwarf fortress style life simulator though I couldnt imagine doing it in anything but OOP. It allows you to rapidly scope out impact of features. Say you have something that you want to affect anything that walks on two legs-you dont have to remember all 30 biped races youve created, you have it affect the parent object type "biped" and call it a day. And if you create a new biped race you dont have to remember to add the new race to a list or whatever, its just automatically gonna do whatever bipeds do. In any situation where you are creating something with a ton of moving parts you WANT to interact in unforeseen ways OOP is the way to go. When you have a very clear limited scope of functionality that you want to be very efficient and streamlined, OOP doesnt offer much
I'm a newbie and I understand what you mean about OOP not being taught properly. In my course, we've been taught Java exactly with the animal/mammal example and all of us were so lost/confused when the time came to do java challenges. Still today I struggle to understand how a language like java is actually used in the real world...
The $100,000 in student debt argument is only valid for the US though. Most normal countries allow you to go to college without having to sell a kidney.
In india its pretty much the same, cheaper colleges are harder to get into cuz competition, and colleges with less competition are expensive Also, because college with high competition get more attention, their degree is deemed more valuable. So if you just want a degree for gaining experience in the field then tough luck, cuz you have to be an expert to begin with if you want it cheap. And if you take the expensive route, you degree is deemed useless
6:45 Come one... the point of the test is to be the specification. If the specification change the test changes so you can adapt code to the tests. Tests are needed EVERY SINGLE TIME unless you don't care about quality.
It actually makes even more sense in countries where lots of companies and institutions require certain degrees to hire someone (I'm in my third year of CS in France and it's definitly better to have one...)
Yes but there's also a lot less competition on the Job market for the IT industry. If you know how to code, you'll be able to rake a job in fairly easily.
@@akshaypendyala nope, Netherlands changed their system a few years ago, around 2100€ just to go to an university per year now, average study dept is somewhere between 20k and 50k
My logic behind getting the degree was that "if i dont enjoy my time working IT jobs, i'll at least have a bachelors to begin with" which helps ensure that i'm somewhat employable in general and that I can still support myself.
You and 90% of people, I'd say. I sure belong to that group, even if I ended up enjoying my time working in IT jobs, that was also my rationale for my bachelors/masters.
@@techtutorvideos You still pay years of your life. Of course in the long run that doesn't really mean anything, but it's hard to think like that when you're 18 years old and 3-5 years seems like a huge amount of time
@J Boss many positions arbitrarily put "must have a bachelor's degree to apply" in their job postings which automatically eliminates [most] of the people who don't have it. That's why having a bachelor's degree allows you to atleast apply for it without getting immediately eliminated.
There is a difference, you can tell if you did it, I have worked with so many programmers. It gives a wider perspective. Not necessary but relevant.
3 роки тому+52
The speed is perfect. I actually watch tutorials at 2x speed just because tutor is boring and slow. Man, the thing you wrap up in like 10 min, someone is choking viewers for an hour or so. Thank you and keep on like this lifesaver!
On the unit testing part, (I am a junior developer) there came a production issue to our team and to solve that we introduced some meta data to our cache, I didn't feel to unit tests the changes but since it is the procedure, we did and found out 3 more bugs that were somehow passing before introducing the meta data, and so it helped prevent future production bugs.
Your video format is the best. It's like the sparknotes of programming. I can quickly watch a video and immediately know whether I'm interested in the topic or not. I also always know what I need to research more on and what things I'm already familiar with and have a solid overview of what that thing is and why it exists.
One thing i definetly found out, espacially in less professional programming circles is people spend way too much time thinking about performance. They think about how to optimise their code into oblivion and while there are best practices for every language you should always follow (for example using StringBuilders over Concatination for very long strings in java), it's not always the most important aspect and as soon as you work with an external system like a database, the speed of your code will become your smallest concern most of the time. Most business applications are very fancy database interfaces. Therefore optimizing your database usage is a lot more important then whether or not to use a for loop over a forEach.
I also think you should first worry about getting a rough prototype and then refactoring, but have the discipline to NOT develop new stuff while refactoring (you can just jot down any ideas you get while refactoring)
I myself like to find out ways to optimize my code sometimes for fun as an exercise, but I must agree that nowadays unless you're doing game development it doesn't even matter anymore
"comments that explain why something exist tend to be the most valuable" Such a simple but great reminder, especially for people like me who get caught up commenting on what every bit of code does. Thanks Fireship!
About the CS degree... I've been working in IT (mostly System Engineer, but also programming) for more than 15 years without a degree. I've recently started studying computer science parallel to my job and I have to say while I already knew most of the stuff (at least what I've seen so far), there are a few concepts that are new to me, especially when it comes to "choosing the right tool for the job". In the past I might have solved most problems thrown at me but not necessarily in the most efficient way. CS helps with that. Though I have to say that at least here in Germany, there is a lot of "empty information" that prepares you for an academic career but does nothing for you if you want to work at private enterprises. Also this "you must code my way" is definitely a thing. For example when implementing Quick Sort, our professor deducts points if you don't pick the rightmost entry as pivot though it has been known for a while that on average it's best to pick the pivot at random. This clearly discourages students from digging deeper into a topic and widen your horizon because it does nothing for your credits. It's just stupid. But all this being said, you could learn all of the stuff outside a university as well, IF you're not a lazy bum like me.
After seeing you mention the negative feedback you’ve received I felt that I should share this: I have probably gotten more value from your videos than any other in all my time on UA-cam. You have repeatedly shaved hours if not days off projects of mine. I also love your editorial and visual style. All that is to say a huge thank you!
But it's true that information on here is often packed as shit, I've been on some 3 mn videos pausing every 5 seconds and repeatedly going back this spending 15mn on that video lol
The job market is entirely built around looking for senior Developers in favor of new developers in order to pool talent. In theory this means employers get good programmers. In practice It encourages new developers to BS their way to senior positions.
Yeah, no one wants to take the responsibility of training new talent, which is why the industry is so starved for developers. Plenty of young talent who never gets the chance to develop their skills further, which leads to a lack of skilled software developers.
I noticed the opposite, people are hiring juniors because they think they can train them and they're cheaper! The older you get, the harder you are to find a job
@@elmotareal must depend on the industry, big companies can afford the junior guy maybe? In small teams, everyone is looking for rocket scientists with 3 lifetime of experience for a position which usually isn't that exciting in term of tech and pay. The imbalance between expectations employer/employee hurts sometime, especially when you see the candidates knocking at your door with a degree in google only and with a school project they couldn't finish... it is what it is ¯\_(ツ)_/¯
@@colombodoesstuff7653 So other developers have an easier time understanding the code, and also you might forget how your clever one liner worked and have to figure it out again.
I'm ok with "Clever" coding, so long as there's a super-simple comment, just so ANYBODY can understand exactly WHAT this crazy regular expression is there for :P
I disagree with this. Clever can also mean an abstraction that makes the code easier to read, removes some indirection, removes boilerplate or reduces duplication. All that matters is that the code is easy to read. If the clever approach is easier to read then use the clever approach. If the clever approach is difficult to understand don't use the clever approach.
@@whossname4399 The difference is in the programmer. There are programmers who write clever code, but their definition of "clever" is "I saw this neat trick/hack/shortcut in a project/repository/article and I now want to use it everywhere". They regularly use these tricks when solving online programming puzzles or playing code golf and now they feel confident bringing those approaches to production. Those programmers invariably write buggy and unreadable spaghetti code that will get refactored if not replaced the day after they leave the company. Then there are programmers who use clever approaches. They manage their time and expectations so that at the end of the day, their code is simple, concise, and as dumb as humanly possible while still getting the job done. These are the programmers who write stable, efficient, and maintainable code, and they finish their tasks while the first programmers are still burning the midnight oil Googling why their tricks stopped working properly in the latest build.
2:36 I don't know where this attitude comes from and I really think its super unhealthy for developers in general. The expectation that developers should love to spend their spare time on the computer as well, basically continuing to work for themselves, is really putting pressure on those who don't see this as a healthy approach to a job. I find it not surprising that mental problems such as burnout are so common among software developers. Sure, there are most likely a variety of factors in play, but I'm certain this is one of them. Programming is a hard and demanding job. It is impossible for a human to consistently deliver the same performance during an eight hour workday, let alone after that when you're expected to work on hobby projects. Having little to no time for regeneration is a recipe for disaster. Personally, I see programming as a tool, and nothing more. It is a tool to solve problems. Sure, it is a powerful one, but it's not the purpose of life. When I encounter a problem that I can solve with code in my work or personal life, I solve it. But I don't think coding hundreds of hours for the sake of coding is healthy nor is it actually that beneficial. In fact, I think coding in an experienced team with a more senior developer to mentor you is helping you out more than building the 623rd todo app with the 234th framework ever could.
Eight hours a day is plenty of practice, especially if you're solving real problems for real customers, and you take the time and effort to learn the most effective ways to solve those problems.
@@Rsharlan3 don't think the issue is working on your off time as much as passion for the field. A lot of people who only do it as a job might be less interested in getting better. Most of the best people I work with were interested in the field prior to working in it. Once your in it though you should have a life/work balance though.
The main issue I encounter with devs who don't love to code is that they are also the devs who write unreadable code. In their mind, if the code works, their job is done. Sure, there are exceptions, but a majority of the unpassionate devs are like that.
i think it is even MORE unhealthy to be doing something you don't enjoy. It's fine if you don't code on the weekends due to lack of time or something, but because you just get tired at the thought because it is "hard and demanding" then idk. Do something you like?
engineer is a degree tho... you can have one in each of the label you mention. If you mean we should be more cross dev, yeah that's called fullstack isn't it? I'm not a big fan of labelling and semantics...
Please don't say fullstack... It already takes a lot of effort to master backend or frontend.... I don't understand people calling themselves fullstack developers with less experience as they built a project (ToDo app). Technology is changing constantly is another factor. So, I am still trying to figure out, how a fullstack developer can be defined.
On the Customer: I've never said no to a client, but made my clients understand why it was a bad idea / what the implications are.... And 99% of the time they listen, and the 1% left comes back a few month later .... waiting for their "I told you so"
Interesting to learn that pple think that your content is too fast, I watched one of your videos the other day and was amazed to see how many concepts you put in 5 min. Going this fast doesn't make you fully grasp the concept but it gives a good overview and makes you aware about the options available to tackle an issue. In my opinion, it's great to guide you in your research for the best option...
I like your speed. If it's a completely new topic it can be hard to follow but if I just want a brief summary or a refresher crash course it's amazing. You fit a lot of quality content in a short amount of time
Re: Unit Tests. It makes sense in some cases, for example: creating a library of math functions with interdependencies. Ensuring those math functions all pass a series of tests is beneficial and will save time and headaches when further along.
Everything needs to be tested. Otherwise what's the metric of knowing that your code actually works? The difference between a QA and a developer is that QA should be thinking of edge cases where multiple functions/scenarios interact. If your code fails my first basic test, e.g. 1 + 1 = 2, then we know you have issues with coding.
Unit tests don’t make sense for hello world program, but for anything long term they save millions of dollars to companies. With bigger projects you might think you understand part of the code you work on, but they you get 10 unit test fails and you start seeing what you did wrong.
Games are somewhat tricky. I write tests for "library" code: math functions, file parsing, memory allocation, lock-free queues and regular data structures and fibers. IME, it's the lower / lowest level code that needs to be the most battle-tested. Fibers (aka coroutines) are key to make identical and not have subtle differences in assembly behaviour when porting. The case where you switch to had to be handled, and there's a test in the test suite for it. Pretty close isn't good enough. Get it wrong, and you have an opaque crash in the fiber's start function, and it happens *after* the function returns. You can't really reason about that if it's intermingled with regular engine code, but it's a trivially reproducible if it's segregated into a 20 line test.
2:13 Well, you are not using OOP then. You are just using objects in your programming. When people say that OOP is shit, they mean Java-style where every function has to belong to a class, inheritance & stupid design patterns are everywhere, lots of mutable state, etc.
And that (i.e. Java-style) is object *oriented* programming. So OOP is, indeed, shit. Objects are fine as one tool out of many in a programmers skillset.
That really depends on how you do things. for example, in Java Android programming, you can inherit from Fragment to make fragments or make an abstract class that inherits from fragments to introduce fragments with extra functionality, those are both completely reasonable. In many Projects people make a DB class that handles all the db stuff, encapsulating that into a single class is very handy. OOP Can definitely be horrible, I've seen that many times, but that's more down to the dev.
Well, he's not using Functional Programming then. He is just using functions in his programming. When people say FP is shit, they mean Haskell- and Agda-style, where every variable is immutable, monads and stupid syntax is everywhere, lots of copying, etc
TL;DR: Testing is one of the most valued items you can add to a project when done right. 6:35 - 8:20 - I recently got a requirement to get Sonar Cube test coverage up to 90%. I explained to the client that I've been on the project for less than two weeks, and I can only do positive testing (confirming what already exists as it exists). None the less the client invoked "contractual obligations" that I had to meet his requirement. Now they sit with a negative view of unit testing since it is tested, but they still receive unexpected responses (since I had no way to dig through 6 years worth of requests some with only a one liner acceptance criteria to test if the requirement is met).
Today this channel gained a subscriber :) somewhere I always knew that it deserved to be subscribed. Everything is sooooo quick, it's like learning and saving time, while making the video as short as possible no matter what. Also pasting code instead of writing is so much better.
I mean, that other dude's comment was also true. If you're hoping for a channel that guides you through the entire process such that you can do your own stuff, this isn't it. This is just a "get the gist of it" channel (thought I'd guess Fireship paid lessons are much more deep than these). For me, these are exactly what I want. I leave the video with a superficial understanding that is enough to kill my curiosity, without investing too much time.
@@cristhianeduardovelazquezc6130 I think you're missing the point. It's not specifically about the video's speed per se, it's the content itself that is "rushed", he could slow down the video all he wanted, and the specifics of implementation, further use cases, and detailed rationale still aren't there, because that's not what this channel is about. Again, because this is the internet and I know someone will completely misinterpret my words, I feel the need to reiterate: I don't agree with that comment, but that doesn't mean it didn't have its merit, everything the dude said is true, it's just that no one who subscribes to this channel expects anything else...
depends on why are you practicing it, if it's just by joy it's not, if it's for beeing a better programmer o gaining a "faster mind" i guess it is not a waste of time neither. But it wont get you familiar with all the new technologies o will make you related to a specific business.
6:19 Back in my first 3 semesters of programming in college we had this teacher that quite literally will turn down your homework if you didn't write it the way he does it. At the time I thought it was because the way he was teaching us was the correct way, even when I noticed I could get to the same result in a different way, but because I feared to get all my hours of work turned down I had to write my code the way the teacher told us to. He was not very approachable whenever we had problems with our code, be it syntax or logic, as the moment he saw us writting in any way different than how he does it he immediatly turns away and tell us to rewrite the whole thing but in the way he told us to. This made for classes and projects to be very tedious and frustrating. At the fourth semester we had a different teacher meant to teach us higher level programming skills, and that teacher never cared for how we write our code at all, sure, he will teach us one way but once it came for us to do our own projects and homework he'll take the job in which ever way we made it, and the coolest thing is that this teacher was incredibly helpful when we got stuck with syntax problems and stuff as he could detect the problem by just looking at the code for a few seconds, regardless of how we were structuring it. This lead me to believe that the reason why our past teacher didn't want us to write the way we wanted was because he was lazy and didn't want to figure out our logic on the spot and rather just have us copy paste the code every time, but by hand, so we make it easier for him to understand what's happening, but not for us. I'm grateful for our latter teacher and the ones after him since they reignited my love for programming by teaching me the basics but leaving me room to do stuff in whichever way I see fit and explore options as I go.
It's also the difference between eastern and western teaching modalities. Eastern modality, you are often taught the one correct way to something 1000 times until you achieve mastery. And the Western modality, you stumble around blindly doing a thousand different wrong things, until you achieve mastery. Great things are achieved by Masters and both modalities but it does appear The Western modality provides a creativity and lateral thinking advantage. However a lot of people give up and quit.
I think that teacher being lazy part could be really true. I had a completely different experience in university. We were just given an assignment and a few slides which generally explain how to solve somewhat similar problems and the rest was out own job. There was a forum to ask but most of the times the answer was "if I tell it to you then you won't work on your own". it made for many sleepless nights but we were really kickstarted into thinking, being creative and working on our own. but I think it was quite a lot of work to set up, so I'm glad they did it.
This was the first time I heard the opinion that OOP is bad. When I thought about it, I realised I frequently create classes simply to partition related stuff. Which is what C & C++ have namespaces for. I tried implementing a tiny project using namespaces instead and the result was shorter, cleaner, quicker to write & easier to read. I'm not ready to throw classes away, but I think I will write far fewer of them in future. Yes, I write code in my spare time. I did that when I was working as a software engineer and I still write code for fun now I'm retired.
I adore your fast paced style! The key information I'm looking to discover comes so much more quickly and I stay more engaged. Also, your code is short and straightforward enough that I really don't want to see you type it out. Keep it up!
In my career, I've found that the advantages of OOP come in the form of its relationship to the physical world. I've found that for many problems, it's just easier to think about it with OOP than it is to think about it how to solve it with just functions. For example, abstracting away interfaces is pretty clean with OOP.
You have 2 important keywords in your post "problem" and "world". I think it's generally better to model the problem, than to model the world. Sometimes both things overlap but not always. When they don't overlap you often end up with classes that don't really exist in the real world, like managers, delegators etc. OOP works really nicely when your problem domain really does contain many of those real life objects.
@@MsJavaWolf not necessarily. I’ve found that most problems in fact can be explained with things in our world. Are we to believe that managers don’t exist in our world?
I've found the total opposite. I think it's a way of thinking. OOP is really hard for me to comprehent as I'm more of a "connect the dots" thinker. Functional programming is way easier for me and way easier to mainain as well.
OOP is definitely an amazing tool at modeling not only the real world and the subsets that make up the problem at hand, but also how to go about designing the solution for such problem. It also makes your solution easier to explain at a high level, which is invaluable when communicating your solution.
You don't need to be "love programming," but passive interest in tech (like watching this channel) can greatly enhance your ability to understand complex systems, at least at a high level.
That's only true because programming is rather more involved than just programming. You don't necessarily need to love programming, but if you don't love problem-solving, puzzles and searching for efficient solutions, you're probably going to be shit at programming anything interesting.
You can love programming but hate coding, coding it's just a tool to get the job done & tons of people seem to think that programming is typing in any language on a dark terminal You don't hear carpenters claim that you have to love hitting a nail with a hammer to be a carpenter, that's just a tool. You should like building stuff instead
You don't need college to become a programmer, 100% agree with that. HOWEVER, college forces you to do assignments which involve solving problems you might not normally do/solve them just by searching for the solution and be done with it. Sure, its easier and faster, but doesn't teach you anything. Doing assignments is a pain in the ass for me quite often, but in the long run I see the value in them, you learn to solve things differently and become better at problem solving overall. Another point would be that college walks you trough the programming step by step, starting at the start and ending at the finish, not jumping around like you might be if you are a self-learner. Sure, a JS developer won't ever touch code written in C/C++ in their career, but it's crucial to understand how everything works on the lower levels in order to write performant code on the higher levels. But I understand that having to take out a loan for college is a deal breaker for most, luckily I don't have to pay
College doesn't really teach programming. College teaches computer science. They are different things. Programming is a trade skill like Plumbing or being an electrician.
@@macmcleod1188This is pretty much how I think about it. I always refer to coding boot camps/schools as "trade school", because that's what it is. Going to school for CSE is different, it's like having an apprenticeship in plumbing vs studying mechanical/civic/chemical engineering. In both cases you have the skillset to make money and support yourself, but the latter gives a deeper understanding. It's not needed, but it great for those that want to know the theory or want to go into R&D.
Рік тому+1
A basic intuition for what takes up time (usually IO round trips and more rarely CPU) as well as space (memory and disk) is really valuable. You don't have to be a wizard in time/space complexity analysis, but a lot of the self-taught programmers are simply unaware and end up with under-performing applications at the worst possible time. For instance, if you get 10000 new users over the weekend because of a blog post, but there's a sequential bottleneck, you're in a very difficult and time-pressing situation. Now, this isn't just a problem with self-taught or beginner programmers. Many frameworks, libraries, etc, aren't even documenting how much resources operations can be expected to use. I end up having to write my own micro-benchmarks to get a ballpark sense of performance. A great counter-example is Redis, which has incredible documentation including time complexities of every operation. More people - especially framework and library developers - should follow their lead imo.
Premature optimization is a huge problem. Ironically more often for more experienced programmers. That's likely because more experienced programmers know more optimizations and like to apply them to show their knowledge and to improve the code which directly leads to premature optimization.
I'm a bit torn on this one. Because at what point would one consider it to be premature? If it's code that should run nightly and basically create a daily report, it might not have to be very fast. However, I know many situations where a job has not been fast enough. I've also seen some outright awful ways of processing data and reading files. The worst one being when a large XML (100k rows) was read, checked and data stored in RAM for every entry in a rather large array (about 1000 entries). That was obviously just someone being stupid, but it's still a case where I had to retroactively optimize. The code itself ran, but was O(n^2) instead of the O(n) after I rewrote it. That's a massive difference.
@@evryon1810 The tldr is basically; just make sure your code isn't shit and does unnecessary stuff and it's never premature optimization. I would say it's not premature optimization, but the correct way of doing things. Assuming we're talking about my own example. The old code had several issues: 1. Performance. 2. Maintainability. 3. Readability. 4. Testability. After refactoring the code, it ran better, looked better, was possible to test and was easier to adjust later on. So the optimization was really just a result of doing things right. Had the person who wrote the code known how to structure code in a better way, the optimization would not have been necessary. I literally just took a loop out of a loop and threw the result into a map. I do have another example though. The code was written in PHP, we couldn't figure out what caused the pages to load slowly; until I checked. We had been fetching a whole load of data then used array_intersect to find matches. Each time only took a few milliseconds at most, but run that 20k times on page load and you got a resource hog. What did I do then? I just did the sane thing and fetched what we wanted instead of everything. We already had information about what IDs we wanted to match, I just had to adjust the SQL a bit and throw out that array_intersect since we already did the filtering. Again, another time where I wouldn't say it's necessarily optimization, but rather doing things the right way. Had I written the code, that issue would never have happened. My code isn't flawless by any stretch of the imagination and frequently has bugs that I usually find promptly, just edge-cases being missed, but never to the point where the code is severely logically flawed. What I consider to be early optimization is more like using bit shifting because it'll save you a little processing power once in a while when doing a very specific calculation. However, if you have something that'll run pretty much constantly, then optimization is rarely premature. Might not have to squeeze every little gain into it, but should at the very least get the work done in as short of a window as possible. It shouldn't delve into the world of the arcane, but just some sound logic is usually good enough.
One thing experience teaches you is to hold off on optimization until you get the code actually working correctly. I revisited a personal command-line script of mine a few days ago. It was taking about 6 seconds to start each time. I soon discovered a couple of things: * Importing matplotlib is quite slow. So if I defer that to the actual plotting function, so it only gets imported if I use that function, that speeds up the invocation of other functions. * When computing stats over a particular sampling interval, my database query was iterating through all the samples and discarding ones outside the range, because I couldn’t be bothered narrowing things down within the query itself. That made sense at the time, but now I have accumulated over 150,000 sample records, it was time to revisit this decision. So I added a couple of extra queries to determine more appropriate time bounds for the actual query for samples. As a result, displaying accumulated counts over the last 30 days went from 6 seconds down to about 1 second.
In my experience, unit testing is really nice when you want to refactor some stuff. Tests are very nice to see where you made a mistake in those cases.
And changing requirements are exactly when you want to be able to refactor easily. Also if you write your tests first you tend to only rely on the interface, so your code can change without breaking the test.
@@problemat1que Yes. Tests can also help write code in test-driven development, especially when you can just write tests with inputs and expected outputs.
I fully agree. It's easy to just test a new function manually, just run it in the main once and you probably know if it's correct but you don't want to do this after every refactor. Code breaks so often after a refactor, someone might just add a throw or something else that looks insignificant but it can break code that looks completely unrelated.
Well, on the other hand, I think your teaching style is the BEST, why watch a tutorial for 40 minutes when I could watch a better one in 5 or 10 minutes? Keep up the good work !
I'd say it's not that you need a CS degree, but some exposure to the sort of theory taught in CS programs. Even academic topics in software evolve quickly, so constantly learning and staying up to date is far more important than having had good teachers at one point.
And when "up to date" involves learning something that is completely out of left field and will never become popular because it isn't useful? Chasing academic theories is a useless waste of time, better to focus on common sense approaches.
I feel like CS was amazing in the '90s and has now devolved into a branch of abstract mathematics mixed with microprocessor archeology. 😛 But definitely read "CODE" by Charles Petzold! 🥰 Other than that, study what you need on the job and what you love on your own time.
I think in practice a CS degree forces you to learn things that many people don't want to learn normally. I have seen so many people produce bugs because of string encoding for example, that sort of low level concept will often be taught in CS.
@@MsJavaWolf Since I'm great at string encoding (and binary in general, hand-coded x86 assembly and hand-coded WASM! :-) ), I'll disagree. My obsession with stuff like that is worthless, and so is pretty much all of a CS degree. For 99% of programmers, learn what you need when you need it, and do good enough work. A few programmers out there are real geniuses that will solve AGI and put us all out of jobs in a few years anyway. :-P
What is important about formal education and good teachers is the mindset you develop about programming and coding. CS enables you to view things with a mathematic-scientific-systemic approach and not just code-crunching with the latest and buggiest tools
IMO test-driven development's value is context-dependent. If you're writing front-end software or anything else with a high degree of interactivity, it's a lot more likely to be a waste of time, because 1.) it's much more work to develop tests, and 2.) the requirements are likely to change, especially early in development. Scientific computing, on the other hand, usually involves some calculations that are absolutely fundamental to the problem being solved, so it's easy and recommended to implement tests before implementing algorithms and interfaces.
unit tests are starting to grow on me even more recently. unit tests or not i'll have to test my code anyway and it's not usually easier than writing the tests given that there is a framework in place for it. i hook up the tests to my debugger and it saves me a lot of time
you can absolutely automate GUI testing. it's just difficult. i work on a mobile app which does this successfully right now, sharing the same - huge - suite of UI tests (based on Cucumber) among the Android and iOS version. "it's much more work to develop tests" it is, especially since they tend to be flakey (eg. failing on some given device). but it has benefits too. it forces the specification to be clear, and the implementation to be consistent across both versions. it detects device-dependent issues (eg. some element doesn't fit on a smaller device, and thus it's not accessible to the user). "the requirements are likely to change, especially early in development" right - and when they do, and you have rewrite a part of the app, it can save you a lot of time if UI tests protect you against regressions that could crawl in - preventing you from breaking something as an unintended side effect it's much more work to develop tests than not to develop them, but it can also save you a lot of work elsewhere.
@@lawrencedoliveiro9104 you can automate gui testing though... you could turn your gui program tests (in something like selenium or javascript DOM event firings) into a GUI scaffold maybe using chatGPT or something.
My Unix professor told me once: "the university doesn't grade intelligence; it grades discipline" My take is that the biggest value of getting a CS degree, is that it forces you to learn how order your mind and ideas. You can definitely google anything, but in the end you write instructions to a machine to do something, and mental order is an invaluable strength to take your "creativity" and transform it in something you can organize and apply
Personally I feel a college degree is more like a aptitude test. When you have a degree, the university is stamping approval on a paper that you have meet the base requirements for your field of study. It shows future employers that you have the potential to achieve.
I went the degree route because I like the traditional way of learning things. I also like that having classes with assignments helps to motivate me to work on the craft, and it also steers me toward new areas of focus that I might not have found as quickly on my own. With that being said, now that I'm in my final semester and have started doing a couple interviews, I do feel that the degree isn't swaying things in my favor much since they still seem to judge me mostly on my perceived personality and communication skills...and of course, on the fact that I still have little "experience" outside of school assignments. My goal now is to try and throw a few side projects together just to have some more examples of things that I built from the ground up. Fortunately, I'm finally starting to actually think of side projects to work on! For a long time, I had a kind of paralysis when trying to think of things that I thought I was capable of making. These last few classes have made me more confident that I could actually throw something together that isn't a glorified "Hello World" type of program. lol
IQ and ability to do lots of work are both inputs. The different majors have different average IQs and practically no one with a sub 100 IQ gets an engineering degree is my understanding.
I like having a structure to learning stuffs and I felt the freedom of choosing what to learn may be overwhelming if I were to start as a self learned developer
7:20 Yes, 100% yes. I've experiece many times in which I, as a developer, decide to go an extra step thinking about user experience, just to be shut down by clients who think what I did was "unnecessary" and that I need to take it out entirely. As an example: one time I was developing a web app for a client, and in one of the pages a table was needed to display data, and as a little quality of life improvement I added on my own was to add an extra row of titles at the bottom of the table so if the table gets bigger than the screen the user can still have visibility of what column they're looking at, that's all I added on my own, and when the client checked the app noticed the row at the bottom and after I explained why it was there, he was all like "Looks weird, and I don't believe we'll need it, take it away" and take it away I did. Days later, another check-up and a bunch of data was added so the table grew big enough that the top titles hide when you scroll all the way down, so I proceed to agonize internally whilst the client is giving the scroll wheel a run for it's money. It's a small example, but it goes to show how sometimes the client knows very little of what they need/what's better.
Perhaps the expected experience was a frozen headline at the top, like you can find in most spreadsheet software? Perhaps you were talking to an SME who knew the column labels inside and out and other users would have reacted differently? Did they ask you to put it back in when the table became long enough?
@@problemat1que No, not really, I wasn't given any instructions regarding that table other than removing the second row of titles and that it had to have exactly up to 20 rows before it needed paging for the rest of the data, and this person never mentioned the table again despite de problem with the row quantity which caused the foreseeable problem of needing to scroll up to check the titles. I'm willing to believe based on what I've seen about this person that he's very old fashion (to call it something) and honestly rather detached with user experience in general.
I always like analyzing the code you need to change first, than looking at how you can interact with API and going for an hour-long walk. When you come back, you will almost certainly have some good idea on how to make things easier!
I find test driven development (writing unit tests first) very helpful. It helps you feel out the API of your functions. Gives documentation on how to use your code to others. And helps you check if you break something after a refactor.
Test driven development is never going to teach you how to design well. That requires techniques that require a global view of a design so that you don't make fundamental design mistakes when you are down in the weeds coding. Committing to code early is a great way to make a mess. I'm not saying you don't design, but your comment isn't specific about the pitfalls of early code.. so thought it was worth mentioning. This is VERY important. Coding mistakes usually end up with 2-liner fixes after a bug is reported. But serious design mistakes might require re-writing a significant portion of the code you just wrote.. with no shortcuts at all. This is why to me, design skill is THE skill required to be a great programmer. Since programming is SO time intensive, preventing mistakes that require rewrites is a HUGE goal.
Controversial opinion: for some managers, 'Agile' gives them an excuse to micromanage the work of people, causing them to isolate when they should ask for help.
Unit testing starts to be great, when whole project recompiles in order of minutes, application starts in order of (tens) seconds and you are writing some low level library. Also pieces of code covered by unit tests usually have much cleaner interface and tend to rely on dependency injection, rather than having large blob of code. Another possible solution is basically writing whole stand-alone application and then to integrate it as a module.
I want to mention: your opinion on OOP and experiences with it are actually kinda the argument most people who oppose OOP are recommending as an alternative. Objects are fine, it's the orientation that's the problem. You description of your own code is not object oriented, it just happens to use objects when appropriate.
Meanwhile I'm just sitting at the side writing both Java and Python at the same time with no issues lmao, people need to find better things to do in their free time than complain about language features
Comments like this make me think that despite almost a decade in the field + a 4-year degree I never really learned OOP. Beyond encapsulation I don't think I've ever really used any OOP principles in my code, apart from a handful of interfaces that only exist because of cross-language interop needs, and one module that is really more data-oriented than object-oriented, but polymorphism was handy in its implementation (also I'm not convinced I wrote that particular module that well).
@3:40 My favorite response to someone sharing this snooty image is "...and the customer ordered a square." which hits so close to home. Sometimes programmers see the spec and just kinda run with how THEY think it should be done.
I think the biggest problem I have with videos like these is people editing our their breath between sentences. I use the breaths as a split-second break for assessing that sentence subconsciously, and didn’t notice I needed that pause until I started seeing it happening more frequently. Without it, I need to pause the video myself and I can’t always do that, or want to. I hate that it’s so common now, and I bet that this is the problem for other people complaining about how fast you talk also.
In contrast to that one comment you mentioned in the video, I really like the speed of your videos. When I don't understand something I can just rewatch it several times, but don't have to watch someone type a few lines of code for 10 minutes.
Readability vs performance is an interesting conversation to have. The thing that I've found over the years that really annoys me is that there is a lot of blatant disregard for performance up-front. Especially in areas like REST-ful API designs. There is most definitely a balance to be found, but there is a significant portion of developers out here that for some reason don't even see performance as something worth considering. There have been countless times that I've seen PRs with optimisations built in (for good reason, such as making things asynchronous if they are not required to be finished in the immediate scope), that get VETO'd because of a desire for a more readable version in synchronous implementation. Or an even more common one is not acknowledging the impact of altering dependencies with a DI driven environment. I can't make it any clearer how many times there have been scenarios where a full team will spend a couple of weeks or a month on diagnosing a source of performance degradation that accumulated over time, and it resolved to ignorance around the impacts of certain design choices to improve readability. I just wish people wouldn't be so damn ignorant and hard headed in their opinion of readability always being king. ITS NOT ALWAYS THE CASE, it's fine to keep readability key, but don't ever ignore it because you don't see any immediate worth or you think that maintainability of the highest standard is always ideal.
I found that performance only matters in such a tiny percentage of the code that is better to wait until after you've written the code, use a tool to identify that code, and then optimize that code.
@@macmcleod1188 We have the cases when we handle big amounts of data, when there are many requests simultaneously, and when dealing with adio/video/images /hardware... Not that tiny the percentage.
@cheogt yes and even in those cases, optimizing the entire program wouldn't be productive. I've written video games, Minecraft box, I've written for huge database machines at Fortune 100 companies, and I've written online order entry programs. I've used assembly to C to Java. I never saw a case where it was more than a few dozen lines of code in the whole program that mattered in terms of performance. Some of those programs for 30,000 line monster programs. So you write 99.9% of the program to be easy to maintain and then optimize the remaining 0.1% with lots of comments. Just imho but it is an informed imho.
I agree with a lot of bad teachers on medium/youtube, but you’re not one of them! Your content is structured very well, and you mostly keep your opinions broad! I completely disagree with people who call your content rushed! Keep up the great work as always 🔥
From my personal experience: unit tests are almost always useless when you develop something new. But it almost always pays off tremendously when you come back to change something after few months or you need to do some refactoring. I don't like writing them, but the fact that they saved production from countless bugs, gives me motivation to write them. Also another thing for me is that I write unit tests for my self and my colleagues and never ever for client requirements or manager requirements or to reach some code coverage. So in a way they cover the feature requirements, but still for me main idea is that I know for sure that things are working in a way I intended them to work. By the way I love your videos, keep on going!
For one, writing unit tests forces you to think about edge cases beforehand (and clarify requirements in regard to those). This is a huge gain in and of itself, in my opinion.
One thing that I found valuable about my college degree (IT) is that there were courses I was required to take that had nothing to do with what I wanted to do with my career (e.g. computer networking or cybersecurity) that later had practical applications on what I was working on.
The reason you don't do those things in javascript, is that JavaScript is not an object oriented language. You can choose to program with it like it's object-oriented, but you're not required to. So you are not using object-oriented methodology that you would be forced to use in Java or C#.
Newish programmer, know a moderate amount of C and Python. And my favorite part is when I take a break, think about a solution while watching something, then immediately get it right. Breaks are a crucial part, let’s you look at the whole picture. Some people think too hard on one thing, then get stressed and can’t complete it. Been tutoring a couple even newer student from Cornell (I don’t go there, some of my friends friends) and most of them think too hard about simple questions.
It is not *just* about the break, the process of thinking hard about the problem in the first place (spending time to try debugging, even though failing) is crucial for "returning back from break and solving it in 5 minutes".
It's the way the human mind works, you need to process switch in order to retain info better. You don't want to operate off cache all the time, you need to write to a permanent location sometimes in order to correctly associate old and new information.
Controversial opinion: 95% of programmers don’t need to know the common algorithms you learn in college (like merge/heap/etc. sort or the knapsack problem)
@@akshaypendyala Even if they write fresh code. They will most definitely use a more generic, more performant and efficient version from a library, be it built-in or third party.
I haven't even use a "do while" in 2 years, and that is not bad. In College they teach you logic and how to use it in programming, at least at the beginning, and algorithms like merge, heap and other are to improve that logic
It really depends how low level you are programming. I use the heap all the time, but since most programmers aren't writing C code, I guess I agree that most people don't need to know that. But it is fun to know :).
I think understand them and implementing them puts you in the mindset of being a programmer. So while I dont think you should know them off the top of head, you should learn them when you start programming to teach you how to think about code.
Applied math researcher here. OOP is pretty good to make code readable, which is pretty important in research. Also, research code doesn’t need to be maintained usually, since it’s a one-off script to test something.
OOP doesn't make code readable if you use inheritance a lot. In that case it actually disperses and even duplicates code. This is a big deal if you have to fix a problem with a method in one class because now you also have to check the code in all derived classes that have a modified version of that method. It's basically the same problem as with forking, just internally to one program.
The comp sci degree part hit home. I've been relatively successful as a bootcamp grad with a non-technical bachelor's degree and I still wish I had done CS in college...
For me OOP is very good, but it's not like you're forced to do it every time. You can absolutely use an OOP language without doing actual OOP. Game development makes very good use of it, specially when your settings require constant changes in number of entities.
Yeah I was a bit confused about the OOP section. Maybe for something like web development you can do functions-only, but the first thing I thought of was game development; I don't see how you could reasonably make anything that's more complex than Space Invaders without using objects.
@@ZachAttack6089 Using "objects" does not necessarily make your code OOP. You can use objects but not do OOP (by separating data-classes from service-classes). And you can not use objects, but still use OOP (by using structs with functions and initializer functions). Also, quite some game engines these days use entity-component systems, which are not really OOP, so modern games are unlikely to heavily lean into OOP-style class hierarchies. OOP as it is understood these days (the style popularized with Java) teaches you to bundle state and functions related to that state together into one class. Structs/objects without functions are probably not OOP and you can perfectly write complex pograms with them by organizing your functions in another way (modules, service-classes, etc.).
Even Java, the language famed for being overly Object Oriented, works perfectly fine when no objects are actually used (Possible with static methods, annoying as hell, sure, but perfectly doable)
I agree, as BIM developer the BIM softwares would be a mess wihtout proper OOP because they have 1000+ types of objects comapred to a usual web app. I also develop web applications where OOP is not needed that much.
I love the fast paced content it means that I get to keep moving and if there is a skill I am struggling to remember or learn I can watch the short informative video multiple times in a week or stop and rewind whenever I need to hear something again. Frankly, this is the perfect speed for me to write notes and understand what is going on. I only wish I had more daily content from you.
IMO the problem with OOP is the "Oriented" part. Objects, classes, inheritance, etc are all useful tools and it's great that they became popular, but OOP as a design philosophy is almost always the wrong approach. The current paradigm for new languages uses these features where they make sense within many other design philosophies, and I think that's the correct approach.
Who says that immutable recursion is the answer to all things? I would say that most pure functions don't use any recursion. Immutability is always preferred though.
and then complain that software is slow. Of course is slow, immutable recursion requires a lot of copying data between memory layers, including SSD or HDD
Opinion: interviewing requires a totally different skill set than actually doing the job.
The guy taking the interview doesn't have the skills to test you for the job 😁
This is my opinion after almost 20 years as a professional software engineer: you can’t know if you want to work with someone until you’ve actually worked with them. Technical skills, soft skills, and research skills are all equally important, but modern interviews don’t really test for those things. Instead they typically only test your ability to solve a logic puzzle under severe time pressure while someone who already knows the answer is judging you and failure means the loss of a literally life changing opportunity. That kind of pressure, and the kinds of puzzles presented are… atypical, at best, of the day-to-day job. Giving a good interview is a difficult problem to solve on both sides of the table.
@@kosterdan hey what are your tips on preparing for interviews
Agreed, although I do find a lot of value in the algorithms portion.
Not controversial at all
Two golden pieces of advice I've gotten from senior devs: "Less code is good code", and "overestimate the time everything will take by a factor of 2".
The second one was brought up in one of my engineering classes freshman year. It definitely stands true
Time estimation is hard, even for experts on a subject ... aaand most people have an optimism bias. Overestimating by a factor of 2 is a very good start :)
en.wikipedia.org/wiki/Optimism_bias
The first one can be prone to misunderstandings IME. I don't remember the exact words right now, but they were like "readable code is better than clever code", in the sense that it doesn't really matter how technically impressive your code is or how many lines of code you "saved" with it, if in the future no one but you can debug it. I say "in my experience" as nowadays I struggle with other's code exactly due to this reason: By trying to save "lines", you make your code harder to understand. Less code is not about less lines.
My experience is that it's always ten times harder than you think it will be - even when you take this into account.
The second advice actually applies to almost ALL projects in life.
I am learning to code as a hobby, and as a means to make my own apps/devices for my own personal use. I don't intend on getting a job as a dev.
That being said I have MANY hobbies. One of which, is cars, and modifying them.
As an old mechanic once told me:
"Find out how much money and time you plan on spending in your project car, and multiply it by 2. That's two thirds, of what it will actually cost you."
he was so right. :D
My controversial opinion is that, regardless of being new or very experienced, a good programmer is flexible and willing to experiment outside their philosophy. Cause only Sith deal in absolutes.
Why is this controversial tho
This isn't controversial and applies to everything in life? A good paraphrase would be "be open-minded"
@@sunimod1895 part of it is a joke
A sith lord I am
"only Sith deal in absolutes" is an absolute itself xD
my cs prof at university once said something which always stuck to me: "Programming is the art to tell annother human being what you want the computer to do" and I think this is so true
love this
Huh?
.. surely that’s specification, the client tells the programmer what they want the computer to do for them, I don’t get it
@@cdunne1620it means you should write readable code
@@cdunne1620 No, code is for human eyes as much as it is for machines. Programming is a professional and collaborative work, not some kid in a hoodie typing away. Anyone writing code has to keep in mind that others will use, maintain, and build upon their code. There's a reason why legacy code and spaghetti code are a problem.
"I only have about 5000 rep on Stack Overflow, so my opinion really doesn't matter very much" - I swear I watch your videos just for the satire at this point lmao
I love his satire XD The only satire I understand is about programming, human communication is complicated. This was written by OpenAI.
Cries in 50
@@ashiksaleem360 cries in 69
That was satire? I thought he was saying that the people who consider themselves stack overflow insiders would have much higher numbers and not see 5,000 as a big value. I'm around there too and it feels like I often see people with 10x my score blowing by, especially anyone that's a mod or a subject expert.
@@Paarthk a lot of the time those people go around fixing spelling mistakes and formatting errors just to up their score.. 🙄
The opinion about not needing a college degree is very US centric, as in most other countries you can get a degree without getting any debt and often also without any side job.
Louder for the people in the back
yeah, i keep forgetting that muricans have to pay for education, it's mindblowing (and sad)
I can confirm this as an Asian. The idea of not having a degree isn't really popularized here
It's true anywhere - you can write software without credentials. Maybe tuition is "free", but there's still opportunity cost.
I think not having a degree only works really well for certain people - those either very lucky or very good. I think I'm a pretty reasonable programmer (although my opinion of my skills goes down as my age goes up!) but my career has been quite mundane and I feel I paid an enormous opportunity cost in not getting a degree until I was 50, when it's almost too late to use it. I tried 3 times, but I flogged myself so hard to get good marks due to the chip on my shoulder I kept burning out and dropping out. I think I could have had much more interesting jobs if I'd got the stupid piece of paper when I was meant to - ie the start of my career.
FWIW I didn't learn anything about programming that I hadn't already taught myself more of in all the times I tried uni. I did learn new stuff in all the math subjects, but I haven't had to use it yet. I suspect if I knew it better, like I know programming, I'd use it a lot more - the whole time I was doing stats or linear algebra I was thinking "you must be able to solve anything with this stuff" and promptly forgot all of it after the exam.
So I don't think you need a degree to be a good programmer - I think that's a matter of how your brain works and if you have that sort of brain you'll just want to do it anyway, but I do think you pay dearly for not having one in opportunity cost.
Controversial opinion: SQL is pronounced Squirrel
saquille
LMAO this got me laughing so hard!
"honey it's time to go to bed"
"dammit mom I'm waiting on a query from my squirrel this is important!"
".....okay honey, if you say so"
Finally found a reasonable controversial opinion after so many stupid controversial opinions.
You got it. Keep up the great work
Well, sometimes we pronounce it as Circle :D
Not a programmer, I'm a mathematician, but the comment about upper education really resonates with me. If i had not gone to university, i would have not gained the mountains of insight from profs, succinct explanations, had nearly as many helpful peers, and i would never have been able to write anything close to the scope of my undergrad thesis without the supervision i had. If i had wanted to understand something like "hyperelliptic curve cryptography with genus 2", i would have been bumbling through papers and stackexchange posts for weeks, but my prof explained it wonderfully within 2 lectures. The sheer condensed knowledge from people with literal decades of experience in it isn't something you should just forsake as being "easily googlable". I really despise it when people say things like "university is useless", because it's just a certain type of learning environment that might not work for you, but it works wonders for others. Google is a library, not a professor.
Great one
Mathematician turned programmer here, from teaching maths to teaching web dev.
That's exactly right and what I always tell my students, particularly ones that act shy around class and don't shower me with questions. This isn't universities in the 1800's or 1900's. You're not paying for access to the information I'm giving you - all of it is freely available on Google nowadays, and more. You're paying for me to stand there cracking jokes and breaking down layers of abstraction into understandable and relatable concepts, and to separate the wheat from the chaff for you.
Of course most people could learn everything on their own, but that takes a lot of time, and time is everyone's most valuable currency.
And now we have AI which can do the searching and explaining instead.
@@HichigoShirosaki1 you'd be surprised how completely but confidently wrong it can be when explaining math topics or providing even the simplest of proofs.
@@HichigoShirosaki1 Autopilot on planes has been better at everything a pilot can do for decades now. But they're still there because most people distrust machines.
And using AI isn't as intuitive or effective once you get past the trivial introductory level on most topics, and it needs very careful steering if you want fined tuned answers or very specific information.
AI just makes my job easier, not moot.
The last point made me remember my tech lead in my first project : "Don't write optimized code if optimization isn't your goal in the first place"
I have to remind myself of that all the time when I'm doing hobby projects. First focus on getting it done, after that, it can still be optimised, if needed.
Jackson's rule 1 was Don't do it and rule 2: Don't do it yet.
Premature optimization is the root of all evil.
God sakes... I'm new in coding, I always code while test while rewrite for optimal performance. Too much time coding, little ground covered.
so this is like saying "done is better than perfect" in another way, and yes i couldn't agree more, optimization is necessary when your app has reach a bigger scale of users.
Testing: Most stakeholders want test driven development but don't want to pay for proper meaningful tests.
absolutely true
Nobody wants to pay for any kind of test, unfortunately.
And sometimes they don't even want to pay for proper requirement specifications :(
Thats not controversial, that just a fact
PDD is better :D
I've heard it somewhere: "The code is NOT ready when you have nothing to add but when you have nothing to remove." I think it's very true.
This is an old saying that’s originally aimed at the perfection of a product/creation. I believe a famous artist was referring to a statue at the time the saying was quoted.
@@Khunkurisu Then it's the 21th century adaption of the quote :D
@@kisvegabor Duck Dodgers of the twenty-firfth century!
I defiantly agree with this.
Yeah I agree
28 years of experience. OOP was the cool hotness when I was a student in the early 90's. Encapsulation has its place, but most problems don't need it and it tends to obscure the code from the solution.
The more I write code the less I write programs with OOP patterns.
this, man! It's a neat idea but YOU DO NOT NEED IT. Also in say Java, if everything is an object, nothing is (it has no meaning).
There should be exactly one and only one language construct for each aspect of programming:
Encapsulation? -> Modules
Inheritance? -> Subtyping
Doing stuff? -> Functions
Storing stuff? -> Structs
Guess what happens if you try to use one tool for everything? Exactly! You need to invent dozends of useless and dumb patterns to make sense of it. Until this day, I have not fully understood why you would need a "Factory"-Pattern ...
Classes are egg-laying wool-milk pigs (a german proverb for something which claims to do the work of several specialized tools), just like MS Excel and we all know how good that works for building reliable systems
Imagine OOP language in which you could change the interaction even with RAM, CPU or compiler... With that much experience I'm 100% sure you got it
@@robertobokarev439 That's called C++ when you start playing the the vtable pointers... don't do that!
I guess the language in itself is just a problem of syntax. If I want to order a beer in Japanese, I just learn how to order it in Japanese. The problem are Frameworks. In Javascript, the struggle is more about how to identify similar or identical concepts between Vue, Svelte, React, Angular... In Java, Spring Boot is really cool, but there the struggle is to find the superclass of the superclass someone else just injected into your constructor. I find myself more digging in the repo than actually writing one line of code.
@@MCRuCrYeah, you do not need it if your program consists of 1000 lines of code, but when it reaches 1.000.000 lines of code I found OOP to be greatly beneficial to me.
Damn, I actually like the speed of these videos. I hate watching tutorials where they type everything. I just want the core concepts. I end up using the arrow keys to jump giant chunks of the tutorial.
Word! 100 seconds of everything!
True , i normally don't skip, because we sometime miss something....
But this is the only channel i don't need to speed up things...
lol same
Ain't nobody got 1 hour to go through a tutorial. Especially not experienced devs who just want to get the idea and fundamentals of topic in shortest time possible. I completely disagree with people criticizing this channel for being too fast or not going into depth enough. For me this channel is a blessing and if someone feels like this is too fast and confusing, you probably need to go watch those 1-2 hour long tutorials with typing. People should understand that not every video about programming on UA-cam is made for beginners. If you can't follow you probably need to mature more as a programmer and come back later so you could actually value this awesomeness.
1000%
Opinion: Every time someone says "We need to get better at agile", what I hear is: "Agile doesn't work for us, it is causing stress in our company, but we'll keep pushing it anyway because it is trendy and will work somehow".
I think the core tenants of agile should work for *almost* every company. The times I've seen it not work is when it is pushes as a narrow approach, e.g. you *have* to do paired programming and have 100% unit test coverage from the get-go (or else your fancily compensated agile coach will tell you "you're not getting it").
When bosses say "agile", they usually mean daily stand ups and unrealistic deadlines.
@@MrEdrftgyuji This... I really felt it. My life was wonderful, I enjoyed my work, and then agile with 2 week sprints ruined it. Now I feel trapped and frustrated.
@@Hannodb1961 Agile's not for everybody.
Oh so much agree. Agile is like a communism it may look like a good idea on the surface, but it is impossible to implement in any complex enough environment.
I have total respect for developers who are self-taught. I went the university route (got a masters in CS) and I met some pretty talented devs and a lot of horrible ones. If you want to do it, you will find ways to reach your goals, degree or not.
Thnk you
I'm self taught. Do you think it's stupid to want to go back and get a degree?
I'm on my 4th year on my CS degree, 90% of the stuff I know are self-taugh and that 10% is Java which I am NEVER going to use
I'd say it's not about getting the actual degree that matters (i.e. the physical paper and graduating) but more so about the structure path school gives. yes you can be self taught (I am) but I would suggest getting your hands on multiple syllabuses and books for computer science and learn what it is that type of degree is trying to teach. the self taught path doesn't have to be like wondering in a dark factory with a weak flashlight
@@jamesking2439
Its not stupid.
When I started in the early 1980s I had an arts degree and not a CS degree (my first 3 years of College was science/math, the next 3 were arts). I knew I was ignorant of a lot of things about CS, so I went to a university bookstore and bought text books in algorithms, compiler design, data structure theory, etc. I spent my spare evenings studying for the next 4 years, and it changed how I approached programming.
I don't think I would have done as well without the advanced math, but I was taking Engineering level Calculus at a Community College when I was in 12th grade of high school. So math just wasn't an issue for me.
HOW you get the knowledge is not important, THAT you get it IS important.
I like python & Kotlin because they allow you to use OOP when it's really beneficial and don't force you to do it all the time for everything like C# does so, most of the time you can stick to simple functions and modules.
@@richardlyman2961maddest respect if you learnt rust, its so difficult
explain to me how you can use python.
the lack of brackets drives me insane.
ive written things in python, had no errors pop up, dosnt work. send it to friend, he sends it back, no visible changes, it works.
python spacing is black magic and i dont understand it
@@johnathanrichardson the lack of brackets is liberating :D once you get used to it, they will drive you crazy elsewhere :P I hated it at the beginning, but then for one big project I gave it a shot and now I love it. Just use some decent IDE like PyCharm and not that shitty VSCode.
@@johnathanrichardson I think your IDE just sucks. Ever tried switching?
@@abyssmage6979 Notepad FTW
As far as a computer science degree goes, I'd think what's really overlooked is the mathematics and logic skills that the graduates of good programs have. Many degrees require calculus 1-3, linear algebra, statistics, discrete structure logic, algorithm design, etc. I can tell you from personal experience companies that are designing products and solutions for important STEM fields aren't often hiring self-taught programmers because they lack the needed mathematics, scientific, and low level systems knowledge that are required for those positions. If someone has no interest in working in the STEM industry and just wants to make mobile apps or websites, then no, a computer science degree is not worth the time and effort, but, if they do, then it's pretty much required. Computer Science degrees were never designed to make app developers, that's what coding bootcamps are for. CS degrees are designed for the development of scientists who specialize in computer utilization. Telling people, especially young people, an incomplete and biased take of, "College is bad because I didn't need it to get my job," is misleading and dishonest.
I 100% agreed and was about to write the same too :)
I would add that education sometimes knows better what you will need and teach you subjects that are not obviously relevant and that you would overlook.
yeah, most software is easy web+db stuff and they call themselves "fullstack developers"... I know a few more-than-full-stack developers and for them this web+db is just frontend for extreamly complicated systems using the said math. + robotics, elecrical, embedded, heterogenous systems...
Oh yeah, as a self-taught programmer myself, I shy away from hiring "self-taught" programmers. Though there are a lot more factors to that consideration than lack of proven scholastic aptitude. I doubt I will ever take my two degrees off my resume, no matter how much field experience I have. The biggest difficulty I would have in finding a good mid-tier programmer is weeding out rogue programmers - they crop up more often in "self-taught" labor pools than formally trained. That said, when looking for a high-tier programmer (I like to think I fit that bill) I want someone who can tell me what I don't know. I want someone I can hand the project to, who communicates exceptionally (that absolutely applies to readability of code) and not need to question their decisions, in which case a self-taught programmer is indistinguishable from a formally-taught programmer.
I'll add a counterpoint to this from my point of view (for reference, I'm a self-taught audio plug-in dev, which requires a LOT of mathematical knowledge about dsp and a fair bit of low level programming knowledge)
Pretty much everything I had to teach myself (especially regarding maths) was the same as what they teach in college/university and its something I often wish I did, not because it would be beneficial for a job but because it lays out a linear easy to follow path for learning this shit, however
There is absolutely zero doubt in my head I can't just learn the same things by myself if I wanted to, because I already have been to a large extent and that similarly, for someone with enough determination to learn for their respective field, they couldn't do the same. From a purely academic standpoint, going to college definitely is NOT obligatory. You can become just as proficient, if not more, by literally spending zero dollars if you want.
The biggest advantages having a college degree offers are:
1. An environment where everyone wants to learn the same things as you
2. A well thought out path for you to follow to gradually learn all of the stuff you need to know
3. Actual, tangible qualifications that are universally recognised. If an employer wants to hire someone, chances are them having done some form of degree will at the very least ensure some base level of skill without having to interview them.
For me the disadvantages of the insane financial requirements + time and most importantly, mental strain far outweighed these advantages, which is why I chose not to go down a traditional education path but obviously that doesn't need to apply for everyone, but making generalised statements that you do or don't need college are both definitely very misleading
The best advice a senior dev ever gave to me was "The best code is just plain boring"
what exactly do you mean? Is it boring to code the best code?
@@liamrobertson2670 somewhat, it's supposed to counter against coders making too sophisticated code for their own ego instead of making it functinal and readable
@@SixCoreSecond I see
The best code is no code.
@@liamrobertson2670 Code should (amongst others):
- be read like plain english
- be straight-forward and predictable
- be easy to alter/approach according to new requirements
- be composed of/itself be simple block(s)
- be explicit in error handling (+ great recovery mechanisms)
- use the simplest concepts and structures to express complex relationships
- be greatly covered in testing (unit testing/integration testing/E2E testing)
- scream in the form of broken tests when core functionality is altered
- not allow for buggy logic to be described (intensive domain modelling)
The desired effect of the code should be one of safety and stability - for the customer, but also for the programmer - it should not make us be afraid of releasing/breaking prod/introducing subtle bugs because of convoluted logic/touching it because it's so complex.
When you add all of the above together, "boring code" seems quite mean - but it is actually a great compliment - it allows us to focus on the important bit - the problem itself, and not the implementation detail which is the code.
That point about writing comments that explain _why_ something exists and not _what_ it's doing was such a good point for me. I've always had a hard time trying to figure out where I should put comments and ended up either putting them everywhere or nowhere, but in hindsight this is a super obvious rule of thumb to follow
Comments are for communication. Use them if your code is hard to understand. Before you use them though try to make your code easier to understand. If your comments contain no additional info (just explain what’s obvious) they are a liability.
@@ssssssstssssssss yeah well that's the issue... often idek what is obvious. ig a good way would be to get someone to look at your code and go "what the hell is that"
@@ssssssstssssssss comments lie. Instead of writing a comment, try to get code that negates what the comment was going to try and explain. If you can’t, then put a comment. But if you find yourself thinking of adding a comment, that is when you need to go back to writing the code. Code doesn’t lie, comments do, and no one ever updates or removes comments so they become bad actors over time.
Here’s an example of commented code that I write:
my_wait_avail = asyncio.get_running_loop().create_future()
if self.wait_avail != None :
# somebody else using this socket -- wait till they’re done
await self.wait_avail
♯end if
assert self.wait_avail == None
self.wait_avail = my_wait_avail
# claim ownership of socket
Now, would you suggest getting rid of those comments, or not?
@@lawrencedoliveiro9104 yes. If any anything, your methods and properties need better names.
It’s like order of operations. Commenting should be the absolute last thing you do. Renaming variables should be done far sooner than leaving a comment.
The value of a degree is not so much about technical experience - ivy league universities teach largely the same content as other universities, but the value of hiring a graduate is knowing they passed the intense screening and application process. Same holds true for someone with a CS / EE / SWE degree. You can be sure they had to learn the difficult things they wanted to avoid, had to deal with stressful deadlines and full schedules, and had to deal with group projects where people are on different levels. With someone self taught this is not always self evident, and in my experience, a lot of them lack the teamwork and soft skills of graduates.
There is obvious selection bias here, because people who graduated and people who didn't weren't the same at the start. These two grouos weren't split randomly. Other things being equal, someone who is passionate about IT is more likely to pursue a degree from the start. But it's not that they owe their technical curiosity, their knack for analytical thinking etc. to that degree - the causation runs the other way round.
It's like people who play basketball being taller than average. Statistics don't lie, right - "you wanna get tall? Join a basketball team, clearly it helps". Well... :)
Even this isn't 100% accurate. Yea you are technically taught the same subject matter as other less competitive programs but the depth in which the classes go in and the type of assignment you are given are on a whole new level. I thought my CS 101 was tough until I looked at my high school friend's CS 101 at a top engineering/cs program and it was a different beast
With the whole "lazy programmers are the best programmers" section, there have been times at work where I just get up walk away from the computer and take a walk for about 10-20 minutes, and come running back because an idea popped into my head. Luckily I work from home at the moment and didn't have management questioning why I needed to take a walk. A lot of programming is about creative problem solving and just sitting at a desk and typing away doesn't always help once your deep in the weeds in a program or even a piece of functionality.
100%, it's weird how a mid-day nap can spark brilliant ideas. The Spaniards had it right all along.
Definitely agree, though with a slightly different rationale. A lazy programmer will frequently find a way to automate something that they don't want to deal with (within reason of course). While working as a research assistant, I was asked to build some simulation worlds that would have taken me weeks or months to do by hand since the world creator for the program we use is.... Less than good, and hand-coding all of the walls would take forever as you're working with object dimensions, rotations, and absolute positions rather than to-from points. So I took a couple of days and wrote a script that let me hammer out a single world with 70+ individual wall segments in about 30 minutes. I later expanded it to work with a couple of other things that were a complete pain to do by hand (for instance, some animated models required their movements to be timestamped with each waypoint rather than allowing them to move at a set speed, so adding or adjusting a waypoint or speed meant adjusting EVERY waypoint and timestamp with a new set of calculations) and saved myself and the lab a bunch of time and effort.
It's a marathon, not 100m sprint. And with large projects it is even like hiking to Everest. One step at the time. Slowly.
Absolutely correct. I’m retired now, but as a programmer for over 20 years, I found that a midday walk helped me clear my mind when I was stuck on something. Heck, a midday nap helped a lot too. One time I took a nap, and I had a dream with the exact solution I needed for my problem. Pretty sick to be dreaming in code, but at least it helped me when I woke up back in the real world.
@@erikjs this is literally me! Can’t count how many times I’ve dreamt a solution to a issue at work.
Over the past 50 years, I've seen customers routinely make two deadly mistakes:
1. Proposing solutions instead of stating needs. When a user says, "I need a program to ..." I ask, "Where does it hurt?" That often gets to the heart of the matter.
2. Trying to make my job easier. I tell my customers, "Be unreasonable. Demand the sun, the moon, the galaxy, and a galaxy in the universe to our left. I'm an adult, and will tell you if something is infeasible."
Sometimes, going for the moon is actually easier to do than whatever "easier" thing the customer had in mind.
I got that idea by watching the Corridor Crew (a yt channel) react to the moon landing from the pov of conspiracy theorists as an April Fools. Niko, one of the guys, said something along the lines of "actually going to the moon would've been easier and cheaper than faking going to the moon for that time".
And I agree with you, people have the wrong idea about programmers. We don't look for answers, we look for problems. Finding solutions to given problems is what we do 😛. Constrainsts are the roots of creativity after all 😁.
I'm in my second semester of comp sci, and the first thing they taught us in our software engineering class was your first point
@@imcheeze115 Thank you. That's a comfort.
The second one comes up a lot for me in the form of "It only needs to do X. But occasionally it needs to do Y, Z, W, and V, but those don't happen often so they shouldn't be a big deal." In software development, it doesn't matter how often something happens, the same amount of code still needs to be written to support it
As for that #1 - working with programmers for a while now. It happens many times that they tell me something's impossible or has to be done in an ugly way. Then I sit down and do research on my own, and go back to them with some ideas and suddenly it's possible. Maybe not exactly how I envisioned it, but it gives them a path forward. Not that they're bad programmers, but it depends on the type of person they are. My brother has been developing AI, and automated systems, and all sorts of stuff, but sometimes he just misses something that's obvious. Maybe tunnel vision? But I start asking him questions how stuff works and together we figure out the solution. I'm not a coder, it's just my job as a product manager to figure things out. I can't just let it end at "impossible" or "let me do the thinking just tell me what you want".
So yeah, I don't think knowing how to code means that you can't benefit from others' input and ideas
All in all, the answer of almost every question in CS is basicly “It depends”.
There are tons of ideas, design patterns, languages etc. and each of them is best for a specific situation that is defined by lots of parameters. How well you perform a task is directly correlated to how many of those parameters you considered right. And considering all parameters is just an utopia.
So that, all I know is It depends.
Everything depends, doesn't it? The "fact" that 1 follows 0 depends on consent to three other "facts."
Magic happens when we can discuss what it is that matters, why one tactic is better than others in which situations.
yeah im kinda tired of hot takes like "oop bad and it should burn down toghether with java" its like dissing a kind of food ingredient and tell everyone to stop using it entirely because reasons
I actually like coded testing when requirements are vague, or changeable. I write the tests to specifically cover what I've been told to implement. Then, I show the documentation of those tests to the product owner. If there is a change, or misunderstanding, I can update the test, and that will inform the change in the implementation
3:37
"Yeah i ordered 11 square blocks of concrete, but i only got 10 and a sphere for some reason"
"Fuck! Uhhh yeah sorry about that, must be because of james, he's a new hire. We will quickly send the replacement"
try some design job james. they will pay you higher.
Also he wasted some material by cutting the cube
Spoiler: it's play-doh
roasted in seconds
But he delivered it so much faster than the others!
2 Rules for dealing with customers: "The customer is always right" and "the customer never knows exactly what they want." Both statements are simultaneously true.
I my experience at the Requirements Engineering course in CS, I found that's the most truly description of the work life of a programmer.
I agree.
In my experience the customer has a problem, looks at the existing product which to them is a web interface. They'll ask for a change to the UI to get it to do what they need.
When this gets to me (lead engineer) I don't have the context of the problem I only have a request for an odd feeling UI change. So my job is to coax the real problem out of the customer. Most of these problems are solved in the backend with no UI change.
@@ljones140 Here, here! Hear here!
Definitely so.
@@ljones140 yep. "The customer is always right" is a contraction of the more exact statement, "The customer subconsciously knows what is right but cannot always tell you what that means."
The dude that said this channel sucks i felt that and you know why? Cause i was one of those guys years back when the channel was just angular and firebase commenting like that to every video of his lol. But i stuck around and I realized i had to level up to catch up with Jeff in other words experience is what i needed. His teachings are really for intermediate+ devs there is no hiding it.
true. and they're also really good when you have a little understanding of the topic. his videos are like a summary of the topic & tips too.
That's just beautiful, glad to see you here man
I agree to this. His videos are simple and just enough information to understand it.
Hmm I'd disagree that it's for intermediate devs based on my personal experience. As a beginner I've learned way more stuff on this channel in a short amount of time than any other channel on UA-cam. It feels like I've fast tracked my learning time using the short and to the point videos. It also forces me to do research if I don't understand something instead of being fed code to copy and paste into my projects without actually knowing what it does and why it does it. I know every one is human and makes mistake but ever since I've started watching this channel I just can't go back to watching 1+hour tutorials where they make typos and spelling errors thinking its good to show that stuff. Lmao it just messes with my ocd when I can clearly see the mistake or spelling error and they just continue with the video. So yeah that's my opinion based on my experience
Agreed.
Even in some videos about subjects I'm familiar with, I watch it video and think "well, that was a nice overview in a very short time".
I'd much rather watch a shorter video that makes me interested in the subject so I can read the docs by myself, than watch a long tutorial - sometimes with poorly written code - that barely helps when you actually use the language/tool/framework/etc.
I think a big takeaway is that even if you disagree on a topic or if you think code should not be done a certain way (like OOP) it is still important to understand the ins and outs of something you don't like, because you might still need to draw from it in the future or might even need to use it although you do not like it.
Or debug existing code lol
In my experience, 10X programmers are also about the culture where you work. I have seen hyperproductive programmers drop performance by 100X from micromanaging bosses, project leaders or agile coaches. Its depressing to see.
As a potentcial 1/10 dev, would be interesting to look for the amount of things a 10x programmer do in one day
not yet a developer but i agree that working with certain people could boost your productivity by tenfold, but it only last long if its healthy for you
@@blackerhawk1508 consider pair programming… or get a 10X to break something down and explain it or… get them to show you how to get a new project up and running quickly.
Amen, well defined tasks and clear guidelines for what is needed usually get done 10x faster including unit testing etc.
That’s why private projects usually grow faster than what you work with 🤷♂️
Is agile bad for software projects? (I ask it for generally game development)
I remember having an interview where they asked me about error codes within a system. I was able to intuitively break down the first error, but ultimately the correct answer was to 'Google it'.
Bruh what? 😂
My professor in mechanical engineering warned us about a similar interview question where you're handed a technical drawing and ask you what you think that is and if you're not immediately looking at the name of the drawing on the bottom of the page where normally everyone could see it you're out lol.
My controversial is: You don't need to expert in algos, leet code like problems. Just basic problem solving skills are enough most of the time.
really ?
@@statuschannel8572 Depends
That is true unfortunately, the hight demand for software, made the bar level that low. I just don't think it will last forever though
I agree. Never done a leet code problem, basic problem solving skills does the trick
its true. but its good if you are expert in algos because its help you improve problem solving skills, best practices.
I definitely agree to the comments one and I think I wrote literally one comment in my code in the past few months because the thing the code was doing was not immediately obvious and it looked like that part served literally no purpose.
It was a class that was getting SNSMessages from AWS via an API endpoint.
The part with the comment was a try/catch block with a call to a Amazon supplied parse method for the incoming message Json and the catch block would return an http code 500 if tripped.
Then I'd take the message json, re-parse it on my own, and process it by checking what kind it is and what's in it.
At first glance it looked like the call to the Amazon parse method served no purpose, the result wasn't used for anything else, it just parses and then it does something else entirely. It was in fact a verification check, if it can parse that means that the message is legitimate, it's the right format, the certificates check out, and everything is good. If there's something wrong with the message it'd throw an exception that the catch block would catch and send back a 500.
The problem is that the class it parses into is hot garbage that's a pain to work with so I just wrote my own but instead of verifying the message on my own I just used Amazon supplied classes for that only.
As as programmer in his 60s, I agree with your takes on things.
I find OOP to be good for a certain class of problems, and I find inheritance to be a difficult thing to do really well, because there is so much of a tendency for programmers to do things that make inheritance hierachies make no sense (usually classes have code in common which quite legitimately belongs in a super-class, but I've seen SO many cases where common code that isn't related to a class is hidden in a super class and then actually called from both sub-classes and from non-related classes.. what a confusing mess!).
I started out doing Structured Design in the late 1970s, and then switched to OOP in the mid 1990s. My take after all these years is very simple. Take good programmers and have them use any design method they want, you'll get good stuff. Take mediocre programmers with any design method and you'll consistently get poor stuff. I think the majority of programmers fit into the 'mediocre' category. I'm not saying they aren't needed, just that they need good programmers looking after them a bit. I think most of the insults thrown at OOP are actually insults thrown at bad programmers that just don't understand what NOT to do in ANY methodology, with the predictable bad results. Teaching coding is hard enough, but teaching wisdom about what to do and NOT do is incredibly difficult. I've met some programmers that seemed like the human equivalent of a brick wall. Unyielding, unchanging, resistant to change. The trifecta of terror.
Good vid!
I believe you when you say you're in your 60s. You put two spaces after a period. :P
But I still agree on the points you make.
@@electrocatalyst Thanks! And yes, I learned written English back in the 1960s. Those rules have become a bit loose since the advent of the internet.
@@rbarnes4076 Personally, one of the better arguments against OOP and its design patterns is that languages shouldn't focus on making it hard-to-impossible to write bad code, they should focus on making it easy to write good code. Rust is a good example of a language which made it easy to make good (memory safe) code, without preventing people from writing unsafe code (anyone can throw an unsafe block around their code and do horrible things, but it's far easier to just write good code)
Spot on.
A lot of bad programming stems from the Top > Down since corporate heads wanting to ship out their software asap while having unrealistic deadlines and expectations, forcing the Dev leads to opt for Oject Oriented languages to get the job done in a timely fashion. Combine short deadlines with a bunch of mediocre + bad programmers with unrealistic expectations and OOP, you get a bunch of spaghetti code with a ton of bugs that'll end up costing the company 10x as much in the long run than if they did it correctly from the start.
Things get overly abstracted, functions with side-effects, and all that jazz it make it so hard to maintain and very slow to get new devs up and running with the code bases. It's just not a very scalable approach.
OOP just allows for bad code design and implementations to seep into the codebase, but it also allows for faster development. It's a double edged sword, but if you have a great Dev Lead and solid programming team, you can get away with it and reap the full benefits that OOP gives you.
Functional programming reels in the programmer, forcing them to design and develop better and more scalable codebases, but corporate heads hate the time it takes to get the products rolling and thus are very short sighted.
It sucks because most jobs are looking for programmers with OOP experience, and most companies have most of their codebases developed in some OOP language. 80-90% of programmers are mediocre and don't push themselves to get better. They're just the guy working that 9-5 for a paycheck, comes in and just focuses on the small section of code they've been assigned, and only worry about whether that feature they worked on does its job without worrying about any inefficiencies and possible scalability/side effects it could create later on. From my experience, software developers that take the time to truly understand software design and the design of the codebases they're working in are few and far between, which is why a functional programming approach is so desirable since that mediocre 9-5 programmer can just work on that small section, knowing that whatever they implemented has a deliberate outcome with no side-effects.
A lot of the issues with OOP come from how it is taught. Most tutorials focus on abstract examples that bear no real relevance to real code e.g. "class Mammal" / "class Cat".
They then go on to detailed discussions on inheritance, which isn't really used that much in modern code outside of a few small categories (interfaces, etc.).
There is also a lot of confusing dogma and theory surrounding OOP that textbooks and some programmers focus on religiously - e.g. Liskov Substitution, SOLID principles.
One of the best introductions I saw threw away all of that and instead did a step-by-step walk through for creating a "string" class in C++. Not only did it teach me the most relevant parts of OOP, it also made it clear to me straight away what the advantages and disadvantages are. Especially if you have ever tried manipulating strings in C versus C++!
Where did you get that introduction? In a book? If so, what book was it?
Yes, please tell us
Please share the clip, or book, where you found the relevant 'string' class example.🙏
@Sky Gardener oop is amazing for complex simulation stuff imo. Not so much business. If you're making something like a dwarf fortress style life simulator though I couldnt imagine doing it in anything but OOP. It allows you to rapidly scope out impact of features. Say you have something that you want to affect anything that walks on two legs-you dont have to remember all 30 biped races youve created, you have it affect the parent object type "biped" and call it a day. And if you create a new biped race you dont have to remember to add the new race to a list or whatever, its just automatically gonna do whatever bipeds do.
In any situation where you are creating something with a ton of moving parts you WANT to interact in unforeseen ways OOP is the way to go. When you have a very clear limited scope of functionality that you want to be very efficient and streamlined, OOP doesnt offer much
I'm a newbie and I understand what you mean about OOP not being taught properly. In my course, we've been taught Java exactly with the animal/mammal example and all of us were so lost/confused when the time came to do java challenges. Still today I struggle to understand how a language like java is actually used in the real world...
The $100,000 in student debt argument is only valid for the US though. Most normal countries allow you to go to college without having to sell a kidney.
That's way more than a kidney.
how much is kidney?
In France I went to public school and it sucked. Paying gives at least some high quality education.
Not really.. good CS education costs same in every country around the cost of a small car..
In india its pretty much the same, cheaper colleges are harder to get into cuz competition, and colleges with less competition are expensive
Also, because college with high competition get more attention, their degree is deemed more valuable.
So if you just want a degree for gaining experience in the field then tough luck, cuz you have to be an expert to begin with if you want it cheap. And if you take the expensive route, you degree is deemed useless
6:45 Come one... the point of the test is to be the specification. If the specification change the test changes so you can adapt code to the tests. Tests are needed EVERY SINGLE TIME unless you don't care about quality.
A CS degree actually makes way more sense if you’re in Europe and don’t have to pay anything for it
It actually makes even more sense in countries where lots of companies and institutions require certain degrees to hire someone (I'm in my third year of CS in France and it's definitly better to have one...)
In any country of europe?
Yes but there's also a lot less competition on the Job market for the IT industry.
If you know how to code, you'll be able to rake a job in fairly easily.
@@akshaypendyala nope, Netherlands changed their system a few years ago, around 2100€ just to go to an university per year now, average study dept is somewhere between 20k and 50k
In the UK you will pay between 9-20k GBP per year.
My logic behind getting the degree was that "if i dont enjoy my time working IT jobs, i'll at least have a bachelors to begin with" which helps ensure that i'm somewhat employable in general and that I can still support myself.
You and 90% of people, I'd say. I sure belong to that group, even if I ended up enjoying my time working in IT jobs, that was also my rationale for my bachelors/masters.
@@techtutorvideos You still pay years of your life. Of course in the long run that doesn't really mean anything, but it's hard to think like that when you're 18 years old and 3-5 years seems like a huge amount of time
@J Boss many positions arbitrarily put "must have a bachelor's degree to apply" in their job postings which automatically eliminates [most] of the people who don't have it. That's why having a bachelor's degree allows you to atleast apply for it without getting immediately eliminated.
Also MFs don't give you a job or even entry for Interview without a Degree.
There is a difference, you can tell if you did it, I have worked with so many programmers. It gives a wider perspective. Not necessary but relevant.
The speed is perfect. I actually watch tutorials at 2x speed just because tutor is boring and slow. Man, the thing you wrap up in like 10 min, someone is choking viewers for an hour or so. Thank you and keep on like this lifesaver!
2x speed watchers represent.
Same... each youtuber I follow I'll normally increase the speed but not with Fireship or Derek Banas.
On the unit testing part, (I am a junior developer) there came a production issue to our team and to solve that we introduced some meta data to our cache, I didn't feel to unit tests the changes but since it is the procedure, we did and found out 3 more bugs that were somehow passing before introducing the meta data, and so it helped prevent future production bugs.
Your video format is the best. It's like the sparknotes of programming. I can quickly watch a video and immediately know whether I'm interested in the topic or not. I also always know what I need to research more on and what things I'm already familiar with and have a solid overview of what that thing is and why it exists.
One thing i definetly found out, espacially in less professional programming circles is people spend way too much time thinking about performance. They think about how to optimise their code into oblivion and while there are best practices for every language you should always follow (for example using StringBuilders over Concatination for very long strings in java), it's not always the most important aspect and as soon as you work with an external system like a database, the speed of your code will become your smallest concern most of the time. Most business applications are very fancy database interfaces. Therefore optimizing your database usage is a lot more important then whether or not to use a for loop over a forEach.
100%. Nowadays, if your trying to make your custom code more and more efficient, your are prob not utilizing other systems and technology effectively.
I feel offended, yet I highly have to agree with your statement😂😭
This is the most web developer comment you could have given. Thanks to this type of thinking people have to wait 30 seconds for word to open.
I also think you should first worry about getting a rough prototype and then refactoring, but have the discipline to NOT develop new stuff while refactoring (you can just jot down any ideas you get while refactoring)
I myself like to find out ways to optimize my code sometimes for fun as an exercise, but I must agree that nowadays unless you're doing game development it doesn't even matter anymore
"comments that explain why something exist tend to be the most valuable"
Such a simple but great reminder, especially for people like me who get caught up commenting on what every bit of code does.
Thanks Fireship!
I use alot of swear words in my code comments :)
About the CS degree... I've been working in IT (mostly System Engineer, but also programming) for more than 15 years without a degree. I've recently started studying computer science parallel to my job and I have to say while I already knew most of the stuff (at least what I've seen so far), there are a few concepts that are new to me, especially when it comes to "choosing the right tool for the job". In the past I might have solved most problems thrown at me but not necessarily in the most efficient way. CS helps with that. Though I have to say that at least here in Germany, there is a lot of "empty information" that prepares you for an academic career but does nothing for you if you want to work at private enterprises. Also this "you must code my way" is definitely a thing. For example when implementing Quick Sort, our professor deducts points if you don't pick the rightmost entry as pivot though it has been known for a while that on average it's best to pick the pivot at random. This clearly discourages students from digging deeper into a topic and widen your horizon because it does nothing for your credits. It's just stupid.
But all this being said, you could learn all of the stuff outside a university as well, IF you're not a lazy bum like me.
After seeing you mention the negative feedback you’ve received I felt that I should share this:
I have probably gotten more value from your videos than any other in all my time on UA-cam.
You have repeatedly shaved hours if not days off projects of mine. I also love your editorial and visual style.
All that is to say a huge thank you!
same!
us
But it's true that information on here is often packed as shit, I've been on some 3 mn videos pausing every 5 seconds and repeatedly going back this spending 15mn on that video lol
The job market is entirely built around looking for senior Developers in favor of new developers in order to pool talent. In theory this means employers get good programmers. In practice It encourages new developers to BS their way to senior positions.
Yeah, no one wants to take the responsibility of training new talent, which is why the industry is so starved for developers. Plenty of young talent who never gets the chance to develop their skills further, which leads to a lack of skilled software developers.
100%!
I died a little inside after reading this.
I noticed the opposite, people are hiring juniors because they think they can train them and they're cheaper! The older you get, the harder you are to find a job
@@elmotareal must depend on the industry, big companies can afford the junior guy maybe? In small teams, everyone is looking for rocket scientists with 3 lifetime of experience for a position which usually isn't that exciting in term of tech and pay. The imbalance between expectations employer/employee hurts sometime, especially when you see the candidates knocking at your door with a degree in google only and with a school project they couldn't finish... it is what it is ¯\_(ツ)_/¯
"Clever" usually leads to hard to read code, but more thinking and less code is something I 100% agree with.
Often, a few more lines of readable code is better than single line of "clever" unreadable stuff that works, but no one knows why.
@@colombodoesstuff7653 So other developers have an easier time understanding the code, and also you might forget how your clever one liner worked and have to figure it out again.
I'm ok with "Clever" coding, so long as there's a super-simple comment, just so ANYBODY can understand exactly WHAT this crazy regular expression is there for :P
I disagree with this. Clever can also mean an abstraction that makes the code easier to read, removes some indirection, removes boilerplate or reduces duplication.
All that matters is that the code is easy to read. If the clever approach is easier to read then use the clever approach. If the clever approach is difficult to understand don't use the clever approach.
@@whossname4399 The difference is in the programmer.
There are programmers who write clever code, but their definition of "clever" is "I saw this neat trick/hack/shortcut in a project/repository/article and I now want to use it everywhere". They regularly use these tricks when solving online programming puzzles or playing code golf and now they feel confident bringing those approaches to production. Those programmers invariably write buggy and unreadable spaghetti code that will get refactored if not replaced the day after they leave the company.
Then there are programmers who use clever approaches. They manage their time and expectations so that at the end of the day, their code is simple, concise, and as dumb as humanly possible while still getting the job done. These are the programmers who write stable, efficient, and maintainable code, and they finish their tasks while the first programmers are still burning the midnight oil Googling why their tricks stopped working properly in the latest build.
Correct opinion: You’re writing your programs wrong if you’re not writing them in assembly.
2:36 I don't know where this attitude comes from and I really think its super unhealthy for developers in general. The expectation that developers should love to spend their spare time on the computer as well, basically continuing to work for themselves, is really putting pressure on those who don't see this as a healthy approach to a job. I find it not surprising that mental problems such as burnout are so common among software developers. Sure, there are most likely a variety of factors in play, but I'm certain this is one of them. Programming is a hard and demanding job. It is impossible for a human to consistently deliver the same performance during an eight hour workday, let alone after that when you're expected to work on hobby projects. Having little to no time for regeneration is a recipe for disaster.
Personally, I see programming as a tool, and nothing more. It is a tool to solve problems. Sure, it is a powerful one, but it's not the purpose of life. When I encounter a problem that I can solve with code in my work or personal life, I solve it. But I don't think coding hundreds of hours for the sake of coding is healthy nor is it actually that beneficial. In fact, I think coding in an experienced team with a more senior developer to mentor you is helping you out more than building the 623rd todo app with the 234th framework ever could.
The goal should be to built progressively difficult programs
Eight hours a day is plenty of practice, especially if you're solving real problems for real customers, and you take the time and effort to learn the most effective ways to solve those problems.
@@Rsharlan3 don't think the issue is working on your off time as much as passion for the field. A lot of people who only do it as a job might be less interested in getting better. Most of the best people I work with were interested in the field prior to working in it. Once your in it though you should have a life/work balance though.
The main issue I encounter with devs who don't love to code is that they are also the devs who write unreadable code. In their mind, if the code works, their job is done. Sure, there are exceptions, but a majority of the unpassionate devs are like that.
i think it is even MORE unhealthy to be doing something you don't enjoy. It's fine if you don't code on the weekends due to lack of time or something, but because you just get tired at the thought because it is "hard and demanding" then idk. Do something you like?
controversial opinion:
We focus more on being frontend, backend, QA, Devops or fullstack developers rather than being engineers.
engineer is a degree tho... you can have one in each of the label you mention. If you mean we should be more cross dev, yeah that's called fullstack isn't it? I'm not a big fan of labelling and semantics...
You actual engineering takes a backseat to ticking arbitrary checkboxes
Please don't say fullstack... It already takes a lot of effort to master backend or frontend.... I don't understand people calling themselves fullstack developers with less experience as they built a project (ToDo app).
Technology is changing constantly is another factor.
So, I am still trying to figure out, how a fullstack developer can be defined.
@@gagandeep609 That is why a full stack developer is better paid, because he HAD to learn twice : one for the frontend, the other for the backend
@@Naej7 They aren't though, check the latest stackoverflow survey.
On the Customer: I've never said no to a client, but made my clients understand why it was a bad idea / what the implications are.... And 99% of the time they listen, and the 1% left comes back a few month later .... waiting for their "I told you so"
Interesting to learn that pple think that your content is too fast, I watched one of your videos the other day and was amazed to see how many concepts you put in 5 min. Going this fast doesn't make you fully grasp the concept but it gives a good overview and makes you aware about the options available to tackle an issue. In my opinion, it's great to guide you in your research for the best option...
I like your speed. If it's a completely new topic it can be hard to follow but if I just want a brief summary or a refresher crash course it's amazing. You fit a lot of quality content in a short amount of time
I just pause the video when I need to catch up. After all, this is 2020's UA-cam, not 1980's cable TV.
Agreed. And you can always go back and watch again.
And UA-cam has a setting for playback speed for when I’m feeling dopey
Re: Unit Tests. It makes sense in some cases, for example: creating a library of math functions with interdependencies. Ensuring those math functions all pass a series of tests is beneficial and will save time and headaches when further along.
Everything needs to be tested. Otherwise what's the metric of knowing that your code actually works?
The difference between a QA and a developer is that QA should be thinking of edge cases where multiple functions/scenarios interact.
If your code fails my first basic test, e.g. 1 + 1 = 2, then we know you have issues with coding.
Unit tests don’t make sense for hello world program, but for anything long term they save millions of dollars to companies.
With bigger projects you might think you understand part of the code you work on, but they you get 10 unit test fails and you start seeing what you did wrong.
Games are somewhat tricky. I write tests for "library" code: math functions, file parsing, memory allocation, lock-free queues and regular data structures and fibers. IME, it's the lower / lowest level code that needs to be the most battle-tested. Fibers (aka coroutines) are key to make identical and not have subtle differences in assembly behaviour when porting. The case where you switch to had to be handled, and there's a test in the test suite for it. Pretty close isn't good enough. Get it wrong, and you have an opaque crash in the fiber's start function, and it happens *after* the function returns. You can't really reason about that if it's intermingled with regular engine code, but it's a trivially reproducible if it's segregated into a 20 line test.
@@whossname4399 I mean... you can't really unit test 3rd party APIs... you can only smoke test them.
@@GameFuMaster shouldn't have to test their stuff at all that's their job. You should test that it works in your logic though
2:13 Well, you are not using OOP then. You are just using objects in your programming.
When people say that OOP is shit, they mean Java-style where every function has to belong to a class, inheritance & stupid design patterns are everywhere, lots of mutable state, etc.
And that (i.e. Java-style) is object *oriented* programming. So OOP is, indeed, shit.
Objects are fine as one tool out of many in a programmers skillset.
@@Ignas_ nice logic there
That really depends on how you do things.
for example, in Java Android programming, you can inherit from Fragment to make fragments or make an abstract class that inherits from fragments to introduce fragments with extra functionality, those are both completely reasonable.
In many Projects people make a DB class that handles all the db stuff, encapsulating that into a single class is very handy.
OOP Can definitely be horrible, I've seen that many times, but that's more down to the dev.
Well, he's not using Functional Programming then. He is just using functions in his programming. When people say FP is shit, they mean Haskell- and Agda-style, where every variable is immutable, monads and stupid syntax is everywhere, lots of copying, etc
Function pointers are all that was needed
TL;DR: Testing is one of the most valued items you can add to a project when done right.
6:35 - 8:20 - I recently got a requirement to get Sonar Cube test coverage up to 90%. I explained to the client that I've been on the project for less than two weeks, and I can only do positive testing (confirming what already exists as it exists). None the less the client invoked "contractual obligations" that I had to meet his requirement. Now they sit with a negative view of unit testing since it is tested, but they still receive unexpected responses (since I had no way to dig through 6 years worth of requests some with only a one liner acceptance criteria to test if the requirement is met).
Today this channel gained a subscriber :)
somewhere I always knew that it deserved to be subscribed. Everything is sooooo quick, it's like learning and saving time, while making the video as short as possible no matter what. Also pasting code instead of writing is so much better.
@@matthewmango4461 lmao
I mean, that other dude's comment was also true. If you're hoping for a channel that guides you through the entire process such that you can do your own stuff, this isn't it. This is just a "get the gist of it" channel (thought I'd guess Fireship paid lessons are much more deep than these). For me, these are exactly what I want. I leave the video with a superficial understanding that is enough to kill my curiosity, without investing too much time.
@@carlosmspk also that other dude doesn't how to pause and play videos slower on YT
@@cristhianeduardovelazquezc6130 I think you're missing the point. It's not specifically about the video's speed per se, it's the content itself that is "rushed", he could slow down the video all he wanted, and the specifics of implementation, further use cases, and detailed rationale still aren't there, because that's not what this channel is about. Again, because this is the internet and I know someone will completely misinterpret my words, I feel the need to reiterate: I don't agree with that comment, but that doesn't mean it didn't have its merit, everything the dude said is true, it's just that no one who subscribes to this channel expects anything else...
Yup, I love this rushed video manner. I'm getting asleep whenever pleople are explaining things sooo slow
controversial opinion: practicing leet code examples is the biggest waste of time.
not if you enjoy programming challenges, or data structures & algorithms
And big companies love to use them as interview questions which you will spend weeks preparing and to never use them again when you get the job
I think it's fine to brush up on your DSA from time to time. But that shouldn't be your main method of 'improvement' as a programmer.
depends on why are you practicing it, if it's just by joy it's not, if it's for beeing a better programmer o gaining a "faster mind" i guess it is not a waste of time neither.
But it wont get you familiar with all the new technologies o will make you related to a specific business.
Not if you have an Interview Coming up.
6:19 Back in my first 3 semesters of programming in college we had this teacher that quite literally will turn down your homework if you didn't write it the way he does it.
At the time I thought it was because the way he was teaching us was the correct way, even when I noticed I could get to the same result in a different way, but because I feared to get all my hours of work turned down I had to write my code the way the teacher told us to. He was not very approachable whenever we had problems with our code, be it syntax or logic, as the moment he saw us writting in any way different than how he does it he immediatly turns away and tell us to rewrite the whole thing but in the way he told us to. This made for classes and projects to be very tedious and frustrating.
At the fourth semester we had a different teacher meant to teach us higher level programming skills, and that teacher never cared for how we write our code at all, sure, he will teach us one way but once it came for us to do our own projects and homework he'll take the job in which ever way we made it, and the coolest thing is that this teacher was incredibly helpful when we got stuck with syntax problems and stuff as he could detect the problem by just looking at the code for a few seconds, regardless of how we were structuring it. This lead me to believe that the reason why our past teacher didn't want us to write the way we wanted was because he was lazy and didn't want to figure out our logic on the spot and rather just have us copy paste the code every time, but by hand, so we make it easier for him to understand what's happening, but not for us.
I'm grateful for our latter teacher and the ones after him since they reignited my love for programming by teaching me the basics but leaving me room to do stuff in whichever way I see fit and explore options as I go.
fuck your old teacher, coding isnt about memorizing, there is no 'this is the only way you can do that'
It's also the difference between eastern and western teaching modalities. Eastern modality, you are often taught the one correct way to something 1000 times until you achieve mastery.
And the Western modality, you stumble around blindly doing a thousand different wrong things, until you achieve mastery.
Great things are achieved by Masters and both modalities but it does appear The Western modality provides a creativity and lateral thinking advantage. However a lot of people give up and quit.
I think that teacher being lazy part could be really true.
I had a completely different experience in university. We were just given an assignment and a few slides which generally explain how to solve somewhat similar problems and the rest was out own job. There was a forum to ask but most of the times the answer was "if I tell it to you then you won't work on your own".
it made for many sleepless nights but we were really kickstarted into thinking, being creative and working on our own.
but I think it was quite a lot of work to set up, so I'm glad they did it.
It could also be that your way of solving the problem was valid but less clear or harder to debug.
@@macmcleod1188 There's rarely such a thing as "the one correct way".
This was the first time I heard the opinion that OOP is bad. When I thought about it, I realised I frequently create classes simply to partition related stuff. Which is what C & C++ have namespaces for. I tried implementing a tiny project using namespaces instead and the result was shorter, cleaner, quicker to write & easier to read. I'm not ready to throw classes away, but I think I will write far fewer of them in future. Yes, I write code in my spare time. I did that when I was working as a software engineer and I still write code for fun now I'm retired.
I adore your fast paced style! The key information I'm looking to discover comes so much more quickly and I stay more engaged. Also, your code is short and straightforward enough that I really don't want to see you type it out. Keep it up!
In my career, I've found that the advantages of OOP come in the form of its relationship to the physical world. I've found that for many problems, it's just easier to think about it with OOP than it is to think about it how to solve it with just functions. For example, abstracting away interfaces is pretty clean with OOP.
You have 2 important keywords in your post "problem" and "world". I think it's generally better to model the problem, than to model the world. Sometimes both things overlap but not always. When they don't overlap you often end up with classes that don't really exist in the real world, like managers, delegators etc. OOP works really nicely when your problem domain really does contain many of those real life objects.
@@MsJavaWolf not necessarily. I’ve found that most problems in fact can be explained with things in our world. Are we to believe that managers don’t exist in our world?
I've found the total opposite. I think it's a way of thinking. OOP is really hard for me to comprehent as I'm more of a "connect the dots" thinker. Functional programming is way easier for me and way easier to mainain as well.
OOP is definitely an amazing tool at modeling not only the real world and the subsets that make up the problem at hand, but also how to go about designing the solution for such problem. It also makes your solution easier to explain at a high level, which is invaluable when communicating your solution.
@@zorbat5 I like to think of classes as just another type of scope - function scope, file scope, for-loop scope, etc.
You don't need to be "love programming," but passive interest in tech (like watching this channel) can greatly enhance your ability to understand complex systems, at least at a high level.
That's only true because programming is rather more involved than just programming. You don't necessarily need to love programming, but if you don't love problem-solving, puzzles and searching for efficient solutions, you're probably going to be shit at programming anything interesting.
You can love programming but hate coding, coding it's just a tool to get the job done & tons of people seem to think that programming is typing in any language on a dark terminal
You don't hear carpenters claim that you have to love hitting a nail with a hammer to be a carpenter, that's just a tool. You should like building stuff instead
I don't see how people who treat it as job can be better than people who immerse themselves into it all day and night.
oof i strongly disagree with this one so you win i guess
@@crusaderACR In what sense? It’s a fairly benign take and most devs would agree.
You don't need college to become a programmer, 100% agree with that. HOWEVER, college forces you to do assignments which involve solving problems you might not normally do/solve them just by searching for the solution and be done with it. Sure, its easier and faster, but doesn't teach you anything. Doing assignments is a pain in the ass for me quite often, but in the long run I see the value in them, you learn to solve things differently and become better at problem solving overall.
Another point would be that college walks you trough the programming step by step, starting at the start and ending at the finish, not jumping around like you might be if you are a self-learner. Sure, a JS developer won't ever touch code written in C/C++ in their career, but it's crucial to understand how everything works on the lower levels in order to write performant code on the higher levels.
But I understand that having to take out a loan for college is a deal breaker for most, luckily I don't have to pay
College doesn't really teach programming. College teaches computer science. They are different things.
Programming is a trade skill like Plumbing or being an electrician.
@@macmcleod1188This is pretty much how I think about it. I always refer to coding boot camps/schools as "trade school", because that's what it is.
Going to school for CSE is different, it's like having an apprenticeship in plumbing vs studying mechanical/civic/chemical engineering. In both cases you have the skillset to make money and support yourself, but the latter gives a deeper understanding. It's not needed, but it great for those that want to know the theory or want to go into R&D.
A basic intuition for what takes up time (usually IO round trips and more rarely CPU) as well as space (memory and disk) is really valuable. You don't have to be a wizard in time/space complexity analysis, but a lot of the self-taught programmers are simply unaware and end up with under-performing applications at the worst possible time. For instance, if you get 10000 new users over the weekend because of a blog post, but there's a sequential bottleneck, you're in a very difficult and time-pressing situation.
Now, this isn't just a problem with self-taught or beginner programmers. Many frameworks, libraries, etc, aren't even documenting how much resources operations can be expected to use. I end up having to write my own micro-benchmarks to get a ballpark sense of performance. A great counter-example is Redis, which has incredible documentation including time complexities of every operation. More people - especially framework and library developers - should follow their lead imo.
The main answer to all software questions is: “It depends...”
the answer to almost all software questions is "it depends" :D
That's basically the answer to everything.
@@farhanaditya2647 it depends
@@JohnCarloCahimat You got me 😂
And it's a headache because no one wants to take the responsibility for deciding what it should depend on.
I always wanted someone to teach things fast, sometimes I just need to know what is possible
Premature optimization is a huge problem. Ironically more often for more experienced programmers. That's likely because more experienced programmers know more optimizations and like to apply them to show their knowledge and to improve the code which directly leads to premature optimization.
I'm a bit torn on this one. Because at what point would one consider it to be premature?
If it's code that should run nightly and basically create a daily report, it might not have to be very fast. However, I know many situations where a job has not been fast enough.
I've also seen some outright awful ways of processing data and reading files. The worst one being when a large XML (100k rows) was read, checked and data stored in RAM for every entry in a rather large array (about 1000 entries).
That was obviously just someone being stupid, but it's still a case where I had to retroactively optimize. The code itself ran, but was O(n^2) instead of the O(n) after I rewrote it. That's a massive difference.
@@CottidaeSEA would you say premature optimization wouldve been a good thing in this caze?
@@evryon1810 The tldr is basically; just make sure your code isn't shit and does unnecessary stuff and it's never premature optimization.
I would say it's not premature optimization, but the correct way of doing things. Assuming we're talking about my own example.
The old code had several issues:
1. Performance.
2. Maintainability.
3. Readability.
4. Testability.
After refactoring the code, it ran better, looked better, was possible to test and was easier to adjust later on.
So the optimization was really just a result of doing things right. Had the person who wrote the code known how to structure code in a better way, the optimization would not have been necessary. I literally just took a loop out of a loop and threw the result into a map.
I do have another example though. The code was written in PHP, we couldn't figure out what caused the pages to load slowly; until I checked. We had been fetching a whole load of data then used array_intersect to find matches. Each time only took a few milliseconds at most, but run that 20k times on page load and you got a resource hog.
What did I do then? I just did the sane thing and fetched what we wanted instead of everything. We already had information about what IDs we wanted to match, I just had to adjust the SQL a bit and throw out that array_intersect since we already did the filtering.
Again, another time where I wouldn't say it's necessarily optimization, but rather doing things the right way. Had I written the code, that issue would never have happened. My code isn't flawless by any stretch of the imagination and frequently has bugs that I usually find promptly, just edge-cases being missed, but never to the point where the code is severely logically flawed.
What I consider to be early optimization is more like using bit shifting because it'll save you a little processing power once in a while when doing a very specific calculation. However, if you have something that'll run pretty much constantly, then optimization is rarely premature. Might not have to squeeze every little gain into it, but should at the very least get the work done in as short of a window as possible. It shouldn't delve into the world of the arcane, but just some sound logic is usually good enough.
@@CottidaeSEA i understand, thank you for your detailed explanation 🙏
One thing experience teaches you is to hold off on optimization until you get the code actually working correctly.
I revisited a personal command-line script of mine a few days ago. It was taking about 6 seconds to start each time. I soon discovered a couple of things:
* Importing matplotlib is quite slow. So if I defer that to the actual plotting function, so it only gets imported if I use that function, that speeds up the invocation of other functions.
* When computing stats over a particular sampling interval, my database query was iterating through all the samples and discarding ones outside the range, because I couldn’t be bothered narrowing things down within the query itself. That made sense at the time, but now I have accumulated over 150,000 sample records, it was time to revisit this decision. So I added a couple of extra queries to determine more appropriate time bounds for the actual query for samples.
As a result, displaying accumulated counts over the last 30 days went from 6 seconds down to about 1 second.
In my experience, unit testing is really nice when you want to refactor some stuff. Tests are very nice to see where you made a mistake in those cases.
And changing requirements are exactly when you want to be able to refactor easily. Also if you write your tests first you tend to only rely on the interface, so your code can change without breaking the test.
Sounds like you agree with the concept of writing tests to make sure code *stays* correct?
@@problemat1que Yes. Tests can also help write code in test-driven development, especially when you can just write tests with inputs and expected outputs.
I fully agree. It's easy to just test a new function manually, just run it in the main once and you probably know if it's correct but you don't want to do this after every refactor. Code breaks so often after a refactor, someone might just add a throw or something else that looks insignificant but it can break code that looks completely unrelated.
I'd say coverage can be really subjective so 100% is not a good choice if it means 100% total lines but 100% scripts can be a great rule of thumb
Well, on the other hand, I think your teaching style is the BEST, why watch a tutorial for 40 minutes when I could watch a better one in 5 or 10 minutes? Keep up the good work !
100$ agree. High information density while still being approachable.
I'd say it's not that you need a CS degree, but some exposure to the sort of theory taught in CS programs. Even academic topics in software evolve quickly, so constantly learning and staying up to date is far more important than having had good teachers at one point.
And when "up to date" involves learning something that is completely out of left field and will never become popular because it isn't useful? Chasing academic theories is a useless waste of time, better to focus on common sense approaches.
I feel like CS was amazing in the '90s and has now devolved into a branch of abstract mathematics mixed with microprocessor archeology. 😛
But definitely read "CODE" by Charles Petzold! 🥰 Other than that, study what you need on the job and what you love on your own time.
I think in practice a CS degree forces you to learn things that many people don't want to learn normally. I have seen so many people produce bugs because of string encoding for example, that sort of low level concept will often be taught in CS.
@@MsJavaWolf Since I'm great at string encoding (and binary in general, hand-coded x86 assembly and hand-coded WASM! :-) ), I'll disagree. My obsession with stuff like that is worthless, and so is pretty much all of a CS degree.
For 99% of programmers, learn what you need when you need it, and do good enough work. A few programmers out there are real geniuses that will solve AGI and put us all out of jobs in a few years anyway. :-P
What is important about formal education and good teachers is the mindset you develop about programming and coding. CS enables you to view things with a mathematic-scientific-systemic approach and not just code-crunching with the latest and buggiest tools
I'm a self-taught programmer of 31 years and counting. For what it's worth, your videos make me smile if not genuinely LOL. Please keep making them :)
IMO test-driven development's value is context-dependent. If you're writing front-end software or anything else with a high degree of interactivity, it's a lot more likely to be a waste of time, because 1.) it's much more work to develop tests, and 2.) the requirements are likely to change, especially early in development. Scientific computing, on the other hand, usually involves some calculations that are absolutely fundamental to the problem being solved, so it's easy and recommended to implement tests before implementing algorithms and interfaces.
In other words, you cannot properly automate GUI testing, but algorithms can certainly be tested.
That's probably why they focus on unit tests most often
unit tests are starting to grow on me even more recently. unit tests or not i'll have to test my code anyway and it's not usually easier than writing the tests given that there is a framework in place for it. i hook up the tests to my debugger and it saves me a lot of time
you can absolutely automate GUI testing.
it's just difficult.
i work on a mobile app which does this successfully right now, sharing the same - huge - suite of UI tests (based on Cucumber) among the Android and iOS version.
"it's much more work to develop tests"
it is, especially since they tend to be flakey (eg. failing on some given device).
but it has benefits too.
it forces the specification to be clear, and the implementation to be consistent across both versions.
it detects device-dependent issues (eg. some element doesn't fit on a smaller device, and thus it's not accessible to the user).
"the requirements are likely to change, especially early in development"
right - and when they do, and you have rewrite a part of the app, it can save you a lot of time if UI tests protect you against regressions that could crawl in - preventing you from breaking something as an unintended side effect
it's much more work to develop tests than not to develop them, but it can also save you a lot of work elsewhere.
@@lawrencedoliveiro9104 you can automate gui testing though... you could turn your gui program tests (in something like selenium or javascript DOM event firings) into a GUI scaffold maybe using chatGPT or something.
My Unix professor told me once: "the university doesn't grade intelligence; it grades discipline"
My take is that the biggest value of getting a CS degree, is that it forces you to learn how order your mind and ideas. You can definitely google anything, but in the end you write instructions to a machine to do something, and mental order is an invaluable strength to take your "creativity" and transform it in something you can organize and apply
Personally I feel a college degree is more like a aptitude test. When you have a degree, the university is stamping approval on a paper that you have meet the base requirements for your field of study. It shows future employers that you have the potential to achieve.
I went the degree route because I like the traditional way of learning things. I also like that having classes with assignments helps to motivate me to work on the craft, and it also steers me toward new areas of focus that I might not have found as quickly on my own. With that being said, now that I'm in my final semester and have started doing a couple interviews, I do feel that the degree isn't swaying things in my favor much since they still seem to judge me mostly on my perceived personality and communication skills...and of course, on the fact that I still have little "experience" outside of school assignments.
My goal now is to try and throw a few side projects together just to have some more examples of things that I built from the ground up. Fortunately, I'm finally starting to actually think of side projects to work on! For a long time, I had a kind of paralysis when trying to think of things that I thought I was capable of making. These last few classes have made me more confident that I could actually throw something together that isn't a glorified "Hello World" type of program. lol
IQ and ability to do lots of work are both inputs. The different majors have different average IQs and practically no one with a sub 100 IQ gets an engineering degree is my understanding.
I like having a structure to learning stuffs and I felt the freedom of choosing what to learn may be overwhelming if I were to start as a self learned developer
My dumbass professor graded by how interested he was in the subject.
7:20
Yes, 100% yes.
I've experiece many times in which I, as a developer, decide to go an extra step thinking about user experience, just to be shut down by clients who think what I did was "unnecessary" and that I need to take it out entirely.
As an example: one time I was developing a web app for a client, and in one of the pages a table was needed to display data, and as a little quality of life improvement I added on my own was to add an extra row of titles at the bottom of the table so if the table gets bigger than the screen the user can still have visibility of what column they're looking at, that's all I added on my own, and when the client checked the app noticed the row at the bottom and after I explained why it was there, he was all like "Looks weird, and I don't believe we'll need it, take it away" and take it away I did.
Days later, another check-up and a bunch of data was added so the table grew big enough that the top titles hide when you scroll all the way down, so I proceed to agonize internally whilst the client is giving the scroll wheel a run for it's money.
It's a small example, but it goes to show how sometimes the client knows very little of what they need/what's better.
Perhaps the expected experience was a frozen headline at the top, like you can find in most spreadsheet software? Perhaps you were talking to an SME who knew the column labels inside and out and other users would have reacted differently? Did they ask you to put it back in when the table became long enough?
@@problemat1que No, not really, I wasn't given any instructions regarding that table other than removing the second row of titles and that it had to have exactly up to 20 rows before it needed paging for the rest of the data, and this person never mentioned the table again despite de problem with the row quantity which caused the foreseeable problem of needing to scroll up to check the titles.
I'm willing to believe based on what I've seen about this person that he's very old fashion (to call it something) and honestly rather detached with user experience in general.
I always like analyzing the code you need to change first, than looking at how you can interact with API and going for an hour-long walk.
When you come back, you will almost certainly have some good idea on how to make things easier!
I find test driven development (writing unit tests first) very helpful. It helps you feel out the API of your functions. Gives documentation on how to use your code to others. And helps you check if you break something after a refactor.
Test driven development is never going to teach you how to design well. That requires techniques that require a global view of a design so that you don't make fundamental design mistakes when you are down in the weeds coding. Committing to code early is a great way to make a mess. I'm not saying you don't design, but your comment isn't specific about the pitfalls of early code.. so thought it was worth mentioning.
This is VERY important. Coding mistakes usually end up with 2-liner fixes after a bug is reported. But serious design mistakes might require re-writing a significant portion of the code you just wrote.. with no shortcuts at all. This is why to me, design skill is THE skill required to be a great programmer. Since programming is SO time intensive, preventing mistakes that require rewrites is a HUGE goal.
6:08 Actually I prefer teachers who teach the fast way but making it understandable and imo you do this very well.
Controversial opinion: for some managers, 'Agile' gives them an excuse to micromanage the work of people, causing them to isolate when they should ask for help.
thank god for agile and scrum with good managers.
Unit testing starts to be great, when whole project recompiles in order of minutes, application starts in order of (tens) seconds and you are writing some low level library. Also pieces of code covered by unit tests usually have much cleaner interface and tend to rely on dependency injection, rather than having large blob of code. Another possible solution is basically writing whole stand-alone application and then to integrate it as a module.
Controversial opinion: The hardest part of getting a CS degree is learning to pronounce "Dijkstra"
Edit: And group projects if you're unlucky
i don't see how that's controversial
daikstra
True that. When I met a dutch person IRL for the first time, this was my question to her.
Is this implying a Cs degree is easy or that dijkstra is hard to pronounce?
I did an engineering degree so I genuinely have no idea
@@JacobKinsley The latter
I want to mention: your opinion on OOP and experiences with it are actually kinda the argument most people who oppose OOP are recommending as an alternative. Objects are fine, it's the orientation that's the problem. You description of your own code is not object oriented, it just happens to use objects when appropriate.
You could say he is results oriented and objects are just another datastructure to so get results.
the thing is, the user dont give a fck about OOP or FC
Meanwhile I'm just sitting at the side writing both Java and Python at the same time with no issues lmao, people need to find better things to do in their free time than complain about language features
@@theshermantanker7043 oop isnt a language feature tho. it is an concept. Which in practice never tends to work.
Comments like this make me think that despite almost a decade in the field + a 4-year degree I never really learned OOP. Beyond encapsulation I don't think I've ever really used any OOP principles in my code, apart from a handful of interfaces that only exist because of cross-language interop needs, and one module that is really more data-oriented than object-oriented, but polymorphism was handy in its implementation (also I'm not convinced I wrote that particular module that well).
@3:40 My favorite response to someone sharing this snooty image is "...and the customer ordered a square."
which hits so close to home. Sometimes programmers see the spec and just kinda run with how THEY think it should be done.
If the customer ordered a square they all got it wrong
I think the biggest problem I have with videos like these is people editing our their breath between sentences. I use the breaths as a split-second break for assessing that sentence subconsciously, and didn’t notice I needed that pause until I started seeing it happening more frequently. Without it, I need to pause the video myself and I can’t always do that, or want to. I hate that it’s so common now, and I bet that this is the problem for other people complaining about how fast you talk also.
In contrast to that one comment you mentioned in the video, I really like the speed of your videos. When I don't understand something I can just rewatch it several times, but don't have to watch someone type a few lines of code for 10 minutes.
Readability vs performance is an interesting conversation to have. The thing that I've found over the years that really annoys me is that there is a lot of blatant disregard for performance up-front. Especially in areas like REST-ful API designs. There is most definitely a balance to be found, but there is a significant portion of developers out here that for some reason don't even see performance as something worth considering. There have been countless times that I've seen PRs with optimisations built in (for good reason, such as making things asynchronous if they are not required to be finished in the immediate scope), that get VETO'd because of a desire for a more readable version in synchronous implementation. Or an even more common one is not acknowledging the impact of altering dependencies with a DI driven environment. I can't make it any clearer how many times there have been scenarios where a full team will spend a couple of weeks or a month on diagnosing a source of performance degradation that accumulated over time, and it resolved to ignorance around the impacts of certain design choices to improve readability. I just wish people wouldn't be so damn ignorant and hard headed in their opinion of readability always being king. ITS NOT ALWAYS THE CASE, it's fine to keep readability key, but don't ever ignore it because you don't see any immediate worth or you think that maintainability of the highest standard is always ideal.
There is room for everything, you just have to figure out when to use one or the other. It should be very obvious.
I found that performance only matters in such a tiny percentage of the code that is better to wait until after you've written the code, use a tool to identify that code, and then optimize that code.
@@macmcleod1188 We have the cases when we handle big amounts of data, when there are many requests simultaneously, and when dealing with adio/video/images /hardware... Not that tiny the percentage.
@cheogt yes and even in those cases, optimizing the entire program wouldn't be productive.
I've written video games, Minecraft box, I've written for huge database machines at Fortune 100 companies, and I've written online order entry programs. I've used assembly to C to Java.
I never saw a case where it was more than a few dozen lines of code in the whole program that mattered in terms of performance. Some of those programs for 30,000 line monster programs.
So you write 99.9% of the program to be easy to maintain and then optimize the remaining 0.1% with lots of comments.
Just imho but it is an informed imho.
I agree with a lot of bad teachers on medium/youtube, but you’re not one of them! Your content is structured very well, and you mostly keep your opinions broad! I completely disagree with people who call your content rushed! Keep up the great work as always 🔥
From my personal experience: unit tests are almost always useless when you develop something new. But it almost always pays off tremendously when you come back to change something after few months or you need to do some refactoring.
I don't like writing them, but the fact that they saved production from countless bugs, gives me motivation to write them.
Also another thing for me is that I write unit tests for my self and my colleagues and never ever for client requirements or manager requirements or to reach some code coverage. So in a way they cover the feature requirements, but still for me main idea is that I know for sure that things are working in a way I intended them to work.
By the way I love your videos, keep on going!
For one, writing unit tests forces you to think about edge cases beforehand (and clarify requirements in regard to those).
This is a huge gain in and of itself, in my opinion.
One thing that I found valuable about my college degree (IT) is that there were courses I was required to take that had nothing to do with what I wanted to do with my career (e.g. computer networking or cybersecurity) that later had practical applications on what I was working on.
I love today’s departure video. Want to see more like this!
0:18 If I asked such a question, the moderators would have blocked the question, stating its unsuitable for stack overflow
😂😂😂yea mf explicitly mention *NO OPINION BASED QUESTIONS*
The reason you don't do those things in javascript, is that JavaScript is not an object oriented language.
You can choose to program with it like it's object-oriented, but you're not required to.
So you are not using object-oriented methodology that you would be forced to use in Java or C#.
Newish programmer, know a moderate amount of C and Python. And my favorite part is when I take a break, think about a solution while watching something, then immediately get it right. Breaks are a crucial part, let’s you look at the whole picture. Some people think too hard on one thing, then get stressed and can’t complete it. Been tutoring a couple even newer student from Cornell (I don’t go there, some of my friends friends) and most of them think too hard about simple questions.
It is not *just* about the break, the process of thinking hard about the problem in the first place (spending time to try debugging, even though failing) is crucial for "returning back from break and solving it in 5 minutes".
It's the way the human mind works, you need to process switch in order to retain info better. You don't want to operate off cache all the time, you need to write to a permanent location sometimes in order to correctly associate old and new information.
Breaks are for 1x developers.
@@colombodoesstuff7653 That's why Rubber Ducking a problem works so well. It forces you to restate all of your assumptions and re-think them.
Controversial opinion: 95% of programmers don’t need to know the common algorithms you learn in college (like merge/heap/etc. sort or the knapsack problem)
Because majority of them end up maintaining the already written code!
@@akshaypendyala Even if they write fresh code. They will most definitely use a more generic, more performant and efficient version from a library, be it built-in or third party.
I haven't even use a "do while" in 2 years, and that is not bad.
In College they teach you logic and how to use it in programming, at least at the beginning, and algorithms like merge, heap and other are to improve that logic
It really depends how low level you are programming. I use the heap all the time, but since most programmers aren't writing C code, I guess I agree that most people don't need to know that. But it is fun to know :).
I think understand them and implementing them puts you in the mindset of being a programmer. So while I dont think you should know them off the top of head, you should learn them when you start programming to teach you how to think about code.
For the record, just wanna say I really enjoy your teaching! Thanks so much for making all this stuff and posting it online!
Applied math researcher here. OOP is pretty good to make code readable, which is pretty important in research. Also, research code doesn’t need to be maintained usually, since it’s a one-off script to test something.
OOP doesn't make code readable if you use inheritance a lot. In that case it actually disperses and even duplicates code. This is a big deal if you have to fix a problem with a method in one class because now you also have to check the code in all derived classes that have a modified version of that method. It's basically the same problem as with forking, just internally to one program.
The comp sci degree part hit home. I've been relatively successful as a bootcamp grad with a non-technical bachelor's degree and I still wish I had done CS in college...
Political science major here, same.
Bootcamp grad 🤡
For me OOP is very good, but it's not like you're forced to do it every time. You can absolutely use an OOP language without doing actual OOP.
Game development makes very good use of it, specially when your settings require constant changes in number of entities.
Yeah I was a bit confused about the OOP section. Maybe for something like web development you can do functions-only, but the first thing I thought of was game development; I don't see how you could reasonably make anything that's more complex than Space Invaders without using objects.
@@ZachAttack6089 Using "objects" does not necessarily make your code OOP. You can use objects but not do OOP (by separating data-classes from service-classes). And you can not use objects, but still use OOP (by using structs with functions and initializer functions). Also, quite some game engines these days use entity-component systems, which are not really OOP, so modern games are unlikely to heavily lean into OOP-style class hierarchies.
OOP as it is understood these days (the style popularized with Java) teaches you to bundle state and functions related to that state together into one class. Structs/objects without functions are probably not OOP and you can perfectly write complex pograms with them by organizing your functions in another way (modules, service-classes, etc.).
@@KatharsasOfficial Ohh I see. Thank you for the detailed explanation! I had assumed that OOP simply meant relying on classes and objects.
Even Java, the language famed for being overly Object Oriented, works perfectly fine when no objects are actually used (Possible with static methods, annoying as hell, sure, but perfectly doable)
I agree, as BIM developer the BIM softwares would be a mess wihtout proper OOP because they have 1000+ types of objects comapred to a usual web app. I also develop web applications where OOP is not needed that much.
I love the fast paced content it means that I get to keep moving and if there is a skill I am struggling to remember or learn I can watch the short informative video multiple times in a week or stop and rewind whenever I need to hear something again. Frankly, this is the perfect speed for me to write notes and understand what is going on. I only wish I had more daily content from you.
I love the "It's ok if you don't know it. But you're fired if you can't even Google it."
I feel like there's an irony to saying OOP is bad, and then preaching immutable recursion as the answer to all things.
IMO the problem with OOP is the "Oriented" part. Objects, classes, inheritance, etc are all useful tools and it's great that they became popular, but OOP as a design philosophy is almost always the wrong approach.
The current paradigm for new languages uses these features where they make sense within many other design philosophies, and I think that's the correct approach.
Who says that immutable recursion is the answer to all things? I would say that most pure functions don't use any recursion. Immutability is always preferred though.
Ye i learned to love OOP about half a year into programming in 7th grade, its the best thing ever
and then complain that software is slow.
Of course is slow, immutable recursion requires a lot of copying data between memory layers, including SSD or HDD
@@JosifovGjorgi Um, that can be optimised away in many cases...