I am a Transgender, blogger, speaker, developer and ops person (see DevOps), I vastly enjoy positions of leadership, for those who knew me by another name, I am immensely sorry for being a massive asshole, I'm now reformed and infused with estrogen.
Random interests include RC Cars (scale and drift), Movies, watching loads of TV, Start-Ups, Speaking at meet-ups and conferences, baking deserts, high-heels that I can't walk in, electronics & IoT, security.
DevOps is a massive passion for me, precisely the SRE model that emerged from Google, I enjoy reducing the friction between Development and Operations, We’re always going to see pure Developers, but I believe pure Operations will become more and more niche as we move away from on-premise and towards the codified cloud.
You can read more about SRE here.
As a transgender woman with a deeply flawed voice, I'm terrified of conference talks which is one of the main reasons I push my self so hard to keep doing them. I'm also a very bubbly speaker, and I take all engagements seriously and spend a whole bunch of time preparing. I also say a little prayer to the demo gods just before I get on stage.
I'm hugely passionate about DevOps; I started my career as a network engineer scripting for a Novel to NT4 migration project. I eventually became a .net programmer, switched languages and platforms a couple of times. At some point, I took over as Head of IT Operations and built one of the first Microsoft private clouds on-premise.
Using both my skills sets allowed me to implement DevOps before the term was coined. Right now we can see more parts of the platform lifecycle getting involved at an earlier point such as Info and Sec which shows how powerful collaboration can be when you shift left a bit more.
While I'm not from the school of TDD, I do believe that it's important to understand who is and who isn't of that ELK. It can be quite damaging to your code base to aim for one 100% test coverage with non-TDD dev's, usually what you end up with is 100% test coverage by path, but little thought put into functional tests.
I have a previously failed start-up called Whish; the idea was to crowdsource delivery so that buyers could request goods, commit upfront to the contract, couriers would be able to float their own money to buy the products and Whish would act as a broker with quick payments and instance disbursements.
The primary challenges Whish faced were being unable to instantly disburse fees + float to the couriers upon delivery of the goods to the customer. Company cards, robotic automation, payment platforms were all evaluated, but in the end, the required speed of disbursements just wasn't in place to allow me to launch this business.
Happy Labs draws off some experience in low moral environments, the platform goal is to help teams and well as leadership take a reading on team happiness, I hope that the temperature can be used to steer better decision making, as-well-as help illuminate issues in a team that might not be so obvious.
You can find the labs here.