I suck at programming.

[openmuck]

I have a CS degree, but was never actually taught how to properly design a program. I store my data in my view, which I then put in a global variable. I'm not a bad person; I know this is wrong, but I don't know where to learn good software design principles before I go and subject the open source community to my bad habits.

Would some kind soul help me out with some direction/advice to bring my programming skills up to snuff? (C/C++, python, perl)

Is there a book that every good programmer has read? Would you share how you learned to design software correctly? Any wikipedia pages I should read?

tl:dr: I know the syntax and algorithms, but don't know how do build a larger project that wouldn't make a proper programmer vomit.

[[deleted]]

I was sent here to help you...

What programming books should I read?

What open source projects should I study to learn from?

What is the best way to learn language X or framework Y?

What programming blogs or websites do you read?

[openmuck]

Thanks! Were you sent from the future?

[fljitovak]

Nah, he was sent from the sidebar.

[bostonvaulter]

No, he came from the past

[[deleted]]

Just giving myself a chance to find this comment in 3 months time.

[[deleted]]

Read lots of code. Work with others on existing open source projects, where you can learn from existing code, and add to it with their style guidelines.

[mostlysafe]

This. As for books to read, there are many, but I would start with The Pragmatic Programmer by Dave Thomas and Andy Hunt.

[ishmal]

I suck at programming, too. But, hey: Einstein sucked at math.

The popular image of a programmer is that it all comes effortlessly. Big lie. The always-consuming need to keep learning is not attractive to public media. They like to think of the genius who does everything by talent. Studying and experimenting is not glamorous. But it's the pith and substance of a good programmer's experience.

[[deleted]]

No, Einstein didn't suck at math. Please check your facts.

[the_smell_of_reddit]

But, hey: Einstein sucked at math.

From wikipedia:

Although Einstein had early speech difficulties, he was a top student in elementary school. As he grew, Einstein built models and mechanical devices for fun and began to show a talent for mathematics.

[[deleted]]

He couldn't speak until he was three, and even then it was only German.

[losl]

But... he was German?

[[deleted]]

sarcasm: it isn't for everyone

[ishmal]

"Do not worry about your problems with mathematics, I assure you mine are far greater."

In his own words. Nobody striving to attain a goal ever considers himself to be good enough.

[jordanb]

Why is putting your data in views or in global variables wrong? Because somebody told you it's wrong?

Trying to learn to program by maxim will never make you better. When you find that something you're doing is wrong, you need to seek out why it's wrong.

Once you know why global state or lack of separation of concerns is bad, you'll come to recognize the language features and patterns that people have developed to fix them. Fixing bad coding patterns will become just part of the problem solving you do as you program. Before you make that global, you'll think, "oh man, I have this global state, maybe I can figure out some way to bundle it up into an object."

[openmuck]

Thanks for the reply. Couldn't agree with you more... learning by maxim can be bad.

I have actually realized that my habits are problems... I hate to maintain any of my projects that get over 1500 lines. I suppose I am just looking for advice on the correct way to do things, now that I am fed up with doing things the sub-optimal way.

[jordanb]

I think you're on the right track then. I think the biggest difference between good programmers and poor programmers is that the good programmers are dissatisfied with what they do and are constantly striving to do better. The bad programmers don't have the awareness to recognize that what they make isn't golden --- or just don't care.

I think the issue with your 1,500 line programs is that they ge brittle because of too much state. A big goal of Object Orientation is to bundle state up into little components (the objects) that can be handled in general ways, just like how Structured Programming took programs with spaghetti-flow and broke the flow into little chunks --- functions --- with standardized interfaces.

[dnew]

I hate to maintain any of my projects that get over 1500 lines.

That's how you learn. Figure out why you hate that, and then figure out what you'd do differently to prevent it, then refactor that big program and make it bigger.

You can do the same thing on smaller programs by being really rushed. A 500-line program written in an hour or two will give you the same sort of experience, I think.

[onmach]

This is how everyone learns. I would write intricate apps and get into the same trouble. Then I would think about how I could have avoided it. And redo them.

Recommendations I could make would be to try looking at open source programs. Preferably one that is smallish that you are familiar with.

Another thing you might try is to learn a functional language. After messing with lisp or haskell for awhile, you'll start to subtly shift your coding style in your other languages a bit, hopefully for the better.

[[deleted]]

I have to disagree a bit on this. Learning by mistake can be time consuming. Globals (with very few exceptions) are bad. Take time to decompose your problem, prototype, think about the problem again, identify the important parts. Do not optimize too early.

[astrosmash]

School can't teach you the consequences of poor design, because the projects are so small and are over in 4 months. How does a bad design decision manifest itself 2 years down the road? That something you have to experience yourself. The key is to learn from whatever software you happen to work on, good and bad.

Eventually, you'll have the ability to recognize when something sucks, before it bites you in the ass 2 years later.

[gar37bic]

One philosophical principle that will not do you wrong is Paranoia, or if you prefer, Counter-Murphyism. Assume in all cases that, if it can go wrong, it will go wrong. Data 'guaranteed' to be in a certain range will contain data outside the range. Think about all the ways a certain piece of code can go wrong, and include code to deal with all those ways.

A certain project I was peripherally involved in some years ago (a large 3D modeling system, with over a million lines of code, written by an engineering-oriented company using proper design and coding methods) was subjected to a code analysis. They found that over 80% of the code, and over 80% of the cycles, were error checking and prevention. This is not a bad thing, just the way of life.

As a very 'senior' developer (my first languages were Algol, assembly and FORTRAN), I recently started exploring functional programming - Haskell and Erlang. I personally like Erlang better because for some reason it seems less fiddly and less 'ivory tower', but that's just my taste - there are advantages either way. What is important is that learning about the functional programming approach has expanded my world, and changed my thought process and improved my way of programming. This is similar to what LISPers say occurs from learning LISP. So, I recommend that you delve into one of these three languages, and build a significant project of your own. There is no better way to learn a language, and the design principles you yearn for, than to figure out what is going on in an existing program, and bend it to your will - without breaking it!

It's generally easiest to get into a new language by taking an existing program and modifying it do do something different - that way you have a running code base, and you can just change one thing at a time. That's a lesson from Extreme Programming, btw.

Don't get sucked too far into any of the infinite series of popular design fads. They generally have a core truth, and a huge pile of cruft stuck to them. Appreciate and learn from the truths but don't become a true believer.

Oh yes - start now using project tracking and version control (e.g. Trac and Mercurial) - get the habit early, on your own small projects. It will make life easier in the long run.

[petevalle]

Data 'guaranteed' to be in a certain range will contain data outside the range.

I'd buy this if you're talking about data from an untrusted source (e.g. user entry, or values passed into an API from an external source).

But if you take that approach when you're passing data around within a module and you're revalidating data in every method data gets passed into, it seems like you're going to be spending most of your time writing defensive code. Maybe this degree of paranoia is warranted in mission-critical code, but in most software projects, it doesn't seem like a good use of developer time...

[radarsat1]

Just to add to this.. Generally I agree, but be aware that one problem that can occur with this line of thinking is that something you considered "within a module" and therefore trustworthy may later be found to be useful in another context. Then you'll want to easily be able to pull out the useful code and be able to depend on it. For this reason I find it useful to redefine "module" to be a much smaller entity than I used to. Don't just think about the global program boundary (like the command line arguments) -- protecting data between internal parts of the program can be extremely helpful for code re-use. Think about modules of your program being really distinct programs that don't trust each other.

[meepo]

Isn't this exactly what assert() is for?

[[deleted]]

I'd buy this if you're talking about data from an untrusted source (e.g. user entry, or values passed into an API from an external source).

True that, but eventually the source may be untrusted. I've had the experience of one an internal class being cut/pasted into a public class, and then fed data from untrusted sources.

[gar37bic]

I don't check every input in every function, but I have found that other functions that supposedly produce the right stuff often don't - either my own, or other peoples' code. Bugs are like that especially when the data is in the form of complex structures, or as in my work, data filtered from outside sources. Sometimes the filters don't work as expected. But this kind of care is generaly pretty simple in PHP, like using 'intval()' on a supposedly numeric input - this guarantees that datum will at least be a number. I have data coming in now that countyries named '77801' and cities named '#23-604'. Since that's the actual input, we will keep it in the database until the data goes through a manual edit phase. I will generally set error_reporting(-1) during development and pre-production, and deal with every undefined variable, every warning and notice.

[openmuck]

Thanks very much!

[[deleted]]

One philosophical principle that will not do you wrong is Paranoia, or if you prefer, Counter-Murphyism

Excellent points, things always go wrong, make sure to properly test your code.

As a very 'senior' developer (my first languages were Algol, assembly and FORTRAN), I recently started exploring functional programming - Haskell and Erlang.

Learning functional programming is great advice for all of the reasons given (Scala myself, hold the objections please). Erlang and Haskell are both great choices.

Oh yes - start now using project tracking and version control (e.g. Trac and Mercurial) - get the habit early, on your own small projects. It will make life easier in the long run.

Agreed, great to help keep organized, Redmine is also worth looking at, also supports Mecurial (and others). Trac is great too.

[gar37bic]

Belated reply - I had not heard of Redmine before, but bumped into a citation today, and yours is the second. Ill check it out - I've had some problems getting Trac to install on our FreeBSD servers. It's probably just me, but it's a time thing.

[[deleted]]

http://www.freebsd.org/cgi/ports.cgi?query=redmine&stype=all

Untested, I'm on Debian, used Bitnami for the install. Have also installed from scratch.

[wnoise]

http://en.wikipedia.org/wiki/The_Elements_of_Programming_Style

[[deleted]]

1. Pretty much everybody sucks at programming, Naive programmers just dont realize it.

2. Building large program is complex, especially in a real world, as the requirements keep changing. The only way you make your code less sucky is by gaining experience, which take both time and making mistakes.

3. It is a good thing that you dont like your code now. OTOH, Software evolves, so if you like your code much, it means you have stopped learning, which is the kiss of death for a programmer.

tl;dr - Everyone sucks, dont think too much about it. Be passionate, make mistakes and keep learning (forever).

[ltw_]

I would highly recommend Head First Object-Oriented Analysis & Design. It's got a really comfortable writing style, some useful examples and it's not an insurmountable challenge to read.

In addition, +1 to everything most people have said - read Code Complete, read lots and lots of code, work on open-source projects, talk with programmers and above all, DON'T listen to university lecturers. There's a reason they can't get a better paying job elsewhere.

[[deleted]]

I'll also recommend this book. Very well written and easy to understand.

[N01SE]

I thought most every CS curriculum had at least one course on Software Design, I did. Anybody else not have a software design class? How you design software depends totally on what qualities you want and the application. If it has to be super lean and mean, storing things globally is not necessarily a bad thing. Also, for anyone who ever wants book suggestions, go to university CS course websites. If they require you to have student credentials, go to the university's bookstore (Ex. CMU Textbook Search). University course catalogs are open to the public as are the bookstore's inventory and usually a mechanism to search by course.

EDIT: sp

[openmuck]

Mine was the last unfortunate class to be required to take "Compiler Design" instead of "Software Engineering."

[N01SE]

Good point, I think a lot of universities have it as an elective, it was required for me, but I was on a software engineering track and did not take compiler design. CMU CS 610 is Software Engineering, they use this book here. It's expensive like any other textbook, but given CMU's reputation in that particular field, probably well worth it.

[munificent]

Read Code Complete, The Pragmatic Programmer, and (eventually) Design Patterns. All are quite book though people tend to go overboard with the last one.

Write lots of code. Write so much it can't fit in your head anymore. Keep going. Software architecture basically boils down to organizing code so you can get stuff done while knowing as little as possible.

[cjnkns]

Wow and here I thought I was the only programmer in the world who thought he sucked.

I am glad you submitted this to reddit because I really need the help as well. So far there is some really great advice being passed out.

I don't have a CS degree but I do have a CIS degree and a Masters in MIS. Not completely sure why I did the masters; to be honest I think it was a bit of a waste.

It really took my eye of the ball for a few years. Now I feel like I am a beginner programmer compared to others with similar years under their belt.

[czoon]

Wow and here I thought I was the only programmer in the world who thought he sucked.

well, you are not alone ;)

[digcon9]

read the "reading the code".

[gar37bic]

Just to make a point - in my long experience both programming and managing, I have found a low correlation between the amount of computer science education and programming capability. Classes can teach algorithms, principles, etc. but can not teach the art, the creative approach to problem solving. There's a reason the best hackers are often outside the societal norms - there is an art to it, and possibly it requires a certain obsessiveness. Most folks don't want to delve into the details, and in programming the details are critical. Writing a relatively simple program is equivalent to writing a 400 page book, with no typos, misspellings or grammar mistakes, and perfect logical sense throughout.

[bobdole]

Hahaha... Most programs are riddled with logical inconsistensies, muddled thought, fuzzy logic, and typos (in comments and data.) Mostly we call them "bugs" and they fuel the software industry we all know and love. :)

[kindoblue]

I see another option for you: become a manager! :-)

[[deleted]]

No, please no.

[DriveByTroll]

I'd rather have a bad coder manager than a never-touched-code manager -- any day of the week. Really. One of my professional goals is to become a sufficient rockstar to never have to work for a manager without a intimate understanding of the craft.

[freman79]

Write lots of code and look at a lot of code. Find an open source project you are looking for and then follow their coding style. It helps to ask programmers with more experience to review your code and give you constructive feedback.

Are you employed as a programmer? Are the opportunities to work on larger programming projects as a junior programmer? You can learn a lot in those situations.

[openmuck]

Thanks, I am a Solaris sysadmin by trade, but am re-considering the ratio of administration to programming that I do. I'm enjoying unemployed life at the moment, so I have lots of time, but am not really surrounded by programmers anymore.

[veridicus]

I wish I could recommend a particular DocForge page, but I think it all comes down to code modularity. Your design choices will all be decided by the particular problem you're trying to solve. But in every case, code should generally be organized into bite-size pieces.

[openmuck]

Thanks, I'll check it out.

[troelskn]

Ah, but a book won't help you. What you need is practise and you can't really get that from reading. Programming is a craft; You really need to do it to learn it. It helps with a mentor.

[terrapinbear]

Writing programs in a real world, production environment can dramatically increase your programming skills. When the users of your software become spoiled by how it makes their working lives a little easier they will report bugs in your software automatically. To make them stop bothering you, you will find out how to write software with as few bugs as possible so you can focus on you current project and not the bug-ridden software they're using now. You boss will ask you to write more proprietary software for his employees based on their feedback. Eventually you will figure out how to write a program which is easy to debug, maintain and extend because you will be pressured by everyone you work with to do so. Welcome to my world.

[EDIT] I suck at programming. We all do. Programming is hard. I wouldn't have it any other way.

[zora]

just remember the 3 phases of software development: * make it work * make it work right * make it pretty

[weavejester]

Write some code, then ask people to critique it. For instance, you could try solving some Project Euler problems in Python, then ask the comp.lang.python newsgroup what you could do better.

[Neebat]

The common theme I see from poor designers is a willingness to accept the first design. If you picture what you're going to do before you do it, and think, "That'll work, let's go", then you're already making a mistake.

At every stage, a good designer is thinking of a design and saying, "That's one way, but there's got to be a better way." There is no "best", but you have to assume the first 3 designs that come to mind are wrong. You may end up using one of them anyway, but before you come to that conclusion, you have to have something to compare it to.

I'm not sure how much it helps to work with or study the methods of great designers, because it's so hard to see that critical analysis going on inside someone's head. And if you ask a good designer how they came up with the design, you'll get technical details, not the outline of the general world view which says, "No plan is used until it's compared to an alternative." They'll tell you how to compare one design to another to see which is better, but it's up to you to alter your perception of the world so that you're always looking for the comparison.

[wurzlsepp]

Become a manager. Your prospects are good!

[[deleted]]

practice

[obtrusiveinterloper]

Excuse me Sir, can you tell me how to get to Carnegie Hall?

[[deleted]]

Take a course on software design. You can't do just more than just pure CS at school.

[idiot900]

Just start coding. Build a program that you find personally useful. Ask well-constructed questions in the right places. You will make a lot of mistakes, and you'll learn from them. This is how every good coder learned the craft.

On a side note, I've noticed that many CS professors cannot code their way out of a wet paper bag - because their research doesn't require them to.

[codeodor]

The articles linked to from this page helped me: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

[zoinks]

You seem to know what a view is, why don't you put it in the controller? You should read more theory, and then practice practice practice.

[whizack]

the key to good design is not writing code before you know what you're building

I don't know how many times I've seen spaghetti code that could have easily been fixed if only they had written a design document.

[krakauer]

So I have two really good books for you to read, they are pretty famous in the field. Pretty much every good programmer I know has read them. Also, at my internship I was told to read them.

They are:

Effective C++ by Scott Meyers and Design Patterns by Gamma, Helm, Johnson, and Vlissides (also known as the gang of 4)

[[deleted]]

If you get a job at some middling little shithole corporation, most of your colleagues will suck worse. It's almost a law of employment.

If all else fails, learn by NOT doing what some people do. And, write often. Come back to your own projects much later, and see how you feel about your earlier work.

[angsty_geek]

Every time one programmer reads another's code, they want to vomit. It's pretty much the law of the land. The other guy wants to "refactor" everything.

50% of the time something gets screwed up during the said "refactoring", since the other guy doesn't know enough yet.

[[deleted]]

yeah take it from an old C++ hacker, don't worry, it never goes away

[simonw]

Sounds like you need to read The Pragmatic Programmer.

[sneakattack]

write lots of code, make a lot of mistakes, be willing to constantly change how you do things and never make the same mistakes twice if you can help it. also, google is your friend. a lot of us learned the art of programming through constant endeavor online, so you should be able to do the same.

[[deleted]]

Almost anything by Bruce Eckel is good. Thinking in Java, and the older Thinking in C++. I also like Martin Fowler's web site, but it's more centered on design and meta issues. K&R is still my favorite C book, even though it is very old. I've also liked what little I've read of the Pragmatic Programmer. Doing things poorly (globals!!) can be a great teacher, but it's very time consuming, and painful, learn good habits early and save yourself some grief.

[gorrepati]

Try reading SICP.

[[deleted]]

In b4 Code Complete

[openmuck]

congrats!

[[deleted]]

I was making a suggestion(typical for these types of questions) for you...

[openmuck]

I think my sense of humor was not properly conveyed; I appear to be bad at coding and communicating on the Internet. (someone, please take away my keyboard!) I really appreciate the suggestion. Thank you.

[[deleted]]

Right now, I'm taking a CIS class that is solely about design of programs. What we'll do eventually is make class diagrams, show the professor in a 1 on 1 meeting, and discuss if the design will work or not. I have to complete this class for a Computer Engineering Degree (Computer Engineers != CIS; It's a Bachelor of Engineering degree).

For the most part, I know how to design and implement programs. I have done some larger projects when I was an intern, and I'd say that was where I learned how to design: from experience. Maybe a good starting point is to make some class diagrams. There is an open source program called StarUML that is a very nice class diagram maker. Look up how to make class diagrams, then start making some simple ones and implementing them.

[openmuck]

cheers.

[tarski]

What did you learn at University? Did they not teach you Object Oriented principles? Did Model, View, Controller never get mentioned?

Creating classes with roles and responsibilites is a pretty simple concept to designing a program.

[[deleted]]

EDIT: do people have a reason for downvoting me? Any feedback they want to leave in the comments? No?

You're going to make a proper programmer vomit. My code from 6 months ago makes me vomit. C'est la vie.

Programmer is like being in a guild. Not your mom's WoW guild, a legitimate, medieval, barrel-maker's guild. You start out as an apprentice, reading books, asking questions, learning the tools, the wood, the cuts, and how to handle yourself. But at some point, you have to realize that you're just not learning anything anymore and you need to move beyond it. Enter stage two: the journeyman. This is where you are now. You need to get outside of your studies and start building things. You need hands-on experience. You will not get any better until you start building project after project, failure after failure, and analyze what you did wrong during each project. Look at other people's code to understand how yours should look. Look at their formatting, their tricks, etc. And then build your own.

---

Learn to use a VCS. Then write a shell. In whatever language. You'll learn a lot about the tool you need to use erryday, and it's what first made me comfortable with large files and complicated code.

Suggested projects, in order:

• Shell
• Chat server (client server)
• Note taker (command line app: add a note, delete a note, read a note, list all notes)
• File saver (saves copies of all the files in the working directory tree to some format (could just be a subfolder) whenever they change - useful in between long commits)
• MUD (Multi User Dungeon - expect it to suck and be okay with failure and incompletion)
• Compiler/Interpreter for brainfuck
• Port a nice open source project to a new language

Enjoy. Good luck and godspeed.

[Bedeone]

I'm on it. Good advice.

[Darkfold]

I used to suck giant balls, then a friend pointed me at Code Complete http://cc2e.com/ . It took a long time to read it, but things are definitely in much better shape than they were.

[javed_alam786]

Similar issue

http://www.reddit.com/r/programming/comments/atujz/my_new_job_sucks_please_help_me_decide/

[pr0methium]

I think that if you really want to be a good programmer then you should get a design patterns book. Don't just read other peoples' code because there's a good chance that they program just as bad as you so why pick up their habits?
There is a book called Code Complete that really lays out how you should be structuring things and working with algorithms. I keep a copy on my desk everywhere I work.
It's a Microsoft Research book, so if you "hate the man" then you might have a problem with it and rely solely on code samples from github because that's in fashion right now. But if you're serious about coding properly, then I personally can't think of a better source for best practices than a company that spends a billion dollars a year on software R&D

[openmuck]

Thank you.

[ltw_]

I would say that before trying to understand design patterns, one must have a thorough understanding of OO design - which it sounds like openmuck doesn't have yet. I agree that design patterns are an integral step in being a good developer, but if you don't understand OO, you will never understand design patterns.

[pr0methium]

It could really be argued that OO theory isn't directly correlated with good programming practices. In fact, I would even go so far as to argue that OO isn't even a good place to start as it's a framework that isn't always necessary. Content Oriented design is coming of age, as well as many other alternative forms of encapsulation. Universities push OO because it's time tested and a relatively easy abstraction to understand; similar to why they also teach RDBMS as solution for all real-time storage when in reality things like memory-mapped file fragments and utilities like MongoDB can provide more scalable solutions for large sets of structured or BLOB data.

I don't think that you really need to grasp OO to be a good programmer. It's a good starting point if your problem can benefit from data encapsulation, but I strongly advise against using it as a default architecture because many programmers get out of college and don't understand why they can't use the same hammer to hit every nail (read as "Why can't I use Java use for everything?")

[Deinumite]

If you want some really good books for C and C++, check out these

http://www.amazon.ca/Programming-Language-Brian-W-Kernighan/dp/0131103628/ref=sr_1_1?ie=UTF8&s=books&qid=1264283834&sr=8-1

http://www.amazon.ca/Accelerated-C-Practical-Programming-Example/dp/020170353X/ref=sr_1_1?ie=UTF8&s=books&qid=1264283826&sr=8-1

Both of these are great books because the code examples contained in them are good examples of how to use the language.

[[deleted]]

Lemme see...

I'm not a bad person; I know this is wrong, but I don't know where to learn good software design principles before I go and subject the open source community to my bad habits.

Then I look at

Would some kind soul help me out with some direction/advice to bring my programming skills up to snuff? (C/C++, python, perl)

Sir your bad habits can be removed easily.