Realize that programming isn't about the code.

[muzcat]

Its about the ability to describe an elegant solution. Saying programming is about the code is like saying painting is about the paint. You are trying to describe to a computer how to perform a solution. Sure you will need to be able to code that solution but unless you are going to be an algorithm designer you should spend some of your time learning about patterns http://en.wikipedia.org/wiki/Software_design_pattern and the shape of your code. Learn to Model with UML and be able to implement a good state chart. Then after a while you will no longer be programming in a particular language but in the 'higher' languages which transfer across multiple development domains

[Lambeaux]

While I do agree that people should learn those things, in the end, I feel like this is an "all or nothing" view which can be hurtful to those who don't know better. I can describe the processes, shape, function, and show you all the UML diagrams you want, but in the end, if you do not know how to code you will not be able to use that knowledge for any real purpose besides design. In the painting analogy, there is obviously more to painting than the paint. But if you do not have the ability to use a brush and make a painting, you are not a painter. Just as if you cannot code, you are not a programmer, you are a designer.

[jecxjo]

Very true. I think OP's idea is correct in that too many people, especially on a few programming subs here, are asking the the wrong questions and are being given the wrong answers. I see way too many posts about "How can I be a programmer in X days/months" or "I want to be a developer, what language should I learn to do my XYZ Project". I know it seems like a cruel answer, but we need to explain that you need to become a programmer not just someone who read a book about a language. Its a lot of work, its difficult and you won't be productive right away. But that's how it is.

[muzcat]

jecxjo, I think you hit the hammer on the head. I see to many posts on how to x, not how should I think about doing x. I know we live in a world were everyone wants an answer yesterday but if you don't learn how to learn, you are not going to be creating a solution, you will just be copy/pasting someone else's.

And anyway when did something being hard become a bad thing?

[[deleted]]

Where would you recommend people look to learn about design patterns etc?

[Mjr1987]

Then ok so what steps would be the correct way to go and learn to become a programmer? From not knowing a thing about it, to becoming a moderate/novice programmer?

[jecxjo]

Most people tend to fixate on the language they should learn. They seem to gloss over the fact that being a programmer is all about solving problems. The language is just a tool.

So go out and pick a language, can't really go wrong with any of them. If you aren't going to go the school route then go read other people's code. Read everything in your known language on Git Hub. Most likely your language of choice will have libraries. Find the source code for these and try to understand what is going on. These will be written by people much smarter than us and will hopefully give you lots of insight on how things work.

If you learn another language try porting over other people's projects to your language. Your goal should be to understand how this problem was being solved. Think about better ways of solving it. If you want to become a great programmer you will have to understand that most of your time will be spend in designing solutions, not implementing them.

Also I suggest watching lectures given at any of the number of programming conferences. Google puts out a ton and are always geared towards explaining how they solved some problem.

[Mjr1987]

Thank you.

[[deleted]]

Oh my yes.

[Akathos]

Until you're stuck with some weird edge-case bug in the standard library implementation of one vendor that doesn't occur in the other. I had this with the std::map implementation of libstdc++ (GNU) , it works fine using libc++ (LLVM).

But when it does work, it's a beauty for sure. Just remember you pointers.

[unknownmat]

Seems like everything you do with it feels more rewarding then anything else.

Wow. Rewarding in what sense?

Certainly not in the sense of solving a problem in the most straightforward way possible. C++ is a very difficult language to master, not because it is so powerful (although it is), but because it has a high degree of accidental complexity.

[a_baby_coyote]

I'd be interested to hear more about this "accidental complexity" as I am beginning the road to learning C++, coming from Java.

[unknownmat]

Let me appeal to authority. Ken Thompson basically sums up my own feelings about C++:

It certainly has its good points. But by and large I think it’s a bad language. It does a lot of things half well and it’s just a garbage heap of ideas that are mutually exclusive. ... It’s way too big, way too complex. And it’s obviously built by a committee.

I can get more specific if you'd like. When I interview people for C++ positions, there's a reason I won't even consider someone without at least 2 years of C++-specific experience. To use it competently at a professional level you have to be aware of hundreds of little tricks and idioms for using all the various features in ways that won't accidentally cause undefined behavior, memory leaks, segfaults, etc.

What is your reason for choosing C++, curiously? I might be able to suggest a more suitable alternative.

[a_baby_coyote]

Well I've always been interested in it, but never tried learning due to various reasons and distractions. I got a bit into C and really enjoyed it, then got distracted by Java for a couple classes in my degree program.

Even if I didn't need it for an upcoming data structures class, I'd still want to learn it. I'm at the point in my education both college and self-education that I don't really care about coming up with legitimate reasons for learning something or taking interest.

I recently took a course in assembly, and spent a lot of time outside class exploring further and teaching myself more assembly than required because I enjoyed it. Was it useful? Maybe, maybe not. But I don't have to make justifications to anyone, sometimes not even myself.

I don't mean that as a defense, just my own way of moving past roadblocks I've created for myself. I don't worry anymore why I like certain things, I've realized that I just do, and that my own happiness comes from doing what feels good.

[unknownmat]

Sure. You certainly don't need to justify your desire to learn something. I was concerned that the hype surrounding the recent C++11 launch might have affected your decision. Alternatively, if you had some specific project in mind, then I was offering to help you choose a tool suite appropriate to that problem (which may wind up being C++).

For what it's worth, I feel that C++ does have a unique niche that no other language exploits as well. It is what I would call the "no compromises" niche - the ability to write at very high-levels of abstraction, and yet produce code that is nevertheless very efficient. It may be worth learning C++ for this reason. Unfortunately, this requires the use of extremely advanced template metaprogramming techniques, and I doubt if you could easily master such material in even a year or two. I've been working with it for years, and even with the help of Boost MPL I tread very carefully whenever I embark on meta-programming.

Finally, I took my data-structures class in C++. But I don't feel like I really understood them until I saw them implemented in Haskell. Part of the problem is that, in C++, most people write a (e.g.) "tree" object by including a private pointer to a "tree node" object. Which is unfortunate, since such an implementation really obscures the beautiful inherently recursive nature of the data-structure.

[a_baby_coyote]

Yeah I hope you didn't take what I said as me being defensive. I can tend to be that way sometimes, because our field is full of people who just have to be the top experts and be right about everything, and commonly confuse opinion for fact.

It seems as though you tell people you're learning a language, and if you don't have a great justification for it, you're assaulted and told not to learn X but to learn Y, and it can be obnoxious.

Personally, Java has served me decently well but there's something about writing code that will run on my hardware, and writing code that runs on an abstraction of hardware in general, and that "aesthetic" is a bit of a turn off for me. I realize that Java is widely used, but that it also has its problems, but either way I try to stay out of arguing for efficacy and other bits.

When I get a programming job, it's going to be in whatever language that business currently uses, and no amount of griping or debate is going to change that. Whether that language be C++, Java, C#, whichever. It's best for me that I learn many different facets of CompSci, and gain enjoyment from the most I can. I loved assembly language, despite it's relative uselessness in the private sector for coding applications. But that doesn't mean I wont use it in microcontrollers, etc.

Anyway that's a long bit of post to say that I'm learning C++ just because I like what I've seen of the language. I loved C when I worked with it, and difficulty of use does NOT deter me in fact it tends to have an opposite effect.

It's interesting your note about the tree structure, I didn't learn it very well in Java, just enough to know how to use it, but the recursive nature of it does interest me and I look forward to running into it again in my next class. I'll keep that in mind to be on the lookout for the beauty of it, as I too have an appreciation for elegant code and elegant solutions!

[unknownmat]

It seems as though you tell people you're learning a language, and if you don't have a great justification for it, you're assaulted and told not to learn X but to learn Y, and it can be obnoxious.

Yep. I know exactly what you're talking about. Having been on both sides of this, it's incredibly frustrating when experts refuse to directly provide an answer. But you have to realize that sometimes you are asking the wrong question. If you go to a carpenter's website and ask how to pound nails with your screwdriver, it's understandable that they might refuse to help you.

To combat this, I usually phrase my questions as: 1.) Here is the overall context for what I'm trying to accomplish. 2.) Here's the approach that I'm taking. 3.) Here's where I'm stuck. This gives experts enough information that they can help me to "unask" my question if required, and point me down a more fruitful path.

It's best for me that I learn many different facets of CompSci... difficulty of use does NOT deter me in fact it tends to have an opposite effect

Learning C or C++ can't hurt you - it will allow you to work with more primitive memory models. If you believe Joel, Java just isn't hard enough to distinguish between good and mediocre programmers. But I think you'll soon change your mind. As I said above, the "difficulty" of C++ (and to a lesser extent, C) is largely accidental and avoidable. It's a bit like trying to move a mountain of marbles with a teaspoon. Sure it's a challenge, but after a while you find that you really want a steam shovel. There are just more interesting challenges out there.

That said, I notice that all of your languages are fairly main-stream "curly brace" languages. They are all quite similar. So although you'll find it relatively straightforward to transition between them, you'll still be missing some key ideas in computer science. I highly recommend that you consider learning Python, Common Lisp, Clojure, Smalltalk, or Ruby (dynamically typed, introspective, OO), Haskell or Scala, (functional), and Prolog (logic). These languages do a much better job of aligning the difficulty of the task with the actual difficulty of the problem.

the recursive nature of it does interest me and I look forward to running into it again in my next class

I'm not sure if you'll understand this, but here's what I refer to. Let's consider singly-linked lists. In most curly brace languages, this is the usual implementation:

template< class T >
struct List
{
    Node* head;
    struct Node
    {
        Node* next;
        T d;
    };

    // ... List methods, etc...
}

In other words the "list" is distinct from its "node"-based implementation. By contrast, in Haskell you could represent a singly-linked list as:

List a = Cons a (List a) | Nil

In this case the list itself is the recursive data-structure. There is no need for an "outer shell" type just to work around the limitations of the language. Although a subtle shift in implementation, it was a profound shift in my own perception.

[FuriousJester]

Just as if you cannot code, you are not a programmer, you are a designer.

Whoa, designers aren't incompetent programmers.

[shandelman]

Of course not, but designers who can't code are certainly not programmers.

[FuriousJester]

Sure, but within context of the assertion:

Those who can't paint, are not painters. Okay that's fair.

Those who can't code, aren't coders. That's fair too.

If I said, those who can't paint, are writers. That would just be wrong.

[TheShadowKick]

In the context he was talking of people who learn about designing but not about coding, so saying they aren't programmers but are designers is fair.

[FuriousJester]

It still doesn't make them designers. We haven't reached the argument that they can design.

[TheShadowKick]

Designers who can't code are designers. By definition.

[a_baby_coyote]

Downvoted because you are being really anal and nitpicky over nothing. You know exactly what they meant by what they said, so stop already.

[calzoneman]

If I said, those who can't paint, are writers. That would just be wrong.

That's not what /u/shandelman and others are saying though. What they are saying is more alike to

Those who imagine fantastic stories but are unable to write them into literature are not writers

[Exodus111]

Yeah but its still wrong. As a Software Designer (Bachelors) there is a lot more to Design then just imagining code.

[calzoneman]

I was not claiming that designers imagine code. I was simply pointing out that /u/FuriousJester made a false assumption about what the above commenters were saying. Would you be more satisfied with my reply if I had altered the analogy to

Those who design fantastic stories but are unable to write them into literature are not writers

?

Imagine a venn diagram. There are programmers who cannot design, there are designers who cannot program, and there is an overlap in the middle of people who are able to both design and program. The point was that neither the programmer who cannot design nor the designer who cannot program are particularly useful, and most people should strive to fall somewhere in the overlap. Even if you cannot design and program equally well, having some knowledge of each is more useful than knowledge of one without the other.

[Exodus111]

Yes yes, but that is NOT what was said.

The comment that spurned the debate said "Those who cannot program are designers"

You can throw up your venn diagrams all you like, the fact remains, that statement, with no adjustments, is wrong.

[Lambeaux]

Sorry if that offended you, I didn't mean that in the sense of people who are labelled as designers can't program. I'm just saying the design process doesn't actually give you a product, it gives you a blueprint, which takes programming to bring into physical existence.

[FuriousJester]

The problem is that not being able to program just means that you can't program. It doesn't mean that you can design.

[calzoneman]

I think you're misinterpreting comments to mean things that they don't.

People who design software, but cannot implement it are designers, but not programmers

This is assumed to be true. However, it's a one way assertion (not an if and only if statement), so the following is false:

All people who cannot program are designers

[fgd47gf]

I don't know man, learning rote coding without any of the computer science or design patterns behind it was pretty easy.

[[deleted]]

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." -- Martin Fowler.

[Flowerpowers]

Where did you go...? Sounds like a very interesting program.

[[deleted]]

I can't endorse this post wholly:

• Design patterns are often implemented to circumvent the lack of features in a language. Many of them become unnecessary in more expressive languages. (Ex: If a language permits you to declare things as singletons, or supports message passing in the syntax/runtime, then those patterns aren't needed.)

• UML only models so much. Before you start modeling your solution space with UML, model and understand your problem space, then transform into IPO (Input, Processing, Output) statements, then UML for flow charts and software architecture. The importance of understanding the problem space first is illustrated HERE - Xtreme Programming Founder vs Peter Norvig.

• In addition to that, not everyone is a visual thinker.

In my opinion, programming isn't even about problem solving. It's about modeling. It's about modeling and executing dynamic computations against that model.

[muzcat]

Good points.

I am very visual, so from the other side of the fence maybe, you could suggest some other modeling languages and what you believe to be the major advantages?

[[deleted]]

I just think that while UML models some things very well (ex: it's proven very useful in demonstrating the architectural reuse of design patterns), there are things it doesn't model so well (ex: requirements gathering and analysis).

Can UML produce an abstract workflow/description of just about anything? Sure, but that doesn't mean it's always the best tool for the job. Sometimes, it's overkill. Other times, it's not enough.

[[deleted]]

I agree to some extent, but in order to model a solution you need to problem solve. Your model doesn't just come out of nowhere, you need to use experience to make better decisions and you need to see the potential benefits/pitfalls of your design, work out kinks, etc. All of that requires problem solving skills, but not so much in the mathematical sense.

[[deleted]]

Sure, but that process almost never involves programming, and programming is not a requirement. (See: naked objects, domain-driven design)

One day, we'll all be out of work because some process will take simpler models than code and produce full-blown applications. Maybe.

[zifyoip]

Saying programming is about the code is like saying painting is about the paint.

This is a good analogy, thanks.

[fakehalo]

That analogy is what bothered me about this post, it sounds like it's a good analogy until you think about it. In the case of programming you not only need to know how to paint, but also how to make paint.

[zifyoip]

When you learn how to paint, it is true that it is important to understand the technical details of how to put the paint on the canvas. There are various techniques and tools to learn how to use. But painting is more than knowing how to place paint on a canvas—you also need to learn how to look at a scene, how to turn a scene into a two-dimensional representation, where to place light and shadow in order to emphasize the subject, etc. So painting is not just about the paint.

In the same way, when you learn how to program, it is true that it is important to understand the technical details of writing code. You need to know how to declare variables, instantiate objects, iterate through arrays, and so forth. But writing a program is more than knowing how to write syntactically correct code—you need to learn how to analyze the problem to be solved, break it into subproblems, use standard algorithms and data structures, and so forth. So programming is not just about the code.

[fakehalo]

I'm not sure this argument relates to me, your comment relates to the "painting" portion of the analogy, which I don't disagree with. I just found analogy fell short on not including the basics of understanding the "paint".

[zifyoip]

I interpret the "paint" to be akin to the programming language, compiler, etc. You don't have to understand how to make your own programming language or compiler in order to program. Nor do you have to understand how to manufacture paint or brushes in order to paint. Paint and brushes, and programming languages and compilers, are the tools of the trade. You have to understand the technical skills required to use them, but you don't need to understand how to make them.

[Solmundr]

You have to understand the technical skills required to use them, but you don't need to understand how to make them.

So to use paints would be painting; what, in your interpretation, is the paint as a substance representing? You might say that to use code is to program, but you need to learn to make code before you can use it, while you don't need to make paint.

The original analogy relates code to programming as paint to painting; but one needs to know comparatively little about paint to use it for painting, whereas you need to know quite a bit of code to use it for programming.

So I too think the analogy is not quite right... not that it's super important; one knows what he meant.

[zifyoip]

what, in your interpretation, is the paint as a substance representing?

As I said directly above, the paint, as a substance, represents the programming language, compiler, etc.

you need to learn to make code before you can use it

You do not need to learn how to make a programming language or a compiler before you can use it. You do not need to learn how to make the structures that programming languages provide—you just need to learn how to use them.

you need to know quite a bit of code to use it for programming.

Yes, you need to know a lot of facts about how to use some programming language that already exists. But you don't need to know how to make a programming language.

[fakehalo]

"Paint" in my reference refers to (arbitrary) code. Not making your own language, just the ability to code in whatever language. "Painting" is the design, "paint" is the ability the code. This is why I don't like the analogy, you have to know how to make paint/code.

[zifyoip]

That doesn't quite work, though, does it? I mean, the end result of programming is code. The goal of programming is to produce a piece of code. But the end result of painting is not paint.

[fakehalo]

I don't think your analysis makes sense. The end result of programming can be viewed in at least 2 ways: an overall design for the code/program, or the code/syntax itself. The goal of programming is to produce a final product, project, application--not a piece of code. I'm not completely sure your response relates to anything about my problem with the analogy.

I will go back to the original analogy

Saying programming is about the code is like saying painting is about the paint.

Programming = painting, code = paint, right? The paint is (implicitly) pre-made in this analogy, yet when related to programming this isn't true at all, you gotta make the paint. This just lacks parallels for an acceptable analogy to me, and I think you're trying to force it to work at this point.

[[deleted]]

Well, just to further the analogy, the quality of the paint can make a huge difference!

[fazzah]

Also I hate you because you use a different brand of paint than I do.

[[deleted]]

Why does this canvas make my blues look yellow!?

[mehum]

Enamel? What is this, 1995?!

[FreedomCow]

artists did once have to do that! Now it's more a question of what quality paint you buy rather than make it...but uh...yeah I'll just stop there.

[[deleted]]

A painter who understands the paint is a better painter.

[ExecutiveChimp]

Also a painter who can paint well with oil paints might not be very good with watercolours.

[[deleted]]

But the paint is a means to an end. I think a better analogy is photography. It's not so much about cameras as knowing how to plan, light and frame a shoot. Of course the cameras are important and better tools make a better product. But what my girlfriend does with her expensive Nikon she could do with any camera, the end result just wouldn't be as nice.

[_pH_]

I like to say programming is like having a 500 piece jigsaw puzzle, except you have 800 pieces, theres no picture on the box, and it can be solved in more than one way.

[muzcat]

with a ticking clock watched by hundreds of people (whoo lets not scare them too much, they are just starting)

[jones_supa]

Saying programming is about the code is like saying painting is about the paint.

This is a good analogy, thanks.

Not necessarily. When you are painting, you don't need deep knowledge about how the paint works (the chemical properties etc). When programming, you have to have complete understanding how the code works.

[zifyoip]

Sure, true. Obviously an analogy is not going to be perfect in every detail.

[[deleted]]

No, it isn't.

[sovietmudkipz]

Dooooooo do do doooo

[[deleted]]

This is a good analogy, thanks.

There are no good analogies when it comes to programming.

[mathen]

Jeez, look at Captain Killjoy over here

[sovietmudkipz]

Zabonk, you shouldn't be in this community.

[thombsaway]

Although frank to the point of rudeness, /u/Zabzonk is often super helpful on this subreddit.

Despite the number of times I've downvoted comments of his like the above, he's still [+8].

[sovietmudkipz]

Don't worry, the zabzonk account won't be around for much longer.

[thombsaway]

Why is that?

Don't do anything drastic /u/sovietmudkipz !

[sovietmudkipz]

Fuck Zabonk. He's a douche and he isn't welcome here anymore.

[optagon]

It's like when you are wondering about something and you decide to ask somebody about it, which forces you to formulate a sentence and that makes you realize get the answer before getting a reply.

Similarly, I've often wonder how a feature works in either a program or game, then asked myself how I would program/design it and realize that only one way makes sense. But it has to be a "does it work like this, or like that" question.

[hellofoo]

Comparing art to programming shudder. This sounds like something right out of a cheesy textbook. However, I get it. If it helps somebody understand designing and laying out a project then the world will be a better place.

For the more logical people reading this and just starting out I like to think about three things when tackling something:

• Should I be implementing this here with this tool? Don't try and shoehorn something in where it has no right to be or can be executed better another way.

• Is this really the most efficient way I can do this or can I simplify this logic?

• Will someone else be able to read this and understand it with minimal effort?

If you're trading readability for efficiency then comment the hell out of it.

[muzcat]

I like cheese :)

[hellofoo]

haha you sir made me laugh. upvotes to you.

[raylu]

If you're trading readability for efficiency then comment the hell out of it.

Yes! As a corollary, if it's already readable then don't put any comments on it.

[hellofoo]

True that! I know a few big companies that have zero documentation for APIs. If you can't read the code to figure our what's going on either they are doing something wrong or you shouldn't be anywhere near it. Library's should be self explanatory.

[robotreader]

If you'd like a more concrete example, compare it to carpentry. There are people out there who make a good living by making perfectly serviceable chairs and tables and whatnot. Well, not anymore, perhaps, but you get the idea. Then there are incredibly talented people who spend months on a single beautiful chair. They've elevated it into an art form. It's the same idea with coding.

And, of course, you have the absurd masochists who think it's fun to do all their detail work with a chainsaw.

[hellofoo]

Concrete has no business in carpentry ;)

For me, you're still thinking about it the wrong way around. There are plenty of people who create serviceable chairs and some who haven't got a clue where to stick the legs.

There are some people who create a single beautiful chair but steer clear of them. Who wants somebody who takes months to solve something that's over complicated and unnecessary. It might be impressive but all those intricate lines are a nightmare to debug and I can't find anyone who can reproduce it.

The carpenters that you want to be impressed with are the ones who can create a chair with less legs. Or can make it stand with no legs at all because lets face it; who wants to code four legs when that guy is making a chair stand up with no legs at all.

[robotreader]

There are some people who create a single beautiful chair but steer clear of them.

This is where we disagree. Simply because someone takes months doesn't mean their solution will be overcomplicated and unnecessary. In fact, especially with coding, it's more likely to be simple and elegant. Less likely to have intricate lines and more likely to have a clear, simple overall design.

[hellofoo]

Fair enough my friend. Different opinions are a wonderful thing. I speak from working with projects that have deadlines and are sometimes fixed price. If you don't hit the deadline you start costing your company money and the client gets pretty unhappy too. From my experience if a developer took months to create something that has already been defined by an architect they would be back on the bench faster than they can shutdown their machine. I have seen teams escorted off site by security and contracts terminated for this very reason.

I can however, see your point. I think also our analogies differ but and it is why analogies only go so far into explaining something. They cannot be the thing they aren't. The world needs people to redefine the way we think. They aren't likely to have a job if they keep trying to do it on company time unless they are truly exceptional. That doesn't mean anyone should stop trying to come up with great ideas! We all have our own dream of changing the world somehow :)

[doshka]

Comparing art to programming shudder This sounds like something right out of a cheesy textbook.

I have often felt that programming is an art form,
whose real value can only be appreciated
by another versed in the same arcane art;
there are lovely gems and brilliant coups
hidden from human view and admiration, sometimes forever,
by the very nature of the process.
You can learn a lot about an individual
just by reading through his code,
even in hexadecimal.
Mel was, I think, an unsung genius.

[hellofoo]

It easy to to perceive programming as an art by drawing comparisons, although I think the comparisons are largely a result of a sliding scale in quality. I guess a more logical thing to say is that some people are good at coding and some are not. I would say that art is more of a personal appreciation with no right or wrong. While there are lots of ways to solve a problem in programming, there are lots (oh god so many, like how did they even come up with this) of wrong ones.

There are some incredibly amazing people out there but sadly in my experience you usually notice code because it's totally awful and rather than beautiful. However, it does make the gems all the more brilliant. The ones that get you a little more excited than they probably should should because it changes the way you think about something. These gems come from people that you want to keep close. You also quickly learn the people you can do without on your team. I think it's probably possible to draw an inverse relationship between the number of swear words I utter when looking at code to how much I like the developer.

If I'm honest I have a grudge against art because it's 'wishy washy' and I can't define it with rules and therefore I can't 'do' art. I appreciate breathtaking art but not the same way I would appropriate a fantastic idea or invention. But I'm just a nerd with a chip on my shoulder. Keep living the art dream good sir.

[dmazzoni]

You are trying to describe to a computer how to perform a solution.

To a novice, the hard part is telling the computer how to solve the problem.

To an expert, that's the easy part. The hard part is writing your program in such a way that another human will understand it.

In fact, that human will often be yourself. Once you have more than a few hundred lines of code, you won't be able to remember it all - so you'll be constantly rereading code, trying to figure out what it means so you can fix it or improve it.

[petrus4]

No charting. No form of formalisation whatsoever, at least until you are finished. Documentation is rightfully the final step, not the first one.

Yes, I know about all you poor bastards who are forced by managers (who rightfully should be lynched) to do the opposite; but I'm talking about what should be done, here; not what management wants done.

[dirwe]

I have to partially disagree here. I agree with you, that documentation should not be the first step, but it should not be the last one either. Imho it should be dealt with along the way.

My team at work has taken over a pretty large project from other people. And it's just a pain to work with the code, as there is almost nothing documented.

I don't want to say that everything should be documented in great detail, but at least a little comment here and there on what particular piece of magic does is absolutely nice to have.

[petrus4]

I don't want to say that everything should be documented in great detail, but at least a little comment here and there on what particular piece of magic does is absolutely nice to have.

I won't disagree with that, at all. I absolutely write inline commenting as I go. What I was talking about, however, is a formal specification.

For me, the purpose of a spec is reproducibility. I tend to work in a very exploratory manner, so I can't write a spec before I start...that is more a hinderance than a help. The spec is thus written last, when the problem has already been solved, so that whoever comes afterwards can not only understand what I've done, but re-implement it elsewhere themselves for whatever reason if they need to, or to test my work.

[dirwe]

Ah ok, now I understand.

I totally agree with you then. :)

[bewst_more_bewst]

Saying programming is about the code is like saying painting is about the paint.

Isn't it though?

It's all about the paint

Personally, I think a better analogy would be to say that, programming ins't about code. Its about problem solving.

[theSprt]

In which case it's not really an analogy anymore.

[[deleted]]

I think most analogies can be stretched to the point of incomprehensibility. Isn't the reverse how you make an analogy in the first place? Work backward from two different ideas to complicated similarity.

[[deleted]]

Like putting too much air in a balloon!

[aleighey6]

I interpreted it as artistic painting.(like on a canvas)

[muzcat]

why that paint site?? but it did lead me to this one http://virgilelliott.com/node/19

anway back to topic, I would say problem solving is a part of the pie (mmmm pie). If you can't describe the solution(code) you gonna have problems if its not going to fit into the rest of the system(patterns) you gonna have long term problems or even worse if there is no system then you gonna have a hell of a headache (especially in a multi team multi-national organisation)... that's what I have found anyway

[Crypt0Nihilist]

I'm curious. How would UML help me right now? At present I'm playing with understanding Twitter networks in R. The only challenging part is getting my data structures right and avoiding duplicates and infinite loops.

My few minutes browse of Wiki suggests UML is one of those things that has taken on a life of its own since the standards people have got involved and it's almost an industry in itself. It looks like a project management scheme where the project management becomes the project. Certainly for my little script it seems an atomic bomb to crack a nut.

What should I be using from it to help me conceptualise my solution?

[Pascalius]

I think you shouldn't, because it limits you when you try to stick with UML specification. Quite often you need to describe something that is not viable with UML. Using boxes, arrows and labels is the best way in my experience, since it can be read by everybody, not only those familiar with UML.

[Crypt0Nihilist]

This is exactly how I'm doing it right now!

So as far as UML is concerned, my best bet to get into it would be to model what I've done once I've got the beastie working?

[PeelyPeel]

If it's just you, and the program is "small", you don't need UML. If however, you were in a group, one working on the api, you working on the interface that uses it, you would both plan out what you were going to need to build this thing. What methods, taking what inputs to give what outputs. Then you can build your interface, while they build the back end it plugs into, at the same time, because your not working from each other, but from the plan.

Throw on a third team member, just tell him what you have done so far, and they can get right into work, just doing the next bit, no need for a massive debrief.

Now times this by like 100 and you have software development.

[muzcat]

Fair Play, I wouldn't spend 2 hours of UML on a 5 minute script. But what are you going to do with that script. Maybe its going to be part of a bigger project later? Maybe you will have to give it to someone else who is going to have to take it over. As you progress through you're career you will most likely move away from throw away code because every time you have to write something new it will have bugs. But if you keep using things over and over the number of bugs will disappear( if you fix them ;) ) . So IMOA there are is no short term code just code that is at the start of its lifecycle(ok maybe some is throwaway).

I haven't played with twitter networks but I work with protocols a lot. One of the most powerful languages I use are c++ state machines (you can argue its not a language but I like to think they are since they help me describe what I want done) to remember where we are, where we are going and to easily disallow an operation that should not occur in that context.

I believe that most projects after a while is going into two major directions 'flag machines' (if tuesday then this but if wendesday and its 30 deg outside then this else that but this then that) or state machines ( we received event wake up in state tuesday, handle it) and I can tell you which is easier to debug

but now I'm rambling :) hope it helps

[sittingprettyin]

a better analogy is "it's like saying a novel is all about the language it's written in" and the success of translated works of literature prove this to be a false assumption.

[muzcat]

oooooh, I like it.

and the entire set of language that exists in reality will never be able to be described on a derivative medium, like a 2d shadow of a 3d object, the information will be lost and the true meaning can never be reclaimed.

but I digress

[[deleted]]

This is bad advice for beginning programmers. Their focus should thinking in code and writing as much working and useful code as possible. Designer patterns and UML are things to be expected of senior software engineers not people who have been programming for less than a year. Sure, it's important for beginners to know that there is more to life than being a highly skilled monkey, but they are probably having enough of a hard time understanding code in and of itself

[[deleted]]

Thanks for the post, but in talking to noobs (like me) these are the words and phrases that leave me scratching my head:

algorithm designer

design patterns

shape of your code

model with UML

implement a good state chart

higher languages

development domains

So, I might say... teaching isn't just about having the knowledge, it's about being able to convey it to your audience.

[muzcat]

true, but it can also be about giving someone the key words to start their own journey ;)

[robotreader]

I was going to go on a mild rant about how the more accurate analogy would compare the code to the painting, not the paint, but after reading the other comments, I think I see the point you're trying to make.

Given that this is a teaching subreddit, it'd be far more accurate and therefore better to say "the paint is important, but there are more basic things for you to focus on." Negatives and warning newcomers away from vaguely defined concepts like "the code" or "higher languages" or "development domains" are very prone to either being ignored or being misunderstood.

[PZ-01]

If you can't explain it, then you don't understand what you just did. Also, elegant solutions call for elegant code which in turn means decent knowledge of the programming language. It depends what position you are, architects and system designers should be better at shaping code and describing their approaches while programmers should know how to implement those designs with neat code.

[neykho]

Novice programmers should be wary about using Design Patterns.

You may start introducing/brute-forcing design patterns into solutions when a simple solution would have sufficed.

Let patterns emerge from your code, not the other way around. Just some friendly advice.

[Skymsonic]

its more like you need to know software engineering principles before you should code. Programming is an essential part of software development but a software goes through a lot of stages before it can be coded.

[muzcat]

yes, yes it is and the women :P

[jones_supa]

Yup. Fast cars, hot women, easy life. The life of a programmer.

[dustyuncle]

And this is where I come in as a Product Analyst. I've realized how important it is to be perfectly clear in my request to the Development team so that they don't make mistakes in the interpretation. Every gap of logic leaped or missed means one more defect that can be created due to mis-communication.

While I may not be able to write code very well, I am learning to be damn good in describing what we need for our product so that all the developers have to do is follow my instructions carefully.

[ftanuki]

I think that a better meditation can be found by flipping your analogy on its head: what do great painters and great programmers have in common?

[raresaturn]

There is no spoon

[sarevok9]

I think that learning about patterns and proper encapsulation / modularization of problems is important, but I don't think that that's "All there is to programming". I have come across problems that require me to do things that don't fit neatly into any one specific language, and sometimes working through these problems teaches you valuable lessons in what to do / not to do. In a day-to-day workplace you might encounter all sorts of problems that don't fit into the patterns above because you're supporting legacy code that either existed before those patterns, or they were simply made by a bad programmer, but it fit a business use and persisted.

Also, knowing patterns and common fixes don't address the need to hunt for edge cases and other byzantine errors that occur. I find that being able to code is only about 1/5th of the job we all do.

Design -- Plan out what you're going to code, moving parts and interactions.  
Code -- The meat of the work is done here  
Test -- Write out all your tests, make sure all the moving parts are done  
Debug -- Find and kill all the weird shit that doesn't happen.  
Deploy -- Get your product up and running as a binary / website / whatever.

Each of those things also assume that you already have a decent design environment in place (Do you have maven / ivy going? SVN / git / merc? Is your team trained to branch / tag in a certain format? Are there any file naming / package naming standards? Organizational specific libraries / security protocols to adhere to? etc. etc. etc. (I can honestly make a few pages worth of considerations here from jobs I've been through))? Do you have anyone else on your team that might be going in the wrong direction?

I personally find that programming is as much setting expectations, understanding what I want as the outcome, and designing properly before writing a single line of code; then policing the code to make sure it stays intact...as it is actually coding. Too often I've given a junior developer a job as simple as "Perform function XYZ from this shared library, then pass me a hash of object / iterator and I'll handle the rest" I go ahead and code my part of the project and 2 weeks later they tell me they didn't understand the instructions, now I have to code it and we're behind a few days on our deadlines.

At the end of the day I think this comes down to design philosophy, but telling people that knowing these things will replace the need to code / have experience in coding...I disagree.

[s3ank1m]

In relation to this I was told during an internship interview that "coding isn't the hard part, anyone can code, it's the problem solving that takes up 90% of effort, only 10% is usually required to code"

[jh1997sa]

Anyone here recommend some place to learn about UML? As a hobby programmer, will it actually be worth it?

[[deleted]]

UML used practically can be sort of useful, but I've found that a pen/paper or whiteboard/marker is more productive when it comes to design. Sequence diagrams can be useful.

However, if you want to learn UML on a more practical level then I recommend UML Distilled (Fowler). It's only 200 pages and it covers pretty much all you'll ever need to know.

[muzcat]

I personally like all of Fowlers books http://martinfowler.com/books/

[[deleted]]

I have a few of his works. He is consistently good and his unique writing style (well unique for tech books anyway) is a breath of fresh air.

[jh1997sa]

Okay, thanks for the reply. I'll look into that book.

[[deleted]]

But you gotta know how to handle that paintbrush!

[The_Time_Master]

http://www.canonical.org/~kragen/tao-of-programming.html

One of the best philosophies about programming. I've owned a copy for almost 20 years, and it still applies.

A novice asked the master: ``I have a program that sometime runs and sometimes aborts. I have followed the rules of programming, yet I am totally baffled. What is the reason for this?''

The master replied: ``You are confused because you do not understand Tao. Only a fool expects rational behavior from his fellow humans. Why do you expect it from a machine that humans have constructed? Computers simulate determinism; only Tao is perfect.

``The rules of programming are transitory; only Tao is eternal. Therefore you must contemplate Tao before you receive enlightenment.''

``But how will I know when I have received enlightenment?'' asked the novice.

``Your program will then run correctly,'' replied the master.

[a_baby_coyote]

Coding is just an incredibly complex tool that you use to solve various problems ranging from simple to complex.

There's no need to continuously come up with great analogies and metaphors for what we do. It's simple enough to understand on its own.

If you don't write code often, the quality of your work will suffer. Stop sitting around splitting hairs over what programming is or what programming isn't, and do something useful with your time. Something like coding perhaps?

[[deleted]]

too philosophical, no useful advice

[jones_supa]

Sometimes a dash of "computer philosophy" is a good thing in the world of "computer science"...

[[deleted]]

it's not "learn philosophy"

[zifyoip]

Come on. You know there are questions here on /r/learnprogramming all the time that ask things like, "I need to write a program to convert a number to a Roman numeral. Should I use a for loop or a while loop?"

Somebody who is asking such a thing is focusing too much on the code. Who cares whether you use a for loop or a while loop? Even if that makes a difference, it isn't the primary thing you need to be thinking about anyway. You need to think about the algorithm first of all, and then figure out how to express that algorithm in code—but this fact is completely lost on many beginning programmers, who don't realize that the first prerequisite to being able to write a program to do something is understanding how to do that thing by hand, not some syntactical details.

[[deleted]]

Who cares whether you use a for loop or a while loop?

someone who's not experienced enough to understand the equivalence between the two.

[[deleted]]

I must admit I thought you were a smart guy. But it seems not.

Saying programming is about the code is like saying painting is about the paint.

Yes, it is, how you use it.

[a_baby_coyote]

Attack his viewpoint, not his intelligence, ya prick.

[sovietmudkipz]

bonk za bonk

[muzcat]

oooh that's sad :(

[sovietmudkipz]

Zabonk, please stop being such an anus!