"Stop trying to communicate and just communicate" is actually career-changing advice.
7:50 bad code example 9:18 problem: 14:00 fizz buzz basic code 19:52 table lookup way 20:22 problem: havent got rid of the second check 21:05 answer in JS version 22:45 Cargo cult programming 32:33 is too many imports in your code a bad thing 33:38 avoid long imports by using wildcard 38:30 another aspect of Cargo cult programming 45:04 46:37 ConfigurationManager 47:43 Configuration is way better 47:48 ConditionChecker 48:40 Condition is way better
11:09 "Sometimes when you approach the problem from the wrong angle, you can really make it something of it" is so relatable.
Sometimes code isn't re-written because it's "bad". It gets re-written because somebody has a different opinion on what "good" and "bad" code is. You don't necessarily end up with "better" code. You end up with different code. Rewrite culture is definitely a thing.
"There's a lot of developers who can't program." True. There's a lot of programmers who can't develop, too.
22:14 " ...and we've reduced it to its essence, and we can wander around feeling mathematical, functional, and remarkably cool, and also very certain of our jobs. So there's this other side to Enterprise Programming that we see in a number of cases, and again I want to refer to this point as being Art: It's clearly a unique result of a unique temperament... "
I worked at a company with a guy who committed almost every enterprise programming sin mentioned in this. He was absolutely obsessed with making wrappers and abstracting the most basic functionality into monolithic classes. If I every asked him why he was doing it, he would tell me that it is "good design".
Wildcard imports in Java would be nice if they didn't cram so much into every single package. Seriously, it feels like they just use the java.util package as a dumping ground for anything they didn't already have a package for; it holds pretty much every data structure in the entire language plus a few other arbitrary features like Currency and Date that have pretty much nothing to do with anything else. The other major issue is that wildcard imports erase the data of where each class you're using actually came from. This isn't an issue with the standard library, but it can get pretty bad with large codebases importing code from other packages in the same codebase. Without IDE indexing features it's basically impossible to figure out where any class in a file with wildcard imports came from, which isn't very nice generally.
I love how almost each and every video in this channel is simultaneously educating and entertaining!
Frankly, if your code has too many imports, the issue isn't that you should be using wildcards. It's that your class is doing too much all by itself. Half the reason it's recommended that you import everything explicitly is exactly so that you can identify it as a code smell.
"It's a stringly typed system"
Having only started with Objective-C(++) less than a year ago, I lost count how many times I wanted to look up and strangle the person who came up with that language's naming convention. "Nonono. Having a function doThing(ArgType):arg and another function doThing2(ArgType):arg (Arg2Type):arg2 is bad. You should call these functions startThingDoerWithArgument(ArgType):arg and startThingDoerWithArgument(ArgType):arg andSecondArgument(Arg2Type):arg2 " - some daft maniac who really likes poetry, I suppose. The only reason why we stuck to this style for our iOS code is because other iOS developers expect this style. Repetition does indeed increase truthfulness. No wonder people have huge full HD or 4k monitors these days. It's in an attempt to fit method calls on one line.
I loved this talk. I retired last year (2021) but have seen this kind of stuff throughout my entire career in one form or another. Management don't understand any of this and people get promoted to positions where these practices are imposed on people below them in the hierarchy. Glad I'm out of it. Well done Kevlin.
"All roads lead to stackoverflow". Yup
Speaking of code commenting. In school, high school or college, it seems in the beginner programmer courses the teachers are quite adamant about adding comments. In high school, they just don't add comments and so the teacher pounds it into their head to document every line. In college, the comments may be sparse among the spaghetti code that gets turned in. The professor comes back with "add more comments," and docks points. I had dev experience when entering the beginner Java class at university and, of course, commented the necessary lines and it was a nice bit of code. The student aid came back with "add more comments." Oooh, boy... did they ask for it then!
I disagree with the point on imports. The only time I ever look at imports is when I'm reading someone else's code, and in that case I want to know exactly what package a specific class is in. Using * imports would mean I have to guess which package it's coming from, or I would have to have the project loaded in a tool that can calculate dependencies for me.
We run software that about 80% of the companies users rely on every day. When designing an API, I mentioned to the enterprise architecture team it was an enterprise document API. They asked if it accounted for all documents for all systems…I said no, just our teams system which accounted for 99% of all documents in the company by volume. He remarked that it wasn’t an enterprise API then and it was an application API. I said “sure” and moved onto the next thing in he meeting.
Other examples of import collisions: - DateUtils (apache.commons vs apache.http vs of.course.your.own) - Function (java.util vs various spring packages) - List (java.util vs hibernate) - Collection (java.util vs hibernate) - Map (java.util vs hibernate) - Optional (java.util vs bytebuddy) - StringUtils (apache.commons.lang vs apache.commons.lang3 vs of.course.your.own) - Date (java.util vs java.sql) - Assert
"If you get the names right, you are communicating design" : 43:16 Leading into real code examples of "Stop trying to hit me, and hit me" (renaming methods/classes to make it clear, specific and concise) : 46:40 and 47:46
@DoubleBob