Everyone wants to work for a sexy, up and coming startup .... apparently! I've even seen people say that if your first job in tech isn't at a start up or on a new team at one of the big tech companies then your tech career is basically a bust before you got out of the gate.
Setting aside the ridiculousness of that statement I want to look at the difference between working on greenfield projects and older, more established IT estates at companies for whom tech probably isn't their primary focus. Is one better than the other?
Start up / greenfield work
Nearly everyone loves the first page of a new notebook, that sense of opportunity of what this book could be, the person you will become once you write your thoughts and ideas in it - there is something exciting about it. We all know after page 3 it will be full of scribbled notes from calls and reminders for tasks you need to do, but still, we hover the pen over the page just that bit longer on page one, like we're stepping out in to the first fresh snowfall of the year not wanting to ruin it.
Starting a new codebase is similar, all those ideas and possibilities. Knowing that this time you will "do it the right way" is alluring, not having decades of technical debt to slow you down is freeing.
You will get to know more of the code, you have a hand in crafting many of the main areas, and so further changes and refinements are fast because you already know the code and the patterns employed. You don't need to reference documentation all the time or go spelunking through layers of function calls because you already know the final DynamoDB document that the data you need ends up in.
Working on a greenfield project can make you feel like a coding god. You know what to do and where to do it. You deliver features quickly and you're on top of your tech debt. It's nice but short lived because all greenfield projects grow old, become complex and no one knows how it all works, not really any way.
Brownfield
Working on old IT estates is tedious, hard and boring. Nothing new happens and it's all just maintenance!
This misconception is what startups and agencies want you to believe because it's their best narrative to persuade you to come and work for them. At some companies it might be true, but that's not an issue inherent with older codebases but instead organisations that are set up in such a way that this is how they view their IT systems. Funnily enough a boring company that isn't really innovating will probably have boring IT projects that will feel like the above.
Companies that recognise the value in their IT department and are actively adding features and modernising their IT estate on the other hand, offer something equally fun and, I think, more challenging than greenfield projects.
- They teach you the ability to decipher how a system works without relying on knowledge you accrued from making it yourself. You become a better problem solver.
- You are forced to become comfortable woking on a system you only partially understand.
- You learn the value of tests, not because you are forced to write them but because you will loath previous developers who didn't write any for the code you now have to change.
- You will be given the chance to modernise an old system using best practices and compare new approaches to the "old ways" and see not only the benefits but also the downsides.
Greenfield vs Brownfield
There is no right or wrong answer to which is better but I will say that I have seen developers come to existing IT projects, having only previously worked on greenfield projects, and flail for 6 months getting frustrated and annoyed at how slow everything feels because their expectations have been set unrealistically high from their experience to date. Most of the work with existing code bases is working out exactly what you have to change and where, rather than the change itself.
People who start their careers on old systems, adding features, fixing old bugs and generally ushering this creaky beast into more modern times don't have this painful learning curve, and when they come to a greenfield project they are delighted and appreciative of this window of time where they can move fast and break things.
Latest comments (16)
Strong agree with a bunch of what you're saying here. Especially for those who really want to up their game, or even enter other spaces in tech (such as technical leadership, architecture, or AppSec), learning to read existing code and understand it quickly is a game-changer.
A well-rounded engineer really needs to be able to both write and read code, finding issues and understanding systems. Regardless of your career goals, those who get the best opportunity and pay can work both green-field and brown-field.
legacy code = new code + time
A fun exercise is to find an open source repository, and just read it. Review the code, understand the system from the code, not from having someone tell you what's going on. Then, once you think you have a good idea of what's happening, reach out to the maintainer and validate your findings. Maybe close an issue or two while you're at it.
thanks, yes i think that's a good idea to gain an idea of how "legacy" code develops and how to start to understand how a system works from just the code. It can be daunting the first time you do it. Fortunately at a company there are people who can support and help but sometimes you have to work on a system that no one knows anything about.
To me, startup means probably not getting paid and working on a product 80% likely to fold 🤔.
Quite possibly, the good ones are like a rocket ship though, everyone hanging on for dear life, writing bad code and making poor choices in the mean time!
The funny thing is that working on a start-up doesn't necessarily mean that you'll be working on a Greenfield. You can land on a start-up after 3/4 years of it's creation and the base software is already done, you can end up in a maintenance hole as well.
Apart from that, those Greenfield projects need seniors, and startups usually pick seniors mostly from brownfields. I don't think this fact does not need further explanation but here we go anyway:
The hability to keep in mind all the little pieces, details and concerns for a given product that should be in production for millions of customers to use is something that you learn on surface when studying, then the reality punches you in your face many times till you learn how to make a proper decision making, prioritize, get a clear sight of what resources you have, the availability and dependancy of this resources and a global vision of what this needs to be.
Ideally you need managers, tech leads, consultants, senior devs and so on to fullfil this needs and that's the reason we're bombarded with requests on LinkedIn. Juniors are mostly to get cheaper workers to apply the easier parts of what those other senior roles had been thinking on and deciding.
The same way we can encounter this situation on start-up companies we can see the need to create new projects with new tech on -currently- brownfields, making an oasis in this companies. You can get hired on a consultancy and start maintaining an "old" banking app and then a new client appears, maybe a neo bank that needs a full ecosystem of applications so if you're like a 4x4 developing your engineering skills and make your superiors notice it, you can be moved to the new project and be in a Greenfield.
I would say that working on many "little" projects and in a full stack role as a junior makes you better in the future in project development career, as you get global vision of what is a project in truth, all the concerns and how it's managed.
Erm... Tbh to me it's more of the different type of work your doing, mindset, pay and the culture you will be part of.
I remember something similar by Reid Hoffman. "People who works in a early stage startup is like a marine who's purpose is to capture land and secure a beachhead.
Whereas the role of a Army (developers working in brownfield projects) is to secure and hold the land that has been captured by the Marines.
They don't work well with each other and hate fulfilling each other's roles if they are given the choice."
So it's a matter of preferences. If the person has aspirations for MNC/consultant/government working on brownfield projects.
I would just point to them to go for those type of companies. Cause they know themselves best. If they want to be part I will tell them what they should look out for.
I'd argue with this a bit. I don't think that a marine needs to know what and how exactly an army solider does. Whereas in IT it's different.
Those who never worked on brownfield, those who were never been responsible to maintain a product, will never deliver maintainable code.
We all now those devs who fly from project to project without never following any product into later phases of their lifecycles. They write some code, the feature "work" and after them, The Deluge.
In our teams, we used to have a rule. You join the maintenance team first and once you felt the burden of decades on your shoulders, you can start working on new features.
I call these drive-by developers. They usually leave a mess.
The core of the problem is in how you run your software development process. If you run it like a series of projects with a fixed goal (i.e. the delivery of a feature), then you get unmaintainable code. If you run it as a product, you have the chance of getting maintainable code.
It is well documented that writing maintainable code is slower at first, but it will pay back big time in the future. Maintenance is easier but so it extending the product. Where with project based development you will often find yourself applying more and more ducttape and other MacGyver style tricks to keep the thing from not collapsing.
Starting with maintenance work is a good way of learning how the system is set up. You need to get an understanding of the system to know how to change it.
I like the sound of that rule, I can't imagine a smaller company going for it but 3 to 6 months trawling through old code, weird database relations and learning about the madness of SQL jobs that are undocumented and totally hidden from view would be quite "character building" I think.
I once managed the upgrade of 6 backend nodejs APIs with about 700 end points, every single one had to be changed in someway as they all hit SQL and the SQL package we used was changing. Not a single end point had a test, I had to manually test and verify every single end point individually.
I will never not write an API response test again.
Yeah, it is a very good character building experience. That I just had to look at this article called The 5 stages of dealing with legacy code when I was taking over a legacy system from a outsourcing software firm.
The worst feeling is the aspect of reverse engineering that legacy system. I was scolded by the business ppl that I was bad and taking a long time on building/upgrading certain parts of the legacy system. Despite there's totally nothing given to me that is useful for development.
That's a good rule and that's provided that they know they are getting into a legacy system. As Simon and you had mentioned unless they know what they are doing and prepared for it they will fall badly. So it makes total sense to have a new developer working on maintenance before working on new features.
I understand that new systems will become legacy systems eventually. Therefore there's a need to understand and learn ways to tackle legacy systems regardless your own focus or type of work you want to do.
What I am saying is that if I were to do the same thing, say bring a developer who had worked only on legacy systems into greenfield projects like those in startups. It will be quite challenging for them to tackle greenfield project like those in a startup. Since the focus is towards speed, adaptability, resourcefulness and product market fit that you are building for.
Agreed, there are challenges joining a greenfield from brownfield but having done that myself I think the challenges are lesser - if only because most devs have started new codebases themselves for learning and side projects. It's hard to grow a side project to 3,000 SQL tables and 6 interconnected APIs and a fragmented front end.
Yup I got to agree on they might have a easier time to transit. I won't say that might be easy including things that brownfield projects does not contain.
Like design, business value/case for the solution your building, resources availability, prototyping and time to adapt to rapid changes 2 weeks from now or less.
Yeh I think a good mix of both is probably my the best but it’s a question I get from people on my Instagram quite a lot - fearful of making the wrong first step (when really there isn’t a wrong step just different experiences) 😀
Haha I won't be surprised they will be asking to choose between the management or the individual contributor path.