Technical Leaders Should ENABLE Developers To Be Successful
Вставка
- Опубліковано 6 лип 2024
- Describing what technical leadership looks like and offering advice on how to support development teams in a way that can help developers be their most successful selves!
Gary Gruver talks to Dave about modern software engineering leadership and speaks on his past experiences operating in large-scale organisations.
You can listen to the FULL episode HERE ➡️ open.spotify.com/episode/6I5c...
-
🗣️ THE ENGINEERING ROOM PODCAST:
Apple - apple.co/43s2e0h
Spotify - spoti.fi/3VqZVIV
Amazon - amzn.to/43nkkRl
Audible - bit.ly/TERaudible
-
🙏The Engineering Room series is SPONSORED BY EQUAL EXPERTS
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
-
#softwareengineer #developer - Наука та технологія
Yes Dave!
Don't optimise for arbitrarily-defined dates and outputs; 'what's the point of that if we're delivering the wrong thing'?
Project deadlines are not a measure of value.
Keep on this message Dave as is important and empowering for devs to share with stakeholders.
It's hard for us to predict the future, but this deadline is a 'sure thing'.
As a lister to the podcast, it would be great if you could somewhat label this type of clip in the thumbnail because I have to open these videos to check what sort of content they are. And I have missed some of your non-podcast videos because I have been confused about what is a podcast and what isn’t (I did eventually go back and click all the videos on your channel to see if I missed anything, but not everyone will do that).
This is so important. If you want to improve the organization, the best way to do it is to go start making things better. Engineering is a great place to start.
I'd agree - but some industries deadlines don't move. One of them is automotive manufacturing, you have 1000's of companies committed to begin start-of-production on date X. There are penalties in contracts if you're not ready. You *can't* not launch because of software. That said, it's an increasing problem as the vehicle systems get more complex.
Maybe we need industries to adapt to the reality of software development - though that's never gonna happen
@@pacifico4999 Changing industry structure is a behemoth beyond technology.
@@petebrown6356 absolutely
That's easy: Promise only whatever is working reliably.
@@disgruntledtoons Companies exist for profit, and automotive is no exception. They would rather overpromise and work you overtime, than be more sensible about it, because the competition is just as ruthless.
Will be nice if the podcasts are available in all regions. Can't access this on Spotify at the moment.
It’s also available on most other audio platforms, not just Spotify, if that’s helpful?
I don’t disagree with the sentiment of the title, but I do think that software engineering, Agile, continuous deployment, continuous delivery, continuous integration, DevOps, etc. are probably great and work well only when software is the product.
But not when software is embodied in a products design and software development/engineering needs to integrate with mechanical, aerodynamic, structural, production, etc engineering and product design, marketing, sales, operational deployment/sales support, etc. Then you’re dealing with directors, senior managers & programme/project managers who are extremely focused on delivery milestones & deadlines. And software teams need to accept that other teams within a business take different approaches to delivering their work.
Deadlines are the enemy of code quality.
oooo a deming quote! 😆
Actually completing the deadline sooner can be wrong. It can happen in emerging markets. The market not being ready for you can be just as shitty as arriving late to the party.
I don’t think Dave really heard what Gary was saying. Gary made no mention whatsoever of deadlines. His focus was on empowered teams who are constantly moving toward the highest priority work. Dave somehow turned that into a monologue on deadlines and a headline for a YT video, but there was zero engagement with the guest on the effectiveness or lack of effectiveness of deadlines.
It seems that agile is removing and deflecting from any objective measure and changing computer science to sociology. Also, there are huge time sucks on teams, usually SCRUM ceremonies and coupled with no metrics on performance, we're left with smiley faces and stars depending on how we feel.
I wish you cared about your logo as much as you care about testing. In graphic design world, you are a WordPress developer who writes all code in functions.php.
😂
I think the low quality logo enhances his credibility. Would you trust an engineering manager with great graphic design skills?
@@EricLesch-km7oe I dunno. Would Dave give a graphic designer a break for not creating tests? The answer to that is the answer for both. One's profession is not more important than another. The logo fails accessibility (colour difficiencies, reading and contrast), it fails any signage or print rules, and fails legibility when scaled. That's at least as important as writing tests for a recipe blog. And all of his finger waving examples about tests could easily apply here -including the insinuation of laziness.
I don't think audience of this channel are generally bothered by graphic design of the logo as long as logo is not hideously ugly. Which is not. Nice burn tho, will steal and use it.
@@drbek It's not a burn. This channel is about living up to a standard that Dave has insisted on. There are plenty of hobbyist programmers or people who write code for fun - and Dave calls these people lazy if they don't do unit testing, so I'm calling a spade a spade. The larger point here is that Dave continually demonstrates dogma over practicality - and I can do the same. The logo is garbage, and if Dave's branding was held to the same standard as he holds over every line of code, he'd be at the bottom of the list. If he's comfortable putting video after video out about laziness of not doing unit testing, then I think your precious little heart can take 1 comment about his hideous logo.