On the one hand, if it seems like a problem now, that doesn't may indicate a questionable relationship. On the other hand, that it seems like enough of a problem now to load it into the contract seems shortsighted by the company: if there's a problem 14 months from the "effective time" [whatever that is], the best thing for everyone might be for you to resign rather than stick around another ten months [an early-stage startup eternity] to maintain your equity while the other founders devote energy toward getting you to quit instead of growing the company.
To me, it looks like it may indicate the use of documents more typical of a small closely held business than a startup in the form of a Delaware C-corp. Then again, a lot of companies are called "a startup" that are not really designed for sustained rapid growth and organized to accept outside equity to fuel it...e.g. people refer to restaurants and similar new local businesses as startups.
If the other parts are low and this is seen as part of the main package rather than a longer term bonus, then it wouldn't be so far...
I doubt a co founder is going to leave within two years unless something is seriously going wrong...
Contracts are a negotiation process, line out or modify the sections you don't like and submit it back for their approval. If they're not willing to negotiate then they likely aren't a place you'll want to work for.
All those are different from projects like Open-Street map which mark success by large world-wide communities addressing global needs.
You should asses whether burnout could be the case and take steps to recover.
Here's what you could expect if you were in England:
That's via the NHS. NHS treatment is patchy. You could also go private, in which case I'd recommend seeing if the NICE guidance is right for you then finding a therapist registered with eg BACP.
The recommended therapy is quite short and should be manageable. Up to 14 weeks at an hour per week.
> are startups just not for me?
Only you can answer that. I'd think that maybe you'd have the same level of anxiety even if you weren't working at a startup, but that it'd be about different things.
You might give them that amount of time, inform them you're going to disclose, and if they're still unresponsive, you did your due diligence trying to disclose responsibly and I think it's ok for you to publish.
I've had this problem with iDrive, the backup program. If you use their web interface, they send the encryption key to the server as plain text and decrypt at their end, not in the browser. They denied this when I told them about it. I sent them dumps of the web traffic.
Depending on how much time you've given them this sounds like a perfect candidate for the Full Disclosure mailing list, just post anonymously.
If they threaten you, contact a few well-reputed security research companies and ask them if they want to handle that case for you. They have experience dealing with such situations and a name that will make every company think twice about threatening them with lawyers.
I'd use post. Like, printed stuff on actual paper. If you send something to their business address as registered mail, not only do you get proof that you sent it, you also get proof that they received it. It's much less likely to be ignored.
As for PhD, I think that, as long as you're exceptional in your area of expertise, you can get R&D jobs without it. On the other hand, getting to that level can easily take as long or longer than doing a PhD. Also, I think you can probably gradually advance into more researchy positions through smart career progression, starting with more development-oriented jobs in R&D areas combined with doing plenty of research on your own.
So my advice to you is see if you can get in on the ground floor at either a startup or small company that is in R&D and you'll be forced to learn a ton of provable marketable skills that will allow you to move on and work for a larger company without a PhD.
Most web applications have a parameter in them that points to one or more database servers of some kind, so you can create a new instance by doing, say, "CREATE DATABASE" in mysql and installing the software in a directory on a web server configured to point to the database. If there is a need for scratch directories and other resources that can be handled pretty much the same way as the database.
The provisioning system then is completely separate from the main body of the app so it is easy to keep one private and open source the other.
With the above you can often host a huge number of instances on one machine without any exciting tech (I was doing this at least as early as 2003) but obviously the idea could be implemented with containers, cloud servers, etc. today, for instance you create a cloud server for the user and auto-provision the software to the server.
There are more fancy "multi-tenant" systems such as Salesforce.com where you put a "tenant id" on the database fields so that many tenants can run in a single database, but that's another whole issue in which case some clever thinking would be necessary to add multi-tenant to the open source software.
Start by creating a remote-first culture. Everyone should think "remote" first. Thus it should never matter if a local employee is working from home, the HQ, from the other side of the world. Make all work processes remote friendly. That should be step zero when considering hiring a remote person regardless of the reason. The goal should be to avoid a two-tiered culture. Some differences will always be there but if the spirit of the remote-friendly culture is there integration is pretty fluid.
Thus (near) all communication happens in Slack/Hipchat/etc. Group meetings, when including remote people, happen in video conf / Hangouts. Shared Google docs to collaborate on. Have in-person meetups 2-4 x a year for beneficial face-time and for people to get to know each other better on a personal level. When a new person is hired, have them do 20 min 1-on-1's with all team members to get to know each other and their job role. Have monthly video conf/hangouts on non-work technical topics where people rotate presenting.
The biggest element is the decision to be a fully remote team. Which honestly is a major retention benefit as well. Why should local employees not enjoy the same flexibility to work as needed remotely?
Daily standups, dialed in on planning meetings and the odd visit for project kick off meetings all help to make me feel a little more integrated into the team. In saying that, I'll never be as integrated as the people that are in the office everyday, but I can live with that for the flexibility remote working gives me.
I should also note that I don't work from home, but rent a desk in a coworking space.
I truly think that this is the future of the work environment. People go to an office to work, but one that is local to them, rather than relocate.
We have built our current office space to be as remote friendly as possible. We integrated Google Chromebox for meetings in every conference room and telephone room. This prevents about 5 minutes of initial setup for microphone and camera. We have already invested in, and continue to invest in, state of the art technology for our All Hands Meetings. Proper microphones, speakers, and cameras in our Atlantis. Once all presentations are are complete, we switch to the camera view so we can see all of our remotes in the room with us as we continue through our AMA portion.
These are just the baseline of things that we have done to make our remotes feel connected even when they are not in our office. We continue to upgrade the experience often and are continuing to grow our remote staff Internationally.
Part of the problem stems from the framing of the question. Flipping it on its head as "how do you integrate local developers into a team?" highlights how easy it is to believe the team's core must be determined geographically rather than functionally.
Reframing remote work as the normative context then places responsibility for accommodation on the people who have the habits that make integration difficult.
We use IRC for everything, which has the good side effect of preserving knowledge for later. Everyone has a bouncer like ZNC setup so they don't miss anything while they're offline. Managers, directors, and VPs all encourage work from home, and a lot (including my manager) work from home themselves. We have an internal video conferencing system that we use frequently. We have a sync twice per week via video, a weekly 1-on-1 with the manager, and people hop into a dedicated engineering room whenever they want high-bandwidth communication with someone or just want to hang out there.
We also have a non-work IRC channel we use to talk about anything, in terms of social / team spirit related things. We have monthly tech talks that anyone can give. Once a year, we meet up for a week in person to get high priority things done. The company also sends us to open source conferences, so we see each other there a couple times a year. A couple folks play video games together like CS:GO. We are thinking about making an optional weekly gaming event with people, maybe something like LoL.
A totally optional thing that I like doing to preserve some record of my work is IRC standups. We have a web form where you can submit what you did yesterday, what you're doing today, and any blockers which gets posted to a separate IRC channel to avoid spam. Other teams with whom we collaborate on a daily basis also use IRC heavily. My manager doesn't like having this, but I like having an IRC highlight with my name that beeps whenever someone mentions my nick or asks me a question.
With this, we're able to collaborate across quite a few timezones, including one dev in the UK. It's worked out really well. I live near the HQ and sometimes go into the office, but generally working from home has been really efficient for me and a lot of our team.
Then you just have to worry about communication. But the onus of communication is on the remote worker, IMO. The most successful remote people I've worked with were all excellent at written communication. You may think that having extra meetings and video chats are a way to integrate the team, but it could be better to let remote workers leverage the quietness of their remote setting in order to knock out code that requires focus.
That said, chat is huge! But it's like texts, in that it's socially acceptable to answer anywhere from immediately, to an hour later.
For team building, I find it's good to fly everyone in a couple times per year, for product planning and social time.
You can adapt this ideal to remote work situations and there is lots of material about how to accommodate that. But many people who gravitate toward remote work are probably trying to move away from this ideal.
For some it may be because they've experienced open source collaboration and don't see why commercial development can't be done in a similar way.
Open source projects tend to use low-bandwidth, asynchronous communication, perhaps as a cultural heritage from the days of slow internet. That enables collaborators to schedule their work in whatever way suits them.
Many programmers are psychologically introverted, which means that they function best when they're allowed to be by themselves, instead of being constantly communicated with. These programmers are often unhappy in the office environment, especially those with open plans.
If you take a step back and look at contemporary software development offices from a kind of anthropological perspective, it's actually quite a bizarre and extraordinary way of life.
When everyone is in the same house for 8 hours every weekday, the demand for social compatibility is, in some sense, even greater than with most families and friend groups... one way to get around that is for each worker to wear headphones all day, which is also quite a strange situation, socially...
I'm personally yearning to be able to work remotely in a way that suits my introversion and my preference for asynchronous independenceor to be frank: I just don't want to be in the same house all day every day with 10 other dudes, and I really don't want to be on conference call with them all day either.
Nor do I really want a strong "team spirit" in the sense of social bonding. I think work would be more sustainable and enjoyable if team relations were less tight, and if my lifestyle allowed me a wider spectrum of daily social interaction.
I'm motivated by helping to do good software development. I'd rather do this in a way that's like the open source model, preserving my basic independence in terms of location, time, and communication.
#1. You need to have a PM for remote devs, on their side. Or decide who is the PM out of these remote devs. This person will be your trustworthy manager. If something goes not right, you talk to him/her first. Ask him to provide all the honest and bold feedback from himself and all the other remote devs if something happens.
#2. Request daily short updates from every developer. Just 2-4 lines of text about what have been done during the day. Explain to them that you will not actually reply to these updates. It's just to keep everything transparent. So, they write - you only read. Rarely reply with some questions.
#3. Set the goals on projects you work on with them, request deadlines, you can set it in sprints. It's like mini OKRs (google it if you don't know what is it). It helps them to be accountant and spend their working hours wisely.
#4. Have at least one 30 min call per week with all the remote devs to chat about what you are doing and motivate them with some good news. So they would feel they actually get paid not just for the code, but they make a difference for your company and for your clients. Share with them what you personally have done during the week. All people want to work with even better people, so it should be clear for them that you are awesome. They will respect you more. Basically, treat them as your usual team members.
#5. Use some reporting tools. At DevTeamSpace we have this kind of dashboard - http://i.imgur.com/F6Q3COn.png . Maybe it would be helpful for you too.
In fact, so many companies struggle to manage remote dev teams. If you need any help - ping me at alexey(at)devteam.space.
As noted elsewhere, thinking remote-first is required for non-co-located teams to be successful.
Technical items, in no particular order:All meetings are conducted with full video teleconferencing.
Most meetings are configured to default participants as muted (help stop random noise on line).
When we white-board, we use a webcam (or lacking that, frequent cell-phone pics) to keep remotes in the loop.
Heavy use of IM tools, online wikis/notes, etc
Social Things:Try to meet in person occasionally. Obviously doesn't work if people are truly global, but I usually see my team in person at conferences, client meetings, or we fly them in every so often (project kick-offs, major high-level design efforts, etc).
Find team building activities that can be conducted via video-conference. Commit to doing them regularly.
If you conduct 1-on-1s, make sure part of those meetings is social. Take the time to do some "water-cooler" chit-chat.
Although I missed many of the perks of working remote I felt pretty connected socially. What I discussed with my colleagues they also found it ok.
As said this is not for everyone, but I look forward to technologies that enable people being in same place remotely.
My first group was very coherent and supportive even if remote. We were constantly in contact via chat/email/phone and there was a sense that we could count on each other to get things done. We only met in person once or twice a year, which didn't seem like a big gap given our close communication.
My current group, while the company strongly supports remote workers, is very detached and isolating. I actually see my coworkers a lot more frequently but don't feel a lot of commonality or support. Some of that is just how this organization is constructed - it deemphasizes peer-ship.
I'm Justin Gordon, the founder of ShakaCode, http://www.shakacode.com. My article and video on telecommuting from Maui is still the number one google search result for "telecommuting maui": http://www.railsonmaui.com/blog/2014/05/06/remote-pair-progr....
I've been a full-time remote worker from Maui, since 2007, a remote freelancer since 2011, and over the last 2 years, I've run a remote consulting and product company. To brador, that says "Remote devs start to have mental health issues from the loneliness and lack of supervision in down times", I'd say that's total hogwash. We spend almost every day video chatting on Skype with people (team members and clients) around the world, and we are very often on ScreenHero sharing screens (often with Skype video), and always on Slack and github conversations. There is 100% no loneliness with this lifestyle. In fact, I'd say spending 1-2 hours a day commuting is a far bigger risk for physical and mental health issues!
Since I founded my company to be 100% remote-first, we've avoided many of the issues that face companies that are schizophrenic about remote work. I've heard numerous stories around Silicon Valley about how companies start allowing "work from home days" and then the senior managers see the parking lot 3/4's empty at 11am, and then there's an ultimatum that you have to work from the office unless you have specific management approval to work from home for one given day. And I'm NOT EVEN EXAGGERATING ONE BIT!
One of the keys to my firms success is to hire team members that love what they do, either programming or design, and that typically interact well on open source. To that end, I've found almost all my team members though our popular open source, https://github.com/shakacode/react_on_rails/ 1238+ stars), which is the number one package that integrates Ruby on Rails with React via Webpack and NPM.
If you don't some people will become very reluctant to video conf as they'll see it as constant water cooler talk that prevent them from working.
I also would insist on tools equivalent to screenhero and floobits to facilitate pairing, whether remote or inhouse.
I would also have a convention of not switching off webcams in meetings. People often do that, thinking why do people need to see my face, but it is essential that they do so that visual communication/presence also works.
I also like the idea of having a skype/hangout running all day long so remote people are aware what happens in the office, who is around etc. At one startup I hurt my leg and was WFH for 3 weeks. They left an ipad running skype all day on my desk. It was great as people would walk up to my desk to ask quick simple questions / water cooler comments etc, instead of most likely not send a hipchat/slack message as not important enough.
We also use Basecamp on a daily basis for specific project tracking.
All in all, we are pretty "integrated" using this rather minimal set of technology.
My advice - have a core team in house and out-source what you would have given to a remote dev. You're going to be parcelling out jobs to the remote dev(s) anyway, but with freelance they're not your problem if they get lazy and you can next them easily. Also, a single cost for the job and no employee paperwork to deal with.
Plus, if a freelancer proves themselves an excellent part of the team you just throw them more and more projects of increased scope.
1) Use as many visual techniques as possible e.g. Screen sharing and drawing pictures and sketching examples of what you're talking about.
2) open chat channels all day
3) ability to build rapport e.g. During standup calls look at what the weather is like in their country or share something about what's happening in your area at the weekend. Ice breakers if you will
4) if possible get them to visit you so they understand the culture in your office and understand the people. the most success we've had is when people visit the local team soon after joining
Beyond that, you have to practice the technical bits, conduct all meetings on a google hangout. If people don't offer remotes that opening to talk, they have to make it.
It's one of those problems that everyone faces one evening, but the hassle of using an app is usually higher than actually having a 2-minute conversation about where to go.
That being said, you never know what will work, so don't give up just because of random Internet advice.
It looks like your app doesn't need to have network effects to be useful. That's a good thing. So you'd be fine with even 10 people using this every week. That would be a sign that your app is useful. Once you reach that stage, you can focus on scaling. But just even getting 10 couples to use this weekly is a tough challenge. Do you use it? Does any of your friends actually use it?
Looking at your website, if you are disappointed by the conversion rate, target a smaller niche first and see if the conversions increase. Right now it sounds like a generic "restaurant recommendation". The couples angle is not there. You go with more punchy headlines: "no more arguing Friday night about where to take your SO".
Bottom line: go from 0 to 10 users by sheer force of persuasion. Then come back here and we can chat some more :-)
I'm hesitant to "like" a restaurant suggestion because if I was to match, then I'm stuck going to that restaurant for dinner when there is possibly a better match that just had yet to be suggested to me. The original Tinder model works because there is no risk of being locked-in (lol).
That being said, I think this is a great idea and IMO your initial use-case and test users should be startups trying to decide what to order the team on Seamless. Print out some flyers that say "Team can't decide what to order for lunch?" and post them around co-working spaces.
If I was building this app my first iteration would have been to show the users a list of the top 10 nearby restaurants weighted by stars on yelp and filtered by price/distance. Let them give a 1-5 thumbs-up rating of as many restaurants on that list as they want and total up the number of upvotes for each option.
If so, what are their pain points and how are they being addressed?
If not, then getting one user is more important than a marketing strategy, and harder. People using the app validates the beliefs:
1. the app solves an actual problem 2. there might be a profitable product
Also try pitching food blogs and technology/lifestyle blogs to review. Write up some stories like "My wife and I kept ordering gross pizza because we couldn't decide where to eat -- here's how we saved our relationship!" Make them entertaining and relatable, and offer them as content for food and restaurant blogs. Find some quality food blogs or youtube foodies, offer to pay for their dinner if they will use your app to decide where to go.
Find larger food/restaurant apps and sites, ideally ones that complement and not compete with your concept, and look for ways to cross-promote. e.g. they make a post or ad or something to drive users to your app, and in return you put a prominent button on in your app for six months that says "View this in BigFoodApp" and opens their product.
I like the approach suggested by the book "Traction", which boils down to try a bunch of things a little bit to see which one works, then focus on the channel that gets you the most return.
I would try a basic video that just is informative showing off your app.
I would also see If you could get a short video made that is somewhat humorous involving a couple arguing over dinner and then using your app, it could have potential.
Good onboarding, snappy support replies by smart people, they do what they say they'll do, good transparency when there are mistakes, early heads up on changes. Overall, they are solid people running a solid business. We respect them and enjoy being clients of theirs.
We're a medium sized business and we run charges pretty regularly through out the day. Their status page only reports their larger outages. If you are running charges regularly, expect their end points do go down for 20 secs up to 2 minutes 2-3 times a month. Its to the point where our customer service chat knows what's going on and says things like "ask the customer to wait 2 minutes, it'll be right back". Its frustrating. We've considered setting up a fail over with spreedly and braintree but its juuuust inside the threshold of annoying enough to do all that.
That minor gripe said, I still have the Stripe afterglow because we suffered through the Auth.net days and the AMEX domination days. Stripe set us, and everybody else, free from that jazz. We're still grateful and probably always will be.
Lastly I note, if your volume merits, they will discuss alternative rates within reason.
You should go with Stripe.
If you process less than 80k a month:Use Stripe their API is the best and they just innovate faster than everyone else. Love these guys!
If you process 80k - 250k a month:At this level support becomes a bigger factor and unfortunately Braintree just kills Stripe on this side. The below forum post alone shows how much people hate Stripe support. I know their fixing this area but its really hard for medium size business to work with a processor without phone support. Braintree literally picks up the phone in minutes while sometimes Stripe takes days to get back. This is killer when your dealing with thousands of charges a month.
If you process 250k+ a month:I hate to say this but I would seriously look at Authorize or one of the traditional processors. They just provide the best rates and you have to factor how much the cost savings is worth with the increase in implementation pain.
I want to emphasize my feedback changes depending on the type of business your in and how quickly you need innovate/ change your processing. Stripe is really moving fast on new innovations which is awesome. But you have to realize basic merchant processing is a commodity so your paying a premium for non commoditized things like a great API. Also things like a great API are becoming commoditized. Stripe is smart and their launching new non commoditized features like Atlas/ Platform Functionality/ ACH etc. The only thing you have to ask yourself do you need these new innovations or just traditional merchant processing.
1) Dollar amount processed by month
2) Average dollar amount per transaction
From there, you can figure out the rest
For startups, the default is ALWAYS Stripe (IMHO) because you can get to processing cards right away - like in 5 minutes. Their API is easy, their virtual terminal works as expected for manually keyed in transactions. There is even a super dumb screen that is just HTML (Checkout) if you don't even want to deal with an API.
As far as the fees, the $0.30 per transaction fee is always going to be there. The 2.9% percent is negotiable, specially if you are doing volume. If you are doing $1,000/mo, 2.9% will be your rate.
If you are doing much higher volume, that rate goes down. For example, if you can show (with proof via bank statements or from your current merchant provider) something like $300-400k per month for the last 3 months, I was able to get them very close to what is called the "interchange rate" which is the lowest rate you can get even with traditional processors like Moneris (FirstData). My current "effective rate" is about 1.6-1.7% (effective rate is my quick math of fees/total).
Like somebody already said, micropayments are pretty bad.
High volume + low margins make it sound like you are operating a restaurant where the fees are much more different due to the physical nature of the business (less fraud due to card present) vs internet (card not present)
I can't speak to my experience as a Braintree customer as sadly my app hasn't processed many payments but the initial integration using Braintree was much easier for me.
I'd consider using Stripe and have in the past, but we're doing millions/month USD (less than you'd think with a high-dollar, low-margin business) almost entirely card-present, now with EMV, which puts us way outside Stripe's target market. We also have a complex approval process and capture/settlement several days after approval, which, again, isn't really in stripe's wheelhouse.
Don't use heartland. I've had to deal with them a lot over the past month and they're absolute garbage. Shit API, integration specialists that can't be bothered, NDAs before they'll look at you, just all-around bad experience. They also announced they're deprecating SHA-1 support, which would be prudent except that they gave merchants two weeks notice before doing it.
Last I checked, no other service has any separate fee for micropayments. Paypal doesn't make it easy to find this info out, but it definitely still offers the product.
of course paypal can be really, really annoying to work with, as their code is VERY old and their APIs can be confusing. They also have a weird variety of products that semi-overlap, so selection of which specific product to use can be confusing (Express Checkout vs. Instant Checkout vs. Adaptive payments..?).
a few other things to note: paypal's international coverage is much better than any other provider, so if you want to expand to EU or South America quickly, they are good for that. also, paypals payout process (MassPay) is much easier to use than ACH or any other solutions I've seen, and much cheaper (2% transaction fee for payouts). Also, all the payee needs is an email address, no bank account info, etc.
Truthfully, those are two reasons we still use Paypal. Otherwise, it kinda sucks =)
You might find yourself requiring multiple providers for different requirements and redundancy.
Playspan was for example very good at the south american market, Vindicia very good at retrying failed payments and auto replacing card details for recurring subscriptions. And a lot of customers expected to be able to pay with Paypal whom are also good at fraud prevention.
But to echo everyone here, if my "next" startup requires a payments provider I would initially go with Stripe and/or Braintree.
- Wells Fargo Merchant Services
- Chase Paymentech
- Vantiv (acquired Litle)
- Forte (acquired ACH Direct)
Stripe is probably your best bet, but should you decide to choose anyone else, let me know if you'd like any help as I've integrated with most of these processors before :)
PS: Ultimately your decision should come down to your card blend, i.e., if you process mainly debit cards (Durbin regulated and basically zero interchange), go with a processor who will offer you interchange-plus pricing. If you process mostly premium cards, go with a processor who will offer you a blended rate, since they'll probably be eating their AMEX transaction fees (typically around 3.5%).
1) https://github.com/stripe/stripe-node2) https://stripe.com/docs/api/node#intro
So far I haven't run into any problems. The only thing I really needed was to customize customer e-mails, so I used Braintree's webhooks to my server to send out my own e-mails.
Support wise, I was on the phone with them quite a bit in the beginning, and they were nice and knowledgeable. I used them pre-paypal and post-paypal i haven't noticed any differences.
Fraud wise, my customers tend to be reliable ones so I haven't had to worry about fraud yet.
Based on this alone, you need to get your own merchant account and gateway. I highly recommend Beanstream in Canada for the gateway. A proper merchant account (interchange plus pricing, either Chase Paymentech or TD are good) will boost your margins. For example, processing a debit card has a much lower interchange rate than a credit card (I don't think the rate is as good as the USA, but its still 1%+ difference).
Beanstream will also give you the option of Interac Online - which is a flat transaction fee between 20-50c.
I've had a great experience so far, the staff is very open and responsive.
We originally intended to go with stripe, but they refused us as 'forbidden business' which we aren't as we reviewed their terms plenty of times to see what we fall under. I asked for a clarification/re-review multiple times, but i got no reply which i think is very unprofessional.
Micropayments are tough (if that's what you're going for).
Downside: The cost is somewhat higher. So I don't think they work for a low margin business.
I do however, work in ClojureScript, using Reagent, which is an opinionated binding to React with a special emphasis on functional reactive programming.
I discovered the FRP approach through Hoplon, and then soon moved to Reagent, and I must say that it was an absolute godsend.
It is the first real alternative paradigm to interface development in years, and the first one that actually interfaces well with functional programming at the most basic level.
FRP allows you to write an interface in a declarative, functional style that is easy to follow, and largely easy to predict. State is kept to a minimum, and can be organized and localized in sane ways. View updating is basically automated, left to the underlying mechanisms of the virtual DOM.
With CLJS' Hiccup syntax, even defining and passing HTML values becomes painless.
Discovering FRP was basically the same light bulb moment for me as a programmer that discovering Lisp and FP themselves were. I only wish I could find a framework for developing desktop applications that was as easy to learn and use.
React makes it easy to create small components, encouraging maintainable, reusable software. On the flip side, passing data around in your application is a lot of work, and even the best current solution (unidirectional data flow with something like Redux) is very oblique and involves significant boilerplate.
In my opinion the React/Redux model is pretty good, and the libraries are well designed, there is just a need for a good framework to deal with the indirection involved in unidirectional state flow. I'm currently working on something in this space, it just needs some additional battle-testing so I can settle on the interface and work out all the kinks.
React really is different than everything else that has come before. I don't know if React will be the final, new framework most developers use. But whatever is the final framework will almost certainly borrow many of React's ideas.
Angular and Ember never quite did it for me. I don't agree with all the design decisions they've made. I do however enjoy using React a lot. It fits my mental model much better when it comes to building front-end apps. It's simple to learn, focuses on building modular components and I really like how it manages state (either via components or Flux/Redux.) That said, it's not something I use for every project. But I had something that just wouldn't work as a traditional server-side rendered project and React was a godsend.
I'm hopeful that ClojureScript continues to gain traction and improved tooling. I really like the language, and feel that it offers enough to replace JS for most of my needs. I've played with Reagent and _really_ liked what I saw there.
There's only so many incremental improvements to front-end development left.
I don't think we will seriously find a consensus until we get WebAssembly.
I'm not against new concepts. Client-side rendering is awesome, reactivity is awesome. But I'm against all that bloatware. If a new concept can't be implemented without bloatware (hint: it can), we don't really need it.
But these things can and should be done in a different way. For example, all my JS stack (Z5 + DaBi) targets ES5 and is under 4 KB altogether. Yet it provides:
- DOM manipulation and auto-polyfilling some DOM essentials (only for the stuff that's really uncomfortable to do with native APIs - Q.js);
- reactive in-memory storage (with an ability to easily populate from external objects or remote requests - Zen.js);
- easy data-to-DOM and DOM-to-data binding (DaBi library);
- ability to easily build DOM and CSS styles from JS native constructs (XT.js and XS.js - never go through escaping hell again);
- client-side routing (R.js).
And while I agree that React/Angular are the bloatware (even jQuery is), I disagree that server-side rendering is any better and that throwing in another bloatware like ClojureScript would solve this issue. Like I had said in my article about client-side development (http://clientside.surge.sh/), go native or go home.
- All developers on a project are in sync.- You can get the repo back into a good state if npm choked.- You can go back in time to a prior version with all of it's actual dependencies at that point in time.
-- i just made that up.
(but we actually do, in fact, do all of that for our major dependencies like upstream OS's, build deps, gitgub repos, cm, etc.)
if you don't have anyone on your team that knows how ......... well, you should probaby fix that.
1 - https://news.ycombinator.com/item?id=11354147
The short answer depends on what you're cracking.
Let's assume your message was encrypted with AES, using a key derived from a passphrase, and nothing else. There's no authenticator on the message (no keyed checksum) and so the ciphertext is insecure, but we'll ignore that.
Then the attacker is just going to try every possible password. As you observed, each of those decryption attempts is going to generate gibberish. But all those gibberish results will be binary gibberish: a decryption attempt with a key differing even in one bit from the real key will produce an effectively random plaintext, with bits evenly distributed.
The right key won't have that property; the result will be 7-bit ASCII. It will almost certainly be the only result that produces ASCII, and certainly the only one producing intelligible ASCII. :)
If the message is encrypted securely, with an authenticator, the job of cracking it might be slightly simpler: you use the authenticator to verify that you got the right result. This is how some older systems tell you you got the right key (but it also implies that you encrypted the MAC, which is unsafe for other reasons).
Finally, if you're encrypting with a block cipher mode that requires padding --- something you shouldn't do but that systems designed 5+ years ago all tend to do --- you'll know if you got the right key based on whether the padding makes sense. There's a very famous crypto attack based on this property.
Indeed, the notion of what expectations you can even have of the data, in principle, relates to information theory and reducing said expectations is crucial to keeping private transmissions secure.
- Anyone can be interrupted at any time (to say nothing of @everyone), so it's essentially just an all-day meeting. At least emails could be responded to at relative leisure.
- There are only three notification states: "nothing" (normal icon) "something happened in a non-muted channel" (red dot), and "you were mentioned specifically". There's no way to gauge importance without disrupting your flow. Some pointless cat GIF (why are these being posted on work chat?) is ranked the same as "what should we do next?". Similarly, "@everyone there are donuts in the kitchen, OMG" is ranked the same as "@someone THE SERVER IS ON FIRE".
- Channels are never-ending, so it's relatively impossible to tell where one topic began and another ended. Additionally, multiple conversations can be held at the same time, and it's difficult to tell who's replying to who.
However, I quite like Slack's group private chats. I'd like to see a group-chat solution that promoted those and completely got rid of static channels. Everything's just a private group chat, with all of the people that are needed. When the discussion's done, archive it - it's searchable, of course, but if you need to continue the discussion, make a new one! Maybe everyone in the chat even gets a summary emailed to them that they can search in their email client as well (thus solving the "wait, where did we discuss that" problem).
There are a few other changes I would make - for example, the return key should be newline by default to prevent people from writing
putting their thoughts into well-composed
Yes, yes - Slack gets all the news and chicks and is probably bigger. But it's the entire mindset. You wouldn't start an HVAC repair company after hearing that an HVAC repair company is doing well, even if they're the biggest one in the region and even if they're making millions; similarly, you shouldn't start a chat app just because you hear Fortune magazine writing about a chat app.
There's another part to this too: With the word 'disrupt' I'm hearing "Slack is doing well; I'm jealous of Slack; how can I hurt Slack?" I used to have a neighbor that would get jealous of people and key their car if it was nicer than his. Nobody liked him and eventually they arrested him for unrelated reasons.
Don't phrase your business plan as being the equivalent of keying Slack's car.
Don't ask 'How do I disrupt Slack?', or more generally 'How do I disrupt Y?'.
Also don't ask 'I want to build Slack for X, what X is good?', or more generally 'I want to build Y for X, what X is good for that Y?'.
Instead observe your environment. Get out and walk around. Talk to people you know in domains you have personal experience in, or are very familiar with. Lots of people - people that are like you, and people that aren't. Find out what their pain points are, and what they'd pay to get rid of those pain points. If you want to focus on chat, find out what their pain points are in communication (the broader area).
Then execute to solve those pain points and make the world a better place. Iterate your execution to solve one pain point (the one the most people say they have/would pay for) and get your first customers. Then solve additional related pain points in successive iterations.
Don't try to compete with a well run team at the peak of their abilities. Go find an underserved market that has tons of money and incompetent incumbents providing services. Slack is successful because this is what they did, but that has sucked a lot of the upside out of the market.
When I say UI and UX, I mean an interface that both looks good and is easy to use as well (they are not mutually exclusive).
Of course, the app has has to be fast and reliable too. Even better if it's lightweight in size and in it's use of system resources - things that many cross-platform apps rarely achieve (including Slack).
I don't think Slack has the best UX in some aspects. For example, the way you need to sign-in multiple times to separate groups feels clumsy and cumbersome.
Does Slack now have too many features and functions? Does the interface feel too busy or cluttered? Do people want even more features? (Probably, although they probably want different features for their own unique needs). Can a simpler, open-source version offer an alternative?
One thing that's obvious from interviews with their staff is that they take UX very seriously - it's a key component in the development of their product. If you're developing an alternative open source version, don't discount the importance of UX to your own product.
Whether you agree or not that Slack is a well-designed app, there's no doubt its succeeded because it can easily be used by both developers and non-developers. Not something you can really say abour IRC, often put forward as a Slack alternative.
Incredibly difficult problem to solve -- any solution would probably add considerable friction to the interface, but it would rock if somebody could nail it.
To disrupt Slack, make an awesome news feed, with chat and publishing API and search. Add an API for reading (like Twitter's API). Make it easily compartmentalised (faceted search maybe?) Then you'll pick up users like me, who used to use email and find group chat better but really need "Hootsuite for infrastructure".
To collect some examples from this thread:
* Some engineering teams need default UI that encourages larger message sizes so people aren't writing strings of tiny messages all the time. This _clearly_ isn't something that everybody wants or needs - a lot of brainstorming goes on in my Slack chats, for example, and that means tiny ideas have to go out quickly and easily - but it's a reasonable submarket to target. This would also lead to a larger emphasis on text formatting and composition, better controls on notification and addressing, better searching and filtering and quoting/reply/threading, and other tools that improve the power of an individual message at the expense of usability and speed - move it more toward the email/forum topic side of things.
* Some teams feel that the existing UI already gets in their way too much. Improve the ease of use and speed of message composition and flow of discussion. Not sure how you'd do this exactly; Slack is already pretty well optimized in this direction. Step one here would probably be to hire a whole building full of UX engineers and optimize the crap out of every single interaction anybody ever does with the UI. Microoptimization on top of microoptimization on top of microoptimization, like Apple did with the groundbreaking early IOSs.
* Specifically cater to enterprise clients with security requirements. Better technical details for security and access control, make it compliant with regulations with particular security and auditing and access control requirements. Provide a powerful system for per-channel access controls that interoperates with something like LDAP, maybe provide a system where you can only talk to people in different groups if you've managed to inherit some permissions that let you talk to them otherwise everything they say never appears on your screen, tag everything with a secrecy level and control access intelligence-agency style, etcetera.
And so on and so forth.
I guess it just comes down to how set on being in SF and not giving up equity you are.
I've tried many different blogging solutions and I find Hugo to be exceptionally easy, especially when combined with GitHub pages.
The current blogging workflow to publish an article is only 3 steps:
vi some-new-post.md && ./build && git push
There are SEO benefits to having your website and blog use the same domain, which is one more reason why we chose this route.
2. How hard would it be to build a deploy system that updates a Jekyll site when the header.ejs changes?
3. Maybe a CMS is a better choice.
TLDR: using medium means you are letting it be easy, and avoiding the cobbler's own shoe type of problem.
- Arrows indicated which way I voted instead of disappearing completely.
- I could change my up or down vote on a comment after making it. When viewing on a phone it's easy to fat finger the wrong arrow. If there's a concern about changing votes long after a discussion, gate it by time.
Similarly I'm guessing most people won't care about my favorite topics quantitative finance or algorithmic trading.
It might cut down on the weekly posts where someone complains that HN is going to shit because a story made the front page and they just can't believe someone would find it interesting.
- Improved readability design
- Retina screen support
- User following
- Super fast inline replies
- Quick profiles with social network info when hovering over usernames
- Filtering of stories based on terms and phrases / domain or user
- Endless scrolling
- Collapsible comment threads
- Direct link to Google Cache version
- Social sharing for Twitter, Facebook, Google+, Buffer
(not affiliated in any way with this, just love it)
Internally, there's obviously tracking of parent/child relationships, but adding container elements so that the children can be hidden would require getting rid of the table-based layout and replacing it with a nested div-based layout. The markup and styling changes would be fairly simple, but none of us know what the impact is on the backend, or on anything that depends on the markup structure that may or may not be in HN's control. My guess is that these non-technical impacts are the driving force behind keeping the markup as it is, which prevents the kind of features you want.
We already hide things if our collective mind thinks it's a bad idea, but I'm not sure it's beneficial to let this occur on an individual basis.
If everyone thinks what I am saying is wrong, then this comment will get whited out and sent to the bottom, but if only you think it's dumb, maybe you should still have to read it.
I kinda like the current way.
Here it is: https://addons.mozilla.org/en-US/firefox/addon/hn-collapse
Also on github: https://github.com/tomkel/hn-collapse
Why is it that the discuss option isn't available on posts that are job adverts?
I think it would be useful/interesting to allow casual conversation about job postings.
If you look in the relevant folder, you may notice it was initially designed for Word Press (WP.user.js), more precisely SlateStarCodex, and seems to work for most such blogs. SSC.user.js is just meant to improve the styling of SlateStarCodex.
It should be hard to manage tons of comments on a story, because it lowers the overall comment count.
I'd love to see some A/B testing on this.
It's very lightweight and doesn't clutter up your screen with an icon since that's literally the only use case. I haven't gotten around to publishing it on the web store yet unfortunately so you'll have to install manually.
1 : https://github.com/premii/hn
I wrote this userscript a while ago.
In light of the left-pad brouhaha, maybe I should mention that my userscript doesn't have any dependencies - not even an embedded jquery.
I don't trust plugins and extensions.
i despise reddit's collapsible / half-loading comments. on large threads it loads the same 10% every single time and hides a lot of the good responses.
just give me all the comments in one shot. i'm a big boy, i can handle reading.
Core dumps, memory leaks, hardware faults, and plain bad luck.
Big O, data flow, always learning -- or out you go.
Manager metrics, schedules hectic, methodology hegelian dialectic.
Taking the heat, feature creep, open office, uncomfortable seat.
Holy wars, revolving doors, carpal tunnel, all you can take? There's always more.
Fucking suits, random reboots, and the ever present "thousand language stare".
Oh yeah, pressure -- lots of pressure. And time, time, time.
Metric shitloads of time.
Time, man. You gotta do your fucking time.
I would say the difference between a junior and a mid is experience breadth of knowledge. Knowing what tools, patterns or architecture to use and when.
The difference between a senior and a mid, is that a senior knows when NOT to use them.
In other words, juniors and mids tend to focus their attention on technology. Seniors tend to focus on delivery.
A mid-level developer is mostly autonomous within the confines of a planned out project. Given a specific scope and criteria, they mostly get the job done with some help from a senior. Their errors and bugs are typically of the architectural and performance type, though a lack of foresight can plague the less savvy mid-level.
A senior should be nearly completely autonomous. You tell them the general thing that needs doing and they are able to do it on their own. They can see the impact a decision would have far enough down the road to accurately weigh pros and cons. On top of that, they are able to help the mid-levels and juniors get better at their craft as well.
Imagine your company has a programming problems that is a shaped like a vague cloud.
With a junior developer, you need to do the work to dig into the cloud, define its boundaries, segment the work, and write it all up as tickets. Then you give it to the junior dev who focuses on each one independently. They are not responsible for the end result, though they may be asked to verify the parts they coded in production.
With a senior dev you say "solve this problem" and walk away to do other work. You know they can just dig in, figure out the right solution, code it, test it, and maintain it.
How far out you can spot your mistakes, and the multiplier affect you have on the people working around you.
To ask your direct reports where they want to be in 5 years and help them get there - without disregard of what that means to the day's need
In business school, you are taught how to create business plans, and in that business plan, you have a section that talks about your competition. If you don't know if there is something better or if something like this exists, you are either not looking hard enough or you have stumbled upon something great.
If it is the former, do more research and I guess asking here isn't a bad start, but really, you should be posting in some Cassandra specific newsgroup, if such a thing exists. Or some NoSQL site.
If it is the latter then, hooray and too bad at the same time. Another thing you are taught in business school, is the innovators, are usually not the ones that benefits from their innovation. It's usually those that iterates on the innovative ideas, that benefits. How good of a solution you have, will dictate your market entry strategy.
I guess my answer to your question is, it depends, but I would have to imagine, simple benchmarks would go a long way to further validate your solution.
I'm working on more advanced Redis use case patterns and your project fits in with that theme.
The awesome thing about the tech industry... what you did or make this year doesn't affect what you can make two years from now all that much.
>What did you do to keep head high and still achieve something great in life
Be confident you can eventually get where you want, but realistic about how many weaknesses you have and how long it will take to get there. This might be a two year path for you to get that dream job.
In the mean time, you can't spend 100% of your time stressing about how you aren't growing/progressing fast enough. Partition your free time into both 'learn/grow' and 'goof off/relax' time. You absolutely need the latter too. Study your tech books, practice coding etc.
For me, no matter how crappy or great my week is, friday night I have a couple drinks with friends or my GF and don't think about work. If I stay up all night working, I try to read a fiction book for fifteen or twenty minutes before falling asleep. Little things like that will keep you sane and happy for the marathon it will take to get to where you need to be.
You don't get "lucky" with these. They take effort.
Don't think in terms of how much you are struggling.
Think about what other people want. What kind of men do women like in your area? What kind of employees are employers valuing? Where in the world you can get a house for less than $100k? What kind of assets are very cheap right now?
Think hard all the time about all of these things.
That's what I do, like all the time.
I'm in a relationship. I have a 6 figure job. My stock portfolio went up heaps in past year. I pay $400 rent after renting out the other rooms of the house I'm renting for $2200.
None of these were "luck". And I didn't "get" them by working and going to the gym and making applications.
I'm Asian also.
1. You mention you want the "life of luxury" that these "lucky" people enjoy. If you spend your life chasing wealth, you will never feel satisfied. These "lucky" people spend their days doing something they love, not just chasing wealth. This motivates them to learn constantly and become better everyday.
2. The difference between you and the people who are "lucky" is when they get rejected, they study harder, learn more and keep persisting. Instead of doing that, you wasted your time writing this post to complain.
Figure out what you want and go after it. Do whatever you need to do to achieve it. It's as simple as that. If you don't really want it you will fail.
Seriously though you do have to make your own . . . with a positive attitude, keep trying . . .
Sounds like you have a decent job . . . compare your peanuts to some other workers around you . . . restaurant manager, uber driver, I expect you're making more than most professions.
Focus on the positive, improve your skills, be confident, build a few side projects to help you in your next interview. Show them what you can bring to the table beyond slinging code, business logic, improving the flow/ui/ux of the apps your work on . . . there are lots of ways to bring more value than the other devs out there . . .
Good luck, keep trying . . . make your own luck, and pay it forward to the less 'lucky' employees around you.
If you are bad at getting a job, make your own. Moving to the bay area is a terrible idea. It's a bad place. It's expensive but I guess on the plus side, you wouldn't feel out of place going homeless.
Improve your confidence, improve your skills. Also, "achieving something great in life" is different for everyone.
Re: struggle (just for some perspective)
I'm self-employed now, but when I was looking for jobs, I was rejected multiple times (before finally finding a job). I tried to learn as much as I could from the situation and I moved onto the next interview. Sometimes, it's just not a good fit or they were looking for someone with a different skill set.
All of these successful people that are 5 years younger than you probably got rejected multiple times before getting a job. They will never tell you this and you only see the success.
It reminds me of many photographers' portfolios: You might see 100 beautiful, perfect, pictures. But, you don't see the 1000 terrible shots it took to get them.
"It has been at least a month I have been looking for new job but still nothing."
Try to get busy with something. Work on an open source project while you are looking. I'm not sure why, but I've always found my best jobs while I wasn't thinking about getting a job all the time. It might have to do with subtle signs or body language...or maybe I'm just more comfortable.
"So far life has been really really brutal for me"
Welcome to life. It sucks..but you sound like you are on the right path.
Dating will always be tough. I dated around for 5 years before finding my wife. I have found that it's very similar to finding a job: When I'm not concentrating on looking for a date, I end up finding one.
My wife and I met through a meetup group. It had nothing to do with dating, just a mutual interest.
Has to what to do ? I don't have any solutions but i can offer some reflections of my own having been in that dark hole myself a lot of times.
First let's talk about your inner world. I don't know you, and i don't know the struggles you face, but independent of your external conditions, there is a large body of "technics" on how to deal with and manage negative emotions ( lookup self-regulation in emotional intelligence for a start). Beyond that, the idea of "emotional hygiene" has been very helpful to me.Much in the same way that feeling tired all the time is usually a sign that your body is missing something, experiencing long period of negative emotion might be a sign that your are not taking care of you emotional system as you should. Some people mentioned hanging out with friends etc...A sense of belonging is very important (even for introverts) , but there are many other aspects (Ask more questions is you want more specific item as to what to do ). I also get from your post the impression that your self worth is somewhat attached to your success... A lot of us feel this way, and that's a very dangerous way of valuing one self.
Now after all that emotional sweet talk, the fact remains that emotions do usually contain a kernel of truth. i think the gist of it is that your are not happy with the results your are getting given the amount of efforts you putting in. The reason for that might that your model and assumptions about success and how to be successful are not accurate as they can be. In other words, what you experience as "luck" for other people, might not really be luck as much as a chain of consequences that your model cannot explains. You mentioned someone getting a cheap housing, maybe it was pure luck , or maybe that someone has better soft skills which translated to better/bigger social network which resulted in him/her being aware of more housing deals; and more housing deal combined with better negotiation skills resulted in a good deal.So instead maybe you should be thinking "i need better soft skills".
So maybe this is the time to reevaluate some of your core belief; You seems to be focusing on "hard work" as the main variable for success...But smart work,soft skill, opportunity and leadership are all equally important. How are you doing on those fronts ?
Try volunteering, giving back, and getting to know some of the millions of people who are much less fortunate than yourself. It might help you gain a new perspective on your own situation, and, if nothing else, will stack some karma points up in your favor.
3) What do you wish got better? - more companies making products helping the world / making a difference - less competition for jobs
3) Scala.JS is good. We need more good stuff to compile down to web assembly so we can write browser code in a sane language.
"Intuition" (or more generally, associative thinking) can definitely lead us astray. So can (superficially) analytical thinking that might appear to be based on a chain of logically sound, "if A, then B" statements but yet ultimately miss the bigger context, or otherwise just end up coming to warped or irrational conclusions.
So both strains of thought are needed. Especially if we're to stand any chance at all against the robots.
2. There should be a clearer channel to communicate with the different stakeholders. I might have good product ideas, regardless of what my designation is (engineer, in my case). There should be an easier way to get feedback on ideas - good or bad.
3. Lopsided workloads should be regulated. It will be nice if all teams were equally loaded. In my case, I have a very reasonable schedule, but in some of my friends' case they work really hard!
4. Give people more responsibilities! Nothing teaches leadership like taking up ownership.
1. The money was good ($175k as director of engineering in Los Angeles) and the hours were 9-5.
2. I wish I had more autonomy to manage my team. Although I was director, engineering was basically under the control of product and upper management. Unfortunately they knew nothing about how engineering works.
3. A chance to define a new role, possibly R&D or skunk works, so I could contribute but not be bound by the traditional management hierarchy.
4. Ultimately nothing, since he was the problem. He is CEO of a tech company but he can't even plug in a thumb drive. He has said in the past he views engineering as "black magic" because he doesn't understand it.
1) What are some of the best things you value at your job?
The clients I work for are huge, well known companies. The work is interesting, and I'm learning a lot from the other developers. They like to encourage professional growth.
3) Besides money what is the one thing you wish your organization would offer you?
Getting to work remotely as often as I'd like, which would be like 3-4 days a week. Higher matching for the retirement plan comes in second.
2) Putting less skilled people in middle mgmt on top of engineers (thats a big putoff bcoz we do check their profiles), measuring work more, valuing people that actually work more
3) Sports area, occasional hangouts, spare time for personal projects
4) News updates, taking reviews, giving feedback, more involved, valuing tech stuff, following future market trends
Medium, somewhere between half-baked and well-done.
Considering the sheer number of 'self-promotion disguised as content' and 'Dear whatever subject I feel like complaining about today', or 'Dear Dear response to complainer' posts, I wouldn't consider it a good Medium (pun intended) for any content that matters.
Unless, of course your business is shameless, thinly veiled native advertising.
I'm exactly the same. I run 2 profitable (totally automated) startups.
Do you work a fulltime job or are you free? If you want to work on a project with profit as the goal, mail me.