The Android Gunslinger
•Download as PPTX, PDF•
0 likes•447 views
A lot of talks go about how to work on a big team, but which are the challenges you face when you're the only person working on your platform? What are the stakes when you are on a small team really product-focused?
More Related Content
Viewers also liked
Viewers also liked (18)
Similar to The Android Gunslinger
Similar to The Android Gunslinger (20)
Recently uploaded
Recently uploaded (20)
The Android Gunslinger
- 1. The Android Gunslinger A hero’s jouney to building a product Saul Diaz Android Dev @ Chicisimo.com @sefford sefford@gmail.com
- 5. BEGINNING
- 6. ARCHITECTURE PRODUCT IS ABOUT INTENT RULE 1: NEVER CHANGE THE DEAL RULE 2: NO NAMES RULE 3: NEVER OPEN THE PACKAGE
- 8. DEVELOPMENT From a product viewpoint
- 9. Specification Analysis Design Impl. Testin g Deploy Maint. Review Review QA Analysis Design Impl. Testin g Deploy Maint. Prototype Asseting PRODUCT LIFECYCLE
- 11. ARCHITECTURE IS ABOUT INTENT PRODUCT PURPOSE
- 12. PRACTICES
- 13. THERE ARE NO BRAKES
- 14. YOU ARE YOUR OWN WORST ENEMY
- 15. Analysis Design Impl. Testing Deploy Maint. SOLID BS + CI UNIT ACCEPTANCE COVERAGE BETAS S.ROLL CRASH REPORTING SOFTWARE LIFECYCLE SEMANTICSITERATIVE
- 16. RELEASING
- 17. THINGS PEOPLE DON’T DO: READ GIVE A F**K UPDATE
- 18. THINGS PEOPLE DO: COMPLAIN CLICK KEEP THEIR PHONES ON A SHITTY STATE
- 20. THE COMPANIONS
- 22. Questions?
- 23. Thanks for playing! Saul Diaz @sefford sefford@gmail.com
Editor's Notes
- A lot of talks go about how to work on a big team. But sometimes you will be hired on small teams or startups where you have to work alone. Obviously there’s always someone on the team. But what when you are on a one-man team in your platform? You become the Gunslinger. The guy who has to fight against the bad guys on their own.
- You will experience the “Journey of the hero”, which ironically can translate into the “Journey of the developer”.
- Rule 1: Never change the deal. Be a professional. Try to be clear on what are you going to do, and when you will have finished. Shit happens, but as you’re the only one, there is only one responsible. The rest of your team might rely on your deadlines. Rule 2: No names. Feedback should be always welcomed. Crticisim, both constructive and destructive should be accepted, no matter where it does come from, and take it as a warning shot before continuing with the same attitude/way of doing things. Rule 3: Legacy code. Do not change it unless you know perfectly what you are doing. (On a technical note, never tackle legacy without good practices on refractoring. - Build a reliable test suite of the code beforehand and go refactoring little by little.
- Sometimes we didn’t get there first. Sometimes we were not as cunning as we used to be when we did something. Be empathic. No good dev want to do shitty code; but sometimes rush, bad decisions or a bad foundation for a code can lead to “bad” legacy code. Most of the devs usually fear code they didn’t write. But rebuilding an app or parts of the app might produce two unwanted side effects. Reappearance of bugs that were already fixed on this “shitty code”. Losing time on doing the same thing over and over. Remember that, no matter how good you are, you cannot throw away eg 9 months of work and redo it better on 1.
- Let’s talk about Product lifecycle. Software lifecycle is already a complicated issue (Analysis > Design > Implementation > Testing > Deployment > Maintenance), but building a product is a much more complex issue: You have a PM who will write a specification of an app or feature Which a designer will prototype and asset In the meanwhile your backend team will attempt exactly to do all the work, hopefully before you do yours. And everybody will want to test and review the work done. Imagine how many things can go wrong from a technical standpoint.
- Source: From Spotify. But even more things can go wrong from the product standpoint. A product which is awesomingly good technically can fail because it does not convey the idea correctly. The difference on this slide is that the people on the top want to build a Car. Obviously a car takes a lot of time and pieces to be built, you start with a wheel, then the body, etc… until you finish. But your customers are not happy because you promised them a car. However the people on the bottom want to build a “mean of transport”. Obviously a skateboard is not as cool as a sports car; but it fills its purpose: To carry you from one place to the other faster and more effortlessly than a car. And then the only thing you need to do is iterate, iterate, iterate. Faster, more reliable, with more extras...
- That’s why Product is about Purpose. The best example of this is Bricomania TV Programme. They have a lot of professional tools to build the things they build; but they avoid to make the programme a show-off those tools. They USE those tools to show how to build things to improve your home. But the PURPOSE of the programme is about building the stuff, not using the tools. Don’t make your product become a technical show-off
- When you’re working on a small startup; the first golden rule is that: You cannot buy time, no matter how many money do you have. You have to think carefully your rodamap and your moviements. Invest wisely your time; a misstep might end up messing your time to deliver or mess up with the rest of the teams.
- When you work alone, the worst enemy is not the guy from product, the designer who reviews your sceeens or the QA who points your errors. YOU are your worst enemy.
- The best way to avoid you adding mistakes is yo use good practices from the beginning. Try to automatize things as much as possible, Build Systems, Testing suites, Continous integrations. Use tools that will cushion potential failures like Staged Rollouts and Betas, the sooner the code is in production in a controlled way, the earlier you will receive error reports. Use tools like Crashlytics to know where the app is failing and Mixpanel to understand cognitive frictions on the product itself.
- When everything fails, keep calm. Try to use your tools to diagnose properly: Analytics could be of use to understand if it is a certain brand, device or Android version which is failing. Having a push system from day 0 is advised. You can communicate things through push notifications or use it to enable/disable functionalities or app itself Try to hold the urge to hotfix every 2 minutes, especially on Android. Too many updates will fragment your userbase and will piss them off. Have a out-of-app update notification system. It takes little time and will bug the users enough to force them to update.
- Eventually your team will grow if things go properly, and will need to find a good partner. Find a guy who: Thinks, independently of how skilled on your platform is Delivers and can do stuff Is personality-compatible with you. Don’t feel bad if he’s better than you. You will learn from him. Don’t feel bad if he’s more junior than you. Everyone started learning
- Let’s talk about philosophy. What does Testing provide you as a developer?