UnityCoin
6 HN recommenders · recommended in 7 months, 2020–2026
1:48:42 · 2.2M views · Aug 9, 2019
The first lesson of Uncle Bob (Robert C. Martin)'s "Coding Better World Together" series. It makes the case for clean code and for treating software craftsmanship as an ethical and professional responsibility. It runs about 109 minutes.
HN commenters call it better than the Clean Code book, a must-watch for engineers that changes how they read and write code.
8 comments from Hacker News
Maybe it's true at some companies, but it has nothing to do with agile / scrum, but letting non-tech people who love confrontation take over engineering leadership from engineers who are afraid of confrontation (which sounds like the disaster it is). Robert Martin (one of the creators of the agile manifesto) explains it quite well in ,,Clean Code'' presentation: this video The whole presentation should be a must watch by all engineers so that they understand what _is_ agile to the point when they know it better than product / project managers / non-tech people. It's hard to get a better description than the original source, and no non-tech person has authority to override the real agile at that point.
That's probably great as well, but I'm talking about searching for a book author. Just for example Clean Code is a great book, but the presentation is so much better: this video
Clean Code series by Bob Martin (Uncle Bob) Changed the way I read/write code and my perspective about programming in general. this video
If you're going to do this I recommend you at least take these things at heart: Why do developers slow down > this video 80% of developers are unhappy. The problem is not AI, nor is coding > [LINK] What you're looking at is starting greenfield development. This always starts in the same way: 'we need to deliver functionality quickly because management wants results'. This always leads to the same issue, where code quality is ignored for sake of delivering functionality, which then leads to development slowing down and both management and devs becoming unhappy. If you want to build something for the long term, I'd recommend starting slow. Get some experienced freelance devs where you do thorough reference checks. Get them to set up a stable core and help in hiring some medior level devs to train. The medior level devs can grow to become the coaches of junior devs and then you can start scaling down the freelance devs. Whatever you do, don't plan to release something within the first year. Don't ask the team to estimate a delivery date within the first six months. After six months you should have a baseline that development can be continued with and then you probably have a team that can start estimating work and has a grasp of what they need to do to deliver something useful. Also, get a good product person, someone who can talk to business, draw out the different parts of the application and explain them to the developers. All of these things are hard, so you really need to comm
> About 700 subpostmasters were prosecuted for fraud and theft and over a hundred sent to prison And at least four purportedly related to these prosecutions committed suicide[1]. Perhaps most alarmingly: prior to 1999, the burden of proof for proving that the Horizon system was working correctly would have fallen to the Post Office (as the prosecutor in these instances) and Fujitsu (as the developer). That rule was changed to presume that the computer system worked correctly unless there was explicit evidence to the contrary[2][3]. A very high barrier for a non-technical person to prove, especially in an extremely complex system. It worries me how many people put unchecked faith into the systems that, now more-or-less, rule our lives whether we like it or not. It worries me even more that a lot of computer programmers, systems engineers, et al, don't understand how their code affects others in bad and unintended ways, and why testing matters so much. Uncle Bob, as divisive as he is, hits this nail on the head with a depleted uranium sledgehammer[4] (19:47-24:33). [1] [LINK] [2] [LINK] [3] [LINK] [4] this video