|
The one that got me was "sandwich artist". Take a guess where I saw that position advertised.
|
|
|
|
|
Subway.
I'm still trying to find a way to use it as some sort of greeting when I walk in, and yet remain inconspicuous about it. But there's just no way of using it without sounding as dumb as, well, it sounds.
That, and the people Apple has working at their "genius bar". Makes me wish I could bring in a defective product, and watch them make the problem worse, just so I could sarcastically say "way to go, genius"...
Oh, and low-level employees that the higher-ups insist on calling "associates" so they somehow feel empowered. Wal-Mart's guilty of that. And given the type they employ, it only comes across as demeaning.
|
|
|
|
|
Yup, our local store had many of those positions available when the new store first opened in the town where I live.
Another common name was also advertising at the time for coffee related artistry and technical based positions...
I wonder how long it's going to be before we see adverts for "Burger & Fries Engineers..."
|
|
|
|
|
Carbohydrate and protein materials construction engineer?
|
|
|
|
|
🤣🤣🤣🤣🤣🤣🤣🤣🤣
Give them time.
|
|
|
|
|
800V crammed in a 20cm round box, it's FUN!
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
The shortest horror story: On Error Resume Next
|
|
|
|
|
charlieg wrote: 120v scares me, 240+ I want to pee. 480 and up? hell no.
LOL!!! I don't blame you for that. But since I design systems that transport power at 120V through 69kV, I've had to get used to it. But it's still strange to open a cabinet and realize that if I stand a few inches closer, an arc could form and kill me, not to mention dimming the lights for a bit.
Will Rogers never met me.
|
|
|
|
|
I will weigh in on both sides of this.
Engineering has a history of what emerged as accepted designs, formulas, and processes that generally produce safe, reliable products. Software can't make this claim, though I'd say that OO and patterns, in most settings, are an step in that direction. But systems are very diverse, so software remains far more craft and art than it does engineering.
On the other hand, much of my career (starting in 1981) was spent in a company whose products were becoming more and more dependent on software, and less so on hardware. Consequently, many EE types moved into software. Yes, they could do it, and most had a smattering of it in university, but few were or became good at it. I said it was like putting me in an EE role if my expertise was that I'd noodled around, building speakers in my basement.
One major difference, as I see it, is that the essence of software systems is evolution. Expecting a bridge to be lengthened by 30m as part of its "next release" would provoke derisive laughter, yet the equivalent is commonplace when working on software. How to deal with this is a central challenge.
|
|
|
|
|
I agree. What "triggered" me - in a humorous way - was the term Firewall Engineer. I'm still chuckling.
I think I would lean more toward an engineer having more solid foundations in the basic sciences - physics, thermo, etc. Having said that, I have NEVER seen an engineer including myself pound out code like some of the CompSci folks I've worked with. Looking at the code witch as an example. I've worked with a few others. The code springs from their fingers, and their minds work at a level that makes me dizzy.
There was a book a read long ago about Star Wars. Not the movie, but President Reagan's vision of strategic missile defense. One of the pillars of the concept was the space based X-Ray laser. This was a device that was nuclear bomb powered - you aimed the lasing rods at targets and detonated the weapon where upon the x-rays from the detonation were directed at targets. Now, there are treaties and all sorts of problems putting (more?) nuclear weapons in orbit, but the idea came from some Lawrence Livermore PhD (might have been CalTech, I forget) who had a blue sky moment.
He spent the next few days pounding out simulation code to validate his idea. The concept had such potential that they piggy backed it on an upcoming nuclear weapons test. Yes, at the time the US was still detonating weapons under ground (mainly to develop the data so that designs could be confidently simulated). As I recall, the test was not successful, it was wildly successful.
Anyway, I still want to know what a firewall engineer is 
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
It's a Wizard from Dungeons & Dragons that can cast the spell Fire Wall with precision.
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
Today there are so-called "engineering" students whose Bachelor's degree specialization is "Artificial Intelligence and Machine Learning". Am not exactly sure whether these students will be engineers when they come out with the degree.
And once this AI hullabaloo dies down, where can they be employed, employable?
|
|
|
|
|
Back in the early 80s (can't speak to much earlier or later since that is when I was in college) most of the major technical colleges (one of which I was attending) referred to their programming degrees as Software Engineering.
Why? Most likely because there were two camps, science and engineering, and you had to be in one or the other. The Computer Science side, which included both hardware and software, was much more abstract and theoretical and, at the time, tended not to produce people doing the actual work.
The disappearance of SE degrees in favor of CS degrees and the "developer" moniker came later as programming degrees proliferated. Probably because the other engineering programs derided software engineering as a degree for people who couldn't hack being "real" engineers so both sides felt the need for an amicable divorce.
Given what started happening at that time, I'm sure many of those newly minted SE's were crying all the way to the bank a few short years later.
|
|
|
|
|
charlieg wrote: "Senior Firewall Engineer."
sounds to me like a fancy bricklayer.
Also the apocryphal
Yesterday I couldn't spell Engineer. Today I are one!
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
charlieg wrote: "Senior Firewall Engineer."
So...an almost-retired brick layer?
|
|
|
|
|
Sometimes (most of the time) I am dense. I missed the joke. 
good morning
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
I've never been comfortable calling myself an engineer, but it's because I view programming as more of an art, a knack.
What I mean is with a system of any significant complexity things get complex rather than complicated in software, and the ability to repeat the project with a different set of developers is effectively nil.
Sure you can fulfill the same functional requirements, but the software will work entirely differently.
The electrical engineers I work with produce highly repeatable designs, for lack of a better way to express what I'm talking about.
And if I put a different team of engineers on the same project replicated twice, the results, while not identical, will be much more consistent between the two teams than they are with software.
That's not how I would define engineering though - like I don't want to commit a no true scotsman fallacy here. Rather, I'm trying to give an example where programming is more ... organic? messy? at the end of the day non-repeatable.
So among other reasons, that's why I'm uncomfortable with the term "software engineer", especially as it applies to me and the way I code.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
- "Programmer", "software developer" and "software engineer" are often lumped together and mean the same thing: a person who creates and modifies software. I don't have an issue with candidates describing themselves using any of these terms.
- Unlike software engineers, electrical, mechanical, civil, aeronautical and other types of engineers work with extremely well defined specifications. Experienced software engineers will design for extensibility and robustness (for example by building loosely coupled components) but this isn't guaranteed. Consequently, software often evolves in a manner that eventually causes it to become overly complicated and difficult or impossible to maintain, requiring The Great Rewrite.
- We software developers could learn a lot from the folks who engineered the modern day lightbulb. I can use a modern tri-light LED bulb in a 1960s lamp without worrying about compatibility. The tri-light feature may not work if the socket doesn't support it, but the lamp's operation will gracefully degrade to a simpler behavior. Granted, software is more complex, but you've gotta give credit to the designers of the light bulb and the machines that allow light bulbs to be manufactured, for designing for change.
/ravi
|
|
|
|
|
honest assessment. But the point of the post was - tongue in cheek - what is a firewall engineer. The general consensus is a brick layer  .
This is the lounge folks, you are failing me.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
charlieg wrote: his is the lounge folks, you are failing me.
Apologies! 
/ravi
|
|
|
|
|
You make an interesting point about the lightbulb.
Is your point that we need to design new systems so that they comfortably interface with old systems?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I was advocating designing software in a way that makes it easier to extend and change, when change is warranted. Some ways of achieving this is by modularity, maintaining separation of concerns, abstraction, loose coupling and encapsulation. While following these principles won't guarantee the software we build will be easy to extend and modify, not doing any of these things will almost certainly ensure that it will be difficult to extend the software.
cf: Bob Martin's story about the Sword C++ debugger.
Clean Code with Uncle Bob Episode 1[^]
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: not doing any of these things will almost certainly ensure that it will be difficult to extend the software.
While doing those things poorly will make it impossible and cost more just to maintain
|
|
|
|
|
jschell wrote: While doing those things poorly will make it impossible and cost more just to maintain
Doing anything poorly will make the software difficult and more costly to maintain.
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: Unlike software engineers, electrical, mechanical, civil, aeronautical and other types of engineers work with extremely well defined specifications.
Tell me you never worked for pharmaceutical, food safety, automotive, avionics, naval, trainlines and biomedical without telling it.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
The shortest horror story: On Error Resume Next
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
