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.
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/)
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.
- 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...
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 :)
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...
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.
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.
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.
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.
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
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
A developer with marketing skills can build products and achieve revenues far in excess of their skill set.
If I were to do it again I would focus on the creating a solution to the smallest subset of the problem I am solving and trying to sell that. Program that one feature and do not start on the next feature until you have a paying customer for the first one.
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.
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.
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.
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.
> Willingness to pay
Most people see it "charge as much people pay"
But the real lesson here is a different one:
You create a value. The value - costs is profit. Someone along the chain makes this profit. Might be the people you work with, your boss, might be the person sitting at your client looking smart for buying in cheap or your client's boss. Someone does. People are ok to pay as much as long as it's less than the value provided (and comparable to the rest of the market - sidenote: specialization)
Someone makes the money. Stop charging in hours. Charge based on the value. (obviously it should be more than the hour costs otherwise dont take the project)
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.
* 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.
Communication, communication, communication. I'll say it again, communication.
When it gets time to hiring someone to take over the day to day handling of your clients support needs and/or sales inquiries. I suggest you get someone who is very knowledgable about your product and who is interested in converting every single lead into a sale.
This will mean the difference in your business making money or not.
I'm starting a venture and I have many vendors. I must have spoken to 50 potential vendors across many different markets and there are so many sales and support people who are utterly clueless about their company and product. Who go above and beyond telling a potential customer to pound sand. Sometimes I am speechless in the service that I have had with some companies.
In fact, a few times I've actually had to use the nuclear option, which btw I hate. I've had to find the CEO's email and contact them directly. This always made the difference in the connection.
When I have had to do this, it always it went from the support person detailing reasons why the business can't do "that" and that they supposedly pushed it up the chain or spoken with colleagues and it's just not possible to accept my request.
After emailing directly with the CEO, who then forwards the communication to a senior manager and the issue gets resolved quickly.
In fact, I have a beauty of communication which I may one day publish on Medium. Which outlines the how someone went above and beyond not to win my business. I'll be framing this email in my office for sure!
Other great examples are when I am trying to clarify a question and highlighting something in a faq or a webpage and then I get that url link right back at me with the same quote. As if they are copying and pasting me wording from a support document. Which quickly leads me to believe VA's are handling the support and they immediately lose my interest.
Finally, the best ones are when on the vendors side, the communication goes cold. That they just are not interested in getting back to you. Which I can't understand. I want to give them lots of money!
Don't be one of these companies. One lesson I have learnt in the past. Is that if someone approaches you to make money, don't immediately turn them down. Even if they can't help you right now. They may do in the future and it may be really beneficial to both parties then!
Apply Why? to everything.
- Why this tech?
- Why this market?
- Why this team?
- Why do I want this life, experience, challenge, team?
- Why do paying want this product?
- Why will I push through when everything is bleak?
Watch for vanity answers as mentioned by others.
4 years later, happy to report that I have a successful startup.
 Market is a group of people whom you can reach and who have a problem you could probably solve.
 Product is whatever thingamajig that solves the problem market has. Probably software, but don't force it.
Take cash over equity. Drop acid or shrooms at least once. Don't get married young.
Unit economics: http://blog.samaltman.com/unit-economics
- 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).
Just because you are good at something doesn't mean you should be focusing on that thing and leave the rest for later.
Disclaimer: in my experience small privately held companies do pay consistently and on time. Other kinds of customer, not so much..
My one thing: The software business changes faster than you think, especially when you're young and your frame of reference regarding time is so short. Just when you think you're hitting your stride and the business is cruising, that is when you should be working on your next big thing. If you don't, you're going to find yourself "out of the game" pretty quickly.
- when venting/bitching/complaining, make that clear by saying, "Hey friend, I'm just venting here. <venting> ... </vent>"
- don't run out of money
- don't take money from anyone who can't afford to lose it
- search for ways to delegate & outsource non-essential tasks, but plan on doing them yourself, as you'll find there are somethings you can't offload no matter how much you try
- try to avoid putting yourself in a situation where your business dies if any single person dies/walks/disappears
- assume anything you say to anyone was not correctly heard, and ask them to repeat it back to you
- commit to working in 100% in person, or 100% remotely
- be prepared to have to trust others, and adjust your expectations accordingly
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.
- Be organized! Many developers have messy desks, cluttered folder structures, and no task lists. Taking time to organize and get a good practice of listing out tasks, place items in correct order, and knowing what your daily plan helps in becoming a better developer and more valuable to a business.
- Tooling! Get useful programs, apps, and utilities to get you more productive. Good spreadsheet application, useful powerpoint templates, and documentation tools are an example of items that will go a long way in business.
Best advice I can think of is to not think generally about what is good strategy, or anything of that sort, but about what makes your product valuable in the lives of the people you hope to make it for.
The rest will sort itself out.
This can be any method of marketing you want, but you need it and it needs to be effective. The odds of being the exception that does not need it are low.
tl;dr:1. The most important thing for developers to understand is the business goal of the software they are delivering. 2. The second most important thing for software developers to understand is how much they cost and their opportunity cost - especially if they are on staff.
To explain in more detail:
1. Software you develop professionally serves a business goal. Engineering decisions should be made in support of this goal - they are, themselves, not the primary motivating force. There are often cases where an engineering decision is a key part of the business offering - e.g., a specification, compliance with a protocol or a law or regulation, performance metric, systems compatibility - but this is still a business point. You are still building software for it to be sold. Part of understanding the business goal of the software is how the client (whether that is your employer or your actual client, if you are an independent developer or studio) actually makes money off of that software or how it fits into their business model. This means that, by and large, while executives are actually very sympathetic to engineering decision - you have to understand that a very large number of engineering decisions (possibly a majority?) are non-responsive to business concerns - i.e., they truly do not care if you go with react as opposed to angular for engineering reasons - but they do care if you tell them that there are more developers out there familiar with angular, they are easier to find and hire, the codebase is more actively maintained, it is less prone to failure, it is more likely to continue to be stable in five years, and it will not cost as much to re-factor the old parts of your production-software to this new platform as opposed to an old platform (NB: this example is made up. I have no idea if it is or is not true, with regard to react v angular). They don't care if one is shinier or newer - unless it has a material impact on the ability of software developers to perform and deliver, or it will have a material impact on the stability, security or performance of the underlying software.
2. Software developers are monstrously expensive. Mind-bogglingly so. And non-technical people have a very, very hard time understanding what you do all day. The many, many attempts to metricize software development - velocity, kanban boards, (god forbid) LoC measurements - are an attempt for non-technical people to try and match cost to output. Please understand that this is well meaning - they do respect what you do, they just do not fully understand it, which is why they have to build these elaborate systems to try and make sense of it. To express this another way - you cost money with every breath you draw, and you are fantastically expensive to keep around. A few months ago I was at a JS meetup here in NYC, where a CTO walked through how much work it took to install bower, grunt and babel into their production stack. He said it took 3-4 senior engineers three months of dedicated time to make this transition. I thought to myself, he must have made a great business case, the business managers must have understood this was necessary for the health of the product, his managers must defer to him without question, or the organization has very loose controls, or some combination of the foregoing, because that is somewhere on the order of 3.5 (persons) * 150 hours (productivity / month) * $125/hr (cost of a senior dev, fully loaded) * 3 months = ~$200,000 worth of work for changes to the stack that were purely internal. The math is crude and very back of the envelope - but consider the opportunity cost - that was senior dev time not being put into feature development, critical bug fixes, or performance optimization - it was purely back-end refactoring. Personally, I have no idea if this investment will turn out to have been worth it - I don't know enough about what it was like to write code in that org before and after these changes - I do know a tiny fraction of JS devs work in es6 - so I am skeptical of the utility of babel at this point, but that may be very shortsighted. What I can say with some certainty, however, having negotiated many, many millions of dollars worth of software development agreements, that this was a major operation, even for an 'internal' client. To put it another way, if you hired outside guns to do this same thing, double the cost. The whole point of this story is realize that, when this was all pitched to the management, who are decidedly not software developers, they had to put tremendous faith in their engineering team that this really large cost was worth it, when I'm sure there was a yard-long list of bugs, features and optimizations that were being de-priotized for this fix that the managers would never actually see, touch or interact with directly. When you are pitching engineering decisions to your clients, you have to make it very expressly clear why it matters for the business case - not just why it matters for the engineering case. You may be right and they may even understand and agree - but in the end, unless the engineering changes are going to have a business impact, it is not a good business decision to invest in them. Please understand - sustainability, security, performance and the happiness of the software development staff are important business considerations - so you can include them in your pitch. But if you just tell a manager that react fiber is better and the way of the future, and you must do a full-stack migration from your static HTML forms to react fiber and it will take 1000 hours of dev time, don't be surprised if you get the stinkeye. Tell them this is an investment in the sustainability of the product and it will mean it will work on more systems, more browsers, work better on mobile and make it easier to hire engineers? You may succeed in your pitch.
Work out simple and efficient ways for rock solid end-user experience. Anticipate lots of time spent with customers.
Help others, friends are the most valuable. Protect your plans in the early phases and be prudent with your capital, prepare for the long term. Do not be afraid in taking risks, patience will pay.
Do: Create something you would buy yourself!
But the best article I read some time ago: he said that a man does not need to earn more than 3000 euros per month to be happy.
When you leaving the company - you and your partner/partners HAS to agree on a price.
Remember this in your paperwork (where you try to think of all kinds of breakup)
Starting the first company may be the most difficult thing. Once you are in the entrepreneurship loop, it must be easier to fund new businesses.
I'd like to have been exposed to Steve Blank's works, The Four Steps To The Epiphany and The Startup Owner's Manual sooner. They are BTW, both the same book and not the same book. That is, TSOM is sort of the 2nd edition of TFSTTE, so in that sense they're the same book. But while there is a lot of overlap there's also plenty of material in each book that isn't in the other. So for anybody who is interested, I'd actually encourage you to read both.
Likewise, I would have liked to have been exposed to Jeffrey Thull's selling process, "Diagnostic Business Develoopment", which is described in his book Mastering The Complex Sale, Exceptional Selling and The Prime Solution. I'm a fan of his model and while I can't claim to have empirical proof that it works yet, it feels right somehow.
I would also like to have had the chance to read How To Measure Anything by Douglas Hubbard sooner. It's not a book that's about entrepreneurship, selling, or anything of that nature, but the ideas in the book strike me as broadly applicable to many domains. To give a tl/dr; it's roughly something like "use calibrated probability assessments to generate initial estimates, build a model possibly incorporating nth order effects, and then use a monte carlo simulation to build a probability distribution using the estimates and the model". There's a little bit more to it than that, but that's the gist (as I understand it anyway).
Finally, I'd say that I'd like to have been exposed to the ideas in *The Discipline of Market Leaders" earlier. The core idea in that book is that there are different bases for competition. One (obvious) one is price, and another pretty obvious one is "technical (product) superiority". But the book makes the point that there are other, less obvious ways to compete, like "operational excellence" (basically, running leaner and managing costs/defects, etc. better than the competition) and - my favorite - "customer intimacy". The last one basically means being more knowledgeable about your customer's business, making more tailored solutions, and basically becoming more of a partner than just a vendor. That happens to align well with the whole "Diagnostic Business Development" idea that Jeff Thull pitches, so I think these ideas complement each other well.
Outside of all that, my advice, FWIW, would be to say "you can't learn and understand enough about marketing and sales". Seriously, building technology comes easily to us... doing sales and marketing does not always do so. But I firmly believe that this stuff can be learned, and I think that if you're selling something you're actually passionate about (and if it's something you built, you probably will be) then you can learn to sell it without being a "natural born salesperson". Yeah, maybe some personality types take to selling more easily than others, but I think pretty much anybody can learn to sell to some degree... and in the early days of a startup, unless you're lucky enough to partner with somebody who is a "sales guy" type already, you probably will have to do the initial selling.
So you want to frame it differently. For example, provided this is true, you could emphasize that you've been the most senior person in your company, but that your company offered limited growth opportunities. Now you're just champing at the bit to work with people from whom you can learn and grow, and you're overflowing with energy to do so. Demonstrate why it's true, perhaps with examples of things you've been poking at on your own. Or something. You need your story to be true, and the above might not be. But you do need to have _a_ communicable story.
If you have 7 years of experience, you almost certainly have important, non-junior level skills of value.
But companies do not hire people based on how good of a developer they are, they hire you based on how good you are at interviewing. These are corrolated, but not equivalent skills.
What you need to do is get better at interviewing.
Interviewing is a skill that needs to be practiced.
That means you need to get better at programming silly algorithms on a whiteboard.
Fortunately, this is a skill that can be practiced. There are loads of resources out there that will teach you exactly the stuff you need to know to become good at interviewing.
I'm assuming you build websites? Web developers don't typically deal with the sort of algorithmic problems that software engineers tend to deal with.
You're essentially switching to a new career path, which is not a deal-breaker.
Simply explain to companies that you are a senior level WEB developer, but a junior-level software engineer.
I wouldn't worry about "years" too much. It's very very easy to work a number of years and still be a "junior" skill level. I see it all the time. It's not even a criticism of the person at all; if your job is "perform minor fixes/improvements to this web app" and you do that for 5 years, for example, you're not likely to have technical skills beyond the junior level even though you've worked for many years. This is not a problem. It just means that if you want to move your career forward you will need to find a position in a more tech-oriented, forward-moving, mentorship-based organization.
A senior developer at a non-tech organization can easily translate into a junior or mid level developer at a major tech or tech startup.
Ben Chestnut Co-founder and CEO of @mailchimp (aka mailkimp aka mailshrimp), seems a worthy subject. > https://twitter.com/benchestnut?lang=en
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.
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.
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...
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.
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.
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.
Here is one interesting (maybe too long) answer:
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
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.
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.
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?
70% of the money will come from the enterprise/offline sales you do and the rest will come from your website.
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.
- 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.
The kicker is, how well you do on the 20% determines how hard your 80% will be.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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?
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.
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
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!
These days apps have to compile for multiple architectures especially on Android. Those are all packaged up together. Not only that these days you have multiple sizes for image assets for various pixel densities. On top of it all these days people rely on a lot of external libraries which may or may not be on a phone or system. You can't depend on shared linking like when developing for Windows back in the day.
Not to mention, fonts. Apps these days package up fonts and send them along too.
[Edited for more content]
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.
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.
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.
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.
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.
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.
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 ...
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.
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.
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.
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.
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!
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
If this is action they take at scale with millions of visitors I wouldn't even risk it with something so intimate as a blog.
I certainly did take advantage of an Apple discount though, at the time, it was way better than it is today. It was 2009 when I bought a Macbook. They gave me a printer, an iPod Touch, and $100 in Apple credit which I applied towards the computer. I think I also opened a credit account with them which took off 10% more from the total price.
Sold the printer for $100, sold the iPod for $250.
So a $1500 laptop ended up costing me $1200ish with tax.
I think they have since changed all that and give you a $100 discount.
It isn't a lot but free is free.
edit: and Adobe stuff like Photoshop and Illustrator
The Mythical Man-Month by Fred Brooks for tech management.
Confessions of an Advertising Man by David Ogilvy for advertising/marketing industry.
Design Patterns: Elements of Reusable Object-Oriented Software by the "Gang of Four" for OOP software engineering.
It is hilarious and informative! Described in more detail here: https://hackernoon.com/how-to-become-a-hacker-e0530a355cad
Comprehensive, concise, and beautifully written.
Another set of books I consider to be "one" bible are Edward Tufte's (1) The Visual Display of Quantitative Information, (2) Envisioning Information, (3) Visual Explanations and (4) Beautiful Evidence.
Advanced Marathoning, 2nd Edition - Pete Pfitzinger, Scott Douglas
It's heavier on the biology and human kinetics in a way that I don't need a bachelors in a hard science to understand and is quite well known now to serious runners. I read it every year as a motivator and to reinforce the importance of training smart.
But I don't think it's comprehensive or constantly referenced by those in the industry (it's almost forgotten about by modern designers, I bet). I think a closer fit to a 'bible of the field' would be The Art of Game Design: A Book of Lenses by Jesse Schell. Lots of good information about what to think about, and you can even buy a deck of tarot-sized cards that has a compiled list of all the questions the book invites you to raise when thinking about your game on them.
I'm still waiting for something similar that focuses more on board game design specifically, but a lot of the Book of Lenses can be applied to board games as well.
In my work in math education, there are many possibilities, but I think Polya's "How to Solve It" is a strong contender.
Principles of Digital Audio, by Ken Pohlmann
Handbook of Model Rocketry, by G. Harry Stine.
(p.s. if anyone has any suggestions for the field of imaging, I'd love to hear them as I don't know of a good imaging "bible".)
This book is amazing and still holds up today, for the most part.
Web Application Hackers Handbook 2nd EditionandThe Art of Software Security Assessment
Alternatively you could try IBM OpenWhisk or Azure Functions, both of which are open source.
Also, props for using a term that actually makes some sense (Functions as a Service) as opposed to that other name thats so popular.
Most things I've seen so far are docker-based, which is a non-starter for me.
You compile it down to a single executable and then you do whatever you want with it.
I can't provide the autodeploy part though...
2. Exercise and eat right.
3. Set goals. People with goals vastly outperform those without.
4. Track your progress. This will involve determining the right metrics. "What gets measured gets done."
5. Look for more efficient ways to do things.
6. Read the book "The 7 habits of highly effective people."
7. Learn some time management techniques.
8. Read up on how to plan things backwards: Start with where you want to be and figure out the step before that and the step before that, etc. Otherwise, you may be "climbing a ladder leaned against the wrong wall."
It also has a companion book.(Book came first anyway). It's well researched and has many tricks on boosting productivity e.g Pomodoro technique.
P.S. See also Max's earlier blog post Measuring Developer Productivity: http://www.codesimplicity.com/post/measuring-developer-produ...
The biggest insight is that it's far more important to work on big, important problems.
If your goal is content, then you should worry about being consistent with content.
The platform will only matter later in the future.
I'd go with WordPress.com and that's it. From 0 to 60 in a second.
Most people will spend time playing with platforms and tech and forget the most important part which is writing.
I'm a big golang user so I recommend Hugo for the site generator.
Mostly, security these days is securing your cloud accounts. I use two factor authentication on my Apple, Google, and DropBox accounts.
I use Firefox as my primary browser. It's configured to delete all cookies and browsing history when I restart.
Proprietary software gives you zero security against its owner/developer.
FLOSS is the only way we can have real security.
I'm going to parrot my interpretation of patio11's  advice since I don't have direct experience: Pay for the service and focus on building a product people will pay for. That's what those services that handle VAT did and why you are considering using them.
What Patio11 doesn't say is if you build it, you have to maintain it and maintaining it means keeping up with changes to tax law and tax forms and tax policy. Odds are you're not a tax expert (if you were, you'd probably be standing up a tax calculation service like the one's you've found).
: AKA Patrick Mackenzie. My understanding is that he often chats with people who contact him.
VAT MOSS only applies to B2C sales.
I'm pretty sure that the satellites at the time could read 3 inch newspaper print under the right conditions which happened rarely.
I've got a tack sharp 600mm Canon lens and it's sort of useless for a lot of stuff. If there is any haze, heat, dust, whatever, in the air, all that expense glass sees is that instead of what you want to see.
That note aside, it was a fun project. I was the I/O guy, I did this work:
and I got Seagate to redesign part of their 9gb (I think, might have been 2 or 4g) barracudas. I've got a benchmark in lmbench that shows how the disk performs as a function of seek distance, looks like this:
The lower edge of the band is what you get if you seek and get to the track just as the sector you want is to about to pass under the head;the upper edge of the band is what you get if the sector had just passed under the head;the height of the band is a rotational delay;and those outliers? In this case I think they were either bad blocks or I don't know.
But when you ran this benchmark on two drives, mounted in a rack right next to each other, you got tons and tons of outliers which blew any chance we had of meeting the performance metrics. I bitched at Seagate and they hemmed and hawed and finally admitted there might be a problem with their internal mounts.
The problem was that their mounts were so useless that the vibration caused by one head moving vibrated the drive next to it enough that the other drive's head didn't settle properly and you blew a rev waiting for it to get where it needed to be.
Seagate redid the mounts.
But more resolution isn't what's important. Other capabilities, such as deep infrared, ultraviolet, radio, whatever scanning is more useful. Sats made U-2s, SR-71s mostly obsolete; drones are doing a lot of what Sats did. Top of the list though is refueling spy sats. That is the Holy Grail of reconnaisance which the USAF X-37B totally experimental research craft totally doesn't do.
Refueling massively extends their use and lifespan. Its like have twice as many for the money. Cuz, ya know, a hundred ain't enough.
31cm/pixel through WorldView-4
A perfect 2.4-meter mirror observing in the visual (500 nm) would have a diffraction limited resolution of around 0.05 arcsec, which from an orbital altitude of 250 km would correspond to a ground sample distance of 0.05 m. Operational resolution should be worse due to effects of the atmospheric turbulence.
Disclaimer: I'm the OP on that question.
As an aside, that donation has actually put NASA in a bit of a bind. For political reasons they can't very well turn down the offer. But the telescope itself is only about one third of the total cost of space telescope, with the rest being due to the cost of the instruments and the launch itself. Unlike the US military, NASA does not have an unlimited budget so this unexpected expense threw a wrench into their long-term plans. Furthermore, the telescopes were designed to look down instead of up, so they're not optimized for astronomical observations.
Satellite cameras dont have a 2D sensor you can find in a traditional camera. Instead, they feature a long narrow sensor. As the satellite flies over the earth, the sensor records a single row below the satellite. That row is oriented perpendicular to the satellites velocity. As the satellite flies, it scans a long strip of land underneath.
It works similar to a flatbed scanner. Can you film a video with the scanner? I dont think so.
About Bin Laden, the live satellite feed was not filmed from space. The feed was recorded by an on-body camera of an American soldier, transferred to a telecom satellite, then back to Earth, at Obamas place.
I recall reading somewhere about satellites being able to see license plate numbers from space but I have no idea where I read that or if it's true.
As many have alluded to here, there's likely to be a big difference between publicly available imagery and what's currently possible. Sticking to publicly available stuff though, while the resolution of all mapping services varies a lot across the globe, http://wego.here.com provides satellite imagery that betters Google's in a lot of cases.
This is all somewhat moot if you're looking for MIB-esque video of course as these still images are compiled rather than directly snapshotted
For example http://www.cropcopter.co/uav-imagery-vs-satellite/
For the full NIIRS rating:https://fas.org/irp/imint/niirs.htm
But well be posting open office hours on our events page: https://www.facebook.com/pg/YCombinator/events/.