Hacker News Reader

Comment by kenhwang | Hacker News Reader

I'm partial to the O-ring explanation. Software engineering is uniquely multiplicative because it's possible for a software engineer to create software that does software engineering.

Chemical/electrical/mechanical engineers can't use their field to automate their field. Doctors and lawyers are almost exclusively service jobs, unlike the manufacturing nature of engineering.

Automation is a force multiplier, and software engineering benefits from being able to create automation, apply automation to others, as well as being able to apply automation to itself.

View on HN

Chemical/electrical/mechanical engineers can't use their field to automate their field.

A mechanical engineer designing a new manufacturing technique or robot is most certainly using their field to automate their field. Most of computing exists because electronic engineers used their field to automate their field. Software is not unique in this respect.

Every field is working to automate their field with the help of software. For which you need software developers. The article raises the question of why people are hired as software developers even if they don't have such a degree. Its because companies see it as an automation problem and not as a software engineering problem. That is also why quality or experience of the developer is irrelevant most of the time, there is no one else to judge it, so if its working then its working.

Every field is working to automate their field with the help of software. For which you need software developers.

Right, but let's be clear about our terminology here. Automation in mechanical/manufacturing isn't being done by CS grads with skills in RoR employed as software developers. It's being done by MechEng graduates armed with FORTRAN compilers who write a lot of code but don't consider themselves to be developers at all.

A rose by any other name would smell as sweet.

How different is a MechEng writing FORTRAN for mechanical engineering from a MechEng writing RoR for trendy widget bean button SV startup?

I'd argue they're both programming, which is sufficient to reap some of the benefits of automation. Software engineering can be described as applying engineering to programming. Any company that benefits from programming would also benefit from the increases in efficiency, reliability, performance, etc. software engineering would bring to programming.

How different is a MechEng writing FORTRAN for mechanical engineering from a MechEng writing RoR for trendy widget bean button SV startup

Because in scenario A the main skill being applied is mechanical engineering and in scenario B the main skill being applied is RoR.

If everyone who ever writes a line of code is a "software developer" would you include an Excel VBA 10-liner writer? Probably not, and nor would that person include themselves, they're an accountant (or whatever).

I don’t typically think of web developers as software engineers.

I think of work like FFTW and the Tensor Algebra COmpiler (TACO) as software engineering.

Whereas when I say "software engineering" I am referring to formal methods, or software components of engineered systems e.g. avionics. Nevertheless - the point is that lots of professions automate themselves. Now that I think about it even a doctor who invents a more effective treatment lessening the workload of other doctors is using medicine to automate medicine.

Not in the same way, or in the same ball park.

Mechanical engineering didn't have its Lisp. We do.

Mechanical engineering didn't have its Lisp. We do

The steam engine was more of a productivity multiplier than Lisp could ever dream of.

Steam engine unfortunately can't make itself. So.

You most certainly can use a steam engine to make it possible to make a bigger steam engine by driving machine tools. So.

Stream engine can't modify itself. Sorry. Somebody using tool A to create tool B, isn't what we are discussing here.

Tool A should modify itself to become Tool B. And Tool B should modify itself to become Tool C and so on...

Modify itself? OK, I will grant you that there are no sentient, self-aware steam engines.

> Software engineering is uniquely multiplicative because it's possible for a software engineer to create software that does software engineering.

I think you misunderstood the O-ring explanation by citing that idea as an example. It doesn't mean building AI. It applies to any of those fields you mentioned. Good people in field X work together with other good people in field X in top firms -> multiplicative productivity.

Who said anything about AI?

Most people would consider software that "does software engineering" AI.

A compiler is software that does software engineering. Saves a lot of time and effort.

Package managers, that used to be hard to do by hand.

Bundlers and linkers, that stuff used to need skilled engineers.

Many other examples

This feels like it could quickly descend in to self congratulation. So to cast this in a different light perhaps another way to think about this is that programming is just becoming a basic skill, like reading, writing, basic mathematics required for all disciplines.

Most dedicated software engineers exist because this new basic skill hasn’t yet gained widespread adoption as a basic skill in other disciplines. But with time it will, and the number of dedicated software engineers required will decline.

It takes a child several years in full-time education to learn how to fluently read and write. Basic mathematics takes even longer. Similarly, a typical person will become a skilled and highly productive software engineer only through spending several years working full-time at the profession, ideally with the assistance of one or more mentors. Having only a basic grasp of the concepts behind programming does not enable anyone to achieve anything particularly useful, and someone working in a different profession will not have the time or energy to acquire the skills needed to roll their own applications, unless they're an unusually dedicated hobbyist.

> Similarly, a typical person will become a skilled and highly productive software engineer only through spending several years working full-time at the profession, ideally with the assistance of one or more mentors. Having only a basic grasp of the concepts behind programming does not enable anyone to achieve anything particularly useful [...]

You can create basic good looking iOS or web or android app without all those years and be extremely useful. Many jobs and positions don't require years of study with mentors. Many self taught programmers started like that.

You can do basic data analytics and write selects without years or study too.

There is huge amount of positions that don't require years of study.

You can. Others cannot. I think you vastly overestimate the number of people capable of doing that.

> You can create basic good looking iOS or web or android app without all those years and be extremely useful.

We obviously have differing definitions of the word 'useful'.

Several years ago I worked in ad ops for one of the biggest publishers on the internet, making a bunch of ad placements by hand using Dart for Publishers, which was a dreadful product. I also was taking a night course in Java mostly for fun. At that point I didn't even know what functional programming, Big-O notation, or any of your other highfalutin' CS stuff was.

All of the company's ads (thousands of different line items at any given time) had been entered by hand in to Dart. Things like "make every add weight-based-bulk with weight 100", etc.

I wrote a craptacular Java app using Swing and the Dart API to get a handle on them. I mean - this thing was AWFUL. "Paste your username and password in to this box and type the name of the site you want to work with in that box and click something in this row of 14 buttons" level stuff. They used it to fix their waterfall.

The first month it was an extra 80 grand or so in revenue. The next month I had a new job.

This is based on what I learned in a few months of tinkering as a kid, and a few months of a Java course at Ohlone College in the east bay.

Perhaps you can provide your own, more helpful, definition of useful? Most of what's "useful" is taking something that was a pile of godawful spreadsheets and making it manageable; not something meant for consumers.

Doesn't your anecdote actually support my primary point, which is that a programmer with limited knowledge and experience will typically produce poor-quality software? (Or, to use your own terms, apps that are craptacular and awful?)

An application, in my mind, is truly useful when it not only fulfils a user requirement, but is also dependable, scaleable and maintainable. It's not best practice for a business to base a process around some jury rigged POS that will be thrown away in horror when an experienced developer eventually gets a look at it.

But hey, we can agree to differ on this.

Eh, it was dependable enough to make money. It scaled to the task at hand. It was maintained longer than the Dart API was since Google retired it months later.

"It's not best practice for a business to base a process around some jury rigged POS "

I suspect you'll find plenty of businesses jury-rig a POS first, and then only fix what needs fixing. Turns out most stuff doesn't need it.

For most companies, craptacular software is heaps better than what they already have (nothing). The point is, any newbie with ~3 months of training can write a non-beautiful non-scalable, line of business program that produces measurable value.

He produced useful, if poor quality, software. It did helped at a time and when it cease to be useful, it is small enough to be completely replaced with something else (instead of maintained).

It is ok to throw away things and not everything needs to be scalable.

It is also not best practice to base everything on the idea that everybody must be experienced senior to do anything. Many tasks are suitable for inexperienced juniors, because that is enough and it is small enough to throw it away if it goes bad.

The things that were most useful for people I worked for were not the things that were most difficult to create.

There is only one definition of the word “useful” that applies across the entire field: one whose output generates revenue for the company.

Defined as "able to be used for a practical purpose". Yes, companies need those apps and web pages and what not. They also need data analytics and what not.

> Having only a basic grasp of the concepts behind programming does not enable anyone to achieve anything particularly useful

This is absolutely untrue.

There are many many jobs that are effective people doing data analysis in excel spreadsheets.

The people doing this data analysis by hand can greatly improve their ability to do their jobs through simple things like learning how excel macros work. This is programming!

There are tons of low handing fruit in the world, where basic tasks that are being done by hand, could easily be automated by the people doing it, through very simple, easy, "toy" solutions.

I don’t see the equivalence. Yes, the skill you listed take some time to acquire. But few master them to a professional level, yet still use them regularly in their jobs.

I think programming is on the same trajectory. We might not even recognize many of the tools as “programming” (they might look more like spreadsheets). But I think general up take of programming skill will increase.

> Yes, the skill you listed take some time to acquire. But few master them to a professional level

So you're contending that few people can fluently read or write their own native language?

I’m saying that few people write as their sole occupation (novelists, maybe journalists etc). Others use it as part of their professional work, but it is not their sole professional work.

Similarly I’m suggesting software engineering will be part of many people’s professional work, but will be the sole professional work of few.

For programming you need at least someone who has no problems with algebra, that's a bit above the basic maths. I say that not because you will need algebra for programming but because you must be capable of manipulating abstractions.

Yeah, but the questions is if creating tools (software that does software engineering) is so complex that only a few developers can do it well? Otherwise this tool creation would still be subject to market prices just as regular development.

You are looking at differences between developers, but try pretending for a while that they are all the same, moderately qualified to adapt to any environment. I'm pretty sure that you would still see roughly the same distribution, since all environments are not created equal, and neither are the different positions inside those environments.

The stagnant bog of billing hours to captive (e.g. internal) customers for example does not lend itself very well to a toolmaking microsingularity. Bimodality of pay is at least as much about the task as it about the one one executing.

There is of course still a lot of correlation between ability and high value positions, but that's a natural consequence of matchmaking: both high value positions and high value developers get disproportional choice relative to their lesser peers.

I am too, and it seems testable, at least for large companies. Are the salaries bimodal within companies or not? If not, then the hypothesis would seem to hold water.

Reply on news.ycombinator.com