This is a guest post from Perry Tiu. Enjoy.
Dear New Developer,
Ask for great hardware.
Ask for that latest MacBook. Ask for that extra built-in 2TB of flash storage. Ask for that 32-inch monitor. Ask for that additional vertical monitor. Ask for that standing desk. Ask for that Aeron chair. Ask for that expensive USB-C hub. Ask for that ergonomic keyboard.
Now you may be thinking that you don’t want to be perceived as a burden to the company, or that you’re coming off as greedy and needy. I get it. If you had to purchase all of this yourself, it would surely be an unpleasant hole in your pocket. We all get it.
Fortunately in the bigger picture, this amount is actually minimal for companies compared to all the other costs related to hiring a new developer (salary, staff hours spent on interviewing individuals, etc). Most well-run companies regularly take into account these costs as they grow and there are many reasons why they are willing to invest in their staff’s developer experience.
One of the more obvious reasons is improving efficiency and productivity: having a laptop with an additional monitor setup is generally better than without. Interestingly, there are also indirect, not exactly tech-related, benefits. For example, being able to satisfy a developer’s needs improves work satisfaction, which contributes to employee retention. As long as you justify using the amazing hardware at your disposal, the return of investment in the long run far outweighs the cost of the hardware.
So ask away, treat yourself and embrace what modern technology has to offer. Your company should be there to help you grow in your role so don’t be shy. But more importantly: share your experience. Let people know what works for you, what doesn’t. Countless times have I learned new quality-of-life improvements just from hearing or seeing someone else live it. Not only will your peers and friends appreciate the discussion, it is also a collective push to improve each other’s developer experience.
Oh and it is harder to ask for upgrades down the road than when you just joined.
Sincerely written on an outdated machine,
Perry is a Software Engineer and host of a podcast ruined by a software engineer.
This is a guest post from Christie Brandao. Enjoy.
Dear new developer,
It’s easy to get wrapped up in only focusing on the deeply technical aspects of your job, especially if many parts of the stack have technologies you haven’t worked with yet. As your career progresses over time, you will be improving the quality and readability of the code you write as well as your problem-solving skills. This takes deliberate practice, but you’re already used to this! At the beginning, it’s natural for all your energy to go towards getting up to speed with the codebase and learning how everything works together. My advice is to take some time to also understand the use case.
At the core of it, your job is to be building something that will provide a positive business impact through your development skills. Ignore the urge to dive right in and start coding and instead, take some time to learn the bigger picture. Focus your energy on gathering as much information as you can to start building your foundational knowledge of this area of the product. You can start small! When asked to build upon a feature, for example, don’t just take the ticket at face value. Ask questions (to yourself or others) about how the current feature is currently working. What are the difficulties people are having using this feature? How is this going to be an improvement to the current process? Once you have a good grasp on the ticket level, it’s time to learn about the bigger forces that impact larger business decisions. You never know, maybe your fresh perspective will offer valuable insight that no one else has brought to the table.
Christie Brandao is based in Columbus, Ohio. She is a Full Stack Serverless Web Developer for Branch, a tech-forward insurance startup focused on giving instant prices for home and auto with just a couple questions.
Dear new developer,
In my experience, four types of companies use software. Software is as prevalent as accounting, so every company uses it in some way.
- Those that sell software to help build software, software product companies. Examples from my career: Oracle.
- Those that sell software, often called product companies. Examples from my career: The Food Corridor, Katasi.
- Those that sell hours or knowledge of developers and other software professionals (PMs, designers, etc). Examples from my career: XOR, Culture Foundry.
- Those that sell anything else and use software to help. Basically almost every other business. Examples from my career: 8z, Phoenix Enterprises.
As a new software developer consider where to seek employment, they each have strengths and weaknesses. It’s worth talking about these so you can find a company that aligns with where you want to go (remember, every place has its warts).
Software product companies
- You are the end user, so having user empathy is easy.
- Software developers are highly valued within the organization.
- Lots of focus on building out higher leverage software processes.
- When successful, these companies have great gross margins and can afford good pay and benefits.
- Developers often start companies like this, so there’s a lot of competition.
- Jobs are desirable, so may have a long interview process with a lot of hoops.
- You can go deep into a particular business domain.
- Software developers are key components of such a company’s success, and are treated like it.
- They often have recurring revenue and a business model that allows for good pay and benefits.
- Can be harder to get hired than in other types of companies because jobs are more desirable.
- May be boring to be in same domain for long periods of time.
- May use older technology depending on the age of the company. Legacy systems make money!
- You often skim domains, so you can get some variety of experience in different types of businesses.
- Always new projects to be on, often means new technology to evaluate and learn.
- An hour worked is often an hour billed, so your efforts are directly related to revenue.
- If you are looking to go off on your own, these consulting businesses are easy to start (no overhead, no investment in building a product, you just need a laptop and an internet connection and someone willing to hire you).
- As an employee, you need to realize that there is no real exit strategy for the founder(s). Which is fine as long as the founder is still interested in running the business.
- There is limited recurring revenue, which means that the business goes through cycles of grow -> shrink -> grow -> shrink.
- Lots of lots of effort in finding new projects and clients.
- Because of the sales cycle, it is hard to specialize as a consulting company, sometimes you take projects because you have to pay bills.
- Can have tight deadlines and lower profitability, which affects your experience as a developer.
- Often have stable businesses.
- Software quality and process tends to lower in non software focused companies, making it easier to outperform competition.
- Software quality could be competitive advantage.
- You’ll have the chance to learn about and work in a non software business domain.
- Developers won’t be as highly valued at some other types of companies.
- IT/software can be seen as an expense rather than a revenue generator, especially if not affiliated with revenue side of the business.
- Sometimes you may be alone or in the company of expert beginners.
Each of these types of companies has different strengths and can be a good fit for you early in your career. Consider what excites you and what is available in your job market when you make the choice. It’s also worth reminding yourself that since as a new developer you’re judged on potential, any choice you make to go into one type of company or another isn’t permanent!
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).