This is part of my live blogging from QCon 2015. See my QCon table of contents for other posts.

Coding isn’t enough to be a good engineer.

“Mature engineers lift the skills an expertise of those around them” – John Allspaw “On Being A Senior Engineer” – bit.ly/senior-engineer

Must understand why doing things. Teaching to fish is an essential skill at this level.

Why to be a good mentor?

• Mandatory for career advancement
• Needed for their careers too. Having a mentor is often the difference in staying in the industry
• Your company needs you to mentor junior engineers because they need senior engineers. Who are hard to hire
• Our industry’s future. The next generation is trained by us, not by university

Need – vision, goals, mentor with expertise Need to be able to evaluate them and provide feedback

Becomes negative feedback loop. Think if bad and fail, won’t have to do it again. Just witing for time to pass. Never get better if don’t want to try.

Good to have small/clear goals so can progress/grow. Within vision of company. Good if like mentee/stay in touch have lunch/etc. [I agree. Easier to respond to feedback when have trust]

Lessons learned by speaker

• Be eagar to help. Or at least appear to be. If you look like you are angry when someone asks for help, they will be afraid to ask. Need to seem excited to be interupted. (or preferably actual be). You don’t want your apprentice to be blocked. He/she isn’t learning anything and you can’t evalulate. We overemphasize figuring things out on your own.
• Know what your apprentice doesn’t know. ex: github, pm, working on one thing at a time. Try to anticipate these questions. [This is why I like a buddy system when there are mutiple new people. It’s harder to keep track of what multiple people are up to]
• Admit when you don’t know. It models that it is ok to not know things an not be embarassed when don’t know. Also helps teach problem solving
• Ask apprentice for help. Can do code review even if don’t find much/anything. Still learn. Still create good patterns

Excuses for why not to mentor

• “I’m an introvert” – controlled interactions are easier. Predicatable. Apprentice is likely to be an introvert too so understand each other. Introverts listen. Can develop a relationship
• “I can’t explain what I know” – can teach by working together; don’t have to explain to teach. If it can be explained, it probably is in a book somewhere
• “I’m a bad mentor” – It is a skill that improves with time/practice
• “I just want to code” – Some people don’t like leading young people. History of craftsmanship with master/apprentice relationship. Making the investment can change how you think of yourself. Satisfying feeling when work

Q&A

1. I asked about you becoming Google for trivial facts by never letting your mentee block. He said that he thinks we are so far on the side of not wanting to be interrupted that trying to always be open will help shift to middle. Someone brought up the idea to timebox that window. Such as an hour of blocking max.
2. How do you balance how much time on your work vs apprentice? Your apprentice is the #1 priority.
3. How deal with multiple apprentices? Best if one to one. Cuts back on pain of being interupted
4. Interns provide muscle. Should intern be involved in your project or a separate one? Interns are not muscle. Not significant productivity compared to what take from you.[I disagree. I think we came out ahead four of the five summers we had an intern on my team]
5. Can be scary to mentor. Imposter syndrome. Knowledge atrophy. Ok to admit what don’t know. Have wisdom even if less tactical

I like the session. A case study of good/bad internships was a good way to present the material.

This is part of my live blogging from QCon 2015. See my QCon table of contents for other posts.

Excited to see Mary as the keynote. Good speaker and good role model.

Abstraction
The presentation started with Moore’s law going back to the very early calculators and covering the different generations of hardware. We are a trillion times faster since 1940’s. Massive minuiturization as well.

Happened both by becoming small and by abstracting out how classes of things. For eample, no motherboard in 1970’s.

Then she went into how code changed over her career. Fortran to HTML Baby steps as far as abstraction is concerned. Same generation. Changes not as vat in hardware.

Generation changes – reading/writing, printing press, personal computer, internet, culture of participation.

Currently a project where you can design your own sensor and plug into your phone.

Federation
Federation scale

• mini-computer evoloved to embedded – control you rown process
• pcs evolved to servers – retail software packages
• internet evolve to services – websites
• smartphone evolve to wearables – apps interact through the cloud

Federation leads to wide participating. Can share from own serice. More open source. Sharing helps industry grow. Reputation on sites like ebay allow anyone to share. Share practices on blogs. Education online.

If thinking about scale, think about how you can share.

Friction
Large systems don’t deal well with friction. Container ships helped with this. Standards size/shape.

Enterprises have databases. We create deep dependencies across apps because all hit same data. Which means high friction because hard to change. Amazon microservices have local data. Trying to decouple.

What is a microservice

• A microservice must be indpededently deployable to be useful.
• Small team-endto endreonsibility. You build it. You monitor it. You fix it
• No central db. Extensive automation and monitoring. Canary releasing. Smart versioning services. Double mock contract services

Companies with very high volumes like Amazon seem to require microservices. Requires strict discipline/operational excellence. Teamsnee situational awarenss. Must know all the time how service impacts customers and providers.

If you and provider change rapidly, how do you know mock returns same value. Create a pact so can check. See pact github project

Goals: limit risk and lower friction

How do you deal with a monolith if you have one?
Pack dependent code into containers. If put service and dependencies into a container, can put box around it and isolate it. Refactoring to make smaller/simpler. [I like how nicely she got from container ships to virtual containers]. This gives you portability, consistency, isolation, ease of use and better server utilitation. Most importantly, get lower friction and less risk.

Smashing it doesn’t work. Poking it does. Smashing is like a releae. Poking it is continuous delivery.

DevOps
If have branching, aren’t doing continuous delivery. Deploy mainline always with new features on switches so can turn on when ready.

Some people want to be safe (safety goals) and some want to be experimental (aspirational goals). With safety, failure/setbacks cause more efforts. With aspirational goals, prasise causes more effort. For safety,attention is for bad behaviorand asprirational, it is for good. Ops tends to be safety and dev tends to be aspirational. Marriage works well when have both, but must work towards same goal.

Who is responsible? Everyone. “Nobody succeeds unless everyone succeeds”

Getting to continuous delivery isn’t inherently harder than other tech issues. The main obstacle is organization.

In military, need to maintain situational awareness one level up and command awarenestwo levels up.

Great talk. A nice start to the day. I like that she sprinkled book and blog references throughout