> This is the best-kept secret of the software engineering profession: engineers hate code. Especially code written by other people. It's why they love working on greenfield projects so much. No code, no maintenance, no headaches!
Except that I've met lots of engineers who were the opposite. They hate greenfield projects and prefer maintaining existing code. I noticed this broad division of personality early in my career. And it's a great thing -- both sorts of engineers are critical to a successful project.
I am one of those who prefer working on existing code. I like making things better, understanding how a code works is thrill, adding new features on existing premises.
I am also an amateur fiction writer, and I notice the same thing in it. I like planning, but the first draft writing is a chore to me. An effort to vomit all my ideas as words. Then, I love rewriting. Revisiting what I wrote and improving it, fixing it, perfecting it.
> I am one of those who prefer working on existing code.
Me too, mostly because I hate starting a project form scratch, it's something I'm not particularly good at. Like you, I love rewriting, I love improving things, making them better, faster, or easier to understand.
The notion that software engineers hate code is wrong, depending on who you consider a software engineer. SREs, systems administrators, operations people, they hate software with a passion. Developer (who in my mind are software engineers) freaking love code and will write more code to cover up problems which should have been address by revisiting designs and earlier assumption. I've meet with developers who's understanding of IT outside the realm of development have been so extremely poor that they frequently reinvent basic webserver or database feature, but badly.
Currently I'm working on a Django project, in the back of my mind I always have a notion that if something requires more than 20 - 30 lines of code, then it's either already a feature of the framework, or I'm doing something terribly wrong. That rules has yet to fail me.
I'm similar, and I've found AI to help with this. I'm able to guide the AI to write the first draft, then I go in and rewrite it. It's helped remove that frustration at the first draft.
Depends on what I’m writing. For anything vanilla I use the chatgpt site Ui. For anything that maybe censored like smut I use prompt engineering and gpt 3.5 turbo via api to get past the censors, although they just announced this model is to be deprecated in January so I’m playing with local language models to some success. For now been using gpt4all and it’s surprisingly good, although slow on my hardware.
I think the reason to like working on existing code is that infra is usually very complex nowdays, and for greenfield project you need to do lots of boring tasks to bootstrap it, and for existing code it is already bootstrapped by someone.
Not just infra. It’s the tests, it’s the crud, its getting clients and config setup, it’s banal decisions around copying existing patterns or trying to refine them for next gen copy pasting.
It’s fun early in career, but gets boring fast IMO. These are good things to have junior and mid eng cut their teeth on.
The sweet spot is for someone with deep experience to lay down the skeletal structure of the tests, rpc, infra, lifecycle, etc… then hand it off to a broader team who could learn the intention behind the decisions.
> who could learn the intention behind the decisions
If people did learn those intentions we wouldn't have the problems we have.
I inherited a project like this once as the third generation to take it over. The (evidently, I never met them) well trained and experienced first developers laid down a foundation using a textbook OO style with a few little tricks needed to make that work in a language where OOP support was bolted on. The code was not perfect, but it was professional work and I would put it around the 80th percentile in terms of code quality.
These tricks caused the virtues of that foundation to be overlooked entirely, and so the project was essentially reimplemented in spaghetti style over time with various ad hoc stovepipes to pass data back and forth between the two sides when the original had functionality that wasn't understood well enough to be reimplemented.
The importance of training, communication, and retention can not be overstated.
hah humans are interesting! I'm the opposite. I love starting a codebase, I also make music and it's way easier for me to make 100 cool unique sketches live and improvised but not finish anything. it really takes all kinds
I would love to team up with someone like you. Having a person that can start a new code base and not be overwhelmed by the task is a godsend. I'm much more comfortable diving into an existing project and extending it or fixing bug than I am starting something new. Somehow it's just more natural for my brain.
My favorite musical partnerships have a balance of a starter and (me) a finisher. I really struggle with producing raw material, but am good at revising, reworking, and cutting out fluff and my best writing partners are great at spewing out ideas, most of which are cut. It together, we are able to make something we’re both excited about.
That's the dream! I think it won't work at most public companies unless you end up in a department with a dead-end product whose raison d'être is to keep one or two whale customers happy.
I have a friend who does migration tools that help businesses move their data from ancient versions of software that the big players don't support any more. It's a niche, but it's a niche that banking/insurance/etc customers are willing to pay for. I've applied for jobs like this and never even made it to the screening call. When I asked how she got the job, it was through a former colleague of hers. I actually interviewed with that colleague at a different company several years prior and I heard from her that his impression of me was that I would be bored in the role. So I think it's really important to emphasize to the hiring manager that it is exactly what you are looking for, especially if you have a background in more "hip" companies.
If the "boring" companies don't call you back, my recommendation would still be to look for B2B software, or an internal/tooling-focused team where your customers are your colleagues. It has to be on a product that is already profitable (or seen internally as valuable) so that you don't get pressured into adding new features or having the whole product killed from under you. Ideally a company that is not on the IPO track. There are some maintenance roles to be found in these "hip" companies, but they're rare, and I think you have to accept that you might only be able to fly under the radar for a year or two until an ambitious executive comes along who wants to reorg the department into a boondoggle production line.
My brother works for Birds Canada making 40k CAD a year. Got dropped into a 500-1M line Java codebase and asked to do site redesign and is now implementing SSO for them.
I recommended “Working With Legacy Code” and he read it.
His first job so great experience. I guess be underpaid is the answer.
I think it's a spectrum. For example I like writing new code and designing new things, but I don't hate or dislike my or other people's old code.
That code also has been written by a human, and it's disrespectful to approach somebody else's work with this prejudice.
It might not be good code, by our standards, but who knows how it was written. Was the author under stress, under time obligations, or happy, or something else?
Also, being able to approach somebody else's code and work with it is humbling and deeply educative for me. You get a (free) passage to a wisdom of a person or a group. That's priceless.
> That code also has been written by a human, and it's disrespectful to approach somebody else's work with this prejudice.
Small piece of advice: it is much better to learn how to take criticism of your code as exactly that - it's criticism of your code. People will always be unkind when reviewing code. Even if it's the best code ever written someone will have a different opinion and express it in a seemingly unkind way. It's easy to be unkind in code reviews because it's _code_ being reviewed and NOT a person with feelings.
Like you said, a different human (the more junior version of you) wrote that code, not you. It's not a criticism of you no matter how much your brain tries to tell you it is. People will never stop saying "who the fuck wrote this shit!?" and you will hear that phrase until the end of time. It's still not personal when people yell that in frustration.
For example, I have learned that Eastern Europeans tend to be absolutely brutal in code reviews. Everything will be nitpicked and the most benign design decisions you've made will be questioned. They make you feel stupid and inadequate but that's your own feelings. It's more likely you're dealing with a direct and to-the-point perfectionist who can see the code beyond your PR and how your code fits in with the rest of the application. They're not the greatest at communicating this context and their comments seem like personal attacks without that context.
You're right, one needs to be able to take criticism, not about the code, but in everything, however being able to give criticism correctly is equally important.
This is not about style (kind or to the point, or in any style), but again about keeping in mind that you're talking with a human being.
You can say "This doesn't work (because of this), so do it this way", in thousand different intonations, and you can add the underlying message in anywhere on the spectrum of "this works better for our case" to "you're a triple distilled idiot".
This is not about being sensitive or having a skin, this is about mutual respect in a professional setting. When you do your to the point, brutal criticism, you cannot hurt the other party if you keep in mind that you are talking with a human being.
During my M.Sc. jury, one member called me a liar, and my professor had to intervene politely yet forcefully, and in my Ph.D. jury one member flat out insulted me, yet I defended myself politely yet forcefully.
They could have said the same thing, with the same words, in a much politer tone, but they preferred to attack me directly instead of attacking my work, so there's that.
I tend to give direct criticisms as well, yet I do my best to make sure that it's plain and simple I'm trying to guide and it's about the work, not about the person.
Because, I do not do anything to anyone which I don't want to experience myself.
Your handling of the PHD situation sounds perfect and it seems like we're in agreement.
I want to reiterate you will never be in a situation where everyone is respectful even if it's a professional setting. You also can't control what other people do so there's no point expecting people to give criticism respectfully or trying to teach people how to do so - you can't correct someone's behavior if they don't want to change it.
Every time I catch myself wanting to say "people should act like xyz" I stop myself and think "I will react a different way when someone acts like xyz" instead if I'm not happy with how the situation went. Especially if I've already expressed my feelings and someone has ignored them and still acts in a way I don't like.
I think I misrepresented myself. I don't expect anything from anyone, in any setting, or I don't intend to change anyone. Who am I to expect to change someone?
I just wanted to say that, I behave the way which I want to be treated. I ask myself, "what would I feel if that's done to me", and if I don't like the answer, I change myself, and try to better myself step by step.
Actually "The Four Agreements" by Don Miguel Ruiz sums up pretty well how I live this life. It's a surprisingly thin yet dense book. I recommend it wholeheartedly.
Looks like we try to do the same things with slightly different methodologies. My hat's off to you dear sage internet stranger.
I agree so strongly with this. It’s all about the code! You need a tough skin in this game, and the ability to seperate emotion from the end goal “good code!”.
I love the Eastern European approach; blunt and to the point. The French are also good for this. We anglos are so sensitive, and so afraid of offending, that you end up with a silly inefficient dance. “Have you considered? Perhaps if we tried this approach…”. No! Give me “this won’t work, do it this way” every time!
> That code also has been written by a human, and it's disrespectful to approach somebody else's work with this prejudice.
Not only has it been written by a human, but one should also remember that they're missing the context in which the code was written. Was the author stressed about their latest children being born? Fearful of possible layoffs? Under time pressure? Tired?
I've definitely written code myself that came to bite me later, and I marveled at how badly written that was.
We're all human, which, among others, means that we're all inconsistent to a large degree.
Also important is Chesterton's fence and the history lesson when touring existing code. What were the business requirements the first time around that were thrown out the window for version two, but there was no time for refactoring so version three has this known wart that version four tried to refactor but that wasn't complete until version five which had this new feature that needs another refactor.
Too many developers remain hyper committed to shiny object syndrome, or wanting to relearn lessons of the past as if they are the first to ever lay eyes on it.
No code is perfect, and lots can be learned even from a well intentioned approach gone wrong.
It’s far easier learning from other folks and their rattlesnake bites instead of insisting of recollecting that baggage yourself, first.
Greenfield is still useful, but too often it has to do with preference and interpretation or a lack of willingness to do so.
I’m pretty good at writing code but I consider one of my “superpowers” to be that I also love to read code. I cannot even begin to estimate how this has affected my career and abilities. It’s a task that most seem to dread, but is something that I do for fun.
Indeed! This phenomenon has been a great source of freelancing customers for me.
Startups naturally thrive on an early team that loves building new things, but the flip side is that they rarely seem to go back to fix existing stuff. That leaves a gap for people like me, who prefer to take something that works poorly and make it bulletproof. For some reason this quite often seems to involve db access patterns but there's a fair bit of algorithms work too. Usually the "building new things" engineers are quite happy to let me take over the investigation into why the 150 line SQL query is slow, so it's a win-win.
Startup teams also aren’t great as they should be at being even slightly kind and thoughtful to their future selves.
Understanding greenfield usually means iteration, a small amount of conceptual architecture and organization before dialing into the matrix to go full Neo can go a long, long way.
Specifically, it’s easier for startups to create productive new beginners in their codebases.
Most of my clients were from a local meetup where I eventually got to know most people quite well and they me. It was mostly word-of-mouth where people remembered "Oh! <other startup> had similar problems and WJW solved it for them".
Sure. Of course there are actually software developers out there in the world that read and write code. After all, that's where all this software in the world actually comes from.
But for the other 85+% of people in the profession its basically a game of AdLibs. Fill in the blank. That's why there is such heavy reliance on things like frameworks, dependencies, and Invented Here Syndrome (people who don't trust their own or teammates code). That's why you have expert beginners, because you can get really masterful at coloring with crayons.
Try to take any of this color by numbers nonsense away and see immediate full on emotional apocalypse. It's not a choice. The number one priority is to retain employment, and if your employer has failed to provide you the preparation or environment necessary to perform with confidence this is what you get.
> But for the other 85+% of people in the profession its basically a game of AdLibs
This is so true. I work at a fairly small organization (~35 devs). Large enough to see roles form but small enough that I can tangibly see everyone's contributions. I work SRE, so I see lots of code from all the teams and ultimately talk to almost all the devs.
In our impressive enterprise-level codebase (our SaaS product has average annual subscriptions in the range of $1.5M per customer), there are probably 3 developers that wrote 80% of the codebase. I can name them all and call them up. But I said we have 35 devs in the organization. So what do they do? Mostly little things. Flipping a conditional or making a slightly more explicit test case to fix an unexpected edge case we experienced.
Most of these 32 other engineers are solving simple problems, basic refactoring, and so forth. Not too different from the adlib, fill-in-the-blank analogy you provide.
Also, to be clear, it isn't like we hired 3 seniors and expect them to write all the code. These are just groups people fall into naturally.
The reality is most software engineers have only ever done the adlib style work and have built an entire career around never solving any real problems. They know just enough syntax in a language to solve the little problems and with software, there is a near infinite supply of these little problems.
Sounds like SRE has afforded you a unique "who's writing what code small-org-wide"
semi-impartial perspective. Thanks for sharing!
I'm curious if the ~three devs that "wrote 80% of the codebase" mutually recognize one another? i.e. do you think they think of themselves as in a "writes a lot of code" category along with the other ~two devs? Do they think of themselves as "writes a lot of code"? Does management recognize this and/or plan around it?
I've sometimes been one of the "people writing a lot of code" in a small org. When I'm in that mode/context, I find myself daily appreciating the types of contributions made by the larger body of folks less deep in the woods. They do a different and complementary type of work, and I've found both types bring something valuable (and different) to the codebase.
When I was a developer I hated it. I was almost always the #1 in LOC, Jira Tickets, Scrum Points, you name it. I was naturally good at it, but the environment was always very competitive and the other top performers would brush it off as just me being lucky with "LOC Heavy" tasks. And it would piss me off that I would get paid the same as a guy who wrote 200 LOC a month and wasn't doing much more than those lines.
Being a manager/lead developer today, I enjoy the people doing small work. I just let them pick tasks as they wish, and it takes longer, but they eventually pull through.
The problem is just that they're a bit unpredictable, so if something has a tight deadline, we gotta assign to someone else.
As a developer I don't mind that other people don't do work. If they want to stagnate in their career that is their problem, but it certainly isn't a problem for me... until they make it my problem. This typically happens when entitlement sets in and the baseline lowers so dramatically that not doing work becomes a mandatory expectation only shattered by the crying when conveniences are peeled away.
Worse than that are the people who work their ass off, but just aren't good at it. I would rather work with people who prefer to not do work. The output is generally the same, but the people who work their asses off cannot see the difference and believe they somehow deserve more.
In my career the single biggest failure that I see repeated EVERYWHERE is confusion about what software really is. There is only one purpose to any of this: automation. In that mantra actually not doing work is supremely desirable so long as the output meets expectations.
I think the biggest risk with the people who work their asses off more than they should (doesn't matter if it's good or bad code) is that they end up with a non-sustainable output. Productivity is artificially high, and often achieved by overtime, working weekends, and overworking themselves. Eventually that leads to burnout, lower quality, and it becomes hard to replace. When it's people working too much and delivering bad code it's probably not as bad, though.
At my current company we have someone in this situation, with work affecting their day-to-day stress levels very much, to the point of damaging their personal relationships. Their manager is young and inexperienced, and doesn't see the issue, but he was flagged by HR and I hope something gets done.
This is why the tech interview is still an unsolved problem (for non-tech ppl).
How does a non-tech role sift through the 32 devs who did 10YOE flipping bools vs. the 3 that built the entire system? They'd look similar on paper and in superficial conversation.
This is the plague of hiring senior engineers, and one of the reasons we needed a new code test/challenge to get fewer bool flippers in our senior engineer hiring process. If you make them do something complicated/complex you get a lot more signal than if the test is bool flipping/a simple project from scratch
I think this is an orthogonal point. Certainly there are lots of bad developers in the industry whose code appears to only work by accident. But there are just as many of them doing greenfield projects as maintenance tasks. In fact, I would guess that in growth-oriented companies there are far more of these bad developers doing greenfield projects.
The issue is that in many companies there is constant pressure from management to "innovate" by building new features or new products, even if they are of no particular utility. New stuff will bring new customers (or new subscriptions from old customers) and that will either make you personally rich, or at least look good on your CV so you can leverage the experience into the next job where you can get rich. And if the project fails, it still leaves you looking more valuable to the top brass than the people who quietly kept the systems running, because you took risks and had big ideas and showed a growth mindset.
I didn't really notice this at the start of my career, but once you see the pattern it makes so many jobs incredibly depressing. People just keep building more and more crap to advance their careers and enrich the shareholders, even when very little of it is actually useful. It's even more depressing in B2C where it becomes apparent that a large part of the money comes from exploiting individuals who simply get a buzz from buying new stuff, no matter what that stuff does or how good it is.
Personally, I am much more happy to work on an established system that already has real customers that value what it does. The phase of throwing huge amounts of crap at the wall to see what sticks is over, so what remains is an actually-useful piece of software that's full of bugs and superfluous functionality that the "innovators" (comprised of both good and bad developers) left behind. I think it's worth it to have good engineers dedicated to this role of taking the mess and refining it into the best version of the thing that customers actually want. Leaving that task to the bad developers will just result in the system eventually collapsing, which might not matter to the entrepreneurial types who only care about growth, but it does matter to the customers who were getting value from it.
The way that masked language models are trained is nothing more than madlibs. This is how I've always explained it to normies and they get it quite well.
Most of my early career was "greenfield". I really loved doing that. Sometimes that meant me doing everything. Guess where the buck stops? There's no way to disconnect the final result from the work. Keep in mind though that green field pretty quickly turns into maintenance. You ship something, guess what, there's bugs to fix. You want to add a feature, you have an existing code base. The nice thing is that there's no one else to blame. Is it really hard to add a feature? You (or your team) messed up. Does the quality suck? You (or your team) messed up.
Even in well established code bases there can always be "green" new pieces. These are choices to make: should we refactor the code, should we fix the old code, should we rewrite pieces of it. There is no one answer that always works. The problem is when you look at something and your answer is always a rewrite just because you didn't write the original code. I've seen people/team rewrite perfectly good code for no business reason, just because they want to.
In terms of code written by others, sometimes that's a thing of beauty, a piece of art. Sometimes it's just garbage. I'm sure we've all seen some code where we go wow, this is incredible. And then we've all seen code where we go wtf. I don't really see the need to dig too deep there, what's great is great and what's garbage is garbage and then a lot is somewhere in the middle. I sometimes look at code I've written in the past and I think it's really great; and sometimes I go wtf. Usually the latter is where I was not familiar enough with the problem space or the code base I was working in. Questions to ask are: does it work? what's the cost of maintenance? Ugly code that works well, doesn't need to be touched, can be fine.
1. Only working on greenfield means you don't want to learn from others or have difficulty doing it. Lots of knowledge is expressed in the code you refuse to read and you need humility and patience with your own ignorance.
2. Only reading code is insufficient as you are not only a scholar of the code base, but a maintainer and developer who must extend and adapt it.
Working with a code base is more like a conversation. There's a back and forth, though not symmetrical. (1) is someone who monologues. (2) is an audience member only.
Earlier in my career, I was stereotyped as a "maintainer", but now I've been a self-employed indie developer for years, so all of the code is mine.
Once your own code gets to be 5 years old or so, it's almost like maintaining someone else's code. It's like, why in the world did I write that before??
I guess my focus has always been on the product and the user experience, so I don't make the code itself central to my work and my identity. The code is not the product.
I think it's a culture thing in SV/VC//startup world and I think that group is very public, outspoken and sure that they speak for everyone.
Most if us aren't that but we just continue about our business developing new features and squashing bugs. I like greenfield projects but the choices and freedom they present come with a lot of non-coding and missing infrastructure.
A nice brownfield project lets me check in code, see it auto built into the dev environment and have QA feedback the next day.
I mean, there are badly designed brownfield projects with tight coupling, bad documentation, and, where you have to spend half an hour to figure out why a simple change broke everything.
Funnily enough, personally, I can handle badly designed projects as long as I was part of the team designing it. At least then I understand it enough that changing things isn't too much of a pain, and I can pretend my refactors will eventually make the codebase look good (or if that fails, I can write enough documentation to at least mitigate the problem). It's a pain in the ass for new maintainers though.
But goddamn, working in a good established project where other people have done the hard work of figuring out non-coding project management stuff is a fricken breeze. No arguments there.
My experience is that people who love writing new projects are probably not well suited for it. It means they aren't stressing over the ambiguities and long-term consequences of every single architectural decision, and thus are more likely to produce a project that immediately suffers from many technical issues, such as scaling, performance, ease of monitoring/debugging, ease of extension, ease of onboarding new maintainers, etc.
Start your project on the right foot by finding that disgruntled senior engineer and giving them ample time for design and research.
I like both. Greenfield projects can be pretty boring when there isn't something special about the functionality or a new architecture to try out, but it feels good to spurt out stable features when you know what you are doing.
Repairing / fixing / retrofitting an old code base always has it's wonders. I've seen much code in my life that was in a bad shape and my approach for fixing was seldomly the same, it was always tailored to the team and situation.
To rephrase from Tolstoy: "Good code bases are all alike, every bad code base is bad in it's own way."
I like greenfield projects but I also have the problem where a blank page gives me writer's block. Sometimes "like" doesn't go far enough.
It seems like this is a good opportunity for LLMs…
A related problem is that "maintenance" is conflated with editing code, but IME some languages especially """bug free""" would prefer you rewrite every time you make a change rather than edit things, because the code becomes impossible to understand after it has more than one author.
I didn’t realize how unique my circumstances were until I started reading r/experiencedevs.
I’ve had 8 jobs over 25 years and over that time, I’ve mostly done green field work, including at my first job out of college.
I’m not even sure I have the skillset to modify a huge existing code base.
Even at one job where there was a large codebase that I was “modifying”, it was mostly to add new CRUD features to an API or website and I did my own vertical “slice” that didn’t involve modifying existing code.
Because a greenfield project would require to do something that software engineer abhors more than writing code: giving time estimates in an "agile" environment.
I'm one of the persons who loves refactoring existing code. It's much easier to get started than writing something from scratch. I change a few bits, then I get more ideas on how the code can be further improved. I always try to consider the business value - is the a maintainability problem? Does the code need upgrades to reduce tech debt? Etc. Hard to sell this sort of work to PMs who just keep pushing for new features.
Depends on the project and the person I guess. The trust of your manager is tremendously important. N=1 here, but at my current client it took me several hours of staring at a huge SQL query before I understood why it wasn't fast but the client was trusting enough that it was time well spent. I've also has PMs who could barely understand the concept of refactoring at all.
I always apply Chesterton's fence when working on existing systems. You don't get to add, remove, or change things before you understand what exists. That discovery is inherently exciting to me.
Well, I'm currently trying to reverse engineer something done by an open source SaaS offering, to patch a tool written by another person which works with that part I'm trying to reverse.
I just wanted to use the tool without any effort, but I have to understand the interface and patch the tool to make it work again. I'm not complaining.
Just wanted to add a data point for the former part of your comment.
And you enjoy and prefer this kind of work? OK! I guess occasionally I enjoy this kind of work too, when I'm in an environment with reasonable expectations of how challenging it will be/long it will take, when I have room for it.
I like both types of work. It’s fun to do greenfield projects because of less maintenance and the ability to do it the way you want. But it’s also fun to take something years old that’s barely working and try to gradually improve it while minimizing down time.
Yep I have a hard time with a blank page and love the flywheel of incrementally iterating on a working baseline. I didn't realize this until very recently; I think I had internalized "well everyone loves greenfield projects, so I must too".
This is a really great point, and it’s awesome when a team strikes the right balance. In my experience these engineers tend to be rarer than the group I talk about in this post, but when you find them they’re worth their weight in gold!
They prefer maintaining existing code until they get a project that's full of legacy stuff and nobody wants to replace it, because it works (most of the time at least).
Fair question, I suppose I didn't express myself clearly.
Firstly, I'd like to abolish the idea that "greenfield" and existing are somehow opposites. Greenfield projects take on a bunch of existing abstractions and complexities from all the stuff they are built on. Instead, these two terms are actually very similar, "greenfield" projects just chose to throw out one more layer than using the existing system. My argument here is that the dichotomy here is false, and that the two terms are instead a classification of degrees to which you abandon existing abstractions.
As I said, I understand that this is what you mean when you say greenfield, I'm not asking you to use different words. I'm asking you to pay notice that this is what you are saying. That you are explicitly not in a "green field" with nothing around you. You've thrown all the furniture out, but the building is still there, the walls are still the same color, and the windows are still overlooking the same parking lot.
This makes no sense to me... Greenfield projects have problems that legacy projects don't (What language to use, what framework to use, where/how to deploy, etc.), and vice versa (How do I design my feature with the existing limitations of the system in mind, do I need to to redesign a part of the existing system to get it to work, etc.).
None of that has anything to do with "Time thinking about the problem", nor does either one imply that its questions are easier or harder to answer in all scenarios. They're just very different questions, but some devs prefer dealing with the issues a greenfield project presents.
Except that I've met lots of engineers who were the opposite. They hate greenfield projects and prefer maintaining existing code. I noticed this broad division of personality early in my career. And it's a great thing -- both sorts of engineers are critical to a successful project.