The PHP Rountable podcast, hosted by PHP community member Sammy K Powers, has posted their latest episode - Episode #77: Tech Interviews for Self-Taught PHP Programmers. In this episode Sammy is joined by Frank de Jonge, Parker Phinney and Gayle Laakmann McDowell.

Self-taught PHP programmers, even those of us with decades of experience, would likely fail a tech interview in an epic way. If you've ever wanted to work for a big tech company like Google, Amazon or Facebook but have always been too nervous about the tech interview, this episode is for you.

We chat about what we need to do to be fully prepared for a tech interview. And maybe soon you'll be showing your friends how to reverse a binary tree on a whiteboard.

You can catch this latest episode either using the in-page video player or you can watch it directly over on YouTube. If you enjoy the show, be sure to subscribe to their feed and follow them on Twitter for updates when new shows are released.

In a new tongue-in-cheek (humor) post to his site, Tomas Votruba shows you how to criticize like a senior programmer when offering feedback on code errors or architecture decisions.

As I spend most of my socials online time on Github and PHP-related discussion, I've noticed many people do so many wrong things while giving critics. I want to correct this once and for all, so I've prepared a guide for you.

His recommendations (again, the opposite of what is actually useful) include and eight step process to find a bug, never reversing your stance, repeating the same comments over and over and always telling, never asking. Following this list of "not to dos" he also includes a list of "to dos" correcting the misconceptions. This list includes:

• asking if feedback is desired
• determining your motivation for the feedback
• replacing "you" with "I"

In each recommendation there's examples of phrasing and comments that give you some guidance on how you can be more effective at giving feedback on projects and code.

On the Laravel News site there's a new post sharing five command line tools that could be helpful for developers and make their workflow a bit simpler.

Over the last several years, I’ve improved my command line searches through a few tools geared towards programmers. These tools help developers find phrases and patterns in text files in an unfamiliar codebase without the complexity of grep.

The following is a list of five command line search tools that will help you as a developer if you are interested in using the command line more for finding code, text, and files quickly without relying on an editor or an IDE. Some of the tools are ‘nix only, but I’ve listed a few that are cross-platform and ridiculously fast!

His list describes the usage and benefits of:

• grep
• Ack
• the Silver Searcher
• Sift
• RipGrep

Each includes command examples and, where required, the commands to install the library (as it's not standard for Linux builds).

On the Stitcher.io blog there's a new article posted about a programmer's cognitive load and offers some tips to help reduce it, especially when reading code that's new to you.

Whether it's your own code or that of others, when you open a file, you have to take it all in. You need to wrap your head around what's going on, before you're able to write your code. Doing this day by day, it's important to find ways to make this process easy. To try and reduce this cognitive load as much as possible. Streamlining the way you take in code, will allow you to not only work faster and better; but also improve your mental state and mood.

[...] Today I want to share some techniques that can help you reduce this cognitive load while coding. In contrast to some recent advocates of "visual debt", I won't talk about stripping away pieces of your codebase. We'll look purely into the visual aspect: what makes code hard to read and reason about, and how to make it easier.

The tips they article make use of some of the most common features of IDE including adjusting fonts and spacing, using code folding to reduce visual noise and effective naming. Each point has either screenshots or code examples to help illustrate the point.

On the SitePoint PHP blog Christopher Pitt has written up a new article, a story about "John" a developer caricature that's all too familiar in the development world and how you can grow up from "being a John". It's all based on Christopher's own experiences too.

John was a developer. To be specific, he was a young, white, straight, young, self-taught developer. He wasn’t rare, but he was special. John grew up with a couple parents, who paid for everything he needed.

[...] John got average grades, but it was ok because [according to mum]; “he’s just bored of schooling, and too clever”. He walked right out of high-school and into a programming job. The pay wasn’t great; only enough for a small apartment and modest groceries [for one]. In time he’d earn more. [...] Over the years, John quickly got bored of programming. He loved the thought of the career, but it was all so boring. He moved jobs every year or so, and only then when his idiot bosses stopped seeing how much he mattered to their company.

He talks about his own past, how he realized he was a "John" and how he made the conscious decision to grow up and out of that situation. He talks about those being born into comfort and how they're not always forced to grow up or to really struggle. He mentions other common "John" points of view ("we can always just move jobs" or "meetings are just a distraction"). He's angry with himself for seeing so much of his previous life in these examples. He's also angry to see these same patterns in other developers around him, other "Johns" that treat him the same way with excuses, failed promises and delays.

I think of all these clever little things I could do, to force John to work. All these processes and mantras and check-lists. Then I despair. The only thing that’s going to make John realise he is wasting away is wasting away enough to fall through his safety net. He’s going to have to grow up on his own, and maybe then he’ll pay it forward to his future employers and clients.

On the O'Reilly Software Engineering blog there's a post from Gregory Brown sharing what he thinks is the definition of a "proficient programmer" and how it differs from competence.

Do you know what the difference between competence and proficiency is? That sounds like a trick question, because the words seem to mean the same thing. But the subtle distinction between them is critically important.

Competence means having enough experience and knowledge to get stuff done; proficiency involves knowing why you are doing something in a certain way, and how it fits into the big picture. In other words, a proficient practitioner is always a competent practitioner, but the opposite may not be true.

He goes on to talk about the Dreyfus Model of Skill Acquisition and how it relates to the biggest bottleneck he sees for developers: "crossing the divide from competence to proficiency." He defines what it means to be a "competent" programmer first and then one of the things junior developers struggle with - thinking knowledge is enough to make you more competent. He gives a more concrete example of this with the use of the Memento pattern, when to use and - for the competent side - when it breaks down.

He ends the post with some suggestions that can help you if you're wanting to make the jump from "proficient" to "competent" (even if you've been programming for a long time, some good tips here).

In his latest post Ben Ramsey suggests that "yak shaving" (a seemingly useless activity that lets you solve an immediate problem) is a core part of what we, as developers, do.

When I began my journey as a programmer, every task was fraught with problems, and I loved it. Everything was new, and every problem was an opportunity to learn and grow. It was great.

Somewhere along the way, though, problems became nuisances. As I grew older in life and my career, my tolerance for problems became lower, and my desire for things to Just Work became greater.

As I struggled to find a solution for the problem I had with Packer, Tate Eskew reminded me that yak shaving is a part of my job.

In his example he was working with Packer and hit a problem with the environment required to get it working. Instead of slogging through it he created a patch to make it work correctly with Amazon Machine Images.

In a recent post to his site Sahand Saba has posted a list of nine anti-patterns every programmer should avoid. This list isn't language specific and ranges in types of advice from general programming practices down to more specific "code smells" to avoid. The code examples are in Python but you can interpolate them into the world of PHP pretty easily.

A healthy dose of self-criticism is fundamental to professional and personal growth. When it comes to programming, this sense of self-criticism requires the ability to detect unproductive or counter-productive patterns in designs, code, processes, and behaviour. This is why a knowledge of anti-patterns is very useful for any programmer. This article is a discussion of anti-patterns that I have found to be recurring, ordered roughly based on how often I have come across them, and how long it took to undo the damage they caused.

The list of nine includes things like:

• Premature Optimization
• God Class
• Inner-platform Effect
• Management by Numbers

Each item on the list includes a few subheadings talking about what it is, why it's bad, how to avoid it and some code examples (where appropriate) to find it in your code.

Anna Filina has posted her own addendum to a top ten list of common PHP programmer mistakes, adding seven more of her own.

I was recently asked by one of my readers to give feedback on the following article he read: 10 Most Common PHP Mistakes. It is well written and very thorough. Most of the tips are specific to PHP, others are about web programming in general or database performance. It’s a very good read. I was also asked to contribute to this list, so here are 7 more tips.

Her list of seven touches on topics like caching, allowing SQL injection, disabling error reporting and ignoring accessibility. She also includes some configuration settings, code and links to other tools/resources to help provide information on preventing these other mistakes.

The /Dev/Hell podcast, hosted by Chris Hartjes and Ed Finkler, has posted its latest episode - Episode 41: Let Me Wet My Beak. In this new episode they're joined by guest David Rogers.

This week we’re joined by David Rogers, aka @al_the_x, to hear how he’s teaching PHP in college courses for brand-new programers. We also talk about what possessed Ed to develop his own unit testing framework.

You can check out this episode either through the in-page player or by downloading the mp3 of the show. Also, be sure to subscribe to their feed if you like what you hear.