I'm a junior programmer still so I'd like to share my thoughts regarding this post. I'd actually like to say that I've been aware of all these (code commenting, incorrect function names, etc.) and the thought of changing them is always "it takes up time" or "you don't know if it's worth the time." But I'm always asking my superior that specific question: "can I get rid of this?" Unfortunately, wherever I've worked, I haven't been working under very experienced people either so they've responded to me with the simple "uhhhh..." and given me no answers. In the end, I end up faulting into habiting into this article's main points.
What most young programmers need to learn
21–30 of 108 posts
Re: What most young programmers need to learn
#22Expected to see a long list of algorithm design books, but was pleasantly surprised. "In this case however it all still makes sense to be in one class, but the class simply grows too big." - would be nice to see some examples, I bet anything can be split in a nice way.
In my case I see this when I treat a class as a namespace and fail to follow the single responsibility principle.
Re: What most young programmers need to learn
#23The following are a few of the most common issues that I see in code written by young programmers. These are also issues that experienced developers can help new developers fix by
1. Lack of knowledge of the business domain leading to an inability to understand the high-level, conceptual view of a system
2. Poorly named variables
3. Poor code organization
4. Loose cohesion in objects and functions which in part flows from bad naming
IME, these issues can be fixed on an accelerated timetable when experienced developers help mentor younger ones.
Re: What most young programmers need to learn
#24I'm a junior programmer still so I'd like to share my thoughts regarding this post. I'd actually like to say that I've been aware of all these (code commenting, incorrect function names, etc.) and the thought of changing them is always "it takes up time" or "you don't know if it's worth the time." But I'm always asking my superior that specific question: "can I get rid of this?" Unfortunately, wherever I've worked, I…
Why do you ask for a permission?
If I am working on a task and code got a bit too messy for my liking, I'd simply refactor, it's simply part of the task. Working != complete. If something goes wrong, it will be easy to revert given it is committed in a sane way (i.e. not loads of unrelated work under one commit).
It's a bit different if you want to do major refactoring (taking multiple days). But with small ones, just do as you go ;)
Re: What most young programmers need to learn
#25I'm a junior programmer still so I'd like to share my thoughts regarding this post. I'd actually like to say that I've been aware of all these (code commenting, incorrect function names, etc.) and the thought of changing them is always "it takes up time" or "you don't know if it's worth the time." But I'm always asking my superior that specific question: "can I get rid of this?" Unfortunately, wherever I've worked, I…
The short answer is "yes, it's worth the time".
One big improvement I've made in my code over the years is that I take the time to improve my code. Continuously improving code quality does lead to high code quality, and high code quality reduces maintenance hours (both amount needed and time spent).
Re: What most young programmers need to learn
#26> Code in comments [...] When asked applicants are usually well aware that commented-out-code is confusing, but somehow they almost always have it in their code. To my experience this is a common symptom of not using a version control system. You change a line of code, but you want to be able to undo if it doesn't work, possiblay half an hour later when you changed other places of your code (so your editor's undo is…
> I also see this from people who are using VCS, but that's mostly because they are overcautious and/or have not really gotten "warm" with the VCS.
Yeah, that could probably describe me. Reverting a particular piece of code back from VCS seems like more work (the kind of "I need to think about it" work), which is enough for me to leave bits of code commented when working on some particular task. I never leave them there for long - usually only until I can get the new piece of code working and tested. The commented code serves as a reference/fallback.
Re: What most young programmers need to learn
#27One I see regularly is not testing code or writing tests that are useless. To some extent, it's related to the mistakes mentioned in the post: messy code is hard to test.
Re: What most young programmers need to learn
#28I'm a junior programmer still so I'd like to share my thoughts regarding this post. I'd actually like to say that I've been aware of all these (code commenting, incorrect function names, etc.) and the thought of changing them is always "it takes up time" or "you don't know if it's worth the time." But I'm always asking my superior that specific question: "can I get rid of this?" Unfortunately, wherever I've worked, I…
I think part of the point of this article is to say that your transition into "seasoned developer" status should include developing your own opinions and solutions to the code smells discussed.
Re: What most young programmers need to learn
#29The following are a few of the most common issues that I see in code written by young programmers. These are also issues that experienced developers can help new developers fix by 1. Lack of knowledge of the business domain leading to an inability to understand the high-level, conceptual view of a system 2. Poorly named variables 3. Poor code organization 4. Loose cohesion in objects and functions which in part flows…
Poor database schema design. If you get this wrong it makes your life a lot more difficult and it is harder to fix. These bad models often outlive the applications themselves. You see these around years after they were made.
Re: What most young programmers need to learn
#30I'm just not sure you can teach these things to a junior programmer, and actually expect to see results. A baby takes 9 months to develop, you can't expect to see finger nails develop until they've developed fingers. As a junior, you're probably spending most of your time (and a lot of it at that) just trying to make the dang code work. Making sure it's written in a way that other people can maintain it etc is second…
>>> I'm just not sure you can teach these things to a junior programmer, and actually expect to see results
You can't expect to teach them and see results immediately. But teaching them (and supervising / reviewing code) would certainly help to make the learning period shorter.