Recommended
More Related Content
What's hot
What's hot (9)
Viewers also liked
Viewers also liked (20)
Similar to Why other ppl_dont_get_it
Similar to Why other ppl_dont_get_it (20)
More from jaxLondonConference
More from jaxLondonConference (20)
Recently uploaded
Recently uploaded (20)
Why other ppl_dont_get_it
- 1. Why other people don’t get it @sandromancuso
- 3. Which ones are the good developers?
- 4. You tell me You fucking hired them
- 7. Managers complain about developers, but: Do they know what a good developer looks like? Do they know how to hire good ones?
- 8. Developer: How do I convince … ?
- 9. 1. Define the culture you want to have in your company. 1. Don’t make your problem bigger. Hire allies. 1. Help people to help you.
- 10. Changing the recruitment process Look for passion
- 11. job descriptions are bad
- 12. Java Developer - J2SE / J2EE - Financial Software Java Developer (J2SE or J2EE) with SQL experience required for a permanent role with a growing and extremely successful Financial Software organisation. The ideal candidate for this java development role will possess a passion for technology and a desire to have exposure to, and learn more about the Financial Services arena. Salary: £50,000 - £60,000 plus benefits and bonus Skills and Experience Applicants must have strong core Java skills gained in a commercial environment along with the following technical skills and experience: • 5+ years intensive Java Development (J2SE or J2EE) • 3+ years intensive SQL (some knowledge of SQL Server and Oracle) • Experience with web technologies (ideally HTML 5, CSS 3, jQuery, Spring MVC) • Strong OO analysis and design experience • Experience of the full software development lifecycle (SDLC) • Ability to clearly communicate with peers, business analysts and subject matter experts
- 13. Java Developer - J2SE / J2EE - Financial Software (cont.) The following skills would be beneficial but not essential: • • • • • Development on high performance distributed systems (in java) Experience with both real time and batch systems Experience with distributed technologies such as Oracle Coherence Experience with Spring , Hibernate Experience in an agile environment (including TDD, JUnit, etc.) The java developer role will involve close interaction with the Systems Architect, Java Team Leaders and other members of the development team and will demand a high level of design and coding to implement and deliver enhancements. There will be ample opportunities for the successful java candidate to quickly expand on their banking and funds management experience, with plenty of business exposure.
- 14. [Ideal candidate] … will possess a passion for technology
- 15. What if a job description is needed?
- 16. Developer (senior) - Development Team We are looking for smart, self-motivated software developers to join our truly exceptional development team. Good working TDD experience is essential for this role. About you • • • You care about software; you have a passion for what you do which you can clearly convey by your actions rather than just waffly personal statements on your CV. You have an eye for software design and can talk eloquently on a range of topics due to your experiences and also from reading and experimentation. For you it’s more than a job. TDD Among other things we’re strong advocates of TDD. We think it represents such a particular mindset we’d only consider you for a senior position if you have significant working experience with it. If you do have working experience with TDD, great! We want to know more. How much? How did you do TDD? How have you used TDD on a recent project? What problems have you faced? The more the better!
- 17. Developer (senior) - Development Team The role Our teams are cross-functional, self-organising and highly autonomous. No architects, project managers or middle management, you’ll be working directly with our Product Managers and stakeholders in a highly collaborative manner. This approach requires a huge amount of teamwork and maturity and is not right for everyone, but we believe it’s the best way to create great software. Among other things, Pair Programming, TDD/BDD, Refactoring, and Continuous Delivery are deeply embedded and we’re constantly striving to improve the way we work. We know typing is not the bottleneck, so among other things: • Have around two sessions a week spending time doing things like Katas, Dojos and discussing practices and technologies. • Each get up to two days “innovation time” a month we can use to play with new toys or product ideas. • Regularly attend conferences and community events, both as participants and contributors (we’ve recently ran sessions at QCon, SCUK and SPA). • However, we’re not perfect and not afraid to say so. We recognise we have many problems which need solving and a long way to go on our journey of continuous improvement.
- 18. Developer (senior) - Development Team Technologies we use Most of our stack is C#/.Net but we’re using and investigating many other languages and technologies (e.g. Ruby, server side JavaScript, C++, Python). We’d be interested in candidates from any background as long as you have a keen understanding of Object Oriented languages. Here’s a (not exclusive) list of technologies we currently use: • C#, Ruby, JavaScript • ASP.Net MVC, OpenRasta, Nancy, ServiceStack, Nhibernate, Windsor, StructureMap, NUnit, RhinoMocks, ReSharper, NDepend • Cucumber, Rails, RSpec, Rake, Capybara, Selenium, Watir • REST, Oauth • MS SQL, ElasticSearch, Solr • Mono, Windows, IIS, Nginx • RabbitMQ • Git, TeamCity We’re also very keen on open source. We contribute to some of the technologies listed above as well as maintaining our own forks (+ publishing other things we’d like to share) on our GitHub account
- 19. Culture & Values
- 20. You can’t be serious about building a great team if you don’t have time to interview
- 21. filtering developers by passion
- 22. The interview process code submission technical conversation pair programming session final conversation
- 23. Don’t blame the developers Ask yourself how they were hired Ask yourself how they were nurtured
- 24. The longest and hardest recruitment process in history
- 26. switching projects for an iteration pet project time book club communities of practice group code reviews tech lunch hands-on sessions roundtables switching projects for a few hours
- 27. It’s better to ask forgiveness than to beg for permission
- 28. What if others don’t join in?
- 31. autonomy, mastery, and purpose
- 33. Dear Manager, The reason why people don’t give a shit is because that’s the behaviour you unwittingly nurtured. Yours sincerely, Sandro
- 34. Dear Developer, The reason you have to put up with a lot of shit is because you haven’t done enough to change the situation. Yours sincerely, Sandro
Editor's Notes
- Managers asking for team assessment (who is good, who is not?)Common question asked by managers. “We give them the ‘freedom’ to do stuff but they don’t care”.
- There is no way I would name someone, unless I think there is someone that will destroy the team. It’s not right to spend sometime with developers, earn their trust, and then betray them.
- Managers asking for team assessment (who is good, who is not?)Common question asked by managers. “We give them the ‘freedom’ to do stuff but they don’t care”.
- "Why do things take so long to be done? Why the developers don't care?Why is it so hard for them to understand the business? I don't think this Agile thing is working for us. We need better developers—talented people, people that can get the job done.”Whenever this question is asked, I know that the problem is much deeper than that:Incompatible attitude. What is good, what is not? (devs vs. managers)
- Mr Manager: Good developers are not the ones that do what you want.Good developers are the ones that can
- "How do I convince my team to do TDD? How do I convince my boss about pair programming? The other developers in my team don't care. What do I do? How do I convince my boss that we need more time? How can I find a good company to work for?"
- When thinking about this talk, I wanted to talk about many things. Everything we did in the past 2 / 3 years in a large IB. However, I decided then to focus on recruitment, since I consider it to be thing that should be changed first. 2. Stop recruiting the same type of people you are trying to get rid of. 3. Provide an environment where they can learn and flourish. Help them to get the knowledge.
- Company wants good developers. The problem is that good developers also want good companies.Unless your company is in the middle of the Brazilian rainforest or the Sahara desert, consider that your company is not good enough to attract good developers.
- Reasons:Promote keyword matchingDesigned to weed out the worst instead of attracting the bestNot used for internal promotions
- Created for mass marketJ2SE (OR) J2EE? Old acronyms (J2EE instead of JEE). Old rolling spec that no one cared to update?Passion for technology, as long as it is Java. Small salary range: as if all developers were equal.Seniority measured by years, not by knowledgeSDLC: Planning, Analysis, Design, Implementation, Maintenance (inclination to waterfall)
- Agile / TDD is not essential. Mix Agile with TDD and Junit (as if they were the same). The “etc.” after Junit reinforces that Agile is just a bunch of not essential stuff they don’t care much.Hierarchical environment, with architects and team leadersNo interaction with real users or business (POs).Subtle message: Gaining experience in the business will help you move on with your career, becoming a manager.
- In the previous job spec, this is total bullshit. No one values passion for technology there.
- Design it to attract passionate developersAbout You sectionTechnical practices are more important than specific technologiesState the company structure (no architects, PMs, middle mngmt.Time for learning and sharing
- About You: Tailored to attract passionate developersTDD: They know that solid technical practices are more desirable than knowledge in a specific technology.Seniority measured by experience.Clearly states their culture and values.
- Technical practices more important than knowledge in specific technology.Time to practice and learn is embedded in their culture and highlighted in their job description.
- - They talk about technology they use, not the technologies that are essential for a candidate to know.- Value OSS, contributing to OSS projects. - Have their own GitHub account.
- This is not just about a job spec. This is about a company’s culture and values. What is your company culture? What are the values?Mr. Manager? What have you done for enabling your company to be like that?Mr. Developer? What have you done for enabling your company to be like that?
- Every one complains they don’t have time to interview. Mistakes: Delegate interview to recruiters and vendors; Inefficient filter criteria; Failure to find good developers; Failure to understand what good developers look like. First change: Empower the team to hire
- The first change in our selection process was to filter by passion:No attention to CVPublic profile: GitHub, Pet projects, Blog, open source contributions, Twitter, Tech Communities, Books, Whichever filter criteria you use, you will always leave good people out.
- Code submission (using their own GitHub)Complex enough to use a few classesNo technology requirementNo deadlinePair programming sessionTime to start, not to finishBring your own laptopChoose your own language and tools
- You may have a much bigger problem. A people hire A people. B people hire B and C people.C people just hire D and E peopleBeat the passion out of the devs.
- No formal interviews. Just a 30 minutes conversation.Recruiting from community.
- Managers: Enable your team to do itDeveloper: Take the initiative and organise the sessionsAvoid consensus delayDon’t ask for authorizationDon’t complicateEstablish a rhythm
- That’s what I’ve done at UBS. I kept pushing the boundaries. Managers want people to get stuff done and many times they are just happy that some one goes there and does something.
- Not everyone at UBS joined. Frustrations. 80-20 Pareto’s law. 20% of the people can make a 80% improvement in the company.Be an exampleFocus on those who careDon’t forceFew people, big improvements
- Two of the main reasons why we have bureaucracy and politics inside companies.
- Ivory-Tower architect storyManagers: If you are responsible, you should also be accountable. Developers: Don’t take accountability if you don’t have responsibility.
- As a manager, you should strive to provide these three to your employees.As a developer, that’s what you should look for in a job.
- You wouldn’t ask questions like “Why my people don’t .. ?” if you had hired good people, provided them with a learning environment and empowered them to do their jobs.