6 ms·

After working in robotics for a few years, I came to the realization that people (applies especially to managers) don't recognize when they are bringing the wro

After working in robotics for a few years, I came to the realization that people (applies especially to managers) don't recognize when they are bringing the wrong instincts to a problem. If you come up through software, you develop one set of instincts, EE another, and ME yet another set of instincts. When making a decision, step one must be identifying the appropriate set of instincts to bring to the problem. Once upon a time I worked for a manager who could only bring software instincts to any problem. He was dismissive, even, of ME problems. But not every problem can be solved in two-week sprints and pushed over LTE to the fleet. (Actually, if you want a good start-up idea, find a way to push a field update to a 5 kilo aluminum casting over LTE -- I'd invest in that.) But here is the thing -- unless you can synchronize the release of software + electronics + mechanics, you don't have a robot. That means design, validation, component tracking, field updates, maintenance. You always need to take a step back and ask yourself what instincts to bring to a problem, and if you are weak in one/some of those areas, learn who's instincts you can trust and bring them in. I am presumptuous enough to believe this applies to IOT mechatronics as well as robots. (Actually robots need more than SW+EE+ME, but this rant is already long enough.)

dhosek 6y ago
This is one of the cool things about the Harvey Mudd College Engineering major. Rather than doing Mechanical Engineering, or Electrical Engineering or Cheese Engineering or whatever, you just do Engineering. Graduates leave with a full toolbox of skills. I kind of wish when I was an undergrad, I hadn't had such an aversion to practical knowledge (I started out majoring in Physics/English, then Math/English then dropped out of college to eventually get a BA in English).
- ascar 6y ago
  That might be a start, but higher education only scratches the surface of on-the-job skills in engineering. You learn the basic tools, the way of thinking and the skill of acquiring additional knowledge. You get near to zero experience on real engineering problems as encountered in business. So in the good case this degree might broaden your horizon and teaches you that you don't know enough and in the bad case it might make you overconfident in even more areas while having even less knowledge than from a more focused degree.
  - dhosek 6y ago
    The capstone of the engineering major is the engineering clinic project which has students working on “real engineering problems as encountered in business”. Companies pay the college to have teams of senior engineering majors solve a problem they face. Two of the sexier projects were Disneyland hired HMC to come up with an anti-collision system for autopia and West Dorm had a clinic team refurbish a beloved vintage pinball machine.
    - PascLeRasc 6y ago
      My university had a student club doing that and it's probably my fondest memory of engineering. It was so inspiring and almost addicting to work on projects that actual people would use or have their lives improved by. And you got to have a hand in writing firmware, machining parts/enclosures, meeting the customer (mostly doctors, which was super cool), and researching the market fit for if it were a real project. It was so much fun. I really wish my post-college engineering experience could be anything like that. I miss making useful things.
      - dhosek 6y ago
        My wife, after she finished her MS in Software Engineering, ended up in a job where one of her first tasks was writing DOS .BAT files. On the other hand, her first asp.net page was demonstrated by Steve Ballmer at CES, so she did advance in the world.
  - lmilcin 6y ago
    That's right. So I see a lot of mechatronics students that actually, instead of trying to develop all their skills, settle in either electronics or software development. Students should understand that what they learn at uni is as far from real world product development as possible. Uni does not have incompetent coworkers, unreasonable, conflicting or entirely missing requirements, scaling issues, vendors trying to screw you, procurement processes trying their best to prevent you from doing anything, faulty materials, etc. Knowing a bunch of mechanic formulas or software development patterns does not an engineer make.
dmytroi 6y ago
I like your use of the instinct concept, similar to experience/seniority yet very different.
- dbcurtis 6y ago
  I was pretty terse about my definition of instinct in my original post, because I thought the post had gone on long enough. But the idea I that am trying to get at is grounded in the concept that emotion and gut feel drive more decisions than we would like to admit, with logic applied to back-justify the decision. Then part two is that by the time someone has risen to the level of decision authority that SW/EE/ME are all answering up through their portfolio, they probably have baked in a lot of intuition about the branch they came up through. That intuition informs their decisions -- but may not be reliable outside of their comfort zone. Someone who came up through software intuitively knows that while "it is only a 3 line change in each of 4 files", making the change in master is only the beginning. Also on deck are: back-porting and validating in the 4 release branches still running on the 4 hardware versions in the field, and pushing the update reliably, oh, and it changes the log format so our log monitor query needs to be updated and validated. EE -- yes, it is just changing out one connector -- but we need the latching version and only two latching variants are available, and one requires moving a mounting hole which would require chassis rework, the other is expensive and has a 12 week lead time... and in any case we need to update the test fixtures. And we need to keep some of the old test fixtures around for the old rev, and while we could save some money by reworking some of our old test fixtures, who has time to write and validate the engineering change order for the test fixture rework? ME -- yes it is only moving two mounting holes, but both the chassis and the skins need to move, so we either have to rework the fleet to accept new skins, or do two sets of expensive tooling for the skins, or do some kludge adapter that allows new skins on old chassis, but we need to vibration test that. Intuition and instinct are about understanding the implications and the unarticulated risks buried with decisions.
accurrent 6y ago
I'm in robotics and I agree with this. ME people are 100 times more thorough in checking things are done correctly than EE or SWE. Its very hard to make changes in ME. Also people heavily underappreciated the difficulty of the field. From a SWE perspective, Robotics Engineers need to know physics and math than the average SWE learns. Interestingly almost all the successful robot projects I've worked on seem to follow a waterfall process. You keep working on it till it works. After its ready don;t change anything.
- ptx 6y ago
  > waterfall process ... keep working on it till it works I thought waterfall was to plan it out in detail, then do all the work according to the plan despite realizing that the plan is wrong, then finally, after disbanding the development team, test it to see if it works? That's obviously a caricature, but if you have the feedback loop to see if it works while you're working on it, you might also call it agile.
  - jki275 6y ago
    You’ve described waterfall accurately, but waterfall is kind of an anti-pattern. Nobody actually uses it.
    - lmilcin 6y ago
      You mean there are no places where managers tell their teams the scope and deadlines and then tell the team to go play "agile"?
      - jki275 6y ago
        That's not waterfall.
        lmilcin 6y ago
        From that point of view I would say no project is waterfall. In any sufficiently complicated project requirements MUST change over development if only for the fact it is not feasible to specify absolutely everything absolutely precisely before development starts.
lmilcin 6y ago
This is even worse with managers. Managers have whole lot of other problems to deal with and what they frequently fail to recognize is the need to separate areas where it is up to manager do act on their "instincts" (which I call experience) and where it is up to engineer to do their job. Unfortunately, the power assymetry between managers and engineers frequently manifests itself as you have described: -- managers trying to understand everything through the lens of their past experience, -- engineers trying to conform to managers (ie. using manager's language to formulate problems and solutions) -- managers dismissing/prioritizing down areas, ideas, problems that they are not familiar, promoting/prioritizing up where they feel they have good understanding, -- engineers responding by doing the same (ie. focusing on where they feel they will be rewarded by manager). -- managers hiring/promoting based on their assessment of the candidates/employee competency in the area of expertise of the manager, because it is easier to rate candidate/employee competency if it is in your area. -- managers failing to improve in areas where they are completely new. Maybe because people in general tend to want to improve in areas they already know. Maybe because they don't want to be seen as noobs making silly mistakes with experts around, and so trying shun entire area as less important so that the discussion can focus on where they are comfortable talking to experts. -- so on... So where a team works on a product that requires software/electronics/mechanics, the team, regardless of its initial composition, will over time get skewed in the area of expertise of its top manager. Same goes for startup -- duo of guys who know software and electronics will inevitably look for products in the areas they know best. Not being able to quickly rate how difficult something is, mechanically, is definitely scaring a lot of people away. I also noticed people dealing with software and electronics rarely mingle with mechanics/material experts which I think might also explain a little bit why there aren't too many enterprises that join those areas well.

dhosek 6y ago

This is one of the cool things about the Harvey Mudd College Engineering major. Rather than doing Mechanical Engineering, or Electrical Engineering or Cheese Engineering or whatever, you just do Engineering. Graduates leave with a full toolbox of skills. I kind of wish when I was an undergrad, I hadn't had such an aversion to practical knowledge (I started out majoring in Physics/English, then Math/English then dropped out of college to eventually get a BA in English).

ascar 6y ago
That might be a start, but higher education only scratches the surface of on-the-job skills in engineering. You learn the basic tools, the way of thinking and the skill of acquiring additional knowledge. You get near to zero experience on real engineering problems as encountered in business. So in the good case this degree might broaden your horizon and teaches you that you don't know enough and in the bad case it might make you overconfident in even more areas while having even less knowledge than from a more focused degree.
- dhosek 6y ago
  The capstone of the engineering major is the engineering clinic project which has students working on “real engineering problems as encountered in business”. Companies pay the college to have teams of senior engineering majors solve a problem they face. Two of the sexier projects were Disneyland hired HMC to come up with an anti-collision system for autopia and West Dorm had a clinic team refurbish a beloved vintage pinball machine.
  - PascLeRasc 6y ago
    My university had a student club doing that and it's probably my fondest memory of engineering. It was so inspiring and almost addicting to work on projects that actual people would use or have their lives improved by. And you got to have a hand in writing firmware, machining parts/enclosures, meeting the customer (mostly doctors, which was super cool), and researching the market fit for if it were a real project. It was so much fun. I really wish my post-college engineering experience could be anything like that. I miss making useful things.
    - dhosek 6y ago
      My wife, after she finished her MS in Software Engineering, ended up in a job where one of her first tasks was writing DOS .BAT files. On the other hand, her first asp.net page was demonstrated by Steve Ballmer at CES, so she did advance in the world.
- lmilcin 6y ago
  That's right. So I see a lot of mechatronics students that actually, instead of trying to develop all their skills, settle in either electronics or software development. Students should understand that what they learn at uni is as far from real world product development as possible. Uni does not have incompetent coworkers, unreasonable, conflicting or entirely missing requirements, scaling issues, vendors trying to screw you, procurement processes trying their best to prevent you from doing anything, faulty materials, etc. Knowing a bunch of mechanic formulas or software development patterns does not an engineer make.

dmytroi 6y ago

I like your use of the instinct concept, similar to experience/seniority yet very different.

dbcurtis 6y ago
I was pretty terse about my definition of instinct in my original post, because I thought the post had gone on long enough. But the idea I that am trying to get at is grounded in the concept that emotion and gut feel drive more decisions than we would like to admit, with logic applied to back-justify the decision. Then part two is that by the time someone has risen to the level of decision authority that SW/EE/ME are all answering up through their portfolio, they probably have baked in a lot of intuition about the branch they came up through. That intuition informs their decisions -- but may not be reliable outside of their comfort zone. Someone who came up through software intuitively knows that while "it is only a 3 line change in each of 4 files", making the change in master is only the beginning. Also on deck are: back-porting and validating in the 4 release branches still running on the 4 hardware versions in the field, and pushing the update reliably, oh, and it changes the log format so our log monitor query needs to be updated and validated. EE -- yes, it is just changing out one connector -- but we need the latching version and only two latching variants are available, and one requires moving a mounting hole which would require chassis rework, the other is expensive and has a 12 week lead time... and in any case we need to update the test fixtures. And we need to keep some of the old test fixtures around for the old rev, and while we could save some money by reworking some of our old test fixtures, who has time to write and validate the engineering change order for the test fixture rework? ME -- yes it is only moving two mounting holes, but both the chassis and the skins need to move, so we either have to rework the fleet to accept new skins, or do two sets of expensive tooling for the skins, or do some kludge adapter that allows new skins on old chassis, but we need to vibration test that. Intuition and instinct are about understanding the implications and the unarticulated risks buried with decisions.

accurrent 6y ago

I'm in robotics and I agree with this. ME people are 100 times more thorough in checking things are done correctly than EE or SWE. Its very hard to make changes in ME. Also people heavily underappreciated the difficulty of the field. From a SWE perspective, Robotics Engineers need to know physics and math than the average SWE learns. Interestingly almost all the successful robot projects I've worked on seem to follow a waterfall process. You keep working on it till it works. After its ready don;t change anything.

ptx 6y ago
> waterfall process ... keep working on it till it works I thought waterfall was to plan it out in detail, then do all the work according to the plan despite realizing that the plan is wrong, then finally, after disbanding the development team, test it to see if it works? That's obviously a caricature, but if you have the feedback loop to see if it works while you're working on it, you might also call it agile.
- jki275 6y ago
  You’ve described waterfall accurately, but waterfall is kind of an anti-pattern. Nobody actually uses it.
  - lmilcin 6y ago
    You mean there are no places where managers tell their teams the scope and deadlines and then tell the team to go play "agile"?
    - jki275 6y ago
      That's not waterfall.
      - lmilcin 6y ago
        From that point of view I would say no project is waterfall. In any sufficiently complicated project requirements MUST change over development if only for the fact it is not feasible to specify absolutely everything absolutely precisely before development starts.

lmilcin 6y ago

This is even worse with managers. Managers have whole lot of other problems to deal with and what they frequently fail to recognize is the need to separate areas where it is up to manager do act on their "instincts" (which I call experience) and where it is up to engineer to do their job. Unfortunately, the power assymetry between managers and engineers frequently manifests itself as you have described: -- managers trying to understand everything through the lens of their past experience, -- engineers trying to conform to managers (ie. using manager's language to formulate problems and solutions) -- managers dismissing/prioritizing down areas, ideas, problems that they are not familiar, promoting/prioritizing up where they feel they have good understanding, -- engineers responding by doing the same (ie. focusing on where they feel they will be rewarded by manager). -- managers hiring/promoting based on their assessment of the candidates/employee competency in the area of expertise of the manager, because it is easier to rate candidate/employee competency if it is in your area. -- managers failing to improve in areas where they are completely new. Maybe because people in general tend to want to improve in areas they already know. Maybe because they don't want to be seen as noobs making silly mistakes with experts around, and so trying shun entire area as less important so that the discussion can focus on where they are comfortable talking to experts. -- so on... So where a team works on a product that requires software/electronics/mechanics, the team, regardless of its initial composition, will over time get skewed in the area of expertise of its top manager. Same goes for startup -- duo of guys who know software and electronics will inevitably look for products in the areas they know best. Not being able to quickly rate how difficult something is, mechanically, is definitely scaring a lot of people away. I also noticed people dealing with software and electronics rarely mingle with mechanics/material experts which I think might also explain a little bit why there aren't too many enterprises that join those areas well.