Hacker News new | ask | show | jobs
by soneca 1081 days ago
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.

6 comments

> 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.
What model do you use for this?
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.

Yeah, sorry, I personally call it dev infra
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.
Some people are editors, some people are authors.

Some authors really need an editor.

Some editors don't know they're not authors.

Not a rebuttal just an addition. All these things are true.

How do you find job postings for these types of jobs? Any keywords to look for? And how do you interview for them?

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.

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.