Is programming more in the category of writing than engineering?

I'm a software developer, yet I'm teaching myself electrical engineering atm. Programming certainly comes closer to art IMO but not by much. Comparing it too much to writing ignores the logical thinking required with programming, I think.

But yes, it's possible to write "apps" being completely oblivious to maths and logic, in certain cases.

I suspect, in concept, it is closer to engineering, but likely, in terms of the actual experience and similar, is probably more similar to writing.

actually, I think it is more like reading or writing, but more directly tied into visual processing and thinking, rather than natural language which more often is tangled up with and has to take a route through auditory thinking processes.

I think it may actually be a little easier, as I have more "mental bandwidth" in the visual space than in the auditory space, which can often only really manipulate information about as fast as it can be heard or played back.

but, at least for me, the auditory route is more directly linked to semantics and "meaning", leading more often to code being handled in terms of visual manipulations, with some overlap with my sense of tactile experience (almost like if a person had extra arms which were able to quickly manipulate the thoughts within ones' head). sort of like where any thinking and associated mental and physical actions all sort of end up tangled together.

so, it gets confusing how it is best classified...

and, "the experience of endlessly manipulating bits of text in an editor and similarly manipulating bits of text in editors with ones' mind, often at several times the speed they can manipulate the text IRL, and typing out the bits of code which form within ones' mind" would be a woefully inadequate description...

nevermind if one claims that representations of data-structures seem to have a size/shape/feel almost like they were physically existent objects, where working with code and data-structures is an experience almost like messing with something like legos or similar (like, where the programmer can actually "feel" the code, which in some ways isn't just like flat text, but is in some ways almost like its own independent entity, which almost seems to quietly speak about what it wants to be and what it wants to be able to do, ...).

yeah, weird and meta I know.

so, I don't really know how it fits, if closer to writing or engineering, or how exactly writers and engineers seem to experience things.

I am aware though that when trying to write fiction, it is often an experience more like I am sitting around watching something happen on TV, and then describing what it is I am seeing, with some ability to "imagine" things which happen or are pulled into the scene (or to try to steer the action), which then influence what starts to happen (how the characters respond, etc...), then I basically pause/unpause or cause it to advance at a slower rate to give more of a chance to write about and describe what I am seeing (and don't often know how things will start to turn out before I start writing about them). but, at the same time, one also can sort of know the thoughts and feelings of all the characters in the scene, which in turn determine how they respond to the various events and actions by other characters, ...

but, I guess it is sort of similar.

I have sometimes found that I am slightly limited by what sorts of things I can imagine, like if I can't visualize an object or thing in space, I can't really describe or reason about it.

like, logic and math becomes like a physical mechanism, with the "shape" of the mechanism, interconnections of various parts, basically influencing how things "fall through" the device, ...

this gets to be a problem with more advanced math though, as things seem to go into areas which are harder to visualize or reason about as objects.

but, with a machine, one can imagine the device and its parts doing their things, and have a pretty good idea how it will behave, or just imagine the device from the known parts and "poke at it" and see what happens and similar.

or, you can pull a person (or big robot or whatever else) into the scene and they can poke at the device, or throw a stream or rocks at something, or whatever else.

(yet I still fail to make good game contents or think up much interesting to make happen in it...).

or such...

I engineer my code as though I'm writing to an audience of one. I have to translate what I want to communicate to the computer so it can understand what I'm saying. It makes no effort to try to understand me or care what I feel. I have to spoon feed it line by line until finally it seems to do what it took so long to coax it into doing. Sometimes the final version differs vastly from the original goal because the medium helps to shape the message.

Writing is not really equal to technical writing. I did programming, writing BS (on forums), writing user manuals and customer reports, designing very simple machines and designing Lego Technic.

According to my experience, the only two similar things in the line is machine and Lego Technic model design. I suck at writing (putting my thoughts into text) but I seem to be talented in technical writing and editing technical documents, user manuals etc.

All professions have similar traits but have very various depths in the different aspects, like complexity, maths and natural science involved, forgiveness about hacky and temporary solutions, number of aspects and conditions to be matched, the possible danger of usage, the range of users, the required durability, the life-spam, legal stuff etc etc.

Just an example: programming is much more forgiveable about hacky and temporary solutions than machine design, because it affects less areas, mostly maintainability.

I personally think it's exactly in-between.

The engineering part are the algorithms, the good practices, the logic, etc... It's there to make it work, be correct, robust and tested. However, merging all that elegantly into code is a form of art, like writing ...since we write the code for humans after all, not the machine. And how good you master the skill of writing code intuitive for others is the difference between an amateur and ...an "artist".

You are acting as if there is no component of artistry in other engineering fields, but this is simply not true (though I admit it may not be readily apparent to the casual observer).

There are obvious fields such as architecture and industrial design, which are plainly a fusion of engineering and art. But even the more-sciency fields (electrical engineering, etc) are not devoid or art. The overriding principle in engineering solutions tends to be "elegance", and elegance is a thoroughly aesthetic principle.

Yeah building a bridge or an office or a combustion engine or a toaster all require creativity, insight, innovation, artistic thinking, etc... just like building structures in code does.

For me, "software engineering" is largely thinking about how to write code on a larger scale. Most coders are not software engineers.

Anyone can make a model house out of popsicle sticks, but an architect worries about how to make a full-scale house that will actually stand up to real loads.

There's lots of bedroom coders who can make cool things in isolation, but a software engineer worries about how to modify coding practices so that 20 staff can all be coding on the same project, and what kind of constraints to put on the way those people write code such that the resulting product will be bug-free, easily maintained, and will perform under real loads.

A structure engineer can look at a pillar and tell you that it won't be able to hold up the floor above. They can tell you that if built this way, you won't be able to add a roof-top garden later without renovation at the foundational levels.

A (games) software engineer can look at a loop and tell you that it's going to saturate the L2 cache and bottleneck the CPU, blowing out your frame budgets. They can tell you that if coded this way, then later extensions to this module are going to require large-scale refactoring, rather than elegant connections.

I'm not sure if you can separate writing from a job that requires literacy. We do write entire novel-length text with logical syntax, however we're no closer to having a title such as a novelist than some other highly technical field, like engineering.

Given time, trained program designers who are also programmers will make their fair share of technical documents, exactly like engineers have. They'll even have to explain what the documents are if they'll be reused, exactly like engineers. This includes charts, drawings, schematics, storyboards, you name it.

Programing isn't just typing in text, just like writing for people isn't just typing in text. Both fields have "engineering" - when you're writing for other people, you have to consider how your audience will interpret your message. Do they have the existing knowledge necessary to understand what you're saying? Will they interpret your meaning in the way you want them to? How will they react to your message?

The higher abstraction layers of human communication include Social Engineering - engineering your interactions with people in a particular way in order to get the desired response from them. Patterns arise in social engineering similar to how patterns arise in software engineering - you have a particular goal or problem, and there are some ways to achieve those goals that have higher probabilities of success than others.


In short, I would argue the other way around: Writing is more in the category of engineering.

You are acting as if there is no component of artistry in other engineering fields, but this is simply not true (though I admit it may not be readily apparent to the casual observer).

Agreed. For instance, I designed my first circuit board recently. Routing connections on several layers between electrical components is more of an art than anything else (though some logicial constraints apply and have to be watched out for all the time). Coincidentally I felt it's something I will not want to do again, because a less technical person could just as well do it in their less expensive time. It's like how I'm not comfortable spending time coding (simple) websites or user interfaces.

In programming, you may never use that stuff at all. Sure, I've used some dot/cross product, plane equation, etc. in my game development, but in my professional experience (business apps) I've never used more than basic arithmetic.

Actually you can model quite easily and very efficiently with math in programming regardless of what you are doing, you can easily make your entire application a collection of mathematical equations. Then again you can model anything, math can be applied to everything and be useful too. Computers are really powerful calculators and everything you see or do has some math behind it, making it easier to apply regardless of the project and it can actually be a fun way to move away from the traditional 'physics / engineering / finance' approach to calculus.

Play around with an OO functional language focusing on equations for a while and you will probably quickly find many ways you can apply calculus to your business apps and almost all the areas wont be obvious either.

In programming, you may never use that stuff at all. Sure, I've used some dot/cross product, plane equation, etc. in my game development, but in my professional experience (business apps) I've never used more than basic arithmetic.

Actually you can model quite easily and very efficiently with math in programming regardless of what you are doing, you can easily make your entire application a collection of mathematical equations. Then again you can model anything, math can be applied to everything and be useful too. Computers are really powerful calculators and everything you see or do has some math behind it, making it easier to apply regardless of the project and it can actually be a fun way to move away from the traditional 'physics / engineering / finance' approach to calculus.

Play around with an OO functional language focusing on equations for a while and you will probably quickly find many ways you can apply calculus to your business apps and almost all the areas wont be obvious either.

reminds me of something that came up a while ago, and became a point of contention:

as I see it, computers don't run on math;

this doesn't mean math isn't involved somewhere, only it is not what actually "runs" the computer, but rather, it is much closer to running on mechanisms implementing basic arithmetic with an algebra-like abstraction layer thrown on top, but even then it is weak as many core assumptions made in algebra and calculus don't really map over to computers, and with most of the actual "math" part being done by the human programmer (and not by the computer).

but, then again, I am left to realize that this basically comes down to worldview.

actually, I guess this brings up another point:

actually knowing what one is doing, and thus designing something more based on the relative design tradeoffs of the various options;

not really knowing what they are doing, and just sort of hacking on it in an attempt to get a desirable result (basically, lots of fiddling and trial-and-error trying to better approach the desired results).

I guess, arguably the "engineering" in software-engineering, is probably more in reference to when someone knows what they are doing (and weighs various options and similar), rather than just hacking on it in an attempt to make it work.

interestingly, both seem to have pros and cons, rather than one strategy or another always producing a better result.

it seems to depend a lot on what someone is doing at the time.

other times, a person may need to "just do it" regardless of whether or not they really have all the prerequisite knowledge.

like, "there is only me, and I don't really know how to make this, but there is no other way it is going to get done" (leading to it being time to break out the trial-and-error and prepare for extended periods of fiddling...).

or such...

I think of "engineering" as being the process of taking a set of requirements and creating a system of some kind to achieve those requirements. "Software engineers" therefore take a set of requirements for the behaviour of a piece of software and create a software system to achieve those requirements.

I think of "engineering" as being the process of taking a set of requirements and creating a system of some kind to achieve those requirements. "Software engineers" therefore take a set of requirements for the behaviour of a piece of software and create a software system to achieve those requirements.

A set of requirements encodes an infinite spectrum of possible implementations. And all possible fields can be reduced to that act of producing implementations which satisfy a particular set of requirements (even a master chef is merely producing a recipe that satisfies a set of subjective requirements).

It is that act of creation that is relevant to this discussion.

Play around with an OO functional language focusing on equations for a while and you will probably quickly find many ways you can apply calculus to your business apps and almost all the areas wont be obvious either.

That sounds awesome! I have been meaning to make some time to learn F#. Do you have any examples of how you've applied calculus to a business app? Did it have practical benefits? (e.g., implemented code faster, more maintainable code, etc.)

I think of "engineering" as being the process of taking a set of requirements and creating a system of some kind to achieve those requirements. "Software engineers" therefore take a set of requirements for the behaviour of a piece of software and create a software system to achieve those requirements.

A set of requirements encodes an infinite spectrum of possible implementations. And all possible fields can be reduced to that act of producing implementations which satisfy a particular set of requirements (even a master chef is merely producing a recipe that satisfies a set of subjective requirements).

It is that act of creation that is relevant to this discussion.

yeah, I think it is mostly a question of methodology and thought processes, and what exact types of methodologies and processes can be regarded as engineering, ...

for example, some people assert that it isn't really engineering unless a person uses the BDUF or Waterfall methodology, or may go as far as to claim that Waterfall is the only valid way to develop software, ...

whereas, lots of other people use various other strategies, and tend to also be fairly successful at getting software made.

I have personally found it is preferable to avoid dealing with anyone which obsesses too much over methodology though.

for an individual developer, elements of lifestyle, psychology, time and effort investment, available resources, ... may also become significant factors.

so, whether or not it is really engineering or not, or necessarily even whether or not it is ideal to consider whether it should or should not be such, I don't really know...

Engineering: the art or science of making practical application of the knowledge of pure sciences.

Programming is one part of the process of Software Engineering - which in itself represents an art / science of making practical application of the knowledge of computer sciences. It's indisputably engineering.

Dictionary definitions aside, a software engineer is not doing work that is all that different to the person who is designing and architecting bridges (indeed, the architect is almost certainly reliant upon at least one software engineer in order to do their part of the work, if they are not doing so themselves already). People hire programmers who are good at math, because algorithms are a strictly mathematical process used for reasoning or data processing. Writing code may require the act of applying oneself to a keyboard and organising a series of words into recogniseable language, but that's about as far as it goes in terms of similarity to writing.