On Tuesday 6/23//19, I became a Java Champion. If you aren’t familiar, there’s a good
overview of the program. To me, it’s an amazing peer recognition award! As of right now, there are 287 Java Champions. ( Andres Almiray maintains a list of Java Champions)
One of my friends took
video of the announcement. It was fun. I was the track lead of the Modern Java Innovation track. When I got up to explain the track, Wes (the MC) said there was a mistake on the slide. He then explained the Java Champion program and announced me as one.
Shortly after that came the official tweet
You might be wondering what I did to become a Java Champion. Many things including speaking, writing, volunteering with a robotics team, community contributions like CodeRanch and more.
A year ago at conferences, I started getting asked if I was a Java Champion. I was not, but it motivated to organize my accomplishments. I stood up a Google site to list what I’m most proud of:
http://jeanneboyarsky.com/. Time to add Java Champion to that list! (and yes, I know how to make a website; I choose google site so I could focus on content)
Randy Shoup @randyshoup
For other QCon blog posts, see
QCon live blog table of contents
You to not often interact face-to-face with the people that you work with Models- single site, multi site, remote first Anti-pattern; Centralized HQ control. Most things and all decisions done at HQ. Others get work doled out to them Anti-pattern: Site + Satellite Remote – One or several site where people work every day and one or two on own Remote first – everyone on video and slack. Model that Ok to interrupt b/c net slow
Larger talent pool Take advance of localized supply and demand Parallel hiring – can grow teams in parallel. Not tied to a recruiting team. Each site can hire in parallel Geographic hedge – can hire more in one region if things slow down in one Diversity and inclusion – flexible location/hours, geographic/cultural, neurodiversity (b/c communication styles vary) Retention – can live different places, employee satisfaction, productivity Little/no commute Flexibility Personalize work environment If at HQ and work with remote people, more flexibility because your teammates are remote Ensure each team full stack so not relying on team in another country for communication Follow the sun. Round the clock triage, on call handoffs Close to customers. Local presence, customer empathy, local implementation/customization
Local laws (hire/fire/severance) Local recruiting norms Local compensation – pay everyone as if at QA or by local market. But must be consistent Local currency – do you pay in US dollars or local currency Local regulation – laws, taxes More travel. Problem to never see teammates No commute == no exercise Solitude/isolation Time management. Easy to keep working Best to be single site or remote first. That way don’t have onsite conversation and inform (Or forget) remotes later Don’t have one site dole out work. That’s outsourcing Managing time zones – respect time zones over others. Watch DMs off hours. Trade off inconvenience. Use overlapping hours well
Possible to do remotely, but better to bring in a bunch in person Bond with cohort Instill company/team culture Mentor/buddy system – ideally two role/team and culture Structured onboarding that can do at own page – ex: recorded training
Video Audio Internet Connectivity – mifi hotspot good in rural areas Comfortable desk/chair/etc or coffee shop or co-working space Quiet/child proofed space
Maker’s schedule – want chunks of uninterrupted time. Try to have meetings close together to preserve time. Manager’s schedule – mostly meetings In a remote environment, blocks of time mater more Block out calendar, office hours
Good to have remote manager. Sets example, shows career advancement possible, empathy Clarity on goals 1:1 are sacrosanct, not a status meeting, praise in public (can be slack)/correct in private. Don’t have management by walking around so won’t see implicitly
The half life of rust is 6 weeks An interaction reinforces it
Video Chat Collaborative docs
Be really explicit about “what is the problem you are trying to solve” Clartify the “why” Straighforward language Repetition – a lot Culture of “ask in public” – remember to model this Also model “when in doubt ask” Be open to feedback when write doc and be specific about the feedback want Clarify the purpose of meeting Pre-reads. Or read doc together if can’t do before. Feels weird first time, but gets everyone on same page Template agenda for common meetings Cancel meeting if no agenda Have senior person moderate to stay on topic Allow time for chatting/social bonding
Did quarterly Primary goal was social bonds and connections Do high bandwidth communication Planned well in advance Rotate locations Spent a day learning together Prioritizing fun and team building Hackathon with theme Internal Conference Structured activity about coding
This was great. I’ve heard much of it before, but hearing it again helps reflect. And there were some that were new to me
Note: Randy mentioned his collegue’s 2017 QCon presentation a few times. Here is a summary
For other QCon blog posts, see
QCon live blog table of contents
Discovery vs Delivery
Delivery: completing lots of tickets, points completed, happy team Discovery – different goals Two types of work; two different ways of thinking Dual track agile – discovery is for learning. Inputs into delivery track. Discovery will happen whether planning to do it or not. ex: bug report Can change % of tie on discovery vs delivery over phase in project
Welsh word Complex/Chaotic/Complicated/Obvious Also box in middle for when don’t know which in. Complicated – can use knowledge to see what to do
Key areas of discovery work
Maximize learning – accelerate discovery, MPVs Want to encounter problems as quickly as possible Learning is messy and doesn’t easily fit Scrum process MVP goal – maximize learning while minimizing risk and investment MVPs can be paper prototype or a single use case Better ideas – idea flow, collective intelligence Levels: Psychology safety, dependability, structure & clarity, meaning, impact Validate with people outside team Closer relationships with specific customers so can see reaction as progress Alignment – OKRs, Briefs, Roadmap OKR = objective and key results Think about where want to go and how get there Should understand why vs an aspirational goal Alignment and autonomy are orthogonal Product brief – map from strategic level to feature going to build. It is not a requirements or architectural doc Roadmap – show on larger ranges of time Metrics – 3 levels, correct category (delivery vs discovery) Business, product and engagement metrics.
I like that he provided an outline with the key points up front. The OKR section was detailed with examples. I like that there were book references/recommendations. And it was certainly interesting. I think I expected it to be about something else, but I’m glad I came. I would have liked more on examples of discovery projects specifically.