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.

B3b2139e4f2c0eca4efe2379fcebc1c5?s=128

Anna Filina
PRO

August 21, 2021
Tweet

Transcript

  1. You Don't Need More Developers PHP COMMUNITY SUMMIT | AUG

    21, 2021 @afilina
  2. "We need to hire more developers, but we can't find

    any!"
  3. Anna Filina • Coding since 1997 • PHP since 2003

    • Legacy archaeology • Test automation • Public speaking • Mentorship • YouTube videos
  4. Dig For the Root Cause

  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…
  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.
  7. Code is Hard to Debug

  8. "Every hour spent on defect prevention will reduce repair time

    by 3-10 hours." - Jones, Capers. Assessment and control of software risks.
  9. 5 x 3 = 15 15 – 5 = 10

    1 hour each day x 3 hours saved on debugging – initial investment
  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.
  11. Clean code has fewer defects.

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

  13. • Easy to reason about • Testable and tested •

    Easy to modify
  14. Writing clean code doesn't take longer. It appears longer because

    it takes time to learn clean code.
  15. That looks interesting. Where can I learn this?

  16. Pair programming.

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

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

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

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

    time.
  21. Any knowledge eventually reaches the whole team. Inject new knowledge

    with conference, pair programming with outside dev, etc.
  22. But all of this is expensive!

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

    Glassdoor.
  24. PHP Community Summit: R$100

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

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

    Catch Up
  27. Fully automated test suite gives the confidence to ship straight

    to production
  28. Wait 3 months for tester to get to my code.

  29. Bug found in code merged 3 months ago.

  30. Need to switch context.

  31. None
  32. Switch context back.

  33. Long feedback loop.

  34. Automated tests shorten feedback loop.

  35. Wait for Testers to Catch Up Can't Delegate to Juniors

  36. 1 2 3 Task 1 is easiest. Task 3 is

    hardest.
  37. 1 2 3 Hope for junior dev to somehow level

    up by doing the easy task.
  38. 1 2 3 Hoping that they'll be able to suddenly

    work on harder tasks is inefficient, and doesn't guarantee best practices.
  39. Pair programming makes juniors useful today, and speeds up their

    road to senior.
  40. None
  41. Senior devs will retire, start their own companies, or move

    to other roles. More pressure on remaining senior devs. ✗ ✗
  42. Wait for Testers to Catch Up Heavy Development Process

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

  44. Behat / Codeception * Or anything using Gherkin.

  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
  46. Too many meetings.

  47. A few people talk The rest listen to things that

    don't concern them
  48. Fewer people make meetings more productive: more focus, more opportunity

    to speak.
  49. No-meeting day

  50. No-meeting day No-meeting morning No-meeting morning

  51. Build teams.

  52. 6 projects / 4 devs = everything on fire

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

  54. You can also build several teams.

  55. "Capable of dealing with competing priorities." Biggest warning sign in

    job descriptions. Translation: we're always on fire.
  56. Better tooling.

  57. None
  58. • Configure Xdebug • Use an IDE • Give people

    access * xdebug.cloud for an even easier setup.
  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.
  60. @afilina