It seems to me startups can be divided into two major groups: those that intend to make profit and those that intend to consume capital. Ostensibly every startup wants to grow big and make millions in profit but observation of their behavior implies otherwise.

Burning VC money is actually the smart way to make money as a startup founder. Buy a fancy suit, make a shiny slideshow, throw around some buzzwords, and rake in piles of money from wealthy wanna-be investors who wouldn’t know a router from a Roomba. Rent a company house, lease a company car, eat at company lunches, go on company retreats, then pay yourself six figures for doing all that “work”. When you run out of cash, beg for more. When rich idiots get tired of subsidizing your lifestyle, blame the economy, the competitors, the employees, or whoever you can. Rinse and repeat.

The alternative is to actually work. It’s a foreign concept to many these days. Since profit is a function of income and expense, when there isn’t enough income you have to cut expenses. Personal frugality is not as fun as pissing away other people’s money. It may not ever pay off either. You could work 60 hour weeks for years only to have the whole thing fall apart for reasons outside your control. At best it pays for a handful of people to live a modest lifestyle.

So how do you tell? Seeking VC money is not an indicator alone. Some companies fail to get VC funding despite trying. Others use VC funding to seek profit in earnest. Profit itself evades pursuers more often than not. Like anything else in life, you see true intentions when a mutually exclusive choice arises. Look at executive compensation. Do the take a modest salary until profits justify the expense? Do they forego payment entirely when money gets tight? Do they have the company pay for their housing when it can’t even cover the office out of revenue? Will they take a substantial pay cut in order to hire necessary talent? Do they buy toys and throw parties on the investors’ dime? Do executives go on long vacations before managing to turn a profit?

It’s not cut and dry either. I worked for one executive who leeched housing off the company (in an expensive city) but was willing to cut his (moderately high) salary in half to take on a skilled developer when the opportunity arose.

Both types can benefit you as an employee as long as you know which type you are in and what phase it’s at. Capital burners are all fun and games in the beginning but become a stress-filled psychotic nightmare when the money runs out and the technically incompetent executives panic to keep up the facad and bring in another round. Small profitable startups don’t grow into billion-dollar unicorns. Life is slow and steady but you have to get real work done. You won’t be able to come in and screw around four out of five days per week. The managers will also know the difference between real productivity and the illusion of it. I’ve worked in both and don’t prefer one over the other. You have to keep your eyes open and know when to jump ship in any company, regardless of intent.

This may seem cynical, but never do more than you are told to do.

There are two reasons to color inside the lines. First, you expose yourself to risk. When management asks for a feature, you estimate conservatively, keep a log, and blame them when anything goes wrong. When you build in unrequested functionality it’s your neck when something breaks. Or when someone else’s code breaks and they blame it on your maverick code to save face. Unrequested code is presumed guilty even after proven innocent because blame cannot flow anywhere but the author. It’s a safe play for anyone above you in the management chain.

Second, you create more work for others. You may volunteer your time and effort to write unrequested code but other people will have to integrate and maintain it. This is a quick way to make enemies of your coworkers. Your problems become their problems which then makes you a problem for them.

A friend of mine was a developer for a small financial services company. He worked on the back end database for processing all incoming web requests. He inherited a rather naive schema, tortured and twisted with every new feature. The smart thing to do was leave it be and keep shoehorning in functionality. The foolish thing he did was champion a complete rebuild. Being the only half-way competent developer, all the work fell on him. He also had to keep up with his normal workload. He didn’t make a single dime extra since he was paid on salary. Eventually the rebuilt database shipped. He was immediately blamed for three critical production outages over the next few months, only one of them being his fault. He burned valuable social credit with the front end developer who had to integrate changes with an already full schedule. Executives and customers will never even know the difference.

There are exceptions to this rule. Automating existing tasks can pay off big time. Start with a small shell script. Stop when it outgrows the capabilities of bash. A few minutes per day over the course of two weeks resulted in a script that saved my employer two hours of labor per day and eliminated manual errors. If it doesn’t make your job easier leave well enough alone.

An obvious exception is if you’re the guy in charge. Then your job is to implement things as you see fit. Blame for problems falls squarely on your shoulders anyway, as it should. Keep in mind the limits of your authority and discretion.

Another exception is “20% time”. Always work on work projects during this time. Never give them the rights to your personal clever idea or project in exchange for salary you would have gotten anyway. Writing a cool new feature won’t earn you a raise. Refactoring library code won’t get you in too much trouble, if you’re lucky. Career advancement comes through social bullshit and demonstrated skills. Save that inspiration for your Github account where people can do more than just take your word for it. Build your bullshitting skills by selling the normal work you’ve been doing as a new and creative idea when the time comes to show off your 20% efforts.

Taking initiative worked out a few times for me. I got burned more often. Even when it worked out blame flew my way easily. None of the projects benefited my career or earned me any interview points. Nobody cared. They can’t even be maintenanced by remaining staff after I have left. Save your energy, save your ass, save your ideas; don’t do more than requested.

I recently saw a recruiting company ad claiming to provide the “top 3% of vetted senior-level developers”. Ignoring for the moment how to vet developers or whether they can be ranked on a linear scale in the first place, do you need top 3% talent? What even is top 3% developer talent?

Here’s one thing it isn’t: web developers. Not that someone employed to do web work cannot also be a top tier developer, but web development never requires advanced knowledge or techniques. Hell, you only need two data structures. It says something that PHP has an 80% market share. The nature of your specific website or service does not matter. The platform itself is inherently limiting. Hardware access and acceleration is extremely limited. Browsers are a very limiting platform. Network latency is everywhere. Limited end-user bandwidth constrains intensive operations. Javascript, despite recent advances, is still a very slow language compared to C++ in practical circumstances. Oh, and your website has to be able to run on a 10 year old bargain-basement eMachines pieces of junk still using a 1024×768 first gen 4:3 LCD monitor. An ATX motherboard is 9.6 inches wide; the United States is 170,000,000 inches wide. Local applications will always be faster and more advanced than web applications.

Sophisticated remote services are not “web” applications merely because they have a web front end. Developing a custom cloud photogrammetry backend requires top tier talent. Those developers are not web developers. They are application developers. Nothing “web” happens in the photo processing code. All of the sophisticated code lies on the backend servers. The user has no interaction with that code after submitting a job with certain parameters. You could replace the web connection with a flash drive-wielding intern without losing any capabilities.

Here’s another thing top-tier talent is not: mobile application developers. While phones don’t suffer from the severe communications restrictions that websites do, they are still weak little toys. High end phone hardware is equivalent to PC hardware from a decade ago. The Galaxy S8 comes with 4GB of slow-ass “LP”DDR4. CPUs keep shrinking but heat and power limitations are inescapable. A gaming rig can consume a thousand watts. A mediocre desktop scarfs down several hundred. A lean ultrabook still pulls 50 or 60 watts. The S8+ will manage 5 or 6 hours of processing (Netflix with “video enhancer”) on a 3500mAh battery. That works out to 2.7 watts. Draining the battery in an hour still only works out to 13.5 watts. Processing takes power, no way around it. What goes in must also come out. Phones, like Macs, lack the space for heatsinks large enough to support fast processors. (No, Macs’ aluminum cases are not thermally connected to processing elements. Even if they were it wouldn’t help because of comparatively low thermal conductivity over such a large, thin surface.)

Granted, a few mobile apps do require advanced programming skills. Coders working on mobile game engines and operating systems no doubt make the big bucks for good reason. Regular app developers are not among their ranks. Regular apps are functionally little more than websites. Nearly all games use a 3rd party engine. Sophisticated software like panorama stitching uses libraries developed on and for the workstations of old. Phones are never on the cutting edge of programming because they are never on the cutting edge of hardware.

So where does the top tier talent work? Game engine development, for one. Using an engine doesn’t require much skill at all. Heck, non-technical designers can and do build entire games using engine editor GUI’s. Building the engine in the first place is the complicated part. Commercial and industrial application development represents most of the top job positions. Companies like Autodesk, Adobe, IBM and Oracle. Quants can make a shit-ton of money telling Wall Street dude-bros which stocks to buy with other people’s money.

Last but not least are open source projects. FOSS has been systematically replacing commercial software all over the place. Open source libraries do the heavy lifting on more than a few proprietary applications. Do you license a commercial JPEG decoder? How about the compiler you use? The language runtime? The database? Every day it gets harder to avoid using open source packages in a commercial program. Linux already dominates the server market. Most of Apple’s operating system is cobbled together from open source Unix packages. Popular myth has it that open source projects are written by ad-hoc hordes of random developers charitably donating their efforts to humanity. Romantic, I suppose, in a nerdy non-romantic sort of way.  It’s just not true. Go look up the commit histories on a major project. Google the primary contributors. You’ll find they are employed by companies large and small with a vested interest in the project. Even Microsoft funds open source development.

TL;DR: Managers, unless your application’s minimum system requirements preclude sub-$1000 laptops, you don’t need top tier developer talent. You wouldn’t even know what to do with it. Just hire normal dudes who seek simplicity and can ship working code.