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!" You generally don't need more devs. Let's find the underlying problem to the shortage and solve it.
  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… Ask "why" like a kid until you get the root causes.
  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 You can spend the majority

    of your time debugging. It usually takes more time to debug the code than to write it.
  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 If you need to modify 10 classes to add a tiny feature, then you're potentially introducing more defects.
  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. Knowledge travels between team members. Add new knowledge with conferences,

    pair programming with outside dev, etc.
  22. But all of this is expensive! Not really. Let's calculate

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

  24. PHP Community Summit: R$100 You can afford to send every

    single developer every year, and then some.
  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. A fully automated test suite gives the confidence to ship

    straight to production
  28. Typical non-automated QA process: I wait 3 months for tester

    to get to my code.
  29. Bug found in code I wrote 3 months ago.

  30. I now need to switch context.

  31. I don't remember what that feature was all about, since

    I did so many things in that time.
  32. Switch context back.

  33. Long feedback loop. Even if it's not three months, manual

    testing takes long enough for you to switch contexts and kill productivity.
  34. Automated tests shorten the feedback loop.

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

    The whole notion of delegating work to junior developers is misguided.
  36. 1 2 3 Task 1 is easiest. Task 3 is

    hardest. We tend to delegate easy stuff to juniors.
  37. 1 2 3 We then let them work alone, in

    the hopes that somehow, they will acquire new knowledge over time.
  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. Pair programming also prevents the pipeline from drying up.

  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 Business people can understand the requirement at a glance. There's no chance at ambiguity. It's always up-to-date.
  46. Too many meetings.

  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.
  48. Fewer people make meetings more productive: more focus, more opportunity

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

  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.
  51. Build teams. Stop assigning one developer per project. Teams are

    where the magic happens.
  52. Real world example: 6 projects / 4 devs = everything

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

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

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

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

  57. Company won't give this person direct access, forcing them into

    a very inefficient, soul-crushing process.
  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