Everyone isn’t perfect, and it’s the most honest of truths. It is the same with programmers as with any other field in life. There are a lot of goo...
For further actions, you may consider blocking this person and/or reporting abuse
Some of this is contradictory or confusing. Examples and some reorganizing would've taken this a long way.
In your first point you chide people for not talking to their coworkers, then in the ninth you frame asking your coworkers questions as a bad thing. Which is it?
A lot of this can be boiled down into "Don't be arrogant about your favorites" whether it's your code, environment, IDE, etc.
You mention not being slow about communicating, but all we get is a quote about craftsmen and nothing concrete spelled out for WHY. Like most of this list it should be self-explanatory, but you didn't give much detail.
The mention of refusing to write bad code then picking at naming conventions seems backwards without examples.
It is 100% always an option. Not a great/idea/easy one, but it is always there. You can quit and find another job as worst-case scenario if your current job isn't working for you.
Also, regarding your last point, there actually can be situations for development, which just would need too much effort to solve it (if possible). Just imagine using a bugged product as part of your system and you find, that it does not work as expected and the company (creator) does not provide any fix or solution.
If we think about code (and I guess, this is what the article is about), if you cannot find a solution, you definitely have options, like asking somebody for support or postpone it until you have more experience.
I'm not sure which guideline or rule you are referring to in this article with your first sentence, but this article is listing bad habits to avoid, not rules to live by. I don't see how it's even possible to disagree with any of these 10 bad habits to avoid, considering how they are intentionally phrased to sound bad so that you'd avoid them.
While your comment is great advice in it's own right, it sounds like you thought the title of this article was "10 Coding Habits to Pick Up". Maybe the author edited the title or the content after you commented?
I have not changed the title 😀
These types of programmers are FAR more common than you might think. And they can be coders of only a few years experience. Or twenty years in the field.
Hopefully, one of them might read this article and recognize themself. And realize that maybe they need to make adjustments in how they work. Who knows. Could happen!
Wow. I'd think that anyone who has done coding for at least two years should already know all this. These mistakes not only cause issues for you, the coder, but can easily later cause major issues for the company. Not just that project.
One of my biggest pet-peeves are arrogant coders.
Avoid, when reasonable, working with (or managing) these types of coders.
8/10 items on your list are exactly what arrogant programmers usually do.
And, unfortunately, I've found they are nearly impossible to rehabilitate.
I'm sure that it tied to these types of programmers tend to have all the same personality traits.
Not saying they can't change. But...rarely they do. It's very frustrating working with them.
The Google tip cracked me up, almost choked... I too think you mean well but seriously, ignoring the reality that there are many search engines and buying into the use of google as a verb to search the web is so doing dev skills and savvy a disservice IMHO. If anyone knows better it has to be developers surely. Might even have been better to write Not using Stack Overflow enough... though that would stink of the same product myopia.
Don't quit, can also tone down to Don't quit too soon or such... there are plenty of contexts in which refusing to quit is the problem. There's an old pop (or country if you prefer) aphorism that runs "You gotta know when to hold 'me, know when to fold 'em". Point being sometimes it's right to quit, sometimes it's right to power on.
I think the author's point on the Google one? I suspect their were more implying to...
"know your resources and use them!" And to take initiative. And understand what you are looking for and how to use what you find.
Google is still a great resource to remember. Of course, it shouldn't be your only one. And some coding fields would use it for research. There are some where trying to Google would be useless.
Again - comes back to knowing and using your resources. And sometimes that means becoming more familiar with all the in-house resources your company has available. I've worked at such a huge and complex place that this would be several places. It's intensive and you have to even know where to look to find what you need, depending on not only what department you were in but also what project you were currently doing.
Overall, to everyone who didn't like this article...
It isn't the final Bible on how to code. Any coder knows there are no absolutes.
I would have thought that knowing this article was only a slice, and not absolute. And that it may simply just not apply to your world? That other coders would already know this. And set their expectations accordingly for any article about coding.
These are suggestions. And good reminders. Just because this article isn't useful to you doesn't mean it isn't useful to anyone.
Just because your current job wouldn't look anything like what they listed as suggestions doesn't mean that those suggestions are wrong.
I've worked various places. Even for vastly different languages. Totally different environments. I
I often forget that most coders only know their slice of the world. And often don't realize that the coding job can look very different depending on so many factors. Many times things you'll never encounter due to what you specifically do. But... your world isn't everyone's world. Or even the average world. Rant over.
Good article.
Good rant, I've seen more than one person strongly disagree with this seemingly straightforward and uncontroversial article, which is surprising because most articles just have people commenting "nice article". The author is unequivocally pointing out habits that sound bad and giving general sound advice, I don't understand what people are disagreeing with.
The tip about the Google is spot on and I read it to be more like "Don't ask your colleague a question that you can easily find the answer to in a few minutes on Google". If the question is complicated, it's unlikely that an ad hoc chat with a colleague would provide you the answer you need, especially if you didn't do your own research first. If the question is basic, then you'd just be interrupting your colleague from their focus.
Can you help me with book name that mentions Ramanujan's diaries, writings or thoughts.
Very good stuff
If you don't want to communicate with the team, you can communicate with others on the network community, such as Reddit, Stackoverflow, Github.