Reddit Reddit reviews Design Patterns: Elements of Reusable Object-Oriented Software

We found 217 Reddit comments about Design Patterns: Elements of Reusable Object-Oriented Software. Here are the top ones, ranked by their Reddit score.

Computer Vision & Pattern Recognition
AI & Machine Learning
Computer Science
Computers & Technology
Design Patterns: Elements of Reusable Object-Oriented Software
Great product!
Check price on Amazon

217 Reddit comments about Design Patterns: Elements of Reusable Object-Oriented Software:

u/samort7 · 257 pointsr/learnprogramming

Here's my list of the classics:

General Computing

u/_a9o_ · 188 pointsr/cscareerquestions

Refactoring: Improving the design of existing code

Design Patterns

Working Effectively with legacy code

Clean Code

How to be a programmer

Then there are language specific books which are really good. I think if you read the above, slowly over time, you'll be in a great place. Don't think you need to read them all before you start.

u/Magical_Gravy · 61 pointsr/badcode

My bad.

In Object Oriented Programming (OOP), there are lots of design patterns that end up getting repeated all over the place. You might have run in to the factory pattern, or perhaps the builder pattern?

If you can understand and notice these patterns, it means you can re-use old code more effectively, because code to handle a pattern in one place is probably very similar to code to handle a pattern in another.

In addition, if you're discussing a problem with somebody, it means you can refer to the patterns by name as a sort of shorthand notation for "put it together like this". Saying "use a decorator" is a lot quicker and easier than describing what exactly "a decorator" is from scratch every time.

The "Gang of Four" are four Computer Scientists who were among the first few to notice that these patterns kept popping up, and wrote a pretty well known book describing about 20 of the most common ones.

In this specific instance, the builder pattern would probably have proved useful. Rather than having a single, monolithic constructor, you create a separate "builder" class.

Character chararacter = new Character(xx, yy, life, kpph, kpyl, kvin, krak, kgr, kptgr, kbb, havepph, havepyl, havevin, haverak, haveya, isevented, x1, y1, x2, y2, x3, y3, x4, y4, x5, y5, IE)

Can become

Character character = Character.builder()
.initialCoordinates(x1, y1)

This is waaayyy more readable (especially if you're assigning values as arguments, rather than named values. If you ever called createFrom(...) with a string of numbers, it'd be very difficult to work out which number was what), and a lot easier to lay out properly. It also means you can gather arguments for creation gradually over time rather than all at once.

Also looking more closely, and as /u/PM_ME_YOUR_HIGHFIVE pointed out, they're not actually using objects at all, which would be a good place to start.

u/Nezteb · 43 pointsr/compsci

Some book recommendations:

u/Shuank · 40 pointsr/argentina

Creo que mucha gente se confunde ser autodidacta con hacer algun cursito de como hacer una web y darle con eso.
Para llegar a cierto nivel, tenes que aprender computer science, teoria y trabajar en cosas que te permitan aplicar esa teoria.
Tenes que saber ver un algoritmo y poder calcular la complejidad, tenes que entender que son las patrones de diseño y cuando conviene aplicar tal o cual.

Tenes que entender como funciona OOP, pero tambien tenes que aprender algun lenguaje funcional, te va a hacer un programador más rico.

Tenes que entender de Unit Testing, automated testing, Integration testing.

Los dos libros que más me ayudaron cuando empecé en computer science son :

Y ir codeando mientras vas leyendo y aplicando las cosas es fundamental.

Me parece que la diferencia entre ser autodidacta es que no tenés esa vara minima que te da la facultad, asi que depende de vos que tan crack queres ser y si estas dispuesto a poner el laburo y a aprender cosas constantemente.
La información esta en internet o Amazon, no hay ningún secreto.

u/geek_on_two_wheels · 33 pointsr/csharp
u/jhartikainen · 32 pointsr/cscareerquestions

fwiw, bare minimum working code is often a good idea if we're talking about the amount of code to do some task :)

Design patterns are most useful in that they help you start recognizing patterns in your own code, and they show you a number of common patterns which can be useful - but it's good to keep in mind that you shouldn't force a design pattern somewhere just because it's a design pattern.

Anyway, the Design Patterns book is good, and so is Head First Design Patterns.

u/jesseguarascia · 31 pointsr/gamedev

I think your major problem here is that you want the "why not"s instead of the "why"s. A good programmer can look at a chunk of code and determine "why" the programmer is doing certain things. These pre-extising code blocks that people refer to are given because you should be able to read through it and interpret what's going on and why. The questions you most likely ask at the "interpreting" stage isn't "why" but instead "why that way and not this way?"

Really, when it comes down to it, the answer as to that question for a lot of things in engine programming (or just programming in general) is that it's what the lead designer or lead programmer thought was the best idea.

For instance: How do you want to store your array of tiles? As integers representing tile indexes in a tile set? As separate Tile class instances in a vector array containing vector arrays of Tile instances? As a hashmap indexed using characters to grab a tile? etc. There's a million ways to handle each and every part of an engine, it all comes down to what design patterns and what theories you think are the best for what you need your engine to do.

I suggest reading up on some of the design patterns in here (actual link in the sidebar) and here. They're a great way to start understanding the multitudes of ways of handling different ideas in your engine! Reading up on pre-existing theory or seeing pre-existing pseudo-code is fine and dandy, but sometimes you have to reinvent the wheel. Sometimes, for the most part you can follow a lot of design patterns that already exist.

P.S. For a great tutorial on loading tile maps and working with them in your game, lazyfoo's got you covered (it's in C++ but can easily be adapted for other languages) Here

u/in0pinatus · 23 pointsr/programming

I admire your dogged adherence to being wrong in every particular. It takes a special brand of stubborn contrarianism to quote someone's badly edited notes as a primary source and then followup by a claim that this is best possible research.

However, outside in the real world, Alan Kay writes extensively and authoritatively here and in his numerous contributions on Hacker News quite aside from publications spanning decades.

And an awful lot of people agree with his definition. The introduction of the classic Design Patterns defines objects as an encapsulated package that only responds to messages. People who teach OO programming readily quote Mr Kay's definition. The Ruby programming language is fundamentally based upon it, and before you shout "but Ruby has classes" note that Ruby classes are actually themselves objects, for which the new message happens to do something particular by convention. And so on; the point being that Alan Kay's definition is super influential, which is why the idea that Erlang is the most object-oriented language is not a new proposition.

u/abstractifier · 22 pointsr/learnprogramming

I'm sort of in the same boat as you, except with an aero and physics background rather than EE. My approach has been pretty similar to yours--I found the textbooks used by my alma mater, compared to texts recommended by MIT OCW and some other universities, looked at a few lists of recommended texts, and looked through similar questions on Reddit. I found most areas have multiple good texts, and also spent some time deciding which ones looked more applicable to me. That said, I'm admittedly someone who rather enjoys and learns well from textbooks compared to lectures, and that's not the case for everyone.

Here's what I gathered. If any more knowledgeable CS guys have suggestions/corrections, please let me know.

u/teknobo · 22 pointsr/programming

Even though this seems to be just aggregating some Stack Overflow answers into blogspam, I'll bite.

> Two lines of code is too many

If you're seriously going to complain about one extra line of code in a method, I don't see this ending well.

> If it's not native, it's not really programming

Semantics. Even if you don't call it programming, you'd damn well better know those things if you want to use them. SQL, Java, and any other VM-based language may not qualify as "programming" by this definition, but they're still damn useful.

> The "while" construct should be removed from all programming languages. (In favor of "Repeat...Until")

Semantics again. There is no functional difference between the two, and I would argue that while is actually preferable since it puts the looping condition right there on the same line, instead of having to skip to the end of the block to find out if you even entered the block in the first place.

> Copy/pasting is not an anti-pattern.

No, it's not, and it's been proven. I'm having a hard time finding the peer-reviewed study on copy/paste programming right now, but basically, it's been shown to save a lot of time as long as you're using it properly.

Where the hatred for it comes in is that, like GOTO, if you use it too often, you'll probably end up using it wrong.

> Developing on .NET is not programming, it's just stitching together other people's code

A reiteration of his 2nd point, but honestly, a huge amount of working as a professional programmer -- hell, almost the definition of working in a team -- is stitching together other people's code. There's nothing wrong with that, and it's hardly controversial.

> The use of try/catch exception handling is worse than the use of simple return codes and associated common messaging structures to ferry useful error messages.

This has been getting debated a lot in go-lang circles, but the general consensus seems to be that unless you're working in an embedded environment (or some other highly-constrained environment), you're probably better off with try/catch.

> Test constantly

Test-Driven Development is something that I personally agree with, and truthfully has become a very popular practice among Rails people. I don't see how that would qualify it as being controversial.

That said, certain studies have shown evidence that TDD is not as effective as many seem to believe.

> Object Oriented Programming is absolutely the worst thing that's ever happened to the field of software engineering.

I've heard this claim semi-often. It seems to mostly come from people having worked with languages that claim to be OO but constantly make exceptions to the rules, like Java, C++, or Python. In fact, the author specifically calls out Java.

Try Smalltalk or Ruby and you'll come to see that OOP done right is actually quite wonderful.

> C (or C++) should be the first programming language

Debatable, but certainly not controversial by any stretch of the imagination.

> Classes should fit on the screen.

How big is your screen? I can fit any class definition on a 64" monitor.

Some classes simply must be large. It is an unavoidable fact that certain things are simply more complex to model than others. This point isn't controversial, it's just asinine.

> Making invisible characters syntactically significant in python was a bad idea

This again? Is it really a controversial opinion if it's been something non-Python programmers have been whining about for decades? Because as far as I can tell, people whine about it for about the first five minutes of Python coding, and then give up because they would've been indenting anyway.

It can cause bugs when transferring code between computers, I'll give them that. Otherwise, it's Python demanding good formatting, something that you should be demanding from everyone on your team anyways.

My main regret with Python is that I haven't found a good tool that auto-formats everything (a la "gofmt").

But otherwise, Python's indentation requirements are so in line with common indentation in almost every programming language that proper indentation comes naturally to more or less everyone. In how many programming languages that you regularly use do you not format your conditional, looping, class/method, or exception blocks?

> Singletons are not evil

It's not controversial to agree with Design Patterns. That book is more or less the undisputed truth on the subject, and it thinks the Singleton pattern is fine and dandy.

u/MrBushido2318 · 20 pointsr/gamedev

You have a long journey ahead of you, but here goes :D


C++ Primer: One of the better introductory books.

The C++ Standard Template Library: A Tutorial and Reference: Goes over the standard template library in fantastic detail, a must if you're going to be spending a lot of time writing C++.

The C++ Programming Language: Now that you have a good idea of how C++ is used, it's time to go over it again. TCPPL is written by the language's creator and is intended as an introductory book for experienced programmers. That said I think it's best read once you're already comfortable with the language so that you can full appreciate his nuggets of wisdom.


Modern C++ Design: Covers how to write reusable C++ code and common design patterns. You can definitely have started game programming by the time you read this book, however it's definitely something you should have on your reading list.

C++ Templates: Touches on some similar material as Modern C++ Design, but will help you get to grips with C++ Template programming and how to write reusable code.

Effective C++: Practical advise about C++ do's and dont's. Again, this isn't mandatory knowledge for gamedev, but it's advice is definitely invaluable.

Design Patterns: Teaches you commonly used design patterns. Especially useful if you're working as part of a team as it gives you a common set of names for design patterns.


C++ Concurrency in Action: Don't be put off by the fact I've put this as an "advanced" topic, it's more that you will get more benefit out of knowing the other subjects first. Concurrency in C++11 is pretty easy and this book is a fantastic guide for learning how its done.

Graphics Programming

OpenGL: A surprisingly well written specification in that it's pretty easy to understand! While it's probably not the best resource for learning OpenGL, it's definitely worth looking at. [edit: Mix it in with and arcsynthesis's tutorials for practical examples and you're off to a good start!]

OpenGL Superbible: The OpenGL superbible is one of the best ways to learn modern OpenGL. Sadly this isn't saying much, in fact the only other book appears to be the "Orange Book", however my sources indicate that is terrible. So you're just going to have suck it up and learn from the OGL Superbible![edit: in retrospect, just stick to free tutorials I've linked above. You'll learn more from them, and be less confused by what is 3rd party code supplied by the book. Substitute the "rendering" techniques you would learn from a 3d book with a good 3d math book and realtime rendering (links below)]

Essential Mathematics for Game Programmers or 3D Math Primer for Graphics and Game Development: 3D programming involves a lot of math, these books cover topics that OpenGL/DirectX books tend to rush over.

Realtime Rendering: A graphics library independent explanation of a number of modern graphical techniques, very useful with teaching you inventive ways to use your newly found 3d graphical talents!

u/sid78669 · 18 pointsr/compsci

I would recommend reading Design Patterns: Elements of Reusable Object-Oriented Software. That book will give you the majority of design knowledge you would gain at this point in your career from college.

u/bmathew5 · 18 pointsr/learnprogramming

Design Patterns by the gang of four. It is the essence of designing software architecture. It describes very common designs that have been tested time and time again, however it is broad and you have to specify your requirements but it is an amazing starting point.

(ps it actually is similar to design problems in civil architecture identified by Christopher Alexander. A Pattern Language (1977) & A Timeless Way of Building(1979).)

It really opens doors to how you should approach and choose the correct design. It's not language specific. The book however does have C++ examples

u/Cohesionless · 17 pointsr/cscareerquestions

The resource seems very extensive such that it should suffice you plenty to be a good software engineer. I hope you don't get exhausted from it. I understand that some people can "hack" the technical interview process by memorizing a plethora of computer science and software engineering knowledge, but I hope you pay great attention to the important theoretical topics.

If you want a list of books to read over the summer to build a strong computer science and software engineering foundation, then I recommend to read the following:

  • Introduction to Algorithms, 3rd Edition: A lot of people do not like this classic book because it is very theoretical, very mathematical, and very abstract, but I think that is its greatest strength. I find a lot of algorithms books either focus too much about how to implement an algorithm in a certain language or it underplays the theoretical foundation of the algorithm such that their readers can only recite the algorithms to their interviewers. This book forced me to think algorithmically to be able to design my own algorithms from all the techniques and concepts learned to solve very diverse problems.

  • Design Patterns: Elements of Reusable Object-Oriented Software, 1st Edition: This is the original book on object-oriented design patterns. There are other more accessible books to read for this topic, but this is a classic. I don't mind if you replace this book with another.

  • Clean Code: A Handbook of Agile Software Craftsmanship, 1st Edition: This book is the classic book that teaches software engineer how to write clean code. A lot of best practices in software engineering is derived from this book.

  • Java Concurrency in Practice, 1st Edition: As a software engineer, you need to understand concurrent programming. These days there are various great concurrency abstractions, but I believe everyone should know how to use low-level threads and locks.

  • The Architecture of Open Source Applications: This website features 4 volumes of books available to purchase or to read online for free. It's content focuses on over 75 case studies of widely used open-source projects often written by the creators of said project about the design decisions and the like that went into creating their popular projects. It is inspired by this statement: "Architects look at thousands of buildings during their training, and study critiques of those buildings written by masters."

  • Patterns of Enterprise Application Architecture, 1st Edition: This is a good read to start learning how to architect large applications.

    The general theme of this list of books is to teach a hierarchy of abstract solutions, techniques, patterns, heuristics, and advice which can be applied to all fields in software engineering to solve a wide variety of problems. I believe a great software engineer should never be blocked by the availability of tools. Tools come and go, so I hope software engineers have strong problem solving skills, trained in computer science theory, to be the person who can create the next big tools to solve their problems. Nonetheless, a software engineer should not reinvent the wheel by recreating solutions to well-solved problems, but I think a great software engineer can be the person to invent the wheel when problems are not well-solved by the industry.

    P.S. It's also a lot of fun being able to create the tools everyone uses; I had a lot of fun by implementing Promises and Futures for a programming language or writing my own implementation of Cassandra, a distributed database.
u/sbsmith · 12 pointsr/gamedev

Hi PizzaPartify,
I believe that different companies/teams will place emphasis on different skills. When I was helping to hire software engineers for EA's motion capture studio, I liked to see candidates who showed a strong aptitude for engineering code to be maintainable. For me, this meant a familiarity with design patterns and software development processes (like Test Driven Development or Extreme Programming). In my department, much of our code was in C++ and Python. However, other departments would use languages like Java, C# or ActionScript - depending on the project.

It would be helpful to know what role you are applying to.

To answer your specific questions:

  1. If you're already familiar with C++, I would highly recommend reading Effective C++ by Scott Meyers ( Every C++ developer should read this.

    Regardless of the language you're working in, I would also recommend Design Patterns by the gang of four (

    A game-specific recommendation is Game Engine Architecture by Jason Gregory ( It doesn't matter if you intend to write an engine or not, it is immensely helpful to understand how they work.

    I own all of the Game Programming Gems books but use them more as a reference library. The books above will be more helpful right now.

  2. I worked with Unity only briefly to prototype a game, so I can't really comment here.

  3. This is tricky. I think you will need to find a passion project in C++ so that you will just naturally learn more about the language. And speaking of passion: you need to really want the job you are applying for. I have seen qualified developers miss out on jobs because you could tell they were just looking for anything (rather than really being enthusiastic about the position).

    I hope that helps.
u/frenchst · 12 pointsr/cscareerquestions

Three CS fundamental books in the order I'd suggest someone read them if they don't have a background in CS.

u/SouthernArrowwood · 11 pointsr/learnprogramming

From what I understand they're a way to structure your code to solve specific problems. An example would be a combination of the Factory pattern and the Component pattern as a way to use data driven design to create "things" in your world (I have enemy Bob, Bob.txt/Bob.xml/Bob.whatever has all the information to create Bob. The "factory reads in this info, and then handles creating the entity and components.)

If you'd like to learn more there's the gang of 4 book Design Patterns: Elements of Reusable Object-Oriented Software, and for a focus on design patterns in games I liked

u/faintdeception · 11 pointsr/learnprogramming

The amount of planning you have to do scales with the complexity of the project.

Professors drill the importance of planning, documentation and unit testing into students because it is extremely important and once you start your career if you're a poor planner it's going to come back to haunt you.

However, when you're working on a simple project that's not intended for public release you don't have to go overboard with docs unless you just want to practice.

My own process usually starts with me jotting down an idea; I find that writing it out helps me to get a better grasp on the overall feasibility.

Once I'm satisfied that I actually have something I can implement I'll diagram the flow of the application, and maybe do some wire-frames.

I usually find that this is enough of a launching pad for a simple personal project.

Professional projects are a different ballgame, because as I said, the amount of planning you have to do scales with the complexity and size of the project. It's in the professional environment that all of the things your professors are teaching you will become really important.

So, to answer what I think was your question,

>So how does one end up with 20 classes connected with each other perfectly and a build file that set everything up working flawlessly with unit test methods that check every aspect of the application?

This comes about more in the implementation phase than the planning phase. I've heard it said that in war "no plan survives contact with the enemy" and you'll find this to be true in software development as well. Even when you plan really well you'll sometimes have to go back to the drawing board and come up with a new plan, but that's just part of the process.

Some books that I recommend on the topic are Hackers and Painters - Paul Grahm and I think every software dev should have a copy of Design Patterns

The former is a collection of essays that might give you some useful perspective on the process of writing software.

The latter is more of a reference book, but it's helpful to become familiar with the patterns covered in the book so that you don't find yourself re-inventing the wheel every time you begin a new project.

As for the other part of your question (apologies for addressing them out of order)

>My new "bottleneck" writing code is the structure. I end up having huge classes with way to many public methods. I might as well just write a script with everything in one file. Almost anyway.. I try to write OO, but I often get lazy and just end up with not very elegant systems I would say.

Don't be lazy, because as you're already seeing, it comes back to bite you in the ass.

As you're writing your code you have to be mindful of the complexity of the project as it grows around you, and you have to periodically take a step back and look at what you've created, and re-organize it. This kind of goes back to what I was saying earlier about no plan surviving enemy contact.

So when you find yourself creating a new class that you hadn't thought about, be mindful of where you put it.

Should you create a new file (yes, of course you should), new folder?

Do you have a bunch of similar classes doing the same thing? Should they inherit from one another?

Be especially mindful of copy and pasting from one are of your code to another, generally speaking if you're doing this you should probably be writing a function, or using inheritance.

It's up to you as the developer to make sure your project is organized, and now-a-days it's really easy to learn how to best organize code by looking through other peoples projects on github, so there's really no excuse for it.

Hope that helps, good luck.

u/SkepticalMartian · 11 pointsr/PHP

Beginner and Novice are the same thing. It sounds like you're trying to transition of Beginner to Intermediate.

You really should stop trying to write your own framework for the moment, and start using a mature framework. Good frameworks aren't trivial to write, and generally require an expert level of knowledge to write well.

The thing with a framework is that it helps remove you from a lot of boilerplate code - that is, common code everyone would normally need for any give web project. The easiest way for you to bridge the gap is to begin using and understanding code that is better than yours. Don't reinvent the wheel until you understand how to make a better wheel.

Design patterns are everywhere in good code. The trick is to recognize when a design pattern is being used, and to understand why it's being used. In order to help with this, it's commonly recommended to read Design Patterns: Elements of Reusable Object-Oriented Software. This is a book every programmer should own regardless of the language they use.

u/ActionHotdog · 9 pointsr/cscareerquestions

Knowing a giant list of programming languages is really overrated. Instead, focus on learning new programming concepts.

Sometimes that can mean learning a new language, but not always. Some examples:

  • Design patterns! There's so many and while a lot of them are pretty niche, it's always helpful to be able to identify what someone else's code is doing, or identify when a give problem can be partially solved using one. The Gang of Four is the go-to book for this area.

  • On the other end, anti-patterns. Being able to identify (and fix) poor design choices that can cause maintainability problems later is really valuable.

  • Memory management. Java/C# handle most of it for you, but understanding what's happening under the covers is crucial for making design decisions (i.e., how much garbage needs to be collected as a result of using this API versus a different one?). C/C++ is the king of this area, so you could use this as a reason to learn a new language.

  • Functional programming (Scheme, Lisp). It's really different from imperative (Java, C#, C++) programming.

  • Advanced features of languages that you already know. Generics, operator overloading, etc. You might know many of these, but I doubt you know all of them.

    And regarding your concern of it being harder to learn new languages later, you'll only really have that problem when learning a vastly different language (such as Scheme when compared to your C#). Once you know one language in the same "family", a lot of knowledge carries over.
u/Newt_Hoenikker · 9 pointsr/C_Programming

C and C++ are pretty different nowadays depending on your standard. "Game engine" is a pretty generic descriptor, because you can build game engines in a lot of different ways depending on your needs for the genre and how all-encompassing your engine needs to be, so I'm going to ask you a few questions about specifics in regards to your experience which might help to flesh out where you can start your search.

  • How are you with Data Structures? Algorithms? Which are you familiar with? How extensively have you used them? CLRS is a decent starting point with pretty broad coverage and good descriptions.

  • What about Design Patterns? Which ones? How much? They're not so much applicable in C, but C++ and other OOP languages are lousy with them. My university was way too into this book, but it wasn't bad; bonus all the examples are in C++.

  • How portable is your code, generally? What's your programming environment like? Windows? Mac? Linux? *BSD? Games are usually Windows oriented, but there's a lot that C/++ can do aside from that, and IMHO the best way to learn systems programming is with C and a Unix-like OS.

  • What is it exactly that you want to accomplish with your code? A broader engine? A more portable engine? Something not game related? In my experience learning for the sake of learning is great and all, but I lack drive without a concrete goal I'm working toward.

    Hope this helps.
u/rafuzo2 · 8 pointsr/androiddev

Here's a rough outline, from high level to low(ish):

  • Fundamentals of Object Oriented Programming. Understand basic concepts like inheritance and encapsulation and why you'd use them. Any book with these words in the title/subtitle should be able to get you the basics, pull a highly-rated book off Amazon for recommendations.

  • (This is optional but highly recommended) Learn basic design patterns such as those presented in the Gang of Four book. These aren't required for writing Android apps but the more you understand about patterns the more it'll help you later on. You don't need to master this stuff at the outset so just read at your leisure.

  • Learn Eclipse. It's a big subject and for seasoned veterans the various components can be confusing, but you should know how to use an Integrated Development Environment regardless.

  • Follow the tutorials that VersalEszett mentioned.

    Extra Credit
  • Get an account on Github and understand how Git works. It's free unless you want private repos. Google around, find android development projects that are public, clone the repos and walk through the code - retype it line by line if you need to. Try to figure out why things are broken out the way they are.

    That will get you started but there's tons more. The best thing you can do is write code and read code and be patient.
u/munificent · 8 pointsr/ruby

One of the things we can do to make our lives harder in software engineering is muddle terminology. It adds needless friction to our job if when you say "flernb" you're referring to a widget but when I use say it, I'm talking about a whozit.

In low level code, we're pretty good about sticking to the first term that was coined for something. If you have a series of objects, each with a reference to the next, you'll probably call it a "linked list", just like I would.

But when it comes to higher-level architecture and design, names get a lot messier. Fortunately, some dudes wrote a book that tries to be the beginning of a taxonomy for architecture. Ultimately, the names they pick are arbitrary, but if we all agree to stick to them, then they become concretely useful.

What the author describes here is not a proxy. A proxy is a local object that represents a distant one, usually on another machine or process. It's not a very common part outside of distributed systems.

The author created an adapter.

u/herpington · 8 pointsr/learnprogramming

These are all good points.

With respect to Design Patterns, I feel that the holy grail is Design Patterns - Elements of Reusable Object-Oriented Software by Gamma et al.

u/JohnKog · 8 pointsr/compsci

You probably already have, but if not, definitely read Design Patterns, which is old but a classic. I'd also highly recommend the Pragmatic Programmer.

EDIT: I just want to say, that I also fully support alienangel2's answer. I wanted to recommend a couple good books to get you on "the path", but ultimately, the best thing by far is to find a job that grows you. For some people, the best way to do that is to work at a super small startup, where everything you're building is from scratch. For others (like me), the best way is to work at a company with tons of really smart people who have already built great software, and learning from them and the choices they've made (and why). And if you still feel like you're regressing since school, maybe that's the answer: go back to school (i.e. get a Master's or PhD)!

u/yoho139 · 7 pointsr/ProgrammerHumor

From wikipedia, and I highly recommend this book as reference material.

u/mrcleaver · 7 pointsr/java

Learn by experience and by reading is probably the way to go. The gang of four's design patterns is still the de-facto standard:

I really love this book for Java design patterns though, fun to read and really informative:

Then it's a matter of knowing when and where to apply them, which is a harder problem and just an experience thing I'd say.

u/ArmenShimoon · 7 pointsr/csharp

They seem a like reasonable starting point I think. Repetition is the mother of mastery, the more books the better (in addition to applying what is learned).

Since Mosh is calling out learning fundamentals as important to becoming a good C# developers, I would personally also recommend some general (non C# specific books) too for who are starting out in software development:

  1. Design Patterns (Amazon) - also known as the "Gang of Four" Design Patterns, it was originally published in 1994 and is still relevant today. When people talk about design patterns, they're referring to the book more often then not.

  2. Soft Skills (Amazon) - Not a book on programming actually... it's a software developers life manual. The reason I like this book is it covers the other parts of the life of a developer that I haven't seen covered anywhere else. Everything from learning strategies, time management, career advice, and even some health and fitness. It was an enjoyable read and I think other developers would enjoy it too.

  3. The Passionate Programmer (Amazon) It's been a while since I've read this one, but I remember it giving decent advice for building a career in software development. Not to be confused with The Pragmatic Programmer (Amazon) which should be read at some point too.

    There's a ton more, but those are a few that stood out to me. Essentially the more the merrier in my opinion - books, courses, videos, tutorials, and so on. The books I'm recommending here focus on adopting the developer mindset and being successful at it. That's part of the puzzle.

    The other part is understanding the technical details including the programming language and frameworks you intend to use.

    And finally, for learning about C#, I do highly recommend Mosh's videos/courses (some are free on YouTube, others available on Udemy). He's got a unique ability to explain things clearly and simply in a way that beginners can pick up quickly.

    What I'd do is check out his free content first, and if you agree his style is ideal for learning, an investment in one of his courses is well worth it since he'll cover a lot more breadth and depth on each of the topics and they're organized into a super consumable package rather than scouring the internet for various topics.
u/ZukoBestGirl · 7 pointsr/ProgrammerHumor

And you could check stack overflow for question on general programming books. I would always go for a general concept functional programming over how to functional programming in haskell.

But I'll be perfectly honest, I'm a victim of the curse of knowledge so I honestly don't know how one should start. What I do remember is that I had huge problems with syntax (how do I tell language X to do a for (Employee e in employeeList), how do you write a switch and stuff, why would I ever need a ternary operator, and like that.

But once you master the basics of how to write x, y and z in your preferred language, you absolutely need to understand design patterns, you absolutely need to understand how code is supposed to be written, you absolutely need to understand data structures, you absolutely need to understand inheritance and polymorphism, you absolutely need to understand lambdas and functional programming.

Then you can get to the more "neat" stuff like the benefits of having immutables, and "job specific stuff" like how to solve race conditions in threading; sockets and web communication, etc.

u/Tefferi · 7 pointsr/JobFair

Two things: The coursework from my CS degree, and reading books about software engineering.

I've spoken in other places about the former, and for the latter, I recommend The Pragmatic Programmer, Code Complete, and Design Patterns: Elements of Reusable Object-Oriented Software

u/FattyBurgerBoy · 6 pointsr/webdev

The book, Head First Design Patterns, is actually pretty good.

You could also read the book that started it all, Design Patterns: Elements of Reusable Object-Oriented Software. Although good, it is a dull read - I had to force myself to get through it.

Martin Fowler is also really good, in particular, I thoroughly enjoyed his book Patterns of Enterprise Architecture.

If you want more of an MS/.NET slant of things, you should also check out Dino Esposito. I really enjoyed his book Microsoft .NET: Architecting Applications for the Enterprise.

My recommendation would be to start with the Head First book first, as this will give you a good overview of the major design patterns.

u/EughEugh · 6 pointsr/programming

There are several good books on designing good software:

Code Complete

Design Patterns


u/JavaJosh94 · 6 pointsr/learnprogramming

While data structures and algorithms are important, don't forget design patterns!

Design Patterns: Elements of Reusable Object-Oriented Software

u/whereisspacebar · 6 pointsr/cscareerquestions
u/flares___ · 6 pointsr/programming
u/KingEsoteric · 6 pointsr/AskMen

Small employment gaps are no big deal. Over six months people may ask, but it's all in how you answer. I'm not sure why you feel like you're unmarketable having worked in the industry for two years, but do know a lot of the postings - especially junior postings - are inflated. I've seen one that asked for three years of experience with Visual Studio 2019. If you're halfway there, shoot your shot.

As a junior dev, the expectations are low. All I'd expect you to know is how to get code up and running that I don't have to tear down for the good of the company. Be able to read your language and solve simple problems. The biggest thing I look for in a junior dev is if I can give them some piece of of the software to write while I'm not looking and feel that you're mostly there when I come back to check. Apply for appropriate positions and don't fudge your experience. Enthusiasm and eagerness to learn go a long way. Don't be a know-it-all from your position.

Decide what kind of role you'd prefer, and start the process of brushing up on that. Use the job postings that represent the jobs you want as direction on what you need to learn. If the role you really want is too far, get a job doing what you know to pay for your education in the role you want.

As a front-end developer, you're going to want to learn a Javascript toolchain and one modern framework to start. Npm and Node.js are the backbone of what you do. If you want to switch, learn what juniors do in that paradigm. Do know that the Javascript world is fast-paced and fad-based, so if you miss a wave, wait two years and the next one will be coming around for you to hop on.

Personal projects are a good idea, just make them meaningful by using the proper setup (not just some bullshit hack job) or address an interesting problem. You're going to want to get it up on a personal repository that you can put a link to right on your resume and job site (Indeed, Dice, Glassdoor, Linkedin) posting. Be able to speak to every decision you made, even if it was a bad one. Your personal project doesn't have to be spotless or even completely done, it just has to be yours, it should be able to execute, and you should show some decent decision making. A mod for a game, a contribution to open source, a personal thing that has some use-case or whatever.

Get experience with related technologies. Start to learn one step before and beyond the one you're a specialist in. For example, you're a junior front-end dev. Learn a little about backend work, and learn about deployments. Learn about the experience of your fellow team members as they try to integrate your work with Git, build with Jenkins or AWS Code Build, and containerize with Docker. Think about the pain points you face in architecture, code, building, and deploying; think about how you'd solve them or if you can't, keep an eye on solutions as you go. Know the differences between elements of your chosen sphere.

Higher level concepts like SOLID principles,Design Patterns, and Refactoring Patterns are more goals than expectations, but you should take a look at them now and at least be able to speak to at least one of them somewhat. With limited time, prefer Design Patterns. You don't want to walk into an interview where someone asks you about how you use design patterns and you've never heard of them. Even if they'll accept that, you still won't feel good about it.

Look up some materials on coding challenges, as some companies give coding quizzes. I just had an interview with a guy that touted 10+ years of experience but couldn't read from a file given an hour.

If you feel like you're going to be let go due to performance, get ahead of that and ask your supervisor how you're doing or what you need to do to grow. If you feel like you're going to be let go due to a restructuring you can't affect, you have two options: get to know other teams so you can maybe hop on their project later, or just save your money and get to work on some of the stuff above each weekend until the axe falls. You're a junior dev. You're not expected to be perfect, but you should come in a teachable state - some foundation with programming, a willingness to learn, a willingness to figure things out, and the ability to take direction.

u/JAPH · 6 pointsr/learnprogramming

Introduction to Algorithms by CLRS. Used in almost every algorithms class I've heard of, and a great reference book. It's about 1300 pages, so don't try to read straight through it.

C Programming Language by K&R. This is a C programmer's Bible.

Design Patterns by the Gang of Four

This is a little more of a topic book, but The Art of UNIX Programming by Raymond.

These are all either pretty common, or almost essential. You'll probably see these in your curriculum anyway, and you should. These are a good cornerstone.

u/obeleh · 6 pointsr/compsci

Perhaps offtopic but... Some books you should read regardless of CompSci branch

u/Shadowhawk109 · 6 pointsr/learnprogramming

MVC is just a paradigm. Implementations differ from language to language, and some languages have better support than others, but yeah, just a paradigm.

Look into Design Patterns by the (in)famous "Gang of Four" for more information about this.

I will say this -- most experience I have with C# backends leads to great usage of databinding between model and view regardless of application platform (WPF, Windows Forms, even some ASP.NET). And I'm pretty impressed with the support of other design structures that C# and Visual Studio offer with the help of NuGet (looking at you, Angular).

u/joeswindell · 5 pointsr/gamedev

I'll start off with some titles that might not be so apparent:

Unexpected Fundamentals

These 2 books provide much needed information about making reusable patterns and objects. These are life saving things! They are not language dependent. You need to know how to do these patterns, and it shouldn't be too hard to figure out how to implement them in your chosen language.

u/Tip_of_the_hat · 5 pointsr/learnprogramming

It really depends on your use case. A good starting point (I'm assuming architecture in software) would be to read Design Patterns by Group of Four. It uses C++ for it's examples and is quite a dense read, but is worth the read.

u/Nition · 5 pointsr/gamedev

Not specifically game-related, but the great classic Design Patterns: Elements of Reusable Object-Oriented Software is really well written, and it's patterns are as applicable to game design as they are for anything else.

You do say you're an experienced programmer though, so you may already know many of the basic general design patterns in there (or you may have read the book even).

u/caryy · 5 pointsr/learnprogramming

In addition to Code Complete 2, which, while very dense, is a compendium of wonderful coding knowledge... I recommend Clean Code by Robert C. Martin.

One of the best books on concurrency that I've ever read is definitely Java Concurrency In Practice it's (obviously) written with Java in mind, but most of the concepts map rather easily to constructs in other languages as well.

The standard for design patterns is still probably Design Patterns (colloquially "Gang of Four")... but I've heard good things about Head First Design Patterns as well, despite the really stupid cover.

u/joshrulzz · 5 pointsr/programming

> Computer science is about building things like engineering but without the luxury of a toolbox and components taken from the physical world. No one has worked out reliable and effective procedures for building large pieces of software as the engineers have done for physical project.

At first, I started to take issue with this statement because of software patterns. But I he means more than this. The author's points were thus:

  • Engineering components exist in the real world - No one expects a widget to break the laws of physics.
  • Engineering components interact in more predictable ways - In the real world, separate subsystems are really separate.
  • Engineering has fewer fundamental midcourse design changes - Waterfall process works because people don't demand mid-course changes as much.

    IMHO, the author's points are a human problem, not an engineering problem. In point 1, a project manager didn't set expectations for a client. In point 2, developers did not use tools that exist. Buffer-overrun protection DOES exist (his example), and other technologies help modularize software properly. Hell, cohesion and coupling are among the core software design principles. In point 3, again, a project manager did not properly set expectations for the client. PM technologies like agile methods have been developed to fight this. Further, because software is much newer to the human knowledge collective, it's less well understood. When it has been around for as long as architecture and machines, clients will have better expectations of the process.

    In all, it sounds like his experience with software has not been true engineering rather than modern software development techniques.
u/pogotc · 5 pointsr/PHP

A good place to start might be learning some of the common design patterns, these are common solutions that have been found to work over and over. The standard book for learning them is this one:

It's not a PHP book but the patterns it covers can be used in any language, there's also loads of stuff on Wikipedia around them:

Learning how to approach a programming problem is at the heart of being a good programmer and it's something you'll always be able to improve on (I'm still learning after 15 years of programming) so I would recommend a combination of trying to read as many programming books as you can, asking for help on StackOverflow when you need it, looking through well written open source code to see how those guys approach problems and above all else, practice, practice, practice.

u/xbrandnew99 · 5 pointsr/Frontend

Design Patterns: Elements of Reusable Object-Oriented Software doesn't use JS for it's examples, but is highly regarded in learning design patterns.

Also, Mastering JavaScript Design Patterns is pretty good, and if I recall correctly, is modeled after the first book I mentioned. Heads up, there is a more up to date 2nd edition of this book available (linked version is 1st edition)

u/ttutisani · 5 pointsr/softwarearchitecture

My blog about software architecture: (may not be for very beginners but I hope that it's able to communicate important topics).

I'd also suggest reading the classic book about design patterns (a.k.a. Gang of Four):

There are several good thought leaders in this direction, specifically Martin Fowler ( and Eric Evans (he does not write much online, but his book is great - all about modeling properly):


I'm big on modeling, objects, etc. so reply back if any questions.

u/sh0rug0ru · 5 pointsr/java

Read lots of code and read books to get multiple viewpoints. This is a deep topic which will require more than superficial online reading.

Check this out.

Books I have found useful:

u/robertcrowther · 5 pointsr/programming
  1. He's not the author
  2. The book was published in 1994
  3. Java was first released in 1995
u/thatsnotgravity · 5 pointsr/learnprogramming

Pragmatic Programmer, Clean Code, and Head First Design Patterns come to mind right away. They're 3 of my favorites.

There's also Design Patterns by the Gang of Four. That's a lot more dense IMO than Head First, but it's fantastic material.

Since you're looking to jump ship and start interviewing, take a look at Cracking the Coding Interview. That will prepare you for any questions you run into during the process.

It's probably also worth brushing up on Algorithms and Data structures.

u/eric_weinstein · 5 pointsr/learnprogramming

Seconding The Pragmatic Programmer and Cracking the Coding Interview. I'd also recommend:

  • Code Complete: verbose and somewhat self-congratulatory, but extremely good.
  • The Mythical Man-Month: a little dated and weirdly religious at times, but has great insights into how software problems are actually people problems and how large projects are (mis)managed.
  • Design Patterns: a.k.a. the Gang of Four book. This one's a classic.
  • Pro Git: you mentioned version control systems. IMHO, you should learn Git if you don't know it, and this book is a great resource.

    If you let us know which languages you primarily write, I can probably recommend some good language-specific titles, too.
u/realfizzbuzzed · 5 pointsr/learnprogramming

For language specific stuff like c++ I'd suggest: as a pretty good quick review. Going through c++ primer (or whatever book you learned C++ from) and just touching on all the topics that you don't remember can help a lot.

What helped me with design patterns is head first design patterns. Even though that book seems very 'intro' it has helped me pass all the design pattern question I've ever gotten. I think just visitor, singleton and MVC are the most popular interview design patterns. The more canonical 'gang of four' book would be: this.

For just practice tech interview problems that you'll see on silicon valley, big4 tech interviews, the most popular site is probably leetcode (hackerrank, or top coder or even codewars are pretty good sources too). The most popular book (as mentioned many times) is Cracking the coding interview.

Just grinding out problems on leetcode, you'll probably learn enough to pass most tech interviews after about 100-200 questions (if you've never done this before, less if you have).

Before/during your leetcode practice I've written a series of tech interview tips to help you check on your fundamentals (you can check it out at I try to go over the questions I see people failing most often. I'm also trying to help readers so would love to help you if you run into problems.

I also think you should ask the recruiter the style of interview you'll be having. If you are on the whiteboard then you should practice on it before hand (whiteboard interview tips here.

u/j-dev · 4 pointsr/learnprogramming

There are books out there, many of which are unfortunately not language agnostic, that deal with this. What you want to know is the basics of object oriented design and, most importantly, design patterns, which are general answers for recurring object-oriented design challenges. You may have to dabble into languages other than the one(s) you currently use in order to follow along.

u/ckdarby · 4 pointsr/PHP

I have included some links for more information about myself in the original post.

To have a better idea of the type of person I am these are the books within my arms reach right now:

Design Patterns: Elements of Reusable Object-Oriented Software

[Refactoring: Improving the Design of Existing Code](

The Mythical Man-Month

Along with some other ~50 similar books I've read.

u/cjrun · 4 pointsr/cscareerquestions

Everybody's learning style is different. Here are some books I believe to be essential for any novice or pro.

Programming For Dummies. It has a stupid title, but it is well reviewed for good reasons. I read through this beast in three weeks. There is no coding involved, as it is mostly theory, but it covers most of the bases of computer science and programming logic. Looking back, much of it confused me at first read, but the big ideas are all presented here. Reading this during the summer before first semester was a huge boost for me. All of the major computer languages are discussed in the book.

Cracking the Coding Interview. A book meant for veterans trying to get into highly demanding top tech companies, the book is a great introduction to programming paradigms. There are numerous examples of problems in each chapter with answers at the back of the book. The whole thing is in Java, with a short chapter on C++.

Design Patterns. As you learn more about object oriented programming, the concept of design is introduced. This book is the holy grail of software architecture and recommended by many. I would hold off acquiring it until you are certain that CS is where you want to be, it is quite technical. This book follows C++, although a Java version of the patterns exists on

A non-technical book just for fun:
The Innovators is essentially the story of computer science and how it got to present day. It follows the characters, human beings, that were involved each step of the way right up until modern day. Your professors will be impressed that you know who Alan Turing, Grace Hopper, and Charles Babbage were. If only I had been at THE MOTHER OF ALL DEMOS! The actual stories of Microsoft, Apple, The internet, the PC, video games, the space program, etc. On Quiz Up, a trivia app, every other question in the CS category involves names from this book. Read it just to be a real geek that knows where this stuff came from, and the drama/tension that led to innovation. The book is actually really funny at times.

u/reflectiveSingleton · 4 pointsr/webdev

I would add design patterns to that list...they are extremely helpful and it essentially what modern frameworks try to put in place.

It's why MVC/etc exists, and if you are fluent in many design patterns then you can mix/match/modify the appropriate one to your current problem set. Also, things like that transfer to non-backend development if you ever decide to go that route.

See books such as Design Patterns: Elements of Reusable Object-Oriented Software - written by the 'gang of four'...and other related and more modern derivatives of this.

u/OverQualifried · 4 pointsr/Python

I'm freshening up on Python for work, and these are my materials:

Mastering Python Design Patterns

Learning Python Design Patterns

Fluent Python

Design Patterns: Elements of Reusable Object-Oriented Software

I recommend them to OP.

u/CSMastermind · 4 pointsr/learnprogramming

I've posted this before but I'll repost it here:

Now in terms of the question that you ask in the title - this is what I recommend:

Job Interview Prep

  1. Cracking the Coding Interview: 189 Programming Questions and Solutions
  2. Programming Interviews Exposed: Coding Your Way Through the Interview
  3. Introduction to Algorithms
  4. The Algorithm Design Manual
  5. Effective Java
  6. Concurrent Programming in Java™: Design Principles and Pattern
  7. Modern Operating Systems
  8. Programming Pearls
  9. Discrete Mathematics for Computer Scientists

    Junior Software Engineer Reading List

    Read This First

  10. Pragmatic Thinking and Learning: Refactor Your Wetware


  11. Code Complete: A Practical Handbook of Software Construction
  12. Software Estimation: Demystifying the Black Art
  13. Software Engineering: A Practitioner's Approach
  14. Refactoring: Improving the Design of Existing Code
  15. Coder to Developer: Tools and Strategies for Delivering Your Software
  16. Perfect Software: And Other Illusions about Testing
  17. Getting Real: The Smarter, Faster, Easier Way to Build a Successful Web Application

    Understanding Professional Software Environments

  18. Agile Software Development: The Cooperative Game
  19. Software Project Survival Guide
  20. The Best Software Writing I: Selected and Introduced by Joel Spolsky
  21. Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams
  22. Rapid Development: Taming Wild Software Schedules
  23. Peopleware: Productive Projects and Teams


  24. Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency
  25. Against Method
  26. The Passionate Programmer: Creating a Remarkable Career in Software Development


  27. The Mythical Man-Month: Essays on Software Engineering
  28. Computing Calamities: Lessons Learned from Products, Projects, and Companies That Failed
  29. The Deadline: A Novel About Project Management

    Mid Level Software Engineer Reading List

    Read This First

  30. Personal Development for Smart People: The Conscious Pursuit of Personal Growth


  31. The Clean Coder: A Code of Conduct for Professional Programmers
  32. Clean Code: A Handbook of Agile Software Craftsmanship
  33. Solid Code
  34. Code Craft: The Practice of Writing Excellent Code
  35. Software Craftsmanship: The New Imperative
  36. Writing Solid Code

    Software Design

  37. Head First Design Patterns: A Brain-Friendly Guide
  38. Design Patterns: Elements of Reusable Object-Oriented Software
  39. Domain-Driven Design: Tackling Complexity in the Heart of Software
  40. Domain-Driven Design Distilled
  41. Design Patterns Explained: A New Perspective on Object-Oriented Design
  42. Design Patterns in C# - Even though this is specific to C# the pattern can be used in any OO language.
  43. Refactoring to Patterns

    Software Engineering Skill Sets

  44. Building Microservices: Designing Fine-Grained Systems
  45. Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools
  46. NoEstimates: How To Measure Project Progress Without Estimating
  47. Object-Oriented Software Construction
  48. The Art of Software Testing
  49. Release It!: Design and Deploy Production-Ready Software
  50. Working Effectively with Legacy Code
  51. Test Driven Development: By Example


  52. Database System Concepts
  53. Database Management Systems
  54. Foundation for Object / Relational Databases: The Third Manifesto
  55. Refactoring Databases: Evolutionary Database Design
  56. Data Access Patterns: Database Interactions in Object-Oriented Applications

    User Experience

  57. Don't Make Me Think: A Common Sense Approach to Web Usability
  58. The Design of Everyday Things
  59. Programming Collective Intelligence: Building Smart Web 2.0 Applications
  60. User Interface Design for Programmers
  61. GUI Bloopers 2.0: Common User Interface Design Don'ts and Dos


  62. The Productive Programmer
  63. Extreme Programming Explained: Embrace Change
  64. Coders at Work: Reflections on the Craft of Programming
  65. Facts and Fallacies of Software Engineering


  66. Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software
  67. New Turning Omnibus: 66 Excursions in Computer Science
  68. Hacker's Delight
  69. The Alchemist
  70. Masterminds of Programming: Conversations with the Creators of Major Programming Languages
  71. The Information: A History, A Theory, A Flood

    Specialist Skills

    In spite of the fact that many of these won't apply to your specific job I still recommend reading them for the insight, they'll give you into programming language and technology design.

  72. Peter Norton's Assembly Language Book for the IBM PC
  73. Expert C Programming: Deep C Secrets
  74. Enough Rope to Shoot Yourself in the Foot: Rules for C and C++ Programming
  75. The C++ Programming Language
  76. Effective C++: 55 Specific Ways to Improve Your Programs and Designs
  77. More Effective C++: 35 New Ways to Improve Your Programs and Designs
  78. More Effective C#: 50 Specific Ways to Improve Your C#
  79. CLR via C#
  80. Mr. Bunny's Big Cup o' Java
  81. Thinking in Java
  82. JUnit in Action
  83. Functional Programming in Scala
  84. The Art of Prolog: Advanced Programming Techniques
  85. The Craft of Prolog
  86. Programming Perl: Unmatched Power for Text Processing and Scripting
  87. Dive into Python 3
  88. why's (poignant) guide to Ruby
u/fluicpana · 4 pointsr/italy

Per testare le acque velocemente puoi usare (introduce Ruby in modo basico). Anche Coursera, Khan, Udacity e simili hanno corsi introduttivi sulla programmazione.

Mentre se vuoi imparare a programmare, il percorso deve toccare almeno tutte queste tappe, in ordine:

  1. [Computer Organization and Design](

  2. The Structure and Interpretation of Computer Programs

  3. Un buon libro di Assembly

  4. The C programming language

  5. Compillers

  6. Code complete, The practice of programming

  7. Fai finta di aver letto tutto The art of computer programming

  8. Un linguaggio a oggetti, magari Programming Ruby

  9. O/E Python, Dive into Python

  10. Design patterns

  11. Impara un linguaggio funzionale.

    Da qui puoi partire e specializzarti in quello che ti interessa

u/Jonny0Than · 4 pointsr/learnprogramming

The "gang of four" book titled Design Patterns is an excellent reference for object-oriented architectures.

Note - this really is more like a reference book than a tutorial or gentle introduction. It's not something you read cover-to-cover.

u/Continuities · 4 pointsr/javascript

This is a really big question, and not really specific to javascript. Architecting large applications, in my opinion, is kind of an art form. You can learn strategies by reading, but you're not going to get good at it without years of experience. Ideally you learn this stuff while working alongside strong senior developers who know what they're doing.

Read Design Patterns, if you haven't. I'd also recommend Javascript Alongé, but I'm a functional programming crazy.

Build something in a way that feels right, then evaluate what worked and what didn't. Which parts sucked to modify when requirements or assumptions changed? Which parts were hard to understand a month later?

In general, I have a few guidelines:

  1. Definitely use some sort of module system (AMD, or ES6 modules) to aid in encapsulation and prevent global pollution
  2. Keep similar code together and differing code apart.
  3. Keep modules small, and single purpose
  4. Prefer composition over inheritence
  5. If you're doing web stuff, don't be afraid to keep the html, css, and js for specific pieces of UI together. Don't fall into the trap of conflating technology with concerns.
u/carols10cents · 3 pointsr/cscareerquestions

Design Patterns (sometimes called the "gang of four" book) is the best book I know of about design patterns- and I haven't heard of it being used in college courses (I could be wrong). This will give you a sense of the patterns that are out there, but knowing which pattern to use when is still mostly experience and even team-based preference/convention.

CS programs give you a broad overview of computer science theory, which is helpful but is not in any way sufficient to prepare you for programming practices. What you're going through is totally normal.

Debugging someone else's code is a skill that is also not taught in schools. I actually did a talk on debugging skills a few years ago; the slides don't make much sense but we made a PDF of our main points. I'll see if I can find video when I'm not on my phone.

I'm happy to talk more about this stuff with you or anyone else reading this; pm me or email carol dot nichols gmail.

u/GrayDonkey · 3 pointsr/java

You need to understand there are a couple of ways to do Java web development.

  • Servlets & JSPs. - Check out Core Servlets and JavaServer Pages or the Java EE Tutorial. Note that I link to an older EE tutorial because the newer versions try to switch to JSF and not much changed in Servlets and JSPs between Java EE 5 and 6. I recommend learning Servlets and JSPs before anything else.
  • JSF - A frameworks that is layered on top of Servlets and JSPs. Works well for some tasks like making highly form centric business web apps. Most of the JSF 2 books are okay. JSF is covered in the Java EE 6 Tutorial
  • Spring - Spring is actually a bunch of things. You'd want to learn Spring MVC. If you learn any server-side Java web tech besides Servlets and JSPs you'd probably want to learn Spring MVC. I wouldn't bother with GWT or any other server-side Java web tech.
  • JAX-RS - After you get Servlets and JSPs down, this is the most essential thing for you to learn. More and more you don't use server-side Java (Servlets & JSPs) to generate your clients HTML and instead you use client-side JavaScript to make AJAX calls to a Java backend via HTTP/JSON. You'll probably spend more time with JavaScript:The Good Parts and JavaScript: The Definitive Guide than anything else. Also the JAX-RS api isn't that hard but designing a good RESTful api can be so be on the lookout for language agnostic REST books.

    Definitely learn Hibernate. You can start with the JPA material in the Java EE tutorial.

    As for design patterns, Design Patterns: Elements of Reusable Object-Oriented Software is a classic. I also like Patterns of Enterprise Application Architecture for more of an enterprise system pattern view of things. Probably avoid most J2EE pattern books. Most of the Java EE patterns come about because of deficiencies of the J2EE/JavaEE platform. As each new version of Java EE comes out you see that the patterns that have arisen become part for the platform. For example you don't create a lot of database DAOs because JPA/Hibernate handles your database integration layer. You also don't write a lot of service locators now because of CDI. So books like CoreJ2EE Patterns can interesting but if you are learning a modern Java web stack you'll be amazed at how archaic things used to be if you look at old J2EE pattern books.

    p.s. Don't buy anything that says J2EE, it'll be seven years out of date.
u/sgspace321 · 3 pointsr/iOSProgramming

I didn't look through your code.

Just some general advice: Don't force design patterns into your app. Design patterns are solutions to common problems. You should just be familiar with them to recognize when you're trying to solve a common problem.

You should read this:

u/gauchopuro · 3 pointsr/programming

The "Gang of Four" design patterns book is the one that started it all. There are code samples in C++.

I've also heard good things about the "Head First Design Patterns" book.

u/technocraty · 3 pointsr/cscareerquestions

As far as your courses go, the best book I can recommend is Algorithms in a Nutshell. It is a small book which quickly introduces you to most of the core algorithms you will use throughout University. It also covers measuring efficiency through "big O notation" - a very important concept in CS.

If your University's SE program is anything like the one I am familiar with, you will also be focusing on software engineering principles. The most important SE books I ever read are:

u/SeriousGoose · 3 pointsr/MLPTalentExchange

Design Patterns (Gamma, Helm, Johnson, Vlissides)[aka the Gang of Four] is THE Design Patterns book, but it's a little dry and I don't think it talks about MVC that much. I've gotten about 1/3 of the way through it twice, I just keep getting distracted and forget about it.

Head First Design Patterns has gotten a lot of good reviews and I've head good things about the Head First series of books, but I haven't read any of them myself.

I'm not sure about any online tutorials, but I'm sure they exist.

I taught myself a little about Design Patterns and MVC, but I'm sure I understand them just enough to be dangerous. I'm going to be taking a class this Fall that should talk about Design Patterns more.

u/donnfelker · 3 pointsr/androiddev

What books can help you expand your knowledge of design patterns?

u/KorgRue · 3 pointsr/webdev

Only ever fully read a single programming book, and that was because the material was best learned through a book. It was about non language specific design patterns. It was a key that unlocked so much knowledge for me.

The book is Design Patterns: Elements of Reusable Object Oriented Software. It's old but it does not matter. Object Oriented design patterns don't change much because they are tried and true, and you will see them in every OO language. While JS is not technically OO (though ES6 introduces some strong OOP features), it still uses many of the same patterns!

u/diisiqueira · 3 pointsr/brasil

Cara, reinventar a roda não é ruim! Resolver problemas clássicos é uma ótima maneira de aprender e praticar é a melhor maneira de melhorar em algo. Eu sou o tipo de cara que gosta de aprender as coisas na prática então sou suspeito de falar mas vai lá e desenvolve. Essa minha aposta com meus amigos é justamente para nos forçar a isso, desenvolve qualquer coisa mesmo que seja algo completamente inútil, que é melhor do que ficar parado. Umas semanas atrás, nessa aposta um dos meus amigos desenvolveu um script que calculava se era ecologicamente correto urinar no chuveiro ou na privada, utilidade real do projeto é nula, mas fazendo isso ele já começou a aprender uma nova linguagem e investiu tempo em se tornar um programador melhor. Realmente meu conselho é faça, desenvolva! Uma dica é pegue pequenas coisas do seu dia-a-dia e resolva elas com programação, por exemplo, uma vez eu fiz um script que me perguntava quais ingredientes eu queria em um lanche, ai ele varria o site do iFood e me falava qual era a opção mais barata que eu tinha. Não tinha necessidade alguma de fazer isso, era muito mais rápido fazer uma busca manual, mas na época isso me ensinou a usar a BeautifulSoup e foi super divertido de fazer.

  1. Eu sempre tive a visão de que o mercado python no Brasil é bem mais fraco do que em outros países, não sei ao certo de porque, aqui na minha região por exemplo não conheço nenhuma empresa que seja especializada em python. Por outro lado aqui o grande foco das empresas é o PHP, em todos os níveis. PHP é realmente uma linguagem de entrada, por ser muito aberta e deixar a pessoa fazer as coisas de qualquer maneira, acaba sendo muito fácil de tornar uma pessoa capaz de criar códigos funcionais em PHP, depois quando aprendem melhor o paradigma da programação, muitas acabam migrando para outras linguagem.

  2. Atualmente eu tenho dois livros que ficam grudados na minha cabeceira da cama, e leio um pedaço todos os dias quando acordo, são eles o Clean Code e o Design Patterns. Tambem to de olho no The Pragmatic Programmer.

u/Toasterthegamer · 3 pointsr/gamedev

Although I agree with the others and good coding pillars are important. C# can be incredibly easy to learn and as such it's great for beginners to start with. Focus small and build up from there. I would write simple console apps understanding the core concepts before you move into actual gamedev coding. Without a strong fundamental grasp of how C# works you'll end up rewriting code in your game later on as you learn new things. You might spend a good chunk of time doing something a very tedious way only to discover that there is a much easier way later on. Also as others have said code agnostic coding pillars are very important. Some good books:

Understanding how to structure your code is very important.

u/PAK-9 · 3 pointsr/cpp

I was underwhelmed by code complete, although I had really high expectations after jeff atwood gushed about it so hard.

Design patterns I don't hear brought up very often but I found it extremely useful. Even if you don't use or even like some of the patterns you are likely to encounter them in your programming career at some point and being able to recognise them is invaluable.

u/ntr0p3 · 3 pointsr/AskReddit

By biology I don't mean what they teach you in college or med-school, I mean understanding the basic processes (physiology-esque) that underlie living things, and understanding how those systems interact and build into more complex systems. Knowing the names of organs or parts of a cat is completely worthless, understanding the process of gene-activation, and how that enables living organisms to better adapt to their environments, especially, for instance, for stress factors activating responses due to new stimuli, can be very valuable, especially as a function of applied neurology.

Also, what we call biology and medicine today will be so pathetically obsolete in 10 years as to be comical, similar to how most mechanics can rebuild a carburetor, but not design and build a hybrid drivetrain, complete with controller software.

Economics and politics are controversial, but it is a question of seeing the underlying forces that is important, similar to not understanding how gravity works, but still knowing that dropping a lead ball will accelerate downwards at 9.78m/s^2. This is a field that can wait till later though, and probably should.

For systems analysis, I'm sorry but I can't recommend anything. I tended to learn it by experience more than anything.

I think I understand what you are looking for better now though, and think you might be headed in the right direction as it is.

For CS I highly recommend the dragon book, and design patterns, and if you need ASM The worst designed website ever.

For the other fields I tend to wiki subjects then google for papers, so I can't help you there. :(

Best of luck in your travels however! :)

edit: For physics, if your math is bad get both of his books. They break it down well. If your math is better try one of wittens books, but they are kinda tough, guy is a fucking genius.

also, Feynman QED is great, but his other book is awesome just as a happy intellectual read

also try to avoid either kaku and hawking for anything more complicated than primers.

edit no. 9: mit's ocw is win itself.

edit no. 10: Differential equations (prolly take a class depending on your math, they are core to almost all these fields)

u/bot_bot_bot · 3 pointsr/AskProgramming

The Pragmatic Programmer and Design Patterns.

The Pragmatic Programmer is a really enjoyable read about practical decision making and coding practices. Design Patterns is more for reference, both great books. You can google the design patterns though, but I like to have a copy of the book anyway.

u/ThereKanBOnly1 · 3 pointsr/csharp

So I don't think you should get too hung up on "enterprise architecture" at the moment, partially because you're still very early in your career, but also because enterprise architecture means a lot of things to a lot of different people. At this stage in your career, I really think you should focus mainly on SOLID code, core Object Oriented design concepts, and then understanding patterns. Good architectural strategies are built around all of those concepts, but they're also much much more than that.

For SOLID code, one of my favorite references is actually Dependency Injection in .Net by Mark Seemann. Although he does spend a good amount of time on DI, the recommendations that Mark makes for how to properly structure your code in order to take advantage of DI are very useful in understanding SOLID oriented design principles in general. The examples and code really work through the concepts well, so you get a great explanation followed by some well thought out code.

Clean Code by Uncle Bob is a great reference on how to structure well thought out code that touches on some architectural principles, but doesn't have that as the main focus of the book. Many of the topics in the book you'll find need to be addressed throughout a codebase.

As far as design patterns (which are different then architectural patterns), I don't think you can go wrong with the original Gang of 4 book , although I personally have a C# specific version, C# Design Pattern Essentials. I don't want to put too much emphasis on design patterns, because sometimes they get overused and applied too literally, but they are still very useful. I think the key to design patterns is not just knowing what they are, but determining where they might be applicable to your use case, and whether you should make any small adjustments or tweaks to them.

After you really have a rock solid base of working with code, then you can shift your focus on more architectural concerns. For that, it really depends on what problem your looking to solve, but Domain Driven Design (DDD) is a good way about understanding those problems and to structure the solutions in a well thought out, loosely coupled, and evolvable manner. That "central framework" that you referenced in your post is the business logic, and its the key focus of DDD

u/cyrusol · 3 pointsr/learnprogramming

Algorithms? Something like because there you are supposed to create more complex algorithms from the "simple" ones you learn from books or perhaps in college or from Wikipedia/googling/free online resources.

Design patterns? That book specifically and anything from Robert C. Martin, but preferrably Clean Architecture.

If you are poor there are probably PDFs/epubs somewhere in the web but consider buying the books when they made you rich.

u/Ravilan · 3 pointsr/node

IMO you should go beyond learning node.
Learn javascript (node is just javascript with core libraries).
Actually don't learn javascript, learn how to code.
Even more, learn how to learn.

I'm not the only one with this opinion:

Also a side point: learn how to test. Testing (may it be unit, behaviour, …) is really important. It helps you code better, have a stronger code (less bugs, or more easily identifiables), more maintainable, and so on.

If you know the basis of code, and how to learn, not only you'll know node, but you'll potentially know php, ruby, scala, whatever.

I strongly encourage you to read:

u/Jollyhrothgar · 3 pointsr/learnpython

Just looking for learning, etc? If it's for interview prep, I'd give different recs.

I highly recommend:

u/N0N-Available · 3 pointsr/learnprogramming

This is one of those questions that basically yields no useful answers.

  • On the how part, it depends. Generally you would analyze your requirements and problem and find out that it fits problems described by one or more design patterns. So you apply these design patterns and modify them as fit until you think you've cover all the basis on a higher level. Now you have a fuzzy picture of the house you want to build and where the general walls and hallways are. You might have kitchen and bedroom marked that you know will be for certain purpose but you don't have anything specific in each room yet(hope the analogy makes sense)

  • Next step will be the more difficult part, which is fine tunning and validating your blueprint. Idk how other people do it, but I prefer to run through each requirements and see how they fit into each "room". This process usually expose ambiguity in the architecture. You want to the repeat the process till it is clear how each requirement will be handled. It's a good idea to also anticipate how the requirements might change or expand in the future when validating your architecture.

  • In the case of Django they basically did most of that for you already. If that's all you work on then I'm not sure what you are asking, you could look into data structures topic if you want better data model designs. Front end is pretty flexible, usually depends on the framework you pick and follow their design style. For server side application that supports your front end would depends on your problem/requirements. Like I said this is one of those questions that yields no useful answers since it's essentially design question and design is very subjective and a broad topic. As far as UML or whatever other tool/diagrams you choose to use, it really doesn't matter as long as it conveys your design clearly and there's no ambiguity.

    Not sure if I answered your question. You can checkout topics on design patterns. there's a good book on Amazon for that I think just called design patterns. Or checkout tutorialpoint.Com ? For software architecture.

    Design Patterns Book

    Software Architecture Quick Overview

    edit: added resources and changed format
u/ASUalumi · 3 pointsr/cscareerquestions
u/pyrotech911 · 3 pointsr/cscareerquestions
u/thehollyhopdrive · 3 pointsr/java

Two Java specific books you should read cover to cover (and keep around as an effective reference) are Effective Java and Java Concurrency in Practice, and you should also seriously consider reading Design Patterns. The examples in it aren't written in Java but they hold for all OO languages.

u/LuminousP · 3 pointsr/Physics

Sadly, for a large part of the industry, Java and C# is the standard.

.Net still has a huge marketshare for developers, but Java is gaining quickly. Get proficient in either of these and some Agile development practices, as well as design patterns.

The Gang of four book is the standard design pattern book. I don't know off the top of my head what the best books to get on Java and C# are, but there are huge threads on StackOverflow that will point you in the right direction.

Good luck, my friend!

u/GeminiVI · 3 pointsr/csharp

> learn these patterns practically?

Maybe for now you might want to just read up on them and keep them in mind for the future. For further reading on design patterns pick up "Design Patterns: Elements of Reusable Object-Oriented Software". When you start building something plan it out before hand, preferably with pen(cil) and paper. Once you have some rough idea, see if you can recognize any place where design patterns would come into play. Sometimes they will be intuitively incorporated into your design process, or they will emerge naturally if you try and think holistically about a problem instead of moving your project along piecemeal.

>My goal eventually would be to land an entry C#/.NET position at some software company.

I would encourage you to learn ASP.NET MVC 5, a web framework like Angular or React, and Entity Framework. You may just want to learn the "Core" versions of ASP.NET and Entity Framework then go back .

I've taken this course on udemy on ASP.NET MVC 5, which I would recommend. The same author has put together another course on ASP.NET Core, AngularJS, and Entity Framework which I want to take soon. It looks like they are sequential given the requirements for each course, so you should take the MVC 5 course before you take the ASP.NET Core course. If you created a Github for a sample website (say a pizza shop where users can register, login, and order) and hosted it on Azure to show prospective employers, that could very well get your foot in the door.

u/lodc · 3 pointsr/ITCareerQuestions

Well I'm 40 and didn't really "get" CS until I was in my early 30s, despite doing it for 10+ years prior. Once you turn the corner or whatever it is, things just make sense. For me what helped was going back to the concepts called "computational thinking", as described here

I understood the meanings of words like abstraction, recursion etc but didn't really know them as well as I needed to, and didn't know how to see these same basic ideas everywhere, take advantage etc. Also learning some design patterns such as explained in the gang of four book can be eye opening.

edit - book

u/bwainwright · 3 pointsr/learnprogramming


I've been a professional programmer for 20 years and I still don't formally know design patterns.

What I mean by "formally" is that I naturally use more basic patterns without even realising it.

However, recently I've moved into software architecture for my company, and am finding that there are more and more reasons to learn and understand patterns, as they help design complex systems.

Definitely focus on programming first. Patterns will come.

Also, a tip - people will always recommend the Gang Of Four book ( for design patterns. And it is the gold standard book for Design Patterns. However, in my opinion, it is an incredibly 'dry' read.

Head First Design Patterns ( is a much better introduction to design patterns for most people.

u/Neres28 · 3 pointsr/learnprogramming

Sounds like what you've done is real/serious programming, just on a smaller scale.

I wouldn't worry too much about not knowing various frameworks. We use Spring to inject dependencies into our client code, we use Glassfish as our application server, and we use JPA backed by EclipseLink as the glue to our data layer. However, when it comes down to it it's mostly about writing plain old Java objects.

For the rest:

  • I've heard that the Head First design patterns book is very good, but haven't read it myself. I've always gone to the GOF, but I do find it dry and hard to understand at times.

  • For algorithms I used Cormen et al in college and still refer back to it. But I don't really suggest it outside of a classroom.

    Rather than further enumerate my reading list, I'll point you to the Programming FAQ; an excellent resource for exactly the questions you're asking.
u/pipocaQuemada · 3 pointsr/learnprogramming

Read the GOF design pattern book. For better or for worse, you can't write intermediate Java if you aren't familiar with the basic patterns of Java code

u/thescientist13 · 3 pointsr/angularjs

There’s really no meaningful content, it’s all just very superficial IMO. You just keep saying what a patten is, list a few at the end and then you don’t explain them or even give examples. Lastly, no relevance to AngularJS in the article, which is the sub you’re posting in.

As far as AngularJS goes, I would recommend most people start with John Papa’s styleguide.

As far as JavaScript design patterns go, I would recommend this book.

For learning about design patterns and a larger set of them in general, you can’t beat the Gang of Four

u/zoredache · 3 pointsr/learnpython

What you might want to do is pick up a book on design patterns. I am not aware of an good ones specifically aimed, at python though.

Learning the mechanics of doing OOP in python really isn't that hard. Learning how design your objects is the tricky bit. A book on design patterns basically is just a cookbook of things that work. It is about giving you practical examples of when you would use OOP.

Here are a couple books I have on the subject, and have found useful. Reading about design patterns was basically what let me actually understand the point of OOP.

u/bonestamp · 2 pointsr/angularjs

I know it's temping to take the short cut and look for good examples of how to do it in angular, but I beg you to delay that as long as you can.

Instead, start by reading about design patterns in general. Once you understand the major design patterns, most of them appear regularly or can be replicated in language and framework you learn in the future. If you go into angular with this knowledge, you'll spot bad structure much more easily and know how to fix it. Then it's just a matter of looking at the APIs to see how to achieve those design patterns. You may still end up looking for good examples, but you'll have a much better foundation to work from and you'll probably understand the examples more easily and have some theories to help you do the things that aren't spelled out.

There are many resources for design patterns, including wikipedia. The design pattern bible is this book:

u/timmyotc · 2 pointsr/cscareerquestions

>Oh well, can't work on the past

Everything you do today is tomorrow's past.

You need to do some light learning. I'm linking a few books that are fantastic in accomplishing these goals and I think your english is pretty great, so I don't anticipate so much trouble. I highly recommend doing everything in Java; not because I'm arguing that java is what will help you the most, but because almost every code example from these classics refer to Java.

For design patterns, Gang of Four is a good introduction, but it's a little harder to understand
I would recommend finding AND implementing these patterns.

Grab a copy of Code Complete by Steve McConnel and Clean code by Robert Martin. That will help you write nice code that you'd be proud to share with a company.

u/Corn0ffTheCob · 2 pointsr/cscareerquestions

This is a good place to start:

As for android specific, no idea.

u/ianhedoesit · 2 pointsr/learnprogramming

Design Patterns by the Gang of Four is probably the most cited book on programming design patterns I've ever seen.

u/chrissinclair195 · 2 pointsr/cscareerquestions

Here it is on Amazon. You can probably get a copy cheaper somewhere else though.

u/emcoffey3 · 2 pointsr/IWantToLearn

Objects are for grouping related data and methods together. It really is as simple as that.

Start off by writing applications where you're just creating and consuming objects, not writing your own classes. Java and .NET both have tons of libraries that contain a wide assortment of objects. You mentioned C#, so write a few .NET apps. Try to start identifying and understanding the way properties and methods are grouped into objects, and how the different objects relate to each other.

Once you're comfortable using objects, then you can start writing your own classes. A lot of universities try to teach this by having you write common data structures. This approach is worth considering, as it's important to be familiar with data structures, but this isn't the only way to learn object-oriented programming (nor the best, in my opinion). Another commenter recommended writing a video game, which sounds like it's worth a try. Ultimately, the right approach is the one that interests you the most.

Getting good at OOP will take some practice, but it is possible. Objects are like functions: they should do one thing well. Enforce separation of concerns. Learn the design patterns. Practice makes perfect(-ish).

Recommended Reading:

u/slowfly1st · 2 pointsr/learnprogramming

Your foes are kids in their twenties with a degree which takes years to achieve, this will be tough! But I think your age and your willingness to learn will help you lot.


Other things to learn:

  • JDK - you should be at least aware what API's the JDK provides, better, have used them ( I think (personal preference / experience) those are the minimum: JDBC, Serialization, Security, Date and Time, I/O, Networking, (Internationalization - I'm from a country with more than one official language), Math, Collections, Concurrency.
  • DBMS: How to create databases and how to access them via JDBC. (I like postgreSQL). Learn SQL.
  • Learn how to use an ORM Mapper. (I like jOOQ, I dislike JPA/hibernate)
  • Requirements Engineering. I think without someone who has the requirements you can't really practice that, but theory should be present. It's a essential part of software development: Get the customers requirements and bring it to paper. Bad RE can lead to tears.
  • Writing Unit Tests / TDD. Having working code means the work is 50% done - book recommendation: Growing Object-Oriented Software, Guided by Tests
  • CI/CD (Continuous Integration / Delivery) - book recommendation: Continuous Delivery.
  • Read Clean Code (mandatory!)
  • Read Design Patterns (also mandatory!)
  • (Read Patterns of Enterprise Application Architecture (bit outdated, I think it's probably a thing you should read later, but I still love it!))
  • Get familiar with a build tool, such as maven or gradle.


    If there's one framework to look at, it would be spring: provides dozens of frameworks, for webservices, backends, websites, and so on, but mainly their core technology for dependency injection.


    (edit: other important things)
u/trashhalo · 2 pointsr/programming

Disclaimer: This may not be true for your job, but it has been for every job I have worked at.

That everything they are teaching you about algorithms will not be useful to you when you get into the field. Your education starts day one at your first job. Clients don't pay us to innovate in algorithms. They pay us to find and glue together other peoples libraries and to use this to present them the requested information.

Code you will actually be writing:

  • Glue code. Integrate Library X with Library Y.
  • Unit tests. To make sure your glue code works as expected.
  • UI code.

    Things you will be doing that CS degree does not prepare you for

  • Fleshing out incomplete requirements documents
  • Dealing with drama between teams
  • Estimation
  • Understanding that 80% is often good enough

    I would suggest reading books like Design Patterns, Mythical Man-Month and Code Complete
u/JamesK89 · 2 pointsr/gamedev

That book is sort of an applied version of the "Design Patterns" book by the "Gang of Four" that is frequently mentioned by the author. The "Design Patterns" book is an excellent reference book to have on hand that I would recommend to any developer. I have both books and of all my programming books (and I have a lot of them) they are probably my two favorites out of the bunch.

u/swankybear · 2 pointsr/SoftwareEngineering

Boot camps might help teach certain technologies, but they might not help with the fundamentals. Additionally before you give money away try to complete courses on Udemy or Coursera to see if you can commit to the effort.

Over simplified recipe for building skills to transition:

  • code on the side; build skills to learn and dig deep. You'll always be solving things you may not know. The skill of learning is huge. Always be curious.

  • Master an OOP language, a scripting language, and maybe get familiar with CSS/HTML/JavaScript Node if you want to be a modern web Dev.

  • read this:

  • read this (recommend to study for Google interviews):

  • learn about web services . Try to build one from scratch with a REST API and a connection to a database. A lot of good fundamentals here and a lot of companies have devs that do this daily.

  • code some stuff on GitHub; maybe find an open source project to contribute to. Get involved with a Dev community and you'll learn 10x more than paying for a boot camp.

  • If web Dev turns out to not be your thing. Dive into other "programming" domains such as machine learning, big data, embedded systems, etc.

    If any buzzwords here might not make sense, congrats you get your first exercise in digging for answers ;) (no rudeness intended)
u/rjcarr · 2 pointsr/learnprogramming

You should first learn the patterns and then apply them to what you're doing:

Probably not as useful to go the other way.

u/shakes_fist · 2 pointsr/learnprogramming

I would suggest checking out design patterns if you haven't already. Even if you don't find direct applications of patterns in your project, you will probably gain some insight into good oop techniques. Check out the gang of four book or headfirst design patterns.

u/richmondavid · 2 pointsr/gamedev

> Books that old are also unlikely to talk about Design Patterns

The original GoF book was published in 1994.

u/Hougaiidesu · 2 pointsr/cpp_questions

One thing that may help is to read

And like someone else said, try to make something that interests you such as a simple text based game or simulation or something, and you'll learn good design over time.

u/topfpflanze · 2 pointsr/PHPhelp

Coding Style:

Currently there is a lot of discussion about the PSR-1 and PSR-2 standards. The PSR-0 is definitly something which you should know about and follow it.

OOP structuring, Design Patterns:
Understand design-patterns (the standard book on this topic by the gang of four), and have a look into the topics of MVC and dependency injection. Zend Framework 2 and Symfony2 are the two major frameworks in this context.

Maybe also learn to know how database patterns like ORM and/or Active Record work. (Frameworks like Doctrine2, Zend_Db,...)

Test Driven Devlopment:
Check out PHPUnit and Behat for Behaviour Driven Testing

Version Control:
Our teams (2-8 programmers) work with both Subversion and Git. I recommend to check out both. Each has its disadvantages and advantages. There is a lot of discussion out there.

Related to this is the knowledge of Continous Integration and the connected tools. (Keywords: Jenkins, Bamboo, phpUnderControl, Hudson)

u/DutchmanDavid · 2 pointsr/gamedev

Read books. It might be boring, but a lot more informational than watching a youtube video.

If you already know how to program in another (preferably OOP) language there's The C++ Programming Language or C++ Primer if you want to learn C++11 (not to be confused with C++ Primer Plus, which is a different book 'series')

If you don't know how to program and you want to learn C++ for game development there's Beginning C++ Game Programming, which starts at the beginning (variables are one of the first things explained). After that book you should read up Introduction to Algorithms to make sure you're not writing horrible inefficient programs. Then there's Design Patterns: Elements of Reusable Object-Oriented Software to teach you more about certain patterns used in programs design (needed when using Ogre3D for example. Ogre3D was 90% magic to me until I read about Design Patterns. :p As alternative to DP:EoROOS there's Head First Design Patterns, but it's Java-centric which is a whole other beast than C++.

After those books there's this Stackoverflow thread. Read the first answer (the gigantic list of books). The thread used to be a ton of comments (with the most votes comments on top), but all anwers got copied to the first comment, so it's all sorted on votes. Code Complete (2nd edition) was the most upvoted one, The Pragmatic Programmer was the 2nd most upvoted one, etc.

Then there's this Stackoverflow thread, which is more C++ centric.

I hope this helps :)

u/whizack · 2 pointsr/golang

Generally the Adapter Pattern is what you're describing, but it could also be used in combination with a Façade or other Structural Patterns from the Gang of Four book.

u/balefrost · 2 pointsr/AskProgramming

So in this case,

  • IBridge corresponds to Implementor
  • Bridge1 and Bridge2 correspond to ConcreteImplementor
  • AbstractBridge corresponds to Abstraction (you can tell because it's the only thing with a field, and Abstraction is the only thing with a field in the pattern)
  • IAbstractBridge doesn't correspond to anything in the pattern
  • RefinedAbstraction from the pattern isn't present in the C# code

    If you want to go deep into the world of patterns, I highly recommend picking up the GOF book. It has 8 pages on the bridge pattern, including an example of supporting multiple window systems without suffering from combinatorial class explosion.
u/xampl9 · 2 pointsr/csharp

“Gang of Four” It’s the original design patterns book.

Like lots of new things, they got over-used. And misused.

Design Patterns: Elements of Reusable Object-Oriented Software

u/valbaca · 2 pointsr/cscareerquestions

These are books I actually own and would recommend. Of course there are other great/better books out there, but I'm going to stick with what I've actually bought and read or "read".

I say "read" because several books are NOT meant to be read cover-to-cover. These typically have about 1/3 that you should read like normal, and then skim the rest and know what's in the rest so that you can quickly reference it. These books are no less important, and often even more important. I've marked these kind of books as #ref for "read for reference". Normal books that should be read cover-to-cover are marked #read

For learning your first language: This is really the hardest part and unfortunately I don't have any books here I can vouch for. I started with "C++ for Dummies" and am not including a link because it's bad. Your best bet is probably "Learning <language>" by Oreily. I also love the Oreily pocket books because you can carry them and skim while on the bus or the john, but you can just do the same with your smartphone. Pocket Python, Pocket Java, Pocket C++

Top Recommendations:

Accelerated C++ #read Made for people who already know another language and want to pickup C++. Also great for people who need a refresher on C++. I really like how it doesn't start with OOP but gets you familiar with the imperative parts of C++ before diving into OOP.

The Algorithm Design Manual #ref This is my new favorite book and the first I would send back in time to myself if I could. Each algorithm & data structure is given a mathematical breakdown, pseudocode, implementation in very readable C, a picture (very helpful), and an interesting war story of how it Saved The Day.

Cracking the Coding Interview #read I originally avoided this book like the plague because it represented everything I hate about coding interviews, but many interviewers pull questions straight from this book so this book can equal getting a job. Put that way, it's ROI is insane.

The Pragmatic Programmer #read Must-have for any profressional software engineer that covers best-practices for code and your growth. You can also find the raw tips list here

Head First Design Patterns #read Many prefer the "GoF/Gang of Four" Design Patterns which is more iconic, but Head First is a modern-version using Java to cover actual design patterns used day-to-day by programmers.

For Intermediates:

Effective Java or Effective C++ and Effective Modern C++ #read When you're ready to go deep into one language, these books will give you a huge boost to writing good Java and C++.

Design Patterns #ref You'll want to get this at some point, but early on it's too much for a beginner and many of the patterns are obsolete.

The Art of Computer Programming #ref The programming "bible" but like Design Patterns you should hold off on this iconic book until you've got your basics covered. It would make for a great purchase with your first paycheck or first promotion :)

u/e7hz3r0 · 2 pointsr/learnprogramming

Regarding a dictionary: not that I know of, no unfortunately.

Also no, programs are not always laid out in the same fashion. There are the concepts of design and architecture. For the purposes here, I'm going to define architecture as how the entire system/program is put together, from the highest-level. Often this involves modules that each contain multiple classes (in OOD). Design, on the other hand, I'll define as how a small number of classes, within those larger modules, are related and interact. This is usually a class diagram in UML. Large scale vs. small scale essentially.

Architecture's goal is reducing risk and ensuring that the application/system exhibit certain non-functional requirements (or quality attributes in SEI-speak). These are '-ilities'. E.g., security, maintainability, modifiability, testability, but also time-to-market, performance, etc. One of the things to remember with architecture is that it encompasses not only the compile-time structure of the code, but also the runtime structure, the deployment (systems-level) structure, and the relationship to other systems (context) and, potentially, time.

While design also influences (and is influenced by) the non-functional requirements, it also concerns itself with data encapsulation: what data should be contained within what objects and how should it be accessed and modified, how tightly coupled and cohesive they should be.

Suggestions for architecture books (these are the two I have personal experience with):

  1. Software Architectures in Practice - It's written by the SEI so it's very much a textbook, but I think they do a good job.
  2. Designing Software Architectures - Another SEI book

    Suggestions for design books:
  3. Design Patterns by the Gang of Four - This is the go-to for most people but isn't the easiest book to read or use. One important thing to keep in mind is that this book is a catalog of design patterns the authors came across/found. It's not a book of recommendations. For example: they have the Singleton pattern but most experienced devs abhor that pattern (though every pattern has its uses).
  4. Head First Design Patterns - The Head First series has a lot of fans but I've never used this particular book.
u/ideidk · 2 pointsr/learnprogramming

If you did the Princeton Algorithms course and have two years experience as a professional developer you're way too advanced for CS50 and other intro classes.

The classes I'd recommend for someone in your position are:

  • Networking (probably the most relevant for you since you're a front-end dev, some knowledge about TCP/IP and HTTP would be beneficial): Udacity has a good course on this
  • Analysis of Algorithms (teaches you some more general algorithmic techniques like dynamic programming, greedy strategies, approximation algorithms, as well as how to mathematically analyze an algorithm to determine its performance): Coursera has a good course on this
  • Computer Architecture and Assembly (teaches you how a computer actually works; not terribly relevant for a front-end dev, but computers will stop being magic after you finish it): Check out OpenSecurityTraining's Intro x86 course for the best course I've ever found on this subject

    More than the above though I'd recommend learning the following concepts and subjects even though there aren't any good MOOCs on them (to my knowledge):

  • Design patterns. There's a couple books that are highly recommended on this subject: Head First Design Patterns and the aptly named Design Patterns
  • Back-end web development. You already know how to do front-end development. Learning back-end development will probably make your job easier when you have an idea of what's going on behind the scenes. It will also allow you to move to full-stack if you ever wish.
  • Design patterns.
  • Web security. Priceless for any web developer, though granted it's more relevant to back-end engineers than front-end.
  • You should really learn design patterns.
u/insertAlias · 2 pointsr/learnprogramming

Personal opinion: for language-specific books, the hands-on ones are the only ones worth reading.

If you want "bedtime reading", I'd suggest books that are broader than learning a specific language. Books that discuss algorithms, or design patterns...stuff like that.

Speaking of design pattern books... Not sure how much mileage you'll get out of that, but it's considered one of the best design patterns books that I've ever heard of.

u/EboKnight · 2 pointsr/gamedev

I'm not sure what your background is, but if you haven't had any formal programming education, I believe we learned out of a book like this:

One of the keys to good software is good design. Making a plan of action before you even start coding cuts back on the 'quick fix' solutions that make your code harder to work with later.

I don't think this is C# specific, but design is really something that is abstract from language specifics. If you're looking for something specific to the environment you're working in, I think material on best practice for the game engine you're using would be better. I have done application development with C# and C# scripts in Unity, and there are definitely differences in how I am able to make things interact, which impacts how I design my code.

I have two recommendations if you're wanting to expand your abilities in design:

  1. UML Diagrams: You can model out all of the pieces, with their members, functions and interactions with each other. Doing this can help in prototyping a system, you can see the interactions and logically create classes and scripts around the model instead of bloating things as you run into problems along the way.

  2. Documentation: This is key to the longevity of a project and saving time in bugfixes and expanding on software later. When you finish any snippet, leave comments explaining what you're doing. Use good variable names. I do consultant work on legacy code and it's amazing how people can write an entire application without comments, in one large Main file and with variable names that mean nothing. I was terrible about naming things 'temp' and what not when I first started out, and if you ever work with anyone else leave a project to sit for a few months to a few years, you and your colleagues will greatly appreciate documentation.

    As far as the book goes, I can't condone it, but there's probably PDFs out there. Sometimes it helps motivate to actually read through it if you've invested some money into it, though. I would recommend finding an old/used copy. An old version of the book should work just as well as an 'updated' version.

    You may also find it useful to look into Agile/Scrum. It's all about documenting your development, and helps to organize what's been done and what needs to be done, as well as give you an idea of how long things take, which helps later with estimations. All these things are skills that will come in handy later, if you decide to pursue software as a career. Plus, it's all good habits that help facilitate good, clean code.
u/nwilliams36 · 2 pointsr/learnprogramming

> Is this stuff obviousl once you program more? Is it the study of software engineering? Computer science? Where can I learn about it?

No you need to work at it, yes, yes and on the job. You can start of the journey of learning this stuff through study and continue through experience. However it is a journey without an end, the landscape is changing, mobiles are the latest new technology but in 10 years time we will all be programming on devices we haven't even heard about yet.

> I want to learn classical program structures that common throughout programs.

There are some common design structures, especially for OO design with the book by the Gang of Four being a foundational work in this area. However knowing the patterns is just the start, knowing when to apply them and why they work is much harder and again comes from experience.

u/kzisor · 2 pointsr/gamedev

I've been doing a lot of research lately on the best books in programming in general to start a blog about each one and their importance to an inspiring developer. These are two of the books which will help you greatly getting started on designing your first game.

The first book is completely about design patterns, you will need to learn about these as creating software in general requires knowledge of how specific design patterns work and when you should use those patterns. The second book in the list is a complete guide to creating a small sample game, albeit not in libgdx, it should provide you with enough material to get you started.

  • Design Patterns
  • Game Code Complete

    I also recommend the Game Programming Patterns and Game Engine Architecture books which were stated in a previous comment. I have both these books as well as the Game Code Complete book and will be buying the Design Patterns book I mentioned as it is the most highly recommended book for any developer.
u/phao · 2 pointsr/java

A lot of doing java programming right is understanding how things are commonly (effectively) done in Java (and in languages with similar set of features).

Regardless of anyone's opinions, a lot of that has to do with learning common design patterns, mainly the ones on the Design Patterns book (gang of four; Although the patterns in the book are just the starting point, it seems to be pretty good in terms of getting you up to speed with what some people tried (and are trying) to do with the design patterns movement, although there is significant disagreement.

There is also concurrency. This is a big thing in Java. A lot of the design of libraries and frameworks in Java are about dealing with concurrency issues. Server applications have to inherently deal with it, and this is where Java is mostly used. Although it's also a language independent subject, it's worth studying it applied to Java. A commonly recommended book is this one:

The issue with all of this is that what I'm basically telling you is that "a large part of learning how to program in Java is to learn how to program", which isn't very helpful on its own. However, it's something I believe a lot of people miss. The focus on the language can be (it isn't necessarily) a symptom of that.

u/melancholiclabs · 2 pointsr/Drugs

Read a lot of books. Everything is usually available as a pdf on the internet and the ones that aren't are $10 to rent on Amazon. Here's the ones that I've read that relate to this project.


u/YuleTideCamel · 2 pointsr/learnprogramming
u/Cryocore · 2 pointsr/gamedev

gratz. After you are done with learning java, you might find this book useful: Design Patterns: Elements of Reusable Object-Oriented Software

u/KevZero · 2 pointsr/java

I have no formal training in CompSci, but this book seems like a pretty standard 1st or 2nd year text. It's one of the best technical book purchases I ever made, imho: Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process by Craig Larman. I would recommend it to anyone who wants to learn programming. Goes great with the classic "GoF" book, Design Patterns. For any particular language's syntax and libraries, I just read the docs and check stackoverflow or IRC for any tricky idioms and for best practices.

u/ldelossa · 2 pointsr/golang

What about some classics like Uncle Bob talks?

A lot of good design focuses on decoupling and creating components which work together but separately also.

Id first look into language agnostic design principles such as SOLID (golang)

A good book will help.

I still keep a copy of the Gang of Four book at arms reach even tho the popularity is dwindling as OOP is not topic of most convos today. However when dealing with DI and sharable components in Golang, i find myself still falling back to abstract factories patterns. Its a good breathe of knowledge to at least glimpse at the patterns here:
Design Patterns: Elements of Reusable Object-Oriented Software

Once you get thru these topics, you can start picking up what I consider the "hot" architectures of today:
Microservices, event based systems, domain driven design, event sourcing, and architectures aiding themselves to functional programming.

I really enjoy reading Martin Fowler blog posts:

He covers a lot of these topics.

PS: maybe a niche and a personal favorite of mine but ive learned ALOT by researching the different types of kernel architectures. Nothing really geeks me out like those topic, but not for everyone.

A fabulous free course exists on these topics:

u/solid7 · 2 pointsr/learnprogramming

Design patterns are simply canned OOP designs for commonly encountered forms of different problems. Design Patterns is a seminal text. It's worth pointing out that design patterns are not a gospel for developing software, but you will inevitably run across some of them and should be able to recognize a given design pattern when you see it.

u/pmjones · 2 pointsr/PHP

That's what I get for being snarky. ;-)

There's another excellent book called Design Patterns that predates the Uncle Bob one, if you'd like to learn some history on the pattern.

u/bridgesro · 1 pointr/learnprogramming

I don't know of any others from personal experience that I can vouch for. A quick search on Amazon returned this book, which has good reviews and might be worth looking into.

u/cdrootrmdashrfstar · 1 pointr/learnprogramming

Most remember it purely through repeated use. You honestly only need to know the following about any data structure or algorithm:

  1. Where it's typically used (Check out this Stack Overflow post for examples of what I'm talking about)
  2. Advantages and drawbacks (where/when it's slow, where/when it's fast)
  3. The general, broad information about it (that linked-lists are nodes with pointers to other elements of the list, forward/back pointers, etc.).

    Here's a good google search to use: stack overflow <insert-data-structure-or-algorithm-here> applications

    That should return a good list of links which should provide further information about whatever you're searching. Don't feel bad to google information, that's much better than attempting to rote memorize information.

    Also: here's a good book on object-oriented design that I'd recommend which covers typical design patterns.
u/Noctrin · 1 pointr/learnprogramming

In terms of books, i think this is all you need. Read the intro, and do as it says, don't memorize it, just understand the ideas behind the concepts and come back to them when you need them.
> how do you avoid forgetting rarer patterns, so you can still use them in new designs?

I wouldn't worry about that. You should not memorize the patterns, just know them and understand them. Understanding them comes with practice, use them enough and you start to see why this is good. It's like formulas in math, at first you memorize them, eventually you understand them, eventually you can derive them.

Same idea with patterns, once you have enough experience and practice with them, you don't have to worry about the lesser used ones since you will probably have some notion of it. Just read what the structure/goal behind it is and everything should come to you naturally.

Depends what industry you work in, game design will employ other patterns more often than say building some saas web app.

But as long as you know the major ones well, the rest tend to be variations or extensions. Like Factory and Delegator. Delegator is essentially a Factory.

Factory is one you should know, singleton, mvc, facade etc...

u/yalogin · 1 pointr/learnprogramming

Crap! I just ordered this book from amazon. Had I known about this free book I would not have.

u/DEiE · 1 pointr/learnprogramming

Design Patterns is the de facto standard, although Design Patterns Explained is probably better as an introduction.

u/specialpatrol · 1 pointr/learnprogramming

Reading up about design patterns will give you some more abstract ideas about how you might construct programs, particularly object oriented. This book's a bit of a bible in that regard.

u/yash3ahuja · 1 pointr/learnprogramming

That's not what I meant, sorry if I came off that way. My point is, you can read all the books you want -- but if you don't supplement it with code you write, they're just concepts. Even if you're not writing code, you still should be looking at pseudocode or example code to see how it's implemented. Talking about something is easy -- programming it is hard. What people say when they say to design first, they mean to lay out your program, your APIs, and everything else ahead of time. This is part of professional software development. In order to get to that step though, you're going to have to program. You don't recognize good OO or game design by just reading a book.

Regardless, for a good OO-book, check out:

For a good book on game engine design, check out:

If you want just game design and setup, there are more than enough resources at /r/gamedev.

Also, make sure to supplement everything with code you yourself write, or else nothing will stick.

u/dnk8n · 1 pointr/cscareerquestions

Can you suggest a website? Is this an example of what you mean? Or could you recommend a book? Is this a good example?

u/mlester · 1 pointr/programming
u/cynoclast · 1 pointr/

Design Patterns (Head First).

It's the "gang of four" patterns covered in a somewhat silly way to help you learn it. Teaches you some very good stuff.

I'd get the gang of four book for a reference, but get the Head First one to learn them first. It's not precisely pure OO, but it teaches you concrete ways to apply good OO practices, such as (the most important one IMHO) favoring composition over inheritance.

u/tyriku · 1 pointr/gaymers

100 Rogues didn't require anything fancy. I tried using some AI algorithms that sounded cool, but if / elses served the design way better, once they were organized. If you're looking to learn how to turn the basics into larger projects, I'd read up on design patterns.

The bible:

90% of the heavy lifting in 100 Rogues is a combination of Command and Observer patterns from that book.

u/Woolbrick · 1 pointr/programming

Gang of Four; an industry nickname for the four authors who wrote this book

u/bscit · 1 pointr/gamedev

Coming from a programming perspective, I would be happy with this book, Design Patterns by The Gang of Four (

It's more programming related but still very useful for game developers.

u/koko775 · 1 pointr/IWantToLearn

This is THE reference on OOP patterns. And I mean *THE* reference: Design Patterns

I highly recommend it.

u/ChrisFingaz · 1 pointr/learnprogramming

Not sure what language you are working in, but if it's an OOP then this book is father of code design. You can surely find something similar that's specific to whatever language you are working in also:

Make sure you comment really well and use naming conventions that make sense. Read about encapsulation, loose coupling, and inheritance. I just make sure you continue thinking about it until it becomes second nature and you have solid habits.

It's not even for a team thing, it's even for yourself. Eventually you'll go back to an old program and realize you have no idea what's going on.

EDIT: accidentally a word

u/ServerSimulator · 1 pointr/Unity3D

>mostly because you need to be good at a lot of mathemtics, is this true?

This is primarily for algorithms. It's pretty easy to be good at math, the hardest part I find for people who program is that they often don't think "outside the box" in breaking their program down.

I and others recommend programming in C#. You should be able to get off the ground with the following resources:

This list is for programming in general:

u/gevvvvv · 1 pointr/PHP

I've been trying to read everything and anything that interests me. You probably need a reading list of some sort. One book I can recommend right now is Design Patterns: Elements of Reusable Object-Oriented Software.

u/wfalcon · 1 pointr/learnprogramming

Design Patterns is a classic textbook on the subject.

Unfortunately, I don't know any good free resources.

u/apieceoffruit · 1 pointr/learnprogramming

"Design patterns" are the function use of oop so from a learning perspective I would suggest starting there (assuming you understand the fundamentals of programming of course)

I loved head first design patterns but the GoF book : Elements of Reusable Object-Oriented Software is pretty awesome albeit a bit heavy for learning.

u/Gankbanger · 1 pointr/learnprogramming


  • Code Complete 2. It is language agnostic BTW, most recommendations and guidelines apply to several languages, if not all. I would definitively start by this one if you are a beginner. The lessons from this book will help you for the rest of your career.

    Object Oriented Programming (OOP):

  • Applying UML and Patterns. In my opinion the best book on UML in the market. Excellent illustration of step by step process to getting an idea from concept to code while thinking Object-Oriented. Just keep in mind the book has some embedded propaganda for IBM's Rational Unified Process(RUP). OOP works just as well outside the RUP; i.e.: using agile methodologies.

  • Design Patterns If you are only starting now, save this book for later. It covers more advanced design subjects. Read this one when you are already VERY comfortable with OOP.

    EDIT: People who are downvoting this are doing you a disservice out of ignorance. You must read Code Complete 2.
u/thesircuddles · 1 pointr/learnprogramming
u/transt · 1 pointr/

we use the whiteboard for that. until he can read this:

and k&r on his own, I will be teaching him

u/chitraketu · 1 pointr/DesignPatterns
u/phpeter · 1 pointr/golang

Is this the book, "Design Patterns", that you were referencing?

u/Truth_Be_Told · 1 pointr/C_Programming

First note that Career/Job/Market is quite different from Knowledge/Intellectual satisfaction. So you have to keep "earning money" separate from "gaining knowledge" but do both parallely. If you are one of the lucky few who has both aligned in a particular job, you have got it made. Mostly that is never the case and hence you have to work on your Motivation/Enthusiasm and keep hammering away at the difficult subjects. There are no shortcuts :-)

I prefer Books to the Internet for study since they are more coherent and less distracting, allowing you to focus better on a subject. Unless newer editions are reqd. buy used/older editions to save money and build a large library. So here is a selection from my library (in no particular order);

u/liaguris · 1 pointr/learnprogramming

Yeah I have read around 70%-80% of all YDKJS books combined .

By the way just in any case you find anything interesting and helpful (but for also copy pasting this list in the future) here are the books-site tutorials-docs that I am reading-have read-plan to read-follow :

web dev road map


css in depth (manning)

eloquent js

YDKJS (all books)

HTML5 for masterminds

dom enlightenment

high performance images

web performance in action

reliable javascript

building progressive web apps

http: the definitive guide

learning http 2

cracking the coding interview

javascript data structure and algorithms (be careful,not a good choice, it has a lot of mistakes but I find it concise)

professional git

vs code docs

Using SVG with CSS3 and HTML5

Interactive Data Visualization for the Web

refactoring ui

figma docs

react docs

redux docs

vue docs

webpack docs

clean code

design patterns

web components in action

Inkscape: Guide to a Vector Drawing Program

and many more to come .

u/jj2parkie · 1 pointr/cscareerquestions

I think it depends on your location. If you live in or a commutable distance to a city with a strong technology sector, they will be quite a bit of companies willing to hire an high school level intern.

For example, a friend of a friend got an internship after graduating high school for the summer in the city he lives. I live outside the city and I am taking a year off before university because I got sick in the summer. I'm better now but all the companies near me are kind of old fashioned and they don't accept interns after a lot of cold calling; my calls and emails get sent to their HR manager, and they don't feel like giving me a chance. Also the benefit of an internship in the city for him was that he used pretty modern web development stuff.

As a high school intern unless you find a research group, you will highly unlikely use R. You can probably do front-end web development, so learning HTML, CSS, JavaScript, Jquery, and the Bootstrap framework would be awesome. If you don't want to do front-end web development, you really have to market yourself and make sure you are competent in Python if you want to use Python.

As a person who graduated high school last year and is taking a year before university to recover from an illness, I have to compete with other university students of various years who even the freshman have some sort of qualification as a candidate for a bachelor of applied science or math degree which tells the potential employer the applicant is knowledgeable. If you want to be competitive with the freshman or maybe the sophomore students, you really need a good GitHub portfolio which shows you are knowledgeable as them.

For example, in my GitHub portfolio, I have an Android application (GitHub and Google Play). In this small to medium sized application (35, 000 lines of code), I show I can use a version control system and a bug tracker by using Git and GitHub, respectively. Furthermore, in the bug tracker, I show I can debug by showing results of me using an allocation tracker, a heap dump analyzer, a GPU rendering profiler, and the like. In the actual source code, I show my experience with Java. But more importantly, I show I can implement an architectural pattern like Model-View-Presenter (a deviation from Model-View-Controller), some design patterns like wrappers, singletons, mappers, adapter, presenters, contracts, providers, and factories, and design an API which performs network requests, database queries, and file input and output. In the source code, I try to apply as much as I can from reading, Effective Java (2nd Edition), Clean Code: A Handbook of Agile Software Craftsmanship, Design Patterns: Elements of Reusable Object-Oriented Software, and Introduction to Algorithms while I get acquainted with reading Software Engineering: A Practitioner's Approach. I still need to try to utilize TDD and Agile practices; I read about them, but I never tried them out.

I think if you have a GitHub portfolio with project(s) of a good size that shows a lot of computer science and software engineering concepts, you will be ahead of most freshman students whose only projects might be a small class project in their Intro to Java class which all their peers did.

Currently, the application has around 5,000 downloads in about a month with 4.4 rating to place it 5th in its specific category above 4 stars on Google Play:; it took about a month and a half. However, every time I send my resume to a local company outside the city for an internship, I get no response. I'm going to a Career Fair at a friend's university in the city on Friday, so I'm a test my luck there; they have quite a few recruiters for mobile application interns, and one company develops a full stack product and service whose mobile applications kind of match mine. Overall, it's feasible if you are near a city, willing to commute, and can prove you know as much as a freshman student who they could hire instead.

u/phaggocytosis · 1 pointr/webdev

How about a new language? Or writing software rather than web stuff?

After doing webdev for a while I got in to offline Java (software) development. Aside from helping me tighten my grasp on real OOP, it also caused me to shift/alter some of my design patterns. Java itself can be extremely cumbersome to write, but the process of doing so definitely made me stop and re-think exactly HOW much I want to leverage the flexibility of other languages.

Writing Java also lead me to read books, from which I took lessons I could apply to other languages. These books in particular were helpful:

Obviously I'm just using Java as an example. If you already write Java, or feel great about your understanding of OOP, perhaps try a functional programming language? Lisp(Clojure)? Scala? The performance of some of these languages is really wild, and I'd think it would be possible to leverage their speed when working on large SAAS projects.

Anyways, to each their own. Obviously the other comments here have plenty of good suggestions. I know I certainly didn't regret getting familiar with SASS. And I could probably stand to spend time forcing myself to get more proficient with my editor. Right now I use Sublime Text 2, and I could either make sure I'm using all the proper key binds for traversing/manipulating text OR just go boss mode and make the switch to vim. Or even bite the bullet and use an IDE (

Best of luck!

u/AMAInterrogator · 1 pointr/learnprogramming

Interview Cake

It is paid.

It is prepares people for coding interviews. Those will have the fundamental issues that you will need in your courses. It has pretty top notch for explanations and broad coverage. Many languages. High quality product. If you are having issues paying for it - maybe some of your coding friends might be interested in splitting the bill. You'll have to work out how ahead of time. Definitely sign up for the weekly email and do the problem.


The other issue you may have is that you don't understand how the code fits together. Specific lack of understanding on how the design patterns work and fit together into architectural patterns.

Design Patterns: Elements of Reusable Object Oriented Programming

There are less than 30 of them. You should know them by pseudocode. Know which ones apply to which types of languages. It might take you awhile to really learn them. Use Anki to help review them on the toilet.


The other aspect is software architectural design patterns. I don't have a book that I would recommend for that one. Not because I couldn't find one, I just haven't reviewed enough literature to point you in the right direction. There might be 20. There might be less.



u/tsredd · 1 pointr/learnprogramming

Design Patterns: Elements of Reusable Object-Oriented Software (Gang of Four / GoF's book) is the bible of OO design pattern.

You can also find info here:

You can easily find info / samples / illustrations of the various design patterns if you just Google their name one-by-one though.

u/GeekGoesRawr · 1 pointr/compsci

You probably don't need extensive knowledge of data structures for mobile apps, but I ALWAYS encourage learning data structures! Knowing what structures are available and when to use them is a bit like being a programmer super-hero and one of the things that really sets apart the self-taught hackers from the top tier engineers and scientists.

It's not a course, but I always love to plug my professor's book Open Data Structures. He's made it freely available in many different languages with code samples in multiple languages, and it's a really good read.

One thing I would highly recommend before getting into the mobile space, however, is looking into design patterns. The fundamental book on this is Elements of Reusable Object-Oriented Software by the Gang of Four, but there are some other ones I've found which are pretty handy. Game Programming Patterns is freely available, but it is a bit domain specific. It really nicely details a lot of patterns, however. JavaScript Design Patterns also really nicely details them and is also freely available.

u/Vorzard · 1 pointr/java

You mentioned Robert Sedgewick. His book, Algorithms and his online courses are highly recommended. And he uses Java in them.

For object-oriented design the Head First books are great. It also worth to have the classic book Design Patterns: Elements of Reusable Object-Oriented Software.

I also recommend the books Code Complete, and Clean Code, they are great.

u/VerticalDepth · 1 pointr/learnprogramming

CompSci covers a wide range of subjects, many of which won't be that relevant to you. When I was at Uni my classes covered:

  • Algorithms
  • Functional Programming
  • Architecture and Design Patterns
  • Ethics, Professional Issues
  • Artificial Intelligence
  • Compilers and Programming Language Design
  • Data Structures
  • Database Systems
  • Networked Systems
  • Operating Systems
  • Discrete Mathematics
  • Low-Level Systems and Hardware

    This list isn't comprehensive, but covers most of the main points. For your job, you can happily ignore most of that core.

    I think you'll want to focus on with the highest priority:

  • Design Patterns (Book Suggestion)
  • Algorithms (Book Suggestion)

    Warning: Algorithms is a heavy and dry book. It might not be a good recommendation for a beginner to be honest.

    As you're interested in Data Science, you're already off to a good start with R and Matlab. Python is fine but has some issues that don't make it ideal for large-scale data processing. The good news is that once you've got the hang of Python, you can learn another language much easier. I think it's worth noting that R is quite obtuse in my experience, so if you get your head around that you're doing quite well.

    But I digress. You're also going to want to learn about data structures, networked systems and databases, especially if you want to work with "Big Data". I think thought that your best starting place here is learning how to code. With that under your belt along with your math degree, everything else should be easy enough to learn on a case-by-case basis.

    Source: Masters & PhD in CompSci subjects. Good luck, and feel free to PM me if you're interested in a mentor for this. With a better understanding of your position, I could probably help pare down what you need to study to more specific subjects.

    PS: Assuming you're at Uni, your library should have both books I have suggested.
u/grumpieroldman · 1 pointr/learnprogramming

Design Patterns is a land-mark work published in 1994 that captures some recurring, useful object-oriented designs.

u/DeliciousSkooma · 1 pointr/Cplusplus

Sorry but there's no cheat sheet and no reasonable way of making one. C++ is a rather large and complex language laid atop C, which is effectively laid atop an assembly language, which is compiler manufacturer and target platform dependant.

The best way to learn C++, or any programming language for that matter, is to use it, learn from your mistakes, and of course researching and reading everything you can. And of course, have fun with it!

Many popular books exist covering C++ things. Here are a couple good starter ones, in my opinion:

u/ReleeSquirrel · 1 pointr/gamedev

First Advice! Don't listen to high school guidance counsellors.

You require certain high school courses to qualify for College or University programs. What you want (ideally) is a 3 Year University Bachelor's Degree in Computer Science with a Minor in Game Development. Figure out which schools you're interested in and what they require for admissions to their programs.

You're probably hoping to start making games now though, so I'll give you some advice on that.

Try to get a copy of this book:

It's kind of a heavy book, both figuratively and literally, but it'll teach you everything about how a video game works. Even if you're not going to be building this or that part of a game, it's important to know how it all works and fits together.

This YouTube Channel Extra Credits has a lot of great video articles on game design and development, and links to other channels.

You can find a ton of guides on YouTube for computer programming, game design, 3D modelling, music, etc. The key word to search for is Tutorial.

Once you've learned how to program computers, you should read this book to learn how to program computers well: Design Patterns: Elements of Reusable Object-Oriented Software

It's a pretty old book, but that's because nobody has had reason to update it; it's just that good. That said, a smart fellow released a free web-based followup book for Game Developers here:

If you want to focus on Game Design I'm a big fan of Raph Koster so here's his book too:

I guess the rest is up to you. Any specific questions?

u/jacobisaman · 1 pointr/ISTJ

If you finish up the other books, you could read Design Patterns and The Pragmatic Programmer. There will be some overlap with the first two books I mentioned, but I think it can be helpful to read about the same topics from different points of view. I would probably read Clean Code and The Pragmatic Programmer straight through. The other two can be used more like reference books. Although, be sure to practice the design patterns you learn from the reference books.

There are programming exercises that you can use to practice patterns. Look up coding katas and see what you can find. Start with Gilded Rose. There are multiple ways to refactor this code, so it's a good one to practice. Here's another one.

u/autisticpig · 1 pointr/Python

If you were serious about wanting some deep as-you-go knowledge of software development but from a Pythonic point of view, you cannot go wrong with following a setup such as this:

  • learning python by mark lutz
  • programming python by mark lutz
  • fluent python by luciano ramalho

    Mark Lutz writes books about how and why Python does what it does. He goes into amazing detail about the nuts and bolts all while teaching you how to leverage all of this. It is not light reading and most of the complaints you will find about his books are valid if what you are after is not an intimate understanding of the language.

    Fluent Python is just a great read and will teach you some wonderful things. It is also a great follow-up once you have finally made it through Lutz's attempt at out-doing Ayn Rand :P

    My recommendation is to find some mini projecting sites that focus on what you are reading about in the books above.

  • coding bat is a great place to work out the basics and play with small problems that increase in difficulty
  • code eval is setup in challenges starting with the classic fizzbuzz.
  • codewars single problems to solve that start basic and increase in difficulty. there is a fun community here and you have to pass a simple series of questions to sign up (knowledge baseline)
  • new coder walkthroughs on building some fun stuff that has a very gentle and friendly learning curve. some real-world projects are tackled.

    Of course this does not answer your question about generic books. But you are in /r/Python and I figured I would offer up a very rough but very rewarding learning approach if Python is something you enjoy working with.

    Here are three more worth adding to your ever-increasing library :)

  • the pragmatic programmer
  • design patterns
  • clean code

u/roastingapples · 1 pointr/cscareerquestions

Does anyone know what would be best to prepare me for interviews for new-grad interviews that'll probably open during Fall 2019? I don't think it's that important to have side projects as I have internships/experience under my belt, so I just want to be studying/enhancing the foundation I have. I currently own CTCI and The Algorithm Design Manual. I'm planning on getting the Gang of Four Design Patterns, but I'm not 100% yet. Anyone know any good resources for System Design? Any feedback on how should approach this preparation? I know it's super early, but better early than late.

u/UnityNorway · 1 pointr/gamedev

I'm surprised Design Patterns: Elements of Reusable Object-Oriented Software isn't on the list. Old (1994), but gold.

u/eziroth88 · 1 pointr/learnprogramming

Try Pretty fun in short bursts. Books are still good resources. Try out Do you like playing games? Try making a crude remake of the simplest game you enjoy. Maybe a poker clone...then add an AI.

u/DevIceMan · 1 pointr/cscareerquestions

I've heard good things about Design Patterns: Elements of Reusable Object-Oriented Software and Head First Design Patterns. Haven't read either yet myself, but they're on my todo list.

u/tmthyjames · 1 pointr/Python
u/jrochkind · 1 pointr/ruby

The game piece example is about using singleton to, yes, conserve memory, with simple data types. For instance, you'll note that ruby itself, analogously, uses it with integers. 101 is always exactly the same object in ruby (which is necessarily immutable for that reason; in general, singletons that have any mutable state at all are going to give you nightmares, especially under concurrency). (You can verify this checking 101.object_id, always the same for any 101 anywhere in a program execution. This is not true for string "101", which is of course also mutable).

In the "Gang of Four" book, which introduced the notion of "design patterns" in programming as well as the "singleton" pattern specifically -- I think this particular pattern would actually be identified as the "flyweight" pattern, rather than "singleton", although it's implementation might in this case be in terms of singleton.

I probably wouldn't be likely to actually implement a chess game that way. I think the "flyweight" pattern is pretty specialized in contemporary programming, where RAM is a lot more bountiful compared to when the GoF was writing. The times you need to conserve RAM this way and it's worth the added complexity are probably rare (although probably not never ever encountered).

u/jbacon · 1 pointr/javahelp

Here's pretty much your most basic flow for problem 3:

  1. Find the square root of your target number.
  2. Starting at 2, check if target % loop counter == 0
  3. If yes, store as a factor and divide your current target by that number. Use that as the new for loop end condition. Find the complement of that factor, and store that as well.
  4. Go through all the divisors you found and test if they are prime.
  5. The largest remaining number should be your solution.

    To troubleshoot, use a debugger (Eclipse's builtin is nice). If you feel it's taking too long, break the program's execution and check its state. Is the loop counter about where it should be? Are the found divisors plausible? Is the loop end target plausible? Set a breakpoint on the first line inside the loop and keep stepping through (either one line at a time if you like, or just hit 'resume' and it will break again at the top of the next loop iteration).

    I learned Java throughout college, as it was the primary teaching language. Honestly, the best way to learn is just to WRITE CODE. Solve problems that you don't know how to solve. Invent random things that are useful to you. Your code doesn't have to be perfect when you're learning (and it definitely won't be!), and what is important is that you constantly look for ways to improve. I want you to look back on code you've written a year ago, and think that it's absolute crap - that will show that you are learning and improving.

    Somewhat counter-intuitively, the best resources are books! I'll list some recommendations below.

    Keep these principles in mind:

  6. Don't repeat yourself. If you're copying and pasting code, it is wrong. If there is not a single point of truth for each piece of information in your code, it is wrong. Find ways to keep your code clean and non-repetitive.

  7. Document everything. Comments - comments everywhere. Explain what ever piece of your code does. Explain what each method's arguments are, what it does, and what it returns. If you don't know, then that's a big red flag to reevaluate your design. If a bit of code is doing something complicated, write inline comments explaining what each bit does. All this is for future you - I can hardly remember code I wrote last week, let alone a year ago.

  8. Separation of concerns. Each piece of code should only work with what it is directly responsible for. UI code should deal with presentation. Application logic should deal with data manipulation. A persistence layer should handle any database or serialization of things. Keep your code loosely coupled!

  9. Design patterns. There are dozens of semi-formal patterns used to solve common problems in software. Learn to recognize these problems, when to apply these patterns, and how to modify them to suit your goals. See Wikipedia, or Design Patterns by the Gang of Four.

  10. Be pragmatic. What does your code really need to do? What is the minimum that it needs to accomplish, and how can you keep it extensible enough for future expansion? The answer to the last part is largely the previous points - well designed code is always easily changeable. The Pragmatic Programmer is another excellent book. It even comes with a handy summary sheet of its main points!

  11. TEST! Write lots of unit tests. Make sure that every piece of your program is tested to be correct. Every time you find a bug, write a test for it so it never happens again. If a piece is difficult to test, it may mean that it is poorly designed - reevaluate it. This is guaranteed to save your bacon at some point - you'll probably hate the work, but the safety net is invaluable. Being able to instantly tell if you program is working properly is invaluable when making changes.

    Once you start getting a feel for Java, which I think you might be already, Effective Java is the book. You probably won't need any other resource for Java itself.

    If you need help with something, Reddit is a great place, but Stack Overflow is the programmer's mecca. The best resource on the web for just about everything software, and their sister sites cover other topics, from IT/sysadmin to gaming.
u/Lord_NShYH · 1 pointr/sysadmin

As someone making the switch (I start my new Developer role later this month):

  • Learn software design patterns; especially from "The Gang of Four"
  • Learn a bit about algorithms and "Big O" notation and use this wonderful cheat sheet
  • Learn to think separation of concerns, and learn how to test code.
  • You had better know how to profile your code.
  • To help expand your mind, learn different programming paradigms. Tail recursion in functional programming is its own reward.
  • Never forget all of your lessons and paranoia as a SysAdmin. They will make you a Developer that Operations can easily get along with.
u/Tavataar · 1 pointr/learnprogramming

Gang of Four is the standard for design patterns.

u/PearlyDewdropsDrops · 1 pointr/learnprogramming

cant believe nobody has mentioned design patterns yet.

u/CodeShaman · 1 pointr/learnprogramming

Design Patterns is called "The Bible," also called the "GoF Patterns" aka "Gang of Four"

Some people like Head First Design Patterns as an introduction (it has better code examples), but if you end up wanting something more information dense/rich then try the GoF.

u/goozez · 1 pointr/learnprogramming

You might try to fit your work in design patterns ( start with the gang of four ;) ) and code the structure UML style.

Take one of your old projects and use umbrello (only for linux) to port it to UML. Check if you can make it more simple,better or fit in a design pattern. And don't go to the other edge -in this way of programming you get clean and organized structure but you need more time (and sometimes code) to get a result.

Also, get a task manager like taskfreak and write a todo list with deadlines.

And as dmazzoni advised: use github.

u/inopia · 1 pointr/programming

Personally I'm very partial to Design Patterns: Elements of Reusable Object-Oriented Software. I see Java more and more as a software engineering, rather than a programming language. You can do programming more effectively in Python/Jython or (J)Ruby, but Java for me still is king for developing type-safe, robust libraries and unit testing.

You might also want to read up on Eclipse or another decent IDE. Eclipse reduces the amount of monkey typing that all Java developers must endure dramatically with things like templates, getter/setter generation, delegate method generation etc. Since the editor parses the code as you type and keeps an AST in memory, refactoring support is excellent and you'll spend less time worrying about minor design issues when starting a new project. Code is compiled on the fly so startup times are minimal. It's also able to produce very descriptive and useful information about any errors you might have in your code (unlike GCC, for instance:)

If you want to know a bit more about how the JVM itself works, read The JavaTM Virtual Machine Specification, Second Edition which is online and free. It'll give you a bit more insight into why some crappy things are as crappy as they are (backwards compatibility with Java 1.1). Read books that are recent enough to include language features of 1.5 and 1.6, such as static imports, enums, generics, varargs and so on, and decompile some Java code to see how the compiler implements them.

u/silenti · 1 pointr/gamedev

While it's not specifically game related this book has been an excellent resource for me as far as patterns go.

Also, flyweight rox!

u/lg-j · 1 pointr/cscareerquestions


So many things in this book are immediately noticeable in many of the large frameworks. Model-View-Controller is a really common pattern.

Actually the biggest things to learn for me were testing related however. Test-driven development is an awesome habit to pick up - really changes how I design code.

u/MissMaster · 1 pointr/learnprogramming

I would focus more on deciding what you want to make. When you can make something that works, you're a programmer. When your code isn't brittle, is well commented/documented, is "clean" and other devs can understand and work with it, you're a good programmer.

So pick something you want to create and make it: a website, a simple program, a game, etc.

How to go about it? Once you have that thing you want to make, break it down into bite size tasks and start tackling them one at a time. First, you'll need to figure out what language and libraries you need (or want) to use. Then set up your dev environment and get a "Hello World" example to work. Then just start building piece by piece. Once it works, make it work better (i.e. refactor it).

I use a bunch of resources to be a better programmer:

  • dev blogs (a google search for "best <insert your field here> blogs" should give you some good ones

  • books for the basics. I can particularly recommend Code Complete 2, The Pragmatic Programmer, Head First Design Patterns, Design Patterns: Elements of Reusable OO Software and Algorithms in a Nutshell

  • Tutorials. I love a good tutorial. The trick is to find one written by a professional (usually on a blog you trust or from a tutorials site that vets the content, like tutsplus). Unfortunately, any asshat can throw up shitty code and call it a tutorial, so be careful googling and look at the comments first to look for people calling out issues. As you get more experience, you'll be able to spot 'code smell'.

  • pair programming. I hate pair programming. I instantly lose my ability to type or form coherent thoughts when someone is lurking over my shoulder. I am constantly terrified that someone will think I'm stupid. But it works.

  • fellow devs. Nothing really replaces direct communication with another dev. Find someone or a community online or at work who you are comfortable with. Someone you can go to when you're stuck or don't get something. The difference between needing babysitting and needing help is having specific questions. Instead of saying "I don't understand x", approach them with a more specific question like "I'm trying to get comfortable with closures so I set up a simple counter, but instead of counting to 10, I get 10 printed 10 times, can you help me spot where my error is?"

    I hope that helps.
u/xnoise · 1 pointr/PHP

There are a ton of books, but i guess the main question is: what are you interested in? Concepts or examples? Because many strong conceptual books are using examples from java, c++ and other languages, very few of them use php as example. If you have the ability to comprehend other languages, then: definetly a must read. Beware not to memorize it, it is more like a dictionary. It should be pretty easy to read, a little harder to comprehend and you need to work with the patterns presented in that book. - has already been mentioned, is related directly to the above mentioned one, so should be easier to grasp. - one of the most amazing books i have read some time ago. Needs alot of time and good prior knowledge. - another interesting read, unfortunatelly i cannot give details because i haven't had the time to read it all.

u/Tjinsu · 1 pointr/cscareerquestions

Lots of books and videos cover it well. You can find lots here also:

Also this classic book many people recommend:

u/rolldawg · 1 pointr/newzealand

My advice is:

  • Do self project and make a portfolio on git. You are more likely to be hired employer's know you strive to learn something knew everyday.
  • If you can, read this book Design Patterns Its old but is gold. Its an abstraction of patterns commonly found on any company's code base.
  • Don't assume you know everything and anything. Employers tend to like people who admit it when they don't know anything. Nobody likes a "know it all"
  • Learn how to google. Stack overflow will be your best friend
  • Learn how to debug someone else's code
  • Be friendly and show to interviewers that you are approachable and open. The IT world is not a one man job. You will be working and be part of a team.
  • Learn to be able to say/express how and what you think. You will need that skill to convey your thoughts to colleagues, especially to product owners / stake holders.
  • Don't assume you'll be making this kickass app/program/web service/database from scratch. Chances are, you are highly likely to be maintaining someone else's code.

    I was in the same boat as you 3 years ago. CS degree anddd thousands applying for the same position as me. Luckily i got a job in the end. Started applying 3 months before i finished my exam. Ended up getting a job straight after finishing my exams as a junior software developer. :)
u/aahhii · 1 pointr/AdviceAnimals

Get an MS degree. I had a BA in Psych and went straight for MS in Comp Sci. Not every school will allow it and the ones that will will require you to take a couple of undergrad courses and pass them with B or higher.

That being said - if you still prefer to go the no degree route you're going to have somewhat of a tough time with interviews even though you may perform the job well itself. Most software engineering interviews revolve around things like how a hash map works and properties of binary trees - information you aren't usually going to get from the "build your own iphone app" type books. So I would recommend:

  • Read a book on data structures, in either Java or C++, and really understand Big O complexity analysis and be able to pick the right data structures/algorithms in common situations
  • Read this book. You don't have to understand it completely the first time through; but re-read every few years and come back to it as you gain experience.
  • Design your own web site which uses a database, user authentication, and looks nice on mobile browsers. Read through Google's SEO guide and optimize your site for search engines. Automate the deployment of your site. Write test for your site. Basically, treat your site like people used to treat the rusty Corvette in the back of the garage. Constantly take it apart and put it back together, making it slightly better with every iteration. Even when you get a day job keep working on the site in your spare time. If you do all of the programming and design work yourself, you can run a small site for free (Heroku has a decent free service tier).

    Good luck!
u/pooponastick · 1 pointr/cscareerquestions

This book reference gets overused, but Design Patterns was a change for me in the whole way I saw code. It's not easy to get through and some of the patterns take several reads for the lightbulb to go on, but once you get a design pattern, that knowledge stays with you through any OO language, not just C++. The patterns in the book are things that you run into all the time in programming, and that spidey sense of "I've seen this before" when you're working through the design of a problem is beyond valuable. Knowing what the patterns do, and more importantly, when it's appropriate to use them, is a key differentiator especially in C++ programmers.

Technically, for C++ specifically, knowing your stuff on memory management is a highly valuable. Not just how memory management works, but what are the best practices? Who is responsible for freeing the memory if a function creates a new instance of an object and returns a pointer to it? How do you know that all references to an object are out of use once an object is released from memory? (I saw smart pointers referenced before) When do you have to zero-init alloc'd memory and why? alloc, free, calloc, realloc, new, delete, learn all of that memory management stuff.

u/hell_0n_wheel · 1 pointr/Python

All I could recommend you are the texts I picked up in college. I haven't looked for any other resources. That being said:

This text is really only useful after learning some discrete math, but is THE book to learn algorithms:

This one wasn't given to me in college, but at my first job. Really opened my eyes to OOD & software architecture:

u/tragicshark · 1 pointr/dotnet

I own all of Robert C. Martin's books, except for UML for Java, as well as Martin Fowler's Refactoring (the white one), PEAA, DSL and Analysis Patterns. I also have Refactoring to Patterns, Code Complete and Design Patterns (aka go4) and a few others.

I would suggest Refactoring to Patterns is the one you are looking for, but that expects you have a working knowledge of what the patterns are already (likely with your experience though you may not know them by name). I don't think that is strictly necessary but it will help you understand why you might want do do things the way being suggested in the book. The examples are in Java, but they apply to C# just as much. His site is here: and he has the code up behind an online course / paywall (I have not looked into this).

In a greenfield environment, tdding up an application from a blank project Uncle Bob or Fowler's pattern books are probably better, but from the perspective of an existing codebase I think Kerievsky's Refactoring to Patterns and Fowler's Refactoring are best.

u/Silound · 1 pointr/dotnet

I find more often than not that patterns are rarely well represented in books; they are almost always delve too far into implementation specific details or simply gloss over any implementation details in favor of theory. Sometimes, all I want is an ELI5 about the pattern, and let me work the rest out for my codebase.

Books on principles of coding, however, are dime a dozen. One I like in particular is Adaptive Code via C#. It gives plenty of code examples (you can download the entire working solution projects from the website given in the book) and it does a fair job of covering several patters and gives specific examples of how they apply to the SOLID principles.

Of course, there's always Design Patterns: Elements of Reusable Object-Oriented Software. This book has been one of the programmer's bibles for the past 20 years. It is a more difficult read, since it is a more theory oriented book. One thing to note is that some of the design patterns discussed in the book have been rendered obsolete by aspects of some languages and frameworks, while a number of new patterns have come to exist based on those same languages and frameworks.

u/meheleventyone · 1 pointr/Unity3D

> Unity seems to be encouraging this weird hybrid style.

This isn't actually true, there are lots of weird implementation details but there is nothing weird or hybrid about Unity's design. It's just not a data-oriented ECS. The Unity pattern is a variation on the Composite Design Pattern from this book:

u/rocketsocks · 1 pointr/askscience

Code every day. Work on as many little interesting projects as you can. If you don't know any languages I'd suggest starting with Python, there are a million different tutorials and resources online, so getting started shouldn't be a problem.

Add to that, read some books to learn about how software development projects work, different techniques, best practices, pitfalls, etc. Here are my recommendations on books: The Pragmatic Programmer, Refactoring, Code Complete (a bit dated, but still solid), Rapid Development (slightly mis-titled, it's a good overview of different development practices), The Architecture of Open Source Applications, and Design Patterns. Code as much as you can, be ambitious, be analytical and introspective about the problems you run into, and read and understand those books too. There's a lot more you'll need to learn to become a good developer, but what I've described will give you a very strong base to build on.

Oh, and if you don't already know discrete mathematics you'll need to pick that up. I'd recommend this book.

u/IronTek · 0 pointsr/programming

This one is one of the most (if not the most) popular book of C++ design patterns.

u/shivasprogeny · 0 pointsr/learnprogramming

If you didn't like the style of Head First, the GoF book is a more formal option.

u/StoneCypher · 0 pointsr/programming

No, it isn't. Wikipedia is, like usual, because it's written by people who learned what MVC means from random frameworks that also get it wrong.

u/farox · 0 pointsr/csharp

Get the original book, at least skim it and remember the type of problems it helps you fix. You don't need to memorize it, but it also just helps thinking about software more abstract:

Also as you said, there are a lot more now. A lot of new trends came and went since then. But this is a really good foundation. On top of that you can read up on whatever is relevant for your projects.

u/somekindofsorcery · 0 pointsr/learnprogramming

I would assume digital design has to do with software planning, i.e. making UML diagrams and such. You will also most likely be expected to know the basics of design patterns, and you should check out this book.

u/LieutenantKumar · 0 pointsr/practicemodding


> Test plans - When you apply for QA roles, you'll almost certainly be asked "how would you test ____?". The correct answer is to be methodical. Don't just spew out a stream of test cases as you brainstorm them. Understand the different scopes (unit, functional, integration, maybe end-to-end) and what the goals of each is, and how they differ. Understand that there are different areas of testing like boundary, happy path, special cases (null, " ", 0, -1), exceptions, localization, security, deployment/rollback, code coverage, user-acceptance, a/b, black box vs white box, load/performance/stress/scalability, resiliency, etc. Test various attributes at the intersection of a compenent and a capability (borrowed from the book How Google Tests Software), and I believe you can see a video that goes into this called The 10 Minute Test Plan. Understand how tests fit into your branching strategy - when to run bvts vs integration vs regression tests.

> Test methodologies - Understand the tools that make you an efficient tester. These include data driven tests, oracles, all-pairs / equivalency class, mocking & injection, profiling, debugging, logging, model-based, emulators, harnesses (like JUnit), fuzzing, dependency injection, etc.

> Test frameworks - Knowing all the tests you need to write is good, but then you have to write them. Don't do all of them from scratch. Think of it as a system that needs to be architected so that test cases are simple to write, and new functionality is easy to implement tests for. I can't recommend any books for this because it's something I learned from my peers.

> Test tools - Selenium / WebDriver for web ui, Fiddler for web services (or sites), JUnit/TestNG, JMeter (I have to admit, I don't know this one), integration tools like Jenkins, Github/Stash, git/svn.

> System design - As you're entry-level, this may not be a huge focus in an interview, but know how to sensibly design a system. Know which classes should be used and how they interact with each other. Keep in mind that the system may evolve in the future.

> Whiteboarding - Practice solving problems on a whiteboard. The process is more than just writing the solution, though. This is the process I follow (based loosely on the book Programming Interviews Exposed):

  • Clarify the problem - resolve any ambiguities, determine behaviors for special cases (throw an exception vs return null?). Look for gotchas (like if you're doing some string manipulation with overlaps)
  • Give a couple test cases to demonstrate your understanding of the problem, to make you think of other special cases, and because they want someone who's test-focused if you go into QA. Give a happy path scenario and a couple negative or special cases
  • Propose a solution - do this verbally, and give its runtime complexity (and less importantly, its memory usage). If the runtime complexity is bad (polynomial, exponential), then say so and think of a better solution (there will almost certainly be one)
  • Implement the solution - verbalize your thought process while doing so. If you don't know something, say so. The interviewer will likely help you out without penalty. Listen very carefully for clues, because the interviewer will be giving them. Really understand everything the interviewer says, and understand his motivation for saying it. If you see potential bugs, say so ("I want to be careful that I don't go out-of-bounds in the last iteration of this loop").
  • Debug the solution - walk through it as if you're a debugger, using the happy path test case that you made earlier. Oftentimes, the interviewer will give you a test case with the problem. Use it - he probably selected it for a reason (the numbers are in an interesting order that will find the most bugs, for example).
  • Test the solution - Add to the handful of tests you gave earlier. Think about the different types of tests, and if they apply.


    > Learning to test:

  • How Google Tests Software
  • Guice, and another
  • Google Test Automation Conference
  • Netflix's Simian Army
  • Google Testing Blog
  • Hermetic testing
  • The Art of Software Testing (I've only skimmed it)

    > Learning to interview:

  • Programming Interviews Exposed
  • Programming Pearls

    > Learning to program:

  • Design Patterns (I'm embarrassed that I don't have more recommendations for this...)

    > Miscellaneous

  • Meetup
  • Inventing on Principle

    > What sort of skills should I really hone? I realize I gave you a ton of stuff in this post, so here's a shorter list:

  1. Read How Google Tests Software
  2. Understand dependency injection
  3. Understand unit, functional (use hermetic environments), and integration testing
  4. Understand mocking (Mockito's a good one for java)

    > Examples of projects that make you look valuable

  • Refactoring product code to be Guice-friendly
  • Tool to profile method calls simply by adding annotations
  • Tool to automate bug filing/updating/closing - assign to the right person, re-activate when they repro, give good steps, close when they're fixed and don't repro
  • Tool to automatically quarantine flaky tests that aren't caused by product bugs
  • Aggregation of distributed logs into central, indexed location (I didn't write the solution, just did the work to integrate an existing one (Logstash/Kibana))
  • Automatically display the picture of the team member who checks in code with the highest coverage (I didn't do this, just something cool I read about)
  • Tool that logs messages with contextual information, so for example you can see all messages associated with user 123
  • Tool that captures inter-server traffic, associated with the user-request
  • Tool that provides metadata about test cases in your web proxy