I meet a lot of people who want to start a career as a web developer with no idea of what the trade-offs are of working at different sorts of jobs. This article aims to give you a rough idea of the sort of environments you could end up working in as a developer.
The software lifecycle
The timeline of software projects tends to follow a common sequence. How you contribute to a project will be different depending on what stage in that sequence the project is in.
- Project kick-off. A brand new project. At this stage technical decisions are fluid and there's usually no revenue depending on the project, so the requirements can change very quickly.
- Ongoing development. A project where developers are regularly changing the behaviour or adding features to the software.
- Maintenence. A project where the majority of the work is fixing bugs, applying patches or otherwise keeping the software running in a stable and consistent manner.
There are no discrete lines between any of these stages, and most projects end up in a state of ongoing development and maintenance at the same time. The type of job you get will dictate where in this sequence your projects will be.
Challenges at work
Your job as a developer is to solve problems. The type of problems your job presents to you will depend on the type of company you work for. Here's a rough categorisation:
- Configuration. If you're installing Wordpress, setting up Shopify or otherwise using someone elses code the majority of the time, then you're configuring software rather than actually building it. This can be extremely valuable for the right business, but won't necessarily stretch you as a developer.
- CRUD. Stands for Create, Read, Update, Delete. The vast majority of custom web software you write is going to be a glorified CRUD application under the covers. This is the bread and butter of web application software.
- CRUD and Plumbing Apart from the simplest cases, your CRUD applications are going to need to interface with the outside world in a myriad of weird and interesting ways. That's anything from sending emails to interfacing with third party APIs to breaking your infrastructure out into internal services.
- Research Most of us don't do any original research in our work as web developers, but some companies (Google, Facebook, Amazon etc) do in fact come up with novel technologies and publish their findings.
Type 1: The "Digital Agency"
The role: A developer at a marketing company that provides website design and development. The company might focus specifically on websites rather than provide a more comprehensive marketing package to clients.
Many of this generation of web developers got their first jobs in the industry at companies like these.
In this sort of role, you'll likely be working on new builds though the work probably won't be more challenging than configuring existing frameworks/software and some basic CRUD functionality.
Companies that focus only on content managed websites don't typically have difficult technical requirements, so the knowledge and skill level on their teams isn't very advanced. This means that after a few years at a job like this you're likely not going to have much scope for improving your skills. The salaries at these companies for technical roles aren't much to write home about either.
If you are in fact a beginner programmer, working at any job that has you building web sites full-time will probably be good for you. Repetition is an important part of building any skill, and having to work on or with code on a daily basis shipping site after site will make you better at it.
It won't however present many interesting challenges to you after the eighth or ninth time and you risk stagnating if you stick around too long. If you're interested in applying good practices to software development, you'll probably be frustrated before long: many agencies still haven't heard of backups or version control.
Type 2: The Regular Business
The role: A developer at a profitable company that does something that happens to require computers. The company requires an in-house development team to carry out it's business functions.
In a role like this, you're working on the ongoing development and maintenance of at least one existing software project. This teaches you a number of things that working on successive new builds doesn't:
- The long-term effect of decisions you make when you write code.
- How building software is different on a large team.
- Refactoring and safely changing the behaviour of complex legacy code.
These are skills that make you a better developer no matter what your job is.
Unless the product of your company is the software itself, the work you do here will probably not be much more complicated than CRUD and plumbing. The older software gets, the more things it does, so the added challenge here is going to be managing all that code in a way that keeps it functional, performant, easy to understand and quick to fix.
Established, in-house teams have a good mix of junior, mid-weight and senior technical staff so can be a good environment for developing your skills earlier in your career. The financial compensation is at least at market rate for software developers, but can vary a lot from company to company.
You'll likely have to deal with specific technical challenges that you won't find anywhere else. You won't get much scope for playing with new technologies on an established team. You'll instead be expected to dive deep on the technology stack in play at work.
Many developers also don't like having to work with and maintain legacy code. However, diving into large, hairy codebases and coming out with a strong understanding of how they work is an extremely valuable skill to develop.
Type 3: The Software Development Consultancy
The role: A developer at a consultancy that provides software development services. You're charged out at a daily or weekly rate to clients who want a software project built.
This role usually has you working on new builds for a large variety of clients. Except for where the consultancy has a niche it specialises in, the work here is usually just CRUD and plumbing.
Good consultancies are usually top-heavy in terms of skillset: they tend to prefer hiring senior developers over training junior developers from scratch. This means that consultancies can be excellent places to learn from other developers but may be difficult to get into in the first place.
The developer salaries at consultancies tend to be on par with those of senior in-house developers, though don't approach the ones on offer for in-house technical leadership roles (architects, CTO's etc).
Since you're working on one new build after another, you get a lot of scope for experimenting with new technologies and practices. On the other hand, you don't always see the long-term effects of your technical decisions, so it can be difficult to guage their success.
What does this mean for you?
When you first start looking for a job as a developer, you're not fussy about the type of work you can get. You're happy as long as they're willing to hire you to build things on the web.
But the type of work you do has long-term effects on the trajectory of your career. What do you want to be doing five or ten years from now? Will you be able to develop the skills for that at your current job?
The job types I've outlined here are in no way exhaustive and you'll likely be able to name plenty of example companies that don't fit the profiles I've described. They're a rough analog of many companies I've come into contact with in my time in the industry, and the descriptions are just to get you thinking about what you want in a job.