
Just a Techie? – Techies, Devs, Boffins and Geeks - yogthos
https://juxt.pro/blog/posts/dev-not-just-a-dev.html
======
SoulMan
Very short article (which I like) and some great points that have been
occupying my thought process lately.

Every other day our local newspapers mention the word "techy" to describe
someone work in IT, he could be a product manager or an operations manager in
facilities, just because he is in Silicon Valley of India.

The agile example is great. We enforced something which works for assembly
line where things are repetitive and we know how much time it takes exactly to
assemble two parts of a car. Software Development is could not be more
different than this. We want iterative development yet we need to have fixed
deadline.

We don't trust the developer, we hire a scrum master who in most cases just
moves stories in Jira if a developer forgets to do it religiously. In that
process, we (read middle management ) are happy to have stories in "done"
section but have a problem with "in progress" section tough later is likely to
have higher quality. Because earlier one looks good on paper.

I have seen when scrum master/co-ordinators / middle managers when getting a
tech-related question from other teams or execs, they loop the engineers
saying "rookie question".Really just say "I don't know anything about
engineering that my team does"

Also the "IC track" for engineers? Seriously if someone works in teams that is
engineering teams. Why should they be called "Individual contributor"?

IMHO, if engineers were little more disciplined we did not need middle
managers or these dedicated agile coaches, scrum masters who neither has any
tech skill nor has any vision, unlike the leadership / executives.

~~~
badpun
The scrum masters feel 100% like a scam to me. The "work" they do is a
complete joke - they basically have a couple of rigid scripted behaviours that
could be performed by a bot or an intern - ask people about tickets' statuses,
ask if a ticket cannot be split into smaller ones, ask people to do estimates,
ask if X can help Y on task Z etc (all these questions are so basic that in
general any experienced dev has already asked them themselves in their heads
before coming to a standup). Also, from what I'm seeing, they "work" maybe for
1-2 hours a day. The only redeeming factor is that they usually make way less
than a senior dev (at least here in Europe).

I suspect Scrum Masters will be completely purged out of the industry in the
next 10-20 years, as the execs realise they provide negative value (sadly,
they'll probably be replaced by some other fad role, and the same people who
are scrum masters now will just retrain into that fad).

~~~
SoulMan
The dedicated Scrum Masters I think already started to be diminishing, in my
last two jobs usually one of the engineers (not too senior or junior but
should be able to communicate well) is asked to take that role along with his
usual 8 story point a week coding responsibility.

But unfortunately in this case above scripted behaviour is being shown by
middle management (Engineering manager with not much coding background ). This
is because they are mostly under fire if there is a "Spill Over" . The
engineer playing scrum master role can easily get away with it because the
probably did their part in the coding front and just threaten to step down
from the role. But managers don't add much to anything else in the delivery
process, so they are forced to be accountable for everything. (C'mmon we all
know appraisals are also pretty much scripted) .

------
ravenstine
One of the reasons developers will never garner even 1/3 of the respect of a
surgeon is that our mistakes can almost always be fixed. If a surgeon makes a
mistake, that can ruin a person's life or even end it. We have so much wealth
that we can afford to devalue programmers and put up with bad code, but
there's yet to be an affordable way to completely reverse a severed spinal
cord for even the richest.

------
cbkeller
> There’s a destructive pattern inside of Agile software development of
> squashing individualism. Devs can’t be trusted to work solo, so pair them
> up. Devs can’t be trusted to think holistically about the problem at hand,
> so each 'story' needs to be written child-like. We demand TDD, a convoluted
> code-review and branch process, and antipatterns such as 'the big ball of
> mud' terrify us, so we must insist on nano-sized microservices to promote
> code shared ownership and polyglot diversity, so that each service can be
> rewritten at any time in any language, and no single developer can possibly
> ever become a bottleneck.

------
davemp
If "techies" assume as much personal liability as surgeons, then they may
deserve seen in the like.

Where are the malpractice suites for person info leaks of infrastructure
downtime?

~~~
masonic
A better analogy would be if the Lion Air crash resulted from a software
defect in the new design.

------
bklaasen
"It’s not simply the insidious dehumanisation and the patronising that bothers
me - which to be fair, is a human condition - rather it’s the attempted
commoditisation of what is a highly specialised trade. When you trivialise a
trade, you make the trades-people interchangeable."

This pushback has been going on since the very earliest days of the attempts
to professionalise software development. Here's Nathan Ensmenger in "The
Computer Boys Take Over":

"In response to this perceived challenge to their authority, managers
developed a number of interrelated responses intended to restore them to their
proper role in the organizational hierarchy. The first was to define
programming as an activity, and by definition programmers as professionals, in
such a way as to assign it and them a subordinate role as mere technicians or
service staff workers. As the sociologists Haroun Jamous and Bernard Peloille
argued in their groundbreaking study of the organizational politics of
professional development, this technique of reducing the contributions of
competing groups to the merely technical is a time-honored strategy for
defending occupational and professional boundaries. We have already seen some
of the ways in which the rhetoric of management literature reinforced the
notion that computer specialists were self-interested, narrow technicians
rather than future-minded, bottom-line-oriented good corporate citizens.
“People close to the machine can also lose perspective,” maintained one
computer programming “textbook” for managers. “Some of the most enthusiastic
have an unfortunate knack of behaving as if the computer were a toy. The term
‘addictive’ comes to mind.”"

------
jm__87
I think our society tends to offer respect and status to others for some
specific (mostly superficial) reasons, and developers usually don't meet the
criteria. I can think of a few different cases of this:

1\. I feel society respects people with authority over others and most
developers have none. Most of us are just implementing someone else's high
level idea (granted, a great idea implemented poorly can be useless, so good
developers are very important in fact. It just isn't clear to an outsider as
to why).

2\. We also respect others who have great social skills, but the word "coder"
or "developer" tends to conjure up an image of some guy sitting behind a
computer screen by himself for hours on end (if you knew nothing about what a
software developer really does). Some devs will have good social skills, some
will not, but I would imagine the average developer job does not necessarily
require it.

3\. The stakes matter. If a developer screws up, you revert the change or fix
the bug and most of the time the worst case scenario is that the company lost
some money (with some exceptions like those who work on self driving cars or
autopilot). Doctors are dealing with peoples lives. Law enforcement,
firefighters and military risk their own lives for others. Lawyers and high
level executives at larger companies work in positions where the economic
stakes are often high, not just occasionally.

4\. We respect those who are at the top of their respective field. With
software development, there is nothing that those at the top of the field are
displaying to the public that differentiates them from anyone else in the
field (that the average non developer can understand, anyway). This is very
clear if you're an athlete or professional musician.

I would say that software developers as a group are usually fairly intelligent
people with respect to technology. I think referring to someone as a "techie"
does not make an assumption that someone isn't knowledgable about the domain
of tech, but may come embedded with an assumption of lower status (with
respect to the points I mentioned above).

As a developer myself, I do sometimes regret my choice given the low status
that this job carries (at least in North America - perhaps in other parts of
the world this is different) in spite of the fact I get paid fairly well. On
the other hand, I enjoy writing code and solving difficult technical problems,
so if I just forget about what people I don't know think about me, then the
job is great. Hard to beat a comfortable, high paying job where I get to work
on interesting problems and mostly get to avoid the annoying political battles
that are often ongoing in large orgs.

------
collyw
Beancounters, suits and normies are the ones calling us techies. There is
really no need to get upset about the labeling. Most of the time I see techies
looking down on other departments at least as much as they look down on us.

~~~
SoulMan
Like "techies" look down upon testers?

~~~
collyw
Testers are techies I would assume.

------
nobodywillobsrv
x100. Let's stop using the inactive words "developer" or "engineer" to
describe people.

Instead say things like we need to get some people to "build it" or "make it
work" or "figure out what is the best". It is how managers obliterate their
workers and claim all credit.

I like to use the word "human" in these cases to emphasize what is going on.
"We need three developers" vs "We need three humans". The latter emphasizes
how ridiculous and dehumanizing it is (unless you are a contractor and paid up
front).

Managers are basically just schedulers at best. A good leader is someone who
actually risks their time, reputation or capital.

Management structure would be fine if they were literally given a pot of money
that they could pay themselves or contractors with and required to build
something. Anything else involving employees kind of results in dehumanizing
power structures once the size of the team gets big enough.

