Developer Productivity ISN'T About Measurement | Trisha Gee In The Engineering Room Ep. 26
ฝัง
- เผยแพร่เมื่อ 12 มิ.ย. 2024
- Trisha Gee joins Dave to talk about developer productivity. What are the keys to creating an environment for software engineers to feel positive and happy while being at their most productive? Can we really measure developer productivity? Let's find out!
___________________________________________
🙏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
___________________________________________
CHAPTERS:
[00:00] Introduction and Guest Announcement
[00:56] Trisha's Involvement with the Continuous Delivery Channel
[01:19] Discussing the Topic of Trisha's Upcoming Video
[02:07] Discussion on Testing and Developer Productivity
[05:48] The Role of Behavioral-Driven Development (BDD) in Testing
[10:15] Other Potential Topics for Trisha's Content on the Channel
[24:00] The Importance of Finding the Right Team and Work Environment
[39:26] The Future and Relevance of Java in Modern Development
[42:10] The Evolution and Benefits of the Java Virtual Machine (JVM)
[58:15] Final Thoughts and the Value of IDEs Over Text Editors
#softwareengineer #developerproductivity - วิทยาศาสตร์และเทคโนโลยี
![ถ้าพี่วุ้นท้อง แป้งจะท้องไปด้วยกัน !!!! [ดูคลิปเต็มหน้าช่อง] #Short | PANG ORNHIRA](http://i.ytimg.com/vi/FeyEnVMwitA/mqdefault.jpg)
@6:30 in this conversation you both made fantastic points about T/BDD --- it's NOT about testing , it's about specifying code behaviour and defining its precise requirements in the tests.
Trisha also made the superb point that, while actually developing, you ARE testing that the code does what you intended it to do ...... that could ultimately still be wrong but NOT by mistake 🙂
I normally don't comment but that was such a precise statement of the underlying concepts of B/TDD I had too.
Great video!
I joined LMAX shortly after Trisha and Dave left, and it really was a great place to work. When they mention fixing flakey tests around 18:00 it reminded me that Trisha's input and attention to test automation quality was so high impact that we had a test monitoring and alerting tool called auto-trish in memory of her vigilance. The name of the tool and the tool itself was my first introduction to Trisha's unrelenting commitment to making work better.
I'll worry about AI when my customer(s) can tell me *exactly* what they want a system to do and behave - down to the TINIEST of details. So *absolute* requirements, full coverage, well written & illustrated, etc.. Good luck, I don't think it'll ever happen. I've never had anything close. Outside that, AI is a tool - a very good one, learn how to use it.
Thank you , someone who finally gets it!! ... we can't even get past step 1... decent specs.
We have a word for specifying the behavoiur of a system exactly. That word is 'programming'.
@@marksmith286 Only in languages like Ada subset called SPARK you can try specify behavior of a system exactly
AI gives very experienced developers more ability to unambiguously explain things for junior developers to understand. That has got to be a good thing all around.
Excellent video! What you call froth, I call noise as in signal-to-noise ratio. Most of the differences between languages today is just sugar. I worked on both COBOL and Java internals in the 90's. X86 assembler. (I never wrote a single line of COBOL.) I saw the dawn of both JVMs and .dlls... 😮
Trisha is speed demon 😉 At first i thought i watch video x1.5 😄
Knowing everything doesn't really matter. What matters in this business is your ability to learn.
Lovely video; great content ❤
Watching them talk so animatedly is like watching two teenagers talking about their favorite game. 😂😂😂😂
I would really like more AI tools for boring migration in code:
- Migrate all the legacy Junit4 tests to Junit5
- Migrate Spring Boot 2 to 3
- Check any potential issue if I migrate from java 17 to Java 21. Do you want to change this class to use records?
- Replace all the Hibernate repositories from Hibernate to JDBC or viceversa
- Make the Kotlin migration a bit more intelligent . Or even ask "This class can be a data class. Do you like us to migrate it"
No need for AI there is already OpenRewrite which automates most of those things, regardless of the model or the trained data. It created an abstract syntax tree of the code and the code style and makes the explicit changes recipe by recipe and step by step
Trisha mentioned large tests that were revamped by bringing in the BDD style of "given, when and then" framework of testing. I am interested how exactly did that help to make the tests easier to understand? Is it something like factoring out repeated "given" setups, or is it just grouping the tests into the 3 phases that made them easier to understand? Because I can't see how that immediately makes tests easier to understand. I see tests using this pattern that are also hard to understand, because there is nothing saying why things need to be like they are set up in the given stage, usually because there a ton of things are mocked there without any clear link between them or meaning... I guess this is more a problem of not writing good tests, so sorry if I went on a rant for that... tests are just frustrating when they are not done right...
What I found is that with some integration tests, there's a temptation to add a bunch of similar-but-not-quite-the-same tests into a single test method. E.g. if you're testing an "insert" operation, you'll do the setup, the insert, the assertions, and then be tempted to add an "update" operation on the inserted values, and then assert that went ok. Even this would not be the end of the world if the setup, test, and assertions are clearly separated, but we also found (for example) people were doing assertions after setup to check the database was in the correct state. It made it really hard to understand what was really being tested. It didn't help that these tests were often called "test1" "test2" "test3". With clearer test names and a clear separation of setup, test and assertion, it's much easier to see what it is we're really trying to test
I don't think the question is "what language?"...that isn't the concern, yes, Java is a must due to legacy. It's everywhere. My bigger concern is the buzzword frameworks that come and go, we're building a legacy debt-of-maintenance, as many of these frameworks will be unknown to future developers. When a company needs a developer for a legacy system, they'll be asking for languages A/B/C and *experience* with frameworks M/N/O/P/Q/R/S/T.....blah blah. Good luck.
Hey Dave,
can you add the link to the talk about hibernate vs sql?
Thanks a lot
Super interesting. Looking forward to the new moderation
It is listed in Dave's "10 must watch software talks" (th-cam.com/video/QOFCHla3F0Q/w-d-xo.html).
At 10:45 what does McKinsey scale level productivity? Do they have a framework (or something like that)?
Oh, you missed a fun one! McKinsey seems to be a capital-A "Agile" consultancy - so yes, they'll happily sell you their framework. They published a blog article a while back asserting you CAN measure developer productivity, actually. There's a great response video here on the channel. Enjoy! 🍿 th-cam.com/video/yuUBZ1pByzM/w-d-xo.htmlsi=bZ0xS8JzkpxDiQSJ
I like the idea of being T shaped... I might have even managed it a couple of times over the years.
How long before AI is built into compilers so they optimise code using AI as they compile. Gradually we could offload coding tasks to the AI-enabled compilers so we do less. Like garbage collecting, etc., today.
Is any developer going to be able to survive ignoring AI for a few years???
Dave, are you losing sponsors? :)
31:05 - Uh oh... someone's going to be left behind! How could anyone consider AI "froth"? 🤨 It is an *absolute* game changer, and any developer who thinks that they'll finally get around to looking into AI in a couple of years ... *rubs his crystal ball* For starters, anyone creating paid tuition content for Web Frameworks that - unless they can partner with an AI Firm will absolutely go bust, with their services becoming redundant and replaced by what AI delivers today.
half the video is the guy choking on his of flem