
Things I Believe About Software Engineering - turingbook
https://blog.wesleyac.com/posts/engineering-beliefs
======
neilwilson
I'm with Dijkstra

"Our intellectual powers are rather geared to master static relations and ...
our powers to visualize processes evolving in time are relatively poorly
developed. For that reason we should do (as wise programmers aware of our
limitations) our utmost to shorten the conceptual gap between the static
program and the dynamic process, to make the correspondence between the
program (spread out in text space) and the process (spread out in time) as
trivial as possible."

As Systems Engineers we're probably better than 99% of the population at
visualising the dynamics of the system, and even then we're still pretty bad
at it.

Humility in the face of this human limitation helps enormously I find.

~~~
dickjocke
Can anyone give me examples of what trivializing the correspondence between
the program and the process looks like?

~~~
hu3
* Tests

* Types (Classes, Structures, ...)

* State management

* Documentation

* Formal models

------
jmull
> Most measures of success are almost entirely uncorrelated with merit.

A more important and useful thing to understand is that merit is measured by
rules that bubble out of social systems.

A mistake you can make is to believe the the rules of merit that you believe
are the same ones others believe, that the ones they state are the same ones
they actually believe, that the rules don't depend on context, etc.

It's hard for people to accept this because we're taught that merit is an
inherent quality, we may internalize the rules of merit we learn, treat them
as constants, and then build our self-images based on those rules.

(I'm not suggesting to give up on the idea of merit altogether, but you'll do
better to think of it as something you achieve for personal satisfaction and
not necessarily expect external rewards.)

BTW, the rules of success (beyond the most basic stuff) are also social
constructs, but they are different than the rules of merit. It's a mistake to
expect them to necessarily be harmonious or consistent.

~~~
crimsonalucard
I don't agree with 'most.' Our schooling and educational systems are very
merit based.

One could say that in the work place, success is uncorrelated with merit.

~~~
thewebcount
> Our schooling and educational systems are very merit based.

I'm not sure where' you're based, but that's certainly not the case where I
live. I once worked for a company that made grading software. I quit after 3
months because they wanted to implement features like, "Teacher wants to be
able to change grade to a specific letter, even if student's scores add up to
a different letter grade." (In other words, even though this student received
an "A" based on test scores, I want them to have a "C" instead. Or vice-
versa.)

~~~
johntran
I took Calculus AB in high school and the teacher was notorious for giving
students D's and F's because of his teaching style was poor and the exams were
difficult. The only saving grace from that class was that you would be given a
C if you scored a 4+ on the AP exam.

He still kept his job because majority of the class got 4+'s on those exams,
despite at least 1/3 of his class getting D's and F's.

I wouldn't generalize editing letter grades as a way of "cheating the system".
There's usually good intentions in every act.

------
einpoklum
> Being aligned with teammates on what you're building is more important than
> building the right thing.

So, let's cave in to peer pressure or management dictates and continue down
the wrong path (technically/socially)?

Strongly disagree with that.

> Peak productivity for most software engineers happens closer to 2 hours a
> day of work than 8 hours.

Here I mostly agree. The thing is, that you don't know in advance when these
hours are going to happen. Also, sometimes it's 2, sometimes 0 and sometimes
8.

> The amount of sleep that you get has a larger impact on your effectiveness
> than the programming language you use.

(Yawn) Indeed...

~~~
_petronius
> So, let's cave in to peer pressure or management dictates and continue down
> the wrong path (technically/socially)?

Seems like a very unfair restatement of what the author said. I would read
that as "it's more important that everyone has a common understanding of what
you are building than it is to spend time worrying about whether you have the
exactly perfect goal."

Or to phrase it another way: if the understanding of the product isn't clear
across the whole team, it doesn't matter if any one individual has a bunch of
brilliant ideas for/about the product, because you aren't all working towards
the same goal.

~~~
smitty1e
I'd offer that the "alignment" is substantially a function of the
management/leadership on display.

~~~
_petronius
Sure, but hopefully the choice isn't a binary one between "lack of alignment"
versus "management/leadership dictates", since that would be evidence of a
rather toxic team culture.

------
pmiller2
Here is my (unpopular? original?) opinion about software engineering: software
engineering is more like writing a novel than building a bridge. Bridges are
fairly well understood, and the parameters necessary to build them
successfully can be approximated very closely once it’s decided what materials
to use. Software will surprise you, in the sense of “no battle plan survives
contact with the enemy.”

You will have bad data in prod. Users will do unexpected things. You won’t
always be able to reach S3. And, this is all true even assuming the software
is written perfectly to spec.

Knuth has famously said he thinks reusable code isn’t all it’s cracked up to
be. It’s re-editable code that we ought to all be striving for. There are two
aspects to this. First, how often do you get to write entirely new code inside
a mature software project? Not often, I would wager, so why not make the job
as easy on future you as possible? Second, re-editable code needs to be
understood before it can be edited to extend it. This means we need to write
code for humans to read, and computers, only incidentally, to execute (I think
EWD might have said something to that effect).

~~~
kikimora
> You will have bad data in prod. Users will do unexpected things. You won’t
> always be able to reach S3. And, this is all true even assuming the software
> is written perfectly to spec.

Surprisingly this nonsense happens in a discrete setting where we can (in
theory, of course) enumerate all possible inputs. Again surprisingly we cannot
find effective way to automagically partition input space into equivalence
classes to assist us in testing.

Novel works in conjunction with our brains and it is not surprising that there
are no definitive rules or “good novel equation”. But programs implement
defined algorithms and super predictable. Yet creating them feels like writing
a novel.

I agree with your statement but at the same time it feels wrong that we find
ourselves in such position.

------
jwr
Couldn't agree more with every point listed. These are fantastic points.

I do not know the author, but reading these points makes me suspect he/she is
an experienced software engineer that has been doing this for many years now.

I expect that especially his first point (about being humble in the face of
software systems complexity) will provoke many hubris-filled comments. I fully
agree with the author: we are incapable of building complex and correct
software systems. This is why I am afraid of the hype behind self-driving
vehicles.

~~~
barrkel
I have a different expectation of correctness; absolute correctness is
impossible, in practice correctness is not a binary condition. Even if
something provably executes correctly according to spec, the spec may be wrong
(and probably is, since everything interfaces with humans eventually).
Everything is in a process of becoming; 100% correctness is not achievable,
but it's not desirable either - it costs too much; it just needs to be better
than the next best alternative.

~~~
AstralStorm
The proper goal is robustness. It is either achieved via clear indication of
failure and guidance on alternative solutions - so that the user can handle
it. Or by actually failing gracefully and handling as many error conditions in
an always reasonable way.

Usually letting user handle it is more general as long as the failures are
rare enough.

Internal correctness is perfectly achievable though. External (correct spec)
is not.

There are always some unhandled conditions, due to hardware or external
component failures...

------
andruby
> Being aligned with teammates on what you're building is more important than
> building the right thing.

I would write this as:

Building the right thing wrong is more important than building the wrong thing
right.

And I firmly believe that agreeing on _what_ you are builing is more important
than _how_ you are building it. Mainly because it is easier to change the
_how_ than it is to change the _what_.

~~~
karmakaze
> Building the right thing wrong is more important than building the wrong
> thing right.

I entirely agree with this, but don't think that's what the original point was
getting at.

> And I firmly believe that agreeing on _what_ you are building is more
> important than _how_ you are building it. Mainly because it is easier to
> change the _how_ than it is to change the _what_.

This seems like it should be true. In practice, I've found that the _how_ is
the part that gets embedded in the wet-ware of people/companies and is the
hardest to change.

Given an application written in a language with some framework, some
datastore, deployed to some cloud, it's actually exceedingly easy to make
another that follows that pattern and does a completely different business
function. Much more challenging would be to change those parts of an
application and keep it doing the same thing.

------
mtrycz2
> Writing non-trivial software that is correct (for any meaningful definition
> of correct) is beyond the current capabilities of the human species.

Bullshit. Humans have been sending computers into space for decades, and while
yes, some have had programming problems, most worked correctly, for a very
specific definition of correctly.

Thing is, NASA (and Russian and Chinese and Indian and ...) space engineers
have approached their challenges from the point of view of actual engineering,
while modern "software engineering" is all about craftsmanship, and just a
sprinkle of actual engineering to make ourselves feel good.

~~~
sacado2
And it's obviously not the developers' fault, but the clients/customers'.

You want a 100% bug-free web browser? OK, so let's define precisely and
formally what the browser is supposed to do. Then, you'll sign a very
expensive contract, and in 6 months to 1 year, I'll deliver the software, with
a formal proof it works as expected. Of course, the requirements won't change
during the development process, and any update after delivery will be costly
and will take time.

Now, who would want to pay thousands of dollars for a web browser that will be
delivered in a year and that will be obsolete as soon as a new fancy web tech
will be used everywhere else? I can't really blame the customer/client either.

But the thing is, "agile" requirements rely on craftmanship, not on
engineering. You can only engineer durable things. Buildings would crash
constantly, too, if they had to be updated each other week, ASAP, and while
keeping the costs as low as possible.

~~~
Silhouette
Your general argument seems reasonable, but it also doesn't necessarily
contradict the GP's point.

If we're going to build something non-trivial that is correct, we first need
to specify what a "correct" result would be, in some rigorous, comprehensive,
unambiguous form. That in itself is already beyond the vast majority of
software development projects, though not necessarily outliers like very high
reliability systems.

That is partly because the cost of doing so is prohibitive for most projects.
This is a common argument against more widespread use of formal methods.

However, it's also partly because for most projects the desired real world
outcomes simply don't have some convenient formalisation. The potential for
requirements changing along the way is just one reason for that, though of
course it's a particularly common and powerful one. There's also the practical
reality that a lot of the time when we build software, we're not exactly sure
what we want it to do. What _should_ the correct hyphenation algorithm for a
word processor be? How smart _do_ we want the aliens in our game to be when
our heroes attempt a flanking manoeuvre? If you're a self-driving car on a
road with a 30 legal limit but most drivers around you are doing 40, how fast
should you go and why? Once we get into questions of subjective preferences
and/or ethical choices, there often isn't one right answer (or sometimes any
right answer), so how do we decide what constitutes correct behaviour from the
software?

------
astura
>Being aligned with teammates on what you're building is more important than
building the right thing.

Goodness this is incredibly naive.

It can only be true _only_ if youre working without customers or stakeholders
and who the hell works that way other than hobbyists and startups that are
indiscriminately wasting other people's money? The vast majority of software
I've written (I'm outside the valley) is written for actual paying customers,
and it must be "the right thing," ie, _exactly_ what they paid you to build.

Beyond that, if you're, for example, writing an emulator and the emulator
works different than the system it's emulating that's a _failure_ no matter
how "aligned" your team is. Nobody will buy it and nobody would even use if
you gave it away.

~~~
sime2009
> Goodness this is incredibly naive.

Actually it demonstrates hard earned wisdom.

A team which isn't aligned will only produce a mess regardless of whether
their end goal was the right thing.

An aligned team may miss the target but they will be in a position to correct
themselves and pursue the target.

------
bartread
> Being aligned with teammates on what you're building is more important than
> building the right thing.

I don't buy this. I'm not sure these two things should be placed in opposition
(or at least tension) in this way. It makes for a nice soundbite but I don't
think it withstands scrutiny.

I've seen and worked in teams where alignment was great and we all worked
really well together but, at the end of it all, nobody bought the damn
product. I.e., we didn't build the right thing. Let's not kid ourselves:
aligning and working well together to build the wrong thing is somewhat
pointless (granted, you might learn some useful lessons along the way). Now,
if you take that team and then assign them to build the right thing you have
something really powerful.

~~~
mic47
I read it more like this:

If you are building right thing, but you are not aligned, then you will not
build the right thing and you will fail. But if you are aligned, it's easier
to steer the ship closer to the right thing.

~~~
k__
Sure.

But I've seen too many dev departments building crap over and over again and
feeling pretty good about themselves the whole time.

~~~
6510
I wonder how few wrote something that in their own opinion wasn't crap and did
something impressive.

~~~
k__
Technically maybe.

------
cryptica
Based on the title, I was especting yet another opinionated story written by a
successful outlier littered with biases, but actually every point resonated
with me. Maybe this article illustrates the difference between sharing
knowledge and sharing wisdom.

Knowledge can be divisive because it's often communicated through rigid (black
or white) statements and founded on outlier experiences but wisdom is
generally not divisive; wisdom usually doesn't get people as excited but it's
also harder to refute; wisdom is knowledge without the bias. There are plenty
of extremely clever (and extremely biased) developers, but very few wise ones.

I tend to think that upvote/downvote mechanisms (Like on Reddit and HN) are
somewhat of a threat to the sharing of wisdom because wise ideas don't create
that dopamine rush which clever ideas do (they don't trigger the strong
feelings required for upvote/downvote). Wisdom is rarely surprising or
controversial.

Even discussing the idea of wisdom seems to be taboo. As if it's some kind of
outdated concept; but the irony is that it's more relevant now than ever.

------
AJRF
> "Read the classics. So many “new” ideas in software development have
> actually been around for decades."

From the original post that inspired this post:
[https://gist.github.com/stettix/5bb2d99e50fdbbd15dd9622837d1...](https://gist.github.com/stettix/5bb2d99e50fdbbd15dd9622837d14e2b)

What would HN say are the "classics"?

~~~
stronglikedan
I don't know if it's a "classic", but I recently picked up a copy of _Wicked
Problems, Righteous Solutions: A Catalogue of Modern Software Engineering
Paradigms_ [0] after reading through another HN thread on good software dev
books. I haven't cracked it open yet though.

[0]
[https://books.google.com/books/about/Wicked_Problems_Righteo...](https://books.google.com/books/about/Wicked_Problems_Righteous_Solutions.html)

~~~
varrock
Can you link the HN thread about good software development books?

------
hliyan
By some remarkable coincidence, @JanStette's version of this (1) and mine (2)
have a lot of overlap. Maybe we should all write a version of this and see if
common themes emerge.

Jan and I clearly agree on coding, design and testing, for example.

1\.
[https://gist.github.com/stettix/5bb2d99e50fdbbd15dd9622837d1...](https://gist.github.com/stettix/5bb2d99e50fdbbd15dd9622837d14e2b)

2\. [http://zen.lk/2019/08/18/Things-I-
believe/](http://zen.lk/2019/08/18/Things-I-believe/)

------
tr1coder
> Peak productivity for most software engineers happens closer to 2 hours a
> day of work than 8 hours.

Is it possible to improve this by training? For example if I'm productive 2
hours and force myself to be productive 10-30 more minutes each day for a
number of days and when I'm comfortable with 2:30 hours of productivity, force
myself to be productive for 30 more minutes. Would this eventually lead to 8
productive hours? Or is burnout (or another complication) a more likely
outcome? Has anyone tried this?

~~~
veeralpatel979
For me, I think I can achieve 8 hours if:

\- I'm working on something I'm interested in

\- I feel like there's upside for me if the project succeeds

\- I can work in different places throughout the day, like my desk, my sofa,
in another room, etc. Not really possible in an office

\- It's a quiet area where I won't have people interrupting my flow state

\- I'm not blocked on things I need to know

\- I'm working on something that's been de-risked. I know what I need to do
and I know how to do it

~~~
marcosdumay
> \- I can work in different places throughout the day, like my desk, my sofa,
> in another room, etc. Not really possible in an office

> \- It's a quiet area where I won't have people interrupting my flow state

It's amazing how much an office fights against productivity.

~~~
ProZsolt
That's why I stay home when I need a long stretch of productive time on one or
two things.

But the office has upside when the task is not well defined or I work on a lot
of small stuff. At home, my brain will wander around more easily between
context switches.

------
DBYCZ
His last point is my favorite, I feel useless at work if I don't get decent
sleep. He should append working out and going for walks to that as well.

------
msla
> Writing non-trivial software that is correct (for any meaningful definition
> of correct) is beyond the current capabilities of the human species.

I think it's worse than this: Defining correctness for any nontrivial system
to the level of detail required by software is beyond the capabilities of any
human or group of humans operating to a deadline. The only way to get there is
to pare down the scope such that physically possible things are defined to be
out of said scope, such that the system punts and relies on humans to figure
it out.

This has implications for job automation.

> Thinking about things is a massively valuable and underutilized skill. Most
> people are trained to not apply this skill.

Attempting to prove yourself wrong is a massively valuable and underutilized
skill. If you get a theory, develop a test which the theory is vulnerable to,
such that if the test comes out a certain way the theory is disproven, and
then run that test. Some people seem unable, or unwilling, to think like that.

This has implications for software testing. It has implications for all kinds
of testing.

~~~
yetihehe
> If you get a theory, develop a test which the theory is vulnerable to [...]
> Some people seem unable, or unwilling, to think like that.

Because developing that test is often even harder than developing theory
itself and developing nontrivial theory requires ALL of your mental effort.

------
karmakaze
> Being aligned with teammates on what you're building is more important than
> building the right thing.

It depends. If iterations are quick and the current direction is roughly on
the path to finding the right thing yes, otherwise no unless you are choosing
to redefine software engineering.

------
loxs
> The amount of sleep that you get has a larger impact on your effectiveness
> than the programming language you use.

For me this is not true. The type system has a bigger impact on me. If I use a
language with static types + IDE, I am quite productive even while chronically
not getting enough sleep (currently looking after a newborn). Probably much
more productive compared to writing in a dynamic language while getting enough
sleep.

And of course, that does not mean that sleep is not a huge factor. It most
definitely is.

------
lordnacho
> Most measures of success are almost entirely uncorrelated with merit.

This is life in general, no? Aside from maybe professional sports, where it's
forced to be that way by design.

------
antirez
> There are many fundamental discoveries in computer science that are yet to
> be found.

That's a strange claim. It could be, but there are large evidences that we
discover most of the fundamental things immediately up to the 80s, and then
the other improvements are kinda really incremental, a program from 1970 is
not alien today. Technology of computing progressed a lot more than CS itself,
a computer of 1970 kinda is alien, and a toy.

~~~
wry_discontent
Your description of how things are is exactly how Thomas Kuhn describes the
process of "Normal Science" in The Structure of Scientific Revolutions. Cracks
in our understanding grow, and patchwork theories are put around those
contradictions, but eventually the dam breaks and a scientific revolution
reshapes the way we think about a subject.

------
l0b0
> Being aligned with teammates on what you're building is more important than
> building the right thing.

It's important to define the terms here. Does "important" mean important to
_you_ or the company? I could understand the former, but how are you ever
going to build the "right thing" if you can't agree as a team what you're
building?

------
BigJono
> The fact that current testing practices are considered "effective" is an
> indictment of the incredibly low standards of the software industry.

This is an interesting one. I first took it to mean 'current testing practices
are inadequate', which isn't an extreme opinion, and one I bet 99% of HN
agrees with. It's 'common wisdom' that teams should be doing more testing,
TDD, etc.

But now that I read it again, it's specifically saying that current testing
practices are 'ineffective', not 'inadequate', which would indicate we should
be doing less or even none of it. 'ineffective' to me means worse than
nothing, since testing, like anything, has a cost. (time wasted, more code to
maintain, lower morale etc)

I'm not sure which the author meant. But I do think the latter is a hot take,
and I get the feeling I'm in the minority in agreeing with it.

I'm reminded of this PG quote (obviously written a while ago):

"Indeed, these statistics about Cobol or Java being the most popular language
can be misleading. What we ought to look at, if we want to know what tools are
best, is what hackers choose when they can choose freely-- that is, in
projects of their own. When you ask that question, you find that open source
operating systems already have a dominant market share, and the number one
language is probably Perl."

If I think about what I've written unit tests for at home, that'd be a bunch
of maths-y stuff that I was having trouble debugging, and a few functions here
and there that I consider 'tricky' and want a bit of extra peace of mind for.

When I'm building web apps at home though, like I always do at work, how much
of it do I write unit tests for? Zero. I can't quantify why. I just _know_
intrinsically that they're useless and it's a waste of time. I just _know_
that 95% of my code works and I _know_ what the 5% I'm unsure about is and
what manual testing or browser testing I need to do to clarify it.

If anyone on my team at work ever said that, everyone would look at them like
they just took a shit on the carpet (including me, because I'm happy to smile
and nod for the right salary).

Then there's this, from the same essay:

"One difference I've noticed between great hackers and smart people in general
is that hackers are more politically incorrect. To the extent there is a
secret handshake among good hackers, it's when they know one another well
enough to express opinions that would get them stoned to death by the general
public. And I can see why political incorrectness would be a useful quality in
programming. Programs are very complex and, at least in the hands of good
programmers, very fluid. In such situations it's helpful to have a habit of
questioning assumptions."

I definitely know a few coders I've worked with who I'd be comfortable raising
my views on testing with. We might differ on the details (I quite like browser
tests, don't find a lot of value in snapshot testing most of the time, we
might unit test a different tiny subset of the app etc), but by and large we'd
agree that most common testing is a crock. And coincidentally, they're all the
devs that I think write fantastic code, and that I'd happily build a startup
with.

Anyway, that's my Thing I Believe About Software Engineering, with a bit more
clarification than OP's ones.

~~~
skolsuper
High test coverage is mainly useful for code that will be worked on by more
than one person, so it makes sense that you wouldn't want to add it to your
personal projects. Doesn't mean it's not worthwhile.

~~~
bluGill
High test coverage is also more important for large projects than small, even
when working alone. I never write unit tests for hello world - it would be a
waste of time. I will write tests when I'm hacking on a large project even if
I'm alone because I know eventually I will make a change that breaks something
that used to work.

------
jingw222
Being perfectly aligned with teammates on everything but ending up with a
totally differently or straight wrong result. How do you justify that?
Otherwise I'm with OP.

------
karmakaze
> Peak productivity for most software engineers happens closer to 2 hours a
> day of work than 8 hours.

Pair programming can easily double that and the low productivity periods are
not nearly as low.

~~~
bartread
> Pair programming can easily double that and the low productivity periods are
> not nearly as low.

Pfft. Prove it.

People are very different and work best in different ways. I don't mind pair
programming for specific reasons but as a the "normal" way of working? You can
keep it.

Pair programming performed relentlessly selects for certain personality types.
I, for example, didn't get into programming because I wanted to sit around
talking all day. Far from it.

Programming is a creative endeavour, kind of like songwriting. Some people are
great solo songwriters, some people work well together, people often struggle
to cross that divide and, even if they collaborate well, may struggle to
collaborate well with everyone.

I can work effectively in a team but under most circumstances I cannot program
at my best with somebody hovering around or buzzing in my ear all time. And,
believe me, I am by no means unusual in that regard.

Mandatory pair programming is one of those things that, I think, seems like a
good idea to third rate management who don't want to take the time to
understand how the people on their teams can work together most effectively.

~~~
karmakaze
All good points and I was of the same opinion before I underwent almost 2
years of mostly pairing. My takeaways:

People are different. The core bunch came from Pivotal which performed pair-
programming interviews so were self selected. That accounted for about half
the engineering staff so the other half didn't undergo this process. I myself
have always been a solo developer so pairing was very unnatural at first and I
didn't pair well with everyone. We rotated pairs every week (sometimes two) so
that wasn't a big problem.

There are times when solitary deep thought is useful and breaks for that
activity could be taken at will while the other pair works on maintenance
tasks etc. Most of the time the work isn't of this type and more often less
complex requiring light whiteboarding or on-screen prototyping which both work
well when pairing.

The style of code that comes out of pairing tends to be more plain than when
working solo. There is incremental progress in both implementations and design
refinements when pairing. When working solo there tends to be grander designs
with a moment where it all comes together or not. I enjoy the latter but find
the former higher by average throughput. Pairing tends to eliminate more of
the 'might need soon' or 'will need in the future anyway' implementations.

After pairing with someone a few times, verbal communication becomes very
terse and fluid. An unexpected benefit was the ability to immediately resume
context after interruptions or breaks.

The biggest advantage of pair-programming that doesn't get mentioned much is
the organic spread of good practices and conventions. With approximately 20
devs it's not really worth writing and maintaining standards documentation and
conventions for handing new cases that keep appearing. With rotating pairs
this discovery of what works well and normalization upon it is natural. Minor
tips and tricks aside from the source code can also be invaluable power-ups
when learned by others.

Pair programming isn't about maximizing 'your own productivity' it's about
maximizing the productivity, quality, and consistency across all dev teams.

Within that period we also tried full-stack dev pairing. This was much more
challenging and didn't work nearly as well. We didn't stick with it long
enough to know if it could become more beneficial because basically people
self-selected into front or back-end development and liked it that way.

These are my findings from being both a solo and pair-programming developer.
If you're curious and have an opportunity I highly recommend trying to stick
with it for a while and see what your findings are.

------
karmakaze
> There are many fundamental discoveries in computer science that are yet to
> be found.

Purely in the realm of computer science and has little the no bearing on a
software engineering context.

~~~
falcolas
Except when it does. It's not fast, but these findings in CS find their way
into general software development. See: Rust, Haskell, Typescript, ML, Ray
tracing, and so forth.

------
EnderMB
I clicked this expecting an overly opinionated list on how to do things the
right way, but came away agreeing with nearly everything said.

> Writing non-trivial software that is correct (for any meaningful definition
> of correct) is beyond the current capabilities of the human species.

This is the one point I somewhat disagree with, and it leads to one of the
things I believe about SE - it's all about perceived risk. Mission-critical
systems work well because the risk is well-defined, and it's usually "people
will die". In business, managers are happy to break rules when the perceived
risk of it biting them in the ass is low. Small budget? Skip the tests, click
around on deploy to see if it works, and ship it. Not enough time? Deliver a
minimal product and build the rest later when we have the budget.

There are two examples I often use for this - Panera Bread and Pipdig. The
former leaked millions of customer records, ignored the press for a few days,
and got off with zero consequences. Pipdig did even worse, they did backdoors
and DDoS code to attack competitors in their WP themes/plugins, and when
called out they lied, hid the evidence, and then went back to selling themes
to unsuspecting bloggers with zero consequences.

Both sides likely knew what they were doing was wrong, but the risk of getting
caught was minimal, so why not break the rules? It probably saved them a ton
of money in the long run.

> Being aligned with teammates on what you're building is more important than
> building the right thing.

I've no idea why so many of you are up in arms about this. It isn't about
bowing to managers, or being a punching bag for others. It's about making
concessions as a group to define what you need to build, and the best way of
doing it.

> Peak productivity for most software engineers happens closer to 2 hours a
> day of work than 8 hours.

I'd stretch this to say that "on average". Some days I'll get 30 minutes of
stuff done, some days I'll fly through work for a solid 8 hours.

> Thinking about things is a massively valuable and underutilized skill. Most
> people are trained to not apply this skill.

This is so true it hurts. I'm currently working on a project in an agile
structure, and it's going like many agile projects I've worked on in the past.
Agile is used as a buzzword for "fuck planning, just write user stories and be
done with it", all while team mates bitch and moan about spending too long in
"planning" meetings. The second we took the time to actually have these
meetings and plan out our backlog, we made key decisions and discoveries about
how things work, what edge cases we need to think about, what doesn't work
from a user perspective, etc.

> How kind your teammates are has a larger impact on your effectiveness than
> the programming language you use.

Over the years, I've always believed that empathy is the best skill you can
have in software, and that is often paired together with kindness. An
empathetic team is often a kind team, and when empathy is a core part of a
team it highlights areas where certain stakeholders don't share that trait.

~~~
cambalache
To offer an opposite position I pretty much disagreed with --or at least would
heavy qualify-- with most points. The rest I thought were trivial.

> Writing non-trivial software that is correct (for any meaningful definition
> of correct) is beyond the current capabilities of the human species.
    
    
       Perhaps, but this is a worthless distinction, especially if the author does not define correctness. If it is mathematically correctness he is after I think experience has shown a program does not to be correct to be very very useful, and except for extremely critical situations is not a consideration. The same way a road does not need to be perfect.
    

> Being aligned with teammates on what you're building is more important than
> building the right thing.
    
    
       Hell no! Every leader would prefer to go in the right direction at 50% of maximum speed, that going 100% in the wrong direction.
    

> There are many fundamental discoveries in computer science that are yet to
> be found.
    
    
       True, but trivial. The same thing can be said about every theoretical branch of science like math and logic, and even for many experimental branches.
    

> Peak productivity for most software engineers happens closer to 2 hours a
> day of work than 8 hours.
    
    
      Perhaps, but if you work the other 4-6 hours at 25% of your peak you still would do more than double during the day. Besides, the 2-hour figure, although reasonable strikes me as anecdotic at best. If anyone knows about a study I would love to read it.
    

> Most measures of success are almost entirely uncorrelated with merit.
    
    
      Without a definition of merit, this is worthless. And for that matter, a definition of success is also needed.
    

> Thinking about things is a massively valuable and underutilized skill. Most
> people are trained to not apply this skill.
    
    
      Really? Thinking is a valuable skill?, who would have thought?
    

> The fact that current testing practices are considered "effective" is an
> indictment of the incredibly low standards of the software industry.
    
    
      Or perhaps reaching that "effective" threshold is beyond human capacity. I think this claim is pretty insulting to the software industry in general too.
    

> How kind your teammates are has a larger impact on your effectiveness than
> the programming language you use.
    
    
      Perhaps? It is not that straightforward. Doing a CRUD app with Ruby in a team full of assholes will have a "larger impact" than doing in on assembler with a bunch of goodie-goodies.
    

> The amount of sleep that you get has a larger impact on your effectiveness
> than the programming language you use.
    
    
      Perhaps? Without further qualifying it is worthless.

------
classified
Thank [insert relevant deity] I'm not a reasonable person, so I can afford to
agree with all of the author's points. Especially the one about testing.

And if that applies to you: Kick those amphetamines and get more sleep
instead.

------
unnouinceput
"<Writing non-trivial software that is correct (for any meaningful definition
of correct) is beyond the current capabilities of the human species.>"

You can say this about any tech field. Heck you can say this about social
domains as well. And yet world marches over with progress being made.

"<Being aligned with teammates on what you're building is more important than
building the right thing.>"

Because yeah, building the wrong thing was always good and had nothing to do
with economic failures, right? Tell this also to NASA teams that build the
moon race, is littered with teams doing different stuff and not being aligned.
My favorite story for that is the one about how they made the suit.

"<There are many fundamental discoveries in computer science that are yet to
be found.">

There are many fundamental discoveries in all fields that are yet to be found,
CS is no more special then Psychology for example, it only pays better these
days.

"<Peak productivity for most software engineers happens closer to 2 hours a
day of work than 8 hours.">

Peak productivity depends on each individual and within each individual there
are seasons. I can be productive at nights or during day time, and when I am
productive during certain hours for the life of me I would not be able to be
productive on other hours. Procrastination is perception of individuals during
their non-productive hours.

"<Most measures of success are almost entirely uncorrelated with merit.">

Finally, the single statement in this otherwise useless article that I can
agree with.

"<Thinking about things is a massively valuable and underutilized skill. Most
people are trained to not apply this skill.">

That depends on what your education/how your parents raised you. As for how
much value this has in current society, well just ask Trump (he's still a
billionaire). Also, in that regard see previous point.

"<The fact that current testing practices are considered "effective" is an
indictment of the incredibly low standards of the software industry.">

Actually the standards are quite high, you should've seen them 40 years ago
when Ford preferred to allocate 200M USD for paying victims than rather
improve its safety when building the chassis, because that would've eaten
their profits ten fold.

<"How kind your teammates are has a larger impact on your effectiveness than
the programming language you use.">

Become freelancer, be your own boss and you couldn't care less about
teammates. One man show where you call all the shots is awesome.

"<The amount of sleep that you get has a larger impact on your effectiveness
than the programming language you use.">

This point goes hand in hand with above one about productivity, it all boils
down to each individual.

------
EugeneOZ
> _The fact that current testing practices are considered "effective" is an
> indictment of the incredibly low standards of the software industry._

It's not tests' fault that programmers are lazy and write tests not for every
function, or write unit tests without integration tests or write vice versa.

Whole article is just low-quality whining.

