Talk in English - US at Longhorn PHP Conference 2023
Track Name:
Ballroom A
View Slides: https://docs.google.com/presentation/d/1EYbx1eoCghowPYmyNRBHbwbFW2r7XBFjB6IBvlDIxXM/edit?usp=sharing
Short URL: https://joind.in/talk/2c879
(QR-Code (opens in new window))
Have you ever started on an engineering task with the thought, "Oh, this will be easy - I know exactly what to do,"; ... and then, several days and as many rewrites later, realized maybe not? Have you ever worked with an engineer that submitted incomplete work, letting code review and QA do most of the heavy lifting? Ever been that engineer yourself? There is a better way! Learn the systematic steps to follow within a Unit of Work to level up your engineering from see-what-sticks to a deterministic approach that results in beautifully crafted and robust code.
Comments
Comments are closed.
A lot of great advice.
I really like this concept. The analogy to bridge-building was excellent. Also loved the signing as a gesture to diversity and accessibility. The slides are much too wordy, however. As a result, the text was too small to read in the back of the room (it was an unusually long narrow room) and it's quite hard to listen and try to read all the words at the same time. These seem more like slides meant as reference rather than presentation. Maybe consider removing some wording in order to focus the audience on the thing you're talking about at the time, or at least breaking up the slides and using larger fonts. Also, maybe consider using a table to do the comparisons between writing code and building a bridge instead of bullet points so the audience can more easily understand the analogy. (one thing tables are great for is comparison)
The idea of working waterfall at the micro level (microfalls?) is definitely something I’ll be taking forward.
This is a realistic breakdown of how projects actually go. The blueprint breakdown before coding is an inspired task todo. It really clears up all the mental work developers do and makes it clear to management how much effort a "simple" task takes.
"Agile in the big, waterfall in the small" is an interesting concept, and I really like the potential it has. Need to think through how or if I can convince my team to give it a try.
I really appreciated seeing how another developer breaks down a task into smaller pieces and organizes their thoughts. I love the idea of leaving behind the blueprint for a task in the ticket.