The Loosely Coupled Podcast

Jeff Carouth and Matt Frost discuss developer life as it relates to practice and patterns

Episode 11: I Learnded Goodly

In this episode Jeff and Matt talk about how we teach and how we learn as developers. Often subjects such as testing or object-oriented programming are taught in ways that could be considered the most difficult way possible. This episode covers some advice about how teach these types of subjects in an accessible way and, even better, how to go about learning difficult subjects.


Episode 10: Titles and Classifications

In this episode Jeff and Matt continue their conversation about careers by discussing their thoughts on titles and classifications of developers. If you’ve ever asked “what is a senior developer?” or even “am I a senior developer?” this episode is for you.


Episode 9: Career Development

In this episode Jeff and Matt discuss experiences with career management and career development. This was the first ever live recording of an episode, broadcast over Google Hangouts on Air. With the help of the kind folks in the IRC channel (#looselycoupled on Freenode) this episode covers topics such as salary negotiation, when to ask for a raise or promotion, how to plan a career plan, how to deal with co-workers in difficult situations, and a few other pieces of advice about successfully navigating a career as a developer.


Episode 8: Do You Even Polyglot?

In this episode Jeff and Matt talk about the idea of polyglotism, the benefits, practical advice about choosing which languages to learn and how to be successful while learning new languages. You should go out and find a new language and prepare to give it the time it deserves. It’s best to find a mentor or someone to help you and step out of your language or paradigm comfort zone.



Episode 7: Building a Testing Culture

In this is episode Matt and Jeff discuss how to build a testing culture in your company. They discuss organization resistance, the importance of testing and how to move forward when the rest of your company is less than excited.


Episode 6: PHPTownHall Mashup

In this episode, Matt and Jeff join forces with PHPTownHall to talk about Open Source, burn out and briefly discuss their favorite open source projects. Jeff had a spell of bad luck with the wifi at the AirBnB he stayed at in San Franciso, so you may not get as much of him as you’d like.

If you’ve not checked out PHPTownHall, you can do so here PHPTownHall

Also if you aren’t following Ben or Phil on Twitter you should:


Episode 5: Side Projects

In this episode Matt and Jeff talk about how and why you should consider getting involved in side projects. Despite the jovial subtitle, “Getting a little side action,” participating in development outside of your normal development routine is beneficial to you as a developer as well as to your employer or clients. They further expand on the topic by talking about non-code-related side projects such as podcasts, discussion groups, or even writing.

If you’re looking for a project to get involved with, the PHP Mentoring Mentor App would love to have your participation. Contact either of us, or come hang out in #phpmentoring on Freenode to get involved.


Episode 4: An Agile Rant

In this episode Matt and Jeff talk about their experiences with adopting Agile as individuals and as teams. The important take aways are to not be too loose nor too rigid with the practice; to accept change as it happens but to not force change too rapidly; to honor the purposes of the components of agile practices; and, above all, to find what works for your team specifically over what you read in a book.



Episode 3: Conference Conversations

Episode 3 of the Loosely Coupled podcast was recorded live at Lone Star PHP. Since we were at a conference, we decided to do a meta episode about conference experiences and speaking at conferences. This episode covers information from how Jeff and Matt got involved with the conference community all the way through some advice on submitting your first talks. If you have never been to a conference, find a way to get to one soon. It’s more than just the presentations.



Episode 2: My Code Is Perfect

Writing clean code isn’t something you pick up overnight, nor is it a brand new topic. In this episode Jeff and Matt discuss the characteristics and mechanics of creating clean code and how to approach your project from a clean code perspective.



In this episode, Jeff and Matt talk about code quality and beautiful code. Beautiful code follows a standard. If you don’t have one, find one and adopt it. For PHP projects you can start with PSR-2, a part of the PHP-FIG Standards, or PSRs (not actually called Phil’s Silly Recommendations.)

Find a project you can admire–or at least one that has the quality level you want to achieve–and study it. One example might be to look at a framework that’s popular, such as Laravel. Study the project and realize that it likely didn’t come to exist exactly how it is now overnight.

Don’t be afraid to throw code away. Your first solution will never be the best solution to the problem. It’s okay to write code to learn more about your problem–perhaps just tests, even–and then get to a reasonably-clean solution eventually.

While Jeff and Matt talk a lot about coding standards, there is much, much more to clean code. The three holy books of clean code are Clean Code: A handbook of Agile Software Craftsmanship and The Clean Coder: A Code of Conduct for Professional Programmers by Robert Martin (a.k.a. Uncle Bob,) and Code Complete: A Practical Handbook of Software Construction by Steve McConnell. Reading these three books won’t necessarily make your code better, but it certainly won’t hurt you to be aware of what they contain.

Learning the process of writing clean code takes an entire career. Matt watched a relevant TED talk about the technique of learning things in 20 hours called Learning Anything in 20 Hours. To become great at doing anything as a programmer, you have to learn the process of breaking your subject up into segments and practice. It’s Matt’s opinion that the idea of taking 10,000 hours to master something is too daunting, so breaking things up into 20-hour segments is more appealing.

On the subject of practicing, one useful tool for practice is a Code Kata). There is a formal definition and lots of resources for code katas. But what if you could just apply the concept of repetitive practice into your tasks? Matt did something like this with an OAuth 1.0 client he was working on to learn about signatures.

There is no substitute for actually writing code. No amount of reading documentation will substitute for experiencing the errors that come about from your misunderstandings. It is part of the process.

Being a sole developer is hard in terms of code quality. You need someone else to look at your code because that exposes the problems with the legibility of the code you’re writing. So if you are a sole developer, find some way to get someone else’s eyes on your project. No one will know if your code is good or bad if they can’t see it. Posting small gists or pastebins is not sufficient.

Ship early, ship often. If your code is only local, no one can help you. Get your code out there as soon as possible. You’ll be a better developer because of it.

Jeff and Matt weigh in on developing libraries for a larger audience. You should start by solving an actual problem in your business, then extract into a library if it’s relevant outside of your business. Don’t start out with the goal of making the new hotness, let that come naturally. Matt mentioned his Snaggle library as something he’s working on right now and Jeff mentioned a project he worked at for his employer called the Gem formerly known as Clerk. Both of these started as libraries which kind of contradicts this advice.

If you’re looking for a HTTP client for your PHP projects, look no further than Guzzle.

The last important point of discussion is to always challenge your expectations and assumptions in your code. When you’re writing code you should be constantly asking yourself, “why am I doing it this way?” Sometimes the answer is, “I don’t know,” which means you need to take a break and seek out the answer to the question.

Go forth and practice writing clean code.