Dear new developer,
I remember reading this article a few years ago and being struck by the wisdom contained therein. Code and development is crucial to building many businesses, but as developers we often get wrapped up in the code to the exclusion of other things.
I have definitely discounted the value of other aspects of a business (marketing, sales, accounting) in the past. That is a mistake, as there are many many things that need to happen to deliver value to a customer.
Doing a schlep is a great way to inexpensively deliver value to customers. It doesn’t scale, but it is far quicker to change a manual process than to change code.
From the essay:
No, you can’t start a startup by just writing code. I remember going through this realization myself. There was a point in 1995 when I was still trying to convince myself I could start a company by just writing code. But I soon learned from experience that schleps are not merely inevitable, but pretty much what business consists of. A company is defined by the schleps it will undertake. And schleps should be dealt with the same way you’d deal with a cold swimming pool: just jump in. Which is not to say you should seek out unpleasant work per se, but that you should never shrink from it if it’s on the path to something great.
The whole post, titled Schlep Blindness, is worth a read.
Dear new developer,
It’s paradoxical, but sometimes the best thing you can do is not write code. Remember, the value you provide is to solve the problem you are faced with (the outcome), not to write code. Custom code has value, but comes with costs. It needs to be deployed, maintained and upgraded. It has bugs. It requires a developer to change. It also has opportunity cost. Writing custom code to accomplish task A means that you won’t have time to accomplish task B, which may be either more urgent, more important or both.
There are a couple of ways in which you might solve a business problem with out writing a lick of code.
- Use a library or framework. For instance, I worked at a place where they had written their own database connection pool. Why? I never got a great answer, but it wasn’t clear to me that one of the open source solutions wouldn’t have worked. You need to have an awareness of such libraries to be able to propose this.
- Use a third party SaaS tool. I’ve seen people run their own in house git repositories. There may be good reasons to do this (including security or privacy concerns). But Github is going to give you a far better experience and unless you have a big team, probably better security and privacy. You need to know what the problem, the solution and the cost are to make an effective suggestion.
- De prioritize the work. I was at a meeting with a CEO and we were talking about continuing an effort to integrate a set of outside data sources. I asked why, and we discussed it a bit further. It became clear that the reason we were thinking about doing it was because of inertia. It became clear that there was no real business reason to do it, and we prioritized other work instead. A clear roadmap and the willingness to question requirements are helpful with this path.
- Do it manually. I was working on a startup and we had the need to occasionally refund customers. I could have integrated with the payment provider and had this case be handled automatically, but it was much much easier to document the process and handle it manually. Refunds happened rarely enough that there was no value in automating them. Here it is helpful to know how often the problem arises, how long it takes to fix manually, and how often it will arise in the foreseeable future.
Now, sometimes you may not understand the larger context of your work. You may propose a solution that isn’t the right fit, and there’s certainly nothing wrong with writing custom code to solve a problem.
In cases where I’m not sure I have full understanding, I always preface my questions with “I am not sure I have the full picture, but I think we could solve the business problem using solution A or project B, rather than writing custom code.” If you are working directly with the client, they likely won’t care, as long as the problem is solved. If you are on a team, the engineer or project manager running your project should have a good understanding of alternatives and why custom code might be the right solution. Most folks will be happy to share that reasoning with you.
In short, it’s better to keep your eyes on solving the business problem and be aware that custom code isn’t always the right answer.
PS No, this isn’t an April Fools Day post 🙂
Dear new developer,
Justin Kan has deep experience in the startup space, including at an accelerator called Y Combinator. He gave a talk about why you should work for a startup, and why you shouldn’t. Here’s the transcript,, and here’s a blog post based on it. If you’re looking for good management, avoid startups:
The management at startups generally sucks. I wish I was joking, but sadly it is very true.
On the flip side of that:
At a startup, you will get access to jobs that you are completely unqualified for and you might not be able to do well (yet).
(Possibly the two are related!) There’s a lot more good advice in there, well worth the read.
As a new developer, you may have a risk profile that allows you to work at a small startup. If you can swing it, you’ll never have an opportunity to learn more about how to build a business. The first few years of your career are precious and should be spent carefully. The more experienced I get, the less risk I want to take (all other things being equal), and I’ve seen that be the case for most of my colleagues.
How can you choose the right place? I’m no expert there, as I’ve fallen into several great jobs. But I’d recommend:
- working at a place with no jerks
- optimizing for learning
That’s about it. Yes, make sure you are paid market rate. Yes, make sure you are being challenged. Yes, don’t get taken advantage of. But for the first few years of your career you have the opportunity to take positions at pay levels and in areas that may be closed off later in your career.
Dear new developer,
Your code is written to further some end. It could be for academia, government, or, more likely, for business purposes. In all the cases, having a greater understanding of these overarching purposes will allow you to make smarter decisions and write better systems. However, just like in software development, business uses a lot of jargon.
It’s worth spending some time decoding that jargon. You may not understand every part of it (just like you probably don’t understand every piece of the system you are working on) but even a little can help. It can help you sift through possible solutions and connect with non technical staff.
For a very high level overview of how business and financial decisions are made, I can’t recommend the MBA Mondays series enough. From one of them:
If cash flow is positive for all periods, then you are done with cash. If it is negative, do one more thing. Divide your cash balance by the average monthly burn rate and figure out how many months of cash you have left. If you are burning cash, you need to know this number by heart as well. It is the length of your runway. For all you entrepreneurs out there, the three cash related numbers you need to be on top of are current cash balance, cash burn rate, and months of runway.
You can definitely find other sources for this information (I enjoyed The Personal MBA as well). These general purpose business books will give you a handle to have discussions with other people in the business. Have those discussions–at gatherings, in the hallway, at lunch. Take these opportunities to ask questions–people love to talk about themselves.
You don’t need to be an expert in the business your employer is in, but being even slightly familiar with it will give you a better understanding of how your technical decisions affect expenses and revenues.
Dear new developer,
Businesses will spend money to make money (or save money, which is essentially the same thing). This is what they are doing when they are hiring you, when they buy that shiny new office building, when they spend money on computers and other tools to help you do your job, and even when they pay severance. While you may not be in the position to spend money yourself, understanding that businesses will do so can clarify your understanding of what you are working on.
Making money is not the only reason businesses spend money. Sometimes they spend just because the CEO or other leadership want to, or for image reasons, or because of inertia. But in the long run, spending money for other reasons is bad for business.
Spending money to make money is rarely a sure thing. If the return was certain, then other businesses would notice and step in and spend money down (this is assuming a relatively free market–regulations are a whole different ball of wax). So taking bets with money is a key part of running a business.
What does this mean to you, new developer?
When you evaluate a project, think about the economics of it. How is it going to make money? What assumptions are there? Don’t assume you know all the answers to these questions.
Asking the people behind the project why they think this project is going to make the company money will help you understand why the project exists (it’s no fun to work on a pointless project), help you improve the project (perhaps there is a more economical way to achieve the goal) and increase your value to the company (someone who can execute the details while understanding the big picture is more valuable than someone who can only do one of those).