
7 habits of highly ineffective developers - sitepen
https://www.sitepen.com/blog/2017/04/18/7-habits-of-highly-ineffective-developers/
======
volkk
I am so far in at step number 7 at my current place, i should have left months
ago. The worst part is most people here are at step 7. The only reason I
haven't left yet is because interviewing is actually worse than being here,
and that's saying a lot.

Slight tangent, but I'm always jealous of my friends who have to interview for
new jobs (non engineers) and have to wonder why they're so nervous. They don't
have to sit there and code on a whiteboard in front of 4 uninterested
developers for 4 hours straight, and then be rejected for unknown reasons so
that you can't even fix the potential gap in knowledge you might have. /rant

~~~
beaconstudios
you have to whiteboard code for hours as part of your interviews? And this is
common where you live? Is this a California thing?

~~~
sawmurai
This seems to be a US thing ... I had to solve a problem in a given time frame
at two interviews at two different companies ... no one watching - but
available for questions - internet access, no restriction. Like ... a real
World scenario. No idea why whiteboard interviews were / are a thing.

Edit: based in Switzerland

~~~
cholantesh
How much time, and were you compensated?

~~~
sawmurai
4h each, no compensation

------
dahart
Making excuses & being disengaged are definitely ways to be ineffective. They
might be signs that you and your job aren’t a good fit. They might also be
signs that you’re on easy street and have a good deal. But if you’re unhappy
and want to fix it, start looking for something better!

> The Expert Beginner. This is someone who makes a career out of always being
> semi-competent and never mastering anything.

This one is interesting because several of the most effective people I’ve ever
met are in this category. Some people are breadth first, and some people are
depth first. You actually need both to have effective orgs, so don’t assume
breadth first is somehow bad. Many so called “masters of none” are good at
gluing multiple systems together, and building pipelines.

~~~
theprotocol
I agree with you, going by the description, about it being more like "breadth
first vs. depth first."

I think the author of the article may have misunderstood the blog post he was
citing; "Expert Beginner" seems to be more about self-awareness
(Dunning–Kruger effect) and awareness of the big picture rather than
specialization.

~~~
dahart
> “Expert Beginner” seems to be more about self-awareness (Dunning-Kruger
> effect)

Hmmm I guess it’s too bad for that hypothesis that the Dunning-Kruger effect
has been shown to disappear for cognitive tasks like writing code, IIRC by the
very same authors.

~~~
mcguire
Interesting! Do you have a reference?

~~~
dahart
Yeah, here's one: [http://www.talyarkoni.org/blog/2010/07/07/what-the-
dunning-k...](http://www.talyarkoni.org/blog/2010/07/07/what-the-dunning-
kruger-effect-is-and-isnt/)

"...some studies have shown that the asymmetry reported by Kruger and Dunning
(i.e., the smaller discrepancy for high performers than for low performers)
actually goes away, and even reverses, when the ability tests given to
participants are very difficult."

Dunning-Kruger is almost a meme, people throw it around casually like it's
blanket truth and applies in all situations. What is rarely discussed is that
the original study only measured very, very simple tasks. And (importantly, I
think) they are tasks that you don't learn in school, so nobody has metrics or
good calibration for their abilities. The ability to get a joke was one of the
tasks they measured. You can't really compare the "skill" of the ability to
get a joke to the skill of writing computer programs, but that's what's
happening. When task difficulty was controlled for, the conclusion is the
effect depends on task difficulty. So I pretty much agree with the author:
using DK to explain people I can see in my life is probably confirmation bias,
rather than evidence.

*BTW, note the two spellings of Kru[e]ger, I may have mistaken the Krueger referenced in that article as the same Kruger in Dunning-Kruger. I thought that the DK authors had clarified in a later paper, but I'm not sure now.

------
Animats
"Expert Beginner" \- this is the fate of most web developers. There's so much
churn in the "technology" that by the time someone gets really good at
something, it's obsolete.

Conversely, getting really good at something can be career ending when that
thing dies.

~~~
bhhaskin
I think this is a mistake that most Jr and Mid level developers make. You
shouldn't focus on being good at a "technology", but rather focus on being a
good developer. Being effective at problem solving as well as quick to learn
or adapt are far better skills than mastering a "technology".

------
dvfjsdhgfv
"If we choose music like we sometimes choose technology, we would all be
listening to Justin Bieber. The cow paths aren’t justification enough to use a
technology or adopt a pattern."

I wholeheartedly agree with the quote. Almost each technology wave takes its
toll. Remember how everybody got excited about NoSQL? It's not that this
technology hardly matters nowadays - it's just clear it's relevant only in
certain contexts, just like everything else. Yesterday it was about
"microservices", today it's "serverless". It's almost as if people were
bending over backwards so that the technology currently en vogue matches their
problem/solution scenario. As is people were afraid of thinking independently
and challenging what happens to be the hype of the moment.

~~~
BinaryIdiot
> Remember how everybody got excited about NoSQL?

It's one of the downsides of being a contractor; your new client thinks NoSQL
is the next best thing and if you want the job you have to use NoSQL, even if
it makes zero sense in your use case (and yes you always argue with the client
it just rarely works if they have the money to throw at the issue).

When the NoSQL craze hit I stopped using RDMS _entirely_ for about 6 years. It
was _never_ my choice and only in one case do I think it was the _correct_
choice.

~~~
dvfjsdhgfv
For me the worst was the XML craze. Suddenly everyone was talking about XML as
if it was a game changer. One major database vendor announced an XML database.
New standards like XSLT and Xpath proliferated. XHTML seemed to be on the way
to replace HTML... When you look at it now, each of these technologies has
some use, and the "XML revolution" contributed to some useful developments,
but the exaggerations on the way were egregious.

What is interesting is that many people were aware of the shortcomings of the
new technology from the very beginning. For example, many noted that XML is
too verbose for both machine-to-machine communication as well as editing by
humans. It's interesting to note the same phenomena in each technology cycle.

------
CobrastanJorji
I have a question about the cow path problem. The blog postulates that, when
choosing an appropriate approach/framework/technology/tool, I should lay out
the options and choose the best one, taking into account the longterm cost of
adopting something new?

What if I'm not competent at most of the options? I can spend a few days
evaluating each one and getting a beginner's idea of what it can do, but
evaluating the long-term costs of more than 2 or 3 choices seems like it would
take an inordinate amount of time.

Say my team has expertise in our own areas but we need to add a thing in some
new domain we have no experience in, for example web development. We're going
to need to build our thing on some sort of framework, but, for the sake of
argument, we're not familiar with any of them. How do we choose the right one
without spending months in analysis paralysis but also not simply following
the cow path?

------
aaronbrethorst
I've had situations where dealing with a #6 coworker when coupled with an
unsupportive boss turned me into a #7. I quit and am far happier for it.

------
thethirdone
> \- You’re in denial

> If any of the above apply to you, you might want to consider improving your
> self-awareness.

How are you supposed to know you are in denial if you are in denial?

------
marak830
There are some... Interesting points here. I'd like to throw in an alternative
point of view from someone who doesn't work as a Dev full time.

1.FOMO "This issue is defined as a fear of regret, which may lead to a
compulsive concern that one might miss an opportunity for social interaction,
a novel experience, profitable investment or other satisfying event."

Missing out on a social experience? Most jobs you need to work to their
schedule and socalise around that. If you are worried about missing out on
something, then you would have to either catch up later, or try and swap
shifts to be there.

2\. Honestly I don't understand the point the author is going for here. I read
a lot, doesn't mean I'll change all my code to the latest fad.

3\. Because management says so.

I have been lucky, I have been able to converse with my managers a lot and
been able to offer my point of view. At the same time, I have seen people lose
their job for disagreeing with management. In most jobs, if you disagree, you
either knuckle under or you don't get shifts.

You do what they say, how they say, without talking back. Sounds horrid, but
that's how most jobs work.

4\. Well... I don't argue either way on that point, it's a little too
generalised.

5\. Everyone is a beginner at one point. How do you pick what is best? When
I'm cheffing I can't afford to perfect every type of meal- there are just too
many. Instead I try and learn a little about everything, then once it's
required I study more in-depth. I have done the same with coding. I Have also
done the same with working on the docks(container loading via hand, and
forklift(5+10ton), also container stacking(larger forklift, plus warehouse
management and the office software), Same with coding, I can write c#, vb6 and
.net, frontend I can do JavaScript, php, tie into MySQL, and learn frameworks
as I go.

6\. I was given advice from my grandfather. If your the smartest in the room,
change rooms.

While I'll be the first to say that as a saying it's a little insulting, if
you take it directly, when you consider specialisations it has helped me a
lot.

7\. How do I approach this one.

Honestly it to non devs it comes across as rather insulting. Do I want to cook
this menu over and over after I have mastered it? No.

Do I want to collate these documents again and again? No.

Do I want to write this php to store data and track the users through the
site, then log it to the MySQL and ensure it reports to the manager where the
user stopped on the form for follow up? No, not really.

But that's why they pay us.

Or put it another way, do I want my child to eat next week, how will i pay my
rent, what will I do if my wife gets sick and can't work.

I really think it's over used, but honestly, entitled comes to mind. Most(
_most_ ) people don't have the freedom to complain about a boring job. We have
no choice.

I don't think what the article says is wrong per se, but it really struck me
as a very (again I think it's over used) entitled way of looking at things.

Introspection isn't a bad thing, but realising you have it rather good can be
a good thing too.

I hope this doesn't come across badly(also I'm using my phone so forgive any
typos please haha).

Edit: fixed typos(sorry stuck using smartphone and Firefox kept crashing)

~~~
jbeckham
Thank you so much for #7. I'm in management now, but even during my 10 years
of development, I had this same view. Maybe that comes from a work ethic
drilled into my on a farm when I was a kid, but when I think about what I get
paid for sitting inside, in the A/C, typing at a computer and then compare
that to farm work, I pretty much remember that I am still privileged just to
have this opportunity.

~~~
marak830
I constantly have it drilled into me seeing my family working on the farm,
driving trucks and doing dock work(hence my experience with it haha).

I love programming, I really enjoy reading hn for the tech insight, but some
of the complaints really rub me the wrong way at times.

