Any tips before I start my first Android Dev job? Thank you everyone :)

Work 8 hours a day and study 4 hours a day the libraries, procedures, and examples for the libraries being used for a month, maybe two. Consider it a future investment. Once you master it all you can get your work schedule down to an hour or two a day.

Download the SDK examples in Android Studio all of them. Walk through them and understand what they are accomplishing and how they did it.

Live in the Google Android Documentation not Stack Overflow (whilst giving a shit lol explained below)

Architecture can be standard or wonky. Make sure you follow the patterns by copying other code in the code base that does close to what you are doing. Most of the major projects are the same thing over and over again with subtle differences.

Even take their exact code and implement it once on a new fragment and each subsequent layer and work backward by making alterations until the screen meets your requirements and uses whatever new web service or storage mechanism that's needed.

After you do this a couple of times you'll understand their decision-making. Their layers. Their architecture and you'll fit in.

Use Git annotate to find the most through person on the team that has the easiest-to-follow code that accomplishes the most and have him review your work.

Follow his feedback and don't get upset if he stomps on everything you've done the first few times. If he is the neatest and most productive he's likely slightly autistic and isn't going to care about your feelings. His goal will be to protect his baby and get you productive without you causing too much mess.

The first month they'll likely assign you small text or layout changes. Take this time to study all the layers and data interaction points.

Also, don't forget that sometimes everyone on the team is terrible at coding so you might be in a huge mess. When in this huge mess you'll stay employed forever doing very little. Take this time to learn. If you can't find anything in the code base that follows the exact pattern discussed above multiple times consistently, you are here. They have bad management, QA or don't know how to fire staff. This happens when no one had industry experience on the entire team going into the project.

If you have read a computer science book you should be able to follow the code albeit it'll be time-consuming at first.

Make sure you get good with the debugger and walk through the code.

It's getting a lot harder to follow code these days with very very stupid unneeded inversion of control everywhere.

Alt+Enter is your best friend.

After a month or two of making sure your code is crisp and meets the standards of their most 'uber' developer. There are two routes to take.

A) If the team is hard-working, consistently trying to improve and the project is at least heading towards or has a baseline architecture and consistency --- work harder than them. Find improvements in their arch. Ways to greatly speed up the execution or draw times of the application. Be harsh on yourself and ask yourself how do I improve this user experience and share your results with the team, in this type of environment you'll hear constant remarks, feedback, and proposals for improvement and the developers will always be trying to buy more time from business to perfect. Business will be pushing for features. Both sides give a little. Everyone is happy and motivated and feel like engineers not minions. Great learning environment, each year here is really ~ 5 years experience.

B). Next type of team that's low morale from oppressive business or 1 or devs with negative attitudes that are burnt or a few other reasons. Decent architecture, but you can feel no one cares. In this situation finish your tasks the best you can to make the business people happy and check out for the day as fast as you can and study work with other projects. You can see if your in this environment if you suggest a minor improvement that's logical and you get a bunch of push back and there's nearly moans and groans. No one will participate in meetings or their answers will be the bare minimum amount of work over the best solution.

C) Next type of team is no one knows what they are doing. Try to finish your tasks, if they don't make any sense (this happens) ask a lot of questions. Stay in constant communication. These team's base performance around communication and if you know what you're doing, but don't constantly communicate they will try to literally get you fired. They do this because they are trying to set a rubric they can easily pass, so they never have to worry about being fired by making performance not matter. Stay very quiet in this environment but always respond. Its likely many of them have been working on this catastrophic failure for many years drawing a good salary and the reason they are still there is they are very good manipulators. Start looking for new work, keep your head down, you're are going to be super frustrated coming in green to this situation. If you aren't worried about your future or learning, these projects are mislead and way overfunded you can get salary for a long time. Don't get enthused. Don't 'fix' things. The incumbent developers may see this as an attack. You'll get fired.

There are a few more team dynamics to deal with. Like too much process that nothing gets done etc, but they all fit into above. Stay objective & only use statistics or objective reasoning to show that a piece of code is garbage etc. Stay positive. Try to speak very little and work very hard.

Chat a little with each team member. If you find one that isn't a douche waffle, they'll take pride in helping you get unstuck etc. People that aren't douche bags are pretty easy to spot. There's quite a few douche bags in programming teams however. (Non douche bags only happens in the first two team dynamics).

/r/androiddev Thread