What is Software Engineering?
research.swtch.com
research.swtch.com
I'm sure this kind of work does go on throughout the world, but not in 95% of the software that gets written. Just like how engineers aren't involved in 95% of construction jobs, except when writing some guidelines 20 years ago. Most programmers are plumbers and brickmakers building houses, not engineers designing skyscrapers.
"When Roman engineers built a bridge, they had to stand under it while the first legion marched across. If programmers today worked under similar ground rules, they might well find themselves getting much more interested in Ada !" — Robert Dewar, President Ada Core Technologies.
Conversely, most mechanical engineers don't end up designing a new production motor, they design a door handle.
To preface, I think there's room for a wide variety of meanings people assign to words and nobody has a monopoly on what "engineering" means. That said, I offer an alternative:
Software engineering = programming that accounts for real-world _constraints_ such as performance goals, technology limitations, monetary budgets.
Whether engineering a bridge or engineering a circuit board, they share a common theme of optimizing multiple constraints (materials, cost, maintenance, durability, etc).
An advantage of this view of engineering is that it can also be applied to solo programming. The single programmer weighs the tradeoffs to a possible solution.
The other concept of "add time and other programmers" that the blog author is talking about is also important but in my opinion, I'd prefer the industry find another catchy label for it. I've seen others call it "software factory design" instead of "software engineering". The "factory" of optimizing how multiple programmers work together is what books like Mythical Man Month, Peopleware, etc talk about.
To apply my concept of engineering (constraints) back to the Go language... let's say I interview a candidate and ask what his favorite language is and he says "Go". I then follow up and ask "Ok, Go is good. What is Go not good for?" If he responds that he can't think of anything negative, it means he can't do engineering with Go. Engineering means you know the stress weaknesses of concrete, or corrosion properties of steel, or the warts of programming languages. If the candidate then tries to answer with the universal "well, good and bad programming can be done in any language", that's just a restatement of the Turing Tarpit[1] and you can't do effective engineering with that view. Assembly, C/C++, Haskell, Lisp, Javascript all have weak points that work against particular engineering goals.
I have used this tactic for interviews for quite a while. Though working primarily with Java and the JVM, every good programmer already has a long list of complaints. Regardless of preferred languages, frameworks, etc, everyone should know when their tools are not sufficient. I never care what the answer is other than they are able to articulate an answer.
I simply don't know enough to make an intelligent argument about why, say, PHP is a bad idea. But I have used it, and I don't want to do it again.
So is Java.
Why choose one over the other? I could make an attempt at answering that, but a 2 minute elevator pitch won't do it justice at all.
The best you are going to get is the recounted, received wisdom. Is that wisdom accurate? Are we just selecting whatever flavor of the month opinion hacker news is espousing?
Much more I want a developer who can be productive in an existing codebase, regardless of the language. Someone who plays well with others, is willing to learn, to contribute, to compromise for the sake of the team, etc.
Same went with all senior programmers I worked with, they all said "I was a programmer for the longest time! Now I want to become a software engineer!" Just to come out of a certification course and asking "That's it?!"
I think the core ideas and principles are right, but after you learned what can be done with code, like infrastructure etc. you don't want to meddle around with stuff that is so far away from code as these methods. It just slows things down too much.
The only thing I really liked were class and call diagrams to find out what's going on in legacy codebases.
Semi-relevant: http://programming-motherfucker.com/
The whole viewpoint seems to just add a sort of high-handed argument from authority to your typical subjective arguments over programming features.
I think the useful questions are: Did your choices actually achieve your intent? And, in doing so, what new problems did you introduce? (You always introduce some new problems.)
One possible reason: import statements in source code can be analyzed regardless of which build system you're using. In the case of Go, there are at least two important build systems ("go build" and bazel), so analysis tools would need to support both.
On the other hand, if a package.json file were just as universally used as Go source code, it would effectively be part of the language.
It's like chemistry and chemical engineering. Chemistry is about atoms and molecules, and about chemical reactions. Chemical engineering is about building and running chemical plants that efficiently produce the desired chemicals without blowing up.
Though I guess that's the difference between computer science and software engineering, not between programming and software engineering. Maybe in the chemical analogy, programming is pipe-fitting in the chemical plant.
This means the software have to perform functions needed by its users, under real world constraints (time, space, power, cost) while being sufficiently robust to handle noisy inputs and variances. This also means the user will play a large role in driving the evolution and direction of the software and that the scope of software engineering encompassing beyond the theory but to the entire lifecycle of he software product including development, deployment, support, and iterative improvement.
That was quite empty article... what’s that? A sales pitch for the next article?
The only comment related to design was an implementation detail: the Go modules are git urls. Even at speaking an implementation the article fails: the article does not comment the pros, cons, consequences, problems or typical pitfalls, and evolution in time of this decision; it even does not compare with any other existing choices out there.
I believe these kind of articles should not be part of HN since it just aims to exploit the audience.
Edit: format
Hand a strong theoretical CS person a steaming pile of a project and ask for the smallest tweak and it will take forever - that is if their head doesn't explode or they decide to re-architect it. Task a good software engineer with the same thing and they will get the change done with the understanding that they also hate the steaming pile of a project, but it isn't worth any more time.