- 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
Oldest comments (31)
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.
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.
Clean code should be self explanatory. It should rarely require comments
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
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.
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.
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?
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...
Comments in your code are often an indication that your code isn't clear enough.
I agree with most of the other points though.
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.
Summary:
"People who don't do things my way are bad programmers."
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.