Upgrade to Pro — share decks privately, control downloads, hide ads and more …

You Don't Need More Developers

You Don't Need More Developers

Every company is struggling to hire developers. There are simply not enough to fill all the available positions. But are we looking at it from the wrong angle? Are we solving the correct problem? In this keynote, I will show you how you can significantly reduce the need to hire new developers. Through training and mentoring, you can get much more done at a fraction of the cost and without the hassle.

Anna Filina

August 21, 2021
Tweet

More Decks by Anna Filina

Other Decks in Programming

Transcript

  1. You Don't Need
    More Developers
    PHP COMMUNITY SUMMIT | AUG 21, 2021 @afilina

    View full-size slide

  2. "We need to hire more developers,
    but we can't find any!"
    You generally don't need more devs. Let's find the
    underlying problem to the shortage and solve it.

    View full-size slide

  3. Anna Filina
    • Coding since 1997
    • PHP since 2003
    • Legacy archaeology
    • Test automation
    • Public speaking
    • Mentorship
    • YouTube videos

    View full-size slide

  4. Dig For the
    Root Cause

    View full-size slide

  5. Why do we need
    more developers?
    We struggle to keep
    up with all the work.
    Why?
    Because things take
    a long time to do.
    Why?
    Umm…
    Ask "why" like a kid until you get the root causes.

    View full-size slide

  6. Because we have a heavy
    development process
    Because we need to wait for the
    testers to catch up
    Because most tasks can't be
    delegated to the junior devs
    Because this code is hard to
    debug.

    View full-size slide

  7. Code is Hard
    to Debug
    You can spend the majority of your time debugging. It
    usually takes more time to debug the code than to write it.

    View full-size slide

  8. "Every hour spent
    on defect prevention
    will reduce repair time
    by 3-10 hours."
    - Jones, Capers.
    Assessment and control of software risks.

    View full-size slide

  9. 5 x 3 = 15
    15 – 5 = 10
    1 hour each day x 3 hours saved on
    debugging – initial investment

    View full-size slide

  10. 5 x 3 = 15
    15 – 5 = 10
    5 x 10 = 50
    50 – 5 = 45
    Same, but with 10 hours saved per invested hour.
    Equivalent of doubling the team size.

    View full-size slide

  11. Clean code has fewer defects.

    View full-size slide

  12. This is great!
    I don't know what clean
    code is.

    View full-size slide

  13. • Easy to reason about
    • Testable and tested
    • Easy to modify
    If you need to modify 10 classes to add a tiny feature,
    then you're potentially introducing more defects.

    View full-size slide

  14. Writing clean code
    doesn't take longer.
    It appears longer because it takes
    time to learn clean code.

    View full-size slide

  15. That looks interesting.
    Where can I learn this?

    View full-size slide

  16. Pair programming.

    View full-size slide

  17. Order devs by skill level.
    Knowledge gap can be intimidating.

    View full-size slide

  18. One shares their screen and both
    work on the same problem.

    View full-size slide

  19. Most of our time
    is spent thinking, not typing.

    View full-size slide

  20. Better code means fewer defects.
    Learning better code compounds over time.

    View full-size slide

  21. Knowledge travels between team members. Add new knowledge
    with conferences, pair programming with outside dev, etc.

    View full-size slide

  22. But all of this is
    expensive!
    Not really. Let's calculate

    View full-size slide

  23. Average PHP dev salary:
    R$7.400 / month
    According to Glassdoor.

    View full-size slide

  24. PHP Community Summit:
    R$100
    You can afford to send every single
    developer every year, and then some.

    View full-size slide

  25. Time saved affords books and even
    time to read them at work.

    View full-size slide

  26. Wait for Testers
    to Catch Up
    Wait for Testers to
    Catch Up

    View full-size slide

  27. A fully automated test suite gives the confidence
    to ship straight to production

    View full-size slide

  28. Typical non-automated QA process:
    I wait 3 months for tester to get to my code.

    View full-size slide

  29. Bug found in code I wrote 3 months ago.

    View full-size slide

  30. I now need to switch context.

    View full-size slide

  31. I don't remember what that feature was all
    about, since I did so many things in that time.

    View full-size slide

  32. Switch context back.

    View full-size slide

  33. Long feedback loop.
    Even if it's not three months, manual testing takes long
    enough for you to switch contexts and kill productivity.

    View full-size slide

  34. Automated tests shorten the feedback loop.

    View full-size slide

  35. Wait for Testers
    to Catch Up
    Can't Delegate
    to Juniors
    The whole notion of delegating work to
    junior developers is misguided.

    View full-size slide

  36. 1 2 3
    Task 1 is easiest. Task 3 is hardest. We
    tend to delegate easy stuff to juniors.

    View full-size slide

  37. 1
    2
    3
    We then let them work alone, in the hopes that
    somehow, they will acquire new knowledge over time.

    View full-size slide

  38. 1 2 3
    Hoping that they'll be able to suddenly work on harder tasks
    is inefficient, and doesn't guarantee best practices.

    View full-size slide

  39. Pair programming makes juniors useful today,
    and speeds up their road to senior.

    View full-size slide

  40. Pair programming also prevents
    the pipeline from drying up.

    View full-size slide

  41. ✗ ✗
    Senior devs will retire, start their own companies, or move
    to other roles. More pressure on remaining senior devs.

    View full-size slide

  42. Wait for Testers
    to Catch Up
    Heavy
    Development
    Process

    View full-size slide

  43. Communication specs through docs is
    inefficient and error-prone.

    View full-size slide

  44. Behat / Codeception
    * Or anything using Gherkin.

    View full-size slide

  45. Scenario: User can subscribe with a credit card
    Given I selected a subscription level
    When I enter valid credit card details
    Then I should see a payment receipt
    Business people can understand the requirement at a glance.
    There's no chance at ambiguity. It's always up-to-date.

    View full-size slide

  46. Too many meetings.

    View full-size slide

  47. A few people talk, the rest listen to
    things that don't concern them.
    Invite as few people as possible.
    Take notes and share if needed.

    View full-size slide

  48. Fewer people make meetings more productive:
    more focus, more opportunity to speak.

    View full-size slide

  49. No-meeting
    day
    Declare recurring no-meeting days.

    View full-size slide

  50. No-meeting
    day
    No-meeting
    morning
    No-meeting
    morning
    You can also ensure that devs have several
    consecutive hours to focus on other days.

    View full-size slide

  51. Build teams.
    Stop assigning one developer per project.
    Teams are where the magic happens.

    View full-size slide

  52. Real world example: 6 projects / 4 devs = everything on fire.

    View full-size slide

  53. Build a team and keep the
    other projects in backlog.

    View full-size slide

  54. You can also build several teams.
    Just don't start all projects at once.

    View full-size slide

  55. "Capable of dealing with
    competing priorities."
    Biggest warning sign in job descriptions.
    Translation: we're always on fire.

    View full-size slide

  56. Better tooling.

    View full-size slide

  57. Company won't give this person direct access, forcing
    them into a very inefficient, soul-crushing process.

    View full-size slide

  58. • Configure Xdebug
    • Use an IDE
    • Give people access
    * xdebug.cloud for an even easier setup.

    View full-size slide

  59. You don't necessarily need more
    developers.
    You may just need to make them better
    at their job and avoid wasting their time.
    Start by making the most out of the devs
    you already have.

    View full-size slide