Ugh, regardless of what we say we wish to do on this post, what I'm sure many of us lack is external motivation to do it. One app to help solve that is called Spar, developed by a friend of a friend (https://itunes.apple.com/us/app/spar!-get-better-at-stuff/id...). You set a goal with your friends, e.g. read a chapter every day, and put 20$ or so in the "pot". Whoever does the best at meeting the goal, gets the pot, and if you slack on your goal you lose the money.
When the incentive to finish a goal shifts from the innate satisfaction of completion to a fear of financial penalty, is it possible that the goal itself will unintentionally change in subtle ways?
its called the Token Economy Problem. tl:dr; using tokens as an external motivation mechanism transfers away from buidling internal motivation. (e.g.,$5 for each book a kid reads gets a kid to read books for $5 bills and not for love of reading/imagination/thinking. $5 tokens run out? Kid stops reading.)
Right, I was just about to reply with a similar response to another post. I went to Virginia Tech, lived in Northern VA for a while, and now I'm here in SF and it's like night and day. I did not believe that being here would be such a huge and significant difference, and yet it is. Influential and successful people in tech are so incredibly accessible here. After only a couple months I got to meet VCs, startup founders, CEOs of successful companies, other highly intelligent people in tech doing amazing things and so on. Most importantly, at least for me, there's a constant external motivation to push yourself, learn, collaborate, get involved, to do more, and I love it :D
Fellow ex-Virginian and I have to agree. Many of the entrepreneurs in the DMV seem like they're doing a startup because doing a startup is cool, but don't have any idea on how to actually build a business. Maybe one day I'll come back, but it's even hard to find skilled people who want to work at a startup out there -- perhaps because they've experienced what I'm talking about also.
In 2012ish as a freshman intern at Microsoft, I asked Will Kennedy (then CVP in Office) how did he feel about people pirating Office apps. He said that they would rather permit people to use illegal versions of Office than have them use their competitor's tools. Essentially he was saying Microsoft would rather people use their products free of charge rather than using other products as it promotes Microsoft image and helps Microsoft dominate the workspace. Promoting VSCode vs Visual studio are not competing efforts - the two tools are solving different problems in different work environments / tech stacks. They're simply trying to branch out to permeate more of the workplace, and it's working. Now that I'm in a startup in SF, I look around and I see some people switching from Sublime to VSCode for our web/backend stack, who would never ever use Visual Studio (100% macs here).
I have used Atom for about one year and then went back to Sublime. I do mostly back-end web development, in various languages.
I believe Sublime is a superior product in terms of performance and stability.
Reasons for switching back:
1 - Atom has some long-standing bugs that compromise its usability (e.g. there is a bug where you basically can't scale down a window after it was maximised: https://github.com/atom/atom/issues/10720 )
2 - Atom is slower, you may think a fraction of a second when opening a file or doing a search should not make much of a difference but, when you are using an editor every day for many hours, it ends up affecting your productivity.
PS I liked VS Code but it's different enough from the other 2 editors that it would take time for me to become proficient with it. I especially liked VS Code's debugging features.
Yup, Sublime Text rules. I still use 2.0.1 at work (on a Mac) mainly for Perl and JavaScript. It always works, it's fast, doesn't ever crash. I didn't like VSCode that much (mainly have a problem with the toolbar on the right and don't want to learn new key bindings/menus etc). Also I don't use debuggers that much, so it's a useless addition to VSCode for me. Atom is a lot like Sublime in terms of usage, but it's painfully slow. It is getting a bit better with every new iteration though. I'm using Atom at home for learning new stuff, as Sublime's widgets are fairly different from the general UI in Linux (looks like an editor from outer space) and Atom tends to integrate somewhat better.
No, but if it's not open source and multi-platform (at least Linux and Mac) then I see no reason to switch. That's why I probably ignored it, in fact; also why I keep checking Atom out.
Not op, but I definitely preferred sublime to atom. I have since swapped entirely over to vscode, though, and I have been using it to write / compile / debug Node.js and c# / f# dotnetcore backend applications without many complaints.
I went back to sublime as I had too many stability issues with Atom. You can throw megs of data at Sublime (if needed) and it absorbs it, Atom grinds to a painful death.
> VSCode vs Visual studio are not competing efforts
Yet. Little by little, rather than invest in windows-only vstudio, they'll enhance code until it's building all the same stuff as studio and then they'll announce how amazing code is and stop talking about studio alltogether.
When MS ghosts a product, you know what its future is.
Yeah ultimately what all this is trying to achieve is to make JavaScript have the basic properties and benefits of many other languages. Unlike other languages, JavaScript was developed in 10 days in 1995 and was never intended to be used as heavily as it is today, hence the gargantuan amount of packages and modules to rectify it's shortcomings.
I don't know the proportion, but coincidentally enough, I work at a startup that uses Stripe and we used to support bitcoin transactions (and thus refunds). I just asked a friend who's been here longer why we're not supporting bitcoins anymore and his response was "exchange rates were a huge pain" haha so yeah it is indeed convoluted to do refunds with bitcoins, but if we are to attempt to use them as regular currency for goods and services, we can't not support refunds. so we dropped bitcoin support altogether.
Was that bitcoin support manual, or through stripe? I would never want to deal with bitcoin payments manually due to the exchange rate issue; but taking them through stripe works wonderfully.
Hmm digging through our old code looks like we never tried to use Stripe, for reasons unknown to me (maybe their support/requirements were different back then, maybe it didn't work for our product, idk). But yeah, especially after reading this article, handling bitcoin payments and dealing with the exchange rate sounds unfavorable lol :) glad we're not doing that.
That's my point - with stripe, you don't have to deal with the exchange rate. You say "I want $X" and magic happens. Stripe takes care of the messy details of fluctuating exchange rates.
So that's not entirely true depending on how you use the product. We were attempting to use Stripe for a contract-like setup, e.g. person A pays person B, but person B doesn't get paid until some event occurs, and we hold on to the funds until that happens since that expiration of that event isn't guaranteed to be under 10 min.
Hahahaha as someone who recently made the switch from corporate/tech-giant world to the startup world in the bay area, I can really relate to this article.
Why would you rewrite already-working services written in an expressive and battle-tested language to a fad 1970s-style language?
It's like being in the late 90s and replacing your existing infrastructure with Java hype, except with a language somehow worse but justified with Rob Pike's pseudointellectual bullshit.
Haha fair argument. As someone pointed out - it's very easy to incur technical debt in Perl. It's a dynamic language with virtually non-existant dev tools and lacking open source community. I personally can't wait to go back to a static language for our backend. We're looking at NodeJS (of course...), JVM, and Go. Arguably you can fake typing in NodeJS with TypeScript, Flow, etc, but my team isn't too excited about JS for our backend, I personally have an allergic reaction to Java for backend and I really want a static language, so by process of elimination, Go wins.
Fair, and good response. I was kind of just venting about my general dislike for Go there….
I do think Go has a decent niche for backend services similar to Erlang but with a much easier learning curve (and more available talent). Sounds like you're actually using the right tool for the right job.
depending on technical debt in Perl code (which is quite easy to incur) it might make sense if you're still making changes to the project. also single-binary deployment is always nice, though in the world where docker exists not as big of a deal as it used to be a few years ago.
