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...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
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.
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.
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.
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.
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!