I don't really like the term "design your system using interfaces" because it doesn't tell you why. It's a generic idea without any context.

It is better to start with a principle, like Dependency Inversion. Dependency Inversion says you should separate your code from its external dependencies. This is good, because it keeps your code isolated and not dependent on the particular details of things like storage.

Does your application use MySql? Does it use MongoDB? It doesn't matter. In your interface, you can specify query methods for objects from a data store, and a method to save objects to your data store. Then implement the interface specifically for the data store. Your interface could be called FooRepository and the implementation MySqlFooRepository or MongoFooRepository. I dislike interfaces called FooRepositoryImpl. This strongly suggests an interface isn't necessary.

Interfaces are contracts that help you preserve your design and to explain what you need out of external dependencies.

Interfaces are good, but so are classes. Don't overuse interfaces, because indirection isn't always necessary or good. It can make your code impossible to follow and understand.

Start by learning principles like SOLID, which will help you understand where usage of interfaces makes sense. Agile Patterns, Principles and Practices is the best book I've read about this. Another book which does a great job of explaining how to properly use interfaces is Growing Object Oriented Software Guided By Tests.

I had a lot of similar issues early on in my career. I seem to type faster than I think, and a lot of little things somehow made it into my code that I wouldn't notice until much later, when I had a lot more code debug through.

Getting into the habit of Test-Driven Development pretty much solved this for me. By writing unit tests in expectation of the functionality of the code I wanted to write, I would prevent myself from building on top of code with bugs or small errors.

A lot of people think TDD takes twice as much time because you write roughly twice as many lines of code, but I was drastically underestimating how much time I was spending debugging. My code gets written and merged in half the time it used to take, and having my code reviewed takes almost no time at all.

TDD is by far the best remedy for small, easy-to-overlook mistakes, but it also forces you to break down problems into much smaller units than you might instinctively. I find that this also helps me solve problems faster, because I prevent myself from immediately attacking the first problem I see, which may actually be a combination of 2-3 problems (which I may have already solved somewhere else). My code is more functional, more organized, less repetitive, and problems get solved much faster.

I highly recommend reading Growing Object-Oriented Software Guided by Tests.

Just a public service announcement - this is not what mocks are for. I would recommend anyone interested in the subject of effective mocking to read Growing Object Oriented Software Guided by Tests by Pryce and Freeman, the authors of the jMock framework.

From the OP, the way to test "monolithic" applications using mocks is exactly the same way you should test HTTP endpoints as well. As far as the application is concerned, it should not matter that the endpoint is a microservice, a remote HTTP API or otherwise.

This lets you set a service contract for your expectations of the remote service specified using a service interface. The implementation contains the details of the HTTP interaction, which you can test for real, separately and in isolation from the rest of the application to verify that it meets the needs of the application as specified in the service contract.

Otherwise, this mock isn't really testing anything other than you are using an HTTP connection API correctly, which doesn't tell you if the REST service actually behaves the way you expect.

Today they are saying the problem was actually a virtual function not being overloaded properly.

> Long story short, diffing the 1.1 and 1.2 executables after seeing all the bug reports to see if I could fix any of them. There's a MagicTarget interface class that is implemented by everything you can damage. One of the virtual functions on that class is used to calculate resistance (as a scale factor), and the diff showed that for the versions used by Actor (base class for Character/PlayerCharacter) it had fallen back to the base class' implementation of "return 1" instead of the larger function before. A new virtual function with roughly the same code as the old MagicTarget function appeared on Actor, but it isn't being called. It seems like someone accidentally misnamed or changed the signature of that function in Actor (or vice versa), so it isn't overriding the function in the interface.

http://forums.bethsoft.com/index.php?/topic/1288179-wipz-skyrim-script-extender-skse/page__view__findpost__p__19568346

Bethesda doesn't even have an automated unit testing system to make sure their virtual function calls are hitting the proper targets. Simply unbelievable for a project as large as a huge open world AAA game that probably has like 5 million lines of code. I suggest we all send Bethesda this book for Christmas: http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627/ref=sr_1_3?ie=UTF8&qid=1322766398&sr=8-3

> But I've come to avoid mocking as much as possible as tests based
> on mocks don't prove anything, except that my code works under
> the assumptions i made

This isn't really how mocking is supposed to be done. I would recommend reading Growing Object Oriented Software Guided By Tests, written by the authors of JMock, and the people who originally came up mocking as a test practice.

In short, you don't mock external services or anything you don't own. You should mock an interface you created and that you own, that defines the contract that external dependencies must meet to work with your class on your terms (aka, ports and adapters). This is the essence of dependency inversion. Mocks ideally guide development towards DI.

The adapter is concerned with making sure that the external dependency actually conforms to the contract defined by the interface that is mocked, and adapter code must definitely be integration tested. And the integration test now needs only to verify that the adapter meets the terms of the contract. This separates testing the logic of the system (where TDD fits in) from tests of the integration with the external environment (functional and integration tests). However, the authors of the GOOS book recommend writing the user acceptance tests (functional tests) before you write the unit tests (which they lump into TDD, in a more holistic sense).

I was right where you are now about 6 months ago. I'd done some unit tests in previous projects and could kinda see the point in using them for certain things, but I didn't understand the need for writing tests first, and didn't understand the value in the red, green refactor cycle.

I can tell you six months ago I started working for a company that believes heavily in TDD, and after going through the initial pain barrier, I now can't see any other sane way of writing code.

There were a few hoops I had to leap through in order to get to this point. One of them was due to the fact that I simply wasn't testing things correctly in the past. You should always isolate your tests to the EXACT thing you are testing in each case - so you should never really be connecting to the database, or depending on other modules etc. Any dependencies therefore need to be injected into the system under test and mocked accordingly, so you know you are isolating the thing you want to test.

You also should never be testing implementations, which is why you should never have to test private methods. You only care that the public methods of a class will return whatever you expect under the conditions you are testing for. This is crucial, because it's this that makes it really easy to refactor your code later.

When you take this approach for everything you do (combined with doing red, green, refactor), you find yourself soon entering a luxorious position of being able to refactor things at a higher level just to make things cleaner and easier to understand.

Just this week I took a system with over 2500 unit tests and refactored some of the fundamentals of that system - found some abstractions and moved them higher up the chain + extracted some interfaces to make the code easier to extend without modification, and all the while I knew everything was working because my unit tests proved it. This is part of the core of a system that deals with literally millions of users each day (seriously), and I did so without fear.

This approach means the code is constantly getting cleaned and tidied up as we go along.

The red/green/refactor approach works something like this:

• write a failing test (this is important, because simply going for a green pass right away can sometimes bite you - perhaps the test is providing a false positive? You should always see the test fail first for this reason)
  
  
• Make the test pass - I tend to do this in a sane way, but I don't try to engineer my code so much at this point. Just get it passing. The key to this is to only test the expected behaviour of the class, not to test the implementation - we only care about the result, not how the result is achieved. Doing this brings us to the next part:
  
  
• Refactor. This means we can do obvious stuff like removing duplicate code, and then generally chopping and changing stuff around to make it easier to understand and less complicated.
  
  The refactor step is crucial, but because your tests should be rapid (because we've mocked out all dependencies), you can refactor in very small steps and run the tests each time you make a small change. This way you can neaten up and tidy your code in small, safe, incremental steps, and you keep doing so until you are happy that it's easy to understand and give you the flexibility you need. Once you're happy, you move onto the next test.
  
  The entire cycle is quite quick actually - much of the complexity comes down to to learning the best way to test and how to mock out dependencies etc.
  
  Our suite of around 2500 tests takes about 15 seconds to run, but as I'm working on a feature I may only be running one test at that point, so it'll usually take less than a second to run the tests as I'm refactoring. Toward the end of the process I run the entire test suite to make sure everything still passes.
  
  I went from not believing to seeing this work in practice, and now I honestly don't think I can work anywhere that doesn't do TDD. I would be happy to teach other people how to do it in a company, but as mad as it sounds, to me now, not doing TDD is like saying you don't want to use version control. This has all changed in the last 6 months, having seen it work in practice.
  
  Here's a book I highly recommend: http://www.amazon.co.uk/Growing-Object-Oriented-Software-Guided-Signature/dp/0321503627
  
  I love the title of that book "Growing Object Oriented Software Guided By Tests" - this it the thing - working this way allows you to "grow" your software, and the tests really do guide you towards the solution you actually need (this is powered by the refactor step).

[Test Driven Laravel] is an excellent resource for people who are new to testing, even though it is tailored to Laravel. There are plenty of concepts you can apply to other languages/frameworks, though.

[Growing Object Oriented Software Guided by Tests] is a book that really helped me understand testing, especially test first. The examples in the book are in Java, but again, the concepts apply to other languages. The Test Driven Laravel link I provided is very clearly inspired by that book.

I'm really surprised nobody has included the books by [@grmpyprogrammer] since he's fairly well known as the "testing guy" in the PHP community. I believe all of his books are on his [Leanpub].

[Test Driven Laravel]: http://testdrivenlaravel.com

[Growing Object Oriented Software Guided by Tests]: https://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627/ref=sr_1_1?ie=UTF8&qid=1525976055&sr=8-1&keywords=growing+object+oriented+software&dpID=51fUKOog3VL&preST=_SX218_BO1,204,203,200_QL40_&dpSrc=srch

[@grmpyprogrammer]: https://twitter.com/grmpyprogrammer

[Leanpub]: https://leanpub.com/u/chartjes

Edit: Apparently I needed to refresh before posting as other people have linked up to Grump Programmer.

The absolute best book I've read about TDD is Growing Object Oriented Software Guided by Tests. One thing to note about this book is that it follows the "mockist" approach to TDD, as opposed to the "classicalist". Martin Fowler goes into the difference a little bit here. The "mockist" and "classicalist" debate is somewhat of a religious war, be warned!

Data structures and Algorithms Write code to impleement every (or even most) and you'll be well preparped.

Design and Testing here.

Programming Languages here.

Also look for an open source project that needs help and provides you with experience in one or more of these areas (or start your own). Code is always a good way of showing you know something.

So, DHH's objection really isn't to unit testing, but to extreme decoupling, and in a way, his article misses the point entirely.

His complaint is that in the pursuit of testability, Jim Weirich introduced the Hexagonal Architecture. But testability is not the purpose of the Hexagonal Architecture. It is one way to remove Rails as a dependency on the application logic, following the principles of Clean Architecture. That doesn't mean you don't write tests against the Rails controllers, those are absolutely mandatory. It just means, theoretically, you could ditch Rails. Whether that is a reasonable goal to code for, you be the judge.

You don't have to design the code in that way, simply in the pursuit of testability. The style of testing promoted by Weirich is the so called London Style of TDD, promoted by British developers Steve Freeman and Nat Pryce in their famous book Growing Object Oriented Software Guided by Tests. Whereas, the Chicago Style popularized by Martin Fowler (who ironically, is an Englishman), promotes testing with real objects, and test doubles as necessary for behavior verification. which correlates more closely with Kent Beck's original conception of unit testing.

For testing, I liked this one: https://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627

For version control, continuous integration, continuous delivery, this was a good read: https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912

There are many extreme programming books that briefly talk about pair programming. If you want a book specifically on pair programming only then there is this: https://www.amazon.com/Pair-Programming-Illuminated-Laurie-Williams/dp/0201745763

There are thousands of books out there for learning various topics of software engineering.

> The idea is that both DAOs join the transaction, and that either the
> data from both DAOs ends up in the DB, or none at all. The DB has some
> contraints set for the data that we are persisting.

and

> What we however really wanted to test was whether the data
> actually ended up in our DB and whether both DAOs joined the
> transaction to see if the effects of DAO1 are correctly undone
> (rollbacked) when DAO2 throws.

This is not what mocks are for. This is why you do integration testing and functional testing.

Mocks state the expections a class under test has for its collaborators, and verify behavior given those expectations. You use this to grow the interface for collaboration based on class under test's needs. Furthermore, the owner of the interface is the class under test, not the collaborator. If you change the interaction with the interface, you must verify the collaborator still meets the expecations of the class under test. This is in line with the principle of Depedency Inversion.

Thus, returning to your example, the proper question is what does the ServerFacade need from the DAOs? You grow the DAO to meet the needs of the ServerFacade. Then, integration tests should be written to verify that the DAO meets the expectations set by ServerFacade. And any time you change ServerFacade's expectations, you'd better make sure the DAO still meets those expectations by updating the integration test.

Seriously, read the book Growing Object Oriented Software Guided By Tests, written by the authors of the EasyMock framework. Before reading your own interpretation of what you think mocks are for, read how the authors of EasyMock intended it to be used.

Growing Object Oriented Software, Guided by Tests is hands down the best TDD book out there in my opinion.

> I am a relatively new to development

If you're new to development, it's hard enough just to learn Rails by itself. In addition to the Rails concepts (e.g. ActiveRecord, view rendering, etc.) there's Ruby, databases/SQL, servers, HTML, CSS and JavaScript. Even if you're already comfortable with all those things, it's pretty hard to throw testing into the mix. When I first got started my question was, "What do I even test?" Do I write unit tests? Integration tests? View tests? Controller tests?

My advice would be to forget about Rails for a little bit and just practice testing Ruby by itself for a while. Then, once you're comfortable with testing Ruby, it will be easier for you to go back and try to write some tests in Rails.

> What is your recommendation on if I should focus on rspec vs minitest?

A person could make technical arguments for either. Deciding which testing framework to use depends on your objectives. If you're teaching yourself testing to become a more marketable developer, then I would definitely recommend RSpec. Almost every Rails project I've worked on (20+ production projects) has used RSpec. Having said that, it's less important which tool you choose and more important that you have a solid understanding of testing principles. I personally chose RSpec and I'm glad I did.

Here are some testing resources I often come across:

Growing Object-Oriented Software, Guided by Tests (awesome book, highly recommended)

Rails 4 Test Prescriptions (just started it, seems good so far)

Working Effectively with Legacy Code (super good book and more relevant to testing than it might seem like)

Everyday Rails Testing with RSpec (haven't bought it yet but seen it recommended a lot)

Destroy All Software (just bought it today, seems good so far)

Lastly, I myself created what I call a Ruby Testing Micro-Course designed to make it easy for people like you to get started with testing. Feel free to check that out and let me know what you think.

I realise this isn't free but Growing Object Oriented Software Guided by Tests is the best book on testing and OOP that I've ever read. I highly, highly recommend it.

Couple must reads:

http://www.amazon.com/gp/aw/d/0321503627?pc_redir=1408680419&robot_redir=1

http://www.amazon.com/gp/aw/d/0321127420?pc_redir=1408765483&robot_redir=1

http://books.google.com/books/about/Domain_Driven_Design.html?id=hHBf4YxMnWMC

Let me start by saying good code is code that solves the business problem at hand. For someone that really cares about internal quality of software that was a hard thing to accept.

You didn't quite define what you mean by "good" in your question, so I assume you mean adherence to SOLID principles. I've long thought like this too but realized adherence to some metric by itself is not very helpful, exactly because you end up in situations where your code is overdesigned, or worse, has the wrong abstractions.

What helped me figure out where the line is was stepping away from SOLID and focusing on Test Driven Development (TDD). TDD is great because it forces you only to write as much code as you need, not more not less. But in order to write testable code you'll have to apply SOLID principles. So you end up with code that reaches just the abstraction level you need to solve the business issue you're trying to solve.

The interesting aspect of this is that there's no clear universal line you can draw and say "this is too much design!" or "this is too little!". What I've observed is that there's just the right amount of design, and interestingly that's, at least in my opinion, a function of how much change you expect. Writing a 100 line hack to do something that you'll never change again is perfectly good code - it does what you need it to, it has certainly no wrong abstractions or over design. But as with most software, change is inevitable and with change internal quality becomes more important. If your code has good internal quality changing it is easier. The better the internal quality, the easier, within limits. So finding the line is an interesting exercise to balance the cost of design vs the expected rate of change.

If I may recommend some reading here:

• Sandi Metz' blog post on the cost of wrong abstractions and I highly recommend her other blog posts
  
• Growing Object-Oriented Software, Guided by Tests helped me figure out how to think about software quality and how to better design it

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

​

Other things to learn:

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

One option is to follow the techniques explained in the book Growing Object-Oriented Software, Guided By Tests. They use Test-Driven Development as their design technique, but they don't start from the bottom up and leave integration testing to the end. They start with the "walking skeleton" concept from Crystal Clear: A Human-Powered Methodology for Small Teams, an implementation of the thinnest possible slice of real functionality that you can automatically build, deploy and test end-to-end. They then start a TDD cycle by writing a failing acceptance test for one feature and, in the process of making that acceptance test pass, they will write a failing unit test, make it pass, and refactor and they will repeat this process until the acceptance test for the feature passes. The will then write the acceptance test for the next feature and go through the same process again until all features have been developed.

Besides the book itself, there is a short tutorial I was reading yesterday called Three Steps to a Useful Minimal Feature which describes how to write a "walking skeleton" using a simple "Pay a Bill" scenario.

Thanks!
During his degree, my friend who is currently in the machine learning engineer role had only studied one or two modules (out of 6 per year) of machine learning but still got the job. I believe they start with even more training than the software development grad scheme I'm on. I think it's 1-2 months of training before you start doing proper work.

The textbook was this one: https://www.amazon.co.uk/Growing-Object-Oriented-Software-Guided-Signature/dp/0321503627/ref=sr_1_5?crid=1VLKSUNCURZGL&keywords=test+driven+development&qid=1555061804&s=gateway&sprefix=test+driven+%2Caps%2C138&sr=8-5

I'll PM you the company

Working Effectively with Legacy Code is a good book that sounds applicable to your circumstance. Michael Feathers defines untested code as legacy code, which makes sense to me. Unfortunately untested code tends to be untestable, but tests are required to confidently make changes, so you have to chip away at the monolith strategically.

For the future, a good book on growing new systems alongside tests that inform design is Growing Object-Oriented Software, Guided by Tests

Today the defacto way to design something is though tests. Some people might disagree with me here but I believe that Test Driven Development can help. You may want to do a small top level design but before you write any code you must always write the unit test for that code first. This way you can see how it is going to be used before you spend time coding it. Each of your tests should represent a piece of functionality in the code base. As you write each test you implment just enough code to get it to pass before you move on to the next one. Never regressing by letting old tests fail.

I usually start with a top level class and work out it's relationship to other objects in the design through interfaces. Then I'll write tests for each of the dependent objects and work top down like this. This is known as the London style TDD. There are other ways as well.

I reccommend this book:

Growing object orientated design through tests

Also this one, (but it's a bit long winded and it's a different style of TDD)

Test Driven - Kent Beck

This is Dependency Inversion.

The best demonstration I have seen for effective use of interfaces is in Growing Object-Oriented Software Guided By Tests. Interfaces express the requirements a unit has that its dependencies must fulfill. The dependency is inverted (synonymous with terminated?) - instead of the unit depending on the specifics of its dependencies, the dependencies must be adapted to suit the requirements of the unit.

>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 want an excellent whirlwind tour to computer science basics with a language you've probably never heard of, I'd recommend MIT's Structure and Interpretation of Computer Programs course. The video lectures and the course book are available free online. It's pretty tough going but will seriously expand your mind :)

For design stuff I'd recommend reading books about OO testing and refactoring, like this or this.

The book recommended above by /u/clappski is very good. I also recommend it.

Since you probable will be doing some refactoring on your code, I'd also recommend:

• Growing Object-Oriented Software, Guided by Tests
  
  Im curious, have you tried to learn/use testing before? If so, what we're the challenges?

I thought that this book was pretty good, Growing Object Oriented Software Guided By Tests.

For me, when I was learning about TDD and testing in general, my biggest 'AHA!' moment was realizing that there isn't any secret to writing tests. Rather, the secret is to write code that is easily testable. When your code is easy to test, figuring out how to write your unit tests becomes trivial and all the TDD practices sort of fall into place. If your code is not easily testable, TDD and testing in general will be a huge pain in the ass, and it'll seem like a giant waste of time. In order to improve the testability of your code, I'd recommend reading about dependency injection/inversion of control if you don't already know about them.

I'd take a more tools- and methodology-driven approach. The programming language itself is secondary by a long shot. It's hard to be convinced of this when you're starting (hindsight is 20/20), but the fact is you don't need to spend hundreds of hours "learning a language." To a newbie, learning to program and learning a language is almost synonymous, but the latter is a far smaller subset of the former.

Here's how I would guide the younger me:

1. I would start by learning some of a language. The Pareto Principle (i.e., the 80/20 rule) applies here. In many languages you can spend a lifetime really exploring the details, but you'll largely forget these details through disuse. Why waste your time with that? It shouldn't take much more than a day to learn what you need to move past this step.
   
   
2. Learn very high level concepts of programming methodology. Engineering is about making complex systems easier to manage through things like encapsulation, information hiding, and abstraction layers. This is key to making software and is a lot more important than language-specific details.
   
   
3. Learn your tools inside and out. Learning a text editor is actually a great way to learn how to program. After all, a great text editor like vim is fully programmable. Things like snippets allow you to think about programming on a higher level beyond "do I need a bracket here?" etc. Another important tool is a debugger. There are some folks that advise against them, but it's incredible how much you'll learn by watching the way your code transforms your input. The third vital tool I'd suggest is using version control. Make a github account and use it in conjunction with your vim configuration files so that you may continually refine your environment (and never lose it, thanks to git).
   
   
4. Learn to use test frameworks, and then be adamant about writing tons of tests (preferably before writing any code).
   
   I think this is a great foundation. You don't need a lot of books, but I think Code Complete is a great one stop shop. I would probably also add something like Growing Object-Oriented Software because I feel Code Complete is a bit lacking when it comes to the actual practice of testing (though it provides a great overview of it).

Senior Level Software Engineer Reading List

Read This First

1. Mastery: The Keys to Success and Long-Term Fulfillment
   
   

   Fundamentals
   

   
   

2. Patterns of Enterprise Application Architecture
   
3. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions
   
4. Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML
   
5. Systemantics: How Systems Work and Especially How They Fail
   
6. Rework
   
7. Writing Secure Code
   
8. Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries
   
   

   Development Theory
   

   
   

9. Growing Object-Oriented Software, Guided by Tests
   
10. Object-Oriented Analysis and Design with Applications
    
11. Introduction to Functional Programming
    
12. Design Concepts in Programming Languages
    
13. Code Reading: The Open Source Perspective
    
14. Modern Operating Systems
    
15. Extreme Programming Explained: Embrace Change
    
16. The Elements of Computing Systems: Building a Modern Computer from First Principles
    
17. Code: The Hidden Language of Computer Hardware and Software
    
    

    Philosophy of Programming
    

    
    

18. Making Software: What Really Works, and Why We Believe It
    
19. Beautiful Code: Leading Programmers Explain How They Think
    
20. The Elements of Programming Style
    
21. A Discipline of Programming
    
22. The Practice of Programming
    
23. Computer Systems: A Programmer's Perspective
    
24. Object Thinking
    
25. How to Solve It by Computer
    
26. 97 Things Every Programmer Should Know: Collective Wisdom from the Experts
    
    

    Mentality
    

    
    

27. Hackers and Painters: Big Ideas from the Computer Age
    
28. The Intentional Stance
    
29. Things That Make Us Smart: Defending Human Attributes In The Age Of The Machine
    
30. The Back of the Napkin: Solving Problems and Selling Ideas with Pictures
    
31. The Timeless Way of Building
    
32. The Soul Of A New Machine
    
33. WIZARDRY COMPILED
    
34. YOUTH
    
35. Understanding Comics: The Invisible Art
    
    

    Software Engineering Skill Sets
    

    
    

36. Software Tools
    
37. UML Distilled: A Brief Guide to the Standard Object Modeling Language
    
38. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development
    
39. Practical Parallel Programming
    
40. Past, Present, Parallel: A Survey of Available Parallel Computer Systems
    
41. Mastering Regular Expressions
    
42. Compilers: Principles, Techniques, and Tools
    
43. Computer Graphics: Principles and Practice in C
    
44. Michael Abrash's Graphics Programming Black Book
    
45. The Art of Deception: Controlling the Human Element of Security
    
46. SOA in Practice: The Art of Distributed System Design
    
47. Data Mining: Practical Machine Learning Tools and Techniques
    
48. Data Crunching: Solve Everyday Problems Using Java, Python, and more.
    
    

    Design
    

    
    

49. The Psychology Of Everyday Things
    
50. About Face 3: The Essentials of Interaction Design
    
51. Design for Hackers: Reverse Engineering Beauty
    
52. The Non-Designer's Design Book
    
    

    History
    

    
    

53. Micro-ISV: From Vision to Reality
    
54. Death March
    
55. Showstopper! the Breakneck Race to Create Windows NT and the Next Generation at Microsoft
    
56. The PayPal Wars: Battles with eBay, the Media, the Mafia, and the Rest of Planet Earth
    
57. The Business of Software: What Every Manager, Programmer, and Entrepreneur Must Know to Thrive and Survive in Good Times and Bad
    
58. In the Beginning...was the Command Line
    
    

    Specialist Skills
    

    
    

59. The Art of UNIX Programming
    
60. Advanced Programming in the UNIX Environment
    
61. Programming Windows
    
62. Cocoa Programming for Mac OS X
    
63. Starting Forth: An Introduction to the Forth Language and Operating System for Beginners and Professionals
    
64. lex & yacc
    
65. The TCP/IP Guide: A Comprehensive, Illustrated Internet Protocols Reference
    
66. C Programming Language
    
67. No Bugs!: Delivering Error Free Code in C and C++
    
68. Modern C++ Design: Generic Programming and Design Patterns Applied
    
69. Agile Principles, Patterns, and Practices in C#
    
70. Pragmatic Unit Testing in C# with NUnit
    
    

    DevOps Reading List
    

    
    

71. Time Management for System Administrators: Stop Working Late and Start Working Smart
    
72. The Practice of Cloud System Administration: DevOps and SRE Practices for Web Services
    
73. The Practice of System and Network Administration: DevOps and other Best Practices for Enterprise IT
    
74. Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale
    
75. DevOps: A Software Architect's Perspective
    
76. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations
    
77. Site Reliability Engineering: How Google Runs Production Systems
    
78. Cloud Native Java: Designing Resilient Systems with Spring Boot, Spring Cloud, and Cloud Foundry
    
79. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation
    
80. Migrating Large-Scale Services to the Cloud

Do you know: Growing Object-Oriented Software, Guided by Tests?

It's main language is Java. But, the technics can be easily applied to Ruby environment.

https://www.amazon.com/dp/0321503627

Growing Object Oriented Software Guided By Tests. This book shows you how to grow a project and refactor as you go along to keep the code clean.

https://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627

First of all, Capybara is the wrong approach. Take it from a guy who wrestled with Capybara for too long and decided it's a shitty way to do testing. You should need to use Capybara in your test suite AS LITTLE AS HUMANLY FUCKING POSSIBLE. Seriously. If it takes some crazy test setup just to get a look at a view you can assert against without using Capybara, USE THAT. No joke. If some of your site depends on Javascript-generated content that requires you to have Javascript run and do its thing before you can even assert anything about the output... Redesign that shit. For your fucking sanity. Note: I am slightly insane because I've been in those trenches.

It looks like you're writing Ruby. Do you have 30 minute long (or longer) test suites yet? (Ours got as high as 45 minutes. 45 minutes before you could context-switch onto another project. If it failed, start all over again. Another 45 minutes.) It's because you have too many integration and Cucumber tests, basically. Plus, you're probably essentially testing the database repeatedly in every single test. Boss complaining about slower and slower release productivity and deploy times yet? Explain to him that it's your test suite and the code under test and that he'll have to start budgeting (the dreaded) refactoring time. Start trying to pitch to your boss to refactor the code to be 95% unit tests of Plain Ol' Ruby Objects (PORO) which can hopefully more easily be run in parallel. Tell him you'll do it Freeman/Pryce/Beck style and Martin Fowler style, because those guys really know their shit, and there won't be much risk of new bugs being introduced because they stick to known-good code transformation patterns. Then get shot down (because features features features is this bug fixed yet get back to work don't see the forest for the trees), then quit before the shit hits the fan. Make double the money contracting, because shit is hot right now. Watch your former boss leave the company after his RSU's vest... which was his gameplan all along. See, he didn't give a shit about the codebase, he just wanted money. See: my last year.

Oh... and don't get me started on the ENV being a HashWithIndifferentAccess. I spent a MONTH on a bug caused by a bug in HashWithIndifferentAccess inside the ENV (customers would lose sessions randomly. How shitty is that?). ENV should be a fucking plain old Hash. HWIA can take a long walk off a very short pier, or at least be considered harmful.

I would suggest reading these books to get a deep understanding of OOP:

• Agile Patterns, Princples and Practices in C#
  
• Growing Object Oriented Software Guided by Tests
  
• Clean Code
  
  Here's a chapter from the Agile PPP book, Heuristics and Coffee, which gives a great overview on how to think in OOP terms. Keep this in mind: OOP is a way of thinking as much as it is a way of programming. OOP lives in the spaces between objects, in the methods, not necessarily the objects!
  
  Also, note that OOP is a code organization, which really starts to make sense in larger programs. I would suggest writing some larger programs, such as a contact manager, an email client, a chat application, etc. Larger programs will give you a chance to play with technologies such as databases and client/server networking. More stuff to add to the ol' resume.

Bien. le voy a echar ojo.

Yo ahorita estaba estudiando lo mismo pero leyendo Growing Object-Oriented Software, Guided by Tests. Esta bien bueno tambien ese libro. Lo vi recomendado por el tipo que creó Angular.js en este GoogleTechTalk: How to Write Clean, Testable Code. Tambien recomiendo ese talk

Growing Object-Oriented Software, Guided by Tests - very practical description with a lot of code examples on how to implement tdd

For learning, I use plural-sight courses and/or use specific books.

This seems like a good course Outside-In Test-Driven Development. You can sing up for 10 days trial and see if you can learn something from it.

This is also good book Growing Object-Oriented Software, Guided by Tests Paperback– Oct 12 2009

by Steve Freeman (Author), Nat Pryce (Author). But it's bit outdated with the project and technology. The key concepts is there which is get a walking skeleton done and than use TDD to add features and refactor along as you go.

Also don't get bogged down with details in the beginning; otherwise it will be never end journey. Before you try anything you should ask your self how is going to help me be a better developer.

I am not sure what your experience level is so can't say much.

​

I haven't seen this suggested, but it is a good book on exactly that topic.

Clean Code by Robert Martin.

and I have to mention...

Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Yours Truly, which frequently touches on that topic