People love to talk about themselves and their businesses. You will get a ton of positive response by picking up the phone (or sending emails) saying "I'm new to this sector and I've been learning everything I can online and through books and trade magazines. But I know I would learn more by talking to someone working in the field. Could I stop by Monday morning for 15 minutes and learn about your business. I'm interested in finding out how you came to even be in this business, what parts are enjoyable, and what parts are challenging. Thank you for your consideration."
The first day I was in Palo Alto (and the US), I had absolutely no contacts and was severely jet lagged. I had just moved to the US to establish my startup (https://journeyapps.com) in the US, raise "Silicon Valley VC" and chase the dream ;) tl;dr - JourneyApps is a platform for businesses to quickly developer mobile apps for internal use.
I walked down University Avenue, and spotted Palo Alto bicycles. I walked in (very nervous) and asked one of the sales people if the manager is in. Jeff (the manager), was there and asked what I wanted. I explained I'd just moved here, and was working on a startup that eliminates paper forms.
He was kind enough to not kick me out, and (because it was closing time), spent some time talking to me about how they sell bicycles and which paper forms he uses. He also explained how much of a pain it is.
I kept delving into the details of his business, which he absolutely loves, so he was keen to keep talking. After forming a good idea of what his world looks like, I asked if he'd be keen to do an experiment with us. We'd make an app that does bicycle sales on a tablet, and bring it to him in a day or two. The experiment would be free, he just needs to tell us what works and what doesn't.
He was really keen, and gave me copies of the forms he uses. Overnight we built an app on our platform that acts like his paper forms. The next day we rolled out in his store, and waited for bicycle sales.
The app worked, and we learnt a heck of a lot about US business culture, even though it was just a "small family owned" bicycle store.
Eventually we raised the mythical Silicon Valley VC money and got our first Fortune 100 customers, but the process stayed remarkably similar:
1) Find someone who's passionate about their business
2) Talk to them with genuine interest and learn about their world
3) Be upfront and open about which problems you think you can help with, and which not
4) Over deliver.
Fwiw, I've become mildly obsessed with this topic, and have written up a couple articles that may help:
* How to talk to customers: http://customerdevlabs.com/2013/11/05/how-i-interview-custom...
* Which customers should you talk to first: http://customerdevlabs.com/2017/03/20/who-are-early-adopters...
* How to ask for conversations: http://customerdevlabs.com/2014/02/18/how-to-send-cold-email...
- still at the idea stage, I began talking to people online on iOS dev forums - iphonedevsdk forum, and reddit.com/r/ios /r/iphone, etc
- I asked my friends who I knew were devs. I live in Poland, and my target audience is mostly US, so their feedback was slightly limited, but still valuable, because I could talk to them in real life
- as soon as possible I went to San Francisco, and went to any meetup I could find through my contacts, on Meetup.com, and Startup Digest
- I try to follow news as closely as possible (e.g. there is iOS dev weekly newsletter), and look for opportunities to engage in the communication. Even without mentioning the name of my project (which is AppCodes.com -- a shameless plug here :D )
- Sometimes I write to bloggers and people who write about my subjects about something I work on, to honestly gather their feedback, and of course to ask if they want to know more about my project. It's always personal.
After a few years of doing various projects, I noticed that it almost always takes around 6 months for the word to go out that I do things, and people start coming back to me by themselves ("are you still doing X?"). With time, finding connections is easier, but not faster - it always takes exactly 6 months :)
If you go to a small retail business (say a cafe) when it is not the peak hour, you might find the owner working there. It is usually not hard to get them in a conversation, many of them will talk your ear off. (Sometimes this even works for a supermarket or a large chain store.)
On that front, people usually like to be heard so if you do a lot of listening that takes the pressure off you. Often a good sales call is 90% or more listening to the customer talk.
I've gotten good prospects through LinkedIn and simlar means and have had very good luck (much better than 80%) at sending a message or email and getting an appointment for a phone call.
If I have any challenge here it is that there are people out there who really like to talk and talk and you can easily wind up having an absurd number of calls over a long period of time and get no sales. However, almost always in B2B sales you will need to make several calls over a period of 2-3 months. Big companies lke IBM can tolerate a sales process that runs longer that, but you can't.
Ok, that wasn't helpful. So let me try to break it down, without knowing anything about what you are selling.
I will assume that your service is to solve some problem in a particular business domain. From that you can decide on who would have the problem you are solving and how critical it is for them. Hair on fire is good. Nicer typography on the menu - meh. Nevertheless, you can sketch your ideal customer. Potentially only a very small proportion of your town's business population is a possible prospect. Once you have identified the businesses, you could look at who in those businesses would be most motivated to do something about getting you to solve the problem(s) you have identified and are capable of solving.
Then you go an talk to the people you have identified. You listen more than you talk and refine your approach.
For a far more detailed approach you could read "Four Steps to Epiphany" by Steve Blank. Customer Development Method might be exactly what you need to help you maximise the productivity of your time when you are out of the office, talking with prospects.
If you provide some details about your business then some HNers might be able to give you specific advice.
- Include an invite for a quick 10-15 minute chat in the welcome email (more people than you would think actually take up the offer)
- Ask them why they signed up (this is key to help you determine what problem people want you to solve)
- Ask them their biggest frustrations about the solution so far
And just take it from there.
Then I'd call them up and chat.
At first I'd setup calls only with those who responded.
Then I began calling up people even if they did not respond.
Most people are happy to talk about problems.
"Hello, this is cosmorocket, and I'd like to learn more about your industry. Can I stop by sometime and ask you some questions? Perhaps shadow you for a little while? I'll bring coffee and danish."
Just watch and listen. If you see them get frustrated by something, give them a moment then ask "So, what just happened?"
Think of what you can do to support what your customers need to do rather than think of how you can get your customers to fill your pocket :)
I see the zero customers part. I would update my content marketing game until someone called me.
But on the topic of how to talk to people, I really want to recommend the book by Dale Carnegie 'How to make friends and influence people'. Ignore the corny title and read it. This book has changed how I talk to people.
The biggest takeaway for me from that book was that people love to talk about themselves. Make the conversation about them; focus on their situation instead of on your product.
First you need to figure out who you want your customers to be.
If your answer is local coffee shop owners, then it's easy to make a list of customers and you can call them, email them, or visit them in person.
There are many places on the internet that give free advice on how to do cold calls, emails, visits, etc. Steli Efti writes about it a lot on the close.io blog. There are numerous questions asked and answered on quora.
Start at those two places and once you know more of the basics, you can start learning more specific skills.
But if you don't know who to talk to, then you are trying to solve two problems at the same time: who to talk to and how to talk to them.
Solve one problem first, then the other.
Once you know who to talk to, then you can start talking to them to see if they have the problem that you are trying to solve.
If the service or product you are selling doesn't solve their problem you are not going to be able to sell it to them.
It's much, much easier if you are trying to sell to a customer base (market) that you understand well or already know some problems they face.
Then you can talk to them and verify that you are correct and they have the problem that you think they have.
If you are making software for restaurants, go sit at the restaurant during peak and off hours, and be keen about what's actually going on, down to the minute detail.
If the problem you are solving is in the kitchen, see if you can offer a hand doing dishes for free and observe at a detailed level what everyone else is doing and what their problems also are.
Asking questions in survey format could potentially work, though I doubt it. It could also be high barrier if you are basically a nobody trying to talk to restaurant owners.
The worst thing that can happen is people telling you they have a problem they don't actually have, and you create an imaginary problem to solve that nobody cares about.
The advice is good but often it means talk to your users. You can use it to validate your idea, but it is helpful to validate your product.
If you are building something be damn sure it's something people want this is hard if you don't know those people
Let me assume that you have a consumer product -- an app, or a piece of hardware. There are things out there that do something vaguely similar, but you think yours is better.
Go to the comments sections of various chat boards that are discussing the current way of doing things. Make note of the complaints.
Ask the people there if they will chat with you for 5-10 minutes about a product idea.
You might also find the UX book "Don't make me think" generally useful. I am mentioning it because it does talk about how to get effective feedback on your website. If you are doing an online thing, you may find it very pertinent.
Wrote to a bunch of strangers. Made it a point to stress that I've nothing to sell (not yet at least) and just want to talk and pick brain. Promised not to take more than 15 mins and never did. Most people never replied, a handful of them did and I had lovely conversations with them. One even became a friend (I referred her to the place I work) and we still keep in touch, even though the original reason I talked to her didn't work out. When I thanked one person, she simply said "no need, just promise me you'd do the same if a stranger reaches out to you".
From my limited experience, it is more or less a numbers game, unless you are willing to spend enormous amount of time looking for that specific set of people who is the perfect fit to help you. There is no guarantee that they would though (why should they? Everyone is busy with whatever they are upto anyways)
Improving here might be crucial.
Yes! That is exactly the point of the advice.
Go out in the field and you will learn something - because it will NOT be what you expected!
I am excited for you! Good luck!
* Windows ==> macOS
* Jira ==> Trello
* Stash/Bitbucket ==> GitHub
* MS Office ==> Google Drive
* Box ==> Dropbox
* Outlook ==> Gmail
* Skype for Business ==> no chat system
In almost all of these cases, one person (or small group of people) made the purchasing decision for many more people. Likely this was based on price, not utility.
I consider myself lucky that I never have to use Internet Explorer ever. Some people have to use it every day.
Currently we use Confluence for documentation, which, like many other Atlassian products, is lacking notable features compared to cheaper competitors. Other than that, we're great: Exchange, Slack, Github (including issues), etc
Google for Business or w/e would be great, but there is no way a company this size is gonna do that.
Bitbucket has native LGTMs (approves) without having to click the "Files" tab, the "Review" button, the "approve" radio option, then "Okay".
Ironically, I also hate using an office suite that is not MS Office 2003, including MS and non-MS products.
But that's agency management software. Orbiting categories like project management, kanban, communication and time-tracking have many good options but integrating them in a way that can "check off all the boxes" enough to satisfy risk-averse partners and controllers is difficult.
Ewon (industrial remote VPN)
Eagle (PCB design)
Onsip (all others I have used are bad also)
So much fail piled on top of each other.
The lesson, I think, isn't that corporations are dumb - it's that compatability has substantial value.
Jira. I just hate it. I despise it. What makes matters worse is my manager is a Jira fanatic. I think he is obsessed with it. One needs to shift in his seat "create a bloody Jira ticket". I, and many others, suggested simple ways to do things or even many GTDs. Many others teams use Trello and other tools but he has to use Jira.
Google Docs. Yeah, I don't like it either. Mostly how it's overused and abused.
Okta based login system. Logs me out every 30 minutes even though I choose to be remembered.
Intelliji or Webstorm or Android Studio. They are just bulky. I tried using other setups but since everybody else uses them it's difficult. (not forced to use these though).
KDB+ (but now I love it)
But every few months (weeks?) I see a post by a founder-type essentially trying to mine the Hacker News collective brains for startup ideas. It doesn't work that way. The best startups are ones that solve a pain point you yourself have experienced.
The idea of a savior who comes in and solving the major problems of an industry they have never worked in is not a myth but close to one. (Elon Musk being a notable exception with cars and space flight... but he has the capital to attract domain experts to fill in the gaps)
I'd point out the problems in my industry except I am actively working to solve them :)
With that said. Don't let a "know-it-all" on HN (myself included) tell you what to do. If you want to tackle a hard problem in an industry you don't have experience in, please do. You might be the next Elon Musk, I don't know you so I don't know.
If that wasn't your goal with this question... again I apologize.
I've said this a few times but we're going through a growth period like AAA video games have over the past 20 years.
I used to be that 2 guys could make a video game, then it went to 10, then 50, now its around 200 from what I've last heard.
Hedge funds are going through a similar shift.
It used to be that one person could manage data cleaning, and algo generation for a fund.
Then cleaning got split out into its own job.
Then the number of data streams exploded growing by a couple orders of magnitude.
Then the data types diverged so that each new data stream needs its own special cleaning, and normalization and even data storage, ie some data isn't suitable for a sql or non sql database storage, like satellite images.
Nowadays a typical algo fund might make use of 100 different algos for trading, each of which has 20 different inputs, some real time, some updated irregularly.
It takes those signals and weights them to come up with a trading signal, which then gets mixed with a portfolio balancing signals and risk signals.
It can be tough to disentangle each individual signal from the algos themselves so even things like detecting if a signal still has alpha generating abilities is tough.
You can have 10 people just back testing signals and monitoring risk levels.
And the growth of data and data sources isn't slowing down.
This is good if you are one of the larger players, see Virtu buying out competitor KCG, who previously ate competitor Knight Capital, yes that fund with the huge blowup, but not so great news if you want to remain a small, person wise, fund.
Not sure how to run a quant fund anymore with only 4 people. Not sure anything an be done about.
In the "good old days" where 2 people could make a video game, odds are that just shipping something guaranteed you'd make money. But that's no the case anymore now that 1000+ apps come out every day on iOS / Google Play. Of course most of those are crap. But you could be making a great game that caters well to a particular audience or niche, and yet you might still fail just because no one can find it or really just be aware of its existence.
The "simple" answer to this is marketing. Hustle your way to some visibility, partner up with some publishers or some platforms holders, and get as many eyeballs in front of your game as possible. However this effort is very close to being "zero-sum." Either you win and get your promo art banner at the top of the app store, or someone else does, but you can't both get it. It's less obvious when it comes to PR and having articles or game review written about you, but it's still there: with so much noise now on the internet, it's hard to generate a meaningful signal.
The harder solution is being tackled by the app stores themselves. Steam, iOS, etc. have all been improving the way games are presented in their stores. There's more focus on specific genre features, more flash sales, more suggestions based on what you already play. It's a decent effort but I don't think it's enough yet.
What can we do about it? Not sure. Algorithms that try to discover what you might like based on your previous purchases are nice and all, but most of my favourite gaming experiences were surprises that came out of genres I didn't expect (e.g. Rocket League), so this can only go so far.
2. Excessive costs, lack of performance among professionals
3. Change in attitude seems to be the biggest factor. If lawyers stop being about fighting and competing and persuading and more about tackling problems, getting to the truth and finding solutions, we can have a much better chance of succeeding.
There is a lot of opportunity for automation that no one seems to want to get involved in. A good example is document discovery which has been largely automated.
Other areas that could be automated include divorce. For example, in my jurisdiction what each partner is entitled to on divorce in terms of child support and alimony and division of property are set. There is some room to argue about custodial arrangements but not very much.
Given this - there is absolutely no reason to have many years of contentious divorce suits. If there was someone way of just entering the information into a computer and informing both couples of what they are entitled to and then working from there - I believe we would be much better off, because, although I haven't done alot of divorce suits, but in my limited experience it seems to me that lawyers certainly have a large role in exacerbating them and needlessly.
Already done successfully
* Reproducibility -- running code months or years later, on another machine.
Current tools, like VMs tend to be too heavy-weight. Docker is too hard to set up.
The main problem with these various tools is that exploration is slow -- Often I'll take an experiment, tweak it a few dozen times, then finally get the code for a paper. At that point I don't want to package it up, I want to be able to "freeze" where my last execution.
You might think that there's no shortage of phone Repairer's out there and your right but you can bet that 90% of them are self taught or eventually taught by someone.
Considering the amount of important information we store in phones and the price of the devices it has now become more important to ensure that your phone repairer knows what they are doing and of course has a reliable supplier
2. Most people don't like their jobs but suck it up. The 9-5 grind, climb-ladder, can't switch careers, lack of meaning, social pressure to have job. Getting laid off, searching new job, financial downsides of being unemployed
3. Restructure the job model/market (flexible choices, live comfortably, security)
Unengaged workers- Gallup poll on American workforce trends http://www.gallup.com/reports/199961/state-american-workplac...
3. SystemVerilog is not really at the right abstraction level and still has many of the problems that face Verilog. It is sort of what C++ is to C and what I need is more the equivalent to rust.
Homelessness is on the rise nationwide in part due to a serious lack of genuinely affordable housing. Among other things, in the 1960s and 70s, we tore down a lot of SROs. The Baby Boom generation was an anomaly. The unprecedented wealth of their parents was due to WW2. Yet, expectations from that era still shape housing policy and infrastructure, much to our detriment.
You do not necessarily need to be a construction company to play a role in addressing this issue. Another very serious problem is the lack of financing mechanisms for housing alternatives. For example, co-housing projects in the US tend to be self financed because we do not have financial products that fit them. This actively undermines their ability to add affordable housing to the system, a purpose they successfully serve in other countries, from what I have read.
There are, no doubt, many other things one could do to work on this issue.
2. Cost of launch locks out potential customers and limits R&D uses. Global launch cadence is slow; getting into orbit is a multi-year adventure.
3. Yes, we're working on reusable rockets.
However, this only goes so far. Personally, I think that more money needs to be put into non-rocket modes of space travel, so that there's some competition. The fundamental problem is that it takes so much energy (and, with rockets, so much mass fraction optimization) to get to space, so it's difficult to engineer things with physical margin.
If you could build a rocket like a car (just toss some more steel in the frame and call it a day, with no need for the obsessive mass savings), getting to space would be a bit easier. If you had a power source that doesn't shake and bake its surroundings, getting to space would be a lot easier.
2. Oligopoly just a few companies who deliver live results.
You would need a ton of cash upfront, to hire people who would watch the games and would press buttons in order to inform you about results so you could parse them and deliver live results which eventually would become a live API.
But as you can see, there are people involved in this, who watch all those games, if you can manage to automate this, without requiring too many people, you are a rich man.
Let's put in that way, almost everyone consumes their API if they are offline, we are offline.
2. I don't know if it's stopping the industry from growing, but existing communication tools (specifically chat, email) are a serious drain on attention and productivity. See http://www.paulgraham.com/makersschedule.html.
3. I'm working on it. Might be better tooling, might be educating people on how harmful they can be.
I think there's a massive opportunity to lower costs and improve user experience in every area. I wish Apple used their pile of cash to invest in a big vertically integrated healthcare service - a chain of hospitals, in-house-developed software throughout, improve user experience, integration and tech on every level. Basically healthcare rethought from the ground-up with Silicon Valley consumer-oriented mentality. Yes, extremely daring, but they're in a unique position to pull that off.
2.1 Access to energy / energy density of fuels (batteries included). This is the case across a wide range of industries and problem areas of course, not just transportation. But incremental optimizations in efficiency have lead to squeezing more performance out of the margins, but no Moore's-law type growth will ever happen without some kind of energy breakthrough.
2.2 Going forward, tightly coupled systems will be the norm. The traditional tube-and-wing aircraft with bolted on nacelles is a bit of a dead end for civil aviation. Systems to enable a more complex design workflow (e.g. graph based dataflow with accurate gradients) will be more paramount.
3. Research into the next generation of energy storage materials, and improved large-scale gradient-based numerical optimization algorithms.
2) A lot. Publishers relying on clickbait to generate money. Advertisers creating invasive ads with autoplay sound and video. Ignoring do-not-track requests as part of the industry (even if some technology providers respect DNT, it seems like a lot don't). Malware. A lot of useless metrics. Bandwidth usage. Etc...
3) Micro-payments vs delivering content only when an ad has been seen? Validating content delivered through exchanges. A better way to anonymize data used for tracking? Smaller ads. Honestly, I'm not too sure, there's probably a lot that can be done but I feel the industry did too little too late.
2. Product complexity, legacy IT & culture and regulation
3. Provide regulated banking services as a lean platform / utility, let others play on top
(3) is not easy to execute and no, blockchain is not the answer
2) Massive underfunding from central and local government; entrenched ways of working; incorrectly defensive working; dysfunctional cheerleading of incorrect approaches
3) Yes. Improve efficiency. Move to better ways of serious incident analysis. Challenge people who cheerlead incorrect approaches. Push for more funding, especially using Spend-to-Save data.
2. Seamless, lossless, low-cost interoperability
3. Doubtful. Many companies profit by providing custom products and services to address the problem.
2. Hiring Process
3. Replace meaningless whiteboarding interviews AND silly notepad algorithm questions, with a live coding interview on a laptop and a real development environment.
Companies would be surprised how fast and efficient the hiring process would be. They would stop eliminating a bunch of great candidates by running relevant technical interviews and not silly CS academic stuff. I can spend 3 month memorizing 500 algorithm solutions and nail all your 45min technical interviews. I would get an offer, a kick ass package and I would join your team. Then, on my first day I'd ask for help from my colleagues because I can't even setup my development environment. I'd write buggy code that doesn't integrate well and wouldn't be able to understand how to design a system. All I'd know is how to write text in a notepad and how to flip a linked list on a whiteboard.
But hey... I'm smart! And now I'm rich :)
Tenure is a huge cost to the university and not every professor is both an amazing researcher and an amazing teacher. So you have a chunk of the budget spent on old researchers while poorly paid adjuncts fill in for undergraduate classes. Not sure if fixable.
Politics runs everything. Broken clock Ayn Rand was at least somewhat right in Atlas Shrugged when she speculated that bringing about the end of money would usher in an age of pull. That's exactly how higher ed works: unless you can justify your work with student evaluations and big $$$ research grants, politics runs a lot of decisions. Not sure if ever fixable.
No two American universities are alike. Colleges within universities have major differences too. Good luck getting any real traction consolidating IT services. Everyone has different needs and cut-outs for their work.
Higher education is a hydra. It cannot be fixed or reformed at the drop of the hat or with the use of an app.
Abandon simple solutions, all ye who enter here.
3. More money.
In the publishing industry (where I have worked since 1997), the transition from print-only to print-plus-digital that began around 1999 and really got underway after Amazon released the Kindle in 2007 has finished. Now we have an industry in which print and digital co-exist (at different levels 50/50 for fiction, but more like 80/20 for non-fiction, and even less of digital for more complex product types like Bibles). Currently the growth area is audiobooks, led (of course) by Audible.
2. What are the biggest problems stopping your industry from growing?
Publishers have not really solved these problems:
(a) How to distribute very small publications and receive very small payments? We're still reliant on credit cards for payments, which pushes us to a smallest payment size of about $1.99 or so.
(b) How to increase discoverability? Most publishers are reluctant to post all of their content in a web-searchable and social-shareable form (for somewhat obvious reasons). However, this means that it's hard for them to draw direct traffic to their books.
(c) How to reduce reliance on the behemoth of online retailing? As physical bookstores have died away, publishers have recognized that they are too reliant on one distributor, which is a dangerous position to be in (as that retailer has shown itself very ready to use monopsony powers to bully their suppliers). Most publishers have direct-to-consumer selling operations. But (a) and (b) and other factors mean that they find it extremely difficult to draw traffic to their sites.
3. Can something be done about it?
I have been working on some of these problems in my business (http://blackearthgroup.com). Here is a sketch outline of how I would encourage publishers to solve these problems:
(a) Micropayments are needed, and to do that we need an online currency that can be used to buy content without going through the credit card processing network. Publishers should invest in the development of an online token that they would support on their sites. Customers could then purchase a supply of tokens and use them on publishers' sites to buy content. There are a couple of projects like this in the works. The simplest approach would be to create a coin based on the Ethereum network, and then support that coin for all purchases. (The hardest part of this is probably that the value of the coin would not be completely stable, because Ethereum is not, which means that publishers would have to either adjust their token prices regularly, or would have to live with variability in revenues to sales this problem is solvable, but it requires a lot of capital to create a value stabilization mechanism.)
(b) Publishers should put all their content online in excerpt chunks using non-discoverable public URLs, then submit it all to the search engines, and start sharing excerpts through social channels. It is true that some of the content would be given away, but that would be limited because each excerpt chunk would not be linked to the others in the same publication access to one would not grant access to all. Using full-content search and sharing is one of the best ways for them to draw more organic traffic to their own sites. (They'll need to invest in better discovery mechanisms on their sites, too.)
(c) Publishers have a real chance of building a customer base in their own content niches, if they invest in developing a content discovery and purchase experience that is significantly better in that niche than what customers experience on Amazon.
(Cross-posted to my blog: http://blackearthgroup.com/2017/04/20/what-are-the-greatest-... .)
2. Knowledge sharing within companies/organizations. Formal methods (primarily their absence). Effective use of simulations in design, development, and V&V efforts. Requirements traceability (this is mundane and seems bureaucratic, but it's critical here).
3. Yes, to everything.
For the first, break down information silos and project fiefdoms. Allow for greater flexibility for staff to move across project boundaries so knowledge can be shared more equitably, and people can see other teams work (learn both good and bad things here). Training. Make it a recurring event. Not the crap training many organizations do. Have a seminar series where people come in and present on something, not always directly related to work. Encourage people to write up their lessons learned, and perform and publish post mortems on projects. Take the approach of avoiding blame, focus on correctable errors and faults along the way (these are primarily process faults, not technical ones; where technical they're typically design and not implementation errors).
Formal methods and simulations are much easier to get started with today than ever. I'm not even talking about making a full-blown simulation of the final system, just high level "is this protocol sound" models. Presently working on radios. I don't need to implement a simulation of every detail of the protocol, I just need to know things like: If we add this new message, that must be sent so often, can it actually get broadcast at the correct frequency within the physical constraints of the radio? This turned out to be NO on one project I saw (not worked on), but not discovered until it was implemented (several man-months wasted). A message was supposed to be sent out every X time slots, containing N bytes of data. Each slot allowed you to send MAX size. Other messages also had to be sent out, say every X4 slots with size M. N+M > MAX, meant something wasn't sent. Both were mandatory, by design the protocol couldn't function. Another similar issue, though requiring a more complete simulation/model, was that one of the processors handling some of the messages simply wasn't fast enough. It was required to (worst-case) process N messages within X microseconds, but could actually only process ~N0.75 messages. Admittedly, this was worst case behavior, but by the system's design (protocol requirements, selected hardware, selected data bus, selected program design) it could not achieve the required performance.
The more complete the simulation, though, the better off you are. Technical solutions already exist, it's primarily an issue of finding good case studies or getting an amenable manager to sign off on trying it to demonstrate the cost savings (versus the typical approaches, which in my experience are often significantly late and errorful). Also being at the right stage in a project. Being at the maintenance end, constructing these models/simulations is harder than when you're taking on a novel project.
But, simulations also aid V&V efforts. If you can construct a full(er) simulation of the radio network, your V&V team can start creating test cases, procedures, and models and verifying that they're reasonable. From a protocol perspective, this is relatively easy on our radios, setting aside timing. So ignore time (as a strict concept) and instead focus on time slots. Create a simulation where each tick corresponds to one time slot, let computation run as long as needed. At the end, you'll see what should show up from the radios given some inputs. Run these through your data analysis tools to exercise them, and when you have functioning radios you can use these tools to create simulated network peers (pre-generated network data played back to the radio being tested).
For requirements traceability, just stop using Word and Excel. Use an actual requirements database. I know DOORS sucks, but it's infinitely better than Word and Excel.
I noticed in the videos that nothing ever goes in front of the animated objects, so they're probably not identifying objects, and trying to figure out object boundaries or anything like that. It's a simple, well-polished trick.
But just plain old analysis of "parallax" (things closer move faster etc) can quickly give you a workable understanding of the general geometry of a space.
The new MR headsets like Magic Leap and HoloLens likely use both types of sensors (like the kinect camera) to determine this stuff. But Snap just wants the widest push possible, and since it is not mounted on your eyes, the 'pixel stick' being off is not as much of an issue.
- Pick "unique" points currently in view
- Track how they move as the camera moves
- Combine this data with the accelerometer to get an accurate movement reading of the phone.
- You can get the depth of any point by comparing two images and knowing the change in user position.
Simple algorithm, but their results were astonishingly good. Snap don't need to model the entire room, they just need to work out where these points are to keep the image appearing still.
Do not be seduced by the technology!
I killed one of my startups this way. I've seen many many die this way.
It can hurt your pride as a passionate technologist to choose non-cool but mature and easy-to-hire-for tools. But it's those tools that are the most economical.
Remember, your customers care 0% about the backend technologies you're using as long as they are getting the value you promised them.
"Be regular and orderly in your life, so that you may be violent and original in your work." Gustave Flaubert
You're running a business, not a technological showcase for other engineers (who are not even your customers!).
Remember that the most economical tool for the job is often not the coolest or trendiest - but is some old boring workhorse that other engineers will scoff at.
Build your business for your customers, not for your technological pride or to demonstrate your technical prowess to friends.
Don't get me wrong though! There's certainly a time and a place to play with all the coolest and trendiest stuff, but if you're optimizing for growing a business, that is the time for choosing low-risk, simple, mature tools.
But some top tips stand out for me over time:
* Talking to people, networking > Not talking to people
* Bug free > Elegant code
* UX > UI
* Simple products that do one thing well > Complex products
* Understanding entire market > understanding some people
* Building brand > Making quick money (for the long run)
* Sleep, exercise & healthy food > late night coding
* Solving your problem first > Solving the worlds problems
* Adaptability, pivoting > Ego
* Knowledge of where the money is > No knowledge of it
* Overestimating cost/expenses > Underestimating it
* Patience > No Patience
* No procrastination > Procrastination
* Reading books > Not reading books
Business, like developing software, is a strict discipline, and there is a vast amount of knowledge that only comes from experience.
I found myself trying to do everything, until a friend taught me a clever trick:
1) Write down all of the tasks you have to do on a daily, weekly and monthly basis.
2) Write a short paragraph for each task's job description.
3) Write a job application from yourself for each of the jobs.
4) Contemplate why on earth you would ever hire _you_ for the job!
My advice is to work out exactly what tasks there are in running your business that you are not an expert at, such as accounting, sales and marketing, copy writing, etc. and hire people to do those parts for you. You'll see a return in no time... unless you don't... in which case your business model would never work.
Scream it in a loud voice, IF YOU BUILD IT, THEY WILL NOT COME!
You are going to have to build it, find them, plead with them, fight their refusals and shove it down their throat.
There are many unknown "unicorns" that currently exist as code. The code is done, there's just no users, because the world doesn't even know it's a thing and those that do know have not being convinced that it's needed.
My opinion, my advice. Forget the code, find the customers/market first.
A software developer with complete code and no customers is just a software developer.
A business person with tons of customers and no software/product is in business.
So decide if you want to be in business or to be a software developer. I suspect that most developers just dream about business as a means of escape from their day to day reality, but secretly don't even want to be in business, they love writing code more than being in business.
You need to get your company to 10k USD monthly product revenue within three months. If you can't, either the product, target market or team needs to be revised drastically.
It's hard advice to follow, but it will save you a lot of time because you can't wait months and years doing unessential tweaks to the product and marketing, hoping that sales miraculously grow.
It's also useful as a pricing yardstick early on. If you have very few customers, they need to be paying enough that you reach $10k almost immediately. If your product isn't worth that much, then you need to scale out. It's best to figure this out right from the start.
If it feels like you can't do $10k MRR in three months on your own, then you need to find a cofounder who can do it together with you... So it's a good way to calibrate cofounder expectations as well.
2) Banks will loan you money when you don't need it and won't loan money when you do need it. Apply for a loan or line of credit when you're flush with cash in case of a rainy day.
3) Running a business is a different skill than developing software. Be prepared to learn a lot of new skills.
4) Don't hire too quickly. Payroll + benefits can eat through profits like crazy in a software business. The counter-point is that a good salesperson will bring in far more revenue than they cost in salary and commission.
5) Know your numbers. You should have good accounting records and know from week to week if you are on track or slipping.
6) Don't hire a 'marketing' firm. They will charge 10's of thousands of dollars to ask you questions like 'What do you think we should do?' and then feed it back to you. If the product is positioned well with customers, you know more than the marketing company ever will.
7) Don't let a single customer account for more than 10% of your revenue. If that customer leaves, you'll be in a painful situation. It's difficult to do this at first but it keeps you from chasing a big fish to the detriment of the rest of your business.
8) A good reputation and word-of-mouth is better than buying the #1 spot on Adwords.
9) Figure out how to sell again and again to the same customers. A one time sale makes means a high cost of customer acquisition. Once the customer likes your company you should see what complimentary products and services you can sell too.
10) Once you've had a taste of the freedom (and stress) of working for yourself, it will be very difficult to go back to a regular job and work for anyone else.
1) Customers don't care about the technologies you're using, the elegance of your XYZ algorithm, or the novelty of feature ABC. What they care about is solving some problem they have, making their day easier, becoming more productive, etc. When you're pitching your product, talk about how it helps the customer, not about how it's built. A great 5-minute video on this is "Understanding the Job" by Clayton Christensen: https://www.youtube.com/watch?v=f84LymEs67Y
2) Think about monetization early on. Like most engineers, I had dozens of side project and business ideas. For each idea, I had thought about the features I'd build and how I'd build them, but not the business viability: who would I sell to? What would the pricing model be? How much money would that translate to for a typical user? Would users have the work/personal budgets to pay what I wanted to charge? Was the price enough to cover marketing and user acquisition costs? I haven't read it, but have heard that a great book on this topic is Monetizing Innovation (https://www.amazon.com/dp/B01F4DYY1I). Another good book to think about business models is The Art of Profitability (https://www.amazon.com/dp/B000FA5TTM, brief notes: https://codingvc.com/the-art-of-profitability)
3) Finally, think about marketing and customer acquisition in parallel with product. After almost 5 years as a VC, I can readily confirm that most products don't sell themselves. Even the really good products need sales, marketing, etc. A great book to get started on marketing is Traction by Gabriel Weinberg (of DuckDuckGo) and Justin Mares (https://www.amazon.com/gp/aw/d/B00TY3ZOMS/)
- Shoot for between 3 and 10 clients. Any less and you'll be very stressed about losing a client. Any more and you'll be overwhelmed with juggling too many balls.
- Fire bad clients. They aren't worth the stress, frustration, and opportunity cost.
- Work on your process. Doing an hour of client works earns you one hour of revenue. Improving your agency processes can earn you a large multiple of that.
- Don't be a <insert software technology> shop. Be a solver of a specific business problem for a specific type of business. Example: "We streamline backend processes for multi-million dollar trucking companies." The most valuable contracts are for solving expensive problems.
* Execution>Idea. Don't work on multiple projects till at least one is shipped.
* Pairing up with other like minded folks is better than going solo, but only if you can get along really well.
* The highs are higher, and the lows are lower.
* Develop good habits
* Make your first project a small one
* Failure (at least small ones) is not a problem. Failing to recover is.
* Sales and Marketing are very important. They need as much time as working on your products/ideas
* Start now, you'll never feel ready
This is the tl;dr version of a longer blog post I wrote about my personal experience http://www.dotnetsurfers.com/blog/2016/03/29/lessons-learned...
Your first MVP is simply a static website describing problem, solution and signup, with Google Adwords and analytics.
* Given that your target market are going to be ideally using Google to search their problem or solution, with Adwords, you can test exactly what they are actually searching for when they are looking for your product.
* Analytics will be powerful to measure the engagement of the user to your desired product. Have buttons or measure scroll for engagement. Do they read your problem and leave? Obviously not relevant. Do they continue onto your solution but leave? Wrong market-product fit. Have options on the website for easy A/B testing to figure out your demographic.
* Static website is super easy to change and make pretty as so many templates out there, and even if you don't use A/B testing tools, you note when you make changes, so you can compare sets of user analytics data.
This approach was popularised by lean startup methodologies, but what I love about it is it takes a couple of hours to setup, and an hour each week to tweak and monitor, and you'll know early on whether it's worth even developing the software from the very beginning. The saved time is worth the adwords cost (you can set a budget per day on their dashboard) and cost of static website hosting.
Build something, get it in front of customers as quickly as you can and get them to pay you. You'll likely need to do this multiple times to get the right product or features that people actually want and will pay money for. Skip anything nonessential at the start. Focus on the key features that customers will pay for. It will feel broken, but it's only broken if you can't get any customers. This seems like obvious advice, but you're a developer, it will be difficult for you not to aim for perfect before you ship.
Know going in that you will probably be embarrassed by your codebase, but it doesn't matter. When you find the right product formula and need to scale, you'll probably need to refactor or rewrite large parts of it anyway. Even if you build it "perfectly".
Whatever you do, don't use this time as an opportunity to learn some new language or framework. Use whatever you are most efficient with - now is not the time to be learning React/Vue/Angular or whatever else you've been wanting to get stuck into recently. If you can build it faster with mostly server-side views, then do that. Don't stress about picking a language or framework based on future problems like how you'll hire a team - worry about getting that far first. If you're a pro with PHP, use PHP - don't worry about others thinking you're less of a developer because you're not using Go or whatever the flavor of the month is.
Oh and keep it cheap and lean. Don't go building out a huge microservices infrastructure that you may never need. Build a simple monolithic app first and host it on a dirt cheap VPS. Once you get traction you can start splitting it out and worry about scaling individual services.
I've written a little more about this on Medium - https://hackernoon.com/shit-startups-do-episode-1-cbfa73f9c2...
1. Your idea and your software will probably not be aligned to your market needs at first;
2. Go out and talk to your customers;
3. Do not just focus on code;
4. When your customer really needs something that is not in your software, do not hesitate to bill this customer for special developments: it will finance the feature for all your customers and keep your feet on the ground;
5. CIO are overstretched by sales rep, so B2B sales cycles can be really long (at least in France).
Disclaimer: CEO of a French Cybersecurity software company.French market is known to prefer service over software and "On Premise software" over "SaaS". As a result, we switched from SaaS mode to On Premise, and we started with Penetration Testing to join the end of the month.While my advices might not be the best, we are in our third year of business and should finally reach profitability :)
2) Pick an idea that you would pay to use (product champion). If you are not the target market, you need to find a product champion who will join your team prior to the MVP creation.
3) Do things that don't scale. don't future proof your MVP, just make it so you can validate that your product has a market beyond your product champion.
4) Create a website for your MVP and make sure you can run it at low/now cost for at least 6 months before you decide to abandon. Marketing is hard and product discovery might be the biggest challenge you face. As long as you have more customers every month you are doing ok.
5) Even if you give your product away for free during MVP/beta, figure out some way that customers who want to pay you can. This is very valuable for determining product fit. if nobody wants to pay, figure out what would make them decide to, and use that for determining how to pivot.
source: myself, I made/make phantomjscloud.com
Let me elaborate on that a bit. Seeking more and more knowledge and wisdom in an effort to learn some kind of system or trodden path to success is understandable but can quickly consume all of your time & energy and likely won't provide much real value over the long term. Nothing, and I mean absolutely nothing, beats jumping in, doing stuff, being objective and introspective enough to identify what works and what doesn't, and iterating. What people are doing now will change. What people are using to do those things will change. What won't change, though, is the value of being able to take action and move through that world with confidence and resilience.
Reading, research, and listening to people is good but you should trust the laboratory of action above all else, especially over other people's opinions. Why, if you're a normal, intelligent, rational human being, would you ever put the opinion of some arbitrary person above what you can observe yourself? Because it's on the web or in a book? That's silly. Be extremely selective in who you allow to be your advisors - you wouldn't indiscriminately sleep with just anyone at the drop of a hat, would you? Don't just take advice from everyone, either.
Don't let people pigeonhole you, don't let people project their ideas onto your passion, and learn to identify where you should spend your precious time & attention - most of the time, you should spend those on action, not navel gazing and not "preparation" for action.
There are maybe a handful of books and blog posts that are really worthwhile. Once you have read those, everything else is simply other people regurgitating what they have read and is therefore not very useful. Also, on points that are very crucial, like legal and financial matters, I would hope you have an attorney and accountant to help you make those decisions - don't try to learn everything yourself and carefully establish and nurture your inner circle so that you can focus on - you guessed it - action.
I made this mistake in 2012 thinking that my product would no longer be wanted by 2016 and so didn't invest in expanding sales. 2017 has arrived and our sales are at an all time high and I have no idea when the market will start to decline. I lost a huge amount of money getting this wrong.
In my defence eveyone else in our industry thought the same thing and made the same mistake.
1) It takes longer than you think/imagine
2) Start smaller, no smaller still
3) Self fund for as long as possible
4) Be positive, stay positive
5) Identify people you can talk to about your work
6) Be honest with yourself, hard/brutal honesty
Thus technical debt, scalability etc. simply don't matter until you iterate your way to solving a problem other people care about. That's much better than solving a problem well, a problem that not enough people have.
Ie. in short, stop engineering software and start figuring out what people actually need. Not just 'nice to have', but a real need that causes real pain. To see if enough people need what you are planning to build - you don't need to built at all, just draw it out, explain it in a doc, and go ask people. You have to really ask them and push beyond their initial "sure yeah, it'd be nice to have". Ask them how they do the task / fulfill the need now. Ask them how much that costs. How much would they pay if you built a better one, etc. Really try to get a "no i don't actually need it" instead of being content with the polite lie of people wanting the product.
The other advice that has been invaluable to me is NEVER EVER reveal your salary to recruiters. Always state what you want to be paid and go from there. When you reveal what you are earning, you are immediately weakening your negotiating position. This may seem obvious but it would surprise you how many people just go along with their very invasive questioning.
I've seen what happens when you keep the product secret, trying to perfect it before you show it to the world. You'll run out of money making a pretty baby that no one wants.
A developer with marketing skills can build products and achieve revenues far in excess of their skill set.
I wish I knew that I could start saving and investing the money I was already earningand retire while still young. Your odds of success as an entrepreneur are basically zero. (I know some of you are going to do the startup or nights/weekends project anyway and I wish you the best of luck.)
If I knew this I could probably have shaved years off of my FI date.
* Look after yourself. The body supports the mind and vice versa. Neglecting one is neglecting both.
* Create a distraction-free environment. Co-working space, public library, converted garage/shed, quiet cafe. Only work from home if it is truly free of distractions & interruptions.
* You can't be an expert in everything. Focus on the value creating activities.
* Serve people, not problems.
* Solve problems, not people.
You won't get anywhere solving any problem.
Find a niche for what you can offer, and only go forwards once you've saturated that niche. For example, find a specific line of business that you're passionate about and approach them. Get a name for yourself and excel.
When I came to the Bay Area I knew I wanted to be entrepreneur but I also knew I had a lot of gaps in my understanding. The two big ones were sales and marketing, and the other end production and release. I took positions at established companies (Intel and Sun) to learn what these functions do in "real" companies. I then joined as an early employee a start-up, and learned everything I could about funding and equity and the unique environment of small groups tackling big problems. Then did it again and got to learn about the whole acquisition process, the challenges of taking things public (or not), and learned I still had a huge gap in what MBAs called the 'business model.' I went to work at a company that had an excellent leader and business model at the time (NetApp) and started internalizing what adds value, what doesn't, and what is and what isn't a reasonable way to look at things.
If I had to do it again, I would probably have gotten an MBA while I was at Sun (my second job). While there is a lot to dislike about 'MBA culture' that would have been a faster way to accumulate an understanding of how to evaluate a business to see where it could be improved.
Learn how to do sales end-to-end.
How to listen to a customer and understand their needs, how to market to those needs, how to convert those leads into contracts, how to bill those customers, how to make them feel valued and show value to them, how to upsell when the contract expires (how to get more value from them).
Learn sales. Mostly because it helps you understand the whole of a business, and will guide any prioritisation of your engineering like nothing else.
It turns out, you really don't need to build a great thing, you just need customers who pay.
- Some of that quick & dirty temporary code would be used for the next 18-19 years.
- I might as well have used PHP instead of Perl. Same (bad, messy) code quality, but even faster development and much easier hiring.
- Costly hardware early on was a waste of money (we outgrew it so fast that a beefy desktop PC would have been a saner investment at that point).
- Managing people is the one thing that you can't "fix" permanently. It's always an uphill battle unless (presumably) you're naturally talented/charismatic/psychopathic.
- don't bother with marketing people, advisors, business consultants early on and don't create product dependencies (e.g. by building a specific version of your product for others). It's not worth it until your product is polished and proven.
- Don't hire people carelessly because you don't want to invest precious time. Don't hire friends/acquaintances unless you've seen them working. Firing people is one of the most difficult tasks.
- Bad things will happen. Don't spend too much time trying to prevent them, or worrying to much. Just make sure you know what your options are when you need to put out fires and manage basic info (don't go searching for your hosting provider's phone number when you need it).
> Startups don't create new technology, they create new technology-dependent business models.
I wouldn't say this is 100% true, but it is probably 95% true.
4 years later, happy to report that I have a successful startup.
Disclaimer: in my experience small privately held companies do pay consistently and on time. Other kinds of customer, not so much..
- Be a train. (realized that I was 3)
- Be a breakdancer. (realized that bodies age)
- Be a DJ. (realized I liked employ-ability and stability)
- Be a classicist/anthropologist (realized once again that I liked employ-ability, and wasn't excited about becoming a Vatican priest)
- Be retired so I can go back to A. (still working on it.)
You may have wanted to focus on specific occurrences, but all my biggest/most unfulfilled "regrets" are by nature more long term, and don't have "easy fixes" as e.g. my dream of doing a cross country road trip, or starting a massive fruit garden (I've partially realized both those goals)
Some of the companies I'd be thrilled to see included:
AirbnbStripeUberLyftSlackRobinhoodPalantirSnapInstacartSpaceXGitHub DraftKingsWarby ParkerOfferUp
I'm asking because, in order for the new data to be useful, it must include both successes and failures, which would allow Jessica to test her hypotheses.
Ben Chestnut Co-founder and CEO of @mailchimp (aka mailkimp aka mailshrimp), seems a worthy subject. > https://twitter.com/benchestnut?lang=en
Min-Liang TanPaul EremenkoTravis KalanickBen ChestnutDaniel Stewart
For the most part, the stories were great but all revolved around folks who growing consumer/developer-focused companies.
I'd buy the 2nd edition in a heartbeat.
I dont know the founders but the idea that you could start the apts section of craigslist that out values real established businesses itself is a huge motivator.
Of course with close examination, nothing more than a repeat of near zero interest rate capital flooding a crowding market.
Some will strike the lotto, most will not. Hindsight bias is not at all being discussed here.
Tempted to try https://draculatheme.com/
Since I use both editors numerous times throughout the day depending on what I'm doing it's very convenient having both look similar.
But I switch frequently
> It has to scale to tens, possibly hundreds of thousands of simultaneous users
My suggestion : just use a database you are familiar with and start building. Most comment systems use a rdbms, so that's a safe bet. Use a graph database only if you find a strong technical reason to do so, not because another company is using it.
If you need extra performance later on, you can always add an extra layer.
I just used SQLite, but psql/mysql would work just as well. Handling comments, even threaded ones, isn't likely to be too heavyweight.
I made a handful of units for one company last summer, so the dev cost is covered already. I'd be willing to build a few more. How many do you need?
If you're thinking about the RPLIDAR, get it from DF-Robot and not Seeed Studio (DF have better shipping).
We're now sending the rest of the response emails. You should get yours by 7PM.
We interviewed in-person for W17 in October and got rejected because we didn't articulate a good plan for growth. - we grew 4,000% since October- launched huge features for both sides of our marketplace- received acquisition interest in < 3 months of being live- most importantly, made something that people are loving and using on a daily basis.
It's a bummer for sure but not the end of the world.
To anyone who got an interview,Figure out your biggest weakness and a plan for how you overcome it. Your interviewers will exploit it.
Here's some notes on our experience going through the interviewhttps://paper.dropbox.com/doc/YC-Interview-Experience-L45KzT...
Good luck all
Please check your post rejection applications - do you see these questions? Did you answer these questions, or does it look like they were added after submission? If I am wrong or misunderstand, I apologize. I submitted my application on 3/22.
I would even pay for it. I know that's absolutely not within YC's context and mindset, but I'd pay to just read one short line that helps us see what you saw (or hoped to see but didn't).
Would have our own presentation day, pitch feedback, try out each other's products, etc. I think it would be great! :)
I totally get rejection, I've been rejected for all sorts of things, but normally for rejection I can understand on some level why.
This I don't get. Not only are we applying with a company that fits with an RFS, not only is our team really solid, not only is concept proven, but we have a possibility to do real social good that both makes money and helps people.
Even in talking to other people, the reaction was either "why are you even doing YC" or "Sheesh I'm embarassed to by applying next to you". I know that sounds really arrogant, and Im sorry for sounding like that. I'm just...confused, I guess? I really wish that the applications came with a reason why they were rejected, even if it was one sentence.
I can't honestly believe that typing a one sentence "rejection for reason" would take that much extra time. Even a drop down of "we rejected you for this one of the following 5 canned reasons" (your team was bad, your idea was bad, you have no revenue, etc.) would be helpful.
Is it because my cofounder is from another country? Or because we don't live in the bay area?
I seriously do not understand this. I know that sounds a little bit whiney, but it's just frustrating to have put this much emotional investment into something and to get rejected for it without even a brief explanation of why.
: For people that don't live in the bay, applying to this program is a big deal. I skipped out on events next week because we might have to block out time for an interview, I moved things around this week specifically so that I could schedule an interview if possible, I moved things around this summer so that if I needed to be in SF I could etc.
I get not counting your chickens and all of that, I don't think we did. Nothing is lost for us here, and moving events and things around isn't a big deal, obviously that is just part of doing business. It is just frustrating to get a rejection email that doesn't even include a few seconds explaining why.
Forever onward, obviously. It just really sucks not having feedback on why you were rejected.
As I read through the comments, I believe many businesses forget the fact that business is ran by the numbers. Yes, can YC help you get attractive numbers for investors, but you can do the exact same thing on your own if you build something people need (love). I find it hard to believe that any investor that YC can introduce you to will turn down your meeting if you have built a business that has attractive numbers. That's what they look for anyway...YC funded or not.
For those that got an interview, congrats. For those that didn't, keep going and be great in what you are doing.
Till then have your lunch, breathe, work on your product and check your emails later this evening. :)
Anybody else in Phoenix? My cofounder and I are going to hang out and get some beers/lunch together while we try to wear out the refresh buttons on our laptops if anybody wants to join us.
When will the invites/rejections be sent out anyway?
If you have a SO though I've no data on how well it would work out. :'(
In the UK you can find smaller companies hand making them with only natural layers (and telling you what each layer is made of!) offering 10 year guarantees. They're not cheap though, you're looking at minimum $1,500 and easily $3,000 for a larger size.
I've also slept on an expensive latex mattress and it gave me shoulder and lower back ache. Initially it felt great but the pain started after a couple of nights.
http://www.sleeplikethedead.com/bed-mattress-review-home.htm... might be useful
My present mattress is a firm Tempur Pedic mattress. I probably could've gone with anything of similar firmness. I live in a one-bedroom apartment. I give up my bed for (most) company and sleep on the couch, I got a softer topper for it (can't remember the brand) that some people prefer to the firmness of my bed.
There's an old-school outfit in NYC called Dixie Foam that sells amazing firm latex mattresses and toppers. (They also sell less expensive polyurethane mattresses, which have a slightly different feel, and are warmer, but come in both softer and even firmer modes. You might combine a poly mattress with a latex topper.)
And I really like the latex foam pillows from Talatech/Latex International, which I could only find online at one place.
 https://dixiefoam.com http://www.sleeplikeabear.com
It's an amazing piece of materials science, and it feels luxurious as hell, but it was waaaaay too soft for both of us. She woke up in considerable pain. Also, it was pretty hot.
Fortunately, the Leesa customer service people were awesome, and they immediately took it away again and refunded us.
This was once my plan.... a year later I was still sleeping on the first one I bought. :P
There was a more recent version, but it seems to be down.
Best sleep ever was on a king size mattress at a high end Marriott before they switched to foam toppers. Avoid "memory" foam at all costs if possible.
Invest in a high quality latex mattress topper and pillows. As long as you don't have an allergy it will change your life. If you have lots of money to spend, full latex mattresses are amazing.
Do you have an email record of your booking confirmations? Why not ask the hostel/hotel/bnb operators?
My wife and I ended up with a foam mattress, which we really like. Our only complaint is that it's noticeably warmer in the summer than our previous regular mattress.
You need to figure out whether you prefer a soft mattress or firm. You could go demo a Sleep Number in their store and see which level is best.
After a trip to Japan I found sleeping on a futon was the best sleep I've ever had. After returning home, the first thing I did was buy a roll-out futon. Been sleeping on it ever since. It's cheap, I can store it during the day to "reclaim" space in my room.
I'd probably do just as fine on a firm mattress - but the futon is cheaper than a mattress. I can also roll it up and take it with me when visiting friends or relatives who do not have the luxury of having a "guest room".
I don't miss my bed.
"How much will this cost" should not be calculated as an afterthought, but rather from the beginning, at the same time you're answering all other architectural questions.
If you've calculated the cost from the beginning, you may as well track costs in your monitoring code and metrics system. For example if you've had 10 VMs running the last hour, log the price of them to your metrics system. Then you can graph prices along with any other metric and see how bottlenecks drive cost.
Try to anticipate the bottlenecks of your system, and see if there's an easy way to avoid AWS for those components. That is, if you're an image host, you probably don't want to pay per GB of bandwidth at AWS when you can pay per capacity at any dedicated/colo provider.
70% of the money will come from the enterprise/offline sales you do and the rest will come from your website.
- On-boarding and acquiring new clients is still a lot easier than sustaining/retaining them. A lot of us focus too much on marketing, getting new clients etc. but not on sustaining them. For some businesses, that works but for SAAS, customer retention is a big deal and really hard.
- Every month, a small percentage of Credit cards will fail to renew the client's subscription. Sometimes it is just the banks being stupid, sometimes the cards expired or reported stolen. You need to have a process to ensure clients are aware and fix this asap. Fancy word for this is "dunning"
- Unless you have a solid team with good funding, offering a free or freemium version will be difficult for you since you will get tons of tire kickers and time wasters. So you will be spending too much time talking to them when they are probably not going to be paying customers anyway. Hint: If after 2 discussions/emails/calls, someone still asking questions are most likely the ones who will never convert. Yes, there are a few who take time but in my experience of doing this for 3 years now, I almost know who will convert and who won't.
- Not all clients are same. You may have to be partial at times depending on the client. For example, some clients just want the whole world and don't get the idea of a SAAS. Learn to keep them in check while it is ok to pamper the good ones a bit more. Hint: Keep track of support emails/questions/tickets for each client. If you see too many unreasonable requests from a client, be polite but frank with them about what is possible vs not. Often times, clients mean well and just don't understand why a feature cannot be built just for them. It is your job to explain that to them.
- Reduce friction when it comes to on-boarding. A lot of clients leave because they find it difficult to get started. This is not the same as building an easy software. This is about ensuring that your clients learn how to use that software when early on. Documentation, FAQs, Guides whatever you call it. And no, don't listen to people who say that only badly designed software needs documentation. Everything needs documentation. Trust me.
- Backups. Remote backups. Not on the same server. Don't take this casually.
- Learn to Sell. Only way is to actually do it. Don't "outsource" your sales specially in the beginning. You being able to convince someone that your product is worth it is what matters.
- If you start growing and think you need to hire, be very careful. Hire really slow. Fire really fast. If you can, hire a freelancer/sub-contractor instead of full-time. Then go from there as needed.
- You will need to do some basic accounting yourself to understand your business numbers. Learn how to create a simple PnL statement. If you don't know, talk to a good CPA (or equivalent in your country).
- If you are making some money, don't forget to incorporate AND also hire a good CPA if you can afford. For small businesses or SAAS products, a good CPA can cost anywhere from $500-$2000 for the entire year (depending on what you ask them to do)
Finally, I will leave you with this. Running a SAAS is awesome once you get a hold of what matters and what doesn't. You will learn with experience and probably make a few mistakes. But don't give up and keep fighting. Nothing is better than seeing recurring payments hitting your bank every month and knowing that you are providing value to some people in the real world.
It takes great to get liftoff. The bad ideas aren't the hard ones. The hard ones are the good ideas .. Maybe people are paying. Maybe they even like it. Sadly good isn't good enough in SaaS. For a SaaS product to really win it needs real, measurable velocity.
If I could offer one big of insight I've managed to pick up - genuine traction in SaaS is hard won, but then it's really (really) obvious. If it's not slapping you in the face, then time to change tack. Maybe that's a tweak or it's a pivot, but keep trying till you have that clarity.
Focus on sales. Did I say sales? Have you ever sold anything? Did you write your prospect list and started setting appointments?
Sales. If you are bad at those, anything else wont matter.
The kicker is, how well you do on the 20% determines how hard your 80% will be.
On the other hand, if you want to have more control in the long term, I can recommend to use Hugo  as a static website generator.
They have plenty of themes  to choose from. You can still adjust it with basic knowledge in HTML/CSS. Afterwards you can chose where to host it. You can use Github Pages  for free or pay for a service like DigitalOcean . I wrote a technical cheatsheet  on how to setup your own website with these ingredients.
-  https://gohugo.io/
-  http://themes.gohugo.io/
-  https://pages.github.com/
-  https://www.digitalocean.com/
-  http://www.robinwieruch.de/own-website-in-five-days/
Having your site content live in the git repo instead of a database is amazing. In fact, this is the approach taken by most documentation sites these days. It makes it so much easier and faster to make changes, updates, and experiment. I use Netlify as a static host; they have features to make any commit, pull request, or branch into a hosted preview. It's an awesome way to work.
(For less technical editors, you can plug them into the process with something like NetlifyCMS, a clever open source project from the same folks that basically is a CMS interface running on git / github.)
I've been hearing a lot about Hugo lately, but my main concern as a blog editor with static website generators is the fact that they are great for, well, static content. If you want to update your site with new content and features (posts, pages, sections, widgets, comments, web statistics) WordPress make that easier.
On static websites generators at least the ones I tried a couple of years ago, octopress/pelican/jekyll these systems are great if you want to just have a good/superfast landing page and a few other pages laying around. Once you want to add new pages and posts you had to recompile everything again, something that wasn't a good idea with sites that grow dinamically through time with hundreds or thousands of posts (like my blog, for example).
Please let me know if Hugo (and others) solves the "recompilation" issue to rebuild the site each time, I'm probably wrong or not updated here. In your case it seems that static website generator could be a good fit though.
Squarespace is really nice too, btw. Good attention to design and detail, not so versatile as WordPress.
P.S. This is from working with Joomla, Drupal, and Wordpress sites in the past. Static sites are the way to go.
One example. ConvertKit is killing it these days, right ? See their marketing website. It is WordPress.
this is one of the few times that the right thing is also the easy thing.
Basically, how important is human involvement in your sales process?
If it's really important, focusing on your website at all is probably a waste of your time. Just choose whatever involves the least amount of work (probably SquareSpace or Launchrock) and crank something out quick.
Revisit it later when the website is actually interfering with your sales.
So far the best options look like WPEngine, Wordpress.com, or Pantheon.
I've also worked with Squarespace and would caution that developers can find it to be frustrating--requires a lot of hovering and clicking to configure pages and post content. Not really a fan now--too much of a pain.
If you want other non technical people to edit or make changes, choose a CMS.
Your goal is to get your message out there asap so you can solve problems.
End of day, the customer doesn't care, only you do. You can always change it later.
However use other things for your SaaS platform, WordPress is too slow for that kind of thing. Instead go with something lightweight like Slim Framework.
You don't have to have WordPress as the go-to resource for everything, but also you don't really have to roll your own CMS every time you build up a site, which is quite a time consuming task.
Grav offers a light experience to a CMS, and you can decide if you want to just work with markdown files, or rely on the Admin panel for easier editing.
(Disclosure: I'm a dev team member).
The Algorithms and Data Structures course is one of the foundational courses of a CS degree. Even if you think you don't need to be able to implement the algorithms you learn in your work later on, it is important to have some idea of which algorithms exist for a given task.
Also, and perhaps even more importantly, understanding how these algorithms work really hones your problem solving skills. You learn how to abstract the information given to you as part of a problem into an appropriate data structure, and what kind of operations you can carry out with which data structures. You learn how to cope with several different layers of abstraction and develop an intuition for programming approaches that are fast and/or light on memory. Basically, the ADS course doesn't teach you how to be a programmer, but how to think like one.
As for studying for this course: there's nothing like doing it yourself. Chances are, you already have to do so anyway as part of your course work. Take the programming tasks seriously and really do try to do it yourself. (Get friends to help you by all means, but don't let them do the work for you.)
I would advise you not to slack either: based on your information and the ADS course at my uni, I'm guessing that you're still at the very beginning of your degree. It isn't going to get easier in terms of workload, and the algorithms you learn about later on in the course are a lot more complicated than those at the beginning. But if you've made the effort to understand the first bunch of algorithms, you'll be in good shape to understand the latter ones too. So yes, it is hard work, but you can do it :-)
1. Merge sort. Given two sorted sequences, they can be merged in linear time. Given an algorithm that does so, we can sort a list in O(n log n) time, as follows: split the list into two equal halves, merge sort each half, and then merge the result. (The base case is that sorting lists of length 1 is really easy.)
2. Insertion sort. Let's say you want to sort in increasing order. To make things concrete, let's say your given list is
[3, 1, 4, -1, 5, 9, 2, 6, -5, -3]
You start by walking through the list: 3, 1, ... WAIT. That's not right, 1 should come before 3. Let's drag it to the front of the list where it belongs. We now have:
[1, 3, 4, -1, 5, 9, 2, 6, -5, -3]
Now we again walk through the list: 1, 3, 4, -1 ... WAIT. What's -1 doing here, let's drag it to the front of the line:
[-1, 1, 3, 4, 5, 9, 2, 6, -5, -3]
Again: -1, 1, 3, 4, 5, 9, 2, ... WAIT. What's 2 doing here, we need to drag it forward, but not all the way to the front:
[-1, 1, 2, 3, 4, 5, 9, 6, -5, -3]
And so on. Is this what you meant by essence?
When starting out you'll be learning, for example, the different sorting algorithms in great detail. This isn't terribly useful later on (the level of detail at least). What is useful is that they each have a shape, a style of functioning. Merge sort as one of the quintessential divide-and-conquer algorithms provides an excellent template for other algorithms with the same shape, but meant to compute something different. While bubble sort is a terrible sort algorithm, the pattern of bubble sort for computation is present in numerous algorithms. Same with insertion sort and shell sort and the rest.
It's like language acquisition, or at least like language acquisition is for me. When learning Spanish, I learned a lot of specific instances (hablo, hablas, habla, hablamos, hablan as 5 distinct things). Then I learned the pattern (grammar rules, -ar verbs generally drop the -ar and -o means I <verb>, -as means you <verb>, etc.), then I focused on root words in vocabulary (hablar means to speak) rather than memorizing every conjugated form of a verb.
Same as physics and calculus. Learn specific cases at the start, then you learn the rules, then you apply the rules to new forms to construct novel (to you) solutions.
And as others said, code. My algorithms class didn't require much programming, technically, it was rather high level. But I coded everything I could to try things out and understand them. Sitting down with pencil and paper to understand it was sometimes helpful, but the act of coding was more effective.
EDIT: High level in that it was focused a lot on the maths of algorithm analysis. I had one earlier in college that was more practically focused, on implementing algorithms, but the one that really stuck with me was the later one.
However if you still want to study them, there are plenty of resources online, like this youtube channel.
Taking 2 days to understand insertion sort is fine but you just need to practice learning more often and use the things you learn more often. Even if it's on toy projects.
Here is one interesting (maybe too long) answer:
points / age^2 * a-lot-of-penalties
A more detailed (old) discussion is in: http://www.righto.com/2013/11/how-hacker-news-ranking-really... HN discussion: https://news.ycombinator.com/item?id=6799854 (920 points, 1240 days ago, 190 comments)
The algorithm is tweaked from time to time without warning, so many details may have changed since this was posted ~3 years ago. But the main idea is still there.
1) first, grab a real pen(cil) and paper (even if it's scrap), sit down somewhere comfortable, and take some time to write down what's bothering you. How it makes you feel, and why, and what you want to do about it, and everything that's been running through your mind about it. Until you have no more to say. This helps your mind feel like you have given the problem the attention it deserves.
2) write down 2-3 finite, specific tasks that are important for you to get done today, and that you know that on an ordinary day you can complete all of in just half a day. This is a point of focus for your workday. Even if you accomplish nothing else, completing these tasks should be considered a victory on a bad day.
3) take a walk or meditate for 15 minutes to clear your head and refocus. Don't beat yourself up if your mind wanders or even returns to what's bothering you, but if you can empty your head, do. The purpose of this time is to create a mental break between the thinking about this problem and thinking about work.
4) don't force yourself to start coding. Do force yourself to open up your text editor to the place you need to be to get the first of your 2-3 tasks done.
5) if, at this point, you're still unable to code, take a mental health day or two. Focus on taking care of yourself, because you'll be more productive tomorrow if you heal yourself today.
At my company, I switched over to our new stack (all ReactJS) at the end of last year and then had a whole bunch of personal/family drama hit me right after. It was so overwhelming I had to ask my supervisor to move me back to our old (Ruby) stack. I'm grateful he did. Not having to suddenly learn 10 new technologies at once gave me back the mental space I needed to deal with the other stuff.
I am going to take a small break now to mindfully approach all the problems and think of what I can do to solve them today. If there's nothing I can do today, I can at least know that I did whatever I could for now and can move on from the thoughts temporarily.
Listening to music which you usually listen to while programming can put you back in the zone, if the problem is not too serious or not too distracting.
I find myself more energized getting straight to work after a run.
Hope you work it out
- take some time off
- work out
- do free expression exercises
For suggestions, it's going to depend on what type of problem it is.
For a short term (or not overly personal) problem, like extended family issues or similar, take day off and either:
* Sort out the issue (if you can)
* Relax - just taking a day for yourself and doing what you feel like doing (even if it's lying in front of the TV all day) can do wonders for your mental state
Like another poster pointed out, the issue can be more productively dealt with or processed with a dedicated day, rather than trying to do it inbetween work commitments.
For longer term issues (serious illness in immediate family, relationship problems, etc), there is no surefire way to deal with it, but there are ways to make it impact your work less (note: it WILL impact your work - the goal is to make that impact as minimal as possible). Keep in mind that your health and mental health impacts your ability to work and provide for yourself (and family). Protect this at all costs, and remember that family responsibilities should come first (any reasonable employer will understand this to some degree).
Some things that worked for me:
* Inform a superior that you trust about the issue. Tell them that you will do your best to minimise impact on work, but it's important that someone knows you're not just 'slacking off', but dealing with problems. Ideally, this is someone that will have your back.
* Talk to someone, be it a friend, professional, family member, etc. Talking to someone helps you process the issue quicker, and takes some of the worry off your shoulders.
* If you have elements of your job that involves close interaction with other people, do those. Interacting with another human (with the knowledge that you can't let them down while working with them) is a quick way to focus, and also has room for lighthearted interaction, or deep technical discussion with someone to take your mind off things.
* Focus (in the short term) on things that you're good at, and can do almost 'mechanically'. If you're good at coding, but hate documentation, do the coding. If your superior knows what's going on, they'll understand.
* Find things that are mechanical to do - if you need to test things, and there are test plans and procedures in place that you can follow systematically without too much thinking involved, do those.
* Meetings. Everyone jokes about them, but they are good in this case (unless you have to prepare/present them).
* Lower your expectations for daily output, so that you are not disappointed at the end of a day. Do, however, try and absolutely stick to these lowered expectations. Start small with tasks, and once you're in the groove, keep running with it. Try your best to not overthink things - break them down into small, manageable chunks.
* Try and avoid unnecessary interruptions when you're in the zone, because at this moment, it will take you much longer to get back in the zone.
* Try and avoid things that will remind you of the issue while at work - deal with them after or before work. Do not check personal e-mails, etc. Obviously this is not applicable in all scenarios, but helps for things that you can't do much about short term.
* If it all gets too much, take a day off, and relax. A 'mental health day' can buy you another month work of mostly productive work days.
I hope this helps!
Change the way you think about programming problems: Haskell
Enterprise Development: Java. Maybe Scala?
Apple Ecosystem: Swift (and actually, it seems like a kind-of pleasant language for general server-side use).
Low-level: C++. Or maybe Rust (although not yet given that a serious whirl)
Edit: oh, if you're broadly happy with JS, Typescript is worth a look and might (depending on your circumstances) be something you can start using day-to-day fairly easily.
If you're a pragmatist it's still a good choice. You can bring FP concepts to C, Java, whatever later on too.
C / C++ if you're looking for something with wide applicability to learning other languages more quickly.
If you want to focus on backend technologies, I suggest Java.
If you have other goals, I think there are a lot of other great answers. :)
For learning new paradigms I would either recommend Haskell for a "strict functional" path or Rust for an "immutable/non-racy" approach. Both languages take the concepts to a pretty extreme level and may feel overwhelming at first, but they can be brought back to your existing back-end development skills to help enhance the maintainability of your code.
For something between concurrency and functional programming I would recommend Erlang/Elixir - though I do so only from recommendations and not from any meaningful experience with either. Might be up your alley and definitely worth at least considering for your "one language".
If your goal is getting a job, looking around in your technical and geographical area and see which languages are used most, which pay the most, which will result in the most interesting jobs.
If your goal is purely educational, try Haskell: you'll learn about functional programming and use a much more powerful typing system than most languages provide.
C# because I love it after experimenting with a lot of languages ( VB.net the first and c# second though, I'm a bit biased) and typescript because it will improve your current nodejs writing.
Both are closely aligned and I think it's perfect in your case. Start the next project with typescript and change to c# later for another project.
Also, there are a ton of projects to learn from. But other than that ( a lot of languages have great examples), there is a lot of employment in c# and it seems to be a sure bet future-wise.
Ps. CMS -> Umbraco. Webshop -> Merchello. It's like woocommerce and WordPress but easier and cleaner
If you want to pick up a language as quick as possible then C# or Java. Either choice is fine.
C# has a lot of potential in the future now Microsoft are making it more open with multi-platform .NET but it is still a way off IMHO.
Java is used everywhere and while it isn't all that "cool" it does work well, is easy to write, debug and maintain. Plus I actually quite like JavaFX. It allows me to make a nice looking UI very easily. As great as C#/.NET is you can't use C# for any decent GUI stuff outside of Windows just yet.
If you want to get a job then look at what jobs in your area are using.
Are you planning on making an IOS app?
Do you want to make a back end server?
I picked up Go for my side project for the server side, and it has been a great learning experience.
I think if I were to do a mobile app, I might try Swift.
Useful for writing back-ends? Java. (Maybe Go.)
Useful for learning about type theory? Haskell.
Great language that has stood the test of time and runs on Windows, Linux, OSX, and sometimes Android and IOS.
F# is similar to oCalm, still can do the things C# do, still you can use C#, still you are using .NET.
That is a lot of plus!
The main downside is the smaller job market.
BTW if you use PHP/JS, C# will not teach you much. Is also "OO" and much code around, specially old or coming from the corporate world is not eye opener.
PHP/Js are less well designed languages, that encourage and celebrate bad practices... but most decent developers learn to workaround that and coming to other languages will look at first like "same".
Require some study and effort to see how much C# is better.
In contrast, F#, Pascal, oCalm, Haskell, Rust, etc will open your mind and increase your skills, because will move you out the comfort zone.
If you want to stay in the computer science realm, I would recommend C#, C++, or Go. All three have the critical mass to be dominant languages in the next decade.
Kotlin comes in second place if you like Android and their mobile ecosystem.
There are many other languages that will teach you valuable things; buy if you're asking about one, or at least the first one, C# is definetly the best choice. When you'll come from it to Haskell or Rust, you will already be equipped with a habit for OOP and static typing, and will not face a frustrating cognitive overload.
If you don't want some of those attributes, then Rust probably isn't the best answer for you.
That said I have a lawyer edit my IP agreements to scope them as tightly as possible to the company, instead of signing the broad "we own everything you make even outside of work". For some reason most devs seem to just sign them without realizing they have a say in the matter.
In my contracting work my lawyer added a clause about things that I create in the process to make my job easier so that no client owns those. There's a technical term for this but it's slipping my mind right now. It covers things like writing your own code generators and automation scripts that you might use with multiple clients but are not a part of the work product.
There's a lot of focus in the law about core types of IP that are protected by statute: copyright, trademark, patent.
It is quite possible that the type of cool technique you develop while doing code for a customer wouldn't be protected by copyright, trademark, or patent law. But most customers probably want you to enter into a contract that governs ownership of IP.
By contract, you can protect certain types of IP that, for example, wouldn't be subject to copyright protection. Depending on what is in your contract with your customer, you may end of inadvertently winding up with your customer "owning" any technique, idea, know-how, etc...that you come up with in the course of performing services with the customer. ("Owning" this type of IP is not the same as "owning" certain other types of IP, as concerns 3rd parties. But that's not particularly important for your question.)
Even if the customer couldn't sue you for copyright infringement for using a technique they end up "owning" by contract, they might be able to sue you for breach of contract or trade secret misappropriation, depending on how you use the technique and its value proposition to the customer. Or, if the technique is patentable, they might be able to apply for a patent covering the technique and prevent you from using the technique that way.
There are a number of ways to work around this in your customer licenses. How, exactly, depends on what you are doing for your customer, what your customer does, and your negotiating leverage. But it's certainly doable and happens everyday.
If, in the middle of a project, you suddenly change brace style in your code? Nobody will care.
If you invent something like map-reduce? You can be sure the customer will own that invention.
There's a huge spectrum here. Lawyer up.
Email is the least-intrusive way for me to be contacted by people outside my organization. Some of them I do want to hear from and will be happy to transfer to a more synchronous or intrusive communication channel. Most I don't. Email is the best medium I have for screening those contacts.
Then there are marketing messages and announcements from platforms I use. I like having those pushed to me in such a way that I can easily ignore all but the 3% that are actually of interest.
And notifications. Yes, if a server is on fire, I want SMS or slack. But if someone's added a new ticket to our issue tracker or needs a pull request reviewed? Email is very effective for going through such notifications one at a time at one's leisure and dealing with each in succession.
Finally, there are the occasions where I want to share a big chunk of text with a bunch of people who may or may not be using the same platforms for other communications. It might be an announcement. It might be a list of questions for a vendor. Whatever it is. Email is very effective for that.
Now, what do you propose we replace all of those use cases with?
First is reason nothing goes away at most big companies: if it ain't broke, don't fix it. It's something they understand, they're often lay people who might not want to learn something else, they might have tons of stuff built on top of it (tech or processes), tons of important information stored in old emails (it's archive medium, too), and they'll get emails from other people anyway. So, why not keep using what you've been using.
A few others I hear occasionally on top of that big set. One that I like is that it's asynchronous. They can put emails off easier without it seeming like they're ignoring people. Managing it is fast and easy vs some web apps for communication. The security might be perceived as better esp with security software they likely have for email & data breaches they see on other things that aren't intranets or Gmail. It's decentralized, vendor-neutral protocol which existed for ages (stability). Bosses in smaller firms even use it straight-up as free alternative to paid chat or archive tools if it's Gmail. Just to avoid paying anyone past the ISP which is also cheap or someone's Wifi haha.
So, there's a few I've heard that tell me email ain't going anywhere.
Unlike something like FB, or Google, that grew up building out their defensible data assets and infrastructure from a for-profit perspective, email infrastructure has been baked into the internet since before the web ever existed.
It's not the whole picture, but try replicating the functionality of email with "something better" without replicating the whole infrastructural advantage it has? Good luck.
So: What would be better? Given that the world currently runs on email, what would be enough better that it would be worth it to switch? I don't know. I don't think Paul Graham knew then, or knows now. And I think that the reason people haven't switched is that, so far, there isn't an alternative that's enough better. And the reason there isn't one is because, contrary to Paul Graham's expectation, creating something better is actually pretty hard.
1. Your age is NOT an issue
2. Many professional developers do not have Mastery in any specific language. That may be sad, but it is a fact.
3. The biggest difference between what you've done to date and being full time is finishing. By that I mean having the stamina, interest or sheer bloody-mindedness to finish medium to large software projects. Starting is fun, scripting is fun, algorithms are fun...slogging through hundreds of modules, building interface after interface, implementing api after api, creating tests for everything can become very much like ... hard work ...
Then, you say you are/were an administrator. I say that this is a very, veryconvenient position to do programming. (1) You have tasks that warrant writinga program; (2) you will be part of your own audience, so you know when yourprogram is good enough and what the heck should it actually do; (3) you'renominally not a programmer, so nobody will expect you to adjust your toolboxto the company's vision. Language choice will be your decision, so if you deemErlang to be much better for something, you write Erlang, not C# or Java justbecause the rest of the company uses that.
I am such a sysadmin myself (was? my title now is "programmer/Linux systemengineer"), so I speak from experience. Most of my day is spent on writingcode for managing systems, not on administration itself, though I do some ofthat, too. And there's a lot of tools that would be helluva useful forsysadmins (or for me, at least), but they are not written yet and I don'texpect regular programmers to write them.
If you enjoy developing pick a framework (Rails or Laravel) and start building apps. Learn all you can. Work toward obtaining a remote developer position or working on contract projects to learn more/get a better taste of what the work is like. If you enjoy it and are successful work toward transitioning to it full time.
Another option is to create your own app/business and be your own boss if you're interested in that. Then you don't have to worry about being hired or ageism.
Inspiration: @DHH Startup School Talkhttps://www.youtube.com/watch?v=0CDXJ6bMkMY
Good luck, don't give up on your dream.
I think it'd be better to gain some experience in your home country first, but I understand it might not be possible.
I think your best bet would be to look for a DevOps position which would provide you with more opportunities for coding while valuing your sysadmin skillset.
That being said, I see some similarity in your position to the one I was in a few years back. I had just finished a degree in computer engineering and I wanted to start a career as a software developer. I had some background developing basic sites with PHP/HTML/CSS/jQuery but I found that employers were looking for more. I ended up studying a few modern frameworks for a few months and found a job much more easily after that. I'm sure that will be the case for you. Just research the job market and find out what skills are demand and what skills you are lacking, it is probably a lot less work to catch up than you might think. Good luck!
Interviewing varies widely among companies. Some places only want to hire people that are experts in some tech they are using (say a js package), others want to hire people that are generalists, or have worked on mostly frontend - ui, or backend (not ui). Some places want people who can learn anything. There's no uniform thing.
Most companies in the US would not consider you for a senior coder, unless you were very very advanced in some aspect of cs. Since you don't have much experience, you could look for an introdutory role. I don't know about signapore, but in the us because of the huge demand its generally easy to find a starting programming job. You could also look for a job that takes advantage of your dev ops/admin background while have some easy programming required, but you'd want to make sure it was really a job that had programming.
Good luck! I'm 50+ and have many years of experience and have no shortage of jobs. Just program, try for an hour a day if you are still working in your admin job, and in a few months you'll be much more fluent.
You really never know where you are going to end up and anything is possible, no matter what age you are. It is always worth it and will always be worth it. Since I started, I have built two semi-popular websites at http://www.confessionsoftheprofessions.com and https://mypost.io/ and after those, began developing real web apps that I charge for. I just started my own business that specializes in apps for memory and communication. We have a few apps in beta testing, about 4 of them ready to go out with 4 more side projects in design and development stages.
Most companies want to see your experience. Just make sure you have a portfolio and a little documentation regarding work you have done. Have references available upon request and get a LinkedIn and have them write recommendations for you and return the favor. I remember I used to be willing to give all these PEOPLE references, but after they see your work and know it is yours, they usually need not see any more than that.
It can be scary, moving to another country. But believe in yourself, know that this is another path in life and an adventure you are going to take, and make the best of your situation. You have a lot of knowledge and based on that knowledge, it seems like you are always willing to learn more and go beyond. There are tons of position to be filled that go unfulfilled, even if it may seem the market is saturated with developers. You are in demand as long as you make yourself in demand. If you get tired working for the boss, work for yourself. In this day and age, more than ever, WE have the power to do that.
Regret doing it. That is a much better regret than the regret for not doing it.
In terms of age, most newer companies (mine included - London) don't associate title to time served or your actual age, but your abilities. We've hired a junior who was then 29 and made a switch from being an accountant. He had the gist of how things worked and his personal projects looked promising. He completed the coding exercise in a language he was not familiar which demonstrated well his ability to problem solve; guidance was needed but he was were we'd expect a junior with no comp sci background to be. I myself am the youngest in our team by quite a margin (mid-20s) and am the Technical Lead - age isn't a worry. Just be prepared to be outdone/tutored by people young enough to be your children; at previous companies I've met people that have fought me on every aspect bc of that fact even though i was brought in to advise and fix their architecture issues.
If I'm recruiting it's generally for a specific full stack developer. i.e. Ruby on Rails. Personally I would see your background as an advantage but I'll still need to be able to see that you can hit the ground running.
So ideally you'll need a project on your CV targeted at the recruiters development stack. Perhaps an open source project or a side project, or freelance on upwork.
You're age is an advantage, don't forget that. We grow wiser every year.
You might have also missed an important part: Do you need to put food over the table?
There is always a market for 40+y.o junior software developers. It probably is not as rewarding as you might need it to be.
Relevant: If you are a thick skinned guy with lots of deduction and perseverance; there is a market for SaaS/Products which require little marketing and sales. Can earn you a decent income. No location dependance and no boss (though customers can be as much annoying)
Because of that, I firmly believe many people can work as a software developer and contribute meaningfully to a company's bottom line.
State your ambition and let the results of your work do the rest.
Figure out a back-end language and web framework you like - I'd recommend Python+Django or Ruby+Rails - and build a web app in it - if you spend a few months and put in a few hundred commits and build a large enough application, you're good to participate in a team and start adding good value. That by very definition should land you a full-time programming position.
I'm all for age being of no importance as I'm about to hit 30 in a few years. But it's worth mentioning (maybe).
The mechanics of learning to code simply takes determination and hard work. In my experience, the vocabulary is the first major hurdle.
By the time you're 50 you'll have a decade of experience
It's silly to burn up that little bit of $ that you will receive on an outside chance like this.
Like jacquesm says, finding a new job and running your startup on the side is the safer bet. If that's viable, then I'd suggest you find a new employer that has a contract friendly to side projects.
As an aside, there should really be a list of companies that are friendly in this regard. GitHub was recently in the news for allowing employees to work on personal projects using company resources, which is awesome.
Go meet your customers in the first week. Ask lots of whys. Do more structured IN PERSON interviews in the second week. Look at how it has been solved in the past and what competitors do. Draw up a rough solution (e.g. landing page) in week 4 and test it out in person as well as drive some traffic to it from online communities (reddit and FB groups do get you some traffic to have an idea about conversion rates).
GV has some good articles around cust dev interviews on their medium.
You probably have higher chances finding angel money for a well validated idea in the market than a product you built for 3 months full time without knowing exactly what to build.
Then look for a problem in the new job for which a solution is needed. One that really consumes a ton of people time. Something that would apply to more than just that company. Build that solution in your free time.
If you already have an idea as it seems you do, try to find a related job in that industry so you can continue to build out the idea in your free time.
You should know that getting even a small angel investment, for many, is quite tough -- and it takes time. If I were you, I would consider instead just focusing that time on getting the product far enough along that people either can use it or get excited about it. Get to know startups in your area and make yourself known in that community. Just chasing investment without an MVP that has clear growth is usually a waste of time.
Desktop applications can avoid security problems inherent in web apps that are run through a general purpose browser.
The commonly cited tradeoff with desktop apps is they are harder to deploy and update. I don't believe this is necessarily true. You can tell a desktop application to periodically check for updates and notify the user to restart before allowing further writes to any central data stores. If fact many already do this. Problems arise when the OS prevents updates from being applied by non-admin users and you are deploying within a locked down corporate environment.
Java SE/Swing is a good platform for writing cross platform desktop applications. I work on an engineering simulation tool with a complex UI written in Swing. With Nimbus Look and Feel it looks and works the same across Windows, Linux and OS X without changes. Some people (devs) complain that is doesn't look native - none of my users care though.
The few times I have ventured into web development I have been horrified by the amount of work required to get web apps to look and work the same across different browsers. JQuery and Bootstrap deal with a lot of the pain but web dev still feels very hacked-together compared to desktop development to me.
I see most of the companies I work with moving towards AWS or Azure with all the scaling support and APIs that really make web apps easier to work with.
Instead of dealing with dozens of IT rules as to what can be installed on the various corporate images (which now include Macs), it's easier to just point users at a URL and make sure whatever single sign on they've got is integrated.
Another point: desktop apps are just as complicated as web apps these days, especially when dealing with Mac, Unix, Windows compatibility along with mobile. It seems like nobody has really done a good job of replacing VB6, Delphi, etc, and I haven't touched (as a Java developer) Swing or JavaFX in years.
As for the stack, c# and winforms is a good bet, particularly if you need to target older versions of windows. If you need a bit more performance or cross platform support then c++ and qt would be better. You could go c++ and win32, but MS dropped the ball on creating a nice api.
Deployments are another area MS dropped the ball, click once is sort of ok if you are using visual studio, but either way chocolatey is better. You may want something better for release management, in which case look into octopus deploy. These suggestions apply to electron apps as well.
Basically, had windows XP come with a better programming APIs (more like qt/gtk) and a better deployment model then web apps would have never been a thing. OSS has made windows a viable desktop.
1. In the login form, ask for an email.
2. When a user inputs an email, send an authenticated link to their email. This link contains an authentication key that can be used to perform a one time login (or several) to an account associated with the corresponding email.
3. If a user has logged out or needs to login from another device, simply enter your email again and receive a new authentication link (or use the email you received in the past).
4. If a user logs out, invalidate all the previously generated login URLs.
Notion uses this system and I like it
For bearer tokens use secure, httponly cookies that have names starting with __Secure- . Check Origin header to protect against CSRF. Optionally consider using token binding  so that cookies cannot be exported at all.
My suggestion is as follow: always allow signups via e-mail/registration. If I go to a site and the only options are "Login with Facebook/Google/Twitter," it's not worth my time. I never used those walled gardens as identity providers.
There are a number of people who do login with their social network, so if you want to get that segment of the population to try your app, you do need to support login via 3rd party providers. Usually two should be enough (Facebook, Twitter, Google).
Under the surface, most providers use either OAuth or OpenID. Most web frameworks have plugins that support a variety of authentication types. Pick a framework with a good auth plugin that shows frequent commits and a large userbase. You want something that is actively developed, so if security problems are found, they can be patched quickly.
I totally understand not wanting to allow FB logins. If your audience is mostly the HackerNews types, then you could authenticate with GitHub as well.
It's also open (two text strings), decentralized (you can use whatever password manager you want), and simple (people have been using it for ages). So before implementing anything else fancy, I'd highly recommend doing email/password first.
Whereas integration of OAuth 1.0a and OpenID 2.0 required an extension, in OpenID Connect, OAuth 2.0 capabilities are integrated with the protocol itself. (http://openid.net/connect/)
I can't find any direct assurance on the OpenID Connect website that a conformant OIDC implementation will by definition be compatible with a compliant OAuth2 implementation, although I suspect this is due to the open-ended nature of the OAuth 2 standard (i.e. I'm not sure if you could confidently say any particular implementation of OAuth2 would be compatible with another implementation). FWIW, you can implement an OIDC 'relying-party' directly on top of google's social auth OAuth 2 endpoint, if I'm reading this correctly: https://developers.google.com/identity/protocols/OpenIDConne...
Unless much has changed in the past year or so, it's also very easy to do a relying-party implementation, which I think matches your scenario. For example, I wrote a (probably insecure) relying-party implementation straight from the spec in a bit less than a day, and I'm not a programmer by trade.
It worked when tested against one of the django OIDC libraries floating around out there, which came as a bit of a shock. This might suggest the standard is 'tight' enough to ensure interoperability between independent implementations. Then again, it's only one data point so YMMV.
OpenID Connect 1.0 is a particular set of narrowly defined workflows on top of OAuth 2.
The company I work for tries to focus our interview challenges on knowledge that you would actually exercise and think about while on-the-job but isn't language and framework specific. It has trade-offs (we have a take-home test, which does impose a cost on candidates' free time) and I would be interested in seeing someone more experienced than I go through the process and evaluate how well we do.
* A lot of software developers don't apply to enough positions. A number of developers who talk with me and complain about the interview process don't apply and get enough interviews to be picky about the interviews they are accepting. Companies play on this fact very well. They know developers get their heart set on only a few jobs and so make them jump through hoops to get the position. Try applying to 10 developer positions a day. Seriously. It's fun and refreshing.
* Software developers don't market themselves well enough. I honestly don't even have a resume available. When people ask for one I say, "I don't have a resume nor do I need one." They will then say one of two things. A) "Fine, we're not interested in you." Great! I didn't apply with you anyway and frankly don't have time to jump through your hoops. B) "Oh that's not a problem can we just chat with you for a bit? I know you spoke at Conference A, B, and C, and we saw you at MeetUp X, Y, and Z. You're good friends with our Senior Ops person. We don't need a resume." Fantastic. My marketing is working out well. By the way, when they bring me in to have a chat and say "We'd like you to write out a red-black tree on the board in your favorite language, please. Oh and answer a bunch of random Big O notation questions." The answer is: No. Remember how you heard me speak at those conferences? Remember how I did a live coding and pairing session at that MeetUp? I think we can assume I know how to code. And if we can't, that's fine.
* Finally, have confidence. Honestly, most interviewers aren't confident in how to hire or what to hire. So, be confident for them. 50% of the time when I say I will not answer your asinine questions, more interviews stop and say, "Oh, well excellent, let me just talk to you about our problems." Which is where most interviews need to go.
So, you ask, how could we fix this? Fix it for yourself, individually. You aren't going to fix the industry. You aren't going to fix how bad people are at judging others work in a short period of time. But you can make your own situation substantially better.
Simply refuse to participate in asinine technical interviews. Counteroffer with a discussion proposal.
This subject actually comes up with great regularity. Here's a solid TC article from 2015 > https://techcrunch.com/2015/03/21/the-terrible-technical-int...
I hope I am not nitpicking here but ain't nothing wrong with knowing the time/space complexity for code you'd write. Especially if you are a "senior software engineer".
Some people freeze up during interviews and are not able to code as good as they otherwise could. That is unfortunate and a problem I don't know how to solve.
Juniors aren't, though they are expected to show some capability in thematter (and that's why everybody demands from them a college degree).
In the old days companies were training their employees on the job. In thosedays it wasn't uncommon for employee to stick to a company for twenty-thirtyyears, so training paid off for the company. Today employee works only forcouple of years before moving (or being moved) to next company, so it's notsurprising nobody wants to train anybody from ground up. Training requiresloyalty from both parties, which is a scarce resource nowadays.
> I'm a senior software engineer, why do I have to spend hours/weeks/months on Leet Code, Hacker Rank, etc. in order to be prepared for a "technical interview" these days?
I don't. Apparently it's a location-specific phenomenon.
> Why do technical interviews force me to re-learn something not relevant to the actual job I'm applying for? [...] I'm referring to the mathematical/academic concepts like big O, binary trees, graphs, linked list, etc.
I don't know what are you doing in your work, but in my job data structuresand computational complexity are important basics. Without ability to jugglewith those in my head (assessing complexity on the fly) I couldn't evenstart to think about anything substantial. And I'm not even fully fledgedprogrammer, I'm in large part a sysadmin.