My knee-jerk reaction to the book Hooked (which I've somewhat shamefully avoided reading out of a sort of premeditated disgust) was based on the general arguments laid out in this blog post.
I believe the tech world has a huge problem on its hands here, and that problem doesn't get anywhere near the attention it deserves. Large swaths of the population are turning into zombies and tech is the facilitator. Try looking at the drivers turning through a busy intersection some time. It's obscene how many are staring down at their phones rather than at whatever might be in the road around the corner.
That said, I don't believe the problem is simply that certain products remind or encourage people to use them at times. Rather, it's that there is a class of truly addictive products that don't do much (if anything) to help people manage the resulting dependency. And that approach is celebrated far more than it's scrutinized.
Coincidentally, I wrote the following on Twitter yesterday:
"Any potentially addictive software/service should offer a way for users to lock themselves out of their own account for a predetermined set of hours." [0]
It was meant in my usual tongue-in-cheek style, but I do think that a solution for breaking tech product dependency is sorely needed and hope this discussion gains some steam.
I really don't believe this is true for tech companies at all.
A decade ago, I had a front-row seat for Yahoo! under the stewardship of CEOs brought in to run the business well. The focus was not on innovation, and the company continued to languish. Why? Because tech companies that don't innovate get their lunches eaten by the ones that do.
As for Buffett, I'm no expert on his portfolio, but I believe his track record was built on non-tech companies until very recently.
There's also a high chance that document was shared on Slack. In which case, they were one Slack breach away from the entire world having write access to their prod database.
It's depressing how many companies blindly throw unencrypted credentials around like this.
The plan is to offer a subscription service even if there's an offline component. For a bunch of reasons, it's the best approach for a one-person venture trying to get off the ground.
I've been an OSS user and supporter for a long time. I don't think I'll be open sourcing the core system anytime soon, but I'm very likely to release any useful NLP or ML-related libraries that are created as part of this project. Not sure what those will be or when they'll be ready, but I do have a mind to give back to the OSS community.
Yeah, I understand, it's a completely valid use case. I'm personally much more productive when I'm completely disconnected, so I really identify with the request.
I had, in the past, also been thinking a bit about how the system could work offline because it would avoid a lot of security issues for something like a medical office that wants to create content that's then copied into a medical records system.
My initial thought was to bundle a local copy of the server with pre-trained models, but that becomes problematic on mobile clients. I'm writing the server in Go, so if I go that route I'd probably need to reimplement parts of it in another language and avoid using any remote APIs.
So the answer is: very likely yes, but not initially. You've definitely moved the functionality up my planned features list.
My initial target is short-form content such as blog posts and essays. I'm going to wait to see how that goes to decide what to focus on next, but odds are that it'll be more structured content like academic papers or technical reports.
I'm definitely not ruling out an eventual focus on creative writing, but it'll take a bit for the system to get to that stage.
That said, I'm designing it with the ability to ingest annotated writing samples of any sort, so it's possible that a wider range of writing types will be supported sooner than expected.
Problem: The process of getting thoughts from your head into an organized, written draft form isn't as fast or accessible as it could be.
Project: I'm building a conversational UI / bot (https://writing.ai) that helps people write faster. The basic idea is that it asks you a series of questions about a topic, asks follow-up questions for more detail as needed, and when it's done outputs a completed draft. You're still providing the content, but the system understands the structure of completed documents and knows what questions to ask to get the actual writing done more easily.
I just quit my job and started working on this full time last week, so no public version yet, but signups are very welcome.
I don't quite agree with the all-or-nothing assessment, but your passion is exactly why this will happen.
Too many of the silent developer masses (probably mostly back-end engineers) have and continue to feel this way about being stuck with JS. The genie's out of the bottle, it's not going back in.
I agree completely, but I would take it a step further:
If wasm doesn't overtake JS, something else that offers native bindings to other languages will eventually. There are huge benefits to be had for teams that want to be able to code their full stack in a language that isn't JS.
We never asked for JavaScript (well the vast majority of us), but we've been stuck with it for the past two decades for all things web. Now that a doorway to replacing it with a general-purpose solution has been cracked, I expect the industry to kick it wide open as soon as possible. Not because JS is bad per se (it has certainly gotten much better), but because a lot of developers would simply prefer to use something else.
There are two sides to this: usability and revenue.
On the usability side, there's lots of room for improvement in terms of fostering meaningful discussion, which in turn would lead to stronger social ties between users. Addressing that issue would probably have to start with an effort to improve discoverability of accounts that engage thoughtfully with other users. So people who reply to tweets that earn hearts might show up in suggestions more often, etc.
I'd also work to discourage endless ICYMI repostings of big multimedia tweets and go back to a chronological timeline. If there's too much noise in a chronological timeline, that means too much clickbait/link spam is being posted, and that's the real issue.
From a revenue perspective, there are a bunch of options worth looking at: a Patreon model to encourage people with great insight to tweet more; more accessible paid analytics, baked right into the app that could help non-business users improve the quality of what they send out; an in-app store for subscribing to third-party add-ons.
Basically, at some point it's worth realizing that plenty of mobile users will spend some money for an improved experience. The constant focus on ad-based revenue makes money, but ultimately incentivizes the company to do things that make the overall product experience worse.
Something small I wish I'd known when I started doing Android development - if you need to display images, use an image loading library (Picasso or Glide). It'll save you from dealing with a lot of quirks, some vendor specific.
I just replaced the battery in my Nexus 5 due to earlier stages of the same issue. The battery failure was causing a lot of random device shutdowns that I had initially thought were related to the rollout of Lollipop.
Several of the posters there noticed that their battery had started bulging, ordered a new one, and reported that their devices were back to normal. Same issue and fix for my device.
This issue is definitely concerning, and I'm a bit surprised that more hasn't been made of it by now. It seems to be a fairly widespread problem.
ArmorText | Washington, D.C. Area (Tysons Corner, VA) | Full Time
ArmorText is helping organizations replace existing communication tools with a modern, secure alternative that puts them in control of their own data. We're passionate about great design, strong security, and making products that our users love.
We're currently looking to add 2-3 members to our 8-person team in the Washington, D.C. area:
* Front-End Engineer - Interested in developers with solid iOS, Android, or JS (Node.js, Angular) experience. All three are not required, but we do need someone capable of serving as a product lead in one or more of the listed areas long term.
* Back-End Engineer - We have an immediate need for a back-end engineer with experience designing and implementing large systems for scale. We're currently running on Java/Spring with MongoDB as a backend. Experience with AWS, RabbitMQ, WebSockets, and Docker are all a plus.
* DevOps Engineer - Looking to hire a DevOps engineer to help us mature all aspects of our current back-end infrastructure. Strong security, Linux, and AWS experience are a must. Experience with Java, Ruby, Node.js, Nginx, Docker, Chef, Jenkins, MongoDB, RabbitMQ, and Atlassian Tools are all desired.
I believe the tech world has a huge problem on its hands here, and that problem doesn't get anywhere near the attention it deserves. Large swaths of the population are turning into zombies and tech is the facilitator. Try looking at the drivers turning through a busy intersection some time. It's obscene how many are staring down at their phones rather than at whatever might be in the road around the corner.
That said, I don't believe the problem is simply that certain products remind or encourage people to use them at times. Rather, it's that there is a class of truly addictive products that don't do much (if anything) to help people manage the resulting dependency. And that approach is celebrated far more than it's scrutinized.
Coincidentally, I wrote the following on Twitter yesterday:
"Any potentially addictive software/service should offer a way for users to lock themselves out of their own account for a predetermined set of hours." [0]
It was meant in my usual tongue-in-cheek style, but I do think that a solution for breaking tech product dependency is sorely needed and hope this discussion gains some steam.
[0] https://twitter.com/ncantelmo/status/930876372620374017