Hacker News new | comments | show | ask | jobs | submit login
7 habits of highly ineffective developers (sitepen.com)
62 points by sitepen 10 months ago | hide | past | web | favorite | 27 comments

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

I too get paid six figures to read HN and nothing more. Interviewing this winter is going to feel like running again for the first time in a year (painful!!).

"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."

Be careful. If you stay there long enough, and the feelings about interviewing get strong enough[1], the only road to maintaining your self-respect is to quit the game.

With some luck, I won't outlive my savings.

[1] Ok, interviewing is unpleasant. But the knowledge that the next job is only going to be better until I know what is going wrong kills me.

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

It's pretty common for developer positions regardless of where you live (at least in the United States). When I was on the east coast and when I moved to the west coast, every single interview consisted of hours and hours and hours of whiteboarding.

Some of the better companies had you whiteboard something you'll run into on a normal basis (like drawing up how you'd architect a RESTful API). But most of them was "here is this CS problem that you'll either never have to deal with on the job or can look up in 2 seconds because it'll be easy to recognize; now whiteboard it up with zero help from the internet".

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

How much time, and were you compensated?

4h each, no compensation

i'm in NYC and its common at every big company that pays well

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.

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.

> “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.

Interesting! Do you have a reference?

Yeah, here's one: http://www.talyarkoni.org/blog/2010/07/07/what-the-dunning-k...

"...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.

"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.

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".

"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.

Everything goes through the hype-cycle ie 'trough of disillusionment'.

'Serverless' is one that is here to stay for sure. Nobody likes having to manage 'instances'. There's a gold mine for anyone who can reliably make something that 'just runs your code at scale' - in a normal format, without a lot of weird apis or behaviours. AWS Lambda's are 'almost it' but there's a few caveats that make them annoying enough that they are not the solution.

NoSQL are limited mostly by: A) lack of 'joins' in queries and B) too many query languages. I suggest both of those problems are solvable, in which case they might be even better than RDBMS for many apps. Also - many people just don't know how to 'data model' for them. Or maybe RDBMS will come a long with an easy 'flex table' solution and solve the problem noSQL was trying to solve and make it relevant. (Who knows, maybe they have? I don't pay close attention to that community).

As for Justin Bieber - well - there's 'no advantage' to everyone listening to 'Justin Bieber' - but because technology has to 'work together' - there is an existential advantage when we 'all use the same stuff'. 1 solid tool that everyone uses is probably better than 100 different tools, each of them a little bit better in different ways, and nobody on the same page.

Finally - the bleeding edge is important though, it's the tip of innovation where new stuff happens :)

> 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.

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.

Honestly, we have to bend everything out of shape to make any functional software for any domain, using any technology. It is just natural that people have problems identifying wether stuff suits their problem or not.

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?

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.

> - 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?

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)

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.

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact