
Software is a focus intensive industry - siscia
https://redbeardlab.com/2020/01/19/software-is-a-focus-intensive-industry/
======
sktrdie
Please let’s not reinvent concepts or words. We are not the chosen ones nor do
we live in a field that is different from any other.

Many other fields require the same mental capacities we employ: from doctors
to school teachers all the way to even accountants. They are literally doing
the same stuff we are doing: grabbing stuff that was already built by others,
thinking about it, discussing it, having meetings, etc.

I hate it when a community becomes so biased towards their own field in a way
that creates a bubble and interferes with actual innovation. This has sadly
been the case for the software industry.

~~~
terminaljunkid
> Many other fields require the same mental capacities we employ: from doctors
> to school teachers all the way to even accountants. They are literally doing
> the same stuff we are doing: grabbing stuff that was already built by
> others, thinking about it, discussing it, having meetings, etc.

Here I disagree. Doctors? It seems true.. But school teachers and accountants?
Nope..

I don't really think these fields compare, unless your 'software' is limited
to doing some outsourced CRUD work..

However much people tout against it, I believe software engineering is closer
to any other engineering (say Mechanical) than it is to other fields. Our task
is solving problems in efficient ways, and optimizing things for one thing or
another. Except these days unfortunately the bar seems very low..

~~~
saiya-jin
> Our task is solving problems in efficient ways, and optimizing things for
> one thing or another

Sounds literally like every other white collar job, or in fact ideally any job
ever. I agree with OP, we devs are sometimes a bit too full of ourselves, when
in fact mostly we have simply just another engineering work. I used to think
that way too when I was young, naive and inexperienced.

My wife is a doctor, and when I compare, we have it too easy considering our
compensation. When was the last time your bug killed a human being / destroyed
their health for good? When was the last time when you got dragged into court
for a bug you submitted 3 years ago and jail with permanent loss of license
was a real option? Getting 25$ for 12-hour weekend nightshift?

Instead we have remote work, digital nomads and people humble-bragging about
400k FAANG compensations being at the low end and barely livable.

~~~
rodrigo975
Just a short list
[https://en.wikipedia.org/wiki/List_of_software_bugs](https://en.wikipedia.org/wiki/List_of_software_bugs)

* By some accounts Toyota's electronic throttle control system (ETCS) had bugs that could cause sudden unintended acceleration

* The Boeing 787 Dreamliner experienced an integer overflow bug which could shut down all electrical generators if the aircraft was on for more than 248 days

* In early 2019, the transportation-rental firm Lime discovered a firmware bug with its electric scooters that can cause them to brake unexpectedly very hard, which may hurl and injure riders.[6

* A bug in the code controlling the Therac-25 radiation therapy machine was directly responsible for at least five patient deaths in the 1980s when it administered excessive quantities of beta radiation

Now we have to sit and wait for the autonomous vehicles:
[https://en.wikipedia.org/wiki/List_of_self-
driving_car_fatal...](https://en.wikipedia.org/wiki/List_of_self-
driving_car_fatalities)

~~~
saiya-jin
Yeah and that's what, 0.1% of all software devs globally that can potentially
do physical harm? Most of us just hurl data between places and worst damage is
financial. You can't even compare the scales.

If you're a construction engineer, any serious flaw in any building you design
can kill, sometimes hundreds.

How many engineers of those few cases you mention went into jail and were
forbidden to work in software industry forever?

------
ken
> Unfortunately people get bored, especially in creative profession, when the
> product is mature, the job becomes more boring.

This is backwards, IME. I _want_ to maintain a system and make it run great.
Management is always pushing for some damn new thing, and features and
velocity over stability and quality.

~~~
coretx
Closely observe where they are creating technical debt for this can be your
future cash cow.

------
Syzygies
It is poor style to capitalize FOCUS throughout the article.

For example, when a mathematician starts reading a paper that uses too many
acronyms, they generally freak out. It's a strong signal that they've wandered
into the wrong part of town. While there is brilliant work done in applied
domains, one rarely finds it in acronym-heavy papers.

After a lifetime of reinforcement with this filter in place, it's very hard to
read FOCUS as anything but an acronym. That's not what you intend, so look
into styling your html with bold or italic emphasis?

(I was at a faculty meeting that was spending an unreasonable amount of time
debating an acronym for our salary committee, something that would reinforce
the message that there are other aspects of our compensation. My contribution:
"I love how Brits use short words for things. As a member of the most symbolic
department, I'd like to speak in favor of an acronym-free workplace." I got
the Provost evil eye.)

~~~
onreact
Yeah, also people who are blind and use screen readers will have it spelled
out char by char each time as its assumed to be an acronym.

Use bold, italics, text-marker effects instead.

------
onreact
The way you define focus sounds a bit strange to me. Focus is indeed needed
for programming - that's why you need to be in the zone when coding - but it's
the focus we refer to usually.

As we live in a frantic attention economy now focus is indeed very valuable as
dealing with the ongoing bombardment with distractions is truly expensive.

Just think about all those remote workers getting reminded all the time that
some new Slack, Flock, Skype, WhatsApp, Facebook, e-mail messages arrived.

All the companies above make money by hijacking our attention and forcing us
to focus on the work we do for them for free instead. Imagine us focusing at
the code instead.

------
cuillevel3
Maintaining focus is actually labor. Adding more devs might not help with a
late project, but it does help with building bigger systems. So, I disagree,
software is extremely labor intensive work.

~~~
cies
I agree with you.

> Software is not labor-intensive. Not many people are necessary in order to
> produce good software.

Not many people are needed to produce 500gr of good rice. And lots of people
are needed to produce something like all the software Google or MS maintains.

The specialty of software is the low cost of marginal products. This is the
new thing here, not labour intensiveness.

> On the contrary, Brooks’s law on software project management states that
> “adding manpower to a late software project makes it later”.

This has more to do with communication, collaboration and slowness of getting
up to speed when joining a software project.

~~~
fit2rule
Attention is not easily managed labor. This becomes extra complex in cultural
environments - industrial/work - which do not strive to promote commonality of
attention among the group members, such that it fosters communication, and
ultimately .. production.

This is clearly visible in the HR requirements practices. Companies which have
a confidence in their ability to manage the on-boarders' attention, tend to
interview for communication rather than experience - those who haven't made
the investment in attention-management techniques, such as great training,
technical on-boarding routine, etc., tend to focus on _experience_ over
sociability.

>Brookes' law

I've found, with 30 years of experience in software development from both the
trenches to management and back, that there is an aspect of this law which
goes ignored - "Adding manpower to a late software project makes it later, but
adding documentation to a late software project makes it easier to add
manpower.."

The better you document things so that strangers can understand them, the
easier time you have on boarding strangers and getting them up to speed. This
is a cultural mechanic, and alas is usually in the wrong persons' hands - i.e.
HR, upper managements, etc. Technical people need to get this _right_ for the
true fire to burn ..

~~~
cies
> "Adding manpower to a late software project makes it later, but adding
> documentation to a late software project makes it easier to add manpower.."

I think this is shared by all big engineering works.

> This is a cultural mechanic

I'd call this "structural" instead of "cultural", where I am of the opinion
that culture is implicit and structure is explicit in nature.

~~~
fit2rule
Interesting, I would reverse those terms entirely: culture is explicit (it has
to be continually re-told in order to persist) whereas structure is a
consequence of the natural form of life, imposed upon the laws of the physical
universe.

I wonder how we came to such abject differences?

~~~
cies
Indeed interesting. Someone told me long time ago: if you dont provide
structure at the job, people will find a shared method of working but it will
be culture then (harder to change, mostly implicit).

This stayed with me. I think I recently read a similar statement again in some
text.

------
draw_down
Why do we think our field is so special and unique and different?

