Software engineers are not (and should not be) technicians
106 comments · 81% upvoted · source · other discussions
comments
timwaaagh
itijara
The premise that good software engineering and predictable work are at odds is a good one that I think is stated well here, although I was confused by the term technician as I don't think of technician work as always predictable. This is a well known phenomenon in "knowledge work" that much of it is hard to simplify to a series of steps (this also includes work such as visual art, music, etc). It is also why I think that software engineering is not a good target for contracting out or offshoring and is probably not as susceptible to AI as some think.
FatStoic
I think the term "technician" here is merely being used as the opposite to "engineer", on a spectrum where a "technician" wants a safe job that doesn't change, and an "engineer" wants to continue learning how to solve harder problems in better ways.
I don't particularly object to it, but perhaps the term "operator" might align better with the author's intentions.
yojimbo_beta
I agree about the AI part particularly.
I have been saying for a while now - maybe since the release of CoPilot - that every snippet of code generated by AI is essentially a bug report against the productivity of your tech stack
What I mean by that is, if your work is so rote and repetitive that a language model can do it, you are probably leaving expressiveness and efficiency on the table.
Notice how a lot of engineers like it when CoPilot generates "glue code" or code for managing infrastructure. But imagine if you didn't need to do that:
- you had a more expressive programming language or framework that made the glue code invisible or basically trivial in most cases
- you had a compiler and framework that could figure out your desired infrastructure and necessary CloudFormation resources etc
The thing is those tools do exist! In functional languages you get rid of glue code by coming up with monad stacks. In orchestrated programming the compiler figures out your IAC / terraform code. But they haven't crossed the horizon yet for most programmers, who are preferring the short term gains of CoPilot generated code over the long term gains of more expressive tools
cheeseless
In functional languages you get rid of glue code by coming up with monad stacks.
Would you be able to expand on this? How do "monad stacks" get rid of glue code?
my_name_isnt_clever
I don't know about others but I don't use AI to write my code for me. I use it as a super-charged StackOverflow that I can have a conversation with. Yeah it's not always 100% accurate, but code you find from a web search could have bugs as well, and might not be applicable to your situation.
All half decent programmers know not to use code wholesale from anywhere without understanding it, and I don't understand why that's only seen as a problem now with AI.
Kirk_Kerman
GPT and the like are just a rubber duck debugger that talks back, really. Useful for boilerplate too, or if I'm foraying into a new language and don't know the best practices for naming and organization, or need some syntactic mess dissected.
OfficeSalamander
I find it's good for iterating too, if I know the codebase well, know what needs to be done and just don't care to refactor/rewrite things. Obviously important to check and make sure it looks good, but I've found Claude really good at doing refactoring for rapid iteration of ideas/concepts for how something could work. Obviously, as with any AI, it gets off track and acts like an idiot sometimes, but I'd say the vast, vast majority of the time it does what I ask it to
Scroph
I agree, I find them especially useful as an alternative for searches whose queries can't be condensed into a short sentence because of all the context behind them
my_name_isnt_clever
Yes, exactly. And being able to talk to it like a person to help you is what makes it so powerful. There were a lot of times I would find a post from a deleted user 10 years ago with code that was close but not quite what I needed, and wished I could just talk to the poster for 5 minutes. With AI I can ask follow-up questions, ask it how the code would work in X situation instead, and ask for clarity if there is a concept I don't understand.
I also love using it for learning a new language, because prompts like "in <any language> what is the closest thing to a python list comprehension" are so helpful. And it's great at translating code so you can just write some of the language you know and say "how do you do this function in rust" or whatever.
Skellicious
I use it as a super-charged StackOverflow that I can have a conversation with.
I did this for a few months until I got burned by how badly it was gaslighting me with different hallucinations for like 30 minutes straight.
Scroph
IMO the rarer the technology you're working with, the more hallucinations chatGPT gives you about it, due to a shortage of training data. The answers it gave me when I asked it questions about jasper reports had me doubting my sanity
Skellicious
Doesn't have to be rare. In my case I asked if you could access docker volumes during build time.
Even though the answer is no, "docker" and "volume" must be closely related terms so that it hallucinated different solutions like crazy.
I ended up solving my issue with a build cache, which probably isn't even in chatgpt/copilots training data.
techwiz3
Plus, AI can’t deal with the human end of it. So much of our time at work involves managing clients. AI can’t do that for us.
IHeartMustard
Kinda wish they could tbh, so that I could do the fun stuff ;_;
reddituser567853
I think most tech companies have technical project/program managers for that.
-Hi-Reddit
I hate this war on simple but verbose code.
Yes 6 if statements could be turned to 0 with dependency injection and context tracking and a bunch of extraneous shite in a more "expressive" language...or you could leave it as 6 ifs until you actually need the abstraction...if you ever do.
Pr0Meister
Bro at least split them in different methods, sonarqube will scream about the supposed "complexity" otherwise.
Dextro_PT
To think that I've been doing this stuff for over a decade and Sonar freaking Cube is still annoying developers everywhere with BS "code smells" is seriously disappointing.
Pr0Meister
At this point it's a Pavlovian reflex to never have more than two nested if statements ever.
-Hi-Reddit
I didn't say nested, and didn't mean nested, i am a "never nester"
-Hi-Reddit
Mark as reviewed, "locality principle takes precedent here", move on.
Pr0Meister
Out of my hands, architects and DevOps require full compliance without us interfering with it
-Hi-Reddit
devops deciding on how many if statements can exist per method? that's disgusting
Pr0Meister
DevOps are responsible for the pipeline, the pipeline stops if sonarqube doesn't give the green light, can't change sonarqube config without their go ahead, so yeah in a way they get to decide
evert
It's a beautiful idea, but endless abstractions have their own set of problems because it's incredibly difficult to find the correct abstraction. An incorrect abstraction is way more expensive than a bit of copy-pasted imperative code.
Glader
I enjoy using Copilot. It allows me to write the stupid simple code that solves my stupid simple problems very fast without having to resort to introducing complex mechanisms that add to my cognitive load. It's hard for me to introduce complex bugs now, and that makes me happy.
vladimir_sn
This is so on the money - exactly my sentiment about AI tools to generate code as well!
techwiz3
I agree with what you said about AI. Plus, a lot of software engineering involves dealing with people. You have to translate expectations into results.
FlyingRhenquest
Heh. I suspect one of my future resignations will be accompanied by a Python script, written by ChatGPT, that allows you to import a ChatGPT prompt and automatically run the code it returns. And my resignation letter will read:
"Gentlemen! I wish to notify you that I have designed my way out of this position. The accompanying code will run whatever your heart desires! All you need to do is provide it an English description of what you want it to do in a fashion that will allow the AI to unambiguously understand your exacting requirements and implement the same solution reliably each time! I wish you well on your way to the economic domination of the world that my provided solution should enable for you! Thank you for the opportunity to work for you!"
FluidmindWeird
The technician analogy works for me. Having taken courses in electricity concepts and design, and having seen electrical generation and transmission equipment maintenance instructions, I get this use of technician. While we want humans for safety reasons for those sorts of large scale electricity management, but in software? If I encounter "manual" anything, I make it my goal to eliminate that part of the process entirely by automation. Because it makes a lot more sense than spending a human's time if all it really is is a bunch of calculations.
[deleted]
If the rocket to launch the warhead to destroy the asteroid heading for earth is having some weird glitches on the launchpad and there isn’t much time to diagnose and fix the problem: option 1 send in dedicated team of technicians with the manual or send in the people that designed and built it. I’m choosing the latter.
Unfortunate_Gamer
I don't necessarily agree with the premiere that software development "isn't as susceptible to AI as some think" software engineer as it used to be is going and and the wholly due to AI, one just has to look at how GitHub copilot the is changing and impacting how developers work. I work for a it multinational consultancy and not only is AI changing how we do business but it also changing how our clients are too and this is just it's infancy.
yojimbo_beta
I think this is a very pithy description of the problem. Predictable work is exactly the kind of thing that should be automated away. So if the business incentives predictable work it will encourage waste
Special_Wing3476
Spending 3 year on automing a job that takes two hours to complete every fortnight is a sure sign of a pie in the sky thinking.
TiaXhosa
Maybe, but no one is spending 3 years automating one two hour job unless they are selling their solution as a product.
Ashken
I second this. As a junior I once spent something like 3 sprints automating something that was a 2 hour daily job, and they told me I saved the company like $50K a year. Thats worth the time as they may have paid me what, $15k at the most?
Special_Wing3476
That is what the article calls for, with its lack of nuance.
RoosterBrewster
For personal use, it just feels better to automate some things that would be mind-numbing to do, even if the payoff takes a long time.
Special_Wing3476
What we do for personal reasons, are often not the best for the business.
dccorona
This article provides one single example to try and explain their point and it isn't even a good example because it is an example of automation winning. Where is the example of a company not investing in automation because they'd rather do repetitive but predictable work? In particular: where is the example doing that and then not doing the more challenging thing at all because they're spending all their resources on something automatable? The whole premise of this article is that that does happen, but it doesn't provide even a hypothetical example of it happening.
For what it's worth I have not experienced this happening unless the effort to automate something was so great that it would have had more impact on the ability to do "better things" than just putting an engineer in the loop for a task would. And generally the reason for that is not because the happy case is hard to automate, but rather all the error and edge cases are hard (often because deeper in the system something does not error out clearly or consistentely, etc).
SpaceMonkeyAttack
My experience is that the manual technician work takes up all the available engineer capacity, and is also mission-critical. To automate it, the engineers need to spend time not doing it manually. Very often, the ones doing the manual stuff are the ones who would best understand how to automate it. But they can't be spared from their critical manual tasks, and other engineers can't be spared from fixing bugs and shipping features.
So instead of spending a few weeks of one-off dev time on automation, we waste several times that much every year. If we're lucky, we get to chip away at the automation work, a few hours out of every week.
tanorbuf
Imagine if your deployments happened by having an developers manually copy jar files to individual Windows servers and also manually fiddle on-server configuration until things are as he likes (regardless of VCS file content). I don't have to imagine, I see it every day. The project managers know with good precision how long it takes to deploy an update, and customers are paying for it, so the business is happy. And the software developers who work on it seemingly are also happy. But like the OP I don't think it's really software development work, it'd be more correct to call it technician work.
NotUniqueOrSpecial
Where is the example of a company not investing in automation because they'd rather do repetitive but predictable work?
Almost literally every single large legacy organization that has software involved in their core line of revenue.
The systems responsible for all the money-making are fragile garbage tied up in mud. The people that understand them the best lack the skills to better things or they would've done so 10 years ago.
The people managing those people are burnt from a decade of delays, regressions, and sloppy garbage from all the error-prone processes in question and no longer are capable of even entertaining sweeping changes, no matter how big the payoff would be.
It's just fear and legacy albatrosses around everybody's necks.
And if you've not worked at one of those places, you're lucky, but be assured they exist.
dccorona
I don’t doubt that they do. I’m pointing out that the article doesn’t prove its premise, not claiming that its premise is not possible to prove.
NotUniqueOrSpecial
Ah, gotcha. Thanks for clarifying.
interbingung
I've work for long time in company where I mostly did technicians job. Its not that they are doing it in purpose but they have no idea that there are opportunities of automation. It doesn't help that I purposely hiding that from management, yes I'm lazy.
[deleted]
I'm not sure if a specific case can be generalized but the point of it is "Don't be a robot doing A,B,C,D".
Not sure how technicians are related. Technicians have to do dynamic work as well, so I don't think demeaning their role in industries is a good example of proving software engineers need to use their brains more.
agumonkey
Initially managers liked the fact that this developer could estimate reliably (because the work was well-understood) and this developer liked the fact that they didn’t have to leave their comfort zone. But it wasn’t great for the business! This person frequently became a bottleneck for releasing new features because they had inserted their own manual labor as a necessary step in the development pipeline. They made the case that management should hire more such developers like themselves to handle increased demand for their work.
Seen this first hand. Astonishes me that a lot of devs are like this. But it's probably a timeless anthropological thing, that ripples through the economy. A lot of place will indeed hire more people to do useless manual tasks (customers will pay most of the time anyway and can't legitimately question the way work is done)
jl2352
These posts are always complex ways of saying ’I don’t want to give estimates’ or ’I can’t keep to delivery.’ They also position the world as either being no estimations, or a regimental date in the sand. With nothing in between.
You are allowed to give an estimate and say, this estimate will be updated as we go. And then update it as you go.
You can also give an update for short term work (with a high predictability), and give a much more rough estimate for long term work.
For the experimental work OP talks about. You can do investigations, and use that to look into the unknowns.
Tbh I find the whole anti-estimate mantra spoken by some engineers to be unrealistic and borderline childish. The business just wants to know, loosely, when it’ll probably be done by. They are paying your wages. Why is that so unreasonable?
Kalium
The real-life issue that many an engineer has run into with estimates is, unfortunately, simple.
You are allowed to give an estimate and say, this estimate will be updated as we go. And then update it as you go.
They aren't allowed to do this.
You can also give an update for short term work (with a high predictability), and give a much more rough estimate for long term work.
Or this.
Many organizations treat early estimates as deadlines set in stone. Those set dates are then planned around. Updates to estimates are bad because it means you're now upsetting months and even quarters of future plans.
The anti-estimate crowd is often a reaction against the business wanting not a loose of idea of when something will probably be done, but against a structure that repeatedly takes a loose idea and launders it into a commitment. If you can't get them to stop that - and they probably have strong incentives to keep doing it - your only options are to quit or to decline to provide something to launder.
Yes, a lot of software organizations really are that breathtakingly immature. They usually call it "acting like a startup" or similarly launder their immaturity into a virtue.
ub3rh4x0rz
Pretty much this. I can say from personal experience that in relatively functional orgs, I've felt safe making estimates, and they'd be right a fair amount of the time. People could plan better because of it. If conditions changed and things had to be reconsidered, this would be done and communicated readily. In more dysfunctional organizations, all estimates are compromised and effectively useless for anything other than whipping people, and the work and communication invariably suffers.
Having seen it both ways, I do get annoyed when people more used to dysfunction than healthy planning and communication try to derive some categorical rule that estimates are bad and the stakeholders ought to just worship at the alter of the software engineers and cater to their every whimsy. If you adopt that mindset to resolve your cognitive dissonance, you're basically shaping yourself to perpetually work for dysfunctional organizations. Quit if you're that jaded.
Kalium
I agree, with the caveat that we've got at least a whole generation of junior to mid-career engineers who have never worked in a mature organization. They genuinely don't believe in the possibility of a mature one. They've never seen it and most of their peers haven't either.
ub3rh4x0rz
Maybe not be a good option for everyone, but a good number of us (myself included) learn this and battle it out in smaller organizations that have trudged through dysfunction long enough to be open to influence from within to change these things. I've been in at least couple orgs like this, one as a lead/manager, current one as an IC, and it's awesome to be able to shape things to be less dysfunctional and a great professional development opportunity. There's tons of smaller orgs with in house software that aren't even primarily tech companies, I think it just takes a certain intersection of tech and soft skills and disposition for it to be a good path.
Kalium
I've been in some orgs like that. The best I was ever able to manage, even as a very senior and respected IC, was to convince some of the lower-level engineering leadership to shelter their engineers from some of that pressure. It generally only worked with the managers who were important and respected enough that they didn't get challenged too much by their superiors.
Otherwise, though? This is the kind of shit that rolls downhill. More aggressive, promotion-hungry managers - the kind that often join small tech companies looking for growth - tend towards toxic anti-patterns. Nevermind pressure from actual execs.
I've been in some of the not-really-a-tech-company orgs, too. The small one that did in-house stuff was perhaps the worst. Small businessman tracking everything to the penny, and you can guess how that translated to anything that seemed like it took too long. Oddly enough, the defense contractor I worked for was great at understanding estimates as estimates for a company that was fundamentally not a "tech" company.
ub3rh4x0rz
I'll probably have more to say later, but for now: if anyone is more notorious for slipping deadlines and budget overages than software teams, it's defense contractors lol
DPaluche
I don’t detect any anti estimate sentiment in this article. It’s just pointing out that highly accurate estimates are not the flex you might think they are.
ub3rh4x0rz
They're painting with too broad a brush, and they're implicitly misattributing all accurate estimation to grunt work vs real engineering work (tm).
Accurate estimation is a skill highly correlated with experience, skill, and higher order thinking. It's a muscle you have to both care about developing and the organizational context to exercise. The hardest part is recognizing the function of time/complexity on the appropriate precision with which to estimate, as well as executing and communicating well enough that stakeholders don't perceive your estimates to be bullshit or overly padded (hey sometimes that's entirely their fault, see "organizational context" statement above).
ModernRonin
The business just wants to know, loosely, when it’ll probably be done by. They are paying your wages. Why is that so unreasonable?
Because to estimate something with any accuracy, you have to have done it (or something very much like it) before. Probably several times.
But software is often original. Writing a new program is often like wading into a nest of alligators, whose capabilities and problems you have no clue about. And you can't figure them out until you're ass-deep in the middle of all of them. And they're already snapping at your fingertips.
Things are this way in SW Dev, precisely because business-people always want it done faster. Which means that bad architecture, lack of documentation, and quick hacks (that are inevitably going to blow up in someone's face at some point in the future) are the rule in modern software, rather than the exception. And engineers hate all that bullshit. We hate it with the white-hot nuclear fire of 10,000 supernovae. But we are constantly counter-manded from doing things right by profit-mongering idiots in the C-Suite. Whose major concerns are not if the company is shipping good code, but rather whether or not their stock options will go up this quarter, and if they'll get their cash bonus for delivering the software by $ARBITRARY_DATE_SET_BY_MARKETING_GUYS .
If you don't believe me about any of this, then I invite you to just look around. Why did Boeing 737s have a faulty MCAS system that caused them to crash? Why did half the Windows servers in the world crash last week?
Was it because good software engineers were listened to, and their concerns were heeded?
...
I've read the Manager FAQ. I understand it, and even agree with some of its points.
Have you read the Hacker FAQ? Do you understand it?
[deleted]
[deleted]
Kalium
I wouldn't wish a manager onto my worst enemy who treats a story estimate as a hard deadline.
It's been my experience that this is an extremely common behavior pattern for managers, PMs, and TPMs. In general they are being pressed by those above them for clear, predictable, reliable timelines that the even-higher-ups can plan and resource around.
Managers are often measured on their ability to make the organizations they oversee run in predictable, mechanistic ways that produce output reliably from a given set of inputs. The worst thing they can do for their careers is present large error bars and specify that adding together estimates makes the overall timeline less certain as error compounds.
Presented with a choice between screwing themselves or screwing the engineers they can always ride harder, managers make the obvious choice. Well, the obvious choice for a manager who is more concerned with their career and hide than the happiness of the engineers under them.
ModernRonin
I wouldn't wish a manager onto my worst enemy who treats a story estimate as a hard deadline.
Sounds like you work at a much better company than average.
The realities for most people are much harsher.
spareminuteforworms
I've been put in the position to make estimates based on a 10k page specification which I had only read bits and pieces. I said I'd need to do a serious amount of reading and reflection to make any sort of estimate. They said how long is it going to take to do all that reading and reflection. I said its a 10k page specification I have no idea. It can become quite circular in some scenarios.
[deleted]
El_Serpiente_Roja
This assumes managers are reasonable and good at their jobs, this assumes stake holders are open to date changes, this assumes requirements are clear, this assumes the culture isn't political. This sounds good in a reddit reply and maybe your job is actually like that but the Peter principle alone will make this kind of thing impossible in a lot pf places. "This estimate will be updated as we go" lol..thats a good one.
jl2352
What you describe has come up a bazillion times as a retort. ’What if the manager is a shitty manager who is shit at their job?’ Then you’ll have a shit time.
Dealing with terrible people is a different topic. They will scupper anything. Not just estimations.
Having been in multiple teams in multiple companies, over fifteen years. My experience is most people are reasonable. Let’s say 8 out of 10.
That doesn’t mean they are clear, or know everything, or good at their job. I’m saying reasonable.
I’m often left with the impression in these discussions that engineers expect to be given crystal clear requirements, and if they aren’t, they do nothing to help get clarity. Say it’s unclear. Say what you need. Put forward suggestions, and let them shoot them down with what they actually want. Say you’ll get it done sooner if you do more discovery. Divide the clear requirements from the unclear ones, and work on the clear ones first. Lead the discovery on what you need. You are allowed to do these things.
The above has worked for me in multiple times.
Getting back to shitty people; when you are delivering projects well with one set of people. Then suddenly badly with one particular stakeholder. It’s much, much easier, to point out the issues to senior management.
Whereas if all your projects are late, with any stakeholders. Then you are seen as the problem.
tevert
I don't think OP is arguing against estimates. They're just saying that assigning value to something being estimateable is a false sense of achievement
mangodrunk
What does the business do with bad information (especially early estimates)? Why do they need to know? As others have said, estimates do have a tendency to becoming deadlines and commitments.
TheESportsGuy
Large businesses build inefficiency into their business models intentionally or entropically. So while the premise is a nice one, it's directly at odds with how money works.
TechFiend72
I don’t think this person knows what they are talking about technicians are in infrastructure. Don’t steal titles and use in a totally different context.
techwiz3
I think the overall article makes sense. But “technician” was not the right word. Someone else here proposed “operator” as a better one.
TechFiend72
I use to call them automation programmers. A lot of senior systems admins do automation programming as well.
bmiselis
In my view, a great software engineer is one who automates repetitive/manual labor.
You know what's an added benefit of an engineer doing so? Automation of the task is its documentation. I like to think about automating manual processes as literally showing the teammates what I'm doing. Whenever I'm unavailable, anyone can do what I would do.
There's a risk, however, that you've highlighted: automating away too much of ones job may lead to the perception that you're no longer needed. But if they fire you, who will automate next problems? 🤔
It's not easy to maintain a tradeoff between automating stuff and keeping your position intact.
tasminima
Sounds like somebody has trouble to finish their projects and wrote some ad-hoc justification of their shortcomings.
cheezballs
What an empty article.
Humble-Implement-36
Maybe a more appropriate statement would be:
Software engineers are not (and should not be) PROGRAMMERS.
umlcat
Agree., But, the Elite wants it to be ...
[deleted]
wittleboi420
tell me you’re from the US without telling me you’re from the US
benji_york
I'm curious what you mean. Will you unpack that some?
wittleboi420
The usage of the term „software engineer“ just seems kinda inflated in the US. I’m not trying to gatekeep here, but not everybody that is working with code is an engineer
jeorgewayne
That is true. In the US, real engineers (ie have engineering degrees and licensed) are associated with prestigous organizations like NASA. For some unknown reason (maybe insecurity) programmers started calling themselved "software engineers".
A self taught web programmer can put on their resume "Software Engineer". That is a load of bullshit to me.
benji_york
You might be interested in the Crossover Project.
to have completely normal work spiral out of control because of ripple effects that you can't see is not desirable either. So it really depends where the complexity comes from.