MUGOYA DIHFAHSIH

Last week, Dan Abramov posted a very personal and humbling blog post entitled  Goodbye, Clean Code . I saw a tweet about this in my timeline and, being a long-term proponent of “clean” code, TDD and things of that ilk, I was naturally concerned. Here’s what I replied with. Daniel Irvine @d_ir @dan_abramov  You’re conflating two separate things. One is the desire to write clear, well-structured code. Another is your belief that your code is more valuable than that of your colleagues. I fear you’re missing the more important lesson. Human code > clean code > clever code > dirty code 15:00 PM - 12 Jan 2020    1   25 I dislike Twitter because it’s so hard to find any nuance to arguments. So in this post I’ll explain what I mean by  human code . It’s easier to blame code than it is ourselves I think it’s wonderful that Dan is blogging about deeply personal experiences in his career. Many programmers who become team leads will have had a similar experien

Software development is undergoing fundamental changes that are completely changing the face of the application attack surface. Modern software teams are moving faster and their development patterns are shifting dramatically. Developers favor assembling together microservices and open source software components into smaller applications. Those are then bound together with more API integrations and abstraction layers than ever. This is contributing to new kinds of vulnerabilities, as well as recombined — and sometimes more toxic — versions of the same old types of vulnerabilities that application security teams have been dealing with for years. Security experts and development professionals generally agree that the only way that the industry will solve the appsec problem is through more effective security training of developers. The trouble is that even before the advent of the modern DevOps and continuous integration/continuous delivery (CI/CD) movements, dev training has been