- can’t focus on one language
- don’t have fundamentals clear
- think you know everything
- don’t utilize the resources
- ignore errors
- don’t know how to optimize the code
- refuse to ask for help
- freeze under pressure
- don’t write enough comments
- can’t accept new technologies
- copy code from online
- don’t plan before implementing
- count hours
- over engineer simple problems
- ignore suggestion of others
- don’t practice much
- give up too soon
- don’t use social media
- don’t interact with programming community
- don’t keep project manager updated
- are not clear about what you’re doing
- You pass blame to others
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (31)
Nobody should focus on one language. Programming in multiple languages broadens your horizon, you can think of more solutions to the problem and don't try to shoehorn the one language you know into places where it doesn't really fit. This really contradicts with "can't accept new technologies". You literally do not need to master a language, there is exactly never need for it. Unless maybe you're further developing that language, even then it's questionable.
While I agree over the longer term, when learning a particular language, it is important to focus on it and learn its idiosyncrasies (e.g. features and how they're implemented, coding conventions) before jumping to another language, especially if it's one of your first languages.
What should be your #1 priority is always productivity. Figure out how to do things, get the thing you need to do done, then try and figure out how to do it better, prettier, etc. if you still have extra time.
For one, if you spend a lot of time figuring out how to do things in the most perfect way instead of just doing it in less perfect ways, you will lose motivation to do the thing and will instead just do something else.
Also there is nobody out there who can say they know everything about any language, you keep learning with experience, best practices evolve, languages evolve, so having your focus be on "fully understanding" any language is just plain wrong.
When working with others, you should focus on things like readability. Generally speaking you should understand things like avoiding premature optimization, but when you do notice a place where speed matters - then focus on figuring out how to make that bit of code as fast as necessary or easily possible.
Most languages contain a lot of things that most people will never need. When I started with the Commodore 64's BASIC, e.g. POKE and PEEK were there, and mostly unnecessary. There are still tons of functions I've never used nor seen any practical use for. And BASIC is pretty damn .. basic.
Generally I would wish people would stay away from their languages special shorthand syntaxes and other such things that make their code unreadable for people who are not deeply familiar with that language's specialties (especially since often the people using them don't understand what they do either, they just copy & pasted it). I'm looking at you JavaScript:
Learn what is useful to accomplish your tasks, occasionally spend some time looking at best practices when you have time, try to at least occasionally google before trying to solve every problem yourself and learn more about the wonderful world of libraries that take care of things for you .. but occasionally also reinvent the wheel when you have time and motivation so you understand what is going on.
Oh and e.g. I've been a heavy user of Python for many years, I'm still regularly surprised of features the Python standard library includes, but it's more like "oh, neat" (and then usually forgetting about it) instead of "oh damn I would've done my job so much better all these years if I had known about that".
I definitely agree with you on both these posts. I've seen it said that a good senior dev's code looks more obvious than a junior dev's, simply because they'll produce what is both readable and efficient - which includes not using some of the weirder syntax and obscure features. But by the same token, you can get people trying to learn who are hopping around so quickly between languages (whenever they get bored of the current one or find another one more interesting), that they don't give themselves a chance to get a solid foundation (or even a "SOLID" foundation). I'd rather solve a new problem in the same language than have to relearn how to solve it - but I'm also a newer developer, so I know that will be different once I have a couple more languages under my belt.
Some code should be commented, for example any code which is very specific to a domain problem and appears counterintuitive.
Comments for the sake of comments - like "looping through array" - are annoying
Totally agree. I follow "Clean Code" by Robert Martin. If it needs to be commented, that means it's not clear enough
Which can be a good thing of course, in case anyone reads this and thinks all good code must be self-explanatory.
"Code that is not clear" is not necessarily "bad code".
For the sake of no. 19, what drives me insane is people not writing comments :D Try debugging anything a bit more complex or code you see for the first time and you start appreciating comments quickly. Remember, what's self explanatory to you, might not be for someone else. Or for yourself in a year, for that matter... And I agree with Gary, not talking about arbitrary comments.
Clean code should be self explanatory. It should rarely require comments
That's why I said codes should be self explanatory.
And that's why I said "what's self explanatory to you, might not be for someone else" :D
Think about this, comments are often not maintained well and can be misleading.
Better to have no comments, than misleading ones.
If the code is clear enough, comments are almost never needed.
Code can't never been self explanatory for everybody, you need the right comments at the right place. I don't like javadocs but sometimes a line of comment in the right place is all you need.
Indeed, been caught out by our of date comments before.
Plus a lot of comments don't even make sense sometimes
Working with existing code feels like coming into a movie series half way through -- you have no idea who the characters are, and why they're doing that.
Some background really helps!
IMHO, comments should give context.
Ex.
"Looping through results" is pointless.
"Build array for export" tells you why.
Point 1 and 10 sort of conflict with each other. Why is focusing on one language a good programming habit? I would still be coding in C in that case...
It's important to learn the basic concepts and all languages do have same principle. Each language gives you something more than other... Your requirement decides your technology...
I read a lot of "if you need comments your code is not clear enough". That really tells how "professional" you and your work is. I bet your biggest projects were calculators. 😂😂😂 Maybe I can figure out why some variables are there by taking some time reading it and scrolling searching for use but why should i take 1 hour of reading code when I can understand in 10 mins by reading comments. Another thing that is more important than comments are self-explainatory variable and function names. So yea, stop acting important and smart.
Ya I don't understand people's issues with comments. If the code is calling like 20 other functions, grabbing data from multiple sources doing all sorts of crazy comparisons and checks, etc it might be nice to know what problem it's supposed to solve.
Maybe it's just a bad solution, which translates to bad code, and now I just wasted all that time trying to understand it.
"over engineer simple problems"
Definitely guilty of that. You want an app that will display the "current time"? Well, let me think about how this Clock object should be displayed. Oh maybe I should separate the Clock Display from the Clock Mechanics. Oh but what if you wanted support for different timezones? i18n? What if you wanted to see multiple clocks at the same time? Did you want an alarm as well? Did you want to connect it with Google Calendar?
Now I have layers and layers of abstraction, composition, interfaces, factories, plugin architecture, whatever other hot software design buzzwords, etc all thought up in my head.
Wait, you mean you just wanted a stop-watch?
[I'm tired so take this with a tiny grain of salt. Also I'm not even a native English speaker so 4am + 2nd language doesn't mix well]
What is "count hours" a bad habit ? Really ? You're trying to guilt trip people into working ? Not everyone wants their job to take over their lives, and that doesn't make them a "bad programmer," or really just bad at their job. Having a healthy and clear separation between life and work is extremely important, and it can actually lead to being happier, therefore having a clearer and healthier mind, therefore working more, being more productive, or even having a clearer codebase/app architecture.
Also, half the things in this list just sounds like "oh this is the way I do it therefore those that don't behave like me are wrong and bad." Like, number 18 (don't use social media) doesn't even make sense, except if you consider StackOverflow a social media. Using social media doesn't change anything about your programing skills. Maybe you'll be less likely to know about the latest trend, but chances are, if you have a newsletter like the programming digest by jakub or just read articles often enough, you will hear about those trends anyway. Discussing with your coworkers (if in a corporate environment) is another way to learn about new things, and it has the added benefit of socializing, which helps teams consolidate, it builds trust between its members, and brings them closer together. I'd also like to highlight point 8 (freeze under pressure) really quick : some people just can't deal with pressure, whether it be in relationships, in sports, at school, or at work. Blaming those people just makes it worse. This stuff is not helping anyone. If anything, it's just gonna make them even more stressed, even more anxious, because then when those people will have a hard time because of pressure from management, they'll also start to think "I need to work I need to work I'm wrong I need to work I should react like that I need to work I'm gonna get fired because I can't do this I need to work" and they will just get stuck in an infinite negative feedback loop, telling themselves over and over that they are gonna fail and get fired, stressing over every detail, being unable to work or think calmly. Another one I'd like to point out is number 11 (as well as the details that is given on the website linked); it seems quite contradictory to two other points here, (ones with which I agree with, surprising I know), namely points number 4 and 7. I think everyone will agree that StackOverflow, articles, tutorials, gist, github projects, etc... are very important learning ressources in one's journey to programming. There is a reason why books like "Rust by example" are popular, and why online tutorials (articles or videos) have been and still are one of the major ways people start coding. And that is because people can just copy the code, tweak it a bit, see what changes, and that's how they discover and understand new concepts or quirks or advantages of a language (or framework). Copying code is really important to beginners, and that apply to people that are beginners in certain areas, even though they know their way around the language. If you've never done image processing before, you'll probably start by copying some code at first, tweak it a bit around to understand it, and you'll reuse that knowledge later in your app/project. However, mindlessly copy-pasting things brainlessly without ever looking into it is wrong, I think we can all agree with that (except for nasty incomprehensible bugs that we just don't have the time to get into at our job (although they should be re-examined later if possible)). Most of the other ones are either the most obvious thing, or more indicative of a bad human being than a bad programmer, so I hope the people that read this list didn't need to be told those were bad, both for them and the people around them (seriously tho, please ask for help around you, it's really important for any kind of stuff, not only work).
Although I'm quite tired so maybe I just interpreted that whole thing completely wrong. Sorry for that, and sorry for the rant, I didn't mean to sound like a dick (is that word/expression allowed here ben ?), but it seems like I often do.
Thanks for this concise list, very interesting. However, I disagree with some points:
don’t write enough comments: Comment can often be considered as code smell, documenting your code with comments is ok, commenting all your code is not. When you update your code you need to update all your comments also, but developers are lazy so you get outdated and misleading comments. If you comment everything you will comment even self-explanatory code, which is useless. If your code isn't self-explanatory, it's maybe too complex and code is intended to be read by humans. There are plenty of reasons why you don't want to comment your code. But some people already wrote great blog posts about this subject, so I will let you google about it.
copy code from online: Well, it depends, copying blindly without mentioning the origin of the code is very bad, especially if the code is under some licence (like on StackOverflow). But otherwise, it's often pretty useful, and if you can adapt the copied code well to your use-case, it's sometime a great time-saver, as long as you have the right to do it obviously. And in this case it's good to add a comment to reference the origin of the code.
don’t plan before implementing: Again, it depends, on your workflow and organization mostly. Sometimes you want/need to plan, sometimes not. It's not a bad programming habit, it's just a way of doing things. In some case you will have to, in other cases you want to avoid it.
count hours: If you're freelance, you do want to count your hours, to bill the right amount of time, and maybe to ensure that your estimations were right. Otherwise, yeah in a lot of cases, don't count, "When it comes to love, you don't count the cost.".
don’t use social media: If the social media is facebook or instagram, I'm not sure you really need this to work, it could be more a distraction than a benefit. If it's reddit or dev.to, it can be a great source of inspiration or help. So again, it depends.
Again, thanks for this great list, there is always places where you cannot agree with everybody, but different point of view are always interesting.
Great list. But don't agree with 11. I see nothing wrong in copying code if it does exactly what you need.
Yes, and it completely contradicts #4 - online code IS a resource. However using online code and not trying to understand it is a bad habit.
Comments in your code are often an indication that your code isn't clear enough.
I agree with most of the other points though.
Add: Multitasking
Summary:
"People who don't do things my way are bad programmers."
Sometimes I re-visit my code after a month and have no idea why I did what I did. And then I need to spend some time to understand what I was trying to solve and what kind of cases I had thought of...
Great list!
My two cents:
About 11. Well that depends on your version of what "copying" is. :)
About no. 5, maybe you meant warnings because how can tou possibly 'ignore' errors?