On the surface, I think you're describing fire-fighters (who are loved for solving high-visibility problems), but in retrospect, I think these are also developers with very high reading comprehension and reasoning abilities. That may not make them great designers and architects (though some are), but they can see code for what it is and fix it, as in "The Big Lebowski", "in the parlance of our times" (in other words, in a way that fits the code as it was originally written).

I mean, if you understand spaghetti code just as easily as any other code, why wouldn't you write it? It would make no difference to them.

What is this reasoning?

If you know the right way and wrong way to build a bridge, you'd build it wrong, because it makes no difference?

More like, if you know English and Latin, why not blog in Latin, since it makes no difference to your ability to enjoy your posts.

So, the question that makes the difference should whether he writes blog for himself or for his readers?

[replace "blog" by "code"]

Anyone can read their blog! Since anyone can learn Latin, if they feel like it.

(Yes, I know I'm representing a terrible argument.)

It's a lack of reasoning, if it's not causing any issue's why change? The rest of us write good code because we're to dumb to read bad code.

No, the reasoning is why build it to handle 600% specified load (and higher cost) if 150% specified load is sufficient?

(Not that there aren't good reasons to do this. Especially for public infrastructure which might be around for a shockingly large time. But predicting future usage is very difficult. For a small start-up, it's fair to err on the side of leaner/fix-it later IMO)

The other way around. If you can get out with doing it the wrong way, why even care about there being a good way ?

And here you see why one should be wary of hires who are too close to the computer, e.g. most CS graduates.

I might be one of these people. I've worked with enough underdocumented code/systems, I don't expect, look for, or provide documentation.(Exception: I provide documentation where there's a clear and stable boundary/interface another team will use)

I had this with the OpenStack API. It's so hilariously underdocumented that I've reverse-engineered it by poking at a Devstack and checking the HTTP requests in mitmproxy. After some time, even when I had to work with a new part of the API, I didn't even bother to check for documentation because just poking around was faster (and more reliable: one never knows how close the documentation is to the real deal).

It was my job for a while to work with scientists and their spaghetti Fortran codebases. One esteemed fellow still stuck to the FORTRAN IV of his youth (the original pasta language). It was amazing how much they could do with such old technology. The overriding impression ultimately was: "Never keep intellectual property just in code"

I feel your pain. Scientists & data scientists are notorious for spaghetti code.

Refactoring scientists code was how I got into software engineering. I used to be a scientist, and I found restructuring/modularizing the analysis code more fulfilling than the actual analysis.

As someone who is currently in that exact situation, and is considering switching away from science, how did the actual switch from science to software go?

For me, the key things were :

- get really proficient in a language, for me it was python, it is a solid, flexible, minimal boilerplate, can use it already for science applications (amazing libraries for it, like pandas, scipy etc)

- understand databases, and how to interact with them

- start testing (unit, integration and acceptance), this is super important, and key difference with scientist programming. When doing a take home test for a job interview, always include tests, even if you get the solution wrong, they will give you massive points for having tests.

- start applying! You'll fail a lot, but you gain experience with each test and interview you do.

Thank you. I've been primarily working with C++ and Python, and consider myself proficient in both, so it is good to hear that Python is usable. I've been meaning to work more with databases, as I haven't interacted with them in particular. Maybe writing a mini-library catalog, as my bookshelves are starting to outgrow the haphazard google spreadsheet where their contents are currently recording. And yeah, testing is something that I try to do in my home projects, but 95% of the coding for research is throw-away code, and so I don't get much of a chance there.

C++ and python are a suburb combo, they complement each other really well. If you master both, by that I mean not just the syntax, but the different patterns and styles you need to employ in static vs dynamic typed, understand the tradeoffs of both, you've pretty much mastered programming.

Python also glues v. nicely with C, if a part of your code is v. CPU heavy, you can write it with cython, and then call the compiled code from python, as you would a normal python function, and it would run just as fast as native c. This is how all those python data libraries work under the hood (pandas, sklearn etc)

Library catalogue is a great idea for DB learning, you'll learn how to model data, and the relations between them, using tables, foreign keys, primary keys etc. I'd recommend postgres for the DB.

Again, python would be an excellent language for this, you can use sqlalchemy to define your tables, and query them. You can then use flask to provide a web interface for the catalogue.

Really well. Dev work is way more fun than science! If you want some advice then:

- Take some time to learn some CS fundamentals.

- Make sure you know a language that someone that might employ you knows (just so they have a point of reference).

- Write some toy applications in the field you want to move to.

Thank you, and it is very good that the path I'm looking towards is possible. I've been brushing up on algorithms, mostly as I run into them in things that I have been writing on nights and weekends. Primarily C++ and Python, with a smattering of C, bash, javascript, and php. I have probably about 6-9 months before graduation, so I've been starting to look at fields in more detail, rather than the nebulous concept of "industry" that you typically hear about in academia.

> management likes them because the can solve problems, they just don't see the creation of yet more problems.

In fire-fighting situations at least to my experience it is usually about fixing things fast and under stress. Not many devs are interested in doing that. These hotfixers probably know their code sucks, but I don't think they need to feel bad for solving the urgent problems in their own way - in my experience it is not a job that many are that willing to take. Majority like to solve the problems properly in a slow-paced less stressful way.

It's a balance you need to run. But as a PM, spaghetti fixers are indeed very nice to have around. Keeping an eye on technical debt is important though.

The hardest part isn't the technical debt, it's detecting when spaghetti fixers are actually adding features to the product.

This is another great point. Our support team is directly linked to a spaghetti fixer, this is great bc bugs are squished instantly.

But sometimes a new checkbox appears and that is a real problem.