An employer of mine has a fairly large, quite complex desktop application, and I saw a support exchange that basically went like this:
user: "how do I do X & Y?"
support: "it was in your training, but fine, I'll show you"
internal: "have these users not absorbed even the basics of our training?...
I'm having a weird interaction with a customer this morning.
She emailed to tell me that something is labeled as New when it's not New anymore. I told her it's less than six months old so it's automatically labeled as New. She asked if she took the pub date out, would that make the New tag go away.
I am failing to understand why it matters that the product is labeled New.
My opinion of it is that if it is that important, then they need to clarify their business rules of marking things as New. We took the manual label away almost a year ago because it was applied inconsistently.
Almost randomly.
And left on until someone happened to notice it was there.
Some other engineers do, but from what I've seen, it tends to not be mass produced. Junior electrical and mechanical engineers may build the first article to ensure their designs work.
But most senior electrical and mechanical engineers support a manufacturing group and do design.
And prototyping. But prototyping is part of designing.
But you could take the stance that software engineers don't build the product. The compiler or interpreter builds the product.
That's the "source code is design" argument. There's no difference between a detailed drawing and specification that a mechanical or electrical engineer makes and hands to a manufacturing floor versus my source code that I hand to a compiler.
Following that argument is quite interesting, because the gap between that "bad" kind of "Software Engineering" (i.e. the one we associate with waterfall) and Agile suddenly becomes a lot smaller.
Not really. Actually, maybe. It does eliminate a whole step from the waterfall: coding.
You go from design to test. But there is still a difference in that you continuously build small pieces and test them versus completing your design and then testing it.
Software builders are interchangeable and only the designers are creative? Yeah, sure, if the designer is the programmer and the software builder is the compiler that makes sense!
It's a different set of words. People don't like changing words.
It also changes how you bid projects. PMs are used to seeing implementation == writing code. "Implementation" becomes "maintaining build processes", really.
Managing your CI environment, writing and updating build scripts...etc.
@Maitiu The practice of using only one return statement is due to several factors, such as memory management (in C) or alternate code flows (in FORTRAN). Nowadays it's not quite as much as an issue. In Java you can certainly have more than one return statement in a method. See this excellent Programmers.SE question. for more details. — Mage Xy55 secs ago
@ThomasOwens Given the analogy, it is fun to imagine a construction worker (the 'builder') building a house each time somebody living in it wants to use it :D
@Alfro But it doesn't make it a bad analogy. Software is different than hardware. However, if you look at the steps, there is a mapping. However, looking at coding at being the same as building is wrong. Compilation and interpretation are building. Coding is designing.
@Ixrec no, more like a change to our CI build system scripts (which I knew about), a change to some of the internal dependency vendoring, and non-backwards compatible version updates :P
Your question is off-topic for Stackoverflow. You might delete your question here and instead ask your question on our sister Programmers site. — markE19 secs ago
An employer of mine has a fairly large, quite complex desktop application, and I saw a support exchange that basically went like this:
user: "how do I do X & Y?"
support: "it was in your training, but fine, I'll show you"
internal: "have these users not absorbed even the basics of our training?...
The Whiteboard
The Whiteboard