It’s a Book! OCP Java 11 Complete Study Guide Now Available!

Jeanne and I thrilled to announce “the birth” of our new OCP Java 11 Complete Study Guide! This nearly 1200 page tomb of work is the combined product of our two recent OCP Java 11 Study Guides (Programmer I and Programmer II) and contains everything you need to pass Oracle’s the 1Z0-815, 1Z0-816, and 1Z0-817 Java exams. On top of that, it’s filled with challenging practice questions, interesting examples, and a bit of fun and humor.

Available for purchase now in physical or digital editions, where ever books are sold.

the effective remote developer – live blogging at qcon

The Effective Remote Developer
Speaker: David Copeland @davetron5000

See the list of all blog posts from the conference

David has worked for 4 years remotely. Most people are remote.

Definition of remote

  • “You are remote if you do not often interface face-to-face with the people you work with”
  • hard – lone wolf – only one person is remote
  • easy – everyone is remote
  • also – multiple offices

Definition of effective

  • Productiving value
  • Agency – don’t just want to be closing jira tickets
  • Inclusion – don’t want to be that guy in Alabama that people send work to
  • Rewarding

Not easy; takes constant upkeep

Benefits

  • Freedom & flexibility – no commute, acccess to own kitchen, live where want
  • Company has access to wider pool of talent – slowing down ability to liver by restricting to specific area

Must build with people you don’t know and maintain trust with people that don’t.

Trust

  • “the half life of trust is six weeks – it must constantly be replenished”
  • Communicate frequently and clearly – Turn big projects into small ones. Everyone knows what working on. Get early feedback. So shows value delivering. Provide more context. Read what wrote and revise at least once. Use bold/underline/whitespace for clarity.
  • Be responsive, but set boundaries – publish your working hours (including time zones). Put in email signature and comment if meeting outside working hours. Developer a worklow where you aren’t heads down coding for hours; develop mental SLAs for communication. Specific affirming (positive) feedback is useful.
  • Assume good intentions – we are not good at critiquing. remember the reviewer is trying to help even if sounds cold and harsh.
  • Help others help you – go to chat or video for people who don’t communicate well over emai. Find out how everyone best communicates. Be specific in what type of feedback you want

Base level of technology

  • Easiest thing, but need to be successful
  • Chat system that is easy to use
  • Video conference that supports multiple people
  • Better mic than laptop mic

Types of communication

  • Coding – Think about smallest viable change. Write better change requests so can judge your changes. Learn to screencast (quick video) and diagram.
  • Synchronous – ex: video chat. Experience people as a human when not present. Be prepared. Formulate opinion in your mind. Use nouns instead of pronouns more than you think in case a few words drop. Also, pause more frequently and ask for feeback. “Any questions before I move on”. Don’t multitask; pay attention – best case is missing info; worst case is getting called out or having to ask. Have regular backchanel for tech issues.
  • Asynchronous
  • Socializing – If quiet in office, people still know who you are and that humanizes you. If remote, you are a producer of emails. Use time before meeting starts to socialize. Have one on ones with no agenda. Like scheduling time to stand around the water cooler. Travel to meet others in person. Accept that will miss happy hours

Remember computers are terrible and nothing works. Can bond over shared bad experience.

When interview, do chat and give take home project (add a few features) then pair program remotely to add another feature. Then fly onsite to interview. Have hired a few without flying in

Dedicated area at home to work.

Many of these tips are helpful even without remote developers.