With the ubiquity of mobile devices like smartphones, two new widely used methods have emerged: miniature touch screen keyboards and speech-based dictation. It is currently unknown how these two modern methods compare. We therefore evaluated the text entry performance of both methods in English and in Mandarin Chinese on a mobile smartphone. In the speech input case, our speech recognition system gave an initial transcription, and then recognition errors could be corrected using either speech again or the smartphone keyboard.
We found that with speech recognition, the English input rate was 3.0x faster, and the Mandarin Chinese input rate 2.8x faster, than a state-of-the-art miniature smartphone keyboard. Further, with speech, the English error rate was 20.4% lower, and Mandarin error rate 63.4% lower, than the keyboard. Our experiment was carried out using Baidu’s Deep Speech 2, a deep learning-based speech recognition system, and the built-in Qwerty or Pinyin (Mandarin) Apple iOS keyboards. These results show that a significant shift from typing to speech might be imminent and impactful. Further research to develop effective speech interfaces is warranted.
This study was conducted by researchers from Stanford University, University of Washington, and Baidu.
I’m co-founder and CTO at Overleaf, a successful SaaS startup based in London. From August 2014 to December 2015, I manually tracked all of my work time, minute-by-minute, and analysed the data in R.
Like most people who track their time, my goal was to improve my productivity. It gave me data to answer questions about whether I was spending too much or too little time on particular activities, for example user support or client projects. The data showed that my intuition on these questions was often wrong.
There were also some less tangible benefits. It was reassuring on a Friday to have an answer to that usually rhetorical question, “where did this week go?” I feel like it also reduced context switching: if I stopped what I was doing to answer an chat message or email, I had to take the time to record it in my time tracker. I think this added friction was a win for overall productivity, perhaps paradoxically.
This post documents the (simple) system I built to record my time, how I analysed the data, and the results. The main things I learned were:
I tracked a bit over 50 hours of actual work per week on average. I am more skeptical of the fabled 130 hour work week.
My management time increased by 230% as the development team grew by 200% (2 to 6), but interestingly my time in meetings decreased by 70%.
My development time stayed pretty much the same, but that was mainly because it shifted from the workweek to the weekend.
I’ve been working, for more than a decade, in an environment dominated by people with a background in math or physics who often have sparse knowledge of “software engineering”.
Invariably, the biggest messes are made by the minority of people who do define themselves as programmers. I will confess to having made at least a couple of large messes myself that are still not cleaned up. There were also a couple of other big messes where the code luckily went down the drain, meaning that the damage to my employer was limited to the money wasted on my own salary, without negative impact on the productivity of others.
I claim to have repented, mostly. I try rather hard to keep things boringly simple and I don’t think I’ve done, in the last 5-6 years, something that causes a lot of people to look at me funny having spent the better part of the day dealing with the products of my misguided cleverness.
And I know a few programmers who have explicitly not repented. And people look at them funny and they think they’re right and it’s everyone else who is crazy.
In the meanwhile, people who “aren’t” programmers but are more of a mathematician, physicist, algorithm developer, scientist, you name it commit sins mostly of the following kinds:
Bad names (m, k, longWindedNameThatYouCantReallyReadBTWProgrammersDoThatALotToo)
Access all over the place – globals/singletons, “god objects” etc.
Crashes (null pointers, bounds errors), largely mitigated by valgrind/massive testing
Complete lack of interest in parallelism bugs (almost fully mitigated by tools)
Insufficient reluctance to use libraries written by clever programmers, with overloaded operators and templates and stuff
Do you write programs in Python? You should be using attrs.
Why, you ask? Don’t ask. Just use it.
Okay, fine. Let me back up.
I love Python; it’s been my primary programming language for 10+ years and despite a number of interestingdevelopments in the interim I have no plans to switch to anything else.
But Python is not without its problems. In some cases it encourages you to do the wrong thing. Particularly, there is a deeply unfortunate proliferation of class inheritance and the God-object anti-pattern in many libraries.
One cause for this might be that Python is a highly accessible language, so less experienced programmers make mistakes that they then have to live with forever.
But I think that perhaps a more significant reason is the fact that Python sometimes punishes you for trying to do the right thing.
The “right thing” in the context of object design is to make lots of small, self-contained classes that do one thing and do it well. For example, if you notice your object is starting to accrue a lot of private methods, perhaps you should be making those “public”1 methods of a private attribute. But if it’s tedious to do that, you probably won’t bother.
Why Python is awesome and you should at least give it a try.
My first encounter with Python was a part of the introductory course to programming. Well, I actually played with it on my own before, so I already was familiar with its syntax when the course began, but I didn’t do any real project in it before that course. Even though I thought it’s a great language to introduce people to programming, I wasn’t a big fan of it. It’s not that I disliked the language, it was more of a “meh” attitude. The reason was simple: there was “too much magic”. Coming from a background of languages such as C an Java, which are a lot more explicit in terms of what’s going on under the hood, Python was the complete opposite of that.
Another issue was that Python seemed a lot less structured: writing large, complex programs seemed to be a tougher task to achieve than, for example in Java, where you have some strict rules when it comes to the structure of the program (for instance the one public class per file rule), Python on the other hand, gives you a lot more freedom in such things.
Another thing is strict typing and debugging: since Python is an interpreted language, finding bugs wasn’t as easy: if you have a syntax error in C, the program will simply not compile, on the other hand, in interpreted languages, the problem might go unnoticed for quite some time, until the execution reaches that particular line of code. Trying to pass a string where an integer is expected? cc will go crazy at you, while Python’s interpreter won’t mind at all (there are some tool that address that problem though, like mypy, but I’m talking about vanilla Python). What I just mentioned here is a general downside of interpreted languages and are not exclusive or particular to Python, but those were some of the main reasons of my initial attitude towards it.