_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI The reality of working in tech: We're not hired to write code (2023)
disambiguation wrote 1 hour 33 min ago:
Yes the nature of employment is that you're paid to do whatever the guy
paying you tells you to do. Roles and specializations are
organizational tools - meaning, for the benefit of the organization,
not you. There will never be an exact match between the "definition of
a role" and "the work that needs to be done."
dogleash wrote 4 hours 30 min ago:
Managementbrain's definition of a well rounded developer is also the
definition of people they're trying to promote out of development. Then
they look around at developers wondering why they all just don't "get
it".
Probably because they took the money to change role rather than keep
the job they wanted.
Willingham wrote 7 hours 53 min ago:
This article makes many valid points, but itâs important to remember
10%~ of devs are system developers(OS, compilers, firmware, database
kernels etc.) For these jobs, the code itself often IS the core
product. Correctness, stability, and compatibility come first,
therefore the âout with the old and in with the newâ mentality is
much less prevalent.
vkaku wrote 9 hours 32 min ago:
I think that we're diluting the scope too much. Not only do people get
paid to solve problems, also to execute them. When we get into the non
execution zones, it causes many layers of beaureaucracy that will
bankrupt any respectable company.
mcv wrote 13 hours 49 min ago:
I wonder if the fact that we're not hired to write code, is also the
reason we're not paid as much as some other roles. This is my big
frustration: that senior programmers (in NL at least) are not paid as
much as managers, POs, various kinds of architects, and even scrum
masters.
A couple of years ago, I was freelancing for a company where I wrote a
lot of excellent code. They had a bunch of data they wanted to do
something with, but weren't entirely sure what or how, so I did that
for them. Connected, visualized it, made it fast, and they loved it.
And so did I. It was fun work, I talked to a lot of people about what
they wanted and needed, and delivered that.
My freelance period ended, but I wasn't ready to leave this project
yet, so I became an employee, but that turned out to be a massive step
back in terms of income. Despite the fact that I worked closely with
lots of stakeholders and solved complex problems for them, their
internal rules didn't allow them to pay me as more than a code monkey.
I felt all the non-code work I did wasn't being appreciated. Nor the
code work.
I left, they ruined the application (it's apparently slow as molasses
now), and now I'm about to go back. I guess I've made peace with the
fact that they don't pay programmers as much as I think they should.
(It's not actually bad pay, just not as much as non-programmers get.)
But mostly, it was a fun project that taught me a lot, and I want more
of that.
aaronbaugher wrote 1 hour 16 min ago:
I think it's easy for the decision-makers to take programming talent
for granted because they can't see it or estimate what it can do. If
my manager comes to me with a task, he may not even know if the task
is possible. If it turns out to be relatively simple and I kick out
the solution in an hour, he's impressed, but he's also "learned" this
this stuff is easier than he thought. That shifts his mental window
of what's possible in X hours. Every time he thinks, "That must have
been easy after all," the more he's likely to devalue what he thinks
the work should cost. A smart manager will know better, but many
don't.
We could combat that tendency by taking a longer time than necessary
on some tasks, basically loafing to make our work look harder, but
who wants to play that game?
63stack wrote 9 hours 39 min ago:
>so I became an employee, but that turned out to be a massive step
back in terms of income. Despite the fact that I worked closely with
lots of stakeholders and solved complex problems for them, their
internal rules didn't allow them to pay me as more than a code
monkey.
Surely there was a negotiation step before signing contracts? What
happened there? What was the blocker that did not "allow" them to
change their own internal rules that they themselves control? Surely
there is a way to do that.
>I left, they ruined the application (it's apparently slow as
molasses now), and now I'm about to go back
Then state what you want before going back, if it's important for
them they will find a way. Don't accept these kinds of zero effort
"oh our policy doesn't allow us to pay you more" explanations.
jen20 wrote 4 hours 40 min ago:
I interpret "our policy doesn't allow it" as "I don't want to work
here".
sam_lowry_ wrote 12 hours 51 min ago:
This is the general culture in Europe. Techies do not get promoted
and do not even have a possibility to grow to management. Everything
is run by humanities people and we do not even have the right words
to describe this situation, although some voiced their concerns for
many years, see e.g. The Two Cultures [1] from 1959.
URI [1]: https://en.wikipedia.org/wiki/The_Two_Cultures
godelski wrote 11 hours 0 min ago:
> and do not even have a possibility to grow to management.
Hang on, why should this even be the goal? I really do want to
question the premise of this kind of ladder in the first place. You
got someone with a really good skill, one that is critical to your
operations and you... want to put them in charge of people rather
than keep doing what they're doing? You can just keep promoting
people with whatever direction you want them to go in. It is all
arbitrary and made up anyways. So why not keep promoting them in a
direction where you still benefit from those technical skills?
lurking_swe wrote 9 hours 10 min ago:
ever work for a manager that barely understood what you do, or
how itâs done? Been there, done that. Never againâ¦
Engineers shouldnât be _forced_ into management but the option
should be encouraged if they have the aptitude for it.
godelski wrote 2 hours 27 min ago:
You're also making a bad assumption. I'm just saying there
should be multiple paths forward. You can promote in any
direction you want as long as you decide that your employees
can do that. In our fictitious scenario some could go to manage
teams some not. Some could focus on their work being a team
lead, some just continue doing their thing.
My point is literally at the arbitrariness of promotion and how
biased it is. There's a very clear bias that being structured
by business people who think business people are the most
important. The classic "I do x, so x is more important"
fallacy.
My point is to make people just question if what we do is
actually reasonable, and if we could do things better.
Besides, I've worked with people who previously knew how to
program but lost the skill when moving to management for a
decade and they aren't really any better than the manager that
never knew it. Neither of these results in smooth operation.
But I think to see a solution we'd also need to reconsider the
premise. That's what I'm getting at.
sam_lowry_ wrote 10 hours 50 min ago:
Nope.
I do not say that experts have to be put in charge of people
instead of doing what they're doing.
I rather say that experts should be in charge of what they are
doing.
godelski wrote 40 min ago:
I think this is a good option. I also have no problem with
experts being put in charge of people. Truthfully I think the
bigger issue is that there's not more ways for growth. But at
this point I'd settle for just ways to grow in the technical
side without needing to move to management (being a group lead
or having people under you is something I'd consider different
when your main job is still doing technical work)
mcv wrote 11 hours 47 min ago:
Techies can get into management, but they stop programming if they
do. I've been told I could get into a higher pay scale if I took on
managerial or administrative tasks that I'm bad at and have nothing
to do with programming. I'd like to be appreciated for the stuff
I'm good at, not for doing stuff I'm bad at.
sam_lowry_ wrote 10 hours 46 min ago:
That's exactly the point. The expectation is that techies stop
being techies if want to have a career.
This is exactly why we can't innovate in Europe.
DrillShopper wrote 6 hours 45 min ago:
I hate to break it to you, but this also happens in the US -
especially at huge companies.
The next step of my career progression at my current company is
deciding whether I want to go into the continuing tech route as
an architect or staff software engineer or if I want to go into
the managerial / people leader route.
The later is quite more lucrative, but I would have to stop
programming.
whstl wrote 10 hours 58 min ago:
Eng Manager here. At previous jobs I constantly had this
assignment of "stop coding and only do code reviews". This to me
is incredibly short-sighted as my code reviews are gonna be shit
if I don't code.
Also managing a team of even 10 developers was the easiest job I
ever had. Hire well, treat them well, talk with them routinely,
solve conflicts, allow them to explore things.
The hard part of the job is of course functioning as a therapist
for disorganised power-grabbing product people and shielding my
team from their shenanigans. I'm so tired of it.
Every bad engineering manager I had two characteristics: they
never have time to code but also never have to talk to me or any
other employee.
lifestyleguru wrote 12 hours 0 min ago:
European societies are extremely class based which is brutally
visible in UK, France, Netherlands, even Germany. INSEAD and other
MBAs see techies as washing machine repairmen.
mcv wrote 11 hours 42 min ago:
Netherland is actually extremely egalitarian. Managers are often
just one of the team, you address everybody informally, we're all
equals, etc. Except in pay. And especially in larger
organizations. Managers and people on track to management are
seen as the shit. Programmers are paid fairly well compared to
the average job, but even if you're single-handedly pulling an
important project, you're never going to make the same as people
who push numbers, papers and money.
lurking_swe wrote 9 hours 7 min ago:
> informally, we're all equals, etc. Except in pay.
arguably the most important part. :) 2nd being team and company
culture imo.
lifestyleguru wrote 9 hours 51 min ago:
> you're single-handedly pulling an important project
Never do it on employment contract in Europe. Even if you
really are and then quit your job, from next Monday everything
will operate as if you never had worked there.
> you're never going to make the same as people who push
numbers, papers and money.
That's why the top EU companies are loathed ERP company,
perfumes and purses company, and obesity drug for Americans
company.
whstl wrote 10 hours 56 min ago:
Europe is egalitarian in the surface but class-based deep down.
Your word is worth as much as your title.
Of course I can't speak for every country but that's the
reality.
I'm not saying that anywhere else is better, but in other
places I worked there was no such illusion.
sam_lowry_ wrote 11 hours 54 min ago:
I think it is deeper than the theory of class struggle.
France rebuilt its educational system under Napoléon to teach
science to bright kids from all backgrounds.
Fast-forward 200 years, it degraded into a system that teaches
anachronistic humanities to smart and docile kids of upper middle
classes.
P.S. For non-French, I am talking about the system of Grandes
écoles [1]
URI [1]: https://fr.wikipedia.org/wiki/Grande_%C3%A9cole
em-bee wrote 15 hours 42 min ago:
While I was previously the go-to person for building new features, I
was unable to contribute to the implementation of Angular due to my
lack of experience with it.
was he unable or was he not allowed or simply not asked? it sounds like
it could be the latter which is something i'd expect from that kind of
dysfunctional company, but if he was really unable then this person
should not be working as a software developer.
94b45eb4 wrote 16 hours 12 min ago:
I used to hear this all the time back in the early 2000's. It's far
from a new idea.
The version I heard (or at least the one which stuck in my head) was
"your job is not to write code, your job is to solve problems".
edit:
I wish this was more mentioned more frequently these days. I see junior
developers very focused on superficial aspects of code and specific
"cool" frameworks these days. Often I find myself asking "what problem
does this solve? What are the trade-offs with your approach? etc." and
it's just crickets. I think we have made a lot of progress with modern
frameworks, tools, etc. but I also think there is something from the
"old days" of programming which we have lost, which I think we should
have fought a bit more to keep.
skydhash wrote 15 hours 11 min ago:
I mentor a few friends and my first question when they come to me for
troubleshooting is: What's the problem you're having and what has you
tried so far? Then I restrict them from talking in too specific
technical terms. Instead I orient the conversation to the appropriate
metaphor, and more often than not, they can see the solution by
themselves (unless it's really a technical implementation issue).
WalterBright wrote 16 hours 34 min ago:
You're hired to make money for the company.
mitthrowaway2 wrote 14 hours 46 min ago:
... In theory yes, but company incentive structures don't always
amount to this.
If you take that too literally and act on your own initiative in ways
unrelated to your job description, you may well be dismissed for
circumventing upper-management decisionmaking and not staying in your
lane, even if you make money for the company in the process.
Or if you make tons of money for your company doing what you were
hired to do, but do so from home in violation of a mandatory RTO
order, you may quickly be replaced by someone who makes less money
for your company but sits in the correct cubicle.
In reality, you're not merely hired to make money for the company,
you're hired to do your job, even if it's not the maximally
profitable action.
WalterBright wrote 14 hours 32 min ago:
The company can absolutely be wrong in their idea of how to make
money, no doubt. But it's still what motivates them.
I've stepped out of my lane to make money for the company, even
when explicitly told not to, but the making money part meant they
overlooked my transgressions. I figured they would, as businessmen
really like making money.
---
If you refuse a mandatory RTO order, you may be replaced with a
less productive employee. But from a company standpoint, allowing
you to violate it means others will demand it, and it may be a net
loss for the company to keep you.
graphememes wrote 14 hours 51 min ago:
most people forget this one
zombiwoof wrote 16 hours 53 min ago:
We are hired to support whatever closed door management agreements were
made. Mostly not even made for the company goals but the managers self
interest
BrenBarn wrote 16 hours 56 min ago:
This is another article that largely boils down to "Some people really
really like money."
prescriptivist wrote 17 hours 6 min ago:
Guess what: This has all changed with LLMs. The impact of the average
developer is proportional to the amount of code they ship in a world of
copilots (key word is "ship", not write) and that's why some of the
staff engineers I work with have 3 concurrent Cursor projects for the
same codebase in flight at the same time. These are some of the best
engineers I've ever worked with and they have drank the cool-aid of
volume over quality.
I'm keen to this because I maintain our CI systems and have become
acutely aware of the overhead of hallucinations breaking our CI tooling
in pathological ways that draw me in to diagnose. A year ago I would
have to log into our CI Kubernetes cluster to diagnose a busted build
that doesn't self-report failure maybe... once a month. These days it's
a couple times a week. LLM based dev is both amazing in the legit force
multiplier it adds to writing code as well as the way it introduces
some of the most incoherent and silly ways it breaks existing
conventions.
I guess the headline is correct in that we are not hired to write code
anymore, instead we are hired to shepherd code now, and a lot of it.
And a lot of this code we shepherd is good enough but some amount of it
is bad enough to break existing processes, but that is secondary to the
volume and velocity we perceive from LLM code gen.
analog31 wrote 16 hours 19 min ago:
All bureaucracies evolve towards this state, be they governmental or
otherwise. The stuff that can be automated has been. (In past times,
it was automated in the sense of having clerks performing basic
repetitive tasks by hand). But no complex system can be fully
automated without breaking down frequently. The bureaucrats are no
longer hired to carry out the basic tasks, but to fix the system when
it breaks down. (In the past, they helped the clerks, or signed off
on a manual override of a process).
Because the automation is invisible, all that the naive observer sees
is the stuff breaking down and being fixed by hand, which looks like
utter chaos. And they're always drawn to wonder if the system would
work better if the people were replaced by automation. No, because
new people will need to be hired to keep the new system working.
prescriptivist wrote 16 hours 13 min ago:
Like the average observer who says the current conditions are
really just the old conditions born anew, you are conveniently
ignoring rate of change and its destabilizing effects.
_heimdall wrote 16 hours 41 min ago:
What you're describing is the erosion of engineering and computer
science in software development.
We've turned what can be an engineering discipline into code
slinging. I'll say my opinion is more focused on web development ad
that's been my focus for the last 8 or so years, but I don't think
that's unique to web either.
I don't use LLMs to help with coding, for many reasons that likely
aren't important to go into here. I ship more code than most of my
colleagues and I end up chasing down fewer bugs and production
regressions along the way.
I don't have any problem with devs using LLMs if it makes them more
productive, though that depends entirely on how one defines
productive. As you said today it generally means shipping more code
and has almost nothing to do with quality, which I'm just not willing
to waste my time chasing. I'll ship quality code that I understand,
and its either valued by my employer or it isn't.
yoyoyoyop wrote 17 hours 0 min ago:
Can you explain why they have 3 concurrent cursor projects for the
same code base?
trashchomper wrote 16 hours 30 min ago:
I assume they're trying to work on three features at the same time
prescriptivist wrote 16 hours 23 min ago:
Exactly, if you are doing copilot driven dev, then you are in a
feedback loop with the agent and it's easier to have multiplexed
ongoing "conversations" with the agent across discrete checkouts
of the same codebase than it is to ask an agent to make a change,
commit, checkout another branch, wait for the context to
update/become aware, ask for a change, agree to it, commit, then
switch back to another context.
It's the kind of thing git worktrees was made for.
alexjplant wrote 16 hours 48 min ago:
Presumably to crank out multiple features at the same time. After
spending some time writing project rules for Cursor I've gotten it
to reliably implement end-to-end CRUD operations from a simple
description of the fields and functionality. It's pretty neat and
surprisingly accurate but it does take time to generate on the
order of ~1k LOC so I understand the desire for parallelization. If
you have a well-factored codebase with loose coupling, good
abstractions, etc. this should be pretty doable without them
stepping on each other.
yawnxyz wrote 17 hours 11 min ago:
if this was true, then leetcode wouldn't be the cost of admission?
Manuel_D wrote 16 hours 33 min ago:
Writing code may not be the ultimate objective of software
developers, but it is one of the primary tools to achieve that
objective.
jimbob45 wrote 16 hours 42 min ago:
The articleâs argument was that the company was able to migrate
away from his code quickly, so his code didnât matter.
Thatâsâ¦an argument. I think most developers, myself included,
find the idea of migration to be almost impossible in many cases. The
author handwaved that away too easily.
dev_mike12 wrote 17 hours 22 min ago:
Thoughtful perspective on the challenges of contract work. Clear
communication and well-defined scope are indeed critical. I'd add that
working with clients you trust and believe in, even if it means saying
no sometimes, makes a world of difference in consulting. Thanks for
sharing your experiences!
vincenthwt wrote 17 hours 37 min ago:
In other words, software engineers need to "sell" the value of their
work.
AliveShine wrote 15 hours 25 min ago:
they like to call it "impact"
don-code wrote 17 hours 40 min ago:
I have a coworker who _excels_ at writing code - one of those engineers
who can metabolize caffeine directly into code.
They write code to implement the all-important features. They write
code to work around lack of process. They write code to work around
problem people not doing their jobs well. They write code to work
around buggy code by other developers. They write code to work around
their own code, written weeks or months earlier.
I've been encouraging them to _reduce_ the amount of code they write,
and instead consider the context around why they're writing the code.
Code is just one way - and not always a particularly good way - that we
can solve people and process problems.
ck425 wrote 4 hours 7 min ago:
Best Software Engineering advice I ever heard was at a conference
talk by a guy called Dan North: "Think of code like surgery".
Basically Surgery is a means to an end (patient gets better) and a
useful tool for achieving that but it's also dangerous so only used
when necessary. If other treatments can fix the problem you try them
first. If surgery is required you only do the minimum required to
treat the issue.
Code is similar. More code means more maintenance, more tech debt,
slower deliverables in future and higher risk of dependencies no one
understands. So when coding ask "Can I fix this without code?"
because if yes it's often easier in the long run and "What's the bare
minimum/simplest code I need to write to fix the issue?".
stephenbez wrote 17 min ago:
That's a really interesting metaphor. I worked with Dan years ago.
It seems like the talk was at CraftCon 15 and called "Beyond
Features: rethinking agile software delivery with Dan North".
I couldn't find it, but I found a similar talk he gave at a meetup
that discussed surgery: [1] or
URI [1]: https://youtu.be/EoJFWdhv8q0?feature=shared&t=1564
URI [2]: https://www.youtube.com/watch?v=lz5HBtDl-1A
pydry wrote 9 hours 39 min ago:
I'd be trying to make better use of this tendency and talent, not
trying to curtail it.
MultifokalHirn wrote 8 hours 6 min ago:
you are clearly missing the point, and probably feel like you have
that tendency and talent yourself
pydry wrote 6 hours 50 min ago:
Not at all. Im more of an all rounder. I just like to see people
matched to tasks which suit their temperament and talent.
I hate seeing people who would rather be doing customer
interaction half heartedly refuctoring while people who live and
breathe code sit on customer calls bored out of their minds.
I also feel a little disgusted at seeing talent wantonly
squandered unnecessarily.
mcv wrote 13 hours 41 min ago:
I try to write as little code as possible. I do love writing code,
but I've learned to love removing code even more.
The big problem in many companies is that often programmers are kept
out of that context. Problems are discussed without programmers, and
only tossed to programmers once non-programmers have decided what
they need to do. I think we need to be more involved in those
decisions.
mberlove wrote 4 hours 38 min ago:
Completely agree. This is a great insight. IMHO part of the growth
of a programmer is learning how the code fits the context, and a
large part of that is writing less code, not more, or getting rid
of some entirely.
xnx wrote 17 hours 41 min ago:
Code is a liability. Employees are a liability. Solving problems with
as little code/employees/risk/cost is the goal.
glitchc wrote 17 hours 20 min ago:
Business is a liability. Maybe society should do away with most
businesses and free up capital for more useful things.
reductio ad absurdum
lijok wrote 17 hours 45 min ago:
In most companies, writing code is the last thing developers (should)
do. You're there to achieve business objectives, and you were hired
because someone thought your experience and skillset will be necessary
to achieve those business objectives. Sometimes those objectives are
met with an excel sheet, sometimes they're met by losely integrating
various 3rd parties, sometimes they're met by integrating various
libraries, and sometimes it requires treading new ground and writing
some real code.
The best web dev isn't the one that knows .Net, React, Svelte, GraphQL,
micro-frontends, etc. The best web dev is the one that can convince
their manager that their business objectives can be achieved by using
WordPress.
dxroshan wrote 14 hours 32 min ago:
I disagree with you. According to your definition of best developer,
is one with a skill for persuade manager enough for building complex
we apps and services? A developer is hired to write code and they
achieve business goals by writing code and building software. Writing
code is the skill they have and that is why they are hired.
makstaks wrote 14 hours 35 min ago:
I think it depends on your company rather than saying "most". If you
are in a software company (i.e. you sell the software you write),
then your value is the unique IP you create from writing code. In
that case, hopefully a larger portion of your day is coding.
edit: When I say coding, I don't mean plumbing code, I mean something
that is actually a unique invention.
godelski wrote 16 hours 16 min ago:
I think your model has faulty assumptions. It makes the assumptions
that the companies and managers actually know what the business
objectives are. Or rather, what the business objectives that will
make money are. I think we all have seen examples where maybe an
afternoon's worth of work could fix some feature that is frustrating
users, but since there's not a clear "value" ascribed to it, it gets
pushed off. While simultaneously we've seen tons of money dumped into
things neither users nor investors want and that end up failing.
If we're handed an engineer title, I think we should be engineers.
Which requires you to be a bit "grumpy". That is because the job of
an engineer is to find problems and then fix them. I say "grumpy"
because it is your job to find friction in a system and remove it.
What I've often seen though is that acknowledging friction is
interpreted as rejection and not as part of the process to make
things better. Unless we get to the magic land of perfection, the job
of identifying issues and improving will always be extremely valuable
and naturally lead to increased revenue[0]. There's a lot of things
that go into making a product "good" and this can't be entirely done
from technical skills, but it is a critical aspect. Look at Steve
Job's Apple. The genius was the mixture of form and function. You
make computers that are powerful, have good software, AND the UI/UX
is far from a second thought. Good UI/UX and shitty code don't make a
good product, similarly neither does shitty UI/UX and impressive code
(backend devs don't rule the world)
> The best web dev is the one that can convince their manager that
their business objectives can be achieved by using WordPress.
Seems like your developer is a manager. This has perverse incentives
and I don't think this is the right way to frame things. As an
example, in law you wouldn't want a lawyer to win just because they
were better at arguing. Obviously this happens and a charismatic
lawyer can win despite the facts not being in their favor, but I
think we all can agree that this is not what we want a justice system
to look like. We want facts and the law to matter more while a
lawyer's charisma (or lack of) is an unavoidable fact of life. Just a
limit in the underlying mechanisms in which we communicate. Every job
has politics and you can't get rid of them, but you don't want
politics to rule the job. That wouldn't create the most value for the
company, though it might for a person at that company.
[0] Obviously you have to weigh the costs that it takes to fix
things. But identification is often cheap and easy. At least the
first step of identification anyways.
noosphr wrote 16 hours 34 min ago:
>The best chemical engineer isn't the one that knows the pressure at
which chlorine tanks fail, they are the one that knows chlorine gas
can be stored in a garage in coke bottles.
I look forward to the day that software 'engineers' are held
accountable to the same degree that all other engineers are.
I've written software for industrial machinery that can kill people
if it went wrong. It's amazing how much your views on software change
when you realize that your accountability starts at manslaughter and
goes up from there.
A human life is valued at around $10m in the developed world,
incidentally my first real job was fixing an excel spreadsheet that
caused $10m in trade losses after the API it called for exchange
rates went stale.
I'm not saying that we arrest everyone who writes a spreadsheet to
help them with their job. But _someone_ should have their head on the
line when it becomes a business process without oversight that can
cause millions in losses, damages or bills.
cced wrote 9 hours 13 min ago:
Developers should get the axe even though thereâs an entire
process behind pushing code out to production? QA, UAT? Surely
people sign off on whatâs being pushed out?
lijok wrote 10 hours 24 min ago:
I am very glad to hear the positive tone of discourse happening
under your thread. I've been arguing for regulation for the
software "engineering" "profession" for over a decade now, and am
usually met with dramatic recoil.
You don't need to write pacemaker firmware to produce severely
negative outcomes through ineptitude or indifference. I know of a
frontend developer whose UX mistake in a financial mobile app
triggered a vulnerable customer to end their life. I've heard
stories of people ending up in the hospital because of unmet,
unvoiced requirements for tasks delegated to junior developers.
It's a strange world we live in where the "profession" with the
most (usually unrealized) potential has no oversight.
Bob Martin said it best: We either regulate ourselves or we will
find ourselves regulated.
whstl wrote 10 hours 49 min ago:
I don't think this is gonna happen until we're able to say no to
stupid shit pushed on us.
When working as an electrical engineer I never had co-workers
fighting me on whether I should do stuff that goes against building
code. My building engineering friends never had a product manager
say "trust me, we don't need this load bearing wall".
I know of engineers who did stupid shit at work and got their
license revoked, and even some famous ones went to jail.
Of course there is the famous Steve Jobs story [1] where he forced
Burrell Smith to do a stupid PCB and it didn't work, but Jobs was
at least willing to accept that this was a test and would take the
fall for the spent money.
URI [1]: https://folklore.org/PC_Board_Esthetics.html
Wurdan wrote 13 hours 52 min ago:
I look forward to the day when "good code" becomes as obvious as
the best practices in some other engineering disciplines.
I like the Practical Engineering YT channel and one thing I always
find interesting is learning about all the research and guidance
that exists for things I never thought of. Like there are 400 page
documents on how to implement drainage in dams based on decades of
experience and post-mortem investigations when things went wrong.
But it feels like every time I'm involved in a software project,
we're starting almost from scratch and just incrementing towards an
unknown future which is "good enough". Even if you have a team of
experienced developers then the Best Practices at the start of the
project are not what they were 2 years prior. The tools that they
used on their past projects have evolved (or been deprecated). Or
maybe they're being asked to do a bunch of data engineering where
they previously did full stack Web development, because org
structures are fluid and many IT leaders feel that good engineers
can solve any problem with code (ignoring the idea of
specialisation).
This is not to disagree with your point, but more to say that a lot
of the infrastructure and professional norms around classical
engineering disciplines just aren't there (yet) for developers.
okwhateverdude wrote 12 hours 24 min ago:
> infrastructure and professional norms around classical
engineering disciplines just aren't there (yet) for developers.
I honestly doubt it will ever get there. Our profession pretty
much materialized over night in comparison to other disciplines,
and in a rapidly evolving environment, with a much broader
application. Only so many bridges/dams/buildings are built in a
given time frame and have such incredible capital costs, and
human life costs if they get it wrong. It makes sense to
carefully curate who and how those things get built. The vast
majority of software on the other hand, unless it is for
medical/construction/factory equipment that can kill people, is
usually super low stakes. And with the democratization of
programming in general, even your VBA-curious business analyst
can do it in their spreadsheet. Sure I can do the pro se thing in
court (and lose my life/freedom), read webmd and treat my own
cancer (and die), build my own dam (and flood my neighborhood),
but we gatekeep those professions because of the dire
consequences of fucking it up. Until software more broadly has
those kinds of consequences, there will be no licensure.
esperent wrote 14 hours 37 min ago:
> chlorine gas can be stored in a garage in coke bottles
I get the point you're trying to make but you absolutely can't
store chlorine gas safely in your garage in a coke bottle. If you
try doing this as a business, you'll get shut down hard and
possibly some prison time too.
On the other hand, WordPress is a valid solution for a huge number
of businesses. Perhaps the previous commentor should have labored
their point and noted that the engineer's skill is required to know
when WordPress is a valid option, and also just as importantly,
when it's not.
But suggesting the use of WordPress is in no way comparable to
doing something illegal like storing chlorine gas improperly.
A better comparison would be to using an off the shelf chlorine
storage system versus developing your own.
For most companies, off the shelf will be the right choice, but
others are doing complex things that require them to develop their
own systems.
namaria wrote 13 hours 23 min ago:
I have a fairly obscure domain that gets absolutely bombarded by
wordpress related scans. This tells me two things: wp seems
pretty easy to misconfigure, and a lot of scripts are looking for
these misconfigurations. Based solely on that I would never
recommend it to a tech-naive business.
esperent wrote 13 hours 8 min ago:
We're talking about businesses who have hired a software
engineer to advise them on how to set things up correctly. I
don't personally have any experience with WordPress, but I
assume that it is possible to set up correctly, right? If you
hire an expert and pay them to do it, I mean.
Mountain_Skies wrote 16 hours 29 min ago:
I look forward to the day when software engineers have the autonomy
that licensed engineers have, so they can tell managers no and if
the manager goes around the engineer, the manager and the company
end up directly liable for the damage they create.
godelski wrote 16 hours 3 min ago:
These are in fact the same thing. It is because an engineer can
be held liable that results in them being willing to say no. In
general, they probably won't be prosecuted, but a common reason
for this is that there will be written records of engineers
telling management that there are concerning risks. This also
results in the job of a Professional Engineer, who is a person
who legally puts themselves on the line. They get paid very well
and for good reason, they have a lot on the line themselves.
I suspect that a big reason CS is not held to the same standards
is due to abstraction and that it is still new. But we do live in
a time where bad code can get people killed (control systems are
the easiest examples), just as building a faulty bridge will. I
just hope we don't need a Tacoma Bridge to cause change.
Obviously it is harder to figure out things that are more
abstract like Social Media (can provide both good and harm).
But I'd say, you can always say no. If you're not saying "no"
now, that's still a choice you've made. A job is very persuasive,
and I'm not saying you're bad for just keeping your head down,
just that people should consider where they'd draw the line. The
line is personal and different for everyone (which is okay!).
Having taken traditional engineering courses, I'll note that
ethics is frequently discussed and you're likely to be told you
should try to define your line before you asked to cross it. If
you don't, you'll likely to cross the line without knowing, as
you just didn't know what it looked like. You can always redefine
the line as you get more resolution (it continuously updates) but
it's much harder to say "no" when you haven't given it much
thought.
necovek wrote 15 hours 33 min ago:
The main reason we are at a point we are is that it is possible
to build very complex software systems cheaply: both the tools
and building blocks are abundant and available to everyone.
If an engineer tried to build a skyscraper or a bridge, they'd
meet challenges other than them having knowledge or
professional certification.
And to your point, if anyone ever asked an engineer to insert
another floor between 8th and 9th floor of a 15 story building,
they'd laugh at them. In software engineering, this is possible
even if hard.
And finally, because of software living a much different life,
it will be hard to define criteria for good software.
whstl wrote 10 hours 46 min ago:
> And to your point, if anyone ever asked an engineer to
insert another floor between 8th and 9th floor of a 15 story
building, they'd laugh at them. In software engineering, this
is possible even if hard.
Bingo.
For building engineers this is chuckle worthy. For software
engineers, it's Wednesday.
godelski wrote 14 hours 26 min ago:
I think you misinterpreted. I mostly agree. But people do
program things like cars, planes, and other things that can
literally cost human lives.
The judgement isn't made on if mistakes happen, but if those
that built the thing should have known better. You don't get
sued when you legitimately don't know, but you can't be
infinitely stupid either. It's about if you should have
known. This does include things like not spending enough time
or research determining if something is safe, because you
can't just avoid answering a question that a reasonable
person would have asked. And it has to lead to harm being
done.
It can help to see what the lawsuits are about. Like Takoma
Airbags case[0] where they're being charged with knowing
issues. It's for knowingly doing something bad. But you can't
avoid asking questions, like in the Challenger Shuttle
disaster[1] both NASA and Thiokol ignored signs that the
O-rings being used were potentially dangerous and ignored
concerns from engineers. While they didn't know the O-rings
were defective in cold weather they should have known.
With more abstract stuff like Social Media, yeah, we're not
in clear cases that are doing harm. No one is going to be
prosecuted for inventing nor even building social media. But
you can have knowingly harmful practices like manipulating
users feeds without consent to perform testing to see if you
can make users more happy or sad[2]. The issue isn't that the
experiment happened, but that you're experimenting on humans
who did not knowingly give consent. You couldn't do that type
of a thing with people offline. Offline you need consent
before experiments. And you can't just say they'll subject to
any experimentation with no warning and grant this privilege
indefinitely. Because you should be asking if your
experiments might harm people and there's a reasonable belief
that it might cause harm.
And on the other hand, no one is asking that the devs at
wikipedia be sued or lose their programming license just
because they created a dark mode where the radio button has
an option of "system" but is defaulted to "light". Nor
because they didn't go to the lengths is would be to make
sure all images properly render when viewed in dark mode.
These don't cause harm. Annoying and easy to fix issues, but
no real harm has been done. Just petty issues.
It can definitely be fuzzy at certain points, especially as
all this is new, but it is also okay that things become more
defined over time as we learn more. The point is to keep
ethics in mind and to be thinking of the consequences of your
work. No one is in trouble if you don't hurt someone but you
can't walk around never considering the consequences of your
actions. It's the work version of not allowing an excuse of
"I was just following orders" or "I was just delivering them,
I didn't know what was in them". This is not some belief that
people should be sued just because they wrote shitty code.
But they could IF someone gets hurt AND you used AI to write
code because it is cheaper than a person AND knew that the
code being written could harm someone.
[0] [1] [2]
URI [1]: https://www.justice.gov/criminal/criminal-vns/case/u...
URI [2]: https://en.wikipedia.org/wiki/Space_Shuttle_Challeng...
URI [3]: https://techcrunch.com/2014/06/29/ethics-in-a-data-d...
nearting wrote 15 hours 9 min ago:
> And to your point, if anyone ever asked an engineer to
insert another floor between 8th and 9th floor of a 15 story
building, they'd laugh at them. In software engineering, this
is possible even if hard.
Ah yes, another cocktail party idea [1] where a software
engineer pretends like they understand civil engineering.
URI [1]: https://danluu.com/cocktail-ideas/
necovek wrote 5 hours 20 min ago:
It's great when you make a general statement about somebody
you are conversing with without really knowing their
background.
As Dan notes himself, even scenarios which are simpler than
this (moving a bridge, moving a building) are done much
more rarely compared to similar requests in software. I did
not accidentally use "modify something in a dimension
that's really hard to modify in civil engineering" as an
example â perhaps your response was a cocktail party
response of someone not understanding either civil or
software engineering?
IMHO, it is all about costs (which I start off with being
small in software â comparatively): traditional
engineering doing changes like these is extremely expensive
and thus they don't (it's usually cheaper to demolish and
rebuild).
godelski wrote 1 hour 37 min ago:
I really think you should read Dan's post in full.
Because you really did make the error him and Hillel
discuss. I think it'll also help interpret my point and
the gp to my comment. We're not thinking in a framework
where CS and Eng are all that different.
Or skip to this part of Hillel's video[0]
I've been an aerospace engineer. Worked there before
coming over to CS. And I can certainty tell you that yes,
someone may ask you to split a floor in half. There's
nothing really preventing you from doing this. There's
buildings with more levels than there are ordered floors.
It's a 15 floor building, but you label your floors 1-14.
Such an area can be used for things like running conduit
or even just as a fire break. Hell, there are even split
level homes, you know those ones where you walk in the
front door and either go up or down? There's also things
like scissor flats.
So yeah, you are making the mistake because your example
belies you. It illustrates that you aren't aware of the
complexities and abstractions in the engineering job.
It's okay to have only a rudimentary understanding of
engineering, you've spent your time learning other things
that are more valuable to you. But that doesn't mean you
should assume things are simpler than they are.
The truth is that any job, has depth and far more
complexity than appears at the surface. While in many
jobs you can get away with only doing the simple part,
there's still more depth than is actually being utilized.
Likely for the same common error. You are right about
cost being a big factor, but this is also a very
different argument than the one about floor 8 and a half.
[1] [0]
URI [1]: https://x.com/danluu/status/1484268111687663620
URI [2]: https://youtu.be/3018ABlET1Y?t=920
necovek wrote 38 min ago:
Again, you are making assumptions: I have read it in
full, and I have experience with construction as well.
> someone may ask you to split a floor in half
Yes, I've seen it done plenty times. It's especially
common with old houses which might have 4-5m high
ceilings around here and people do introduce new floors
in between.
Similarly, with pillars being carrying structures, it
is feasible to go and turn 3 floors which are 4m high
each into 4 floors ~3m high.
But while that's a way to interpret my "original ask"
(and all of your examples like hidden floors and such),
my intent was clear â in software, you literally go
and introduce a whole new thing between the two things
that were tighly coupled. Like actual structures above
a certain floor.
If your implication was followed in software (i.e. try
to predict the future and introduce hidden floors,
service floors and such) â and it sometimes is â we
really end up with worse, more complex software that
has technical debt built in from the start. IOW,
that's exactly not the way to build software.
Again, this does not discount the complexity of civil
engineering â it is freaking hard! But my point is
that it is DIFFERENT and that same approaches do not
necessarily work.
godelski wrote 14 hours 23 min ago:
Obviously never been to floor 7 1/2[0]
[0]
URI [1]: https://www.youtube.com/watch?v=T2Y7oo3iB40
compootr wrote 17 hours 20 min ago:
... or ones that can convince them not to use WP! (RE: matt
mullenwag's breakdown/mental issues)
sharkweek wrote 17 hours 23 min ago:
Oh wow⦠the WordPress exampleâ¦
Worked at a SaaS company that had a fantastic product and a great
tech team that had built it.
We also did a lot of data-based research and published it as white
papers for lead gen.
We wanted to start publishing more content on our site to expand
reach, so the team decided a CMS would be a solution for the
researchers and content marketers to publish without any tech
involvement.
Well it turns out our CTO, for a few justifiable reasons if weâre
painting with a broad brush, absolutely loathed WordPress. So despite
our arguments an integration would be easier/cheaper/less time
consuming for everyone, we built our own CMS instead.
And we, of course, ended up with a significantly worse version of
WordPress that the content folks all hated.
So it goes.
MPSimmons wrote 17 hours 51 min ago:
>Does it mean that we shouldn't write code or shouldn't try to get
better at it? Not at all. When working in a team, what matters most is
that the weakest developer be at the very least competent. The rest is
to try to build and maintain the company's product and features.
Yes. A company doesn't exist to hire programmers who write code.
Software development is a means to an end.
mickael-kerjean wrote 17 hours 39 min ago:
That's in theory, in practice a very large amount of companies only
hire dev to bring jira tickets to completion where engineers are kept
in a complete bubble and will never speak to a single actual
customer.
arealaccount wrote 17 hours 51 min ago:
In the same way a nascar driver isnât hired to drive, but hired to
win races.
Feels sorta pedantic.
Fun read nonetheless.
godelski wrote 15 hours 51 min ago:
Here's a less pedantic version:
An academic researcher isn't hired to do research, but publish
papers.
Similar to TFA, I think the issue is more about alignment than
anything. Goodhart's Law creeps up slowly and can destroy any
business or industry. Both can also stay off alignment for an
uncomfortable amount of time. In our research example, I think it is
clear we want our researcher to actually be doing research and that
paper publication is a (measurable) natural result of that work, but
it should be a bit more obvious to see that there are ways to
increase your publication rate without increasing your research rate
(or even increase your publication rate at the cost of your research
rate). (Obviously I disagree with TFA's point)
paulcole wrote 16 hours 13 min ago:
The driver helps create revenue the car owner (often in the form of
ad dollars). They may do this by driving well or they may do this by
dating a country superstar or starting fights with other drivers.
Sure at the end of the day driving is a big part of it, but itâs
not the only thing.
Thereâs what, 40 cars in the Daytona 500 and 39 of them lose. Are
those 39 bad at their jobs?
shermantanktop wrote 15 hours 52 min ago:
I know nothing about car racing and Iâll prove it: until your
comment I always vaguely assumed that the number of cars in the
Daytona 500 wasâ¦500?
paulcole wrote 7 hours 57 min ago:
The 500 is the length of the race in miles. Itâs 200 laps of a
2.5 mile track.
taneq wrote 17 hours 4 min ago:
I don't think it's pedantic at all. Your NASCAR driver is hired to
win races, not to drive. If they drive on the highway, or down to the
shops, or at the track when there isn't a race (or qualifying, or
testing, etc.) on, or they drive a different team's car, or their own
personal car, then they might be driving but they're not doing their
job. Their job is to drive that particular team's car in such a way
as to (directly or indirectly) win races.
In exactly the same way, a software developer isn't just hired to
write code. We're hired to solve problems. We usually do that by
writing code but that's not always the right approach. If your
employer told you they wanted to be able to control a Windows
computer from a different computer in the next room, I hope you
wouldn't start writing code, you'd just show them Remote Desktop (or
VNC etc.) If your employer wanted a web dashboard for your product,
you might write a bit of code, but you'd try and find some existing
dashboard project with an appropriate license, and hook your
product's metrics up to that. Writing code is a tool, of course, and
if there's no better way to do a thing (like if you're developing a
new product) then writing code is going to be necessary, but a lot of
times it's a tool of last resort.
chii wrote 16 hours 8 min ago:
if you hired a plumber, and asked him to fix the toilet, you expect
him to fix the toilet.
You don't expect him to tell you your whole house's plumbing sucks,
you have lead pipes and to properly fix the toilet you need to
replace it all.
Just do the smallest, cheapest thing to fix the toilet.
Replace 'fix the toilet' with 'writing code', for programmers.
cassianoleal wrote 7 hours 43 min ago:
I would absolutely love for the plumber whom I hired to fix my
toilet to let me know what other crap I missed in my house's
plumbing. Just doing the smallest, cheapest thing to fix the
toilet is sometimes desirable but if it's just going to cause
issues again soon, or if there are other issues I'm not aware of,
I'd better at least start planning for those!
Ekaros wrote 14 hours 26 min ago:
Handyman might be better analogue. And fixing should be either
change some parts inside the toilet bowl or swap whole thing.
What a software engineer would do is teardown bathroom with half
a building and build a new annex with squat toilet...
billfruit wrote 15 hours 55 min ago:
But software engineers are tasked with solving business problems.
Ofcourse writing code is part of it. But other things too, for
example communicating with users to understand requirements
better, which lead to a reduction in scope, which reduced the
code to be written.
Or sometimes it is found that a good solution can be devised but
which satisfies about 80 percent of the requirements, and it may
be prudent to attempt to negotiate to remove the 20 percent
requirements which cannot be satisfied.
chii wrote 15 hours 36 min ago:
> But software engineers are tasked with solving business
problems.
i would imagine that a business owner may want to hire a
business analyst to undertake such a task, rather than a
software engineer. Someone ideally with domain expertise in
such business problems.
A software engineer is trained to produce software, given a set
of requirements. If this software engineer is also tasked with
gathering these requirements, which somehow, is increasingly
the case now-a-days, then he's doing more than the job of a
software engineer - he's also doing the role of BA.
gitremote wrote 15 hours 12 min ago:
A lot of the times, the BA gives you wrong business
requirements, and an experienced software engineer can see
it's wrong by reading it, and refuse to start it until the
requirements are fixed. By "wrong", I meant there is a
logical contradiction, or there would be harmful logical side
effects because the BA can't play out the logic in their
head, or it's technically impossible, or the development
effort would not be worth it (for example, replicating what
Google took years to build as a nice-to-have feature for an
internal tool that isn't critical to the business).
skydhash wrote 15 hours 19 min ago:
Code isn't an output, it's just the final form of
requirements. The software engineer job is just going from
the informal talk about the feature to the formal nature of
code that implements it. Yes, you can have an experienced
person that broadly strokes the direction and have another
less experienced programmer implements it, but there's no
clear demarcation for the separation of role.
The real output is the shipped project, and sometimes your
own code is only a tiny part of it.
BoiledCabbage wrote 17 hours 18 min ago:
> Feels sorta pedantic.
Absolutely not. A Nascar driver isn't hired to drive to the grocery
store. Or to run errands. Their not hired to drive leisurely. They're
not hired to be the safest driver. They're not hired to drive the
absolute highest speed either (and crash). Their hired to win races.
And it's important to understand that.
The difference is that in Nascar it's very visible to everyone when a
Nascar driver is driving in a way other than what they were hired
for, it's not as clear for a programmer. Not to mention success as a
programmer also means doing many things other than programming,
including knowing when to say "we shouldn't build this".
mitthrowaway2 wrote 14 hours 56 min ago:
But they're also not hired to simply "win races". You don't hire
them to tinker with the car's engine, invent a
tire-traction-enhancing additive, lobby for rules changes that
favor your team, subcontract the driving to a better driver, or
play loud music to disrupt the sleep of the opposing drivers on the
night before the race. You hire them to drive the car well enough
to win, because driving is the skill you hired them for.
You don't hire them to drive Ubers, sure, and likewise you want
your programmers to be building things of high value. But you also
don't expect them to just walk into the CEO's office, sit down in
the big chair, and say "Actually, rather than writing code I can
contribute more value from here, so today I'll do this job."
defrost wrote 17 hours 24 min ago:
More in the manner a foreman is hired to deliver cars to end
customers.
A nascar driver seems like overkill, competent drivers that can
deliver cars without speeding, truck drivers that can load up and
move 10 cars at a time, managing a team of subcontractors who can
drive on demand as needed, etc. all seem like better options.
MathMonkeyMan wrote 17 hours 52 min ago:
The jobs I've had are about figuring out what to do, modifying code,
and communicating why to other people.
It's fun to create a new thing or to remove an old thing that isn't
needed anymore, but that's just when you can get away with it.
upghost wrote 17 hours 54 min ago:
I mean its no wonder "vibe coding" is so appealing if this is the
incentives framework. Why put brainpower in if it is treated as
disposable junk. Just tell the AI to vibe out some slop and move on --
"business" can't tell the difference anyway.
FWIW-- I resist this mindset, but I am sympathetic to it, I understand
where it comes from. Pearls before swine and whatnot.
DIR <- back to front page