9

I work with someone who insists that any good software engineer can develop in any software technology, and experience in a particular technology doesn't matter to building good software. His analogy was that you don't have to have knowledge of the product being built to know how to build an assembly line that manufactures said product.

In a way it's a compliment to be viewed with an eye such that "if you're good, you're good at everything", but in a way it also trivializes the profession, as in "Codemonkey, go sling code". Without experience in certain software frameworks, you can get in trouble fast, and that's important.

I tried explaining this, but he didn't buy it. Any different views or thoughts on this to help explain that my experience in one thing, doesn't translate to all things?

gnat
  • 21,213
  • 29
  • 113
  • 291
Spencer Kormos
  • 745
  • 7
    If you're going to downvote, could you at least comment as to why? Particularly since your input could help rephrase / refocus the question. – Spencer Kormos Apr 13 '12 at 13:44
  • 11
    first off this is a rant and not a question, and second it is a flawed assumption rant, this needs to be voted down and closed. –  Apr 13 '12 at 13:54
  • Well, it is a question: how do you explain things about the programming field to people who don't know about it. – Marcin Apr 13 '12 at 14:02
  • 6
    @JarrodRoberson There is a legitimate question here I think. It is asking for a good explanation that asks for an explanation of why some view software engineering as more or less specialized than other engineering fields. – maple_shaft Apr 13 '12 at 14:05
  • @Marcin Thats a different question entirely ;) – maple_shaft Apr 13 '12 at 14:17
  • @maple_shaft No it isn't. It's almost exactly the question asked here. – Marcin Apr 13 '12 at 14:18
  • @maple_shaft how could confronting a fuzzy analogy be a legitimate question here escapes me "...you don't have to have knowledge of the product being built to know how to build an assembly line that manufactures said product" – gnat Apr 13 '12 at 14:29
  • @gnat So, you think this question is really about production engineering? – Marcin Apr 13 '12 at 14:33
  • 2
    @gnat I explained my opinion on this however it is probably a moot point because it already has 4 close votes meaning the community disagrees with me. The Community Speaks! :) – maple_shaft Apr 13 '12 at 14:38
  • 3
    @Marcin I think this question is really about confronting a fuzzy analogy. - Software engineering is like manufacturing! - No, it's like an art! - No, it's like a craft! - No, all of you are wrong, it's like a virgin! – gnat Apr 13 '12 at 14:54
  • 3
    The community seems to be capricious and arbitrary on closing questions that relate to the profession. Though if someone pointed me to the FAQ, I probably would've withdrawn the question myself. – Spencer Kormos Apr 13 '12 at 15:04
  • @SpencerK: FWIW, there are now votes to re-open, so at least some people think this question was worthwhile... – FrustratedWithFormsDesigner Apr 13 '12 at 15:11
  • 7
    @SpencerK You question is "some random dude made a bad analogy, how do I respond", and well, that's not really a question. Just ask for solid evidence and / or references that support his position, you aren't the one who needs to prove themselves here. – yannis Apr 13 '12 at 15:16
  • 3
    I'd probably make similar analogies about, "Do any medical doctor handle any medical issue?" or "Does any chef cook every possible kind of dish on the planet?" which may be met with a, "Well, no..." kind of response though I'd wonder if the co-worker understands how complex software can be. – JB King Apr 13 '12 at 15:41
  • There is no software engineer certification, so yes, you may go work on any type of project in any language you wish. – JeffO Apr 13 '12 at 17:17
  • 5
    -1 because I disagree with your premise. Software Engineering is no more specialized than other engineering fields. They can both be highly specialized *and* generalized. A good electro-mechanical engineer may not be a good biomedical engineer. On the other hand, a good electrician might work on both houses and cars. – zzzzBov Apr 13 '12 at 17:48
  • 1
    I'm with @zzzzBov here. I know a "mechanical engineer" who has twenty-five years experience diagnosing and fixing vibrations in pumping systems handing multi-phasic flows such slurries (think the pulp handling systems in paper mills, coal sulrries, drilling mud mixtures and so on). Are you suggesting that a this is not highly specialized? – dmckee --- ex-moderator kitten Apr 13 '12 at 18:33
  • @zzzzBov And would you hire your house electrician to pull apart your car to see why the windshield wipers won't turn on, because you've engaged the cigarette lighter? If it were a Jaguar, would you take it to a Honda mechanic? I'm sure they both could eventually figure out your problem, but at what cost? I've mentioned in another comment to an answer, that it's about ROI. If you understand fundamental concepts you can attack anything with time. But you can't just blindly write a WinForms app, just cause you're a wiz in Swing. – Spencer Kormos Apr 13 '12 at 18:38
  • 2
    @SpencerK, your title implies "software engineering is more specialized than other engineering fields" I am saying that neither is more specialized than the other. You can hire a specialist, or you can hire a generalist. As anecdotal evidence: I've got an IT friend who built his own hand-held device out of a SNES, I can go to him for advice on wiring an outlet, or speakers in my car. I wouldn't go to him for advice about building a pacemaker. One can certainly learn WinForms in addition to learning Swing, you just might not be a specialist in either. – zzzzBov Apr 13 '12 at 18:47
  • 2
    The comments for this question are a dead giveaway that it is a flawed, non-constructive question. There is no answer. It should have been left closed a long time ago. – Eric King Apr 13 '12 at 20:33
  • 1
    Nice to see that a mod took the decision that the community was wrong to vote to reopen this question. This question - it's just too dangerous for us. – Marcin Apr 14 '12 at 07:11
  • You need a lot of specialised knowledge to build an assembly line. – gnasher729 Apr 19 '16 at 14:50

12 Answers12

23

but in a way it also trivializes the profession, as in "Codemonkey, go sling code".

I would argue quite the opposite. A good software engineer would have the ability to conceptualize, architect, and design quality software agnostic of technology. The opposite end of this spectrum is the .NET or Java or PHP only "codemonkey" that is good at being given direction or specifications and utilizing the tool to implement the software.

A software engineer doesn't need to be a master of all tools, but should have a pretty good high level understanding about what the majority of them are, what they bring to the table, and what will likely be most appropriate for the given project. I would expect a code monkey to only be a master of their proclaimed expertise in a specific tool.

I wouldn't trust a Ford engineer that doesn't know how to do the Mechanic's job.

Still though, software engineering is one of these fields where in many cases we are expected to be the Engineer, the Builder, and the Mechanic all at the same time.

maple_shaft
  • 26,511
  • 11
  • 57
  • 132
  • 8
    I would also stress the importance of understanding concepts and principles over languages and tools. – Oded Apr 13 '12 at 13:51
  • +1 One of my pet peeves are the people who say "I'm a C# developer...". And then just drink the kool-aid and accept anything from MS as gospel. 10 years of programming I've learned over 11 programming languages, and each one has made massive improvements in how I program in the other languages. Learn software engineering! Not platforms that will be gone in 2 years. – Timothy Baldridge Apr 13 '12 at 17:24
  • +1 for Ford Engineer reference. I haven't thought about Software Engineers vs Programmers in that way before. –  Apr 13 '12 at 18:43
  • A programmer is a subset of an engineer, not the other way around. – Spencer Rathbun Apr 13 '12 at 19:23
12

I agree to an extent with the person you work with. A good software engineer deals with general principles of design and software production. The actual languages and frameworks are details.

That's not to trivialise the ease with which you can pick up new languages and frameworks. There's always a learning curve associated with them but the point is it is a curve, not a vertical wall to a good software engineer.

A good software engineer has a wide range of experience in a number of different tools and technologies. If he doesn't, how can he pick the best tool for the job? To wheel out the old cliche, to a man who knows how to use a hammer, every problem looks like a nail. Even if you are not an expert with a screwdriver, it pays to have a passing understanding of them so you can recognise a screw as not just a funny looking nail.

JeremyP
  • 418
  • 4
  • 7
  • " A good software engineer deals with general principles of design and software production." Producing embedded control systems and web application are almost exactly the same, right? – Marcin Apr 13 '12 at 14:36
  • @Marcin: Some of the principles are, yes. The poitn I was making is that (for example) designing an embedded system in C or assembler employs the same sorts of principles even though the tools are different. – JeremyP Apr 13 '12 at 14:42
  • Those tools are not that different, and they address very similar problem domains. This is why this is entirely unhelpful. – Marcin Apr 13 '12 at 15:37
  • 1
    @Marcin: you have obviously either not programmed in assembler or not programmed in C. I assure you that despite the common myth, C is not assembler and programming in those tools is as different as (say) programming in C and Ruby. – JeremyP Apr 13 '12 at 15:47
  • Hardly. In both cases, you are mostly frobnicating memory locations. Sure, C is a higher-level way of doing that, but it still targets the same problem domain. I take it from your answer that you haven't done much other than programme in C and assembler. – Marcin Apr 13 '12 at 15:54
  • @Marcin: I have programmed in a large number of different languages and I can tell you for a fact that C is not assembler. I'm amused that you think all embedded programming is merely "frobnicating" memory locations. – JeremyP Apr 13 '12 at 16:01
  • I never said that C is assembler. The point I am making is that both C and assembler target the same problem domain. And yes, as far as I can tell all embedded programming seems to involve calculations and setting memory locations. – Marcin Apr 13 '12 at 16:04
  • 1
    @Marcin, sure, and bowling is just a matter of knocking down all the pins. Piece of cake really. While web programming and embedded programming may share some high-level principles and best practices, what really governs the day-to-day work are the constraints that govern the implementation of those practices. While you may eventually be able to retrain a web programmer as and embedded engineer and visa versa, they are not fungible. – Charles E. Grant Apr 13 '12 at 18:25
  • @CharlesE.Grant Yes, that's what I said in my answer. You should probably vote it up. – Marcin Apr 13 '12 at 18:31
5

TLDR version: Other engineering disciplines need knowledge of the materials they are using (e.g. architects need to know how much load the materials they are using in their design can bear). The languages and frameworks we use for software engineering have certain limits and we need to be familiar with them to design and develop effectively against them.

There are two distinct phases to what we do. The first is conceptual design. That is high-level and low-level system design (e.g. using UML). High-level designs can theoretically be implementation agnostic (although sometimes a High-level design has to take into account specifics like, database platform, off the shelf middleware, etc.). Low-level designs are a bit trickier. You can design the specifics of the business logic without putting the infrastructure details into them and again, these can theoretically be platform agnostic.

The second phase is actual programming. While some view programming as construction, others (including me) argue that coding is still a design discipline (in PPP, Bob Martin refers to an article where the author puts forward a very good argument to this effect, I don't have it with me now, but I'll update this answer with a link to that article). The actual construction happens when you hit compile and is in effect free.

Just like an architect has to take into account things like tensile and compressive strength of the building materials he is using, so does a software engineer have to know the capabilities of the platform they are developing against when writing code. I would argue that a low-level system design is not very effective if it doesn't take into account the platform choices as well.

Michael Brown
  • 21,752
  • 3
  • 47
  • 83
5

As someone who graduated from a Software Engineering degree program, I can say that your coworker is partially correct. A good software engineer focuses on applying mathematics, statistics, computer science, and domain experience in order to build a system. The methods that a software engineer uses are typically technology and language agnostic - the tools don't matter as much as the underlying principles.

That said, your coworker's analogy is flawed. Understanding the domain problems are essential to any engineering discipline. If you don't fully understand the problem that you are trying to solve and the people that you are attempting to satisfy, it becomes infinitely more difficult to build the best possible solution to their problems.

Ultimately, software engineering (and any engineering discipline) is about applying a number of concepts to solve a problem. If you frequently use the same tools, you'll become more proficient with those tools. It will be easier for you to identify problems that those tools can solve, the risks or pitfalls with using those tools, and then using those tools to construct a solution.

Thomas Owens
  • 82,739
  • The underlying principles can vary enormously. – Marcin Apr 13 '12 at 14:26
  • 1
    @Marcin No, they don't. Computer science doesn't change if technologies changes. Mathematics doesn't change. Statistics doesn't change. Neither do requirements analysis, system design, configuration management practices, verification and validation strategies, quality principles... – Thomas Owens Apr 13 '12 at 16:16
  • Actually, "requirements analysis, system design, configuration management practices, verification and validation strategies, quality principles" do all change between problem domains. If you don't recognise that, then you are likely to do a very, very poor job working in a domain you don't know, because you are too arrogant to realise what you don't know. Also, the applicable mathematics changes rather a lot, but I bet you imagine you know everything about mathematics too. – Marcin Apr 13 '12 at 16:22
  • @Marcin I've worked in everything from embedded systems to web applications. They don't change that much. The qualities of a good requirement don't change based on the domain. The tools used for designing a system don't change. How you measure and achieve high quality systems don't change. – Thomas Owens Apr 13 '12 at 17:39
  • "How you measure and achieve high quality systems don't [sic] change." Yes it does, it changes enormously, unless you consider things at such a high level as to be vacuous. – Marcin Apr 13 '12 at 17:43
  • @Marcin I'm sorry, but quality measures don't change. All systems can be measured based on complexity, defects, uptime, performance (time, memory usage, disk space), code readability, test coverage. As a software process engineer, one of my jobs is to measure and monitor the quality of systems, and I use the same tools to measure and monitor quality. – Thomas Owens Apr 13 '12 at 17:54
  • 1
    Yes, you're right, every software project in the world is the same, and you have figured out how to manage every single project. You should probably write a book explaining the One True Way to write and manage all software. – Marcin Apr 13 '12 at 18:21
4

His analogy was that you don't have to have knowledge of the product being built to know how to build an assembly line that manufactures said product.

This is almost certainly incorrect. Specialist production engineers do need to understand quite a lot about the products under their care.

In any case, a better analogy is with graduates of mechanical engineering courses: even though everyone starts off (in both mech and software) with much the same skils, no-one remains "a mechanical engineer", but instead specialises in the types of things they build. Likewise, software development also has very distinct subfields.

To return to the assembly line analogy, every assembly line is different for each product, and different types of software development require different methodologies - you wouldn't build your security software the same way that you build a game.

Marcin
  • 498
  • 1
    software construction at the same level is the same regardless of the software product. We just call them methodologies instead of assembly lines, but they are conceptually the same thing. –  Apr 13 '12 at 13:59
  • 1
    @JarrodRoberson No. Assembly lines are not uniform, and methodologies are not generally applicable. – Marcin Apr 13 '12 at 14:01
  • 2
    I agree with Marcin, you do have to have knowledge of a product in order to put together an assembly line for the product. You have to be able to accurately select the tools to be used to get the correct end result. In software a methodology would be a specific tool or task. If your one task is to complete a specific task you may not need knowledge of the whole. But then you're an operator and not an engineer. Selecting the correct set of methodologies to form the assembly line makes you an engineer just like other engineering. Its no more specialized or different. – RJay75 Apr 13 '12 at 14:15
2

There is a learning curve involved with different specializations. I'm talking about differences between Embedded/Real-time programming, Web-App programming, Systems/OS programming, Thick-client programming, Mobile development, etc.

Someone who is an expert in one type of programming might not able to cross over into another right away because of different requirements. Sure, a software engineer has the basics to do so, but it takes time to specialize in something.

Atif
  • 915
  • 1
  • 6
  • 12
1

I agree with the premise your colleague suggests although I would add a caveat.

A good software engineer will be able to build good software in any tech..... after they have done a bit of learning in the new tech.

There might be some quirks that are not obvious at first, but a good software engineer will soon learn them.

I think what he really means is that just because a developer has 2 years solid C# experience, it doesn't mean a better software engineer with a Java background, who has never done C# before couldn't come along, learn C#, and quickly become a better C# developer than the first guy.

In other words, you shouldn't necessarily discount the Java guy for a job, JUST because he has "done the time" in C#.

ozz
  • 8,322
  • 2
  • 30
  • 62
  • I think this is a given, but it's really about ROI. I wouldn't hire an engineer with primary Java experience, if I want to get a C++ project out the door in 6 mos. Though, if you have a Swing project that needs to get out in 6 mos, a primary server-side engineer might still qualify. – Spencer Kormos Apr 13 '12 at 14:09
  • @SpencerK absolutely agree. It depends how quickly you need your ROI. If you have a longer period to wait, then the better software engineer should "win". – ozz Apr 13 '12 at 14:39
  • Also, harsh minus if it was you! – ozz Apr 13 '12 at 14:39
  • 1
    Nope, not me. I don't downvote without comment as to why. I have better manners than that! – Spencer Kormos Apr 13 '12 at 14:50
1

I work for a helicopter company and the aviation engineers here are specialised by the types of aircraft they can work with. They need to be "type rated". Technically they could work on anything from a Robinson R22 to a Jumbo Jet, but not without the conversion training.

I think this is pretty similar to software engineering except that the "conversion training" is more informal for software engineers.

Jaydee
  • 2,667
  • 1
  • 19
  • 17
1

Case in point: the software framework which you feel is so critical to have specialized experience with likely did not exist 10 years ago, or has undergone significant transformation if it did. The very nature of our profession makes it impossible to specialize for the entirety of one's career. Depending on your respective skill levels, your specialization gives you an advantage for somewhere between 1 and 6 months over someone who has never used your particular framework. After that, you are on par.

Karl Bielefeldt
  • 147,435
  • 2
    Really? I take it you would expect a security engineer to be up and coding games in 6 months, and be indistinguishable from an experienced specialist. – Marcin Apr 13 '12 at 14:34
  • I agree with Marcin, it is not only the knowledge of a programming language or platform. I have worked in two different areas and spent a few years in each of them: it takes a while until you are familiar enough to be really professional and productive in one area. Of course, being an experienced software specialist speeds things up, but I would reckon 2, 3 years rather than 6 months. – Giorgio Apr 13 '12 at 18:09
1

When talking to a painter, would you tell him he'd have no problems with sculpting?

Learning a new language or specifics to a new domain is similar to an artist who primarily deals with pencil and ink, learning how to paint (or vice-versa). This is what most of the other answers are talking about, how your friend is partially correct - a lot of the same concepts apply.

But teaching a painter how to sculpt a 3D object, or write a novel (Both forms of artistic expression) is a different beast entirely. That's the viewpoint you're coming from.

Web-based software requires an entirely different type of thinking than desktop software. Both are completely different when applied to games versus a work environment. I suspect working on an OS or integrated systems also require thinking a different way (but I have no experience with them). And I have no doubt there are other domains that also require a different way of thinking.

Summary and examples:

"Art" includes sculptures, novels, comics, and paintings. Skill overlaps include:

  • Body form and color theory: Sculptures, comics, and paintings
  • Textual communication: Novels and comics

... And so on. But as mentioned above, a comic artist is unlikely to do well on their first novel. They need to think differently.

Likewise, there is overlap in different fields of programming/software engineering, but most of them are too distinct to be able to just jump in. For example:

  • Algorithms: OS/integrated systems, games, and other places you often need to optimize for speed or memory. Rarely a big deal in web development
  • Design: Everywhere in web development, but not very important in integrated systems without a UI.
  • Client/server software: The "don't trust the client" mentality, which doesn't necessarily exist in some domains (single-player games and other standalone desktop software, which I admit is rarer these days).
Izkata
  • 6,098
  • I've always argued that programming and software design is as much an art as it is science or engineering. I guess this is another example of how they're similar. – Izkata Apr 13 '12 at 17:10
  • Oh, and before someone bites me for it, by "Algorithms", I'm talking about the high-level CS-y ones. Fibonacci heaps and Timsort are two that pop into mind. (I almost never work at that level of algorithmic complexity, so I know little about that topic at all) – Izkata Apr 13 '12 at 17:58
0

Are all road construction workers able to use every piece of equipment and machinery on the job site? The answer is no. There are pieces of machinery that they know and are likely familiar with the others. The same should be true for software engineers, there x number of languages and frameworks you know because you work with them everyday, but shouldn't be expected to know the exact operations of others without some training. Its like taking the jackhammer worker and assigning him the task of driving the cement mixer.

Programming languages and frameworks are just tools in a software engineers tool belt. There are some tools which you will know better than others because of experience. Ultimately, the best tool is the understanding the core concepts and principles of computing. Picking languages and frameworks is just selecting which screwdriver to use on which screw.

Colin D
  • 125
  • 2
    This is a bad analogy, they are talking about engineering, not construction workers, even though they mix the metaphors in the question. To that end all civil engineers that build roads are expected to be able to build any kind of road! Just as any dump truck driver hauling the asphalt to said construction site should be able to drive any kind of dump truck. –  Apr 13 '12 at 13:56
  • 1
    @JarrodRoberson I agree that it's a poor analogy, but I'm not sure your civil engineer assertion is any better. Sure, any civil engineer should be able to read the plans for any road. But if you're building a runway or an ice road, do you want to hire someone who's spent years building highways, or do you want someone who has specific experience with runways or ice roads? – Caleb Apr 13 '12 at 14:40
0

This sort of thing happens a lot where I work.

I like to compare to my wife's uncle's profession - a car mechanic.

He specializes in Mercedes, he can apply his knowledge to other makes of cars, and he does - some of them rather rare, but that doesn't mean that he can immediately repair make X because you say it's making a noise.

I program in a few languages, but that doesn't mean I know why Safari on your MacBook reloads pages every time you change tab (today's weird call). I'll try and figure out why but I'm not going to know off the top of my head because the computing field is HUGE.

In both cases after spending some time looking into our respective fields we could probably work out the answer but not in the ten seconds that people think because "but you work with cars" or "but you work with computers".

Do people say such things to their local doctor (such as "I have a headache what disease do I have?") - I bet they do because most people really don't understand that there is more to any one profession than their immediate expectations of said profession.

Reuben Mallaby
  • 101