Here are some things I (and I know others) have struggled with. I think the web is exploding with resources and information, so I don’t necessarily think we need to explain what a prototype is. There’s better places elsewhere to learn things about UX, but I think we could provide some good resources for not just people new to UX but everyone else too. I’m coming at this from what I wished I would have access to when I was trying to get into the field. I know that /u/uirockstar has some good walls of text that probably should be included as well. Feel free to suggest any changes to what I have here.

I really want to begin a career in UX/UI. What do I do?

Well, first it’s important to know that UX and UI are not synonymous. While many job postings combine them, UI is a subset of UX, just as research and information architecture are. UI is still important and if you can do both, you do increase your value. While many see UX as a research field at its core, the UX/UI title implies that it’s only about creating pretty things.

The first step is learning more about the field, which brings us to…

What kind of education do I need?

If you are still in school, there are more places recently that are offering courses in human-computer interaction. You can even try to create your own internships. There are very few UX specific schools, though they are starting to pop up, like Center Centre and General Assembly.

Yeah, yeah, that’s great. But I already graduated, so where do I start?

Any focus on people or technology can act as a solid foundation for learning UX. Because there has never been a set entrance path into the field, UX roles are filled with people from many different backgrounds. The most common degrees for those in the field though are design, psychology, communications, English, and computer science. link

There are a number of people in the field who are self-taught. There are tons of books, blogs, and designers (here are some helpful resources) which provide enough UX stuff to keep us all busy. When I first started reading about it, I quickly got overwhelmed because there was so much information available and most of it was intended for those who already had a pretty good grasp on things. The Hipper Element’s crash courses in UX and user psychology are great places to get a fairly quick overview.

There are books like The Design of Everyday Things by Donald Norman, 100 Things Every Designer Needs to Know About People by Susan Weinschenk and Don’t Make Me Think by Steve Krug that make for great first books.

UX Mastery has a great eBook for getting started, appropriately titled Getting Started in UX. Kevin Nichols’ UX for Dummies is both very readable, yet detailed. You can even buy the eBook if you don’t want people on the bus to think you’re a “dummy.”

Lastly, Fred Beecher has a very extensive Amazon list of recommended UX books, depending on what area you are looking to learn more about.

Great. I’ve read a whole bunch of stuff and have a pretty good idea how UX works. Now how do I get someone to hire me so I can gain experience?

Hey, easy there. While, yes, there are lots of UX jobs out there, very few are entry level and not many employers will hire someone who has only read about it and not actually done it. You can’t get a job without experience and you can’t get experience without a job. I know. Frustrating, right?

You have to prove that you can do it. One way to do this is site redesigns.

Go find a website that lacks in it’s user experience and figure out how to fix it. Maybe it’s a small business down the street from you or maybe it’s a feature on eBay you think could be better. Redesigning sites is a good way to practice a process and make mistakes on your own time. If you can involve the owner from that small business down the street, that’s even better because then you can get a sense of the customers (users) that you will be designing for.

Once you have done this, you have (some) experience! Start a portfolio and add to it!

But I have a resume. Why do I need a portfolio?

Resumes are great. But resumes won’t get you a job starting out. It’s a million times more effective to show potential employers what you have done, rather than showing them a resume showcasing that you are a team player and proficient in Microsoft Office. But you should still have a resume that outlines your UX skills.

But I’ve never worked in UX! What should I put on my resume?

You don’t need to put all of your old jobs on your resume if they are unrelated to the field. Most places still want to see some work history so they know you haven’t been living in a cave for the last four years, but they don’t care about how you sold vacuum cleaners or trained circus horses. Maybe you can relate some crossover UX skills to your previous work.

Back to portfolios. They are a lot like elementary math class in that you want to show your work. Potential employers are much more interested in how you made a design decision rather than the final result. If your portfolio just has a bunch of fancy wireframes, that doesn’t tell them how you took specific personas into account and you are simply showing them something that looks pretty. And just because it looks pretty doesn’t always mean it makes sense.

Okay. I have a portfolio with a few unsolicited site redesigns in it.

Congratulations! But I have some bad news. Are you sitting down?

No one wants to hire you yet. You haven’t worked on any “actual” projects that showed how your UX skillz helped a business. I know I suggested you do site redesigns to get practice and you should because that is work you can take to a nonprofit or another small business and say, “here are some trial runs that I’ve done that prove I know what I’m doing and now I can help you for free in exchange for adding it to my portfolio.”

They’ll probably be skeptical and say, “hmmm… I don’t think my website needs this newfangled user experience you speak of and—wait did you say free?”

You both get something out of it and you’re doing it pro bono, which relieves you the pressure of making one tiny mistake. (There is a great site called Catchafire that matches non-profits all over the country with people looking to donate their time and skills.)

Once you have a portfolio displaying your work and some experience, start applying! But there is one more aspect that goes into getting hired and that is the people who will hire you.

Ugh, but isn’t networking just using people for my own professional gain?

I had this same mindset and it probably delayed my entrance into the field. I wanted to rely only on the quality of my work and trusted the rest would follow. I avoided networking and meeting people in the field because I didn’t want it to seem like I was only mooching for a job.

But the fact is people are altruistic in nature and like helping others. Many people also enjoy talking about themselves, and those are the two main principles of an informational interview. You’ll also find that people are excited to help others get started since they remember how difficult it was (see: this blog post).

It wasn’t until I started getting those informational interviews and talking with people at UXPA and MeetUp groups that I learned another side of UX, but also got more familiar with more hiring managers or those that knew them. Whenever possible, people will hire those they know and like. Until you get out and start shaking hands and kissing babies, you will be just another faceless name in a stack of resumes.

Meeting with recruiters/staffing agencies is also a good route as they make money by finding you a job, so they have a vested interest in giving you constructive criticism.

I've heard that you have to live in a big city to get a job in UX.

Move. Just kidding. But while it’s true that larger cities like New York, San Francisco, and Seattle are full of opportunities, there are plenty of other places around the country that have jobs. Here are the top 20. If you live in a tiny city, expect a tougher time finding a position.

Okay, I got an interview. How do I not mess this up?

Some great advice is to go all UX on your preparation and treat the interviewer like a user.

.......to be continued.



Blogs:

• Boxes and Arrows
  
• The Hipper Element
  
• UX for the Masses
  
• UX Mag
  
• UX Mastery
  
• UX Matters
  
• UX Movement
  
  
  Other:
  
  
• uxdesign.cc: Methods and Deliverables
  
• CogLode.com: behavioral and consumer psychology
  
• Good UI: Best practices shown in a “don’t do this, do that” way
  
• UX Mastery’s HUGE list of resources
  
• UXarchive: iOS user flows
  
• iOS Human Interface Guidelines

I can definitely relate, this sounds just like me last year! I've done things the hard way and it took me 5x longer. I also prefer screencasts to books. I always need to create a project to solidify those fresh skills, otherwise they'll be gone in a month. Also tutorials for things like Backbone assume you know how to use jQuery, Underscore, and things like REST, and JSON responses... this can quickly get confusing if your not familiar with all of these. My largest regret is not building enough practice apps in the last year. I really should have applied more by doing, instead of staying in the theoretical world.

Here are some insights that i've made and the courses/tuts/projects that helped me the most:

Learn the language first:

• https://tutsplus.com/course/javascript-fundamentals/
  
• https://tutsplus.com/course/object-oriented-javascript/
  
• https://tutsplus.com/course/advanced-javascript-fundamentals/
  
• http://eloquentjavascript.net/ If you feel you need more coverage of the same topics (interactive html like CodeCademy).
  
• Build something interesting, things like games seem to also challenge your programming skills at the same time. Something like Whack-a-Mole, Connect 4, etc... Don't worry too much about the looks, unless you want to practice that too. At this point you should be able to do basic dom manipulation, events, and basic logic.
  
• The tut-plus courses cost a little for a few months but they're really high quality... most of them also give you projects too.
  
  

  Set up a comfy environment
  

  
  Take some time to start optimizing your development environment, the Paul Irish explains it very well below, but some of the topics are a bit too advanced for now (modules, build tools, etc...).
  
  

• Javascript Development Workflow of 2013
  
• Setup a jshint plugin (~4min above), read the website/docs for all the options. http://www.jshint.com/
  
  
• A more entry level talk on setting up your environment Front-end Tools for the Young Developer
  
  
  

  Learn the native DOM and it's API
  

  
  

• http://domenlightenment.com/
  
• Create your own DOM manipulation library
  
• While this one is a book, it's small and has js-fiddle examples for every code block to try it out... i'm currently going through this and it's great! They have a free HTML version (not final edit) and a cheap softcover on amazon. This will make using jQuery much easier and less 'mysterious'.
  
  

  Learn jQuery
  

• https://tutsplus.com/course/30-days-to-learn-jquery/
  
• https://tutsplus.com/tutorial/jquery-anti-patterns-and-best-practices/
  
• http://fixingthesejquery.com/#slide1
  
• https://tutsplus.com/course/jquery-plugin-development-best-practices/
  
• Re-write one of your previous apps to use jQuery instead of vanilla.
  
• While I love vanilla, jQuery just saves time. Learn when you can easily not use jQuery to gain some easy performance.
  
  

  Read "The Good Parts"
  

  
  Though very cliche at this point, read through this classic. If you don't really understand it all 100%, make sure you hang on to it though as it gets better with age. Try and follow it as close as possible, then later feel free to break the rules. By then you'll know why you can break them.
  
  

• JavaScript the Good Parts
  
  

  Learn Underscore
  

  This is a great library that gives you a lot of cross browser ES5 features and features that should be in JS. Not a lot of tuts on this one, reading the docs and source helps a ton here.
  
  

• http://net.tutsplus.com/tutorials/javascript-ajax/getting-cozy-with-underscore-js/
  
• http://vimeo.com/60216668
  
• http://underscorejs.org/
  
• https://github.com/bestiejs/lodash
  
  

  Learn Backbone
  

  There are lots of these libraries but Backbone is the most popular and easiest to learn. Keep in mind this is a library, not an entire framework like ember. This means in a larger app you will essentially use Backbone to help build you own SPA framework for your app.
  
  

• https://tutsplus.com/course/connected-to-the-backbone/
  
• https://tutsplus.com/course/advanced-backbone-patterns-and-techniques/
  
• http://addyosmani.github.io/backbone-fundamentals/ Great book!
  
• Build a Todo app with backbone
  
• Build a backbone powered Reddit mobile web app, read the following posts for inspiration.
  http://cheeaun.com/blog/2012/03/how-i-built-hacker-news-mobile-web-app
  http://cheeaun.com/blog/2012/03/how-i-built-hacker-news-mobile-web-app_26
  
  

  Learn Node
  

  
  

• https://tutsplus.com/course/introduction-to-node-js/
  
• Build a command line app ( I built a scaffolding app to spit out my boilerplates, and a really janky language transpiler)
  
  

  General Front-End, Programming
  

• Baseline for front end developers
  
• So you want to be a front end engineer
  
• http://pineapple.io/wiki
  
• https://www.edx.org/courses/HarvardX/CS50x/2012/about
  
• I can't stress how helpful the CS50 course has been to me, even on the front end.
  
  

  Read a comprehensive JS book
  

  I really like Nicholas Zakas's book over the definitive guide. I find that he is able to tell more of a story and makes it easier for me to absorb.
  
  

• Professional JavaScript Development
  
• JS the Definitive Guide
  
• Re-read "The Good Parts", this should make much more sense than the first time you read it.
  
  

  Testing
  

  
  Make sure you're comfortable with everything before moving onto testing... this includes frameworks etc.. Learning testing will only slow down the learning process if you're not comfortable with the rest. Mocha is the newer test runner and is better with async. However, Jasmine is very popular and time tested. The "Lets code javascript" below is an awesome course. Don't let the first sections turn you off, they may seem tedious at first (integration server, etc...) so feel to skip to dom/browser testing and then loop back when testing is more normal.
  
  

• http://www.youtube.com/watch?v=eVpXkyN0zOE - Short intro to Jasmine and TDD
  
• https://tutsplus.com/course/javascript-testing-with-jasmine-2/ - Nice n Easy course to Jasmine & TDD
  
• http://www.letscodejavascript.com/ - epic comprehensive JS TDD course from server to browser
  
• 
  
• http://visionmedia.github.io/mocha/ - My favorite runner (with Chai)
  
• http://karma-runner.github.io/ - Test in mult. browsers from the command line (advanced)
  
• https://github.com/rmurphey/js-assessment - test your skills (no pun intended)
  
  

  --
  

  I just started sketching out a website to try and solve this problem. It has different paths to follow to fill in gaps of JS knowledge quickly (much like hackdesign.org)... unfortunately it's not finished yet! Watch LevelUpJS on Github in the future. I also have some more links on app architecture and things like modules but this list is getting a bit large!
  
  Cheers and good luck!
  

I'm sorry if the reply turned out a bit too general, but the individual steps depend a lot on the specifics :)

As I said before, it's crucial that you understand the problem domain as good, or better than your customers. I like to think of it as the Fog of War in strategy game maps. I can only effectively perform once I have explored enough territory to see the big picture. Here's roughly how I would try to wrap my head around such a challenge, if the company hired me to help:

Customer

Who are the customers? It's actually possible to think of the customers just in terms of their needs and desires. But it's useful to know their demographic attributes, so you can choose whether your solution is going to be a lateral or a niche one. For instance.. Trello is a lateral solution, because the kan-ban methodology can be applied to many different types of problems. On the other hand, It could be argued that 500px is a niche solution, because it caters to photographers more than meme authors. It's very easy for 500px to figure out where photographers hang out online and in the real world, should they choose to reach out to them in any way.

The job (Problems / Desires)

The customers usually have some sort of job to be done. That job is driven by their desire for a benefit, or a lingering problem that needs solving. Those benefits can range from monetary to peace of mind or social status. And problems can range in severity. Furthermore, different customer segments can rate some problems and benefits as more important than others. This is the combinatorial explosion of stakeholders and their points of view, that informs a strategy of a good product designer, and causes an uninformed designer to arrive at an optimal solution only through brute force or sheer luck.

Solution

Sometimes the solution has to be drawn up from scratch, optimized or entirely re-imagined. So what is the existing solution? What would an utopian solution look like? A complex problem might require a solution in the form of a toolkit of multiple core activities (Like Google, HubSpot or Moz). A focused solution though, can be embodied in a single product (Caffeine.app keeps your mac from going to sleep). If a solution is complex behind the curtains, but you make it simple and gratifying from the user's point of view, it may seem like magic to them.

Business

The things that you do behind the curtains are some core activities, that might require some key resources. That's how the business makes sure it spends less than it earns on a customer (unit economics). It's easy to paint a picture where the world is split between sociopathic capitalists with a greedy agenda & empathic designers, who champion the user's priorities. But a similar solution with a sound business foundation will always be better for the customer, because it stands a better chance of outperforming the economically inferiour solution in the long run. It's the job of a designer to balance between the two aspects. So much so, that the Elements of User Experience places big emphasis on both Business Objectives & User Needs.

Communication

Once you love your people, and you have a way to show it to them, you'll have to start and maintain some sort of relationship. You can identify Touch Points or Channels. If, for instance, your customers are tourists looking for a place to grab a meal before boarding the next train, you can administer your solution right then and there, at the train station. But most of the time you'll be reaching out to your potential users somewhere between you and them, probably through a third party (online publication, app or ad network). It may take multiple exposures in different contexts, before somebody decides to give your solution a try. So a customer might bump into your message at certain touch points, open a communication channel like a newsletter or notification subscription, and only then decide to commit. There's often talk about a multiple stage funnel, through which we try to shove as much of our target market. But you can also look at customer lifetime stages as vertebrae in the cohort spine. For instance.. Slicing out customer segments by lifetime lets SoundCloud identify differences between a newcoming podcaster & a long-time podcaster, and communicate with each of them appropriately, even though most of the people that care about SoundCloud are producers and record labels. Staying on top of communication also helps you avoid conversion attribution mistakes, so you can communicate more effectively.

Here are some resources related to those subjects:

• Value Proposition Design, Alexander Osterwalder: How to map the Customer, their Problems and Desires to a Solution.
  
• The Innovator's Dillema, Clayton Christensen: Describes how disruptive innovators solve existing problems in novel ways.
  
• Minto Pyramid Principle, Barbara Minto: How to communicate the value propositions to a rationally minded customer.
  
  A bit more business related:
  
  
• Four Steps To The Epiphany, Steve Blank: A user-focused methodology for efficiently finding a viable business model, called Customer Development.
  
• Business Model Generation, Alexander Osterwalder: His first book takes a broader look, dealing with booth the business and customer side of things.
  
• Lean Startup, Eric Ries: What Steve Blank said.
  
  Once I have a good understanding, I would focus on Information Architecture, Experience Design, Production & Iteration. I can't spare the time to write about those now, but here are some related resources:
  
  
• Elements of User Experience, Jesse James Garret: What a typical experience design process is made up of.
  
• About Face, Alan Cooper: Another take on the whole process, dives a bit deeper into every stage than Garret's book.
  
• Don't Make Me Think, Steve Krug: One of the first books to gave the issues of IA and UX design a human, customer point of view.
  
  I might write more about the specific subjects of IA and UX later, when I find the time. In the meanwhile, check any of the three books with italicized titles, if you haven't already.
  
  Peace o/

Hahaha, you're right, my post sounds totally creepy, sorry about that.

What I got from you is that you're basically dealing with 2 issues:

Lack of knowledge, skills and experience: it's like you have 4 times 1 year experience instead of 4 years of experience. Seems that you miss being exposed to different challenges and solutions to those challenges.

Imposter syndrome - fed by the previous one

First, it's important to acknowledge that both these problems will follow you throughout your whole career. The very nature of our industry, whit new tools, languages, frameworks and techniques appearing litterally everyday, makes it impossible for someone to know everything. Given this scenario, we have to be smart about what and how to learn things and, at the same time, be confortable being unconfortable.

I think those are a whole new discussion (we can talk about it if you want) but I'd like to suggest some tactics that might help you on a shorter term:

Join a community

This was what made THE big difference for me years ago. I didn't know anything other than what I did at my job; the community showed me different ways of doing my work that I didn't know even existed. It's a perfect space to learn, share experiences and network. Try to join a local community that has in person meetings. I still get a lot of energy from interacting with people from outside my job.

Pair programming

I don't know if your team does pair programming, but I'd recommend it. Even if you team doesn't do it, ask people if could pair with them for an hour or so on their tasks. Learn their style, how they use their tools, their shortcuts. Ask what they're thinking as they code. Discuss the solution being implemented, talk about alternatives.

I think pairing is one the best ways to learn.

Good article about techniques for pair programming by colleagues of mine

Start a pet project

Assuming you lack experience on backend development, I'd suggest you start building a complete web application on your free time. Build something that you care about and would actually do something, so you stay motivated. You can start with something very simple and add features as you go.

I don't know if you're interested in some specific language/technology and I don't know what your team uses on your current job (it would be nice to practice on something that would be immediately useful on your job), so I'd recommend something like Rails. Rails can be simple enough for a beginner to see progress quickly and has a huge community for support.

This app can be your platform to learn and practice a complete software development lifecycle for a typical web app - stuff like OO design, HTTP and REST, MVC pattern, unit testing/TDD, integration and functional testing, version control and how to deploy and operate a system in production.

You can share your code in GitHub and ask for reviews and feedback.

Teach

There's always someone that knows less than you do about a subject. Offer help on the communities you're part of, answer questions on reddit or stackoverflow, coach a new teammate... there are tons of opportunities. Teaching will make you feel good about yourself and will help you to reflect and understand more deeply the subjects you're teaching. Confidence + knowledge.

Host a lunch & learn or brown bag session for your team/company. You could share interesting stuff you're working on, cool technologies for your team to try or any other tech related subject. This can make you be perceived as the "go to" person on some subject and as someone who's making an effort to learn and share with coworkers, bringing lots of value to the team/company.

Books

I strongly recommend you check out Clean Code and The Pragmatic Programmer. There are many other great books I could recommend but those two were the ones that changed the way I see my profession.

I can think of a bunch other tactics to help you improve your skills and confidence, but I think this is enough to start a conversation.

Ideally, our jobs should provide all the opportunities to practice and accomplish all the things I suggested you do by yourself. But to get one of those jobs, we need to take the firsts steps. My point is that we should be in control of our career, not your manager/team/company. If we want to learn something, or use some tool or technology, we shouldn't wait for the opportunity to come.

Does this make sense to you? Is this helpful?

PS: I'm curious about a couple of points:

When you say "I've always struggled to build big features", what kind of features you're talking about? Can you be more specific?

When you say "I have to spend a really long time just thinking about some problem", what kind of problem is this?

I might have some insight about those issues.

[2 of 4]

• How curious are you? Do you have more ideas then you can execute? What are your curiosities about? What are your ideas about - is it environmental or conceptual, and can you please elaborate?
  
  • I think this is something I struggle with on a daily basis. I like many things, or so I like to believe. Like I feel that everything’s interesting and everything is connected somehow through symbols. I like thinking about these symbols and connections constantly. So my ideas are about concepts mostly. I can’t remember facts if I can’t attach them to concepts that make sense to me.
    
  • This has been my latest conflict I have to say. I started a career in EE, and then I shifted to computer science. I’ve wanted since I was an undergrad to start a research path, but I’ve been struggling to find something I really really love. I am not good at taking decisions, but an academic path looks now like my best bet for not working in a desk never again (I like having my own desk at home, though).
    
  • I’m confident everything will be good at the end, and I am confident I can do almost anything. Not trying to be cocky, is just that I know I’m physically and mentally capable of learning anything (in the realm of normal stuff, of course I won’t build a heavy falcon myself), so unless that does not change, I’m good. On the other hand, being so certain about that backfires at me, filling my head with “what ifs”
    
  • I have this bad habit of reading (and most of the time not finishing) books in parallel, now I’m reading about
    
    • Carl Jung (https://www.amazon.com/Jung-Short-Introduction-Anthony-Stevens/dp/0192854585 mostly motivated by understanding this mbti thingy)
      
    • About network science (https://www.oreilly.com/library/view/complex-network-analysis/9781680505399/ and https://www.amazon.com/Networks-Introduction-Mark-Newman/dp/0199206651 because network analysis can be applied to almost anything)
      
    • Machine Learning (http://shop.oreilly.com/product/0636920052289.do) because is what the cool kids do in IT now or so I’ve learned, I’m more into software architecture though, and
      
    • EGB (https://www.amazon.com/G%C3%B6del-Escher-Bach-Eternal-Golden/dp/0465026567) which is a beast and I wanted to get my feet wet about cognitive science and semiotic. I am at about 40% of all of them,
      
  • I pick a chapter until I finish it, and then I move on to the next book, when I have time. I’ve lost interest in reading fiction, I get that from reading graphic novels and manga, mostly. If it matters something, currently ongoing mangas I like are Hajime no Ippo, One Piece, Vinland Saga and The Promised Neverland.
    
• Would you enjoy taking on a leadership position? Do you think you would be good at it? What would your leadership style be?
  
  • I’m not very good at getting stuff done so I would probably suck as a leader of anything. But hey, I am good listening to people and helping them improve. I also don’t think I’m a good teamplayer. I’m bad at following instructions if I don’t trust them. During college I was the guy that ended redoing the work of others during group assignments, because I either I was not satisfied with their work or I was not good at giving instructions. I didn’t know at that moment I was being a dick and I know now, and it’s not something I’m proud of. I'm working on it.
    
• Are you coordinated? Why do you feel as if you are or are not? Do you enjoy working with your hands in some form? Describe your activity?
  
  • I used to draw more when I was younger, and did a bit of woodwork also. I had plants. I like to cook, and have strong opinions on food. I like creating stuff with my hands, I consider myself a creative person. In short, I am coordinated, but not so with team activities like team sports.
    
• Are you artistic? If yes, describe your art? If you are not particular artistic but can appreciate art please likewise describe what forums of art you enjoy. Please explain your answer.
  
  • It’s hard to pin down what kind of art I like, I just know I like something after I’ve seen it or told about, with no particular topic. I don’t understand sculpture, and I vaguely get poetry. Regarding drawing, I appreciate the flow and light in shapes. I was into human figure for some years, and I did a lot of drawings that were good.
    
  • I know a bit of guitar and ukulele, but I never played for others than girls I like. I am too shy of my voice, my singing and technique, I know it needs improving. I took singing classes once but with only the gist of it I got it’s something that requires more discipline and time than what I’m willing to spend.
    
• What's your opinion about the past, present, and future? How do you deal with them?
  
  • uhm, now I strive to live a life that maximises happiness and minimizes regret. At my age I think I know enough about the things I can control, and play along with that hand, always with the best intentions, and I am optimist about the future.
    
  • Sometimes I regret not being like this in the past, however, and I see myself revisiting things I would have done better, like studying more, eating better, loved more.
    
• How do you act when others request your help to do something (anything)? If you would decide to help them, why would you do so?
  
  • I always help, I believe in karma as a thing (I mean, not religiously) and that life has been really good to me. I don’t help when I know I can’t help, or when I’m being ordered to or asked in a bad way i.e. makes me feel bad. I have trouble noticing these situations though.

Hey there! I recently finished this course and also recently got my first offer for a Jr. Front-End Developer role after about a year and a half of self-study. Colt's course is awesome, and I found it to be the best single resource on web development I encountered. So I think you've picked a really good place to start. But, that being said, it is just a starting point (even a full-time $10k boot camp is just a starting point), and you probably will need to look into other resources as well.

I will second what others have said that I found the Rob Percival course underwhelming, but there's a lot of other stuff out there that I would recommend. Note: I'm going to go a bit link crazy here, and I know that might seem a bit overwhelming, but I'm figuring it's better to give you more rather than less; your mileage may vary, and you may not need all of these. These are just the resources I found most helpful.

Free Code Camp is a great place to find practice problems to work through, mainly when it comes to front-end. I can't stand using it end-to-end as a learning path, but others love it. So, different strokes and all that.

CSS Tricks is a really great blog and site for learning how to do advanced CSS stuff. And the site founder Chris Coyier, also hosts a really great podcast called Shop Talk that's all about front end.

John Duckett's books HTML & CSS and JavaScript & JQuery are really pretty and very noob friendly. The JS one does have some errors, so be wary of that, but I found it really helpful for getting a sense of the underpinnings of the language while reading on the train.

You Don't Know JS Is a great book series that is all available online for free and will really help you solidify your JS knowledge.

JavaScript: Understanding the Weird Parts is another Udemy course that does a deep dive of JS (Udemy always has sales, by the way, so never pay full price for their courses).

JavaScript Design Patterns is a free course on Udacity that is super helpful in introducing you to JS frameworks and MV* design patterns. Note that, while you can pay to do a "Nanodegree" through Udacity, you can also access a lot of their courses for free, so I would recommend trawling through them--there's a lot of good stuff on there.

JavaScript 30 is a 30-day structured course in building stuff with vanilla JS by Wes Bos, who has a lot of other good courses as well (though some of them are paid).

Practical JavaScript This is one I've actually just started working through, but so far, I'm really enjoying it. Again, this is free. It will introduce you to test-driven development and give you a better sense of how to plan your own projects, while also not getting mired in any frameworks.

If you want to go into the bowels of the framework world, though:

The udemy course I did first for React/Redux now seems to have been taken down by its creator so that he can update it. But it was called The Complete React Web App Developer Course by Andrew Mead, and when it comes back in updated form (hopefully soon), I would definitely recommend it. If you like Colt's teaching style, Andrew's has a lot of the same feel (excited, but really detailed explanations, and goes over things 50 times in different projects and contexts so that you really learn them). I've also started doing Stephen Grider's Modern React with Redux, and it seems really good so far (though I'm not that far into it, so take it with a grain of salt).

React Fundamentals is another awesome free course by one of the developers of react-router.

Hey dude! I want to send you a huge long explanation I did a while ago about Wacom tablets (which are "industry standard") that didn't get much love in the original post, but I put a lot of work into figuring everything out for this dude so I thought I'd share it again.

Before I paste in my response to this question someone posted, I wanted to mention a few things about your unique situation.

When starting out in design, it's probably more important to invest in a mouse, the Creative Cloud Suite, and some sketching supplies. I use my tablet all the time, but in my classes only about half of the people use tablets. Everyone else gets by just fine (even in illustration) with a mouse. Trackpads are asses to work with, and a good sketchbook, a set of Micron pens, a nice .5 mechanical pencil and some Prismacolor pens are gonna do you a lot more help than a tablet, especially if you're just starting out in classes. Other supplies you might need include a T-Square, a right angle measure (is that what they're called?), a good X-acto knife and a bunch of blades, a good ruler, some tracing paper, and a case to carry it all around. Oh and a portfolio (one of the cloth ones so you can carry your print work around).

If you're specifically looking at web design, i'd invest in a couple amazon books like this book and this book

In terms of graphic tablets, I'm posting an explanation of all the ones available right now. The person for whom I was originally responding was looking to buy one as a gift for, I think, their SO who was primarily a photographer using Photoshop. And just as I post at the bottom of the quoted message, feel free to PM me if you have other questions about anything that I've mentioned here :) Good luck OP, and sorry for the wall of text!

> First off, it's much easier to navigate the different models via the actual wacom site[1] . Here's a breakdown of Wacom tablets:
Almost all wacom tablets come in different sizes. Typically they are small, medium, and large. Very simple, it just dictates how large the tablet is. On the other hand, it also dictates the ratio of calibration to the screen. Let's pretend that your tablet is 4"x5" and your screen is 8"x15" (for the sake of an example, ignore the absurd dimensions). Since every point on the tablet is directly calibrated to a point on your screen, it'll take 1.5 times longer for your cursor to travel horizontally than it will vertically. Not an issue, but it makes the learning curve for using a tablet a little steeper because you have to learn how to change your hand-eye coordination from 1:1 to 2:3.
Ok so about the different models: Bamboo is an older model that is no longer sold. Now they have Intuos Pro and just plain old Intuos. Bamboo is great, fine, wonderful even, but as time goes on it'll be harder to find replacement stuff (like pens, which I have lost once or twice) for the tablet itself.
Now, in the plain old (newest) intuos family, you've got Draw, Art, Photo, and Comic. Draw, the cheapest one, is not a touch tablet. It won't respond to your fingers on it, just the stylus. The rest are all touch tablets too. All four are considered "small". Draw is the bare minimum. Nothing special comes with it. Next level up, you've got Art. Art is touch sensitive and comes with Coral Painter. Next one (Photo) comes with Tonality Pro, Intensify Pro, Snapheal Pro, Noiseless Pro (and I know nothing about what each program does). Then Comic comes with Clip Studio Paint Pro and Anime Studio® Debut 10 (again with the not knowing what it is).
Next up You've got the Intuos Pro, which is what I use (i'm a senior design student with four years of professional design experience, to put it in perspective I do a lot of illustration and I'm very happy with my Intuos Pro). There's really nothing too complex about these, there's small, medium, and large. That's really the only difference among them.
In terms of which one to get, here's my thoughts. The Intuos Pro family is great, but if he's only editing photos then it might not be worth it to get the more expensive tablet. The bamboo tablets are adorable and easy to bring around, but they jack up the price for absurd programs that you most definitely don't need (Adobe suite is standard in the industry. While he sounds like he's only working with Photoshop, if he ever needs to share a file with someone who doesn't have the programs that come with the tablet, they'll also have to own the software in order to read the files).
I have an older generation Intuos Pro that does not have touch-capabilities. It's fine, I have learned key commands to compensate for my inability to quickly zoom and move around artboards, etc. If you're trying to save money, go for the Intuos Draw. It's a great starter, and within the next year-and-a-half to two years he'll probably upgrade. Or you can drop a hot dollar on the Intuos Pro family and kinda bite the bullet. I started out with a bamboo (back in 2007!) and used it until I came to college. I got an Intuos Pro, loved it to bits, and lost the stylus. For about 8 months I was too lazy to buy an $80 new stylus so I used my 2007 bamboo for all my work, and it went fine! I have since sold my little baby bamboo, but it served me well for a long, long time. The only problem is that the appeal of a new toy is sometimes greater than the practicality and logic of playing with an old one.
Best of luck! Let me know if you have any other questions...

> I just realized it's 900+ pages, sheesh. Is it still an easy book to pick up to learn the language?

It's still useful for learning it. If you want something more brisk, try Accelerated C++ which clocks in at under 300 pages.

> I just had a semester using Scheme and I really had a fun time using functional programming. It just feels more structured, but I don't know if that's a misplaced opinion.

> How easy would it be to transition from Scheme to Scala or Clojure? And can interesting projects be made in those languages? I only ask because I've tried to figure out what I could make with Scheme and came up empty-handed, so I'd love to find a functional programming language I can make something cool out of.

Functional programming is a great paradigm, makes a lot of things simpler. The languages also tend to have really awesome features.

Once you know one functional language, a lot of the core concepts carry over to other languages. Scheme and Clojure are also Lisp dialects so they will look very similar. Scala can be used in a very OO way because it was designed to be a Java replacement and to be easier to transition to.

There are certainly a lot of cool things out there written in functional languages. The Haxe framework is written in Ocaml. Netflix wrote their open source telemetry system in Scala. Clojure is used for web services and web applications, and there are some cool open source projects written in Clojure like the Light Table IDE.

> Is there a reason people want to use Haskell?

It's one of the biggest names in functional programming and is known for being a major source of research. It's older than a lot of the newer functional languages like Clojure or Scala, plus promises things like speed, easy concurrency, and doesn't require additional stuff like a Java runtime (like Scala or Clojure do).

> Speaking of FP languages, what're your thoughts on OCaml? I know Jane Street uses it, but that's about it, haha.

The ML family of languages is probably my favorite functional programming family. I learned standard ML in college and have also used F# a lot, which is derived from OCaml. I haven't used a lot of OCaml directly but I imagine it's awesome since I love f# and standard ML.

> Damn, never heard of NIST, it sounds like a fantastic resource! I haven't even seen it linked on the sub before (which, given how often people ask for resources for DS&A, you'd think it'd come up.

It's really more of a basic cheat sheet without a lot of information. Years back when I did more DSA type interviews, it did help as a simple refresher.

> Do you by chance know anything about C and learning it via books? If so, do you think The C Programming Language is a good starting point?

I love C (but it and C++ have been replaced by Rust in my life now). That book (the K&R) is the de facto book for C and one of the best technical books I've ever read, it's very concise. However, it was also written thirty years ago so while it's still mostly useful, it serves more purpose as reference than as a "learn C" book. Though I also learned C from the book and then used additional resources to learn about the newer language features that came out with C99 and beyond.

I'd say give K&R a try - if you don't like learning from it then try Zed Shaw's Learn C the Hard Way which is a free eBook/website.

> Languages generally speaking have a documentation which specifies itself. That's the spec for the language. Someone interested in creating a compiler, interpreter, or some sort of analyzer, and so forth for the language needs to know how the language is supposed to work. The spec is the document which talks about that in detail. It's like the official documentation if you will.

Okay, that makes sense; so the spec is a document explaining the nuances and how the language works?

> "Minimalist" is not very exact terminology. It means the language has a small set of concepts and things that you can use. The nice thing about scheme is that from this small set of features, you can do tons of stuff. It usually implies a small set of keywords, but that's not just it. Generally speaking, it has a small features set, which isn't very exact terminology either.

That makes sense; so Scheme is minimalist in one sense that it might not have a ton of built in keywords, but with what it does have you can create a lot from it?

> These weren't courses per se. I did this before getting into college. The C programming I was talking about came from K&R2 (https://www.amazon.com/Programming-Language-Brian-W-Kernighan/dp/0131103628/) and looking things on the web. I think it helped. Not sure how much. I don't think the PHP web dev helped.

That book looks very interesting, I might take a look at it later on!

I only ask if the experience helped because I mainly want to see how ready I can before I go into SICP without spoiling myself, as I believe SICP is a great place to teach people concepts for the first time (even if they're not totally understandable, like in my case).

> I have no clue what is the better choice in here. Try both at the same time? I think MIT 6.00 even uses "how to think like a computer scientist" (the book I mentioned before).

Duly noted, might look into the lectures before I start SICP.

> Both. It's meant as an introduction to programming and computational problem solving. In one of the lectures I think the professor talks about how people do better in SICP if they take this course before.

If you don't know this answer it's totally fine, but does the lecture prepare for the content in SICP and how to solve the accompanying exercises?

> That is true, but there is more to it than that. Each language has its ways of doing things. When people are making new languages, they're highly influenced by other languages. To the point that most languages I've seen have nothing new but a few pieces, and most of everything else is just a "rehash" of ideas from other languages. Generally speaking, you'll see a lot of commonalities among several languages.

Can these commonalities be seen amongst different paradigm languages as well? Like are there commonalities between, say, Python and Scheme? I only ask because for example, I never saw the use of car and cdr as ways of accessing elements of a list before, let alone the heavy usage of recursion in a language. But perhaps that's because it's my first functional programming language

> It is true that each language has its style, but that style shares plenty in common with other styles from other languages. There will be things in common, and very rarely stuff you learn in one language won't help you in another language.

So even though there's different paradigms amongst languages, there's still quite a lot of shared aspects between them?

> In the end, you'll have a bag of cohesive programming techniques. That's not really language dependent as much as some people will tell you. Languages aren't that important as far as I can tell. I remember, back when I was starting to learn how to program, giving real importance to programming languages. Maybe they are really important, but it doesn't seem to me like they are anymore. The programming techniques and ideas behind them are though. The language is just a "conduit" by which you apply those techniques to solve problems, which has its importance but it's greatly exaggerated by most programmers if you ask me.

So it's more so the ideas that are developed through the languages that are important rather than the languages themselves?

> In fact, in SICP, you'll end up learning that a way to make problem solving more approachable is to make a language that is a better means to apply the programming techniques that you think help in solving the kind of problem that you want to solve.

That sounds incredibly interesting. I know I'll learn more once I read it for myself, but do they suggest that the way of approaching a problem is to define techniques or functions within the language itself that would help better solve it, or do they imply to switch languages entirely to solve it better?

> Nowadays, some languages are nice enough that you'll be able to do that by just cleverly designing a new library or framework. Making new languages is still valuable though, and in my opinion, underrated.

When you mean you can design a new library or framework, do you mean creating a whole new sub-language so to speak to deal with the problem, or do you mean just creating new functions that meet the solver's needs and isn't readily available (i.e. the goal the user had in mind isn't implemented in the language, so the user instead creates it themselves)?

In what ways are creating new languages underrated? Do you mean the experiences one has and take away from creating one that are underrated?

> I didn't see it emerging either. I started to study programming and CS in 2006 (I think). All I've said is based on "stories" and reads that came up while I was reading books, reading blog posts, talking to people, etc.

Yep, that's pretty much how my background about the older days of CS is built. Although I suppose it's the only way to learn about a time before ours in which CS was emerging.

Another standalone question, if you don't me asking for your opinion: I currently have a book on data structures and algorithms (aptly called Data Structures and Algorithms in Java by Robert Lafore) that I plan on reading. Would it be in any way detrimental to read that book, or at least begin it, before delving into SICP, and once I've completed my next CS course (taught in Scheme), then begin working on SICP? Again, I only ask because you're more experienced and I'd like to hear your thoughts on this matter.

Android team lead here, I've been working with Android commercially since 2009 (before Android 2.0 was released) and have worked at, or done work for, some big companies (Mozilla, Intel, Google, HTC...). I was in a very similar situation to you in that I was a web development and was bored, I'd been playing with Android in my spare time; I got my first break by volunteering to do an android app at the company I worked for, and went from permanent employee to contractor fairly quickly after that and have been doing it ever since.

First thing to say is that if you can get your currently company to pay you to learn android and stay with them, that's a win win for both parties (you get to learn something new without a drop in salary and don't have to interview and they don't lose a good member of staff).

In terms of moving company, I don't know where you are based, but here in the UK I often see junior Android contract roles coming up for £200-300 a day. Failing that it's just a case of applying for lots of poisitions and really knowing your stuff.

What I would look for in a junior is to have read, understood and put in to practice Clean Code (https://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882) and Design Patterns (https://www.amazon.co.uk/Head-First-Design-Patterns-Freeman/dp/0596007124). I would expect you to have a good understanding of basic Java and OOP; a working understanding of MVP or MVVM (https://news.realm.io/news/eric-maxwell-mvc-mvp-and-mvvm-on-android/, https://www.linkedin.com/pulse/understanding-difference-between-mvc-mvp-mvvm-design-rishabh-software); understand threading; know about all the major parts of Android (Services, Broadcast receviers, Activities, Fragments etc); know how to write a custom view; be able to efficiently design a layout in XML and correctly apply styles and themes; understand the support libraries - what they contain, why they exist and what they are used for (and also when you don't need them); understand the difference between unit testing and integration testing and know what makes for a good test; the Gradle build system is a really nice way of defining your project build - knowing the fundamentals is essential.

A few of the main libraries I'd expect you to know and have used would be OkHttp (https://github.com/square/okhttp), Retrofit (https://github.com/square/retrofit), Butterknife (https://jakewharton.github.io/butterknife/), Picasso (https://square.github.io/picasso/) or some other image loading library, GSON (https://github.com/google/gson) or Moshi (https://github.com/square/moshi) or some other json parsing library

If you want to level up then there are loads of advanced topics surrounding Android. Any of these following topics will take a while to learn, but will be worth it and will look good in interviews and on you CV:

• RxJava (http://blog.danlew.net/2014/09/15/grokking-rxjava-part-1/) - This is the new hotness in the mobile world (including iOS) at the moment. Version two of rxJava has just been released and knowing this will probably land you a job super quick.
  
• Dagger (https://www.youtube.com/watch?v=Qwk7ESmaCq0) - Dependency injection library. I actually find it super confusing to setup because of some overloaded annotations and lack of clean documentation, but lots of places use and expect you to know it, so it'd be a good idea to at least get a basic understanding of it.
  
• Kotlin (https://developer.android.com/kotlin/resources.html) - The new Android language - not many places are using in production but learning it now would be a great way to invest in the future (and it's fun)
  
• Clean Code architecture (https://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/, https://fernandocejas.com/2015/07/18/architecting-android-the-evolution/, https://github.com/android10/Android-CleanArchitecture) - A great architecture that I use in my current projects - being able to mention this and talk about it would super impress me from someone with your experience.
  
• An understanding of different architectures (https://github.com/googlesamples/android-architecture) - A great resource for learning, it's a simple todo app but build in lots of different ways
  
• Room & the other new Android architecture libraries they've recently announced (https://developer.android.com/topic/libraries/architecture/index.html)
  
  There's so much more - this is a large topic and it's easy to feel overwhelmed (I know I did & do) but the sheer amount of stuff to learn, but take it slowly and it'll come. The best way that I found to learn all of this stuff is to have a personal project which I was working on (I started doing an app which teaches you how to play guitar - never released it but learned so much). Get the fundamentals down and them start looking at some of the more advanced things. A good test app would be to write a Reddit client (they have open APIs: https://www.reddit.com/dev/api/) - this will get you up to speed on networking, background services (to poll the API to see if you have any messages) etc
  
  Let me know if this helped or if you want to chat about stuff. Happy to help.

You always want processing. You may or may not need graphics. I saw you say you liked fighting games. You'll need a decent rig with some capable graphics.

You wanna dev?

First, yes you need a machine, a decent one. Do you want to build it? Yes , but if not then check these out. I suggest getting a workstations because they're built for productivity. However, they're expensive.

Also, I'm not sure you should commit to a desktop. Two words: Game Jams. You might want to take part in communities involved in game making games. For inspiration, mentorship and just overall fun. If you're not familiar, games jams are when developer enthusiasts get together and build a game over a period of time. The games tend to be simple and set around a theme for the event.

In which case, look at some cool laptops. The reason I suggest getting a gaming laptop is that it will have the graphic card you need, it doesn't need to be high end, just good enough to not be a toaster. Also gaming laptops tend to be more powerful.

So from a dev point of view, they're pretty solid. Personally, I prefer workstations. If you asked me, I would get a workstation with a video card, but those are very expensive and maybe when you master your craft you can drop some real cash on it. You're new. So don't spend too much, in case the entire thing doesn't jive with you. Worst case you get a decent gaming laptop to play MK at the coffee shop. (Don't laugh, I used to play Street Fighter at a coffee shop, it's a nice vibe!)

Also, I would also check out Meetup.com. Your city or area might have groups dedicated to building games and maybe you can learn with another person. From a professional point of view, there's a lot of value in learning to work with others.

So you got your hardware, now for software.

You will likely want to start building stuff. But you're going to need some baseline stuff.

So, I say go with Unity, long term. However you need to get to a place to understand unity. So... you're going to need to learn some coding. To at LEAST be comfortable with code. I say learn the basic and intermediate stuff first then jump into Unity. If you're feeling bold you could also do the advanced.

You will need only Visual Studio and make sure during the install you ask to include Unity.

Finally, you should read Clean Code. Write good clean code. Future you will thank you.

Now, you gotta be productive.

Set up time to do what you want to do. One or two hour blocks. Commit to them. Log that time. Also, get open office, or some other equivalent and start organizing your workflow. as a develop you need purpose in your tasks. So outline your tasks. Develop you "method" for working. Maybe you like self imposed crunch where you just throw on music and go. Maybe you prefer small bursts of productivity. Whatever it is, figure it out.

Journal your work. Go back and read it occasionally. Take non-digital notes on important stuff you learn. Writing helps with retention. You have two processes you need to flesh out.

• Your development process. How something gets built, tested and delivered.
  
• Your Creative process. How you come up with a game idea and flesh out if it's good.
  
  You're going to need to get a good sense of how to build a proof of concept. This will help you "feel out" your game's mechanics.
  
  Over time, you will need to explore more advanced idea in computer science like data structures and design patterns... but for now, focus on getting comfortable with code, debugging. Hell, even make a console app text adventure game. Start there. Then get more complexity. The idea here, is to take your time, be diligent and stick to it. Slow isn't bad, not completing is bad. So take your time and good luck!

Firstly, I wanna say sorry for your losses. You've had a rough life but good shit trudging through it 3Head, although you've arguably lost the best years of your life (Chester Bennington Who? Robin Williams Who?)

Now, I don't give a fuck if you were #1 or #777 in your programming class at your trashy school. You didn't get my point that however well you do in school doesn't matter, because regardless, you're bounded to solely that school, you're not nationally or internationally ranked (Being an analogy Andy, the #1 runner in my high school runs a 16:30 5K which is pretty good, but is no where near the international Olympiad level; the same is true with you and your trash-tier programming ability, you haven't accomplished anything in that field outside of school [and don't blame this on your illness, if you realized you were intelligent in high school, you would've been something back then, before your chronic disease emerged])

Also, those are the most fundamental basics of a multi-paradigm programming language, I learned Object-Oriented, exception-handling, recursion, generics, use of external libraries, methods, events, pointers, e.t.c. in 7th grade and there are hundreds of kids who'd done so at a much earlier age than me. Anyone with a somewhat quantifiable amount of intellect can understand that shit, that's the basics. You never truly got into programming, I can tell, as if you did, you would've instead listed the more complex theorems that actually require intellect to be able to derive and truly understand (algorithms and data structures) such as Computational Geometry and Shortest Path Algorithms(BFS, DFS, Dijkstra, Floyd Warshall, Prim, Kruskal), Computational Number Theory, Hashing, Trees, Data Structures(segment tree, fenwick tree, disjoint sets, Heavy-Light Decomposition). The list is endless; although you're 30 and pretty far behind, if you're at all interested in truly understanding these algorithms, their proofs and derivations (if you want to work at google, apple, e.t.c you need to learn), here's a link to an introductory book written in Pseudocode: https://www.amazon.com/Introduction-Algorithms-3rd-MIT-Press/dp/0262033844

(I may be immensely toxic, but just trying to help you out if you're still trynna stay on the CS path)

Also, you don't understand the problem-solving I was referring to. The questions you are referring to, given in school, require very basic problem-solving skills that don't truly captivate the beautiful art of problem-solving. True problem-solving is when you're faced with the most difficult and complex ad-hoc (One subdivision of programming problem topics contains problems for which there exists no general technique or algorithm, i.e. no well-studied solution. These are known as ad*-hoc problems. Each* ad*-*hoc problem is unique, and requires a specialized approach) problem ever, where you have to manipulate it to devise an innately beautiful algorithm which beautifully merges a bunch of previous theorems that seem unrelated to creatively take a shortcut to the solution in a truly brilliant manner(this is easy to explain to others who understand problem-solving, but it's kind of hard to generalize it so sorry for the butchered explanation, here's a link that you can explore to learn more: https://artofproblemsolving.com/ )

Here's a programming question (from the final round of the USA Computing Olympiad for the brightest programmers across the nation, which I successfully solved). It may seem simple at first due to its short length, it's actually immensely complicated and requires immense critical thinking+IQ to come up with a unique algorithm which solves every possible test case; in my eyes, it truly captivates the art of problem-solving. If you're at all interested in seeing it here's a link: http://www.usaco.org/index.php?page=viewproblem2&cpid=950 (and don't lie and tell me you solved it, I know you can't because it requires knowledge of the complex Gauss-Bonnet theorem in topology/computational geometry taught far after Multivariable Calculus: https://en.wikipedia.org/wiki/Gauss%E2%80%93Bonnet_theorem )

TWITCH: And no, your remark about finding another way in was pretty retarded, of course, everyone would think of doing that, that's simple ban evasion. I'm obviously not gonna create a new twitch account to fucking chat, I already stream myself programming on my main twitch account so I'm not gonna go and make a whole new account to just chat, I'll donate someday and get unbanned from Felix's channel. Furthermore, I'd have to resub and build up my sub-streak all over again so not worth.

Also, I highly doubt I would've committed suicide if I were in your shoes because I would still have something going for me, the fact that I can and will make a meaningful contribution to society. And I know why you "weren't good enough for your interview," because you couldn't problem solve, most interviewers for companies such as Google and SpaceX ask questions that are slightly easier than those found in competitive programming competitions.

And bill gates and zuckerberg were dropouts because they were entrepreneurs, they could've easily finished college but it wasn't worth it because their companies started rapidly growing; they have skills that you don't, you're just a random dropout for no reason, most dropouts that make it big drop out because they see another vision for themselves. The main reason I want to go to a top university isn't for the education, I could learn all that I want from edX and Coursera, it's to meet others top students in hopes of creating our own successful business from our dorm.

If you're still interested in becoming a dev, hope that helped (although I'm half your age so I don't see why you'd listen to a zoomer like me regardless).

Edit (Didn't see your edit, I'm boutta go hard for disrespecting me): You're fucking retarded lmfao, your reddit is filled with gaming related shit (you're 30 and you game for a living, sad life) so I scrolled down to see the first post not in r/xqcow or r/letitidie and your age was there, I didn't see any sad shit you posted.

And yes, I do actually help others and inspire those invested in my field that I find in school and other communities, if I realize that they have recognizable talent and intellect to be something, but I'm not gonna be a soyboy cucklord who tells someone they can do it when they're realistically not smart enough to, I won't hold their hand and tell them they're worth something when they're really just an average andy that doesn't have the unique ability to ever do anything meaningful; I'll gladly shit on others who aren't smart and sit in a corner studying all day for the SAT because they can't naturally do well; I'll gladly tell them to kys, as talent outweighs hard work heavily.

I'm not privileged, I started at the fucking bottom (Kapp -> low middle-class) and reached the top myself, if you can't do it and are complaining, then natural selection retard.

(Also, Iostux is dogshit, I'd roll him in a 1v1 Kapp)

Sure, there are a few directions you could go:

Algorithms: A basic understanding of how to think about and analyze algorithms is pretty necessary if you were to go into combinatorial optimization and is a generally useful topic to know in general. CLRS is the most famous introductory book on algorithms, and it gets the job done. It's long, but I thought it was decent enough. There are also plenty of video lectures on algorithms online; I liked the MIT OpenCourseWare of this class.

Graph Theory: Many combinatorial optimization problems involve graphs, so you would definitely want to know some graph theory. It's also super interesting, and definitely worth learning regardless! West is a good book with lots of exercises. Bondy and Murty and Diestel also have good books, which are freely available in PDF if you do a google search. Since you're doing a project on traffic optimization, you might find network flows interesting. Networks are directed graphs, where you think about moving "flow" across the edges of the graph, so they are useful for modelling a lot of real-life problems, including traffic. Ahuja is the best book I know on network flows.

Linear and Integer Programming: Many optimization problems can be described as maximizing (or minimizing) some linear function subject to a set of linear constraints. These are linear programs (LPs). If the variables need to take on integer values, then you have an integer program (IP). Most combinatorial optimization problems can be formulated as integer programs. Integer programming is NP-hard, but in practice there are methods that can solve most IPs , even very large ones, relatively quickly. So, if you actually want to optimize things in real-life this is a very useful thing to know. There's also a mathematically rich field of developing methods to solve IPs. It's a bit of a different flavor than the rest of this stuff, but it's definitely a fertile area of research. Bertsimas is good for learning linear programming. Unfortunately, I don't have a good recommendation for learning integer programming from scratch. Perhaps the chapters in Papadimitriou - Combinatorial Optimization would be a good introduction.

Approximation Algorithms: This is about algorithms which quickly (in polynomial time) find provably good but not necessarily optimal solutions to NP-hard problems. Williamson and Shmoys have a great book that is freely available here.

The last book I'd recommend is Schrijver. This is the bible for the field. I put it here at the end because it's more of a reference book rather than something you could read cover to cover, but it's REALLY good.

Lastly, if you like traffic optimization, maybe look up what people are doing in operations research departments. A lot of OR is about modelling real problems with math and analyzing the models, so this would include things like traffic optimization, vehicle routing problems, designing smart electric grids, financial engineering, etc.

Edit: Not sure why my links aren't all formatting correctly... sorry!

> Someone said I might be "destined for grad school" which is fine, but I'd rather know the ins and outs before I get my mind wrapped around the idea.

Depends what you want to do. If you want to work in some very focused area, the MS might help. If you just want one of the multitude of SWE jobs where you get paid big bucks to contribute to a really cool project, then just get a job after your BS. You can always get an MS later, without quitting your job even.

> From talking about it in passing, it has to do with turning it into bits and the usage of an assembly language?

More or less, but to be pedantic, everything is always bits, and it's more about machine language the assembly language (which is a human readable version of machine code). The NAND to Tetris course I mentioned will make this all extremely crystal clear to you, possibly moreso than any class you actually take at school.

> Based on what you say later on, is it safe to say that abstraction is just the idea of isolating a piece of code, presuming it works, and letting it do its thing while you work around it to produce something better?

Not just code, but any physical resource. When you connect to a website over the HTTP protocol, your entire interaction with that web server is defined by that protocol. All you know is that there are certain commands you can send it, and certain responses it will give you back (you personally don't send these commands, your web browser does it for you). That web server is a fairly complex system in itself, but for your purposes, it's just a thing that takes requests and returns responses. It's no different than a method in a piece of code. This is what abstraction is, and it allows extremely complex projects to be managed understandably, by individuals or by teams.

At the same time, to be a competent computer scientist, you should know how a web server works... roughly speaking. But as a programmer sending it requests, you don't have to burden yourself with thinking about it.

> If you could change one thing about the order that you learned things, would you first learn about how a computer works before you began programming? And if so, how far in-depth would you go before you would be satisfied?

Honestly, I'd like to have had a better bottom-to-top view of computers before getting into all the super focuses classes that each teach a single aspect, but require cursory knowledge of the others. In addition to the book I mentioned already, another great one is CODE by Charles Petzold. It's lighter reading, and has no projects/assignments. It reads more like a novel and is really written for anybody, but at the same time it can explain a lot to a new CS student or even to a CS grad who got no good "high level" view in his classes.

> I'd love to read "From NAND to Tetris" based on what you describe it as, provided it doesn't require a heavy foundation of computer architecture. I myself have always wanted to know how a computer is built, what parts make simple functions like moving the cursor and key input work, how memory is stored, etc. Would "From NAND to Tetris" teach me those types of things and beyond?

Yes. The author says there are no prerequisites except knowing a programming language. It's a 12 chapter book that starts off with boolean gates (the basic building block of a microcircuit) and ends with Tetris. Each chapter in between builds something on the results of the previous chapter. Essentially, by the end of the book, you've built a video game from boolean gates. But thanks to the abstractions at each level, you don't have to concern yourself with transistors when writing your game; you only have to think about how a Tetris shape can move. Each chapter has a project, and they're not easy. But I loved, loved, loved those projects. I did all of them in about 2 months, in a pretty addictive approach. Basically, you learn about things like compilers, operating systems, etc, and you build simple "toy" versions of each one, but seeing how all of these connect together, eve with toy versions, is IMO more useful than a course that teaches you how to build a real compiler, but without a good understanding of how that compiler works in a larger system. Here's the book: https://www.amazon.com/Elements-Computing-Systems-Building-Principles/dp/0262640686

> Would it be safe to say that CLRS is meant for seasoned veterans or those who are fascinated by DS&A, rather than someone like me who just wants to understand how they work and when I could use them in a program?
> Would Skiena's book be something to read after my DS&A course, based on your description of it?

I don't know who CLRS is intended for. Probably beginners. I actually don't like the book that much and really haven't read the whole thing, but I've looked up certain algorithms in it just to see how they're presented. It's not bad by any means, just not my style.

And yeah, I'd read Skiena at some point in your progression. Whenever. I've actually read it twice... both times when preparing for really tough job interviews, based on this famous post... and it paid off.

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

Beginner

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.


Intermediate

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.

Advanced

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 Open.gl 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!

I can't speak of a specific book that is a comprehensive history of computing, but I will speak to books that speak of our culture, our myths, and our hero's.

Hackers and Painters, by Paul Graham. People are polarized about the man, whether he's too "pie in the sky" - full of shit and ego, or if he speaks as an ambassador to our most optimistic ideals of our (comp-sci) culture. The contents of this book is a collection of his essays that are inspirational. It made me forego the societal pressures within our culture and reject popular opinion because it is merely popular and just an opinion, which is a virtue no matter who you are, where you are, or what you do. All these essays are on his website, though. If you want to review them, I recommend Hackers and Painters (the essay), What You Can't Say, Why Nerds are Unpopular, and The Age of the Essay; his oldest essays are at the bottom of the page and go up - he writes about what he's thinking about or working on at the time, so you'll see the subject matter change over time. So much of this will have direct application to his middle school and high school life. I cannot recommend this book, and the rest of his essays, enough.

If he wants to get into programming, I recommend The Pragmatic Programmer. This book talks about the software development process. I'm not going to lie, I don't know when best to introduce this book to him. It's not a hard read whatsoever, but it's abstract. I read it in college in my first months and said, "Ok," and put it down. Approaching the end of college and my first couple years in my profession, I would reread it ever 6 months. It's a kind of book that doesn't mean anything, really, without experience, without having to live it, when he has an obligation to his craft, his profession. I tell you about this one since you're asking about books to tell him, because this isn't something someone would normally come up across without being told about it.

The Cathedral and the Bazaar is a telling book about the cultural differences between the proprietary monoliths like Apple and Microsoft, and the Free and Open Source Software communities that back such popular software as Linux (the most popular operating system on the planet, running on all top 500 super computers, most server computers on the internet, and all Android phones) and Chrome(the worlds most popular web browser). Indeed, this book directly reflects the huge cultural battle that was duked out in the field, in the industry, and in the courts from the mid-90s and into the 2000s. It advocates helping the community, contributing to something larger than yourself, and that none of us are as good as all of us. To paraphrase Linus Torvalds(inventor of Linux) "Given enough eyeballs, all bugs are shallow."

It's important to know who the hero's are in our culture, and they are diverse and varied, they're not just computer scientists, but mathematicians, physicists, philosophers, science fiction writers, and more. I would find a good book on Nicola Tesla, since he invented basically everything anyway (Thomas Edison was a great businessman, but a bit of a tosser), Richard Feynman was a physicist who is still celebrated in his field, and he even worked for Thinking Machines, back in the day, which was a marvel of it's time. Seymour Cray founded Cray Supercomputers and they have a lasting legacy in the field, a biography on that would be interesting. A biography on Symbolics and their Lisp Machines will make him yearn to find one still functioning (a rare gem that crops up every now and again, though he can run one in an emulator), and about the "AI Winter", a significant historic era (note: the AI Winter is over, and we are in spring, the history is both compelling and enthralling). Anything Issac Asimov published (in nearly every category of the dewy decimal system) is also compelling, and hardly dated. In fact, he's the originator of a lot of modern sci-fi. Charles Babbage invented the modern computer (though it was entirely mechanical in his day, and it wasn't actually built until 1996-2002) and Ada Lovelace was the worlds first computer programmer. A woman! Speaking of women, and it's worth young men learning this about our history, Grace Hopper was a military computer engineer who invented the term "bug".

And speaking of women, someone I have respect for, especially if your boy wants to get into game development is Sheri Graner Ray's Gender Inclusive Game Design, which may be more appropriate when he's in high school, and I consider it required reading for anyone who wants to enter the gaming industry. The book lays out plainly how video games hyper-sexualize both women, and, for some reason surprisingly to many - men, it's disastrous effects it has for the game industry, the game market, and the gaming community, and insights on how we may combat it. I have seen colleagues (men) become indignant and personally offended at reading this book, but were absolutely humbled when they took the fight to Sheri directly (we had a few phone interviews with her, always fantastic). If your boy found a problem with this book, he would do well to read Paul Grahams essay on keeping his identity small... The subject matter is not a personal attack on the individual, but on the blight, and he would be better served finding himself on the right side of history with this one, it would serve him well if he were to pursue this craft, specifically, but also any forward facing media in general.

And I also recommend some good books on math. Algebra, linear algebra, calculus, and statistics. You can get very far, lead an entire career unto retirement without knowing anything more than arithmetic and basic, basic algebra, but he could only serve himself well if he makes the decision that he is going to like maths and chooses to willfully become good at it. Outside the context of school and terrible teachers, it's actually an enthralling subject. Just get him a copy of Flatland, Flatterland, and Sphereland. Try this. There are books about proofs that break them down into laymen terms so that anyone can celebrate how special they are. My wife has a few on the shelf and I can't remember their titles off hand. Also this, the book is the narrative of some witty laymen who discover a whole branch of mathematics from first principles, the surreal numbers, an extension of imaginary numbers. It's really quite good, but might keep him occupied for a couple years in high school.

I should stop here or I never will.

Start by trying to understand the CSS and HTML on the sites you like going to. If you haven't already, become familiar with the F12 developer tools each browser provides. You'll want to get comfortable with them all because early on you will want to discover why your pages aren't looking the same in one browser to the next. Using the dev tools in the browser you can actually change the way the page is styled by literally changing the CSS in the developer tools. Or you can add styles as well which is GREAT when modifying your own site so you dont have to go back and republish it each time you make a change. IE's dev tools are actually pretty great. You can also simulate older browsers by changing the document/browser mode in the Emulation tab (this isn't perfect btw, but works well for the most part)

Next start using JSFiddle.net or CodePen.io and try to recreate some elements on a site you like. Do this daily, and do not get frustrated. By using the dev tools you can see how they used CSS to get the style you like, and the surrounding divs/spans/p/etc around it. You can also right click on the page and select "inspect element".

Codecademy is GREAT but one thing it doesn't do well is using real world tools since you are using their environment. You will learn far more by manipulating the dom in F12 or using JSFiddle/CodePen. Plus you can post a page you are working on in JSFiddle/CodePen to a forum like this one for help with what you are working on for a lot better discussion.

Another good site to keep in your toolbox is Can I use. This will help you with understanding which CSS can and can't be used for your specific browser support needs. One example that comes to mind is wanting to use text-shadow which isn't supported in IE9.

Because this is a post in a CSS sub, I'm not sure if you are going down the web developer route, but if you are, then continue reading. Otherwise, feel free to skip to the last paragraph.

Next you will want to move on to the final tool in your front end development toolbox you will want to master and that is JavaScript. Learn straight JavaScript first, and avoid mixing in jQuery until you feel like you have a great understanding of how JS works on its own. I believe the JS tutorial on Codecademy mixes jQuery early on, and if you are just starting out you may not realize the difference. Don't get me wrong, learning jQuery is almost as important as learning JavaScript, it's just important to understand it is a library for JavaScript, and as a framework has its uses and limitations. I really liked the JavaScript tutorial on Code School, so that would be a great place to start. It's not free, but I believe they have a free trial. Otherwise everyone will tell you JavaScript: the Good Parts and Eloquent JavaScript (which is online and free) are required reading.

After that you'll want to learn some of the more popular libraries and frameworks for CSS & JS, such as LESS, Sass, jQuery, AJAX, node.js, backbone.js, and Bootstrap to name a few.

After this, then you'll need to decide if you prefer to lean more to the designer side or the back-end developer side. Front-end developers are usually the bridge between the designer and back-end developer.

In my experience though, you fall in to either being an all-in-one or the designer who does front-end work. Learning designer tools like Illustrator and Photoshop will be helpful if you are asked to or need to create your assets. I actually prefer Fireworks (though I hear it is being discontinued) for creating quick assets I couldn't create with CSS instead of Illustrator because its a little less robust and for someone new its much easier to learn. Otherwise if you are going the back-end route you'll probably want to research which server-side language you want to start with like PHP, Ruby, Python, .NET, etc and then what database such as MySQL, MSSQL, etc.

The best advice I can give you though, is don't be a "master of none" web developer. Become a master at CSS before you move to JavaScript. Then become a master at JavaScript before you move to another language, or whichever language you choose next. When I started out I tried to learn CSS, JavaScript, ASP, PHP, jQuery, C#, AJAX, SQL, and a few others because I wanted to get started quickly...along with pressure from the company I worked at. You will get overwhelmed, burnt out, and start making mistakes, or even worse, not get to the bread and butter of the language you are trying to learn.

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
    
    

    Fundementals
    

    
    

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
    
    

    Mentality
    

    
    

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
    
    

    History
    

    
    

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
    
    

    Fundementals
    

    
    

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
    
    

    Databases
    

    
    

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
    
    

    Mentality
    

    
    

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
    
    

    History
    

    
    

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

Yes! Also, quite honestly I don't know that many CS majors who took linear algebra at my school for whatever reason.

Where do you get started?

• If you're the type of person who likes an organized class to learn concepts, consider checking out coursera or other similar websites which offer free online learning courses! Check out their CS offerings and start from the intro.
  
  
• I must be known for spamming this SR with this, but check out CLRS, it pretty much contains most of the "CS math" you need to know for algorithms. As well as pretty much all you need to know about Algorithms and Data Structures for any basic job.
  
  
• REALLY make sure you understand your Algorithms and Data Structures, nearly every interview for a basic position centers around these topics. As well as some others, depending on the company: Bit manipulation, multi-threading, TCP/IP, etc.
  
  
• You want to learn some mainstream language as a lot of other people mentioned: C++, Java, C#, Python are a few that come to mind (though there are more like Ruby!). Side Note: Some people have differing opinions on whether C++ is good to learn as a first language. I don't know C# (but from its apparent similarity to Java) I would say C++ is probably the most difficult language to learn of the four I listed, but I feel that it also provides the most flexibility, because once you understand C++ it's easier to trainsition from C++ to Java, than say Java to C++ (similar for the other languages).
  
  
• Practice! Start working on some Project Euler problems, or other practice problems. Bonus: Someone in another thread mentioned that they made a blog post for each problem they solved and explained every one of their design decisions. This seemed like a bit over the top, but it really is a good practice for an interview and a job! You can even put a link to this on your resume to share.
  
  
• Find an Open Source to contribute to, come up with your own projects and post them on your github! This can show off your skills to a potential employer!
  
  Bonus for programming:
  
  
• When coding alone it's easy to get lost and start "hashing" together code. When you get to big projects, you'll find that this causes a lot of problems (and when working with other people it can cause even more). Some things to keep in mind when coding:
  
  
• Make sure your code is maintainable.
  
  
• Make sure your code is scalable.
  
  
• Test, test, test!
  
  Maintainable kinda means that your code is easy to test, easy to comprehend (by others) and easy to modify. Read up on different design patterns to learn more about this.
  
  Scalable is something you'll learn more about later, but basically it's kind of thinking about whether your code will be "good" enough to handle a lot of users (how fast is it how much memory will it take up)
  
  Testing is very important when coding. You want to try to write small pieces of code then test it (i.e.: make sure it works).
  
  All three of these things show up a lot in interviews, and if you can relate why you made your code the way you did to one of these three points (or something else) you should be pretty well off :D
  
  How do I land an interview?
  
  
• In your resume make sure to list any CS projects you want to mention, a link to your website (if you have one) or to other work. As well as Operating Systems you're familiar with (Linux is a big plus, but not absolutely necessary), IDE's you're familiar with (things like Eclipse, Visual Studios), and Languages you know. If you can, make sure to relate those three bullets to your project and work somehow to reiterate your experience with each language.
  
  
• A lot of recruiting is done on-campus, but there are other options, like applying online or even better...
  
  
• Network your way in. This gets your resume through the massive HR screen
  
  
• Edit, edit, edit (ask friends who are in the industry).
  
  How do I study for an Interview?
  
  Typcially, an interview will have you and the interviewer. The interviewer will first ask questions about you, what you're majoring in. And then maybe ask questions about your previous projects, and then he'll throw you a programming problem. Sometimes these can just be questions like "Which is faster: quicksort or mergsort?" or something like that, but other times they'll have you code something. If the interview is online, this will either mean you'll need to tell them the code you're writing or you'll code online on some collabarative envirionment (i.e.: you type the code online). If it's in-person they may have you write on a whiteboard. There are other formats of interviews as well, so make sure to research. Typically, for most larger companies, they won't care what language you code in (hopefully though it's mainstream!), but if you don't code in a language which they use, they may test you later for proficiency in one of their languages.
  
  
• As I mentioned before, Algorithms and Data Structures are usually go-to's for interviews, but other topics may come up so check out the req's for each job specifically.
  
  
• It may have been a while at this point since you studied your material, to brush up on interview questions, Cracking the Code Interview is a great book to brush up on your topics for an interview, it also has some resume advice, etc. if you choose to follow it.
  
  
• Be sure to practice talking out loud while you're coding, as this can help you during interviews. If you're stuck but your thought process is good an interviewer can help push you in the right direction.
  
  
• If you struggle with interviews, try having a friend who you know has experience and having him ask questions, better yet if you know a friend at the company, ask him to mock interview you.
  
  
• If you have time ALWAYS make sure you run test cases through your code mentally, and mention the test you're running and what it's supposed to catch (expected behavior) to your interviewer! If you have time and choose to ignore these, it can give the interviewer a wrong impression :\ (it also makes you look really good if you come up with all the boundary cases)
  
  Sorry, not sure if this helps or not!
  Good luck!

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: https://www.amazon.com/Introduction-Algorithms-3rd-MIT-Press/dp/0262033844. 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: https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/. 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: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882. 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: https://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601. 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: http://aosabook.org/en/index.html. 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: https://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420/. 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.

It depends on what you already know.

​

Do you have any prior programming experience? If not, start there. My no. 1 recommendation here would be Allen B. Downey's free Think Python book. Others might come along and recommend something like SICP, which is a good book, but perhaps a bit hard for an absolute beginner. Downey also has a version of his book that uses Java, so if you know for a fact that this is the language your introductory programming class will be using, then that could be a better option (Python is a simpler language, which makes it easier for you to focus on the actual concepts rather than the language itself, but if you know that you'll be using Java, you might as well kill two birds with one stone).

​

If you do have prior programming experience, you have all sorts of options:

• You could learn a functional language, like a Lisp (Clojure, Racket, Scheme, LFE, ...) or something in the (extended) ML family (Standard ML, OCaml, F#, Haskell, Elm, ...).
  
• Or, you could go the other way and learn something low-level, like C. You could even learn about C and Lisp at the same time by building your own.
  
• Or learn a logic programming language, like Prolog.
  
• Or, if you really want to understand object-oriented programming (and how languages like Java managed to stuff it up), you could learn Smalltalk.
  
• If you don't know what a unit test is or how to write one, you should learn.
  
• Learn about data structures and algorithms. As a CS student, you'll be learning about them at some stage anyway, so there's no harm in starting early. Some people might recommended CLRS for this, but for someone just starting out, I'd recommend something a bit friendlier, such as this series of videos from Princeton (presented by Robert Sedgewick, author of one of the most popular books on the subject). If you'd prefer a book, this free one from Allen B. Downey (who also wrote the introductory programming text I recommended earleir) looks quite good.
  
• Work your way through NAND2Tetris. It will take way longer than a month, but it will definitely set you apart from the rest of the class. Even if you don't do this now, you should definitely plan to do it at some point.
  
• Learn about databases. Again, you'll have to study them eventually, so why not start early? You could start by trying to build something that uses a database, like a simple todo utility.
  
  ​
  
  Regardless of whether or not you have programmed before, I would also recommend doing the following:
  
  
• Learn some basic Unix skills. It doesn't have to be too much – just enough to be able to sit down at the command line and have a vague idea of what you're doing is fine for now. You'll learn more as you use it more. That said, if you really want to dive in and learn how everything works, then something like How Linux Works could be a good read.
  
• Learn some discrete mathematics. As a CS student, you'll be required to learn it at some stage – it's the mathematical backbone of CS, much like calculus is to physics – so you might as well start early. This free, book-length set of notes from MIT is very well-regarded (but don't expect to get through it all in a month!). There is also a set of video lectures if you prefer. If you're keen on learning functional programming, another option could be to integrate that with your discrete maths studies by reading Thomas VanDrunen's Discrete Mathematics and Functional Programming (if the physical book is a bit expensive for you, there's also a cheaper ebook version available).
  
• For bonus points: learn to use either Vim or Emacs. There probably isn't a massive practical advantage to using these this early in your career (although they could certainly come in handy later), but if other students see you writing code in one of them, you'll look like an absolute badass. Your teachers will probably be quietly impressed, too.
  
  ​
  
  if you have any questions about my above suggestions, let me know, and I'll see if I can point you in the right direction.
  
  ​
  
  Good luck!

Good on you for looking to grow yourself as a professional! The best folks I've worked with are still working on professional development, even 10-20 years in to their profession.

Programming languages can be thought of as tools. Python, say, is a screwdriver. You can learn everything there is about screwdrivers, but this only gets you so far.

To build something you need a good blueprint. For this you can study objected oriented design (OOD) and programming (OOP). Once you have the basics, take a look at design patterns like the Gang of Four. This book is a good resource to learn about much of the above

What parts do you specify for your blueprint? How do they go together? Study up on abstract data types (ADTs) and algorithms that manipulate those data types. This is the definitive book on algorithms, it does take some work to get through it, but it is worth the work. (Side note, this is the book Google expects you to master before interviewing)

How do you run your code? You may want to study general operating system concepts if you want to know how your code interacts with the system on which it is running. Want to go even deeper with code performance? Take a look at computer architecture Another topic that should be covered is computer networking, as many applications these days don't work without a network.

What are some good practices to follow while writing your code? Two books that are widely recommended are Code Complete and Pragmatic Programmer. Though they cover a very wide range (everything from organizational hacks to unit testing to user design) of topics, it wouldn't hurt to check out Code Complete at the least, as it gives great tips on organizing functions and classes, modules and programs.

All these techniques and technologies are just bits and pieces you put together with your programming language. You'll likely need to learn about other tools, other languages, debuggers and linters and optimizers, the list is endless. What helps light the path ahead is finding a mentor, someone that is well steeped in the craft, and is willing to show you how they work. This is best done in person, watching someone design and code. Also spend some time reading the code of others (GitHub is a great place for this) and interacting with them on public mailing lists and IRC channels. I hang out on Hacker News to hear about the latest tools and technologies (many posts to /r/programming come from Hacker News). See if there are any local programming clubs or talks that you can join, it'd be a great forum to find yourself a mentor.

Lots of stuff here, happy to answer questions, but hope it's enough to get you started. Oh, yeah, the books, they're expensive but hopefully you can get your boss to buy them for you. It's in his/her best interest, as well as yours!

Programming is a tool. I suggest finding another interest that you can apply it to. Robots, graphics, music, animation, sports, economics -- the possibilities are endless. Pick your favorite area, look at what kind of problems there are in that area that people use programs to solve, figure out how those sorts of programs work, and try to solve some of those problems yourself.

A few interesting examples:

• Project Euler has a set of challenges relating to both math and computer science that will stretch you to learn more about both.
  
• Python Challenge is basically a series of puzzles that challenge you to do new and interesting things with Python. Granted, several of the puzzles are quite similar and some of the libraries they reference are deprecated, but it's a place to start for programming challenges.
  
• Programming Computer Vision With Python talks all about using programs to do things like find objects in pictures and track them even at different sizes and angles. Lots of great examples.
  
• Programming Collective Intelligence talks about putting together data from different sources (primarily websites) and finding patterns. It deals with many machine learning concepts in ways that are practical and interesting. Things like modelling and predicting, optimizing, clustering (finding similarities), searching and ranking, and pattern recognition.
  
• Arduino Robotics describes many robots you can build with relatively common parts that can be programmed using the inexpensive, C-based Arduino microcontroller platform. I've made several of these myself.
  
• Digital Signal Processing is all about writing software that takes advantage of advanced math to manipulate signals in many ways. It's invaluable for audio, but you see it used with graphics, digital communications, and many other areas.
  
• There is a subset of sports fans that really enjoy statistics and software can be very valuable for them. Things like comparing players across eras, predicting future performance, and helping to find high-value players. The general field is called Sabremetrics. I looked deep into it in relation to major league baseball. Two books that I found valuable are The Book: Playing the Percentages in Baseball and Baseball Between the Numbers.
  
• Programmable games are cool too. Things like CROBOTS, CoreWar, RoboWar, and Robot Game. It's just as fun building the simulation environment as it is building the bots that compete within them.
  
• Pick up any book on algorithms. Learn to apply the basics like binary search, insertion sort, radix sort, memoization and linear programming, Dijkstra's algorithm, and Newton's method for root finding.
  
• Grab another book on data structures. Make sure you understand the differences between arrays, linked lists, hash tables, and trees. Learn about unique and useful things like binary trees, radix trees, heaps, and queues.
  
• Learn how to write better code. I recommend books like Code Complete and The Pragmatic Programmer.
  
  Whatever you do, as you clearly pointed out, you have to be interested in it or you'll grow bored and give up. Find something that is interesting to you and pursue it as wide and deep as you can.

Your mileage with certifications may vary depending on your geographical area and type of IT work you want to get into. No idea about Phoenix specifically.

For programming work, generally certifications aren't looked at highly, and so you should think about how much actual programming you want to do vs. something else, before investing in training that employers may not give a shit about at all.

The more your goals align with programming, the more you'll want to acquire practical skills and be able to demonstrate them.

I'd suggest reading the FAQ first, and then doing some digging to figure out what's out there that interests you. Then, consider trying to get in touch with professionals in the specific domain you're interested in, and/or ask more specific questions on here or elsewhere that pertain to what you're interested in. Then figure out a plan of attack and get to it.

A lot of programming work boils down to:

• Using appropriate data structures, and algorithms (often hidden behind standard libraries/frameworks as black boxes), that help you solve whatever problems you run into, or tasks you need to complete. Knowing when to use a Map vs. a List/Array, for example, is fundamental.
  
• Integrating 3rd party APIs. (e.g. a company might Stripe APIs for abstracting away payment processing... or Salesforce for interacting with business CRM... countless 3rd party APIs out there).
  
• Working with some development framework. (e.g. a web app might use React for an easier time producing rich HTML/JS-driven sites... or a cross-platform mobile app developer might use React-Native, or Xamarin to leverage C# skills, etc.).
  
• Working with some sort of platform SDKs/APIs. (e.g. native iOS apps must use 1st party frameworks like UIKit, and Foundation, etc.)
  
• Turning high-level descriptions of business goals ("requirements") into code. Basic logic, as well as systems design and OOD (and a sprinkle of FP for perspective on how to write code with reliable data flows and cohesion), is essential.
  
• Testing and debugging. It's a good idea to write code with testing in mind, even if you don't go whole hog on something like TDD - the idea being that you want it to be easy to ask your code questions in a nimble, precise way. Professional devs often set up test suites that examine inputs and expected outputs for particular pieces of code. As you gain confidence learning a language, take a look at simple assertion statements, and eventually try dabbling with a tdd/bdd testing library (e.g. Jest for JS, or JUnit for Java, ...). With debugging, you want to know how to do it, but you also want to minimize having to do it whenever possible. As you get further into projects and get into situations where you have acquired "technical debt" and have had to sacrifice clarity and simplicity for complexity and possibly bugs, then debugging skills can be useful.
  
  As a basic primer, you might want to look at Code for a big picture view of what's going with computers.
  
  For basic logic skills, the first two chapters of How to Prove It are great. Being able to think about conditional expressions symbolically (and not get confused by your own code) is a useful skill. Sometimes business requirements change and require you to modify conditional statements. With an understanding of Boolean Algebra, you will make fewer mistakes and get past this common hurdle sooner. Lots of beginners struggle with logic early on while also learning a language, framework, and whatever else. Luckily, Boolean Algebra is a tiny topic. Those first two chapters pretty much cover the core concepts of logic that I saw over and over again in various courses in college (programming courses, algorithms, digital circuits, etc.)
  
  Once you figure out a domain/industry you're interested in, I highly recommend focusing on one general purpose programming language that is popular in that domain. Learn about data structures and learn how to use the language to solve problems using data structures. Try not to spread yourself too thin with learning languages. It's more important to focus on learning how to get the computer to do your bidding via one set of tools - later on, once you have that context, you can experiment with other things. It's not a bad idea to learn multiple languages, since in some cases they push drastically different philosophies and practices, but give it time and stay focused early on.
  
  As you gain confidence there, identify a simple project you can take on that uses that general purpose language, and perhaps a development framework that is popular in your target industry. Read up on best practices, and stick to a small set of features that helps you complete your mini project.
  
  When learning, try to avoid haplessly jumping from tutorial to tutorial if it means that it's an opportunity to better understand something you really should understand from the ground up. Don't try to understand everything under the sun from the ground up, but don't shy away from 1st party sources of information when you need them. E.g. for iOS development, Apple has a lot of development guides that aren't too terrible. Sometimes these guides will clue you into patterns, best practices, pitfalls.
  
  Imperfect solutions are fine while learning via small projects. Focus on completing tiny projects that are just barely outside your skill level. It can be hard to gauge this yourself, but if you ever went to college then you probably have an idea of what this means.
  
  The feedback cycle in software development is long, so you want to be unafraid to make mistakes, and prioritize finishing stuff so that you can reflect on what to improve.

Cost? - FREE

Here is the info but if you need more than that, you can always pm me your questions and if you want me to actually help you as in actually putting together pages and configuring settings, then we can talk about a fee but for now the following info should help a lot.

First you should know I am advocating using wordpress. Some people are not good with it and are worried about that factor. So here are some guides and stuff to learn it.

WordPress Guides

Some guides are created for helping people out. Some are free and some are not. Some are actual manuals and some are video tutorials that get embedded into the dashboard of the website, which I find to be pretty handy.

Free

• Easy WP Guide (PDF and Word - free)(brandable)
  
• WordPress User Guide (PDF low quality - FREE)
  
  
  Paid
  
  
• WordPress User Guide (PDF high quality - $6, Editable Word Doc - $40)
  
• Video User Manuals (video in dashboard - $24/mo )
  
• WP101 (video in dashboard - $19/mo)
  
• Integrated Video Tutorials by WMPU DEV (videos in dashboard - Need a Membership to Use - white label - hosted on their server - always kept up to date)
  
  Now that you have that here is some info on how to build a website.
  
  This is in answer to people consistently asking how to get a website built.
  
  Validate Your Skill Level
  
  Are you currently a web programmer? If no, please do not attempt to become one to code your own dynamic website as security is a huge issue and it will take you years to catch up. It is not a reasonable effort to put forth if you want to keep your sanity, not burn your spare time, etc. Not saying you can't learn it, just saying it takes a lot of work and time that most entrepreneurs don't have to use and in some cases waste.
  
  You can learn how to do html and css within a few months but using a CMS system is much cleaner and easier and if you need something dynamic, you will probably need a developer.
  
  You generally need to know at least php and mysql for dynamic websites unless you want to get into the confusing worlds of joomla and drupal (non exhaustive list of alternatives: Python & Django, Node and ExpressJS, Python and Flask, Python & Pylons, Ruby & Sinatra). I hear decent things about Ruby on Rails though on par with php and mysql learning curve I think.
  
  Want to Learn Web Programming Anyway?
  
  Try CodeCademy for interactive programming learning.
  
  No Coding Skills Start Here
  
  Get / Use the following:
  
  
• Hosting: Bluehost.com
  
• Domain name: Buy through Bluehost and get a privacy option on it
  
• Web Platform to one click install: WordPress a CMS platform
  
• Find an appropriate responsive wordpress theme here: Themeforest.net
  
• Install and configure these free plugins in order: Better WP Security, BackWPup, Akismet, Yoast, Broken Link Checker, FirmaSite Theme Enhancer, Growmap Anti Spambot Plugin, Date/Time Now Button, and Advanced Responsive Video Embedder
  
• Buy other plugins you need here: CodeCanyon.net
  
• Need an affiliate manager?: Use Linksert.net and it's free WordPress plugin.
  
  Need Something More Dynamic?
  
  You have a few options. This list goes from least expensive to most expensive. Just know that most things you want to do already have a plugin or theme designed for them for WordPress. There are however a lot of exceptions to that guideline and that is why you look at the following options.
  
  
• Least Expensive end
  
• Hire someone to develop a WordPress plugin to do that dynamic stuff (cheaper than second option)
  
• Hire someone to build you a custom WordPress theme that has the functionality you need.
  
• Hire someone to develop the site from the ground up.
  
• Most expensive end
  
  The reason why WordPress is mentioned a lot is because it is a CMS aka Content Management System which allows you to manage a ton of the pages and posts and various other aspects of the website. If a developer really needs to, they can modify the core parts of WordPress. Rarely will you need someone to build you a brand new website and honestly you really do want a CMS or you are going to have a hard time.
  
  Some developers can be found here: Elance (freelancers), Matchist (freelancers), and Glowtouch (dev company vetted by Bluehost)
  
  Things to remember with website development
  
  
• Try to use a responsive website themes and plugins so that it can fit any screen size including tablets and phones.
  
• Get familiar with what they call "sticky footer" so that your footers don't end up halfway up the screen on low content pages. Example and info.
  
• Get familiar with the concept of having a fixed header as it will promote a lot of use of your website. Example and info.
  
• Design is important. You have ~2.6 seconds to capture their attention before they bounce. Read this book to learn about it: "Don't Make Me Think"
  
• Best colors to use for design and other design tricks (the best you are going to find): Article and Video
  
  I am actually putting together a series on how to build a website that will be fairly extensive. If you would like to be notified of that you can sign up here and I will send you a message when it's ready.

Oh god where to begin?

***

Well I Like to think there are level of programming understanding that are relatively tiered.

Tier 1 - How to Code

***
This one is tough as there is no real definitive best answer. My personal primer of choice is

• Sams Learn Java in 24 hours.
  
  > Fyi - , that is not "in one day" that is , in 24, 1 hour sessions equating to a hypothetical 4 college lectures a week lasting a month and a half of intensive training. A huge amount of homework is required to accompany that primer.
  
  so now you can write an app, what next? well. to finish the thought:
  
  
  

  Tier 2 - How to Code...
  

  so other programmers don't want to hit you over the head for each line in your longest function screaming CYCLOMATIC COMPLEXITYYYY
  
  **
  
  Here we talk about how to program properly* You want to be looking up Uncle Bob . Head over to
  
  

• www.cleancoders.com
  
  and check out his video form of his famous book:
  
  
• Clean Code....then buy that book.
  
  Now you should be writing code that doesn't make other programmers eyes bleed.
  
  

  Tier 3 - How to Code..To Solve Problems
  

  ***
  Here we talk about design patterns. Now, you will bump into a lot of debate over their value but...that is stupid. that is like some people saying all carpentry should be done with a saw and another group saying carpenters should never use a saw. Design patterns are names for recognised ways to solve problems you will hit every day in your programming. They may not always work in your case but at worst they will have you thinking around a problem better.
  
  For a primer, check out:
  
  

• Head First: Design Patterns
  
  In fact the entire head first series is great, It is like the For dummies series for programming principles. Great for morons like myself.
  
  With that read, get the real design pattern book:
  
  
• Elements of Reusable...
  
  Don't expect to actual understand almost any of this. I read that book cover to cover and it didn't actual click for me till it slapped me in the face when i was in the real world developing business tier applications. Although having read it so many times meant I new which pages to flip to when I was ready.
  
  

  Tier 4 - How to Code... For Users
  

  ***
  
  This is a whole different kettle of fish. Now you may have written the perfect app to do X with only two buttons, you will find quickly that users are adept at licking the buttons in just the correct order to cause your application to explode. You need to program applications so the cast of jersey shore can use it.
  
  I am a fan of the blog:
  
  

• Joel on Software.
  
  Joel (Co-founder of Trello) covers a lot regarding front facing applications and UX that is required reading...even if he a bit cavalier on his approach to testing.
  
  This is the next part. Testing. You are going to want to Learn about Defensive Programming andTesting. There is a wealth of tutorials over on pluralsight for these.
  
  

  Tier 5 - When NOT to Code
  

  
  **
  
  This is a hard step to get to. Realising that copy and pasting code is GREAT!..but for the right reasons. Once you jump over the initial Copy+paste = the greatest thing in the world barrier , most developers grow a level of defiance that borders on the absurd. Preferring to rewrite the wheel instead of using ...the wheel. When you can honestly say you could* program it from scratch, it is perfectly okay to use libraries and apis.
  
  This is where I go to:
  
  

• www.codeproject.com
  
  and hit up Sacha and others. They show you fairly feature complete and interesting implementations of problems, not just the one or two lines you get from Stack Overflow. Granted this is miles more complicated but it shows not only how to do it, but how to do it right and WHY to do it right. and github of course.
  
  

  Tier 6 - Learning From Mistakes
  

  ***
  
  Now that you have climbed code mountain and are absorbing the combined knowledge of all the internet geniuses, it is time to see where you went wrong.
  
  Head over to
  
  

• http://codereview.stackexchange.com/
  
  and post you functional applications. There a number of people will politely tell you not...how but how to do it better, general improvements in design, logic and reusability. take you through the solid principles and much more. Also..say hello to me if you like :P.
  
  You don't even have to learn exclusively from your own mistakes.
  
  check out:
  
  
• www.thedailywtf.com
  
  and cringe at some examples of real software....and if you don't understand why you should be cringing..learn.
  
  ***
  
  

  Tier 7 - How to think like a programmer
  

  
  Now things get a little bit meta. The best way to become a great programmer? don't JUST read programming. Read books like:
  
  

• Zen and the Art of Motorcycle Maintenance
  
  
• Don't Make Me Think
  
  Read anything and everything, exercise your mind. books on architecture, books on carpentry. any kind of design and problem solving with stretch your understanding of how to climb those brick walls you will hit.
  
  Read some of the more general programming blogs, like:
  
  
• http://blog.codinghorror.com/
  
  Read anything and everything.
  
  

  Final Thoughts
  

  ***
  
  Have fun.
  
  Check out:
  
  

• www.commitstrip.com
  
• www.xkcd.com
  
  and..well..here.
  
  I would also say as a personal suggestion, although i left it out of the mandatories up above as it is a bit controversial, I suggest going TDD. Test driven development. It is not for everyone, a hard ethos to get into but in the real world, in business applicable coding...a life saver. Uncle bob is the man for that again.
  
  Finally I am a fan of Rubber Ducking. Great way to work though problems.
  
  If you want some final reading, I left them out because everyone and their brother has these (and most of the above) in their top 50 programming book lists so it is a mite redundant:
  
  
• Code Complete
  
• The Mythical Man Month
  
• The Pragmatic Programmer
  
• Refactoring: Improving the Design of Existing Code
  
  ***
  Enjoy.
  
  
  
  

Something like Code: The Hidden Language of Computer Hardware and Software may be up your alley.

So may be From NAND 2 Tetris, a course where you build a computer (hardware architecture, assembler, OS, C-like compiler, and programs to run on the OS / written in the compiler) starting with just NAND.

At the end of the day though, the way things work is like this: Protocols and specifications.

Everything follows the same published IPO (input, processing, output) standards. Stuff is connected to and registers expected values on expected peripherals. The CPU, motherboard, graphics card, wireless modem, etc. all connect in the right, mostly pre-ordained places on the hardware.

In this vein, there's firmware level APIs for then communicating with all of these at the BIOS level. Although as far as I'm aware, "actual" "BIOS" is no longer used. UEFI is instead: https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface

This is what Firmware is / is built on-top of. Operating systems build on top of these. System calls. Operating systems communicate under the hood and expose some number of system calls that perform low-level actions like talking to devices to perform things like file access or network I/O. A lot of this stuff is asynchronous / non-blocking, so the OS or system will then have to respond to an interrupt or continuously check a registry or some other means of getting a response from the device to see if an operation completed and what its result was.

Loading the OS is one thing the BIOS is responsible for. This is through the bootstrapping process. The OSs are located at very specific locations on the partitions. In the past, the only command you had enough room for within BIOS / pre-operating system execution was to load your OS, and then the OS's startup scripts had to do everything else from there.

Once you have an operating system, you can ask the OS to make system calls and invoke low-level API requests to get information about your computer and computer system, such as the file system, networks, connected drives and partitions, etc. These calls are usually exposed via OS-specific APIs (think the win32 API) as well as through a command-line interface the OS provides.

New devices and I/O from/to those devices communicate through firmware, and interrupts, and low-level system calls that are able to communicate with these firmware APIs and respond to them.

Just about anything you can think of - graphics, audio, networking, file systems, other i/o - have published standards and specifications. Some are OS-specific (X windowing system for Linux, DirectX win32 API or GDI on Windows, Quartz on Mac, etc.). Others are vendor-specific but don't seem to be going anywhere (OpenGL, then nVidia vs AMD driver support which varies across operating systems, etc.).

The biggest hardware vendors and specification stakeholders will work with the biggest operating system vendors on their APIs and specifications. It's usually up to device manufacturers to provide OS-compatible drivers along with their devices.

Drivers are again just another specification. Linux has one driver specification. Windows has another. Drivers are a way that the OS allows devices and users to communicate, with the OS as a middle-manager of sorts. Drivers are also often proprietary, allowing device manufacturers to protect their intellectual property while providing free access to use their devices on the OS of your choice.

I'm not an expert in how it all works under the hood, but I found comfort in knowing it's all the same IPO and protocol specifications as the rest of computing. No real hidden surprises, although a lot of deep knowledge and learning sometimes required.

When we get to actually executing programs, the OS doesn't have too much to work with, just the hardware... So the responsibility of slicing up program execution into processes and threads is up to the OS. How that's done depends on the OS, but pretty much every OS supports the concept in some sense.

As far as how programs are multi-tasked, both operating systems and CPUs are pretty smart. Instructions get sent to the chips, batched and divided by them and the computational results placed into to registries and RAM. Again, something I'm not a huge expert in, and it honestly surprised me to find out that the OS is responsible for threading etc. I for some reason always thought this was at the chip level.

When you include libraries (especially system / OS / driver libraries) in your code, you're including copies of or references to OS native functions and definitions to help you reference these underlying OS or system calls to do all the cool things you want to do, like display graphics on the screen, or play audio. This is all possible because of the relationship between OS's and device manufacturers and the common standards between them, as well as the known and standard architectures of programs designed for OS's and programs themselves.

Inter-program compatibility is where many things start to become high level, such as serialization standards like JSON or XML, but not always. There are some low-level things to care about for some programs, such as big- vs little-endian. Or the structure of ASM-level function calls.

And then you have things like bitcode that programs like Java or JavaScript will compile to, which are a system-independent representation of code that most often uses a simple heap or stack to describe things that might instead be registry access or a low-level heap or stack if it had been written in ASM. Again, just more standards, and programs are written according to specifications and know how to interface with these.

The modularity of programming thanks to this IPO model and the fact that everything follows some standards / protocols was a real eye opener for me and made me feel like I understood a lot more about systems. What also helped was not only learning how to follow instructions when setting up things on my computer or in my programs, but learning how to verify that those instructions worked. This included a lot of 'ls' on the command-line and inspecting things in my debugger to ensure my program executed how I expected. These days, some might suggest instead using unit tests or integration tests to do the same.

I would like to encourage you a little and liberate you from the thought that a good designers must "be creative" (i.e., good at making things look pretty).

Form and function. Web design is primarily about function (i.e., problem solving). Form plays a lesser role and can be highly subjective. As a general principles, so long as form does not hinder function and is not needed to communicate a particular message (e.g., elegance, happiness, anger, etc.), then good-enough form is good enough.

Consider Craigslist. It's an ugly website. It's not going to win any good-looks awards. Yet, people are not leaving in droves because it solves a problem (i.e., post, search, and review classifieds) and does so well.

On the flip side, there are many beautiful websites that are functionally defective.

Good designers solve problems. If you want to learn good design, I'd recommend a few courses:

• Graphic Design Specialization [Coursera]
  
• Interaction Design Specialization [Coursera]
  
• Game Design Specialization [Coursera]
  
• User Experience Research and Design MicroMasters [edX]
  
• Intro to the Design of Everyday Things [Udacity]
  
  You can take all of these courses and specializations for free. (Make sure you select the free option if that's your preference.) They will help you learn "design thinking" from three different perspectives.
  
  A really good book on usability (function) with wide applicability is Don't Make Me Think by Steve Krug. A good book on graphic design basics is The Non-Designers Design Book by Robin Williams.
  
  Sadly, most web "design" books focus on teaching HTML, CSS and JavaScript rather than design, so I can't provide any good resources specifically on web design. (Maybe others can fill that void.)
  
  However, the benefit of approaching design from a variety of perspectives and in a variety of contexts is that it helps you learn how to "think design." Seeing design thinking play out across areas reinforces the basic design principles and practices and makes it easier to apply them to web design.
  
  If you are more interested in form, then I'd recommend looking into studio art classes (e.g., drawing, painting, photography, digital imaging, etc). (Alternatively, you could follow courses on YouTube for these.) While these sometimes focus more on technique, they'll help you learn how to dissect what you see. You'll learn to see objects as shapes, lines, textures, shades, hues, etc. Combine that knowledge with good technique (e.g., drawing, HTML/CSS, Photoshop, etc.), and it becomes easy to make things look nice.
  
  Also, don't neglect creativity. One of the best books on creativity that I've ever come across is Sparks of Genius: The Thirteen Thinking Tools of the World's Most Creative People. While it's a long read, it provides you with some great tools to use to "spark" creative thought.
  
  Hope that helps.

A Word of Caution on Inspiration Galleries

Seeking inspiration (ideas) is perfectly acceptable, but it must be done so cautiously. Too often, people fall into the trap of simply copying the sources of inspiration because it looked nice.

Instead, it's helpful to study the source of inspiration. Which components are interesting? Why were they used? What problem was the designer attempting to solve with them? Once you understand why those components were used, then you are better positioned to decide if they help solve your design problem.

It's also helpful to remember that no two design problems are the same. Sure, you're a bank and we're a bank, but we have different needs, target different audiences, have different value propositions, different brands, and so on. Thus, our design solutions will necessarily differ.

Some Helpful Resources

As for helpful resources, I would start with a video from Flint McGlaughlin on the inverted marketing funnel. You're probably already familiar with the funnel concept from marketing, but he describes it as fulfilling a sequence of "micro yes" points. If you have a good understanding of how the user moves through these "micro yes" moments, then it can help you decide where to choose and place elements on a page. For example, should your call-to-action be above the fold? Do you need pictures? Are stock photos okay? And so on.

Going more in-depth, I would recommend looking to The Elements of User Experience by Jesse James Garrett. You can find lecture videos from him on YouTube covering the ideas.

Another book on the essential reading list is Don't Make Me Think, Revisited by Steve Krug. It's a fantastic book on usability and user experience.

For a slightly more graphic design bent, although still applicable, I would recommend The Non-Designer's Design Book by Robin Williams. It will help you understand the basic components of graphic design which can be applied to web design.

What all these resources do is give you a basic framework through which you can make better design decisions.

Design is fundamentally about problem solving. You are not creating a design simply for the sake of the "design." You are creating a design to accomplish some goal. This is true of graphic designer, web design, user experience design, interaction design, and even industrial design.

>Why is it so hard to figure out where to start?
>
>It's no secret that software development has exploded in the past 20 years. New software startups pop up like dandelions in the spring. It then follows that a lot of people think software development is a good career choice and are afraid of missing out on a lot of great opportunities.
>
>Software developers are, in general, pretty opinionated. I doubt this is unique to developers, but it gets tiresome when you've dealt with it for years. If we're not fighting over what operating system is better, then it's what language is better. If it's not that, then it's code editors, or databases, or frameworks, or bug trackers, or development processes, or...or...or. It's like we enjoy fighting.
>
>In a time where more and more people are becoming developers, it's not enough to be just "a developer" anymore. No, to feel superior now, developers need to somehow differentiate themselves from both the non-developer “rabble” and their fellow developers.
>
>This mentality has lead to more coding languages being developed that purport to "fix" issues with other languages. New frameworks are built to "fix" issues with previous frameworks. And on and on.
>
>All this leads to a huge amount of choices, opinions, and resources. Naturally, that makes starting to learn, daunting.
>
>Since I'm a developer too, I'm susceptible to the same opinions and biases that I just railed against. The difference is, I'm right. I'm kidding, seriously, calm down everybody. Here are my suggestions.
>
>Choose your weapon language
>
>As someone once said: “the weapon doesn’t make the man.” It’s probably a quote from some B martial arts movie or Dragonball Z, but the philosophy holds true for programming languages. A good developer is a good developer regardless of language. However, you need to start someplace, and if you pick your first language wisely, you’ll drastically shorten the time to hit your goal.
>
>Picking a language boils down to what you want to do. This is a quick list of general development goals and what language(s) are your best options to get there:
>
>1. Front-end web development (user interface and interaction): Javascript, HTML & CSS
>1. Back-end web development (services that front-end web apps and mobile apps call out to): Ruby, Python or Javascript
>1. Mobile development: Swift (iOS) or Java (Android)
>1. Windows development: C#
>1. MacOS development: Swift or Objective-C
>1. Operating systems, file systems, embedded systems, etc: C/C++
>
>Naturally, there are other options for each of these. Javascript is useful for items 1-5, for instance. But the list is a good starting place as-is.
>
>How to find good resources to start learning
>
>There are a ton of resources to learn to code out on the web. How do you sift through the chaff and find the real gems?
>
>Most resources fall into the following categories:
>
> Books
> Videos
> Blogs/tutorials
> Courses
>
>Books are the traditional go-to resource. Search Amazon.com for your topic and read reviews. Make sure that any books you're considering are new. Languages change and older books could slow your progress.
>
>A lot of people have gravitated to videos to learn coding and other topics. YouTube is the first place most people look. Fair warning, this is going to turn up a bunch of crap. Look at how many subscribers a given instructor has, and watch some videos to see if their style and method works for you. Another possible issue is that because video is more difficult to update for new versions of a language (or corresponding tools), some videos might be outdated.
>
>For blogs and tutorials, a simple google search like "best python tutorial" or "best swift tutorial for beginners" is a great place to start. As with videos, you'll have to try a few to see how they work with your learning style.
>
>Online courses are the newest resource on the scene. Codecademy is one that a lot of people find immediately. However, after I talked to a lot of people who tried it, none really thought it did a good job. Free Code Camp or The Odin Project are both highly regarded for web development. Udacity, Coursera, Udemy all have courses in different genres. Each has reviews so you can compare and only look at ones that helped others. My specific examples follow in the next section.
>
>Where you should start, specifically
>
>Each development goal in the above list is different enough to require different starting points. I’ll list the place that I’d recommend you start for each one. I have not personally tried all of them, but have come across them when doing research. There also might be better ones, and so if you know of any, let me know and I’ll update this list.
>
>1. Front-end web development: Free Code Camp
>1. Back-end web development: Ruby (for Rails), Python (for Django), Javascript (for Node)
>1. Mobile development: Swift Lynda’s Swift Essentials (check your local library to see if you get a free Lynda account with a library card) or Flatiron school’s free Swift course, Swift Programming book or Java Head First Java, University of Helsinki’s MOOC
>1. Windows development: Head First C#, Pluralsight’s C# course
>1. MacOS development: Cocoa programming for OS X, or the same courses for mobile Swift
>1. Operating systems, filesystems, embedded systems: C++ How to Program book, C++ Tutorial for Complete Beginners
>
>Once you pick your language and starting point and you start learning, some things will be obvious, but others will be difficult to understand. You’re going to run into trouble and with concepts and code errors. That’s normal. We’ve all been there. Getting unstuck takes practice too.
>
>How to get unstuck once you’ve started
>
>Once you start learning to code, you're going to run into problems that you don't know how to solve. This is normal and part of the process. You don't really learn unless you struggle through it. That said, you won't always be able to move forward without some help. So how do you find that help?
>
>First off, forget books. They aren't a great place to start here, because the number and types of errors they can cover is so small.
>
>Online is the easiest place to find help. Most devs look for solutions on StackOverflow or just google the error message (if they have one). Other solutions are to find newsgroups or forums dedicated to the language you're using.
>
>How to use Google to get unstuck
>
>When you first try to google an answer to your problem, you're going to run into the issue of what to search for. Experienced developers are really good at this part, but unfortunately, it's hard for beginners, who need it the most. So here I'll give you some expert hints on how to improve your search results.
>
>1. Always include the name of the language you're using. If you're using a specific tool, database, or framework, include that as well. Don't include all of them, just the ones that you believe are relevant. This will take practice.
>1. If you're getting an error message, include that in quotes. Edit the message to contain only the core of the message so it doesn't reference any files, classes, path or filenames that are specific to your program or computer. The trick here is to make the error message as specific as possible while still being general enough to apply to others who are using the same language/tool/etc. but in a different context.
>1. If you're working through a publicly-published problem from a book or course, add that information to the search.
>1. Explain what you're trying to do, with the fewest words. This is tough for developers of all levels. For a beginner, you may have trouble coming up with the right terminology. This is where the books, tutorials, and course materials come in handy. They should use the right language if you're doing something similar to what's covered in them. If not, you're going to need to try some different wording. Remember, other beginners are going to be having problems too and might explain the problem the same way.
>
>Here are a few examples I’ve used (minus the quotes):
>

I've been self-teaching myself C through various books/courses/series the last few months (I'm still not that great), and so I have some suggestions about good places to start learning.

Books:

• The C Programming Language AKA "K&R" by developers of C - It's short/concise and simple, but covers the whole language (because there's not that much syntax to cover), and tons of people swear by it like a bible.
  
• C Programming: A Modern Approach by K. N. King - This book is much larger and more in depth than K&R, with around 800 pages and lots of examples and exercises. It's essentially a college textbook and is actually used in colleges.
  
• Learn C the Hard Way by Zed Shaw - This one is free and online. I like it because it focuses more on you figuring out things on your own by breaking the code in various ways and having an absolute understanding of every line, rather than just having you copy everything and telling you how it works
  
  Courses/Videos:
  
  
• [Harvard CS50x](https://www.edx.org/course/introduction-computer-science-harvardx-cs50x) - An awesome, free online course with high production lectures, and helpful videos/tips if you get stuck. It mostly covers C, but it does go into other things (that are still worth knowing) at the very beginning and end.
  
  
• A Free Course for C Beginners by Carl Herold - Not really a full course, just most of the videos. I found this very recently, and the original website doesn't exist anymore. It goes at a very relaxed pace and explains things incredibly well in a way that you will remember. These videos really solidified/helped my understanding of binary, hex, and pointers. I highly, highly recommend it over anything else if you're just starting out.
  
• Handmade Hero by Casey Muratori - You can watch and follow along with this guy as he programs a video game from scratch in C. He streams every weekday, usually has a Q&A after, and puts every video up on YouTube. The series starts off with a sort of rushed intro to C, and honestly the whole thing is always at a fast pace and can feel complicated. But that's what it takes to make a game from scratch, and he takes time to explain what everything means. Plus it's mostly all very interesting and useful.
  
  Resources:
  
  
• Google - google everything, or Bing it, I don't care
  
• Stackoverflow - someone probably asked your question before, especially with C
  
• /r/dailyprogrammer - Great daily challenges. These are like working out your programming muscles.
  
• /r/learnprogramming - Occasional posts about C, and you can ask/find your questions here as well
  
• Online C Compiler - A convenient compiler that you can use anywhere to play with simple programs using C standard library functions.
  
  Other than that, you should maybe look into trying out Linux, because it's more developer-friendly than Windows (such as having a C compiler out of the box). And the whole kernel and many core components of the OS are written in C, which are all usually open source, so you can learn from, and contribute to them.
  
  Good luck, friend.

That's an interesting pattern you have going on there. I don't know what kind of background you're coming from, but one of the nice things about Python is that, being dynamically typed, you can pass almost anything to a function at run-time.


What that means is, you can have a function like a spell that expects a character object, whether it's p1 or p2 is irrelevant. It holds the logic of how to access the object and alter the attributes. There's a LOT that goes into how you design that, but that's a thing that literal books have been written about.


So, as a brief example, you might do something like this:

def fire_spell(target):
target.spell_hits('fire', damage=2)
return target

class Character:
def init(self, name, health=10, mana=10, immunity=None):
self.name = name
self._health = health
self._mana = mana
self._spells = {
'fire': fire_spell
}

@property
def health(self):
return self._health

@property
def mana(self):
return self._mana

def cast_spell(name, target):
self._spellsname
return self

def spellhits(self, type, damage=1):
if self.immunity == type:
return None
else:
self.health -= damage
return None

So let's break that down a bit:


fire_spell: Exists outside of the characters. I would probably put all my spells in a separate module, that way I can import them, and add and remove them at run-time from the characters. That enables you to do things like have spells that aren't accessible prior to a level up, or some other mechanic. This isn't too different from having a separate class for the moves, since you're trying to namespace the moves, but I'll get to where that's a little odd here in a second.


self._health: This is just an attribute, but note the leading underscore. This is a pythonic convention that tells anyone who is using your code not to use this variable to access the thing that it points to. That is it would be best to leave it private. Python doesn't have private variables, so this is as good as it gets. We're all adults here.


@property: This is an example of a built-in decorator. If you don't know what decorators are, there are TONS of tutorials out there. Essentially, they modify how a function works. This one makes it so that instead of having to call the function, e.g. player1.health(), you simply access it as an attribute a la player1.health. Why on earth would you want to do this though? Well, any code in the function will run prior to returning the attribute! This allows you to modify what the calling code receives when it accesses the attribute. You want to have a conditional health buff based on the zone that the character is? Boom, way easier with this pattern. What to have the mana get dropped to 0 because of a status effect, easy peasy. And as soon as the effect clears, it can go right back to where it was! Basically, @property is really cool.


spell_hits: This is a method on the Character object. This you know. But why is it there? Well, designing a game is essentially designing an API. You may have heard of API around town, usually people are talking about web APIs, but the term is Application Program Interface. It applies equally to what this is. The Character class exposes an API to function inside of your program. They can expect that if they're going to receive a Character then they can act on it in a certain way. This is actually where you start to understand why certain programmers really aren't fans of dynamic typing. Python gives precisely 0 shits what you pass to this function. You can pass it a list of integers and it will not be annoyed. Well, until you try to call spell_hits. Then you get PropertyError: list object has no method 'spell_hits'. This won't happen until runtime. Then you're stuck chasing down which part of your gaht DANG CODE PASSED IN A DAMNED LIST!!!!! This probably won't happen to you with a small program, but I like to add context!


return self: Why would you do that? Well, we're back to the concept of API design! It's a pattern used for a "fluent interface". This pattern allows you to utilize method chaining, which is a really nifty thing. For example, let's assume that you want to run specific series of methods on a certain user input, then you could do p1.cast_spell(p2).use_item(p1).another_method(). This is a pattern that you see in a lot of libraries. It helps wrap your head around it if you write some code yourself that does it.


As far as your code is concerned, there's on thing that really sticks out:

Attributes.init(self)
Moves.init(self)

You don't need to explicitly call __init__. The __init__ function is what a lot of pythonistas refer to as a "dunder method", short for "double-underscore". I prefer to call them "data-model methods", since that tells you what they're actually a part of, instead of describing how they're written (which is totally useless information). A bit pedantic? Totally, but I wouldn't be a programmer if I didn't have a pedantic pet peeve (how's that alliteration!)


Data model methods are called when they need to be, and in the case of __init__ that is when you initialize an object. Example:

class Thing:
def init(self, name):
self.name = name

t = Thing('bobby brown')
print(t.name)

That will output 'bobby brown' because we assign the newly initialized Thing object to the variable t. Without capturing the object with a reference to a variable, they will be garbage collected. Basically, the Attributes and Moves objects that you're initializing will not be attached in any way to the player. You would need to do something like

self.attributes = Attributes(self)

Which would allow you to reference the new objects inside your player. Garbage collection in python isn't something that you'll need to be concerned about often, but I mention it because it's nice to know that python uses reference counting. Well, C Python does, and you're probably using that, so....


Overall, I think that what you need to get coded (pun intended) into your brain is the idea of frist class-ness, specifically as it relates to python. This concept is what makes decorators possible, and underlies the design patterns related to classes. I would also highly recommend the official tutorial as a place to find solid info on basics.


Past that, really it comes down to design choices. There's a million other ways than the one that I gave you to do this. Each one has a good reason to do it, and each one has trade-offs. This is where the rubber meets the road! Real programming boys! If you're interested in reading something that might help, I recommend Clean Code as a good read on designing good reusable software. The design book I linked above is kind of dense and uses Java, which could be confusing if you don't have experience with it. Clean Code is more generalized.


TL;DR: Functions accept objects, so pass the player object to the function and alter the health there. Then go read a LOT of stuff on OOP design patterns, cause they're hella hard.

I have some advice for you. I'm speaking more from the position of someone who didn't do a lot of these things and regrets it than someone who can say for sure what you need to do, but I still think I have some helpful advice:

First and foremost, take a little time to enjoy your last summer before going off to university. I'm not saying you shouldn't also learn some CS, but honestly if you're the type of person who knows how to study and is willing to go to class and put in the work you already have a "head-start" on a good percentage of your classmates. And frankly, life gets a lot more stressful after high school. Enjoy yourself. You're right that AP courses aren't representative of the college experience, but your first year's coursework isn't going to be too scary. If you can handle AP, you can handle your freshman level coursework. Go to class, take good notes, and be an active participant in your courses, and then study afterwards. That's 90% of college success in the classroom. Doing well in the classroom isn't the only thing you need to worry about though (more below).

If you'd like a little summer reading, I personally found this book really enjoyable. Picked it up during my freshman year IIRC: https://www.amazon.com/Code-Language-Computer-Hardware-Software/dp/0735611319/ref=sr_1_1?ie=UTF8&qid=1541924346&sr=8-1&keywords=code

It is both very informative and a fun read.

If you've taken AP Comp. Sci. then I'm assuming you can code a bit. If you want to do some programming I'd recommend sticking to what you know and deepening your understanding of it or trying out the language that your university starts you off with. They might even be the same language. Don't worry about learning multiple languages yet. You will likely be introduced to several languages in undergrad. Focus on the fundamentals.

Get connected at your university. Universities have a lot of resources for people interested in research. For example, my university had an undergraduate research program. They also had a student success center with people equipped to help you develop a plan (which is what you're trying to do now) to get to where you want to be, including graduate school and beyond. Be an active participant in your CS classes. You're going to have some shitty professors but you'll likely meet some really cool people too, who are passionate about what they do and who have the connections to help you if you show some initiative. If it's a larger school there will also be plenty of student organizations for you to check out, both explicitly CS-related and basically anything you can imagine. Don't be afraid to check out non-CS stuff. See what your university has to offer. If you don't know where to start, check out the website and once you get on campus seek out the equivalent of what I called the student success center. They will be familiar with all of the programs and services that your university offers at a broad level. Should be pretty similarly named. Also, ask your professors! At my university student organizations had faculty advisors and even if your professor isn't that person they will probably know who is.

Final note: while you should be active, have a plan, and get involved, don't try to do too much at once. You will burn out. You need to be honest about your limits. It's healthy to push yourself, but only if you are mindful of what you can handle. And if you find yourself struggling, do not be afraid to seek out academic coaching. If you have trouble adjusting to the university experience (very common and nothing to be ashamed of) your university might also offer access to therapists. Finally, if you have a diagnosed disability, make sure to register with disability services to receive accommodations!

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: https://www.amazon.com/dp/0201633612/?tag=stackoverfl08-20

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.

Ah, it seems we have just filled those positions! Apologies to get your hopes up, that was bad timing. We will need more UI designers later this year - most likely in late Summer. Perhaps this is better suited for you anyway so you have time to prepare an application!

Adobe XD is a must - the fastest "basic" prototyping I've ever experienced. I've pushed it's use through our studio and it's producing awesome results (at least till InVision Studio comes out!). After Effects is optional but an invaluable tool for communicating bespoke animations for the programmers.

Really, as long as you can apply good UX practices to your designs, consider different player experiences at all stages, and can create something awesome in XD / Photoshop / Illustrator that is enough.

Some relevant books from the top of my head:

• Game Development Essentials: Game Interface Design - https://www.amazon.co.uk/gp/product/1133134750
  
  > Basic, good for references to how other games implement UI. Gets you thinking about all the necessary interactions and states required for effective communication
  
  
• Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability - https://www.amazon.co.uk/dp/0321965515
  
  > Old but gold. Remains the most solid book for understanding UX for software applications of all time. Still relevant to games, particularly on PC.
  
  
• The Gamer's Brain: How Neuroscience and UX Can Impact Video Game Design - https://www.amazon.co.uk/Gamers-Brain-Neuroscience-Impact-Design/dp/1498775500
  
  > Very good for understanding basic psychology without delving too deep, and applying those fundamentals to game mechanics and common player behaviours.
  
  There's plenty more non-game specific design books that are fantastic. I can send more examples if you like via DM.
  
  I tend to watch a lot of YouTube channels too that create game design-specific content. Tends to be more detailed about mechanics and user experience. Nothing too UI heavy (There is a sever lack of game UI video content online) but will help you get into a game design mindframe:
  
  
• Super BunnyHop - https://www.youtube.com/channel/UCWqr2tH3dPshNhPjV5h1xRw
  
• Game Maker's Toolkit - https://www.youtube.com/channel/UCqJ-Xo29CKyLTjn6z2XwYAw
  
• Raycevick - https://www.youtube.com/channel/UC1JTQBa5QxZCpXrFSkMxmPw
  
• Errant Signal - https://www.youtube.com/channel/UCm4JnxTxtvItQecKUc4zRhQ
  
• Game Array - https://www.youtube.com/channel/UCIr5cIzrkBIOwMCxJVJOx7Q
  
  Finally, some good reference sites to look up inspiration and ideas when you want to work on a new element:
  
  
• http://videogameinterfaces.com/
  
• http://www.gameandtype.com/screenshot/
  
• https://ilikeinterfaces.com/
  
  DM me if you want extra details. Good luck!

While being a self taught sys admin is great, learning the internals of how things work can really extend your knowledge beyond what you may have considered possible. This starts to get more into the CS portion of things, but who cares. It's still great stuff to know, and if you know this you will really be set apart. Im not sure if it will help you directly as a sys admin, but may quench your thirst. Im both a programmer and unix admin, so I tend to like both. I own or have owned most of these and enjoy them greatly. You may also consider renting them or just downloading them. I can say that knowing how thing operate internally is great, it fills in a lot of holes.

OS Internals

While you obviously are successful at the running and maintaining of unix like systems. How much do you know about their internal functions? While reading source code is the best method, some great books will save you many hours of time and will be a bit more enjoyable. These books are Amazing
The Design and Implementation of the FreeBSD Operating System

Linux Kernel Development
Advanced Programming in the UNIX Environment

Networking

Learning the actual function of networking at the code level is really interesting. Theres a whole other world below implementation. You likely know a lot of this.
Computer Networks

TCP/IP Illustrated, Vol. 1: The Protocols

Unix Network Programming, Volume 1: The Sockets Networking API

Compilers/Low Level computer Function

Knowing how a computer actually works, from electricity, to EE principles , through assembly to compilers may also interest you.
Code: The Hidden Language of Computer Hardware and Software

Computer Systems: A Programmer's Perspective

Compilers: Principles, Techniques, and Tools

The usual advice is "get out and program!" and that works, but it can be very tricky coming up with something to write that's also satisfying. The idea is that you learn best by doing, and that many topics in programming can't really be learned without doing. All that stuff is true and I'm not denying that at all, but some of us need more. We need something juicier than spending hours configuring a UI for a project we couldn't care less about. It shouldn't be an exercise in masochism.

I guess what I'm saying is that there are a lot of ways to learn to write code and books are great if you can really sink your teeth into them (a lot of people can't). Code Complete is a great book on the practice of programming. You also say that you "get" OO pretty well, but it might open your eyes to read up on design patterns (e.g., Head First Design Patterns). You have a long way to go before you really get it

In addition to those, you could delve deeper into your languages of choice. There's no way around JavaScript if you're a web programmer, and a book like JavaScript: The Good Parts is pretty enlightening if you've got some experience in JavaScript already. It's a pretty interesting and unusual language.

But sometimes programming is about building gumption, so instead of just being practical, try to figure out what you like about computers and keep going deeper into it. If you have an interest in computer science and not in just building apps, then something like Structure and Interpretation of Computer Programs could instill in you an enthusiasm for computers that trickles down to everything else you do. If you're more interested in web design, there are probably similarly interesting books on artistic design principles.

I think what I'm ultimately saying is that you should find what you enjoy doing and just go deeper down the rabbit hole, getting your hands dirty when it's appropriate and interesting.

> The next question would be what are some key concepts I should learn before I start programming?

How to write instruction manuals for retards. I don't know actually. I've taught programming (friends and TAing) but I don't know how to teach someone to be a programmer. It takes a certain attitude. You have a problem and there are certain small steps you are allowed to perform. Programming requires you to translate your problem in a sequence of small steps. There are some people who have a knack for it and they will catch it immediately. Others will look at problem, know the steps but blank out completely and never be able to make the connection of what steps they can perform to solve the problem using the small steps. I would recommend go slow and up the difficulty enough to keep you interested but not so much as to discourage you. I don't know how hard you it will be for you but I think the attitude in proving a theorem in mathematics is what would help. It sort of has the attention to tiny detail, creativity and dealing with the frustration of not seeing the solution immediately that programming requires. I think the easiest way to learning how to program would be trying.

> What do I need to install in my computer in order to practice?

I meant to answer this question in my first post. For C on Windows your options also include installing cygwin and then pretending you're on Linux. For Java, Eclipse. Itself written in Java, so cross platform. Perl, Python should be again avilable on all Platforms on the commandline, all it needs is a text editor (haven't seen any Perl IDEs). Oh in C if you're using good old gcc you should also choose a text editor. A good IDE with a not intimidating example project should be decent, but you'll probably become confident a lot quicker if you were using a simple text editor with just your compiler and interpreter.

> Is there a great difference in programming command line programs and GUI programs? What do I need to know to do GUI programs? Do I need special software / libraries / skills?

To be honest I have barely done any GUI programming. I have modified a couple of GUI programs and have done some 3D stuff in OpenGL. My answer is GUI programming is just annoying not interesting. Most of the real work does not involve how you interact with the user. GUI programming is mostly calling a bunch of library functions with some voodoo magic. Of course no matter how technically awesome your program is it's not impressive to a non-programmer until they see a GUI.

> Could you recommend a good book for self-reference?

For Perl the camel book (larry Wall is author of Perl) will serve you your entire life. For C K&R is by the auhtors of the language and considered the definitive learn C book (haven't used though). As far as C++ don't learn that as first language but I know there is a book by Stroussup and Deitel and Deitel is used in almost all universities. I found Thinking in C++ to be useful (used in my school alongside Deitel and Deitel) but please please don't learn C++ first. I plan on reading ANSI common LISP by Paul Graham one of these days.

But seriously a book won't get you very far. The quickest way of learning programming is doing it. Once you're confident programming you'll find all languages making sense and starting to edit a program in a language is a great way to learn. You have code examples right in front of you and the fact that it already runs and does most of the stuff boosts your confidence until you get comfortable enough with the language that you can see yourself do the whole thing.

> I tried teaching myself Python a while back, but then they upgraded Python to 3.0 and I couldn't do anything anymore and I was very confused as to why. It since has become clear to me that knowing a couple of codes in a particular programming language is not the same as "programming". So, I would like to know more. Could you please help?

That's why I said start with C. It's a very concise language that does exactly what you say. And there is slmost nothing to remember for it. It should help you develop the programmer mentality. The other school of thought though is that a learner computer language is something that helps you express algorithms which makes C the worst choice because it is too lcose to what you want to tell the computer rather than the ideas you havem but I'm from the bottom up rather than top-down school of thought.

> Fast forward into the future... our system speaks very well. Fluent English. There is no self. There is no awareness. But it's an incredibly effective chatbot. The best ever created. It learned from scratch. Naturally. No programming involved, other than the basic conditions for the neural network to start developing.

You got your order backwards. That's impossible without context / experience to go with it. You can say, "Oh, well it's taking in a bunch of data, that's it's context." but at that point it is identifying self and other already to build context.

Like a baby, it identifies self before it can speak well.

Have you read any of Douglas Hofstadter's work? You would really like his writing. It's all about this sort of stuff. His least popular book (that I wouldn't recommend as a starting read) is Le Ton beau de Marot which explains the difficulty of translating language without context, and is surprisingly relevant to the struggles of Google Translate and the like.

>Gradually it starts developing a self. How wouldn't this happen? Learning how to speak is a process tightly related to learning how to think. Can you imagine thinking without language? Can you imagine fully-fledged human-like communication without some basic underlying thinking? Can you imagine being in love without language? Can you imagine getting attached to your girlfriend, or worrying about death, without language? Take a moment to picture that. A language-less mind.

Yes, I do it all the time, though depending on what you call language. Most of my thoughts are not linguistic which imho is probably why I struggle with English so much.

I've also written AI that pattern matches visual information, like charts of data, mostly for the stock market. So actually, yes, I do know exactly what you mean.

>More complex hierarchies were built. That is how human thinking emerges. Slowly, over the years. Developing such a deep level of understanding of language that it can encode complex thoughts and emotions.

Yes abstractions and recursion. It's not that complicated.

>Back to our system. It's proficient in a language, not hard-coded; but self-taught. It developed not only great grammar and vocabulary, but great communication skills.

I have horrible communication skills. Can you teach me how to be a better communicator?

>You think you can encode emotions without language? Well, sure. But I bet you've never thought of the concept of "Doing your very best effort, to the point of challenging your very own mental and physical limits, going beyond what you thought you were capable of, to push yourself forward and improve" in one single word. You might have thought about this, but... in a single word? Well... you have, if you speak Finnish and know the word "Sisu". Non-Finnish-Speakers lack this. The same applies to tons of languages.

Ahh, but did you ever think about boiling that concept down into a single word itself? (The concept of boiling down concepts.)

There is this thing called Domain-Driven Design in the software engineer architecture world. One of the key aspects of it is called "Ubiquitous Language". It's kind of the heart of business terminology (though technically incorrect from a historical perspective). The idea is you make up a word that represents a concept and then casually use it in the work place in such a way that the sales people, managers, and engineers use it. This way casually everyone syncs up to the same terminology bridging communication between individuals of different backgrounds.

Sadly, ubiquitous language is often used as an ego boost by senior engineers to maintain seniority. Please, if you ever use this technology, explain how it works to the juniors clearly, so they are kept within the loop. Too often seniors will use it as a way to choose who is in the loop, so please "with power comes responsibility". We could use more kindness in the engineering discipline, or at least out here in silicon valley.

>This system I've described in this whole post is actually a human being.

Pretty awesome write up.

You're pretty smart. Are you on hacker news by any chance? Or and totally checkout GEB, you'll like it.

You know, there really isn't a real good 'comprehensive' guide to all this kind of stuff. All I know is there is way more out there then anyone would realize.
A little about me, this is sort of my specialty. I've been doing application and system monitoring for over 10 years now and was an MVP for MS Operations Manager (MVP is a joke. Here's an MSDN sub, now work tech support for us). Anyway..
As for books, the only one I've found even remotely interesting about all this is The Practice of System and Network Administration. I actually bought it and am going through it now - seems like a good read so far. I'm tired of monitoring, rather go back to good ole system admin.
If I was in your shoes, here's what I'd do.

• Enable SNMP on all of the servers. And assign a community string for both read-only as well as read/write.
  
• Especially if you go to Server 2008, install and setup WinRM
  
• Install Powershell and learn it well. You'll never go back to any other scripting language in Windows again - especially with 2.0 & WinRM
  
• Download GetIf - yes it's old, but it still works. Go out and find the MIBs for the servers you use Dell/HP/etc.
  
• Yes, its a bitch getting the hang of it, but install Nagios anyway
  
• If you really don't want to install Nagios, then check out Servers Alive!. It's another tool I use and the 'enterprise' cost is only 300 euro. It has its flaws, but for what it does its pretty awesome.
  
• Also install Cacti for all your graph love.
  
• Learn all about SNMP. It's been around over 20 years now and imho does an awesome job if the devices you have support it. And even if they don't, with something like Net-SNMP, you can make your own OIDs that when polled run a script and such.
  
  Combining a free powerhouse monitoring tool like Nagios, with a graphing tool like Cacti, is all you'll need. It's even overkill for your network, but once they're all setup it's dead simple and you'll look like a rockstar - suits love graphs.
  Yes, you'll need a linux box, but a simple P4 workstation with a gig of ram is more than enough for it, and you probably have them lying around.
  And once you get into powershell (On IRC we hangout in #powershell on Freenode) you can do a lot of amazing things quickly with it - especially combined with WinRM.
  I could go on and on about all this, I've been doing it forever - and I can even help you with the setup of it all and answer any questions. Just send me a PM and I'll give you my email.
  As for SNMP, it's very well supported by all the major manufacturers - HP, Dell, etc. So in your RAID failure scenario, if you have a Dell server with a Dell RAID card, then you could have polled the machine to ask its RAID status and if there was a failure it could have sent a trap to your monitoring box to let you know. It can also handle all of the hardware info like drive capacity, processor utilization, etc etc. The only downfall SNMP really has these days is the fact that it can seem almost mystical to those looking from the outside. But once you get the hang of it, it's great. Nagios also has an add-on called NRPE (Nagios Remote Plugin Executor) that you can use to run scripts and such on local machines if you can't get the info you need out of SNMP.
  
  If you're interested in doing environment monitoring as well, a decent inexpensive device is the Weathergoose from IT Watchdogs. I've got one at home that I demoed years ago and it's still going strong. At $500 its a good price for what it does plus there's a ton of addons you can get for it or even make your own since its just I2C
  
  Anyway, this is probably a shotgun of information to your face, but like I said just ping me and we can talk about it. I'm recently unemployed, again, so I have the time.. again.

At UVic, I think there are security specializations for degrees such as the MTIS or the Computer Science Options (such as Network Security -- although I did the Software Engineering option for C.Sc. in my undergrad)

I focused on taking classes, but I did a LOT of my own (legal) research/projects. That "legal" caveat is IMPORTANT. Don't get arrested for a hobby, it doesn't achieve your goal, and it's not worth it. Do things the right way, don't trespass or break the law.

Most of the government cyber defense jobs are in Ontario -- so expect to have to move there if you want to work with them. I hear there are ... "sites" ... elsewhere, but realistically you would have to "do your time" there before anything like that became available.

Business and Finance classes are always a good idea -- not just for business but personal benefit. My wife is an accountant and those skills are really helpful to have for our daily/monthly/etc finances.

Advice

• You have to "shoot straight" when it comes to security. Gone are the days where someone hacks the FBI and they offer him a job. Now they just arrest you and you stay there. It makes sense, why incentivise it. Don't do something that might even be construed as illegal. (With that being said, there is an argument to be made for making security education too "academic" and forgetting that people actually have to work on practical aspects -- this is outside the scope of this conversation though)
  
• There are plenty of projects such as OWASP Broken Web App, classes like Elec 567 at UVic, or just learn how to make your own VMs and attack them locally (the best route -- then you can control what's installed, with a fine-tooth comb) -- this also helps test new patches, etc to see if the software is vulnerable.
  
• Read. Lots. Subscribe to blogs, order books (I am partial to books such as Hacking: The Art of Exploitation (Pretty low level, but helps you understand what is going on under the hood), and Violent Python (more of a cookbook / handbook)), and read up on security news. Rule of thumb: Read at least 2 new security books every year (at a minimum) -- It gets easy when you have a dedicated app for security podcasts, RSS feeds, and you keep a book or two with you all the time.
  
• When interviewing for government security jobs, don't lie to them. If they asked you if you have smoked pot, tell them if you did. They are looking for truthfulness.
  
• Look at open source projects where you can contribute (general coding advice, but it helps). It doesn't have to be the Linux kernel, just work on something that isn't an assignment/project from school.
  
• Learn who the big players are in security -- Like everything on the internet, there is lots of talk. Find the people who actually know what they are talking about and listen to them. Take EVERYTHING (including this post) with a grain of salt! The classic motto is "Trust but verify". This applies to everything. The security industry is ... interesting ... Think of it as a cross between the mafia (Pay us for protection ... or else), "tinfoil hattiness" (Comes with the territory -- you see a lot more than the average person, so it skews your view on certain subjects... not all of which you can even talk about), and the classic balance between privacy and security (ranges from surveillance state and anarchy) ... Politics play a HUGE part.
  
• Always be learning. Show this to prospective employers. Don't just talk, do.
  
  
  Sorry, this turned into a bit of an essay. I'm just one opinion out there, but hopefully you get something out of this. As always, "trust but verify".
  
  [edit: a word]
  

Well I left school in 10th grade, travelled around and worked odd jobs for most of my 20's until one day while working a particularly shitty job I realized if I didn't make a change soon I'd be doing jobs like that for the rest of my life! So I went to university and studied something unrelated for a few years. Somewhere along the line I clicked a link on Reddit that said "Try Ruby!" and it took me to a site kindof like Code Academy with a tutorial for Ruby. I tried it out, got instantly hooked and started spending all my free time programming!

Eventually it got to the point where programming all the time made me fail a few units so I dropped out of uni. I enrolled in a programming course but that didn't work out either, so I decided to take six months and just teach myself programming full time. It was a really awesome time, I'd wake up every morning and work on my projects, take online courses and read programming books all day!

Eventually I started running out of money. I didn't think I was good enough yet but the fact that I was rapidly becoming destitute gave me the kick I needed to start applying for jobs. I was incredibly lucky in the fact that I ended up getting hired at the first place I applied. Apparently they chose me over the other candidates because of my "life experience" and the projects on my Github, although the fact that I was willing to work for peanuts helped as well haha.

That was over six months ago and I'm still really enjoying it. If I were to offer some advice it would be to just stick with it. Even when you doubt that you are good enough, or smart enough, or that this whole learn programming idea might not work out at all and you'll never get a job - keep at it! If you enjoy programming and put the effort in then someone, somewhere will give you a chance, and all you need is one chance.

Also, make sure to take projects through to completion and post them on your Github. One simple, well written project is more valuable then 20 half finished ones. Code your projects knowing that your future employer will be reading it and deciding whether or not to hire you!

To that end, I'd highly recommend Clean Code. This book really helped me, but I'd recommend reading it after you've written a project of your own. Then, as you read through the book, go through and refactor your code.

Finally, when you're thinking of projects, don't worry about trying to create something amazing straight off the bat. Pick anything that interests you, maybe scratch an itch, or even re-implement something that already exists. At the end of the day the idea does't matter as much as the fact that you've spent the time and effort to build something. If you look at my projects, they're boring as anything! But they were good enough to get my foot in the door.

All the best!

I've been here a few times in my decade-long career.

To start, this isn't something that only happens to junior developers. Trying to approach a large existing code base can be a real challenge, even when you have lots of experience.

You're not going to understand the whole application in a day. Probably not even in a week, and probably not even in a month. On some large code bases, I've regularly run into new code *years* after I first started working on the application.

What I've found helpful is to pick a small part of the application; preferably one that's related to a feature you're trying to add or a bug you're trying to fix. Find what looks like the entry point of that small part of the application. In a web app, it could be a method in a controller class. Or it could be a method in a service class somewhere.

Once you've found that entry point, read through the code one line at a time, and try to make sure you understand what's happening at each point. If the method you're in calls another method/function, jump to that and go through it one line at a time. On code that's particularly complex, I'll grab some sheets of lined paper, and devote one sheet to each method I go through.

As I go through each method, I'll write out the whole thing by hand as pseudocode. In order to do this, I have to understand what the code is doing. Some people might find it more effective to do this in a text editor. I find that there's something about the process of physically writing it out on paper that really helps cement my understanding.

Now, the whole writing out part isn't worth it if you just need to go in and do a quick bug fix. But if you've been handed responsibility for a chunk of code and you'll need to understand it deeply, I've found it to be a useful approach. I think it can still be helpful even if you're not solely responsible for a piece of code, but will have to work on it heavily.

Start by deeply understanding one important part of the code. Then move on to understanding another important part. Soon, you'll start to see patterns and understand how these important bits of code fit together.

If you're not yet sure what the important parts of the code for you to understand are, then a good way to find out would be to look at the repository's commit history to see which files have the most commits over time. The places that change the most often are likely the ones *you* are going to have to change, so they are a good place to begin. You can find instructions on how to do this here:

https://stackoverflow.com/questions/5669621/git-find-out-which-files-have-had-the-most-commits

That assuming your code is in a Git repository. If you team uses Mercurial, you can look up instructions on how to do the same thing. If your team uses Subversion or heck, even CVS, you can probably accomplish the same thing. If your team doesn't use source control at all, then start spiking your morning coffee with rum or Kahlua because that will make your job significantly less painful.

For a look at using Git commit history to find the most important code - and the parts with the most technical debt - I enjoyed a book called Software Design X-Rays.

I've found the book Working Effectively with Legacy Code to be quite helpful in showing me different ways to approach an existing code base. Even if you don't apply all of the techniques the book suggests, I think it's still useful for finding out ways to find 'seams' in the code that you can use as points of attack when refactoring, adding features, or even just choosing a place to start learning a new bit of code.

If your employer will let you expense the cost of eBooks, you might find these interesting. If you can get access to Safari Books Online, both these books are available on there, along with a metric ton of great software development books. You might not need to pay for it - in my city, everyone with a public library account can access Safari for free. Maybe it's similar where you are?

Also, if you have a particularly frustrating day, feel free to come on Reddit and send me a DM. I might just have some useful advice. And if I don't happen to have useful advice on a particularly topic, I'll at least be able to come up with an on-topic smartass remark that will help you laugh and feel better about the code that frustrated you.

I've always felt like C is a good language for a programmer to think in. With that being said, I often recommend that a programmer who doesn't need to know C++ learn C if (s)he wants to learn something that will improve his/her skill across the board.

C will give you a good appreciation of what's going on behind the scenes in many of the languages you use. You'll get an appreciation for how passing by value and reference works in other languages thanks to pointers. You'll learn how your strings are actually managed in memory. You'll have a better understanding of how many of those built-in generics you may use (List<>, LinkedList<>, HashMap<>) actually work, because if you want to use them in C you'll have to implement them yourself or download a source file and read it to understand the author's implementation.

This knowledge will help you build more elegant solutions. You'll be less sloppy and gratuitous creating new strings anywhere and everywhere, and may even find yourself using references more often. Your code may or may not be cleaner, but you'll have an appreciation for how and why you should write code for runtime efficiency. You'll be more likely to use the right data structure for your task at hand.

The best part is that C has a great standard resource for learning the language. Pick up The C Programming Language Second Edition and read it cover to cover. By the time you're done you'll know everything you need to know about C, and will have a wonderful reference in the even that you need to use C later on.

If you want to improve your object-oriented programming skills, you don't need to learn a new language. It is best to learn OO independent of any language in order to gather a strong understanding of the underlying concepts and to be able to apply it to any language. Craig Larman's Applying UML and Patterns is the best book I've ever read on the subject.

Heh, sure.

A lot of people are fans of Code Complete. I tried reading it after being in industry for a decade, and I found it to be very dry and boring. The general consensus from people that I've talked to is that it's more useful when you're just starting out. Maybe I just came to it too late.

A better book (in my opinion) in that same vein is Clean Code. Clean code is shorter, more focused, and has better real-world examples. It feels less "complete" (hue hue) than Code Complete, but to me, that's a strength. As a quick point of comparison: Code Complete devotes 32 pages to the chapter on identifier naming; Clean Code devotes just 14.

I got a lot out of Design Patterns. I seem to recall that the pattern fad was in full swing back when I read this in 2005-ish. I think I had independently discovered some of the patterns already at that point, but this book helped me to codify those ideas and also showed me some new ones. Some of these patterns are now seen as antipatterns (I'm looking at you, Singleton!), and all of the patterns have an object-oriented bias. But there's still something useful in the pattern language, and this book is a reasonably comprehensive start. The book is somewhat dry, and some people report that Head First Design Patterns is a gentler and friendlier introduction. Head First Design Patterns hits the essential patterns, but misses a lot of the less popular ones.

Eventually, you'll need to work in a codebase with some technical debt. Maybe it's debt that somebody else put there, or maybe it's debt that you introduced. Working Effectively with Legacy Code is still my go-to recommendation. It defines technical debt as code that is not under test, it introduces the idea of "seams" that you can use to pry apart code that's too tightly coupled, and it then provides a cookbook of specific scenarios and reasonable approaches.

If you're looking for thought-provoking videos, I recommend anything by Rich Hickey. I don't know if I've watched all of those, but I remember good things about Hammock Driven Development and especially Simple Made Easy.

Get comfortable with a source control system. I didn't use source control in college, since it wasn't needed for any classes, and that was a missed opportunity. The whole world loves Git, so you'll probably want to learn it if you haven't already. But I'll also toss out a recommendation for Mercurial. I haven't used it in years, but I remember finding it to be quite good.

Good luck!

Physicist here so don't pretend I don't know what science is. (Though like the ancient Pythagoreans I'm sure as soon as I discuss something that has been proven that goes against a purely scientific worldview out comes the pitchforks.) And though I love science, unlike some people here I am willing to admit to the limits of science. Science can lead to all truth in the same way that rational numbers define all numbers: it can't! and Godel proved it.

The real problem with science is that it has been mathematically proven by Godel that there are more things that are true then are provable and thus you can't ever have a scientific theory that can determine the truth or falsity of all things. As soon as you write down that theory, assuming it allows for arithmetic, Godel's incompleteness theorem immediately shows if the theory is true there will be true statements about reality that are beyond provability. Read Godel Esher Bach or Incompleteness or work through it yourself in this textbook as I have.

So like I said above, science is great in it's sphere (and in that sphere let me emphasize it is awesome!) but leads to all truth in the same way that rational numbers leads to all numbers. (And the analogy is precise since Godel used the famous diagonizational argument in his proof.) Russell and Whitehead set out to show in the early 1900s that if we could determine the axioms of reality then through logic work out everything that was true and Godel spoiled the party.

It it would be one thing if these truths were trivial things, but they are not. Some examples of true or false statements that may fall into this category of being unprovable are:

• Goldbach's conjecture and an uncountable number of mathematical theorems (by the diagonalization argument) for that matter.. (Search the pdf for Goldbach)
  
  
• Issues related to the halting problem in computer science.
  
  
• Issues related to recursive logic and artificial intelligence.
  
  
• And again, this list goes on uncountably.
  
  Now, at this point critics almost always tell me: but Joe, Godel's incompleteness theorem is only relative to your set of logic. (Ie... we can prove Goldbach by just adding axioms needed to do so.) Fine. But two things: (first) adding axioms to prove what you want willy nilly is not good science. (Two) You now have a new set of axioms and by Godel's theorem there is now a new uncountable set of things that are true (and non-trivial things like I listed) that are beyond proof.
  
  Now usually comes the second critique: But Joe, this doesn't prove God exists. And this is true. But at least it has been proven God gives you a chance. It has been proven that an oracle machine is free from the problems that hold science and logic back from proving the truth of all things. At least something like God gives you a chance (whereas science falls short).
  
  Or, like Elder Maxwell says so well: it may only be by the "lens of faith" that we can ever know the truth of all things. He maybe be right, and hence the importance to learn by study, and also by faith...

You have to be above the bar to begin with. If you can understand exactly what intelligence is then you can increase it.

Meditation can be used as a way to gain insight. This is not all types of meditation, but there are definitely types of meditation with the goal of enlightenment in mind. Using the Buddhist definition of enlightenment and overly simplified explanation is insight, specifically the type of lower level type of insight that not everyone can get to and for the most part needs to be unlocked. Once it is unlocked, how one utilizes it can be a large intelligence booster, but you have to be able to comprehend how your mind works. If you can't fully recognize a lot of advanced and abstract concepts then knowledge gain is possible but hardly any intelligence gain.

Using the example you mention, math is utilized on the other part of the brain in such a way that you can multitask while solving advanced math problems. A way this can be figured out is solving math problems in your sleep. It is like a piece of your brain is a math coprocessor and it can chug along while you are talking to someone, reading writing, sleeping, or generally not paying attention to it, much like cooking something in the oven.

It depends what you want to learn. The most direct path is raw insight. For advanced logic, paradoxes, and other mathy nerdy stuff you might want to checkout GEB. Meditation doesn't skip the learning step. You still have to learn things the same way everyone else does. Meditation just helps you realize you can utilize your brain to a more full potential.

If you are really interested and think you can can push forward, I highly recommend you try a 300µg+ dose of lsd. Tripping is the same thing as a deep meditation state, but it doesn't stay. It is like driving a car over the mountain instead of walking. In a deep state under the influence you can do all of the more insightful things one can do in a deep meditative headspace. However, figuring it out could take multiple trips as sometimes insight will take 6 hours to come full circle. When meditating in a deep headspace the answer can come much quicker.

The idea is if you can figure it out while tripping, then you can remember what you've learned and migrate it into meditative practices, as it can literally take a life time to get to the level of meditation skill as one night of dropping acid will bring you to.

It is definitely possible. If you don't ask very specific detailed questions about how your brain works, I will not be able to explain in detail, and without asking yourself you can't move towards figuring things out either.

An efficient way to get to a deep headspace from meditation is a map, so you have an idea of which direction to go in. This tends to be pretty good.

well depends on what you want to learn. Do you only want to do webdev stuff or learn a ton about CS concepts? I'm going to answer in terms of learning CS stuff, but first here's a page on how to go from knowing nothing to knowing a wide range and depth of CS topics: you do this, you'll be a grade A software engineer!

OK, moving on. First the basics which it sounds like you've got covered.

1. understand basic programming concepts (conditions, loops, functions)
   
2. learn a programming language pretty well, it doesn't matter what language. Being good at and Understanding CS concepts does not involve mastering a single language... once you get the concepts any language will be easy to learn... It sounds like you know some Javascript (not my personal recommendation for learning CS concepts), personally I'd recommend Python (easy syntax, great resources, wide use, etc..)
   
   OK, now where it sounds you stand. Learning the Advanced stuff.
   
   
3. Algorithms: The bread and butter of programming. There are many resources out there, if you want to buy a book, the gold standard is "Intro to Algorithms, 3rd edition ". Other than that, I'd suggest just the relevant Wikipedia article for algorithms. Take the pseudocode and implement it yourself in your language of choice. Understand what the algorithm is doing. Compare it to similar algorithms, understand why/when it's better or worse.
   
   
4. OK, now that you've got that done, you can start making more complicated stuff. Come up with some silly or interesting real world examples to practice with. I suggest at this point learning more about Object Oriented Programming... learn about Classes, class structure, generics (this all varies by language). Practice, practice, practice. 4 hours of coding a day if your not doing anything else, spend the rest researching/reading.
   
   
5. Learn how to use Unix/Linux. it's good for you(tm)
   
   
6. optional but cool: Learn about Computers structures and how operating systems work, bonus points if you want to build a basic OS from scratch (this requires learning a systems language like C/C++/Rust and some assembly).
   
   anywhoooo that's kind of an overview/recommendation... feel free to ask any more questions/clarifications/suggestions for resources.

I'll preface this by saying i've done a little bit of hiring and helped my boss look at candidates so i'll try to explain why interviews might not be coming your way.

Also be wary that i'm bias. I don't really understand the idea of a "boot camp"; You can't leave your job and become a teacher or a lawyer in 6 months, why is a developer different? I guess it just seems a bit offensive to just assume that the field has such a lower barrier to entry that you need next to no training to be work ready.

Ok rant over.

Some tips/advice:

• Go to meetups. Whether it be a nodejs or an express meetup find what is happening in your area and do your best to get along. You'll meet people and build up a bit of a network which will help gain some respect even if it's within small circles. Many of the people will have jobs and might be able to hook you up
  
• You currently don't get interviews because you're easy to discount from a list. If a business gets 20 applicants an easy way to narrow down is by degree/experience. As somebody without either you're just culled while the list is narrowed down so you probably never get past that first step. That's why the above is vital. Also if you're rejected somewhere try to find out why, follow them up and see if you can improve yourself. I know many people who've done comp-sci/programming at uni for 4+ years and still can't get a job, you're going to need to work hard to get ahead of these people
  
• Reason 2 people won't give you an interview is you're a big risk/investment. To get you where up to scratch in tech they're going to need to invest time in you, get you mentored, train you and help you which is $$$. The fact that you've dropped your previous degree and done a 6 month course I know my boss and I would raise a red flag at, how do we know you won't get bored in a year and after all the investment you just leave? Not saying you are like this at all but trying to explain what goes through peoples heads when they look at you
  
• Not sure what jobs are like in your area but it's probably worth looking at what tech is popular. Is C# the king of your area? Learn C#. Is python the most popular stack? Learn python. People get too caught up in trying to use something cool and current rather than something that will be useful. You can write beautiful code in any language.
  
• Read some good books. Most people have done a 3 year degree at uni to get to your position so in some aspects you'll be massively behind. Reading something like clean code(best book i've read on development) will help you get up to speed. Understanding how to get requirements is as important as being able to write the code.
  
• Make sure you're applying for the right positions, again I have no idea what you're looking at but you need to be looking as low as possible. Anything without the word junior in it they'll write you off instantly. Call some businesses and see if you can find out what they look for in a junior, maybe they like seeing more side projects etc.
  
• Contributing to open source is often a good idea, while some people hold it up as all important I think it's just good as it shows you can work with others and understand the idea of getting issues/features done and have the ability to come into a library/application and understand it enough to contribute.
  
  Portfolio critique:
  
  
• Nowhere does it mention what sort of job you are after(unless I missed it)? It just launches into name then skills, having something like "developer" or "web developer" I think would help me
  
• Skills are way too saturated, you can probably remove all the browser images, i'd take away ajax, and depending on your target audience html/css. If you call yourself a dev and can't do html/css you're not worth looking at
  
• Personally i'd put a contact form on there, you say "be the next chapter" but don't give me an "easy" way of getting in touch with you, drop a form in so I don't have to do more work
  
• All your projects look like assignments from your course(they might not be). I'd try to diversify those because I just assume when I look at them you've had help or have not actually done it yourself and is something i'll often question with our applicants

I. BACKGROUND INFORMATION

• What was your major in college?: Computing science.
  
• What was your career/vocational journey like once you graduated from college?: Turbulent.
  
• How did you prepare for entry into your profession?: Co-ops, reading dozens of articles and books about how to be a programmer.
  
• How did you locate & secure your current job? : Twitter, surprisingly.
  
• What specific degrees or experience is necessary for this kind of work? : "Be a good and unusual programmer." CS degrees are always helpful but not necessarily requisite.
  
• If you were to redesign your college experience what would you do differently? : One time I took Software Engineering II instead of Algorithms II, and I still regret it. Universities don't do practical stuff well.
  
  II. CURRENT ROLE INFORMATION
  
  
• What is a typical work day like for you? Tasks throughout the day?: Shower, commute, standup, lunch, coffee, programming, commute, take-out, draw comics, watch TV with girlfriend.
  
• Do you have opportunities for varied schedule, such as telecommuting; flex time, or job sharing? : Yes.
  
• What are the most interesting or challenging aspects of your job?: I learn new things all of the time, because I've never worked in a job where I have to maintain cloud infrastructure or work with mobile devices.
  
• What are some of the difficulties and frustrations of your work?: Maintaining cloud infrastructure, working with mobile devices.
  
• What are the most significant changes facing your field/organization?: We're getting bigger, fast, and we're not sure how to attract good talent, filter out bad talent, and keep things from becoming a bureaucratic nightmare.
  
  III. YOUR INTEREST IN THE FIELD
  
  
• What experiences would you recommend I have (coursework, internship, volunteer, campus involvement, etc.) to prepare for a job in this field? : I could answer this ALL DAY. Get a CS degree, it's good for you. Don't do unpaid internships, it's bad for everybody. Try to get a commit into an open-source product that you think is cool.
  
• What does it take (personality traits, strengths, and competencies, experiences) to be successful in this field?: If you're in any way different from the herd of young white males, you need an incredibly thick skin and a lot of personal resolve, and you're going to deal with a metric tonne of stupid entitled bullshit from people who have really only ever learned computers and little to nothing else. If you're young and white and male, uh... you're pretty much set, but try to be kind to others.
  
• What do I need to have on my resume to be considered for employment in this field?: Programming languages. No food stains.
  
• Can you recommend resources that offer helpful information about the field? : CodingHorror, Joel on Software,
  
• What are some related occupations that I might investigate? : Tech Writer, DevOps/Sysadmin, Data Analyst,
  
• What professional organizations would you recommend? Publications to read? The ACM releases some surprisingly good magazines. I like Linux Voice quite a bit, too.
  
• What specific advice would you give a person entering the field? Be kind to others. Don't believe in the meritocracy. Socialize with your peers. Join the student society.
  
• Can you provide me the names of two or three other people in this field who might talk with me and provide additional information? May I use your name? : No.
  
• Would you be willing to review my resume if I emailed it to you? : Probably not?
  

tl;dr version:

1. yes
   
2. no, but that will be the case at any school
   
   Quick background to validate the above/below: I was a 30y/o banquet manager when I decided to change careers. I had no prior experience [unless you want to count a single programming class I took in high school] but did get a job in tech support at a medium size startup while I was in school and wrote a couple apps for our department. Just before I graduated I started working at a primarily Google & Mozilla funded non-profit as their sole software engineer. I moved on after a little over two years and am now a software engineer at VMware.
   
   
3. The degree is a huge boost in getting past HR and/or having [good] recruiters work with you. You'll also learn the skills/knowledge necessary to get hired as a developer, which is obviously the more important part - but for the most part this is all stuff you can learn on your own, but you'll greatly reduce the number places that will even give you a phone screen if you don't have a degree [I'm not saying this is how it should be, but this is how it is].
   
   
4. I typed out a lot before remembering New Relic had a great blog post a few months ago about all the stuff you don't learn in school [about software development], ha. So I would highly recommend you not only read it but also try to learn a little on your own (especially regarding SQL and version control) http://blog.newrelic.com/2014/06/03/10-secrets-learned-software-engineering-degree-probably-didnt/ Being a good developer (or good anything) takes time/experience - but knowing what they don't cover in school (and trying to learn it on your own) will help.
   
   Two books I'd suggest reading are The Pragmatic Programmer and Code: The Hidden Language of Computer Hardware and Software. Pragmatic Programmer is one of those classics that every good dev has read (and follows!). Code is great at giving you some insight into what's actually happening at a lower level - though it gets a bit repetitive/boring about halfway through so don't feel bad about putting it down once you reach that point.
   
   The best thing you can do to help you land a job is have some open-source side-projects (ideally on GitHub). Doesn't have to be anything major or unique - but it will help a lot for potential employers to see what your code looks like.
   
   

• Clean Code is a really good programming book. It's technical in that it gives you best practice, but you don't need a laptop or to code to follow along, you can just absorb the information and follow along with the simple samples (even if it's not your primary coding language).
  
  
• The Clean Coder is a great book about how to build software professionally. It focuses on a lot of the softer skills a programmer needs.
  
  
• Scrum: The Art of doing twice the work in half the time is a great introduction to scrum and why you want to use it. Agile (and scrum in particular) can have a major improvement on the productivity of development teams. I work for a large technology company and we've seen improvements in the range of 300% for some teams after adopting scrum. Now our entire company is scrumming.
  
  
• Getting Things Done has personally helped me work more efficiently by sorting work efficiently. Having a system is key.
  
  
• How to Win Friends and Influence People I often recommend devs on our team read this because it helps with interpersonal communication in the office.
  
  
• Notes to a Software Tech Lead is a great book so you can understand what a good lead is like and hopefully one day move up in your career and become one.
  
  

I don't know of any one source that teaches "good testing principles". There are thousands of sources and Sturgeon's law is working against you. A few sources are predominantly good, most have bits (often the same bits) of genuinely good advice in-between chapters of bland, uninsightful repetition, many are appropriations of popular acronyms by closely or distantly related professions (no, you're not "testing" a requirement specification, you're just reviewing it), and some sources are just plain bad.

I had an opportunity to attend Dan North's Testing Faster course and would strongly recommend it. In my case it was more helpful for formalising my own experience than learning concrete new things but other attendees did absolutely "learn new things". He made a point that "TDD" and "BDD" are both inaccurate names and that something like "example-guided development" would have been far more honest; he recommended a book, I think Specification by Example, as a good resource to that end (and noted that that name, too, is technically inaccurate). He also confirmed that Cucumber is a solution looking for a problem.

Test Driven Development: By Example by Kent Beck is a classic, and as far as I can remember, decent. It's maybe a little old now, and it definitely misses some subtle points about maintainability of automated tests in general (or perhaps rather, doesn't really address that).

I've skimmed Code Complete 2. I don't remember it in detail but my overall impression of it was that the sooner it becomes irrelevant the better, because that would signify our profession maturing (if not quite reaching maturity). A lot of its contents would be considered basic by contemporary software development standards and that's a good thing. I don't remember what it says about testing. One thing in a very late chapter (33.8?) stuck with me, though: that seniority has little to do with age and your approach to software development will be formed early on.

Working Effectively with Legacy Code by Michael Feathers is excellent, perhaps the most practically applicable one here.

Sandi Metz is famous in the Ruby community for speaking on this topic and there are recordings on YouTube. From what I've seen her material also mainly addresses beginners but it's fast and easy to consume and her form doesn't bother me the way Martin's does.

One piece of advice I picked up from one of those mostly-mediocre sources had to do with naming in tests, trying to capture the essentials. If you're relying on a particular property of a piece of input to test behaviour, make sure this is evident. Conversely, if any input would satisfy, avoid drawing undue attention:

fn bees_can_fly() {
let some_bee = ...
let bumblebee = ...
let dest = ...

assert fly(some_bee, dest);
assert fly(bumblebee, dest);
}

fn bees_can_pollinate() {
let some_bee = ...
let flower = ...

assert pollinate(some_bee, flower);
}

Testing is about developing confidence. There are many kinds of testing and many things to develop confidence in. For automatic tests it's more about checking (arguably not "testing") that you retain correctness in the face of continuous change. Automatic tests that obstruct that change or compromise your confidence are not helping you and should be rewritten or removed. Reliability of tests is usually more valuable than coverage, for instance.

Okay I came in to school like you with very little programming experience. Probably even less than you since I only messed around on my TI. I am going to assume you're only taking ECE110 first semester. If not I recommend getting in as soon as you can. They may give you some crap about it depends on last names, but it doesn't really matter. After a certain point its open to everyone.

Either way, programming in ECE doesn't really start until you take ECE190 which is all C programming and a very simplified assembly language for educational purposes. Like I said I went into the class with practically zero programming experience and still did very well in the class, so don't let anyone scare you on that. If you put the time aside to read the book (really helpful in 190) and doing your MPs/ask the TAs questions you will do fine.

I wouldn't fret too much over the summer with learning stuff, but I would definitely recommend C over Python. Python is pretty easy to pick up, but its also very high level. If you need an introductory language to get familiar you can try python for a bit, but I'd go with C after that. It is worth noting that the other two required programming class you have to take (CS 225 and ECE 391) are C++ and C/x86 respectively. So learning C should definitely be your focus.

I recommend the book written by the creators of the language. The book the school requires is pretty good too actually and would give you a better idea of what to expect. They're kind of pricey, so its your call how you want to get them. As a heads up, codecademy does have Python, but not C as far as I recall. I've never used lynda do I can't comment on them C Book ECE 190 Book

I honestly wouldn't fret too much about it all. Enjoy your summer, depending on how busy your schedule is next semester you can probably set aside some time now and then to study some languages. If you have any more questions I'd be happy to answer.

Hi there. I'm a professional web developer by trade. Your website looks like it's from the 1990's...I understand that both of you are working full-time, but I highly recommend completely re-doing your website.
I don't even know where to start, so I'm just going to give you examples, resources, and inspiration, and relevant comments.

Inspiration:

This is by far, THE best website for tea I've ever seen.

DavidsTea

• It's responsive (try resizing the window from 100% to 1 inch - see how well it resizes?), looks modern, clean, fun, creative, and brands the tea/products very well.
  
  
• Design is done by an award-winning designer from Holland, if I remember correctly.
  
  Mid-tiered websites:
  
  Harney&Sons
  
  
• Harney & Sons appeals to a different demographic (yuppie-ish) whereas DavidsTea appeals to hipster younguns. Can you tell by the color scheme?
  
• site isn't responsive and still needs some user interface work, but overall as basic as you can get.
  
• Look at the way they market themselves and write descriptions. Look at the next few sites as well.
  
  Some more sites you can look at:
  
  Adagio Teas
  
  Mighty Leaf
  
  Verdant Tea
  
  Lower-tiered websites:
  
  TeaVivre
  
  Den's Tea
  
  Absolutely not:
  
  Upton Tea
  
  
• I know Upton's is pretty popular here on reddit, but I think the website is just awful. I flat out refuse to buy on that site - it doesn't even look remotely reassuring to me to pay on that website. I'm sure it is secure, but....jesus, that user interface. Absolutely not.
  
  Resources:
  
  
• Html and CSS by Jon Duckett
  
  
• Javascript & JQuery by Jon Duckett
  
  
• UXPin Free Resources [there is a pdf book in this link that shows the latest trends in modern web design, take inspiration from there)
  
  
• Do you use Firefox's Firebug tool? If you don't, just install Firebug on Firebox. Click on the bug icon, and then click on the inspector tool. Now you can hover over various elements and see what properties are being done on them if you need to figure out how something was done. You can also make changes without coding and refreshing your page each time.
  
  Let me know if you have any other questions, thanks!
  

A famous artefact of early computing is the boot-strapping process where the goal is a self-hosting compiler - which lets you write the compiler for a new language in the new langauge. However to get to that point a lot of earlier innovations were needed.

Take all of this with a pinch of salt - the order and the details may be wildly inaccurate, but the overall ideas viewed from afar give an idea of how we got to the point that we can choose our own language to write a compiler for another language..

To start with, raw binary values had to be set in order to define and run a program. Those raw binary values represent instructions that tell the hardwaer what to do and data that the program needed to operate. This is now usually referred to as machine code.

At first you would enter values into computer storage using switches.

Since that's so tedious and error prone, puched cards were developed along with the necessary hardware to read them so you could represent lots of values that could be read toagether. They had their own problems but it was a step forward from switches.

After some time symbolic instructions were defined as a shortcut for several machine code instructions - now usually called assembly language. For example put the value 8 and store it into a memory location 58 could be written as ST 8, [58]. This might take 3 machine code instructions, one represents the store instruction, one the value 8 and one the location 58. Since now assembly language could be written down it was easier to understand what the computer is being instructed to do. Naturally someone had the bright idea to make that automatic so that for example you could write down the instructions by hand, then create punched cards representing those instructions, convert them to machines code and then run the program. The conversion from the symbolic instructions to machines code was handled by a program called an assembler - people still write programs in assembly code and use assemblers today.

The next logical step is to make the symbolic instructions more useful and less aimed at the mundane, physical processes that tells the computer exactly how to operate and more friendly for people to represent ideas. This is really the birth of programming languages. Since programming languages allowed you to do more abstract things symbolically - like saving the current instructions location, branching off to another part of the same program to return later, the conversion to machine code became more complex.Those programs are called compilers.

Compilers allow you to write more useful programs - for example the first program that allowed you to connected a keyboard that lets you enter numbers and characters, one connected to a device to print numbers and characters, then later to display them on another device like a screen. From there you are quite free to write other programs. More languages and their compilers developed that were more suitable to represent more abstract ideas like variables, procedure and functions.

During the whole process both hardware - the physical elctronic machines and devices and software, the instructions to get the machines to do useful work - were both developed and that process still continues.

There's a wonderful book called Code by Charles Petzold that details all of these developments, but actually researched and accurate.

Congratulations on the masters! :)

I would say step one is to read "Don't make me think" by Steve Krug. The book is full of common sense advice that helps eliminate a lot of decision fatigue.

This blog - The Nilsen Norman Group is a great resource for the "functional" end of things, full of tips and research results on what people find the easiest and most enjoyable to use. Its another resource that gives you a ton of information on what mistakes to avoid when designing interfaces, and what has generally worked out for other designs.

As for aesthetics, just immerse yourself in good work as often as you can. Dribble is good if you view the designs with a grain of salt because a lot of them look great but would be pretty damn hard to use, wouldn't work on mobile etc. Pinterest is good too, and generally just approaching websites you come across critically and thinking "what do I like about this design? What don't I like?"

I'm also like Goodweb.design at the moment too, it's a good one to use to see how many different executions of content with the same purpose can work.

The best teacher is of course experience. Pick something and design for it. If you're stuck and can't figure out how to improve the design, just trawl the internet for ideas or draw wireframes on scrap paper.

This channel is FULL of great design advice. The videos where the company owner reviews employee work is really valuable.

This video is a little drier and a little more on the analytical side, but again gives great insight into how people use interfaces and why they use them like they do.

Hope there's enough there to keep you busy for a little while and see if UX/UI is the direction you'd like to move toward :)

> Okay, that makes sense. For clarification purposes, is a spec the documentation?

Languages generally speaking have a documentation which specifies itself. That's the spec for the language. Someone interested in creating a compiler, interpreter, or some sort of analyzer, and so forth for the language needs to know how the language is supposed to work. The spec is the document which talks about that in detail. It's like the official documentation if you will.

> And just to make sure I'm interpreting it correctly, do you mean that because Scheme (at least R5RS) had a small pool of reserved keywords and special forms, it made it minimalist, while languages like Clojure and Haskell allowed the programmer to have a wider range of tools at their disposal?

"Minimalist" is not very exact terminology. It means the language has a small set of concepts and things that you can use. The nice thing about scheme is that from this small set of features, you can do tons of stuff. It usually implies a small set of keywords, but that's not just it. Generally speaking, it has a small features set, which isn't very exact terminology either.

> Do you think your previous experience (the C-based DS&A course and the PHP web dev) help you get through SICP? Or was that knowledge independent of what was taught in SICP, and didn't really apply?

These weren't courses per se. I did this before getting into college. The C programming I was talking about came from K&R2 (https://www.amazon.com/Programming-Language-Brian-W-Kernighan/dp/0131103628/) and looking things on the web. I think it helped. Not sure how much. I don't think the PHP web dev helped.

> Would you recommend anyone to take any sort of background/intro course (e.g. the MIT 6.00 intro course, perhaps) before delving into SICP?

I have no clue what is the better choice in here. Try both at the same time? I think MIT 6.00 even uses "how to think like a computer scientist" (the book I mentioned before).

> I think I might take a look at that. Is it meant to prep students for SICP even though it's taught in Python? Or is it meant as a general introduction to programming?

Both. It's meant as an introduction to programming and computational problem solving. In one of the lectures I think the professor talks about how people do better in SICP if they take this course before.

> I only ask because each language has its own paradigm, so I don't know if one's knowledge of Python would transfer well or apply well to SICP/learning Scheme. You can of course implement objects in Scheme, and do other OOP-based things, but it's not as laid out or simple as it is in Python, from my experience at least.

That is true, but there is more to it than that. Each language has its ways of doing things. When people are making new languages, they're highly influenced by other languages. To the point that most languages I've seen have nothing new but a few pieces, and most of everything else is just a "rehash" of ideas from other languages. Generally speaking, you'll see a lot of commonalities among several languages. It is true that each language has its style, but that style shares plenty in common with other styles from other languages. There will be things in common, and very rarely stuff you learn in one language won't help you in another language.

Even though the way you program in python will be different from the way you program in scheme, there is plenty in common.

In the end, you'll have a bag of cohesive programming techniques. That's not really language dependent as much as some people will tell you. Languages aren't that important as far as I can tell. I remember, back when I was starting to learn how to program, giving real importance to programming languages. Maybe they are really important, but it doesn't seem to me like they are anymore. The programming techniques and ideas behind them are though. The language is just a "conduit" by which you apply those techniques to solve problems, which has its importance but it's greatly exaggerated by most programmers if you ask me. In fact, in SICP, you'll end up learning that a way to make problem solving more approachable is to make a language that is a better means to apply the programming techniques that you think help in solving the kind of problem that you want to solve.

Nowadays, some languages are nice enough that you'll be able to do that by just cleverly designing a new library or framework. Making new languages is still valuable though, and in my opinion, underrated.

> Truth be told, though I am younger and wasn't around for when CS was emerging [...]

I didn't see it emerging either. I started to study programming and CS in 2006 (I think). All I've said is based on "stories" and reads that came up while I was reading books, reading blog posts, talking to people, etc.

...continued...

> 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.
  
  Resources:-
  
  > 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
  

I'm going to go against the grain here with my recommendation. I'm a guy who was in a similar position years ago. I've since transitioned from web development to game programming and have working knowledge of 7+ languages.

Dude, don't sweat these feelings you're having. You're just at a wall. We all reach different kinds of walls in this career and they're really the best thing ever. It means you're about to jump ahead in skill by at least 10x. You just got to find the trigger for it. Be patient and try different things. Go check out Udacity and do some courses on there. Also this is the time to start reading books. Not just any cheap book you find. Good books that will give you the perspective of an industry professional. Books like JavaScript: The Good Parts, Code Complete, The Pragmatic Programmer, or The Little Schemer. Also it doesn't matter what language the books are in to enjoy it. 98% of all programming languages are the same anyways, which you'll soon learn. For the most part, they just have moderately different ways and syntax to do the same thing.

I would recommend not switching platforms from the web. One of the most important skills guys like us can have is seeing where technology is heading and betting on the right horse. It's very clear that webapps are going to be even more important in the future. You can already make desktop apps with web technology naively in pretty much all major OSs now.

I say learn JavaScript front and back. Read JavaScript: The Good Parts and JavaScript: The Definitive Guide cover to cover. Once you learn JavaScript it'll be very easy to transition to any C-based language, which is most of them. In fact I credit JavasScript for giving me the basics to jump to just about any language comfortably and pick it up in a few weeks.

After that, learn a good server side language like Java, Python, or C#. (C# is in very high demand, and has many applications) Or learn all three and you'll be very well positioned career wise. Well, make sure to get some experience with SQL too for good measure.

Also if you want to have a good challenge instead of being bored on those easy things, like drawing shapes, why don't you try Udacity's fine WebGL course? Jumping in the deep end isn't bad as long as you don't expect it to be easy.

Books on project management, software development lifecycle, history of computing/programming, and other books on management/theory. It's hard to read about actual programming if you can't practice it.

Some of my favorites:

• Code: The Hidden Language of Computer Hardware and Software - GREAT choice I notice you already have listed. Possibly one of my favorite, and this should be on everyone's reading list who is involved in IT somehow. It basically how computers and programming evolved and gets you in a great way of thinking.
  
  
• The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography - Another great history book on code and how things came to be. It's more about crypto, but realistically computing's history is deeply rooted into security and crypto and ways to pass hidden messages.
  
  
• Software Project Survival Guide - It's a project management book that specifically explains it in terms of software development.
  
  
• The Art of Intrusion: The Real Stories Behind the Exploits of Hackers, Intruders and Deceivers - A fun collection of short hacking stories compiled and narrated by Kevin Mitnick, one of the most infamous hackers. Actually, any of Mitnick's books are great. Theres a story in there about a guy who was in jail and learned to hack while in there and get all kind of special privileges with his skills.
  
  
• Beautiful Data: The Stories Behind Elegant Data Solutions - Most of the books in the "Beautiful" series are great and insightful. This is one of my more favorite ones.
  
  
• A Guide to the Project Management Body of Knowledge: PMBOK(R) Guide - THE guide to project management from the group that certifies PMP... boring, dry, and great to help you get to sleep. But if you're committed enough, reading it inside and out can help you get a grasp or project management and potentially line you up to get certified (if you can get the sponsors and some experience to sit for the test). This is one of the only real certifications worth a damn, and it actually can be very valuable.
  
  You can't exactly learn to program without doing, but hopefully these books will give you good ideas on the theories and management to give you the best understanding when you get out. They should give you an approach many here don't have to realize that programming is just a tool to get to the end, and you can really know before you even touch any code how to best organize things.
  
  IF you have access to a computer and the internet, look into taking courses on Udacity, Coursera, and EDX. Don't go to or pay for any for-profit technical school no matter how enticing their marketing may tell you you'll be a CEO out of their program.

Congrats at getting into NEU. After reading a bit about the school, it sounds like you had to do work hard in your schooling to get into it.

On becoming a sysadmin, be patient. It's going to take a while. However, here are a few things to keep you busy:

exercise 1:

1. Tutor yourself in vim (vimtutor) or emacs (Ctrl-h followed by t). They are
   your world. DO NOT code in an IDE. Code in them all the way through
   your degree.
   
2. Make a custom vim or emacs rc that has syntax highlighting and
   personalizes your editor to you. Become a power user in whatever your
   editor of choice is.
   
3. Make a custom profile and rc file for your shell (choose either bash
   or zsh, but if you go with zsh, you have to learn bash anyway) to
   customize your shell to your liking
   
   exercise 2:
   
4. look up the man pages on the commands below and bash to learn what they do (when you type
   things into your shell that the oh-so-helpful! interwebz tell you to do, you should always understand
   what they do before your run them)
   
5. open three terminals
   
6. in one terminal run:
   strace -eread=all -ewrite=all -f nc -l -p 18100 127.0.0.1 > server_out 2>&1
   
7. in the other terminal run:
   strace -eread=all -ewrite=all -f nc -v -v -n -w 1 127.0.0.1 18100 < /etc/profile > client_out 2>&1
   
8. as root run: tcpdump -s0 -ni lo -w /home/conversation_out.pcap
   
9. use vim or emacs to scroll through the file and annotate everything you see in
   the file until you understand all of it and use wireshark to annotate everything
   that is happening on the network in that pcap you had tcpdump write out all
   the way up the OSI stack
   
   exercise 3:
   
10. look up the man pages on the command below and bash to learn what they do
    
11. open a terminal and run:
    strace -eread=all -ewrite=all -f wget -qO /dev/null www.google.com > wget_out 2>&1
    
12. as root run: tcpdump -s0 -ni lo -w /home/wget_out.pcap
    
13. use vim or emacs to scroll through the file and annotate everything you see
    in the file until you understand all of it. include everything that happened between
    your host and google (you don't know google's internals so just assume they're
    running an apache server) over the network in the annotation. study a webserver
    (apache, lighttpd, nginx) in debug mode with strace to understand what happened
    on the other side of the network connection and use wireshark to annotate everything
    that is happening on the network in that pcap you had tcpdump write out all the way
    up the OSI stack
    
    

• learn the config files and log file formats for major Open Source software (programs such as apache, a syslog daemon, postfix, BIND, ISC DHCP Server, xinetd, ntpd, etc.)
  
• learn how to monitor these programs and servers running them (nagios, graphite) and the networks they communicate over
  
• have basic understanding of cvs, rcs, git and svn. have advanced understanding of git or svn or both. store ALL the code you work on from here on out in your own software repo and keep it backed up.
  
• learn how to compile open source programs from the ground up and build your own packages (both rpm and deb formats)
  
• learn about puppet, fabric, capistrano, chef, mcollective
  
• learn about rabbitmq and stomp message brokers
  
• learn file permissions, user/group ownership, absolute and relative paths and how these translate to structures in the filesystem
  
• learn perl compatible regexes inside and out
  
• learn how to script in a bourne compatible shell, perl, python and ruby and get really good at scripting in shell and one of the other languages
  
• learn how to read C and be able to write simple programs in C. use gdb to single step some of these programs (both lines of C code and x86 instructions) and learn how they interact with the stack, heap, environment, kernel, c-library functions etc.
  
• play with sqlite, postgres and mysql to get a general idea of how databases work
  
• pick a web framework and set it up in a webserver, learn MVC and use a database back end as you develop some apps. you could track your homework or whatever with the apps you make but the point is learning. any of rails, django, pylons, sinatra are fine. starting with sinatra and sqlite is probably easiest.
  
• learn how to harden your operating system so that ONLY the services (daemons) that the OS needs are running
  
• learn how to write iptables rules to protect your host
  
• get one or two trusted friends to attack the host that you've hardened and see if they can compromise it
  
• learn the basics of all these protocols and their addressing schemes (where applicable) and any crypto they use: IPv4 (TCP, UDP, ICMP, ARP), IPv6, HTTP, NTP, SMTP, POP, IMAP, TLS/SSL, SSH, NFS. Get familiar with the network packets that all of these protocols generate.
  
• learn the OSI stack and where protocols and various types of network gear live in the stack (hubs, switches, routers, firewalls, load balancers). all sysadmins should have CCNA level knowledge or better when it comes to networking.
  
• learn how to debug and troubleshoot. those friends that attacked your system for you? have them break something on your system. then you go in and figure out what's not working and fix it. do this again and again. if you can find some like minded folks then work together on all this stuff and learn from each other. good sysadmins work in teams to make things happen. we don't teach this in college or secondary ed. the work place ideally (hah!) is all about groups of people pulling off the impossible together.
  
• learn how to search in search engines with all the advanced operators that average folk don't use. search engines save you when you run into some weird error message you've never seen before that others have.
  
• hang out on serverfault and stackoverflow and learn from others
  
• learn the following commands/programs (and what type they all are. 'type' is your friend): ack-grep, apt-cache, apt-get, ar, as, autoconf, automake, awk, base64, bc, bison, bzip2, cal, cat, cd, chgrp, chmod, chown, cpio, curl, cut, date, dd, df, dig, dpkg, du, echo, env, eval, exec, exit, expr, false, fg, find, flex, ftp, fuser, g++, gcc, gdb, gnupg, grep, gzip, head, help, history, host, hping3, id, install, iostat, jobs, kill, killall, last, ld, ldd, less, lftp, ln, ls, lsof, make, man, md5sum, mkdir, mknod, mktemp, more, mv, nc, netstat, ngrep, nice, nm, nmap, nohup, nroff, nslookup, ntpdate, od, openssl, pax, pcregrep, ping, pkill, ps, pstree, pwd, readelf, rm, rmdir, rpm, rsync, scp, screen, sed, set, sipcalc, size, sleep, socat, sort, ssh, stat, strip, stty, su, sudo, tail, tar, tcpdump, telnet, tmux, top, touch, tr, type, uname, uniq, vmstat, wc, wget, who, whoami, xargs, yum, zcat
  
• learn how to use shell script snippets and perl/ruby/python oneliners to make yourself more efficient at the commandline
  
  Read these whitepapers:
  
  
• http://labs.google.com/papers/gfs-sosp2003.pdf
  
• http://labs.google.com/papers/bigtable-osdi06.pdf
  
• http://labs.google.com/papers/mapreduce-osdi04.pdf
  
  Buy this book and learn it inside and out. It is your bible.
  
  If you do all this and learn it well, get a couple years experience under your belt (frequently there are computer labs that students can work in in college, that is one place to go) and then move to Silicon Valley or some other hub (sounds like you'll already be in Boston--there should be opportunity there). You'll never run out of work and you'll have the opportunity to try to work for the companies that make directly make money from their computing systems instead of being inside an IT shop that is a cost center in some company that does not appreciate you.

As other's have said, K&R is a great introduction to C, but not a great introduction to programming/computer science. I think more people should try to C as their first language as it gives the student a better idea of what the computer is actually doing than high-level languages. I wish I had a modern book I could refer you to for learning C as a first language, but I am out of the loop, however, I have heard great things about Harvard's free online course: Introduction to Computer Science which uses C (and some other languages).

As far as learning how to be a better programmer, I think one of the key things is to 1) strive to understand what is happening under the hood. 2) Break large problems into smaller ones 3) Logically order the operations needed to complete the tasks that solve the problem, 4) Learn multiple programming languages.

Some tips for becoming a better programmer

Strive to understand what the computer is doing when you execute your program

Understanding what the compiler/interpreter is doing with your source code, how the the processor executes the binary and how information is stored/accessed in memory will help you write more efficient code. The C language is great for learning these things once you start to wrap your mind around it. I would also recommend learning computer organization and hardware. One book I found that really helped me learn what a computer does is The Elements of Computing Systems: Building a Modern Computer from First Principles. I would recommend a casual reading of it, don't get too hung up if you don't quite 'get' it. Read it and see what sinks in. After you get better at C and maybe learn another language, come back to this book and read it again with closer scrutiny.

Break large problems into smaller ones. Logically order the operations needed to complete the tasks that solve the BIG problem

Before I write a single line of code I will spend days, weeks or even months just planning the program out. Flow charts and lists, pseudo code are your friend. Identify your large problem, think about all the different steps needed to get there, write them all down. Determine how to what you need to do to complete each step. Determine if you are doing the same task multiple times (I keep writing data to this log file, I keep checking to see if this array is full, etc.), if so, then you need a function for that. Write this all down as a human readable list of steps. Once you think you have solved the big problem, start coding the small stuff. Write small programs that complete each step you identified and test each little program. Once you've written all those little programs, put the pieces together. Check out How to Think Like A Programmer. It's an excellent book in this area.

Learn multiple programming languages

Again, stick with C until some things are really clicking for you. Eventually though you need to learn another language or two before the "thinking like a programmer" will really sink in. The more languages you learn, the easier it is to learn even more languages. You will begin to see the patterns in languages. You will notice the different approaches that different programming paradigms take. There is a reason that nearly every book, course or tutorial on learning a language follow very similar trajectory: What datatypes exist in this language? How to declare a variable of a particular type. How to output text to the screen, how to cast a variable to a different type, how arrays work in this language, how IF/Then/Else works, How loops work, etc. These are things (nearly) every language has and they are the first steps to learning how to work with that language.

Hope some of this helps!

I have an internship lined up, but I'm really excited to be learning outside of that too. You should check out The Elements of Computing Systems by Nisan and Schocken. I'm going to be working through this book throughout spring semester and the summer. I think it will provide a foundation for every low-level part of CS and help fill in some gaps that I'm missing.

If you're excited about web dev, you could make a website with Ruby on Rails, Django, Flask, Node, Meteor, etc. There's always another good web framework that you could learn.

If you're into system programming, programming languages, or compilers, there are tons of great tutorials and guides online. I'm currently working through Learn C: Build Your Own Lisp. I'm really looking forward to doing Implementing a Language with LLVM. If you didn't already know, LLVM was started here!

If you haven't finished core math yet, there's Linear Algebra on Khanacademy. I think Salman Khan is one of the best teachers I've had. The videos are very concise and very clear. There's also a great series on ML on YouTube. It explains the theoretical underpinnings of the algorithms, but doesn't really show how to use them. If you want to use them, your best bet is the Python library scikit-learn.

For reverse engineering, here's a fantastic challenge site, and here's a good book that you can view online.

There's so much to do, and not enough time to do it! If you constantly work on a few things, little by little, it will all start to accumulate. Good luck and have fun this summer!

Designing Interfaces is great, and I find myself coming back to it when I'm stuck on something. I should note, however, that the examples focus primarily on desktop applications. It's not a stretch to apply most of the concepts to web apps, but some of the patterns aren't really applicable. However, I primarily do web work and I still think it's worth getting.

A classic Web usability book that's really easy to get through is Don't Make Me Think. Much of what makes for good web design is common sense, but it's nice to have it reinforced/verified.

If you're interested in site architecture (you should be) or some theory behind decisions behind visual design (particularly regarding heavy information), I'd also recommend The Information Design Workbook. Half of it is theory and the other half is examples and case studies. It also has some really nice guidelines for working with clients, such as "What is a design brief? Why do I need it? What should be included in it?"

Designing for Interaction is alright... The interviews in it are interesting, but the subject matter is pretty basic. That being said, it is a good primer. I'd definitely pick Designing Interfaces over this, though, if you're choosing between them.

I've heard good things about Designing Web Interfaces, but I haven't read it myself, so... I can't personally recommend it. (O'Reilly generally has pretty high standards, though, so it's probably a safe bet.)

I'd second useit.com and smashing, but sometimes, nothing beats books.

(If you're interested in getting more into the psychology of it, or are interested in a specific topic regarding UI/UX, let me know, as I have more recommendations... I just don't know what you're interested in.)

Computer scientist here... I'm not a "real" mathematician but I do have a good bit of education and practical experience with some specific fields of like probability, information theory, statistics, logic, combinatorics, and set theory. The vast majority of mathematics, though, I'm only interested in as a hobby. I've never gone much beyond calculus in the standard track of math education, so I to enjoy reading "layman's terms" material about math. Here's some stuff I've enjoyed.

Fermat's Enigma This book covers the history of a famous problem that looks very simple, yet it took several hundred years to resolve. In so doing it gives layman's terms overviews of many mathematical concepts in a manner very similar to jfredett here. It's very readable, and for me at least, it also made the study of mathematics feel even more like an exciting search for beautiful, profound truth.

Logicomix: An Epic Search for Truth I've been told this book contains some inaccuracies, but I'm including it because I think it's such a cool idea. It's a graphic novelization (seriously, a graphic novel about a logician) of the life of Bertrand Russell, who was deeply involved in some of the last great ideas before Godel's Incompleteness Theorem came along and changed everything. This isn't as much about the math as it is about the people, but I still found it enjoyable when I read it a few years ago, and it helped spark my own interest in mathematics.

Lots of people also love Godel Escher Bach. I haven't read it yet so I can't really comment on it, but it seems to be a common element of everybody's favorite books about math.

I’ve been working on this for a while, so I might as well drop it here. It should provide an authoritative answer for “How do I get started in CyberSecurity”

Before I get started, there are a few things I need to explain about cybersecurity - There are a ton of different areas of “CyberSecurity”.

This post is specifically catered around the core concepts of cybersecurity.

The most basic thing you need to understand about cybersecurity: It revolves around stuff communicating with other stuff. Anything from side-channel attacks to large-scale DDoS’ - stuff is insecure because stuff communicates with other stuff. Communication can be hard understand and even harder to define (let alone secure). I know this is a very vague statement, but it’s one of the core, fundamental concepts of cybersecurity.

The second most basic thing about cybersecurity you need to understand - “hacking” (I hate that word) as it’s known is not some bond-villain type activity. It’s intentionally mis-using something that already exists in a way that introduces a security flaw into the environment. Sometimes the right circumstances line up and this flaw can be leveraged into something, but sometimes it can’t.

I split up my resources into offensive-based and defensive-based because it’s important for you to understand that while each of these groups are individually important, each knowledge area is not as effective without the an understanding of the other one.

One other thing to note - Certifications are great, but you need to de-couple the idea that certifications=knowledge/skills in this field. There are certainly certifications that break out of that mold, but for the most part, this holds true. I’ve ordered them in the order in which I used/learned with these resources, so you can follow-along directly in order (if you want to). I learned offense first, so that’s the way I’m laying it out here.


Offensive-Based:


I started my career in InfoSec by studying for the most basic, foundational certification: The Security+. This is the best beginner-level cert that says “I know something about security.”

I learned by going through Professor Messer’s entire course, and I felt pretty ready after I went through it all. Here’s the link to his Sec+ course

Now, lets get into some practical stuff. OverTheWire. These are war-games, or CTF’s - challenges designed to test your practical ability in security, but also designed to help you learn new things. CTF’s are the absolute best way I’ve found to learn security. Here’s the link to OverTheWire in case Google is down. If you get stuck, here are some helpful write-up’s.

Do them in this order:

• Bandit
  
• Leviathan
  
• Natas
  
• Narnia.
  
  At this point, you should be set to start with the books and Hacking Labs.
  
  
• Penetration Testing (Book, Follow-along labs)
  
  
  
• Hacking, the Art of Exploitation (2nd Edition, Book, follow-along labs)
  
  
  At this point, I’d recommend going for another certification - CEH. Once you have the CEH, you’re ready to move into more practical-based certifications. Here's what I used to learn and practice the CEH:
  
  Now, lets get into some more practical exploitation. PentesterLabs focuses a bit more on WebApp stuff, but I’ve found its the best intro-environment (as it is relatively scripted scenarios, and you don’t have to do as much recon). They're fairly explanatory, and will walk you through the solution if you get stuck.
  
  
• PentesterLabs
  
  
  Next, lets get into HackTheBox (Exploitable virtual machines, ranging in difficulty. You’re going in mostly blind here, so you have to do your own recon and enumeration): HackTheBox
  
  Here are some helpful write-ups (Written Explanations):
  
  
• GitHub
  
  
• 0xRick Webiste
  
  Also, there’s some super awesome video explanations by IppSec
  
  
  After you get through most of these, you should be set to start on your OSCP. The OSCP contains a course (Penetration Testing with Kali), a lab environment (~50-60 vulnerable boxes), and a practical lab test at the end. OSCP
  
  After you’ve completed the OSCP, then you have enough knowledge to continue directly down the cert path, and the courses (in combination with the certs) put out by Offensive Security contain enough good content to where you don’t have to study other resources. The certification path from here on out splits into two different areas: Technical, and management.
  
  
• Technical:
  
  • OSCE (OSCP 2, basically)
    
  • OSWE (OSCP but for web exploitation)
    
  • OSEE (OSCP 3, really fucking hard).
    
    If you’re at this point, getting past the OSEE, you can pretty much walk into any offensive-based job, slap you’re cert on the table, and they’ll hire you. You don’t need my help anymore here.
    
    Now, here's the management path:
    
    
• Management:
  
  • CISSP
    
  • PMP
    
  • MBA
    
    Having the technical background of the OSCP, plus a CISSP, PMP, and MBA would create an extremely potent executive - one who can understand the technical details and risk, and who then could translate that into verbiage that other executives could understand.
    
    
    So, you’re overall standard security offensive certification path should look something like:
    
    
• Security+
  
• CEH
  
• OSCP
  
• OSCE
  
• OSWE
  
• OSEE
  
  OR
  
  
• Security+
  
• CEH
  
• OSCP
  
• CISSP
  
• PMP
  
• MBA
  
  Now, for the Defensive-based side.

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.
   

Algorithms.

Algorithms is an important class, but depending on how its taught, it may or may not prepare you for the challenge of actually developing an algorithm to solve a problem.

Its important to be familiar with certain algorithmic concepts. Each concept (CLRS is a great book for this but it can be...difficult to digest) is a type of solution for a certain type of problem.

Once you have some core tools in your algorithm tool box, then you can start to see how certain problems resemble certain other problems and how a solution can be crafted as a modification of a similar solution.

But to me, the real skill with algorithms isn't whether or not you can memorize a ton of algorithms, its taking a very systematic approach to developing the algorithm, and there are lots of books and classes that aren't very good at helping you learn that part. I find that sections of Programming Pearls and Programming Interviews Exposed are actually very good at helping explain the process of finding the solution.

Having a good process of algorithm building is much more important, imvho, than being able to memorize every algorithm in CLRS. That takes some study, but a lot of practice.

Data Structures:

Anytime you are writing a piece of code, you are probably doing a set of steps that looks like this:

1. Problem definition
   
2. Algorithm design
   
3. Data Structure choice.
   
4. Implementation.
   
5. Testing.
   
   Data structure choice is on that list, separate from implementation for a reason. IMVHO, smart data structure selection is what HELPS you arrive at an elegant implementation...a poor choice can yield similarly poor results in implementation.
   
   Data structures are important. Learning how to make them from scratch (lists, trees, stacks, etc...) is a good way to build your skills in a language, and its frequently the meat of programming interviews in some languages...but in the real world, you will very likely spend most of your time just focusing on selection and then using an implementation from an already well established/tested library.
   
   Knowing when to use a queue vs stack, when to use a list/array versus a hash, knowing what kind of tree will perform better under the specific conditions of your program (avl, red/black, splay, etc...)...these are things that when chosen well, will save you a massive amount of headache in the implementation and testing phases of development. Learning how to traverse those data structures is important too, for example: Recursion is taught to every cs graduate when they learn trees but then in production code it can be frowned upon for various reasons such as what happens when someone who isn't great with recursion has to maintain/debug it, or when it would put too heavy a load onto the call stack.
   
   Also, what /u/bvcxy said is spot on, its one thing to know the theory, but there is that whole other side of understanding source control, how a makefile works, learning how to use continuous integration tools like jenkins.
   
   And we haven't even gotten into debugging, that is its own skill and you will eventually also need to understand how to debug with breakpoints, inspect memory, check your code for leaks, etc...
   
   The nice thing is that so many IDE's out there are integrated with source control and memory inspection tools, so you can pick a good IDE and dive deep into understanding how to get the most out of it. Write a program in C/C++ and then deliberately put a heap memory leak into it, and learn how you can catch this with tools but also how you can inspect the memory at runtime with breakpoints to see what happens.

My suggestion is always to start with Python. It's a very high level language and it's very easy to learn. In fact, Python recently became the most popular language to teach beginners. I know you wanted to learn Java, but there are several things about it that make it not so great for beginners, as well as several things about Python that make it good for beginners (ask why if you're interested, but it may be a bit technical). As a programmer, you will likely learn a dozen or more languages (I've learned over a dozen in school), so saving Java for a bit later isn't really an issue. You'll find in programming that a lot of the important things apply to most languages, so learning these allow you to apply them to new languages quite easily. My university now uses this book in the first year computer science courses.

Get yourself situated with a free GitHub account. GitHub is my favourite version control. If you have a student email you can get a free private repository (so others can't see your stuff). If you don't have a student email to use to get one, you can still make a free account, but it will be public. What that means is that anyone who navigates to your account can see all your code. Since you're just starting out, it shouldn't matter if people browse your code, there's not much to see since it's just you going through the basics. GitHub has a tutorial for new users and also has a user-friendly client that makes it all really simple. You can save the more complex stuff for later until you're comfortable.

Once you've gone through Python and learned a bit, it's time to get into some of the language-independent things. Introduction to Algorithms is an amazing textbook. The authors are some of the most well respected people in the field and I've used it in school in more than one course. You can go through this at any time. I recommend you programming some of the things (they provide some code as well), and perhaps trying this stuff in Java might be a good segway from Python to Java.

If you can afford it I'd highly recommend this course on udemy. Its $35 but theres always tons of udemy coupons floating around. I've been working through it and it definitely has helped me get a better understanding of both the front end and back end in web development since there's code alongs, exercises, quizzes, and you even make a bunch of small websites as well as a couple of actual web applications. That being said I'm not affiliated with it in any way. Just sharing what Ive been using to learn and its been very helpful.


Also there's tons of books available both paid and free.
As other people have mentioned, Duckett's books on html, css, javascript, and jquery are very beginner friendly with colorful and easy to understand material.

This is a good one that I've been going through to learn about UI/UX and the overall look and usability of your website. It basically teaches you how to make your website more approachable to whoever is navigating it.

I don't think anyone else has mentioned it but Udacity also has tons of free content, a large majority of it being web development and programming courses.

Other than that you're honestly going to just have to start messing around in a code editor and see what does what. Come up with an idea and really just start trying to code it. It could be a small one pager or it could be the start of your web development portfolio. A big thing that I've come to learn is that when you decide that you want to build something and you have no idea what you're doing, grab a good old pen and paper and write down or sketch what you want to do. Sketch what you want your page to look like. Then figure out how to code it. And if you get stuck google is your best friend. Break down what you want to do into smaller manageable chunks, do one thing at a time, and don't be afraid to get your hands dirty. Being a computer science student, this is the best advice I can give you when it comes to learning this stuff.

I say this all the time, but: Who would have thought that in the 2012, the greatest OS war of our day would still be BSD vs SystemV (iOS vs. Android)?

Generally, a focus in Windows is going to take you into corporate IT, building internally-oriented tools to support organizations. Here you'll want to learn bout VMWare, the full Microsoft stack, and look closely at tools designed for Enterprise support. There's less demand in this arena for nix, but also less chance to make a real impact on the world. Sure, there's something to be said for helping maintain the compute clusters inside of banks, or using Altiris or similar tools to manage hundreds of desktops for gigantic offices. I've done this myself, but I didn't have very much fun.

For my money, where you want to be is in web operations, building the systems that drive popular websites. Think about Instagram, Etsy, Netflix, companies that move enormous amounts of data around on the cheap, with relatively tiny staff. Read the blogs by the infrastructure team behind Etsy, and you'll realize quickly that these guys are geniuses.

Here you'll want to learn about how to interact programmatically with cloud compute providers, such as Amazon AWS, Rackspace Cloud, and the OpenStack providers that are starting to pop up, like HP. (A cloud provider is generally not just virtualization, but virtualization coupled with an API. It may sound small but it's a big difference!)

Here's some reading: If you want to learn a lot about nix operating systems, check out The Armadillo Book and The Practice of System and Network Administration.

If you're interested in learning web operations-oriented sysadmin, which is a VERY interesting place to be, also check out The Art of Scalability -- well, the first 2/3 anyway -- and the followup book, 50 Scalability Rules.

And especially, especially read and understand this, because there won't be many web-oriented companies still in business by 2014 that don't follow this process: Continuous Delivery.

Good luck! You picked a GREAT time to get started in the industry. The 00's were pretty boring by comparison. :)

EDIT: I KAN SPEEL

I am not totally sure what you are asking for actually exists in book form...which is odd, now that I think about it.

If it were me, I would think about magazines instead. And if you really want to push him, think about the following options:

1. Science News, which is very similar to the front-matter of the leading scientific journal Science. This includes news from the past month, and some in-depth articles. It is much better written -- and written at a much higher level -- than Scientific American or Discover. For a very intelligent (and science-interested) high school student, this should pose little difficulty.
   
2. The actual journal Science. This is weekly, which is nice. In addition to the news sections, this also includes editorials and actual science papers. While many of the actual papers will be beyond your son, he can still see what passes for presentation of data in the sciences, and that is cool.
   
3. The actual journal Nature. This is also weekly, and is the british version of the journal Science. In my opinion, the news section is better written than Science, which is important as this is where your kid's reading will be mostly done. IN addition, Nature always has sections on careers and education, so that your son will be exposed to the more human elements of science. Finally, the end of nature always has a 1-page sci-fi story, and that is fun as well.
   
4. If you must, you could try Scientific American or Discover, but if you really want to give your kid a cool gift, that is a challenge, go for one of the top three here. I would highly recommend Nature.
   
   If you insist on books...
   
   I see you already mentioned A Brief History of the Universe, which is an excellent book. However, I am not sure if you are going to get something that is more "in depth." Much of the "in depth" stuff is going to be pretty pop, without the rigorous foundation that are usually found in textbooks.
   
   If I had to recommend some books, here is what I would say:
   
   
5. The selfish gene is one of the best "rigorous" pop-science books out there. Dawkins doesn't really go into the math, but other than that he doesn't shy away from the implications of the work.
   
6. Darwin's Dangerous Idea by Dennett is a great book. While not strictly science, per se, it does outline good philosophical foundations for evolution. It is a dense read, but good.
   
7. On the more mathematical side, you might try Godel, Escher, Bach, which is a book that explores the ramifications of recrusiveness and is an excellent (if dense) read.
   
8. You could also consider books on the history of science -- which elucidate the importance of politics and people in the sciences. I would recommend any of the following: The Double Helix, A man on the moon, The making of the atomic bomb, Prometheans in the lab, The alchemy of air, or A most damnable invention. There are many others, but these came to mind first.
   
   Hope that helps! OH AND GO WITH THE SUBSCRIPTION TO NATURE
   
   edit: added the linksssss

First of all, applause for the great start.

Here are some criticisms/suggestions I would like to offer. Keep in mind, I am not assuming your level/experience as a software developer:

1. Functions with smaller size. You see, most of the functions that you have written is lengthy because of the sql statements. Here comes my second point.
   
   
2. Separate business logic, application code, data storage related stuff etc. Keep things modular. That separation is important because you want things to be maintainable and reusable. Your code should be open for extension, but close for modification. If that does not make sense to you, that's perfectly fine, just start from this
   
   
3. On that note, since you are using flask, might I suggest using flask-sqlalchemy instead of sqlalchemy? You may like it better. I know you have mentioned
   
   > I force myself to write raw SQL Request to get better with SQL
   
   while that is commendable, it is not really a good idea to write raw sqls in production code if there are ORM library alternatives available. Remember, it's not always you that is going to read/modify the code. While ORM syntax will be fairly universal, your style of writing SQL may vary starkly from other people - which is what creates confusion and lets errors sneak in. Even if you want to do that, maybe keep the raw sql in separate modules (point 2).
   
   
4. Instead of computing everything and then sending the result along with the page, maybe create api endpoints for specific sections; render page with bare minimum info and from the webpage make multiple calls to update the page sections when required. This way, it will be far more responsive, user will not be waiting for you to finish all the computation and if you detect any change in any section of the page, you can just update that particular section with an appropriate api call, thereby avoiding a whole page reload. Design choices.
   
   
5. PEP8. You don't have to blindly follow every rule - just make sure you understand why those rules are there, and that if you are breaking any, you know that it is absolutely necessary for accomplishing what you want. Again, what you want may not always be what you actually need - so be really careful.
   
   
6. This is something I wish I knew earlier - Design Patterns. Without going into much details, I would recommend reading these books to start with and really understand instead of memorizing:
   
   • Head First Design Patterns
     
   • Clean Code - focused more on java, but you'll get the ideas are pretty much language agnostic
     
   • Fluent Python
     
     
7. Documentation is also important. Follow the good practices there. A remarkable reference would be Ken Reitz's Requests library.
   
   Finally, remember that all these are just suggestions, and you may already know them. You will decide which ones to take and which ones to leave behind based on your situation.
   
   Again, great job (I also learnt something from this). Just make sure you keep running.

Good for you, you're seeking out your knowledge and it sounds like you're dedicated to learning as well.

You won't get a good sense of what we do alone, especially because it is a very diverse field and can include specializations in storage, virtualization, databases, helpdesk, desktop support, mobile device management, security (which in itself has a number of specializations), operations, project management, monitoring and reporting, copper and fiber networking, firewall management, programming or developing... See my point? You can read a little more on the fields here

Anyway, if your computer is capable I would suggest you at least familiarize yourself with SOME of what we do, try and get Hyper-V running and learn some of the Powershell commands for interacting with the VMs, then use those VMs to run some *nix stuff and learn how to use those.

There is honestly a ton of free stuff, books, documentation and such available for you, you just have to know where to look and what you might want to see. The search bar here sucks but use the google advanced search for this subreddit and there is a ton of stuff to find, here's a few examples you may find useful:

• Lots of small tips
  
  
• The Sysadmin Bible #1 & the updated one, #2
  
  
• Microsoft Dreamspark has a lot of free software for students, including SQL Server, Windows Server, etc
  
  
• Free Powershell courses,
  
  
• Free books #1, #2, #3
  
  
• Learning to code with CodeAcademy, Free courses from Microsoft Virtual Academy incl training labs,
  
  
• Certifications: CCNA routing and switching videos, Server 2012r2
  
  ... I've got literally dozens and dozens of relevant links that you might find useful. My suggestion is to start wide and shallow and figure out what you might interesting, then explore that further. If you want career advice I would suggest you focus on programming and *nix administration (there's a great comment on here in the last year with a path of things to accomplish) as these would give you the greatest variety of skills to create programs, apps, shell scripts, admin servers, etc... Also, don't neglect your soft skills or negotiation abilities as they are very valuable in helping you complete work when not working alone. Good negotiating skills will help ensure you don't get a $14/hr job when you're doing the work of a $70k

Hey /u/Xerack! I'm the original author of the post linked here.

Appreciate the feedback! If you think I could clarify anything better, please let me know.

As far as resources for Reverse Engineering, I can provide you with a baseline that I would recommend starting with.

x86 Assembly:


If you don't know assembly language at all, this list of videos was where I picked up a decent amount of x86 assembly language.


A few good books would be:

• Hacking: The Art of Exploitation I am a huge advocate for this book. I learned a lot from this and have read it multiple times. It is written very well and teaches someone with no experience how to do C programming and assembly. This is mainly a book for learning exploitation/vulnerability research, but that can play hand and hand with Reverse Engineering. It will show you the assembly language break down of basic exploits and this can help you with RE.
  
  
• Practical Reverse Engineering I read through the beginning of this book and it gave me some good foundations of understanding memory and computer architecture for RE along with assembly of course
  
  
• Secrets of Reverse Engineering This book is a bit in depth, but the beginning gives another good foundation for Comp Architecture and assembly stuff.
  
  
• The IDA Pro Book Haven't personally read this book yet, but I have been told it is the defacto standard for learning IDA Pro, and it has examples you can learn from.
  
  Hands On:
  
  
  
• Legend of Random Very useful hands on with tutorials. Mainly based on cracking, but that requires reverse engineering. Highly recommend this!
  
  
• Lenas Tutorials Again, another awesome hands on tutorial, mostly based on cracking as well.
  
  
• Crackmes These are more of challenges once you start to have a little understanding down
  
  Courses:
  
  Tons of courses on youtube. I learn well from visual, so I recommend these youtube videos:
  
  
  
• Basic Dynamic Analysis
  
• Real World Decompilation There are a few videos to this series and he disassembles a game, definitely nice to learn from.
  
  
  Beyond that, Google will always be your friend, and /r/reverseengineering. I also have a bunch of material for Malware RE, but that's a bit different than Software RE, though it is relatable.

As one of the people who commented on that thread, I feel the need to respond to this as rationally as humanly possible.

For starters, let's clear up the difference between fractal mathematics, fractal woo, and what Douglas Hofstadter might call fractal analogy.

1. From the wiki - Fractal Mathematics would be the study of "natural phenomena or a mathematical sets that exhibits repeating patterns that display at every scale" as well as the study of self similarity and iterated functions. While it has grown complex and vast, the studies of fractals and their geometry started out as literally what you say it isn't: people asking questions about self-similarity in nature and asking how to describe it mathematically.
   
   
2. Fractal Woo would be, as OP said:
   
   >“Everything big is just like everything small!” they exclaim, “the universe is self-similar!”
   
   ...and then using such logic to thereby justify whatever silly energy-Reiki-mystical-connectedness-telepathy-de-jour they want.
   
   
3. Fractal Analogy (my term, but run with it) would be seeing patterns in the world which are, indeed, self similar, as tons of stuff in nature is. This includes plant and animal system, as well as consciousness and human experience. The reason I mention Douglas Hofstadter is that he is a PhD physicist who literally used fractal mathematics to predict some pretty nifty real world stuff 35 years before it was confirmed - but Mr. Hofstadter is also an incredibly enjoyable author who muses at length about cognitive science and AI research, often using the analogy of self-similar shapes to help describe what we understand of consciousness in a way that most layman readers can understand. Even if you are not a very capable mathematician, I highly recommend his Godel Escher Bach, which uses fractals and loads of other creative stuff to help conceptualize how the "mind" arises from the brain.
   
   As well, Chaos Theory - the study of how immensely complex patterns emerge from seemingly simple preconditions - is full of fractal mathematics. Given that the universe is absolutely packed with iterated functions and self-similarity almost everywhere we look, I think you can absolutely take the point of view that the universe is fractal in nature, especially when you are in a self-induced state where your brain makes a lot of connections you might normally overlook or not even bother to think about.
   
   My point is that discussing things in the universe as self-similar is useful to mathematicians and non-mathematicians alike; using the word "fractal" to describe natural systems that exhibit those familiar patterns might not be perfectly correct, but it's not itself offensive or an affront to reasonable discourse. I manage a business; so what's your problem if I visualize the structure of my company as a fern leaf with departments and employees as branches off the main stem? What would be the issues of discussing how incredible human cellular morphology really is with my biologist roommate, and citing some cool research someone decided to do about fractal geometry in the way our bodies build themselves?
   
   EDIT: OP's edit makes it more clear his statements were more about irrational folk seeing the universe as a single continuous fractal (that would be the "fractal woo"), and that he is not denying the existence of fractal-like patterns in nature, or that using fractal models can be useful in understanding phenomena. Sorry for any confusion and thanks for the discussion!
   
   EDIT2: /u/ombortron commented pretty well in regards to the utility of the concept of fractals in scientific discourse and otherwise:
   
   >The universe itself doesn't have to be a fractal for fractals to be important.
   
   >Fractals are quite common in our reality, and as a result, that means they are an important facet of reality, and as such they are a legitimate and common topic of discussion amongst people, and this is particularly true of people who do psychedelics.
   
   >Does this mean the universe is 100% fractal in nature? No.
   
   

Umm, I think Python is a good language to start with. It's forgiving and low on boilerplate code. I haven't read it but Learn Python the Hard Way by Zed Shaw is supposed to be decent (and it's free online). I didn't like Learning Python published by O'Reilly. I'd just read reviews on Amazon if Learn Python the Hard Way isn't working for you. Whichever you end up with, I recommend typing all examples from the book into the computer by hand. Something about doing this really helps make things stick in your head. You'll also make the occasional typo and have to debug your program which is something we programmers spend more time doing than any of us care to admit.

I think it is important to try to think of something you want to make and have it in mind while you are learning the language. It can be any software but I recommend a video game. They are really good for this because you can just think up a simple concept or implement your own version of an existing game. Having a goal makes it so you are constantly solving the problems you will encounter while trying to reach that goal which is the most important part of programming (more so than learning the syntax of the language). This is actually the highest rated Python book on Amazon and is all about gamedev with Python.

After you've learned Python to the point where you are comfortable (no need to master it), learn other languages to grow as a programmer. Once you've gotten a couple languages under your belt it's actually really easy to learn even more languages (unless it's a very odd language like Haskell, Lisp, or Brainfuck). The problem solving skills you've acquired often work in any language and you learn some new techniques as you learn new languages.

• Accelerated C++ is the go-to these days for C++.
  
• The C Programming Language is often recommended for learning C but it's pricey and there are dozens of good books on C to choose from.
  
• Head First Java gets recommended a lot for learning Java.
  
• C# In Depth is very highly rated and happens to be written by the guy with the largest score on StackOverflow (a kind of Q&A for programmers).
  
• The D Programming Language I really enjoyed.
  
• Programming Ruby 1.9 is often recommended but it felt more like a reference manual to me. There are higher rated books on Amazon.
  
  

The jQuery documentation is very, very helpful. Every piece of jQuery has example code and a user comment section to provide extra insight. Don't be afraid to check it out, even if you are an absolute beginner. I actually "learned" how to use jQuery before I learned how plain JavaScript works, so it makes for a good introduction to the language because of how easy it is to use. If you learn by doing, then it's a great place to start.

However, you must have a full understanding of JavaScript to get the most out of jQuery in the long run, so you should definitely look into learning JavaScript without jQuery when you are comfortable enough to do so.

I would recommend the text I used in college for learning JavaScript, but I've since learned that it has a 2-star rating on amazon.com and it is still very expensive. It did a good job of teaching a practical application of JavaScript for beginners, but it has a lot of typos that may trip you up if you do the practice examples, and for the price it really should be perfect. If you can find it for cheap, pick it up.

A cheaper alternative that I have not read is JavaScript Step by Step by Steve Suehring. Much cheaper than a college text and highly recommended. An introduction to getting a grasp on JavaScript is most definitely worth more than the 25 bucks you'll spend.

When you start to feel like you could do some damage (in a good way) with JavaScript, you should definitely check out JavaScript: The Good Parts. It will shed a whole new light on JavaScript and help you realize both how powerful and strange the language is. I don't know if your job duties or passion for programming would lead you this deep into JavaScript, but if your goal is enhancing your career, JavaScript is most definitely the next step in the world of web.

When people ask me what JavaScript is to a web developer, I tell them this: HTML makes up the bones of a website. CSS is the skin. JavaScript is the muscles that makes your website live and breathe. Learning it is essential!

Best of luck!

I generally agree with the other replies that a vanilla computer science degree is better than a game degree, but let me use the example of the University of California Santa Cruz (UCSC) game degree to offer a balanced comparison.

At UCSC, the only difference with a computer science versus games degree is one class in the senior year. The fundamentals of both degrees are identical - you take the same math, physics, and programming in the game degree as you would in the CS degree. Only in your senior year does it differ, where as a games major you do a 1 year elective working on gaming group projects using Unity. If you did vanilla CS instead, you would use that year to take something like operating systems, artificial intelligence or databases. Deciding which one is a better fit for you partly depends on your philosophy of the purpose of school:

• Ivory tower camp - If you feel that a university is best served teaching theory and fundamentals, rather than masquerading as a trade school, then you might agree that learning operating systems or databases in a "pure" manner, without worrying about production concerns like working in a group, would be the best use of your time while you have the privilege of being in school.
  
  
• Emphasis on practicality - If instead you concede that while theory is nice and well, the practical needs of the working world sometimes take precedence, then you might feel that the year of working on gaming projects with others and being able to point at a concrete example of something you did would be time well spent in being able to land that first job.
  
  You can see this difference of philosophy being played out in not just the debate over a gaming degree program, but in things like the programming language of choice for first-year students, where some schools lean toward the practical (UCSC uses Java and C++) and some toward the theoretical (MIT traditionally used Scheme and now uses Python).
  
  Specifically at UCSC, I would say the pros and cons are as such:
  
  Pros:
  
  
• Get to study and spend class time on what is presumably your main interest - game development.
  
  
• Dedicated time to a group project that at graduation, you can cite on your resume and be able to say, "I made that."
  
  
• Possibly make contacts with game industry veterans through the program.
  
  Cons:
  
  
• Spend a one-year class being forced to work in groups and deal with the messiness of production tasks rather than being immersed in 'pure' theory like in a more typical computer science course.
  
  
• Slightly negative connation among the uninformed of having the words "game degree" on your resume and possibly having to defend that your fundamentals are as sound as a vanilla CS major.
  
  The first question you should ask yourself is whether the school you're looking at has a comprehensive undergraduate education and a good reputation, like UCSC, or if it's a specialized trade school like Fullsail or DeVry (stay away) with a bad reputation. Not all game schools are bad - both Digipen and Guildhall at SMU are notoriously challenging programs and in my experience working with a handful of their graduates, I found them to be quite competent. Allen Chou will be graduating Digipen with his first job at Naughty Dog (which was Naughty Dog's first time they've hired someone straight out of school rather than someone with industry experience, though it should be noted that Allen earned a previous bachelor's in electrical engineering before attending Digipen). And USC's game school is well known for having produced Journey developer thatgamecompany, among others.
  
  As for the poor working conditions known at most gaming companies - yes, in general you will work more hours for less pay in the gaming industry than you would outside it. Yes, the industry is rife with constant layoffs. It is likely you will need to move all over the country and possibly world as you chase jobs throughout your career. It's up to you to decide if working on games and with other game developers is important enough to you that it's worth that sacrifice. Many people don't find it worth it, and they are not weaker for choosing another path. It's a personal decision of how much it means to you to work on games; alternatives are arguably more sane.
  
  For working at the kind of companies you mentioned like Bethesda and Blizzard, you will need to be an expert at C++. Because C++ is such a large and complicated language to first tackle, I recommend learning C first. My book of choice is C Programming: A Modern Approach by KN King, which is also highly recommended in the C programming FAQ. Or if you prefer a shorter book, many people have learned from the C Programming Language by Kernighan and Ritchie.
  
  For learning C++, there is only one book you need to know to start with: C++ Primer by Stanley Lippman, which is also the #1 recommendation of the C++ FAQ and highly reviewed elsewhere. You do not need to worry whatsoever about C++ becoming obsolete by the time you graduate. But you do have plenty to worry about mastering the language, because there is a lot of material to cover.
  
  I'm a moderator at /r/TheMakingOfGames and I would recommend perusing some of the videos there that show behind the scenes of development companies (though arguably, the bright side of development). Some examples:
  
  
• Behind the scenes of God of War 3 with the programming team
  
  
• Since you mentioned Blizzard, read Patrick Wyatt's articles on the development of Starcraft. He was a lead programmer at Blizzard before leaving to found ArenaNet and making Guild Wars.
  
  
• Nine examples of dirty programming hacks to fix baffling bugs is a Gamasutra article that might give a glimpse at the harried side of game development, when under pressure and lacking time.
  
  
• Naughty Dog's lead programmer Jason Gregory talking about their interview process and culture

Websites:

http://www.smashingmagazine.com/

http://psd.tutsplus.com/ There is one for vector illustrations also.

http://www.lynda.com/

Web design podcast

Books

Your new bible on type

Lee Varis "Skin". Awesome book on working with skintones

Photo-compositing

Web usability testing

Fun stuff:

Flash cards, the fun kind to get your brain going

color swatches by Pantone

Calibrate you monitor; you don't know what colors you can print without a baseline

Just realize what you print and what your screen show can be close, but it will never be 100 percent accurate. This also depend on the viewing conditions. Calibrate your monitor, get a backup system in place, read and make your own assignments, and good luck. If you want to buy a bunch of business cards cheaper than VistaPrint or elsewhere with a digital offset waterless system... try

CopyCraft.com

Unless you have money for letterpress cards, but i would only hand those to decisionmakers that sign checks :)

Also i almost forgot... magazines!!!

Many on this list

And i personally like this one

Also you need to make sure your drawing skills constantly improve. I use photoshop for photos exclusively and it speeds up my workflow and helps me with my understanding of light and creating shadows etc. I can't stress maybe a Figure Drawing class (if you have a bad position it is okay to move to a better "view") or something similar to help work through drawings faster and get a better basis of form. These little notebooks are so handy to keep for quick sketches and ideas, and random people that are potential clients.

A Wacom tablet (unless you can afford a Cliniq) is so awesome to have. I have the XL and it is too much... the Large is sufficient unless space. I hear that the smallest size is just too small for most people.

Here is a awesome glove to help with sweaty hands and to keep it smooth, i actually just got mine and it actually helps with my editing on my tablet.

edit: added moleskin/wacom/smudgeguard info

From Data Classes and Sealed Types for Java:

>Digression -- enums
>
>If the problem is that we're modeling something simple with something overly general, simplification is going to come from constraint; by letting go of some degrees of freedom, we hope to be freed of the obligation to specify everything explicitly.
>
>The enum facility, added in Java 5, is an excellent example of such a tradeoff. The type-safe enum pattern was well understood, and easy to express (albeit verbosely), prior to Java 5 (see Effective Java, 1st Edition, item 21.) The initial motivation to add enums to the language might have been irritation at the boilerplate required for this idiom, but the real benefit is semantic.
>
>The key simplification of enums was to constrain the lifecycle of their instances -- enum constants are singletons, and instantiation is managed by the runtime. By baking singleton-awareness into the language model, the compiler can safely and correctly generate the boilerplate needed for the type-safe enum pattern. And because enums started with a semantic goal, rather than a syntactic one, it was possible for enums to interact positively with other features, such as the ability to switch on enums, or to get comparison and safe serialization for free.
>
>Perhaps surprisingly, enums delivered their syntactic and semantic benefits without requiring us to give up most other degrees of freedom that classes enjoy; Java's enums are not mere enumerations of integers, as they are in many other languages, but instead are full-fledged classes (with some restrictions.)
>
>If we are looking to replicate the success of this approach with data classes, our first question should be: what constraints will give us the semantic and syntactic benefits we want, and, are we willing to accept these constraints?

That's sort of a tricky one, because there are two distinct aspects to learning JavaScript. The first aspect is figuring out how to solve problems using code, and the second aspect is understanding the nuances of JavaScript. (Ideally, the second phase should require much less time, but unfortunately, JavaScript is a bit of a quirky language so even developers who are experienced at solving problems in other languages might need some adjustment time to get used to the unexpected bits).

Regarding the first aspect, I'm unfortunately a little out-of-touch with the JavaScript ecosystem, and am not aware of too many resources that I think do a good job of teaching you how to problem-solve using JavaScript (which, I should emphasize, is different, and probably harder challenge then just teaching you JavaScript).

That said, freecodecamp seems like a potentially good one. If you care only about JavaScript, you're probably going to want to skim through the first bits on HTML and CSS, but the exercises and projects they provide seem pretty damn solid.

Eloquent JavaScript might also be a good one -- the only main problem is that I think it ramps up a little too quickly in places (in particular, the chapters about writing objects). This might be a good "second resource", after you complete a more basic tutorial and have one or two projects under your belt.

Beyond taking courses, the best thing you can do for yourself is just constant practice, whether it's by working on exercises or working on your own personal projects. The only way to get better at problem-solving is via constant practice.

Regarding the second aspect, here are some good resources that I think do a good job of teaching the nuances and tricky bits of JavaScript. I would consider these beginner-intermediate resources -- they might not be entirely appropriate for somebody completely new to programming, but certainly would be useful for somebody who's completed one or two projects and wants a deeper understanding of JavaScript, or for an experienced programmer who hasn't used JavaScript before and needs to ramp up quickly:

• JavaScript: The Good Parts -- it's a pretty small book, and does a good job of giving a very concise and precise definition of what clean JavaScript code looks like.
  
• MDN's JavaScript guide -- this is a no-nonsense set of guides to JavaScript, and has a variety of different tutorials targeted towards different audiences.

No problem. I am by no means an expert in writing code or buffer overflows but I have written several myself and even found a few in the wild which was pretty cool. A lot of people want to jump right in to the fun stuff but find out rather quickly that they are missing the skills to perform those tasks. I always suggest to people to start from the ground up when learning to do anything like this. Before going into buffer overflows you need to learn assembly language. Yes, it can be excellent sleep material but it is certainly a must. Once you get an understand of assembly you should learn basic C++. You don't have to be an expert or even intermediate level just learn the basics of it and be familiar with it. The same goes for assembly. Once you get that writing things like shellcode should be no problem. I'll send you some links for a few books I found very helpful. I own these myself and it helped me tremendously.

Jumping into C++: Alex Allain

Write Great Code: Volume1 Understanding the Machine

Write Great Code: Volume2 Thinking Low-Level, Writing High Level

Reversing: Secrets of Reverse Engineering

Hacking: The Art of Exploitation I used this for an IT Security college course. Professor taught us using this book.

The Shellcoders Handbook This book covers EVERYTHING you need to know about shellcodes and is filled with lots of tips and tricks. I use mostly shells from metasploit to plug in but this goes really deep.

.

If you have a strong foundation of knowledge and know the material from the ground-up you will be very successful in the future.

One more thing, I recently took and passed the course from Offensive Security to get my OSCP (Offensive Security Certified Professional). I learned more from that class than years in school. It was worth every penny spent on it. You get to VPN in their lab and run your tools using Kali Linux against a LOT of machines ranging from Windows to Linux and find real vulnerabilities of all kinds. They have training videos that you follow along with and a PDF that teaches you all the knowledge you need to be a pentester. Going in I only had my CEH from eccouncil and felt no where close to being a pentester. After this course I knew I was ready. At the end you take a 24-long test to pass. No questions or anything just hands on hacking. You have 24 hrs to hack into a number of machines and then another 24 hours to write a real pentest report like you would give a client. You even write your own buffer overflow in the course and they walk you through step by step in a very clear way. The course may seem a bit pricey but I got to say it was really worth it. http://www.offensive-security.com/information-security-certifications/oscp-offensive-security-certified-professional/

I've been thinking about C and its practical implementation after
learning the basics. And to organize the information I tried making
a skill tree as you would find in the game Skyrim or Kerbal Space Program,
where you complete tasks to get points to advance in the skill tree. I hope
the low quality of the image provides enough context that this is not a complete
work and something I'm poking around with, feel free to suggest nodes or resources
for anyone the nodes as the rest of this post will be me trying to provide
some context and resources for each node.

Basic C
It's right there in the sidebar for anyone to get started.
C Programming Language
Pretty much go through this first, generally suggest using a minimal
text editor and the command line to compile programs.

Intermediate C
This has been marked as optional, as a general stepping stone for
using a few more materials to learn or reference before jumping into
any projects. Books like Modern C, practice books, or understanding
pointers could go here. Let me know if you have any suggestions for
books, youtube, websites.

Sockets
Sockets is marked as optional to separate the group. But in general this section
resolves around the concepts of tcp and udb and sending signals between computers.
Example projects for this group are things like making a basic http server
on the http side, or programming with bluez on the bluetooth side. I threw in game server on the end as there are several open source projects that create the back end for games that don't have online services any more. This seems like a good way to get familiar with a specific set of structs and packets, maybe someone can leave some examples if there are anyones that are a good place to get started.

GPIO
General Purpose Input/Output, such as turning an LED light on or off. I haven't gotten into gpio myself very much, and most of the tutorials for it
seem to use python. But this seems like a pretty good use-case for a practical
implementation with C. I could provide some results from a search, but I only want to provide links to tutorials I can vouch for.

GUI (Gtk)
For making user applications with C, GTK seems to be the most common library for
implementing applications with widgets. The best resource for this pdf seems to be
An Introduction to C & GUI Programming, and
there are a few more examples posted in the gtk discorse.

Graphics
This is the node with the most sub-nodes and not the easiest node to organize as
there are a lot of libraries that can be used. For libraries there is GLUT/GLFW/SDL/GTK+/Raylib/EGL. In general GLUT and GLEW seem to have the least features with them being mostly focuses on getting and window and providing OpenGL context. Freeglut provides a decent wiki for getting started, and while the examples are in C++ it's not too bad to translate them back into C. GLFW seems to be the libary that the OpenGL Red Book currently uses.

SDL is a really common and popular library that's been used for a lot of games,
including Open Tyrian. While it's popular, the only strictly C resource I've found for it so far is this blog , which provides a 2D Shoot 'em Up tutorial. Though the most well known tutorials are written by Lazyfoo, and are provided in C++, while these tutorials have probably been ported to other languages I don't know of any C-only examples out there.

The GTK+ library provides the GTKGLArea widget which allows for an OpenGL 3.0 and above context to be created. So it might be a decent choice to work with if you want to create applications that allow for toggles and widgets, along with a 3d view port. A few example applications for GTK can be found here.

For Raylib I haven't tried it, it often gets suggested here and on forums pretty fequently. So maybe someone can provides links, and maybe provide some context of some comparison between Raylib and some of these other libraries. EGL is an option that I've seen pop up here and there, but it looks like it allows you to write directly to the framebuffer for embedded computers without needing to start a desktop. There's a really good series of tutorials that can be found here.

Summary
So this is what I have for resources that I've found so far that fit into the skill tree. I think there are a few more honorable mentions like libpng, or file compression, or POSIX coding and terminal games and applications. And are there any other nodes that you would add to the skill tree?

TL;DR Improve yourself, invest in your future, don't worry about the mistakes...read the books listed at bottom, and practice!

Few months ago I royally fucked up an interview at Microsoft. A really simple question. But I had no experience doing coding on paper instead of a computer.

I spent a lot of time studying various books and paper coding to make sure it wouldn't happen again.

I then had an interview for another (in my mind at the time) dream job. I did fine for all the phone interviews and they flew me over to the west coast for an in person interview for the day. I did well for the first bit until they started pulling out dynamic programming and integer programming questions on me and expecting me. Once again something I didn't prepare for, and f'd up. Didn't get this job either. For the longest time I was really hard on myself at fucking up on both these interviews one after another. Especially this second one since a lot more was riding on it than just the job (another story).

But then I decided I didn't want to have this sort of experience again and expected better of myself. I made myself further improve and brush up on all those concepts as well. Did a few mock interviews with friends, spent some time working on interview type questions on both the computer and on paper. A month or two later I started interviewing again. By this point I was an interviewing machine - and I'm now able to do just about anything thrown at me. I've had my choice of employers and until just recently, was in the situation where I had so many offers I didn't know which one I wanted most. I'll be heading to silicon valley soon at one of the top tech companies in the world with a fantastic offer considering I just graduated.

The point is - learn from the mistakes and improve yourself. I realize you don't want to be that guy spending heaps of time coding outside of work or whatever... but this is an investment in yourself and your career. Do it once, and then just brush up on your skills from time to time. Get into the interviewing mindset and just rock them so you can have your choice of job - and then you can go about your thing once you have the job locked. The up front investment will be worth it!

Things that helped me:

• www.hackerrank.com - practiced a lot of questions on here
  
• www.careercup.com - another great site for questions
  
• Cracking the Coding Interview More help on questions, but also some great insights into the interview process for the larger tech companies and many hints and tips on how to go about solving the more complex problems
  
• Code Complete A great book for helping you to refresh or learn about software design
  
• Eternally Confuzzled Great resource to learn how to think about common data structures and algorithms
  
  Having trouble with Algorithm design/analysis? These are some of the go-to books for that:
  
  
• The Algorithm Design Manual Probably the defacto for learning about algorithm design and analysis
  
• Introduction to Algorithms A great book with many different algorithms and data structures to learn about
  
• Algorithm Design A great book if you want to dive deeper into more complex subjects like graph theory, dynamic programming, search algorithms, etc.. etc..

Here is my advice, take it with a grain of salt:

• There are lots and lots of flamewar worthy disagreements in computer science, programming and technology in general. Linux vs Windows vs Mac, Gentoo vs Arch vs Ubuntu, Ruby vs Python vs Java, Object Oriented Programming vs Functional Programming. Even within languages, certain frameworks have their loyalists and will tell you their favorite framework is the only way to go. Do not get mixed up in this. Follow your interests and enjoy what you're doing.
  
  
• Be patient. Do not try to learn too much too quickly. Since you have another year or so before you start taking computer science classes, you are not in a hurry. You can take this time to learn some practical skills rather than just theory (which is what /r/compsci is all about). You'll find that your classes will teach you really interesting theoretical stuff like how to measure the efficiency of your programs or how to organize your code to make it more maintainable, all of which is very helpful, but it probably won't teach you how to use Maven or how to use some of the things that the industry wants you to know how to use. This is what I mean by practical skills. Its one thing to know what a Binary Search Tree is, its another to know how to use a specific framework. Spend some time on the practical stuff now. That means actually creating stuff like websites or video games (or whatever interests you.)
  
  
• "The perfect is the enemy of the good." Don't try to make your programs perfect. Make them work and try to form healthy habits but do not be the type that settles for nothing less than perfection. If you do, you'll find that you hardly get anything done.
  
  
• Pick one language to specialize in. You will learn more this way in the beginning. A lot of people have stunted their own progress by spending their first couple of years learning different programming languages. Don't do that. You'll learn other programming languages eventually, it really isn't that hard, but you're better off specializing in a specific language (for now) than being crappy at a lot of languages. (I made this mistake.)
  
  If you want to get good at programming, I would recommend the book "How to design programs" combined together with The Racket Programming Language. If you're really up for it, mix in the content from Structure and Interpretation of Computer Programs (which is a great book by the way). If you finished those, you'll have a very good foundation for learning how to program. I would learn a new language (don't specialize in racket) and continue from there.
  
  The downside to learning racket is that it is not a common language, however as I said earlier, you'll find that learning new languages it very easy so this shouldn't be too much of a problem, especially if you're more concerned with forming a good foundation first.
  
  After learning all of that, I would say look into something on data structures and algorithms. There are a lot of great books on the subject. Introduction to Algorithms is considered the classic. If you can get through the whole thing on your own, then you are better then I am.

No, problem. As far as advice goes.

• Sit in the front of the class. The back can be distracting. Last year, people in the back would regularly have, very loud, full blown conversations.
  
  
• Attend class. It's not mandatory, but he'll be less understanding when it comes to your grade, helping you, and your final project if you hardly show up.
  
  
• Please stay away from Dreamweaver. Dreamweaver's pretty bloated and tends to be more distracting than helpful as a beginner. It's not too popular amongst web developers anyway.
  
  
• Use a text editor. Sublime Text and Notepad++ are pretty good.
  
  
• Get comfortable writing html and css without referencing any sources. This WILL come up on tests and quizzes. Know what tags go where, how to properly use css selectors, how to position elements with css, and know what everything specifically does.
  
  
• When studying for a test/quiz, don't rely solely on the review sheet. The reviews are helpful, but he will throw some things in that aren't on the review.
  
  
• It's possible to find the book online for free(if that's what you're into). HTML and CSS: Design and Build Websites is not required, but pretty good(also possible to get free).
  
  
• Don't forget that we have access http://lynda.com. HTML Essential Training is a good course to follow along with.
  
  
• You're not limited to a "company/restaurant" website for the final project. You can build whatever you want, as long as you satisfy all of the requirements.
  
  
• Don't present your final project in Internet Explorer(unless you want it to look like poop). Open your project in Chrome or Firefox.
  
  
• Start early on your project so you have time to clean it up and make it appealing to the eye. Grid systems are nice, but not necessary.
  
  
• Ha, and the teacher is a guy by the way. He's pretty cool for the most part. He's a grad student and close to our age.
  
  I'm at the point where I'm comfortable enough to start charging to build websites. That's a great way to make money while in school.
  
  If you have anymore questions, let me know.
  

some amazing books I would suggest to you are:

• Godel Escher Bach
  
  
• Road to Reality By Roger Penrose.
  
  
• Code by
  Charles Petzold.
  
  
• Pi in the Sky by John Barrow.
  
  All of these I would love to read again, if I had the time, but none more so than Godel, Escher, Bach, which is one of the most beautiful books I have ever come across.
  
  Road to Reality is the most technical of these books, but gives a really clear outline of how mathematics is used to describe reality (in the sense of physics).
  
  Code, basically, teaches you how you could build a computer (minus, you know, all the engineering. But that's trivial surely? :) ). The last chapter on operating systems is pretty dated now but the rest of it is great.
  
  Pi in the Sky is more of a casual read about the philosophy of mathematics. But its very well written, good night time reading!
  
  You have a really good opportunity to get an intuitive understanding of the heart of mathematics, which even at a college level is somewhat glossed over, in my experience. Use it!

You're asking a very complex question that the best current minds in the fields of sociology, politics, psychology, technology, futurology, neuroscience, education, and many others, cannot answer.

We just don't know what it is that makes a good programmer different from a bad one. We all have theories and ideas and notes and observations and anecdotes, but compiling them together doesn't generate an actual understanding of the subject.

So I'm sorry but there's no real way for anyone to answer your question.

I would look for local resources to double check wtf you're doing.

Befriend a trusted professor and visit them during office hours, or a trusted student or advisor or professional or something. Explain your concern and ask them to walk you through how they approach problems. Not the solution; just watch how they approach the problem and pay very close attention to it.

That's quite invaluable.

For instance, take SQL. If I get really stuck on a SQL problem, I go back to my root approach to it, which is to ask this question: if I had several tables of data printed out on paper, what would I tell a monkey to do to collate them and generate the output I want? That's all that SQL usually does; it explains to the computer how to collate and present diverse data tables.

And that's easy to forget when you're trying to think about join syntax or something and you're grasping at straws and trying to construct a pattern in your mind and it keeps unraveling because you don't have a good sense at the root level of what it is that you're trying to do.

Better programmers aren't defined by what they know, they're defined by how they think.

And I sense your problem is that you're trying to apply knowledge not without understanding it, but without understanding how to understand it.

Watch this, I'm about to do a cool programmer mental trick of segueing to what seems like a completely unrelated subject, but I'm actually following a mental thread that connects the two.

When linguists try to decipher ancient languages, they sometimes run into an interesting kind of trouble. Take Linear A as an example. They have the symbols. They have a pretty good idea of what some of them mean. But they have no idea how they go together or what most of them mean, because they have no context for deciphering the thing. It's completely inaccessible. For all scientists can tell, Linear A might as well be encoded symbols of sound waves which can only be translated intelligibly when played aloud. If they converted a Linear A script to MP3, it might come out a perfect rendition of All Along The Watchtower.

The problem isn't that they haven't unlocked the words, the problem is that they haven't figured out how the writers thought. And without knowing that, the words are probably unknowable. They could throw some together that have likely translations, but what sounds like "there is the sun" might actually mean "my dog ate my banana".

So the key to unlocking the language isn't to stare at the language and to try to wrestle words into place.

Instead, it's to research the culture that used the language, to try to learn more about the culture and how it functioned. Did it have a seat of government? Was it patriarchal or matriarchal? Was it militant or trade oriented or hunter/gatherer or what?

By understanding how the people lived, you get a sense of how they thought. And by understanding how they thought, you can start to figure out how they communicated. And more than one language over time has been deciphered in that way.

Or how about this; you don't speak french, but encountering a french person on the street, you're able to use hand gestures to ask them directions to something, and they're able to respond intelligently using hand gestures. How'd that happen? Because you both thought the same way.

This psychological question consumes exobiologists, because they're tasked with figuring out how to communicate with aliens who, by definition, don't think like us.

So what do they do? They return to the basic roots. And the simplest roots they can find are the hydrogen atom and the set of prime numbers. And maybe pi. Things like that. And people hear "math is the universal language" and sneer dismissively because math is boring, but it's actually true.

So I'm curious whether you're fluent in the universal language of computers, or whether you just think you are because you practiced writing linked lists 37 times.

Charles Petzold wrote a great book called "Code: The Hidden Language of Computer Hardware and Software". It doesn't teach you how to program, but it teaches you WHY you have to program. And by understanding the WHY, you get great inroads to the HOW.

I'd recommend taking a look at that if you can find it. "http://www.amazon.com/Code-Language-Computer-Hardware-Software/dp/0735611319". Notice that the second book in the "Customers Who Bought This Item Also Bought" section is titled "Think Like A Programmer". Code has better reviews so I'd start there.

But that might help.

I don't think you're stupid, I just think that you aren't thinking the right way about the problems.

Or maybe it's a problem solving thing altogether. How do you do with Sudoku or other games like that? Or chess puzzles?

I dunno. This is all food for thought, and maybe some of it will stick.

ETA: Damn I wrote a lot. I'll save it and blog it someday, maybe. Anyway, I did a search on "how programmers think" and came up with this interesting article: "http://www.techrepublic.com/blog/programming-and-development/how-to-think-like-a-programmer-part-1/43". It's interesting not because I entirely agree with it, and I couldn't find the other two parts of it anyway, but at the bottom of the first section, in bold, the author says that the big problem with some programmers is that they've been taught the HOW but not the WHY. So here again is someone supporting my point. Tricks and habits and stuff will only take you so far; at some point you have to learn the WHY in a way that lets you apply it and start coming up with your own HOW's as the need arises.

One of the biggest issues I see with some of the dev's I work with is that they easily get lost in their work. We refer to it as shaving a Yak. Let's say you need to go pick up some milk at the store, but before that you need to fill up your gas tank. But before that you need to change the oil in the car. But before that you need to help your parent access their email. The next thing you know you're in your living room shaving a Yak asking yourself how you got into this situation. All you wanted to do was get some milk.

You would be better off identifying the core features of your project and concentrating on them, one at a time. What are these core features, what is the value of this feature, and what is the minimum amount that would satisfy that feature. If you're creating a car, you would need a motor to drive the wheels, but a a motor has nothing to do with how to steer a car. You've identified two separate features, one for the motor and one for the steering. I'm not talking about sitting down and writing out full specs and requirements. Just get a basic idea of what are the different parts of what you are building. You'll miss some but that's ok. Find a few features, pick one, and start.

Stay focused on that feature. Hack it together, make it work. But make sure that what you're hacking together is only for that feature. The code you're writing at the time should be responsible for solving that feature, alone. Even if you think that what you're creating can be used for another feature, or that you're repeating something that you made earlier, or you've discovered some new feature that you missed initially (and you will), ignore the impulse to optimize or start adding new features in the middle of your task, you will come back to it later. Just make sure you make notes about those things discovered.

When you're code does what it is supposed to and you've proven it with unit tests (you do have unit test right?), then you can start refactoring. Clean it up, move it around, optimize it, look for areas that a design pattern can fix. Give it a good S.O.L.I.D. overview (if you're working in an OOP language). As long as you have unit tests covering the core responsibilities of your features, you can make changes with confidence.

Once you're satisfied, you can move on to the next feature and repeat. As you complete more features, you can re-address some of the completed code during subsequent refactors. Working like this will ensure that
a) your code works as intended because you've proven it with unit tests
b) your code will be loosely coupled because you were forced to work on a single responsibility at a time.

Refactoring is probably the main take away. But being able to pick specific milestones along the way is important. If you leave it all up to the last minute, it will be easy to get overwhelmed.

So book recommendations:
Martin Fowler's Refactor - https://martinfowler.com/books/refactoring.html
Uncle Bob's Clean Code - https://www.oreilly.com/library/view/clean-code/9780134661742/
Steve McConnell's Code Complete - https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670

The biggest hurdles I had motivating myself to work on a project was never coding itself. It was always setting up the compiler, IDE, environment, finding something to work on, etc. The biggest one for me is blank page syndrome.

You don't need to convert to linux if you don't want to but it is good to get some experience in it if you can. I spent sometime setting up a headless Ubuntu server to manage my torrents and be network storage. It took a lot of time starting from scratch but the experience has helped me out.

http://www.ubuntu.com
http://www.reddit.com/r/linuxquestions
http://ubuntuforums.org/

If you want to continue with Java (which is a good choice). I believe the most popular IDE is Eclipse. It has great plugin support and has been used everywhere I've been. You can use it for development on android phones as well if you want to play around with mobile development.

http://www.eclipse.org
http://developer.android.com/tools/sdk/eclipse-adt.html

If your college is like mine, most of the later courses in computer science will not involve much coding at all but will involve a lot of math and knowing popular solutions to common problems (sorting, searching, graph theory, combinatorics). If you feel like you need to brush up on a language, there are a lot of web resources and books to help you.

http://www.codecademy.com
http://www.amazon.com/Effective-Java-Edition-Joshua-Bloch/dp/0321356683
http://www.amazon.com/Head-First-Java-Kathy-Sierra/dp/0596009208/ref=sr_1_2?s=books&ie=UTF8&qid=1382580434&sr=1-2&keywords=head+on+java

Computer science and software development is a broad field which makes scaling it daunting at times. The only way to make it less daunting is to just dive in and do it. Pick a project and work on it. You will encounter problems you have no idea how to solve and that's great because now you've found something you can learn (usually through Google).

Solve problems in manageable bits. If you try to implement your whole program at once it will seem impossible. Implement small portions of your project at a time. Trying to create a Java chat client? Just work on getting some basic sockets to work and build a library you'll be able to use going forward. This will make the goals seem manageable and help you modularize your code. It helped me with not feeling overwhelmed about my project's scope.

I hope I didn't sound condescending. I just wanted to share some things that have helped me. I don't think you are in a bad spot, you just need to stay motivated and find some things to work on to help you learn. If you have any specific questions I can try to help out, but there are other people on this sub that are far more knowledgeable than me.

>How valuable is an Oracle cert?

No more than any other online course from a respected institution such as google, say: https://cloud.google.com/training/free-labs/ or one of the online courses available at MIT/Stanford.

>What else should I look into to boost my repertoire?

See if your university has any business partnerships you could do a 2-3 month project for. I worked with one of the university's here in the UK as part of a business/university partnership and that gives the students real world experience and us some free work. Win-win if the project is completed.

Sorry - mostly UK (amazon) links :)

TDD - https://www.amazon.co.uk/Growing-Object-Oriented-Software-Guided-Signature/dp/0321503627/ref=sr_1_1, Video by Trisha Gee whos fairly well known for speaking on this stuff: https://www.youtube.com/watch?v=QDFI19lj4OM (some very handy shortcut keys in the video and a good outline of some of the tools available to you).

Clean Code - https://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 (by "Uncle Bob")

Design patterns - https://www.amazon.co.uk/Head-First-Design-Patterns-Freeman/dp/0596007124/ref=sr_1_1

Learn to use shortcuts in Intelli J to speed up your ability to generate/refactor code: https://www.amazon.co.uk/Getting-started-IntelliJ-Hudson-Assumpção/dp/1849699615/ref=sr_1_1

Also Jetbrains does good newsletters (curated by the same lady that made the video above under TDD) sign up to stay up to date with interesting/relevant blogs/articles/industry news https://www.jetbrains.com/resources/newsletters/

Github - https://www.amazon.co.uk/Version-Control-Git-collaborative-development/dp/1449316387/ref=sr_1_4

Bash Commands - https://nikgrozev.com/2016/05/22/shell-cheatsheet-part-1-common-bash-scripting-tmux/

XP/Scrum/Kanban development process - https://www.agilealliance.org/glossary/xp/ the way we work

Trusted developer blog on various engineering topics https://martinfowler.com/

Interview Prep https://www.hiredintech.com/courses

Hint: the above books are likely to be available at any academic library. If not, request them. you likely only need to read 33-50% of them and you'll be golden. I imagine you can likely get hold of electronic versions of these books as well.

The best thing you can do to prepare yourself is to start practising developing projects... get them up on github. it could be a website, a desktop application/game/tool, a demo of sorting algorithms, a web service... literally anything. Fork others' projects, code a feature request and create a pull request back to the original repository/codebase on github. Just build something rather than nothing. Anyone can do the latter. There's so much more opportunity now that we have github available. Think of any thing you might be interested in working on and someone, somewhere has likely already got a project underway in that area, and you're free to submit a pull request to their repository at the click of a button. This wasn't really possible 10-15 yrs ago.

The simple answer is there's so much to know, you just have to find what your interests/passions are and follow those as much as possible.

No matter how good you are at what you do today, the tools will be different tomorrow and may even depend on the industry you enter: AI, web services, blockchain, computer vision, robotics? The list is long and each one requires you to be highly trained (over many years) before you're considered any good at it.

Just try to learn what you can. Find something that genuinely interests you and study it until you become a trusted authority on the subject, or you find something you're more interested in instead.

If you have any ideas for the type of area you might be interested in put them up here and perhaps someone can point you to a relevant project?

https://en.wikiquote.org/wiki/Howard_H._Aiken "Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats."

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
  
  

I know how you feel, my college was practically the same. Here are some resources that helped me through:

https://www.youtube.com/playlist?list=PLlrATfBNZ98dudnM48yfGUldqGD0S4FFb

TheCherno has a really nice C++ tutorial. Might not be the best on modern standards, but if you are looking for a place to start, this is a good one, really explains stuff nicely.

​

https://www.amazon.com/Programming-Principles-Practice-Using-2nd/dp/0321992784/ref=cm_cr_arp_d_product_sims?ie=UTF8

https://www.amazon.com/Primer-5th-Stanley-B-Lippman/dp/0321714113/ref=cm_cr_arp_d_product_top?ie=UTF8

These two so far is the most recommended books I could find in this thread, Programming Principles has more nice exercises and is what I personally used, but to be honest just go with the one that clicks for you. read through the preview chapters if you could find them and choose the one you like.

​

https://codeforces.com/

https://www.hackerrank.com/dashboard

https://www.codewars.com/

I think this is what helped me the most at the start if you don't know what to do, solving problems really helps you get comfortable with the basic language syntax, programming logic and is a lot of fun.



Lastly, Google search is your best friend, seize it. Don't be afraid of making a lot of mistakes because you are going to make many AND be willing to explore! Because chances are, there is always going to be a better modern way to do something. Try to know the advantages and disadvantages(Important) of each way if you could, it all may seem so cryptic at first and confusing(it probably is) but it will all click someday.

​

Learning C++/Programming is a life-time learning, Good luck on your journey!

Collections or Categories, it doesn't really matter - what matters is that A) you're consistent, and B) they are self-evident (clear). In other words, you need to endeavor so that a customer is not going to be surprised when they click on a section. Understand that a customer is always going to have some expectation when deciding to click on a category, and that expectation will range from something as straightforward as:

"I am looking for rings, so I am clicking on the 'Rings' section and I expect to see a bunch of rings"

to

"I see 'Tree of Life' and I know that nature-y things appeal to me, so when I click on 'Tree of Life' I expect to see things that are all clearly related to one another thematically in some way AND I can clearly see why this collection is called 'Tree of Life' through the general brand/theme conveyed by this collection of products."

Therefore, in the first example if a customer clicks on 'Rings' and sees some rings as well as bracelets and necklaces....that customer is surprised. Pretty straightforward. In the second example, if a customer clicks on 'Tree of Life' and sees a bunch of jewelry that really doesn't look like it's thematically tied together in some way AND/OR that jewelry is really not conveying the theme (maybe it's all industrial/steampunk stuff) - that customer is surprised. Surprise comes from when expectations are not met, and in this case customers being surprised will lead to disappointment and frustration. Having consistency and clarity will reduce customer confusion/frustration, and that will keep curious customers from bailing out of your store.

That said, as demonstrated above, it is generally much easier to be both consistent and self-evident with Categories, but that doesn't necessarily mean it is better. As you rightly point out, if you have a strong brand that resonates with your customers, the Collections approach can actually be a pretty powerful way to expose your products to your customer and snag sales you otherwise wouldn't have. It just takes a lot more work to maintain consistency and clarity with Collections because it depends on having strong, clear branding. With that in mind, I think if you go the Collections route you really, really, really need to be very careful and deliberate about it in order to maintain consistency and clarity - but if you do it right, you will go farrrrrr.

As an aside, I strongly recommend the book "Don't Make Me Think: A Common Sense Approach to Web Usability" by Steve Krug. It was originally intended to teach user experience and human-centered design principles to web designers, but honestly it's one of the best damn books out there for anyone trying to convey information of any kind on the internet. It's short and awesome and the world would be a better place if more people read it and practiced its principles.

Read these books to get to grips with the latest techniques and ways of working. As an employer I'd be extremely impressed if you'd read these books. They will give you a big head start when trying to move into the professional work environment. Most of them will apply to any programming language but they mainly use Java as the example language but it's very similar to C#. It's books like these that are the difference between a beginner and an expert, but don't forget when you start coding 9-5 with good developers you will very quickly pick things up. We were all in your position at one point, if you get these read it'll all be worth it in the end!

Coding

C# in depth - I've not read this one since I do Java but I've just had a quick glance. This should be pretty useful and it's a respected publisher. I think you should start with this one.

Clean Code - Great book which explains how to write clean concise code, this 1,000,000x. It doesn't matter what language you are using it should apply where ever you write code.

Cleaner Coder - Another Robert Martin book, this one is easy to read and quite short, it's all about conducting yourself in a professional manner when you are coding. Estimating time, working with co-workers, etc.. Another good read.

Growing Object-Oriented Software - This book is about writing code using test driven development. It explains the ideas and methodologies and then has a large example of a project that you build with TDD. I just read this recently and it is really good.

Head first design patterns - This book goes through essential design patterns when coding with an object orientated language. Another essential read. Very easy to read, lots of diagrams so no excuses to not read it!

Work Methodologys

Kanban

Succeeding with Agile


p.s

Start building stuff, get an account on linked in and state the languages you are working with. This will help as well because having something to show an employer is priceless.

There are some key concepts you want to get down if you really want to make the most of .NET

• OO design and basic patterns
  Design patterns are used over and over again in OO based systems. A good understanding of what they are for, and how they tend to be used will be helpful when trying to understand key framework extensions and 3d party libraries. I like to point people at Head First Design Patterns. The opinions on design patterns in this book are a bit dated and the examples use Java syntax but they are all relevant to the .NET world and will go a long way to understanding how class names and object structures are used in OO systems.
  
  IMO One of the biggest concepts you'll need to understand in OO currently is the Inversion of Control pattern (also referred to as dependency injection) and the frameworks that provide it. Most modern .NET applications leverage some kind of dependency injection to simplify development and make unit testing and porting of classes easier.
  
  NOTE: I understand many folks in the PHP world feel that PHP is a full OO system. While they have made strides in this area it is not a fully typed OO system. It's a procedural system twisted to provide some OO features.
  
  
• Syntax
  This is easy, just review MSDN docs and samples. The biggest different you will see in the .NET world is a different opinion in general on casing of object and method names.
  
  
• Frameworks
  This is the part that seems the most overwhelming IMO. The language itself is fairly easy but understanding the huge amount of 1st and 3rd party libraries, frameworks and tools can be daunting. Since you come from the PHP world I am going to assume you are most interested in web based applications. What I would recommend is to pick a set of tools for your web stack and learn them. Once you understand the key pieces of a web application and how they interact you can start picking and choosing different components to meet your needs. I am going to suggest you start with the following stack to get started with a web application, this is the same stack I use for most of my clients making smaller functional websites or simple content driven systems.
  
  
• .NET 4 (you can do 3.5 but really just go with the latest)
  
• Core Web App - MVC (3 or 4)
  
• Dependency Injection - Unity 2.0 or 2.1
  
• Data access - Entity Framework
  
• Application Security - .NET Membership Provider (there is a newer slightly better framework by MS but I cannot recall the name at the moment)
  
• Consuming 3rd party services - WCF
  
• Exposing your own services REST - MVC (since you are already using it for pages)
  
• Exposing your own services using multiple protocols/data formats - WCF
  
• XML Processing - Linq and Lambda's. Also be aware of XmlTextReader and XmlTextWriter for targeted high speed forward-only processing.
  
• Configuration management - build in web.config with CSD for complex configuration structures beyond what appsettings can provide.
  
  Key Concepts for Modern .NET Apps
  
  
• Generics
  
• Lambdas
  
• Linq
  
• Closures
  
• dynamic typing
  
• threading
  
  Some basic tools to help you:
  
  
• dotpeak - provides detailed assembly information and some decompilation.
  
• Assembly binding log viewer - helps troubleshoot dependencies by logging internal CLR calls to dependent libraries.
  
• MSBuild - Build management and orchrstarion. This is the system used internally by Visual Studio for building projects. It's a command line tool so you can build projects even without visual studio. A basic understanding of MSBuild makes it fairly easy to use any IDE or text editor you like for .NET development. I do however like VS2010 or 2012 as it goes a long way in helping you code and understand .net.
  
  Edit: Now with more links.

Escher's work with tessellation and other mathematical ideas are fairly well-known and documented so I'll try to mention a few examples of things I learned in an art history course a while ago.


DaVinci's Vitruvian Man used Phi in the calculation of ratios. Example: the ratio of your arm to your height or your eyes to your face is nearly always Phi. I'm not sure if I'm correct in the body parts mentioned, my art history class was nearly 6 years ago so I'm a bit rusty. I'll try to think of some more examples and post.


EDIT: a few more examples have come back from memory. DaVinci was a master of perspective as well. As you can see DaVinci used linear lines to draw attention to the subject of his works. In the case of The Last Supper, the lines from the structure of the building, to the eyes and gestures of the disciples aim towards Jesus.


Botticelli's Birth of Venus uses a triangle to bring the subject into the viewer's mind. The two subjects on the left and right form the lines that meet at the middle of the top and close off a triangle with the bottom of the work. Venus herself is in the middle of the triangle which brings your attention to her immediately upon viewing the work.


Michelangelo's Pieta also uses a triangle to highlight its subjects. Mary's figure creates a triangle (which is considered to be quite intentional based upon her size, both in relation to Jesus, a full grown man, and from her upper and obviously enlarged lower body). Her triangle makes the outline for the subject, Jesus. He is nearly in the center of both the horizontal and vertical axises. The way he is laying, from near the top of the left and then draping to the bottom of the right, depicts a very lifeless form because of the unnatural laying. Moving the viewer's gaze from the top to the bottom of the triangle strengthens the emotion of the scene.



Moving on to architecture, vaulted ceilings also use triangles to draw your eyes down a line also make an awe-inspiring impression.


In contrast to the European's love of straight lines and geometric figures, the traditional Japanese architectural style was opposed to using straight lines. As you can see, nearly every line in a traditional Japanese building is curved. The traditional belief was that straight lines were evil because they thought evil spirits could only travel in straight lines. This design criteria made for very interesting formations and building methods which I would encourage you to check out because of the sheer dedication to the matter.


The Duomo in Florence is a great example of Renaissance architecture and has a really cool octagonal shaped dome. I could go on and on about how awesome Brunelleschi's design was, but I'll just let you read about it here.


I could talk all day about this sort of stuff, just let me know if you want anything else or have any questions. Good luck with your class!


EDIT2: I've found some more links about the subject of mathematics in art and architecture. It looks like University of Singapore actually has a class on the subject. There's also a good Wikipedia page on it as well. This article is pretty lengthy and knowledgeable, but doesn't include pictures to illustrate the topics. Finally, as almost anybody in r/math will testify, Godel, Escher, Bach by Douglas Hofstadter is a fantastic read for anybody interested in mathematics and cool shit in general.



EDIT3: LITERATURE: I know we've all heard what a badass Shakespeare was, but it really hits you like a bus when you find out that how well the man (or for you Shakespeare conspiracy theorists, men) could use words in rhyme and meter. Here's a Wikipedia article about his use of iambic pentameter and style. Nothing else really comes to mind at the moment as far as writers using math (other than using rhyme and meter like I mentioned Shakespeare doing); however, I can think of a few ways to incorporate math. If you would like to go into any sort of programming during the class, you could show how to make an array out of a word. Once that concept is understood, you could make them solve anagrams or palindromes with arrays... a favorite of mine has always been making [ L , I , N , U , X ] into [ U , N , I , X ] ( [ 3 , 2 , 1 , 4 ] for the non-array folks ).

(Just an aside comment: when I saw this post it was at 0 points. I have no idea why this post or the poster is getting downvoted -- it is legitimate curiosity to link C to computer science and garner interest in CS/programming languages. So what the fuckity fucking fuck?)

1. I think this old post is the essence of Computer Science. (I have it saved for quick referral.)
   
   
2. They are text editors. If you're not comfortable with command-line text editors use something else. Both are incredibly powerful. Emacs more-so. Both have steep learning curves. I'm partial to vim and there's a great tutorial here (see the long IRC style tutorial).
   
   
3. No. You can learn basic constructs but each language is different. C++ is a completely different beast to C. I'm not sure if this was a joke but Bjarne Strousop (the inventor of C++) claims he his knowledge on C++ is 7/10. C is great to have on your resume because it assumes you have skills with systems-level and low-level programming. It is also used heavily in the embedded world.
   
   However if you're developing applications you might look towards using a different language such as C++, Java, Python, Cocoa, Swift, etc. If you're doing numerical/scientific work you might do it in Matlab. C is definitely not a good choice for writing a web application. You pick the language you use appropriate for the type of goal/task you're trying to accomplish
   
   
4. I recently learned about this book on this very subreddit and have been recommending it to real life friends. Deital - C: How to program is an accurate book on C with a modern introduction. Most people will say to read K&R C which is considered the bible, but I find it a dull read (but a fantastic reference if you need to understand certain aspects of the language -- such as what is a volatile or a register keyword).
   
   
5. Good luck. I highly encourage Computer Science. However try to go into the field thinking about "solving problems with computation" rather than "learning programming languages." I feel like people miss the bigger picture of Computer Science. It is a wonderful field with a rich theory. Languages are tools to help you express those computations. In theory programming languages are computationally powerful as each other (or what we call turing-complete) and don't have a concept of speed. In practice the choice of language defines how you wish to express things and implementations of languages typically have different speeds (usually C is incredibly fast because it is closest to machine code/assembly).

IMHO,

step 1: Read https://www.amazon.com/Pragmatic-Programmer-20th-Anniversary-2nd/dp/0135957052/ref=dp_ob_title_bk

step 2: Read https://realpython.com/python-pep8/ and https://docs.python-guide.org/dev/virtualenvs/

step 3: Write a REST API which takes arguments from the URL, uses these arguments to run some predictive model of your creation, and then returns the result; since you already know Python, I'd recommend using Flask, there are many free tutorials, just google it. If using Python, I highly recommend using PyCharm (the free community edition is enough) over Jupyter or Anaconda, the latter will let you do many bad things which would trigger a red warning in PyCharm (such us doing import in the middle of the file).

step 4 (optional, but recommended): Learn the basics of Java (this tutorial should be more than enough https://www.tutorialspoint.com/java/index.htm ) and read https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

step 5: Write a publisher application which reads a csv, xml, or json file from disk (for bonus points: from someone else's public REST API for data, for example https://developer.walmartlabs.com/docs/read/Search_API ), and turns the data contained within into a list of python dictionaries or serializable objects (btw, read up on serializing, it's important), and then sends the results into a kafka or rabbitMQ queue. I would strongly recommend sending each item/record as a separate queue message instead of sending them all as one huge message.

step 6: Learn how to use cron (for bonus points: Airflow) to make the application from step 5 automatically run every second day at 8 am

step 7: read the closest thing in existence to being the data engineering book: https://dataintensive.net/

step 8: Write a consumer application which runs 24/7 awaiting for something to appear in the queue, and when it does, it calls your rest api from step 2 using the data received from the queue, adds the returned result (predicted price, or whatever) to the data, then runs some validation / cleaning on the data, and saves it in some database (SQLite is the easiest to have running on your local computer) using an ORM (such as SQLalchemy).

step 9: Add error handling - your applications should not crash if they encounter a data-related exception (TypeError, IndexError, etc.) but instead write it to a log file (as a minimum, print it to the console) and continue running. External problems (connection to the database, for example) should trigger a retry - sleep(1) - retry cycle, and after let's say 5 retries if it's still dead, only then the application should crash.

step 10: For bonus points, add process monitoring - every time your application processes a piece of data, record what category it was in a timeseries database, such as influxdb. Install grafana and connect it to inlfuxdb to make a pretty real-time dashboard of your system in action. Whenever your application encounters a problem, record that in influxdb as well. Set grafana to send you an email alert whenever it records more than 10 errors in a minute.

Step 11: More bonus points, add caching to your application from step 2, preferably in Redis (there are libraries with helpful decorators for that, e.g. https://pythonhosted.org/Flask-Cache/ )

I'm assuming you are familiar with Spark, if not, then add that to your learning list. A recommended intro project would be to run some aggregation on a big dataset and record the results into a dedicated database table allowing for fast and easy lookup (typical batch computing task). You could also rewrite the applications from points 5 and/or 8 to use spark streaming.

I also heavily recommend learning how to use docker and kubernetes (minikube for local development), this is not only super useful professionally, but also makes it much easier to do stuff such as running spark and airflow on your home computer - downloading and running docker images is way easier than installing any of those from scratch the traditional way.

One crucial advice I can give is the mindset difference between data science and data engineering - unlike in data science, in data engineering you normally want to divide the process into as small units as possible - the ideal is to be processing just one [document / record / whatever word is appropriate to describe an atomic unit of your data] at a time. You of course process thousands of them per second, but each should be a separate full "cycle" of the system. This minimizes the impact of any crashes/problems and maximizes easy scalability¹. That is of course assuming that the aim is to do some sort of ETL, if you are running batch aggregations then that is of course not atomic.

¹ As an example, if your application from step 5 loaded all the data as one queue message, then the step 8 application would have to process it all in some giant loop, so to parallelize it you would have to get into multi-threaded programming, and trust me - you don't want that if you can avoid it (a great humorous tale on the topic http://thecodelesscode.com/case/121 ). You also have to run it all under one process, so you can't easily spread across multiple machines, and there is a risk that one error will crash the whole thing. If on the other hand you divide the data into the tiniest possible batches - just one item per message, then it's a breeze to scale it - all you need to do is to run more copies of the exact same application consuming from the same queue (queue systems support this use case very well, don't worry). Want to use all 8 CPU cores? Just run 8 instances of the consumer application. Have 3 machines sitting idle that you could use? Run a few instances of the application on each, no problem. Want the results really fast? Use serverless to run as many instances of your app as you have chunks of data and thus complete the job in an instant. One record unexpectedly had a string "it's secret!" in a float-only field and it made your app crash? No problem, you only lost that one record, the rest of your data is safe. Then you can sit back and watch your application work just fine while the colleague who decided to use multi-threading for his part is on his fifth day of overtime trying to debug it.

If you already have an engineering degree then you already know how to study. What experience do you have with embedded? If you don't have any then you should be sure it's what you want before you commit to anything huge.

I think the best way to get a job in embedded systems is to build embedded systems, and not bother with language certifcations. I might be going against the grain here a bit but I would suggest starting to dip your toes into embedded systems by buying an arduino and messing around with it.

Arduino gets a lot of flack for being "not real" embedded systems, and while it's true nobody is going to hire you because you can make an impressive arduino project, IMHO it's a great introduction to what embedded is about. The hardware equivalent of "hello world" is blinking an LED. If you are serious about learning then you will quickly outgrow the arduino, but you can always throw away the bootloader and try to program the ATmega with bare metal gcc and avrdude.

I don't know what you already know nor how you feel about math, but things you will want to learn include:

• Analog electrical theory, DC and AC, resistance/capacitance/inductance. Understand basic circuit networks and input vs output impedance. Hopefully you remember complex numbers and frequency response. You don't need a lot of circuit theory but you will need to understand what a pull-up resistor is and why it's necessary. Depending on your math background you can get into filters, frequency response, fourier analysis. A good introduction here might be www.allaboutcircuits.com
  
  
• Digital theory, starting with boolean algebra, logic gates, adders/multiplexers/flip-flops, all the way up to computer architecture. I like this book because it has a very holistic approach to this area https://www.amazon.com/Digital-Design-Computer-Architecture-Second/dp/0123944244/ref=sr_1_1?ie=UTF8&qid=1494262358&sr=8-1&keywords=harris+digital+design
  
  
• Linux, C. Linux and C. You need to understand pointers, and the best way to understand C is to understand computer architecture. If you're not already running Linux, install linux, as well as gcc and build-essential. Start learning how to manipulate memory with C. Learning about computer architecture will help here. My favourite book on C is one of the classics: https://www.amazon.com/Programming-Language-Brian-W-Kernighan/dp/0131103628/ref=sr_1_1?ie=UTF8&qid=1494262721&sr=8-1&keywords=the+c+programming+language
  
  If you get this far and still want to become an embedded systems engineer then you're doing pretty well. I would say just try to build projects that utilize these skills. Maybe you can use your mech background to build a robot and then design the software to support it. Get used to reading datasheets for parts, and imagining what the digital logic inside looks like. Get used to searching google for answers to your questions.

hmm. Where to get started. Learn the gestalt principles of visual design. If you're designing interfaces - these little tips will help you associate, and differentiate well enough to be able to direct attention like a conductor.

Learn to do everything deliberately. If you don't have a reason for something, you're not designing, you're arting. Know the difference and when each is appropriate. For example - want a big splash screen with a fancy colorful image? Is it so you can attract the user to a particular part of the screen? Or is it because you have some extra space and feel like filling it with something. If it's the former, go for it. If it's the latter - you're just making an art project.

Learn about design methodologies, from a university if possible. Industrial design technique is very good for digital problem solving as well. Defining a problem, exploring solutions, and determining a valuable path are things that will help you in every project.

Understand why you are doing what you are doing. And who are you doing it for. Never go past page one without establishing those facts.

Stats will help you in that do everything intentionally part. If you can say 80 of people do this, 20 percent of people do that, you can from this say, that this gets center position, bright colors, dark shadow and lots of negative space. That thing that 20 percent of people do, gets bottom right, lowER contrast, and is there for people that expect it.

Good luck, conferences will help. Podcasts will help. Reading interviews from design teams at larger companies will help.

Asking reddit will help. What you should ask for is paid time off to study lol. Good luck.


edit:
Also get this book universal principles of design I think there's a pocket version. This teaches you what works and why and when to use it.


Get the design of every day things. This book teaches you what good design is. It asks the questions - what is design. When is design good. What is an affordance? How do we signal what things do what? How does all that work? Is a coffee cup good design? What about a scissors? How about google.com vs yahoo.com...

Check out don't make me think... or just think about the title for an hour and pretend you read the book.

a popular one now is hooked. Pavlov's dog experiments except with people, basically operant conditioning for designers.

And learn about grid systems and bootstrap for prototyping. Get a prototyping account. For something, proto.io, invision, framerjs.... Invest in omingraffle and sketch, get a creative cloud license if need be. You will need to show people things a lot. You will need to convince people of your ideas and your paths. You will need to constantly throw together quick and dirty visualizations of what you want to say. Invest in tools that make it simple.

Learn how to sell your ideas. You will be asked a ton of questions as people poke holes in your design. You need to figure out how to soothe their worries. They will your decisions, and you will have to show them that you have the answer. Learn how to present. Learn public speaking. Learn how to communicate with superiors. Learn how to talk with programmers. Learn how to give the programmers what they want from you. Learn how to negotiate, learn how to deliver on time. Learn how to handle stress.

Good luck.

I’m a print and basic web designer that’s been making an overhaul towards UI/UX the past few months so maybe I can offer some help. I’m actually working on a mobile app’s case study as we speak! You may have already noticed that UI/UX tends to get many different definitions depending on who you ask. With this said the path I took was focused on research methods (competitor research, demographic research, user testing, etc), UX deliverables (personas, user flows, wireframes, etc), prototyping, high-fidelity design and front-end coding (I’ll touch on that a little more in a bit).

 

When it comes to UX research I found the following resources immensely helpful:


Books (Reading? Yes, reading. Trust me these are worth checking out…pretty short too)

• Don't Make Me Think
  
  
• UX Team of One
  
  
• Lean UX
  
  
  Podcasts (Listen on your commute, while you’re folding laundry, whenever)
  
  
  
• User Defenders Podcast
  
  
  Websites (It’s also a good idea to Google some successful UX designer’s portfolios)
  
  
  
• UX Mag
  
  
• Reddit User Experience
  
  
• “How I Became a Unicorn” <— Seriously check this out
  
   
  
  Basically what UX teaches you is that all design decisions need to be backed by an informed reason. That reason is found by doing proper research and testing.
  
   
  
  Now for UI design. There’s always Bechance and Dribble for inspiration, but a lot of the pieces you find on there lack context and are merely pretty to look at. So don’t get too obsessed. For software, personally, I’m a Photoshop to Sketch convert. It’s $100 but MAN is it worth it. There’s a number of things that make Sketch attractive (vector based, easy exporting, etc) but I guess the simplest way I can put it is that Sketch just feels…lighter than Photoshop. But it’s really personal preference, if you’re a master at using Photoshop for web design then don’t feel like you have to get Sketch. With that said I HIGHLY recommend investing in Meng To’s Design+Code. While it mainly focuses on iOS design, there is a lot of information that goes across the board for UI design, and it will give you an organized learning method (plus a discount on Sketch).
  
   
  
  It’s also a good idea to familiarize yourself with Material Design. Google’s presentation of the topic gets a little too in-depth at times so you may just want to Google search for other explanations of Material Design (that’s a bit ironic huh?).
  
   
  
  Okay so now you know how to design a basic UI right? Well what if you want to make your designs interactive? There’s quite a bit to benefit from actually seeing your designs work (or not work). Over the past couple years there’s been a gigantic influx of prototyping programs. They all have their pros and cons. Personally I use Pixate but at times it can be a little restricting. My iOS developer friend recommends Origami, it has a pretty steep learning curve but I think I may switch to that at some point.
  
   
  
  The key to becoming effective at UI design is the same with any other form of design: practice, practice, practice.
  
   
  
  Okay, now on to coding:
  
   
  
  Depending on your goals you may have to alter your studies a bit. For example, knowing your way around HTML/CSS and jQuery will give you more control of the design process, improve your relationship with developers on your team and make you EXTREMELY marketable. However, in many cases, only a basic knowledge of those languages I mentioned is required (jQuery being more of a bonus). As a designer you may not even touch the coding side of things at all, it really just depends on the team you’re working with. With that said I HIGHLY suggest taking a dive into front-end coding eventually, you’ll hate yourself for not learning it earlier. Ditch dreamweaver too, pickup SublimeText. Team Treehouse and CodeAcademy are fan-fucking-tastic. Learned a lot from their education programs.
  
   
  
  Whew, if that seems like a lot it’s because it is. Hopefully I broke it down into digestible chunks though. Remember, design is a never-ending learning experience. Don’t stop learning.

1. Read everything you can. Lean/Agile methodology books. Don't Make me think. Any and all articles you can find online. The Neilsen Norman Group. There are a ton of half truths and BS floating around the industry, so when you really know every side of the argument that is being discussed, you will impress people. "Well i know people used to say 5 users is the magic number, but I'm much more interested in Jared Spool's ideology that a team needs to be talking to 5 users every sprint". Which reminds me - I use twitter just for professional uses and it helps me get a pulse on what my professional colleagues are thinking and doing. I highly recommend this. I can throw out some good accounts if you are interested.
   
   
2. Do you mean is it easy to break in to the industry? I managed to get an internship at a start-up here in the midwest with a degree in philosophy. Your post makes it appear that you are hungry to learn and interested in the field. That should come out in any interviews.
   
   
3. In my experience, UX practitioners have a very wide range of backgrounds. Yes, if you have an HCI degree, you're going to get an easy job and a great salary. I think you have more than a good chance of breaking in. Knowing the little we do about you, I would say it might be a boon to you if you lean on your technical/mathematics background and focus on learning how to create/run/synthesize good user tests and research. I may be saying that because that's what I want to do.
   
   PLEASE take everything I've said as being directed towards a UX field. If you are looking more into UI design, you may need some additional training/schooling.

> Is this a good way to highlight the code I used to build on top of the scaffold?

I did see it originally, I wasn't entirely sure that's what it was though. As to if it's a good way? It's a two-edged sword. The good side is that I do get to see your code, the bad side, however, is that it's not really what a README is for. I guess it's just indicative of how Github's being used lately-- remember that Github is supposed to be a repository of git projects, not really a portfolio. The README is supposed to be "how can I use this", or "how can I contribute to this".

It might just be my own personal bias in that negative side. I do appreciate the code sample. Some more critique if you don't mind? Note, I'm a professional developer, about 15% of my time is spent on node.js so things I say might be nitpicky but knowing the idioms can really help when it comes to writing JS code in a team.

$scope.vote is a really big function. The work is also nested in a setTimeout as an anonymous function. In general, you should break functionality out into small, bite-size functions-- maybe no bigger than 5-10 lines. This allows for maintainability, too, because smaller functions can be unit tested whereas large functions, especially anonymous functions, cannot be.

There are magic numbers a lot of places. i; i < 4; i++, what is 4? It's the number of photos to show, right? Name that constant, so it's easy to read. Also, super small thing but the idiom is usually for (var i = 0; i < 4; i++) { .. }, seeing i being defined elsewhere led me to believe it wasn't zero or it was dynamic (but it wasn't).

In fact, variable naming is a big thing too.

if (page.photos.royalty === 4) {
var k = 3;
} else {
var k = page.photos.royalty;
}

What is k? What are 3 and 4?

if (photoArray[0].url === instagramPhotoUrl || photoArray[1].url === instagramPhotoUrl || photoArray[2].url === instagramPhotoUrl || photoArray[3].url === instagramPhotoUrl)

This is a mess. First thing, you're only using the else block, so check out DeMorgan's Laws. Basically, !(a || b) === !a && !b. Secondly, you can write it better in a number of different ways, the easiest of which (and the way I'd probably write it) would be to create a separate function call that looped over your photoArray and returned true if instagramPhotoUrl did not exist in your [[array]].url. Once it returned true, you can set your tempObject, and then break. Note, you should use break instead of setting uui = 20 for readability.

Finally, $http.put('/api/v1/Pages/' + page._id, page).success(function(data) { });. If you don't need to do anything with the returned promise, you don't need the success function. Degenerate functions clutter up the code. The documentation for it is here: https://docs.angularjs.org/api/ng/service/$http#put

I'm not trying to be a dick here, please don't think I am. I'm a regular here in /r/learnprogramming because I love helping people, and especially people who program in one of the top languages I know. You can ignore everything I said if you want, I'm only trying to help. Code readability is among the most important things you learn when you start developing on a team. In fact, I'd recommend this book: http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 . It really opened my eyes when I read it, hope it can do the same for you.

> My main question is this: is the market for Javascript developers in SF similar to that in other cities and will I find similar levels of success?

SF has a huge boner for node.js, so the JS developer community there is huge. There are also a number of jobs, probably the most out of any city, for modern web frameworks (node and rails are gigantic).

He sounds like a younger version of myself! Technical and adventurous in equal measure. My girlfriend and I tend to organise surprise activities or adventures we can do together as gifts which I love - it doesn't have to be in any way extravegant but having someone put time and thought into something like that it amazing.

You could get something to do with nature and organise a trip or local walk that would suit his natural photography hobby. I love to learn about new things and how stuff works so if he's anything like me, something informative that fits his photography style like a guide to local wildflowers or bug guide. I don't know much about parkour but I do rock climb and a beginners bouldering or climbing session might also be fun and something you can do together.

For a more traditional gift Randall Munroe from the web comic XKCD has a couple of cool books that might be of interest - Thing Explainer and What If. Also the book CODE is a pretty good book for an inquisitive programmer and it isn't tied to any particular language, skillset or programming level.

> I have zero Linux experience. How should I correct this deficiency?

First, install a VM (Oracle OpenBox is free) and download a linux ISO and boot from it. Debian and Ubuntu are two of my favorites. Both are totally free (as are most linux distros). Once installed, start reading some beginner linux tutorials online (or get "Linux In A Nutshell" by O'Reilly).


Just fuck around with it... if you screw something up, blow it away and reinstall (or restore from a previous image)

> Is it necessary? Should I start trying to make Linux my primary OS instead of using windows, or should that come later?

It's not necessary, but will help you learn faster. A lot of security infrastructure runs on Linux and UNIX flavors. It's important to have at least a basic understanding of how a Linux POSIX system works.

> If you can, what are some good books to try to find used or on PDF to learn about cissp and cisa? Should I be going after both? Which should I seek first?

You don't need to worry about taking & passing them until you've been working in the field for at least 3-5 years, but if you can get some used review materials second-hand, it'll give you a rough idea what's out there in the security landscape and what a security professional is expected to know (generally)


CISSP - is more detailed and broader and is good if you're doing security work day-to-day (this is probably what you want)


CISA - is focused on auditing and IT governance and is good if you're an IT Auditor or working in compliance or something (probably not where you're headed)


> What are good books I can use to learn about networking? If you noticed I ask for books a lot its because the only internet I have is when I connect my android to my laptop by pdanet, and service is sketchy at my apartment.

O'Reilly is a reliable publisher of quality tech books. An amazon search for "O'Reilly networking" pull up a bunch. Also, their "in a nutshell" series of books are great reference books for Windows, Linux, Networking, etc... You can probably find older/used copies online for a decent price (check ebay and half.com too)

> How would you recommend learning about encryption? I just subscribed to /r/crypto so I can lurk there. Again, can you point me at some books?

Try "The Code Book" for a very accessible intro to crypto from ancient times thru today
http://www.amazon.com/The-Code-Book-Science-Cryptography/dp/0385495323


Also, for basics of computer architecture, read "CODE", which is absolutely excellent and shows how computers work from the ground up in VERY accessible writing.
http://www.amazon.com/Code-Language-Computer-Hardware-Software/dp/0735611319

How and where to learn web design depends a bit on what your learning style is. If you prefer sitting in a classroom and having someone guide you, then you may wish to take classes. Personally, I do my best learning when I have a book in front of me and can play around with ideas as well as skip ahead or repeat chapters.

One of the best books for designers I have found is this little gem:
http://www.amazon.com/HTML-CSS-Design-Build-Websites/dp/1118008189/

Its a pretty good book for those who know little to nothing about web design. But I think the best part about the book is the way it is designed. You can tell just by flipping through the pages that the author is a designer, not just some code monkey. There are also a plethora of images so you can see the link between what the code looks like and how it affects the look of a page.

HTML and CSS are mandatory for doing web design. Java and Flash are completely optional depending on your job. Java is an actual programming language that allows you to run programs on their own or even within a web browser. It looks great on a resume and you may find jobs that want you to know it, but for right now I wouldn't worry too much about it. Flash is mostly used for animations and user interaction, however, it is slowly being overshadowed by HTML5. It is still a big deal though, so knowing it can be very useful. If you did want to go beyond your basic HTML/CSS my recommendation would be Javascript and PHP. Both are extremely common scripting languages and worth at least being familiar with.

As far as software, you can start designing with a simple text editor really Notepad or the Mac equivalent. But I would recommend something a tad more advanced. For something free and simple I would check out Notepad++ ( http://notepad-plus-plus.org/ ). Personally I use Dreamweaver because I get it as part of my Creative Cloud subscription. It does off a lot of useful features and plays well with Photoshop/Illustrator/Flash, but in the end those bonus features are just that: a bonus.

Depends on how old you are.

• Middle school: I really enjoyed this, this, and this, but I don't think I can read those books now (29) without cringing a little bit. Especially, Getting Things Done because I already know how to make to do list, but I still flip through all 3 books occastionally.
  
  
• High school: I really enjoyed this, this, and this, but if you're a well adjusted human and responsible adult, then I don't think you'll find a lot of helpful advice from these 6 books so far because it'll be pretty basic information.
  
  
• College: I really enjoyed this, this, and started doing Malcolm Gladwell books. The checklist book helped me get more organized and So Good They Can't Ignore You was helpful starting my career path.
  
• Graduate School: I really enjoyed this, this, and this. I already stopped with most "self help" books and reading more about how to manage my money or books that looked interesting like Stiff.
  
  
• Currently: I'm working on this, this, and this. Now I'm reading mostly for fun, but all three of these books are way out of my league and I have no idea what their talking about, but they're areas of my interest. History and AI.

Read "The C Programming Language" ( https://www.amazon.com/Programming-Language-2nd-Brian-Kernighan/dp/0131103628 , it's also on libgen)

​

Make sure you're cool with data structures (most of them are important, but hash tables are very key because they form the basis of caches, something you'll have to learn)

​

Look up some basic digital logic (up to flip-flops and d-latches, and cover some FSM too if you have time)

​

I don't really know of any great resources to self-study assembly, so you'll have to just make the most of the lectures on that.

​

Prof Nagarakatte is super fair imo. Multiple project extensions, a multitude of extra credit opportunities (I believe it totaled to something around 15% of the total course grade with max extra credit when I took it), and no curve- you just need an 85% (after extra credit is applied) to get an A, which is nice. The best thing about him, though, and something I've never seen anywhere else, is that the TAs know what they're doing. He tries to get his own grad students TA positions, and so he's got a great working relationship with them. Go to recitation, because the TAs know what's up and will often write out significant portions of the projects for you. In my opinion, the course wasn't particularly easy, but an A is definitely achievable as long as you put in the effort. His lectures are pretty fast, but the slides are online and fairly self-explanatory, so try to go over them after each lecture if you can.

I'll be honest with you, I don't think Head First Java would be a good choice, however DO READ Clean Code. I also suggest Design Patterns: Elements of Reusable Object-Oriented Software and Working Effectively with Legacy Code. The first is a classic MUST READ for anyone in software development. It present numerous challenges that most of us will face when developing solutions, and gives you the design patterns you will need to solve them. The second is great for learning how to fix your predecessors shitty code, you'll need this one. If you haven't already, look up Bob Buzzard and Andy Fawcett. These two guys are my favorite SFDC Dev Bloggers. I also suggest watching any Salesforce Webinar that has anything to do with code, especially security stuff.


Practice makes perfect, except for us there is no perfect, just better. Know your best practices and live by them. With everything you do ask how can I make it better? Faster? More efficient? Do I even need code, or will Workflow/Process Builder/Flow do? How can I write code, so that an Admin can customize it without any code?

> Based on code reviews--my code is pretty good, with good logic and pretty well laid out.

This is actually VERY important, having good logic is obviously crucial, but being well laid out is a kind of hidden requirement with code. You or somebody else will eventually need to maintain your code, if it's laid out well it should hopefully be easy to read and maintain.

When you write code do your best to incorporate declarative features so that further customization can be done without code (I know I said this earlier, but I think it's important). Need to write some code that uses an arbitrary set of fields, consider using Field Sets. An Admin can add/remove them without code. Maybe use a Custom Setting, or Custom Metadata to map fields to values.

Learn how to use Describe calls for everything. Need to write some code that catches dupes and merges them? Don't hard code the values, then nobody will be able to remove or add fields without updating code. Instead use Describe calls, now you get every field on the object forever. Need to remove a field from an object no problem. Need to add a field to an object no problem. Does your losing record have child records that need to be reparented? Don't hard code, use Describe calls to get all sObjects with a Child Relationship. Use Describe to find out if it can be directly reparented or if it needs to be clones (CampaignMembers can't reparent a LeadId to a new Lead. You MUST clone and add the new Lead Id).

How much do you know about HTML? CSS? JavaScript? JQuery? Visualforce? Learn 'em. Lightning is coming, and these are going to be more important than ever (except maybe Jquery).

Practice, practice, practice. One coding assignment per month isn't that bad, but if you get some work done early and you have an hour or two to spare, work on a side project. Can you think of something in your company that could be automated, spin up a Dev Org and give it a shot. Maybe your Sales people could use a new VF page for entering information just a little quicker.

Always seek to improve your code. Always seek new ideas and better ways of doing things.

Trailhead is good, do all the coding ones you can find, it's more practice!

Sorry for getting back to this so late, it's been a long week.

1. You will need a good understanding of HTML/CSS, mostly how to manipulate and traverse the DOM tree. Luckily, this is very simple and straightforward once you figure out how the pieces fit together. On top of that, Javascript does a great job of hiding the need to actually write HTML or CSS markup, though you should still understand how it works. The better you understand the pieces of the puzzle, the more interesting and creative graphics and visualizations you can create!
   
   
2. The graphics are very easy to show off, seeing as they live on the web :) There are a ton of ways to host graphics, either on your own website, or on one of the many free online platforms like Github and CodePen.
   
   
3. As far as preserving interaction outside of the web, I do not have any knowledge of how to do that with Javascript (not to say that it doesn't exist).
   
   
4. As far as resources, I highly recommend reading Javascript: The Good Parts to understand how the language is put together, why it was put together that way, and how to take advantage of its unique style. It is a pretty short read. As far as learning visualizations, I learned most of my fundamentals from taking courses on Lynda, and then used good old Stack Overflow to figure out how to create the specific things I wanted to do in my visualizations. Other good sources for video tutorials are Pluralsight and sometimes Youtube.
   
   
5. YES! That is the beautiful part of creating visualizations on the web, you can power them with any web technology. Most of my visualizations retrieve data from some web API and use that to build graphics or show an interactive dashboard, meaning they look different every time I load them up. This gives you a ton of freedom and flexibility to create graphics that are both pretty AND useful. It's very common to hook them up to databases to query and display data.
   
   
6. As far as IDE's, I absolutely love Visual Studio Code if you have a Mac. It is VERY different from regular Visual Studio and has some great features like a built in terminal window, built in git support, a very lightweight directory structure, and a good community for 3rd party add-ons. It was built with Javascript in mind but I now use it for C++ and Python as well. If you run a windows, I use Sublime Text 2 which has many of the same features. If you want something with a bit more out of the box, Atom is a good IDE that lets you view your site as you build it and also deploys a small web server which is useful if you are not running your own.

It's fun, although unconventional. People may have trouble navigating your site because of the layout. The movement of all the site elements also has my eyes bouncing up and around as I scroll through the page. Is it critical that those navigational elements scroll with the visitor?

The design you have to display work progress is clever ( I would love this if I were a backer), but I'm not sure it works in the scrolling format you have now.

An image of a face will draw the attention of visitors to what you want them to do. Right now, my attention gets drawn to the bouncing navigation bar, which fights with the video for attention through movement.

I think what you want the visitor to do is play the demo and then become a backer based on their enjoyment of that. Is that correct? The cute three liner of features does not convert me into a demo downloader. The other box of features gets me a little closer, but I'm still confused as to what your game actually is. The video makes it look like HOMM with more units.

I would think hard about what you want the person to do and then design it around that. You want to guide the visitor down a path that leads them to the single action that you want them to make. Once they go down that path, then they can explore the other site content (like the bestiary and so on).

Here's my take:

Good

• Art style. Games should be fun. This is a fun page.
  
• Font. Makes me think of old-school print ads for games that used to be in comic books.
  
• The icons are fantastic in terms of the art.
  
• Title. Makes me think of a children's book; reminiscent of a Roald Dahl title. I hope it's intended for children, maybe 10-14 -- am I off base?
  
  'Needs Improvement'
  
  
• Font colors are not appropriate for the background. High contrast text is easier to read. I'm OK with the bolds being differently colored, but a designer might disagree.
  
• Iconography is not labeled, and you must mouseover to learn what it means. If I am landing on this page from somewhere else, it's confusing.
  
• The copy is too heavy on features and not enough on the benefits. Few people buy things based on features. They buy things based on what the features will do for them.
  
• There is no hierarchy to the icons on the navigation bar. See 'suggested reading' for more on why this is an issue.
  
• Center orientation is unconventional, but I can live with that because I'm a fan of columns and think more websites need to use them to improve readability.
  
  Suggested Reading
  
  Don't Make Me Think by Steve Krug
  
  This is an industry standard book on web design that is still applicable today and is well-regarded.
  
  If you believe that your current design is strong, do a coffee shop usability test where you take a laptop and buy coffee for random people, ask them to accomplish one of your site objectives, give them a short survey, and watch how they do without providing them with any assistance.

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.

> Please tell me you don't expect people's websites to fit into a pixel grid and follow the mockup precisely.

D I do the transfer from mockup to code, so everything fits precisely to my specification hehehe. When I am transferring other people's mockups, I try and follow the mockup as closely as possible. Sometimes the mockups are not precise, themselves so I edit them.

> Where can I actually learn more about how to design from the ground up? I'm working on a site that has no existing analog, so I can't just look at how other people have done the same thing and mimic them. I don't even know what to put on what pages.

Hm, I would need some more information to give you good advice. Try and imagine a scenario where a customer is using your site. What is their main goal when using it? Can you simplify the process of them achieving this goal? Any less important goals? What are your main goals with the site? Where would the most logical place for various elements around the site be?

Read Don't make me think for a great usability primer. PM me if you want any more help.

> I thought Gimp did have adjustment layers. At the very least, you can set the blending mode for a layer in such a way that it effectively adjusts one thing in the overall image.

Can it place for example a Hue and Saturation filter on its own layer like Photoshop? I don't want to copy everything into a new layer, apply filter there and then mask or whatever.

> I think the cited reason for the lack of CMYK in Gimp is that they feel Gimp is specifically for image editing, not printing; Photoshop was originally created specifically for printing.

Right, PS started that way but then it evolved. I think GIMP should mimic a lot of PS functionality if they want to see pros switching.

> The .psd support is really lacking. I don't have any way of testing Krita's .psd support... But I do know that if I export a file as .psd from Krita, it doesn't open correctly in Gimp. Specifically, any text objects simply vanish. That's all I've tested, though. Granted, it doesn't exactly import into Krita perfectly either, even though it was saved from there...

Yep. If I receive a .psd from a client I need to be able to open it without any glitches. Currently it doesn't.

> If 'Blending options' in your post corresponds to this post about 'Blending Modes', yes, and Gimp has had them for a very long time. I refer to them earlier in this post, talking about adjustment layers (since I'm otherwise somewhat not sure what you mean by an adjustment layer).

I'm actually talking about the option titled Blending Options which you can select when you right click on a layer in PS. This brings up a Layer Style dialog box with a ton of options. Now, GIMP might have similar functionality scattered around, but I haven't found it yet and it's very useful as I use that dialog box constantly.

> I looked up adjustment layers. Gimp does not have them, but most people say a lot of their functionality - but not all of it - can be made up for with blending modes applied to layers 'above' the layer you want to adjust.

Hassle!

> Also, the APIs necessary for adjustment layers are coming in 2.10, after which they have the technological capability to make them.

That's good to hear. They have made great progress and I am sure they'll see their numbers rise if they get closer to PS functionality.

Another thing I forgot to mention, a minor gripe I have with GIMP's UI - I think the cursor and the selecting bounding boxes look clunky instead of precise. The tools should look and feel precise (as well as be precise), and I think GIMP is lacking here. Compare PS to GIMP and you'll see what I mean.

Instead of buying tons of books, you might want to look at Safari Books. I have the 10-book bookshelf subscription, and it is seriously plenty. Pros, you have instant access to a massive library of tech books. Cons, you are stuck reading on your computer/tablet/phone (I did try reading a few chapters on my Kindle, but the didn't care for the experience).

Books I would suggest:

• UNIX and Linux System Administration Handbook - this is seriously a great book, that will make any admin better.
  
• Time Management for Systems Administrators - has a lot of good tips for time management, but some things are a little dated.
  
• The Practice of System and Network Administration, Second Edition - This is a great read on how to be a better system administrator.
  
  I'm not a huge fan of training videos, but generally watch recordings from conferences. Although, I do really enjoy the format of vimcasts though.
  
  As for general advise, I did see someone recommend looking for an MSP. If you are looking to be a Linux SysAdmin, I wouldn't recommend this route as you are going to be supporting MS installations. Personally, I started doing help desk for a web company and moved up from there. Also, I worked hard to create my opportunities within each position. You'll have to put yourself out there and be patient, It took me 4 years to earn the official title of Systems Administrator (in a small-ish town). The key to this is finding a good Sr. SysAdmins who are willing to mentor you, and some environments/people aren't conducive to this.
  
  EDIT:
  
  BTW, I have a B.A. in Political Science, so don't be ashamed to rock that Philosophy degree. You will see a lot of posting that are looking for a B.S. in Computer Science/Computer Engineering/Rocket Surgery, but seriously don't even worry about that. Most job postings are a list of nice to haves, and most places really only care that you have a degree.
  
  I've been recruited by and interviewed with some very respectable tech companies. I just usually have to explain how I got into tech with a political science degree. In an interview, having the right attitude and knowing your stuff should say more than your major in college. But, you will also run into elitist douche bags who knock your degree/doubt your abilities because you don't have a B.S. in CS/CE. If you work with these people, your work should speak for itself. Don't try and get caught up into a pissing match with them. If it is an interview (as in someone you might work for), practice interviewing never hurts.

C++ Primer is amazing, but definitely not for beginners. Since you're totally new to programming, I'd suggest learning a bit of Python first to get the basics down, or if you're feeling more adventurous, pick up a copy of K&R's "The C Programming Language", as it's a great introduction to lower-level programming, and it'll make C++ a lot easier to understand.

Some good freely available online Python books:

Invent With Python

Learn Python the Hard Way

Learn Python the Hard Way is easier than it sounds, I assure you. I would definitely recommend starting with Invent Your Own Computer Games With Python, though.

A couple more useful things to know:

• If you don't understand something, Google it. Stackoverflow, especially, tends to have a lot of good discussions on common pitfalls encountered by newbies.
  
  
• If Googling doesn't clear it up, don't be afraid to ask for help. This very subreddit is a great place to do so when you get particularly stuck!

Are you a beginner to programming, or have you been programming for a while in other languages and are just getting started with JS?

If you're a beginner to programming altogether, this is a good resource, but I'd also recommend some dead-tree books. I've heard good things about Javascript: The Good Parts, though I've never read it myself.

Edit: One thing to be careful of when you're just getting started, by the way: try not to focus too much on any single language and its features. You want a good solid base of fundamentals, you don't want to hyper-specialize from the start. Don't just learn Javascript, for example. Try Java and Clojure and C and Haskell too, and any other language you can get your hands on. They all have their own idioms and lend to certain styles of problem solving, it's good to be able to figure out which one is best for the task you're facing.

If you've done some coding before, and are branching out into JS as a new language, there's no better way than reading about it and then trying it out on your own. JSFiddle is a great resource for just playing around. You could try implementing solutions to Project Euler puzzles in JS. Or you could pick a pet project you want to work on that has some client-side behavior and implement it in HTML5/JS. Or server-side behavior and do it in node.js. Or you can find an open-source project using JS that you're interested in, and get involved there.

Edit: Also, Stack Overflow has dozens of JS-related questions answered every hour. Sometimes those answers come attached to a lot of useful information. Try browsing there, and if you have questions, ask them. It's a great resource.

So, everyone has different learning styles and there's no completely "best" way to learn something. Here's a couple suggestions on how I'd recommend starting:

• The simplest starting point would be to follow an online tutorial. It's been too long since I learned my first bits of javascript, so I don't remember what I used, but after a bit of looking, this one looks decent: https://javascript.info/ EDIT: Like /u/HothMonster recommended, I've heard good things about CodeAcademy. A friend went their their javascript course and found it useful. Haven't done it myself, but worth a look too.
  
• Are you the type that'd like a book to guide you through? There's one that I read and loved while I was learning: Javascript: The Good Parts. If you google it, there's a PDF in the top few results too, but I have no idea if that's legal or not.
  
  Using tutorials or a book, get a basic start going. Once you have a little bit of HTML/JS knowledge going so that you can make a index.html file and have it load a javascript file that does anything, like log to the console, then you're started. Go through a tutorial/book to get a bit more understanding and then.... build something.
  
  It's hard to choose a topic, but try to find something that you're interested in. Then work on making it. You'll learn an incredible amount by doing it. Don't try to master the language first, just make something with it. Then you can ask specific questions about the parts that you're having trouble with and it will help guide you through it and people will generally be willing to help someone that's working.
  
  Plus, getting help is easier when it's a specific use case that someone can help with vs. "Please teach me everything about this language" because even those of us that have worked with a language for quite a while often don't know all of it. :P

> Recently released books? Udemy courses? Free stuff online like W3Schools or CodeAcademy?

Mozilla Developer Network has fantastic documentation for JS, HTML, CSS, and the browser APIs, and a section intended to guide you through them for the first time in a comfortable order.

If JS is your first language, I'd recommend checking out the book "Code" by Charles Petzold, a great and relatively short book that answers the fundamental beginner questions like "So what's a CPU actually doing in there?", "How does source code make stuff happen?" and "How can music be 1s and 0s?"

There's a great series of books, available for free online, called "You Don't Know JS", that teach you how the language operates. It might be too involved if it's the first thing you read, but definitely at least start it and bookmark the later volumes to come back to.

Marijn Haverbeke's book "Eloquent JavaScript" is available to read freely online. I'd really recommend that one, too. And when you want to stop reading theory and start working on actual projects, grab "JavaScript Cookbook" by Shelley Powers.

> Did I choose right languages for what I wish to create? Maybe I should also use something else, like Bootstrap, Node.js or Typescript?

Don't worry about those for now. Node will be useful if you decide you need a server component to your game. Bootstrap is nice, and it's helpful, but if you're still trying to learn HTML and CSS yourself, it will only get in the way and obscure things. TypeScript is something you'd look at only once you're comfortable and confident with regular old JS. Stick to plain old HTML/CSS/JS of your own to start.

I found Lynda.com to be extremely dry and slow. To me it was the equivalent of those old school mandated educational movies you would watch in classrooms back in the 90s on your faux-wood tv. Take this opinion with a grain of salt though as it has been almost two years since I have looked at anything on Lynda, I hear it may be better today.

If you are looking for web development in particular I would suggest the following:

• Codeademy - Free and very good at introducing basic web development skills.
  
• Team Treehouse - Paid subscription but well worth it in my opinion as they will walk you through everything from the most basic HTML to building advanced JavaScript applications.
  
• CodeSchool - CodeSchool tends to be more advanced and I would wait until you have a strong grasp on your HTML, CSS and JavaScript before investing in their coursework.
  
  In addition, StackOverflow; A general programming Q&A website, has an answer to just about any programming issue you may be running into. If the answer is not already there, then chances are you will have one within 24hours.
  
  I began my pursuit into web development about 2 years ago. In that time I have gone through the resources listed above as well as the following books which have helped immensely:
  
  
• HTML and CSS: Design and Build Websites - Ducketts whole series is extremely friendly to the new web developer and will help you build a solid foundation quite quickly.
  
• JavaScript and JQuery: Interactive Front-End Web Development - Another Duckett book which was just released focusing primarily on JavaScript.
  
• JavaScript: The Definitive Guide - A massive JavaScript reference. It has answers to just about everything.
  
  Some personal career history if you're interested:
  
  In the last two years I have gone from making 18k a year as a Technical Support Representative to 80k a year as a Front-End Engineer building JavaScript applications at a large FDIC Bank. It was only in the last two years that I really dug into Web Development (and programming for that matter) and I really can't see myself ever doing anything else for a living. The job requires an immense amount of learning (which I love) and will keep your mind sharp. I really do get a kick out of problem solving all day. Programming will require a major adjustment to the way you think. I can say that the way I work through problems now is completely different to the way I did before. I feel as if critical thinking has eluded me until the last two years and it has been a major life changing event. By far the biggest contributing factor to my growth has been the team I work with. You have to do your best to find a team that is willing to work with you as a junior so you can siphon that knowledge. Even if that means taking a low paying job, however; know your worth so that you can ask for the right amount of money once you have gained the necessary skills. As a personal rule of thumb, I will not stay at a company where I am the most knowledgable member of the team. This inhibits growth as a developer and will prevent me from realizing my true potential.
  
  Feel free to hit me up if you have any questions.
  
  
  

Well, I know UI and UX are not interchangable terms, but if you want to build UI's, either get really good at front end design at a smaller shop and design things yourself, OR go into User Experience Design, Interaction Design, or Human Computer Interaction (there's lots of names for things) and work on larger teams.

And they don't actually "do" any one thing on a daily basis. And differences between stakeholder needs, legacy, scope, and testing methods will radically change a project.

But here are some examples of stuff I've done in my first year doing freelance UX work:

• I interviewed pediatric cancer survivors about their daily web habits and discovered the majority of them use their mobile phones for the bulk of their web browsing. So I wireframed a responsive site with hosted videos and a private comment section for learning about post-remission care and facilitate discussion between patients. I then sent those wireframes off to a front end developer.
  
  
• My cousin's cupcake bakery was getting good traffic from social media (folks on Pinterest love cute cupcakes), but wasn't getting a lot of people actually using their site to order anything. So I organized some "guerilla user testing" offering cupcakes for a couple of minutes of folk's time and found that the online ordering process was poorly documented. I changed some WordPress plugins around on their site, changed the button size and copy on the site to make things more transparent, and checkout cart transactions online went up more than a third.
  
  
• A local museum was in the process of changing their site around, so I helped set up an A/B test using Optimizely to figure out what best drove folks to the membership signup page. I got 50 billable hours out of it and went to a lot of meetings were I had to explain in plain English what I was doing.
  
  So there's no one thing you'd be doing if you dedicated yourself to UI design. There's elements of project management, front end development, graphic design, behavorial pyschology, and marketing in your toolbox and you just need to figure out what works best with what project.
  
  As for schools: My degree is in "Interactive Arts and Media" from a local art school, but my boss on the cancer project studied Ancient Roman History and another UX pal I worked with studied Feminist Literature at an Ivy League school. So there's really no "path" per se.
  
  > I need a structured environment
  
  Well, this is the bad news... design tends to be a passion for people, which attracts self-starters. This isn't really a framework for what we do because it's not an exact science. So you kind of need to be able to discipline yourself.
  
  But don't worry! I was like you too, and I figured it out because I have a passion for it.
  
  My favorite book (and it's a classic) is Steve Krug's "Don't Make Me Think." I've got like three or four used copies around my house because I loan them out a lot. And if you're close to a big college, they probably have a bunch of used copies for less than $10. But it's a great intro to how people look at interfaces and how folks gets started doing this work, and probably a good starting off point if you think this is for you.

I think I get what you're saying, and I was in a spot like this for a while myself, although for me it was more about trying to figure out "how do I debug my code?" - everything's focused on the language itself, and not so much on the peripheral skills. I eventually found resources that helped and I started making progress, so let me pass on some advice.

First up, if you're getting stuck with your IDE, trying getting rid of it for a while. Instead, just use a text editor and invoke your compiler and run your programs through the command line. This will force you to figure out what you don't understand about the build process, and once you do begin to understand it and grow beyond it, you'll be able to go back to your IDE and more easily figure out how to do all the new stuff you just learned in there. The other benefit is that after a few rounds of compiling godawful novels of commands to include and link everything in a decently complex project, you'll be desperate for a better way and have a motivation to learn about Makefiles (or automated build systems in general) which you mentioned not really understanding, but by this point you'll be intimately familiar with why they were created. To learn about them, Google is really your friend - there are a ton of tutorials online and some of them are decent, along with plenty of templates and such to get you started.

But that's only part of your question, I know. For the more general stuff, I have two major suggestions. For general 'peripheral' coding knowledge, I'd actually recommend Effective Computation in Physics. It's aimed at academic researchers and focuses on Python, but those things don't really matter; the best parts of it are the ones that aren't language-specific or domain-specific at all. Because it's written for people who may be trained as physicists (or biologists, or chemists) first, it works up from ground zero and actually explains things like unit testing, debugging, project organization, version control, and everything you need to have a self-sustaining small-to-mid-sized project, which is what it sounds like you're struggling with right now. My other suggestion is that if you're confronting more abstract issues, like design, you could check out The Pragmatic Programmer, which has a lot of good suggestions for avoiding bugs and increasing reusability and ease of maintenance. It's also targeted at small-to-mid-sized projects, but I find most design books for industry-scale stuff to be almost impossible to get through if you're not actively working on a large design team for a real-world application (though if you need that level of sophistication, there are some options if you poke around Amazon).

Apart from those things, you might also consider directly searching for some of your questions, like "how do I organize a software project directory" - I've found surprisingly helpful mini-tutorials from random university CS sites that way, usually as part of the intro or syllabus for a programming class. Oh, and if you're having trouble even getting started on what you want to do, see if you can't break it down further - make a toy engine that does one thing, then add one more thing, then add something that ties those pieces together, etc...

Anyway, hope something in here helps you, and good luck!

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

Jaap Schroder wrote a book detailing his study of the Solo violin works, and he's recorded the concertos as well. That's a good place to begin. There are some really brilliant insights that most students would never consider.

Don't get caught up thinking you are handcuffed and can only imitate an anemic baroque style or a warbly, romantic style. This video is one sort of hybrid, where the soloist and conductor are very aware of performance practice, but modern instruments and techniques are relied upon heavily. Remember that no recordings exits before 1900ish. There's still a lot of personal judgment in a good historically informed performance.

There are many great Bach interpretations, and you should listen to many recordings (Grumiaux is often held in high esteem, and Schroder, as good models) to find out where your preferences lie. You should attempt to play with all sorts of expressive devices (Non vib, lots of decay, faster bow, different bow strokes, bowing patterns, holding the bow higher, gut strings?, baroque bow) and find out what you have to say about Bach. I think any successful interpretation will at least have two major things: a tremendous sense of line (form, rhythm, a large-scale view) and an expressive use of the tone color (bright, warm, deep, thick, feathery, etc.).

Leopold Mozart also wrote a treatise on violin playing. In terms of playing style, he was more familiar with the Baroque than with the music of W.A mozart. He wrote about a sense of "affect" in Baroque music. He wrote that overall, there is one overriding feeling that should come across in Barque works (especially dances and binary form movements.) In the E major Bach, I bet it would be helpful to decide what the "affect" is for each movement. Is there only one, is the narrative single-minded? More simply, come up with something other than "happy" or "sad."

Don't let anyone tell you Bach was a stodgy, strict person. He was ridiculously smart, as shown by his ability to improvise multi-voice fugues. Hofstader wrote eloquently about Bach's puzzles and intellectualism. He was a jokester - the crab canon and the Coffee Cantata or good examples. He was sometimes compensated for his work with large amounts of beer. Bach had somewhere around 20 children, about half of which survived childhood. Bach was a very complex person, with lots of life experience. Don't let a careless caricature influence how you think about his music.

> Another thing I want to know is which programming languages/tools I should read up on. In my experience I've pretty much only used Java, Git and some basic HTML/CSS and Javascript. I know this is largely dependent on which team I end up on, but I might as well read up on something in the few weeks between graduation and my start date (early July).

AFAIK, we only use Java for the Android versions of our mobile products (MyChart for mobile; and Haiku). Most of our applications use HTML/CSS/JS, though, with use of these technologies increasing as we move away from VB6.

We do not use Git; instead, we use SVN. Maybe spend an hour learning how SVN differs from Git, if you'd like. But a lot of our SVN workflows have an extra layer of automation and hand-holding on top, so realistically, a deep knowledge of SVN isn't particularly useful or necessary for most developers.

I assume you've heard we use VB6 and M. Our internal training materials for these languages is superior to anything you'll find outside Epic. Don't bother hunting through an antique books store for tomes on either of them.

If you're bored and want to learn some job-relevant stuff, consider the following:

• C# and ASP.NET. You'll very likely be trained in C# during your first month or two here, but it doesn't hurt to have a head start. You'll also be trained in the framework that we implement on top of ASP.NET. You never really learn about the ASP.NET layer directly, which is a bit unfortunate; I think it would be good for you to do some reading about that.
  
• TypeScript. We'll have started switching over from JS to TypeScript by the time you get here. You may not understand how awesome this is. Trust me: it's mindblowingly awesome. TypeScript alleviates the pain of development for the web browser in a way that almost no other language/framework does (you have to start getting into esoterica like Emscripten to do any better than TypeScript, and then you start running into impedance mismatch issues).
  
• Learn how to think from a testing-first point of view. I estimate that less than 1% of our code is covered by some kind of automated test (a unit test, an integration test, whatever). This is part of why we have such an enormous QA division (not that QA is entirely replaceable by automated tests, obviously). I don't recommend learning any particular framework (we have internal resources for the frameworks we use). Just learn how to write testable code; how to write good tests; how to develop with testability in mind; etc. Genuine test-driven development is not really feasible for most of the projects I've looked at, but even small steps in the direction of testability help.
  
• Related to the previous point, learn how to deal with legacy code. This is not a skill you are likely to have fresh out of college, but it is a skill you will need in most software companies, and especially at old ones like Epic. The standard tome on this is "Working Effectively with Legacy Code". If you can find a cheap copy, I recommend buying it and skimming it. You probably won't really get it until you actually start working with our code, but better to be prepared than not.
  
• Find a spiritual guru and have him teach you how to attain inner peace. This will help you not rip your eyeballs out every time you have to deal with VB6.
  
  > I guess my main concern here is that I just want to know if I should expect to be putting in 60 hour weeks.
  
  I have never worked a 60-hour week at Epic (unless you count time spent sitting in airports / on airplanes as part of the workweek, in which case I've worked one 60-hour week). My typical week is 35-45 hours (which, granted, is on the low end; 40-50 is more typical).