To assume I could push anything on Fridays was too optimistic. Thus, I’ll commit to Saturdays.
My current company, NetGovern, operates with an open-book management mindset. Apart from other information, all employees know company finances so we can better understand what is our real position and where we plan to go next.
It’s tough to wrap your head around balance sheets or cash flows, especially for me: I was born in 1992, a year after Kazakhstan declared independence from the Soviet Union. Suddenly, generations raised in the planned economy plunged into the free market (didn’t go well). I' came from the culture of mixed and uncertain economic literacy, hence, all these stocks, investing, growth rates and margins don’t flow naturally into my brain.
Nevertheless, I don’t shy away from these topics because learning anything is the best hobby. This week, we read a paper explaining how to valuate typical SaaS companies (how to calculate a price).
The last myth from the podcast “10 myths about API documentation” is: people will respect you more if the word “writer” isn’t in your job title.
Insecure tech writers prefer to call themselves:
- Information developers
- User assistance developers
- Information strategists
- Content strategists
- Technical communications professionals
- Content engineers
First, these are so funny. Second, the testing field has the same tendency. My official job title is “QA & escalations analyst,” whatever this means. Testers don’t avoid the word “test,” but they do try to shoehorn hardcoreness with words “developer,” “engineer,” or “analyst.”
It’s not a secret that I’m not a fan of testing-only conferences. Not rolling your eyes is impossible when you see mind-blowing prices for the STAR conference and find there popular workshops like “Learning Git.” Pass.
Still, I checkout out some occasionally. Heisenbug is amazing. But most of the talks are in Russian, sorry folks.
The next available conference is OnlineTestConf, December 3rd-4th 2019. The previous one was passable, this one seems to have a similar structure. Still, nothing beats free and online. There will be big names, yet what caught my eye was the “Adidas Testing Platform” talk. Adidas API guidelines are awesome, and learning more about their processes would be cool.
Should this be a regular rubric? Perhaps.
Though I love APIs, my knowledge is unsatisfactory and insufficient to be confident in my new undertaking: writing API design guidelines. Without this document, your APIs will soon become an inconsistent mess. You need to have conventions on even the most basic stuff like capitalization or pluralization. We should have created this doc a year ago; doing consolidation and standardization will require painful fixing of existing clients, but better sooner than later.
As I said, I’m not an expert on API design. And I’m not a good writer either. I’m a tester whose job description is to find ways to improve quality. Next months will be fun: doing research, poking devs with sticks, and asking stupid questions in the “APIs You Won’t Hate” slack group.