Each week, I will give you an article to read for pleasure. Do not treat this as a test. Enjoy and learn some new vocabulary too. I am including articles I feel will help you in your IELTS reading. In this reading the article is written in an informal way but the language is full of idiom and useful vocab for talking about work.

Taken from: https://training.kalzumeus.com/newsletters/archive/do-not-end-the-week-with-nothing

Don’t End The Week With Nothing

Hiya guys!

Patrick (patio11) here. You’re getting this email from me because you asked for my occasional thoughts on making and selling software.

Usually I concentrate more on the needs of established software businesses, but recently I’ve been asked for some advice by people who are still in the trenches working at a traditional day job.

There’s absolutely nothing wrong with day jobs. Most people have them. They’re an honest living. Some people really enjoy the particular one that they have. If your day job is right for you, that is wonderful and I will not second-guess your decision.

Many people nurse dreams of entrepreneurship because their day job is not quite right for them. Here’s my story.

I used to be a salaryman at a Japanese megacorporation. The social expectation is that the company insulates the employee from all risk, and in turn, the employee swears themselves body and soul to the company.

I worked 70 to 90 hour weeks for three years. This isn’t particularly out of the ordinary for white collar employees in Japan. It didn’t strike me while I was a salaryman that I was going to continue doing it until retirement, largely because the amount of work was killing me, and I worked after those hours on my own projects.

Somebody asked me recently how I managed to stay motivated to work for the 91st through 95th hours every week. Answer: because I wanted to end the week with something.

Applied Capitalism For Fun And Profit

I’m a capitalist. A friend of mine is a devoted Marxist. I think we mutually agree that, considering any particular employee, it is in that employee’s personal interest to stop selling hours of labor and start renting access to his accumulated capital as soon as humanly possible.

I don’t mean just monetary capital — having $100,000 in your 401k is awesome but that’s not the type which is really interesting to me, simply because rates of return on that sort of capital are so low. There are many types of capital that are no less real just because you can’t conveniently reduce them to a number.

Human capital — the skills you’ve built up over time and the value you’re able to create as a result of them.

Social capital — the ability to call on someone who trusts you and have them do something in your interest, like e.g. recommend you to a job.

Reputational capital — the way your name rings out in rooms you aren’t even in, simply when your topic of expertise comes up. (Hopefully in a good way!)

A lot of day jobs structurally inhibit capital formation. If I were a Marxist I’d say “And this is an intended consequence of Capital’s desire to keep Labor subservient to it”, but I honestly think it’s true even without anybody needing to twirl their mustache.

There’s a great line from Jack Welch to the effect of “You work for a week, collect your paycheck on Friday, and then you and the company are even.” Corporate America has embraced it with a vengeance. I’m too young to remember an America where “company loyalty” wasn’t a punch line.

If company loyalty were a bankable proposition (and it might still be at some places — I know a smaller company or two where “we treat our employees like family” means exactly what it says on the tin), you’d get a wee bit of capital every week you worked. That’s one more week towards your boss’ good impression of you. One more week towards your pension. One more week towards that gold watch.

Japanese salarymen still have that sort of arrangement.

At some point at my ex-employer, I realized that I couldn’t possibly work at a salaryman job until retirement, because it was going to be the death of me. (I won’t belabor that period of my life because it was pretty rough, but suffice it to say if you pull 6 months of 90 hour weeks, towards the end of it the periodic blackouts start to get a little distressing.)

Once I came to the conclusion that I’d probably quit, and therefore discounted the till-your-death-do-us-part slow accumulation of firm-specific capital, I realized something which is fundamentally true of a lot of day jobs. Nothing I did at the job mattered, in the long run.

Sure, in the short run, I was writing XML files and Java classes which, knock on wood, successfully let my employers ship an examination management system to their client (a major university). I was a really effective Turing machine which accepted emails and tickets as input and delivered (occasionally) working code and Excel files as output. But no matter how much I spun, nothing about my situation ever changed. I worked my week, got to the end of it, and had nothing to show. The next week there would be more emails and more tickets, exactly like the week before. The week after that would be more of the same. And absolutely nothing about my life would change. I’d end the week with nothing.

Don’t end the week with nothing. Prefer to work on things you can show. Prefer to work where people can see you. Prefer to work on things you can own.

Prefer Working On Things You Can Show

One of the reasons developers have embraced OSS so much is because it gives you portable capital between companies: if your work is sitting on Github, even if you leave one job, you can take it with you to your next job. Previously this happened pretty widely but generally under the table. (Is there any programmer who does not have a snippets folder or their own private library for scratching that one particular itch?) One of the great wrinkles that OSS throws into this is that OSS is public by default, and that’s game changing.

Why? Because when your work is in public, you can show it to people. That’s often the best way to demonstrate that you’re capable of doing work like it.

Telling people you can do great work is easy: any idiot can do it, and many idiots do. Having people tell people you do great work is an improvement. It suffers because measuring individual productivity on a team effort is famously difficult, and people often have no particular reason to trust the representations of the people doing the endorsements.

(Quick: if you had credible evidence that a mid-level engineering manager at a company you’ve never heard of in Nagoya thought I was a really effective employee, would that make you markedly more likely to hire me? Right, without the context of knowing him, that recommendation is almost useless.)

Work you can show off, though, is prima facie evidence of your skills. After your portfolio includes it, your ability to sell your skills gets markedly better. Given that most people’s net worth is almost 100% invested in their personal capital (i.e. if you’re a young engineer the net present value of all future salary absolutely swamps everything in your bank account), this is a fairly radical improvement in your present situation for not a very radical change in how you go about things.

Thus my first piece of advice: if you have the choice between multiple jobs, all else being equal, pick the one where you are able to show what you’ve worked on. This could mean working on a language stack where work biproducts are customarily OSSed (e.g. Rails) versus one which isn’t (e.g. C#). This could mean working on particular projects within the organization which like external visibility (e.g. Android) rather than projects which don’t (e.g. AdWords plumbing — presumably Google will pay you a lot of money to do that, but consider it compensation for not being able to talk about it). This could mean working in industries which default to being open rather than those which default to being closed.

OSS isn’t nearly the only way to be able to show what you’ve worked on. In the creative industries, where the end product is customer-visible, people keep very close eye on whose name ends up in the credits. Academics spend lots of time worrying about citation counts and directed graphs.

More prosaically, establish an expectation early that you’re simply going to talk about what you’re doing. I think at Fog Creek / Stack Exchange they call this “producing artifacts” — conference presentations, blog posts, OSSed software, and the like, centered around the work. Even at very open companies there exists lots of secret sauce, but most of the valuable work of the company is not particularly sensitive, and much of it has widely generalizable lessons. Write about those lessons as you learn them. If at all possible, publish what you write. Even if it is published to an audience of no one, you will be able to point people back to it later.

Some of my most effective writing in terms of career growth was back in 2006 through 2008, when I was struggling through not understanding anything I was doing, and where I — quite literally — had less readers than my younger brother’s blog on writing superhero novels. Why was toiling in Internet-obscurity still valuable? Because I was able to point to particular experiments that I started in e.g. 2008, and then point to the followups in 2009 and 2010, which showed those experiments were really successful. The failures and false starts aren’t extremely interesting to most people, but having some successes under your belt credibly demonstrates that you’re capable of either reproducing them in the future or experimenting your way to new successes in your new environment.

If you cannot build things you can show at work, you should build things you can show outside of work. Companies in our industry are gradually becoming more reasonable about IP assignment clauses — there’s less of the “we own everything you think of at any point in your employment” nonsense these days. Even at my very straight-laced Japanese megacorp, they were willing to write an exception into the employment contract for a) OSS work that I did outside of company hours and b) Bingo Card Creator. I offered them this in exchange: “If you let me continue working on these, I’m going to learn lots of skills which I can put to the use of the company. Normally you invest lots of money sending engineers to conferences and professional training. This is even better for you: I’ll learn more with no operating expenditure and no decrease in billing efficiency.” That’s an offer you can make to substantially any employer.

I prefer being upfront with people rather than doing the “It is easier to ask for forgiveness than ask for permission” route a lot of folks suggest. Sure, you can just roll the dice and pretend your employer is unlikely to notice your side project. Unfortunately, the odds of them noticing your side project go up sharply if the side project is ever successful, and then your lack of forthrightness about it give you unbounded liability extending far into the future. Just ask. The worst they can say is “No.”

You might consider asking in the context of a more general compensation discussion than just “Hey boss, can I work on OSS?” That way, if they say “No side projects”, you’ll say “OK, in lieu of the side projects, I’ll need more money.” It’s easier to be sticklers for the stock agreements when there’s absolutely no cost to the company to insist on the usual boilerplate, but minor concessions on the boilerplate are often easier than concessions on things which actually appear on the company’s books.

Prefer To Work Where People Can See You

I used to phrase this as “work in public”, but when people think about folks who work in public, they think of rock stars and figure “Well, I’ll never be a rock star.”

Vanishingly few people in our industry have the profile of rock stars. They can still have substantial profile among the audience of “people professionally relevant to them.” That might be as tightly scoped as “people with hiring authority for front-end developers in my metro area”, which might be a set of, what, a couple of dozen folks?

How do you develop that profile? I’d suggest, all things being equal, working at places and on projects which have above-average visibility.

Many engineering projects are deep in the bowels of late-stage industrial capitalism. Then there’s writing the Facebook mobile app. I have no clue what engineers actually worked on the Facebook mobile app, but I’m betting that if I were a Silicon Valley hiring manager in iOS or Android development I’d a) know their names and b) have them at or near the top of my personal poach list.

Side note: A poach list is my informal name for “The people who, if I had infinite money and they had no other commitments, I’d hire to work on a particular project.” I have several mental poach lists — the best people I know on Rails programming, on A/B testing, on writing email, etc. When people ask me for advice on what to do about those topics, I often say “You know who is really great at this? <%= poach_list.pop() %> You cannot possibly waste your time taking them out to coffee.” Brokering coffee dates cannot possibly work out poorly for the people who go to them. (My interest? Helping people out is fun, and — funny enough — people often seem to remember when you get them a job or a key employee.)

You don’t have to optimize for “sexy” projects. You know, sexy projects: I don’t know how to describe them but I know it when I see it. Most engineering work isn’t intrinsically sexy. I would, however, optimize for impact and visibility.

Don’t try to make a career out of optimizing the SQL queries to display a preference page on a line of business app at a company that no one has ever heard of. That is not the straightforward path to having other people learn you are capable of doing meaningful work. Instead, work at higher profile companies/organizations — AmaGooFaceSoft, startups or small companies with anomalously high profile (locally, nationally, whatever), or in positions where by your nature you’re exposed to lots of people.

I have a few friends who are developer evangelists, which is a funny job created at API companies where your brief is basically “Go demo our product to a group of developers. Now, do that again, every day, for the next several years.” Sentiment on the actual job is decidedly mixed. Keith Casey gives a pretty good account here.

(Side note: I’d be remiss if I didn’t note that Keith just got his work shared with 10,000 people because Keith did the work and made it easily shareable, and also because Keith knew me, through his previous job at Twilio. I’m a customer there. Everyone can play six degrees to Kevin Bacon in our industry, but actually putting in the work makes it much more likely that other people will play six degrees on your behalf.)

Anyhow, developer evangelism. An observation: every developer evangelist I know goes into a much better job right after they quit being an evangelist. This is not true of other engineering jobs with checkered reputations, like e.g. The Build Guy. Why do developer evangelists get upgrades but The Build Guy(s) not? My bet is because evangelists literally spent years meeting thousands of people and showing them “Hey, I’m going to live code in front of you while also making my employers fat stacks of money. You run a company and could use both engineers and money. You should probably remember my name, you know, just in case.” The Build Guy(s) suffers in underappreciated solitude, except when maven bottoms out or RubyGems goes down and it is somehow The Build Guy’s fault.

If you cannot gain exposure at your day job, try to get some exposure outside of it. Network actively. Go to local meetups of technical folks, but also go to the (often separate) events where the business side of your industry talks shops. Speak at conferences. Take the things you have created (see above) and actively show them to people to solicit feedback. You don’t have to have an audience of thousands for an audience to be worthwhile — for landing a new job, having an audience of one hiring manager is a darn sight better than having no audience at all. Blog and collect an email list. It’s old and hackneyed advice but it freaking works, particularly when you can compound improvements over years.

Amy Hoy has a great metaphor for this — “stacking the bricks”. Seen from the outside, you might say “That person with an impressive career? It’s like they have a sheer wall made out of awesome. I could not hope to ever have a wall like that.” Seen from the inside, it looks like one day of delivering a single good conference talk, a few weeks spent writing an OSS library, another day writing the definitive blog post on getting multiple Ruby versions playing together, a few months shipping a product used by many people, an hour recording a podcast. Brick by brick, stone by stone, the wall gets higher.

Prefer To Work On Things You Can Keep

The employer/employee relationship is generally “You give us an hour and, in return, we give you some consideration for that hour.” As an employee, you very rarely get to keep hours, bank them against the future, or have them redound to your benefit years later.

I’m not generally a fan of the Silicon Valley model, but I’ll say this in their defense: widespread employee ownership of the enterprise is one of the single best innovations in the history of capitalism. Non-managerial employees own plus or minus 20% of Twitter, Facebook, etc. They own plus or minus “rounding error” of almost all other publicly traded companies, with very rare exceptions.

I think that’s an improvement on the “no shared stake” model of employment, but I don’t think it is the last word in it. For one thing, it overconcentrates employee wealth with one company. As an employee, your short-term cash flow generation is tied to the continued health of your employer. If a large portion of your net worth is tied to their stock, you’re magnifying the impact of a secular or firm-specific shock should one occur. (This is, relatedly, why I’m not a fan of buying the stock of an employer in a company-sponsored DRIP or IRA. You’ve got plenty of exposure to their future already without buying more of it with your own money.)

The explicit understanding among professional investors is that 90% of all shares of early-stage startups are worthless. It seems more than a little self-serving for professional investors to tell employees “While our general partners would laugh us out of the room if we suggested betting the entire fund on a single investment, even if we thought it was a sure thing, you are going the be the lucky ones and you should certainly have 99% of your net worth tied up in the illiquid shares of one particular company.”

So if not hard assets directly awarded by employers, then what?

Well, obviously, sock away money like every financial advisor ever will tell you to. (Here’s everything you need to know: buy broad market index funds in your tax-advantaged accounts. If that sounds too complicated, get a Vanguard target retirement fund where the number most closely matches the approximate time you’ll retire.)

There’s another, harder option with higher returns: the side project. You can “buy” them with sweat equity, one bead at a time. They provide you with many benefits, including the direct financial benefits (if you sell things to people for money, you get money, which can be useful), the compounded benefits of investing the financial benefits (my first $2,000 from Bingo Card Creator turned into Chipotle stock at an average price of $50 a share — don’t buy stocks, buy index funds, but that decision worked out pretty decently for me).

There’s also intangible — but no less real — benefits to having an artifact which is yours. This is one reason why, while I love OSS, I would suggest people not immediately throw their OSS on Github. That makes it very easy for developers to consume your code, but it does not make it easy for you to show the impact of that code to other people, particularly to non-technical stakeholders. To the extent that people’s lives are meaningfully improved by your code, the credit (and observable citations) often goes to Github rather than going to you. If you’re going to spend weeks or months of time writing meaningful OSS libraries, make a stand-alone web presence for them.

Example: my A/Bingo was once probably the best option for Rails A/B testing, by dint of being the only serious option for Rails A/B testing. It is a little old in the tooth now, but being The A/B Testing Guy got me several consulting gigs. The effort to make e.g. documentation, a quickstart guide, a logo, and a branded web presence beats the heck out of having a junior engineer at a potential client just git clone my Github URL and never have my work exposed to a decisionmaker there at all.

(Much love for Github, guys. Great company, great product, great impact on the industry. I only suggest not using them for a portion of one’s projects, for a fairly simple reason: I don’t work for them, I work for me. If I don’t work for myself, it is unlikely anyone else will.)

If you want to learn more about the actual mechanics of building a side project, my blog covers it in a lot of detail. For a much briefer overview of it, I really recommend Jason Cohen’s presentation at Microconf 2013. His formula is “Predictable acquisition of recurring revenue with an annual pre-pay option with a product which solves a demonstrable, enduring pain point for a business.” That idea is developed at the above link for an hour, and a lot of the advice given is specific and wildly actionable. I highly recommend it.

Consumption Is Sometimes Valuable, But Creation Moves You Forward

I’ll close with my usual advice to peers: reading this email was valuable (knock on wood). Watching Jason’s video is valuable. Rolling up your sleeves and actually shipping something is much, much more valuable. If you take no other advice from me ever, ship something. You’ll learn more shipping a failure than you’ll learn from reading about a thousand successes. And you stand an excellent chance of shipping a success — people greatly overestimate how difficult this is.

Just don’t end the week with nothing.

If there’s ever anything I can do to help you out, whether you’re the CEO of a multi-million dollar a year SaaS company or just getting ready to stack your first brick, drop me a line. Nothing makes me happier businesswise than being able to help people, particularly those who are getting started.

Until next time.

Regards,

Patrick McKenzie

P.S. Next time I plan to go back to my usual beat of “tactical suggestions for optimizing SaaS businesses.”

Reading for fun