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.

Transcript

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

   View 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 Slide

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

   View Slide

4. Dig For the
   Root Cause
   

   View 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 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 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 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 Slide

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

   View 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 Slide

11. Clean code has fewer defects.
    

    View Slide

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

    View 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 Slide

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

    View Slide

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

    View Slide

16. Pair programming.
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

30. I now need to switch context.
    

    View Slide

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

    View Slide

32. Switch context back.
    

    View 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 Slide

34. Automated tests shorten the feedback loop.
    

    View 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 Slide

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

    View Slide

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

    View 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 Slide

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

    View Slide

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

    View Slide

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

    View Slide

42. Wait for Testers
    to Catch Up
    Heavy
    Development
    Process
    

    View Slide

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

    View Slide

44. Behat / Codeception
    * Or anything using Gherkin.
    

    View 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 Slide

46. Too many meetings.
    

    View 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 Slide

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

    View Slide

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

    View 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 Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

56. Better tooling.
    

    View Slide

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

    View Slide

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

    View 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 Slide

60. @afilina
    

    View Slide