7 ms·

Software engineers are not (and should not be) technicians

65 points by dahlia 2y ago

mintaka5 2y ago
[dead]
Smaug123 2y ago
The SREs have the word "toil" for work-that-has-the-technician-nature. Relevant page of the SRE book is https://sre.google/sre-book/eliminating-toil/ https://sre.google/sre-book/eliminating-toil/ .
constantcrying 2y ago
I like the distinction between technician and engineering. So much of software development is just technician work and has nothing at all to do with engineering. Unlike other countries in the US you can call yourself an engineer as a job description without any restrictions, so far too many people have taken on that job description, even if it does not make any sense.
- ghaff 2y ago
  I think there is a distinction in general. On the other hand, as someone with degrees in other areas of engineering, I also think there can be too much emphasis placed on the degree to which those other areas of engineering apply formal process and rigorous practices to everything they do. Yes, there are established codes for structural analysis and the like but there's still also a lot of seat of the pants.
- readingnews 2y ago
  ≥≥ Unlike other countries in the US you can call yourself an engineer as a job description without any restrictions, so far too many people have taken on that job description, even if it does not make any sense. This is one of my pet peeves... in Engineering school it is beaten into you that what you build has to be correct. Correct as in, did you check the poles and zeros? Is this thing going to oscillate out of control and kill people in any breeze? Is this circuit ever going to go into a region where it will fail, probably killing people, and did you ensure you have circuitry that will prevent that? Is every floor of this building rated for the loads, winds, seismic activity, etc. I feel like in software, there used to be a lot of focus on correctness of algorithms. In undergrad computer engineering we had to take algorithms and again in grad school. That class seemed like the one to teach you to be correct, but it was just in your algorithm design. So much of software today controls hardware that may end up controlling (insert your deadly item here: life support, airplanes, cars, trains, critical infrastructure, deadly infrastructure, etc) that it makes me wonder just how much holistic testing of the "in which ways can this software fail and kill people" has taken place.
  - lukas099 2y ago
    Usually software is easier to take apart and modify than other engineering products, so it doesn’t make sense to hold it to the same standard of correctness, and prioritize speed of deployment more.
    - ninkendo 2y ago
      I think this is debatable, but I understand where you’re coming from. Personally I think it would be a better world if software were held to the same standards as other engineering disciplines, and we didn’t treat it as somehow less important for software to be correct just because it’s easy to fix. Things would move slower, but we wouldn’t be “spinning our wheels” nearly as much by redoing work and reinventing wheels over and over. A world where software can be considered “done” when it works and is free of bugs sounds amazing to me.
      - randomdata 2y ago
        I see so many mechanical bugs in my farm equipment, I have to question your notion that other engineering disciplines are actually held to a higher standard.
    - constantcrying 2y ago
      >Usually software is easier to take apart and modify than other engineering products, I do not think that is true. The one thing software allows is a large degree of modularity. In Electrical or mechanical engineering everything can always influence everything else. In software you can have very strong boundaries. >so it doesn’t make sense to hold it to the same standard of correctness, and prioritize speed of deployment more. Why? I don't see that conclusion at all.
      - lukas099 2y ago
        You really don’t think it’s easier to rewrite and redeploy some code than to take fix a bridge or something? >>so it doesn’t make sense to hold it to the same standard of correctness, and prioritize speed of deployment more. >Why? I don't see that conclusion at all. Because, except in like safety critical applications, it’s ok to get something that works most of the time out the door and fix minor bugs later.
- randomdata 2y ago
  According to the dictionary, engineer is defined as: A person who designs, builds, or maintains engines, machines, or public works. You may have a point that the prevailing idea of what engineering is does not recognize software as an engineering discipline as it does not fit into any of engines, machines, or public works. But if we were to include software, surely all software practitioners are people who design, build, or maintain software? Even the web API guy from the story is an engineer on that end.
  - constantcrying 2y ago
    You are totally misunderstanding me. I am not saying that software engineering does not exist, but that most people who are software developers are not software engineers. If you look at what engineers are doing in other disciplines you will find that in software there are some people doing the same thing. They are doing things like drafting requirements, designing, defining, simulating, overseeing, but don't spend much, if any, time actually building things.
    - randomdata 2y ago
      > They are doing things like drafting requirements, designing, defining, simulating Which is design; captured in the definition. You're welcome to invent whatever meaning for engineering you want (although you kind of need to define it, in that case – we can't read your mind), but going by what most people consider engineering to be, either all software developers are engineers or none of them are.
      - constantcrying 2y ago
        >either all software developers are engineers or none of them are. Why? I have worked jobs where I definitely didn't do any real design and was just there to implement certain things. I absolutely wouldn't call what I did engineering.
        randomdata 2y ago
rogerthis 2y ago
Thus we don't need that much software engineers. Things should start to get cheaper (considering everything else the same).
kjellsbells 2y ago
A less generous take on this post is that an elite engineering team drove a perfectly competent developer out of the company by minimizing the perceived value of their contribution. I don't think that was good management, if so. Fred Brooks, in the Mythical Man Month, identified the value of "toolmakers" to the "surgeons" many years ago. I think that model applies here too. Seems to me that a better path would have been to ask the developer in question to lead the automation project, and generally push them over time to look for, and implement, improvements across the development chain that increase efficiency. The elite devs get to keep on doing what they do, but now the whole boat is lifted, and the dev gets to put some real wins on their resume.
- Gabriel439 2y ago
  Author here: we didn't lay them off. They left of their own accord.
  - rideontime 2y ago
    The parent comment didn't claim you did?
    - Gabriel439 2y ago
      Oh whoops, I misread. Never mind me, then
  - dogleash 2y ago
    Defending yourself by clarifying you didn't do X, when the suggestion was that you did Y, always looks more sus than not saying anything at all.
    - giantg2 2y ago
      I agree. Firing is at least more honest (or there's a lawsuit if it isn't). Being pushed out sucks. I know because it's happening to me right now for bullshit reasons (the complaint is that my throughput is inconsistent but yet my average throughput is better than the other dev of my level on the team, and I'm involved in more above and beyond work). Being pushed out is very stressful and has negative mental and physical effects, especially if you have specific disabilities (I do).
bluefirebrand 2y ago
I like this distinction between engineer and technician However, I think if the tech industry adopted this distinction formally, the outcome is that there would be far fewer software engineers and far more software technicians. Which would probably actually be a good thing overall. Most solutions being built out in the world don't seem to need software engineers imo
- steveBK123 2y ago
  I've been on numerous projects that would have probably been more successful with fewer "engineers" and more "technicians". Sometimes people too good get bored and need to invent more complicated versions of the actual problem in order to build fun projects.. All good at your own startup or in your free time of course...
  - bluefirebrand 2y ago
    I'm on a project like this right now. All we needed was an API that exposes data from a database and the team in charge of that database is inventing their own query language with a series of microservices run by an orchestration framework, all to avoid having to make new endpoints when different data is needed. Zero documentation of course. Good job security and resume building all in one project! Sometimes 10x engineers means 10x more complicated than it needs to be an 10x less intuitive than it should be. :)
    - steveBK123 2y ago
      Yeah we had a guy come in and of course invented his own DSL. He had carte blanche for 3 years, nabbed 90% of dev resources, but migrated 0% of clients... These things can run illogically longer than you can tolerate an unpleasant work environment / bad comp.
    - trelane 2y ago
      Presuming your characterization is correct, this sounds like premature automation. Like optimization, there is a sweet spot.
gjvc 2y ago
it is an extremely dangerous thing to think of being a "technician" as less important or lower status. until such work is automated (and I strongly believe it should be) then bad configurations will get pushed to production and bolts on doors will not be tight. i find this article to be overly long
29athrowaway 2y ago
The root of all evil is beliefs in some form of exceptionalism that exempts you from having good worksmanship. Being so special you are exempt from having to write documentation, tests, give visibility, etc. Automation is can be partial, like series of scripts that are ran manually.
sevensor 2y ago
I’ve worked as a non software engineer with non software technicians, and I’ve spent a lot of time thinking about the differences. Most of the work done by engineers was also quite repetitive; in our case the big difference had more to do with whether you turned a wrench during the day, which mainly resulted from differences in your degree of formal education. I was quite junior at the time, however. Where experienced engineers made a difference was in their ability to change how we used the machines, where technicians generally did not. (Sometimes they did, and jumped onto the engineer or management track as a result.) All of which is to say that I formulate a spectrum from technicians through engineers, to scientists. Technicians use technology, engineers devise new technologies using scientific facts about the world, and scientists discover new science. All three parties end up spending a lot of time on repetitive tasks, however. Perhaps what makes computer science unique here is that it’s a science of automation, and as such it actually offers us the opportunity to reduce repetitive work.
ianpurton 2y ago
> We wrote some code to automatically generate an HTTP API from the corresponding gRPC API It's possible to do this without writing code. https://github.com/grpc-ecosystem/grpc-gateway https://github.com/grpc-ecosystem/grpc-gateway You can even get it to generate Open AI style documentation.
- Gabriel439 2y ago
  The post mentions this in the footnotes
frays 2y ago
This is like comparing DevOps engineers and Systems Administrators. Both extremely important to the business but sysadmins are perceived at a lower level?
iknownthing 2y ago
I wish we had a definition for machine learning engineer
deleted 2y ago
[deleted]
kleinsch 2y ago
This take makes sense in the context of the specific example, but falls apart for most other software engineering. You can't automate away defining business logic, but in many cases you can deliver it predictably.
bluGill 2y ago
All too often the cost of automation is higher than the cost of just doing the work manually each time. While the example case that doesn't seem to be true, it isn't clear if they did the analsys. if the manual project took 5 minutes every week and the automation took 2 engineers 2 weeks, it will be 2000 weeks before the automation effort pays off - will you need it that long - don't forget that if the process changes you have even more effort in automation, now add in interest on the investment... Of course as time goes on we get better automation tools. what used to not be worth automating often is today. Don't forget that humans tend to be good at noticing "thats funny" situations while automation will pass many of those situations because you didn't think about them and thus didn't handle that error. This is why despite being a big deliver in automated tests I still demand a large amount of time spent in manual testing everything.
deepGem 2y ago
Predictability is great for everyone, from managers to directors to even company investors. What everyone wants to see is consistent yoy/qoq growth. We should all strive for this kind of consistency. However, balancing this consistency with new adventures is where things get a bit tricky. I kind of like Jeremy Howard's approach to learning here. I don't know if it can be applied to a company or a team scale. Spend 50% of your time on predictable tasks, those that you have mastery over and can do comfortably. Spend 50% of your time on frontier stuff things that break your comfort zone. Over time the some of the latter tasks will get into the former category, thereby leading to automation organically. The ratio of comfort:frontier tasks is personal and let's engineers choose their ratio. Some may want the ratio tilted in the comfort zone (greater predictability ) while some may choose to adventure into the frontier zone (lesser predictability ). An organization should have space for both. Even the same individual can alter these ratios based on their life stages, external circumstances. Put rather simply, a good software engineer can also choose to be a good technician and vice versa. Why should these roles be mutually exclusive ?
- jauntywundrkind 2y ago
  > Predictability is great for everyone, from managers to directors to even company investors. I think it's terrible for the knowledge worker, causing both great emotional turmoil (at the dissonance of expectation versus how they actually perform) and reducing quality of output greatly (by forcing output when more dweel/pondering time is required). Hammock Driven Development by Rich Hickey was such a an enormous relief of a talk to run into, back in the day, hit upon so many tensions & frustrations I had because business Taylorism expected consistent output, expected me to know the process from a->b and to be able to say at every point I am x% of the way through the journey. The businesses doesn't know what's happening but cares enormously about making sure it's extracting as much consistent "progress" as it can out of me/us. HDD talked to how analysis & understanding, how development & problem solving iteration really work. And it works nothing like what a business wants. And what a business wants hurts the quality & doesn't permit ideal outcomes to emerge & surface. https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/HammockDrivenDev.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi... And the human factors are that dwell and pondering are essential for creative and knowledge work. Time in the hammock opens possibilities, fuels the muses. > Spend 50% of your time on frontier stuff things that break your comfort zone. That would be so excellent. I still get that mandate a lot, but so often I see peers whose whole life is cranking out pre-digestrd ready-to-go tickets. I want to see a world where we raise up engineers & engineering, not just ticket technicians.
agentultra 2y ago
In my country software engineer is a protected term. People get sued for calling themselves software engineers if they are not licensed. For me the difference between “software engineer” and “technician” is that the latter has a limited scope of work and is supervised by the former. I think it’s a good idea to have a mix of both. There is a certain amount of toil involved in large systems and automating every single task is not always worth the effort. It’s nice to have technicians around to help with that toil.
- kreetx 2y ago
  Curious to know more, which country, how does one get a license, and how do the non-licensed sw-s call themselves?
  - agentultra 2y ago
    Canada. The license requirements are set by the provincial boards. Most of them require a certain level of education, an exam, and work experience supervised by an engineer. There are still a lot of folks here who will call themselves, "software engineer," or have it in their job title. However the Professional Engineers of Canada has successfully sued people in recent years. Some cases were defended successfully but various engineering boards are appealing them: https://globalnews.ca/news/10163565/alberta-engineers-appeal-software-engineer-court-decision/ https://globalnews.ca/news/10163565/alberta-engineers-appeal... https://engineerscanada.ca/become-an-engineer/use-of-professional-title-and-designations https://engineerscanada.ca/become-an-engineer/use-of-profess... Myself, and like minded people, use other terms like "Software Developer," instead. Personally I would like the chance to be licensed but I lack the education requirement and it seems like, in my province, they removed the equivalent work experience route. Also... these boards haven't been targeting companies lately for using the term and practising engineering without a licensed engineer on staff supervising anyone... to my knowledge at least. Software might be a different world if we were beholden to our profession rather than our employers.
    - kreetx 2y ago
      Thanks! As a fellow developer with no formal education I also feel that strictly requiring a CS or similar degree probably isn't the best way - that there should be a way to account for work experience, perhaps some kind of test. Wouldn't mind taking one myself. The further I am in my career though the less any employer seems to care where and what did I study.
_benj 2y ago
I have a story about engineer vs technician. In my very first technology job (title was web assistant, so, very much technician) we updated our online education platform and suddenly all our course were breaking. After some investigation we found that one line in an xml inside the course zip file needed changing. So, my manager planned how to do it. We'll divide the 40k courses into batches, different individuals would tackles certain batches and it all would be done in about 4-6 weeks... Well, probably my ADHD brain or just being lazy but that sounded like an awful lot of repetitive work that I didn't want to do (change file extension to .zip, decompress, go to file X, find line with XYZ and replace for ABC, save, compress, change file extension back to proprietary format), so after talking with my boss and asking permission I got a week to try to automate that. Back then I knew almost nothing about software development but I was aware of bash and python... so I cobbled together a janky script that would likely make me cry if I saw it now, tested it on 1 course, then on 10, then on 100... and then shared with my boss. It all worked perfectly! We still batches of about 1k courses at a time to confirm that everything was working ok, and in the end the job took about 2 days and 1 person (as opposed to 4-6 weeks and 5 people). I was very proud of that accomplishment and very likely marked my perception of the value of software as a tool to decrease human effort (nobody got laid off or leaved, is not like we didn't have A TON of work apart from that migration). Anyways, just wanted to share :-)
- sshine 2y ago
  I automated my first job in a similar way. Re-encode video files to web-friendly formats and upload them (prior to YouTube). There was a guy whose full-time job was to sit and do that with a Windows GUI. First approximation was an AutoIt script. Second approximation was with bash and ffmpeg.
jrs235 2y ago
"I've learnt that Von Manstein (and others) paraphrased Prussian Field Marshal Helmuth Karl Bernhard Graf von Moltke (1800-1891) who categorised his officer corps into four types. Intelligent & Lazy: I make them my Commanders because they make the right thing happen, and find the easiest way to accomplish the mission. Intelligent & Energetic: I make them my General Staff Officers because they make intelligent plans that make the right things happen. Stupid & Lazy: There are menial tasks that require an officer to perform.. and they follow orders without causing much harm Stupid & Energetic: These are dangerous and must be eliminated. They cause things to happen, but the wrong things, and so cause trouble."
- jrs235 2y ago
  I propose changing "intelligent" to "questioning" (curious) and "stupid" to "unquestioning" (noncurious). And perhaps "lazy" to "resource conserving/saving" and "energetic" to "resource utilizing/spending".
carapace 2y ago
The difference between technician and programmer isn't about predictability, it's about novelty. The technician has to know the system well enough to respond correctly (or even proactively with preventive maintenance, etc.) to unpredictable problems that are "in the book". The programmer by definition solves novel problems. - - - - edit to add: Beware folks who look down on technicians. It's a kind of "code smell" of the mind.
- kreetx 2y ago
  There is a difference between something that can be completely automated and where unpredictable problems arise.
  - carapace 2y ago
    I don't understand what you're getting at, how does that relate to what I said above?
    - kreetx 2y ago
      It means that you don't need a technician at all where the problem is completely automatable. In the original blog post, the developer who was automated away was of that type - adding HTTP API endpoints from protobuf definitions if I read correctly.
      - carapace 2y ago
        Oh yeah, that person should have asked to be re-tasked. The point I'm making is that that's not what makes a technician (that's what makes a human robot! Ew!) > It means that you don't need a technician at all where the problem is completely automatable. You can try to make your systems so good that they seldom need technicians but you can't fire them all because Murphy's Law rules real world systems. https://en.wikipedia.org/wiki/Maytag#Ol'_Lonely https://en.wikipedia.org/wiki/Maytag#Ol'_Lonely
        2y ago
drewcoo 2y ago
I use the terms "bespoke work" and "commodifiable work" to differentiate the two kinds of work in the article. I think the article misrepresents what actual technicians do and their value.
Tade0 2y ago
> But it wasn’t great for the business! That is a pure and virtuous stance. I typically refrain from giving management ideas of this sort. It's not a given that the pros outweigh the cons - especially in large organisations. In any case I'm currently in a project which was supposed to be for Technicians, but I need to do a lot of Engineering due to, well, bugs and tech debt. My take is that any sufficiently long running project, even if originally simple, creeps beyond the skillset of Technicians.
tristor 2y ago
I have, at some point in my career, had the title of "Automation Engineer" in the past. I generally agree with the article except there is one huge oversight: Automation requires predictability as a prerequisite and complex systems are not naturally predictable. It takes effort from smart people to ensure the predictability of a system and repeat a task long enough that it can be automated.

65 points by dahlia 2y ago

[dead]

The SREs have the word "toil" for work-that-has-the-technician-nature. Relevant page of the SRE book is https://sre.google/sre-book/eliminating-toil/ https://sre.google/sre-book/eliminating-toil/ .

constantcrying 2y ago

I like the distinction between technician and engineering. So much of software development is just technician work and has nothing at all to do with engineering. Unlike other countries in the US you can call yourself an engineer as a job description without any restrictions, so far too many people have taken on that job description, even if it does not make any sense.

ghaff 2y ago
I think there is a distinction in general. On the other hand, as someone with degrees in other areas of engineering, I also think there can be too much emphasis placed on the degree to which those other areas of engineering apply formal process and rigorous practices to everything they do. Yes, there are established codes for structural analysis and the like but there's still also a lot of seat of the pants.
readingnews 2y ago
≥≥ Unlike other countries in the US you can call yourself an engineer as a job description without any restrictions, so far too many people have taken on that job description, even if it does not make any sense. This is one of my pet peeves... in Engineering school it is beaten into you that what you build has to be correct. Correct as in, did you check the poles and zeros? Is this thing going to oscillate out of control and kill people in any breeze? Is this circuit ever going to go into a region where it will fail, probably killing people, and did you ensure you have circuitry that will prevent that? Is every floor of this building rated for the loads, winds, seismic activity, etc. I feel like in software, there used to be a lot of focus on correctness of algorithms. In undergrad computer engineering we had to take algorithms and again in grad school. That class seemed like the one to teach you to be correct, but it was just in your algorithm design. So much of software today controls hardware that may end up controlling (insert your deadly item here: life support, airplanes, cars, trains, critical infrastructure, deadly infrastructure, etc) that it makes me wonder just how much holistic testing of the "in which ways can this software fail and kill people" has taken place.
- lukas099 2y ago
  Usually software is easier to take apart and modify than other engineering products, so it doesn’t make sense to hold it to the same standard of correctness, and prioritize speed of deployment more.
  - ninkendo 2y ago
    I think this is debatable, but I understand where you’re coming from. Personally I think it would be a better world if software were held to the same standards as other engineering disciplines, and we didn’t treat it as somehow less important for software to be correct just because it’s easy to fix. Things would move slower, but we wouldn’t be “spinning our wheels” nearly as much by redoing work and reinventing wheels over and over. A world where software can be considered “done” when it works and is free of bugs sounds amazing to me.
    - randomdata 2y ago
      I see so many mechanical bugs in my farm equipment, I have to question your notion that other engineering disciplines are actually held to a higher standard.
  - constantcrying 2y ago
    >Usually software is easier to take apart and modify than other engineering products, I do not think that is true. The one thing software allows is a large degree of modularity. In Electrical or mechanical engineering everything can always influence everything else. In software you can have very strong boundaries. >so it doesn’t make sense to hold it to the same standard of correctness, and prioritize speed of deployment more. Why? I don't see that conclusion at all.
    - lukas099 2y ago
      You really don’t think it’s easier to rewrite and redeploy some code than to take fix a bridge or something? >>so it doesn’t make sense to hold it to the same standard of correctness, and prioritize speed of deployment more. >Why? I don't see that conclusion at all. Because, except in like safety critical applications, it’s ok to get something that works most of the time out the door and fix minor bugs later.
randomdata 2y ago
According to the dictionary, engineer is defined as: A person who designs, builds, or maintains engines, machines, or public works. You may have a point that the prevailing idea of what engineering is does not recognize software as an engineering discipline as it does not fit into any of engines, machines, or public works. But if we were to include software, surely all software practitioners are people who design, build, or maintain software? Even the web API guy from the story is an engineer on that end.
- constantcrying 2y ago
  You are totally misunderstanding me. I am not saying that software engineering does not exist, but that most people who are software developers are not software engineers. If you look at what engineers are doing in other disciplines you will find that in software there are some people doing the same thing. They are doing things like drafting requirements, designing, defining, simulating, overseeing, but don't spend much, if any, time actually building things.
  - randomdata 2y ago
    > They are doing things like drafting requirements, designing, defining, simulating Which is design; captured in the definition. You're welcome to invent whatever meaning for engineering you want (although you kind of need to define it, in that case – we can't read your mind), but going by what most people consider engineering to be, either all software developers are engineers or none of them are.
    - constantcrying 2y ago
      >either all software developers are engineers or none of them are. Why? I have worked jobs where I definitely didn't do any real design and was just there to implement certain things. I absolutely wouldn't call what I did engineering.
      - randomdata 2y ago

rogerthis 2y ago

Thus we don't need that much software engineers. Things should start to get cheaper (considering everything else the same).

kjellsbells 2y ago

A less generous take on this post is that an elite engineering team drove a perfectly competent developer out of the company by minimizing the perceived value of their contribution. I don't think that was good management, if so. Fred Brooks, in the Mythical Man Month, identified the value of "toolmakers" to the "surgeons" many years ago. I think that model applies here too. Seems to me that a better path would have been to ask the developer in question to lead the automation project, and generally push them over time to look for, and implement, improvements across the development chain that increase efficiency. The elite devs get to keep on doing what they do, but now the whole boat is lifted, and the dev gets to put some real wins on their resume.

Gabriel439 2y ago
Author here: we didn't lay them off. They left of their own accord.
- rideontime 2y ago
  The parent comment didn't claim you did?
  - Gabriel439 2y ago
    Oh whoops, I misread. Never mind me, then
- dogleash 2y ago
  Defending yourself by clarifying you didn't do X, when the suggestion was that you did Y, always looks more sus than not saying anything at all.
  - giantg2 2y ago
    I agree. Firing is at least more honest (or there's a lawsuit if it isn't). Being pushed out sucks. I know because it's happening to me right now for bullshit reasons (the complaint is that my throughput is inconsistent but yet my average throughput is better than the other dev of my level on the team, and I'm involved in more above and beyond work). Being pushed out is very stressful and has negative mental and physical effects, especially if you have specific disabilities (I do).

bluefirebrand 2y ago

I like this distinction between engineer and technician However, I think if the tech industry adopted this distinction formally, the outcome is that there would be far fewer software engineers and far more software technicians. Which would probably actually be a good thing overall. Most solutions being built out in the world don't seem to need software engineers imo

steveBK123 2y ago
I've been on numerous projects that would have probably been more successful with fewer "engineers" and more "technicians". Sometimes people too good get bored and need to invent more complicated versions of the actual problem in order to build fun projects.. All good at your own startup or in your free time of course...
- bluefirebrand 2y ago
  I'm on a project like this right now. All we needed was an API that exposes data from a database and the team in charge of that database is inventing their own query language with a series of microservices run by an orchestration framework, all to avoid having to make new endpoints when different data is needed. Zero documentation of course. Good job security and resume building all in one project! Sometimes 10x engineers means 10x more complicated than it needs to be an 10x less intuitive than it should be. :)
  - steveBK123 2y ago
    Yeah we had a guy come in and of course invented his own DSL. He had carte blanche for 3 years, nabbed 90% of dev resources, but migrated 0% of clients... These things can run illogically longer than you can tolerate an unpleasant work environment / bad comp.
  - trelane 2y ago
    Presuming your characterization is correct, this sounds like premature automation. Like optimization, there is a sweet spot.

gjvc 2y ago

it is an extremely dangerous thing to think of being a "technician" as less important or lower status. until such work is automated (and I strongly believe it should be) then bad configurations will get pushed to production and bolts on doors will not be tight. i find this article to be overly long

29athrowaway 2y ago

The root of all evil is beliefs in some form of exceptionalism that exempts you from having good worksmanship. Being so special you are exempt from having to write documentation, tests, give visibility, etc. Automation is can be partial, like series of scripts that are ran manually.

sevensor 2y ago

I’ve worked as a non software engineer with non software technicians, and I’ve spent a lot of time thinking about the differences. Most of the work done by engineers was also quite repetitive; in our case the big difference had more to do with whether you turned a wrench during the day, which mainly resulted from differences in your degree of formal education. I was quite junior at the time, however. Where experienced engineers made a difference was in their ability to change how we used the machines, where technicians generally did not. (Sometimes they did, and jumped onto the engineer or management track as a result.) All of which is to say that I formulate a spectrum from technicians through engineers, to scientists. Technicians use technology, engineers devise new technologies using scientific facts about the world, and scientists discover new science. All three parties end up spending a lot of time on repetitive tasks, however. Perhaps what makes computer science unique here is that it’s a science of automation, and as such it actually offers us the opportunity to reduce repetitive work.

ianpurton 2y ago

> We wrote some code to automatically generate an HTTP API from the corresponding gRPC API It's possible to do this without writing code. https://github.com/grpc-ecosystem/grpc-gateway https://github.com/grpc-ecosystem/grpc-gateway You can even get it to generate Open AI style documentation.

Gabriel439 2y ago
The post mentions this in the footnotes

frays 2y ago

This is like comparing DevOps engineers and Systems Administrators. Both extremely important to the business but sysadmins are perceived at a lower level?

iknownthing 2y ago

I wish we had a definition for machine learning engineer

deleted 2y ago

[deleted]

kleinsch 2y ago

This take makes sense in the context of the specific example, but falls apart for most other software engineering. You can't automate away defining business logic, but in many cases you can deliver it predictably.

bluGill 2y ago

All too often the cost of automation is higher than the cost of just doing the work manually each time. While the example case that doesn't seem to be true, it isn't clear if they did the analsys. if the manual project took 5 minutes every week and the automation took 2 engineers 2 weeks, it will be 2000 weeks before the automation effort pays off - will you need it that long - don't forget that if the process changes you have even more effort in automation, now add in interest on the investment... Of course as time goes on we get better automation tools. what used to not be worth automating often is today. Don't forget that humans tend to be good at noticing "thats funny" situations while automation will pass many of those situations because you didn't think about them and thus didn't handle that error. This is why despite being a big deliver in automated tests I still demand a large amount of time spent in manual testing everything.

deepGem 2y ago

Predictability is great for everyone, from managers to directors to even company investors. What everyone wants to see is consistent yoy/qoq growth. We should all strive for this kind of consistency. However, balancing this consistency with new adventures is where things get a bit tricky. I kind of like Jeremy Howard's approach to learning here. I don't know if it can be applied to a company or a team scale. Spend 50% of your time on predictable tasks, those that you have mastery over and can do comfortably. Spend 50% of your time on frontier stuff things that break your comfort zone. Over time the some of the latter tasks will get into the former category, thereby leading to automation organically. The ratio of comfort:frontier tasks is personal and let's engineers choose their ratio. Some may want the ratio tilted in the comfort zone (greater predictability ) while some may choose to adventure into the frontier zone (lesser predictability ). An organization should have space for both. Even the same individual can alter these ratios based on their life stages, external circumstances. Put rather simply, a good software engineer can also choose to be a good technician and vice versa. Why should these roles be mutually exclusive ?

jauntywundrkind 2y ago
> Predictability is great for everyone, from managers to directors to even company investors. I think it's terrible for the knowledge worker, causing both great emotional turmoil (at the dissonance of expectation versus how they actually perform) and reducing quality of output greatly (by forcing output when more dweel/pondering time is required). Hammock Driven Development by Rich Hickey was such a an enormous relief of a talk to run into, back in the day, hit upon so many tensions & frustrations I had because business Taylorism expected consistent output, expected me to know the process from a->b and to be able to say at every point I am x% of the way through the journey. The businesses doesn't know what's happening but cares enormously about making sure it's extracting as much consistent "progress" as it can out of me/us. HDD talked to how analysis & understanding, how development & problem solving iteration really work. And it works nothing like what a business wants. And what a business wants hurts the quality & doesn't permit ideal outcomes to emerge & surface. https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/HammockDrivenDev.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi... And the human factors are that dwell and pondering are essential for creative and knowledge work. Time in the hammock opens possibilities, fuels the muses. > Spend 50% of your time on frontier stuff things that break your comfort zone. That would be so excellent. I still get that mandate a lot, but so often I see peers whose whole life is cranking out pre-digestrd ready-to-go tickets. I want to see a world where we raise up engineers & engineering, not just ticket technicians.

agentultra 2y ago

In my country software engineer is a protected term. People get sued for calling themselves software engineers if they are not licensed. For me the difference between “software engineer” and “technician” is that the latter has a limited scope of work and is supervised by the former. I think it’s a good idea to have a mix of both. There is a certain amount of toil involved in large systems and automating every single task is not always worth the effort. It’s nice to have technicians around to help with that toil.

kreetx 2y ago
Curious to know more, which country, how does one get a license, and how do the non-licensed sw-s call themselves?
- agentultra 2y ago
  Canada. The license requirements are set by the provincial boards. Most of them require a certain level of education, an exam, and work experience supervised by an engineer. There are still a lot of folks here who will call themselves, "software engineer," or have it in their job title. However the Professional Engineers of Canada has successfully sued people in recent years. Some cases were defended successfully but various engineering boards are appealing them: https://globalnews.ca/news/10163565/alberta-engineers-appeal-software-engineer-court-decision/ https://globalnews.ca/news/10163565/alberta-engineers-appeal... https://engineerscanada.ca/become-an-engineer/use-of-professional-title-and-designations https://engineerscanada.ca/become-an-engineer/use-of-profess... Myself, and like minded people, use other terms like "Software Developer," instead. Personally I would like the chance to be licensed but I lack the education requirement and it seems like, in my province, they removed the equivalent work experience route. Also... these boards haven't been targeting companies lately for using the term and practising engineering without a licensed engineer on staff supervising anyone... to my knowledge at least. Software might be a different world if we were beholden to our profession rather than our employers.
  - kreetx 2y ago
    Thanks! As a fellow developer with no formal education I also feel that strictly requiring a CS or similar degree probably isn't the best way - that there should be a way to account for work experience, perhaps some kind of test. Wouldn't mind taking one myself. The further I am in my career though the less any employer seems to care where and what did I study.

_benj 2y ago

I have a story about engineer vs technician. In my very first technology job (title was web assistant, so, very much technician) we updated our online education platform and suddenly all our course were breaking. After some investigation we found that one line in an xml inside the course zip file needed changing. So, my manager planned how to do it. We'll divide the 40k courses into batches, different individuals would tackles certain batches and it all would be done in about 4-6 weeks... Well, probably my ADHD brain or just being lazy but that sounded like an awful lot of repetitive work that I didn't want to do (change file extension to .zip, decompress, go to file X, find line with XYZ and replace for ABC, save, compress, change file extension back to proprietary format), so after talking with my boss and asking permission I got a week to try to automate that. Back then I knew almost nothing about software development but I was aware of bash and python... so I cobbled together a janky script that would likely make me cry if I saw it now, tested it on 1 course, then on 10, then on 100... and then shared with my boss. It all worked perfectly! We still batches of about 1k courses at a time to confirm that everything was working ok, and in the end the job took about 2 days and 1 person (as opposed to 4-6 weeks and 5 people). I was very proud of that accomplishment and very likely marked my perception of the value of software as a tool to decrease human effort (nobody got laid off or leaved, is not like we didn't have A TON of work apart from that migration). Anyways, just wanted to share :-)

sshine 2y ago
I automated my first job in a similar way. Re-encode video files to web-friendly formats and upload them (prior to YouTube). There was a guy whose full-time job was to sit and do that with a Windows GUI. First approximation was an AutoIt script. Second approximation was with bash and ffmpeg.

jrs235 2y ago

"I've learnt that Von Manstein (and others) paraphrased Prussian Field Marshal Helmuth Karl Bernhard Graf von Moltke (1800-1891) who categorised his officer corps into four types. Intelligent & Lazy: I make them my Commanders because they make the right thing happen, and find the easiest way to accomplish the mission. Intelligent & Energetic: I make them my General Staff Officers because they make intelligent plans that make the right things happen. Stupid & Lazy: There are menial tasks that require an officer to perform.. and they follow orders without causing much harm Stupid & Energetic: These are dangerous and must be eliminated. They cause things to happen, but the wrong things, and so cause trouble."

jrs235 2y ago
I propose changing "intelligent" to "questioning" (curious) and "stupid" to "unquestioning" (noncurious). And perhaps "lazy" to "resource conserving/saving" and "energetic" to "resource utilizing/spending".

carapace 2y ago

The difference between technician and programmer isn't about predictability, it's about novelty. The technician has to know the system well enough to respond correctly (or even proactively with preventive maintenance, etc.) to unpredictable problems that are "in the book". The programmer by definition solves novel problems. - - - - edit to add: Beware folks who look down on technicians. It's a kind of "code smell" of the mind.

kreetx 2y ago
There is a difference between something that can be completely automated and where unpredictable problems arise.
- carapace 2y ago
  I don't understand what you're getting at, how does that relate to what I said above?
  - kreetx 2y ago
    It means that you don't need a technician at all where the problem is completely automatable. In the original blog post, the developer who was automated away was of that type - adding HTTP API endpoints from protobuf definitions if I read correctly.
    - carapace 2y ago
      Oh yeah, that person should have asked to be re-tasked. The point I'm making is that that's not what makes a technician (that's what makes a human robot! Ew!) > It means that you don't need a technician at all where the problem is completely automatable. You can try to make your systems so good that they seldom need technicians but you can't fire them all because Murphy's Law rules real world systems. https://en.wikipedia.org/wiki/Maytag#Ol'_Lonely https://en.wikipedia.org/wiki/Maytag#Ol'_Lonely
      - 2y ago

drewcoo 2y ago

I use the terms "bespoke work" and "commodifiable work" to differentiate the two kinds of work in the article. I think the article misrepresents what actual technicians do and their value.

Tade0 2y ago

> But it wasn’t great for the business! That is a pure and virtuous stance. I typically refrain from giving management ideas of this sort. It's not a given that the pros outweigh the cons - especially in large organisations. In any case I'm currently in a project which was supposed to be for Technicians, but I need to do a lot of Engineering due to, well, bugs and tech debt. My take is that any sufficiently long running project, even if originally simple, creeps beyond the skillset of Technicians.

tristor 2y ago

I have, at some point in my career, had the title of "Automation Engineer" in the past. I generally agree with the article except there is one huge oversight: Automation requires predictability as a prerequisite and complex systems are not naturally predictable. It takes effort from smart people to ensure the predictability of a system and repeat a task long enough that it can be automated.