

What most young programmers need to learn - GarethX
http://joostdevblog.blogspot.com/2015/01/what-most-young-programmers-need-to.html

======
vog
_> 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.

~~~
danieltillett
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.

~~~
jerven
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.

~~~
danieltillett
Yes I also think this is what I should do to, unfortunately when I first wrote
the code I spend most of my time working on I didn't write unit tests at the
function level (all my tests are at the module level). I have been meaning to
get around correcting this, but the task is now so huge I fear it would take
me more than a year to write all the unit tests :(

~~~
jerven
IMHO every automated test helps.

Don't aim for 100% test coverage aim at using unit tests to develop faster and
more efficiently and the test coverage stats will come automatically.

I personally need to improve my TDD, but I am quite happy with my test driven
bug fixing approach. When working on a bug I first turn it into a JUnit or
selenium test, and then fix the bug and make the test pass.

------
danso
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

------
deeteecee
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
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 ;)

~~~
cjslep
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.

~~~
eropple
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.

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

~~~
sanderjd
This is a great discussion! I've always thought that after the basic "how do I
even do this at all?" concepts of programming, the next most important concept
to learn how to wield and to perpetually sharpen is the "don't repeat
yourself" principle. Huge swaths of software engineering literature is
dedicated (explicitly or implicitly) to when and when not to apply that
principle.

Your parent's comment addresses by far the best argument _for_ the principle,
which is that any time something is likely to change in a snippet, copy-
pasting should be undertaken rarely and thoughtfully. With the recognition
that nearly any given snippet is likely to change in some way, we can conclude
that nearly any copy-paste is "bad".

Your comment is then a great argument _against_ the thoughtless application of
the principle, recognizing that yes, granted, nearly any snippet will change,
but the required changes may well not be uniform.

Personally, I think it still makes sense to pull out shared behavior for the
period of time in which it is shared. During that period of time, all you have
is a guess that the code might eventually diverge. If there comes a point in
time when you do want the code to diverge, it is straightforward to copy-paste
it back out, if branching or creating a similar method with the differences is
a worse option. On the flip side, if you haven't pulled out the shared
behavior, and you discover that you want to change it everywhere in the same
way, it is far less straightforward to go find all those places, or even be
aware that you need to do so.

Another point is naming by purpose rather than behavior. To continue your
example, it makes sense to ask _why_ one method checks internally and the
other externally? What different purposes do the different checking styles
have? If there are good answers to questions like that, the methods can be
named better, and it becomes less about memorizing name than understanding
when to use which.

Of course none of this is at all black and white, and I think you're spot on
that this is one of those _craft_ bits, and among the most important!

~~~
sophacles
One thing to keep in mind here... some of those "you can't predict" things are
utterly predictable in light of experience. That part can't be faked to well,
there aren't a good set of rules about it. But experience is a good teacher,
and you do eventually learn to be reasonably accurate about when to do C+P vs
DRY, even if you can't explain the _why_ of it.

I think it comes down to this - when I first learned to code, it was hard
enough to keep track of a couple different functions. As experience came, what
I could track and reason about and keep in my mental model grew, so now that
I've got some experience I can see more of how the whole system will grow and
interact. I'm not really smarter per se, but rather I just have more practice
as putting it all together.

~~~
sanderjd
Couldn't agree more. It's definitely a function of the extent to which you're
guessing, which is a function of your experience solving very similar
problems.

I do think we (programmers? people?) have a tendency to avoid inspecting the
experience we already have. We thought hard about some pattern a few times and
came up with some instincts based on that experience, which is great, but we
should make sure to double-check those instincts from time to time.

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

------
Bahamut
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
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
I don't think there's anything wrong with any method that also makes me tea :P

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

~~~
alistairSH
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
Fair enough, that's very true.

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

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

~~~
spacemanmatt
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.

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

------
logn
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)

------
larssonvomdach
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/)

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

------
jkot
Young programmers should first learn to _READ_ and understand code.

~~~
innguest
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
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
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.

------
akbar501
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
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
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).

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

~~~
mkehrt
Disagree about monads. What you mean is that _IO actions_ are an awkward way
to ensure evaluation order in a lazy language. In Haskell, IO actions form a
monad, but this is only reasonable because so many other things form a monad
that the language has special support for them.

Monads are great in that disparate things like lists, sets, IO, control flow,
state, optional values, and even functions are all instances of a single ADT
which is useful enough that one can write reasonable code abstracted over it,
and Haskell provides the mechanisms to do so.

~~~
dschiptsov
> one can write reasonable code abstracted over it

Don't you think that at least in a strict language, this would be rather over-
abstraction or abstracting for the sake of abstraction?

~~~
mkehrt
Not really. I think you're confusing Haskell's purity, which makes it
necessary to write monadic code, with its monad syntax, which makes it easy.

~~~
dschiptsov
I think I am not. Monads has nothing to do with "purity" \- Erlang is a pure-
functional language but there are no monads.

Monad make sense only within a language with Normal (instead of Applicative)
order of evaluation, to ensure that one computation (or action) "finishes"
(being reduced to a value) before another ( _> >=_ and _> >_). _return_ is for
the type-checker.

~~~
mkehrt
That's a very specific way of thinking about monads. Sure, they enforce
ordering in a language where you may want to do that. But they're also any ADT
equipped with a generalized map (that we happen to call >>= or bind) that
commutes nicely. I don't think about my list operations using bind as about
ordering computation; I think about them as transforming data in a way that is
a little harder to do with more traditional list operations. Same with set,
maybe, etc. The ordering feature of monads is more about IO actions than it is
about monads in themselves.

All I'm saying is that monads are a useful abstraction regardless of whether
or not they are used to encapsulate effects. I use Traversables, which have a
bind operation, all the time in Scala, and it is an effectful language.

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

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

------
CmonDev
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
In my case I see this when I treat a class as a namespace and fail to follow
the single responsibility principle.

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

------
throwaway3301
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
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/)

------
vitd
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!

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

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

~~~
BoomWav
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.

------
grimborg
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-
Programme...](http://www.amazon.com/The-Clean-Coder-Professional-
Programmers/dp/0137081073)

~~~
codyb
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-
Const...](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)

[1] - [http://www.amazon.com/Talent-Overrated-Separates-World-
Class...](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)

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

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

~~~
sophacles
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
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
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.

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

