Talk proposal. What do you think?

gistfile1.md

Frequently Asked Questions

As a mentor for thoughtbot's Prime service, I've provided coaching to over 100 developers.

In my talk, I'll share the questions I'm asked repeatedly, and how I answer them.

This discussion will be targeted at beginner and intermediate developers striving to improve.

Likely discussion includes:

• What should I do if I inherit an app with no tests?
• Any advice on how to switch to vim?
• How does one land her first Rails job?
• How does one land a better Rails job?
• How do I conquer the fear of letting others see my code?
• Am I underpaid?
• How do I balance integration and isolated tests?
• How can I make myself stick to TDD when the going gets tough?

Plus, because it's me, we're gonna do some live coding. Take bad code. Make good. Happy times.

Thanks @jalcine.

How can I make myself stick to TDD when the going gets tough?

and

What should I do if I inherit an app with no tests?

are most useful. I have inherited codebases that are built with unconventional Rails or legacy Rails (1.x stuff), and then they've been bandaged with ad hoc javascript. Sometimes it is possible to declare bankruptcy and start from scratch, but other times, we need to write a test suite and then start throwing away old code so we don't break functionality. It's hard to know where to start sometimes.

Balancing long, complicated cucumber features against unit tests is something I've struggled with myself. I feel like something is wrong when my feature is 60 lines long and involves users logging in and out multiple times. Is there a way to write other tests that give the same confidence level as full-stack integration tests?

Also, perhaps some more tips on isolation and when and where to put behavior in a subclass would be helpful. Something tells me that my poor cucumber suite could be a lot faster if my models were organized so that the unit tests can test everything in isolation. I think duplicated behavior leads to a lack of confidence or understanding which leads to massive integration suites.

I see three talks there: job stuff, testing stuff, and dev related interests (fear or showing code, vim, etc). All look great but I can't imagine how you'd get through them all in any depth inside one talk.

For me the "What should I do if I inherit an app with no tests?" and "How can I make myself stick to TDD when the going gets tough?" would be the most relevant. Live coding where you take bad code and make it awesome would be super cool to see.

How about something like:

"How do I actually begin with Ruby to be able to use Rails?" ( Not an introductory talk, just some tips or advices )

I agree with Jack, above -- it feels like a couple of talks, not one focused talk. Which might be fine if you structure it that way. In particular it looks like you've got the tech talk -- how do I deal with the code I'm given, balance testing, etc (which probably will include old fave "how do I convince my managers that testing is important?") -- and the career talk. Both are important but I'm not sure both can be given proper attention within the same talk? On the career side, I'd also add in the item "where do I go from here?" as I've fielded that question for developers in the past. Once you get started on Rails, then every young developer ends up trying to figure out what's next, what do they want, and how do they get there. Important stuff.

FWIW I'd love to hear this talk, especially the "switching to vim" stuff.

@voylinux Good idea!

where do I go from here?

This is a really interesting area. Going from nothing to knowing every day rails is quite a defined path. Moving from intermediate to advanced is a lot less clear. Going the last 20% often takes the most time as the return on investment becomes less noticeable.

Very interesting questions, I would add one more if I may : "How to approach a complex codebase ?".

For example : given the codebase RSpec, given a simple feature I want add, when I'm exploring it with Pry, then I want to ask myself the right questions in order to achieve my goal.

I don't know if this is simply something that you learn by doing (it is I guess), or if there is also a "methodology" that can help.

I think this is a great topic and will make for a great talk. One added area that I would like to see included is your thoughts on how a small group may or may not impact the ability to level up? For example, there is a group of 3 PHP developers who have worked together for years and want to switch over to Rails/Ruby. What strategies might they implement as a group to try to decrease the ramp up time.

For feedback, my personal ranking of topics above, top being highest priority:
How can I make myself stick to TDD when the going gets tough?
What should I do if I inherit an app with no tests?
How do I balance integration and isolated tests?
How do I conquer the fear of letting others see my code?
How does one land a better Rails job?
How does one land her first Rails job?
Any advice on how to switch to vim?
Am I underpaid?

Live coding in talks!!! Yes please.