Types of companies that use software

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

Pluses:

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.

Minuses:

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.

Product companies

Pluses:

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.

Minuses:

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!

Consulting

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).

Minuses:

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.

The rest

Pluses:

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.

Minuses

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!

Sincerely,

Dan

Speaking isn’t as scary as you think, eventually

Dear new developer,

I remember one of the first times I spoke in public. I was talking about J2ME (which was a technology for building mobile apps, pre iphone) to the Boulder Java Users Group. I threw up some slides showing the flow of data across the system, and made a joke along the lines of “sorry if this is confusing, but at least it isn’t UML”. The audience all laughed, and I went on with my talk.

Guess who the next speaker was?

Grady Booch, inventor of UML.

Doh.

Public speaking is a great way to do a number of things for you as a developer.

Raise your profile in your company and in the community. Standing in front of a crowd and talking about a topic will get you noticed. Even if it is a crowd of 10 at your local meetup.
Teach you how to educate people. The way to help someone understand something is not intuitive. Speaking gives you a chance to practice it, and that will help you in your work life, since a large part of development depends on helping other people understand what you mean.
Force you to really understand your topic. Trust me, the pressure of being up in front of a group of people will cause you to dive deeper than you otherwise would have. (Kinda like writing an ebook.)
Let you learn something new. Related to the above point, you can learn something new when you are presenting. This can either be ancillary to the topic you are talking about, or, in some cases, can be the topic of your talk.

Some tips for getting started:

Find something you are interested in. Brainstorm ideas around that. Think about cross sections: “Using javascript in marketing” or “what do SQL and devops have in common”. Both technical skills like javascript, SQL or design and “soft” skills like interviewing and communication can be good topics.
Join a meetup. Go a few times as a regular member, learn who the organizers are. Then go to the organizer and say “I’m a new developer, but I’d love to speak sometime. Do you have any slots open?” (You can also join Toastmasters.)
When you get a chance to talk, practice it multiple times, at least once in front of someone. Remember that you are likely the most expert person in the room. If possible, start off with a joke or self deprecating remark, and ask for audience participation. More tips.
Look for local conferences. Then, look for Calls for Proposals (“CFPs”) at such conferences. Submit. Don’t spend too much time polishing a submission. Submit any proposal to multiple conferences. Papercall is good for that. (I confess, I’m not an expert at this process, so this is more based on advice I’ve read.)
When you go to conferences or meetups, walk up to speakers and ask how they got started. I’d suggest avoiding the superstars. Regular speakers will still have useful advice, but fewer folks surrounding them.

By the way, it is terrifying, but many things are the first time you do it. I mean, do you remember learning to ride a bike?

Public speaking is a great way to stretch yourself, learn new skills and meet new people. Highly recommended.

Sincerely,

Dan

Benefits of blogging

Dear new developer,

I’ve written before about my belief in blogging as a way to sharpen your thoughts and give examples of your expertise. Here’s a post along the same lines. From the post:

People always try to find someone they can trust. You can go through a series of interviews and hope that they will figure out you are a great colleague, or you can write about your approaches and let a wider audience know that.
If you have a deep expertise in some technology, you can demonstrate it by writing deep and thoughtful blog posts.
If this technology is in demand, you will definitely get some opportunities coming your way!

And

Your views expressed publicly can be a good conversation starter.

This may come handy in any professional social context: interviews, meetups, conferences. It’s a different level on conversation when you get approached because someone likes your views.

The author then goes on to talk about specific, measurable ways that his blogging has helped his career.

The whole post, “Is blogging useful?”, is worth a read.

Sincerely,

Dan

Write a brag document

Dear new developer,

You will encounter good managers and bad managers in your career. I’ve found that one common thread for all managers is that they are busy. Busy with meetings, busy with coordination with other teams or parts of the business, busy putting out fires, busy with helping team members. Busy busy busy.

They also will likely be responsible for your career. Promotions, compensation increases, title changes. A good manager will want you to be challenged and grow and learn.

However.

The only person who really cares about your career is you.

You can help your manager help you by helping them know what you do. Sometimes this feels like an undue burden. Surely your manager can keep track of what you’ve accomplished on their team. And some do know some of the stuff you’ve done, some time.

But what you want is to help them know everything that you’ve done that you’re proud of. This helps them understand what a great team member you are, and also gives them ammunition to fight for resources (money, projects) that you deserve.

One place to put this information is in your LinkedIn profile (more about my opinion on LinkedIn). Of course, make sure you don’t reveal any company secrets (projects, launches, technologies) in this.

Another alternative is an internal brag document. Julia Evans has written a great post on writing one. This outlines one way you can help your manager (and yourself) keep track of all the great work you’ve done. It can be far more detailed since it is internal and not limited in length.

It’s not just limited to project accomplishments. You can build a bigger story. From the post:

In addition to just listing accomplishments, in your brag document you can write the narrative explaining the big picture of your work. Have you been really focused on security? On building your product skills & having really good relationships with your users? On building a strong culture of code review on the team?

I haven’t written one of these (although you could consider my blog somewhat of a brag document, I suppose. Yet another reason to start a blog). But having some kind of record of your accomplishments that you can share with your manager will help them help you.

Sincerely,

Dan

Someday, You Won’t Want To Code For A Living

Dear new developer,

I remember the first full time coding job I had. I was able to work on a great team, on interesting problems. I was able to get into the “flow” that is such a magical state. I was paid well. I had free snacks.

I remember going into my manager’s office and chatting with him. He seemed a bit stressed. He was constantly interrupted. He had lots of meetings. He seemed to want to code, but didn’t have time for it.

Me being the naive young optimist, I asked him once why he wasn’t coding. Why would he leave a really fun job for management?

He looked at me with a knowing smile and said something like “one day, you’ll understand”.

I don’t code for a living now. Oh, sure, I write some code. And it still gets me into flow. And I still enjoy it.

But the honest truth is that when I am coding, I have the leverage of one person. As I grow older, I grow more impatient to effect change in the world. The best way to effect change is to have more leverage. Some options for higher leverage:

writing
project management
product management
speaking
mentoring
leading a team
managing
teaching
architecting
consulting

Most of these involve communicating about coding (or other technical systems), but coding is not the primary work output. Instead, the emphasis is on knowledge or alignment of a team.

Now there are also code specific ways to get more leverage. Two that I can think of.

work on really big systems that have a lot of users (FAANG companies, or something similar).
work on open source libraries or projects that have a lot of users

If either of those floats your boat, then pursue that. I don’t like the first because I don’t really enjoy the bureaucracy and politics of big companies. I am not a fan of the second because I don’t really enjoy working for free.

By the way, no one says you have to have leverage. I’ve just seen that happen again and again across many companies and many individuals. Part of that might be the crowd I run with, but part of it might be that more leverage typically means more pay.

Your career is long. My guess is that one day you won’t want to code for a living. Enjoy it now, but keep your head up and think about what other areas, focusing on communication or team alignment, might eventually be of interest to you. Learn about those areas. Meet people who are currently doing them, and ask questions.

Sincerely,

Dan

Think deeply about engineering management

Dear new developer,

This post from Charity about the choices you face as an engineer, and the challenges of technical management, is wonderful. As a new developer, you’re probably a few years away from thinking about that (but perhaps not. If you join a startup rocketship, it’s possible you’ll be managing people in months). But you have to manage your own career, and moving into management is one of the main career paths for a developer. (I’d say the others include: starting a business, becoming a senior developer, or becoming a consultant.)

Charity talks about how management is an entirely new skillset, and how being a technical leader plus a manager is a great way to get amazing things done. She also covers the negatives of “climbing the ladder” to ever more senior leadership. Charity doesn’t mince words:

Your job [as a newly minted technical manager] is to leverage that technical expertise to grow your engineers into great senior engineers and tech leads themselves. Your job is not to hog the glory and squat on the hard problems yourself, it’s to empower and challenge and guide your team. Don’t suck up all the oxygen: you’ll stunt the growth of your team.

…

I mean, there’s a reason we don’t lure good people managers away from Starbucks to run engineering teams. It’s the intersection and juxtaposition of skill sets that gives engineering managers such outsize impact.

…

One warning: Your company may be great, but it doesn’t exist for your benefit. You and only you can decide what your needs are and advocate for them. Remember that next time your boss tries to guilt you into staying on as manager because you’re so badly needed, when you can feel your skills getting rusty and your effectiveness dwindling. You owe it to yourself to figure out what makes you happy and build a portfolio of experiences that liberate you to do what you love. Don’t sacrifice your happiness at the altar of any company. There are always other companies.

I don’t tell you this now, new developer, because I want to scare you away from management. I’m an engineering manager right now and it’s a wonderful place to be. You have autonomy, you can help fix problems you see in your organization, and you get to recruit and help grow people into the best developers that they can be. But just be aware that when you get to a certain level, it’s a one way path away from some of the most fun parts of software development–building things, solving hard technical problems, and being a doer.

Please read the whole post from Charity: Engineering Management: The Pendulum Or The Ladder

Sincerely,

Dan

The Cacophony of the 2019 Tech Landscape

This is a guest post from Rishi Malik. Enjoy.

Hello New Developer!

Right now, it’s Q1 2019. And there’s a lot of advice you’ll find out here on the internet. Much of it is good, some of it is bad, but the important thing to note is that these are all points of view from people. From that person to be specific. This letter is no different, this is just my view on what matters. Take it or leave it. In fact, that’s the first point I want to make.

2019 tech is full of voices. Social media, popular blogs, and news sites amplify voices and feelings. This is an awesome thing, but remember that loud views aren’t necessarily right.

What I mean, is that you’ll find points of view on everything. Developers have always loved flame wars, and pointless battles (vi vs emacs, tabs vs spaces). Now it’s “Javascript developers aren’t real engineers”, or “If you can’t code a binary search, you’re a bad engineer.”

Find yourself in all these voices. It’s not easy, and it will take time. But work on what you value, and develop your skills to who you want to be. It’s ok if you want to work by yourself on speeding up a search by .01 milliseconds. It’s equally ok if you want to ship a single page app with a brilliant user experience. Listen to the voices when they help, and ignore them when they don’t.

To help find yourself, focus on finding customers that value what you do. Most of the time, these customers are the people in the company you’re working for. But if you want to do algorithms, find people who will value that work. If you want to work on networks, find companies who need that.

It sounds obvious, but it’s an easy thing to miss when you’re looking for a job, and when you’re evaluating comp, culture, benefits, and offices. It’s also really hard to gauge from the outside of a company.

On that note, remember that the 2019 tech industry isn’t how it will always be. Right now, the job market is stellar. I mean really stellar. In most big cities, you can find a job doing just about anything you want, most of the time within a few days.

This won’t always be the case. It wasn’t years ago, and everything comes in cycles. That’s the 2nd point. Be willing to do things you didn’t think you wanted to. I worked on embedded systems when I started my career. I got into web technology not because I cared about it, but because it helped me get a job in a city I wanted to live. Turned out to a prescient choice, and opened up tons of opportunities I wouldn’t have had otherwise.

The tech choices come in cycles, but so does demand. I said before that the job market is stellar. But some of us old timers have been through the downturns. When you’re unemployed for 6 months because literally no one is hiring. When your choice is between a 50% pay cut, or a 100% pay cut. Be wise, be smart. It’s a great time to be in tech, but plan ahead for the times that are tough.

Finally, my last point is to remember that there is a world outside of tech. It’s hard when you’re in it to see that. When tech was smaller, and more insular, it was easier to remember that this is a job.

But now, tech is everywhere. Apps are everywhere. The internet is everywhere. More people are writing code, building companies, and figuring things out. But, tech is not the entirety of life. Get outside of the tech zone, and connect with people who aren’t in it. It will change how you think, and how you develop code. And it provides a much needed break from the echo chamber that is tech.

Good luck, and have fun!

Rishi

Rishi Malik is the founder of Backstop.it, a company focused on making cybersecurity easy for companies to implement.