The STUPID MYTH Of Genius Software Developers
HTML-код
- Опубликовано: 20 июн 2023
- It is a common complaint that “we’d practice CD, DevOps, TDD, BDD, do a better job of design and build better software faster, but our team isn’t good enough” but the data says this is wrong. This goes beyond how to spot bad software teams and is more in the realm of myths about software engineering. Sure you need to be smart to build great software, but it is also true that a bad process will limit the effectiveness of the best people every time. Netflix CTO Adrian Cockroft used to be asked "Where do you get your wonderful developers?" and used to answer “We got them from you, and then got out of their way”. How we work is a stronger predictor of success than who is on the team - a finding that debunks software myths, and was repeated recently by Google research into over 180 of their teams.
So if culture and team approach is more important than teams of geniuses, how do we change culture and team approach? In this episode, Dave Farley explores this idea and talks about the specific techniques that make the change in culture that can make a difference in results possible.
-
⭐ PATREON:
Join the Continuous Delivery community and access extra perks & content!
JOIN HERE for as little as £2 ➡️ bit.ly/ContinuousDeliveryPatreon
-
👕 T-SHIRTS:
A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!
🔗 Check out their collection HERE: bit.ly/3vTkWy3
🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery
-
🔗 LINKS:
“How to Build the Perfect Team” ➡️ www.nytimes.com/2016/02/28/ma...
“NUMMI History” ➡️ en.wikipedia.org/wiki/NUMMI
“Lessons from NUMMI” ➡️ / worst-to-best-lessons-...
“DevOps Culture”, John Willis ➡️ itrevolution.com/articles/dev...
-
BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is available as paperback, or kindle here ➡️ amzn.to/3DwdwT3
and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
📖 "Continuous Delivery Pipelines" by Dave Farley
Paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
-
CHANNEL SPONSORS:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
Sleuth is the #1 most accurate and actionable DORA metrics tracker for improving engineering efficiency. Sleuth models your entire development cycle by integrating with the tools you already invest in. You get a full and accurate view of your deployments, see where true bottlenecks lie, and keep your team’s unique processes and workflows. With accurate data, Sleuth surfaces insights that your engineers can act on to improve - with real impact. ➡️ www.sleuth.io/
IcePanel is a collaborative diagramming tool to align software engineering and product teams on technical decisions across the business. Create an interactive map of your software systems and give your teams full context about how things work now and in the future. ➡️ u.icepanel.io/1f7b2db3
Tricentis is an AI-powered platform helping you to deliver digital innovation faster and with less risk by providing a fundamentally better approach to test automation. Discover the power of continuous testing with Tricentis. ➡️ bit.ly/TricentisCD
TransFICC provides low-latency connectivity, automated trading workflows and e-trading systems for Fixed Income and Derivatives. TransFICC resolves the issue of market fragmentation by providing banks and asset managers with a unified low-latency, robust and scalable API, which provides connectivity to multiple trading venues while supporting numerous complex workflows across asset classes such as Rates and Credit Bonds, Repos, Mortgage-Backed Securities and Interest Rate Swaps ➡️ transficc.com 
Наука
You can get Dave Farley's FREE Guide "How to Organise SW Teams" here ➡www.subscribepage.com/organise-teams-guide
When could we see some good open source example of the whole CI/CD process with some good git history? That would be a good series to explain by example, not by just words and concepts. Don't get me wrong - I did enjoy your books but they are not as tangible as I would like to see.
"I'm not a great programmer. I'm just a good programmer with great habits." - Kent Beck
I need some of this Kent Beck in my attitude.
Start off by writing the test
In my extensive experience as a software developer, I've experienced the issues presented here first hand. Continuous delivery using agile methods can result in lower performance due to excessive management interference. It's really tempting, by those in management, to pervert agile methods into simple micromanagement. I believe that these managers who do this actually believe they are doing agile. They are excited about using agile. They actually believe they are managing in an agile way. But, in reality, they are lying to themselves. They are fulfilling their dream of having direct control over the project. To properly do agile, people in the management role have to be brave enough to let go of the reins and let the team essentially self-manage. For a manager, it's scary and it kind of cuts them out of the process. Very rarely have I experienced agile done correctly. That's a sad state of affairs.
i agree, ive been programming for ~25 yrs, multiple languages, networking engineering, i have worked with 1 company that did scrum correctly, everything else was idealism, it is such an immature thinking pattern, im looking out for long running stable production code, which is essentially different from what we have today, ship as fast as possible well address design bugs later. praise glory to the white paper.
Looking at senior level positions on LinkedIn, many companies believe there is an endless supply of unicorns.
I hate that some times i did improvements by myself for a better performance or programming environment, there were unnecessary discussions and cut offs, there was always some kind of "shut down" or silencing.
I agree that the idea of the "genius" developer is effectively a myth. However the notion of the 10x or 100x developer is not. This is the person who brings a process and way of working that uplevels everyone else in their orbit. In doing so they ensure that effort is invested in the highest leverage tasks with minimal waste.
Thank you so much for the videos Dave. You have a big influence in the concepts and habits that I learned and still learn.
About the video I liked about the concept of changing habits in order to change thinking, this also apply to our lives, the habits that we have shapes our thinking.
That also remindes me about the Kent Back phrase “I'm not a great programmer; I'm just a good programmer with great habits”.
Thanks for the presentation. This channel is one of the pearls of Tech RUclips. I particularly connect with the point regarding changing our thinking and behavior. Open-mindedness to change and newer ways of doing things is a great attitude for any team that wants to advance.
Understand the benefits of different pair partnerships, learn how to introduce pairing as an option for your team, and identify anti-patterns and how to avoid them. Get these tips FOR FREE direct to your inbox here ➡ www.subscribepage.com/cd-pair-guide
Way too many companies pay junior dev salaries while expecting senior level performance... some others may not openly EXPECT it, but they NEED it to fulfil the goals they set out. And then everything inevitably goes to sht because the problems just keep piling up.
It's amazing to me how closely software development and manufacturing managment are related. I think it's mostly because both diciplines are working toward the same goal...good products. The way to that good product is correctly managing the resources available whether that is people sitting at a computer or people operating machinery.
There's a great episode of the This American Life podcast about Nummi. It would be good to have a bit more acknowledgement in these videos though that a lot of us will already know about things like Nummi - a lot of us have read Accelerate.
I regard process steps as trail markers. Having the *will* to take that attitude on seems very difficult for some people. The gatekeeping mindset is so unfortunate. (And I say that as a security person!)
14:55 Our organization tried adding gatekeeping, and this truly impacted throughput and confidence. It also tends to foster a toxic environment
Gate keeping? Would you like to elaborate?
It all about having a culture of trust, respect, and honesty. That is my life experience. Success is a product of cooperation through practice.
Before even watching the video: This must be a response to a lot of people in the comment section of the last video. Many of them said they wouldn‘t trust their bad junior developers ending up pushing bad code to production all the time, therefore pull requests. I can‘t wait to watch this video :-)
the market is awful. lot's of senior roles open, but only a very few developers have senior capabilities and correct skills and responsabilities
Great shirt!
I think there are different phases of any software project. In prototyping, you start with an empty folder and have to build up into some MVP - anything that works for some value of works. The next phase is building the real thing, ideally through continual maintenance and revision. Then it tends to go into some kind of long-term maintenance. IMHO, the only way to maintain the code long-term is to continuously rewrite it. As soon as you stop editing, even if only to improve the documentation or formatting or variable naming, it begins to rot.
I thought prototyping died 30 years ago.
@@BryonLape every new project I've ever been on started with zero lines of code.
IBM focused on LEAN, and then missed the public cloud bus to Amazon.
Could you elaborate
@@skyhappy IBM is a small player in the public cloud market. They bought SoftLayer to compete and never caught up.
We do CI and most of our team is new devs with almost no prior experience and is working wonders.
Could you explain how it is working?
@@skyhappy We do a lot of pair programming for onboarding, several months of it and even after the new hire is fully integrated with the team pair programming continues to be a rather common occurrence.
Well, where is the genius statement coming from? In my experience I have heard it repeatedly and it came from organizations hiring testers that are not even able to edit a JSON. The criteria is if you are able to edit a JSON in vscode, then you are a genius. And those organisations will consider you too expensive to be hired as a tester.
Some of us may be geniuses, but we're all idiots too.
Gotta work around the ability to be wrong...
Good points here, but the title is pretty misleading. This is really about gatekeeping and how management sometimes prevents improvement.
Is it possible to use benefits of CI/CD for ETL processes, and Data Warehousing?
Yes with some adaption. The fundamental principles are all correct, and there are lots of data orgs that operate good deployment pipelines. I don't have a video directly on that topic, butt you could try these: "CD for Data" ruclips.net/video/JPfbjKl9jbw/видео.html and "Engineering for Data" ruclips.net/video/jeMQld-6BtQ/видео.html
Tom is a genius.
I use a simple approach having only one reasonably good developer and around 5 developers very average and even below. It is a very stable and highly performing team. Talented developers are bad because they compete with each other and do not deliver.
this was a great video, bad management and bureaucracy kill software development
I think the myth of "genius software devs" is more aligned to those devs who put the work in to learn more, vs those who "rest on their laurels"
A developer who is passionate about their craft will spend time outside of work enriching their knowledge.
That makes them better developers - clearly it does.
I totally get the CD side of things - that has a HUGE amount of merit, when practised correctly.
However, a team is only as good as the individuals within it.
The way I see it, we absolutely have individuals who have an incredible ability - a genius level - but they are few and far between.
What makes up the real performance is the passion, the desire, the striving to improve - and CD doesn't touch on _that_ particular ability.
If you have a bunch of average developers - those who are only "on the day job" and never learn anything new, it doesn't matter WHAT they do with CD and best practices, a team of passionate developers will kick their asses every day of the week, regardless of whether they practice CD or not.
I know this, I've seen it, I've experienced it - not everything is about Continuous Delivery.
Lifelong learning… 😊
In what ways are passionate developers better over their counterparts?
@@skyhappy They are not. Passion leads to a negative attitude towards people who criticize their work, let alone find a bug. Passion is for people batting their wife to death with a golf trophy. Professionals have standards. Be polite, be efficient, have a plan to fix every bug you find.
I adopted the habit to thank my testers for every bug they find. I want them to be happy and actually look for them. On my part I try to keep the "thank you" opportunities to a minimum. After all they are meant to be a treat not a staple.
Depends on the job, really. 90% of this is maintenance, stupid bau work nobody has balls to automate or drop and CRUDs. And then you have 5% of software that requires to dig into subject matter that is beyond reach of most population before first line of code is written.
Oh boys. I've been working with valve and Google engineer and I saw terrible pieces of softwares
Could you elaborate
@@skyhappy pieces of softwares that are filled with bugs, untested etc.
Myth of genius? We're already nerds with no social life! Leave us something!
Software development is not a manufacturing process.
Taylorism has no place in the modern software industry.
Indeed!
If all the developers at Google, etc are geniuses then I'm a monkeys uncle
I think that the claim that some things only work with geniuses is just an excuse for keeping bad habbits. It´s frequently easy to predict the quality of software by looking at the habits of the developers - often before the first line of code is written.