
The Insecure Developer - rbanffy
https://dev.to/agisilaosts/the-insecure-developer
======
zwieback
I listened to this podcast where they were trying to figure out why some car
salesmen sell 2x or 3x the cars of the next best guy on the lot. They found a
pattern where the best performers would maybe briefly celebrate a sale and
then immediately think "Oh god, I'll never sell another car, gotta get
cracking right away." The less successful guys would go back to their buddies
and brag, tell stories and go home early.

Insecurity itself isn't necessarily a predictor of failure, it depends on what
you turn it into.

~~~
news_to_me
That being said, I'd much rather be the less successful guy than the guy
constantly afraid of failure. "Productivity" is only as good as it advances
your own personal life goals, and I don't think it should come at the expense
of mental wellness.

~~~
imustbeevil
This is also a form of self selection. If you believe that working hard is not
worth what you get from it, you won't do it and someone else will.

The less successful guy would also "rather" be himself than the other guy,
because he too believes the other guy must be trading his mental health for
his productivity.

The successful guy doesn't see it that way. He's happy when he sells a car,
and he's happier when he sells more cars. He spends his whole day doing his
job, maybe even does research at home. He still enjoys his time with his
family, has whatever hobbies he invests his free time in (presumably also more
successfully than the other guy). He gets to retire earlier, and he knows it,
and that gives him more motivation to be successful.

It is absolutely tragic that people can have the idea that less success is
more happy. Some people feel better working harder and you shouldn't have to
attribute some opaque negative consequence to them to feel better about the
gap.

------
Xoros
Isn't the point of an internship to continue your formation ? How comes
companies making the same tests as for recruiting for real jobs ?

"Hi, we are not going to pay you, or not very much, but please be at the same
level as senior that are already working for us"

I had interns back in the day I had an office (and not working from home) and
I always made them work on basic tasks under my supervision. Once I had one
woman who was very good, and she worked on a website that ended in production,
but most of the time the purpose was to work on internal projects that can be
used even if not perfectly polished. You know, stuff you always say you're
going to do some day, but you don't.

The advantages were on both sides. They learned real life cases, under my
supervision, and I had the tools I didn't.

Disclaimer : I'm French so maybe my example is not relevant.

~~~
jasode
_> How comes companies making the same tests as for recruiting for real jobs
?_

1) Because _desirable internships_ have more candidate applications than
available slots. E.g. Google has 40,000 students wanting an internship but
only 1500 slots.[1] With that supply & demand ratio, Google can be selective
via difficult coding tests.

2) Even though internships are unpaid, companies evaluate interns to
potentially offer permanent employment. If so, a company like Google would
want to fill those 1500 slots with "the best" rather than randomly pull from
40000 candidates.

That's how it is at the hot tech companies. Maybe other internship programs
outside of tech sectors such as Peace Corps think of interns differently.

[1] [https://www.fastcompany.com/1683136/how-to-actually-land-
an-...](https://www.fastcompany.com/1683136/how-to-actually-land-an-
internship-at-google-and-turn-it-into-a-job)

~~~
Tyr42
Re 2. Internships are paid. Pretty well actually.

------
mikekchar
I'm sleepy, so I shouldn't post, but here goes. Confidence is really important
for a programmer. Writing good code is very, very difficult. On the other
hand, writing terrible code that barely works is not so difficult. There is a
pretty big gulf between the two and if you don't have confidence that you can
achieve something better, it is unlikely that you will even look.

Having said that, our industry is full of a lot of people who probably are not
well suited for the job. Quite a few people look at the 6 figure salaries that
you can get in some places in the US and figure it's a cushy way to get rich.
Similarly, there are tons of jobs. _Everybody_ is looking.

But here's the catch. "Everybody" is not looking for the average programmer.
They are looking for the top 1% of applicants. Anybody who is hiring (i.e.
everybody) can verify this. How man CVs do you get a month? How many do you
interview? How many do you hire? And even _then_ more than half the time I
reckon companies are dissatisfied with the programmers they hire.

So there is actually a huge supply of average programmers that nobody wants.
The average programmers aim at the "barely works" bar, and having hurdled it
think they are senior programmers. A year or two under their belts, they
demand their incredible wages.

At the same time, we all ask ourselves, "How can we protect ourselves from the
hordes of untalented hacks knocking at our door?" Whiteboards, puzzles, trick-
du-jour. It doesn't matter, because the real problem is what I stated at the
top.

Confidence is important because writing good code is very, very difficult.
Writing terrible code that barely works is not so difficult. We think we need
to protect ourselves, but we don't need binary barriers to protect us from the
untalented hacks. We need a better attitude. We need to realise that
programming is a skill that takes time and effort to develop.

Some people should not be in this industry -- not because they don't have the
chops; but because they don't actually want to put in the time and effort to
develop their skills. And it is an _overwhelming_ task. There is so much to
learn that you will be drowning in it for years (another reason people put
their fingers in the ears and think they are amazing).

So to any "young" programmers (of any age), my advice to you: Have courage.
Have confidence. Love what you do because it's a crappy, horrible job if you
don't -- no matter how much you get paid. And for those who don't love it...
there are lots of jobs that are not programming, but are still in the
industry. Quite a lot of them even pay more than programming! Seek them out.

~~~
Sir_Substance
>Some people should not be in this industry -- not because they don't have the
chops; but because they don't actually want to put in the time and effort to
develop their skills. And it is an overwhelming task.

This is something that is near and dear to my heart, so I'm gonna take the
opportunity to rant on it a bit. There are quite a few high-paying and fast-
moving fields.

Pretty much everything under medicine or law moves is moving on a week-to-week
and even day-to-day basis, just like software development. Unlike software
development, practitioners in these fields get paid to stay up to date, as
part of their day jobs. Lawyers spend a good chunk of their days just reading
the latest case reports that are relevant to their field, and boy howdy do our
legal systems churn out a lot of reading for them to do.

It's pretty much only in software development that we expect professionals to
stay up to date and develop new skills /in their spare time/. There would be a
lot more 1% developers out there (or rather, we'd be able to look for the 5%
or 10% rather than the 1%) if companies were willing to have their teams spend
4 hours a week training, but no one is willing to do that.

I have guesses on the causes of this industry-wide unwillingness to train, but
one thing is for sure: this situation will never resolve itself as long as we
honestly and unironically expect members of the field to spend their evenings
and weekends learning new algorithms and languages instead of playing with
their kids or chilling with their mates.

You know why so many developers settle for mediocrity? Because mediocrity pays
the rent, and no one is supporting their path to excellence.

~~~
darioush
Every job I've had and encourages engineers to have reading groups, on any
topic they want. It's also my experience that most people ignore these
opportunities Is this also what others see?

Some reasons I can think are people: \- don't want any more meetings; \- are
bad at having a merit driven discussion

~~~
watwut
Majority of meetings are not merit driven discussions.

------
SadWebDeveloper
> Insecure or maybe well known as imposter syndrome hits me hard many times
> from when I started as an iOS developer

Used to feel the same when the Python-crowd harassed me on choosing PHP over
Python for webdev. I got my revenge when the python-devs i knew started
rewriting their entire projects in ExpressJS/NodeJS due to scaling-related
issues and mine still outperform them after 5 years of service.

------
jmnicolas
> What the heck means, “You aren’t diverse enough”?

It means you're a white man and apparently it has become an accepted form of
discrimination.

~~~
Xoros
Or maybe it means that he was not "good enough" for the multiple technologies
they use. Like just in one language but not all they use.

Pretty dumb at the end if you ask me.

~~~
jackhack
Then the hiring firm is a group of fools best avoided.

Tools change like fashion. What is "hot" today will be nearly frowned on in 5
years and forgotten in a decade or so. In 20 years the fundamentals still
matter, the tools, not so much (Pascal? Powerbuilder? Win32 in C?)

A smart developer can learn any tool. Hire for aptitude, not today's toolset.

~~~
steven777400
I agree. Of course, there is a "spin-up" time and we prefer to select the
competent candidate with skill in our tools vs the competent candidate with
skill in a different tool; but absolutely a competent developer should be able
to adapt to any environment.

Interviews can help accommodate this by allowing the candidate to solve a
coding test in a language of their choice, while also inquiring about the
candidate's learning plans. (Want to make sure they are willing to adapt to
the team's tools and not try to force the team to adapt to them!)

I took a job once where the code base was in a FORTRAN-derivative language. I
had never used FORTRAN or anything like it. Not a problem. I studied the code.
I studied the docs. I figured it out and did the work. I would expect nothing
less of any other competent developer.

Another job had a toolchain based on NodeJS on the server-side. Never used
NodeJS. Not a problem. Studied the code. Studied the docs. You know the story.

The key skill is a developer's willingness and ability to learn the tools that
are desired for the job at hand, and to accept and learn new tools when the
time is right.

