[tkiolp4]

Programming is so different than software engineering, to the point some people (like me) love the former but little by little are starting to hate the latter.

Learning for the sake of learning, being able to be picky about what to learn, feeling like a god by creating your own worlds, trial and error… these are all traits of programming. On the other hand, software engineering is about sprints, useless deadlines, using the wrong tool for the job, writing code to increase shareholders value, high-performing-team obsession, useless C-level execs, broken tech interviews…

Two different worlds.

[prmph]

I think you are confusing the working conditions of writing software in a corporate environment with software engineering. To me software engineering is about skilled application of a wide range of engineering concerns to programming, such as architecture, data modeling, and QA processes.

I find such engineering fun and meaningful. As a software engineer, you understand that is not enough simply to write code that works, the right (or wrong) architecture, for example, can have a massive impact on various stuff like performance, reliability, code-quality, etc.

The BS involved in working for the tech industry as part of a team is another thing entirely.

[bitwize]

I think that the original advocates of software engineering -- people like Margaret Hamilton -- were promoting an approach akin to chemical engineering.

Chemistry is about understanding chemical elements and compounds and the ways they react with each other to form different compounds. This includes the synthesis of new compounds, to understand the mechanism by which they might be created and the properties of the new compound; accordingly, chemical synthesis by a research chemist tends to take place in small amounts.

Chemical engineering is about the production of chemical substances, reliably, at massive scales for industrial purposes. Chemical engineers elicit and apply the manufacturing processes necessary to synthesize these chemicals by the kilolitre or more, which may be totally different from the processes the experimental chemist uses in a lab.

Similarly, programming is the act of writing code for a computer to fulfill some task, or explore some computational idea. Software engineering is the application of a standard, defined process to reliably produce code at massive scales for industrial purposes (enterprise applications, etc.). Architecture, data modeling, and QA are part of it, but the heart of the discipline is finding and applying the means to organize a large team to produce software that is robust, scalable, and maintainable to support an organization over the long term.

People who fancy themselves artisan programmers chafe at the industrialization and standardization of software engineering. But, as Milt Bryce said, "There are very few true artists in computer programming; most are just house painters".

[jrs235]

"Software Development" includes programming, engineering, and "the BS involved in working for the tech industry as part of a team". Your title can be [software] programmer, software "engineer", software developer, or a plethora of other things.

[tvink]

That's not how you define either of those things.

Granted, software engineering is a pretty ill-defined term, but I'm pretty sure most would agree that agile project management is not software engineering.

"Being able to be picky about what to learn" being programming is also a really confusing idea. Programming is writing programs, it's not some learning philosophy, and it's certainly not some liberated opposite to software engineering.

I guess you're confusing having a job with software engineering, and spare time coding with programming.

[rramadass]

> On the other hand, software engineering is about sprints, useless deadlines, using the wrong tool for the job, writing code to increase shareholders value, high-performing-team obsession, useless C-level execs, broken tech interviews…

That is not at all what "Software Engineering" is. It is Management's view and practice of what it should be based on the fad of the month/year, simplistic efficiency/productivity models, cluelessness about human psychology and its specific nuances when it comes to knowledge/programming work, erratic/idiotic business goals, bad human resources management and in general not understanding that while one can look to established Engineering disciplines for inspiration one cannot apply those processes/techniques blindly to Software Development since it is so very different.

The classic works of Gerald Weinberg, David Parnas, Barry Boehm etc. gives one the proper viewpoint to have towards "Software Engineering".

[marxisttemp]

Barry Boehm is the epitome of the process-obsessed, elegance-hating middle manager

[rramadass]

I have had this argument before and No that is not quite true. For people not familiar with his work - https://en.wikipedia.org/wiki/Barry_Boehm

His research was a product of his times when programming/coding was considered a clerical job with the real brain work being done by System Analysts and System Designers who produced System Requirements Specification Documents and System Design Specification Documents. He was the first to show that software development costs would outstrip hardware development costs and the importance of its Risk Management through a Spiral Model. He brought "big picture" engineering process lens to the management of software development which became "Software Engineering" today.

All of these ideas are still valid though they would need to be modified for current times given the decades of experience we have had since then. Software development at the Individual level involves creativity/art/craft/individual flair and companies must acknowledge and provide means for expression of these psychological needs. OTOH, Software development at the Company level is all about Risk Management in the service of its Business Goals and hence needs a reproducible process and associated methodologies. We need to find a balance between the two.

[marxisttemp]

I agree that risk management is important for software companies, in the same way it is for construction companies, and part of that involves software engineers.

But I think pretty much any business has risk management processes that involve domain knowledge, and a much larger and more distinctive part of any kind of engineering involves non-business considerations and tradeoffs that AFAIK Boehm didn’t really concern himself with. For example, a civil engineer designing a bridge is thinking about wind shear, traffic volume, vehicle weight allowances, and so on, just as a software engineer is thinking about latency, throughput, error propagation, and so on. To me, these sort of non-business-logic but very much domain-specific considerations are what comprise the core of software engineering (as compared to programming, which I would classify as just getting the business logic correct without any meta-considerations).

This comment is poorly edited, but essentially Boehm’s processes to me are better described as “software business management” than “software engineering”.

[rramadass]

Agreed, though IMO "Software Engineering" subsumes everything. You are looking for a holistic and reproducible process which can be communicated using well defined methodologies.

One important point though; IMO Risk Management in the Software Industry is qualitatively different than that from other Industries. This is because of the greater play and importance of Human Factors involved and their cumulative non-linear effects. In very few other industries (eg. Finance) can you have a factor of 10x/100x productivity between the average and the best since it does not follow the normal distribution. If i have a Jeff Dean/John Carmack programming or a Steve Jobs salesmanship in my company i can break every engineering rule i want and still come out on top.

Nassim Taleb's ideas on Mediocristan/Extremistan, Power Laws/Fat Tails are all relevant here. Here is a great video explaining these concepts (though we have to adapt and apply it to Software Engineering) : Pareto, Power Laws, and Fat Tails - https://www.youtube.com/watch?v=Wcqt49dXtm8

[fuzzy2]

That's somewhat arbitrary, don't you think? I think of "programming" as just writing code, "engineering" is coming up with what to code.

Rather, this is about capitalism. You want more freedom in going about your business. You cannot have that in a profit-oriented company. (Rare exceptions apply.) We're so focused on delivering, what we deliver becomes less of a concern, even though it should be the number 1 concern. The rest follows.

[throwawayqqq11]

> Rather, this is about capitalism

Well, its about what you measure.

A solution oriented programmer can have the best business goals in mind by not half assing a hotfix but proposing a full new featue with large budget demands.

Some managers respect and care about good software but may need to compromise on budget cuts from higher up.

I have seen it so many times.