
Things nobody told me about being a software engineer - chad_strategic
https://anaulin.org/blog/things-nobody-told-me-about-being-a-software-engineer/
======
mattmanser
Serious question, I've been programming 15 odd years, somewhere around a
million people used my code last year, I've written entire sites on my own
that happily run today.

I don't write tests. Projects that already had tests, those tests caught a
single bug in about 3.5 years of working on that code base.

Yes, 1 bug. We'd have picked it up anyway when actually testing it.

Why do you feel #1 or #16 are actually true?

Am I (and colleagues) a magic snowflake, or are tests a massive waste of time,
or is it somewhere in the middle?

~~~
dougk16
I'm in the same boat and have thought a lot about it. The biggest correlation
I see from automated testing advocates is that they are usually using dynamic
languages for non-trivial core business logic. I mean that's pretty much it.
If you're using a dynamic language for such things, like anything past 10k
lines of code, then I agree, you pretty much need automated tests since
they're partially filling in the role of a compiler and type system. It begs
the question of why to use dynamic languages for tricky business logic, but
that's a whole different flamewar!

If the testing advocates are using something with even a basic compiler/type-
system (e.g. Java), then IME it often comes down to not being fluent with the
design patterns, tricks, IDE shortcuts/plugins, tools, etc. that compilers and
type-systems can provide to work with you to catch bugs at build time. I
mention Java because it's a language that allows you to keep writing "dynamic"
code and avoid the compiler/type-system to a good degree if you want (and boy
do people want to). E.g. passing top-level Object types around and casting,
using HashMaps instead of a proper Class, heavy reflection use, "stringly"
typing, etc. Unlike say Haskell or Rust which force correctness down your
throat to a much higher degree.

Obviously no matter the language choice, their comes a point where automated
testing becomes cost-effective (e.g. safety-critical software). At that point
however there should be formal methods and such in play also. And I'd say for
the majority of us working on CRUD apps, we're not at that cost-effectiveness
point.

~~~
arkh
Currently you read a lot about unit testing. Usually used badly (testing solo
methods or classes).

What you want is E2E tests: test that your product conforms to its
specifications. Automate the test procedure your testers have.

------
kenhwang
> 8\. That having decent people skills makes my technical skills suspect, in
> the eyes of some.

I'm questioning how true this is, especially in today's world of whiteboard
interviews and open office spaces. My personal experience seems to suggest
that better people skills suggest better technical skill, especially to
management.

~~~
uptownfunk
Very true. Back when I was trying to become a dev I'd show up in a suit and
try to be as socially pleasant as possible. When I started dressing more
sloppy, not shaving, etc. and being slightly more awkward (mimicing the
interviewer) I actually started getting offers..

~~~
kenhwang
I think that fits into 4 more than 8. You have good enough people skill to
recognize that you're different than the interviewer, and then putting up an
facade to convince them you're like them.

People with poor people skills incidentally act similar to other people with
poor people skills. People with good people skills can _choose_ to act similar
to people with poor people skills.

------
maerF0x0
> That my gender or my age or my ethnicity or my sexual orientation or my
> weight or my clothes might (will!) have an impact on the perceived quality
> of the software I build. (Or, in other words, that this is not really a
> meritocracy, and doing a good job is not nearly enough.)

Does there exist any body of proof around this one? Would like to see it and
add it to my corpus of knowledge

~~~
Beldin
Yes. One typical test is to have people evaluate identical resumes, with the
thing being checked for constituting the only difference (e.g. "ethnic" ames
vs. "regular" names).

Other data points are gathered by studying success at finding internships. A
recent study found a rather staggering difference - names indicating local
ethnicity got a place in 1-2 letters, while some other ethnicities had to
write over 20 (if memory serves).

You'll want to find studies for the country you're living in, as the
parameters inevitably vary (e.g. which ethnicities to compare). I don't think
the outcomes cary much, but i didn't do a comparative study on the literature.

~~~
bytematic
Maybe names shouldn't be disclosed until the actual hiring is done.

~~~
yladiz
It's not that simple since it's essentially impossible to do a true blind
hiring process, due to the fact that interviews happen in person (on video,
physically, etc.) and so hiding the name can get a foot in the door but biases
take over once the interviews start.

------
arkh
> why is this not a standard feature of testing frameworks? I want some way to
> re-run tests flipping some of the assertions, to make sure they are testing
> what I think they are.

That's mutation testing and it the next big thing for tests.

------
Erem
The author was maybe the best engineer I've had the pleasure to work with
directly in my 13 years in the industry. What a treat to read her internal
thoughts on the job. Highly recommend her other posts on e.g. measuring
performance of engineers [https://anaulin.org/blog/why-do-we-have-performance-
evaluati...](https://anaulin.org/blog/why-do-we-have-performance-evaluations-
anyway/)

------
13of40
Hand-wringing and debating about how we should use the bug reporting system,
triage, sprint planning, user stories, burn-down charts, etc. will keep the
leads and PMs busy for decades on end, even if the tools never change.

------
tinnet
Re #18: It exists, it's called mutation testing, and it's awesome (I only know
the Java variant called [http://pitest.org](http://pitest.org))

~~~
epmatsw
Stryker is a JS version. Google has some interesting whitepapers about their
usage of mutation testing as well:
[https://ai.google/research/pubs/pub46584](https://ai.google/research/pubs/pub46584)

------
Insanity
Don't agree with all the rules, some depend on where you work (e.g, we don't
have a lot of tests in our ~30 year old codebase) .

However, Rule #2 is true for me. Accidentally pressing those keybindings in a
textfield that does not accept them has become common.

~~~
aequitas
Try pressing them in other situations and you might be surprised how often
they work, Youtube player for example to pause, forward/rewind.

------
mh8h
> _20\. That it is all people, all the way down. They are as cute as turtles,
> but don’t have hard shells._

A thousand times this. I used to be amazed by people's intelligence. Now I am
amazed by their kindness.

~~~
iam_takada
This analogy is lost on me. Could you explain?

~~~
BerislavLopac
[https://en.wikipedia.org/wiki/Turtles_all_the_way_down](https://en.wikipedia.org/wiki/Turtles_all_the_way_down)

------
t0mbstone
Pretty much all of these ring true for me (20+ years in the industry).

------
jackconnor
Frontend programmers are very, very undervalued, I 100% agree. This is because
they build the things that your user interacts directly with, where the
"rubber meets the road", so to speak. Good FE coders are worth their weight in
gold, to any company that has users using their software.

------
poulsbohemian
On this point about testing... what’s still surprising to me after twenty
years of doing this is how many errors aren’t _technical_ errors, but rather
because someone forgot / failed to document / communicate how something was
supposed to work. So something fails, fingers get pointed in the direction of
the technical team, but the root cause is all too human.

------
obelos
Regarding #2, I have a harder time switching between touch screen vs. touch
pad than I do between text editor key bindings. I seamlessly shift between vi
and emacs throughout the day depending on what I'm editing, but put my laptop
and tablet side by side and I am forever trying to touch the laptop screen.

------
rco8786
> PHP is cool again

Come again?

------
wyldfire
> That you can have more than a 100% base salary difference doing the same
> job, depending on if you work at a small startup or one of the large
> companies.

Even among and within large companies. Somewhat less so within, usually. But
one element of that is the (US?) taboo around sharing compensation info.

------
amelius
> That the new Altavista competitor would become a less bad Microsoft Office.
> That the new version of My Space would help damage democracies the world
> over.

And that programmers would get a reputation almost as bad as bankers ...

~~~
watwut
I think it is more enterpreneurs and startup founders who get all the hate,
not so much run of mill programmers.

------
amriksohata
The thing no one told me is the number of requirements folk, like ux, ba's
that don't understand their role in agile development and responsibilities in
getting solid requirements across to developers

------
websitescenes
Lost me at #13. CSS is not a programming language, nor is it complex..

------
nraynaud
funny how people confuse being told something and integrating it. We're "told"
millions of things (more exactly we read all day long), some of it sticks some
of it doesn't, it has nothing to do with what we believe is important later in
life.

I think we have to stop with those things I wish i was told/nobody told me/I
would told my younger self. We just decide some points are salient with
experience, and I'm pretty sure the list is different after every decade in
life.

------
chad_strategic
I'm working in Drupal 8, which makes rule 17 = true.

------
purplezooey
How about: one's abilities count for about 10%, and skill level in high school
politics the other 90%.

------
klohto
Article full of hyperboles, without-proof points and self-pity. Doesn't bring
anything useful.

------
watwut
That people who write all those cool blogs/talks and people who write good
code or manage projects in great way are different in important ways. Meaning
what is good tech/code and what is hip on blogs and forums are two distinct
groups. Meaning what is good management is completely different then both feel
good and look at me I tough bs you find on blogs.

------
redleggedfrog
"That my gender or my age or my ethnicity or my sexual orientation or my
weight or my clothes might (will!) have an impact on the perceived quality of
the software I build."

After nearly three decades writing software, I'd say if that's the case,
you're probably at the wrong place. With such circumstances I'd suspect a
whole lot of other bad things are probably true, too.

~~~
dj-wonk
I interpret this comment as saying: if you find yourself in that kind of
situation, look around and try to find other opportunities. In other words,
life is too short.

I also can see the other side: life is often not fair, particularly in the
short-run. Life constraints such as geography are real barriers for many
people.

~~~
redleggedfrog
You are not only an excellent interpreter, but an astute reflector.

------
Mc_Big_G
How about: When searching for a new job, your previous years of experience,
github repos, personal projects, consulting gigs and all other relevant
information about your ability to produce quality software will not matter at
all compared to your ability to do leetcode style programming challenges.

~~~
t0mbstone
That depends on the company you are wanting to work at, though. I refuse to
work at companies that give those kinds of bullshit puzzle interviews.

~~~
dominotw
> I refuse to work at companies that give those kinds of bullshit puzzle
> interviews.

Good luck finding a job then. All companies of all sizes and locations do
this.

~~~
AnimalMuppet
Um, no, they don't. I know of at least one exception - the one I work at. And
I'm part of the interviews for our team, so I know how they're done.

~~~
dominotw
Ah ok. I 've been interviewing bunch of places recently. All of them seem to
have identical format.

I remember there a site I saw here HN that listed companies without whiteboard
interviews. Can't think of the name.

~~~
AnimalMuppet
Oh, no, we do whiteboard interviews. But they aren't those kind of stupid
puzzles. We just have candidates write a little code, and do a little design.
The "write a little code" is _not_ one of those leetcode questions - it's
really a simple problem. We just want to watch them code, and to hear what
they're thinking as they do it.

~~~
ryall
This is the way to do it. How an applicant applies process to problem solving
and communicates their ideas, is way more important than being able to
regurgitate bubble-sort.

