7 habits of highly ineffective developers
sitepen.com
sitepen.com
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
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".
Edit: based in Switzerland
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.
> 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 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.
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.
"...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.
Conversely, getting really good at something can be career ending when that thing dies.
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.
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.
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.
'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 :)
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?
> 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?
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)
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.