Nothing is universal, but I think often the latter.
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.
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.
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.
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.
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.
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!
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.
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.
Wish a peaceful future awaits you.
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.
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.
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.
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.
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.
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.
Some authors really need an editor.
Not a rebuttal just an addition. All these things are true.
I don't want level 3 support or on-call rotation, just established software that needs diagnostics, bug fixes and upgrades.
I guess you just have to apply and ask in the interview.
I recommended “Working With Legacy Code” and he read it.
His first job so great experience. I guess be underpaid is the answer.
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.
I'm being a little bit facetious of course because I do understand the concept of what "greenfield project" has come to mean, but I don't consider it very meaningful.
In my experience the major difference between a "greenfield" and "legacy" project is the time allocated to thinking about the problem. I love thinking from first principles, but with proper management and engineering you can do that just as well on existing codebases, and it will be just as fun.
"greenfield" in that regard, is easier. On one hand, management is more friendly to exploratory exercises when you're building something new. And on the other, the questions you are asking are likely to be way simpler and straightforward, with well known and understood solutions.
In a legacy system, the easy questions are already handled, so the questions you end up asking are difficult and full of edge cases. In many cases an answer may never ever have been considered (right now the system will discard the task if it fails to deliver it for 5 days, is that in compliance with our processes).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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’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.
It seems like this is a good opportunity for LLMs…
Start your project on the right foot by finding that disgruntled senior engineer and giving them ample time for design and research.
I also spend a lot of time repairing and maintaining old cars, houses and fixing up stuff to be better and stronger than it was when I found it.
It’s very difficult for me to leave well enough alone. If it ain’t broke, it could certainly be better!
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.