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