11 ms·

What most young programmers need to learn

203 points by GarethX 12y ago

sonny9 12y ago
I keep hunting for such a post specifically for an iOS Developer.. to get beyond the initial frameworks and learn processes and flows
- sophacles 12y ago
  Everyone hates to do it, but a lot of this comes from reading code. The more code you read, the more you'll learn to understand idioms, styles, what makes things good and bad for understandability. Then you'll be able to do it yourself. Another point to make: while every language has it's own idiom and style, there are also lots of "clean code" lessons that apply across languages, so guides about, e.g. python, translate somewhat into objective c.
  - ddebernardy 12y ago
    It depends on what code you read, though. Think of PHP devs that learn from WordPress, for instance. It's not exactly setting a great example... (Though to their credit, WordPress improved somewhat in recent years.)
    - sophacles 12y ago
      On the one hand, sure this makes some sense, on the other, it maybe means read more code... (i know this sounds sort of snarky). For example, if I wanted to write a novel, and had only read say, _A Tale of Two Cities_ I might thing I needed to include a bunch of broad social statements, and make my point through strongly contrasting scenes and juxtaposition. If I had only read Dickens, I might think writing a novel entailed finding only strange characters, pointing out social flaws. Keeping a thematic style that was about confusing light and dark with the normal associations. And so on. If I had only read Twilight, I wouldn't care much about dialog or character development. I wouldn't understand that there are things you can do thematically without exposition. If however read Dickens, and Hemingway, and Tolkein and Dan Brown, and Stephanie Meyer and ... I would have a different understanding of what could go into a novel. I would be able to see where story arc intersects with bigger themes and character development. I would see different ways of structuring sentences, paragraphs, chapters, and even whole books. None of this reading of course will make me a great author, writing does that, but a wide exposure will certainly help me understand where my writing is working vs where it isn't, it will help me understand how to structure things, help me shape my own work. I consider the same to be true of code. The folks that only read WordPress code have a very limited understanding of possibilities. The folks who have read that, and rails and django, and jekyll and flask and ... will see a wide range of styles, ideas about structure, and so on. An aside: Wordpress has some pretty ugly parts, but there are some ideas in there about structure that I have always liked. Particularly considering it was designed and written during the "explore and figure out what works" phase of web apps, when the industry didn't really have a "best practices for the web" that included lots of experience with what does and doesn't work.
  - organsnyder 12y ago
    Reading code is a good start, but I've found that it's not enough. When faced with an unfamiliar concept, I'm not sure whether it's an unfamiliar design pattern, a hacky kludge, or a special case to get around some quirk for a particular use-case. I've found that reading books—such as the Pragmatic Programmer series, Effective Java, and others—helps me to understand the rationale behind what otherwise seem like strange (sometimes even boneheaded) design decisions. Even oft-derided patterns (such as the "FooBuilderFactoryBuilder" so often seen in the Java world) make sense when understood in the context of the problems they're trying to address.
- _asummers 12y ago
  Check http://www.objc.io/ http://www.objc.io/ for good pointers for iOS and Objective-C related things. I haven't done iOS for a year/year and a half, and I still read their posts.
CmonDev 12y ago
Expected 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.
- Koholint 12y ago
  In my case I see this when I treat a class as a namespace and fail to follow the single responsibility principle.
vog 12y ago
> 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 of no use). 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. A final, very small percentage are familar with VCS and confident with their code, but leave that commented stuff in there accidentally. The usual cause it that they have not (yet) acquired the habit of reviewing the diff before committing.
- irremediable 12y ago
  Yeah... I need to stop doing this. Hangover from pre-VCS academic code-soup habits.
- danieltillett 12y ago
  I am guilty of commenting out code when I am working on a problem, but before committing I remove it unless it is the simple version of some function that I made way too complex in order to improve performance. I find it easier to understand later what the complex code is supposed to be doing if I have the simple implementation in the comments.
  - wmt 12y ago
    I wouldn't call the simpler implementation "commented out code", as it's doing what the best comments are doing, making complex code more readable. Having random scribbles, alt solutions and other "shitty" comments while working on a problem is definitely not a sin if you clean them up before pushing them forward.
  - jerven 12y ago
    I suggest you move the simple version into a unit test case. Making sure the simple version and the complicated one have the same results. Plus I like to add some perf test that shows the complicated version is faster than the simple one that I can rerun after major upgrades to the lower level system e.g. when upgrading from java 1.5 to 1.6 I could remove some complicated code because the simple one was then as fast due to an improved JIT.
larssonvomdach 12y ago
The insight that "knowledge" is not the the problem, but "self discipline" is an interesting one. I made similar observations and came up with a list of "coding commandments": https://larsxschneider.github.io/2013/08/25/ten-commandments/ https://larsxschneider.github.io/2013/08/25/ten-commandments...
onion2k 12y ago
Well-organised code with sensible, correct naming of things will save you years of development time during your career.
- spacemanmatt 12y ago
  True story. I could not tolerate most programming without consistent conventions to guide me. Pretty much every programming language has had a meta-language of convention that went with it, to support learning and readability.
jenscow 12y ago
So true. When I was a junior, code quality was the first thing I was taught, in the first week. While the code worked reasonably well, there was no indentation, spacing, comments and variable names longer than one letter (perhaps because my first language was GW-BASIC).
- spacecowboy_lon 12y ago
  That was often done with GWBASIC to fit the code into the small amount of memory. Anoter trick was always to manualy unwind any loop counters if you had tp break out of a loop as the GWBASICS had a memory leak.
jkot 12y ago
Young programmers should first learn to _READ_ and understand code.
- innguest 12y ago
  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.
  - UrMomReadsHN 12y ago
    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.
    - gknoy 12y ago
      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.
dschiptsov 12y ago
Scheme. As still the best "small" language to teach fundamental principles (everything is a first-class value, symbols are references to values - naming, procedure composition and nesting as the basic building block, ADTs, immutability of the data, evaluation strategies - eager and lazy, and what is meant by "mostly functional language", etc.) and shapes of data structures (list, three, table). It will pay back with any "stack" or a "framework". Haskell. To learn that static typing done right (type inference) is a very clever feature, but it catches only simple errors (it cannot catch flawed logic or wrong abstractions), so it is not a silver bullet, and, perhaps, to realize why "extremes", like "pure-functionality" or "lazy language" are rather unnecessary complications than big gains. And that monads are mere accidental, awkward ADT to ensure an order of evaluation in a "lazy language", where it is undefined by definition. After that one would find everything in industry is rather easy and boring and develop a healthy aversion to Java and other "packers" stuff.
- innguest 12y ago
  I agree with everything you said here; I particularly agree with the part where you say that after knowing Scheme and Haskell everything else becomes easy and boring. Does it ever. Makes me question why I got into programming now that I see the bigger picture of what I have been diligently trying to master for over 15 years. To the beginner I'd say: study Scheme and Haskell. Understand them. Once you do, look at other languages. Everything should be familiar. Now you have to decide if you want to spend your professional life always learning different ways to do the same few things there are to do that you learned from Scheme. YMMV but yes it gets boring and yes it will burn you out.
  - mod 12y ago
    Maybe it's like cheating in video games. Maybe we should all play the normal game instead of turning on god-mode Scheme? I'm not going to lie: I don't want to be bored or burnt out.
    - innguest 12y ago
      I like the metaphor and think it's on point. It's as if you found a way to make cash appear from nowhere. It would be hard to find a reason to work for money. Same deal with Scheme. It lets you do anything, easily, but it makes it hard to find a reason to want to do anything. To be fair I wouldn't blame it on Scheme, more on my own brain, but still, beginners should look at Scheme right away so they can get to the "I can do anything, now what do I want to do, if anything, with this tool" part faster.
amirouche 12y ago
I'll add to the list: - The inability of younger pears to ask for help or otherwise design reviews before they write the code. - Super hero programming which most of the time boils down to the above and various forms of pseudo-optimisation that are difficult to read. E.g. messing with inheritance and directions: UpwardEngine --- inherits ---> DownwardEngine, instead of using a BaseEngine, because it's saves one class definition (and improve dispatch performance...) Another advice I would give to young developpers, is that getting as much as possible bits written helps getting better. The thing is that reading code to refactor and debug given the chance to do it right is more difficult and more rewarding in terms of skills.
- rhodri 12y ago
  My opinion is that most of the bad habits of inexperienced programmers are just manifestations of more general youthful hubris and inexperience in the nuances and complexities of life. I'll add to the list the most extreme form of 'not written here syndrome': 'I didn't write it syndrome'. The programmer sees themselves on missing out on the fun of solving a task by using a library (or reading the relevant framework docs). When experience teaches you that the real misery comes down the line when you need to support your hand-rolled physics engine lacking in tests...
pm90 12y ago
One thing that should be mentioned here is that the amount of time that one has to learn to write code really depends on the company one works at. If you work at smaller firms, its much harder to justify putting in extra time beyond just making it work (although this bites you in the long term by making the codebase uglier). In the larger firms, you have much more time to do code reviews and refactoring.
danso 12y ago
What I've been surprised to learn after leaving school is how important it is for code to be stylistically sound: programmers should be as thoughtful about the structure, readability, and conventions of their code as professional writers are of their prose. This was something that didn't dawn on me until reading Matz's philosophy of "programmer happiness" when designing Ruby. Code seems sterile, something that you just put into place in a logical manner until it works...in small class projects, you don't realize the mental toll it can be to read through a messy code base...But being unhappy about a monolithic, massive codeebase is easy...the problem is tha when working on small projects, you don't notice the mental tax of unclear code that can drain your happiness and productivity. It took a long time of professional coding for me to realize how much thoughtful design of code could make me a happier coder, just like the adept use of language contributes to happier communication in all other areas of life
swalsh 12y ago
I'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 secondary, because who cares if you can maintain it if it never even worked in the first place! When working with a new junior, It's important to expose them to existing (good!) as well as bad code bases. At the same time, let them write new code on things that aren't super business critical. You have to accept that it's going to take them some time to learn, and you should just work with them until they don't have to think about breathing any more.
- gedrap 12y ago
  >>> 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.
- alistairSH 12y ago
  Yes, new programmers spend a lot of time just getting things to work. But, from years of managing summer interns, the biggest surprise to new programmers is the amount of non-code stuff that needs to be done alongside actual coding. Doc, comments, peer reviews (and the associated rework). The sooner they learn this is part of the job, the sooner they'll fit into the team's workflow and contribute at a high level.
  - swalsh 12y ago
    Fair enough, that's very true.
deeteecee 12y ago
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.
- gedrap 12y ago
  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 ;)
  - bmj 12y ago
    Yeah, I think the only time you need to ask permission is if the refactor would cause additional regression testing. Depending on the system, and unit test coverage, this may not even be a big deal, but sometimes, if you have a dedicated QC department, they may want to regress parts of the system even if they are covered by unit tests. Such regression could mean dates slip, etc, etc, and perhaps that's why someone might say "no."
  - Xeoncross 12y ago
    Yes, just like cleanup is part of construction.
  - cjslep 12y ago
    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.
akbar501 12y ago
The 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.
- huherto 12y ago
  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.
  - thirdtruck 12y ago
    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).
gedrap 12y ago
One 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.
grandalf 12y ago
It's hard to emphasize enough how important naming is. The author accurately describes the connection between class bloat and imprecise naming. One tip I'd offer is: You are not inventing something by naming it, you are describing how it's used (based on its behavior). If it's hard to name, one possibility is that it is not designed properly or that it's doing too much.
brickcap 12y ago
I 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 reading after @edw519 said something like he reads his code everyday before going to sleep. While during writing my focus is on making the thing work when I am reading I am more critical of my code. Not as good as having a review but still helpful. Also I think reading code of other programmers is a good exercise. Reading different styles of books is already recommended to writers and I think that programmers can extract same benefit by reading code of different programmers. If nothing else at least it will develop your debugging abilities.
- gknoy 12y ago
  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.
skimmas 12y ago
To code in mIRC. At least that's what I did.
grimborg 12y ago
The Clean Coder is a good read for starting programmers. It goes beyond code to what it takes to be a software professional. http://www.amazon.com/The-Clean-Coder-Professional-Programmers/dp/0137081073 http://www.amazon.com/The-Clean-Coder-Professional-Programme...
- atsaloli 12y ago
  Excellent. I'd also recommend "Code Simplicity: The Fundamentals of Software" http://www.amazon.com/gp/aw/d/B007NZU848?ie=UTF8&redirectFromSS=1&pc_redir=T1&noEncodingTag=1&robot_redir=1 http://www.amazon.com/gp/aw/d/B007NZU848?ie=UTF8&redirectFro...
- codyb 12y ago
  As well as the extensively reviewed, recommended, and appraised "Code Complete" [0] by Steve McConnell I'm working my way through it now (1+ year of professional experience) and it is a magnificent way to improve the quality of your code. I read it off and on, my goal is only 40 pages a week so that I'll make sure to find the time to do it (I'm doing a masters program and enjoy living in NYC too so setting huge goals doesn't work well for me). Every time I crack it open, I find myself inspired to write better, clearer, and more concise code. Sometimes you just need a nudge to get back into doing things you already know you should be doing. Finally, constantly learning, I think, is the best way to become a proficient, and then skillful professional software engineer. Many programmers become proficient and then level off. And that's good enough. But if you truly wanted to become one of the top 5% in your field you need to do something called deliberate practice. Reading 'Talent is Overrated' [1] really exposed me to the theory of constantly challenging yourself in order to grow. I really recommend it, I find myself trying to apply the theories to all areas of my life. [0] - http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=sr_1_1?s=books&ie=UTF8&qid=1420475290&sr=1-1&keywords=code+complete http://www.amazon.com/Code-Complete-Practical-Handbook-Const... [1] - http://www.amazon.com/Talent-Overrated-Separates-World-Class-Performers/dp/1591842948/ref=sr_1_1?ie=UTF8&qid=1420477978&sr=8-1&keywords=Talent+is+Overrated http://www.amazon.com/Talent-Overrated-Separates-World-Class...
freework 12y ago
I 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 live in one place: if (something) { for (blah blah) { something_else(); } do_something(); } on the other hand, this code can be copy+pasted as much as you like: do_something(); do_another_thing(); another_call(); some dogmatic programmers will want to place those last three lines of code into a separate function and instead copy+paste that. But I've found that doing that sometimes makes the code more harder to read.
- justifier 12y ago
  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 maintain if you do this: function dodoan() { do_something(); do_another_thing(); another_call(); } then copy paste dodoan() as many times as you want though i do agree all rules have their exceptions and should be handled in such a way that allows for future alterations stead some obsessive mindless adherence
  - sophacles 12y ago
    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 And so on. Basically you are just putting a memorization task on calling the names rather than using the underlying bits well. Learning the balances around this is one of those "craft" bits of programming.
Bahamut 12y ago
From 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 of code written. They usually recognize the problem once it is pointed out, but it doesn't often register beforehand.
- tragic 12y ago
  A common approach is to describe the functionality aloud. If your description includes the word 'and', then there may be a problem ("this method increments the foo counter, and makes the tea").
  - balabaster 12y ago
    I don't think there's anything wrong with any method that also makes me tea :P
  - Bahamut 12y ago
    It is the minute details that are sometimes the problem. For example, if a developer is iterating over an array to do something to each element, there is a good chance that that iterator should be separated out in the event that it may be reusable (if using something like map).
- spacecowboy_lon 12y ago
  And knowing when OO is not the right solution to all problems.
  - Bahamut 12y ago
    In this case, I'm using classes very loosely - the same applies to methods, and when to break them up into smaller methods.
balabaster 12y ago
Something I've learned over the years: "A little discipline now will save a lot of discipline later." This goes for anyone in any walk of life and in any profession.
_greim_ 12y ago
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.
- droidist2 12y ago
  Right, the best code strives to be dead simple, almost boring. It's not like poetry; it's not more fun when it has hidden obfuscated meaning behind it.
alexvr 12y ago
The 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.
logn 12y ago
I'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)
mahyarm 12y ago
This list of bad behaviors isn't limited to 'young' programmers either. Which is really sad.
- BoomWav 12y ago
  This. I see devs that have been programmers for 20 years and still can't name their methods properly. I see most of the things the article talks about daily.
vitd 12y ago
I agree that these are things programmers need to learn. I think analyzing code (as in debugging it, learning to read what someone else wrote and understand it), are equally important. I learned no debugging while getting my degree. (Or rather, I learned no debugging during school hours. I learned plenty working on my own projects during that time, though.) I see this with junior programmers we hire now, too. They sometimes don't even know what a debugger is!
throwaway3301 12y ago
How does one keep these things in practice in the reality of an over-committed software team with shifting priorities, difficulties interfacing with product management, and bad specifications/requirements that eventually result in significant scope creep? I often feel like I want to refactor code, but the cost of doing so is so high that it would slow me down to the point of missing a deadline. "It works" is usually as much as I have time for. Maybe I'm just not a very good programmer...
- frostmatthew 12y ago
  Instead of trying to dedicate time specifically to refactor try to clean up classes as you come across them when fixing bugs or adding features. Whenever I open a file, I try and take a quick glance to see if there's anything that could use refactoring before working on the actual issue (if it's either a particularly large file or one that hasn't been touched in years I'll check Sonar[1]). [1] http://www.sonarsource.com/ http://www.sonarsource.com/

203 points by GarethX 12y ago

I keep hunting for such a post specifically for an iOS Developer.. to get beyond the initial frameworks and learn processes and flows

sophacles 12y ago
Everyone hates to do it, but a lot of this comes from reading code. The more code you read, the more you'll learn to understand idioms, styles, what makes things good and bad for understandability. Then you'll be able to do it yourself. Another point to make: while every language has it's own idiom and style, there are also lots of "clean code" lessons that apply across languages, so guides about, e.g. python, translate somewhat into objective c.
- ddebernardy 12y ago
  It depends on what code you read, though. Think of PHP devs that learn from WordPress, for instance. It's not exactly setting a great example... (Though to their credit, WordPress improved somewhat in recent years.)
  - sophacles 12y ago
    On the one hand, sure this makes some sense, on the other, it maybe means read more code... (i know this sounds sort of snarky). For example, if I wanted to write a novel, and had only read say, _A Tale of Two Cities_ I might thing I needed to include a bunch of broad social statements, and make my point through strongly contrasting scenes and juxtaposition. If I had only read Dickens, I might think writing a novel entailed finding only strange characters, pointing out social flaws. Keeping a thematic style that was about confusing light and dark with the normal associations. And so on. If I had only read Twilight, I wouldn't care much about dialog or character development. I wouldn't understand that there are things you can do thematically without exposition. If however read Dickens, and Hemingway, and Tolkein and Dan Brown, and Stephanie Meyer and ... I would have a different understanding of what could go into a novel. I would be able to see where story arc intersects with bigger themes and character development. I would see different ways of structuring sentences, paragraphs, chapters, and even whole books. None of this reading of course will make me a great author, writing does that, but a wide exposure will certainly help me understand where my writing is working vs where it isn't, it will help me understand how to structure things, help me shape my own work. I consider the same to be true of code. The folks that only read WordPress code have a very limited understanding of possibilities. The folks who have read that, and rails and django, and jekyll and flask and ... will see a wide range of styles, ideas about structure, and so on. An aside: Wordpress has some pretty ugly parts, but there are some ideas in there about structure that I have always liked. Particularly considering it was designed and written during the "explore and figure out what works" phase of web apps, when the industry didn't really have a "best practices for the web" that included lots of experience with what does and doesn't work.
- organsnyder 12y ago
  Reading code is a good start, but I've found that it's not enough. When faced with an unfamiliar concept, I'm not sure whether it's an unfamiliar design pattern, a hacky kludge, or a special case to get around some quirk for a particular use-case. I've found that reading books—such as the Pragmatic Programmer series, Effective Java, and others—helps me to understand the rationale behind what otherwise seem like strange (sometimes even boneheaded) design decisions. Even oft-derided patterns (such as the "FooBuilderFactoryBuilder" so often seen in the Java world) make sense when understood in the context of the problems they're trying to address.
_asummers 12y ago
Check http://www.objc.io/ http://www.objc.io/ for good pointers for iOS and Objective-C related things. I haven't done iOS for a year/year and a half, and I still read their posts.

CmonDev 12y ago

Expected 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.

Koholint 12y ago
In my case I see this when I treat a class as a namespace and fail to follow the single responsibility principle.

vog 12y ago

> 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 of no use). 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. A final, very small percentage are familar with VCS and confident with their code, but leave that commented stuff in there accidentally. The usual cause it that they have not (yet) acquired the habit of reviewing the diff before committing.

irremediable 12y ago
Yeah... I need to stop doing this. Hangover from pre-VCS academic code-soup habits.
danieltillett 12y ago
I am guilty of commenting out code when I am working on a problem, but before committing I remove it unless it is the simple version of some function that I made way too complex in order to improve performance. I find it easier to understand later what the complex code is supposed to be doing if I have the simple implementation in the comments.
- wmt 12y ago
  I wouldn't call the simpler implementation "commented out code", as it's doing what the best comments are doing, making complex code more readable. Having random scribbles, alt solutions and other "shitty" comments while working on a problem is definitely not a sin if you clean them up before pushing them forward.
- jerven 12y ago
  I suggest you move the simple version into a unit test case. Making sure the simple version and the complicated one have the same results. Plus I like to add some perf test that shows the complicated version is faster than the simple one that I can rerun after major upgrades to the lower level system e.g. when upgrading from java 1.5 to 1.6 I could remove some complicated code because the simple one was then as fast due to an improved JIT.

larssonvomdach 12y ago

The insight that "knowledge" is not the the problem, but "self discipline" is an interesting one. I made similar observations and came up with a list of "coding commandments": https://larsxschneider.github.io/2013/08/25/ten-commandments/ https://larsxschneider.github.io/2013/08/25/ten-commandments...

onion2k 12y ago

Well-organised code with sensible, correct naming of things will save you years of development time during your career.

spacemanmatt 12y ago
True story. I could not tolerate most programming without consistent conventions to guide me. Pretty much every programming language has had a meta-language of convention that went with it, to support learning and readability.

jenscow 12y ago

So true. When I was a junior, code quality was the first thing I was taught, in the first week. While the code worked reasonably well, there was no indentation, spacing, comments and variable names longer than one letter (perhaps because my first language was GW-BASIC).

spacecowboy_lon 12y ago
That was often done with GWBASIC to fit the code into the small amount of memory. Anoter trick was always to manualy unwind any loop counters if you had tp break out of a loop as the GWBASICS had a memory leak.

jkot 12y ago

Young programmers should first learn to _READ_ and understand code.

innguest 12y ago
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.
- UrMomReadsHN 12y ago
  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.
  - gknoy 12y ago
    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.

dschiptsov 12y ago

Scheme. As still the best "small" language to teach fundamental principles (everything is a first-class value, symbols are references to values - naming, procedure composition and nesting as the basic building block, ADTs, immutability of the data, evaluation strategies - eager and lazy, and what is meant by "mostly functional language", etc.) and shapes of data structures (list, three, table). It will pay back with any "stack" or a "framework". Haskell. To learn that static typing done right (type inference) is a very clever feature, but it catches only simple errors (it cannot catch flawed logic or wrong abstractions), so it is not a silver bullet, and, perhaps, to realize why "extremes", like "pure-functionality" or "lazy language" are rather unnecessary complications than big gains. And that monads are mere accidental, awkward ADT to ensure an order of evaluation in a "lazy language", where it is undefined by definition. After that one would find everything in industry is rather easy and boring and develop a healthy aversion to Java and other "packers" stuff.

innguest 12y ago
I agree with everything you said here; I particularly agree with the part where you say that after knowing Scheme and Haskell everything else becomes easy and boring. Does it ever. Makes me question why I got into programming now that I see the bigger picture of what I have been diligently trying to master for over 15 years. To the beginner I'd say: study Scheme and Haskell. Understand them. Once you do, look at other languages. Everything should be familiar. Now you have to decide if you want to spend your professional life always learning different ways to do the same few things there are to do that you learned from Scheme. YMMV but yes it gets boring and yes it will burn you out.
- mod 12y ago
  Maybe it's like cheating in video games. Maybe we should all play the normal game instead of turning on god-mode Scheme? I'm not going to lie: I don't want to be bored or burnt out.
  - innguest 12y ago
    I like the metaphor and think it's on point. It's as if you found a way to make cash appear from nowhere. It would be hard to find a reason to work for money. Same deal with Scheme. It lets you do anything, easily, but it makes it hard to find a reason to want to do anything. To be fair I wouldn't blame it on Scheme, more on my own brain, but still, beginners should look at Scheme right away so they can get to the "I can do anything, now what do I want to do, if anything, with this tool" part faster.

amirouche 12y ago

I'll add to the list: - The inability of younger pears to ask for help or otherwise design reviews before they write the code. - Super hero programming which most of the time boils down to the above and various forms of pseudo-optimisation that are difficult to read. E.g. messing with inheritance and directions: UpwardEngine --- inherits ---> DownwardEngine, instead of using a BaseEngine, because it's saves one class definition (and improve dispatch performance...) Another advice I would give to young developpers, is that getting as much as possible bits written helps getting better. The thing is that reading code to refactor and debug given the chance to do it right is more difficult and more rewarding in terms of skills.

rhodri 12y ago
My opinion is that most of the bad habits of inexperienced programmers are just manifestations of more general youthful hubris and inexperience in the nuances and complexities of life. I'll add to the list the most extreme form of 'not written here syndrome': 'I didn't write it syndrome'. The programmer sees themselves on missing out on the fun of solving a task by using a library (or reading the relevant framework docs). When experience teaches you that the real misery comes down the line when you need to support your hand-rolled physics engine lacking in tests...

pm90 12y ago

One thing that should be mentioned here is that the amount of time that one has to learn to write code really depends on the company one works at. If you work at smaller firms, its much harder to justify putting in extra time beyond just making it work (although this bites you in the long term by making the codebase uglier). In the larger firms, you have much more time to do code reviews and refactoring.

danso 12y ago

What I've been surprised to learn after leaving school is how important it is for code to be stylistically sound: programmers should be as thoughtful about the structure, readability, and conventions of their code as professional writers are of their prose. This was something that didn't dawn on me until reading Matz's philosophy of "programmer happiness" when designing Ruby. Code seems sterile, something that you just put into place in a logical manner until it works...in small class projects, you don't realize the mental toll it can be to read through a messy code base...But being unhappy about a monolithic, massive codeebase is easy...the problem is tha when working on small projects, you don't notice the mental tax of unclear code that can drain your happiness and productivity. It took a long time of professional coding for me to realize how much thoughtful design of code could make me a happier coder, just like the adept use of language contributes to happier communication in all other areas of life

swalsh 12y ago

I'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 secondary, because who cares if you can maintain it if it never even worked in the first place! When working with a new junior, It's important to expose them to existing (good!) as well as bad code bases. At the same time, let them write new code on things that aren't super business critical. You have to accept that it's going to take them some time to learn, and you should just work with them until they don't have to think about breathing any more.

gedrap 12y ago
>>> 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.
alistairSH 12y ago
Yes, new programmers spend a lot of time just getting things to work. But, from years of managing summer interns, the biggest surprise to new programmers is the amount of non-code stuff that needs to be done alongside actual coding. Doc, comments, peer reviews (and the associated rework). The sooner they learn this is part of the job, the sooner they'll fit into the team's workflow and contribute at a high level.
- swalsh 12y ago
  Fair enough, that's very true.

deeteecee 12y ago

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.

gedrap 12y ago
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 ;)
- bmj 12y ago
  Yeah, I think the only time you need to ask permission is if the refactor would cause additional regression testing. Depending on the system, and unit test coverage, this may not even be a big deal, but sometimes, if you have a dedicated QC department, they may want to regress parts of the system even if they are covered by unit tests. Such regression could mean dates slip, etc, etc, and perhaps that's why someone might say "no."
- Xeoncross 12y ago
  Yes, just like cleanup is part of construction.
- cjslep 12y ago
  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.

akbar501 12y ago

The 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.

huherto 12y ago
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.
- thirdtruck 12y ago
  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).

gedrap 12y ago

One 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.

grandalf 12y ago

It's hard to emphasize enough how important naming is. The author accurately describes the connection between class bloat and imprecise naming. One tip I'd offer is: You are not inventing something by naming it, you are describing how it's used (based on its behavior). If it's hard to name, one possibility is that it is not designed properly or that it's doing too much.

brickcap 12y ago

I 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 reading after @edw519 said something like he reads his code everyday before going to sleep. While during writing my focus is on making the thing work when I am reading I am more critical of my code. Not as good as having a review but still helpful. Also I think reading code of other programmers is a good exercise. Reading different styles of books is already recommended to writers and I think that programmers can extract same benefit by reading code of different programmers. If nothing else at least it will develop your debugging abilities.

gknoy 12y ago
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.

skimmas 12y ago

To code in mIRC. At least that's what I did.

grimborg 12y ago

The Clean Coder is a good read for starting programmers. It goes beyond code to what it takes to be a software professional. http://www.amazon.com/The-Clean-Coder-Professional-Programmers/dp/0137081073 http://www.amazon.com/The-Clean-Coder-Professional-Programme...

atsaloli 12y ago
Excellent. I'd also recommend "Code Simplicity: The Fundamentals of Software" http://www.amazon.com/gp/aw/d/B007NZU848?ie=UTF8&redirectFromSS=1&pc_redir=T1&noEncodingTag=1&robot_redir=1 http://www.amazon.com/gp/aw/d/B007NZU848?ie=UTF8&redirectFro...
codyb 12y ago
As well as the extensively reviewed, recommended, and appraised "Code Complete" [0] by Steve McConnell I'm working my way through it now (1+ year of professional experience) and it is a magnificent way to improve the quality of your code. I read it off and on, my goal is only 40 pages a week so that I'll make sure to find the time to do it (I'm doing a masters program and enjoy living in NYC too so setting huge goals doesn't work well for me). Every time I crack it open, I find myself inspired to write better, clearer, and more concise code. Sometimes you just need a nudge to get back into doing things you already know you should be doing. Finally, constantly learning, I think, is the best way to become a proficient, and then skillful professional software engineer. Many programmers become proficient and then level off. And that's good enough. But if you truly wanted to become one of the top 5% in your field you need to do something called deliberate practice. Reading 'Talent is Overrated' [1] really exposed me to the theory of constantly challenging yourself in order to grow. I really recommend it, I find myself trying to apply the theories to all areas of my life. [0] - http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=sr_1_1?s=books&ie=UTF8&qid=1420475290&sr=1-1&keywords=code+complete http://www.amazon.com/Code-Complete-Practical-Handbook-Const... [1] - http://www.amazon.com/Talent-Overrated-Separates-World-Class-Performers/dp/1591842948/ref=sr_1_1?ie=UTF8&qid=1420477978&sr=8-1&keywords=Talent+is+Overrated http://www.amazon.com/Talent-Overrated-Separates-World-Class...

freework 12y ago

I 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 live in one place: if (something) { for (blah blah) { something_else(); } do_something(); } on the other hand, this code can be copy+pasted as much as you like: do_something(); do_another_thing(); another_call(); some dogmatic programmers will want to place those last three lines of code into a separate function and instead copy+paste that. But I've found that doing that sometimes makes the code more harder to read.

justifier 12y ago
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 maintain if you do this: function dodoan() { do_something(); do_another_thing(); another_call(); } then copy paste dodoan() as many times as you want though i do agree all rules have their exceptions and should be handled in such a way that allows for future alterations stead some obsessive mindless adherence
- sophacles 12y ago
  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 And so on. Basically you are just putting a memorization task on calling the names rather than using the underlying bits well. Learning the balances around this is one of those "craft" bits of programming.

Bahamut 12y ago

From 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 of code written. They usually recognize the problem once it is pointed out, but it doesn't often register beforehand.

tragic 12y ago
A common approach is to describe the functionality aloud. If your description includes the word 'and', then there may be a problem ("this method increments the foo counter, and makes the tea").
- balabaster 12y ago
  I don't think there's anything wrong with any method that also makes me tea :P
- Bahamut 12y ago
  It is the minute details that are sometimes the problem. For example, if a developer is iterating over an array to do something to each element, there is a good chance that that iterator should be separated out in the event that it may be reusable (if using something like map).
spacecowboy_lon 12y ago
And knowing when OO is not the right solution to all problems.
- Bahamut 12y ago
  In this case, I'm using classes very loosely - the same applies to methods, and when to break them up into smaller methods.

balabaster 12y ago

Something I've learned over the years: "A little discipline now will save a lot of discipline later." This goes for anyone in any walk of life and in any profession.

_greim_ 12y ago

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.

droidist2 12y ago
Right, the best code strives to be dead simple, almost boring. It's not like poetry; it's not more fun when it has hidden obfuscated meaning behind it.

alexvr 12y ago

The 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.

logn 12y ago

I'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)

mahyarm 12y ago

This list of bad behaviors isn't limited to 'young' programmers either. Which is really sad.

BoomWav 12y ago
This. I see devs that have been programmers for 20 years and still can't name their methods properly. I see most of the things the article talks about daily.

vitd 12y ago

I agree that these are things programmers need to learn. I think analyzing code (as in debugging it, learning to read what someone else wrote and understand it), are equally important. I learned no debugging while getting my degree. (Or rather, I learned no debugging during school hours. I learned plenty working on my own projects during that time, though.) I see this with junior programmers we hire now, too. They sometimes don't even know what a debugger is!

throwaway3301 12y ago

How does one keep these things in practice in the reality of an over-committed software team with shifting priorities, difficulties interfacing with product management, and bad specifications/requirements that eventually result in significant scope creep? I often feel like I want to refactor code, but the cost of doing so is so high that it would slow me down to the point of missing a deadline. "It works" is usually as much as I have time for. Maybe I'm just not a very good programmer...

frostmatthew 12y ago
Instead of trying to dedicate time specifically to refactor try to clean up classes as you come across them when fixing bugs or adding features. Whenever I open a file, I try and take a quick glance to see if there's anything that could use refactoring before working on the actual issue (if it's either a particularly large file or one that hasn't been touched in years I'll check Sonar[1]). [1] http://www.sonarsource.com/ http://www.sonarsource.com/