My advice would be to think in terms of black boxes. You should couch tasks in terms of what the developer can expect to receive through an API and what their code should output. What happens in the middle shouldn't be anything you concern yourself with. When the junior developer works out a solution they can run their idea past you, and if it sounds OK then they write the code. And then you can review their code. The minutia of implementation is not your problem any more.
I encourage that sort of thinking from devs I'm mentoring.
I do this by giving creating a rapport where they feel comfortable asking questions. I do by having an attitude that part of my role is to help them be more effective. When asked a question, I drop everything to help them.
I then specifically give them problems that force them to ask questions. This in turn gives me the opportunity push the envelope with their thinking by asking them to answer their own questions.
So when I get asked a question on how to do something, I will ask them if they understand the goals and constraints we need to work in. I make sure they understand that first. Then I ask them for different ways of solving their problem, the pros and cons of each and ultimately what their recommendation is considering those goals and constraints. By that time they generally end up with the "right" answer, and sometimes something I wouldn't have thought of. What I am doing with that exercise is guiding them through the process of how to think about solving the problem. Soon when they come to me, they are already giving me options, pros and cons with a recommendation.
Sometimes I'm asked to decide about a difference of opinion between two devs. Making sure both have the same view of the goals and constraints is really important and most of the time aligning these solves the dispute. If not, then I will have one or both create a minimal test/prototype, time-boxed, that explores the problem. Then we evaluate the results together against the goals and constraints.
This has worked very well for me.
As far as breaking up tasks and delegating, it all depends on their tolerance for ambiguity. I usually start more junior devs with smaller, well defined tasks that have specific acceptance criteria. I adjust the level of definition based on their ability to succeed, but always do it in such a way that it forces them to grow.
I don't think you can successfully break up programming tasks for junior devs, who can then independently implement them. It has two problems:
1) You either get a lot of code with incompatible ideas, or you do a lot of coaching.
2) The junior devs are not learning as much as they could.
So you should not try to do this on your own, but rather involve the people who will be implementing the project in the process. You can still design the system in your head in advance, but I think the best approach is to then discuss it with the people on the project and come up with the final version together. Maybe somebody will have a better idea, or just tell you something you missed. As you go deeper and deeper, you will keep discovering problems on the lower levels. Some things will remain unknown or require experimentation, but for most you can come up with a solution. I think it's very valuable if everybody on the team understands the big picture. If the application has a few completely separate modules, then you can do the lower level design in different groups, but it's still useful if the task breakdown comes from the people who will be working on the code. Doing it in a meeting, rather than a write up and review process, gives them instant feedback.
Regarding the task breakdown itself, I try to think of how I'd implement all of the code myself. That means thinking about what data comes though the system and where it can be used to set code boundaries, which parts are more important and which can wait, what would be the smallest presentable version and how can I move it further after it's done, do I have some non-code dependencies (business decisions, dealing with external services). I like to draw diagrams (mainly the data flow). Sometimes tasks are simply large and you can't do much about that, but you can at least some milestones for them.
This makes sense to me in a smaller company when building some web application, probably does not make sense in a different situation. (Sorry for a long comment.)
i suppose usually for me one guy (say techsupp or network admin) sets up the svn/webserver/db, one guy decides on frameworks, one guy writes the skeleton, one guy starts on the interface, art guy does art stuff, typically the lead dev is watching over all this and merging stuff and when ready gives orders and access to the repo. if theres at least some structure and one template or working file/interface the juniors will have more success imo.
That's the process of thinking i usually take. First, i'm gonna need a project. Then I'm going to need to instantiate a database. Then I have to create the controlling class. then I need to create the initialization. etc.
For the juniors, it helps a lot to have things more bullet point. they should be able to fill in the more minute details on their own, but do get fairly verbose. Break the work into a small logical scope, and then bullet point what needs to happen for it to be completed. And always explain why.
For the mid-level, be more general about it and have them define the tasks that will be completed. This is to give them more say in the process, enable checks & balances, and trains them to write tasks for juniors and mid-level developers when they are one day senior devs. And that's really what your goal should be.
Everything you work on is a means to make everyone below you better. If you know how to solve a problem, let someone else take a crack at it. If they get it wrong, or need some help along the way, you've already got an answer.
And of course, code reviews are an important feedback loop. But always let them maintain ownership. Its their baby. don't fix their code for them unless its more or less an emergency. Mistakes they make can often be reflected back as a failure of process, and not of themselves.
Delegation is a skill. Matching problems to the capabilities of team members is a skill. Accurately recognizing the capabilities of team members is a skill.
These are all skills you can acquire, but they are all skills that you will do more or less poorly on unless and until you have sufficient practice.
You will also be very slow at it until you have practiced a while and gotten better. So you must recognize that at first productivity will decline, because it will take you longer to delegate than doing it yourself.
Is your work environment reasonably "safe"? (Yes, I do mean that in the "touchy-feely" emotional sense; this is important (not trying to dismiss the idea, just using glib humour to forestall inevitable negative comments - some people are uncomfortable recognizing we have emotions and are affected by them...)).
If so, take your team out to lunch, off site. Tell them what you want to do: Delegate more. Tell them why: So the team gets more done, so there isn't a single point of failure or just one person on the critical path, so that junior members can grow into senior members, to challenge people's abilities, to make better hackers.
Next, tell them that this means you need to practice chunking, delegating, managing, etc., and it will take time for you to get better at these things.
Now ask for their help. Work as a team to do these things.
Note: You may also need buy-in from your management before you proceed. They may view this as a risky change, if they like how things are. Depends how supportive they are.
Try thinking in terms of strategies and tactics. The overall problem can be described in one high-level sentence of "what" to do. That's the strategy. That strategy can be described in one high-level sentence of "how" to do it. That's the tactic. Then that tactic can be broken down into 2-5 slightly lower-level sentences of "what" to do, which are strategies that are sufficient to meet that tactic. You may continue this for a few strategy/tactic levels. Eventually you have some medium-level strategies you can pass on to junior/midlevel people. But trust them to determine the tactic. If you give someone else a strategy and then tell them what their tactic is, you're micro-managing.
This is also roughly what a lot of refactoring and clean code is about. In a method, you don't want to mix levels of abstraction. Instead, a parent method should call inner methods that are named by what they do, while those inner methods in turn have the logic that is how to do what the method is named. And this can also continue on down to lower levels. When developing this way, you might even mock/facade some of these higher level methods/classes/functions/whatever so you can finish implementing and testing the higher level method/function/class/whatever that calls it.
A full-stack developer that hasn't quite made the jump to "architectural" thinking will often immediately and intuitively identify the lowest-level tasks that need to be done for a project, but like you've noticed, focusing on that implementation style doesn't really scale.
First, how to break up tasks. I write very small user stories. I aim for things that can be accomplished in half a day. This forces me to do two things. We now have smaller tasks with tangible end goals that actually produce something for the end user. These are usually easier for everyone, from management to intern to understand and follow through to completion. We also don't overthink a task, bite sized chunks are easier to digest, after all.
Second, as a few others hand pointed out, you have to trust your junior and mid level developers to complete a task on their own. Write the story in a way that they can understand what the end goal and tangible result will be. If you keep it small and discuss these openly, this will get a lot easier in a short period of time. Don't worry about the implementation details so much, that will come more in a second.
Third, (here comes the unpopular parts!) TEST! Preferably, at least in my view, use Test Driven Development. Enforce an cultural change of moving towards testing. This will document the code as much as anything and if a refactor needs to be done after a junior or mid level developer completes a task, the tests will facilitate that. It will increase your level of trust in their work as they complete tangible user story goals.
Fourth, pair program. You don't always have to, but heck after a while you might actually like it. Pairing allows you to riff off of one another. Junior and senior level developers can get a lot out of this, far more than just the junior learning something from the senior. If you are finding that your junior developers aren't "getting your style" pair for a while. You might start to understand them as well.
Finally, all of this leads to trust. Look, code bases will need refactoring. I am quite Senior and I am sure if I sat with your code, or you with my code, we would find areas where things could have been done better. Trust that if the code works and does what it needs to do according to the small tangible goals of a user story, and that when it has accompanying tests, you and others will be able to refactor it and make it even better over time.
This way they don't need to know the full system or even have access to version control; they just need to get their small goal completed, I can take care of the rest.
Over time, they can earn more and greater responsibility/access.
It's totally okay to just talk to a developer about the problem and start sketching out your ideas, without necessarily knowing the specific tasks that you're going to assign.
The abstraction level of the tasks that you should assign will also come out of the level of discussion you're able to have with the person. Everyone has different abilities/amounts of domain knowledge/available time/etc., so there is never "One True Task List" for implementing something; it must depend on the developer.
Finally, it is deeply motivating for the person who's going to do the work to be an involved part of the planning discussion. It's important to anyone to have a certain amount of autonomy in their work, and making them be a part of planning is a great way to do that.
I like to break up tasks into what I hope is achievable in 4 hours. Always assign yourself as much (or more) of these sized tasks than those your assigning others, if you don't want to appear that your only a manager.
Re-evaluate these sizes often. Especially with a new project, new team, or new person. Maybe due to something you did not foresee right out of the gate, this 4 hour task is really a 16 hour task. Or possibly the other developer is working hard, and learning fast, but you just misjudged how quickly they can complete it in. In this scenario, the next time it comes to split up work (or if you really over-shot, you can re-split up what you gave them) remember this metric, and size it a bit smaller.
Depending on distractions, and how well the above process is tuned, I only hope for 1 of these 4 hour issues to be completed per day, while at the same time, looking at it over a week or two average, not daily, as many programmers do not work in a predictable linear fashion.
Over time as engineers progress and grow at their craft, what they may have been able to do in 4 hours, might be 20 minutes. As you work with others you will get a feel for this, and become more tuned into other people's forte's. Not everyone is good at CSS for example, even if you know how it works. So its not just about skill. The longer you work with people, the better you will get at carving out tasks that work for you and for them, and for the team.
So in summary, experiment with it, give yourself as much work, and in the same manner you delegate tasks to others delegate tasks to yourself. Re-evaluate the size of these tasks often, and try to create tasks that others can get done in a reasonable amount of time, so that they get the feeling of completing something.
Not everyone can be given a big gigantic month long task and not get lost in it, and on the other hand, tasks smaller than 4 hours, really start to feel (and take the energy) of micro-managing. The more senior the developer that has proven they meet goals on time and communicate well, these can be relaxed a bit, and you might find someone really prefers 2-3 day sized tasks, but can also be reliable in this manner.
Finally, ask them. You might be surprised.
Both were written about by Niklaus Wirth, (co-)inventor of Pascal, Modula, Oberon, etc.:
From the above page:
Not a panacea, but useful, and can be used together with other techniques like OOP / OOAD.
Start by flow charting your program, divide the task into a group of single statements tasks that can be described without the words, "and", "or", "but", etc. If you need to use those words, you need to chain tasks or make decisions.
After several revisions (3-4) you should have a nice overview of what the program should do, and how it will do this.
Selected tightly interacting objects, and combine them into modules. This will be very apparently visually if you followed the first step correctly.
Now you have your scrum/agile modules which can be outlined and given to subordinates, and tracked.
If the whole thing is a just a big ball of spaghetti, make a another revision. If its very very small you might be glossing over the technical details.
For smaller features, we'll have a Dev just implement it full stack. This takes for granted that a lot of the plumbing is there, i.e. Service Layers
It helps to have these conversation during Planning Meetings. This will help the Dev's involved to get a better understanding of the Stories and Tasks needed to implement.
2. Review EVERY piece of code their write. Code reviews daily.
Generally speaking, finding a way to communicate this will depend on the engineer. Someone very junior may require much more detail both in the technical design and the feature itself. Someone more senior needs less of that.
Also, why limit this to engineers? Is there something about the way we engineers handle our finances that's different from the general population?
Another tip is that you should avoid applying through the company website - hundreds of people do that. They have software which will automatically filter out people without the correct keyword.
Instead, meetups and user groups have been more fruitful for me. You want to work in Java? Chances are, there's a Java User Group happening in your area, and chances are, there are people attending those meetups to source local talent. Attend them, network, collect contact cards, and bypass the HR process altogether.
So your real hurdle (assuming you're at the skill level of an entry-level/junior developer) is landing interviews. If you're not interested in going back to school I'd suggest reaching out to recruiters. Work with several, try not to be too picky, and most importantly, be patient. With an unconventional background getting your first offer will not be easy - but after that you're set. [Or at least, that was my experience, your mileage may vary].
Lastly, you mentioned you picked up PHP & SQL for a personal project - make sure that's on your resume and make sure to bring it up in every interview you have. It shows a genuine interest both in writing software and in learning as well as demonstrate you're capable of learning outside of a classroom.
If you don't select a name for the person you are buying the gift for many of the questions don't scan that well. Also you use he/she as the generic but one of the follow on questions is sex to which I answered and relationship to which I also answered so would have made more sense to personalise the question a little more.
Some of the questions should allow multiple response answers , e.g. does person play an instrument, dance, play in drama, none/I don't know. The person I was thinking of does all 3!
Not sure whether it's important but I would have thought that for some questions there is a big difference between none (or in some cases it should no) and I don't know.
I think it is a great idea. Always struggling to pick a gift. I like the phone charger suggestion. I like how you ask for feedback presumably to make the results better next time.
Will it be a success? I guess it depends on how the word will be spread? Do people want to admit they used something like this to buy a gift for someone?
Another idea for you - can you scan a Facebook account to gather a lot of the information you ask? Would save a lot of typing. It could also send you an email when it is someone's birthday with a recommendation of the present.
A common theme in the how to start a start-up is to do things that don't scale. What if you had a phone line that you answer, people can phone and give the information and you suggest a present. What if you order it for them? You will get a lot of information about the nuances of choosing a present, which can be fed into your algorithm.
In my example the person hates to read books on self development, but likes trashy novels, but on the other hand is very ambitious. It suggest all kinds of self improvement books but I had to keep saying no.
I filled out the wizard about my girlfriend who likes the Steelers, and you showed me a men's Seattle Seahawks shirt: https://dl.dropboxusercontent.com/spa/jacwd2ulo9hdl9o/q_gxfb...
There are ways to automate the process of gender classification, you should look into them for situations like this considering I explicitly filled in "female" and "Steelers" into your wizard.
It'd be helpful to have a back n forth between items, or even better show them as a list (maybe paginate and generate more ideas on each page?). I want to see the options before settling on one.
What I liked best was it gave me a category that works (smartwatch) which spurred an idea for an actual gift- a Fitbit.
Firstly well done on having the guts to show this to people. Doing that scares the hell out of me.
I think you've picked a problem worth solving, at least for some people - me included. I'm crap at choosing gifts, and always have been. Nowadays I choose my wife's presents by asking her what she'd like ;-). If someone could actually build a system that would consistently recommend appropriate gifts I think I'd pay to use it.
In my unqualified opinion, this is a hard problem, and I think you have a lot of work in front of you. But you have to start somewhere. I won't comment on the ui because that's irrelevant at this point. But you might find it useful if I go through my answers and your suggestions. I was answering about my wife who is in her 40s.
The most relevant answers to your questions were a) Kasabian (favourite band), b) One hundred years of solitude (favourite book) and c) spirits (re the choice of wine/beer/spirits).
The suggestions I got were below, with my comments:
1) This is all yours, an Alt J album - [Good suggestion, she already has it]
2) Velociraptor - a Kasabian album - [Again she already has this, but then they're her favourite band]
3) A summary of Love in the time of cholera [Not sure why the summary as opposed to the book. In any case she's already read it, but if she hadn't it would have been a good choice.]
4) Diary of a wimpy kid - the long haul [an odd suggestion given her age, unless I'm missing something. My son says it's a kids' book]
5) The complete book of spirits [ presumably based on the wine/beer/spirits question. I asked her about this and she wasn't keen]
6) A book about Kasabian - [ good suggestion ]
7) KATGI Heart Shape Pendant Necklace [ interesting - I asked my daughter, who thought her mum would like it. I then asked my wife, who frowned and said no ;-) ]
Anyway, not sure if that's helpful. Feel free to ask me anything.
BTW, an idea for you. Some of my friends are extremely good at choosing gifts. Maybe talking to people with that talent would help you work out what makes them good at it.
I've actually looked for this type of site before. Useful concept if it works.
I'd like to see a list of suggestions right after question #1 that change as you answer more and more questions. That gives me the option of either continuing or not without investing a lot of energy.
You could have the questions be "never ending" with that design.
I'm dating a twenty-two yo female and I can choose 13-16 or 27-35.
Not sure if it's intentional.
Working from home, at least for me, means to be more productive, even with kids at home. It also means eventually I work more hours to accomplish my daily goals, and that can become a problem some time (the oldest son already told me "you don't know anything else?")
Depending on the client, there may be some resistance from the in-office workers that have to stay there every day. The key is to do a good work and win confidence from management.
On socializing, in the last two years I started missing more. Probably less because of working and more because of staying too much time at home.
My experience working remotely has been overwhelmingly positive. A notable advantage is avoidance of certain office dogmas -- particularly, the expectation of 8 contiguous work hours.
When it comes to coding, I don't have the mental stamina to produce meaningful technical thoughts for longer than 4 or 5 straight hours. 8 hour shifts are inefficient for me personally, because I get drained and "waste" 25-35% of those working hours with lower quality output.
Working from home lets me work in multiple 2-4 hour spurts a day with time to mentally refresh inbetween. I'm still available to my team during the 9-5 block(computer nearby, phone always on if I'm out), but if I were in an office, I think coming in and out for 2-5 "micro shifts" a day would be frowned upon.
The major downside is that at times it is difficult to turn off. My manager's (tongue in cheek) claim is that WFH is a trick to make employees work longer. I'd say that's true. The lack of effort it takes to start working when you're at home makes it easy to justify "oh, I'm here; I'll just hit this now." At it's worst -- this August -- there was so much work that I'd work straight into the night, fall asleep, wake up, and pick up my laptop. If I was working from an office I imagine the 9-5 rhythm might have been easier.
One other thing worth mentioning is that I lucked out with a great team. They are great technologists from a wide variety of backgrounds and I'm humbled and impressed by my teammates frequently. Sometimes I think learning little things from them has been more valuable to me than the experience I've gained in our "hot" technologies..
The hard part is that I discovered that I have a "natural"27 hour day so I tend to be out of phase with the group.In order to communicate I end each "day" (aka bedtime) witha 1-3 line email stating progress (or at least effort).
"Work" is also a 7 day per week activity as there are nonatural boundaries. It helps that I really love to writeprograms. Calling saturday morning is fine but I might beasleep on tuesday at 3pm.
Also, I write "literate programs" so the work product isa book containing the explanation and the source code.That way the boss can read everything up to the lastestovernight checkin. The book contains all work done to dateso there is never a question about "the state of the work"or whether there is "progress".
On the other hand, if you don't like weeks of dead silence,a lack of extra eyes to find bugs, a river of badly brewedhomemade coffee, and hotdogs for breakfast ... get anoffice job. Working from home is not for everyone.
The only lacking part is office banter . . . socializing . . . but that is good and bad to miss out on. With skype and conference calls it's easy to stay connected with team members.
If you are a talker, you might it harder seeing only a handful of people each week. (Family, friends, service industry workers.)
My suggestion would be to find a company with a local contingency in your city. Like 3-4 developers that are local to you and can meet up to cowork occasionally or a few times per week.
It works best if you have some nice coworking spots locally within a reasonable commute.
The only place where we had to look for an alternative cloud service was when we attempted to set up our own CDN on https. Google currently supports it's global load balancer only for port 80 and 8080 and they suggested we use DNS load balancer which we didn't like the idea of.P.s. we have not worked a lot with AWS. So I do not know much about AWS. From what I hear, AWS is currently much better and gcloud is good upcoming competitor. Overall, we serve 20 million API requests per day on google cloud without any infrstructure issues so far.
Nothing will help you more in interviews, day-to-day dev work, general problem solving, and even application planning. The goal is eventually to transition your mindset into thinking about structures holding your data, and how they act, and interact. Once you do this the optimal architecture, and what you need to write as code becomes clear as day (really regardless of the language).
Other than that - Keep trying different things. Go deeper with the frameworks and libraries you use to understand why do they work the way they do. Read about things that are interesting to you and you have some use for. When you have a problem, don't just "fix" it, understand exactly where, why and when it's happening.
Beyond technologies-- Focus on building a solid consulting practice, client management, how to prospect & pitch new business. Recommend reading Alan Weiss, http://www.goodreads.com/book/show/260218.Million_Dollar_Con...
Freelancing as a junior dev is not a good move. Find a full time position somewhere that will train you and give you access to more experienced developers.
In terms of general advice I can give here:
- I've always found Adsense to perform poorly the more intelligent or technical the audience is. Adblocking is one issue, but essentially sophisticated audience == less likely to engage with weakly targeted ads (except retargeted ads, but that's another story).
- A community site that's so popular has great potential to get a small subset of the audience to pay for some sort of status symbol or internal advertising. See Reddit.
- Depending on what the topics are, job advertising could be lucrative if done right and promoted internally in the right way.
- If you want to take baby steps, consider introducing some BuySellAds units and selling your own ad space through them. You get control over your pricing and if you have an audience an advertiser is interested in, things can work well, especially if you can sell a site wide sponsorship type thing on a monthly basis.
- Do you have e-mail access to your community's members? There could be a goldmine there if it's treated properly. Email CPMs are way higher than the Web.
- Ditto but for having a podcast the community listens to. Podcast CPMs are even higher, but this is an entire project in its own right.
- If you're in the right topic area, boutique networks like http://adpacks.com/ might work well for you. In my experience the CPM isn't particularly mindblowing, but it should be better than Adsense and little work for you.
There was also a thread the other week https://news.ycombinator.com/item?id=8709438 that was how to monetize a smaller site, but the basics are still the same to a certain point. But without knowing the content its kinda tough to give specifics.
Some ideas, you can collect data/posts from the site into ebooks and sell those, or provide training from the site on specific topic etc. And if you haven't already I would be building the email list for a newsletter, cross promotions etc, all of which convert at a much higher rate and do really well.
I would think that out of 4M views per month you should be able to monetize it in multiple ways, so you do not put all your eggs in one basket as well.
Instead of just serving Adsense ads, you can set up various kinds of bidding (or manually create ads to start with) falling back on Adsense when inventory 'runs out'.
Basically, it will end up being a manageable/overridable layer between your site and Adsense, which you currently use.
I have a powerpoint and pdf of my deck on a thumb-drive, but I almost never use them (if anything, I'll email them to the person as a followup after we speak). I once met a guy who had a QR-code on his business card which linked directly to a zip file with his business-plan, pitch deck, etc. I thought that was pretty cool.
Without question this is the single best beginner resource for learning Ruby on Rails I have ever come across. I tried CodeAcademy and a few other similar websites, but just couldn't connect the dots. Michael Hartl does an unbelievable job explaining web concepts in a simple, concise manner.
I can't recommend this resource enough.
You'll find this book, as well as a number of other books in the series, all freely available at the site: http://learnpythonthehardway.org/book/
Also, a tutorial for beginners can be written by someone who isn't an expert, but is a full or part-time professional writer or communicator. A tutorial for experts must be written by other experts, who don't have the time to learn and practice communications skills as much.
A bit domain-specific, but fantastic.
You've taken a job that you know very little about, that thousands of people try every year and fail and broken it down to simple 6 hours to rent an apartment and make a cool 1k an hour - seems like you've been watching alot of HGTV.
Thousands and I mean thousands of people try to make it in the NYC Real Estate world every year and come out broke and jobless. Most of these people probably came in thinking along the same lines you are.
Is the fee unfortunate? Yes, do people understand exactly how much their paying - maybe not. Does it take someone six hours all by themselves to rent an apartment? Nope.
I'm not sure if you're a programer or not but what you've done here is basically the equivalent of me saying "Eh, that's one page of code? And he types at 60wpm? That only took him 4 minutes. Why am I paying him more than $2.44".
Well, you're way off on your math. Just the communications and scheduling of those 9 prospects (and dealing with no-shows, late-shows -- not to mention getting there and back, because it's not like you can get them all to show up in the same time window, back-to-back) involves a very significant multiplier on the 20 minutes per actual showing (1.5 hours per actual, physically appearing prospect) would be a better estimate).
And ditto with the overhead on everything else you're mentioning. Plus they have side costs, and (significant) downtime between clients, etc. I'm not saying these are wonderful people that deserve every penny they're paid. But there's no way the "average" broker is taking in around $7k a week (or $350k a year) as your math would seem to imply.
My argument is that a better model is to compensate the agent hourly vs. commission.
If that was in any way viable it would have happened along time ago. There are reasons the compensation is commission-based; it's because it's basically a sales job, and the same remuneration logic applies: you get paid for closing a sale -- not for posting ads on Craigslist, or for talking up the parquet floors and fireplace and how great the restaurants are.
For example 20 mins per showing assumes they teleported to the apartment, right?
You didn't include all of the fixed costs, like the broker's rent, staff, insurances, cars etc. You didn't include the time spent haggling with the property owners.
So lets assume the pay is lower but still high - say $200 an hour. That is still alot. Why aren't people advertising on craiglist themselves.
On to my second point:
I don't live in the US. Buy my wife sold her apartment herself without an agent (broker) for a good price. She tried an agent first but they were not interested in putting in that much effort. So I agree that these overpaid agents are not always needed.
So why do we need brokers/agents in 2014 when most of the work is marketing, which the internet takes care of (and isn't a lot of work)?
Premium properties and fixer-uppers excepted!
There's plenty of room for disruption - many companies are tackling it, basically growing the concept of "pocket listings" for rentals - but NYC has a high volume of renters and it's a difficult market to convert to a new business model for something as entrenched as real-estate.
From the agents perspective: Its a much harder job than you imagine. You have no control over the quality of your product, or its pricing. Also you can do just a few visits per day.
From the landlords perspective: When you own several properties you will have better things to do with your time than do a real estate agents job.
Anyhow the issue isn't with real estate agents. Its with asset inflation vs wage stagnation. Start complaining about that instead !
Pastoral utopias based on technology depend on industrial dystopia.
No competitor is going to get better deals with UPS, Fedex and USPS. Partially because Amazon has located warehouses such that they help negotiate better shipping contracts and thus provide better customer service.
It has dumped everything that could be a profit into expansion for twenty years. A newcomer would be hard pressed to sell me a Kindle, a movie download, a used book and bearings for my clothes dryer all on the same order at an attractive price and with an aggressive delivery schedule.
If your idea might have legs, some VC will back it.
Can you be the best site for selling pewter figurines, plumbing supplies or bowling equipment? I think you can!
By niching down you can develop a reputation, have a custom-tailored search and navigation setup, etc. As you start getting more customers and income, you can broaden your offerings.
For instance pewter figures -> fantasy art -> fantasy books -> board games.
Amazon started with books before it started selling everything else. You could try the exact same strategy.
Y Combinator funds that sort of thing, and can help a lot with turning an idea into a growing business. You can still apply late for the Winter cycle, though if you don't have the complete team yet the Summer cycle might be better. http://www.ycombinator.com/apply
You are going to need investments to roll out an idea on this scale. But work up an initial version to prove the concept. The farther you can bootstrap it the more equity you'll retain.
Therefore, your first step is to spend a few billion dollars building datacenters, hiring programmers and product people, and create a competitor to AWS that has approximately equal market share. That should take 5-10 years.
When you are done, you can start your e-commerce system that competes with Amazon's. You'll have the infrastructure that costs about the same (i.e. is similarly subsidized) and you'll have a fair fight.
Coderwall has around 500,000 unique user sessions per month, and it's all software developers. They monetize in a few different ways.
(all the revenue is listed transparently at https://assembly.com/coderwall/financials and more detailed breakdown for October is here: https://assembly.com/coderwall/posts/coderwall-s-october-fin...)
1. Job postings: companies pay to list jobs to the community. ($99 for a 30 day posting)
2. Ad partnerships. One is a retargeting partnership with Perfect Audience that pays about $15,000/month and another is partnership with New Relic where users can deploy New Relic and get a coderwall t-shirt (and NR pays Coderwall per deploy)
I actually think Coderwall could be a much larger business than it is given the strong, active userbase, and the community is working on that. If you have questions about this, ping me at email@example.com
For example, http://portland.craigslist.org/ charges $25.00 to run a "software / qa / dba" ad for a month, but nothing at all to run such an ad at http://spokane.craigslist.org/
It's not really the traffic that counts, but conversions. How much money do _you_ really need? Are you working full-time on this? If not you might be better off to charge little or nothing, so as to build market share.
Most job boards don't do much to market themselves, other than maybe send some spam. There's a lot you could do yourself. Suppose you have a local job board, you could show up to MeetUp groups and the like to promote your board, pass out handbills in public places, send flyers around to student employment offices at universities.
You won't need much traffic at all, if the people doing the hiring are able to find lots of qualified candidates through your board.
This is a highly competitive area. There are bazillions of job boards, however most of them totally suck, so you have the opportunity to do well by doing good.
Who are your main users and why would they come to the site? Teachers? If so, what level - school, college, postgrad? Managers who purchase stuff for the teachers, maybe?
I would imagine you will also have to take into account the skills being demonstrated on the site and the value they have to employers. If your site will attract the best and brightest (e.g. top coders on StackOverflow) whom employers want to recruit, then I think the job listings would be more valuable than if it's mostly made up of people looking for free stuff to save themselves the hassle of making it themselves.
Once the audience is built up, by specializing and being in a niche you should be able to charge MORE for postings than a more generic job board.
We put together a pretty comprehensive blog post a while back on the topic of job board marketing and promotion, you may find it useful:
It covers things like email marketing, social and using backfill to beef up your inventory....hope this helps!
Your best bet if you don't have a strong feel for things is to allow free listings initially and then offer upsells (for example, a fee to have the listing mentioned on the site's Twitter account or in a single, tasteful link on the homepage).
If you are catering to a very select, focused audience then you don't need volume, because the specificity is your selling point.
There is a lot more than traffic that companies look for in a job board. Since your site is based around educational content, try to find profitable, untapped markets related to this and focus on only those markets at the beginning.
You can be creative with this: for example, hedge funds routinely pay top dollar to find the best PhD students in math-related subjects, so maybe there is a way to bring both together.
It works but you have to put in effort, it's a massively saturated market.
My tentative plan is to start with Coursera's Neural Network course and implement as many things as possible (probably in Python) along the way. By the end of 2015, I'd like to build a deep learning application from scratch that does something interesting.
While online resources will likely be my primary source of information, I'd love to have a study partner (or partners) to discuss concepts and bounce ideas off of. If OP or anyone else is interested, drop me a note at firstname.lastname@example.org and we'll figure out the best way to do that.
edit: here's the ebook link neuralnetworksanddeeplearning.com
Almost everyone will say "oh, I didn't want to derail the project, let's just move on without it". Some people would rather pay, and I'll gladly take their money.
Recently, I requested a client to sign an Indemnification and hold harmless agreement. The client came back expressing their concerns about couple of clauses and requested to remove them. I replied with details on what is the purpose of those clauses and how they protect both parties. I also suggested to the client that they are welcome to suggest modifications that achieve similar objective and situations as original clauses and also address their concerns.
Once client understood the reasons for those clauses, they signed the agreement without requesting any changes or removal of those clauses.
If the NDA is also a non-compete then no way in hell, but if it is a simple don't disclose my information to third parties, I don't see the harm. No one can prevent you from using knowledge, hence an NDA doesn't stop you from telling your next client hey I know how to do X because I have done it on 3 projects now.
What is the concern? Am I misunderstanding or missing something?
If that's the case you can word the NDA so that it gives them what they want and you don't give up anything you don't want to give up.
It could also be that in order to implement the game (or whatever) you could require access to business strategy information (like pricing, upgrade dates...) that they want to keep secret. You can word the NDA to cover this but not the technical stuff.
Or if none of this applies then you can point out that NDAs don't cover information that is available publicly so any "ideas" typically won't be covered once they are publicly available.
And as others have pointed out always have your own template to start from.
My opinion and experience is that attorneys and law firms are there just in order to prove their usefulness - nothing more. And they are not useful at all. It happend SO many times that an agreement (not necessarily NDA) was kept by the "lawyers" for 3 weeks and then returned with some realy idiotic comments, exposing genuine iqnorane of the project we were working on.
Often, after the lawyer's review, they don't even put project leader's names, dates, bank account numbers, payment time, currency, phone numbers or other details in the agreement and such papers are later signed by CEOs (I wish I could one day show you these documents).
It seems to me that very often clients keep the documents for weeks, delaying the project launch, supposedly scrutinising and reviewing the paperwork, but are returned without being read at all.
We are now trying to sell our product to a minor supermarket chain and they asked us to give them source code to our software platform. When we told them it was impossible, they said that they get the source for every piece of software they use. That's nonsense, we replied and asked if Microsoft gave them the source code for Windows.
The same goes with NDAs - they think that their systems or business processes are so important and require special protection as if it was some kind of serious secret although it's just some simple intranet or knowledge base portal that we build for them.
Clients, negotiators, buyers, lawyers are incredibly ignorant when it comes to technical stuff.
* - (I'm not saying that agreements or legal advisors are wrong in general, just that very often the protection measures and suspiciousness are blown out of proportion)
If potential client will continue insisting on vague language - scrap him.
Then you say: "Fine, and you will need to sign my NDA".
There are perfectly honest reasons to decline and or modify an agreement. Simply state them and offer your earnest intent to make it work for everybody.
To quote Tyrion Lannister: "Let me give you some advice, bastard: Never forget what you are. The rest of the world will not. Wear it like armor, and it can never be used to hurt you."
I tend to think that Internet folks have overly exaggerated impressions of the risk profile associated with having basic biographical information available, by the way. This is not a unique cross we have to bear -- every dentist, lawyer, McDonalds franchisee, etc has the same "problem." The vast majority are never targeted by the Internet hate machine.
The most annoying thing to have happen to me from having my identity public in ~8 years, aside from online criticism, was having someone find my cell phone number on WHOIS and ask for advice at 4 AM in the morning. My advice was to send me an email and schedule a call, like a considerate person.
And if you are in a business, you are likely to want the opposite of anonymity.
If your state of well-being depends upon absolute and total privacy, you will need to take rather extreme measures. Probably starting back in 1992.
So I think I'm just going to keep these accounts anonymous and just use my blog, GitHub, and Stack Overflow as my professional public persona. I don't have a problem putting my name out there as long as I know what I'm writing can be directly tied back to me (not that anything on the other sites are particularly bad I just wouldn't want employers and such having direct access).
I have helped a lot of small businesses with their technology, positioning and marketing and this is one of the most common issues owners bring up. Typically they will say they don't want to be "known" or be out if front because they worry about their identity and the issues around it. Sometimes they say they want their brand to be known not them, but in the early days their brand and themselves are the same which people don't understand a lot of times.
However, it is the #1 mistake I think people make if they want their business, or personal brand to grow. You cannot hide, you cannot turn down press, you must be out there and be genuine. I do advise clients though, that if you are posting what you know to be controversial content on a forum, blog etc and you feel it would be damaging to your brand then first, don't; but if you must, do it anonymously. The problem I see is that rarely is anything ever anonymous, even when you think you are, so its easier just to be you. On the controversial comments, I don't mean that you simply disagree with another view point i.e. you think Ruby rocks and node sucks. I mean when someone has a view that is anti-pattern to common polite society, e.g. racist comments, sexist comments etc.
A couple of my favourites: Birchbox (birchbox.com), Treehouse(teamtreehouse.com), Intercom (intercom.io)
The Github Octocat is also awesome :)
In practice, the state of California makes it next to impossible to enforce non-competition agreements. You are legally allowed to earn a living without indenturing yourself to one employer.
Put this out of your mind. NCA's are routinely signed and ignored by nearly the entirety of the bay area. Even the high-profile cases involving executives/founders jumping ship and joining the competition tend to focus more on nondisclosure rather than noncompetition.
If this is another state just let us know.
I'd say forget it and get on with life. And yeah, think hard before signing anything: there's always time to think about it.
* Unless you are starting a company in the exact same business right now.
Don't waste your money on a lawyer. (Many people here are overly paranoid and will tell you otherwise.)
If so, then you may be in a bind.
If not, I would email them letting them know you plan on ignoring the non-compete. Explain your reasoning.
I would send an email to the firm asking them if you're still bound by it. I would also seek a lawyer to read the agreement you signed and advise you of your rights first.
Books, with rare exceptions such as that of K.J. Rowling's and Dan Brown's, are not a global phenomenon, draw less attention, making the crime of piracy less tempting or less lucrative. Books are more elitist and TV series more vulgar. That's also the reason why it's more profitable to harvest clicks on porn or pirated music than on metaphisical poets such as John Donne.
Since there are fewer book pirates it's also easier to track them vs. millions engaged in pirating movies on P2P networks.
My second guess would be that e-books are quite a new phenomenon (in terms of the recent surge in popularity of e-paper readers and tablets) compared with optical drives and tapes that were around for a couple of decades. DRM techniques were much less advanced and so piracy could flourish. The market and the music or film industries were so badly hit that they had to find a different business model to make ends meet.
Kindles and iPads are made with DRM in mind, the techniques are more advanced today, and the publishers have not been threatened by piracy so much as by the shrinking readership. Also scanning entire books could not have been done so massively and easily as copying music or films.
Finally - a word in favour of piracy - I can imagine, although it's just a guess, that it was exactly the piracy that drove evolution and innovation in film and music towards more spectacular entertainment, 3D, iMAX, 4D, live performance, stand-up shows, HD tv screens, VR goggles, 5.1 stereo, group gaming, motion sensors etc. etc., because watching flat, low res. series or films is not considered a proper fun anymore (even The X-files seems boring today, not engaging enough, from a different epoch, like ballet).
The piracy exists on both and is trivial for most readers of HN to perform, but for casual users of Kindle and iPhone it is a bit of pain.
Bezo is giving a particular viewpoint looking at the issue from Amazon Kindle window. That is, if you are a regular user of Amazon Kindle it will be very convenient for you to buy a licence to use e-books within Amazon ecosystem and relatively painful to pirate books.
If you are just a tiny bit technical you can easily strip Amazon DRM (used to be a simple Python script) for backup, in case Amazon decides to recall a particular book.
You can also pirate books on Kindle, but you will most likely need to convert books to Kindle format .mobi using Calibre unless you like reading misformatted pdfs. Again simple but for someone who is not actively searching and is happy paying Amazon, not something they would do.
On the other hand if you are using a competitor's device, it is relatively easy to find books to pirate in .epub format but the market share is much too small to matter.
I do not go out looking aggressively for pirate sites, but there are a few Russian based places(hint: library of biblical creation) where you can find pretty much any book released in the past 10 years, most books released in the past 10-20 years and some books released earlier. If you can't find it on that Russian site you can find it in Indian or Chinese forums. I am sure there is American ebook pirate scene too but I did not pursue the matter.
So it is a combination of factors: Amazon being the market leader with its closed eco-system and ease of purchasing, the lack of clear poster child for e-book piracy since the demise of library.nu 2 years ago, the fragmentation of ebook pirate market.
Disclaimer: I own multiple e-readers including a Amazon Kindle DX demo model that I reflashed into a regular one.
It seems (I've never done it) that it's fairly easy to copy music or movies into mp4 or mp3 format and strip the DRM. How would you do that with an e-book? What format would it be coming from? What would you copy it to? Is kindle the standard?
The lack of availability, means that you're more likely to find the book you want in the digital book store, and not have to hunt around for it on a torrent site or something. You also don't have to worry about the format of the book working well with the format of your device. Though this may have been an issue for music and movies at one time, I don't think it is anymore.
Lastly, what is the motive of a person who is going to copy or steal a book. First off, I've got friends in digital publishing at a major publishing house, and I've never heard of a time they are not concerned about keeping their jobs. They get paid nothing, and the idea that 'Publishers are having unparalleled profitablilty' is questionable. They have lower revenues per book, and lower costs per sale, but overall, they haven't been able to cut the overhead of editors, marketing, etc. to make the businesses more profitable. I don't think we look at stealing a book and think "the publisher and the author are making squilions of dollars, what's the difference if I get a free copy". It also appears that book publishers don't play the games that other media publishers play with respect to having the correct viewer rights in this region, delayed release dates, etc. etc.
We also spend much more time with a book than a movie, and though music may stick with us for a longer period of time, we are probably less inclined to consider an 'amortization' of the number of times a song is played version the amount of time we spend with a book.
If I'm going to dedicate time over the next 3 weeks to reading a book, I'm more willing to pay $10 for it, and I can always go back to it, vs paying $7 to rent a movie which is only available to me for the next few hours.
Your problem does not stem from the fact that images are covered by copyright, but from violations of license terms.
(A bit nitpicky, perhaps, but I figure if we're going to solve a problem, then we first ought to know what the problem is.)
If you're really freaking, perhaps I could flog my consulting service, and write the program for you under contract?