Press "Enter" to skip to content

Category: Learning

Supporting 100 Languages with Microsoft Translator

Krishna Doss Mohan and Jann Skotdal take us through the evolution of Microsoft Translator:

Today, we’re excited to announce that Microsoft Translator has added 12 new languages and dialects to the growing repertoire of Microsoft Azure Cognitive Services Translator, bringing us to a total of 103 languages!

The new languages, which are natively spoken by 84.6 million people, are Bashkir, Dhivehi, Georgian, Kyrgyz, Macedonian, Mongolian (Cyrillic), Mongolian (Traditional), Tatar, Tibetan, Turkmen, Uyghur, and Uzbek (Latin). With this release, the Translator service can translate text and documents to and from languages natively spoken by 5.66 billion people worldwide.

I’ve used the live translation service a few times. It’s a little clunky but it does work pretty well.

Leave a Comment

Scaling Limitations with Site Reliability Engineering

Tyler Treat argues that the Site Reliability Engineering paradigm doesn’t scale

:We encounter a lot of organizations talking about or attempting to implement SRE as part of our consulting at Real Kinetic. We’ve even discussed and debated ourselves, ad nauseam, how we can apply it at our own product company, Witful. There’s a brief, unassuming section in the SRE book tucked away towards the tail end of chapter 32, “The Evolving SRE Engagement Model.” Between the SLIs and SLOs, the error budgets, alerting, and strategies for handling change management, it’s probably one of the most overlooked parts of the book. It’s also, in my opinion, one of the most important.

Read on for an explanation of this chapter and how it applies to organizations trying to implement SRE.

Leave a Comment

Calculating Lead Time from Jira and GitHub

Maria Zakourdaev wants to measure agility:

Do you want to visualize your RnD team performance to drive business value? Is there anything that is slowing down your development pipeline? How agile is your team? How long are your customers waiting for the features?

There are many things that can hold you back. Backlog management, code review delays, resources provisioning, manual testing and deployment automation efficiency. In this article I will show you my method of measuring one of the metrics described in this book called LeadTime.

Read on to see how you can do this.

Leave a Comment

Up or Out: Promotion Paths

Bob Pusateri describes a common promotion path:

But one piece of career growth that I’ve never gotten from any employer is a promotion.

Allow me to define “promotion”. In my mind, a promotion is where an employee earns a change in job title with commensurate increase in responsibility. I won’t even say it has to include an increase in pay, though I imagine it often would. Similarly, a promotion need not involve moving into a management position. Simply put, to me a promotion is doing a great job as a junior widget maker and then one day being told your hard work and contributions have been noticed and you are no longer junior.

This is pretty common. As an example of the other side of the coin, I’ve been promoted (using Bob’s definition) at two separate companies. But in a lot of cases, hierarchies in engineering teams have nearly disappeared, such that there’s no longer a Software Developer 1 who can be promoted into a Software Developer 2, and then a 3 and a 4, and then an Enterprise Architect 1, etc. Instead, out is the new up.

The funny part of the pattern is that I know people who have left a company in order to move up. Then, after some time with the new company, they return to the old company in a higher role.

Comments closed

Rehearsing with PowerPoint Presenter Coach

Cathrine Wilhelmsen shares a tip for improving those presentation skills:

Did you know that PowerPoint can help you improve your presentation skills? 💡 If you rehearse with the PowerPoint Presenter Coach, you can get real-time feedback on things like your pace and language. If that’s too distracting (it is for me), you can choose to hide the real-time feedback and only view the detailed report at the end of your rehearsal.

The report shows you details about the total time spent, your pace and pitch over time, whether or not you are simply reading from your slides, as well as actionable feedback on your language. The feedback includes whether you are using too many filler words (like ummactually, or you know), whether you are using too many repetitive words with alternatives you can use instead, whether you are using any words that can be offensive, and specific sentences that you can refine.

Click through for more details.

Comments closed

Learn, Test, Forget

Erik Darling shows us the bright side of a memory equipped to forget:

I often have to talk clients down from odd ledges. At this point, there’s about 20 years of advice about SQL Server out there, and for various reasons received wisdom often gets migrated en masse, whether it’s still applicable or not.

Outdated trace flags and settings are pretty common, and don’t get me started on coding practices.

But I get it — that stuff came along with advice that still makes sense — like parallelism and memory settings, separating off tempdb, etc.

Unfortunately, it often leads people to the “it used to be fast so it should always be fast” trap based on what used to work, rather than what makes sense currently. Or even what the current problem is.

Read the whole thing. Also, in a rare double-quotation, I want to cite this line from Erik:

“I don’t know, xxVanWilderFan420xx said they were bad and we should avoid them.”

Never fully trust a person going by the pseudonym xxVanWilderFan420xx. However, if it were xxSolomonKaneFan420xx, 100% believe.

Comments closed

Explanation Anti-Patterns

Julia Evans catalogs things to avoid when providing explanations:

This list isn’t meant to make you feel bad about your writing. I’ve probably done all of these things! I’m certainly going to do them again! I even did at least one of them while writing this post!

But knowing that I’m likely to accidentally do these things makes it easier for me to avoid them, and it makes me more receptive to critique when people point out issues with my writing (“Julia, this is assuming a lot of knowledge that I don’t have!“).

Being aware of these patterns also helps me when reading a confusing explanation: “oh, I’m not confused by this explanation because I’m stupid, I’m confused because it’s introduced 6 new-to-me concepts and it hasn’t explained what any of them is yet!“.

Read on for the list and some excellent explanations of what to do and what to avoid when trying to explain things clearly to people.

Comments closed

Dealing with Insufficient Detail in Work Requests

Kenneth Fisher airs some grievances:

Many years ago I was given a work request that literally just said:

It’s broke. Fix it.

I’m sure you can see how that is supremely unhelpful. And this isn’t the only time I’ve gotten such great requests.

Kenneth has some great advice here when framing requests and I have just one more thing to add: err on the side of using nouns over pronouns, even when it feels repetitive. “I was in the XYZ service and when I clicked the button, it stopped working” is a mess of an error report because it could refer to the service, to the button, or to some third thing which you have in mind but never wrote down.

Comments closed

Journey before Destination and Disagreeing with Your Heroes

Mark Seemann reasons through a difficult problem:

Perhaps we’re really talking past each other. Perhaps we’re trying to solve different problems, and thereby arrive at different solutions.

I can only guess at the kinds of problems that my heroes think of when they prefer dynamic languages, and I don’t want to misrepresent them. What I can do, however, is outline the kind of problem that I typically have in mind.

I’ve spent much of my career trying to balance sustainability with correctness. I consider correctness as a prerequisite for all code. As Gerald Weinberg implies, if a program doesn’t have to work, anything goes. Thus, sustainability is a major focus for me: how do we develop software that can sustain our organisation now and in the future? How do we structure and organise code so that future change is possible?

Reading Mark’s essay makes me want to break out my copy of Tractatus Logico-Philosophicus but let’s not go crazy here… This is a good reminder, however, that incentives (implicit as well as explicit), experiences, and a host of other factors which make it really difficult to say conclusively “X is a better solution than Y” without laying out the specific premises.

Comments closed