Whilst in Sydney I had an interesting discussion around DevOps. I see DevOps as a skill that sits in a team, not as a separate team. If DevOps (and similarly QA) are separate teams its an anti-pattern, meaning the team hasn’t understood the concept of “Done”, and have failed to embrace the culture of delivery (to production).
A few items that maybe of interest to readers:
Angular 2, although a long way off, appears to be a contender for the future. Worth a read (but be aware the Angular 2 API changes almost daily):
When the Netflix Culture deck hit the web some long time period ago it generated some good conversation. Although I never wrote anything about it at the time, other than posting the link, I found the deck most interesting for the conversations it generated:
- “Hire, Reward, and Tolerate Only Fully Formed Adults” – a great comment from HBR.
- “During 30 years in business I’ve never seen an HR initiative that improved morale”
- “We had no vesting period—the options could be cashed in immediately”
- Some great call-outs here and here.
- “Outstanding” employees only. Netflix doesn’t accept anyone who does an “adequate” job (Hastings says those hires often lead to “generous severance packages”).
- “Freedom and responsibility” vs command-and-control: Employees get to make decisions; managers just give them the right context to do so.
- No “brilliant jerks.” It doesn’t matter how good you are at the job. If you’re a jerk, you won’t stick around Netflix for long.
Which leads me to the following thought:
Are HR departments an anti-pattern for managers actually being managers.
Whist in Sydney recently I went to the “Introduction to React Native” Meetup at the News Corp offices. Both presentations were good, but the demo at the end was enlightening, and force me to return to my hotel, complete the rebuilding of a completely broken OSX, and execute the Getting Started guide over on the React Native site. React Parts was mentioned in the presentation as being the place to go for appropriate components – although the few components briefly scanned did appears to be missing tests :(
Clearly although React Native is still in its early days it offers some coolness around building native iOS components. Android appears to be possible with React Native in the future, and one can only assume Apple Watch iOS apps will also be supported
H2O allows “users to combine the fast, scalable machine learning algorithms of H2O with the capabilites of Spark” – sounds all very intersting. Having not had time to play with H2O it would appear that Flow is key to an almost like Clojure REPL (“Read-Eval-Print Loop”) environment. This in itself is interesting for the obvious reason of wanting a RAD environment to improve the models.
Fraud Detection is as usual one of the use cases offered by H2O. I suspect however that financial companies maybe interested in H2O given the issues in the compliance world, especially after the LIBRO incidents the sector has encountered over the last time period.
Customer Intelligence from my perspective would probably be interesting to Proof of Concept (PoC) in the client trading space – think RFQ’s, think trading patterns, think pushing dedicated research to clients etc
Anyone built any interesting PoC’s in H2O?
On the road to continuous refinement of the Continuous Deployment (CD) pipeline, I always find that teams often forget about security testing, in a similar way to performance testing. Teams seems to focus in code, then aContinuous Integration (CI) process at the outset. Only later when they begin to have conversation about the first prod release do they become aware of the need for CD. At the point of CD, they are still not thinking real CD, and thus have overlooked the needs of security (and performance), and are still fixated on the code – not the cleanliness of code.
I’m therefore curious how many readers are using OWASP Zed Attack Proxy, or similar in their tool chain.
Many people struggle when they move into a tech lead role. Primarily because there isn’t a well defined reference guide in most organisation as to what a tech lead is. This book offers some insight by stating the obvious, and interviewing numerous tech leads.
- Page 17 – “Learning better time-management and task-management techniques as well as delegation skills will help you to cope.” Classic management foundations. Although obvious, it needs to be re-iterated and remembered.
- Page 178 – Failure is a natural part of the learning process; it forces you to evaluate circumstances.
- Page 240 – “Lessons Learned by First-Time Tech Leads”
- Page 242 – “Lessons Learned by Practising Tech Leads”
If you do nothing with this book, read page 240 and 242 as the bare minimum.
Remaining technically grounded