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.
You might want to check out some of the criticism advanced by people such as Tristan Harris on the tension between the user behaviors that tech companies optimize their product design, and the goals users hope to accomplish through their use. I do in some ways support Nir in that we should learn how to harness these types of technologies for our own good, to 'supercharge' our ability to accomplish what we want, but I do not trust any company dependent on ad-revenue (or backed by Wall Street in general) to help with that.
I'd also recommend checking out The Attention Merchants by Tim Wu and Addiction by Design by Natasha Schull for background on the history of the commodification of attention and of the
"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."
It's really noticeable that Hacker News provides exactly this feature, and absolutely no other site that I've seen does.
For years I resorted to hacking /etc/hosts to block HN. Mentally, I just assumed that no website would have such settings so I never bothered to learn what noprocrast meant.
The idea of a hard block on tech is intuitive, but it doesn't do anything to undermine the habitual learning in tech addiction; it just frustrates it for a fixed amount of time.
Space focuses on slowly undermining the compulsions behind tech addiction. So that, over time, you don't have the impulse to open the app anymore.
I tried to work out how Space worked on iOS, before I downloaded it. Unfortunately, I don’t see anything in the app’s description or website that stops me from launching the Facebook app the over Space app.
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.
Uber as far as I'm concerned isn't really a tech company - its a logistics company existing under tech company rules - in essence its a freight broker for human 'freight' - how it connects with its customers is irrelevant to what kind of company it is. In short, you're providing short term contracts between a consignor (the passenger) to transport an object (the passenger) between two known end points, by an independent contractor. Uber provides the infrastructure to make this happen, and takes a cut of the revenue from the shipment.
If you wouldn't call JB Hunt a tech company, you shouldn't call Uber one.
(The research into autonomous cars is not really central to their current core business model - and assuming the technology is successfully developed - their entire business model would change - they'd also need a massive capitalization to purchase a fleet of self driving cars when it does.)
"how it connects with its customers is irrelevant to what kind of company it is"
This is a pretty bold claim. The fact that it's instant, and that it geolocalize every party involved thanks to a mobile app, and that every part of the process is fully automated is what makes uber something different from a regular cab company.
To reduce uber to its high level functions abstracting away the technical details and implementation is i think one of the big mistakes business people make in general. I wouldn't be surprised if this kind of reasoning is what business CEO show in their slides before they take the decisions that completely screw the tech companies they're leading.
Twenty years ago an astute and entrepreneurial young man named John took over his father's taxi company, Orange Cab based in San Diego. Exploring ways to reach potential customers, he found that all the cab companies in town were marketing their services through the same traditional mediums - newspaper ads, Yellowbook listings, billboards, etc. Not sure what else he could do, he remembered he still had 4 free hours of America Online credit, and decide to see if the internet had any advice. Then it struck him... Maybe my competitors have websites that I could browse for hints on how they advertise. The search came up empty. Damn he muttered, "none of them have websites", to which his wife Jane (expertly lurking from the nearby davenport desk) quips, "well neither do you, so maybe you should get a website". I have a brilliant idea, he thinks while slightly tilting his monitor away from Jane, maybe I should get a website. He types into the Lycos search bar "how. to. make. a. website." enter, "You know in that technology class I took last semester they taught us how to make a webpage using HTML", pipes Jane; then she smiles and taps John on the shoulder "move over".
After building the website they noticed things starting to pick-up a bit, and in a short few years they were beginning to see real growth; recently their was a nice spike in their marketshare after implementing an online form to request rides directly from their homepage. Younger crowds in particular preferred to request rides over speaking with someone on the telephone.
Fast-Forward ~10 years...
Orange Cab is not so little anymore. They now manage fleets in 14 metropolitan areas and recently incorporated so they could merge with Yellow Cab, making them the biggest cab company in the US. A few days after the merger, Jane (formerly Orange Cab's head of operations) had a meeting with Yellow Cab CEO to see how her role would change after the merger. She came into the meeting excited with ideas about how to innovate to reach new customers (particularly since the new operating budget was 10x the pre-merger budget). She started by sharing an idea where the whole point-to-point experience, from cab request to fair payment is managed entirely by a little software applications on someone's mobile phone. Jane, Jane, Jane, ahhh silly Jane, we are not a tech company. Yes, the website has been really helpful, but don't those smartphone things have a web browser? We are the biggest taxi company in the US, and we have a veteran management team, what's the worst that could happen!
Uber is aggressively pursuing self-driving cars as we can observe from their massive investments to acquire Otto and other AI startups, and to set up labs filled with experienced robotics and AI researchers in the US and Canada.
Once autonomous vehicles become practical, it is almost imperative for Uber to own the critical technology to be competitive in their current businesses.
Uber can't ever own the critical technology in autonomous. They are late to the party, critical patents have been filed. Autonomous technology will be freely available when it's commercially feasible, Uber can buy some then. In the meantime it has to avoid blowing through the remainder of it's capital and stay alive.
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.
Tell me about it. Fortunately where I work is sane and reasonable about it.
We have a password sheet. You have to be on the VPN(login/password). Then you can log in. Login/Password(diff from above)/2nd password+OTP. Then a password sheet password.
I'm still rooting out passwords from our repo with goobers putting creds in sourcecode (yeah, not config files....grrrrr). But I attack them as I find them. Ive only found 1 root password for a DB in there... and thankfully changed!
A plaintext password sheet? Despite the layers of network access control, this is a horribly bad practice in our modern age. Vault is free and encrypted secret storage systems are hardly a new concept.
Not at all. The password sheet password is actually a GPG key. Everything stored encrypted.
We suffer from NIH greatly. We end rolling our own stuff because either we don't trust 3rd party stuff, or it doesn't work in our infrastructure. In this case, multiple access locks with GPG is sufficient.
A response 8 days later is better than no response at all, right? :)
I agree that a multi-recipient GPG protected file is sufficient for a small org. In fact, that's how I used to do it Circa 2011. We found it worked quite well - we committed the GPG protected files to a version control system (git) and used githooks to make sure that only encrypted files were permitted, preventing users from intentionally/accidentally defeating gitignore.
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.
This is a really interesting project. I just signed up to get notified of launch (andrew @ indentlabs.com) but if you want to shoot me an email with what you're working on and where you're at, perhaps I could help out or give you some feedback on the idea/implementation.
Either way, always good to have more eyes occasionally. :)
This is super awesome! I soo need this. Drafting with a structure is a part I often skip when trying to write something, which is why writing has become quite hard. I should stop doing it. But your idea is great, looking forward to seeing it in action!
Cool. I need a conversational AI to help me make good decisions about my to do list.
Orgbot: I'm sorry Dave, you won't have the energy for 3 meetings and a Meetup on Monday. Let's spread the meetings throughout the week and find something you can do in your pajamas while hung-over.
I also find this fascinating. I just signed up..ryan@recraigslist.com I also have another use case I'd like to bounce off you if you could shoot me an email. Thanks!
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.
Looks very interesting. I guess I might be fighting a loosing battle here - but any plans for an offline solution? This is the kind of thing that I'd probably love to use on the train (many tunnels, no 4g/spotty in-train wireless) - and on flights (wifi is comming, but not always) -- or other places without good network coverage (composing a blog post on a hike..).
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.
A self-contained binary would work fine for me (If it could run on a Surface Pro 4 - or as a VM image - eg. hyper-v and/or virtual box).
I always prefer a Free software/open source solution - but I'm not sure how you'd monetize that. Maybe charge for the app (ios/android) - and provide a free/open self-host server solution, along with a subscription service and a web client? (The payment for the app would also grant access to the subscription, and for those that didn't want to self-host/wanted to support the project could pay for the subscription and use the web SaaS solution?).
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.
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.
> something else that offers native bindings to other languages will eventually...
No it won't.
This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript.
Let's be realistic; who has the man power, community good will and business savvy to push an entirely new language across all platforms, mobile and desktop?
Microsoft? Come on. Apple? Google? Google tried with dart and failed.
Who else, seriously, is going to step up?
We can day dream about the magical 'no js' world, but it's never going to happen if web assembly doesn't work.
Currently we're seeing the reverse, js stretched off the browser, onto the server, into mobiles, onto iot devices.
You've got to layout some pretty damn fine arguments about why that trend is going to suddenly reverse.
Web assembly is pretty much our last best chance to flip javascript off and have something better...but it might already be too late for that to work. :/
> This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript.
Do people really hate JavaScript that much? I've grown fond of it in recent years, especially after ES6.
I really do hate javascript that much. It was somewhat acceptable when it was confined to the browser for simple scripting. But the more complicated the application and the more it moves out of the browser the more it's flaws get magnified.
Yes. People really hate JavaScript that much. ES6 brought some sanity to the language, but I continue to be firmly in the camp of continuing to hate and despise its existence.
Weird. I remember hating it ages ago. So much so that I was developing a Python->JavaScript transpiler (before all the cool kids were writing transpilers!) and blogging about how bad it was [1].
Granted, that was back in 2008 and most of my complaints have been addressed now almost a decade later (except for destructors, it still doesn't have those, but I also don't need them anymore).
These days I move between JavaScript, Python, Go, and C seamlessly and I can honestly say that I don't hate any of them as much as clients, managers, and 3rd party code.
People have definitely had and continue to have successful careers in, and many actually enjoy, JS.
I would never debate that. I think language choice for many people is a personal decision. There are some that I will hold my nose and use; not even complain too much. There are others that the minute there is an alternative to, I would use that instead. JS is in the latter camp for me.
If it helps, my current favorite language is Rust... they may be syntactically similar, but I just can't stand the semantics, or lack there of, of JS.
Yes. People really hate C that much. C++ brought some sanity to the language, but I continue to be firmly in the camp of continuing to hate and despise its existence.
Electron is awesome. And with webassembly, I think electron will be even better. Electrons success is because it offers a single Dev experience across all major platforms, windows, macOS, Linux and the web.
It's a great container for reducing the work to deliver code across platforms.
JavaScript is a necessary evil right now; it's the least common denominator for delivery. I would probably choose typescript if I were starting a new app right now to target it, though I want to play with Rust and webassembly soon.
It's success is not bc of JavaScript; it's because it merges the cross platform Dev experience.
I don't hate JS but would rather write my web codebase in something else, something that has a standard lib for instance. ES6 is also a transpile to JS language on the browser. The main problem is that we are stuck with ancient JS on the browser and WASM could fix that. Wouldn't you rather conpile ES6 to WASM instead of JS?
browsers that support WASM will support ES6 natively. compiling ES6 to WASM would not be a good idea, since you would have to send a garbage collector and full dynamic language runtime down the pipe instead of just using the one in the browser.
wouldn't you rather just run ES6 right in the browser instead of compiling it first at all?
If all major browsers support 100% of the spec and every implementation is bug to bug compatible with the others, yes, I would rather run ES6 directly in the browser. The problem is fragmentation and not supporting the whole spec -- some functions working in Firefox and Chrome and not implemented in IE/Edge or Safari.
For example, on the type of projects I work on, all tooling is certified by customers IT and anything extra requires change request, that might get approved, or not.
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.
Is TypeScript as annoying a language to code in as Javascript? Or is it comparable to other modern languages like Swift and Go? If it is, I'd say that pain of dealing with Javascript (for developer productivity and happiness) is already taken care of.
Typescript is a type safe language that "compiles" into javascript. The Microsoft implementation compiles on save, so you work in your file.ts and a program running somewhere fires when the file is saved and converts it to file.js which you would distribute.
I haven't used it yet, but the demo from Anders looked good. It's an attempt to fix the "loosey goosey" nature of javascript. I would be great if browsers supported it as a built in language.
> If you watch the video, you'll notice the argument notation is name: type rather than type name. I think Anders is reminiscing about his Delphi days.
ActionScript and the proposed ECMAScript 4 also use the name:type notation, so there is definitely some prior art in the web sphere
Thats not really what he asked though. If in the end a developer can work 98% in TS, do they really care if it runs as JS or something else if it solves their problems with the language ?
I have heard from people that love TS, but surprisingly many that also prefer pure ES6 JS.
You should think of typescript as javascript+ more than a different language. It looks more like what javascript would look like in 2-3 version if the governing body thought static types were important to add.
TypeScript is a joy to program in. I was on a project where we had the opportunity to turn on all the strict checks (no use of any, no implicit nulls, etc.), and it was super enjoyable and efficient to program in.
You have algebraic types (well, 99%), union types, and concise ways of expressing tree types.
I would imagine it is more pleasant than Swift or Go, though I haven't used either of those very much.
The question was whether the concern of JS being frustrating is already solved by TypeScript, in which case WebAssembly is less important than it would be otherwise.
(Which isn't to say that there aren't other questions like efficiency and already-existing codebases written in other languages.)
Java failed to be what JavaScript became for a number of reasons, but I think the primary was the fact that it never integrated with HTML as cleanly as JS.
It could have been JS, but it was strangled to death by Sun (on the client).
Java also has the problem of long startup times while the JIT is doing its thing. Javascript has always just started executing right away. Waiting a minute or two for a Java loading bar wasn't fun.
JavaScript hasn't always worked that way. My guess is that if Java had become the tool for this, then it's startup times would have been fixed. Pure speculation of course.
If Sun had not killed Hotjava and continued to develop and market it, Java instead of JS might have been the frontend web programming language today. There were millions of Java applets written in a very short time and a Java browser would have been a first class citizen for hosting those apps.
Not the intention, but I see that interpretation. It's not hard to imagine oracle making a netbeans plugin for free and an expensive enterprise version that's faster. Selling point is leveraging existing back end skills.
> If wasm doesn't overtake JS, something else that offers native bindings to other languages will eventually
When I read this I realised that WASM might just pave the way for something more fundamental: browser runtime stdlib.
One of the big issues, even highlighted in this very thread, is that people are wary of forcing 10MB+ blob downloads on their users. What would the effect be if browser provided a proper stdlib?
What was the last time you wrote something that was 10MB after compiled to native code when optimizing for space?
Linux + BusyBox is less than 2MB (I've fitted it in floppies not too long ago) if you don't include the drivers for everything. I've created a 10MB binary set that implements an entire email server, with everything statically linked, and in Haskell (that leads to inherently big binaries).
Yes, I still remember the days when we could have core Linux experience on one 1.44MB floppy disk. This keeps reminding me how bloated most modern software are.
no, WASM will not replace JS unless somehow, overnight, the idea of downloading 30mb of compiled runtime libraries to read an inaccessible-to-screenreaders news article becomes appealing.
but i wouldn't hold my breath for 1990's style java applet loading throbbers to come back into fashion. there's a reason that stuff got outcompeted by the supposedly "inferior" javascript.
what wasm competes with is flash games, insecure java applets, and npapi and nativeclient in general.
JS isn't required to display a news article, and never has been. You can make a fast, beautiful and modern news site using only HTML and CSS, without a byte of JS.
Take a look at the source for any molasses-slow news site. The only site-specific JS will be jQuery, and a few basic event handlers to do things like show and hide elements, which could have been done with CSS.
99.9% of the JS will be advertising, analytics, and tracking. People understand that these sites are tracking them, but I think most people have not idea just how much tracking is going on. Major news sites have hundreds of tracking libraries loaded per-page. That is the only reason they are slow.
You're probably access web sites sitting at home or office, where you have decent 10+ Mbps channel. All this changes when you travel and you use either slow public WiFi or phone tethering. Yes, there's 4G, but in most places in most countries 4G coverage is very poor: it's only in the most populated areas.
I travel between countries and of course I hate staying in huge cities because they're expensive and noisy. But when you move to smaller towns, there're usually limited options for connecting to the Internet.
Last year in India I spent 2.5 hours incessantly trying to open my bank website to make an urgent payment. All these huge React/Redux bundles were loading for ages, and they aren't cached and there's no support for resuming download after it dies because of some timeout or because you were looking at the spinner for 30 minutes and decided to click reload button.
And even when these huge SPA load, they're totally broken on slow connections. People become lazy and they don't handle timeouts and responses coming in weird order because of the slow channel. Even if you manage to open SPA on slow connection, it's a pain to use, almost impossible with all these XMLHttpRequests on every click transferring megabytes of data after every click or typing any letter. :(
Well, I'm talking about "state of the art" apps. You can always fallback to server-side rendering/pure html if the connection is too slow and you can't afford the boostrap/init download. Depending on your use case SPA may actually be an improvement as the static resources can be cached. WASM is supposed to compete with native apps. Why don't you complain about MBs to download on native apps?
that's peasant level net :P. 100 or bust {literally what I have home and better at work). seriously though, indeed the web is overbloated and I don't think there is coming back
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.
Ah, the infamous "random shutdown" of the Nexus 4. It has caused me to be 30 minutes late at work a few times that one.
It's annoying really because in the end, there is absolutely NO accountability from either LG or Google that the battery won't work as expected after about two years. Thing is, the price range of the Nexus 4 doesn't exist in the Google mobile lineup anymore, with the Nexus 5 being about twice as expensive. So ultimately, I'll either have to stop buying Nexus phones or spend $400 on a Nexus 5.
I was using an N4 for over two years... I had the random shutdown/reboot issues as well. When Google nix'd their value lines last year when I was ready for a new phone, I waited a while, and finally bought an NVidia Shield 8" tablet, and a OnePlus One phone. Probably the closest things to heir apparent to the N4/N7 devices.
I have friends who have been happy with Moto G and Blu Studio phones on the lower end.
Yeah it's so frustrating that what I consider the prime price range for mid-range but well built phones existed for awhile, but has since ceased to. Between that and Google Fi sounding great but only being supported by one of these expensive and unwieldy mini-tablets, I guess I'm just outside Google's target market.
Yeah it's so frustrating that what I consider the prime price range for mid-range but well built phones existed for awhile, but has since ceased to.
Did it? You can pick up a 2014 Moto X for $299. You even get to customize it to your own taste. This phone has nice specs and near-vanilla Android. (Love my Moto X 2014 with cognac leather back :). Though, I bought it when is was still 200 above the current price.)
I hear that the Asus Zenfone 2 is also pretty ok. In Europe it's a little more than 300 Euro for the variant with 4GB RAM and 32 GB storage (there are some cheaper variants as well).
Same here. I actually thought I had damaged the backcover clips when disassembling to retrieve a wayward nanosim to microsim adapter. Didn't realize it was the bulging battery until the random reboots finally forced me to buy a battery on the aftermarket.
The one downside I've noticed is that even with my "OEM" replacement battery (who really knows with these things), charging a lowish battery via a high amperage USB still takes significantly (multiples) longer than my iPhone 5 or 6.
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.
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