4 ms·
>Software engineering is what happens to programming when you add time and other programmers. To preface, I think there's room for a wide variety of meanings
by jasode 8y ago
>Software engineering is what happens to programming
when you add time and other programmers.
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.
[1] https://en.wikipedia.org/wiki/Turing_tarpit https://en.wikipedia.org/wiki/Turing_tarpit
- varikin 8y ago> If he responds that he can't think of anything negative, it means he can't do engineering with Go. 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.
- waisbrot 8y agoMy ability to talk at length about what's wrong with a language corresponds directly with how well I know and love the language.
- twothamendment 8y agoYes - or how well I know and hate the language.
- adrianratnapala 8y agoOnly C++. 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.
- deleted 8y ago[deleted]
- cdoxsey 8y agoIt's not a good interview question because it treats something ambiguous and subjective as if it has an obvious answer. Go is a general purpose programming language applicable to a wide variety of programming domains. 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.
- xtreme 8y agoI think the original question (what are some limitations of your favorite language) is similar to other questions that asks the interviewee to justify their choices. While I am not convinced it makes a great interview question, the ability to justify your choices with technical details is often a good indicator of how well/in-depth you know your craft. Often it doesn't matter what you choose, as long as you can show that you did the due diligence and articulate why you chose that.