Видео

I don’t think AI will replace Juniors devs at all, they are gonna adapt, but what is going to probably replace is devs without foundations like CS, again probably. Because probably the schools are probably going to adapt the programs to make the devs more prepared to interact with these LLMs. Probably they are going to have the foundations now to model what a GPT model will produce and, probably coding as typing will disappear but not what was mentioned here which is review code generated, provide inputs to the model, etc. IMHO.

Version control is a subject guaranteed to get the developer arguments flowing. The mistakes i have seen are backup files committed to VCS. Showing someone didn't really understand what VCS did. The other is using branches to avoid merging into a release branch. So dev creates a feature branch and then expects that feature branch to pass QA before it gets merged into the development branch. Whereas customers only care that the feature actually works in their release and the fact it worked on a development branch means nothing. I work with a lot of people that avoid TDD and TBD. Hence we have lots of integration challenges and also ground hog days with bugs that would have been caught by TDD.

I agree that putting an excel spreadsheet in version control is a good idea. I just wonder if using something like Git would be practical in sone scenarios due to the way that git stores changes - I.e, by making a complete copy of the file. I’ve worked in organizations that made daily changes to massive excel files with millions of rows of data. Storing these changes in git probably isn’t practical.

This is a succinct clarity of such a critical topic that we all too often take for granted.

So... How would you version control 2 separate software projects that are meant to work together but work on separate platforms, for example a server and a client?

Thank you, Dave, for pointing out the bug in the Excel spreadsheet! Our minister of finance here in Germany knowingly acted on the wrong suggestion and did big harm to countries like Greece, Italy and Spain. Many people died. He never apologized.

Autopilot has not replaced human aeroplane pilots, even though it could. Human passengers prefer human pilots, however, there is no technical reason why air freight cannot be completely automated. In practice what happens is many junior pilots notch up their flying hours flying cargo around the world before flying humans around the world. A win-win. A lower risk way of training the juniors. I guess some kind of a win-win will pan out in the software sector as well...

Git is a tragedy

I really think AI will excel in TDD *_if_* guided by a professional and experienced prompt engineer. lol

Hah! I've seen entire Oracle EBS systems with NO version control ever backing it. When asked how do they get the latest version, they just tell the DBAs to dump a copy of prod into dev/test LMAO

A VCS should be taught as early as possible.Git has the advantage, you can use it offline. You can use Git on your phone. You won't use your phone for a serious project, but for toy projects it's a good tool. If you use Git for toy projects, where you can experiment, a Git disaster in serious projects is less likely.

I use version control for basically everything these days. From writing letters, for my study notes and config files. To never worry about a mistake setting you back more than a few commits is a powerful thing indeed.

Betteridge's Law applies to thumbnails, right

- “Software Dev is all about coding!” Our job is solving problems, not writing code. I love our profession in part because I enjoy the mental focus that writing code gives to me, but I get much more pleasure from finding a neat solution to a problem - even sometimes if it involves no code at all. Some of the great software developers aren’t great because they know more about languages (although some of them do), they are great because they have more insight into the problems they are solving, and found simpler solutions to those problems. You don’t get to be a 10x programmer(whatever that means) because you type 10 times faster. You’re great when you solve problems with less code. - “If only the Business would get the requirement right!” This idea almost completely misunderstands the problem of software development. It assumes 2 things - first - it’s a developer’ job to write code, and someone else’s job to tell them what code to write. Why can’t the business simply tell us what the solution is clearly and concisely, and we can translate that solution into code! While it’s true many organizations try to make it work this way, this is simply wrong. If a developer's job was simply a translation exercise from a description that was detailed enough to be correct - then couldn’t we automate that translation? - and effectively turn the correct description into code itself - what then is the point of developers at all! The people writing the description would be the developers then. It’s much more difficult than that in reality. Organizing our thoughts so that they are executable by a computer is a difficult thing; but understanding what users want and what works for them - is also a difficult thing. The second incorrect assumption is that there is someone who knows the answers to this. No one really does. There’s a lot of data to back this up. Users don’t know what they want. If you ask most users what they want, their ideas are usually a small step from what they already have. It’s certainly useful to know what the users want but great products surprise users and go beyond their expectations. No one was asking for smartphones before we invented smartphones and revolutionized the mobile phone industry. No one was clamoring to buy books online or sell their sofa online before amazon and ebay started up. The companies themselves, even innovative ones - don’t know the answer either. Steve Jobs and Apple thought that the Newton and the Lisa were great ideas- they weren’t. Data from a study in Microsoft said that two-thirds of software product ideas created 0 or negative value for the company that creates them. So, when your boss says - We’ve got a great idea for a product - she’s guessing! We’re all guessing, so our job is to build systems in a world of uncertainty. This isn’t because someone is stupid or evil or doing a bad job - it’s simply the nature of the game. What this means is that we need to work in ways that protect us from bad guesses. We need to figure out how to incrementally evolve solutions to problems over time, to grow them step by step - and so give ourselves freedom to make mistakes. - “Speed is all that matters!” Software Development is an intellectual creative discipline. Our real goal in software development is learning - that’s the expensive part; not the translation of that learning into code. Once the problem is clear, coding is easy. If coding is hard, that is nearly always because you don’t understand enough about the problem. Making the problem clear is the hard part. TDD is one of the best ways to learn what works - quickly. Optimize for learning, not feature production. - “My job is to code, not to understand the problem domain!” The best programmers know the problem domain well enough to have domain insights that sometimes even experts might miss. We won’t have the same kind of domain expertise as a true domain expert and knowledge will be a little more surface, but if we are doing well - we will spot similarities and opportunities that domain experts miss - because they are too close to the problem. So, pay attention when people are talking about the problem domain. Work to establish a common language that you can share with domain experts to explore and explain problems. Ask them for clarifications if you don’t understand some concept. Try and see the real problem in the real world if you can. This will have a deep impact on the quality of code that you write, on its simplicity, readability and your ability to grow it as your system and understanding grow. - “I can’t ask for help! It shows I don’t know enough.” Truth is - the more you know - the more you know that you don’t know enough. Smart people ask questions, dumb people think that they have all the answers. To be a great software developer, you must become comfortable with uncertainty - because there isn’t much certainty to go around - to be honest. Ask questions, if a dumb person thinks you’re dumb for asking questions - that’s their problem, not yours. The point at which this is not true is - if you ask the same question over and over again. Trick Suggestion: Allow yourself the freedom to ask a question twice; if you want to ask a third time - take the person with answers aside - fess up that you don’t understand and ask them for some help. 9 times out of 10, they will help you and think better of you for doing this. - “Software Architecture is for the experts!” Designing a good software architecture takes experience. I think you need to have seen similar things done in 3 different ways - ideally in 3 different technologies - before you really have that kind of experience. But a software architecture is more than just only creating it. A good software architecture is a bit like a tourist map of a system. It shows you enough to find your way around, without going into too much detail that you can’t find where you really are. Any developer should be able to describe how the system that they work on works - ideally to a non-technical person, but at least to a technical person who doesn’t know anything about your system. What are the organizing principles in your system that really matter? What ideas help you to decide where to place behavior in your system? What’s the tourist map for your system? - “Testing is someone else’s job!” If you write code, how do you know if it works? Even if you write code without automated tests, you run your code to see if it works. If not, you’re dangerous and you need to take a step away from the keyboard. So now, our only debate is whether our testing should be automated or manual. Of course it’s automating testing - there are gains from using TDD/BDD. Who should write the tests? Mostly, it’s us - developers. We’re the people that write code that can break the tests. We’re the people that need to fix the code if it goes wrong, so we’re the people that should see that mistake first; and be best placed to understand it and correct it - for that we need to at least own the responsibility for the tests that are running and most of the time we’re in the best place to write them ourselves too. Our job is to solve problems, not to write code. How can we tell the problem is solved without checking to see if it is. - “I would like to do a better job, but my boss won’t let me!” This is a big but common mistake. It can be a cultural problem in poor organizations and fixing it can feel uncomfortable. To fix it relies on some self-confidence that may be hard to find at the start of your career. But, at some point we must take responsibility for our own work. If you hire me as chef, you’re making a big mistake, but if you make that mistake - you wouldn’t expect to tell me to clean up as I worked - you’d assume that I keep my work area clean and my tools sharp as part of my everyday work. You wouldn’t ask me - how long to cook a good meal - and expect me to answer - “I can do it in 20 mins and as long as you don’t expect to use the kitchen again.” But in software, we do sometimes provide those kinds of answers. If you’ve ever given an estimate that didn’t include refactoring or testing - you did this. If you ever skipped these things to hit a deadline - you did this. There’s a professional duty of care that we’re all responsible for. We are the experts at our profession. I don’t think we should be asking other people permission to do a decent job. Inevitably, you will be working in an existing team with existing norms of behavior. As a junior member, you may not be in a position to exert authority and demand that other people change. My advice then is to do what you can. Try the soup(?) exercise, that Aino Corry mentioned in an earlier video. Identify the stuff that is within your control and change those things for the better. Identify the things that you can influence, and you may be surprised at the influence that an enthusiastic newcomer can exert on a team. As long as you try to change things by demonstrating better ways of working and encouraging people rather than demanding action from others, it’s better to ask for forgiveness than it is to ask for permission. Finally, recognize that some of this stuff is beyond your control and influence - and so focus on the stuff that is and do a good job of that.

I think I'm the only one left using MS Team Foundation Server. I haven't left it for (free, co-pilot enabled) get b/c porting over all the history seems like a scary proposition.

I have been playing with and enjoying using ChatGPT to do small projects. You can do incremental work by giving it something and asking for a change. However, the process is both tedious and error-prone as you sit copying and pasting in both directions. The next big jump for this process will be when the AI assistant can be pointed at a specific Git archive and branch and asked to generate specific changes that it can then make available via a pull request. This would allow the AI to look at the overall project and generate solutions that follow the same coding styles etc. and where possible use local libraries already in use in the project. Until then AI assistants are a lot of fun and for small couple hundred line Python scripts (for example) turn a one or two-day project into a few hours. Especially when you are venturing into new areas and are not familiar with the (many, many libraries) that might help solve your problem. But as currently being used it does not appear to scale well or easily into even medium-sized projects with tens of thousands of LOC spread across hundreds of files.

The only thing with this approach that is still an issue for me is that I don't see a clear way to define a *range* of versions of component A that component B depends on. Only the single currently latest version in the repo. But it is not a big issue as modern orchestrators demand a single version of each component anyway.

What's next for version control? I hope for a way to better record the semantics of changes. In an ideal world you never have to rename things, move them around or change signatures when you're in the middle of a task that's only tangentially related. In an ideally world, refactorings like these go into their own commit with its nice and helpful message. My world isn't always ideal and so I keep hoping that one day VCS will be able to recognize this kind of mechanical changes.

I've been using AI for a few weeks now. It's something that works pretty well if you are disciplined. By that I mean give it a set of interfaces and ask it to create some tests. Tests are an odd sort of code where you want code duplication and let's be honest we all copy and paste a previous test as a template, which means there are invariably bugs. So letting the AI write them makes sense. I don't understand people who ask what comes next after GIT. I want to shout back we work out how to use it best!

I'm not sure about git successor but I've used a lot of different version control systems and git absolutely could be improved on. It does a lot of things right. Probably the big one that git and other DVCS do is allow for easy branching and merging. A lot of prior systems didn't handle this well at all. Even SVN didn't have merge tracking for a long time. But there is a ton we lose with git too. The command-line commands are pretty random and arbitrary. It feels like a random pile of shell scripts (which is partially correct). There is no way to manage which branch should integrate into which. No permissions. No file locking (yeah lfs is a hack). No bug tracking integrations build in. You have to git stash way too much to do basic things. Because a branch is a pointer, commits don't track what branch they were done on. Deleting a branch can delete history. So yes, git is an improvement from many other systems but it is also a step back. First we should get back what we lost and then we can talk about the future.

One thing I've noticed throughout my career is a lot of teams are way too quick to throw away version control history. It seems nearly every company I work for, I end up having to argue against a plan that includes throwing away version history. This happens when switching version control systems (including ones that have an importer), or restructuring repos. I've done quite a bit of version control sleuthing on bug fixes where version history I am looking for is years or even decades old. Often times version control history is the only documentation that exists for knowing why some complex logic exists and if it is still needed or what it should do.

AI can be prompted the last iteration of the code to incrementally build on it and GPT-4o even tries to run the code it proposes, inspects the results and reiterates on them to improve the output. Atleast charGPTs level of managing this is at junior dev level, which is sufficient for an experienced developer to use as a tool. Whoever argued for a git successor does not understand Software. There is only one thing that git does horribly and that’s handling binary artifacts, but we don’t need that, we can just add a file that points to them and a script that downloads them after checking out or updating the repository.

Oh, and…. I’m a huge fan…. Lol

It’s ‘lose’ not ‘loose’. Sorry to be a d!ck but it drives me insane how often I see this.

Foundation models will fail for the reasons you say it will, but you aren’t imagining what’s directly around the corner in terms of AI application.😊

I don’t understand how you can be so smart, and not understand that you are attacking a straw man AI thesis Single shot AI isn’t what you should be arguing against! Think about a tree of experts application that is primed with multi shot, each one operating RAG style within their scope of expertise. …. Your argument doesn’t hold water to this!!!!

Excellent video. Mirrors my thinking on this, but articulated much better 😄

Focus on output isn't a bad thing, even if your aim is outcomes that will still be delivered through output. There is no metric for value.. sure. But if you have no output you will not achieve any outcomes.

I agree with not adding unnecessary complexity upfront, but it is true that the job market will be looking for people that understand the tools, so engineers need to learn some of them anyway

Standards for juniors have increased. It's harder to coast now

Good video.

Good to see that Dave, like me, is also subject to being a bit curmudgeonly at times, and a great reminder from Kelsey that not all complexity is accidental or unnecessary. Tools like k8s solve very real problems, and for many organisations the learning curve is well worthwhile to help support requirements that are now considered basic table stakes in modern software.

These are very good points. But whatever points are made for or against AI coding, it has already been proven that there is no algorithm that can write aribtrary programs. And an AI *is* an algorithm. A complex one, that we do not really understand, but an algorithm nevertheless.

Mr. Hightower's point about vim vs. emacs and tabs vs. spaces is a valid one. It's also broadly applicable, whether it be about software engineering, politics, or sports teams.

no

Kelsey is such a good teacher and demo-er. Always time to learn from him even when I don’t need high level of k8

Isn’t this like a year or something old?

Thank you for share!

the answer to the question in the title is no. large language models use statistical methods to basically do auto complete suggestions. they are also prone to quality poisoning due to untagged data containing arbitrarily bad samples. to select which which refactoring to do from the list of available refactorings for the entire codebase, you need a model of the codebase, which by definition, the llms don't have. it could be done with a good enough expert system, but that is a completely different type of ai.

Sorry for the off topic... Dave, I have the same T-Shirt 😁 Great episode and with great content as always. Thanks for all your work. Love this channel and have shared it with my team as place to go to and learn.

To the question: Is Kubernetes suitable for developers to build anything and everything? Why do software developers have the tendency to be all or nothing over their tools and practices? NO! Kubernetes is a new highly automated infrastructure layer automating and managing container runtime. To build Kubernetes onprem is a quite high invest to do at scale and manage lifecycle. It is a CaaS Layer on top of Infra/IaaS. Developers should care about to implement their business / user requirements coding using TDD to ensure integrity and correctness of their applications. Kubernetes, when using it, needs additional layers (with even additional complexity) on top, to satisfy developers. The k8 API has not a good contract between platform and developers because a developer needs to care about too many things infra related. Kubernetes is an option for many workloads and there are also good reasons to run workloads on top of k8.

While i agree with the sentiment of this video, saying that AI only provides answers is not true. 'pretend you are a junior developer here is some seniors code. Ask some interesting questions as to why it was approached in this way.' [Some code that sends an email] Certainly! Here are some interesting questions that a junior developer might ask about this code: Why is the mail() function used directly here? Is this the best practice for sending emails in PHP, or are there better alternatives such as using a library like PHPMailer or SwiftMailer for more robust email handling and error management? What are the potential issues with hardcoding the email recipient and sender information directly in the script? Would it be better to store these details in a configuration file or environment variables for easier maintenance and security? .... There were over 10 questions, i could of asked for many more.

More and more people might face a tough time in retirement. Low-paying jobs, inflation, and high rents make it hard to save. Now, middle-class Americans find it tough to own a home too, leaving them without a place to retire.

so... wrap it up then you can mock it?

Kelsey seems to think that K8s is a good solution for workload mobility and that its added complexity is paid for by the additional uptime it affords. This is false on its face. This is a "last mile" cost issue, where getting to "full workload flexibility" is the holy grail that companies are all pursuing. Unfortunately the complexity that k8s adds costs in outages, cluster upgrades, integration and compatibility woes. K8s is an extensible API on top of etcd. It's not produced by a single development group or corporate overlord - but is comprised of a vast array of "products" that are "compatible" with its API. It smells like the sequel to OpenStack - everybody and their brother's cousin's uncle claiming their own niche in the "ecosystem" - selling/marketing solutions that are poorly tested and poorly integrated across that ecosystem. And now Devops groups get to pay to beta test, integrate, and unkink entire K8s infrastructures that are each unique amalgams of the hotness of the moment at the time they went to production. Think about how long it took the USB standard to have a stable implementation, where the stable versions of the dominant OSes didn't exhibit "weirdness" with its long touted "plug-n-play". Consider how warily new filesystems are adopted. Think about how eagerly RAID5 gets adopted to squeeze "value" out of storage cost, only to discover that it's inherently brittle when compared to RAID1 or 10. Does running your datastore or datacenter on the technology equivalent of "cups & ball" carnival trick really make sense?

Kubernetes is complex if the only abstraction you're dealing with is raw YAML manifests... or if you skip that step to go full Kustomize and GitOps. There is a sweet spot in between.

"The open, accessible web should be built upon endless build systems, virtual environments, full test coverage and endless gatekeepers." - Sir Tim Berners Lee

I like that almost everything I do is HPC type stuff. We just use something like PBS to submit jobs and have them run.

I think that introducing additional abstraction/complexity is worthwhile only when its (abstraction) complexity is less than the complexity of the problem it solves.

Coming from a SysAdmin background and dealing with software developers that then think of themselves as equally competent SysAdmins because of things like k8s; it's very easy to see the reasons why simple things become overly complex and costly because the wrong tool and skillset are trying to be forced to work to fix a problem. All of the additional requirements that Kelsey starts laying out can be still be easily solved, even without k8s. Wisdom is knowing when to grow into a tool organically and not hinder or force yourself from/into making that transition. Lastly, always incorporate having a means of getting metrics and performance data no matter what solution is created or used; so that when management and customers start yammering on about needing to scale up to be the next Amazon but they're just a bicycle repair shop in a small town, you'll have quantitative data to give them as to why their "needs" of "twenty-seven 9s of uptime" and "geolocated on 6 continents" is ridiculous.