MortenK

"In high-end contracting work, daily rates are industry standard. If you have the option to bill on a daily increment, why would you ever bill hourly?"

This advice is rather black and white, making it not exactly spot on for a large variety of cases. "X is an industry standard" is also rarely entirely correct. Ex. While daily rate might be standard in the UK and US, Scandinavian rates are almost always hourly based. Russian and ukranian as well, and most likely a whole range of other locations I know nothing about.

If you contract for a professional services firm that re-bill your hours, you're going to have an explanation problem when they see 3 hours logged and a full day billed. Conversely, the "full day" is easily stretched by a client-in-need into 10 or 12 hours, which leaves your hourly income plummeting by 25-50%

In this particular case, your best bet by far is to bill hourly. This applies to a variety of other cases as well, which is why there is no such thing as a universally applicable approach on consultancy billing, and such really shouldn't be given or taken without a huge disclaimer.

That might be, but that's not relevant to the point of what dosage is necessary for a psychological effect.

This is not entirely true. Tramadol are often given in doses of 3x50 mg a day for pain relief. To a user with no tolerance, the most common lowest dose, i.e. 1x50 mg is certainly more than enough to give a euphoric feeling, ability to concentrate, stress relief and a whole range of other effects. Effects obviously can't be compared to "real" opiates, where the effect is much stronger and have more of a sedative effect. It should also be noted the effects vary quite a bit depending on the individual, i.e. some people don't have much of a reaction to Tramadol.

You think it's reasonable that he should continue at the helm of Mojang and retain control of Minecraft IP until what exactly? 10 years pass and the brand (which Minecraft has become) finally fades in popularity?

So he can release it as open source, to make good on what? Some "About" page he wrote fucking 4 years ago when Minecraft was nothing but a PC indie sleeper hit?

Get real.

It's absolutely astonishing to me that SV investors and incubators pass along ~4 million USD to a team of people with so little business experience, as to neglect hiring an accountant. End result being unpaid payroll tax for almost 3 full years!

No one ever asked what accounting firm Amicus used? No one ever just glanced at the finances and thought hey, where's the frigging payroll tax? Is valley capital so readily available as to warrant this kind of extremely low investor engagement in funded companies?

No written founders agreement either. I mean this is basics, and it should have been caught or taught by the accelerators and the investors.

This is not a shot at the OP, who I think is exceedingly brave to write such a public, honest and informative account of their screw-ups. Competence comes from experience and everybody in business has been incompetent at some point.

Rather, this is a massive failure on the investors' and accelerators part. With all the talk of "funding the team, not the idea", you'd think there was a bit deeper understanding of team experience and competence, than just some degrees from an ivy.

It's mind blowing that investors can be so careless with their cash. I wonder if it's a common occurrence or if this is an outlier situation.

I think it is important to understand for new programmers that being self-taught is often tough, since your paper credentials are non-existent. So you got to expect a couple of years of low-paid, mostly ungrateful work, and you have to be really persistent in chasing up assignments.

A specific tip is to always try to get a reference / testimonial from the customer. And always document your projects with screenshots etc. My paper credentials when I started out were really shitty, so the "portfolio" of screenshots and testimonials were all I could give to prove that I had at least some experience.

My story:

I started mucking around with VB 4.0 because I wanted to make games. Got a copy of "Peter Norton's guide to Visual Basic" on a recommendation from an IRC chat room and started reading and doing the examples. From there I did small utils for my own use, small games etc.

At the time I worked in a games / software shop and one day some guy came through the door looking for something that could format a huge data file. There wasn't really any shrinkwrap software that could do it, so I offered to make him one. That was the first gig and I charged like 400 bucks. Felt huge at the time :-) By then I had been "hobby programming" for 1 or 2 years.

The first assignment really lighted the fire though and I started trawling any channel I could find for assignments, programming competitions, charity projects and the like. Anything that paid money or could be used in a portfolio.

The channel was mainly Usenet, whereas today it would be sites like oDesk and the like. Eventually got a part-time job with a young entrepreneur, where I learned some HTML, spent days getting a mouse to work on Linux and cleaned and sliced carrots for lunch (which I thought was waaay below me, but it had to be done :-).

Read a whole lot of different stuff, and applied to a lot of companies. After 6 months to a year I ended up in a more professional company doing web "programming" part time (HTML and a bit of JS basically). A years time later I got full-time and into more serious programming.

After ~5 years I shifted into management and ultimately consultancy, but still program quite often for my own purposes.

Because a UI control exists before Windows 95 doesn't mean it's understood by the majority of users. Also, there is a larger amount of users with minimal software exposure now than ever before, due to tablets and smartphones.

If your computing experience is limited to iOS for example, chances are you'll never even have seen a nested tree view control, much less understand the hierarchy behind it.

At least just read a minimum on usability and UX, before being so rude as to "call bullshit" based on your own personal opinion.

For developers and other tech guys maybe. But the average, non tech savy users have a very hard time understanding hierarchies and therefore tree controls. It's to such a degree that UX specialists like Alan Cooper strongly suggests never using tree views unless the data is naturally thought of as a hierarchy, such as a family tree etc.

You have a choice between re-organizing and leaving. If you decide to re-organize, icambron's advice on this thread is really good.

But if you are beyond that point, and it sounds like you are, just get out. Take your co-founders out for a beer and give them straight and honest talk. Some might get disappointed, but more likely they will be sympathetic. Even if they are not, it's their problem. While I understand the pressure, you mustn't sacrifice your health for other peoples opinions.

You emphasize freedom a lot. As you know, this can't be found in an agency setting, as ultimately you are at your clients' beck and call.

If freedom is your top goal, you should aim for independent, freelancing / consultancy or potentially becoming a micro ISV.

A possible solution could be to withdraw from day-to-day management, and act as a part-time, possibly remote freelancer for your own company. Doing what it is you like to do for perhaps 10-20 hrs pr. week.

Your co-founders may or may not accept that, but it's an out that could work decently for both parties.

1) Sure, when talking freelancers / contractors you of course have to account for a ~20% deduction for sickness and vacation. So the base wage increase is often around 100% but compared to a full-time position, it is closer to a 50% increase.

2) It is only unrealistic for freelancers doing many small jobs. Not for contractors with ongoing 40+ hour contracts, of which there is a lot on oDesk. Maybe the confusion is semantics: When I talk of 100% allocation, I mean 160 hours of available work. Over a year, you'd remove 10-20% for vacation and illness, like mentioned above.

Check the work history of the higher rated contractors on oDesk if in doubt about this. There are many doing much more than 160 hours on average.

3) This is certainly not the norm :-) Not a lot of companies are interested in hiring a person a thousand miles away for the same amount of the guy next door. Especially not the type of companies who can afford developers contracting at high-cost market rates i.e. 100-300 USD pr. Hour. Again, if we are nitpicking, there are of course exceptions like especially well known developers or developers who are proven and known to a specific client. Then it's an entirely different story.

The broader topic for this is "outsourcing". When work is done 90/100% remote, to countries far away, it's commonly referred to as "offshore outsourcing". It's a whole separate production discipline, with unique challenges all the way from staffing to day-to-day management.

Many business people and entrepreneurs try offshore outsourcing a couple of times, lured in by the seemingly low prices. They then fail and declare outsourcing as a non-viable solution for product development.

It can and does work, but it requires experience.

So while you are looking for specific tips for searching for developers, you need to be aware that the work doesn't end there - there's a lot more to it.

To get specific though:

1) Always create a private job and invite developers yourself. If not, you'll be spammed with offers from the bottom of the barrel.

2) Filter for location first. If it's your first time with outsourcing, you are best off with developers from countries that are as close as possible to your own culture. For Western Europe, a good bet is Eastern Europe and Western Russia. In the US, you're probably better of with certain south American countries like Argentina and Chile due to the lower time difference.

3) Look for developers that has had long contracts (500+ hours) with 5 star feedback. You can't base much off small contracts with 5 star feedback.

4) Apply same screening techniques as you would, were you hiring locally: Does the guy have an impressive portfolio, CS education, does he have some side projects / Github profile etc, how many years of experience and so on. Don't put too much stock in any single point: There is for example plenty of extremely competent people, who do not have a degree, who do not give a shit about maintaining a Stackoverflow or Github profile and so on.

5) Once you've screened them, invite them to the job listing. Get them on skype, either talk or chat. They need at least a very good written English, if it's your first try with outsourcing. Ask for code samples and review them.

6) If not "just" front-end coding: Have a good, thorough specification ready, for the developers to read. Sometimes they will want payment just to read the spec, sometimes they'll do it for free. Either way, it doesn't show much about their competence.

7) Ask them to deliver a written deliverable of something reasonably advanced. Stuff like a suggested database model, or a very high-level overview of a proposed architecture for whatever it is you are building. This will usually be paid work, between 4 and 8 hours. The purpose is not to get the absolute right db model or architecture - it's to see a written deliverable from the developer. This is invaluable, since it requires real skill, thinking and communication abilities, while still being relatively cheap. If they cannot deliver this, they are not good enough. An exception is if you are looking for some front-end guy, then just get a sample of their markup.

8) Monitor their work closely in the first period of time (first 2-3 weeks is usually enough).

9) Be ready for disappointments. Even with all the above work, you will still not hit a good guy every time.

10) If all else fails, drop me a line, I'll be happy to assist :-)

This is entirely wrong. You are comparing US and Western European high-cost market with the lower cost markets of Eastern Europe, Asia and South America. Yes, a contractor in a high-cost market, offering his services on oDesk won't be top caliber, because he should be able to get local contracts with much higher rates.

But contractors in lower cost countries are just as capable, while charging one third to one fifth of Western European / US prices. While this sounds low, the living cost, tax rates and average salaries are such, that oDesk freelancing becomes very appealing for a person in such a location.

A specific example: A frontend dev salary in Eastern Europe (full-time position) of 3.000 USD a month is quite decent. On oDesk, he can charge 25 to 30 USD pr. Hour. If he is good, he will end up with full allocation, and thus a salary of 4000 to 5400 USD pr. Month given a 160 hour work month. Additionally, he also has the personal benefit of working 100% from home, at hours which he usually has some control over.

Being unable to find good people to work with on oDesk and similar sites, is due to lack of experience in outsourcing, not because it is a market for lemons.

Hiring managers are looking for proof that you are as good as you say you are. Inexperienced / young programmers often vastly overestimate their own abilities and experienced managers know this. Having hired a couple of gung-ho self proclaimed supermen only to see them not deliver, the hiring manager now wants to see proof.

If you are new in the industry, you don't have people to vouch for you. That's why you get requests to see your actual work, rather than own cherry-picked code examples.

"I could do it easily if I just got the chance" won't fly if you are in a location where there are more developers than jobs. You'll have to make yourself stand out. The easiest way to do that is to build stuff. Doesn't have to be groundbreaking stuff, but it should work and be within your "specialty" language(s).

Then next time someone asks you for a non-trivial example, you can just send them a couple of your projects, rather than a couple of clever code snippets.

I use CHM format, sometimes exported to HTML if need be. I use www.helpndoc.com for the purpose.

Software development management:

Steve McConnell: Code complete

Steve McConnell: Rapid application development

Frederick Brooks: The mythical man-month

Hiding connections to previous workplaces is shady to a hiring manager because the assumption will be that you were the problem, not them. Why else would you hide anything?

The saying applies "You run into an asshole in the morning, okay, you ran into an asshole. You run into assholes all day long, you're the asshole."

It's the same reason you don't badmouth previous employers or coworkers in a job interview.

Depends on how you define top technology companies, but many large software companies (5000+ employees) uses UML as a part of their systems architecture deliverables.

Whether they are worth being designed will very much depend on who you ask. The architect who spends a lot of time on designing them will of course be very much in favor. He might feel they properly communicate his architecture.

Certain business types might favor them, on a more simple account - they look deliciously technical and can be used to persuade a customer "we really know what we are doing".

My personal opinion is that certain diagrams can be useful. In general though, way too much time is wasted on doing these diagrams, which aren't going to be at all representative of the end system.

It's not a good communication tool, and it'll in most cases be hopelessly out of date just a few weeks or months into the project.

UML also smells of a top-down approach where the star architect is sitting in an ivory tower handing down blueprints to lowly developers. That kind of approach goes against what I believe about successful software development.

There's useful elements in UML and you definitely won't be worse off if you understand it. But I do not think it's in any way required unless your aspirations are to be developer /architect #2032 in BigCorp.

But again, it'll depend on who you ask.

Some types of errors might be easier to make in one language versus another, but a language that through syntax eliminate the possibility of all errors, is of course a ridiculous notion. Cherry picking particular error types that are avoidable in the authors language of choice, does not prove anything.

The concept of why code does not matter, comes from development management literature. It's not a case of actually meaning "I'm ashamed of the language and the techniques I use". That's an awfully developer-centered point of view.

The influential factors of a successful software project are mainly the quality of the people involved. Next product scope and from there a huge drop down to development process, and finally technology, i.e language.

It's been statistically shown that barring a crazily bad technology choice (Visual Basic for the space shuttle kind of bad), language has very little influence on the success of a project.

That's of course not a nice thing to hear for a developer who's convinced his language of choice is the one true language. Regardless, it's well established knowledge, gained years and years ago through statistical analysis of thousands of projects.

I hate selling cars. It's troublesome and time consuming, so you I'd gladly pay for the service. The pricing turns me off though. Selling a 50K car, the commission would turn out to 2.5K. That's net. So with 50% income tax rate, I'd have to earn 5K to pay the commission.

That's much too steep for me. If there was a cap of say 1K, I'd be a customer in a heartbeat. But 5K gross is certainly worth the inconvenience of selling it myself.

Different companies have different definitions for junior, senior etc. Like other comments mention, it's mainly length of professional experience.

Many places defines senior developers as having +5 years of professional experience (i.e. excluding college). But it varies a lot from company to company.

"Remember the discussion is about employers feeling entitled to owning employees time?"

No, that's actually not at all what this discussion is about. That's what OP's situation is about. My post made two points:

1) If a company is mismanaged or just plain taking advantage of you by requiring regular overtime, then leave such a company.

2) A company (not OP's company) who is well managed and does not require regular overtime, pay their wages on time etc, should be able to expect at least a little bit dedication from their employees. No you don't have to tattoo the product name on your chest, but it would suit you to help out your managers and colleagues in case of (rarely occurring) emergencies.

"Why is leaving after five the way one demonstrates caring about the business/product/team?"

It is not. The way you demonstrate your lack of care is if you insist to leave, even in times of uncommon crisis.

My points from the original post:

1) If it's business as usual = Work the 7-8 hours.

2) If the business has constant emergencies or otherwise requires you to regularly work more than 7-8 hours = It's a badly managed company and you should leave if you aren't in a position to change things.

3) If the business very rarely encounters emergencies: Stick around if you reasonably can, and help your managers and team members get the emergency resolved if this is within your skills and area of responsibility.

Entirely agree. My post makes two points:

1) It should be very rare that work above the normal 7-8 hours is required. If it is common, you are in a dysfunctional software development organization. My advice to OP in this case is to leave.

2) If you and your peers normally work 7-8 hours, it is not unreasonable to expect (for compensation of course), an extra effort in terms of overtime / weekend work in times of extraordinary crisis / emergency.

1) I'm not sure I understand your first paragraph, feel free to correct: Who else than the developers can actually take responsibility for solving the fire in the kitchen? The business of course holds ultimate responsibility for any aspect of operations, but developers are particularly hired due to the business itself, as well as the managers, being unable to handle such a crisis directly. A developer who abdicates such responsibility, is in effect telling the business they can't be relied on in times of crisis, unless it happen to be at a convenient time for the developer.

Like I stated earlier, a business in which crisis are so frequent as to occur daily or weekly, is badly mismanaged and dysfunctional. Such companies will hide under false pretenses like "that's just the way the industry works", while frankly straight up abusing developers. Crisis should by all means be extremely infrequent, otherwise there's a major management problem, which of course can't be the developers responsibility. I'll restate from all my replies in this thread, that if OP is in such a company, he should leave.

2) In the variety of European countries where I've worked, compensation for over-time is a non-issue - I did not mention compensation explicitly, as it's obvious to me - it's indeed against the law not to compensate. You'd either get full-pay, 50% to 100% increase (usually for night and weekend work), or you'd get time off. From yours and other responses, I gather this is not the standard in the US.

3) Certainly there were deployment procedures, however this developer decided to bypass staging, testing and even didn't perform a smoke test which would have shown the crashed application. He deemed his code of such high quality that nothing could possibly go wrong. And while he didn't follow procedure and therefore caused a minor scandal for this particular company's public image and lots of lost customers, he didn't see why he should be involved in recovery, since it was after 5 o clock. Instead his teammates worked until long into the night, to find out what had actually happened before finally fixing it.

I've only encounted unpaid overtime in chaotic sweatshops, which are similar to the companies I mentioned, of constant fires / crisis'. These are so uncommon though, and the practice by all means illegal, that I'd think it obvious that over-time is compensated one way or the other. Are you in the US? My experience is from a variety of European countries mainly, which might differ vastly from american standards.

Yeah definitely seems I have touched a nerve. Just had all my replies being drive-by downvoted by some guy even :-)

In any case, you make a good point. Basically he values a fraction of his time more than any negative, however big, inflicted on his company and his team members.

"The reason for this is because a business needs to avoid having emergencies "

Exactly what I wrote in my post, if you'd actually bothered to read the lower half.

"If there is an emergency and an employee does need to stay later, you need to pay that employee overtime"

I didn't write anything about compensation - I would think it entirely obvious that if you work overtime you either get paid or take compensatory time off?

1) Of course, but if you do not care at all for the business, the product or your team, your not exactly a paragon of the model employee are you?

2) Leaving at 17 under ordinary circumstances is not flaking out. If there is a major crisis which happens in average maybe once every three months, and you consistently can't be arsed to put in some extra hours of effort while your team mates and managers are, then yes, you are flaking out.

Certainly. Is there anything in my post that suggests flexibility should not be two ways?

Where did that come from... Did you read the post in it's entirety?