Inexperienced programmers sometimes can have a dysfunctional, almost worshipful, relationship with complexity. They're entering an industry riddled with complexity, most of it way over their heads, and they're in awe. So when they write complicated code themselves, they almost take it as a point of pride. I wrote this massive, tangled 300-line function that actually works, by god.
What most young programmers need to learn
71–80 of 108 posts
Re: What most young programmers need to learn
#72I have committed all of these mistakes at one time or the other and I am quite sure that I slip from time to time esp with regards to #1. But one thing that I frequently do is read my own code after writing a certain amount. It may be after writing a module or after re factoring it or when I don't feel like writing any more. And reading my own code helps me uncover a lot of inconsistencies in it. I think I started re…
Well said! A similar thing I do is to read the diff of what I've written so far before making a pull request, as if I were a reviewer. I've caught many mistakes and "TODO" comments that way.
Re: What most young programmers need to learn
#73Earlier quoted context omitted.
You mean getting used to other programmers' idiosyncrasies and deciphering them? You will dissuade them from ever taking up this profession with that attitude. I was attracted to this because of the opportunity to create things, not because other people wrote stuff and now I have to read it.
I disagree thats what the GP meant. Too often people just hack away without truly understanding what they are doing. Then you end up with trying a million things until finding something that works and not knowing why it works. If you take a few minutes to read the documentation and understanding why you are doing something rather than "I tried it and it worked" you will become a better programmer.
The Perl Cookbook was one of the best technical books I read in my early career, specifically because it said, "No, look, there are about four ways to do this right, and here are their tradeoffs" for multiple problems. Articulating that concept, and the ability to look at alternative implementations that each might be good, helped me a lot.
Re: What most young programmers need to learn
#74The 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.
I deal with this every single day. The errors made in poor schema propagate through the rest of the application.
To use a metaphor: It doesn't matter how delicious of an apple you have (the data), what truck you use to transport it (the back-end code), or how nice of a store display you put up (the front-end code), if you don't store them properly along the way (the schema).
Re: What most young programmers need to learn
#75I'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, jus…
As a junior programmer in the contracting world, I ask the same as it is also a business question. You do not want to create so much extra work in the process of refactoring that you wind up losing money or running out of time before creating what the client asked for. Asking the super (who is also tech savvy) allows him to worry about balancing the business with the needs of his code base.
Re: What most young programmers need to learn
#76The biggest challenges for me as an intern were reading and understanding someone else's code (Python) and understanding the problem domain quickly and sufficiently. It's hard to judge how deeply you need to understand something before you program around its concepts. Of course ideally you're an expert, but when you're potentially only using something for the summer it makes sense to somehow seek an understanding of the salient concepts without getting overwhelmed by details even though it's sometimes the little caveats that can make a tremendous positive or negative difference in your design depending on your knowledge of them.
And I'll admit that self-discipline was sometimes an issue. When you take responsibility for a complex project when young and inexperienced, you feel a lot of pressure to perform and get it working so you can tackle the next task. Maybe us noobs aren't used to this sort of pressure?
I had the chance to do a code review with a few of the top engineers in the company, and it was tremendously helpful. We focused on a small part of the code that was responsible for a performance bottleneck, and I didn't realize how sloppy some of my code was until we walked through the function. There were really silly redundant things that I thought I would never have written in my right mind. I was trying to optimize a function where some of the simplest code was redundant and actually contributing a bit to the performance problem. They were nice about it and said it was not unusual and that code reviews are great for spotting such things.
Re: What most young programmers need to learn
#77I disagree with his last point. There was once a time when I was obsessive about not copying pasting code. Over time I eventually learned that sometimes it better to just copy+paste a code snippet a few places than being dogmatic by making sure that nothing is ever duplicated. My rul of thumb is that if there is branching then don't copy, if there is no branching, then you can copy+paste it. This snippet should only…
what i understood as the author's issue with copy paste was the knowledge that changes are expected if you copy: do_something(); do_another_thing(); another_call(); a few times in your codebase, but decide that you want to alter that a bit: do_something(); perform_new_feature(); do_another_thing(); another_call(); you can hurt yourself by forgetting that that alteration needed to be done to each instance just easy to…
Yes in that case it's a win, but it becomes an anti pattern when you sometimes want to perform_new_feature() and sometimes you don't. I've seen it happen where you end up with many functions like:
def a_and_b_and_c() {...}
def a_and_b_and_c_error_checked_internally() {...}
def a_and_new_and_b_and_c {...}
def a_and_new_and_b_and_c_error_checked_internally() {...}
def a2_and_b_and_c
Re: What most young programmers need to learn
#78Earlier quoted context omitted.
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, jus…
As a junior programmer in the contracting world, I ask the same as it is also a business question. You do not want to create so much extra work in the process of refactoring that you wind up losing money or running out of time before creating what the client asked for. Asking the super (who is also tech savvy) allows him to worry about balancing the business with the needs of his code base.
I would submit that being a junior programmer in the contracting world is a nontrivial part of the problem. Contracting relies on a lot of really bad incentives that I personally suspect are largely antithetical to good practice.
Re: What most young programmers need to learn
#79I've stopped worrying about duplicating code that is less than one line long, and I'm a happier person as a result. It's a slippery slope that eventually you stop writing code that actually does anything and are just writing layers of indirection. Similarly, not all string values need to be named constants, because not all string values are intended to be changed.
(edited)
Re: What most young programmers need to learn
#80From someone who started as a developer only 2 years ago, I found the stuff about how to properly design classes to be the hardest part. There is not enough touted articles on it on the internet. For example, how would a developer know to break [insert functionality] into a separate method? It is not always obvious to junior developers to break a method into smaller chunks, especially when they understand every line…
And knowing when OO is not the right solution to all problems.
In this case, I'm using classes very loosely - the same applies to methods, and when to break them up into smaller methods.