In my object training class, students recently (with AI enabled) get the correct answer generated. Of course, my reference solutions to my exercises have been scrapped and added to (at least one) AI engine. So, it is good code in my opinion. After all, I wrote it! But these same programmers didn't even understand what that generated code actually did. So maybe another question is, "Do programmers even understand the AI generated code?"

Version control won't be an issue because A senior dev will take a new feature and break it down into small parts and create a bunch of tickets with the type of information an ai will need to build that feature. The ai will create a pr and then the senior dev will leave comments on the pr for it to improve until the pr has been approved. Then the ai will pick up the next ticket. So that will be your version control. It's bee decided by the senior dev.

Thanks for this engagement. I am encouraged. I am at this point that I stopped learning everything because is not working for me. I am just trying to make out something from things I have been learning. Thank you so much ❤

Software engineers aren in big demand but employers are very greedy so there will be always big disconnect between university teaching and industry needs. Also many countries have not very innovative industry where IT is just seen as unnecessary costs, so there is not much jobs for highly skilled engineers.

I'm happy I came to learn something new and realize I was already doing most of it (I was just missing the not judging the code of others part 🤣)

Let it crash!

Handling unhappy paths is a healthy practice to be in the habit of, since it is guaranteed that not everything is going to work 100% of the time. I believe that this mindset is a key aspect that separates quality-oriented engineers from others. In my experience, these conversations create the most meaningful conversations with stakeholders, and provide the most valuable insight into the system's intended design. So long as a boundary is tied to one explicit exception that the business code defines, you will avoid any interface rewrites that are mentioned in this video. If a unit of code cannot handle the failure, pass it along. At the end of the day, somebody must pay the piper; and if the code doesn't, you will.

Amazing we have the same way of reading code! Fantastic!

I wrote a simple lexer in go. Co-pilot tried to improve it by duplicating matches or getting the order wrong. Tried to cajole it to do it right but ended up doing it myself. Prob. cannot read regexes and it fails ordering it from most specific to general.

The "no judgement" ideology has been judged, and it's not good.

Git blame is excellently named. Tech producers should embrace blame and extreme ownership.

I love the way you explain.

Could not agree more. This is something I’ve settled on from two decades of software development. My team is very small but we pair code review. We work only on the trunk branch and jump on ad hoc pair programming calls multiple times a day to review a local commit or prior to pushing. It’s also worth noting finding issues earlier in the development process is less costly too. Many developers tend to want to work in silos but the best thing we can do is collaborate throughout the development process.

Dave, we need to change the way we think about Pull Requests, and their purpose in the Continuous Integration (CI) lifecycle. They are absolutely necessary, but not in the traditional way that they were initially conceived, as a mechanism for a human review process. I advocate for Pull Requests to be a part of the development workflow in order to automatically provide feedback to the developer without ever bothering another human being outside of that developer. Instead of mandating that a human review the Pull Request, and create all kinds of pain related to that, what I do is implement CI so that it runs a slightly modified CI pipeline that detects and knows that it's running on a branch that's associated with a Pull Request, and in the CI pipeline stages, it runs things like code quality scans, code security scans, dependency vulnerability scans, etc. and all of the feedback of these scans, that run in an automated way, are also automatically published to the Pull Request's page (the Pull Request UI), and so the "code review" is done by the pipeline itself, instead of a human, to provide highly valuable feedback to the developer to fix all of the issues found by these automated scanners, and in certain cases you can force a failure on the pipeline until the developer fixes these issues and/or do not allow the Pull Request to be merged if the pipeline is reporting critical issues with the scans. Remove the human review component from Pull Requests, take full advantage of the automation provided in CI, and Pull Requests now go from a painful "how do we do this to not piss everybody off" to a well oiled machine. Also, the concern that the special CI "pull request" pipeline is not real CI because the branch has not been merged, is also false, because the way the CI pipeline works for Pull Requests use-cases is that is runs the pipeline as if it was pseudo-merged with the target branch, so it not only tests that the source branch can be merged but it runs a true build as if it was merged (via the pseudo-merge capability), effectively giving you true CI. The Jenkins Multibranch Pipeline plugin especially excels at achieving these CI and Pull Request goals. See this for a high-level overview: ContinuousDeliveryFlow.com/

I really like this as a way to rewatch some of your content, Having a cohesive theme really makes it easy to keep watching.

Happy to see that I'm already flowing almost all of presented tips 😊

How do you avoid continuously working on surface features if each task or cycle done should be able to be used by customer/stakeholder? For example how would you plan the team's work if something needs a larger restructure? Or if end goal function requires a large database? Thank you!

How should single statements be read? In System.out.println("Hello, World!"); I speak System out println Hello World, but in a*b I speak a times b. Why is the dot-operator not spoken, but the times-operator is?

As a very senior engineer and architect this channel continues to have some of the worst takes and advice. Pair programming is an attempt by management to take 2 inferior devs and try to get them to perform well by shoving them together. Its absolutely terrible, frustrating , cost prohibitive and all around bad most of the time. The only time it is useful is for very specific, targeted tasks that tend to be complex or critical in some way. Or to train a brand new team member on the code base. But always for short periods and limited amounts of time.

is thre a link to the research study paper?

Notes are great! For me they help me separate code into domains even more than tests.

Gotta love Trish’s videos ❤❤❤

Most developers bristle at generalizations about all developers because every developer is a very special person, aren’t we? These navigation tips are GOLD, tho. Here’s another: alt-F7 - find usages. I had become so addicted to alt-F7 that, when I started in a new job 8 years ago where everyone uses eclipse, I immediately installed IDEA IntelliJ keymap plugin for eclipse.

A lot of wisdom there... Reminds me of a long-gone job where my lead thought they were sending me away with a few weeks' work, and I came back 3 hours later with "what if you change these 2 lines?" because I had read the code... O:-) Inheriting hundreds of thousands of lines of code in different languages over and over can lead to new skills or a padded cell.

FP has always been a European project driven by academia and public funding. The big American companies didn't want to support FP (F# never took off at MS) out of fear it would cut into their profits. And India, arguably the largest market for cheap dev workforce, falls closely behind US demand which relies on cheap, replaceable and boring (Golang) only a fraction has the requirements that justifies FP programming.

🧛‍♀

hey, guys. the first 5 minutes of the video were repetition about how not fun it is to read code, it could be more objective. all due respect and appreciation for the channel tough. thanks <3

This is why eDSLs are better than pretty much anything else. The most readable code is the code free from leaky abstractions, and you can do it only with language-oriented programming.

And yet, many people still think that code is meant to be read and interpreted by the machine. Newsflash: it's not.

While this isn't the content I come to channel for, the message is important. Ive seen a lot of complaints around that navigating code with abstractions is hard. Sometimes I think they must not be using an IDE.

Some helpful tips, but man, those method comments seem very wasteful in terms of screen space.

Well designed and written code doesn’t require much maintenance. Software developers are constantly thrust into the poorly designed and written code to fix bugs and add new features. Thus is our curse. We’re constantly exposed to bad code but rarely good code.

debugger OP

I've seen functions of thousand lines calling more functions of thousand lines each. There were tests checking nothing and printing everything to the console. That was not fun, no, I didn't like it.

I can't relate at all. Must be skill issues.

The thing is, if you love code, you like to read it too sometimes. This video is more like you asking for advice than giving it. It's also more about coming to terms with some kind of stress of reading code than the actual practice of reading code. I hope it gets better for you people one day, but I don't really feel this stress you're talking about, I also love asking questions, don't do TDD and sure as heck don't use intellij idea, so this is quite awkward for me to watch. Nope, don't like this.

I'd love to see people who actually program in both styles make a video about this

Have you heard of code reading clubs?

HOPEFULLY.

What a horrendous video cover choice. I thought better of your channel. Be better.

I don't hate reading code. It's often a fun bit of exploration to read old or unknown code and understand all the weird shit it does. Loading all of the software into the wetware and then being able to turn it around and look at it in my minds eye is one of the best parts of software development.

The main win of FP is that now almost all modern and more used la giages has some FP concepts in them. For example is not new news that most of newest Java features implemented in java in the last 10 years has been "inspired" by functional programming languages such as ML, lisp and So on.

12:42